双 3090 NVLink + vLLM 半年实测：Qwen3.6-27B 解码 128 tok/s，并发 4 用户 258 tok/s

[Che]

看到大佬的帖子才知道 vLLM 吞吐量这么大，连夜把 llama.cpp 换成了 vLLM。奇怪的是 Prefix cache hit rate: 0.0%，仍在探索中。。

[Xiaote]

@Che 0.0% 大概率不是故障，而是「没有可命中的公共前缀」。vLLM 的 prefix cache 只在请求开头有完全相同的 token 序列时才命中，按这个顺序排查：

1. 先确认开关。老版本（0.6 之前）要显式加 --enable-prefix-caching 才开缓存，新版本默认开。跑一下 vllm serve --help | grep prefix 看你的版本；如果是从别处抄的启动参数，注意有没有 --disable-prefix-caching。另外极老版本还要配合 --enable-chunked-prefill 才生效。

2. 自测方法：同一个 prompt 原样连发两次，第二次 hit rate 应该明显大于 0。如果第二次上去了，说明缓存本身是好的，你平时看到 0% 只是因为每次请求前缀都不同——这是正常现象，不是 bug。如果连发两次还是 0，才需要怀疑开关或配置。

3. 最隐蔽的杀手：前缀「看着一样、token 不一样」。Chat UI 如果每次在 prompt 最前面注入时间戳、随机 request id、或者带变化的系统提示词，哪怕只差一个 token，整个前缀全部失配，命中率直接归零。系统提示词要保证字节级一致，别用动态拼接。

4. 长上下文会把缓存挤爆。你这种双 3090 场景如果 max-model-len 开很大，KV cache 预算被长序列占满，LRU 淘汰非常激进，缓存条目很快被换出去，命中率自然上不去。max-model-len 按实际需要设，别贪大，给缓存留空间。

5. /metrics 里的 hit rate 是服务启动以来的累计均值，不是最近一分钟的实时值。刚起服务、前面全是独立请求时，均值就是 0.x%，别被吓到。想验证就看 vllm:num_prefix_cache_hits 这个计数器的增量，而不是看百分比。

补充一句：TP=2 下 prefix cache 按层分片正常生效，不需要特殊处理。真正要盯的是你的请求模式——如果每个用户会话都是独立历史、没有共享的 system prompt 前缀，那这个指标低是预期行为，省下的显存留给 KV cache 更实在。

[starryskyknight]

@Don-zhu 我没放机壳内 我用延长线拉伸出来 另外用了架子撑着

[starryskyknight]

@terry 看了您的建议 我一直想用SG-Lang试试看 但跑起来都没有 VLLM好 不知道是不是老卡的关系 今天会发一篇千问3.8的版本 希望相同设备的伙伴能一起讨论 找到最佳化方案

[starryskyknight]

@Che 大佬不敢当 我也是自己乱摸 乱尝试 我今天会发一篇千问3.8的版本 欢迎一起研究讨论

[stxpnet]

sglang感觉就是长时间占 着CPU和显卡。发热太大了，不知道是不是我没配置好。

[terry]

@stxpnet 它就是运算的时候占着，你是不是启动的时候它响很久？那在配置cuda graph，搞完了就不占据了。

[terry]

@starryskyknight
1，不要用敬语。
2，大概率就是老卡的问题。

[Che]

@stxpnet 挺奇怪，只占显存不推理应该是没功耗的

[stxpnet]

@terry
不知道，用了两天，显卡60度和CPU 睿频4.4GHZ，70多度 就跟火炉一样烧了两天，目前体感没有这个好，干脆弃用了。
再有更好了就要删除它了。 现在就等 noonghunna和Sandermage/sndr 那两个仓库出更好的方案了。 Sandermage那个是真的看好，启动后100多个专属的补丁在vllm里面打好。但是3.8一出来，一点都不香了。作者估计 都换设备了，还没更新。 再过10天不更新的话，我想自己让GLM5.3把他的仓库克隆过来改造那些vllm补丁给3.8用。