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

📅 发布时间:2026/8/27 8:38:53
MiniMax-M3 on A800:部署、Bug 修复与压测完整复盘
MiniMax-M3 on A800部署、Bug 修复与压测完整复盘文章目录MiniMax-M3 on A800部署、Bug 修复与压测完整复盘一 项目背景二 项目目标三 时间线与关键节点四 最终部署方案4.1 镜像推荐4.2 核心启动参数4.3 显存占用五 关键问题与解决5.1 A800 batch1 崩溃5.2 128K 上下文 OOM5.3 EAGLE3 是否开启六 性能数据摘要吞吐有 EAGLE3每路 60 tok/s 上限七 开源仓库八 给后来者的建议九 结语参考链接vLLM MiniMax-M3 官方博客https://vllm.ai/blog/2026-06-12-minimax-m3-vllmIssue #48603https://github.com/vllm-project/vllm/issues/48603PR #49149https://github.com/vllm-project/vllm/pull/49149mini-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仓库二 项目目标在 8×A800 上稳定部署 MiniMax-M3-MXFP8支持 128K 上下文支持工具调用、reasoning/thinking 输出压测验证并发稳定性与性能输出可复现的部署方案。三 时间线与关键节点阶段结果单请求验证通过生成、工具调用、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.0v0.25.1 补丁作为 legacy 保留四 最终部署方案4.1 镜像推荐vllm/vllm-openai:v0.26.0v0.26.0 已官方包含 #49149 修复推荐直接使用官方镜像。若因镜像策略必须停留在 v0.25.1可手动打补丁构建v0.25.1-m3patch仓库提供deploy_v0251_m3patch.sh。4.2 核心启动参数--block-size128--max-model-len131072--tensor-parallel-size8--max-num-seqs128--max-num-batched-tokens4096--gpu-memory-utilization0.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_CUDAGRAPHS04.3 显存占用项目每卡权重~58.5 GBCUDA Graph~4.1 GBKV Cache~10.2 GB合计~72.8 GB / 81.9 GB五 关键问题与解决5.1 A800 batch1 崩溃根因topk_indices_buffertoken-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_CUDAGRAPHS0。5.3 EAGLE3 是否开启低并发≤4开延迟降低 20-49%高并发≥8不开总吞吐更高。六 性能数据摘要吞吐有 EAGLE3并发吞吐 (tok/s)平均延迟183.01.54s4209.82.38s16400.04.94s128924.316.90s每路 60 tok/s 上限temp0.7≤2 并发temp0.0≤3 并发七 开源仓库mini-max-m3-mxfp8-v-llm-a800-deployment gitee仓库八 给后来者的建议不要只看单请求MoE 稀疏注意力的 bug 往往在 batch1 才暴露。显存要“精打细算”A800 80GB 对 427B MoE 来说并不宽裕每个 GB 都要争取给 KV。EAGLE3 按需开关低并发开、高并发关不要一刀切。及时跟进上游v0.26.0 已含补丁开源仓库已将其作为默认推荐能升级就升级。保留可复现脚本把所有路径、参数、环境变量脚本化换机器时少走弯路。九 结语MiniMax-M3 在 A800 上是一条“能跑但需补丁”的路径。希望这个复盘和开源仓库能帮到有同样环境的团队。系列文章《在 8×A800 上部署 MiniMax-M3-MXFP8vLLM 实战笔记》《vLLM #49149 补丁A800 上 MiniMax-M3 batch1 崩溃排查与修复》《MiniMax-M3 EAGLE3 推测解码压测分析》《MiniMax-M3 on A800部署、Bug 修复与压测完整复盘》