吞吐与延迟的拉锯战

部署 DeepSeek-V4 推理服务时，工程师常陷入两难：增大批处理（batch size）可提升 GPU 利用率，但冷启动请求可能因 KV cache 初始化阻塞关键路径。实测显示，在 A100-80G 上处理 2048 tokens 输入时，批大小从 1 增至 8 可使吞吐量提升 3.2 倍，但 P99 延迟从 87ms 飙升至 210ms。这种非线性关系源于计算资源的竞争模式： 1. 计算密集型阶段：前向计算时 GPU SM 利用率可达 80%+ 2. 内存带宽瓶颈：加载模型参数时显存带宽成为制约因素 3. 调度开销：动态批处理引入的序列管理成本随批大小指数增长

冷启动流量的隐蔽成本

冷启动不仅影响首请求： 1. KV cache 预分配：FP16 模式下，每个序列需要 2 * num_layers * hidden_size * seq_len 的显存，在 32k 上下文场景中，单序列预分配就可能占用 2.4GB。当突发流量到达时，这种预分配可能导致： - OOM 风险增加 47%（基于 vLLM 的实测数据） - 后续请求排队延迟上升 300-500ms 2. 计算图编译：首次执行时的 CUDA kernel 编译延迟可达 500ms-2s，与框架优化程度强相关。使用 TensorRT-LLM 可缓解但需付出额外部署复杂度代价 3. 预热策略失效：单纯定时发送空请求可能触发框架的节流机制，反而加剧资源竞争。更有效的做法是： - 构造真实请求模板（保持典型输入长度分布） - 采用渐进式预热（从 1RPS 逐步提升至目标值） - 监控 CUDA_LAUNCH_BLOCKING=1 环境变量下的内核初始化耗时

可落地的调优清单

并行化路径选择

• vLLM 连续批处理：
• 启用 enforce_eager 模式减少编译延迟，但会损失约 15% 峰值吞吐
• 关键配置项：max_num_seqs=64（过高会导致调度抖动）
• 推荐搭配：block_size=16 平衡内存碎片与并行效率
• SGLang 动态分片：
• 对长文本场景更友好，支持非均匀序列长度
• 需要手动平衡 max_num_seqs 与 max_total_tokens
• 典型问题：短文本请求可能被长文本阻塞
• Ollama 本地部署：
• 适合开发阶段快速验证
• 生产环境需补全：
  • Prometheus 指标暴露（特别是 ollama_inference_duration_seconds_bucket）
  • 请求级日志关联（trace_id 注入）

关键观测点（以 Grafana 为例）

vllm_num_requests_running  # 当前活跃请求数
vllm_num_requests_swapped_out  # 被换出的请求数
vllm_scheduler_running_latency_seconds{pquantile="0.99"}  # P99调度延迟
cuda_memory_usage_bytes{gpu="0",type="used"}  # 显存使用量

当出现以下情况时需要立即干预： 1. swapped_out 持续大于零超过 5 分钟 2. P99 延迟超过 SLA 值的 1.5 倍 3. 显存使用率 >90% 持续 10 分钟以上

深度优化技巧

KV Cache 压缩实战

对于 7B 参数模型，采用 8-bit KV cache 量化可： - 减少 42% 的显存占用 - 增加 11% 的计算耗时（需权衡） 实现方案：

from vllm import EngineArgs
engine_args = EngineArgs(kv_cache_dtype="fp8")  # 需要 Ampere+ GPU

动态批处理调优

推荐梯度调整策略： 1. 初始设置 max_batch_size=4 2. 监控 batch_size_distribution 指标 3. 当 75 分位数 <当前 max_batch_size 时，按 25% 幅度递增

边界条件警示

典型误配置案例

1. 盲目追求高批大小：当 QPS <50 时，批大小超过 4 通常无收益，反而会增加尾延迟
2. 虚假预热：仅调用 /healthz 不会触发计算图编译，需构造真实推理请求（建议使用生产流量录制回放）
3. 动态批处理的陷阱：混合不同长度请求时，可能因填充（padding）导致：
4. 有效吞吐下降 40%
5. 计算浪费率 >15%

硬件选型参考

场景	推荐配置	预期吞吐
短文本高并发	A10G × 2 + 200W 功耗限制	1200 RPM
长文档处理	A100-80G + NVLink	320 RPM
混合负载	H100 PCIe + 4bit量化	680 RPM

上线前检查清单

1. [ ] 压力测试包含冷热启动混合场景（至少 3 次冷启动冲击）
2. [ ] 监控面板包含 scheduler 队列深度指标
3. [ ] 已设置批大小动态调整的上下限（建议 1-16 范围）
4. [ ] 对长文本请求启用单独的处理队列（如 seq_len > 4096）
5. [ ] 验证过 OOM 后的服务自恢复能力（模拟 kill -9 进程）
6. [ ] 建立容量规划模型（建议每 100RPM 预留 10% GPU 余量）

后续优化方向

1. 投机解码：对高概率序列分支提前执行
2. 显存分级：将 KV cache 部分移至 CPU 内存
3. 请求分类：基于输入特征分流到不同优化路径