Qwen3.5-27B：18 tok/s。Qwen3.6-35B：11 tok/s。gemma-4-26B 双卡：93 tok/s。同样是 L40S，模型选错速度差 8 倍。这篇用真实测试数据告诉你，哪个模型值得你的 GPU 时间。
测试方法
自己写了一个 benchmark 脚本（bench_model.py），核心逻辑：
- Warm-up：每个场景先跑 2 次预热，不计入统计
- 多次运行：每个场景跑 3 次，取中位数
- 测试矩阵：4 种输入长度（512/2K/8K/32K）× 4 种并发度（1/2/4/8）
- 输出固定 512 tokens
- 指标：TPS（tokens/s）、TTFT（首 token 延迟）、TPOT（每 token 延迟）
所有测试在同一节点上完成，3 张卡各跑一个模型并行测试。
测试环境
| 项目 | 配置 |
|---|---|
| GPU | 单卡 NVIDIA L40S 48GB |
| vLLM | v0.19.1（Qwen3.5/Gemma4），latest（Qwen3.6） |
| 优化 | --kv-cache-dtype=fp8 --enable-prefix-caching --enable-chunked-prefill |
三个模型的关键差异：
| 模型 | 架构 | 精度 | 权重大小 | max-model-len | CUDA Graph |
|---|---|---|---|---|---|
| Qwen3.5-27B-FP8 | Dense | FP8 | ~28GB | 128K | ✅ |
| Qwen3.6-35B-A3B-FP8 | MoE 128E/8A | FP8 | ~34GB | 64K | ❌ enforce-eager |
| Gemma4-31B-FP8 | Dense | FP8 | ~31GB | 128K | ✅ |
单请求吞吐（c=1）
最基础的指标——一个请求，模型能跑多快：
| 模型 | 512 输入 | 2K 输入 | 8K 输入 | 32K 输入 |
|---|---|---|---|---|
| Qwen3.5-27B | 18.1 tok/s | 18.5 tok/s | 18.3 tok/s | 16.2 tok/s |
| Qwen3.6-35B | 11.0 tok/s | 11.1 tok/s | 10.9 tok/s | ❌ OOM |
| Gemma4-31B | 17.4 tok/s | 17.2 tok/s | 16.7 tok/s | ❌ OOM |
关键发现：
- Qwen3.5 最快，18 tok/s 稳定输出，32K 长文本也只降到 16.2
- Gemma4 接近 Qwen3.5，但 32K 输入 OOM（31B 权重占了太多显存，KV Cache 不够）
- Qwen3.6 最慢，只有 11 tok/s。原因是
enforce-eager（没有 CUDA Graph 加速）+ MoE 架构的 Expert 路由开销
并发吞吐（c=8）
8 个并发请求同时打：
| 模型 | 512 输入 | 2K 输入 | 8K 输入 |
|---|---|---|---|
| Qwen3.5-27B | 130.3 tok/s | 130.1 tok/s | 100.8 tok/s |
| Qwen3.6-35B | 83.6 tok/s | 82.0 tok/s | 80.9 tok/s |
| Gemma4-31B | 132.0 tok/s | 129.5 tok/s | 126.2 tok/s |
Gemma4 在高并发下反超 Qwen3.5！原因是 Gemma4 的 KV Cache 更大（7GB vs Qwen3.5 的 10GB），在 8K 输入时 Qwen3.5 开始受 KV Cache 容量限制，吞吐下降到 100.8。
延迟指标
| 模型 | TTFT (512in, c=1) | TTFT (8Kin, c=1) | TPOT (c=1) | TPOT (c=8) |
|---|---|---|---|---|
| Qwen3.5 | 1,224 ms | 1,599 ms | 53.0 ms | 57.3 ms |
| Qwen3.6 | 1,148 ms | 1,839 ms | 88.3 ms | 92.3 ms |
| Gemma4 | 1,025 ms | 1,675 ms | 55.4 ms | 57.8 ms |
- TTFT（首 token 延迟）：Gemma4 最快，因为 prefill 阶段 Dense 架构比 MoE 高效
- TPOT（每 token 延迟）：Qwen3.5 最低 53ms，Qwen3.6 因为 enforce-eager 高达 88ms
并发扩展性
所有模型都展现了近线性的并发扩展：
| 模型 | c=1 | c=2 | c=4 | c=8 | 扩展比 |
|---|---|---|---|---|---|
| Qwen3.5 | 18.1 | 36.9 | 73.1 | 130.3 | 7.2× ✅ |
| Qwen3.6 | 11.0 | 21.3 | 42.1 | 83.6 | 7.6× ✅ |
| Gemma4 | 17.4 | 34.3 | 67.9 | 132.0 | 7.6× ✅ |
8 并发达到 7.2-7.6× 的扩展，说明 vLLM 的 continuous batching 在 L40S 上工作良好。
历史对比：单卡 vs 双卡
之前还测过 TP=2（双卡）的配置：
| 模型 | 卡数 | c=1 | c=8 | TPOT |
|---|---|---|---|---|
| gemma-4-26B-A4B BF16 | 2 | 93.0 | 536.9 | 9.1 ms |
| Qwen3.5-27B-Int4 | 1 | 24.5 | 167.3 | 39.0 ms |
| Qwen3.5-27B-FP8 | 1 | 18.1 | 130.3 | 53.0 ms |
gemma-4-26B-A4B 双卡 BF16 是性能怪兽：93 tok/s 单请求，537 tok/s 并发。MoE 架构（4B 活跃参数）+ 双卡 + BF16 精度 = 极致速度。但它占两张卡，在"一卡一模型"的方案里用不了。
另一个有趣的发现：Int4 比 FP8 快（24.5 vs 18.1 tok/s）。Int4 权重更小（~15GB vs ~28GB），更多显存给 KV Cache，decode 阶段的显存带宽压力更小。代价是精度损失，需要评测验证。
结论
在单卡 L40S 48GB 上：
- 追求质量+速度平衡：Qwen3.5-27B-FP8（18 tok/s，76.6% 质量）
- 追求极致吞吐：Gemma4-31B-FP8（132 tok/s @c=8，但长文本 OOM）
- 不推荐：Qwen3.6-35B-A3B-FP8（enforce-eager 拖累太大，11 tok/s）
下一篇讲质量评测——速度快不代表回答好，160 道题 6 个维度的评测结果。