Qwen3.5-397B-A17B-FP8 完整 Benchmark 总结：MoE+FP8+TP8 实测与 TaoToken 配置骨架

1. 先把场景说清楚397B 的 MoEFP8TP8 到底在测什么Qwen3.5-397B-A17B-FP8 这个名字本身就藏着三个关键信息397B 是总参数量A17B 表示每个 token 实际激活约 17B 参数FP8 是权重与激活的量化格式。它属于典型的稀疏 MoE 架构512 个专家、每 token 激活 10 个、60 层里 48 层线性注意力加 12 层全注意力。这种结构决定了它的推理性能不能只看单卡吞吐而要同时盯住显存占用、专家路由开销、prefill 与 decode 的分离程度。我这次复盘的目标很明确在 4 台 8 卡 H100 的集群上用 TP8 单节点张量并行、2P:2D 的 PD 分离部署跑一轮完整的 Benchmark覆盖 256 到 32K 的 prompt 长度记录 TTFT、TPOT、QPS 和并发上限。同时把配置骨架整理成可复制的 config.toml 与 settings.json再通过 TaoToken 的统一 Key/API 通道做一次接入验证确认评测流程能稳定复现。适合读这篇的人正在评估大模型推理性能的开发者、需要给 MoE 模型做容量规划的工程师、以及想用统一 API 通道快速验证模型行为的团队。如果你只是想知道“这模型好不好用”那这篇偏工程但配置和排障部分可以直接抄。2. TaoToken 前置统一 Key 与 API 通道怎么准备在跑 Benchmark 之前我习惯先把接入层固定下来。原因很简单评测过程中如果 API 通道不稳定TTFT 和 QPS 的波动就分不清是模型问题还是网络问题。TaoToken 在这里的角色是统一 Key 和 API 通道把模型对话、Coding Plan、控制台、API Keys 管理收敛到一个入口省去每个模型单独配 endpoint 的麻烦。你需要先拿到一个可用的 Key。操作路径是访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 进入控制台后创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。如果你要长期跑编码或 Agent 任务可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。API 基地址统一用 https://taotoken.net/api 注意这个地址不加 UTM 参数。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 模型对话入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。ClaudeCodeAnthropic 相关配置参考 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 。提示Key 只放在环境变量里不要写进 config.toml 或 settings.json 的明文字段。后面配置骨架里我用${TAOTOKEN_API_KEY}占位。3. 可复制配置config.toml 与 settings.json 骨架这一节是全文最核心的部分。我把部署侧的 config.toml 和接入侧的 settings.json 分开写前者管推理引擎后者管客户端调用。3.1 config.tomlMoE FP8 TP8 部署骨架[model] name Qwen3.5-397B-A17B-FP8 architecture moe num_experts 512 experts_per_token 10 num_layers 60 linear_attn_layers 48 full_attn_layers 12 quantization fp8 context_length 65536 max_prefill_tokens 32768 [parallel] tp_size 8 pp_size 1 ep_size 1 pd_disabled false [pd] prefill_nodes [10.0.0.116, 10.0.0.117] decode_nodes [10.0.0.118, 10.0.0.119] router_addr 10.0.0.117:8000 dp_aware true [transfer] backend mooncake transport rdma [optimization] chunked_prefill_size 4096 weight_loader_disable_mmap true schedule_conservativeness 0.7 cuda_graphs false几个参数我单独解释。context_length从默认 256K 降到 65536是这次收益最大的一步KV cache 释放后短 prompt 并发直接涨了 4 倍多。chunked_prefill_size 4096让 32K 长 prompt 的 TTFT 从 678ms 降到 348ms。weight_loader_disable_mmap true是为了绕开 mmap page fault配合 CPFS 加载加速启动时间从 40 分钟压到 1 分钟左右。3.2 settings.jsonTaoToken 接入骨架{ api_base: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, model: Qwen3.5-397B-A17B-FP8, timeout_seconds: 120, max_retries: 3, stream: true, headers: { Content-Type: application/json }, benchmark: { prompt_lengths: [256, 512, 1024, 2048, 4096, 8192, 16384, 32768], output_tokens: 256, concurrency_levels: [1, 2, 4, 8, 16, 32], ttft_sla_ms: 500 } }api_base固定为 https://taotoken.net/api api_key_env指向环境变量避免明文。benchmark段是我用来驱动压测脚本的prompt 长度和并发档位跟后面的结果表一一对应。3.3 环境变量与启动命令export TAOTOKEN_API_KEY你的Key export MODEL_NAMEQwen3.5-397B-A17B-FP8 export ROUTER_ADDR10.0.0.117:8000 python -m vllm.entrypoints.openai.api_server \ --config config.toml \ --served-model-name $MODEL_NAME \ --host 0.0.0.0 \ --port 8000启动后先确认 router 在 10.0.0.117:8000 上监听dp-aware 路由生效再跑压测。4. 验证请求与成功结果对照配置跑起来后第一步不是直接压测而是发一条最小请求确认链路通。curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: Qwen3.5-397B-A17B-FP8, messages: [{role: user, content: 用一句话说明 MoE 的稀疏激活原理}], max_tokens: 64, stream: false }返回里能看到choices[0].message.content和usage字段说明 Key、endpoint、模型名三者对齐。如果这里报 401先查 Key报 404查模型名拼写报超时查 router 地址。链路通了之后跑完整 Benchmark单条请求 256 输出 token 的结果如下PromptTTFT 前TTFT 后变化TPOT吞吐~256194ms209ms—6.3ms114 tok/s~512233ms249ms—6.2ms116 tok/s~1K225ms199ms↓12%6.2ms126 tok/s~2K234ms191ms↓18%6.2ms127 tok/s~4K276ms230ms↓17%6.2ms124 tok/s~8K378ms243ms↓36%6.2ms124 tok/s~16K285ms280ms—6.3ms117 tok/s~32K678ms348ms↓49%6.4ms108 tok/sTTFT ≤ 500ms 约束下的并发与 QPSPrompt并发前并发后QPS 前QPS 后提升~2567365.819.8241%~5122332——39%~1K3114.26.7—~2K1524——60%~4K5113.45.665%~8K673.14.752%~16K443.12.9—~32K221.51.6—397B 与 122B 的横向对照指标122B (TP4, 6P:2D)397B (TP8, 2P:2D)单条 TPOT4.6ms6.2ms单条 TTFT (1K)155ms199ms单条 TTFT (32K)259ms348ms短 prompt 并发3136短 prompt QPS19.519.8中 prompt QPS (4K)13.05.6系统吞吐 (256 并发)5783 tok/s—核心结论有四条。TPOT 全程稳定在 6.2 到 6.4mschunked prefill 不影响 decode。context-length 降到 65K 是最大赢家短 prompt 并发从 7 涨到 36。chunked prefill 让长 prompt TTFT 改善明显32K 降了 49%。prefill 是瓶颈TPOT 纹丝不动但 TTFT 随并发退化说明 prefill 算力不够用。QPS 由 decode 决定decode 实例数和 TPOT 直接决定 QPS 上限。5. 本篇常见错排查5.1 启动阶段mmap page fault 导致加载慢现象是权重加载卡在 40 分钟以上日志里反复出现 page fault。原因是默认 mmap 加载在 CPFS 上触发大量缺页中断。解决方式是在 config.toml 里设weight_loader_disable_mmap true配合本地 NVMe 预热启动时间能压到 1 分钟。5.2 长 prompt TTFT 超 500ms优化前的 1K 和 8K 在完整请求时 TTFT 超过 500ms实际并发只能压到 1 到 2。根因是 prefill 没有分块长序列一次性算完。加上chunked_prefill_size 4096后32K 的 TTFT 从 678ms 降到 348ms。如果还超把max_prefill_tokens提到 32768减少长 prompt 的调度开销。5.3 并发上不去QPS 卡在低位先看 decode 实例数。2P:2D 里 decode 只有 2 个节点QPS 上限被 decode 卡死。如果业务偏短 prompt 高并发可以调成 3P:1DTTFT 并发能再涨 50%但 QPS 会减半。反过来如果偏长 prompt保持 2P:2D 更均衡。另外schedule_conservativeness从默认值调到 0.7吞吐还能再涨 10% 到 20%。5.4 接入侧 401 或模型名不匹配用 TaoToken 通道时401 基本都是 Key 没放进环境变量或者api_key_env名字写错。模型名必须和--served-model-name完全一致大小写和连字符都不能差。如果返回 404先确认api_base是 https://taotoken.net/api 而不是带路径的完整 endpoint。5.5 CUDA graphs 没开导致 TPOT 偏高这次实测cuda_graphs falseTPOT 稳定在 6.2ms。如果开启 CUDA graphs预期 TPOT 能降到 4 到 5msQPS 提升 30% 到 50%。但开启后显存占用会上升需要重新算 KV cache 余量。建议先在单节点验证再上集群。6. 接入与排障的分流建议如果你在排障或接入阶段卡住优先看 API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 和接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 这两个页面覆盖了 Key 创建、endpoint 配置和常见错误码。如果你要验证模型行为是否符合预期直接去模型对话入口 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 发几条请求比看日志快。如果你要长期跑编码或 Agent 任务Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 更适合固定额度的场景。最后留一个我踩过的坑压测脚本的并发档位不要一次拉满先从 1 到 8 逐档加观察 TTFT 是否越过 500ms 红线。397B 的 prefill 瓶颈在 16K 以上会非常明显32K 并发只能到 2硬拉并发只会让 TTFT 爆表QPS 反而下降。把context_length和chunked_prefill_size这两个参数调对比堆机器更有效。