MiMo 在 1T 模型跑到 1000 TPS

Xiaomi MiMo 和 TileRT 宣稱，1T 參數模型已能在一般 8-GPU 伺服器上跑到每秒 1000+ tokens。

Xiaomi 的 MiMo 團隊這次很敢講。它說 MiMo-V2.5-Pro-UltraSpeed 首次把 1T 參數模型推到 1000+ tokens/s。重點是，它不是靠特規晶片堆出來的。官方說法是，這結果來自模型和系統一起設計，而且只用單一標準 8-GPU commodity node。

這種數字很容易讓人皺眉。因為大家早就習慣一件事：模型越大，推論越慢。MiMo 這次直接把話題拉到另一邊。它說 UltraSpeed 模式比 MiMo-V2.5-Pro 快三倍以上，但 API 價格也提高到 3 倍。講白了，就是拿錢換速度。

這個速度數字到底有多兇

AI 速度數字很常被亂用。很多產品會拿小模型的 token/s 來吹，但那種數字對實際產品沒那麼有感。到了 1T 參數，情況就完全不同。200 tokens/s 和 1000 tokens/s 的差距，會直接改變你能不能做即時互動。

MiMo 的說法很直接。只要模型回得夠快，它就不再像 batch 工具。它可以塞進 coding assistant、搜尋、風控、交易訊號，甚至一些需要即時回應的內部系統。這不是純展示數字而已。這是在說，LLM 的延遲開始影響產品形狀。

我覺得更有意思的地方，是它把速度當成品質的一部分。當生成夠快，系統就能在同樣的牆鐘時間裡試更多推理路徑，再把不對的路徑丟掉。這比單看 benchmark 分數更實際，因為真實工作流在乎的是等待時間。

• MiMo 說 UltraSpeed 比標準 API 快約 10 倍。
• 促銷 API 價格是原本的 3 倍。
• 通過審核的使用者可在試用期免費聊天。
• 每個帳號每天最多排隊 10 次。

MiMo 和 TileRT 怎麼做到的

這次最值得看的，不是單一技巧，而是整套堆疊。Xiaomi 和 TileRT 沒把重點放在特規硬體。它們反而把焦點放在 model-system co-design。這點很像在說：真正的瓶頸，不只是 GPU 數量。

在模型端，MiMo 用了 FP4 量化，對象是 MoE experts。它也加了 DFlash，一種 speculative decoding 方法。這套方法走的是 block-level masked parallel prediction。講白了，就是讓模型一次猜一整塊 token，而不是一個一個慢慢猜。

在系統端，TileRT 負責編譯和 kernels。它不是通用 runtime，而是針對這條 pipeline 調過的版本。MiMo 甚至直接拿 Cerebras 和 Groq 這類特規路線來對照。意思很明白：它想證明 commodity GPU 也能拚出很高吞吐。

“We chose a different path: achieving even more impressive inference speed on commodity GPUs through model-system codesign alone.”

這句話很直白。它不是在說晶片救一切。它是在說，模型的 decoding 行為，和底層執行系統要對得上。對不上的話，算力再多也會浪費。

FP4 量化的重要性也很現實。超大模型最貴的地方，常常不是算，而是搬資料。參數越大，記憶體頻寬壓力越重。把 MoE experts 壓到較低精度，通常能減少 traffic，讓 decode loop 跑得更快。MiMo 的策略是只量化那部分，避免整體品質掉太多。

DFlash 則是在解 speculative decoding 的老問題。傳統做法是小 draft model 先猜，大模型再驗證。問題是，draft 猜太慢，整套流程就卡住。MiMo 說 DFlash 改成整塊遮罩式並行預測，能提高 accepted token 的長度，也能少掉一些浪費。

• 模型端用了 FP4 量化。
• MoE experts 是主要量化對象。
• DFlash 採 block-level masked parallel prediction。
• TileRT 負責編譯與 kernel 優化。

數字看起來漂亮，但代價也很清楚

這篇最像工程報告的地方，是它給了不少可對照的數字。像 speculative decoding，重點不是 draft 速度，而是接受率。接受率不夠高，系統就會一直做白工。那樣只是在浪費 GPU 時間。

MiMo 提到，它把 block size 調成 8 tokens。這樣做的目的，是在驗證成本和並行度之間找平衡。block 太大，猜錯就浪費更多。block 太小，吞吐又拉不上來。這種取捨，才是 inference 系統真正的難題。

它也公開了不同工作類型的接受長度。這很重要，因為它透露出 UltraSpeed 不同場景的表現差異。結構化任務通常比較容易吃到這套優化，像 coding 就比聊天更穩。

• Coding acceptance length：6.30
• Math and reasoning acceptance length：5.56
• Agent acceptance length：4.29
• 部分 coding 樣本可到 7.14/8 的接受 token

這些數字告訴我們一件事。UltraSpeed 最吃香的場景，很可能是 code。這其實不意外。因為 coding agent 本來就很怕延遲。你每次等模型多半秒，開發節奏就會被打斷。

MiMo 還提到 Sliding Window Attention。這種設計可以避免 draft 階段的計算量跟 context 長度一起膨脹。它也說訓練時把 mask-signal sampling 壓到 GPU-local shards，減少跨裝置通訊。這些細節很硬，但也很合理。大模型推論能不能快，常常就卡在通訊。

如果這組數字在外部流量下還站得住腳，那就代表一件事：超大模型不一定非得綁定特規硬體。至少在某些工作負載上，commodity GPU 還有不少空間可以挖。

對開發者來說，這代表什麼

對開發者來說，重點不是 1000 tokens/s 很帥。重點是，這個速度會不會改變你怎麼做產品。當模型反應接近即時，它就能放進 live agent loop。也能放進互動式 coding 工具。甚至可以放進一些以前覺得太慢的決策流程。

但這裡有個很現實的限制。UltraSpeed API 不是全面開放。它是申請制，而且有時間限制。MiMo 說試用期從 2026/06/09 到 2026/06/23。這代表它現在比較像企業測試窗，不像正式大眾服務。

價格訊號也很清楚。MiMo 不是在賣便宜，而是在測市場願不願意為更快的回應付更多錢。這對很多團隊很重要。因為在大型語言模型裡，吞吐已經不是純 infra 指標，而是產品規格的一部分。

• 適合 live agent loop。
• 適合互動式 coding 工具。
• 適合風控與查詢型系統。
• 不適合還在意成本的批次工作。

這次發布放在產業脈絡裡看

AI 產業這兩年很愛講模型大小。可是實務上，很多團隊真正痛的是延遲。你可以有很會答題的模型，但如果每次回應都慢半拍，產品體驗還是很爛。MiMo 這次就是把焦點拉回 inference。

這也反映出一個趨勢。大家開始不只比 benchmark。大家開始比系統設計。量化、speculative decoding、kernel、通訊路徑，這些以前偏 infra 的東西，現在都會直接寫進產品敘事裡。說真的，這才比較接近真實世界。

另一個脈絡是，特規硬體和 commodity GPU 的路線還在拉扯。Cerebras、Groq 這類廠商主打專用架構，優勢是簡化某些推論流程。MiMo 則是在說，通用硬體加上夠狠的系統設計，也能衝出很高的 token/s。兩派都不是空話，但打法不同。

如果你是做產品的人，這裡有個很實際的判斷方式。你的瓶頸如果是模型回覆慢，那就該先看系統。你的瓶頸如果是成本太高，那就該看量化和 decoding。你的瓶頸如果是流量穩定性，那就要看整條推論堆疊能不能扛住真實負載。

接下來該看什麼

我會先看兩件事。第一，外部開發者實測後，1000+ tokens/s 會不會掉很多。第二，這套方法離開 Xiaomi 自家堆疊後，還能不能維持同樣表現。這兩點比宣傳頁上的峰值數字更重要。

如果 MiMo 的數字能在更雜的 prompt、長 context、真實 traffic 下站穩，那它會逼很多團隊重新想一件事：到底是需要更強的晶片，還是需要更好的 co-design。這問題很實際，也很貴。

我的結論很簡單。這次發布最大的訊號，不是 1T 模型有多大，而是大模型推論正在變成系統工程。接下來如果你在做 AI 產品，最好先問自己一句：你的瓶頸是模型，還是整個執行鏈？