一、三层各守一段，不要混着配

1. 限流守的是入口

它解决的问题是进入量超过处理能力。动作发生在请求被受理之前，作用是把突发的峰值削去。限流做得好，后面的重试与降级都轻松；限流形同虚设，后面两层只能疲于应付。

2. 重试补的是偶发

它解决的问题是单次调用因网络抖动、实例切换、瞬时拥塞而失败。动作发生在失败之后，作用是给偶发问题一次机会。重试的天敌是无差别重试，把确定失败也当临时失败，越试越糟。

3. 降级保的是核心

它解决的问题是资源确实不够时必须做取舍。动作发生在处理过程中，作用是有序地牺牲非核心部分，让核心链路继续可用。降级不是失败，它是提前设计好的退让。

三层各管一段，边界要清楚：限流管入口，重试管单次，降级管整体。判断一次故障该归到哪一层，就看它是量的问题、点的问题还是面的问题。

二、限流按三个维度设，阈值从容量反推

只按请求数限流，遇到长文本会失效：请求数没涨，词元消耗却翻了几倍。

1. 请求数维度

按每秒或每分钟受理的请求条数设上限，适合请求长度比较均匀的场景，比如固定模板的问答、分类判断。阈值设定简单，但对长短不齐的输入不敏感。

2. 词元数维度

按输入与输出合计的词元量设上限。这一维度更贴近真实的资源消耗，也更能防止少数超长请求把资源占满。设定时要把输入与输出分开计，输出侧按上限值预估，不要按均值估。

3. 并发数维度

按同时在处理的请求条数设上限，防止瞬时并发压垮实例。这一维度与排队机制配套使用，超过就进入队列，队列满了再拒。

4. 阈值从容量反推，不从感觉来

先在目标模型上压一轮，测出在延迟可接受前提下的处理能力，再乘一个留有余量的系数，通常取六到七成。剩下的三到四成是应对突发与实例波动的空间，不留给它，任何一次小抖动都会直接变成超时。

三、限流要放在两道位置

1. 客户端前置：主动削峰

在调用方放一个令牌桶，按固定速率发放令牌，请求要先拿到令牌才能发出。桶的容量可以设成速率的五倍左右，既能承接短促突发，又不会让长期速率超过上限。这一步的价值是把超限请求挡在门外，而不是让它们打到服务端再被打回。

2. 服务端反馈后：被动收缩

收到表示请求过多的返回码时，调用方主动降低发送速率，并在等待一段时间后再逐步恢复。这一步是闭环，没有它，前置限流的阈值就只能凭猜测。

3. 分池限流：别让一个业务拖垮全部

按业务线、用户等级或任务类型分池，各自独立计量。批量任务与在线交互共用一池，前者一次跑批就能把额度吃光。分池之后，非核心任务超限只会影响它自己。

四、重试先划边界：三类可发，四类不碰

判断标准很简单：这次失败换一个时间点重发，有没有可能成功。有，才重试。

1. 可以重试的三类

一是连接超时与读写超时，二是服务端临时不可用，三是明确的请求过多返回。这三类都属于临时状态，退避后重发有较大概率成功。

2. 不要重试的四类

参数错误、输入超长、额度用尽、内容不合规。这四类无论重发多少次结果都一样，重试只会把一次失败放大成多次消耗。尤其是额度用尽，重试会持续产生被拒记录，把日志刷满，真正的问题反而被淹没。

3. 退避要有节奏

间隔按倍数递增，同时叠加随机抖动，防止大量调用方在同一时刻一起重发。次数设上限，通常两到三次足够；再往上加，成功率提升有限，等待时间却成倍增长。

4. 重试与计费要分开看

每次重发都是一次独立调用。若业务侧按调用次数记账，重试会让账对不上；若响应超时但服务端其实已经处理，重发还可能产生重复结果。解决方式有两步：给请求带一个可追溯的标识，在业务侧做去重；把重试次数单独统计，让它成为可观测的指标而不是隐形成本。

5. 超时要先于重试设好

超时设得比实际处理时间短，本来能成功的请求会被反复判为失败，进而触发大量无谓重试；设得过长，失败发现得太晚，等待时间白白消耗。做法是分级设：连接阶段用较短的固定值，读取阶段按输出长度估算，长输出任务单独一档。超时值要随模型与输出上限一起调整，换模型时重新核一遍。

五、降级按四级顺序往下走

降级的次序要提前定好，出事时才有章可循。原则是从影响小的动作开始，逐级加码。

1. 第一级：换用更轻的模型

同一个任务换成响应更快、消耗更少的一档模型。效果会有折损，但绝大多数场景仍可用。这一级要对业务方提前说明，防止切换后被当成故障。

2. 第二级：收窄输入与输出

缩短携带的历史轮次，压低输出长度上限，暂停非必要的工具调用。这一级对体验的影响是可感知的，但处理能力能明显回升。

3. 第三级：命中缓存直接返回

对高频重复的提问，用相似度匹配已有结果直接返回。这一级要设好相似度门槛，门槛过低会给出答非所问的内容，比不回答更伤体验。

4. 第四级：转异步或统一话术

把请求转入队列稍后处理，或者直接返回一句明确的提示，告诉用户当前繁忙、多长时间后再来。这一级是兜底，宁可清楚地说明，也不要让页面一直转圈。

四级之间要有明确的触发条件，不能凭值班人员现场判断。写进配置，自动执行，事后复盘。

六、三层要联动，不能各配各的

1. 重试要受限于限流的额度

如果重试不受限流约束，限流就形同虚设。正确做法是重试同样消耗令牌，且重试占用单独的小额度，占比不超过总量的一成，防止重试挤占正常请求的空间。

2. 熔断打开时重试必须停

连续失败达到阈值后应先停下来，不再发请求，给下游留出恢复时间。熔断期间的重试是没有意义的消耗，也是把局部故障扩散成全局故障的常见路径。

3. 降级要能自动恢复

降级打开容易，关闭难。恢复要按渐进方式进行：先放少量流量试探，观察一段时间的成功率与延迟，再逐级放开。一次性全量恢复，往往会把刚刚缓过来的服务再压回去。

4. 三层共用一套指标

成功率、延迟分位值、排队时长、降级命中比例、重试占比，这些指标要放在同一处看。分开看，只能看到局部；放在一起，才能判断当前是入口太宽、重试太多，还是降级开得过早。

七、配完怎么验

配置写完不等于配好，压一轮才知道边界在哪。

1. 阶梯加压看触发次序

从日常流量起步，按倍数逐级加压，观察三层按什么顺序被触发。理想的次序是限流先起作用，排队时长上升但成功率保持；继续加压后降级介入；不应出现的是重试率先飙升。

2. 故障注入验证兜底

模拟下游变慢、错误率上升、依赖不可用三种情形，看熔断是否按时打开、降级是否按级执行、恢复时是否渐进。这类验证要在业务低峰做，并提前告知相关方。

3. 每次异常都回看三个数

排队长度的变化速度、重试占比、降级命中比例。三个数一起看，能较快判断问题出在容量、代码还是外部依赖。把这些回看做成固定动作，配置就从一次性的设置变成长时间有效的能力。

结语

推理服务的稳定性，本质上是对有限资源做有次序的分配。限流把入口管住，让进入量始终落在处理能力之内；重试只对临时失败给机会，用退避和上限控制代价；降级按预先定好的次序退让，确保核心链路始终可用。三层配好之后还要联动：重试受额度约束、熔断时停重试、降级能渐进恢复、指标放在同一处看。息壤Token服务把多种模型收在统一入口下，调用方式一致，参数口径统一，这让上述三层机制可以按同一套规则实现，不必为每个模型各写一份。配置之外，压测与演练才是把纸面方案变成真实保障的那一步。