為何人人都在 token 焦慮？

作者｜Cynthia

編輯｜鄭玄

千呼萬喚，2026 年 6 月 1 日兒童節當天，MiniMax 第三代旗艦模型 M3 終于發布了。

光看官方解讀，六個關鍵詞就可以概括這款模型的全部亮點：Coding 能力、1M 上下文、原生多模態、Computer Use、低價 Token Plan、開源。

能力上，作為國內首個集齊了 Frontier 三件套——前沿 Coding/Agentic 能力、百萬 token 級超長上下文、原生多模態的開源模型的國產模型，M3 的實力不必多提。

畢竟在此之前，能同時集齊這三項的，只有 Claude Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5 這些海外頭部閉源模型。

能力固然耀眼，但這次主要想聊一聊的，是它的價格。

官方信息顯示，這次的 MiniMax Token Plan 設計上，個人開發者套餐分三檔：Plus 49 元/月，6 億 token；Max 119 元/月，18 億 token；Ultra 469 元/月，55 億 token。

換算下來，Max 檔在相近價格下約等于 Claude 訂閱的 15 倍用量。

過去在 Chatbot 時代，很多人可能對這種性價比沒什么概念。畢竟用戶問一句，模型答一句，成本還比較溫和。到了 Agent 時代，模型開始學會讀倉庫、掃文件、跑測試、看日志、修 bug、跑測試。一次任務背后，可能是幾十次、幾百次模型調用。

于是，模型變聰明了，但成本也沒多少人扛得住了。

而一個聰明又有足夠性價比的模型，對很多個體以及企業而言，有時候往往就是 AI 真正走向落地的臨門一腳。

01

從 Agent 經濟學的痛點，

到 49 元的 Plus Token Plan

過去大家討論 AI 替代人、解放人，常常默認 AI 一定更便宜。

但這句話成立，是有限制條件的。

特別是 Coding Agent 場景，前段時間，一篇關于 Agentic Coding 成本的研究，分析了 8 個前沿模型在 SWE-bench Verified 上的運行軌跡發現一個有意思的現象：

Agentic Coding 類任務，token 消耗不是線性增長，甚至可以達到普通代碼問答的 1000 倍。更麻煩的是，有時候，token 燒得更多，準確率并不一定繼續變高，很多任務的準確率會在中等成本區間達到峰值，然后趨于飽和。

背后邏輯在于，Coding 需要用戶把完整的項目文件、代碼上下文喂給 AI，才能產出真正可用的代碼。是典型的輸入 token 遠大于輸出 token 的場景。越是生產級場景，上下文成本就越是貴得離譜，有時候，甚至會超過人力成本本身。

這也就解釋了為什么很多過去在 AI 使用上非常激進的企業，從今年開始，出現了態度反復橫跳：

一個極端案例是 OpenClaw。其創始人 Peter Steinberger 曾曬出 30 天消耗約 130 萬美元 OpenAI API token 的賬單，覆蓋 6030 億 token、760 萬次請求，背后是約 100 個 Codex agent 在跑自動化開發任務。

Uber 更是 CTO 與 COO 先后公開下場吐槽，公司到 2026 年 4 月已經花完了全年 Claude Code 預算。

在這一背景下，MiniMax M3 的性價比已經不是便宜一點的問題，更是 Agent 真正普及前的臨門一腳：

Agent 不能試錯就做不了復雜任務；但試錯太貴，企業就會關止步不前，個人開發者也會變得保守。

以前模型競爭的核心的是智力上限，agent 時代，單位成本下的有效工作量才是真正的重點。

這就是為什么我認為 M3 的性價比其實也是產品能力的一部分。

但支撐這個性價比的根源在于哪里？性價比背后，產品的體驗又究竟如何？

02

為什么行業發展到現在，

需要更強的 Coding 和長程自主迭代

價格解決的是敢不敢用，下一步用戶關心的，是值不值得用。

M3 官方給出的 Coding benchmark 很好看：SWE-Bench Pro 59.0%、Terminal Bench 2.1 66.0%、SWE-fficiency 34.8%、KernelBench Hard 28.8%、MCP Atlas 74.2%。

這些數字當然重要，但我更建議把它們當成一個參考系，而不是結論。真正的亮點其實是官方用 M3 實現的兩個實際案例：復現論文和優化 CUDA 的 Hopper FP8 GEMM kernel。

先看看 Hopper FP8 GEMM kernel 優化案例。

在這個任務里，M3 的起點只有任務描述、benchmark 腳本和一個不能直接運行的 Triton 骨架，沒有 reference 高性能實現。

M3 在約 24 小時內完成 147 次 benchmark 提交和 1959 次工具調用，把 Hopper FP8 GEMM 的硬件峰值利用率從 7.6% 推到 71.3%，實現 9.4 倍加速。

這里最重要的細節其實不是最后的 71.3%，而是最優解出現在第 145 次提交。作為對比，除 Opus 4.7 和 M3 外，其余模型大多在前 30 次提交內不再取得新進展并主動退出。

也就是說，模型并不是前幾輪靈光一閃就完成任務，而是在多個平臺期里繼續診斷、嘗試、驗證、推翻，再嘗試。

這個過程里，模型需要需要維持目標、記住歷史、理解 benchmark 反饋，還要避免在多輪改動中把系統搞亂。

這也是 Coding Agent 和代碼補全工具的分界線。一個普通 vibe coding 群體可能沒意識到的現實在于，真實的生產級環境中，無論 AI 還是人類，產出代碼第一次跑不起來很正常；跑起來之后性能差也很正常；優化完引入新 bug 也很正常。而工程任務的大部分時間，都花在診斷、驗證、回滾、再嘗試。

這個能力的背后，不能只靠模型參數更大，還需要訓練數據更接近真實用戶邏輯。為此，MiniMax 構建了交互式用戶模擬器，模擬真實開發者在同一個 session 中不斷補充需求、調整方案、派發任務、反饋修正。

這也是為什么我在前面說，benchmark 結果漂亮固然很重要，但不能直接將其平移到生產環境。今天很多 coding benchmark 仍然是 single-turn task，但真實協作一定是 multi-turn、multi-file、multi-tool、multi-objective。誰能把訓練和評測從一次性解題推進到持續協作，誰才更接近下一代 Coding Agent。

另外再看一下復現論文案例，這個也同樣很有意思。M3 被要求復現 ICLR 2025 Outstanding Paper Award 論文 Learning Dynamics of LLM Finetuning。它自主運行了接近 12 小時，產出 18 次 commit 和 23 張實驗圖表，跑通核心實驗，并觀測到 SFT 階段預測概率變化、DPO 的 squeezing 效應，以及 Extend 緩解方法。

這個任務的特點在于任務本身夠復雜，需要的能力也夠多。模型要讀論文正文，理解公式和圖表，寫實驗代碼，跑訓練腳本，檢查結果是否對齊論文結論，再根據偏差調整實驗設置。這就需要，模型的智能上限、長上下文、編程、多模態、工具調用、事實糾偏各種能力必須同時成立。

而 M3 的一大特點，正在于它是從 Step 0 開始做多模態混合訓練，而且使用的是文本、圖像和其他模態自然交錯的數據。

放到 Agent 語境里，它意味著模型更容易進入真實工作現場，幫開發者看架構圖、錯誤截圖、性能曲線、PR 頁面和終端輸出，幫研究員讀論文正文，以及表格、圖像、曲線和公式。還能幫企業員工在 ERP、Excel、網頁后臺、本地客戶端、聊天工具之間來回切換，讓多模態與智能本身，成為牢不可分的一體兩面。

我在測試里直接讓 AI 根據《西游記》小說，制定一個交互地圖。

完成這個任務的難點在于，首先模型要自己找到《西游記》原文共 100 回，60 余萬字并通讀理解。

在此基礎上，做西游交互地圖最難的是原著地名散亂、虛實空間混雜：行程描述只寫里程但沒有坐標，所有的動線、事件跨百回分布，必須全本上下文統籌梳理空間關聯；而仙界洞府等多層平行空間中的各種虛構場景沒有現實 GIS 參照，同時一些凡間位置，雖然有現實世界原型，但又并未在書中明說。

要把這些文字描述轉成地圖畫面、自動生成開發代碼，對模型的上下文能力、工具調用能力、多模態能力、agent 協作能力，甚至審美都是不小的考驗。

向上滑動查看

這是最終的生成 HTML 頁面的截圖，可以看到，不僅路線圖與劇情完全吻合，甚至不同地點可能對應的現實世界方位，也基本一致。

比如五行山對應現實世界河北五指山，法門寺在陜西西安，通天河在青海玉樹附近，而流沙河對應現實世界新疆塔里木的開都河，與現實世界原型的參考方位幾乎一一對應。

03

稀疏注意力搞定 1M 上下文已經不新鮮，

但如何保證命中率？

講完價格和 Coding，到這里，很多人應該也就能理解 M3 設計的稀疏注意力機制支撐起的 1M 上下文背后的邏輯了。

長上下文現在已經不稀奇。很多模型都在宣傳 200K、1M，甚至更長。問題在于，窗口長不代表模型會用。

Agent 不可能每一步都從零開始思考，它必須把過去的失敗、用戶偏好、項目結構、工具反饋沉淀進上下文。相應的，模型的上下文中會堆滿了超長的代碼文件、終端日志、失敗記錄、benchmark 輸出、用戶反饋、歷史工具調用和中間推理痕跡。

長上下文是實現這一切的基礎。但有時候，窗口越長，也就意味著各種中間狀態、無關內容構成的噪音越多，輸出質量越差，成本也越容易爆炸。

在這一背景下，使用稠密注意力，上下文長度的擴張以及輸出效率會受到限制，成本也會隨之失控。

使用普通稀疏注意力，能省成本，但容易犧牲細粒度信息定位能力。

但偏偏，Agent 執行過程中，最怕漏細節。一次工具調用里的關鍵報錯、某個代碼文件里的邊界條件、某張圖里的曲線異常，都可能決定任務能不能繼續。

因此，實現長上下文本身不難，真正難的是如何實現成本、效率、命中率的三者得兼。

了解行業背景的都知道，MiniMax 不是今天才開始做長上下文和稀疏注意力。

2025 年年初的 MiniMax-01 就用了 Lightning Attention，并且把模型訓練上下文做到 1M，推理上還嘗試外推到 4M 的更長上下文；

后來去年同一時期的 MiniMax-M1 繼續使用 hybrid attention，加上 MoE 和強化學習，主打長上下文、長推理和復雜軟件工程任務。

到了后來的 M2，MiniMax 還一度短暫回退到稠密注意力路線，直至此次 M3，MiniMax 借助 MSA 再次回歸稀疏注意力。

相比業內的其他稀疏注意力方案 DSA、MoBA 等，MSA 通過 scalable sparse attention、document-wise RoPE、KV cache compression 和 Memory Parallel 等設計，可以把訓練和推理復雜度做成線性，并在從 16K 擴展到 100M tokens 時保持低于 9% 的性能退化。并通過精準 KV 分塊升級，在算子層通過 KV outer gather Q 減少重復讀取，整體的計算訪存比是開源的 Flash-Sparse-Attention 和 FlashMoBA 的 4 倍以上。

而借助MSA，M3 能做到 1M 上下文下每 token 計算量只有上代模型 1/20、prefill 超過 9 倍加速、decoding 超過 15 倍加速。多數場景下，能力直接追平全注意力模式。

這類優化聽起來很底層，但用戶端會感受到兩件事：長任務跑得便宜，并且信息的把握非常精準。比如這里，我

把一整本《國富論》喂給 M3，做了一個亞當斯密邏輯下的模擬世界游戲。

這其中的難點在于，《國富論》通篇都是定性社科論述，分工、財稅、外貿、資本、薪資的經濟傳導邏輯零散分布全卷，只有百萬級上下文才能完整通讀全書，提煉環環相扣的量化演算規則，把斯密的文字理論轉化成稅率、生產率、財富聯動的數值公式。

在此基礎上，要完成模擬世界游戲的構建，還需要靠 Agent 不斷完成長時序推演，理解玩家減稅、修路等政令可能導致的結果，最后還能分短中長期按古典經濟學邏輯迭代面板數據，全程不能違背原著底層經濟規律。

最后結果上，可以看到 M3 精準還原了斯密理論在實際生活中環環相扣，稅制、關稅會直接左右生產率與財富增減，辦學政策會在中期、長期對稅務、對勞動生產率、對國家財富積累以及人口產生不同的影響。用戶自定義政策后，系統會自動逐年演算經濟變遷，完整還原國富論里政策隨時間釋放經濟紅利的設計。

而長上下文也只有做到這一步，才有意義。

04

Agent 時代，最稀缺的不是智能，

而是可負擔的智能

M3 的發布背后，各種單點優化固然重要，但它同時也是國產模型開始從追 benchmark 轉向做系統、讓 agent 真正能落到所有企業與個人日常所需中的一個重要嘗試。

復雜任務需要長上下文。長上下文會帶來成本、速度和信息命中率問題，所以需要 MSA 這種更高效的注意力機制。

Coding Agent 需要持續迭代。持續迭代會消耗大量 token，所以模型既要會寫代碼，也要能在多輪失敗里維持目標、讀懂反饋、繼續推進。

真實工作環境是多模態的。只會處理文本，Agent 就很難處理截圖、圖表、后臺、Excel、PR 頁面和終端輸出混在一起的任務。

高頻使用還要足夠便宜。否則用戶不會讓 Agent 充分試錯，企業也不敢把它接入真實流程。

每個點單獨看都不是第一次出現，但組合起來構成的，是 Agent 能力進入開發者和企業日常工作流的敲門磚。

*頭圖來源：MiniMax

本文為極客公園原創文章，轉載請聯系極客君微信 geekparkGO

極客一問

你如何看待 MiniMax M3 ？