MiMo-V2.5-Pro（小米 1T MoE）

在 Clore.ai 上部署小米的 MiMo-V2.5-Pro（1.02T MoE，42B 活跃，100 万上下文）——MiMo 团队首个开源权重 Pro 级模型，原生 FP8，混合注意力

状态（2026年4月）： MiMo-V2.5-Pro 于 2026年4月27日 由小米 AI 部门发布，作为其 Pro 层级中的首个开放权重模型——此前的 MiMo-V2-Pro 仅提供 API，没有公开权重。权重地址： huggingface.co/XiaomiMiMo/MiMo-V2.5-Pro 在 MIT 许可证下。模型卡最后更新于 2026年4月28日，因此部署工具、社区量化版本和复现工作仍在逐日落地。

MiMo-V2.5-Pro 是一个 1.02 万亿参数的混合专家（MoE） 模型，每个 token 只激活 约 420 亿参数。MiMo 团队——由前 DeepSeek 研究员 罗福莉 带领——围绕两个思路进行设计： 混合注意力方案 ，以 6:1 的比例融合滑动窗口注意力（SWA）和全局注意力（GA）（在 128 token 窗口下，KV 缓存约减少 7×），以及 3 个轻量级多 token 预测（MTP）模块 ，在 输出速度上带来约 3× 提升 ，适用于自回归工作负载。该架构共有 70 层（1 层稠密 + 69 层 MoE），隐藏维度 6144，并原生采用 FP8 E4M3 混合精度.

Clore.ai 用户有两点需要注意。第一，这是 首个公开权重的 MiMo Pro 版本：此前的 Pro 变体只存在于托管 API 中，以及 OpenRouter 上偷偷测试的“Hunter Alpha”模型（2026年3月时间线）。第二， MIT 许可证 彻底取消了商业限制——可微调、可再分发、可作为付费端点运行，没有任何附加条件。小米的发布公告声称 V2.5-Pro 在智能体任务上优于 DeepSeek V4，但该基准目前仅由厂商发布——第三方复现尚未到来，在对外引用时不应省略这一前提。

关键规格

属性	数值
总参数量	1.02T（MoE）
激活参数量	每次前向传播约 420 亿
上下文窗口	1,000,000 tokens（100万）
精度	FP8 E4M3 混合（原生）
架构	混合 SWA + GA（6:1），70 层（1 稠密 + 69 MoE），hidden 6144
KV 缓存	滑动窗口 128，与完整 GA 相比约减少 7×
推测解码	3 个轻量级 MTP 模块，输出速度约 3×
许可证	MIT
发布日期	2026年4月27日
组织	小米 MiMo 团队（HuggingFace 上的 XiaomiMiMo）
主要工具链	SGLang（首选）、vLLM

为什么选择 MiMo-V2.5-Pro？

• 首个开放的 Pro 级 MiMo ——前代 MiMo-V2-Pro 仅提供 API，这是 Pro 权重首次公开

• 100万 token 上下文 ——可处理整个代码库、超长智能体轨迹或多文档 RAG，而无需切块

• 混合注意力 ——SWA + GA 的 6:1 组合，相比纯全局注意力可将 KV 缓存减少约 7×；长上下文依然可控

• 原生 FP8 ——无需事后量化，权重由厂商直接以 FP8 E4M3 形式提供

• MTP 推测解码 ——内置 3 个 MTP 模块，开箱即可获得约 3× 解码吞吐

• MIT 许可证 ——无商业限制，无使用场景限制

• 420 亿激活 ——尽管宣传数字是 1.02T，但推理成本仍按 420 亿稠密模型计算

• 沿革 ——首席研究员罗福莉此前在 DeepSeek 任职，且架构选择也体现出这一背景

---

需求

Clore.ai 市场上未列出多 GPU 的 80GB 级机型。 目前列出的最大配置是 4× RTX PRO 6000 Blackwell（每张 96GB，共 380GB）以及 8–11× RTX 5090（每张 32GB）。A100 / H200 / B200 容量可按 裸机 需求提供。部署前请查看 GPU 价格与可用性 。

仍然是 1T 级模型。 “420 亿激活”听起来很友好，但完整的 1.02T 权重必须放在显存中（或者被大量卸载）。原生 FP8 权重需要 约 600GB 以上显存 ，还没算激活内存和 KV 缓存。做完整上下文 FP8 时，建议至少 8×H200 或更高配置。

组件	最低配置（量化 + 卸载，未来）	推荐配置（FP8）	完整 FP8，100万 ctx
GPU 显存	约 141GB（Q4 + RAM 卸载，量化版本上线后）	8× H100 80GB（640GB）	8× H200 141GB（1,128GB）
内存	256GB	512GB	512GB
磁盘	700GB NVMe	1.5TB NVMe	2TB NVMe
CUDA	12.8+	12.8+	12.8+

硬件匹配： 若要在 100万 上下文下获得完整 FP8 并留有余量， 8×H200 是最自然的目标——那是一个 裸机 部署方案，而不是市场租赁——参见 clore.ai/rent-h200.html。8×H100 80GB 也能运行 FP8 检查点，但你需要把 --context-length 设得更低（通常为 256K）以给 KV 缓存留出空间。对于 Blackwell 级硬件，请看 clore.ai/rent-b200.html.

---

方案 A — Ollama / GGUF（量化，社区构建）

提示： 截至 2026年4月28日（发布后一天） MiMo-V2.5-Pro 的社区 GGUF 量化版本尚未发布。预计 Q4_K_M / Q5_K_M / Q6_K 构建会在 1–2 周内出现在 huggingface.co/models?search=mimo-v2.5-pro+gguf。在此之前，通过 SGLang 或 vLLM 使用 FP8 是受支持的路径。

# 一旦有了 Q4_K_M 构建
docker exec ollama ollama pull mimo-v2.5-pro:q4_K_M
docker exec ollama ollama run mimo-v2.5-pro:q4_K_M

# 或者在 GGUF 文件上直接使用 llama.cpp（发布后）
docker run --gpus all -it --rm -p 8080:8080 \\
  -v $(pwd)/models:/models \\
  ghcr.io/ggerganov/llama.cpp:server-cuda \\
  -m /models/mimo-v2.5-pro-q4_k_m.gguf \\
  --n-gpu-layers 99 --ctx-size 65536 \\
  --port 8080 --host 0.0.0.0

---

方案 B — vLLM（生产 API，推荐）

vLLM 通过以下方式支持 MiMo-V2.5-Pro： --trust-remote-code （混合注意力 + MTP 模块以仓库中的自定义代码形式提供）。请使用厂商推荐的采样默认值： temperature 1.0，top_p 0.95.

version: "3.8"
services:
  vllm:
    image: vllm/vllm-openai:latest
    ports:
      - "8000:8000"
    volumes:
      - hf_cache:/root/.cache/huggingface
    command: >
      --model XiaomiMiMo/MiMo-V2.5-Pro
      --tensor-parallel-size 8
      --quantization fp8
      --max-model-len 262144
      --gpu-memory-utilization 0.90
      --trust-remote-code
      --served-model-name mimo-v2.5-pro
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    shm_size: "16gb"

volumes:
  hf_cache:

# 测试 API（厂商推荐采样）
curl http://localhost:8000/v1/chat/completions \\
  -H "Content-Type: application/json" \\
  -d '{
    "model": "mimo-v2.5-pro",
    "messages": [
      {"role": "system", "content": "你是一个自主编码代理。"},
      {"role": "user", "content": "浏览这个 3 万行的单体仓库，并提出一个从 Express 4 迁移到 Fastify 5 的计划。"}
    ],
    "max_tokens": 8192,
    "temperature": 1.0,
    "top_p": 0.95
  }'

在 8×H100 80GB 上，将 --max-model-len 限制为 262144（256K），以给激活和 KV 缓存留出余量。在 8×H200 141GB 上，你可以轻松推到 524288 或更高；1,048,576（完整 100万）是可行的，但预填充时间会很长——在依赖前请先测试。

---

方案 C — SGLang（追求最高吞吐量时推荐）

SGLang 是 一等公民级的服务目标 ，在 MiMo-V2.5-Pro 模型卡中被直接列出。厂商在启动命令中提供了 SGLANG_ENABLE_SPEC_V2=1 ，以启用新的、感知 MTP 的推测解码路径；这正是约 3× 解码提速真正实现的地方。

docker pull lmsysorg/sglang:latest

# 逐字照搬自 HF 模型卡
SGLANG_ENABLE_SPEC_V2=1 python3 -m sglang.launch_server \\
    --model-path XiaomiMiMo/MiMo-V2.5-Pro \\
    --trust-remote-code \\
    --quantization fp8 \\
    --context-length 1048576 \\
    --host 0.0.0.0 --port 9001

对于 8×H200 上的多 GPU TP 配置，请添加 --tp-size 8 以及 --mem-fraction-static 0.88。在发送真实流量前，请用 nvidia-smi 确认 8 张卡都已被占用——如果某个 rank 资源不足，100万 上下文会非常苛刻。

---

Clore.ai GPU 推荐

配置	显存	预期性能	Clore.ai 成本
4× H100 80GB	320GB	FP8，重度卸载，最大上下文约 64K，约 10–15 tok/s	约 $4.16/小时
8× H100 80GB	640GB	完整 FP8，最大上下文约 256K，约 30–45 tok/s	约 $8.32/小时
8× H200 141GB	1,128GB	完整 FP8，最大上下文 1M，配合 MTP 约 60+ tok/s	裸机
8× B200	1,536GB	完整 FP8，最大上下文 1M，速度最快	市场定价

最佳质量： 在 FP8 检查点上使用 8× H200 141GB（裸机）并配合 SGLANG_ENABLE_SPEC_V2=1。你将获得完整的 100万 上下文窗口、MTP 推测解码，以及足够的 KV 缓存余量来支持真实智能体循环。查看 clore.ai/rent-h200.html 以获取实时可用性。

---

应用场景

• 长周期智能体 ——MiMo 团队明确针对持续工具调用进行调优。100万 上下文加上 MTP 加速意味着无需复杂切块即可进行数千轮工具交互。

• 整库分析 ——将一个 50 万 token 的单体仓库直接放入上下文，用于重构规划、依赖审计或迁移设计

• 长文档 RAG ——整本书、多年客户转录记录或一整年的聊天历史都能放进一个提示词里

• 编程 ——厂商宣称 HumanEval+ 75.6%，加上智能体姿态，使其成为自主 SWE 工作负载的候选者（可配合 SWE-agent / OpenHands）

• 研究草稿本 ——100万 上下文能容纳“把整篇论文贴进来、把相关工作贴进来，然后要求综合”的用法，而小模型通常会截断

---

基准

厂商宣称——尚无第三方复现。 下列所有数字均来自小米 2026年4月27日的公告和 HuggingFace 模型卡。该模型在 撰写时仅发布两天 ——关于智能体和长上下文基准的独立复现仍在等待中。尤其是“在智能体任务上优于 DeepSeek V4”的说法来自小米自己的说明；在未被复现前应将其视为营销表述。

基准	MiMo-V2.5-Pro（厂商）	备注
GSM8K	99.6%	数学文字题
HumanEval+	75.6%	编程（扩展）
MMLU	89.4%	通识知识
GraphWalks（100万 ctx）BFS	0.37	长上下文图遍历
GraphWalks（100万 ctx）Parents	0.62	长上下文图遍历
与 DeepSeek V4 的智能体任务	“更优”（厂商）	未验证——第三方复现待定

---

故障排查

问题	解决方案
OutOfMemoryError 在加载时	原生 FP8 仍需要约 600GB 以上显存。请使用 8×H200，或将 --context-length 在 8×H100 上降到 65536。
HuggingFace 下载缓慢	huggingface-cli download XiaomiMiMo/MiMo-V2.5-Pro --local-dir ./weights --resume-download。预计约 600GB 的 FP8。
--trust-remote-code 被拒绝	混合注意力和 MTP 以仓库中的自定义代码形式提供。该标志 是必需的 ，适用于 vLLM 和 SGLang。
SGLang 中未体现 MTP 加速	确认 SGLANG_ENABLE_SPEC_V2=1 在与 python3 -m sglang.launch_server相同的 shell 中已导出。默认路径不会激活 MTP。
推理轨迹平淡 / 质量低	使用 temperature=1.0 以及 top_p=0.95。较低的温度会削弱 MiMo 的推理表现。
在 8×H100 上 100万 上下文出现 OOM	8×H100 80GB 无法容纳 100万 token 的 KV 缓存。请将上下文上限设为 256K，或迁移到 8×H200。
预填充需要几分钟	在 100万 上下文下是预期现象。请使用 --enable-chunked-prefill （vLLM）或将更短请求批量处理以用于交互式工作负载。
GGUF / Ollama 拉取失败	截至 2026年4月28日，社区量化版本尚未发布。请等待 1–2 周，或直接使用 FP8。

---

下一步

• 前代 / 同级： MiMo-V2-Flash ——309B MoE，15B 激活，32K 上下文，更快但更小

• 厂商声称的对手： DeepSeek V4 ——100万 上下文、多模态、约 1T 参数（小米声称在智能体任务上击败的模型）

• 开放权重编程对手： GLM-5.1 ——744B MoE，40B 激活，MIT，目前在 SWE-Bench Pro 上排名第 1

• H200 容量： 按需提供裸机 ——最适合在 100万 上下文下运行完整 FP8 1T MoE

• Clore.ai 市场： clore.ai/marketplace

链接

• HuggingFace 上的 MiMo-V2.5-Pro

• 小米 MiMo HuggingFace 组织

• SGLang 仓库

• vLLM 文档