小米MiMo降價99%并非營銷！羅福莉發(fā)X打臉唱衰者

但無論這件事的具體事實如何，它確實再次把一個問題推到了臺前：為什么總是豆包因為類似事件上熱搜？

羅福莉發(fā)了一條X，要給小米MiMo的降價風波劃上一個句號。

5 月 26 日，小米 MiMo 官方賬號在 X 上甩出一條公告：MiMo-V2.5 系列 API 永久降價，最高降幅99%。所有 context 長度統(tǒng)一定價，Token 套餐升級 5-8 倍。

這條公告在國內(nèi) AI 圈刷了一整周。業(yè)界第一反應分成幾派。最大那派說這是"又一輪價格戰(zhàn)"——這兩年從智譜、DeepSeek、字節(jié)豆包到阿里通義，國產(chǎn)大模型輪著降價，誰不在卷。

另一派往悲觀處看：小米剛公告今年利潤腰斬，這時候還往 AI 燒 600 億、API 直接砍九成——典型的"虧本搶市場"。還有人覺得這是 DeepSeek 效應繼續(xù)——后者把整個行業(yè)的定價基準拽到了地板上，誰不跟誰出局。

所以作為MiMo的負責人，羅福莉在昨晚直接拿出了一份5000 字的技術(shù)博客，把降價的工程賬目公開給了所有人。

“看，這是真實的工程能力，不是營銷手段”。

要聽懂羅福莉在說什么，先得明白這個 99% 到底降了什么。

它不是全模型降價。99% 的折扣專門針對一檔叫Input(Cache Hit)的定價——也就是"用戶在長對話里重復讀歷史上下文"那部分。普通的新輸入（No Cache Hit）降幅小很多，模型輸出（Output）降幅最小。

如果你把模型當成一家咖啡店，這件事就好理解了。

你點一杯半糖拿鐵，咖啡店有兩種做法：每次從頭磨豆子量糖漿倒奶，原料人工都付一次；但是模型知道這周你每天都要喝同樣的半糖拿鐵，干脆做一大壺存進冰柜，下次按一杯舀一份。MiMo 這次做的是后者——把用戶重復讀的部分從"現(xiàn)算"改成了"現(xiàn)取"，所以這部分的真實成本接近 0，自然能給 99% 折扣。

要做到"現(xiàn)取"，技術(shù)博客里講了六個工程，每一個都不能缺。下面一個一個拆開看。

工程一：把模型"記憶"壓到 1/7

模型在和你對話時，每個 token 都要算一份"中間狀態(tài)"，存起來供下一步用。這個東西叫KVCache——可以理解成模型的"短期記憶筆記本"。每說一句話，模型在筆記本上記下這句話的摘要，下次直接翻筆記，不用從頭聽一遍你說過的所有內(nèi)容。

傳統(tǒng)模型每一層都做"Full Attention"——也就是每個 token 都要看完整段對話所有 token，筆記本越翻越厚。MiMo-V2.5-Pro 改了架構(gòu)：70 層里 60 層只看最近 128 個 token（SWA，Sliding Window Attention），只有 10 層"檔案管理員"看全部。

結(jié)果是 KVCache 體積直接壓到 Full Attention 的1/7，計算量同樣是 1/7。

這是降本的第一塊地基。打個比方，原本公司每個員工都被要求記住所有的會議記錄，結(jié)果每個人的腦子都不夠用、效率也低。新規(guī)定把 60 個員工的腦負擔降到 1/7，只留 10 個檔案管理員管全部歷史——公司整體記憶能力沒下降，但效率提升 7 倍。

工程二：讓 SWA 省下的空間真的能用

架構(gòu)上把筆記本壓到 1/7 是第一步，但要把"理論上的 1/7"真的兌現(xiàn)成"實際的 1/7"，還有一道坎。

傳統(tǒng)的 KVCache 系統(tǒng)是按"最大可能用量"給所有層統(tǒng)一分配顯存的。意思是：哪怕 60 層 SWA 只需要小本子，系統(tǒng)也按"檔案管理員的大本子"給所有層都分配——SWA 省下來的空間被白白預留了，等于沒省。

羅福莉團隊的做法是把 KVCache 拆成兩個獨立的池子。Full Attention 那 10 層走"大池子"，按全長分配；SWA 那 60 層走"小池子"，只按 128 個 token 的窗口分配。

打個比方，原本公司給每個員工都發(fā)了"能裝 100 年文件的檔案柜"——但 60 個員工其實只需要"裝一周文件的小柜子"，那些大柜子里 99% 的空間是空的。新做法是按實際需要分柜子。結(jié)果整個辦公室能多裝 5 倍以上的同事進來工作——同樣一臺 GPU 能服務(wù)的并發(fā)用戶數(shù)翻了 5 倍。

這一步看上去簡單，但沒有它，前面 SWA 架構(gòu)的優(yōu)勢等于白設(shè)計。

工程三：讓"老用戶重復讀"真能命中緩存

筆記本壓到 1/7 + 空間真用得起，下一步要解決一個老問題：前綴緩存的命中率。

很多用戶的對話有相同開頭——同一段 system prompt、同一段代碼庫、同一份長文檔。系統(tǒng)會把這些算過的結(jié)果存起來，下一次匹配上就直接復用。這個機制叫前綴緩存。

但 SWA 模式下出現(xiàn)一個坑：兩條請求 token 一樣，不等于 KV 還在。可能前綴算過，但 SWA 窗口外的部分早就被淘汰了。如果系統(tǒng)還按"token 一樣就命中"的舊規(guī)則給你復用，會讀到無效或被覆蓋的數(shù)據(jù)，模型效果會直接崩。

羅福莉團隊升級了規(guī)則到"窗口安全長度"——只承諾"你能完整借到的那部分"。

打個比方，圖書館有 100 萬本書，你想借全套共計三本的《三體》。原來的架構(gòu)會告訴你"這本書在"，你跑過去發(fā)現(xiàn)書架上只剩封面和第一部，后面兩部都被借走了。這種"偽命中"讓你白跑一趟還要重借。新系統(tǒng)的規(guī)則改成只承諾你能完整借到的那部分——先給你第一本，然后把后面兩本再給你調(diào)過來。

聽起來好像更嚴格、命中率會下降。但實際相反：因為 SWA 讓 KVCache 體積壓到 1/7，同樣存儲空間能裝的內(nèi)容多了好幾倍，真實命中率反而大幅度提升。

羅福莉博客里給了線上實測數(shù)字：主流 harness 框架下服務(wù)端 cache 命中率平均 93%，高頻長周期用戶可達 95% 以上。

翻譯一下這個數(shù)字的含義：95% 的"重復讀"請求根本不用GPU算，直接從緩存里取。這就是 99% 折扣的物理基礎(chǔ)。

工程四：把“緩存”裝進GPU自帶的SSD

命中率上去了，下一個問題是：這些緩存裝在哪里。

顯存（GPU 上的 HBM 內(nèi)存）很貴也很有限——一臺 H100 八卡機才 640GB 顯存，但 MiMo 要存的 KVCache 可能是幾十 TB 量級。所以必須分層：最近用的放顯存（L1），稍微舊的放 CPU 內(nèi)存（L2），冷數(shù)據(jù)存到分布式緩存（L3）。

跟你管錢一個道理。錢包里的現(xiàn)金是顯存——隨用隨取但放不了多少。銀行卡余額是 CPU 內(nèi)存——取一次要 30 秒但能放很多。定期存款是 L3 分布式緩存——取一次要 2 分鐘但便宜很多。

行業(yè)的常規(guī)做法是為 L3 單獨建一套存儲集群，專用機型、專用機房，月月付租金。

小米存儲團隊的做法不一樣。他們自研了一套叫GCache的分布式緩存，直接部署在GPU機器自帶的SSD上——跟訓練任務(wù)、推理任務(wù)混布在同一臺機器里。

普通話翻譯：別人為了存大量數(shù)據(jù)，專門租了一個倉庫；小米發(fā)現(xiàn) GPU 機器的車庫其實空著，直接把數(shù)據(jù)存進去了。月租金省了。

技術(shù)博客的原話是："額外的存儲成本為 0。"

這件事的殺傷力比看上去大。常規(guī)的"AI 公司算力賬"里，存儲成本是一個固定支出項——你的模型越大、用戶越多，存儲賬單越長。GCache 這套做法把這一項直接打掉。結(jié)合 SWA 的小體積 + 命中率 93-95%，KVCache 在 L3 的存活時間（TTL）從幾分鐘延長到幾小時甚至幾天——TTL 越長，歷史 context 的可命中窗口越寬，緩存命中率越高，99% 那個折扣就越站得住。

工程五：讓命中緩存的請求走最短的路

緩存能裝、能查、還便宜，最后一步是：怎么讓正確的請求被路由到正確的機器上。

小米開發(fā)了一套自己的調(diào)度系統(tǒng)叫LLM-Router，干了三件事：

一是親和調(diào)度。前綴相同的請求路由到同一臺機器，讓緩存復用最大化。

二是長度分桶。把短請求（0-64K）、中請求（64K-256K）、長請求（256K-1M）分到不同的處理通道，避免短請求被長請求拖累。

三是TTFT優(yōu)化。在排隊等推理的隊列里，優(yōu)先調(diào)度真實計算量小的請求（也就是大量命中緩存的請求）——避免它們被"全新輸入"那種重計算請求阻塞。

比如，在常規(guī)的機場調(diào)度中，所有飛同一個目的地的乘客集中到同一個候機廳，共享行李提取流程——這是親和調(diào)度。帶登機箱的和帶 3 大箱托運的分兩條安檢通道走，快的不被慢的拖——這是長度分桶。登機時優(yōu)先放只帶登機箱的人，他們登機快，讓飛機能早起飛——這是 TTFT 優(yōu)化。

這套調(diào)度策略實測把 L2 緩存命中率提升了 25%，單機輸入吞吐提升 30%，長請求 P90 延遲降低 30%。

翻譯過來就是：同一臺 GPU 能服務(wù)更多用戶。降價的另一半邏輯就在這里——單位算力的有效產(chǎn)出更高，單位用戶成本更低。

工程六：讓模型"打字"也變快

前面五件事都在優(yōu)化"讀"那一側(cè)——讓用戶重復讀歷史 context 的成本壓到接近 0。第六件事是優(yōu)化"寫"那一側(cè)——也就是模型生成下一個 token 的過程。

傳統(tǒng)模型一次只能生成 1 個 token。MiMo 原生支持3 層MTP（Multi-Token Prediction）——一次預測接下來的 3 個 token，如果中間預測對了，直接跳過中間的計算。

打個比方，傳統(tǒng)打字是一個字一個字打——你想打"今天天氣"，要按 4 次鍵。MTP 像有個自動補全在猜你下一個 1-2 個字是什么——如果它猜對了，你就不用再按那兩次。

MiMo 的 MTP 在 agentic 場景下實測：decode 前 128 個 token 加速2.3 倍，128-256 個 token 加速1.5 倍。

這件事的意義在于，99% 折扣專門指向 Input (Cache Hit)，但模型實際服務(wù)用戶時，input 和 output 是同一次請求里發(fā)生的——如果 output 沒省，整體請求成本就只省了一半。MTP 讓 output 那一半也降下來，整套降價的盈利模型才閉環(huán)。

把六件事串成一條降本鏈：

SWA 架構(gòu) → KVCache 1/7 → 雙池真正釋放容量 → 同一臺 GPU 能裝 5+ 倍并發(fā) → 前綴緩存命中率 93-95% → 95% 請求幾乎不用算 → GCache 讓存儲成本歸零 → 調(diào)度把命中請求優(yōu)先調(diào)走 → MTP 讓生成也省 → 單位請求 GPU 時間下降一個數(shù)量級 → 單位成本下降 95%+ → 定價降 99%，毛利率仍為正。

任何一個環(huán)節(jié)缺失，這條鏈都斷在某一節(jié)。99% 降價不是營銷數(shù)字，是六個工程支柱疊加 + 真實線上驗證后的累積效應。

回頭看業(yè)界一開始的幾種解讀，每種都有部分道理。這兩年中國大模型公司之間的價格戰(zhàn)是真的；小米利潤腰斬還要砸 AI 是真的；DeepSeek 把行業(yè)定價拽到地板上也是真的。

但羅福莉這次公開技術(shù)博客并且詳細的技術(shù)細節(jié)公開拆解，無疑是希望回擊對于價格戰(zhàn)的說法，讓“技術(shù)的問題歸技術(shù)、營銷的問題歸營銷。”

她在博客中寫道，MiMo-V2.5 系列模型的推理效率并非來自某一環(huán)節(jié)的單點突破，而是多維度協(xié)同優(yōu)化的結(jié)果。Hybrid SWA 讓 prefill 與 decode 同時受益，但未經(jīng)充分優(yōu)化的 KVCache 實現(xiàn)反而會在各環(huán)節(jié)抬高成本。圍繞這一目標，MiMo團隊系統(tǒng)性重構(gòu)了 KVCache 管理、分級緩存、前綴緩存樹，攻克 SWA KVCache 核心問題，優(yōu)化了調(diào)度策略及 Prefill / Decode 鏈路，并經(jīng)線上真實場景檢驗，最終將其理論效率優(yōu)勢真正兌現(xiàn)到生產(chǎn)環(huán)境。至此，Hybrid SWA 才發(fā)揮出在長文推理上兼具強度與效率的架構(gòu)優(yōu)勢。再組合 MoE 配置和多模態(tài)推理的各種優(yōu)化，極大程度提高了線上推理服務(wù)的性能。

這是一套AI工程的系統(tǒng)性打法，也是值得行業(yè)共同參考借鑒的降本手段。

價格戰(zhàn)不需要寫博客，工程兌現(xiàn)才需要。