如何为大模型平台设计跨地域容灾与降级？

面试时怎么答

跨地域容灾要沿完整请求依赖定义 RTO/RPO，除了数据库还包括模型、Prompt、索引、会话、密钥、配额与外部工具。入口可多活，状态和索引按等级选择同步或异步复制；备用模型能返回不代表质量与合规契约一致，演练必须验证真实降级语义。

可以这样答：

跨地域容灾不能只复制业务数据库，要按一条 LLM 请求的完整依赖定义 RTO 和 RPO，包括模型、Prompt、索引、会话、密钥、配额和工具。无状态入口可多活，状态与索引按业务等级选择同步或异步复制，切换时还要验证备用模型的语义契约。不过，双活恢复快但成本与一致性复杂度高。线上要定期做地域断网演练，记录流量切换 RTO、数据 RPO、降级任务成功率、质量回退和受影响请求数。

核心回答

先按能力定义 RTO（多久恢复）和 RPO（最多丢多少数据），再选择 active-active、warm standby、pilot light 或备份恢复；不是所有组件都需要同一等级。网关和编排尽量无状态、跨区部署；会话、任务、配额和审计数据按其一致性要求复制；模型权重、容器和 Prompt 制品预先复制并校验；推理容量要考虑 GPU 申请与模型预热时间，不能只在故障后才创建空集群。

故障时优先保持安全和数据边界：可切备用地域或供应商，也可降级到较小模型、只读功能或异步排队。任何降级都不能绕过租户权限、数据驻留和内容安全策略。

展开说明

LLM 平台需要分别处理：

控制面：配置、版本注册、配额和路由规则需要有权威来源，避免两个地域在网络分区时同时接受冲突发布。
请求状态：流式响应中断通常难以从最后一个 token 无缝续传；应给客户端明确终止状态和可安全重试的请求 ID。
异步任务：通过持久队列、租约和幂等副作用恢复；切区前避免两个 worker 同时拥有同一任务。
RAG 数据：对象源文档、元数据和向量索引分开规划。索引可以从版本化源重建，但重建时间必须计入 RTO。
外部模型：多供应商可减少单点故障，却会带来能力、Schema、安全和数据处理条款差异，需要预先验证兼容候选。

复制不能替代备份：错误删除或污染也会被快速复制，仍需不可变备份和时间点恢复。

工程实践

维护按依赖顺序编写的 runbook 和自动化切换，但对数据主从提升等不可逆步骤设置审批。定期做区域断网、配额耗尽、对象存储不可用和供应商超时演练，实测恢复时间、数据缺口、备用容量与回切。DNS TTL、证书、密钥、监控和告警接收链路也必须纳入演练，而不只测试模型端点。

常见追问

RTO、RPO 应该按整个平台定义，还是按组件定义？ 先从业务链路目标反推，再给各组件分配更严格的预算；只定义组件目标无法保证端到端任务恢复。
为什么已经跨地域复制数据库，仍然需要备份？ 复制会同步逻辑删除、污染或勒索破坏，备份提供时间点恢复和独立故障域，二者解决的问题不同。
备用模型能返回结果，为什么还不能直接作为容灾方案？ 它可能不支持相同上下文、工具、格式、安全或数据驻留要求；必须通过契约测试与质量门槛。

一句话复习

用业务 RTO/RPO 决定数据复制和 GPU 预热级别，并通过可演练的安全降级而非纸面架构完成容灾。

参考资料

面试题来源：LLM System Design Interview Guide 的高可用设计主题
官方依据：AWS Multi-Region Fundamentals、NIST SP 800-34 Rev.1