四卡 4090 实测最强小模型：Qwen3.8 27B

一台 4×RTX 4090 上的 vLLM + Qwen3.8-27B-AWQ，从首 token 延迟到大海捞针，一次聊透。

局域网里新起了一台推理服务器。与其看跑分，不如直接按在地上测一遍：性能压到 128 路并发、智商做一套带陷阱的题、256K 上下文真塞满试试。以下是一个下午的完整"体检报告"。

01 被测对象

项目	值
推理框架	vLLM 0.25.0（OpenAI 兼容 API）
模型	Qwen3.8-27B-AWQ-INT4（27B 参数，AWQ 4-bit 量化）
上下文	262,144 tokens（256K）
思考模式	混合式（--reasoning-parser qwen3），可开关
工具调用	已启用（--enable-auto-tool-choice），实测 3/3 通过
调度上限	--max-num-seqs 128
硬件	4 × RTX 4090 24GB（PCIe 互联，无 NVLink）

启动命令（原文）：

  --tensor-parallel-size 4 --max_model_len 262144 \
  --gpu-memory-utilization 0.90 --kv-cache-dtype fp8_e4m3 \
  --enable-chunked-prefill --enable-prefix-caching \
  --max-num-seqs 128 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3

有意思的是：实测吞吐——单流 ~108 tok/s、聚合 ~2,274 tok/s、预填峰值 ~4,400 tok/s——基本只到单张 4090 的量级。启动参数证实了 --tensor-parallel-size 4：四张卡没有换来四倍性能，头号嫌疑是 4090 之间只有 PCIe（无 NVLink），张量并行每一步的通信开销吃掉了多卡收益。

另一个实测数据更出人意料：向服务器塞一个 19.8 万 token 的长请求，KV cache 占用只有 12.15%——反推 KV 总容量约 163 万 tokens，是 256K 的 6.2 倍，上下文余量非常充裕。启动参数 --kv-cache-dtype fp8_e4m3 证实 KV 用的是 FP8 精度，配合轻量 GQA 架构才有这么大的余量。文末会回答一个自然的问题：那换成两张 4090 会怎样？

02 先说结论

• 单流生成 ~108 tok/s，微信问答场景秒回；
• 128 路并发零失败，聚合吞吐 2,274 tok/s 逼近天花板；
• 预填充是真瓶颈：峰值 ~4,400 tok/s，240K 输入要 90 秒；
• 常规智商在线：13/14 问答 + 3/3 编程，还纠正了出题人两道错答案；
• 工具调用开箱即用：单工具/并行双工具/该不调时不调，3/3 通过；
• 256K 是"真"上下文：大海捞针 11/11 全中，但细粒度辨别 200K 后退化；
• 两个坑：max_tokens 包含思考 token；冷门事实会编造。

03 生成性能：从 108 到 2,274 tok/s

空载时首 token 延迟 0.4~2.0 秒；把并发一路拉到 128 路，没有一次失败、没有一次超时，首 token 延迟 p95 也只涨到 1.11 秒。（图中橙色为后续双卡复测数据，详见 09 节。）

并发	聚合吞吐	TTFT p95
1	108 tok/s	—
16	803 tok/s	—
48	1,734 tok/s	0.69 s
96	2,165 tok/s	0.96 s
128	2,274 tok/s	1.11 s

注意 24→128 路，客户端翻 5.3 倍，吞吐只涨 1.7 倍——饱和点在 2.3~2.5K tok/s。生产限流建议设在 64~96 路：再多只是摊薄每流速度（128 路时单流只剩 ~18 tok/s）。另：128 路全部成功，恰好顶满 --max-num-seqs 128 的调度上限——超过 128 路的请求会排队。

（防杠说明：吞吐数字用服务端 /metrics 的 token 计数器交叉核对过，不是客户端自己数的。）

04 预填充才是真瓶颈

预填充（处理输入的速度）测试方法很讲究：每次用随机唯一文本（防止前缀缓存虚高）、max_tokens=1（排除生成时间）。图中蓝色为四卡、橙色为双卡复测（见 09 节）。

输入长度	平均速率	边际速率
8K~32K	~4,100-4,300 tok/s	~4,400（峰值）
128K	3,406 tok/s	2,757
240K	2,620 tok/s	1,872

为什么慢？三层原因：

1. 量化拖累：AWQ INT4 加速的是读权重的 decode 阶段；预填充是算力密集阶段，反量化反而有额外开销；
2. 注意力二次开销：边际速率从 4,400 衰减到 1,872，曲线很诚实；
3. 参照系：H100 跑 27B FP8 预填 10~20K tok/s；本机四张卡实测峰值 4.4K，仅相当于单张 4090 水平——结合 PCIe 互联推断，TP 通信开销才是首要瓶颈，而非量化或配置错误。

但有两个隐藏救星。

救星一：前缀缓存。 相同载荷重复请求，11.05 秒变 0.77 秒——14.4 倍加速。多轮对话共享系统提示和历史，实际体感远快于冷启动。

救星二：长任务不卡队。 一个 240K 大预填充要跑 91 秒，我们在第 2 秒插入一个小聊天请求——它 2.34 秒就出了首 token，完全没被大任务阻塞。chunked prefill 生效，长短任务可以放心混跑。

05 智商测验：13/14，还纠正了出题人

一套带陷阱的自建题（temperature=0，单次采样）：

• 数学 4/4：水池三管齐开、涨价降价、平均速度 48、高斯求和，全对；
• 陷阱题 2/2：9.11 vs 9.9 答对；更妙的是 x²-19x+91 的质数解——它指出判别式是 -3、无实根。这题我们预设的"标准答案"本身是错的，模型没顺着题干走；
• 逻辑 2/2：Sally 的姐妹、真话假话随机三人指认，推理链完整；
• 编程 3/3：LIS O(n log n)、星期计算、严格 IPv4 校验，代码全部自动执行验证，300 组随机数据全过；
• 工具调用 3/3：查北京天气→正确返回 tool_calls 和参数；查北京+上海→一轮并行返回两个调用；问 1+1→不误调用直接回答。--enable-auto-tool-choice + qwen3_coder 解析器，Agent 工作流可以直接接；
• 翻车 1 次：2019 图灵奖，一本正经地编造了"Wulf 与 Main（并行计算）"——正确答案是 Catmull 与 Hanrahan。冷门事实记忆不可信，知识问答必须外挂检索；
• 另一个短板：竞赛级难题思考失控，给了 16,384 token 预算，思考链跑满仍未收敛，零正文输出。

一句话定位：常规工程数学/逻辑/编码是一线开源 30B 旗舰水平；极端推理和闭卷事实是短板。

06 256K 上下文：能塞，也能捞

在 31K/92K/255K 三档长文里各埋一根"针"（格式化密钥），从 5% 到 95% 深度共 11 个测试位——全部命中。255K 全文预填约 100 秒。

但边界也摸到了：

• 服务端按 prompt + max_tokens ≤ 262,144 校验，超限直接拒绝；
• 5 根针按"最接近 50% 位置"这种细粒度辨别，255K 处开始出错；
• 关键业务建议按 ≤128K 有效上下文规划，留足余量。

07 踩坑清单（拿走不谢）

1. max_tokens 包含思考 token。给 512 预算，模型思考完预算耗尽，正文返回空字符串。生成类请求 max_tokens ≥ 2048，检索类请求直接关思考（快一倍）；
2. 超长输入要给客户端设 ≥180 秒超时（240K 预填 ≈ 90 秒）；
3. 评测/压测务必随机化填充文本，否则前缀缓存让数据虚高；
4. 保持提示词前缀稳定（系统词、文档顺序固定）= 免费的 14 倍加速；
5. 事实性问答必须外挂知识库，模型冷门知识会编。

08 这台机器适合干什么

适合：团队级代码助手（编码实测扎实）、带工具调用的 Agent/API 后端（实测通过）、多轮对话客服（前缀缓存加持）、中等规模 RAG（128K 内检索可靠）、内部工具的 LLM 后端（64~96 路并发无压力）。

不适合：超高并发公共服务（2.3K tok/s 封顶）、竞赛数学类深度推理（思考不收敛）、闭卷知识问答（会幻觉）。

09 如果只有两张 4090，会怎样？

先澄清一个容易混淆的概念（也被细心的读者问到了）：INT4 ≠ KV cache 精度。INT4/AWQ 量化的是模型权重，决定模型占多少显存、读多快；KV cache 是推理时为每个请求保存的注意力中间状态，它的精度（FP16 或 FP8）是 vLLM 的另一个独立开关。两者可以任意组合，互不矛盾——本机启动参数里 --quantization（INT4 权重）与 --kv-cache-dtype fp8_e4m3（FP8 KV）就是同时开着的，实测的 163 万 token 容量正是这对组合的结果。

然后是本文写作过程中的一个小插曲：我们先给出了双卡预测，然后真的把服务器切成双卡（CUDA_VISIBLE_DEVICES=3,4，TP=2，其余参数不变）复测了一遍。预测 vs 实测，有准的也有打脸的：

指标	4 卡实测	预测 2 卡	2 卡实测	预测评价
KV cache 总容量	1,629K	600~700K	469K	偏乐观
256K 上下文	余量 6.2×	可保留	可用，余量 1.79×	✓
同时满长度请求	~6 路	~2 路	仅 1 路	偏乐观
单流 decode	~108 tok/s	90~110	79 tok/s	✗ 打脸
聚合 decode 饱和	~2,274 tok/s	1,200~1,500	~1,560 tok/s	✓
预填峰值	~4,400 tok/s	2,200~2,500	~3,200 tok/s	偏悲观
240K 预填耗时	89.7 s	~2 倍	128.7 s（×1.43）	偏悲观
255K 大海捞针	命中	—	命中（145.5s）	✓

双卡实测的四个关键结论：

1. 256K 上下文完好：254,827 token 的全文大海捞针依然命中，只是耗时从 ~100s 涨到 145.5s。但 KV 余量只剩 1.79×——满长度请求同时只能跑 1 路（两路并行需每路 ≤ ~230K）。
2. 预填充好于"减半"直觉：双卡拿到四卡 73% 的预填速率（32K 峰值 ~3,200 tok/s）。TP=2 的通信开销显著低于 TP=4，单卡效率反而更高——反向印证了四卡 PCIe 通信吃收益的判断。
3. 单流确实变慢（108 → 79 tok/s）：TP=2 每卡权重分片翻倍，之前"未必变慢"的预测错了。
4. 并发拐点 64 路：96/128 路零失败但 TTFT p95 跳到 11~13 秒（排队），生产限流建议 48~64 路。

双实例复制（DP=2）选项依然成立：每卡一个独立实例，无 TP 通信开销，合计吞吐有望高于 TP=2 的 ~1,560 tok/s，附带故障隔离；代价是单实例 KV 只剩 ~200K 出头，max_model_len 需降到 ~128K。

选型口诀（双卡实测版）：要单路 256K 长文档，现有 TP=2 配置即可（但同时仅 1 路）；要高并发中短上下文，换双实例复制（每实例 ≤128K）。

总结

所有测试均在真实局域网环境完成：吞吐用服务端 Prometheus 计数器交叉核对；预填曲线排除了缓存与生成干扰；代码题自动执行验证；大海捞针用随机唯一文本；KV 容量通过"19.8 万 token 唯一请求 + 采样 kv_cache_usage_perc 峰值"反推实测；工具调用按 OpenAI 兼容格式实测（单工具/并行/控制组）。启动命令与测试脚本、原始数据全部保留，可复现。

如果你也打算自部署开源模型，希望这份"体检报告"能帮你少踩几个坑。