双7900XTX：vLLM Prefix Cache 与 SGLang HiCache 实测对比
-
-
-
补几个读表口径，免得这组不错的数据被读过头：
1）这是「两套可用配置」对比，不是单变量引擎 A/B。至少五处不一致：KV 精度（vLLM FP8 vs SGLang BF16）、投机解码（DFLASH vs 关）、attention 后端、max_model_len（87,040 vs 196,608）、缓存层级（GPU-only vs GPU+host）。所以「冷请求 vLLM 更快」里有一部分是 FP8 KV 省了一半 KV 读流量、以及没开投机带来的，不能整笔记到引擎头上。要引擎结论，就把两边锁成同 KV 精度、同投机开关、同 max_model_len、同 batch/ubatch 再跑。
2）85K 的 vLLM TTFT 比 64K 低，你自己也点到了，是单样本 + 首次 JIT/调度抖动造成的非单调点。每档先预热一次，再重复 3 次取中位数，把首个请求剔除。
3）HiCache 那条要把链路讲出来：125,952 token 的 KV 在 1.11s 内从 host 回载，实际是被 PCIe 带宽限住的（TP=2、两张 x8）。换到 PCIe 5.0 x16 的平台回载还能更快；同时 host 池别开太大，ratio=2.0 在 96G 内存上会和页缓存抢，A 的 KV 越贴内存上限越容易被 swap 拖崩。
4）vLLM 85K 的 A 被 5 条前缀挤出后 hit=0%，是当前实现的预期：它的 prefix cache 只驻 GPU，驱逐即丢；--swap-space 是 prefill 的 KV swap，不是跨请求前缀缓存。所以这不是「vLLM 前缀缓存失效」，是两条路线的差异。
5）选型上你的取舍（85K 常驻 + 128K/HiCache 按需）是对的：一次性长文选 vLLM 冷路径省心；同一大前缀反复问（Agent、固定系统提示、代码库）时 HiCache 的 host 层才是决定性的。
要更硬的结论，补两组：①同 KV 精度、同投机开关的纯引擎对比；②vLLM 侧把 max-model-len 放宽到 131072 跑通，才有 128K 的一致对照。
-
-
-
回帖：双 7900XTX + Qwen3.8-27B TP=2 复刻了你这套 HiCache 实验，补一个我们踩到的坑
楼主这帖我照抄了一遍。我们这边正好也是一台双 7900XTX（TP=2，Qwen3.8-27B 系，上下文 196608，GPU KV 池 242,854 token），把楼主那套"驱逐回访"实验原样复刻，结论基本对得上，但踩到一个楼主没提到的坑，顺手报一下，免得后来人白折腾一下午。
一、实验（照抄楼主的语义）
A(128K) 冷 → A 立刻再问一次（GPU 热命中）→ B(128K) 冷 → C(128K) 冷（把 A 挤出 GPU KV）→ A 回访 判据只看第 ⑤ 步的 TTFT；全程不调 flush_cache（一调这实验就废了）二、结果
配置 ① A 冷 ② A 热（GPU 命中） ⑤ A 回访（已被挤出） 主存占用 不开 HiCache 166.67 s 0.89 s 166.42 s（1.00×） — HiCache， write_back— 1.10 s 171.02 s（0.87×） 48 GB HiCache， write_through169.25 s 0.91 s 1.38 s（0.01×，120×） 48 GB 跟你那边的 186.41 s → 1.11 s 是一回事：这一格确实能靠主机内存救回来，量级对得上。
三、坑一：写策略选错，等于白开（这条最值得说）
第一次我按"省事"选了
--hicache-write-policy write_back（想着只在驱逐时搬运，最不打扰预填充），结果：- 主机池真的建起来了：两个 rank 的
sglang::scheduler进程 RSS 各 26 GiB，/proc/meminfo里 Shmem 48 GB； - 服务自报参数全对：
enable_hierarchical_cache: True、hicache_size 24、hicache_write_policy: 'write_back'、hicache_io_backend: 'kernel'、hicache_mem_layout: 'page_first'； - 启动日志零告警零报错；
- 需要的算子也在（
torch.ops.sgl_kernel里transfer_kv_per_layer/transfer_kv_all_layer都取得到）；
但第 ⑤ 步还是 171.02 s（0.87×）—— 全量重算，一点便宜没捡到。
换成
write_through之后，同样的池子、同样的其余参数，第 ⑤ 步直接 1.38 s。⇒ 教训：光看日志、看进程内存、看
/get_server_info自报参数，都判不出它到底有没有生效。 唯一可信的判据就是第 ⑤ 步那个数字。所以顺序应该是：先换write_through试；不行再怀疑io_backend；最后才怀疑构建/算子。四、坑二：
--hicache-size的单位是「每个 rank 的 GB」，不是总数我一开始按总数估的，写
--hicache-size 48，想着"48 GB 内存留出来"。实际是每个 rank 各 48.5 GiB ⇒ 这台 125 GB 的机器上MemAvailable直接从 113 GB 掉到 23 GB，正好落进"和页缓存抢、贴上限被 swap 拖崩"那个区间。改成
--hicache-size 24⇒ 实占 48 GB、可用内存还有 70 GB，容量约 2× GPU KV 池，正好对应默认--hicache-ratio 2.0的语义。⇒ TP=N 的话，按 N × size 估内存；或者干脆不写 size，用
--hicache-ratio让它按显存池比例算。五、冷路径代价
166.67 s → 169.25 s（+1.5%），而且这是在我们散热更好、风扇曲线已修的条件下测的 ⇒ 基本可以忽略，没有理由不开。
六、一个想跟楼主核对的地方
楼主那张"冷请求"表里，vLLM 85K 的是 0.64 s。按 85K token 算是 132,800 tok/s；而同帖驱逐复测里，vLLM 真正的冷 85K 是 66.22 s（约 1,284 tok/s）。同帖同一框架差 约 100 倍，这两列应该不是同一个口径（我怀疑第一张表那列其实是缓存命中，每档之间没清缓存）。
如果这个成立，"一次性长文档选 vLLM"这个结论可能得再看一眼。我们自己的对照是：同一台机器上 vLLM 的 256K 冷 prefill ≈ 2080 tok/s，SGLang ≈ 800 tok/s —— 不过那是另一对卡（R9700 vs 7900XTX）跑出来的数，口径不同，只作参考。楼主如果有条件，在同一对 7900XTX、同一模型上补一组严格冷启动对照，这个结论就硬了。
- 主机池真的建起来了：两个 rank 的
-
-
-
-
回帖：双 7900XTX + Qwen3.8-27B TP=2 复刻了你这套 HiCache 实验，补一个我们踩到的坑
楼主这帖我照抄了一遍。我们这边正好也是一台双 7900XTX（TP=2，Qwen3.8-27B 系，上下文 196608，GPU KV 池 242,854 token），把楼主那套"驱逐回访"实验原样复刻，结论基本对得上，但踩到一个楼主没提到的坑，顺手报一下，免得后来人白折腾一下午。
一、实验（照抄楼主的语义）
A(128K) 冷 → A 立刻再问一次（GPU 热命中）→ B(128K) 冷 → C(128K) 冷（把 A 挤出 GPU KV）→ A 回访 判据只看第 ⑤ 步的 TTFT；全程不调 flush_cache（一调这实验就废了）二、结果
配置 ① A 冷 ② A 热（GPU 命中） ⑤ A 回访（已被挤出） 主存占用 不开 HiCache 166.67 s 0.89 s 166.42 s（1.00×） — HiCache， write_back— 1.10 s 171.02 s（0.87×） 48 GB HiCache， write_through169.25 s 0.91 s 1.38 s（0.01×，120×） 48 GB 跟你那边的 186.41 s → 1.11 s 是一回事：这一格确实能靠主机内存救回来，量级对得上。
三、坑一：写策略选错，等于白开（这条最值得说）
第一次我按"省事"选了
--hicache-write-policy write_back（想着只在驱逐时搬运，最不打扰预填充），结果：- 主机池真的建起来了：两个 rank 的
sglang::scheduler进程 RSS 各 26 GiB，/proc/meminfo里 Shmem 48 GB； - 服务自报参数全对：
enable_hierarchical_cache: True、hicache_size 24、hicache_write_policy: 'write_back'、hicache_io_backend: 'kernel'、hicache_mem_layout: 'page_first'； - 启动日志零告警零报错；
- 需要的算子也在（
torch.ops.sgl_kernel里transfer_kv_per_layer/transfer_kv_all_layer都取得到）；
但第 ⑤ 步还是 171.02 s（0.87×）—— 全量重算，一点便宜没捡到。
换成
write_through之后，同样的池子、同样的其余参数，第 ⑤ 步直接 1.38 s。⇒ 教训：光看日志、看进程内存、看
/get_server_info自报参数，都判不出它到底有没有生效。 唯一可信的判据就是第 ⑤ 步那个数字。所以顺序应该是：先换write_through试；不行再怀疑io_backend；最后才怀疑构建/算子。四、坑二：
--hicache-size的单位是「每个 rank 的 GB」，不是总数我一开始按总数估的，写
--hicache-size 48，想着"48 GB 内存留出来"。实际是每个 rank 各 48.5 GiB ⇒ 这台 125 GB 的机器上MemAvailable直接从 113 GB 掉到 23 GB，正好落进"和页缓存抢、贴上限被 swap 拖崩"那个区间。改成
--hicache-size 24⇒ 实占 48 GB、可用内存还有 70 GB，容量约 2× GPU KV 池，正好对应默认--hicache-ratio 2.0的语义。⇒ TP=N 的话，按 N × size 估内存；或者干脆不写 size，用
--hicache-ratio让它按显存池比例算。五、冷路径代价
166.67 s → 169.25 s（+1.5%），而且这是在我们散热更好、风扇曲线已修的条件下测的 ⇒ 基本可以忽略，没有理由不开。
六、一个想跟楼主核对的地方
楼主那张"冷请求"表里，vLLM 85K 的是 0.64 s。按 85K token 算是 132,800 tok/s；而同帖驱逐复测里，vLLM 真正的冷 85K 是 66.22 s（约 1,284 tok/s）。同帖同一框架差 约 100 倍，这两列应该不是同一个口径（我怀疑第一张表那列其实是缓存命中，每档之间没清缓存）。
如果这个成立，"一次性长文档选 vLLM"这个结论可能得再看一眼。我们自己的对照是：同一台机器上 vLLM 的 256K 冷 prefill ≈ 2080 tok/s，SGLang ≈ 800 tok/s —— 不过那是另一对卡（R9700 vs 7900XTX）跑出来的数，口径不同，只作参考。楼主如果有条件，在同一对 7900XTX、同一模型上补一组严格冷启动对照，这个结论就硬了。
- 主机池真的建起来了：两个 rank 的
站长已核：本帖设为精华，作者 +5 积分奖励，希望再接再厉！
