QVeris
韧性架构

LLM 高可用
设计故障域并证明可恢复
LLM 高可用
为恢复而设计

测试独立故障域、等价能力、有界恢复与最终结果。

发布日期:2026年3月21日 · QVeris团队制作

Financial market workflow supporting LLM High Availability Design for Recovery LLM Availability Design for Recovery LLM 高可用 设计故障域并证明可恢复 LLM 高可用 为恢复而设计

速览

映射故障域

分离供应商、模型、网关、区域、网络、控制面与配置风险。

构建等价资源池

故障切换前按工具、上下文、输出、安全、区域与数据策略过滤。

限制恢复

限制队列年龄、尝试次数、耗时、Token、支出与重复副作用。

持续证明

注入故障、观察恢复、灰度策略变更并保留回滚。

高可用始于工作负载契约

为每项工作负载定义所需模型能力、最大延迟、数据区域、策略、输出验证和可接受的降级方式。端点只有通过这份契约后,才能进入故障切换资源池。

还要把契约转化为可测量的服务目标。对话助手可能优先关注首 Token 延迟,并能接受能力较小的备用模型;文档提取任务可以接受排队,却必须保持相同的输出结构和准确率;受监管工作流甚至可能完全禁止跨区域切换。因此,“只要有模型返回即可”并不是有效的高可用目标。

必须列出相关性风险。两个看似不同的供应商可能共享云区域、网络出口、网关、身份系统或配置来源。只有与目标故障场景相关的故障域彼此独立时,冗余才真正成立。

依赖图不仅要包含模型供应商,还要覆盖 DNS、证书签发、身份认证、密钥、策略分发、遥测和出口网络。如果所有路由仍依赖同一个授权服务或配置数据库,那么即使增加第三家模型供应商,也没有消除真正的单点故障。

高可用模式决策

模式最适合选择前验证
多可用区网关网关进程或可用区故障是主要风险。核对状态复制、幂等、健康检查与配置一致性。
多供应商资源池必须容忍供应商或模型服务故障。核对能力等价、数据条款、配额、语义与质量。
多区域双活区域故障与低恢复时间要求值得额外复杂度。核对驻留、全局状态、路由、脑裂、成本与恢复切回。
受控降级部分负载没有等价路由。核对显式功能缩减、用户提示、安全与恢复触发。

高可用控制

新鲜健康状态

使用请求路径证据与带时间戳探测,避免过期二元状态。

熔断策略

定义触发、冷却、半开探测、逐步回归与恢复切回。

重试归属

一层负责重试,并在各次尝试间共享父截止时间。

恢复证据

保存候选集、排除原因、路由决策、尝试与最终处置。

开展恢复演练

从未处理过受控故障的切换配置只能算一种假设。应定期开展恢复演练,并明确成功标准:故障检测时间、路由决策时间、在截止时间内完成的请求比例、输出有效率、排队任务的恢复点目标,以及恢复正常路由所需时间。

  • 依次让网关、供应商、模型、区域和配置依赖发生故障。
  • 注入相关性故障、慢响应、流式中断和过期健康状态。
  • 验证截止时间、幂等、租户公平性、数据策略与受控错误。
  • 演练恢复切回和回滚,避免恢复过程制造第二次事故。

演练不能只覆盖完全宕机。速率限制、延迟升高、结构化输出失效,以及输出首个 Token 后卡住的流式响应更常见,也更难判断。需要验证网关是否把全部截止时间浪费在第一条路由上、重试是否进一步放大供应商压力,以及备用响应是否仍满足工作负载契约。

恢复切回也需要独立测试。刚恢复的供应商可能仍不稳定或容量受限,因此应通过健康状态滞后机制和灰度流量逐步恢复。重新赋予完整流量权重前,要比较错误率、延迟和验证指标,并保留不打断在途请求即可撤销变更的能力。

分离控制面与数据面

控制面管理版本化目录、策略、健康状态和发布;数据面验证每个请求,按能力和数据驻留要求过滤,选择健康路由并执行有边界的尝试。两个平面独立复制,同时生成可关联的证据。

控制面不可用时,请求路径仍应在有限时间内继续工作。数据面副本可以使用已签名配置快照和最近一次有效策略,但每份快照都需要版本、到期时间,以及过期后的明确处理方式。高风险策略变更和紧急吊销必须拥有比普通目录更新更快的失效通道。

路由选择必须限制尝试次数。应把端到端截止时间分配给连接、首 Token 和完整生成阶段,为计划中的故障切换预留时间;当剩余时间不足以生成有用结果时立即停止重试。对部分幂等工作负载,对冲请求可以降低尾部延迟,但不受控的重复请求会增加成本,并可能加剧供应商事故。

生产规则:绝不能切换到尚未通过该工作负载能力与策略契约的端点。

把工具可用性设计为独立系统

模型高可用解决的是推理恢复;QVeris 治理外部 API、工具、服务和实时数据。应为这些能力配置独立的资源池、超时、幂等和恢复测试,再通过工作流调用链把两层关联起来。

模型故障切换无法修复不可用的支付 API、过期的市场数据流或失效的文档解析器。每项能力都应单独定义可用性与降级规则:能否使用缓存数据、允许多旧、是否有只读替代方案,以及哪些动作必须停止而不能重试。对带副作用的工具,还要在模型重试和供应商重试之间保留幂等键,避免恢复过程中重复提交订单或消息。

通过共享工作流调用链区分模型、路由和工具故障。记录模型尝试、所选能力、供应商原生请求 ID、超时阶段、验证结果和恢复动作。这样运营人员可以判断用户得到的是降级但有效的回答、已排队动作,还是受控失败,而不会把所有未完成工作流都误判为 LLM 宕机。

FAQ

多少供应商才够?

足以满足风险目标的独立路由即可;更多未测试路由只会增加故障模式。

总需要多区域吗?

不需要。根据业务影响、驻留与恢复目标选择架构。

健康检查应测什么?

测试最小真实能力路径,而不只是 DNS 或通用状态端点。

官方资料与延伸阅读

LLM 高可用 | QVeris Guides