推理服务优雅降级：L1 到 L3 的分级门禁怎么划

降级这个词在 Web 时代就存在。MDN 对 Graceful degradation 的定义很朴素：先按最新浏览器能力构建应用，在不支持的环境里仍然给出可用的内容和功能。前端靠 CSS 层叠和 Polyfill 做到这件事。推理服务的难度上了一个量级——能降的东西少了，替代物很贵，而“部分不可用”本身就会让 Prompt 语义改变。

我不太赞成把降级当成一道开关。更实际的形态是一个决策中心加几级门禁：指标越过阈值，路由切到下一个分支；指标回落，再逐级退回。腾讯云开发者社区那篇讲高并发大模型降级的文章把等级划成 L0 到 L3 四档，这个骨架可以借鉴，本文谈落地时什么在起作用、什么在骗人。

降级的特殊之处：资源被单点按住

传统服务降级常针对数据库连接池或第三方接口。推理服务的死穴是 GPU 显存和 KV Cache。一次长上下文请求排队进来，KV Cache 按 token 数吃显存；队列一堆积，后面所有请求都在等同一块卡。此时限流只是把入口收窄，已经占住的显存不会自己吐出来。

这决定了降级必须能改“请求形态本身”：缩短最大输出 token、砍掉多轮记忆、降低检索召回条数、换小模型。网关层放行多少请求是必要条件，但不充分。

先分清限流、熔断、降级

三者常被混着用。限流管入口速率，不改变应答逻辑；熔断在依赖错误率或超时率过阈值时切断调用，避免无效等待；降级是在资源不足或熔断之后提供替代结果。推理链路的调用栈比普通接口深：网关 → 排队 → 向量检索 → 知识库召回 → Prompt 组装 → 推理 → 返回，每层都需要自己的兜底策略，不会有一个全局开关拯救所有分支。

Google Cloud 架构中心关于优雅降级的文档提的是硬依赖转软依赖：能降级成默认值的依赖就不要配成阻塞链路。落到工程上，向量检索超时的默认行为必须是“空召回继续跑”，不是抛异常把整条问答打断。

四级门禁的实际边界

参照那种分级设计，我通常会划出四档，但阈值不必照搬。

• L0 正常：全部组件健康，允许多轮、长上下文、深度检索。
• L1 轻度：显存 70%–85%、排队开始堆积。关闭长文档摘要、限制输出 token 上限、清理冗余 Prompt。可逆性最好，几乎感知不到。
• L2 中度：显存过 85%、检索时延抖动。缓存强制前置，命中直接跳过推理；检索减少召回条数；推理换小参数模型或 INT8/INT4 量化版本。代价是复杂推理和长文本质量掉一截。
• L3 重度：显存耗尽或显式依赖宕机。停掉实时推理，走静态话术和上一次缓存答案。这档要写成白纸黑字的响应文案，不要交给模型自己谦卑地道歉。

常见错误是把触发条件设成多条 AND。队列长度和推理 P95 通常同时恶化，AND 会导致决策反应慢半拍；更可靠的做法是主指标单点触发，辅指标用来决定进入哪一档。

缓存兜底算降级，但别神化它

智能客服和企业问答确实呈 80/20 分布：多数流量集中在少数问题上。把高频结果用 Key-Value 缓存，问句归一化后做 Key，能给中度降级一个毫秒级出路。

问题出在命中率的数据来源。很多团队统计的是“训练集或 FAQ 集合的覆盖率”，线上真实分布往往长尾很多。缓存 Key 归一化去标点、统一大小写以后，带时间词、带指代的问句基本归不一类。一个直接后果是 L2 下命中率可能只有二三成，剩下七成还得走 L3 兜底——所以缓存分支要单独统计命中率和兜底返回率，而不是只看推理耗时下降就宣布降级生效。

TTL 也值得纠结。降级模式下主动延长过期时间能提高命中，但旧答案的概率同步上升。对提供政策、价格、库存类信息的场景，这条规则要单独豁免：返回过时信息比返回“请稍后再试”的伤害更实在。

动态路由的真正成本

推理小模型从主模型切换过去，延迟收益明显，但质量下降不是线性的。问句简单时差异极小，遇到需要多步推断或精确引用检索段落的内容，小模型会自信地给出错误结论，而这在客服场景里无法靠“稍后重试”弥补。

所以我更倾向于按请求复杂度而非全局切模型；用历史统计（问题长度、检索命中条数、是否多轮）预先路由，同时只对非强 LLM 类接口降低优先级。这一层要成立，得先把业务方接受的质量门禁写进契约；靠工程单方面拍板，上线第一天就会被投诉压回原形。

触发链路需要一个可信的延时双环

纯自动触发最大的坑是抖动。显存瞬间跳过去又下来，请求在两档之间反复横跳，会话开始前后一致性崩掉。可用两件事缓解。一是升降级的不对称：升档要求指标在一个滑动窗口内持续越界，降档在指标回落一段时间后才解除。二是同一个会话保持同一档位，别中途从 L1 跳到 L3，历史对话在小模型里再接回去基本没法看。

线上失败的样子往往比设计跑题

• 降级到静态兜底后，日志里 200 一片，看起来一切正常，直到客服转人工量暴涨才被发现。降级要有独立业务指标，例如降级响应占比、人工接管率。
• 没有给降级链路预留预算，走到 L2 时缓存服务本身还在冷启动，兜底分支跟着挂。
• 只对推理超时设降级，对向量数据库成功但时延 800ms 的情况视而不见，最后还是在整个链路的 P99 抖到用户端。
• 配置项放在代码里，线上调整要发版。要求所有阈值、兜底话术、路径开关至少可热加载，否则改一次要排半小时维护窗口。

真正把估算吃掉的就是这些改配置和回归的开销。有判断的做法还是先跑通 L1 与 L3 两端——降级分支每次回归都要拉去测一遍，L2 至少能在堆满显存后返回点什么；等质量评估手段成熟，再上精细分档。