MiniMax-M3 on A800：部署、Bug 修复与压测完整复盘

MiniMax-M3 on A800：部署、Bug 修复与压测完整复盘

文章目录

• [MiniMax-M3 on A800：部署、Bug 修复与压测完整复盘](#MiniMax-M3 on A800：部署、Bug 修复与压测完整复盘)
• • [一 项目背景](#一 项目背景)
  • [二 项目目标](#二 项目目标)
  • [三 时间线与关键节点](#三 时间线与关键节点)
  • [四 最终部署方案](#四 最终部署方案)
  • • [4.1 镜像（推荐）](#4.1 镜像（推荐）)
    • [4.2 核心启动参数](#4.2 核心启动参数)
    • [4.3 显存占用](#4.3 显存占用)
  • [五 关键问题与解决](#五 关键问题与解决)
  • • [5.1 A800 batch>1 崩溃](#5.1 A800 batch>1 崩溃)
    • [5.2 128K 上下文 OOM](#5.2 128K 上下文 OOM)
    • [5.3 EAGLE3 是否开启](#5.3 EAGLE3 是否开启)
  • [六 性能数据摘要](#六 性能数据摘要)
  • • [吞吐（有 EAGLE3）](#吞吐（有 EAGLE3）)
    • [每路 60 tok/s 上限](#每路 60 tok/s 上限)
  • [七 开源仓库](#七 开源仓库)
  • [八 给后来者的建议](#八 给后来者的建议)
  • [九 结语](#九 结语)

参考链接：

• vLLM MiniMax-M3 官方博客：https://vllm.ai/blog/2026-06-12-minimax-m3-vllm
• Issue #48603：https://github.com/vllm-project/vllm/issues/48603
• PR #49149：https://github.com/vllm-project/vllm/pull/49149
• mini-max-m3-mxfp8-v-llm-a800-deployment gitee仓库

一 项目背景

• 最近负责把 MiniMax-M3-MXFP8 部署到一台 8×A800 80GB 的机器上，用于内部推理服务。整个过程比预期曲折：单请求跑通很简单，但一上并发就崩；定位后发现是 vLLM 在 Ampere 回退路径上的布局 bug；打完补丁后又做了 EAGLE3 压测，最终才确定生产配置。本文把整个项目复盘成一篇完整笔记，并已经把相关脚本和文档开源到 Gitee，方便有同样硬件环境的团队参考。
• mini-max-m3-mxfp8-v-llm-a800-deployment gitee仓库

二 项目目标

1. 在 8×A800 上稳定部署 MiniMax-M3-MXFP8；
2. 支持 128K 上下文；
3. 支持工具调用、reasoning/thinking 输出；
4. 压测验证并发稳定性与性能；
5. 输出可复现的部署方案。

三 时间线与关键节点

阶段	结果
单请求验证	通过，生成、工具调用、thinking 正常
并发 2 压测	崩溃，CUDA illegal memory access
排查	排除 MoE/CUDA Graph/EAGLE3，定位到 vLLM #48603
修复	手动应用 PR #49149 补丁，构建 patched 镜像
复测	并发 1/2/4/8/16 全通过，0 失败
EAGLE3 压测	低并发提速 20-49%，高并发无收益
文档 & 开源	整理脚本、文档、博客，发布到 Gitee
仓库升级	默认部署脚本升级到 v0.26.0+，v0.25.1 补丁作为 legacy 保留

四 最终部署方案

4.1 镜像（推荐）

vllm/vllm-openai:v0.26.0

• v0.26.0+ 已官方包含 #49149 修复，推荐直接使用官方镜像。若因镜像策略必须停留在 v0.25.1，可手动打补丁构建 v0.25.1-m3patch，仓库提供 deploy_v0251_m3patch.sh。

4.2 核心启动参数

--block-size 128
--max-model-len 131072
--tensor-parallel-size 8
--max-num-seqs 128
--max-num-batched-tokens 4096
--gpu-memory-utilization 0.99
--served-model-name MiniMax-M3-MXFP8
--tool-call-parser minimax_m3
--enable-auto-tool-choice
--reasoning-parser minimax_m3
--default-chat-template-kwargs '{"thinking_mode": "enabled"}'
--speculative-config '{"method":"eagle3","model":"/models/MiniMax-M3-EAGLE3","num_speculative_tokens":3,"attention_backend":"FLASH_ATTN"}'

环境变量：

VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS=0

4.3 显存占用

项目	每卡
权重	~58.5 GB
CUDA Graph	~4.1 GB
KV Cache	~10.2 GB
合计	~72.8 GB / 81.9 GB

五 关键问题与解决

5.1 A800 batch>1 崩溃

• 根因 ：topk_indices_buffer token-major [T,H,K] 与 Triton 切片 head-major [H,T,K] 不一致，越界写显存。
• 修复：PR #49149，在 Triton 边界做 transpose。
• 经验 ：单请求正常不等于部署成功，一定要做并发验证。

5.2 128K 上下文 OOM

• 根因：vLLM 默认会预估算 CUDA Graph 显存，导致 KV 预算不足。
• 修复 ：VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS=0。

5.3 EAGLE3 是否开启

• 低并发（≤4）：开，延迟降低 20-49%；
• 高并发（≥8）：不开，总吞吐更高。

六 性能数据摘要

吞吐（有 EAGLE3）

并发	吞吐 (tok/s)	平均延迟
1	83.0	1.54s
4	209.8	2.38s
16	400.0	4.94s
128	924.3	16.90s

每路 60 tok/s 上限

• temp=0.7：≤2 并发
• temp=0.0：≤3 并发

七 开源仓库

• mini-max-m3-mxfp8-v-llm-a800-deployment gitee仓库

八 给后来者的建议

1. 不要只看单请求：MoE + 稀疏注意力的 bug 往往在 batch>1 才暴露。
2. 显存要"精打细算"：A800 80GB 对 427B MoE 来说并不宽裕，每个 GB 都要争取给 KV。
3. EAGLE3 按需开关：低并发开、高并发关，不要一刀切。
4. 及时跟进上游：v0.26.0+ 已含补丁，开源仓库已将其作为默认推荐，能升级就升级。
5. 保留可复现脚本：把所有路径、参数、环境变量脚本化，换机器时少走弯路。

九 结语

• MiniMax-M3 在 A800 上是一条"能跑但需补丁"的路径。希望这个复盘和开源仓库能帮到有同样环境的团队。

系列文章：

1. 《在 8×A800 上部署 MiniMax-M3-MXFP8：vLLM 实战笔记》
2. 《vLLM #49149 补丁：A800 上 MiniMax-M3 batch>1 崩溃排查与修复》
3. 《MiniMax-M3 EAGLE3 推测解码压测分析》
4. 《MiniMax-M3 on A800：部署、Bug 修复与压测完整复盘》