运营契约：SLO、成本、事故与多租户

一套技术栈只有在能说清它承诺什么、花费什么、怎样失败、由谁共享、失败后相信哪份记录时，才真正成为基础设施。前面的实践章已经搭出了这份答案的各个部件：第 88 章 给出了接缝，第 89 章 把发布变成统计意义上的提升问题，第 90 章 把可靠性从精确回复转到被评判的分布，第 91 章 把人工批准放进运行时循环，第 92 章 则把生产轨迹变成下一轮证据。这里缺的是把这些部件扣在一起的运营契约。

旧的生产运维方法仍然有效。服务水平指标和服务水平目标让服务拥有可度量的承诺 (Beyer et al. 2016)；事故指挥把决策、实际修复、沟通和规划分开，避免系统承压时各自为战 (Beyer et al. 2016)；FinOps 把成本变成工程、财务和产品共同承担的运营纪律，而不是月底才看的账单 (FinOps Foundation 2026)；多租户把公平性、隔离和分摊计费变成平台设计问题 (Kubernetes 2026)。AI 改变的是这些纪律承载的对象。服务不只是可达或变慢，也可能流畅但错误；成本不只是 CPU 小时，而是词元、GPU 秒、评判调用、检索、重排和人工审查；事故也不只是宕机，还可能是质量退化、策略失败、成本失控、溯源失败或租户泄漏。运营契约必须覆盖这些表面。

契约表面

一个 AI 产品至少有五份契约。它们都应当写下来、接入仪表，并在路由流量的同一批接缝上执行。

图 93.2 把契约表面画成一个控制面，而不是一份文档。请求从网关进入，网关不只是转发请求，还附上租户身份、预算、路由策略、轨迹 ID 和服务目标。智能体运行时、检索层、沙箱、评测框架和模型服务都继承这个信封。出事时，操作者要回答的头几个问题也从这个信封里来：谁受影响，什么发生了变化，花了多少钱，哪条边界被跨过，哪条轨迹能复现。

语义系统的 SLO

传统 SRE 先问哪些用户可见行为重要，以及如何度量它们 (Beyer et al. 2016)。模型系统里，答案至少有三类。前两类很熟悉：服务必须可用，也必须足够快。第三类是语义质量。一个回复可以很快抵达，同时仍然违背产品承诺。

质量 SLI 是一条被采样、被评判的通过率。这里 $n$ 表示一个窗口内采样到的生产事件数，若回复通过任务准则，则 $s_i = 1$，否则 $s_i = 0$：

$$\hat q = \frac{1}{n}\sum_{i=1}^{n}s_i .$$

其中，$\hat q$ 表示这个窗口里的质量通过率，$n$ 是采样事件数，每个 $s_i$ 表示单个事件的评判结果。由于样本有限，运营决策应该看置信下界，而不是只看点估计。给定目标 $q^\star$，只有当下界仍高于 $q^\star$ 时，某个发布或路由才算健康。这条规则能防止系统把一个幸运的小样本误当成证据。第 48 章 提供度量纪律，第 90 章 提供非确定服务模型；契约把它们接到告警规则和发布闸门上。

交互曲线展示这项权衡。横轴是额外评测、回退或审查花费，纵轴是残余线上风险。滑块控制风险下降的半衰期。脆弱系统的半衰期很长：多花一块钱也去不掉多少风险。被充分仪器化的系统半衰期较短：有针对性的评测切片、有效验证器和回退能快速拿掉用户实际遇到的失败。

import math

def wilson_lower(passes, n, z=1.96):
    if n == 0:
        return 0.0
    phat = passes / n
    denom = 1 + z * z / n
    center = phat + z * z / (2 * n)
    margin = z * math.sqrt(phat * (1 - phat) / n + z * z / (4 * n * n))
    return (center - margin) / denom

target = 0.92
for n, passes in [(50, 48), (200, 188), (1000, 935)]:
    point = passes / n
    lower = wilson_lower(passes, n)
    decision = "ship" if lower >= target else "hold"
    print(f"n={n:4d}, point={point:.3f}, lower95={lower:.3f}, target={target:.2f}, decision={decision}")

这样的写法也能防止 SLO 变成口号。「回答有帮助」不是 SLO；「滚动一天内，客服回答的采样样本至少 92% 通过有依据的解决准则，95% 置信下界高于 90%，同时 p95 延迟低于 4 秒」才是系统能执行的 SLO。具体数字是产品选择，结构不是。

成本治理是运行时控制

成本治理必须坐在请求路径上。月底报表来得太晚，拦不住失控智能体、误路由评判者，或者悄悄把输出长度翻三倍的提示模板。FinOps 在这里有用，是因为它把成本定义为工程、财务和产品共同参与的运营纪律，明确地在速度、成本和质量之间做权衡 (FinOps Foundation 2026)。FOCUS 是 FinOps 的成本与用量数据开放规范，它也有用，因为统一后的成本数据能让 AI 花费与云、SaaS、数据中心账单放在同一张表里，而不是困在某个供应商导出里 (FinOps Open Cost and Usage Specification 2026)。下文的词元计量已经写进了这套规范：FOCUS 的虚拟货币列承载词元的购入与消耗进度（burn-down），2026 年 6 月批准的 1.4 版则把按模型统计的词元消耗划入了下一版的范围。

运行时账本应该记录一项任务的单位经济，而不只是总账单：

$$C = \sum_r \left( p_{\text{in}}m_{\text{in},r} + p_{\text{out}}m_{\text{out},r} + c_{\text{gpu}}t_{\text{gpu},r} + c_{\text{judge}}j_r + c_{\text{review}}h_r + c_{\text{store}}g_r \right).$$

换句话说，每个请求 $r$ 都贡献输入词元、输出词元、GPU 时间、评判调用、人工审查和存储这些项；系数则分别是这些仪表的外部价格或内部单位成本。重点不是每一项都能精确已知，而是契约要命名仪表：输入词元、输出词元、GPU 时间、评判调用、人工审查分钟和存储。一旦仪表被命名，网关就能在账单抵达之前执行预算：

• 把简单任务路由到便宜模型，把困难任务路由到更强模型；
• 按任务类别和租户限制工具循环；
• 预算耗尽时拒绝或延迟流量；
• 把缓存输入折扣和自托管容量分配给实际制造需求的租户；
• 把评测、评判和人工审查计入产品成本，而不是藏成平台开销。

难点更多是组织性的，而不是数学性的。模型团队可能想用更多测试时算力换质量；产品团队可能想要更低延迟；财务团队可能要求硬成本上限。运营契约把这种冲突显式写出来：什么情况下哪个目标优先，以及谁可以改阈值。

事故类别

事故管理之所以存在，是因为人在压力下容易各自行动、重复劳动并丢失状态。Google SRE 的实践把这个一般问题说得很清楚：区分事故指挥、实际操作、沟通和规划，并维护一份实时事故状态文档 (Beyer et al. 2016)。AI 系统需要同样的角色，只是事故分类比「服务挂了」更宽。

图 93.4 画出事故循环。检测只是第一步。操作者还要指挥、缓解、沟通、保存证据，并把失败变成回归测试或已接受风险。Sculley 等人关于机器学习系统隐性技术债的警告在这里很贴切：未声明消费者、反馈循环和胶水代码会制造直到生产中才显形的故障 (Sculley et al. 2015)。事故循环就是把这些隐藏依赖变成明示依赖的机制。

最后一条边是许多组织失败的地方。复盘开完了，系统却没有改变。在 AI 基础设施里，如果一份复盘没有增加评测样本、预算护栏、路由规则、租户隔离控制、数据质量检查或人工批准门，它就只是文字，还没有改动机器。

多租户与噪声邻居

AI 多租户不只是 Kubernetes 命名空间。一个租户会共享 GPU、KV 缓存、批处理槽位、向量索引、评判容量、工具服务器、沙箱，有时还共享人工审查队列。Kubernetes 文档列出了熟悉的隔离工具：命名空间、访问控制、配额、沙箱、节点隔离、API 优先级和 QoS (Kubernetes 2026)。AI 继承这些工具，又增加了语义边界。

租户契约必须回答四个问题。

1. **容量：**一个租户的长上下文或智能体负载，能不能把另一个租户推过延迟 SLO？
2. **数据：**一个租户的提示、检索片段、缓存前缀（服务引擎为共享提示前缀保留并重放、以省去重算的键值缓存）、轨迹或标签，能不能进入另一个租户的上下文或训练流？
3. **权限：**一个租户的智能体，能不能触达另一个租户的工具、凭据或出站路径？
4. **账务：**平台能不能解释谁消耗了词元、缓存词元、GPU 秒、评判调用、审查分钟和存储？

隔离强度应当跟影响半径匹配。低风险内部助手也许只需要命名空间和配额边界；会运行不受信代码的客户侧智能体则应该使用沙箱或租户专用节点池；受监管客户可能需要单独索引、单独加密密钥、单独模型路线和单独保留策略。错误做法是把多租户当成一个平台开关。它其实是一组隔离选择，每一种都有不同价格。

治理不应另起一本书

治理在书的其他地方表现为法律、安全、来源和监督。运营契约把它变成可执行机制。NIST AI Risk Management Framework 把 AI 风险管理描述为贯穿设计、开发、使用和评估的可信度流程 (National Institute of Standards and Technology 2023)，其生成式 AI profile 又列出生成式系统特有的风险 (National Institute of Standards and Technology 2024)。运营上的翻译非常具体：

• 一条策略要求变成网关规则或批准门；
• 一条数据要求变成轨迹里的来源和保留字段；
• 一条透明度要求变成引用、不确定性或披露界面；
• 一条安全要求变成评测切片、沙箱边界或工具白名单；
• 一条问责要求变成事故角色、审计记录和责任人。

Microsoft 的 GenAIOps 指南从工作负载角度提出了同样的实务判断：AI 工作负载具有非确定性，需要围绕漂移、监控、治理、部署和持续运营建立流程 (Microsoft 2024)。按本书的说法，治理不是漂浮在技术栈上方的审查会，而是一组编译进路由、评测、数据、事故和租户机制的约束。

权衡

运营契约会带来开销。它给每个请求增加元数据，给每起事故增加状态，给每条路线增加仪表，给每次发布增加证据要求。团队也可能做过头：一个小原型会被面向受监管多租户平台的控制淹没。契约应当随影响半径增长。第一份契约可以很简单：固定模型、预算上限、轨迹 ID、回滚规则和一套质量评测。不能推迟的是决定契约住在哪里。如果它只住在聊天记录和表格里，系统就无法执行它。

基础设施意味着被运营

本书标题里的基础设施，是一个要求更高的词。基础设施不只是一套能搭出来的栈；它还必须能被承诺、被计量、被共享、被修复、被审计，并在失败后继续改进。运营契约就是把这些动词放进系统里的机制。

能力是契约交付的产品：系统能否在真实用户带来的条件下完成任务。效率是契约里的预算：系统有没有把词元、GPU 秒、评判调用和人的注意力花在能改变结果的地方。信任是契约里的证据：团队能不能解释为什么发布、影响了谁、花了什么、在哪里失败，以及失败之后改了什么。没有这些答案的技术栈也许很强，但还不是基础设施。

延伸阅读