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

作者丨梁丙鑒 吳海明

編輯丨馬曉寧

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

在這套計(jì)費(fèi)方案中，Token 消耗的最小計(jì)數(shù)單位被統(tǒng)一為 Credit。用戶為后者付費(fèi)，購買額度不一的套餐。在調(diào)用 MiMo 系列的不同模型時(shí)，每個(gè) Credit 點(diǎn)數(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（限時(shí)免費(fèi)，不消耗 Credit）

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

這是一套完全不同的計(jì)費(fèi)邏輯。

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

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

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

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

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

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

01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

答案約為一個(gè) Lite 套餐額度的 60％。

02

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Token 的價(jià)格，一直都寫在賬單里。

03

Token 計(jì)費(fèi)的生態(tài)邏輯

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

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

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

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

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

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

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