LLM 推理服务的灾备与故障转移工程 2026

一、问题与动机：为什么 LLM 推理服务需要一套独立的灾备工程

LLM 推理服务的灾备与传统微服务的灾备，看上去都在解决同一个问题——在故障发生时，让用户的请求依然能被正确地、有质量地、低延迟地处理。但当一线工程师真正去落地时，会发现两者几乎是两套完全不同的工程范式：传统微服务的灾备以"请求幂等 + 无状态副本 + 数据库主备"为核心，可以在秒级完成切流而不丢失任何会话状态；而 LLM 推理服务的灾备需要同时管理三件传统服务不必操心的事情——超大模型权重的热加载、生成式会话的 KV cache 上下文延续、以及生成质量在不同副本之间的隐性漂移。这三件事中的任何一件处理不当，灾备切换的代价就不是"延迟升高"那么简单，而是"业务语义被打破"。

更隐蔽的差异来自延迟敏感性。一个普通的搜索微服务 P99 从 200ms 升到 2 秒，用户的体感是"慢了一点"；而一个 LLM 推理服务从首 token 150ms 升到 3 秒，用户的体感是"这个东西挂了"——因为对话型 LLM 应用几乎没有等待 3 秒以上的用户耐心曲线。当我们的灾备链路只能做到"实例存活但首 token 退化"时，业务指标上的可用性看起来仍然是 99.95%，但用户感知上的可用性已经跌破了 95%。

第三个差异是有状态推理。传统微服务的副本是无状态的，可以任意水平扩展；LLM 推理服务的副本之间存在隐性的状态共享——同样的 prompt 在不同实例、不同 GPU、不同 CUDA 版本下可能产生语义等价但 token 序列不完全一致的输出。灾备切流后，用户如果发现"同一个对话怎么换个机器就变了个调调"，会比"服务挂了"更频繁地触发信任崩塌。这三件事决定了 LLM 推理的灾备必须被当作一个独立的工程学科来对待，而不是把传统微服务的灾备 playbook 直接套上来。

二、形式化：三层故障模型与四级 RTO/RPO 矩阵

要让灾备工程变得可度量、可推演、可演练，我们先把故障空间做形式化。第一层是故障粒度：实例级（单个 GPU OOM、单个进程崩溃）、可用区级（一个 AZ 的交换机故障、整个可用区断电）、区域级（一个 Region 的控制面失联或骨干网中断）。三层粒度的恢复技术完全不同：实例级靠进程重启 + 健康检查摘除；可用区级靠跨 AZ 的负载均衡 + 容量冗余；区域级靠跨 Region 的 anycast 或 DNS 切流 + 异地模型镜像。把这三层混在一起谈灾备，是大量 SRE 团队在第一次 LLM 推理灾备演练里踩坑的根本原因——他们用同一套 playbook 去处理 OOM 和骨干网中断，结果当然是不可用时间被指数级放大。

第二层是恢复目标。传统 SRE 用 RTO（恢复时间目标）和 RPO（恢复点目标）两个标量刻画灾备等级，但 LLM 推理至少需要把它们扩展成一个矩阵：RTO_latency（首 token 恢复到目标延迟的时间）、RTO_quality（生成质量指标恢复到目标值的时间）、RPO_context（KV cache 或会话状态的最大可丢失窗口）、RPO_weight（模型权重回滚的最大可接受滞后）。一个声称"5 分钟 RTO"的灾备方案，如果 RTO_quality 是 30 分钟，那么它对于对话型应用就是不合格的——因为用户在前 30 分钟里会持续感知到质量下降。

我们给出一个简明的故障矩阵：

这张表是接下来七节工程实践的脚手架——任何一条工程推论都要回到这张表上检验它在哪个格子有效、在哪个格子失效。

三、健康检查与熔断：Liveness、Readiness 与 Generational health

LLM 推理服务的健康检查，比传统微服务复杂在三个维度。第一，Liveness probe 不能只看进程是否存活——一个 LLM 推理进程完全可能"活着"但 CUDA context 已损坏，或者权重分片加载失败导致每次推理静默回退到随机输出。必须用轻量级"探针 prompt"定期触发一次 token 生成，校验返回 token 数量、首 token 延迟、生成质量三者同时在合理区间。第二，Readiness probe 不能只看端口是否监听——LLM 推理实例在权重加载完成之前不应当接收任何真实流量，否则用户会拿到 503 或超时。Readiness probe 必须显式校验权重加载进度 + KV cache 池初始化状态 + tokenizer 一致性。第三，Generational health 是 LLM 推理独有的第三类探针——用来检测"老一代"实例。新一代模型权重发布后，老一代实例即使健康也不应继续接收新会话（因为它们的输出风格可能与新一代不一致），但仍可继续服务已建立的会话直到自然结束。这是一种"按 generation 摘除"的细粒度熔断。

工程上的实现要点是把这三类 probe 拆成三个独立的 HTTP endpoint：/healthz/live 测 Liveness，/healthz/ready 测 Readiness，/healthz/generation 测 Generational health。Kubernetes 的 livenessProbe / readinessProbe 分别指向不同 endpoint，避免互相干扰。Generational health 在 Service Mesh 层（Envoy / Istio）通过自定义 filter 实现，根据实例的 metadata.generation 标签决定是否加入负载均衡池。熔断器（circuit breaker）则要在推理网关层（vLLM / TGI / Triton 前置网关）实现，而不是依赖 Service Mesh 的全局熔断——因为后者的触发条件是连接错误率，而 LLM 推理的失败模式更可能是"延迟退化"或"质量退化"而不是连接断开。

一个被严重低估的工程实践是健康检查预算（health check budget）：单个集群的健康检查频率不能超过实例总数的 1/10，否则健康检查本身的流量会污染生产链路的延迟分布。在 100 个实例的集群里，Liveness probe 间隔 5 秒意味着每秒 20 次推理探针调用，如果探针 prompt 是 64 token 输出则总开销约为 1280 token/秒——这在生产环境里相当于白白烧掉一个 GPU 的 0.5% 利用率。把探针 prompt 设计成"零开销缓存命中"模式（用前缀缓存命中一个已知 KV cache block），可以把健康检查的开销压到几乎为零。

四、流量切换的工程化：DNS、Anycast、服务网格与 L4-L7 灰度切流

LLM 推理的故障转移链路，按切换粒度从粗到细分成四层：DNS 层（30 秒-5 分钟生效，适合区域级灾备）、Anycast 层（秒级生效，适合可用区级灾备）、服务网格层（亚秒级生效，适合实例级与可用区级灾备的精细化）、L4-L7 网关层（毫秒级生效，适合实例级切流与灰度发布）。每一层有自己的代价和适用场景，混用是工程事故的常见根源。

DNS 层灾备的工程难点是 TTL 治理：DNS 记录的 TTL 不能太长（否则切流慢），也不能太短（否则 DNS 解析器会持续回源，污染权威 DNS）。生产实践是双 TTL 策略——对外短 TTL（60 秒）让切流能 1 分钟内生效，对内长 TTL（600 秒）让内部服务到 DNS 的查询压力可控。切流时把短 TTL 记录从主集群切到备集群，外部客户端的解析器在 60 秒内收敛完成流量切换。Anycast 层灾备的工程难点是路由对称性：同一客户端的请求必须稳定路由到同一可用区，否则跨可用区的会话状态同步会拖垮整个系统。生产实践是用 BGP Anycast + ECMP 让同一 IP 段在不同 AZ 各自宣告，再在每个 AZ 入口处用一致性哈希把客户端 ID 固定到后端实例。

服务网格层灾备的关键能力是流量染色 + 按权重切流。Istio 的 VirtualService 可以做到 99%/1% 的精细切流，配合 Header-based routing 实现"内部员工 + 灰度用户"走新版本、其他用户走旧版本。LLM 推理的特殊要求是切流粒度要细到模型版本号而不是服务版本号——同一个 vLLM 服务可能同时挂载三个模型版本（prod / canary / shadow），流量按模型路由而不是按服务路由。L4-L7 网关层（Envoy / Nginx / HAProxy）的灾备能力主要体现在健康检查驱动的自动摘除——当后端实例连续 N 次 Liveness 失败，Envoy 自动把它从负载均衡池移除，秒级生效。

四层切流的协作模式是：实例级故障由 L4-L7 网关秒级处理；可用区级故障由服务网格数十秒处理；区域级故障由 Anycast 数分钟处理；极端情况下 DNS 兜底。任何一层切流都必须在 observability 层面留下显式的"切流事件"标签（如 routing.tier=l7-cutover），否则事后复盘时无法区分是 L7 自动摘除还是 SRE 手动切流。

五、模型权重的故障转移：热备、冷备、版本回滚与 Checkpoint 路由

传统微服务的故障转移只需要切换请求路由，权重本身是无状态的副本；LLM 推理的权重转移是一个独立子系统。**热备（hot standby）**指备集群已加载好相同模型权重，仅在主集群故障时接收流量——代价是双倍 GPU 持有成本，收益是秒级切流。**冷备（cold standby）**指备集群只下载了权重分片但未加载，需要在故障时启动加载流程——代价是切流延迟 5-15 分钟（取决于权重大小和 PCIe/NVLink 带宽），收益是持有成本只有热备的 1/3。**版本回滚（weight rollback）**指主集群本身发生权重 bug 时，把流量切回上一个已知健康的权重版本——这要求权重版本治理能力（详见 §七）。

Checkpoint 路由是 LLM 推理独有的工程模式：让一个推理实例同时挂载多个权重版本，按请求维度的 model_version Header 路由到对应权重。这与 A/B 测试的架构天然重合——A/B 测试本来就需要"同一实例多权重"，灾备切流只需要把这个能力反过来用即可。生产实践是把权重分片存到共享文件系统（NFS / S3FS / WekaFS），由推理实例按需 mmap 加载，避免每个实例独占一份权重的存储成本。

权重治理的另一个工程难点是预热池（warm pool）。故障发生后再去启动新实例加载权重，整个链路的尾延迟会被权重加载时间（典型 70B 模型 30-60 秒）拖到无法接受。生产实践是维护一个常驻的预热池，里面保持 N 个实例已加载权重但不接收流量；当故障发生时，预热池里的实例秒级接管流量，同时触发冷备池补位。预热池的大小需要按"单 AZ 完全故障"的容量需求规划，而不是按"单实例故障"——因为 AZ 故障时我们需要的是整个 AZ 的容量接管能力。

权重版本回滚的工程实践是引入一个**"权重版本快照"**——每次权重上线都生成一个版本号 + checksum + 已知问题清单的元数据条目，存储到一个独立于模型服务之外的"权重目录服务"。当某个权重版本被发现有质量回归时，通过 PATCH 推理网关的配置即可秒级切回上一个版本，不依赖任何实例重启。这种"权重即配置"的范式让 LLM 推理的灾备具备了"蓝绿部署"的全部能力，而且不需要双倍 GPU 持有——只要预热池维持一定比例的旧版本实例即可。

六、统一视角：把 LLM 推理视为"有状态推理"的灾备理论

把前三节的工程实践统一起来，我们得到一个理论视角：LLM 推理服务本质上是一个分布式有状态推理机，它的"状态"由三部分组成——模型权重、KV cache 池、生成配置（temperature / top_p / stop tokens）。 灾备的工程本质，是把这三部分状态在故障发生时尽可能无损地保留。

模型权重的状态保留，我们已经在 §五讨论过——靠预热池、权重目录、版本快照。KV cache 池的状态保留是 LLM 推理灾备与传统微服务灾备最大的差异点：KV cache 是会话级的、GPU 显存级的、毫秒级更新的状态，传统的"数据库主备"思路在这里完全不适用。工程实践是把 KV cache 拆成"可重建"与"不可重建"两类：系统提示词对应的 KV cache 可重建（每次新会话都重新计算）；用户多轮对话累积的 KV cache 不可重建（重建需要重放整个对话历史）。对于不可重建部分，唯一的灾备方案是实时复制到一个共享 KV cache 存储（如 Redis / 共享内存池），但代价是每次推理都要做一次跨网络写入，性能损耗 5-15%。在生产中常见的折中是只复制"会话级关键节点"（如每 10 个对话回合复制一次），而不是每个 token 都复制。

生成配置的状态保留相对简单——把 temperature / top_p / stop tokens 当作请求级别的 Header 而不是实例级别的配置，让任何实例都能从请求里恢复生成上下文。这种"无配置实例"的设计哲学让灾备切流的复杂度大幅下降：实例切换只是 IP 变化，不影响请求语义。

把上述三件事统一起来，我们得到一个有状态推理的灾备三元组（DR-Triple）：

• W（Weights）——模型权重的可恢复性
• K（KV cache）——会话状态的可恢复性
• C（Configuration）——生成配置的可恢复性

任何灾备方案的设计都必须显式回答"在 W/K/C 三个维度上，故障发生时丢失了什么、保留了什么、恢复需要多长时间"。一个只回答了 W 没回答 K 的方案，对短会话应用是合格的，对长会话应用是不合格的——因为 K 的丢失会让用户的整个对话历史被重放一遍，体感比服务挂掉还糟糕。

七、对工程实践的推论：五条可执行的灾备设计原则

把前面六节的理论落到可执行的工程动作，我们提炼五条设计原则。

原则一：健康检查预算必须显式管理。单个集群的 Liveness probe 频率不能超过实例总数的 1/10，探针 prompt 必须用前缀缓存命中模式避免污染生产延迟分布。Readiness probe 必须显式校验权重加载进度，而不是只校验端口监听。Generational health 作为第三类探针独立部署，用于按 generation 摘除老一代实例。

原则二：切流一致性必须按四层分别设计。DNS 层（30 秒-5 分钟）、Anycast 层（秒级）、服务网格层（亚秒级）、L4-L7 网关层（毫秒级）四层各管一类粒度的故障。任何一层切流都必须在 observability 层面留下 routing.tier 标签，事后复盘才能区分是 L7 自动摘除还是 SRE 手动切流。一致性哈希必须按客户端 ID 而非请求 ID 路由，避免会话状态在切流时被跨实例打散。

原则三：权重版本治理必须独立于模型服务。权重版本目录服务（包含版本号、checksum、已知问题清单）部署在模型服务之外，每次权重上线都生成新条目。预热池按"单 AZ 容量接管"规模规划，常驻 N 个已加载但不接收流量的实例。Checkpoint 路由能力（同一实例多权重 + 按 Header 路由）作为 A/B 测试与灾备共享的基础设施。

原则四：KV cache 的状态保存窗口必须显式定义。把 KV cache 拆成"可重建"与"不可重建"两类，对后者做实时复制到共享存储。复制频率按"会话关键节点"（每 N 个回合）而非"每 token"，性能损耗控制在 5-15%。在 SLO 文档里显式声明 KV cache 的 RPO（典型 1-5 分钟），让用户对会话连续性的期望与系统能力对齐。

原则五：灾备演练必须有节奏，不能"一年一次大练"。实例级故障演练（关闭单个实例）应当每周一次、自动化执行；可用区级故障演练（关闭一个 AZ 的入口流量）应当每月一次、需要人工监督；区域级故障演练（DNS 切流 + 异地接管）应当每季度一次、需要完整的业务方参与。任何一次演练都必须产出"RTO 实测值 vs 目标值"的对比表，并把差距列入下一轮迭代。

八、讨论与局限：与 SRE 经典灾备的差异、监控盲区与演练陷阱

LLM 推理的灾备在三个层面仍处于早期阶段，监控盲区是最严重的现实问题。传统 SRE 监控的是"请求成功率"与"延迟分位数"两个标量，LLM 推理的灾备监控必须额外加入"生成质量"维度——但生成质量的监控本身就是一个未解的工程难题。当我们说"灾备切流后质量下降了 10%"，我们其实是在用某种代理指标（如 perplexity 变化、reward model 打分）来近似真实质量，而代理指标与真实质量之间的偏差可能远大于 10%。

第二个局限是演练陷阱。灾备演练最危险的状态是"演练成功了但生产上没生效"——例如演练时我们成功切到备集群，但生产环境里因为备集群的模型版本与主集群有微小差异（差一个 patch），切流后用户看到的生成质量与演练时完全不同。解决方法是让备集群与主集群的权重版本严格对齐，包括 tokenizer、prompt template、generation config 在内的"语义版本号"必须完全一致。

第三个局限是成本与可恢复性的张力。灾备等级越高，持有成本越高。热备双倍 GPU、冷备 + 预热池 1.5 倍 GPU、纯冷备 1.1 倍 GPU，但恢复时间从秒级退化到 15 分钟级。生产决策必须基于业务的真实容忍度——而不是盲目追求"5-9"或"6-9"的可用性数字。对一个内部知识库问答系统，5 分钟 RTO 完全合格；对一个面向 C 端用户的对话产品，5 分钟 RTO 等于业务失败。

九、给 SRE 与平台工程师的清单：七条落地项

最后给读者一份七条可立即执行的清单：

1. 建三类健康检查 endpoint：/healthz/live、/healthz/ready、/healthz/generation，分别挂 Kubernetes 的 livenessProbe / readinessProbe 与 Service Mesh 的自定义 filter。
2. 建权重版本目录服务：版本号 + checksum + 已知问题清单，作为推理网关配置的"单一真相源"。
3. 建预热池：规模按"单 AZ 容量接管"规划，权重加载完成但暂不接收流量，故障时秒级接管。
4. 把 KV cache 拆可重建/不可重建两类：对后者做"会话关键节点"实时复制到共享存储，性能损耗控制在 5-15%。
5. 四层切流架构：DNS（区域级）+ Anycast（可用区级）+ 服务网格（精细切流）+ L4-L7（实例级）各管一类故障，每层切流留 routing.tier 标签。
6. 灾备演练节奏：实例级周演练（自动化）、可用区级月演练（人工监督）、区域级季度演练（业务方参与），每次演练产出 RTO 实测对比表。
7. 在 SLO 文档里显式声明三类目标：RTO_latency（首 token 延迟恢复时间）、RPO_context（KV cache 丢失窗口）、RPO_weight（权重版本回滚滞后），让用户对灾备能力的期望与系统能力对齐。

LLM 推理的灾备工程远未到成熟形态，但它已经是一个可被形式化、被拆解、被演练的工程问题。把它当作"传统微服务灾备 + 一些特殊配置"的工程师，会在第一次区域级故障时被业务方反复追问；把它当作"独立工程学科"来对待的工程师，至少能在第一个 RTO 目标达成时让团队睡个好觉。

一句话摘要：LLM 推理的灾备工程必须以"有状态推理"为理论起点，把模型权重、KV cache、生成配置三类状态的可恢复性作为独立工程目标，通过四层切流架构与三类健康检查端点把故障转移链路拆解到毫秒级可控粒度。

参考文献

1. vLLM Documentation: Production Deployment Best Practices, https://docs.vllm.ai/en/latest/serving/distributed_serving.html, 访问于 2026-08。
2. Kubernetes livenessProbe vs readinessProbe patterns, https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/, 访问于 2026-08。
3. Envoy xDS Load Balancing and Outlier Detection, https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/overview, 访问于 2026-08。
4. Istio VirtualService Traffic Shifting, https://istio.io/latest/docs/reference/config/networking/virtual-service/, 访问于 2026-08。
5. BGP Anycast for Production Traffic Engineering, https://www.cloudflare.com/learning/dns/what-is-anycast-dns/, 访问于 2026-08。
6. AWS Multi-Region Disaster Recovery Architectures, https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html, 访问于 2026-08。
7. Google SRE Book: Handling Overload and Failure Modes, https://sre.google/sre-book/handling-overload/, 访问于 2026-08。
8. PagedAttention: Virtual Memory for LLM Serving, Kwon et al., SOSP 2023。
9. FlashAttention-2: Faster Attention with Better Parallelism, Dao et al., NeurIPS 2023。
10. SGLang: Efficient Execution of Structured Language Model Programs, Zheng et al., 2024。
11. NVIDIA Triton Inference Server: Architecture and Best Practices, https://github.com/triton-inference-server/server, 访问于 2026-08。
12. Weights & Biases: Model Registry and Version Governance, https://docs.wandb.ai/models/registry, 访问于 2026-08。
13. Prometheus Federation for Multi-Cluster Observability, https://prometheus.io/docs/prometheus/latest/federation/, 访问于 2026-08。
14. OpenTelemetry GenAI Semantic Conventions (Draft), https://opentelemetry.io/docs/specs/semconv/gen-ai/, 访问于 2026-08。
15. Chaos Engineering: Building Confidence in Production Systems, Netflix Tech Blog, https://netflixtechblog.com/chaos-engineering-the-history-of-netflixs-chaos-tool-suites-15e3f6c3c2d4, 访问于 2026-08。