StepFun 的 Step 3.7 Flash 最近在 vLLM、SGLang、NIM、阿里云百炼上同步上架。它是稀疏 MoE：196B 总参数，每 token 激活约 11B，256K 上下文，原生带视觉编码器。卖点是 3 路多 token 预测（MTP-3）把生成吞吐拉到 100 到 300 tok/s，编码场景峰值 350 tok/s。但 Hivebook 的部署笔记里指出一个坑：MTP 不是开一个开关就行，不同推理栈的配置口径完全不一样。
MTP-3 到底在预测什么？
传统自回归一次出一个 token。MTP 头在预训练时就额外加了几个预测头，让模型在前向一次里同时猜测未来 1、2、3 个 token。推理时这三个候选 token 被并行接受或拒绝，类似投机解码，但草稿头是模型自带的而不是另一个小模型。3 路 MTP 理论上能把解码吞吐翻 2 到 3 倍，前提是接受率够高。
vLLM 和 SGLang 的开关为什么不一样？
vLLM 要写 --speculative_config 为 JSON，method 指定 mtp，num_speculative_tokens 给 3。SGLang 走 EAGLE 路径，参数是 --speculative-algorithm EAGLE --speculative-num-steps 3。同一套 MTP 权重，两个栈的调用名完全不同，一个走 mtp 方法，一个走 EAGLE 兼容层。这意味着迁移工作负载时不能只搬权重，要重新调 speculative 配置，否则跑出来的吞吐可能只是基线自回归，白瞎了 MTP 头。
社区在 DGX Spark 上的实测还提到：NVFP4 量化下并发扩展很好，FP8 反而更受限；KV cache 增长时速度衰减很小。对自部署团队，重点不是跑分，而是把 MTP 头在自己的栈上真正点亮。
实际部署还有一个隐藏成本：MTP 头本身要占显存。4B 参数的 MTP 头加载到显存，意味着总权重体积从 196B 的 11B 激活之外，还要多留一份 4B 的额外权重做并行预测。对 24GB 消费级显卡，这是硬开销。社区在 DGX Spark 上的实测也提到，NVFP4 量化下 MTP 才能真正点亮，FP8 下显存不够。这解释了为什么 Step 3.7 Flash 主推 NVFP4——不是为了精度，是为了把 MTP 头塞进有限的显存里。自部署团队在选型时，要把 MTP 头的显存预算算进去，不能只看主干模型的激活参数。
另一个工程细节是 MTP 接受率。3 路 MTP 不是每次都能接受 3 个 token——如果第二个或第三个候选被拒绝，后面的要回滚。实际吞吐取决于接受率，而不是理论峰值。社区实测显示编码任务接受率高，开放域对话接受率低，这也是为什么官方峰值 350 tok/s 只在编码场景出现。自部署团队应该按自己的工作负载测 P50 吞吐，而不是看宣传峰值。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论