Alauda AI
  • 简体中文

    • MiniMax-M2.5 (W8A8)

    minimax_m2-架构模型（MiniMaxM2ForCausalLM）— 一个 256 专家 MoE（每个 token 8 个专家，无共享专家），具有 62 层全注意力（GQA 48/8 heads，head_dim 128 — 一个纯全注意力模型，不是 hybrid-KV / sliding-window 模型）以及原生 MTP head，以 W8A8（W8A8_DYNAMIC，QuaRot int8 attention + expert，无 KV quant；~230 GB 权重，71 个 shard，62 层）形式提供服务。它是 总计 230B，且每个 token 激活约 ~10B。约 ~230 GB 的权重可以放入单个 8 × 64 GB 节点中，但它已在 Ascend 910B3（64 GB/卡）跨两个节点 = 16 张卡 的条件下验证为一个聚合的 DP2 × TP=8 + EP16 服务——与 DeepSeek-V4-Flash 的 16 卡拓扑进行同类对比，其中 DP2 在偏 prefill 的基准上大约将 prefill 吞吐量翻倍。它通过 Alauda AI 的 InferNex surface 运行 vLLM-Ascend v0.23.0 release engine，并且两个基准场景都通过 MaaS gateway（API-key）入口 作为并发扫描（8 / 16 / 32）来驱动。

    不同于 DeepSeek-V4-Flash（W8A8），MiniMax-M2.5 以不带任何加速附加组件的纯聚合方式提供服务——没有 mooncake KV store，也没有 speculative decoding。这是有意采用的生产配置：因为这个模型“很快”（~10B activated + full attention + W8A8），这两个附加组件都被测出会拖慢性能（见 部署规范）。

    目录

    模型标识已验证硬件 × 技术栈模型配置部署规范部署基准结果真实 coding-agent 验证

    模型标识

    字段值
    发布方MiniMax
    架构minimax_m2（MiniMaxM2ForCausalLM）— 256 专家 MoE（8 experts/token，无共享专家）+ 62 层 全注意力（GQA 48/8，head_dim 128；非 hybrid-KV）+ 原生 MTP head；总计 230B / 激活约 ~10B
    量化W8A8（W8A8_DYNAMIC，QuaRot；int8 attention + expert，无 KV quant；~230 GB 权重，71 个 shard，62 层）；MIT license
    Context / vocab196,608（~192k，max_position_embeddings，rope_theta 5e6）/ 200,064
    模型来源（W8A8）https://www.modelscope.cn/models/Eco-Tech/MiniMax-M2.5-w8a8-QuaRot
    ModelCar（OCI Image Layout tar）http://<model-package-host>/packages/aml-models-oci/v0.1.0/MiniMax-M2.5-w8a8-QuaRot/MiniMax-M2.5-w8a8-QuaRot.oci.tar
    NOTE

    内置 MTP head 在这些权重上不可用。 配置声明了 use_mtp: true / num_mtp_modules: 3，但 QuaRot 量化的 checkpoint 不包含 MTP tensors（143,967 个 tensor 的 state dict 在 layer 61 处结束），因此 --speculative-config method=mtp 无法启动。MiniMax 唯一可用的 speculative 路径是 eagle3（一个独立的 draft model），而 eagle3 已作为该模型生产配置之外的方案进行测量——见 部署规范。

    NOTE

    W8A8 ModelCar 以 OCI Image Layout tar 的形式分发在内部包存储上，而不是公共 Docker Hub image。请将上方链接中的 <model-package-host> 替换为 Alauda 为该环境提供的包存储地址。基准测试本身使用的是已在每个节点本地 PV/PVC 上落盘的权重；下方 manifest 挂载的也是这条路径。ModelCar 只是将同一套权重重新打包，便于跨环境分发——先导入到你自己的 registry，然后重新指向 model.uri（见 Deploy 章节）。由于这个 ModelCar 超过 200 GB，oci:// storageInitializer 拉取需要额外处理临时磁盘。

    已验证硬件 × 技术栈

    平台引擎版本 / 配置状态
    Ascend 910B3 64 GB × 16，2 个节点（1 个实例，DP2 × TP=8 + EP16）vLLM-Ascendv0.23.0-openeuler（vLLM 0.23.0，release 固定）✅ 闭环、2 场景 并发扫描（8/16/32）、每档 480 次请求、0 error；纯聚合基线（无 spec decode、无 mooncake）；+ 真实 coding-agent 验证（OpenCode / Pi），全部通过 MaaS gateway
    NOTE

    v0.23.0-openeuler release engine 包含完整的 minimax_m2 技术栈（model + minimax_m2 tool-call / reasoning parsers）以及 vLLM #11505，该修复会将流式 tool-call 参数一直保留到结束的 </parameter> 之前，因此不会把尾部标签碎片拼接进命令参数中。之所以选择它而不是更早的 nightly-main-0709 快照，是为了这个 parser 修复（已在 3,123 次 tool 执行中验证，尾部污染为 0）；代价是相较 0709 的 decode 有小幅回退——见 基准结果。

    模型配置

    参数值
    Tensor parallelism (tensor-parallel-size)8
    Data parallelism (data-parallel-size)2（每个节点 1 个 rank，跨节点）
    Replicas (instances)1 个聚合服务（leader + worker = 16 张卡）
    Expert parallelism (enable-expert-parallel)on（EP16）
    max-model-len196608（agent 长上下文；基准场景 ≤ ~17.5k）
    max-num-batched-tokens16384
    max-num-seqs32
    gpu-memory-utilization0.85（官方值——长上下文，刻意未拉满）
    Quantizationascend（W8A8_DYNAMIC / QuaRot）
    Speculative decoding无（QuaRot 权重中缺少内置 MTP；eagle3 已测出不划算——见下文）
    Decode graphFULL_DECODE_ONLY（ITL ~34 ms，相比 eager 的 ~300 ms）
    Prefix caching已启用，本地（在真实 agent trace 上命中率约 ~62.6 %；agent 窗口内 Prompt-Token 命中率为 91.8–95.5 %）
    Tool calling / reasoning--tool-call-parser minimax_m2 + --enable-auto-tool-choice + --reasoning-parser minimax_m2
    典型环境VLLM_ASCEND_ENABLE_FLASHCOMM1=1。不要设置 enable_fused_mc2——它是“A3 推荐，不适用于 A2”，而 910B3 属于 A2 级别。

    部署规范

    以 agg 方式提供服务——一个单独的 DP2 × TP=8 聚合，不使用 mooncake KV store，不使用 speculative decoding。router 保持 random，cache-indexer 为关闭：单个聚合 endpoint 不需要全局 KV index 或感知 KV-cache 的 routing（与 GLM-5.2 / Qwen3-32B 的聚合范式一致）。真正带来净收益、并且该配置保留的是 FULL_DECODE_ONLY decode graph 加上引擎的本地 prefix cache。

    组件agg
    hermes-router (EPP)✅ 已启动（单 leader endpoint，random 无操作）
    Routing strategyrandom
    mooncake KV store—（已测出无收益；见下文）
    Speculative decoding (eagle3 / MTP)—（已测出无收益；见下文）
    cache-indexer / KV-cache-aware routing—（单个聚合 endpoint 不需要）
    Decode graph + local prefix cache✅（该配置保留的净收益加速项）
    NOTE

    为什么不使用 speculative decoding 和 KV store —— 因为在这个模型上两者都被测出会拖慢。 由于 MiniMax-M2.5 “很快”（只有 ~10B activated + full attention + W8A8），这两个附加组件都会造成负收益：

    • eagle3（speculative decoding）——被排除，有两条独立证据。 ① 批处理吞吐量是净亏损：场景 ① 在并发 32 时，decode 为 377 tok/s（eagle3）对比 631 tok/s（基线）（越多 speculative tokens，越差）。② 一个真实的 27k-prefill agent 请求返回 HTTP 500（engine 保持运行，但每个这类请求都会失败），而基线可以 0 error 地服务同一请求。机制上：speculation 用计算换延迟——只有在 decode 受内存带宽限制（单流）时才是净收益；一旦 batch 使计算饱和，就会变成净亏损；同时 W8A8 基座与全精度 eagle draft 也不匹配，导致 pos-0 仅约 ~44 % 的接受率（每个 draft 仅接受 0.56 个）。内置 MTP head 不可用（量化权重中没有 MTP tensors）。
    • mooncake KV store——不值得。 即使 store 完全 warm（约 ~91 % merged prefix hit），仍然是净亏损：场景 ② 在并发 16 / 32 时吞吐量分别 下降 14 % / 13 %，TTFT 在各方面都更差。MiniMax 的 prefill 快到这种程度：通过网络重新拉取 KV 的成本都大于在本地重新计算——这与 DeepSeek 相反，后者较慢的 prefill 使 store 成为明确收益项。在真实 agent trace 上，本地 prefix cache 已经覆盖 62.6 %，store 只是在其基础上再增加约 ~3.6 %。

    部署

    自包含的 InferNex manifest（engine 内联在 LLMInferenceService 的 leader + worker templates + hermes-router preset 中，跨两个节点的 DP2 × TP=8，纯 agg 基线）：

    规格文件
    agg, DP2 × TP=8minimax-m2.5-w8a8-agg-llmisvc.yaml
    base=https://raw.githubusercontent.com/alauda/aml-docs/master/docs/en/plan/validated_models/assets/minimax-m2.5-w8a8

# 1. Stage the ~230 GB weights on a node-local directory on BOTH nodes (byte-identical),
#    then edit the manifest: set the namespace, pin the two hostPath PVs to your node
#    hostnames (<node-0> / <node-1>) and weights path, and set the image tag (match your
#    CANN / host driver). Then apply — the engine mounts the on-node weights at /mnt/models
#    (the storageInitializer is off, so there is no 230 GB pull).
kubectl apply -f $base/minimax-m2.5-w8a8-agg-llmisvc.yaml

#    Cross-environment alternative — import the OCI ModelCar tar into your own registry
#    once (skopeo does the multi-arch amd64+arm64 push in one go), then set the manifest
#    model.uri to oci://<your-registry>/modelcar-minimax-m2.5-w8a8-quarot:v0.1.0:
#      curl -sO http://<model-package-host>/packages/aml-models-oci/v0.1.0/MiniMax-M2.5-w8a8-QuaRot/MiniMax-M2.5-w8a8-QuaRot.oci.tar
#      skopeo copy --all \
#        oci-archive:MiniMax-M2.5-w8a8-QuaRot.oci.tar:v0.1.0 \
#        docker://<your-registry>/modelcar-minimax-m2.5-w8a8-quarot:v0.1.0
#    (This ModelCar is >200 GB — keep storageInitializer.enabled:false and add an init
#    container that extracts the pulled layout to tmpfs.)

# Internal KServe ingress (no auth):
curl -s http://<gateway>/<namespace>/minimax-m25-w8a8-agg/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"minimax-m2.5-w8a8","messages":[{"role":"user","content":"hello"}]}'

# Product MaaS gateway (OpenAI-compatible, API-key auth + token rate limiting):
curl -s http://<maas-gateway>/v1/chat/completions \
  -H "Authorization: Bearer $MAAS_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"minimax-m2.5-w8a8","messages":[{"role":"user","content":"hello"}]}'

    基准结果

    闭环 aiperf 0.7.0，DP2 × TP=8（16 × 910B3 64 GB），通过产品 MaaS gateway 驱动，在生产 v0.23.0-openeuler engine 上运行。并发扫描为 8 / 16 / 32，每档 480 个请求（所有档位 0 error / 0 mismatch）。TTFT / E2E 以秒计，ITL 以毫秒计；decode = 仅输出 tok/s（实测），TPS = 总 tokens/s（输入 + 输出，计算得出；prefill 主导）。输出长度固定为 128 tokens。

    场景 ① — 固定长度 system-prompt 复用（ISL ~8k / OSL 128）

    并发TTFT 平均值（s）ITL 平均值（ms）E2E 平均值（s）Decode（tok/s）TPS（in+out）
    81.1733.55.418912,004
    161.3536.25.934421,967
    321.4445.67.256436,012

    场景 ② — 多轮对话，长上下文（ISL ~17.5k / OSL 128）

    并发TTFT 平均值（s）ITL 平均值（ms）E2E 平均值（s）Decode（tok/s）TPS（in+out）
    82.9544.08.512017,001
    163.8156.711.018626,225
    325.4287.916.624734,906
    NOTE

    引擎选择——v0.23.0 与更早的 nightly-main-0709。 在相同硬件 / 配置 / caliber 下重新测试后，v0.23.0 相比 0709 表现出小幅 decode 回退（decode 吞吐量 -3…11 %，ITL +5…18 %，且随并发增大而加剧；例如场景 ① 并发 32 时 decode 由 631 → 564 tok/s），而 TTFT（prefill）持平或更好。之所以接受该回退，是为了换取一个release 固定（不漂移）的 tag、统一的 minimax_m2 parser，以及 #11505 的 streaming tool-call 修复。0709 image 仍保留在节点上，作为对 decode 吞吐敏感的交付场景的回退方案。

    配置决策——eagle3 和 mooncake 均不划算（基于基线测量）

    配置（场景 · 并发）基线eagle3mooncake store
    S① conc 32 — decode (tok/s)631377（1-tok）/ 300（3-tok）—
    S① conc 32 — ITL (ms)39.575.7 / 97.7—
    S② conc 16 — TPS (in+out)27,792—23,902（−14 %）
    S② conc 32 — TPS (in+out)37,458—32,421（−13 %）
    真实 27k-prefill agent 请求0 errorHTTP 500—

    → 纯 agg 基线在所有维度上都获胜；这两个加速层在这个快模型上都适得其反。（eagle3 / mooncake 的 A/B 测试是在更早的 0709 基线上做的，早于 v0.23.0 的重新测试；但结论在两个 engine 上都成立。）

    NOTE

    如何解读这些数据。 每个档位都完成了 480/480，0 error，0 输出不匹配。随着并发提升，系统吞吐量（decode / TPS）上升（次线性、逐渐饱和），同时尾延迟（TTFT / ITL / E2E）也会上升——这是更多 in-flight requests 带来的排队成本。TPS 是**总 token（输入 + 输出）**口径，并且是 prefill 主导（ISL 8k / 17.5k，OSL 128）；仅 decode 的输出速率则是单独的“Decode”列。

    这些数字不能直接与本指南中的其他模型对比：这是一轮并发扫描（而不是 Qwen 模型使用的固定并发 4 运行），运行在 910B3 64 GB 卡上，采用 16 卡 DP2 × TP=8 拓扑。请将其视为这个特定大型 MoE 部署的运行边界，而不是跨模型排序。

    真实 coding-agent 验证

    除了合成的 aiperf 扫描之外，还通过 MaaS gateway 将 MiniMax-M2.5 作为真实 coding agent进行驱动。Envoy AI Gateway v0.6.0 将 vLLM Chat Completions 流通过 OpenAI→OpenAI 原样透传，因此 minimax_m2 parser 的流式 reasoning_content 和结构化 tool call 能完整到达客户端。两个 agent（OpenCode 1.17.18 和 Pi 0.80.6）在并发 1 / 8 / 32 下运行了同一套固定的 14 任务 Terminal-Bench 集合（分别运行 14 / 14 / 42 次），并由客观 verifier 评分。

    Agent通过数（并发 1 / 8 / 32）峰值正确任务吞吐量
    OpenCode 1.17.186 / 14 · 4 / 14 · 14 / 4224.65 tasks/hr
    Pi 0.80.67 / 14 · 8 / 14 · 18 / 4234.98 tasks/hr
    • 旧的 </parameter> 命令尾部污染已修复： 在 3,123 次真实 tool 执行中，没有任何一次执行参数包含闭合标签碎片（这也是 engine 固定到 v0.23.0 / #11505 的原因）。
    • 在并发 32 下链路很快且未饱和： 0 waiting requests，KV-cache 峰值 14.6 %，16 卡 AICore 平均/p95 为 17.2 % / 34 %，vLLM 0 error / abort / preemption——因此 32 是已验证的下界，而不是容量上限。
    • 复杂链路上仍存在残余 parser 风险： OpenCode 在 10 / 70 次试验中把原始 tool XML 误解析为文本/reasoning；Pi 在 2 / 70 次试验中合并了相邻 tool 边界。因此结论是可用于 POC，但尚未宣称生产稳定，而且在这个模型上 Pi 的表现优于这两个 agent。