8.3 大流量稳定性：限流、降级与过载保护

8.3 大流量稳定性：限流、降级与过载保护

推理服务扩容要分钟级，但流量暴增可能秒级——营销活动、产品爆红、突发事件都可能在几分钟内把流量推到平时的几十倍。如果没有限流降级，超载会让所有用户体验崩塌，引发雪崩。这一节讲清「扛不住时怎么保命」。

8.3.1 大流量冲击的本质

LLM 推理服务面对的大流量冲击有几类：

• 业务活动：营销推送、产品发布、限时免费。
• 产品爆红：社交媒体传播导致用户激增。
• 上游故障转移：另一个集群挂了，流量涌到本集群。
• 依赖故障：模型加载失败、缓存击穿、网络抖动导致请求堆积。
• 慢请求累积：长上下文请求耗时长，积压成洪峰。

冲击的核心问题是「容量跟不上流量」——扩容要分钟级，冲击是秒级，必然有「容量缺口」。这个缺口期间，必须靠「限流降级」保护系统不崩溃。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 280" font-family="sans-serif" font-size="12">
  <text x="360" y="22" text-anchor="middle" font-size="15" font-weight="bold">大流量冲击下的容量缺口</text>

  <!-- 流量曲线 -->
  <path d="M 40 220 Q 150 220 200 80 L 400 80 Q 500 80 680 220" fill="none" stroke="#dc2626" stroke-width="3"/>
  <text x="600" y="100" font-size="11" fill="#dc2626">流量（突发）</text>

  <!-- 容量曲线 -->
  <path d="M 40 220 L 200 220 Q 280 220 350 180 L 500 130 L 680 100" fill="none" stroke="#16a34a" stroke-width="3"/>
  <text x="600" y="135" font-size="11" fill="#16a34a">容量（扩容滞后）</text>

  <!-- 缺口区域 -->
  <path d="M 200 80 L 400 80 L 350 180 Q 280 220 200 220 Z" fill="#fee2e2" opacity="0.7"/>

  <text x="280" y="160" text-anchor="middle" font-size="11" fill="#dc2626" font-weight="bold">容量缺口</text>
  <text x="280" y="180" text-anchor="middle" font-size="10" fill="#dc2626">→ 需要限流降级保护</text>

  <text x="360" y="255" text-anchor="middle" font-size="11" fill="#475569">扩容慢、流量快，缺口期间靠限流降级保命</text>
</svg>
​

💡 判读：大流量稳定性的核心是「承认扛不住」——不要幻想能扩容赶超突发流量，而要预设「会有容量缺口」，用限流降级让系统在缺口期间「优雅劣化」而非「崩溃雪崩」。

8.3.2 限流：让超量请求「礼貌拒绝」

限流（Rate Limiting） 是大流量保护的第一道防线。它的核心是「控制单位时间处理的请求数」，超出的请求被拒绝或排队。

主流限流算法：

令牌桶（Token Bucket）

• 桶里持续放令牌（按速率 R）。
• 请求来时取一个令牌，有则处理、无则拒绝/排队。
• 桶有容量上限（突发容量），允许短时突发。
• 适合大多数场景（允许一定突发）。

令牌桶数学：
    令牌按速率 R 入桶，桶容量 C
    请求消耗 1 令牌
    长期平均速率 ≤ R，短时突发 ≤ C
​

漏桶（Leaky Bucket）

• 请求进桶，按固定速率 R 出桶（处理）。
• 桶满则拒绝新请求。
• 严格平滑，不允许突发。
• 适合需要严格限速的场景。

滑动窗口（Sliding Window）

• 按时间窗口统计请求数，超过阈值拒绝。
• 比固定窗口更精确（避免窗口边界突发）。
• 适合按用户/IP 限流。

多维度限流

LLM 服务常需要多维度限流：

• 全局 QPS 限流：保护总容量。
• 用户级限流：防止单用户滥用（免费用户更严）。
• token 级限流：LLM 按生成 token 计费，按 token 数限流更合理。
• 并发数限流：限制同时处理的请求数（防止 KV Cache 占满）。

8.3.3 请求排队与优先级

被限流的请求不一定要立即拒绝，可以排队等待。这需要：

• 队列：维护等待中的请求，按 FIFO 或优先级处理。
• 超时机制：排队超过阈值（如 30 秒）自动失败，避免无限等待。
• 队列监控：队列长度作为扩缩容信号（8.2 节 KEDA 触发器）。

优先级队列

不同请求设不同优先级，高优先级先处理：

这种「优先级分层」让有限容量优先服务高价值用户，是大流量期间的常见策略。

排队的代价

排队不是免费的——它把「拒绝」换成「等待」，但等待过长用户体验仍差。生产中要：

• 设合理超时（如 30 秒）。
• 队列长度监控 + 告警。
• 排队时返回「预计等待时间」，让用户决策。

8.3.4 降级：用小模型或简化逻辑保命

当限流不够、排队也满时，最后一道防线是「降级（Degradation）」——用更便宜的方式响应，保证「有响应」而非「无响应」。

LLM 推理服务的降级策略：

模型降级（小模型路由）

主模型（如 70B）撑不住时，路由到小模型（如 7B）：

• 小模型推理快 10 倍、成本低 10 倍。
• 质量略降但「有响应」优于「无响应」。
• 常用于：免费用户、超时边缘请求、内部场景。

响应降级

• 截断长回复：限制生成 token 数（如从 4K 截到 1K）。
• 关闭流式：改批量返回（减少 token 数但增加单请求延迟）。
• 简化 prompt：去掉 few-shot 示例、缩短 system prompt。

功能降级

• 禁用工具调用：Agent 场景关闭工具调用，只做单轮回复。
• 禁用多模态：图像输入降级为「不支持」。
• 禁用长上下文：限制最大上下文长度。

缓存降级

• 相同 query 命中缓存直接返回（虽不精确但有响应）。
• 「热门 query 预生成」：热门问题预先用大模型生成缓存。

💡 判读：降级的核心哲学是「优雅劣化（Graceful Degradation）」——承认在极端情况下无法保证最优体验，但保证「可用性」。这比「直接崩溃」对用户友好得多。降级要预先设计、自动化触发，不能临时人工决策。

8.3.5 熔断：保护依赖不拖垮自己

熔断器（Circuit Breaker） 模式来自电气工程——电流过大时保险丝熔断，保护电路。在软件中，熔断器监控对依赖的调用，失败率超阈值时「熔断」（停止调用），一段时间后「半开」（试探性调用），成功则「闭合」（恢复调用）。

LLM 服务中熔断的应用：

• 下游依赖熔断：模型服务、特征存储、向量数据库等依赖，失败率超阈值时熔断，避免拖垮主流程。
• 自身保护熔断：自身错误率超阈值时，主动熔断（拒绝新请求），避免雪崩。

熔断的三个状态：

8.3.6 过载保护与雪崩防止

雪崩（Cascading Failure） 是大流量最可怕的后果——一个组件超载，导致依赖它的组件也超载，连锁崩溃。LLM 推理服务的雪崩路径：

流量突增 → 推理 Pod 排队 → Pod 内存/CPU 飙升 → Pod OOM/重启
→ 副本数减少 → 剩余副本负载更高 → 更多副本崩溃
→ 雪崩
​

防止雪崩的几个机制：

背压（Backpressure）

下游撑不住时，主动告诉上游「慢点发」，而非「全收下然后崩」。LLM 服务的背压：

• 队列满时返回 429，让客户端退避重试。
• 流式生成慢时降低 token 速率。

舱壁隔离（Bulkhead）

把资源按用途隔离，互不影响：

• 推理 Pod 与训练 Pod 隔离（第 3 章节点池）。
• 不同模型/不同用户组用独立 Pod 池。
• 一个池崩了不影响其他。

超时与重试控制

• 超时：所有请求设超时，避免无限等待拖垮资源。
• 重试上限：失败重试要限次（如最多 3 次），避免重试风暴。
• 退避策略：重试间隔指数退避（如 1s, 2s, 4s），避免同步重试。

容量预留

• 永远预留一定冗余（如平时只用到 70% 容量），应对突发。
• 关键路径（如登录、支付）预留独立容量，永不与 LLM 推理争抢。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 720 280" font-family="sans-serif" font-size="12">
  <text x="360" y="22" text-anchor="middle" font-size="15" font-weight="bold">雪崩与防护</text>

  <!-- 雪崩路径 -->
  <rect x="40" y="50" width="640" height="80" rx="6" fill="#fee2e2" stroke="#dc2626"/>
  <text x="60" y="75" font-weight="bold" fill="#991b1b">雪崩路径（无防护）：</text>
  <text x="60" y="95" font-size="11">流量突增 → 排队 → Pod 超载 → OOM/重启 → 副本减少 → 剩余超载 → 全面崩溃</text>
  <text x="60" y="115" font-size="11" fill="#dc2626" font-style="italic">连锁反应，雪球越滚越大</text>

  <!-- 防护机制 -->
  <rect x="40" y="150" width="640" height="120" rx="6" fill="#dcfce7" stroke="#16a34a"/>
  <text x="60" y="175" font-weight="bold" fill="#15803d">防护机制（4 道）：</text>
  <text x="60" y="197" font-size="11">1. 限流（令牌桶）→ 控制入口流量</text>
  <text x="60" y="217" font-size="11">2. 排队 + 超时 → 让等待有上限</text>
  <text x="60" y="237" font-size="11">3. 熔断 → 切断故障依赖</text>
  <text x="60" y="257" font-size="11">4. 背压 + 舱壁 + 容量预留 → 阻断连锁</text>
</svg>
​

8.3.7 限流降级的整体架构

把上述机制组合，一个生产级 LLM 推理服务的稳定性架构：

这套架构实现了「入口限流 + 队列优先级 + 熔断保护 + 多级降级 + 自动扩缩」的完整稳定性保障，是大流量 LLM 服务的标准设计。

8.3.8 混沌工程：主动验证稳定性

稳定性策略设计得再好，也要主动验证——否则真出事时才发现漏洞。混沌工程（Chaos Engineering） 通过主动注入故障，验证系统的稳定性。

LLM 服务的混沌实验：

著名的混沌工程工具：

• Chaos Mesh：CNCF 项目，K8s 原生混沌平台。
• Litmus：CNCF 项目，云原生混沌工程。
• Gremlin：商业混沌工程平台。

💡 判读：混沌工程的核心理念是「主动制造故障」而非「被动等待故障」。通过常态化的小规模混沌实验，在故障真正发生前发现并修复稳定性漏洞。Netflix 的 Chaos Monkey 是这一实践的鼻祖，AI 服务同样适用。

8.3.9 稳定性的工程实践

落地稳定性的几个工程实践：

1. SLO 驱动：所有稳定性策略以 SLO 为目标，避免过度设计或不足。
2. 分层防护：入口限流、队列优先级、熔断、降级，层层设防。
3. 自动化优先：限流降级要自动化，不要靠人工 oncall。
4. 混沌常态化：定期（每月）做混沌实验，验证稳定性。
5. 降级预案预演：定期演练降级（如真切换到小模型），确保真出事能用。
6. 可观测配套：限流数、降级数、熔断数都要监控告警。
7. 复盘文化：每次故障都做 postmortem，沉淀经验。

本节小结

• 大流量冲击的容量缺口期间，要靠限流降级保护系统不崩溃，核心是「承认扛不住」。
• 限流算法：令牌桶（最常用，允许突发）、漏桶（严格平滑）、滑动窗口（用户级）。
• LLM 多维度限流：全局 QPS、用户级、token 级、并发数。
• 排队与优先级：被限流的请求可排队，付费/重要用户优先，要设超时。
• 降级策略：小模型路由、响应降级（截断/简化）、功能降级（禁工具）、缓存降级。
• 熔断器：闭合/断开/半开三状态，监控依赖失败率，超阈值熔断保护。
• 雪崩防护：背压（让上游慢点）、舱壁隔离（资源分组）、超时与重试控制、容量预留。
• 整体架构：网关限流 + 队列优先级 + 熔断 + 多级降级 + 自动扩缩。
• 混沌工程（Chaos Mesh、Litmus）主动注入故障验证稳定性，常态化运行。
• 工程实践：SLO 驱动、分层防护、自动化、混沌常态化、降级预演、可观测配套、复盘文化。

下一节《8.4 综合案例与未来展望》将用综合案例把全书四层架构串联，并展望未来趋势。