6×3090跑出206 t/s，vLLM修复撑起7路262k

📅 2026 年 10 月 12 日 📖 约 3 分钟 Reddit r/LocalLLaMA AI工程开源

核心成果

用 vLLM 在 6×3090 上跑 Qwen3.8-Flash-Next：7 个用户、262k 上下文，prefill（预填充）6.5k tokens/s，单用户解码 57 t/s，7 个用户同时生成时聚合吞吐 206 t/s。包含对上游 vLLM 的修复。

详细说明、serve 命令和原始数据见 GitHub：https://github.com/lukolszewski/vllm

这套修复解决了什么

这些 vLLM 修复让你可以：

- 把 PLE（n-gram 表，102GB）放到 SSD 上，省出 108GB 系统内存
- 使用 int8 KV（KV 缓存以 8 位整数存储），在显存里塞进更多用户，还不会有 fp8 带来的性能损失

速度对比见我之前的 llama-multigpu 性能修复帖：https://www.reddit.com/r/LocalLLaMA/comments/1x023z4/qwen38flashnext_on_6x3090_6x4090_without_nvlink/

为什么上游 vLLM 跑不起来

上游 vLLM 在这台机器上根本起不了这个模型，原因有三：

1. 模型拒绝 --pipeline-parallel-size > 1：流水线并行（PP）只能为 1
2. 张量并行（TP）只能是 1/2/4/8，6 张卡不在其列，等于没用
3. TP=1 时单张 24GB 卡又装不下

另外还有两个上游问题：把 102GB 的 n-gram（PLE）表放到 SSD 上的 PR 今天才出现在上游（常规做法是让它常驻内存）；fp8 KV 在 Ampere 架构上会崩溃。

测试环境与性能对比

测试机器是消费级 PC：没有 EPYC/Threadripper，GPU 之间无 P2P，但依然可用（6×3090 + 7950X + 187GB 内存，其中四张卡通过 Thunderbolt 连接）。使用 GPTQ-INT4 检查点（nvfp4 更慢），每个槽位一条流式请求。tokens/s 数据如下：

工作负载	上下文	llama.cpp-multigpu	vLLM（本分支，int8 KV）
prefill，单会话	250k	2111	6574
250k prompt 的首 token 延迟（TTFT）	250k	~118 s	37.8 s
decode，单会话	250k	33.7	57.6
decode，5 会话：每会话 / 总和	250k	~30 / ~150（在 200k 时）	37.9 / 190
decode，7 会话：每会话 / 总和	250k	n/a（只有 5 个槽位）	29.4 / 206
GPU KV 中可常驻的 262k 上下文数		5	7.33
服务器空闲时主机可用内存		154 GiB	141 GiB

没奏效的方案

有两件事没能成功：

- NVFP4 权重：无需改动就能加载，但在这些卡上比 GPTQ 慢 10–12%。两者都走 Marlin weight-only 量化路径，Ampere 架构上没有任何能让 FP4 加速的硬件
- 流水线并行下的每用户解码速度会随用户数下降（1/3/5/7 用户：57 → 44 → 38 → 29 t/s），而 llama.cpp 的分组解码基本持平（5 用户时 34 → 30 t/s）。5 用户时总吞吐两者相近

结论：要 prefill 速度、单用户速度和座位数，选 vLLM；想让每个用户看到同样的速度，选 llama.cpp（我之前也发过一套类似的 llama 修复）。

AMD 用户看这里

AMD 侧也有对等方案：u/alanoo81 早前在 Radeon V620 上用 PP=3 跑过这个模型，PP 的思路就是从他那里来的。当前上游只需要去掉 guard 检查，本分支用一个 partition 检查替代。如果你用 AMD，从那边开始。

注意事项

几个提醒：

- 只测了一个模型家族，仅 NVIDIA，只在一台机器上验证过（外加 5060 Ti 上的 kernel 单元测试）
- 批量输出与单次输出不是逐字节一致的，这是 vLLM 固有的批量不确定性
- 从加载到服务就绪需要 4–5 分钟
- 与 llama.cpp 那套工作一样，代码是借助 LLM 写的，用测量和输出检查（needle 测试、kernel 输出与 oracle 比对）验证，没有走人工 review
- 每个改动一个 commit，按需取用
- 这是一个修复分支，不是我会长期维护的 fork