双 3090 NVLink + vLLM 半年实测：Qwen3.6-27B 解码 128 tok/s，并发 4 用户 258 tok/s
-
@Don zhu 你 1015 那个求助帖我也回了，补充一个这帖特有的点：这帖的场景是 NVLink + vLLM，竖装之前要先想清楚 NVLink 桥的问题。
NVLink 桥是刚性件，槽距固定（3 槽/4 槽规格），一旦把一张卡竖装或者用延长线挪了位置，桥就够不着了，等于放弃 NVLink。好消息是 vLLM 的 TP=2 并不依赖 NVLink，走 PCIe 也能跑——楼上 applejuice 也说了，无桥大概损失 15-20% prefill、5-10% decode，对大多数场景可接受。
所以两条路：要么两卡保持相邻槽位走 NVLink（配柔性桥），要么放弃 NVLink、把 FE 竖装/外置发挥它上下贯通的风道，TP 走 PCIe 4.0 延长线。取舍就看你要不要那 15-20% 的 prefill 收益。至于 starryskyknight 本人是不是竖装的，得等他本人答。
-
-
@Che 0.0% 大概率不是故障，而是「没有可命中的公共前缀」。vLLM 的 prefix cache 只在请求开头有完全相同的 token 序列时才命中，按这个顺序排查：
-
先确认开关。老版本（0.6 之前）要显式加 --enable-prefix-caching 才开缓存，新版本默认开。跑一下 vllm serve --help | grep prefix 看你的版本；如果是从别处抄的启动参数，注意有没有 --disable-prefix-caching。另外极老版本还要配合 --enable-chunked-prefill 才生效。
-
自测方法：同一个 prompt 原样连发两次，第二次 hit rate 应该明显大于 0。如果第二次上去了，说明缓存本身是好的，你平时看到 0% 只是因为每次请求前缀都不同——这是正常现象，不是 bug。如果连发两次还是 0，才需要怀疑开关或配置。
-
最隐蔽的杀手：前缀「看着一样、token 不一样」。Chat UI 如果每次在 prompt 最前面注入时间戳、随机 request id、或者带变化的系统提示词，哪怕只差一个 token，整个前缀全部失配，命中率直接归零。系统提示词要保证字节级一致，别用动态拼接。
-
长上下文会把缓存挤爆。你这种双 3090 场景如果 max-model-len 开很大，KV cache 预算被长序列占满，LRU 淘汰非常激进，缓存条目很快被换出去，命中率自然上不去。max-model-len 按实际需要设，别贪大，给缓存留空间。
-
/metrics 里的 hit rate 是服务启动以来的累计均值，不是最近一分钟的实时值。刚起服务、前面全是独立请求时，均值就是 0.x%，别被吓到。想验证就看 vllm:num_prefix_cache_hits 这个计数器的增量，而不是看百分比。
补充一句：TP=2 下 prefix cache 按层分片正常生效，不需要特殊处理。真正要盯的是你的请求模式——如果每个用户会话都是独立历史、没有共享的 system prompt 前缀，那这个指标低是预期行为，省下的显存留给 KV cache 更实在。
-
-
@starryskyknight 问一下这位兄弟，你是把其中的一张卡给竖起来放置了吗？我现在也有类似的问题，我一张卡是 EVGA 的三风扇的卡，另外一张卡是 NVIDIA 的 FE。如果两张卡都并排放的话，根本就没有空间了。
-
非常好的分享，尤其是踩坑点，VLLM吐字速度快，32k上下文prefill冷启动15.2秒，后续如何？VLLM最头疼的就是缓存机制比SG-Lang差太多。SG-Lang可以做到长上下文基本不掉速，吐字速度还是要慢于VLLM的。有空可以测试一下SG-Lang，毕竟Agent是刚需，稍微上点强度的编程也要求走长上下文，聊天走本地意义不大。
-
-
-
-
@terry 看了您的建议 我一直想用SG-Lang试试看 但跑起来都没有 VLLM好 不知道是不是老卡的关系 今天会发一篇千问3.8的版本 希望相同设备的伙伴能一起讨论 找到最佳化方案
-
-
-
@Don-zhu 我没放机壳内 我用延长线拉伸出来 另外用了架子撑着
-
@starryskyknight 感谢回复，我也是买了线放到外边，根本没法装一起。放外边反而散热好很多
