详细解释
多区域部署（Multi-Region） 和 容灾（DR = Disaster Recovery） 是把”单机故障 / 单机房故障 / 单区域故障”这种必然会发生的事故，变成对用户透明、业务不受影响的架构设计。AI API 场景下，这两个词尤其重要，因为 GPU 集群比通用 CPU 集群故障率高得多——显存坏块、NVLink 通信错误、HBM 过热降频、单张卡静默出错引发整批次 OOM，这些事情每个月在任何一个公有云上都会发生。如果你所有推理只放在一个 Region（比如上海 a 区），那哪天那边 70B 推理集群因为固件升级挂了 4 小时，你的业务就挂 4 小时。
基础概念：RPO 与 RTO（所有容灾方案最终要落到这两个数字上）
任何灾备方案，产品经理 / 技术负责人开会时都要先拍两个数字，不然后面全是白讨论：
| 指标 | 英文 | 含义 | AI 业务常见目标值 |
|---|---|---|---|
| RPO | Recovery Point Objective（恢复点目标） | “最多允许丢多少数据？“指从故障倒推到上一个可恢复的数据快照之间的时长。RPO=1 小时 = 最多丢最近 1 小时的数据。 | AI Token API 服务（无状态）：RPO=0 没问题（因为请求无状态）。SFT 训练数据 / 向量知识库（有状态）：RPO ≤ 15 分钟（每 15 分钟做一次增量快照）。 |
| RTO | Recovery Time Objective（恢复时间目标） | “从故障发生到业务完全恢复能用，最多多久？“RTO=5 分钟 = 必须在 5 分钟内切好流量。 | AI API：RTO ≤ 2 分钟（纯 SDK 层自动重试 + 多 Region 路由就能做到）；向量知识库 + SFT 管控台：RTO ≤ 30 分钟（要切换数据库 DNS）。 |
四种容灾架构：冷备 / 暖备 / 热备 / 多活（按成本 & 复杂度从低到高）
| 架构 | 也叫 | 平时备 Region 是否在线跑服务 | RTO | RPO | 成本倍数（相对单 Region） | 适合场景 |
|---|---|---|---|---|---|---|
| ① 冷备（Cold） | Backup & Restore | 不跑，只存数据镜像 / 模型权重文件到 OSS/S3，故障了临时起服务 | 2h 至 24h | 24h（每日快照） | ~1.2×（只有存储费） | 开发测试环境 / 内部工具 / 非核心 |
| ② 暖备（Warm） | Pilot Light | 备 Region 启好了 1/10 容量的 GPU 实例一直空转着；数据双向同步。故障了一键加机器到全量。 | 15 至 30 分钟 | 15 分钟（异步复制） | ~1.4×~1.7×（备 Region 最小实例 + 存储） | 中小型 SaaS 核心 API |
| ③ 热备（Hot） | Active-Standby | 备 Region 全量启好服务一直跑，但流量只占 5%（冒烟流量）；平时主 95% / 备 5%；故障了切 DNS / API Gateway 全部到备。 | 1 至 5 分钟 | 0 至 5 分钟（同步复制） | ~2.0×（两套集群都满载启着，其中一套空跑） | 金融 / 核心客服 / 任何三 9 以上 SLA |
| ④ 双活 / 多活（Multi-Active） | Active-Active / N+1 | N 个 Region 全部承载流量，任何一个挂了其他 N-1 个自动扛；全局流量按路由距离 + 负载均衡动态分配。 | 30 秒内 | 0 | ~2.2× 至 3× | 头部互联网 / 电商大促 / 全球业务客户分布广 |
2025 年 AI 厂商的标配组合是：“公开 API 入口走 双活（多 Region Active-Active）；内部平台（知识库 / SFT 控制台）走 热备（主-备 5 分钟切换）；离线训练数据走 冷备（跨地域 OSS 快照）。”
唯元智创 当前 2026 部署结构：华东（上海）+ 华北（北京）+ 华南（深圳）三 Region 全活承载推理 API 流量；客户打 api.weimeta.cn 默认走 Anycast 就近接入，任一 Region 失败（健康检查连续失败 3 次）30 秒内从路由中摘除，其他两个 Region 自动承担流量；客户可在控制台手动指定”强制走华东”做灰度；RPO=0（推理无状态），RTO=＜30 秒（实测 2025 年全年 7 次单 Region 故障用户全无感知）。
AI API 客户侧：如何 30 分钟内把”单厂商单 Region”升级到”多活容灾”
如果你现在的代码就是 client = OpenAI(base_url='https://api.weimeta.cn/v1') 一行，那你是 RPO=∞、RTO=∞ 的裸奔。升级到”厂商内多 Region + 多厂商级 Fallback”只需要 4 步，代码改动 < 50 行：
- OpenAI SDK http_client 加重试：
httpx.AsyncClient(transport=httpx.AsyncHTTPTransport(retries=3))，对 5xx/连接超时 / 408 自动重试 3 次（指数退避，每次间隔 1.2×）。 - 加一个 SDK 层的 Region 路由拦截器（Middleware）：写 3 个 base_url：
weimeta-sh、weimeta-bj、backup-other-vendor，每个 base_url 自己有一个”滑动窗口失败率”计数器，当失败率连续 1 分钟 > 5% → 临时从候选池里摘除 10 分钟冷却。 - 请求路由策略（优先级加权）：正常情况 60% → 最近的上海、30% → 北京、10% → 深圳；失败时自动弹到”其他所有没被摘的候选”均分（用 Load Balancing 最小连接数算法）。
- 业务层幂等（Idempotency）：每条请求带唯一
X-Request-ID写入日志，重试时同一 ID 打两次不会在你数据库写两次订单 / 扣两次 Token 额度；这是容灾架构最容易被忽略、但最容易让事故放大 10 倍的一条。