4×3090 实测 Step-3.7-Flash：全驻留量化反超更高级别，MTP 与视觉互斥

StepFun 近期开源的 Step-3.7-Flash 是一款 198B 总参数 / 11B 激活的视觉混合专家（MoE）模型，原生支持多模态与工具调用。但要在消费级硬件上把它跑得顺畅，并非「量化越精越好」。一位独立开发者在 4×3090（96GB 显存，无 NVLink）平台上进行了一天的实战调试，得出几条与传统直觉相反的结论，对本地部署者具有直接参考价值。

硬件与软件环境

整套测试平台配置如下：

• CPU：Ryzen 9 9900X，192GB DDR5-5600
• GPU：4×3090（1 块 Ti + 3 块 FE），合计 96GB 显存，单卡 200W 功耗上限，PCIe 通道为 12×/4×/4×/1×
• 电源：1250W MSI 白金
• 软件：llama.cpp HEAD（commit 32eddaf），当前唯一识别 step35/step3vl 架构的构建

调试方法借鉴了 NVIDIA 的 MoE 优化思路（「三堵墙」框架：显存墙、通信墙、计算墙），作者的目标场景首先撞上显存墙，随后是计算墙。

核心发现一：最大可全驻留量化 > 更高精度但部分溢出

Step-3.7-Flash 的量化对比给出了反直觉的结果：

• IQ4_XS（权重约 99GB）：超过 96GB 显存上限，约 20% 专家被迫卸载到 CPU，吞吐约 33 t/s
• IQ3_XXS（权重约 72GB）：完全驻留在 4 张 3090 上，零 DDR 总线流量，吞吐约 65 t/s

同模型、同激活参数，仅因「完全驻留 vs 部分溢出」一项，吞吐相差 2.4 倍。作者指出，VRAM 带宽约为 DDR 总线的 10 倍，因此只要激活专家能完整放回显存，量化精度的小幅损失完全可以被带宽优势抵消。对于不同显存容量的机器，关键是先找到「全驻留」的临界线。

核心发现二：MTP 投机解码与视觉输入互斥

Step-3.7-Flash 自带 MTP（Multi-Token Prediction）草稿头，需加载独立的约 3.5GB GGUF。在纯文本场景下效果显著：

• 基线 65 t/s → 启用 MTP 后 81 t/s
• 代码任务峰值 87 t/s，草稿接受率 68%，n_max=2 为最佳配置

但只要请求中包含图像，llama.cpp 立即硬中止，报错 llama_decode(ctx_dft) failed → ggml_abort（对应 PR 20277）。原因在于草稿上下文无法解码图像 token，任何多模态请求都会击穿投机批次。该问题在所有图像输入上稳定复现，且属于引擎层限制，与显卡无关。

结论是：启动时二选一——要 MTP 文本加速就别用视觉，要视觉就关闭草稿头。

核心发现三：「修一堵墙会打开另一堵」

如果直接叠加 MTP，权重 + 草稿头会超过显存上限，触发溢出，吞吐反而跌至 53 t/s，比不开 MTP 还慢。解法是：将 KV 缓存量化为 q4_0，释放约 4.5GB，使权重、草稿头、KV 全部驻留显存，回到 81 t/s 的完整速度。这印证了「先找驻留线，再把余量留给草稿头」的整体策略。

采样参数与工具调用

实测还纠正了几处容易被忽略的细节：

• StepFun 的真实采样：推理阶段 temp 1.0 / top_p 0.95，对话阶段 0.6；llama.cpp 默认的 0.8 与两者都不匹配
• llama.cpp 当前存在无限推理循环 bug，需用 --reasoning-budget 16384 限幅
• 原生工具调用走模型内嵌的 jinja 模板，可输出带 reasoning_content 的结构化 tool_calls，无需额外 grammar
• 超过 100K 上下文后幻觉增多，作者实际使用上限设为 96K

对其他硬件的启示

文中给出的「形状」结论并不局限于 4×3090：只要显存带宽相对 DDR 总线保持约 10 倍的优势，「最大可全驻留量化」通常就会胜过「更高精度但溢出」的方案。MTP 与视觉互斥的限制来自引擎层，在任何显卡上都成立。

成本参考

按文中报价：4×3090 二手约 3200 美元，192GB DDR5 约 1600 美元，其余硬件约 800 美元，运行功耗 800W 上限，由太阳能供电。对希望以消费级硬件长期跑视觉 MoE 的玩家而言，这是一份可复现的预算与配置基线。