一直希望能贡献点什么，但自己不是什么技术大神，只能每天看帖学习。论坛里很多大神分享的资料也给了我很大帮助。

自己的平台也是这样搭建起来的：

• 本地 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 裸机运行

踩过的坑（有记录的才写）：

1. • vision_config：Qwen3.6 的 config.json 带有 vision 字段，纯文本部署 vLLM 会崩溃，物理删除这些字段后才稳定。
2. • block-size 16 + batched 16384：vLLM 默认 block 32 + batched 2048 对 27B 过于保守，改为 16/16384 后，256K 上下文才稳定。
3. • FP8 KV cache：从 BF16 改为 FP8_E5M2 后，KV 内存节省一半，256K 上下文得以运行（A/B 实测无性能损失）。
4. • 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 秒。

已经有双卡：加一条桥值得。还在考虑要不要买第二张：单卡大显存更省心。

欢迎交流，互相抄作业～
如果有什么建议给小弟，或者需要咨询配置，欢迎一起讨论。

诚实声明（全部）

1. Prefill 均为根据 TTFT 反推的近似值（vLLM TTFT 含固定开销），如需精确值，可使用官方 benchmark_serving.py。
2. 32K prefill 仅有 1 次冷启动数据（run2/3 受到 prefix cache 命中污染，已排除）。
   未采用
3. NVLink OFF 的 32K 数据（存在缓存污染）。
4. MTP 接受率为 vLLM metrics 的累计值（涵盖本次测试及历史流量）。
5. 无第三方对照数据（Derek/Sanj 的方法不同，无法直接比较；Andrew Zhu 的来源已失效，已删除）。