TL;DR
MiMo-V2.5 是多模態工作、常規代理與成本敏感生產的更強默認選擇。MiMo-V2.5-Pro 是面向高難度推理、倉庫級程式開發與長時工具使用的專家選項。兩者皆提供 1M 標記的上下文視窗與最多 128K 輸出標記，但 Pro 採用更大的語言骨幹，普通輸入與輸出標記成本約為 3.1 倍。
MiMo-V2.5 vs. Pro: 快速決策
| 規格 — 官方發佈 | MiMo-V2.5 | MiMo-V2.5-Pro | 推薦模型 | 理由 |
|---|---|---|---|---|
| 主要定位 | 全能多模態模型與高效率代理 | 旗艦級代理與複雜程式開發 | 依工作負載選擇 | 多模態輸入傾向 V2.5；持續困難的文本工作傾向 Pro。 |
| 架構 | 稀疏 MoE | 稀疏 MoE | 依工作負載選擇 | 僅靠模型規模並不能保證在所有任務上更佳。 |
| 總參數量 | 310B | 1.02T | 依工作負載選擇 | 更大的模型針對困難推理，但總規模不等同於任務結果。 |
| 啟用參數 | 15B | 42B | 依工作負載選擇 | 以任務完成度與成本為準。 |
| LLM 層數 | 48 | 70 | 依工作負載選擇 | 層數描述架構，非普遍勝出。 |
| 路由專家數 | 256 | 384 | 依工作負載選擇 | 差異僅在改善目標工作負載時才重要。 |
| 每標記啟用專家數 | 8 | 8 | 皆可 | 兩者均為每標記啟用八個專家。 |
| 上下文視窗 | 1M 標記 | 1M 標記 | 皆可 | 兩者皆標稱 1M 上下文；需測試有效檢索能力。 |
| 最大輸出 | 128K 標記 | 128K 標記 | 皆可 | 兩者皆標稱最多 128K 輸出標記。 |
| 輸入模態 | 文本、影像、影片與音訊 | 文本 | MiMo-V2.5 | 它接受影像、影片與音訊輸入；Pro 專注於文本輸入。 |
| 工具呼叫 | 是 | 是 | 依工作負載選擇 | 兩者皆可呼叫工具；需在實際軌跡上測試成功率。 |
| 開放權重與授權 | 是；MIT | 是；MIT | 皆可 | 兩者皆提供 MIT 授權的開放權重；服務成本不同。 |
決定性的差異：多模態 vs 代理優先
V2.5 原生接受文本、影像、影片與音訊。小米為語言骨幹配備 729M 參數的視覺編碼器與 261M 參數的音訊編碼器，使多模態資訊能直接參與同一推理流程。
- 在呼叫工具前分析螢幕截圖。
- 同時理解影片及其音訊軌。
- 從圖表與文件影像中抽取資訊。
- 操作可視化介面與多模態支援的代理。
- 對長時影片序列進行推理。
V2.5-Pro 採取不同設計。小米目前指定文本為輸入模態，並強調深度推理、程式開發與長時工具協作。
若工作流程本身包含影像、影片或音訊輸入，請先使用 V2.5。當困難部分在於對文本、原始碼、工具或長代理軌跡的推理時，再測試 Pro。
小米官方多模態基準比較。
為何 V2.5-Pro 在高難度任務上可能更佳
模型規模：310B/15B vs. 1.02T/42B
兩個模型皆採用稀疏專家混合（MoE）骨幹、混合滑動視窗與全域注意力，以及三層多標記預測（MTP）模組。小米的 V2.5 模型卡記載骨幹總參數 310B、每標記啟用 15B；Pro 模型卡將其擴展至 1.02T 總參數、每標記啟用 42B。
| 架構 — 官方模型卡 | V2.5 | Pro | 差異 |
|---|---|---|---|
| 總參數量 | 310B | 1.02T | 約 3.3× |
| 啟用參數 | 15B | 42B | 2.8× |
| 隱藏層維度 | 4,096 | 6,144 | 1.5× |
| LLM 層數 | 48 | 70 | 多 22 層 |
| 注意力頭數 | 64 | 128 | 2× |
| 路由專家數 | 256 | 384 | 1.5× |
| 每標記專家數 | 8 | 8 | 相同 |
| MTP 層數 | 3 | 3 | 相同 |
V2.5 使用5:1 的注意力模式，而 Pro 採用 6:1 的本地對全域模式。小米表示，相較於全網路均使用完整注意力，這些設計分別將 KV 快取需求降低近 6× 與 7×。
總參數量不會線性轉化為答案品質。當推理難度或軌跡長度使每步的小幅可靠性提升可累積放大時，Pro 的更大骨幹才最為重要。
為何小幅可靠性提升會累積放大
長代理任務包含眾多相互依賴的步驟。早期工具呼叫中的錯誤可能導致重試或使後續工作失效，因此每步適度的可靠性提升可能對端到端完成度產生更大的影響。請在具代表性的任務上評估該效應，而非假定模型更大就必然更好。
V2.5-Pro 在哪些方面實際改善？
最乾淨的數值比較來自小米的基礎模型評測，兩個模型在相同設定下出現。這可避免混合與不同工具或後訓練配置所產出的結果。
通用知識：小幅到中等提升
在小米的基礎模型比較中，Pro 在 BBH 上提升 1.2 分、MMLU 上 3.1 分、MMLU-Pro 上 2.7 分。這些提升可測但低於其在更困難推理任務上的增幅。
數學與科學：更大提升
在相同的基礎模型評測中，Pro 在 GPQA-Diamond 上提升 8.6 分、GSM8K 上 16.3 分、MATH 上 18.5 分。這是當困難推理決定任務成功時選擇 Pro 的最明確證據。
程式設計：更好，但非全面更好
報告顯示在人類評估（HumanEval+）提升 4.3 分、MBPP+ 提升 3.2 分、LiveCodeBench v6 提升 4.1 分、SWE-Bench AgentLess 提升 4.9 分。請分別測試倉庫級任務與工具使用：這些基礎模型分數未覆蓋所有生產代理工作流。
基準結果： Pro 並非因成本約為三倍而「三倍更好」。隨著推理難度與任務時長增加，它的價值逐步提升。
以上為基礎模型評測結果，並非承諾生產 API 可重現同等分數。代理結果取決於工具、提示詞、重試、執行環境與標記預算。
後訓練與長時域代理
生產模型加入了監督微調、代理式強化學習與多教師在策略蒸餾。小米報告 V2.5 的後訓練分數為 SWE-bench Pro 56.1、Terminal-Bench 2.0 65.8，以及 Claw-Eval 通用部分 62.1 Pass³。
Pro 更明確地針對長時域軟體工程優化。小米描述在持續軌跡中進行數百次工具呼叫，並公布 78.9% 的 SWE-bench Verified 結果。
一個官方案例研究顯示，Pro 在 4.3 小時內完成一個 SysY 編譯器，共進行 672 次工具呼叫，並通過全部 233 項測試。重點不在於每個程式請求都需要 Pro，而是小幅可靠性差異可能決定由數百個相互依賴動作組成的工作流是否完成。
小米官方程式與代理基準圖。
長上下文：相同容量，不同工作負載
兩個模型皆透過小米當前 API 提供1M 標記的上下文視窗與最多 128K 輸出標記。因此，僅從原始上下文容量無法區分兩者。
當長上下文包含多模態材料（如影片、文件影像或視覺代理追蹤）時，V2.5 具有吸引力。當上下文本身成為推理難題（大型程式倉庫、長合約、研究語料或包含許多連續動作的代理軌跡）時，Pro 是應測試的模型。
大上下文視窗描述的是容量，而非保證的推理忠實度。請在實際應用所需長度下評估檢索、指令保持與證據使用。
價格與成本效率
小米海外的按量計費價格使權衡一目了然。
| 定價 — 官方價目表 | V2.5 | Pro | 比率 |
|---|---|---|---|
| 每 1M 標記的未快取輸入 | $0.14 | $0.435 | 3.11× |
| 每 1M 標記的已快取輸入 | $0.0028 | $0.0036 | 1.29× |
| 每 1M 標記的輸出 | $0.28 | $0.87 | 3.11× |
| 上下文視窗 | 1M | 1M | 相同 |
| 最大輸出 | 128K | 128K | 相同 |
一個包含 1M 未快取輸入標記與 200K 輸出標記的請求，估計成本在 V2.5 上為 $0.196、在 Pro 上為 $0.609（不含快取命中、網頁搜尋費用或供應商特定計費）。
快取價格差異較小：對於快取命中的輸入，Pro 僅約貴 29%，而非 211%。因此，具有穩定系統提示詞、工具定義或倉庫前綴的長時代理，應衡量實際快取命中率。
估算每個成功任務的成本。若 Pro 代理能一次完成困難工作流，可能比在便宜模型上反覆失敗更省錢。
應使用哪個模型？
| 工作負載 — 官方指引 | 更佳選擇 | 原因 |
|---|---|---|
| 常規文本對話 | V2.5 | 成本更低；Pro 常無必要 |
| 大量生成 | V2.5 | 標準標記價格約低 3.1× |
| 影像、影片或音訊理解 | V2.5 | 原生多模態輸入 |
| 常規工具呼叫 | V2.5 | 低成本下的強代理能力 |
| 困難數學與科學 | Pro | 基準增幅更大 |
| 倉庫級程式開發 | Pro | 為複雜軟體工程設計 |
| 數百個相互依賴的工具呼叫 | Pro | 更契合持續執行 |
| 成本敏感的 1M 上下文 | V2.5 | 相同名義上下文、成本低得多 |
選擇結果： V2.5 是多模態應用、常規代理與成本敏感工作負載的默認選擇。Pro 是面向困難推理、複雜軟體工程與長期自主軌跡的升級選項。
更佳的生產策略：在兩者之間路由
單一的全局模型選擇往往非必要。將多模態與常規請求路由至 V2.5，僅在遇到困難文本推理、複雜程式開發或長時執行時升級到 Pro。
| 評估維度 | 度量 | 原因 | 路由信號 |
|---|---|---|---|
| 完成率 | 成功任務/嘗試 | 捕捉端到端可靠性 | 對完成率低的類別升級 |
| 品質 | 人工或評分規則 | 防止標記成本主導決策 | 對高風險任務升級 |
| 工具可靠性 | 錯誤與重試 | 小錯誤在代理中會累積放大 | 對長軌跡升級 |
| 延遲 | 至接受結果的時間 | 包含重試開銷 | 讓互動式任務保持輕量 |
| 成本 | 每個成功任務的支出 | 反映失敗與重跑 | 使用能成功的最便宜模型 |
在 CometAPI 測試兩者 API
MiMo-V2.5 API（CometAPI）與MiMo-V2.5-Pro API（CometAPI）支援透過單一聚合層進行並排評估。向兩者發送相同的提示詞、系統指令、工具與輸出限制，然後比較任務成功與成本。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
)
models = ["mimo-v2.5", "mimo-v2.5-pro"]
prompt = """
檢閱此實施計畫。
識別隱藏的技術風險，並提出三項最高優先順序的修正建議。
"""
for model in models:
response = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
max_tokens=2000,
)
print(f"\n--- {model} ---")
print(response.choices[0].message.content)
運行一批具有代表性的請求，包含簡單任務、困難推理、程式碼編輯、長上下文任務與代理工具呼叫。記錄完成率、標記數、延遲、工具錯誤、重試次數、答案品質，以及每個成功任務的成本。
限制
V2.5 的限制
較小的語言骨幹會隨著推理難度上升而留下性能空間。在 BBH 上差距不大，但在 GPQA-Diamond 與 MATH 上大幅擴大。1M 的上下文視窗也不應被誤解為保證 1M 的推理忠實度。
Pro 的限制
Pro 的普通輸入與輸出價格約為 V2.5 的 3.1 倍，且其僅文本輸入使其不適合作為多模態應用的即插即用替代。1.02T 參數的開放權重模型對自託管亦具挑戰，即便每標記啟用參數為 42B。
最終結論
在多模態應用、常規代理與成本敏感生產中選擇 V2.5。面對困難推理、複雜軟體工程與長時自主代理，選擇 Pro。對於混合工作負載，將大多數流量路由至 V2.5，僅對難度或軌跡長度值得額外成本的請求進行升級。
常見問題
Pro 是否一定優於 V2.5？
不是。Pro 在困難文本推理與程式設計上更強，但 V2.5 支援影像、影片與音訊輸入，且成本明顯更低。
兩個模型都支援 1M 標記的上下文視窗嗎？
是。兩者皆標稱 1M 上下文與最多 128K 輸出標記。應用仍應在實際運作長度下測試檢索與推理。
多模態代理應使用哪個模型？
從 V2.5 開始，因其原生接受視覺與音訊輸入。Pro 目前針對文本輸入工作流。
何時 Pro 值得其較高的價格？
當更好的推理可靠性影響困難數學、倉庫級程式開發，或包含許多相互依賴工具呼叫的長軌跡之完成時，最具正當性。
生產系統是否應只使用一個模型？
未必。可透過路由層將常規與多模態工作保留在 V2.5，同時僅將困難文本與代理任務升級至 Pro。