双 3090 实测 SGLang HiCache：write_through 不会真的重用，write_back 才会（混合 GDN + 投机解码栈）

[starryskyknight]

双 3090 实测 SGLang HiCache：write_through 不会真的重用，write_back 才会（混合 GDN + 投机解码栈）

TL;DR

• 在「混合线性注意力（GDN/SSM）+ 投机解码」的模型栈上，SGLang HiCache 用预设 write_through 时：主机池确实会被写满，但逐出后的旧前缀不会被重用——重发同一段 4 万 token 上下文，耗时跟冷启动一模一样（15.4s）。
• 改成 --hicache-write-policy write_back 后，同一探测：15.4s → 0.4s（38×），再发一次 0.1s。
• 如果你的 HiCache「开了没感觉」，先看这两个开关再下结论。

环境

项目	值
硬件	2×RTX 3090 NVLink（48GB 合并）
模型	Qwen3.8-27B（hybrid：16 层 Gated Attention + 48 层 Gated DeltaNet）+ DFlash2 草稿
引擎	SGLang main（2026-09 dev），TP=2、fp8_e4m3 KV、上下文 262K
附加	KV 池 354,788 tokens；host 池 709,577 tokens（+mamba/draft 池）

现象 A：write_through（预设）——池在涨，但没有复用

开启 --enable-hierarchical-cache 后：

• 启动正常：UnifiedRadixCache hybrid_ssm=True hicache_attached=True
• 主机池确实增长：sglang:hicache_host_used_tokens 一路涨到 592,658 / 709,577
• 但做「逐出-回流」探测（见下）时：重取耗时 = 冷启动耗时（7.3s / 15.4s 一模一样），log 里零 prefetch 纪录

探测法（推荐大家用同一招验证有没有真的复用）

1. 冷跑一段 40K token 的唯一上下文 R（记 wall）
2. 灌 10 段各 40K 的唯一内容作逐出压力（> 装置池容量）
3. 重发同一段 R → 比 wall；再发一次 → 0.1s 级才算正常

实测记录：

R-cold  : 15.4s
... 10×40K 逐出 ...
R-rehost: 15.5s   ← write_through：与冷启动无异
R-again : 0.1s    ← 说明装置端机制没坏，是 host 没接手

现象 B：write_back——复用立刻生效

只加一个开关：

--enable-hierarchical-cache \
--hicache-write-policy write_back

同一探测：

R-cold  : 15.4s
... 14×40K 逐出 ...
R-rehost: 0.4s    ← 38×（从 host 回载）
R-again : 0.1s

hicache_host_used_tokens：20,221 → 453,970 → 486,725（逐出时备份的语义生效）

完整启动参数（我们现行主力）

sglang serve \
  --model-path <Qwen3.8-27B-abliterated-AWQ-MTP> \
  --trust-remote-code \
  --tp-size 2 --mem-fraction-static 0.90 \
  --kv-cache-dtype fp8_e4m3 \
  --chunked-prefill-size 4096 --max-prefill-tokens 16384 \
  --max-running-requests 3 --schedule-policy hrrn \
  --max-mamba-cache-size 15 --mamba-full-memory-ratio 0.9 \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path <DFlash2-W4A16> \
  --speculative-num-draft-tokens 8 --speculative-dflash-block-size 8 \
  --enable-hierarchical-cache --hicache-write-policy write_back

注意事项

• 内存：host 池 ≈ 11.6GB/rank（709,577 tokens）+ mamba 池 2.39GB + draft 池 3.63GB；60GB 机器两 rank 合计 ≈35GB，请留好余裕（可用 --hicache-ratio / --hicache-size 调整）
• 我们在 SGLang dev 版上测试；版本不同行为可能不同
• 我们没挖到 write_through 不复用的根因（疑似非同步备份路径语义差异），欢迎懂内部机制的指点

同场加映（同日其他实测，负结果也贴）

• GSP-RM 关闭（driver 610、proprietary）：prefill 16K/50K 与 decode 全部持平（+1.5~2% 噪声级），未重现社群 +58% 的 prefill 增益 → 已回滚。环境：SGLang+610 vs 原案例 vLLM+595，供参考。
• KV cache fp8_e4m3 vs e5m2：单流 +25~30%（12/12 样本 116–134 vs 旧 90 级）——如果你还在 e5m2，值得换。
• chunked-prefill 2048→4096 + max-prefill 8192→16384：batch prefill +4~8.5%。
• --schedule-policy hrrn：长短混排时短请求延迟 −22%（13.5s→10.5s），吞吐无损。

[terry]

HiCache的内存和SSD消耗如何？

[johnnybegood]

@starryskyknight 我测过开了hicache , decode会掉速， 但是prefill 不错， 正常么？

[starryskyknight]

@terry 内存和 SSD 消耗（我们那台：双 3090 / TP=2 / 262K 上下文 / DFlash2，HiCache 只开「显存主机内存」两级）**

• 内存（开机一次性分配）：KV 主机池 11.63 GB/rank（709,577 tokens，默认 ratio=2，即 2x 显存池）+ Mamba/GDN 状态池 2.39 GB/rank + draft 池 3.63 GB/rank；TP=2 合计约 33 GB（实测整机可用内存 48 GB → 15 GB）。显存侧不额外增加（KV 本来就在显存）。
• SSD：我们没启用（storage_backend=None），重启后缓存即失效、要重新预热。想要「重启不丢缓存」可以配 --hicache-storage-backend file 这类存储后端；容量按池子规模规划（我们这种是 GB 级），注意写入量和 SSD 寿命。内存不够的机器可以调小 --hicache-ratio 或 --hicache-size。

[starryskyknight]

@johnnybegood 开 HiCache 后 decode 掉速**
正常，方向是对的：HiCache 的收益大头在 prefill / 前缀复用，decode 会有个位数百分比的代价。我们刚做了开关对照（其他配置完全一致，单流 512 输出 x3 取中位）：

• 开（write_back）≈133 t/s ｜ 关 ≈137 t/s，差约 3%
• 复用收益：同一段 4 万 token 重发 15.4s → 0.4s
  如果你那边掉得明显（比如 >10%），按这三条查：①策略一定要用 --hicache-write-policy write_back（不然写了不重用、白占内存；我们实测 write_through 下重复请求还是全量 15.4s）；②主机内存余量要够（我们这套要一次分配约 33GB，紧张时会有换页/回收开销）；③高并发下逐出线程会和 decode 抢内存带宽，可以调小 ratio 或降并发试试。纯「长输出 + 短输入 + 无重复前缀」的场景收益本来就小，可以按需关掉换那约 3%。