MiniMax M2.7（229B MoE 编程）

在 Clore.ai 上部署 MiniMax M2.7（229B MoE）——支撑 MiniMax 编程智能体推进的开源自托管发布，支持在 H100/H200 上进行 FP8 单机部署

状态（2026年4月）： MiniMax M2.7 已于 2026年4月9日 由 MiniMaxAI 发布到 HuggingFace，并在三周内达到 49.6 万次下载 ——按采用量来看，这是我们 4 月更新中规模最大的开权重发布。权重地址为 huggingface.co/MiniMaxAI/MiniMax-M2.7 采用 MiniMax 自定义许可证 (许可证：其他）。它 不是 Apache/MIT —— 请在 LICENSE 之前阅读，在任何商业部署前都要先看。

更正： 我们模型索引的早期版本曾把 M2.7 列为仅 API 可用的专有模型。这在 2026 年 4 月 9 日之前是错误的——权重已经公开。本文档已替换该条目。

MiniMax M2.7 是一个 2290 亿参数的混合专家（MoE） 模型（256 个专家，每个 token 激活 8 个），也是 MiniMax M2 系列的最新成员——该系列围绕 自我演化 / RL 驱动的后训练 以及 智能体式编码 工作负载构建。2.7 版本是 MiniMax 托管编码智能体的公开、可自部署对应版本，并被 MiniMax 定位为在智能体基准上可与 Claude Sonnet 4.5 竞争，同时在其中少数项目上接近 Claude Opus 4.6。

有趣的架构细节是 交错思考 （在 M2.1 中引入，并在 2.5/2.7 中持续改进）：模型在多轮工具调用中交替进行 <think> 推理块与正常生成，因此思维链会在函数调用往返之间持续存在，而不会在每一轮被丢弃。这正是它对长周期智能体有吸引力的原因——每次你触发一个 tool_use 边界时，推理轨迹都不会重置。

对 Clore.ai 用户来说，实际消息是 M2.7 在官方仓库中提供了一个 FP8（float8_e4m3fn）检查点 。这使得单节点部署在 4× H100 80GB 或 2× H200 141GB 上成为可能——不需要 H200 octets 或 16 卡机架。如果你一直在跑 GLM-5.1 ，并且想在你的智能体栈里再加入一个带不同偏置特征的开权重模型，那么它就是最适合搭配的那个。

关键规格

属性	数值
总参数量	229B（MoE，256 个专家）
每个 Token 激活专家数	256 个中的 8 个
激活参数量	未正式公布 ——见模型卡。M2 系列历史上约为 10B 激活；公开引用前请核实。
隐藏层大小 / 层数	3,072 / 62
注意力	48 个头，8 个 KV（GQA）
上下文窗口	204,800 个 token（20 万）
张量类型	F32、BF16、F8_E4M3
MTP	已启用多 Token 预测（3 个 MTP 模块）
许可证	MiniMax 自定义——默认禁止商业用途
发布日期	2026年4月9日
HF 下载量（3 周）	约 49.6 万
推荐采样参数	temperature=1.0, top_p=0.95, top_k=40
主要工具链	vLLM、SGLang、Transformers、KTransformers、MLX-LM

为什么选择 MiniMax M2.7？

• 229B 的开权重 ——是最大的“真正”开权重编码模型，而且在 FP8 下仍能装进单个 4×H100 节点

• 交错思考 —— <think> 块会在工具调用轮次之间保留，这对 SWE 风格智能体非常有用

• 多语言编码侧重 —— MiniMax 强调 Rust、Go、Java、Kotlin、Swift 和 TypeScript 的强表现，而不只是 Python

• 采用信号 —— 3 周内 49.6 万次下载，是我们追踪到的 2026 年 4 月所有开权重发布中社区采用最强的一次

• MTP 支持 —— 通过多 Token 预测模块内置了推测解码，在 H100/H200 上可转化为真实吞吐量

• 托管兜底 —— 如果你的工作负载超出单节点，MiniMax 的托管端点也存在；你无需在架构阶段二选一

---

需求

229B 仍然是 229B。 BF16 权重约为 460GB。FP8 检查点大约只有一半——约 230GB——这就是单节点部署可行的原因。社区 INT4 量化可降到 120GB 以下，但官方不支持。

组件	爱好者方案（INT4 GGUF，卸载）	推荐方案（FP8 单节点）	完整 BF16
GPU 显存	24–48GB GPU + 128GB 以上内存卸载	4× H100 80GB 或 2× H200 141GB	8× H100 80GB / 4× H200 141GB
总显存	约 48GB GPU + 卸载	320GB / 282GB	640GB / 564GB
内存	128GB	256GB	512GB
磁盘	200GB NVMe	400GB NVMe	600GB NVMe
CUDA	12.0+	12.4+	12.4+

Clore.ai 选择： 位于 2× H200 上的 FP8 检查点是最干净的部署目标——张量并行切分最少、NCCL 跳数更少，而且 20 万上下文的数学运算完全没问题。 4× H100 如果 H200 库存紧张，则是更便宜的替代方案。

---

方案 A —— Ollama / GGUF（量化）

仅限社区量化版本。 MiniMax 不发布 M2.7 的官方 GGUF 权重。社区的 Q4/Q5 构建通常在发布后 1–2 周出现——搜索 huggingface.co/models?search=minimax-m2.7+gguf 并核实上传者。Q4 以下的 MoE 量化质量差异较大。

# 一旦社区版 Q4_K_M 构建上线（先检查 HuggingFace）
docker exec ollama ollama pull minimax-m2.7:q4_K_M
docker exec ollama ollama run minimax-m2.7:q4_K_M

# 或者直接使用 llama.cpp 运行已下载的 GGUF
docker run --gpus all -it --rm -p 8080:8080 \
  -v $(pwd)/models:/models \
  ghcr.io/ggerganov/llama.cpp:server-cuda \
  -m /models/minimax-m2.7-q4_k_m.gguf \
  --n-gpu-layers 80 --ctx-size 32768 \
  --temp 1.0 --top-p 0.95 --top-k 40 \
  --port 8080 --host 0.0.0.0

仅限爱好者用途。真实工作负载请使用 vLLM 或 SGLang 运行 FP8 检查点。

---

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

vLLM 是首选的服务化目标。官方 FP8 检查点就是应该拉取的那个——质量与 BF16 相同，显存约为一半。

docker-compose.yml — 4× H100 80GB

version: "3.8"
services:
  vllm:
    image: vllm/vllm-openai:latest
    ports:
      - "8000:8000"
    volumes:
      - hf_cache:/root/.cache/huggingface
    command: >
      --model MiniMaxAI/MiniMax-M2.7
      --quantization fp8
      --tensor-parallel-size 4
      --max-model-len 65536
      --gpu-memory-utilization 0.88
      --enable-auto-tool-choice
      --tool-call-parser hermes
      --served-model-name minimax-m2.7
      --trust-remote-code
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    shm_size: "16gb"

volumes:
  hf_cache:

docker-compose.yml — 2× H200 141GB

将 --tensor-parallel-size 降到 2，并提高 --max-model-len 以利用余量：

    command: >
      --model MiniMaxAI/MiniMax-M2.7
      --quantization fp8
      --tensor-parallel-size 2
      --max-model-len 131072
      --gpu-memory-utilization 0.90
      --enable-auto-tool-choice
      --tool-call-parser hermes
      --enable-chunked-prefill
      --served-model-name minimax-m2.7
      --trust-remote-code

冒烟测试

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "minimax-m2.7",
    "messages": [
      {"role": "system", "content": "你是一名高级工程师。在跨工具调用进行推理时，请使用交错思考。"},
      {"role": "user", "content": "审计这个 Rust async 处理器的 tokio 取消安全性：..."}
    ],
    "max_tokens": 4096,
    "temperature": 1.0,
    "top_p": 0.95
  }'

不要把 temperature 降到 1.0 以下。 MiniMax 推荐的采样参数是 T=1.0、top_p=0.95、top_k=40。贪婪解码会悄悄破坏 <think> 多轮工具调用中的交错机制。

---

方案 C —— SGLang

SGLang 的 MoE 调度器在 Hopper 上与 vLLM 具有竞争力，并且由于 EAGLE 推测解码与 M2.7 的 MTP 模块叠加，在长上下文编码补全上经常更胜一筹。

docker pull lmsysorg/sglang:latest

python3 -m sglang.launch_server \
  --model-path MiniMaxAI/MiniMax-M2.7 \
  --quantization fp8 \
  --tp-size 4 \
  --mem-fraction-static 0.88 \
  --context-length 65536 \
  --enable-mixed-chunk \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --served-model-name minimax-m2.7 \
  --trust-remote-code

在长篇智能体轨迹上，预计比原生 vLLM 提升约 1.5–2× 吞吐。将 --tp-size 在 H200 上降到 2。

---

Clore.ai GPU 推荐

配置	显存	预期性能	Clore.ai 成本
1× RTX 4090 24GB + 内存卸载	24GB + 128GB	INT4 爱好者方案，约 5–10 tok/s	约 $1–2/天
4× A100 80GB	320GB	BF16 分片，约 15–25 tok/s	约 $15–22/天
4× H100 80GB（FP8）	320GB	FP8 生产方案，约 40–60 tok/s	约 $20–28/天
2× H200 141GB（FP8）	282GB	FP8 生产方案，约 50–70 tok/s，完整 20 万上下文	约 $18–26/天
8× H100 80GB	640GB	完整 BF16，约 80+ tok/s	约 $40–55/天

最佳性价比： 配 FP8 检查点的 2× H200。与 4× H100 属于同一吞吐等级，但张量并行跳数减半，在市场上按天计通常更便宜，而且你仍保留足够的显存余量以支持完整的 20 万上下文。

在这里租这些机器：

• 租用 H200 GPU ——推荐用于 2× H200 FP8 部署

• 租用 H100 GPU ——用于 4× H100 FP8 部署

• 租用 A100 80GB —— BF16 多 GPU 兜底

• 租用 RTX 4090 ——仅限 INT4 爱好者用途

• 市场 ——完整库存，按需和现货竞价

---

使用场景

• 多语言 SWE 智能体 —— Rust、Go、Java、Kotlin、Swift 和 TypeScript 都是一级支持，而不只是 Python/JS

• 长周期工具调用循环 —— 交错思考让推理轨迹在数百次 tool_use 往返

• 代码库审计 —— 20 万上下文可将中型服务及其测试一次性放入一个提示词中

• 重构流水线 —— 通过 MTP 模块在多次文件编辑中保持持续正确性

• 多智能体编排 —— 将 M2.7 作为规划器，与更小的模型（Qwen3.5、GLM-4.7-Flash）作为执行者配对

• Claude Sonnet/Opus 的自托管替代品 用于非商业编码研究——但 请先阅读许可证

---

基准测试

厂商宣称——请独立验证。 下面的数字来自 MiniMax 2026 年 4 月 9 日的发布说明。独立复现仍在持续出现。

基准	MiniMax M2.7	Claude Sonnet 4.5（厂商参考）	Claude Opus 4.6（厂商参考）	GPT-5.3-Codex
SWE-Pro	56.22%	~55%	~57.3%	56.2%
VIBE-Pro	55.6%	——	~57%	——
Terminal Bench 2	57.0%	——	——	——
GDPval-AA（ELO）	1495	——	——	——

MiniMax 的说法是：M2.7 在他们关心的智能体编码套件上与 Claude Sonnet 4.5 持平或更优，并在 SWE-Pro / VIBE-Pro 上与 Claude Opus 4.6 的差距仅有几分。请将其视为方向性信号，而不是最终排名——每一次发布，封闭前沿模型的差距都在缩小。

---

MiniMax M2 系列

版本	发布	架构重点	适用推荐
M2	2025 年 10 月	初始 229B MoE 发布，RL 调优编码	参考 / 历史版本
M2.1	2025 年 12 月	交错思考 引入	适合智能体运行的最早版本
M2.5	2026 年 2 月	自我演化 RL 后训练，更长上下文	磁盘受限时的稳健编码模型
M2.7	2026 年 4 月 9 日	改进的多语言编码、MTP、官方 FP8	默认选择——就用这个

如果你是从零开始，跳过更早版本，直接上 M2.7。架构差异会累积，而且 FP8 的使用体验明显更好。

---

故障排查

问题	解决方案
OutOfMemoryError 在 FP8 加载时	需要约 230GB 显存。使用 4× H100 80GB 或 2× H200 141GB。先将 --max-model-len 降到 32768。
HuggingFace 下载速度慢	huggingface-cli download MiniMaxAI/MiniMax-M2.7 --local-dir ./weights --resume-download。预计约 230GB FP8 / 约 460GB BF16。
工具调用被静默丢弃	在 vLLM 中设置 --enable-auto-tool-choice --tool-call-parser hermes 。M2.7 使用 Hermes 风格的工具标签。
<think> blocks 为空或乱码	采样必须是 temperature=1.0, top_p=0.95, top_k=40。贪婪解码会破坏交错思考。
MTP 错误 / 形状不匹配	将 vLLM 更新到最新稳定版；MTP 支持是后期加入的，旧版本不包含这些模块。
H100 上 20 万上下文 OOM	使用 --enable-chunked-prefill 并从 --max-model-len 65536开始。完整 20 万上下文在实际中需要 H200。
许可证混淆	默认 = 非商业用途。在任何付费产品使用前，发送邮件至 [e-mail] ，主题为“ M2.7 licensing ”。

---

下一步

• 音频同系列： MiniMax Speech ——同一厂商，音频/语音生成

• 开源许可证替代方案： GLM-5.1 ——744B / 40B 激活，MIT 许可证，SWE-Bench Pro 顶级

• 超大上下文替代方案： DeepSeek V4 ——100 万上下文，多模态

• 更便宜的智能体方案： GLM-4.7 Flash ——可运行于单张 H100，MIT

• Clore.ai 市场： clore.ai/marketplace ——来自现货市场的 H100/H200/A100

链接

• HuggingFace 上的 MiniMax M2.7

• MiniMax M2.7 许可证 ——商业使用前请先阅读

• MiniMax 平台

• vLLM 文档

• SGLang 仓库

• KTransformers