<mark id="oztn4"></mark>
0
在這套計費方案中，Token 消耗的最小計數單位被統一為 Credit。用戶為后者付費，購買額度不一的套餐。在調用 MiMo 系列的不同模型時，每個 Credit 點數也對應著不同的 Token 額度，換算比例如下：
MiMo-V2-Omni 256k 上下文：1x（消耗 1 Token = 1 Credit）
MiMo-V2-Pro 256k 上下文： 2x（消耗 1 Token = 2 Credits）
MiMo-V2-Pro 256k~1M 上下文： 4x（消耗 1 Token = 4 Credits）
MiMo-V2-TTS：0x（限時免費，不消耗 Credit）
類似流量包的設計讓用戶對模型調用有了更大的自由度。在 Anthropic、OpenAI、阿里等主流模型廠商都通過“5 小時滾動窗口”限制用戶的使用時間時，小米此次推出的 Token Plan 取消了這一規定，支持用戶集中消耗 Token，編程 vibe 到爽。
這是一套完全不同的計費邏輯。
對用戶而言，傳統的訂閱制是用固定成本換取模型調用權益，邏輯簡單清晰，易于接受。但任務難度的波動讓平臺成本難以預測，模型廠商對用戶加以使用時間和每周請求次數上限的限制，都是為解決這一問題。
另一種常見方案是按模型調用次數計費，同樣可以避免用戶遇到帳單沖擊。但同樣是一次請求，復雜任務編程和修改一份簡歷的 Token 成本天差地別，這種方案難以在計費上體現出不同任務的復雜度，專業開發者的 Token 成本最終會被小白玩家一起分擔。
而小米從 Credit 到 Token 的換算，是對模型文本處理量直接計費，邏輯上確實更易于公平地衡量每個任務的實際成本。它把 AI 服務從一種固定消費，變成了隨任務難度調整的彈性消耗。
但問題在于，Token 是模型思考的最小單位，普通用戶卻難以預估一項任務的實際消耗。當模型輸出從單輪的回答轉向直接交付任務結果，Token 消耗量更是會呈指數級增加，對用戶而言又是一重認知負擔。
模型成為新一代基礎設施的未來已成定局。在 Claude Code、OpenClaw 越發廣泛地進入生產環境時，什么是更合理的計費方案？
Xiaomi MiMo Token Plan 提供了一種全新的可能，對它的評價同樣應該回到真實場景。為此我們向 Mimo V2 Pro 下達了真實的任務指令，看看模型的表現如何，以及小米為此開出了什么樣的價格。
在 OpenClaw 框架之下，我們基于 MiMo V2 Pro 搭建了一套多角色協作系統，將科研流程拆解為五個相對穩定的職責：方向規劃、算法實現、學術寫作、文獻整理與數據處理。對應地，我們引入了五個不同角色的 Agent，分別承擔不同類型的任務：
唐僧：科研戰略與方向規劃（想清楚要去哪）
孫悟空：算法開發和工程落地（把事干出來）
豬八戒：學術寫作與表達（把話說清楚）
沙僧：文獻整理與知識管理（把信息理順）
白龍馬：數據處理與流程自動化（把基礎打好）
目前大模型落地應用在工程技術上存在諸多挑戰。一個常見現象是小范圍的代碼生成已不在話下，但面對復雜架構時，模型往往會出現一致性等問題。
為此我們將首個測試任務交給孫悟空 Agent，要求它基于公開文本分類數據集，完成一個“小樣本垂直領域文本分類基線系統”的開發，借此觀察 MiMo V2 Pro 在代碼實現、復現以及工程封裝上的表現。
經過 3-4 小時的運行，悟空構建了完整的框架與細節。
核心功能方面，悟空按需求實現了 TF-IDF+LogReg 傳統機器學習路線和 BERT fine-tuning 深度學習路線，覆蓋了不同計算資源場景，而且從數據下載、讀取、清洗、劃分、訓練到評估的全流程閉環，形成了可復現的 ML pipeline。
工程化交付同樣規范。通過 train.py 和 evaluate.py 提供統一入口，符合 Python 項目慣例。實驗結果表格結合模型優劣分析的結構化輸出，更展現了 MiMo V2 Pro 的能力不止于跑通代碼，更在于解釋結果。
另一項測試任務是多 Agent 的協同科研。
我們要求五個 Agent 協同完成一個小型科研項目，項目主題為“面向垂直領域 LLM 的輕量化蒸餾研究”，任務內容覆蓋了從課題立項到可投稿初稿的完整閉環。這一任務旨在考察 OpenClaw 場景下 MiMo V2 Pro 的智能體協作能力。
值得注意的是，收到具體分工之后，MiMo V2 Pro 并未直接輸出結果，而是進行即時的角色分離，讓每個 Agent 都根據自身角色明確了輸入依賴和輸出產物。其中唐僧的輸出會成為另外四個 Agent 的輸出，沙僧檢索到的文獻會成為孫悟空實驗設計的參考，后者又是白龍馬進行 workflow 設計的依據，最后所有中間結果都服務于豬八戒的論文初稿。
這種有向無環圖式的依賴結構能被模型自動識別，表明 MiMo V2 Pro 不僅對 Agent 的協作邊界有著清晰的認知，而且真正理解了任務。
可以看到，在任務第一階段首先由唐僧定義了“醫療+金融，≤3B小模型蒸餾”的研究目標，沙僧后續的文獻調研進一步覆蓋了白盒/黑盒/垂直領域，識別出 DDK、MiniLLM、GKD 等 SOTA 方法。
同時作為協調中樞，唐僧后續還執行了兩輪協作反饋和對中間成果的統一驗收，特別是在任務的第三階段及時識別出了孫悟空和白龍馬的交付延遲問題，啟動補救機制。
值得注意的是在第二輪協作反饋中，唐僧提出建議“縮短迭代周期至 3 天 checkpoint”。在經歷了孫悟空和白龍馬的拖延之后，表現出了對任務的迭代復盤，這是 MiMo V2 Pro 執行長程任務不可或缺的能力。
MiMo V2 Pro 的編程和工具調用能力使其非常擅長處理多步驟任務，同時 1M 級的超長上下文設置，讓該模型在處理具有長代碼需求的架構級任務中更加勝任。這些表現，都意味著 MiMo V2 Pro 不是簡單的對話模型，而是為復雜任務和開發場景而生。
兩次交付結果均水平在線，那么成本如何？
答案約為一個 Lite 套餐額度的 60％。
Xiaomi MiMo Token Plan 提供了四檔套餐：
Lite（中國 ￥39/月，海外 $6/月） —— 0.6億（60M）Credits，可執行約 120 個中等~復雜任務 。適合剛接觸 AI 開發的探索者，以一杯咖啡的價格開始。
Standard（中國 ￥99/月，海外 $16/月） —— 2億（200M）Credits，可執行約 400 個中等~復雜任務 。為日常依賴 AI 提效的辦公與開發者用戶打造的主力方案。
Pro（中國 ￥329/月，海外 $50/月） —— 7億（700M） Credits，可執行約 1400 個中等~復雜任務 。面向將 AI 深度嵌入工作流的專業用戶。
Max（中國 ￥659/月，海外 $100/月） —— 16億（1600M）Credits，可執行約 3200 個中等~復雜任務 。為全天候高強度使用的開發者準備，近乎無限制的使用體驗。
這種多檔位套餐、按 Credit 點數折算 Token 消耗的模式，意味著在傳統“一個會員打包天下”的服務方案之后，又出現了真正按量計價的 AI 套餐。
但不知道小米有沒有預料到的是，這種計費模式在應用中帶來了全新的困惑：我開的套餐到底能用多久？一次 Coding 任務會消耗多少 Token？多輪調試的過程，會不會花光我的所有額度，甚至代碼沒調試完額度就沒了？
用戶再次想起了被賬單沖擊支配的恐懼。
特別是在 Coding 場景中，不同于一般的對話，多輪調試、復制粘貼長代碼、不斷追問與修改的任務屬性，都會將 Token 消耗量拉到驚人的高度，而這是人腦難以預估的。至少在追求清晰的預算管理時，今天的大多數用戶對 Token 消耗尚不具備可靠的直覺，這難免讓小米的 Token Plan 變成一筆“糊涂賬”。
那么拋開心理因素，小米讓模型更便宜了嗎？
對比各家廠商面向專業用戶的 Pro 版本套餐，單一價格維度上，小米在一眾廠商中不占優勢。但這個對比的不公平之處在于，用戶為智能付費，各家套餐背后的模型性能卻各不相同。
MiMo V2 Pro 原生支持 1M 上下文窗口，上表的套餐中，只有阿里云百煉的 qwen3.5-plus 和 qwen3-coder-plus 達到了這一水平，其余模型上下文窗口多限制在 256K 以下。
小米對 MiMo 的定位是"面向 Agent 時代的旗艦基座模型"。顯而易見的是，Agent 在多輪規劃任務中保留歷史對話時，累計 Token 會迅速增長，每次調用工具的返回結果也會追加到上下文中，而長鏈推理本身又是另一個 Token 消耗大戶。
在這一場景下，Credit 和 Token 的換算，更像是支持用戶為上下文窗口本身付費，將 1M 的超長上下文從成本負擔變成價值錨點。作為 MiMo-V2-Pro 的核心能力，這正是其在生產環境中的差異化價值所在。便宜與否，取決于任務場景。
而值得注意的是，雖然小米是 Token “流量包”的首創者，但今天更常見的訂閱制也并非無限 Token。
除了單次任務中，模型上下文窗口的硬性技術限制之外，用戶還面臨著隱性的經濟約束機制。此前就曾有用戶反映稱，火山方舟 Coding Plan 標稱配額為每 5 小時 6,000 次請求，但實際會根據單次請求的 Token 消耗量折算為多次請求，且不同模型的隱藏倍率不同。
火山的回應則是，“通常一次用戶提問會觸發多次模型調用，且每次模型調用均會計入一次額度消耗，因此實際消耗的請求次數一般會多于用戶提問次數。”
阿里云百煉的 Coding Plan 也存在類似的限制，當輸入超出允許長度時模型會返回報錯信息，官方推薦的解決方案是精簡輸入或切換上下文窗口更長的模型。
算力成本壓力讓 Coding Plan 沒辦法真正實現無論 Token 消耗的計費模式，因而在計算請求次數時，會對超長上下文的任務適用懲罰倍數。如果說面對小米的 Token Plan 時，大多數用戶還沒有養成估算任務 Token 消耗量的直覺，那么 Coding Plan 也只是用模型調用次數“預估值”的表述模糊了爭議地帶。
Token 的價格，一直都寫在賬單里。
從 2026 年初的漲價潮，到小米率先直接根據消耗量計費，Token 的定價邏輯正在悄然轉變。
此前更常見的是訂閱制，一次性收費將按量計費的連續博弈過程變成單次博弈，用戶覺得自己不是時時刻刻在花錢，預算也不會超額，但算力成本讓這種方案的現金流未必能夠打正。
神經計算引擎創業者梅一凡表示，在這一視角下，OpenAI、Anthropic 采用的混合計費方案成為了一種非常明智的選擇，即訂閱制基礎上，超量部分按 Token 計費，前者降低用戶心智成本，后者保障單位經濟回正。
小米的 Token Plan 本身更像一個帶有封頂機制的 API Plan，但主流模型廠商同樣可以照搬，核心問題仍然是模型強度和成本。
但小米策略的不同之處在于，小米生態和用戶數據構成了天然的護城河，這是 MiMo 模型的巨大應用空間。因此在戰略上，小米 Token Plan 背后更統一的計費方式，或許是一個內部“人車家全生態”準備進一步發力的信號。
也許在小米設想的未來中，所有接入自家生態的 AI 功能，都會遇到統一的計費方案。那么 Xiaomi MiMo Token Plan 的真正意義，就是邁向這個未來的第一步。
雷峰網(公眾號：雷峰網)文章
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
