问题：为什么单纯的 QPS 限制会失效？

在部署 DeepSeek-V4 推理服务时，多数团队首先想到的是通过 API Gateway 设置全局 QPS 限制。但当遇到以下场景时，这种粗粒度控制会失效： - 突发流量导致部分节点过载，而其他节点闲置 - 长文本请求挤占 KV Cache 内存，引发 OOM - 高优先级业务被普通流量阻塞

更本质的矛盾在于：LLM 推理是有状态服务，传统无状态服务的限流策略无法处理： 1. 内存压力非线性增长：输入长度与显存占用并非1:1关系，受 paged attention 分块策略影响 2. 计算耗时波动大：生成式任务存在输出长度不可预测性 3. 多租户资源竞争：不同业务线的请求特征差异显著

熔断设计的三层防线

1. 单机级动态配额（Token Bucket + 滑动窗口）

• 动态权重：根据当前 GPU 显存利用率调整令牌生成速率

  # 伪代码示例：基于显存压力的动态限流
  def adjust_rate():
      mem_usage = get_gpu_memory_utilization()
      base_rate = 100  # 默认QPS
      if mem_usage > 0.8:
          return base_rate * 0.6  # 显存压力大时降速
      return base_rate

• 请求特征感知：
• 对输入 token 数超过 8k 的请求单独计数
• 为流式响应预留缓冲区（避免半截中断）

2. 集群级熔断（基于 Prometheus + 自适应阈值）

• 指标采集：
• 各节点 P99 延迟（需区分首token/生成阶段）
• 显存碎片率（vLLM 的 block 分配状态）
• 错误响应率（含 429/503，需排除客户端主动取消）
• 熔断策略：

3. 业务级配额（多租户隔离）

• 通过请求头 X-Tenant-ID 区分业务线
• 分级保障机制：
• 关键业务：固定预留30%计算单元
• 普通业务：共享剩余资源+弹性扩容
• 低优先级：允许被强中断（牺牲完整性）

DeepSeek-V4 的特别优化

1. KV Cache 预判机制：
2. 在请求准入阶段根据输入长度和 max_tokens 参数，预估最大内存占用

3. 对可能触发 OOM 的请求提前拒绝（返回 429 并附带预估内存需求）

4. 投机解码的熔断协同：

5. 当节点负载过高时自动减少候选分支数（从默认4分支降为2分支）

6. 动态调整 draft model 的调用频率（基于当前 P95延迟）

7. 长上下文专项处理：

8. 为超过32k token的请求分配专属节点组
9. 采用不同的 attention 分块策略（128 vs 256 tokens/block）

实施检查清单

✅ 部署指标暴露（必备项）

• 基础指标：
• 各节点 vLLM 引擎的 running_requests
• PagedAttention 的 cache_utilization
• 采样阶段耗时占比（prefill vs decoding）
• 业务指标：
• 各租户的请求成功率（按输入长度分段统计）
• 被拒绝请求的分布特征

✅ 分级熔断测试

1. 单节点极限测试：
2. 逐步增加并发直到触发 OOM，记录：
   • 熔断触发延迟（从指标异常到动作执行）
   • 错误恢复耗时
3. 集群故障演练：
4. 随机杀死1个节点，观察：
   • 流量迁移速度（依赖服务发现机制）
   • 业务波动范围

✅ 业务影响评估

• SLA 监控：
• 核心业务的成功率下降不得>5%
• 普通请求的排队超时率<3%
• 成本审计：
• 熔断导致的算力闲置比例
• 资源预留带来的额外支出

边界与取舍

⚠️ 熔断敏感度调优： - 对 /generate_stream 采用宽松策略（避免中断用户体验） - 对 /batch 接口实施严格限制（防止批量请求拖垮集群）

⚠️ 长文档场景专用化： - RAG 场景建议： - 部署专用节点组（高内存机型） - 关闭动态批处理（static batching） - 采用更高比例的 FP16 量化

实际部署中，我们观察到当熔断阈值设置为理论值的80%时，能在稳定性与吞吐之间取得最佳平衡。例如对于 A100-80G 节点，应将 OOM 预警线设为56GB（而非80GB），为突发流量留出缓冲空间。