MiMo-V2.5 API

MiMo-V2.5 的技術規格

310B/15B 的架構尤為重要。MiMo-V2.5 並非 15B 模型（傳統意義上）；15B 是每個 token 啟用的參數數量，而完整的 MoE 含有 310B 參數。該模型使用 256 個路由專家，每個 token 會啟用 8 個專家。

什麼是 MiMo-V2.5？

MiMo-V2.5 是 Xiaomi 的下一代多模態模型，專為全模態感知與智能體應用而打造。

與傳統僅支援文字的 LLM 不同，MiMo-V2.5 原生理解影像、影片、音訊與文字。Xiaomi 將其定位於長上下文與多模態智能體場景，模型需要先感知資訊、進行推理，隨後使用工具或執行動作。

對開發者而言，還有一個當前版本的重要事項：Xiaomi 已於 June 30, 2026 停用舊版 MiMo-V2 系列，建議遷移至 V2.5 系列。

因此，mimo-v2.5 成為新整合的相關模型 ID，而非舊的 mimo-v2-pro、mimo-v2-omni 或 mimo-v2-flash。

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

原生全模態理解

MiMo-V2.5 的核心特徵是將多模態能力直接整合於模型之中。

它可接受：

• Text
• Images
• Video
• Audio

這使開發者能建立可跨多種資訊型別進行推理的應用，而非各自處理每一種模態後再將結果傳入文字 LLM。Xiaomi 將此描述為原生全模態感知。

一個實際範例是影片分析智能體：它接收一段很長的影片、音軌與文字問題，接著辨識事件、解釋所發生的情況，並產生結構化答案。

1M-Token 上下文視窗

MiMo-V2.5 支援1 million tokens 的上下文與最多128K 輸出 tokens。

這讓模型特別適合：

• 大型文件分析
• 長影片理解
• 程式碼庫層級程式設計
• 長時間研究會話
• 多步驟智能體
• 延展對話
• 大型企業知識庫

1M 的上下文不僅僅是行銷數字。Xiaomi 明確指出長影片追蹤、冗長文件分析與長時間序推理等為其目標工作負載。

智能體式工具使用

MiMo-V2.5 支援函式呼叫、網路搜尋、結構化輸出與串流。

這使它比僅限文字生成的模型在智能體應用上更具實用性。

典型的工作流程如下：

感知 → 推理 → 搜尋 → 呼叫工具 → 分析結果 → 繼續

這對研究型智能體、程式設計助理、客服智能體與多模態自動化特別有用。

稀疏 MoE 效率

MiMo-V2.5 採用310B 參數的稀疏 MoE 架構，每個 token 僅啟用 15B 參數。

其骨幹包含 48 層，其中 39 層為滑動視窗注意力層，9 層為完整注意力層。此混合設計旨在讓超長上下文在計算上更易處理。

對開發者而言，重要的區別在於：啟用參數數量不應被解讀為總記憶體需求。自行託管一個 310B 參數的模型仍是龐大的基礎設施投入。

混合式滑動視窗注意力

MiMo-V2.5 結合滑動視窗注意力與全域注意力。

其架構使用 128-token 的 SWA 視窗，包含 39 層 SWA 與 9 層完整注意力。

這一架構選擇對模型的 1M-token 上下文能力尤為關鍵，因為若在每一層都維持完整注意力，長上下文推論的成本將顯著提高。

多 Token 預測

MiMo-V2.5 包含三個 MTP 層，約329M 參數。MTP 的設計旨在透過推測式解碼提升推論效率，並支援更高效的強化學習訓練。

---

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

MiMo-V2.5 已發布涵蓋程式設計、終端智能體、研究智能體與多模態智能體任務的基準結果。目前 Hugging Face 模型卡展示以下成績：

這些數字需謹慎解讀。

56.1 的 SWE-Bench Pro 成績顯示具備一定的軟體工程能力，而 65.8 的 Terminal-Bench 2.0 則對需與終端與開發環境互動的智能體特別重要。

同時，一般 Claw-Eval 分數（62.1）與多模態分數（23.8）之間的差異是一個有用的警示：強勁的一般智能體表現並不自動代表在每個多模態智能體任務上都有同等強度的表現。

在生產評估中，開發者應測試自身的工作負載，而非僅依賴單一排行榜數字。

---

MiMo-V2.5 與 MiMo-V2.5-Pro 有何比較？

MiMo-V2.5 與 MiMo-V2.5-Pro 同屬 V2.5 世代，但優化目標不同。

區別相當明確：

若需要原生多模態理解與高效通用智能體，選擇 MiMo-V2.5。若面對最艱難的推理、程式設計與長程智能體工作負載，選擇 MiMo-V2.5-Pro。

Xiaomi 的模型選型指南建議：理解影像、音訊與影片內容時選 mimo-v2.5，而複雜推理與長文件處理則選 mimo-v2.5-pro。

MiMo-V2.5 的使用情境

多模態 AI 智能體

MiMo-V2.5 可作為需要檢視文件、影像、影片與音訊，之後再決定採取何種行動的智能體核心模型。

長上下文文件分析

1M-token 的上下文適合分析：

• 大型法律文件集
• 技術文件
• 研究檔案
• 大型程式碼庫
• 企業知識庫

程式設計智能體

模型的智能體基準與工具使用能力，適合用於程式設計助理：需要檢視版本庫、推理問題、執行工具並迭代解法。

影片理解

MiMo-V2.5 將影片作為輸入模態用於理解，而非以影片生成為主要目的。

潛在應用包括：

• 影片摘要
• 長影片問答
• 影片搜尋
• 事件偵測
• 教學影片分析
• 監視影像分析

視聽助理

由於模型同時接受音訊與視覺資訊，開發者可打造能結合視覺脈絡解讀口語指令的助理。

長時自主智能體

長上下文與智能體式訓練的組合，讓 MiMo-V2.5 適合需在眾多中間步驟中維持狀態、而非一次回應就完成任務的工作流程。

MiMo-V2.5 的限制

MiMo-V2.5 的規格令人印象深刻，但仍有若干實務限制需注意。

首先，1M 的上下文並不代表在最大視窗下每個應用都能達到最佳表現。長上下文推論仍牽涉可觀的記憶體、頻寬與延遲考量。

其次，該模型是非常大的 MoE 系統。雖然每個 token 僅啟用 15B 參數，但完整模型約有 310B 參數，自我託管的難度遠高於運行小型稠密模型。

第三，多模態基準表現會依任務而顯著變化。Claw-Eval 的結果顯示多模態分數遠低於一般智能體分數，再次強調需要針對具體應用進行測試。

最後，該模型的生態仍較 GPT、Claude 與 Gemini 周邊成熟生態新。開發者在導入關鍵任務系統前，應評估工具鏈、供應商相容性、結構化輸出行為與工具呼叫的可靠性。

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

MiMo-V2.5 特別適合用於 API 聚合平台，因其遵循與既有 LLM 生態相容的 API 模式。Xiaomi 本身提供相容於 OpenAI 與 Anthropic 的 API 存取。

在 CometAPI 上，整合流程可與其他受支援模型採用相同的基本工作流程。

Step 1: 取得 CometAPI API Key

建立或登入 CometAPI 帳戶並取得 API 金鑰。

import os

COMETAPI_KEY = os.environ["COMETAPI_KEY"]

Step 2: 設定 MiMo-V2.5 模型

將模型設為：

mimo-v2.5

並使用 CometAPI 的相容 API 端點。

在部署前，請依照最新的 CometAPI 模型/API 文件確認確切端點與請求綱要。

Step 3: 建構多模態與智能體工作流程

mimo-v2.5 更有趣的用法並非一般文字對話。開發者可將其多模態推理與外部工具結合，打造如下工作流程：

使用者輸入 → 影像/影片/音訊理解 → 推理 → 工具呼叫 → 結果分析 → 下一步行動

這使該模型對自主研究智能體、程式設計智能體、多模態客服系統與長上下文企業助理特別具有吸引力。

為什麼要透過 CometAPI 使用 MiMo-V2.5？

在多模型 API 環境中，MiMo-V2.5 特別有用，因為開發者可能希望與 GPT、Claude、Gemini、DeepSeek 或其他智能體模型進行比較，而不必為每個供應商建立獨立的基礎架構。

當您的應用需要：

• 統一的 API 抽象層
• 存取多個 AI 模型家族
• 更容易的模型切換
• 集中化的 API 金鑰管理
• 快速模型比較
• 一個同時適用於試驗與生產的整合層

對於評估智能體表現與推論成本的團隊而言，MiMo-V2.5 值得與更昂貴的旗艦模型一同測試，而非預設最大型的專有模型就一定是最佳選擇。