“MiMo V2 Pro，第一款「走字兒」的模型。”

作者丨梁丙鑒 吳海明

編輯丨馬曉寧

大模型要怎么收費，眾說紛紜。今天最常見的是訂閱制，都說模型是新時代的基建，但沒見誰家電表是包月的。作為模型層的后起之秀，4 月 3 日，小米發(fā)布了第一款“走字兒”的 Token Plan。

在這套計費方案中，Token 消耗的最小計數(shù)單位被統(tǒng)一為 Credit。用戶為后者付費，購買額度不一的套餐。在調(diào)用 MiMo 系列的不同模型時，每個 Credit 點數(shù)也對應(yīng)著不同的 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）

類似流量包的設(shè)計讓用戶對模型調(diào)用有了更大的自由度。在 Anthropic、OpenAI、阿里等主流模型廠商都通過“5 小時滾動窗口”限制用戶的使用時間時，小米此次推出的 Token Plan 取消了這一規(guī)定，支持用戶集中消耗 Token，編程 vibe 到爽。

這是一套完全不同的計費邏輯。

對用戶而言，傳統(tǒng)的訂閱制是用固定成本換取模型調(diào)用權(quán)益，邏輯簡單清晰，易于接受。但任務(wù)難度的波動讓平臺成本難以預(yù)測，模型廠商對用戶加以使用時間和每周請求次數(shù)上限的限制，都是為解決這一問題。

另一種常見方案是按模型調(diào)用次數(shù)計費，同樣可以避免用戶遇到帳單沖擊。但同樣是一次請求，復(fù)雜任務(wù)編程和修改一份簡歷的 Token 成本天差地別，這種方案難以在計費上體現(xiàn)出不同任務(wù)的復(fù)雜度，專業(yè)開發(fā)者的 Token 成本最終會被小白玩家一起分擔(dān)。

而小米從 Credit 到 Token 的換算，是對模型文本處理量直接計費，邏輯上確實更易于公平地衡量每個任務(wù)的實際成本。它把 AI 服務(wù)從一種固定消費，變成了隨任務(wù)難度調(diào)整的彈性消耗。

但問題在于，Token 是模型思考的最小單位，普通用戶卻難以預(yù)估一項任務(wù)的實際消耗。當(dāng)模型輸出從單輪的回答轉(zhuǎn)向直接交付任務(wù)結(jié)果，Token 消耗量更是會呈指數(shù)級增加，對用戶而言又是一重認(rèn)知負(fù)擔(dān)。

模型成為新一代基礎(chǔ)設(shè)施的未來已成定局。在 Claude Code、OpenClaw 越發(fā)廣泛地進(jìn)入生產(chǎn)環(huán)境時，什么是更合理的計費方案？

Xiaomi MiMo Token Plan 提供了一種全新的可能，對它的評價同樣應(yīng)該回到真實場景。為此我們向 Mimo V2 Pro 下達(dá)了真實的任務(wù)指令，看看模型的表現(xiàn)如何，以及小米為此開出了什么樣的價格。

01

核心實測：復(fù)雜架構(gòu)設(shè)計與多 Agent 協(xié)同科研

在 OpenClaw 框架之下，我們基于 MiMo V2 Pro 搭建了一套多角色協(xié)作系統(tǒng)，將科研流程拆解為五個相對穩(wěn)定的職責(zé)：方向規(guī)劃、算法實現(xiàn)、學(xué)術(shù)寫作、文獻(xiàn)整理與數(shù)據(jù)處理。對應(yīng)地，我們引入了五個不同角色的 Agent，分別承擔(dān)不同類型的任務(wù)：

• 唐僧：科研戰(zhàn)略與方向規(guī)劃（想清楚要去哪）

• 孫悟空：算法開發(fā)和工程落地（把事干出來）

• 豬八戒：學(xué)術(shù)寫作與表達(dá)（把話說清楚）

• 沙僧：文獻(xiàn)整理與知識管理（把信息理順）

• 白龍馬：數(shù)據(jù)處理與流程自動化（把基礎(chǔ)打好）

目前大模型落地應(yīng)用在工程技術(shù)上存在諸多挑戰(zhàn)。一個常見現(xiàn)象是小范圍的代碼生成已不在話下，但面對復(fù)雜架構(gòu)時，模型往往會出現(xiàn)一致性等問題。

為此我們將首個測試任務(wù)交給孫悟空 Agent，要求它基于公開文本分類數(shù)據(jù)集，完成一個“小樣本垂直領(lǐng)域文本分類基線系統(tǒng)”的開發(fā)，借此觀察 MiMo V2 Pro 在代碼實現(xiàn)、復(fù)現(xiàn)以及工程封裝上的表現(xiàn)。

經(jīng)過 3-4 小時的運(yùn)行，悟空構(gòu)建了完整的框架與細(xì)節(jié)。

核心功能方面，悟空按需求實現(xiàn)了 TF-IDF+LogReg 傳統(tǒng)機(jī)器學(xué)習(xí)路線和 BERT fine-tuning 深度學(xué)習(xí)路線，覆蓋了不同計算資源場景，而且從數(shù)據(jù)下載、讀取、清洗、劃分、訓(xùn)練到評估的全流程閉環(huán)，形成了可復(fù)現(xiàn)的 ML pipeline。

工程化交付同樣規(guī)范。通過 train.py 和 evaluate.py 提供統(tǒng)一入口，符合 Python 項目慣例。實驗結(jié)果表格結(jié)合模型優(yōu)劣分析的結(jié)構(gòu)化輸出，更展現(xiàn)了 MiMo V2 Pro 的能力不止于跑通代碼，更在于解釋結(jié)果。

另一項測試任務(wù)是多 Agent 的協(xié)同科研。

我們要求五個 Agent 協(xié)同完成一個小型科研項目，項目主題為“面向垂直領(lǐng)域 LLM 的輕量化蒸餾研究”，任務(wù)內(nèi)容覆蓋了從課題立項到可投稿初稿的完整閉環(huán)。這一任務(wù)旨在考察 OpenClaw 場景下 MiMo V2 Pro 的智能體協(xié)作能力。

值得注意的是，收到具體分工之后，MiMo V2 Pro 并未直接輸出結(jié)果，而是進(jìn)行即時的角色分離，讓每個 Agent 都根據(jù)自身角色明確了輸入依賴和輸出產(chǎn)物。其中唐僧的輸出會成為另外四個 Agent 的輸出，沙僧檢索到的文獻(xiàn)會成為孫悟空實驗設(shè)計的參考，后者又是白龍馬進(jìn)行 workflow 設(shè)計的依據(jù)，最后所有中間結(jié)果都服務(wù)于豬八戒的論文初稿。

這種有向無環(huán)圖式的依賴結(jié)構(gòu)能被模型自動識別，表明 MiMo V2 Pro 不僅對 Agent 的協(xié)作邊界有著清晰的認(rèn)知，而且真正理解了任務(wù)。

可以看到，在任務(wù)第一階段首先由唐僧定義了“醫(yī)療+金融，≤3B小模型蒸餾”的研究目標(biāo)，沙僧后續(xù)的文獻(xiàn)調(diào)研進(jìn)一步覆蓋了白盒/黑盒/垂直領(lǐng)域，識別出 DDK、MiniLLM、GKD 等 SOTA 方法。

同時作為協(xié)調(diào)中樞，唐僧后續(xù)還執(zhí)行了兩輪協(xié)作反饋和對中間成果的統(tǒng)一驗收，特別是在任務(wù)的第三階段及時識別出了孫悟空和白龍馬的交付延遲問題，啟動補(bǔ)救機(jī)制。

值得注意的是在第二輪協(xié)作反饋中，唐僧提出建議“縮短迭代周期至 3 天 checkpoint”。在經(jīng)歷了孫悟空和白龍馬的拖延之后，表現(xiàn)出了對任務(wù)的迭代復(fù)盤，這是 MiMo V2 Pro 執(zhí)行長程任務(wù)不可或缺的能力。

MiMo V2 Pro 的編程和工具調(diào)用能力使其非常擅長處理多步驟任務(wù)，同時 1M 級的超長上下文設(shè)置，讓該模型在處理具有長代碼需求的架構(gòu)級任務(wù)中更加勝任。這些表現(xiàn)，都意味著 MiMo V2 Pro 不是簡單的對話模型，而是為復(fù)雜任務(wù)和開發(fā)場景而生。

兩次交付結(jié)果均水平在線，那么成本如何？

答案約為一個 Lite 套餐額度的 60％。

02

從訂閱制到流量包，誰動了我的請求次數(shù)

Xiaomi MiMo Token Plan 提供了四檔套餐：

• Lite（中國 ￥39/月，海外 $6/月） —— 0.6億（60M）Credits，可執(zhí)行約 120 個中等~復(fù)雜任務(wù) 。適合剛接觸 AI 開發(fā)的探索者，以一杯咖啡的價格開始。

• Standard（中國 ￥99/月，海外 $16/月） —— 2億（200M）Credits，可執(zhí)行約 400 個中等~復(fù)雜任務(wù) 。為日常依賴 AI 提效的辦公與開發(fā)者用戶打造的主力方案。

• Pro（中國 ￥329/月，海外 $50/月） —— 7億（700M） Credits，可執(zhí)行約 1400 個中等~復(fù)雜任務(wù) 。面向?qū)?AI 深度嵌入工作流的專業(yè)用戶。

• Max（中國 ￥659/月，海外 $100/月） —— 16億（1600M）Credits，可執(zhí)行約 3200 個中等~復(fù)雜任務(wù) 。為全天候高強(qiáng)度使用的開發(fā)者準(zhǔn)備，近乎無限制的使用體驗。

這種多檔位套餐、按 Credit 點數(shù)折算 Token 消耗的模式，意味著在傳統(tǒng)“一個會員打包天下”的服務(wù)方案之后，又出現(xiàn)了真正按量計價的 AI 套餐。

但不知道小米有沒有預(yù)料到的是，這種計費模式在應(yīng)用中帶來了全新的困惑：我開的套餐到底能用多久？一次 Coding 任務(wù)會消耗多少 Token？多輪調(diào)試的過程，會不會花光我的所有額度，甚至代碼沒調(diào)試完額度就沒了？

用戶再次想起了被賬單沖擊支配的恐懼。

特別是在 Coding 場景中，不同于一般的對話，多輪調(diào)試、復(fù)制粘貼長代碼、不斷追問與修改的任務(wù)屬性，都會將 Token 消耗量拉到驚人的高度，而這是人腦難以預(yù)估的。至少在追求清晰的預(yù)算管理時，今天的大多數(shù)用戶對 Token 消耗尚不具備可靠的直覺，這難免讓小米的 Token Plan 變成一筆“糊涂賬”。

那么拋開心理因素，小米讓模型更便宜了嗎？

對比各家廠商面向?qū)I(yè)用戶的 Pro 版本套餐，單一價格維度上，小米在一眾廠商中不占優(yōu)勢。但這個對比的不公平之處在于，用戶為智能付費，各家套餐背后的模型性能卻各不相同。

MiMo V2 Pro 原生支持 1M 上下文窗口，上表的套餐中，只有阿里云百煉的 qwen3.5-plus 和 qwen3-coder-plus 達(dá)到了這一水平，其余模型上下文窗口多限制在 256K 以下。

小米對 MiMo 的定位是"面向 Agent 時代的旗艦基座模型"。顯而易見的是，Agent 在多輪規(guī)劃任務(wù)中保留歷史對話時，累計 Token 會迅速增長，每次調(diào)用工具的返回結(jié)果也會追加到上下文中，而長鏈推理本身又是另一個 Token 消耗大戶。

在這一場景下，Credit 和 Token 的換算，更像是支持用戶為上下文窗口本身付費，將 1M 的超長上下文從成本負(fù)擔(dān)變成價值錨點。作為 MiMo-V2-Pro 的核心能力，這正是其在生產(chǎn)環(huán)境中的差異化價值所在。便宜與否，取決于任務(wù)場景。

而值得注意的是，雖然小米是 Token “流量包”的首創(chuàng)者，但今天更常見的訂閱制也并非無限 Token。

除了單次任務(wù)中，模型上下文窗口的硬性技術(shù)限制之外，用戶還面臨著隱性的經(jīng)濟(jì)約束機(jī)制。此前就曾有用戶反映稱，火山方舟 Coding Plan 標(biāo)稱配額為每 5 小時 6,000 次請求，但實際會根據(jù)單次請求的 Token 消耗量折算為多次請求，且不同模型的隱藏倍率不同。

火山的回應(yīng)則是，“通常一次用戶提問會觸發(fā)多次模型調(diào)用，且每次模型調(diào)用均會計入一次額度消耗，因此實際消耗的請求次數(shù)一般會多于用戶提問次數(shù)。”

阿里云百煉的 Coding Plan 也存在類似的限制，當(dāng)輸入超出允許長度時模型會返回報錯信息，官方推薦的解決方案是精簡輸入或切換上下文窗口更長的模型。

算力成本壓力讓 Coding Plan 沒辦法真正實現(xiàn)無論 Token 消耗的計費模式，因而在計算請求次數(shù)時，會對超長上下文的任務(wù)適用懲罰倍數(shù)。如果說面對小米的 Token Plan 時，大多數(shù)用戶還沒有養(yǎng)成估算任務(wù) Token 消耗量的直覺，那么 Coding Plan 也只是用模型調(diào)用次數(shù)“預(yù)估值”的表述模糊了爭議地帶。

Token 的價格，一直都寫在賬單里。

03

Token 計費的生態(tài)邏輯

從 2026 年初的漲價潮，到小米率先直接根據(jù)消耗量計費，Token 的定價邏輯正在悄然轉(zhuǎn)變。

此前更常見的是訂閱制，一次性收費將按量計費的連續(xù)博弈過程變成單次博弈，用戶覺得自己不是時時刻刻在花錢，預(yù)算也不會超額，但算力成本讓這種方案的現(xiàn)金流未必能夠打正。

神經(jīng)計算引擎創(chuàng)業(yè)者梅一凡表示，在這一視角下，OpenAI、Anthropic 采用的混合計費方案成為了一種非常明智的選擇，即訂閱制基礎(chǔ)上，超量部分按 Token 計費，前者降低用戶心智成本，后者保障單位經(jīng)濟(jì)回正。

小米的 Token Plan 本身更像一個帶有封頂機(jī)制的 API Plan，但主流模型廠商同樣可以照搬，核心問題仍然是模型強(qiáng)度和成本。

但小米策略的不同之處在于，小米生態(tài)和用戶數(shù)據(jù)構(gòu)成了天然的護(hù)城河，這是 MiMo 模型的巨大應(yīng)用空間。因此在戰(zhàn)略上，小米 Token Plan 背后更統(tǒng)一的計費方式，或許是一個內(nèi)部“人車家全生態(tài)”準(zhǔn)備進(jìn)一步發(fā)力的信號。

也許在小米設(shè)想的未來中，所有接入自家生態(tài)的 AI 功能，都會遇到統(tǒng)一的計費方案。那么 Xiaomi MiMo Token Plan 的真正意義，就是邁向這個未來的第一步。

模型層之爭進(jìn)入下半場，更多廠商動態(tài)，歡迎添加作者微信 LIFACAI_888 進(jìn)一步探討。