@gonep 说:

，那根 PCIE 线

淘宝搜索：工业级TEFZEL特氟龙扎带捆扎，我买得是3.6*250mm10条，价格大概30元

楼主这帖我照抄了一遍。我们这边正好也是一台双 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（一调这实验就废了）

二、结果

跟你那边的 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、同一模型上补一组严格冷启动对照，这个结论就硬了。

奖励凭证：精华 +5 分 · 编号 f1921-1927-1（系统自动发放，只发一次）

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 的一致对照。

@iamvirus 说:

这么绑显卡牛逼

哈哈，万能的捆扎带