容量、区域与可靠性：模型部署的公开 SLO 边界、重试和故障恢复

1. 从可观察信号建立可靠性模型

可靠性证据分三类：供应商写明的 API 或容量契约、自己测到的行为，以及没有披露的内部细节。下表只使用前两类。

2. 一个真正可操作的 LLM SLO 应拆成哪些部分

只指定 ‘平均 tokens/s’ 无法管理高峰、长 prompt、工具停顿或 model migration。交互请求通常需要 TTFT、inter-token latency、p95/p99 与 abort rate；离线请求需要完成窗口、partial failure、幂等回填；Agent 需要 task wall-clock、工具成功率和恢复成功率。

3. 托管模型：429、批处理、模型迁移与降级不是异常分支

API client 要把 rate-limit、5xx、stream interruption、content/safety decision、context overflow 和 tool parser failure 写进状态机。常用处理包括 token-aware concurrency、带抖动的指数 backoff、有限 retry、请求 id、idempotency key、budget cutoff、cache-miss fallback 和 provider circuit breaker。

模型更新需要 golden set 和 canary。即使模型名称没变，服务端版本也可能改变输出、工具格式、token 计数和 cache 行为，因此要保留版本或日期、响应 metadata、prompt/template hash 与 evaluation artifact。跨 provider fallback 还要逐家验证 tool schema、媒体格式、content policy 和价格，不能只替换 endpoint。

4. 自建集群：状态机、观测和故障域

自部署服务要能回答这些问题：request/KV prefix 在哪里，使用哪一版模型、precision 和 layout；worker 故障后能否 fencing；P/D transfer 是否幂等；网络拥塞是否在放大 tail；MoE/TP collective 有没有持续 straggler；一个 replica 丢失后是否还有足够余量。指标必须能关联到请求、GPU、NIC、queue、KV object 和 model revision，数量多并不等于可诊断。

训练与推理共池时，checkpoint、elastic parallelism、热模型与冷模型、优先级和实验 rollout 还会争用资源。共池页、fabric 观测页和 Systems for ML 的训练可靠性论文目录继续展开这一层。

5. 区域、数据驻留、处理与模型版本：不要用模糊词做合规承诺

区域策略要逐模型、逐 feature、逐时间点记录：请求数据存储在哪里；推理处理允许在哪里；cache 是否包含在适用范围；Batch / tools / logging 是否不同；是否需要指定 project、region、model version 或企业合约。OpenAI 文档明确存储与处理不同；Google PT 的作用域是控制面项；某个 xAI 产品在某日期的地区限制不能被外推到所有模型。

当文档没有保证时，应在系统风险表中写 ‘未公开 / 未承诺’，并选择合适 provider、企业功能或本地部署，而不是通过 IP、endpoint 或营销页猜测。

6. 可靠性演练清单

1. 用低配额/模拟 429 验证 token-aware backoff 和公平队列。
2. 中断流式响应和工具调用，验证幂等恢复与重复副作用防护。
3. 做 model version canary：黄金集、schema、cost、latency、cache hit 和安全行为逐项比较。
4. 自建服务在 worker loss、NIC degradation、KV directory outage、cache eviction 和 P/D transfer timeout 下做 chaos test。
5. 针对 region/data policy 保存官方来源、版本、测试日期和默认行为，变更时触发复审。
6. 把成功定义成恢复后的业务正确性，而不只是 HTTP 200 或 GPU 仍有利用率。

7. 观测：把 SLO 追到 request、state 与故障域

至少关联 request trace、model revision、queue/admission、cache state、worker/GPU/NIC、tool environment 与最终业务结果。这样才能区分：是 provider 429、KV miss、TP/EP collective tail、工具超时、模型迁移还是用户输入分布造成回归。指标只报集群平均 GPU 利用率或 API 成功率，无法定位跨层长尾。

8. 容量规划：为 miss、故障和模型迁移预留空间

容量模型应包含 cache-miss 峰值、热模型切换、一个 replica/链路失效、Batch 回填、Agent 长尾和安全预算，而不是仅按平均 QPS。对于托管 API，将公开配额和实际压测分开；对于自建服务，将权重、KV、workspace、网络和恢复资源分开。容量承诺越关键，越应使用供应商明确的合同/控制面而非营销吞吐数字。

9. 一手来源