• 克雷西 發自 凹非寺
  量子位 | 公眾號 QbitAI

全球大模型的軍備競賽，正在“智商”之外開辟新的戰場——

推理速度

把這個戰場抬到新高度的，是小米。

小米發布了全新的MiMo-V2.5-Pro-UltraSpeed模型，也就是MiMo-V2.5-Pro的高速版本。

它擁有1T總參數，支持1M上下文，單API推理速度直接拉到1000+ TPS，刷新旗艦模型全球最快推理速度。

而且不像Groq那樣依靠定制芯片，用通用GPU就能實現

這也意味著，小米這次的新模型，打破了“快、強、通用GPU無法兼得”的行業不可能三角。小米秀出的是從模型層到引擎層的全鏈路推理優化能力，而背后的推理工程實力，毫無疑問是全球第一梯隊水平。

這次，量子位也拿到了MiMo-V2.5-Pro-UltraSpeed的測試資格，到底有沒有這么快，接下來一起看看。

實測小米“最快旗艦模型”

先看看MiMo-V2.5-Pro-UltraSpeed能不能生成一個完整的Web應用出來。

我把它接入了Claude Code，讓它寫一個網頁版的番茄鐘應用出來。

實話實說，以現在模型的推理能力，這個任務已經比較簡單了，所以這個任務主要想看的是它的速度。

用HTML、CSS、JavaScript實現一個可以直接在瀏覽器運行的番茄鐘工作計時器。
要求包含：
25分鐘專注/5分鐘短休息/15分鐘長休息三種模式可切換；
大字體倒計時顯示；
開始/暫停/重置按鈕；
完成一個番茄后自動切換到休息模式并播放提示音（用Web Audio API生成）；
右側顯示今日已完成番茄數和歷史記錄列表；
支持自定義各階段時長；
配色方案參考Linear設計風格。

結果，它的速度，還真讓我大吃一驚。

提交任務后的前5秒，我看到它還在慢吞吞地思考，以為要掉鏈子。

結果它是在憋大招，還沒等我回過神，需要交付的番茄鐘網頁代碼就chua得一下全吐出來了。

500多行HTML，加上思考過程一共只用了7秒

這張動圖體現的就是原速度，注意千萬別眨眼。

相比之下，如果用Claude，而且還是最輕量的Haiku搭配Low Effort，最短仍然需要40多秒。

把同樣的任務放到網頁端來跑，由于思考過程較長，因此總體耗時比用Claude Code接入MiMo-V2.5-Pro-UltraSpeed多了不少。

但網頁端的MiMo-V2.5-Pro-UltraSpeed自帶速度顯示，可以看到輸出階段的平均速度達到了1000+TPS

如果看峰值，目測推理階段最高吞吐量達到了600+ TPS，推理后的輸出階段更是飆到了3300+。

當然簡單歸簡單，功能該驗收還是得驗收的。

頁面跑起來之后，默認時長完全符合要求且支持自定義，要求的音效也會在計時結束時正常播放。

而且完成專注/休息計時后，還會自動跳到另一個模式，并且休息模式的跳轉還遵循了三短一長的節奏。

模型跑得快當然是好事，但如果速度是靠“降智”換來的，那就本末倒置了。

所以簡單的測速題目結束之后，接下來就要開始上難度，看看MiMo-V2.5-Pro-UltraSpeed的速度背后，到底有沒有“降智”。

同時，這里為了測試MiMo-V2.5-Pro-UltraSpeed能不能很好地適配不同的Harness，我又把環境改成了Hermes。

構建一個局域網實時聊天室，要求后端用Node.js+ Express + WebSocket；
支持多用戶同時在線，用戶進入時輸入昵稱，并和設備綁定，同一設備只有第一次進入時輸入，但要有編輯功能；
聊天界面參考Slack風格，支持多個頻道切換；
消息支持純文本和代碼塊（代碼塊自動高亮）；
顯示在線用戶列表，用戶上下線有系統提示；
支持消息引用回復；
消息記錄用SQLite持久化存儲，進入頻道可加載歷史消息；
輸出所有文件的完整代碼，然后啟動并部署到11451端口。

寫完之后，MiMo-V2.5-Pro-UltraSpeed直接向我匯報了項目文件、功能清單和啟動方式。

我們直接看運行效果。

首先最基礎的實時聊天、上下線提醒、輸入提示，全都正常實現。

代碼、加粗這些特殊格式，也都能正常顯示。

消息引用功能同樣正常運轉。

刷新頁面之后，之前設定的設備昵稱按要求被保留了下來，并且另一端也正常出現了下線提示，在線列表同步變動。

總之這一波，MiMo-V2.5-Pro-UltraSpeed把包含前端、后端、數據庫的完整開發流程，三下五除二地就給完成了。

這個例子足以證明，在提升速度的同時，MiMo-V2.5-Pro-UltraSpeed依然能夠高質量地完成全棧開發任務，也就是智商依然在線。

不過，這樣的速度，在實際生產當中，又能發揮什么作用呢？

我讓MiMo-V2.5-Pro-UltraSpeed扮演一位資深劇本編輯，帶著四位分析師在投委會前對一份電影大綱做緊急聯合審閱。

你是一位資深的劇本編輯，手下有三位得力的審稿人。
現在你們需要在明天早上的項目評審會之前，對下面這份院線電影劇本大綱完成一次緊急聯合審閱。
請按照以下分工完成任務：
你的故事結構分析師先接手，專門審查三幕結構是否完整、主線與支線的節奏配比是否合理、高潮場景的鋪墊是否充分，出具一份結構審查意見。
與此同時，你的人物分析師也在并行工作，專門審查主角的動機是否可信、人物弧光是否完整、配角的功能是否清晰，出具一份人物審查意見。
你的市場分析師同步從商業角度出發，審查這個題材的受眾定位是否清晰、同類型影片的市場表現如何、這個項目的差異化賣點是否足夠，出具一份市場可行性意見。
三份意見都到手之后，你作為劇本編輯親自綜合判斷：這份大綱能否推進立項？列出必須修改的問題清單，并直接輸出一份修改后的完整大綱。

故事的梗概是這樣的：

院線電影劇本大綱：《候鳥不南飛》
類型
現實主義情感劇情片，主打25-40歲都市女性受眾。
一句話簡介
一個在北京打拼十二年的湖南女人，在母親突然病倒后被迫返鄉，在照料與逃離之間重新理解了自己與家的關系。
主要人物
謝晚晴，38歲，北京某公關公司總監，離異，獨居，與母親關系疏遠已久；
謝母，64歲，湖南縣城退休教師，強勢、傳統，習慣用沉默施壓；
陳默，40歲，謝晚晴的前同事，因家庭原因提前返鄉創業，現經營一家民宿。
故事梗概
第一幕：謝晚晴接到父親的電話，母親突發腦梗住院。她請假返鄉，原本打算處理完就走，卻發現母親的康復需要長期陪護，而父親已無力獨自承擔。她陷入職業與家庭的兩難。
第二幕：謝晚晴滯留縣城，在照料母親的過程中與母親爆發多次激烈沖突，母親的強勢與控制欲將她推向崩潰邊緣。與此同時，她與陳默重新建立聯系，陳默的生活選擇讓她開始重新審視自己十二年來的人生路徑。
第三幕：母親康復出院，謝晚晴面臨是否回京的最終抉擇。她最終選擇回京，但與母親之間達成了某種和解，不是原諒，而是接受彼此是不同的人。
核心主題
逃離與歸屬，自我實現與家庭責任，中國式母女關系。預計時長：105分鐘。

我用Hermes搭了一個三Agent工作流，讓MiMo-V2.5-Pro-UltraSpeed同時啟動三個subagent對一份電影大綱做并行審閱。

其中故事結構分析師查三幕節奏，人物分析師查動機和弧光，市場分析師查商業可行性。

三份意見匯總后，主Agent綜合判斷并直接輸出修訂版大綱。

結果總共不到兩分鐘的時間，三個subagent就全都完成了各自的任務，最終的報告也完整交付給了我。

三個subagent各自找到了對方沒有發現的問題。

• 結構分析師指出原版大綱里第二幕的中點和第二轉折點完全缺失，這是硬傷。
• 人物分析師發現主角謝晚晴自始至終是被推著走的，缺少一個主動的貫穿全片的欲望，而陳默這個角色刪掉故事仍然成立，說明他沒有找到敘事中的不可替代位置。
• 市場分析師則拉出競品做對標，給出了3000萬到12億的票房區間，并點明差距的關鍵在于情緒烈度和社會話題的引爆能力。

三份意見到齊之后，主Agent給出的修訂版大綱補上了所有結構性缺口。

原版只有一句話的第二幕被拆成三層遞進沖突，補充了中點和第二轉折點，父親從單純的信息傳遞者變成了全片最重要的“翻譯者”，陳默的“歲月靜好”也被推翻，這個設定直接打碎了主角對“另一種人生”的浪漫化想象。

這類任務的價值在于多角色同時在線、實時協同推進同一個目標。三個subagent并行跑完再匯總，整條鏈路沒有等待感。

換成推理速度不夠快的模型，每個節點都會積累延遲，最終拖成一個斷斷續續的流程。

1000 TPS在這里的價值，是讓多Agent協同從理論上可行變成用起來真的流暢

全鏈路Co-design

在MiMo-V2.5-Pro-UltraSpeed出現之前，業界能公開看到的最快推理速度，大概是讓一個400B參數的模型，跑出400 TPS的吞吐量。

雖然參數量和吞吐量都只有MiMo-V2.5-Pro-UltraSpeed的四成，但這實際上已經是相當激進的選擇。

之所以說激進，是因為這樣的速度基本上是靠削減模型參數量換來的，代價就是智商降低。

但小米在模型提速這個問題上，選了一條更難走的路。

MiMo-V2.5-Pro-UltraSpeed的起點是約1T總參數、1M超長上下文的旗艦模型，目標是在通用GPU上把單API推理速度拉到1000+ TPS，三個條件一個都不能放。

為此，小米從模型層、引擎層、系統層三個層面同時下手，進行了全鏈路的聯合設計

模型層承擔了兩件事，一是解決1M超長上下文下的計算壓力，二是處理參數帶寬的壓力。

針對上下文問題，MiMo-V2.5系列采用了Hybrid SWA（混合滑動窗口注意力）架構。把注意力機制拆成了兩級。

具體來說，模型只針對最近的一段上下文繼續做精細計算，更早的內容則先被壓縮，以更低的成本參與后續步驟。

這種分層處理讓整體計算量降到了Full Attention的約1/7，1M級超長上下文下，推理速度和成本依然能保持穩定。

而對于帶寬問題，小米對Expert模塊引入了FP4量化，把并行的Expert模塊參數壓縮到4bit，從源頭減小顯存占用和讀寫壓力。

與此同時，負責信息路由和關鍵邏輯的注意力模塊和Router模塊繼續保持高精度，再通過量化感知訓練把FP4引入的誤差壓到最小。

模型層打好了基礎，引擎層要解決的是decode階段的成本問題。

小米采用的DFlash方案對傳統的Speculative Decoding草稿線做了結構性改造，將草稿模型沿時間軸逐token串行生成的模式，改成對一整塊位置同時并行加工。

同時，主模型也不再對每個token單件驗收，變成了對整批半成品集中審核，合格的整體接入，不合格的局部返工。

草稿模型同樣使用了SWA架構，并經過專項的密集長鏈路數據訓練，保證每次并行產出的一批候選token有足夠高的合格率。

系統層是推理鏈路的最后一道關卡。

當TPS提升到千級之后，瓶頸在于工序之間的切換開銷，以及為小批量請求頻繁啟停帶來的等待損耗。

在上述優化的基礎上，小米又與TileRT團隊深度協作，在GPU執行路徑上做了兩項關鍵優化

• Persistent Kernel（常駐內核）把經常連續執行的關鍵步驟，封裝成長期駐留在GPU上的主計算線，不再為每一批請求反復冷啟動；
• Warp Specialization（線程束專化）讓數據搬運、當前批處理、結果輸出三個環節同時并行運轉，整條算力鏈幾乎沒有閑置等待的空檔。

小米綜合應用這些技術的結果，就是真的讓1T參數的模型，在通用GPU上跑出了1000+ TPS的速度，并且可以穩定復現。

突破大模型商業化天花板

對于小米來說，速度提升的意義，遠不止Token吞吐得更快這一件事。

過去，1T參數的旗艦大模型太大、太慢，只能做“事后諸葛亮”，很難接入對延遲極敏感的實時業務。

例如高頻量化交易要求在毫秒級窗口內分析市場信號并驅動下單，金融實時反欺詐風控要求每筆交易在0.1秒內完成風險評估，廣告RTB競價要求在100毫秒的請求窗口里完成用戶畫像、創意匹配和出價決策。

這些場景長期只能依賴規則引擎或小模型，旗艦大模型的深度推理能力一直被擋在門外。

而在單API穩定跑到1000+ TPS之后，這道門被推開了。

日常生產力場景也在發生質變。

過去一個全棧項目的重構，從理解代碼庫到生成修改方案、逐文件改寫、跑測試、修bug，常常拖成8到12分鐘的等待。

現在同樣的任務被壓縮進幾十秒，復雜報告的討論也從把問題丟給模型等它想好，變成了和模型一起邊想邊改。

總之，很多過去被速度和成本擋在門外的應用場景，如今落地的條件正在成熟。

為MiMo-V2.5-Pro-UltraSpeed做的全鏈路推理優化，對小米來說還有另一層價值。

這套優化是可以在后續模型和業務場景上直接復用的底層能力，換一代通用GPU只需做適配升級，速度和成本優勢可以平移到新平臺。

小米自家的模型和業務場景越多，這套能力被復用的次數就越多，單次推理成本越攤越薄，速度優勢可以像滾雪球一樣越放越大。

把近期小米大模型的幾個動作串起來看，信號更加清晰。

小米模型登頂全球開源模型第一、MiMo-2.5系列全面調價，現在又推出1000 tokens/s的旗艦高速模型，三件事依次落地，高速、高智商、全鏈路成本優化同時到位。

這些事件背后，指向的是同一個方向，那就是系統性地拆除大模型商業化路上的每一道障礙。