1. 8×A800 跑 MiniMax-M3-MXFP8先搞清楚它到底吃多少显存MiniMax-M3 是个 MoE 大模型总参数量 427B、激活参数 26B还带原生多模态能力。官方在 vLLM 发布博客里重点讲的是 Hopper/Blackwell 上的性能表现但现实里很多团队手上就是 A800SM80集群8 卡 80GB PCIe、两两 NVLink 互联。这套硬件能不能把 MiniMax-M3-MXFP8 跑起来、128K 上下文能不能开、张量并行怎么配是这篇要解决的问题。先说结论能跑但配置要比 H100 更“抠”显存。核心就三件事——张量并行必须 8 卡、block-size 必须 128、关掉 CUDA Graph 预留把显存让给 KV Cache。这三条任何一条没做对要么起不来要么 128K 直接 OOM。适合谁看手上有 8×A800 或类似 SM80 多卡机器、想用 vLLM 部署 MiniMax-M3-MXFP8、需要 OpenAI 兼容接口对外服务的同学。下面从模型准备、启动脚本、显存预算、参数解释到接口验证一步步给可复制的命令。2. 部署前的前置准备模型、镜像、环境变量模型文件很大MiniMax-M3-MXFP8 是 31 个分片、约 414GB草稿模型 MiniMax-M3-EAGLE3 约 6.5GBBF16。建议提前放到本地高速存储或 NFS别等 docker run 的时候再拉不然卡在下载上很浪费时间。镜像方面推荐直接用vllm/vllm-openai:v0.26.0。原因是 v0.26.0 已经官方包含了 PR #49149 的 A800 batch1 修复——这个 bug 在 v0.25.1 上会导致并发 ≥2 时崩溃。如果你的内部镜像策略必须停在 v0.25.1那就得手动打补丁后面会提。先把环境变量设好后面脚本直接引用export MODEL_DIR/path/to/MiniMax-M3-MXFP8 export EAGLE3_DIR/path/to/MiniMax-M3-EAGLE3 export HF_CACHE$HOME/.cache/huggingface export PORT8001这里MODEL_DIR和EAGLE3_DIR指向你实际存放模型分片的目录HF_CACHE给 HuggingFace 缓存用PORT是宿主机映射端口。这几个变量在启动脚本里都会用到先 export 好省得改脚本。注意模型分片目录里应该有 config.json、tokenizer 相关文件和 31 个 safetensors 分片缺一个 vLLM 加载都会报错。启动前用ls $MODEL_DIR确认一下分片数量。3. 可复制的 vLLM 启动脚本与张量并行配置核心思路写在前面必须--tensor-parallel-size 8模型要求 8 卡张量并行--block-size 128必须和 MSA 稀疏注意力块大小一致128K 上下文要配合VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0否则 KV 预算不够。同时开启 EAGLE3 推测解码、工具调用和 reasoning parser。把下面内容保存为deploy.sh#!/usr/bin/env bash set -euo pipefail MODEL_DIR${MODEL_DIR:-/path/to/MiniMax-M3-MXFP8} EAGLE3_DIR${EAGLE3_DIR:-/path/to/MiniMax-M3-EAGLE3} HF_CACHE${HF_CACHE:-$HOME/.cache/huggingface} PORT${PORT:-8001} CONTAINERminimax-m3-mxfp8 IMAGEvllm/vllm-openai:v0.26.0 # v0.26.0 已含 #49149 修复 docker rm -f $CONTAINER 2/dev/null || true docker run -d \ --name $CONTAINER \ --gpus all \ --shm-size16g \ -p ${PORT}:8000 \ -e HF_ENDPOINT${HF_ENDPOINT:-https://huggingface.co} \ -e VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0 \ -v $MODEL_DIR:/models/MiniMax-M3-MXFP8 \ -v $EAGLE3_DIR:/models/MiniMax-M3-EAGLE3 \ -v $HF_CACHE:/root/.cache/huggingface \ $IMAGE \ /models/MiniMax-M3-MXFP8 \ --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}执行bash deploy.sh然后写一个轮询脚本watch_ready.sh等/health返回就绪#!/usr/bin/env bash set -euo pipefail PORT${PORT:-8001} until curl -sf http://localhost:${PORT}/health /dev/null; do echo waiting for vLLM ready... sleep 10 done echo vLLM is ready on port ${PORT}bash watch_ready.sh如果内部镜像策略限制只能用 v0.25.1需要手动应用 PR #49149 补丁并构建 patched 镜像。开源仓库里提供了patch/m3_topk_fix.patch和patch/Dockerfile并单独给了deploy_v0251_m3patch.sh直接跑那个脚本即可。4. 显存预算拆解为什么 0.99 和关 CUDA Graph 是必须的很多人第一次跑会在 128K 上下文时 OOM问题就出在显存预算上。下面这张表是每卡的占用估算占用项每卡大约权重~58.5 GB414GB ÷ 8Marlin MXFP8 重打包后峰值CUDA Graph~4.1 GBKV Cache~10.2 GB128K EAGLE3 配置合计~72.8 GB / 81.9 GB8 卡总显存 640GB权重占约 470GB剩余约 170GB 给 KV。关掉 CUDA graph 预分配后每卡 KV 约 10.2GB能支持 128K 上下文。如果不关128K 下可用 KV 只有 4.65GB直接 OOM。所以VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0这个环境变量不是可选项是 128K 场景的必选项。--gpu-memory-utilization 0.99也是同理——权重太大设 0.95 时 KV 预算会变成负数服务根本起不来。关键参数对照表参数作用--tensor-parallel-size 8必须 8 卡 TP--block-size 128必须匹配 MSA 块大小--max-model-len 131072128K 上下文VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0不预留 CUDA Graph 内存省给 KV--gpu-memory-utilization 0.99权重太大0.95 时 KV 预算为负--enforce-eager不要加默认 CUDA Graph 快得多--moe-backend triton不需要默认 Marlin 即可注意--enforce-eager千万别加。有人为了省显存加了这个结果吞吐掉一大截而真正该省的是 CUDA Graph 的预分配不是整个 CUDA Graph。5. 接口连通性与推理结果验证服务跑起来后是 OpenAI 兼容接口。先确认模型列表curl http://localhost:8001/v1/models返回里应该能看到MiniMax-M3-MXFP8。然后发一个 chat 请求验证推理curl http://localhost:8001/v1/chat/completions \ -H Content-Type: application/json \ -d { model: MiniMax-M3-MXFP8, messages: [{role: user, content: 你好请介绍一下自己}], max_tokens: 128 }如果返回里有正常的choices[0].message.content说明推理链路通了。支持的路由包括/v1/chat/completions、/v1/responses、/v1/messagesAnthropic 协议、/v1/completions等。首次请求会特别慢因为 Triton JIT 编译需要 10–60 秒。建议先 warmup 一次再压测不然你会以为服务卡死了。warmup 就是发一个简单请求等它返回之后并发请求就正常了。如果你需要长期跑编码任务或 Agent 场景可以考虑用 Coding Plan 来管理调用配额和模型路由比裸调接口省心。验证模型本身能力的话模型对话页面可以直接对比不同模型的输出。6. 本篇常见错误排查128K OOM先检查VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0是否设置。没设的话 CUDA Graph 会吃掉 4GB 多KV 预算不够。--attention_config.indexer_kv_dtype fp8报错A800 不要加这个参数。FP8 indexer 仅 Blackwell 支持SM80 上加了会直接失败。首次请求极慢Triton JIT 编译需 10–60 秒属于正常现象。先 warmup 一次再压测别在第一次请求就判定服务有问题。并发 ≥2 崩溃这是 A800 上 v0.25.1 的已知 bugv0.26.0 已修复。检查你的镜像版本是否 ≥ v0.26.0。如果因为内部策略只能用 v0.25.1参考开源仓库的补丁方案手动修复。服务起不来、日志报显存不足确认--gpu-memory-utilization是 0.99 而不是 0.95同时确认 8 张卡都被--gpus all正确挂载。用nvidia-smi看容器内是否能看到 8 张 A800。模型加载报分片缺失检查$MODEL_DIR下 31 个分片是否完整config.json里的num_hidden_layers和分片索引是否对得上。7. 接入与后续把服务接到你的应用里服务起来之后对外就是一个 OpenAI 兼容端点。如果你要在自己的应用里调用需要生成 API Key 并配置接入地址。API Key 在控制台的 API Keys 页面创建接入文档里有各语言 SDK 的配置示例。接入时 base_url 填https://taotoken.net/api模型名填MiniMax-M3-MXFP8和你--served-model-name一致。如果你用的是 Anthropic 协议客户端走/v1/messages路由配置方式在接入文档里有说明。对于需要长期跑编码、Agent 循环调用的场景Coding Plan 提供了更稳定的配额和路由策略比每次手动管理 Key 和并发更省事。模型对话页面则适合快速验证模型输出质量不用自己搭服务就能对比效果。整套流程实测下来8×A800 跑 MiniMax-M3-MXFP8 的关键就是显存要“抠”8 卡 TP、128 块大小、关 CUDA Graph 预留换 KV 空间。把这三条落实128K 上下文和 EAGLE3 推测解码都能正常开起来。 在8×A800上部署 MiniMax-M3-MXFP8：vLLM 张量并行配置与验证笔记
1. 8×A800 跑 MiniMax-M3-MXFP8先搞清楚它到底吃多少显存MiniMax-M3 是个 MoE 大模型总参数量 427B、激活参数 26B还带原生多模态能力。官方在 vLLM 发布博客里重点讲的是 Hopper/Blackwell 上的性能表现但现实里很多团队手上就是 A800SM80集群8 卡 80GB PCIe、两两 NVLink 互联。这套硬件能不能把 MiniMax-M3-MXFP8 跑起来、128K 上下文能不能开、张量并行怎么配是这篇要解决的问题。先说结论能跑但配置要比 H100 更“抠”显存。核心就三件事——张量并行必须 8 卡、block-size 必须 128、关掉 CUDA Graph 预留把显存让给 KV Cache。这三条任何一条没做对要么起不来要么 128K 直接 OOM。适合谁看手上有 8×A800 或类似 SM80 多卡机器、想用 vLLM 部署 MiniMax-M3-MXFP8、需要 OpenAI 兼容接口对外服务的同学。下面从模型准备、启动脚本、显存预算、参数解释到接口验证一步步给可复制的命令。2. 部署前的前置准备模型、镜像、环境变量模型文件很大MiniMax-M3-MXFP8 是 31 个分片、约 414GB草稿模型 MiniMax-M3-EAGLE3 约 6.5GBBF16。建议提前放到本地高速存储或 NFS别等 docker run 的时候再拉不然卡在下载上很浪费时间。镜像方面推荐直接用vllm/vllm-openai:v0.26.0。原因是 v0.26.0 已经官方包含了 PR #49149 的 A800 batch1 修复——这个 bug 在 v0.25.1 上会导致并发 ≥2 时崩溃。如果你的内部镜像策略必须停在 v0.25.1那就得手动打补丁后面会提。先把环境变量设好后面脚本直接引用export MODEL_DIR/path/to/MiniMax-M3-MXFP8 export EAGLE3_DIR/path/to/MiniMax-M3-EAGLE3 export HF_CACHE$HOME/.cache/huggingface export PORT8001这里MODEL_DIR和EAGLE3_DIR指向你实际存放模型分片的目录HF_CACHE给 HuggingFace 缓存用PORT是宿主机映射端口。这几个变量在启动脚本里都会用到先 export 好省得改脚本。注意模型分片目录里应该有 config.json、tokenizer 相关文件和 31 个 safetensors 分片缺一个 vLLM 加载都会报错。启动前用ls $MODEL_DIR确认一下分片数量。3. 可复制的 vLLM 启动脚本与张量并行配置核心思路写在前面必须--tensor-parallel-size 8模型要求 8 卡张量并行--block-size 128必须和 MSA 稀疏注意力块大小一致128K 上下文要配合VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0否则 KV 预算不够。同时开启 EAGLE3 推测解码、工具调用和 reasoning parser。把下面内容保存为deploy.sh#!/usr/bin/env bash set -euo pipefail MODEL_DIR${MODEL_DIR:-/path/to/MiniMax-M3-MXFP8} EAGLE3_DIR${EAGLE3_DIR:-/path/to/MiniMax-M3-EAGLE3} HF_CACHE${HF_CACHE:-$HOME/.cache/huggingface} PORT${PORT:-8001} CONTAINERminimax-m3-mxfp8 IMAGEvllm/vllm-openai:v0.26.0 # v0.26.0 已含 #49149 修复 docker rm -f $CONTAINER 2/dev/null || true docker run -d \ --name $CONTAINER \ --gpus all \ --shm-size16g \ -p ${PORT}:8000 \ -e HF_ENDPOINT${HF_ENDPOINT:-https://huggingface.co} \ -e VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0 \ -v $MODEL_DIR:/models/MiniMax-M3-MXFP8 \ -v $EAGLE3_DIR:/models/MiniMax-M3-EAGLE3 \ -v $HF_CACHE:/root/.cache/huggingface \ $IMAGE \ /models/MiniMax-M3-MXFP8 \ --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}执行bash deploy.sh然后写一个轮询脚本watch_ready.sh等/health返回就绪#!/usr/bin/env bash set -euo pipefail PORT${PORT:-8001} until curl -sf http://localhost:${PORT}/health /dev/null; do echo waiting for vLLM ready... sleep 10 done echo vLLM is ready on port ${PORT}bash watch_ready.sh如果内部镜像策略限制只能用 v0.25.1需要手动应用 PR #49149 补丁并构建 patched 镜像。开源仓库里提供了patch/m3_topk_fix.patch和patch/Dockerfile并单独给了deploy_v0251_m3patch.sh直接跑那个脚本即可。4. 显存预算拆解为什么 0.99 和关 CUDA Graph 是必须的很多人第一次跑会在 128K 上下文时 OOM问题就出在显存预算上。下面这张表是每卡的占用估算占用项每卡大约权重~58.5 GB414GB ÷ 8Marlin MXFP8 重打包后峰值CUDA Graph~4.1 GBKV Cache~10.2 GB128K EAGLE3 配置合计~72.8 GB / 81.9 GB8 卡总显存 640GB权重占约 470GB剩余约 170GB 给 KV。关掉 CUDA graph 预分配后每卡 KV 约 10.2GB能支持 128K 上下文。如果不关128K 下可用 KV 只有 4.65GB直接 OOM。所以VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0这个环境变量不是可选项是 128K 场景的必选项。--gpu-memory-utilization 0.99也是同理——权重太大设 0.95 时 KV 预算会变成负数服务根本起不来。关键参数对照表参数作用--tensor-parallel-size 8必须 8 卡 TP--block-size 128必须匹配 MSA 块大小--max-model-len 131072128K 上下文VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0不预留 CUDA Graph 内存省给 KV--gpu-memory-utilization 0.99权重太大0.95 时 KV 预算为负--enforce-eager不要加默认 CUDA Graph 快得多--moe-backend triton不需要默认 Marlin 即可注意--enforce-eager千万别加。有人为了省显存加了这个结果吞吐掉一大截而真正该省的是 CUDA Graph 的预分配不是整个 CUDA Graph。5. 接口连通性与推理结果验证服务跑起来后是 OpenAI 兼容接口。先确认模型列表curl http://localhost:8001/v1/models返回里应该能看到MiniMax-M3-MXFP8。然后发一个 chat 请求验证推理curl http://localhost:8001/v1/chat/completions \ -H Content-Type: application/json \ -d { model: MiniMax-M3-MXFP8, messages: [{role: user, content: 你好请介绍一下自己}], max_tokens: 128 }如果返回里有正常的choices[0].message.content说明推理链路通了。支持的路由包括/v1/chat/completions、/v1/responses、/v1/messagesAnthropic 协议、/v1/completions等。首次请求会特别慢因为 Triton JIT 编译需要 10–60 秒。建议先 warmup 一次再压测不然你会以为服务卡死了。warmup 就是发一个简单请求等它返回之后并发请求就正常了。如果你需要长期跑编码任务或 Agent 场景可以考虑用 Coding Plan 来管理调用配额和模型路由比裸调接口省心。验证模型本身能力的话模型对话页面可以直接对比不同模型的输出。6. 本篇常见错误排查128K OOM先检查VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS0是否设置。没设的话 CUDA Graph 会吃掉 4GB 多KV 预算不够。--attention_config.indexer_kv_dtype fp8报错A800 不要加这个参数。FP8 indexer 仅 Blackwell 支持SM80 上加了会直接失败。首次请求极慢Triton JIT 编译需 10–60 秒属于正常现象。先 warmup 一次再压测别在第一次请求就判定服务有问题。并发 ≥2 崩溃这是 A800 上 v0.25.1 的已知 bugv0.26.0 已修复。检查你的镜像版本是否 ≥ v0.26.0。如果因为内部策略只能用 v0.25.1参考开源仓库的补丁方案手动修复。服务起不来、日志报显存不足确认--gpu-memory-utilization是 0.99 而不是 0.95同时确认 8 张卡都被--gpus all正确挂载。用nvidia-smi看容器内是否能看到 8 张 A800。模型加载报分片缺失检查$MODEL_DIR下 31 个分片是否完整config.json里的num_hidden_layers和分片索引是否对得上。7. 接入与后续把服务接到你的应用里服务起来之后对外就是一个 OpenAI 兼容端点。如果你要在自己的应用里调用需要生成 API Key 并配置接入地址。API Key 在控制台的 API Keys 页面创建接入文档里有各语言 SDK 的配置示例。接入时 base_url 填https://taotoken.net/api模型名填MiniMax-M3-MXFP8和你--served-model-name一致。如果你用的是 Anthropic 协议客户端走/v1/messages路由配置方式在接入文档里有说明。对于需要长期跑编码、Agent 循环调用的场景Coding Plan 提供了更稳定的配额和路由策略比每次手动管理 Key 和并发更省事。模型对话页面则适合快速验证模型输出质量不用自己搭服务就能对比效果。整套流程实测下来8×A800 跑 MiniMax-M3-MXFP8 的关键就是显存要“抠”8 卡 TP、128 块大小、关 CUDA Graph 预留换 KV 空间。把这三条落实128K 上下文和 EAGLE3 推测解码都能正常开起来。