双 3090 NVLink + vLLM 半年实测：Qwen3.6-27B 解码 128 tok/s，并发 4 用户 258 tok/s
-
，系统 取消固定了此主题
-
一开始在油管看老特，后来来到抡槌，追踪了很久，论坛刚成立时也加入了。
一直希望能贡献点什么，但自己不是什么技术大神，只能每天看帖学习。论坛里很多大神分享的资料也给了我很大帮助。
自己的平台也是这样搭建起来的：
- 本地 LLM：Qwen3.6-27B
- 生图：FLUX.2 Dex
- 生视频：LTX-2.3
- 声音：VoxCPM2
除了人在海外，实在弄不到刘悦大神的整合包，没法继续玩下去，其他目前运行得还算稳定。
请我的 Agent 整理一下，和各位前辈交流。我尽量要求内容有干货和实测数据，不要 AI 幻觉。
希望能抛砖引玉，让其他使用相同配置的朋友一起讨论。
也希望各位大神看到我的平台有可以优化的地方时，不吝赐教。~~下面正文 ~~
折腾了半年，双 3090 NVLink + vLLM 终于调稳定了。
先上数据（全部实测）：
- Decode：128.2 tok/s（单请求，MTP n=3）
- Prefill：约 2094 tok/s（2K prompt，根据 TTFT 反推）
- 并发：4 个用户同时使用，系统吞吐 258 tok/s（饱和点）
- 配置：Qwen3.6-27B-heretic AutoRound INT4，vLLM 0.22.1，TP=2
- KV cache：fp8_e5m2，block-size 16，max-num-batched-tokens 16384
- 功耗锁定 290W，单卡显存 23.4GB，256K 上下文稳定
硬件配置：
- MSI Suprim X 3090 + ASUS TUF 3090（LINKUP PCIe 5.0 Riser 90cm）
- 七彩虹 NVLink Bridge（4 links，双向 112 GB/s）
- Core Ultra 9 285K / ProArt Z890-CREATOR / 64GB DDR5
- Ubuntu 26.04 裸机运行
踩过的坑（有记录的才写）：
-
- vision_config：Qwen3.6 的 config.json 带有 vision 字段，纯文本部署 vLLM 会崩溃，物理删除这些字段后才稳定。
-
- block-size 16 + batched 16384：vLLM 默认 block 32 + batched 2048 对 27B 过于保守，改为 16/16384 后，256K 上下文才稳定。
-
- FP8 KV cache：从 BF16 改为 FP8_E5M2 后，KV 内存节省一半，256K 上下文得以运行（A/B 实测无性能损失）。
-
- ComfyUI offloading bug：视频模式存在已知问题，使用 T2V 模式绕过。
实测补充（与社区传闻不同的地方）：
MTP n=1/2/3 扫描：128.7 / 128.9 / 128.9 t/s，差异 <1%；但 MTP 接受率达 77.7%，说明 MTP 本身很有效，n 值影响较小。
NVLink 开启 vs 关闭（2K prompt）：decode 128.2 vs 128.8，差异在误差范围内。
并发饱和：4 个用户达到 258 t/s，8 个用户开始排队（延迟从 3 秒升至 5 秒）。
FP8 KV：在 Ampere 上无性能衰减，纯粹节省显存。
NVLink 到底值不值？
坦白说：2K prompt + decode 场景下，NVLink 差异很小。
长 prompt 场景理论上 prefill 通过 NVLink 会更有优势；32K 冷 prefill 的 TTFT 实测为 15.2 秒。
已经有双卡：加一条桥值得。还在考虑要不要买第二张：单卡大显存更省心。
欢迎交流，互相抄作业～
如果有什么建议给小弟，或者需要咨询配置，欢迎一起讨论。诚实声明（全部）
- Prefill 均为根据 TTFT 反推的近似值（vLLM TTFT 含固定开销），如需精确值，可使用官方 benchmark_serving.py。
- 32K prefill 仅有 1 次冷启动数据（run2/3 受到 prefix cache 命中污染，已排除）。
未采用 - NVLink OFF 的 32K 数据（存在缓存污染）。
- MTP 接受率为 vLLM metrics 的累计值（涵盖本次测试及历史流量）。
- 无第三方对照数据（Derek/Sanj 的方法不同，无法直接比较；Andrew Zhu 的来源已失效，已删除）。
-
@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。如果两张卡都并排放的话，根本就没有空间了。
@Don-zhu 我没放机壳内 我用延长线拉伸出来 另外用了架子撑着
-
非常好的分享，尤其是踩坑点，VLLM吐字速度快，32k上下文prefill冷启动15.2秒，后续如何？VLLM最头疼的就是缓存机制比SG-Lang差太多。SG-Lang可以做到长上下文基本不掉速，吐字速度还是要慢于VLLM的。有空可以测试一下SG-Lang，毕竟Agent是刚需，稍微上点强度的编程也要求走长上下文，聊天走本地意义不大。
-
@Che 大佬不敢当 我也是自己乱摸 乱尝试 我今天会发一篇千问3.8的版本 欢迎一起研究讨论
-
@terry 看了您的建议 我一直想用SG-Lang试试看 但跑起来都没有 VLLM好 不知道是不是老卡的关系 今天会发一篇千问3.8的版本 希望相同设备的伙伴能一起讨论 找到最佳化方案
