MiMo-V2.5-Pro API

MiMo-V2.5-Pro 的技術規格

區分1.02T 總參數與 42B 啟用參數十分重要。MiMo-V2.5-Pro 是一個 MoE 模型：每個 Token 只會啟用部分可用參數。相比稠密的 1T 參數模型，這顯著改變了其推理計算特性；即便如此，完整模型仍具有巨大的記憶體與部署需求。

MiMo-V2.5-Pro 的主要特性是什麼？

1. 兆級稀疏 MoE 架構

MiMo-V2.5-Pro 包含1.02T 總參數與 42B 啟用參數。

其架構包含384 個路由化專家，每個 Token 會啟用 8 個專家。模型具有 70 個 Transformer 層，由 1 個稠密層與 69 個 MoE 層組成。

這比標準版 MiMo-V2.5 提供了更強的表示能力，同時避免為每個 Token 啟用全部 1.02T 參數的計算成本。

實務重點是：

MiMo-V2.5-Pro 的總容量屬於兆級參數模型，但其每個 Token 的計算受 42B 啟用參數路徑所支配。

2. 100 萬 Token 上下文

該模型最多支援1M Token 的上下文。

這對自主代理而言至關重要，因為長期運行的工作流程會累積：

• 工具輸出
• 原始碼
• 搜尋結果
• 文件
• 中間推理狀態
• 使用者指示
• 執行日誌

代理無需反覆摘要並丟棄舊上下文，理論上可保留更大的工作歷史。

Xiaomi 的長上下文評測特別從 32K 到 1M 的輸入 Token 進行測試。

3. 混合式滑動視窗與全域注意力

MiMo-V2.5-Pro 採用SWA 與全域注意力 6:1 的比例，滑動視窗為 128 Token。

其架構包含：

• 60 個 SWA 層
• 10 個全域注意力層
• 128 Token 的 SWA 視窗

據 Xiaomi 報告，此設計可將 KV 快取儲存需求降低近7×，並透過可學習的注意力匯聚偏置維持長上下文效能。

這是模型在技術上最重要的部分之一。

若 1M 的上下文視窗中每個層都對整個序列做完整注意力，代價極高。混合注意力設計減少了每層需要全域關注的資訊量，同時保留專門的全域注意力層以處理長距離關係。

4. 多 Token 預測

MiMo-V2.5-Pro 包含三個輕量化 MTP 模組。

多 Token 預測允許模型預測多個未來 Token，可用於推測式解碼與推理加速。

在其描述的部署設定下，Xiaomi 表示其 MTP 架構可在推理過程中將輸出速度提升至三倍。

這對代理尤為重要，因為代理在長軌跡中可能生成大量中間輸出。提高 Token 生成速度因而能顯著影響總任務延遲。

5. 代理式強化學習

MiMo-V2.5-Pro 的後訓練流程包括：

• 監督式微調
• 大規模代理式強化學習
• 多教師在策略蒸餾（MOPD）

其訓練目標明確面向複雜的代理行為，而不僅是靜態基準問答。

因此模型的最強評測集中於程式設計、終端互動、長上下文推理與代理基準。

6. 27T Token 預訓練

MiMo-V2.5-Pro 在約27 兆 Token上進行預訓練，使用 FP8 混合精度與原生 32K 序列長度，之後才支援擴展至 1M 的上下文視窗。

預訓練規模，結合兆級參數的 MoE 架構，使 MiMo-V2.5-Pro 穩居當前前沿模型之列。

---

MiMo-V2.5-Pro 在標準測試上的表現如何？

已發佈的評測結果尤其有用，因為它同時涵蓋一般推理基準與實用的程式設計/代理評測。

結果顯示其在軟體工程與數學推理方面尤為強大。報告中的 SWE-Bench Verified 78.9 與 Terminal-Bench 2.0 68.4 對於構建自主程式設計系統的開發者特別重要。

長上下文表現

長上下文結果可能比標準基準更有趣。

在 GraphWalks 評測中，MiMo-V2.5-Pro 在極端上下文長度下仍保持可衡量的表現：

據 Xiaomi 報告，先前的 MiMo-V2-Pro 在超過 128K 後迅速劣化，於 1M 時在兩個子任務上都降至 0.00，而 V2.5-Pro 在完整 1M 上下文下仍保有非零表現。

這是有意義的差異：MiMo-V2.5-Pro 的 1M 上下文不僅是理論最大值；已發佈的長上下文評測顯示其在該視窗內深處仍有實際效能。

真實世界代理示例

這些是 Xiaomi 的示範性報告，而非標準化基準分數。

MiMo-V2.5-Pro 與 MiMo-V2.5 的比較

兩者同屬同一世代，但面向不同工作負載。

因此選擇並非簡單地「Pro 更好」。

若應用需要原生影像、視訊與音訊理解，MiMo-V2.5 更適合。若工作負載聚焦於複雜推理、軟體工程、終端互動與長期運行的代理，MiMo-V2.5-Pro 更契合。

MiMo-V2.5-Pro 的限制

1. 僅支援文字輸入的模型

不同於 mimo-v2.5，Pro 模型的官方規格將輸入模態列為文字。它不應作為 V2.5 系列中的多模態模型進行宣傳。

2. 自主託管的高計算需求

該模型約有1T 總參數 / 42B 啟用參數，本地部署比常見的小型開源模型要求更高。

3. 代理效能取決於框架

Xiaomi 接近 1,000 次工具呼叫的宣稱明確與使用合適的代理框架相關。僅靠模型本身並不保證應用能達到相同的長程效能。

4. 推理內容處理

使用思考模式與工具呼叫的多輪代理應用需要正確保存 reasoning_content。處理不當可能導致 API 錯誤。

最佳使用場景

大規模軟體工程

• 倉庫遷移
• 重構
• 除錯
• 測試生成
• 編譯器開發
• 全端應用開發

自主編碼代理

MiMo-V2.5-Pro 對需要反覆執行以下循環的代理尤為適合：

檢查 → 修改 → 執行 → 測試 → 診斷 → 修改

長文檔推理

其 1M 上下文使其適用於：

• 法律合約
• 技術規範
• 大規模研究資料集
• 企業文件

複雜業務代理

工具呼叫 + 網路搜尋 + 結構化輸出可以支援：

• 研究代理
• 資料處理代理
• 企業流程自動化
• 多步驟決策系統

如何在 CometAPI 上使用 MiMo-V2.5-Pro API

相關的 CometAPI 模型 ID 為：

mimo-v2.5-pro

對開發者而言，API 聚合層有助於在不維護獨立供應商整合的情況下，將 MiMo-V2.5-Pro 與其他高階推理與代理模型進行測試與對比。

步驟 1：取得 CometAPI API 金鑰

建立或登入您的 CometAPI 帳戶，並從 API 控制台取得 API 金鑰。

將其設定為環境變數：

export COMETAPI_KEY="YOUR_COMETAPI_KEY"

步驟 2：設定 API 用戶端

Xiaomi 提供同時相容於OpenAI 與 Anthropic 協議的 API，使遷移相對簡單。若需生產級整合，請使用 mimo-v2.5-pro 的現行 CometAPI 端點/結構定義，尤其在需要工具呼叫、串流、結構化輸出或長上下文請求等進階功能時。

步驟 3：將 MiMo-V2.5-Pro 連接到工具

模型在連接外部工具後將大幅提升實用性。

例如：

                    ┌── Web Search
                    │
User → MiMo-V2.5-Pro ├── GitHub
                    │
                    ├── Terminal
                    │
                    ├── Database
                    │
                    └── Internal APIs
                           ↓
                     Tool Results
                           ↓
                    MiMo-V2.5-Pro
                           ↓
                      Final Result

此架構遠比簡單的聊天機器人整合更貼近模型的設計用途。