三个场景使用相同模型（Qwen3-32B）和相同集群（H800×8 + L40S×16），通过不同的流量特征和 SLO 约束验证系统在不同工作负载下的决策差异。
| 场景一：客服 Chat | 场景二：长文本生成 | 场景三：混合流量 | |
|---|---|---|---|
| 请求数 | 500 | 300 | 400 |
| 输入 P50/P90/P99 | 3568/4668/4977 | 487/764/793 | 1281/4487/5751 |
| 输出 P50/P90/P99 | 304/469/498 | 2763/3740/3953 | 458/2113/2987 |
| 输入/输出比 | 11.5（极重 prefill） | 0.2（极重 decode） | 2.2（混合） |
| Prefix 覆盖率 | 100% | 9% | 51% |
| Prefix 复用率 | 0.99 | 0.50 | 0.99 |
| Interactive 占比 | 91% | 60% | 76% |
| TTFT SLO | 800ms（严格） | 2000ms（宽松） | 1500ms（中等） |
| ITL SLO | 45ms | 35ms（严格） | 50ms（宽松） |
| 最大 GPU 数 | 8 | 8 | 16 |
| 容量余量要求 | 20% | 15% | 15% |
| 场景一 | 场景二 | 场景三 | |
|---|---|---|---|
| GPU 池 | H800 NVLink | H800 NVLink | H800 NVLink |
| TP / PP | 4 / 1 | 4 / 1 | 4 / 1 |
| 精度 | FP8 | FP8 | FP8 |
| 副本数 | 1 | 1 | 1 |
| Prefix Cache | ✅ 启用 | ❌ 关闭 | ✅ 启用 |
| Chunked Prefill | ✅ 启用 | ❌ 关闭 | ✅ 启用 |
| Prefill Chunk Size | 2048 | 1024 | 1024 |
| max_num_batched_tokens | 16384 | 6104 | 16384 |
| max_num_seqs | 16 | 16 | 16 |
| KV Cache Dtype | auto (bf16) | auto (bf16) | auto (bf16) |
| 预估单卡显存 | 21.8 GB | 21.0 GB | 25.3 GB |
| 预估 TTFT | 605ms | 99ms | 575ms |
| 预估 ITL | 16ms | 16ms | 16ms |
| 每小时成本 | $14.0 | $14.0 | $14.0 |
| 容量余量 | 96.5% | 87.9% | 97.6% |
| 场景一 | 场景二 | 场景三 | |
|---|---|---|---|
| 操作 | scale_replicas → 2 | 无（稳定） | 无（稳定） |
| 原因 | TTFT 连续 4 窗口违反 | 所有指标正常 | 所有指标正常 |
| 风险等级 | low | — | — |
核心特征：输入极长（P90=4668）、输出短、100% 请求携带 prefix、TTFT 要求严格。
决策逻辑：
- Prefix Cache 启用 — 覆盖率 100% + 复用率 99%，几乎所有请求都命中缓存，大幅节省 prefill 计算
- Chunked Prefill 启用 — 输入 P90=4668 远超 2048 阈值，需要分块处理避免单次 prefill 阻塞 decode
- Prefill Chunk Size=2048 — 输入 P50=3568 > 2048，选择较大分块以平衡 prefill 吞吐和 decode 延迟
- Reconcile 扩容 — Telemetry 显示 TTFT 连续违反 SLO（800ms），单副本在流量高峰时吞吐不足
为什么选 H800 而非 L40S：TTFT SLO 仅 800ms，L40S PCIe 通信惩罚 1.3× 会使 TTFT 从 605ms 升至 ~787ms，逼近 SLO 边界且无余量。
核心特征：输入极短（P90=764）、输出极长（P90=3740）、几乎无 prefix、ITL 要求严格。
决策逻辑：
- Prefix Cache 关闭 — 覆盖率仅 9%，91% 的请求完全无法受益，启用只会浪费显存
- Chunked Prefill 关闭 — 输入 P90=764 远低于 2048，单次 prefill 即可完成，无需分块
- max_num_batched_tokens=6104 — 输出长序列占用大量 decode 时间，限制 batch token 数避免单请求被过度延迟
- TTFT 极低（99ms） — 输入短，prefill 几乎不耗时
- Reconcile 无操作 — ITL 16ms 远低于 35ms SLO，系统运行健康
为什么显存更低（21.0 GB）：输入短导致 KV Cache 的 context_length 估算更小（P99 input + P99 output ≈ 4746 vs 场景一的 5465）。
核心特征：输入长度跨度极大（P50=1281, P99=5751）、输出中等偏长、51% 请求有 prefix。
决策逻辑：
- Prefix Cache 启用 — 覆盖率 51% + 复用率 99%，超过半数请求可受益且命中率极高
- Chunked Prefill 启用 — 输入 P90=4487 > 2048，长尾请求需要分块
- Prefill Chunk Size=1024 — 输入 P50=1281 接近 1024，选择较小分块以更好地交错 decode
- 显存最高（25.3 GB） — 输入 P99=5751 + 输出 P99=2987，context_length 估算最大
- Reconcile 无操作 — SLO 宽松（TTFT 1500ms），容量余量 97.6%
为什么 max_gpu_count=16 但只用了 4：FP8 TP=4 单副本已满足 SLO，无需更多资源。成本优先目标下不会过度配置。
三个场景都选择了 H800 TP=4 FP8 PP=1 单副本，原因：
- Qwen3-32B FP8 在 TP=4 下单卡权重仅 ~7.5 GB，80 GB H800 有充足余量
- TP=4 是满足
num_kv_heads=8整除约束的最小有效 TP（TP=2 也可以，但 TP=4 延迟更低） - FP8 相比 BF16 显存减半，且质量损失 <0.5% 在 0.99 阈值内
- PP=1 避免 pipeline bubble 带来的延迟增加
- H800 NVLink 的通信惩罚为 1.0，比 L40S PCIe 的 1.3+ 更优
差异化体现在功能开关和 batch 参数，而非基础架构选择——这是合理的，因为模型和集群相同，不同的是工作负载特征。