当 DeepSeek-V4 推理服务 QPS 突破 500 时，我们经历了三次因未配置熔断策略导致的级联故障。以下是血泪换来的生产级稳定性 checklist：

1. 限流策略的致命盲区

• 静态配额陷阱：按用户分配固定 QPS 配额（如 10/s）会引发突发流量雪崩。实测发现，当 20% 用户同时超限时，vLLM 的 KV cache 内存会以 3 倍速率增长。更危险的是，静态配额无法感知底层硬件状态，当 GPU 显存碎片化严重时，即使 QPS 未超标也可能 OOM。
• 动态算法选择：
• 令牌桶（适合长周期平滑）：rate=1000, capacity=今年 是 DeepSeek-V4 128K 上下文下的经验值
• 漏桶（硬限流但高延迟）：仅建议用于支付等强一致性场景
• 自适应窗口（推荐）：基于 P99 延迟动态调整，需配合 rolling_period=30s
• 关键参数：burst_capacity=2*avg_rate 必须设置，否则突发流量直接击穿。我们曾因忽略此参数导致 50% 的 8K token 长文本请求被误杀。

2. 熔断不只是 5xx 状态码

• 熔断指标三维度（缺一不可）：
• 错误率 ≥15%（含 429/503）：注意将模型自身错误（如内容过滤）与系统错误分离统计
• P99 延迟 ≥1.5*SLO（如 3s）：需排除预填充阶段的正常耗时
• 显存利用率 ≥85%（vLLM 特有）：需区分整体利用率和最大单卡峰值
• 级联熔断配置：

  # 使用 envoy 的 outlier_detection
  consecutive_gateway_failure: 3  # 必须大于等于vLLM重试次数
  enforcing_success_rate: 80       # 低于此值触发熔断
  max_ejection_percent: 30         # 必须小于50%避免雪崩
  base_ejection_time: 30s          # 初始熔断时长

  注意：当 DeepSeek-V4 启用连续批处理时，需将 base_ejection_time 设为批次间隔的 3 倍以上。

3. 降级不是性能阉割

• 分级降级策略：

4. 灰度发布里的 token 会计

• 流量染色三原则：
• 按 UserID 哈希分桶（非随机！）：确保长文本用户均匀分布
• 新版本初始权重 ≤5%：对于 DeepSeek-V4 这类百亿参数模型尤其重要
• 必须包含长文本（>4k tokens）请求：普通请求无法暴露内存泄漏问题
• 放量判据：当且仅当同时满足
• 错误率差值 <2%（统计显著性 p<0.05）
• 显存占用波动 <5%（需排除预分配块）
• 第95百分位输出长度差异 <10%（防止长文本生成质量劣化）

5. 告警配置反模式

• 必报警项：
• 单卡显存 >90% 持续1分钟（不是瞬时！）：结合 nvidia-smi -l 1 监控
• 同一模型副本连续3次预热失败：可能提示 CUDA 版本不兼容
• 路由层重试率 >20%：通常意味着负载均衡失效
• 不必报警：
• 短时 CPU 飙高（vLLM 的调度特性）：除非持续超过5分钟
• 单次预填充超时（可能只是长上下文）：仅当超时率>10%才报警

6. 复盘模板中的技术债

每次故障复盘必须包含： 1. Token 分布直方图（抓长尾）：特别关注 >8K tokens 的请求占比 2. vLLM 批次调度轨迹（gantt 图）：使用 nvtx 标记各阶段耗时 3. 熔断器状态转换日志：记录从检测到恢复的全链路 4. 显存碎片率变化曲线：通过 memory_stats API 获取

7. DeepSeek-V4 专属优化项

• PagedAttention 调优：
• block_size=16 对 128K 上下文最友好
• 监控 block_alloc_ratio 指标，>0.9 时需要扩容
• 冷启动预热：

  # 预热命令示例
  curl -X POST "http://localhost:8000/generate" \
    -H "Content-Type: application/json" \
    -d '{"prompt":"热身", "max_tokens":1, "ignore_eos":true}'

  需要连续发送 20-30 个请求才能稳定 KV cache

8. 成本与稳定性权衡

我们发现当采用如下配置时，能在成本增加15%的前提下将可用性从 99.5% 提升到 99.95%： - 保留 20% 的冗余计算节点 - 对 >4K tokens 请求启用专属计算资源池 - 为高频用户单独部署模型副本

最终 checklist 的执行要点： 1. 所有策略必须通过混沌工程验证（如模拟显存耗尽） 2. 监控看板要区分系统指标和模型质量指标 3. 定期测试熔断恢复流程（至少每月一次） 4. 记录每次降级决策的业务影响（需产品团队签字确认）

当采用 DeepSeek-V4 的 paged attention 时，上述策略需要额外注意： - 每个请求的 block 数会动态变化，传统的 QPS 限流可能不准确 - 传统 CPU 指标可能失真，需直接监控 GPU 内存带宽 - 重试请求必须携带原 attention mask 指纹，否则会破坏因果性