那个结论是错的。 后来插了几行日志一查，真相是 SGLang 把 MTP 的层数识别成了 64（实际只有 1 层），导致每 token 的 KV 成本被高估 5 倍，KV 池被砍到 1/5 —— 不是"显存不够"，是"算错了"。

修好之后，单路 128K + MTP 直接跑通（池子 44913 → 211357 token）。这篇把定位过程、修复、前后实测和更新后的四方总表一次写完。

1. 先给三张结论表

1.1 修复前后（单变量 A/B：只切换补丁）

指标	修复前	修复后	变化
cell_size	163840 B/token	32768 B/token	÷5
KV 池 token	44913	211357	×4.71
单条输入上限	45417 token	~211000 token	×4.65
127K 单路请求	被拒（HTTP 400）	成功	—
短上下文 code	86.1 t/s	86.1 t/s	0
短上下文 抽取	85.9 t/s	85.9 t/s	0
短上下文 创作	59.8 t/s	59.8 t/s	0
双流聚合	170.1 t/s	171.8 t/s	+1%
运行显存	26182 MiB（余 6016）	30626 MiB（余 1572）	预算用满

1.2 MTP 到底值多少（同权重同参数，只切投机）

MTP 的价值全在短/中上下文；128K 下接受长度塌到 1.6-2.0，验证开销把收益吃光 —— 长上下文别指望 MTP。

1.3 更新后的四方总表

口径提醒：①② 是 Windows 11 + -c 262144/131072、temp 0.7；③④ 是 Ubuntu + fp8 KV、贪婪解码。④ 的双路吞吐 171.8 是在 32K 上下文下测的，② 的 161.4 是在 256K 下测的，论"每单位上下文的速度"② 更强。

2. 现象：MTP 一开，KV 池从 28 万掉到 4.5 万

模型是 RedHatAI/Qwen3.8-27B-INT4（17.7 GB，自带 model_mtp.safetensors），同一个启动命令只差投机开关：

运行	KV 池	128K 请求
不开投机	279214	能跑
开 NEXTN	44913	Input length (125837 tokens) exceeds the maximum allowed length (60967 tokens)

3. 排查：先以为显存不够，后来发现是算错

第一反应当然是"显存被 MTP 吃掉了"，于是把所有能想到的旋钮都试了一遍：

参数调到天亮都没用。直到我注意到一个矛盾：

Memory pool end. avail mem=7.90 GB      ← 分配完还剩 7.9GB 空闲
KV Cache is allocated. #tokens: 44913   ← 却只给了 1.37GB

显存明明够，它却不用。 那就不是"不够"，是"算错"。

于是往 sizing 代码里插了几行日志（_profile_available_bytes 和 _compute_cell_size），一次就露馅了：

[KV_SIZING] avail=11.359GB slack=2.387GB rest_after_mamba=6.853GB pre_load=29.837GB
            reserve_mb=3712 mf=0.92 post_capture=False
→ 交给池子的预算是 6.85GB，却只分配了 1.37GB

[KV_CELL_DEBUG]  cell_size=32768B (32.0KiB/token) num_layers_arg=16
                 mambaish=True full_attn=16 spec=SpeculativeAlgorithm.EAGLE
                 eagle_draft_layers=64                      ← 这里！
[KV_CELL_DEBUG2] EAGLE 缩放生效: eagle_draft_layers=64 num_layers=16
                 -> cell_size=163840B                       ← 每 token 成本被放大 5 倍

顺带还排除了一个我原本以为的元凶：日志里 post_capture=False，说明那个"混合 mamba 模型的 pre_capture 激活预留"（3712 MB）根本没生效，跟这事无关。

4. 根因：MTP 层数识别错误，×5 的缩放

两处代码组合出来的。

第一处，spec_aux_hidden_state.py 里推导 draft 层数：

num_nextn_predict_layers = draft_model_config.num_nextn_predict_layers
if num_nextn_predict_layers is not None:
    config.eagle_draft_num_layers = int(num_nextn_predict_layers)
else:
    config.eagle_draft_num_layers = int(max(
        draft_model_config.num_hidden_layers,      # ← 拿到 64
        draft_model_config.num_attention_layers,
    ))

Qwen3.5/3.8 的 MTP 层数写在 text_config.mtp_num_hidden_layers 里（=1），不是 DeepSeek/GLM 用的 num_nextn_predict_layers。字段认不出来就走了 fallback，而 --speculative-draft-model-path 指向的正是模型自己的目录 —— 于是这个"draft 模型配置"读到的就是整模型的 64 层。

（证据：model_mtp.safetensors 里只有 mtp.layers.0.*，就一层。）

第二处，pool_configurator.py 拿这个数字去缩放每 token 成本：

# EAGLE/STANDALONE: scale cell_size to account for draft model KV cache
self._cell_size = int(
    self._cell_size * (1 + int(eagle_draft_num_layers) / int(num_layers))
)

而混合注意力模型（48 层 GDN + 16 层全注意力）里 num_layers 取的是真正带 KV 的层数 = 16，于是缩放系数变成：

1 + 64 / 16 = 5

每 token 成本高估 5 倍，KV 池就被砍到 1/5。

5. 修法：一处改动

最地道的改法不是去改那个 fallback（那只修了一处），而是在 ModelConfig 里就把字段补齐 —— 所有依赖 num_nextn_predict_layers 的地方都自动受益：

# sglang/srt/configs/model_config.py
         self.num_nextn_predict_layers = getattr(
             self.hf_text_config, "num_nextn_predict_layers", None
         )
+        if self.num_nextn_predict_layers is None:
+            # Qwen3.5/3.8 name the MTP depth `mtp_num_hidden_layers`
+            self.num_nextn_predict_layers = getattr(
+                self.hf_text_config, "mtp_num_hidden_layers", None
+            )

验证（只改这一处，把之前打在 fallback 上的补丁撤销）：

mf 0.97 时池子 257367 token，双路 128K（需要 262144）已经接近可行。

6. 修复前后实测：单变量 A/B

方法：只切换这一个补丁，vocab 占位补丁两边都开，其他启动参数逐字符相同。

公共参数：

--model-path <Qwen3.8-27B-INT4> --language-only \
--context-length 131072 --max-running-requests 2 --mem-fraction-static 0.92 \
--kv-cache-dtype fp8_e4m3 --page-size 1 \
--max-mamba-cache-size 16 --mamba-ssm-dtype bfloat16 \
--enable-hierarchical-cache --hicache-size 12 --hicache-write-policy write_through \
--speculative-algorithm NEXTN --speculative-draft-model-path <同目录> \
--speculative-eagle-topk 1 --speculative-num-steps 3 --speculative-num-draft-tokens 4

127K 单路请求（本轮唯一真实差异）

	修复前	修复后
结果	HTTP 400：exceeds the maximum allowed length (45417 tokens)	成功
prompt	—	128180 token
prefill	—	112.9 s（1136 tok/s）
解码 @128K	—	31.5 t/s（接受长度 1.68）

短上下文 decode：两边逐位相同（对照组）

修复前:  code 86.1 t/s accept 3.56 | echo 85.9 accept 3.66 | prose 59.8 accept 2.51
        双流聚合 90.9 + 79.2 = 170.1 t/s
修复后:  code 86.1 t/s accept 3.56 | echo 85.9 accept 3.66 | prose 59.8 accept 2.51
        双流聚合 90.9 + 80.9 = 171.8 t/s

逐位相同是预期结果：那个字段只被 KV 池尺寸估算消费，不参与任何 kernel、attention 或采样逻辑。这也正好反证了补丁是纯内存修复 —— 如果有人报告"打了补丁速度变了"，那一定是别的原因。

顺带一修的另一个浪费：draft 的 vocab 层（2.4 GiB）

MTP draft 在 __init__ 里会建自己的 embed_tokens 和 lm_head（各 248320×5120×2 byte ≈ 2.5 GB），但运行时 set_embed_and_head() 会把它们 del 掉、换成目标模型的张量引用 —— 而 KV 池是在这之前就按"draft 还占着 5.53GB"算好尺寸的，之后释放的显存就白空着。

用"0 尺寸占位"规避（上游对应 PR #37155 把这步释放提前了）：

draft 加载显存:  5.53 GB → 0.79 GB
KV 池:          14161 → 45423 token

两个修复加起来：池子 14161 → 45423（vocab 层）→ 211357（层数），总共 ×14.9。

7. MTP 参数怎么扫（同 llama.cpp 扫 n-max 的规律）

规律和 llama.cpp 完全一致：steps 越大，可预测任务（代码/工具）越快，创作类接受率反而下降。而且上下文越长接受长度越低：短上下文 3.76，128K 时只有 1.68。

8. 三方/四方横评（更新后）

结论：

1. llama.cpp + Q4_K_M + MTP 仍是"最快 + 最长上下文"的综合最优（256K×2 还能 161 t/s），它的 KV 池是按实际使用分配；
2. SGLang + MTP 修好之后，解码反超 llama.cpp（+6%~13%），双流聚合最高，而且单路 128K 保住了；
3. SGLang 无投机的唯一优势是 prefill（1680-1915 tok/s，123K 时还有 1199）和 HiCache 前缀复用（17.9K 前缀 10.2s → 1.25s）；
4. 两者取舍的核心差异从"显存分配策略"变成了"MTP 在长上下文下收益趋零"这个共同的物理限制。

9. 给同是小白的提醒

1. 池子异常小的时候，先怀疑"算错"而不是"不够"。判据很简单：分配完成后还剩多少显存。像这次分完还剩 7.9GB，就说明预算没被用满，参数调到天亮都没用。
2. 定位靠日志，别靠猜：在 sizing 路径（_profile_available_bytes、_compute_cell_size）插几行 print，把中间值打出来，一次就能看到 cell_size 被放大了 5 倍。改完记得把调试补丁撤掉（env 变量门控更安全）。
3. 换带 MTP 的权重先确认两件事：它带 model_mtp.safetensors；model.safetensors.index.json 里引用了它。
4. Xet 存储的仓库必须 HF_HUB_DISABLE_XET=1，否则 hf-mirror 等于没用，还会 401。
5. max_running_requests is capped to 1 这条日志一定要看：混合 mamba 模型 + 投机下每请求要 5 个 mamba 槽，槽不够就变排队（我实测 2×64K 墙钟 84.4s ≈ 2×42s，是串行不是并行）。
6. --max-mamba-cache-size 别乱调大：bf16 + 16 槽 下跑 2×60K 长并发，两个请求都能完成但随后 AssertionError: Can not alloc mamba cache（mamba_component.py:479）→ SIGQUIT → 整个服务退出。长上下文档建议用 --max-mamba-cache-size 6（默认 float32）。
7. 投机参数要自己扫，而且别忘了它只在短上下文值钱：短上下文 +107%，128K 下 −8%~+10%（基本白干）。

10. 还没解决的

• 双路长并发的 mamba 槽位断言崩溃（见提醒 6），要么等上游修，要么避开 bf16 + 大槽位组合。
• 128K 下 MTP 收益趋零：接受长度塌到 1.68，属于投机解码在长上下文下的通用问题，不是这个 bug 带来的。
• SGLang 的 L3 磁盘层只写不读（混合模型上从不触发预取），三级缓存实际只能用两级。

上游已按第 5 节的方案提交了 issue 和最小复现脚本（repro_mtp_draft_layers.py：Part 1 不需要 GPU，只读 config.json 和权重就能证明误判；Part 2 起两次服务对比池子）。这个 bug 对所有用 mtp_num_hidden_layers 的 Qwen3.5/3.8 混合模型都成立，池子会被砍 1 + 总层数/带KV层数 倍；就算是全注意力模型（每层都带 KV）也会被砍 2 倍。

感谢论坛里讨论投机解码和显存分配的各位，这次少走了很多弯路。