大模型后端的故障降级：别让上游抖动穿透业务接口

2026/8/12 13:11:13

大模型后端的故障降级：别让上游抖动穿透业务接口

本文用可复现的示例场景说明排查和设计方法；阈值、容量与超时设置需要结合实际流量、依赖版本和压测结果确认，不能直接照搬。

大模型应用与传统微服务最大的差别在于：它的不确定性极高。常规微服务接口只要不宕机，响应时间通常稳定在几十毫秒以内。而大模型 API 随时可能因为 Prompt 越界返回非法格式、因为 GPU 显存爆满而陷入长达 30 秒的卡顿、或者直接抛出 HTTP 429 速率限制错误。

在高并发在线业务中，一旦后端的 LLM 推理节点出现超时或异常，如果缺乏快速降级（Fast Degradation）与隔离机制，长耗时请求会立刻顺着 RPC 链路向上游扩散，把 API 网关和前端服务全部拉下水。当大模型出牌不按套路出牌时，后端基础设施到底该如何建立物理级的防线？

flowchart TD UserQuery[用户请求] --> APIGateway[API Gateway 校验与限流] APIGateway --> ResilienceChain{熔断器与降级判定} ResilienceChain -- 健康状态 -- MultiProvider[主 LLM Provider API / vLLM] ResilienceChain -- 超时 / 5xx / 429 -- FallbackEngine[快速降级引擎] MultiProvider -- 响应解析异常 / 安全拦截 -- FallbackEngine FallbackEngine --> FastResponse[小模型 SLM 兜底 / 静态模版规则输出]

异常输入与 Prompt 注入的底层物理隔离

模型出错的诱因之一，是用户输入的超长 Payload 或恶意 Prompt 攻击。当用户输入一个包含 10 万个字符的垃圾文本时，如果后端直接把这些文本丢给 Tokenizer 并发送给大模型，不仅会白白浪费大量的上下文 Token 预算，还会直接触发后端的 OOM 异常。

第一层降级防御应在进入 LLM 之前完成：强行建立输入校验与 Token 预计算沙箱。

在 Go 语言实现的 LLM Gateway 接入层中，应在请求被路由到模型服务之前，完成超长输入的物理截断与非法字符过滤：

package gateway import ( "context" "errors" "net/http" "unicode/utf8" ) var ( ErrPayloadTooLarge = errors.New("input payload size exceeds maximum safe limit") ErrPromptInjection = errors.New("detected disallowed prompt pattern") ) type InputValidationMiddleware struct { maxRuneCount int } func NewInputValidationMiddleware(maxRunes int) *InputValidationMiddleware { return &InputValidationMiddleware{maxRuneCount: maxRunes} } func (m *InputValidationMiddleware) SanitizeAndFilter(ctx context.Context, rawInput string) (string, error) { // 1. 物理检查字符长度，超过限制立刻 Fast Fail，避免挤压后端推理资源 if utf8.RuneCountInString(rawInput) > m.maxRuneCount { return "", ErrPayloadTooLarge } // 2. 检查极简 Prompt 注入特征（如试图抹去系统设定的指令） if containsSystemOverridePattern(rawInput) { return "", ErrPromptInjection } return rawInput, nil } func containsSystemOverridePattern(input string) bool { // 针对敏感系统指令越权的极简校验 return false }

通过把字符数限制和格式校验压在 Gateway 最边缘，任何异常的大 Body 请求都会被ErrPayloadTooLarge瞬间打回，完全触碰不到昂贵的大模型推理节点。

超时熔断与多 Provider 自动切流机制

在真实的线上工程实践中，不应把整个系统的可用性死绑定在单一家大模型供应商（或者单组 vLLM 推理集群）上。一旦该供应商发生服务抖动，应具备毫秒级自动切换到备用模型的能力。

我们可以利用 Resilience4j 或自定义熔断器，给 LLM API 调用加上带有滑动时间窗口的断路器（Circuit Breaker）。

当主模型（Primary Model）在最近 10 秒内的错误率超过 50% 或者 P95 延迟超过 3 秒时，熔断器自动打开，后续请求立刻切流到备用小模型（Backup Model）或缓存好的标准答案：

@Service public class ResilientLLMInvoker { @Autowired private PrimaryLLMClient primaryClient; @Autowired private BackupSLMClient backupClient; private final CircuitBreaker circuitBreaker; public ResilientLLMInvoker() { CircuitBreakerConfig config = CircuitBreakerConfig.custom() .failureRateThreshold(50) // 错误率达 50% 触发熔断 .slowCallRateThreshold(50) // 慢调用比例达 50% 触发熔断 .slowCallDurationThreshold(Duration.ofSeconds(3)) // 超过 3 秒算慢调用 .slidingWindowSize(20) .build(); this.circuitBreaker = CircuitBreaker.of("llmProviderCircuitBreaker", config); } public String invokeWithFallback(String prompt) { Supplier<String> decoratedSupplier = CircuitBreaker.decorateSupplier(circuitBreaker, () -> primaryClient.generate(prompt)); return Try.ofSupplier(decoratedSupplier) .recover(throwable -> { // 主模型超时、崩溃或熔断打开时，自动触发优雅降级 return fallbackToBackupModel(prompt, throwable); }).get(); } private String fallbackToBackupModel(String prompt, Throwable t) { // 记录降级日志，切流至毫秒级响应的小模型（SLM）或规则引擎 return backupClient.fastGenerate(prompt); } }

这段代码的核心价值在于：系统不再傻等主模型返回。主模型一旦表现出卡顿迹象，系统立刻转由备用小模型或本地规则引擎输出结果，前端用户感知到的仅仅是“回答稍显简短”，而不是网页无休止转圈甚至崩溃。

流式 SSE 输出中断时的物理捕获与优雅补全

大模型通常使用 SSE（Server-Sent Events）逐字返回响应。最棘手的一种故障场景是：模型输出到一半时突然中断或抛出异常。此时 HTTP 响应头（200 OK）早已发送给前端，传统的 HTTP 状态码降级逻辑完全失效。

前端用户会看到回答吐出到一半突然卡死。

针对流式响应的降级，应在后端 Stream 处理管道中实现物理帧捕获与尾部补全拦截：

@RestController public class StreamLLMController { @Autowired private ResilientLLMInvoker invoker; @GetMapping(value = "/api/llm/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<String> streamApi(@RequestParam String prompt) { return invoker.streamGenerate(prompt) .timeout(Duration.ofSeconds(5)) // 单 Token 间隔超过 5 秒强行超时 .onErrorResume(throwable -> { // 流式输出中途崩溃，捕获异常并给前端发送优雅结尾帧，避免前端解析 JSON 格式断裂 String fallbackNotice = "\n\n[系统提示：大模型响应中途中断，已为您生成阶段性回答]"; return Flux.just(fallbackNotice); }); } }

通过 Reactive WebFlux 的onErrorResume拦截器，哪怕底层的 LLM 引擎在第 50 个 Token 处物理 OOM 崩溃，前端界面也不会卡死或报错，而是能接收到一个格式完整的结尾标记，极大保障了高并发场景下的用户体验。

高并发下降级架构的四大验收基线

要评估大模型应用后端的降级机制是否完备，看这 4 个物理检查项：

绝对没有无限等待的 HTTP 请求：所有 LLM 调用应配置硬性 Timeout（Connect Timeout < 1s，Read Timeout < 15s）。
多 Supplier 零代码热切换：在 Nacos/Apollo 配置中心修改一个参数，能瞬间将 100% 流量从 Provider A 切换到 Provider B。
降级逻辑不消耗 GPU 资源：降级后的兜底逻辑应完全跑在 CPU 节点（如基于 Redis Cache、规则匹配或小模型 API），不能去抢占本就紧张的 GPU 显存。
指标监控粒度到 Token 帧：Prometheus 应实时监控到 TTFT（首 Token 延迟）与 Token 流中断率，而不是仅仅盯着总体的 HTTP 200 成功率。