23 可靠交付

23.1 基准变量

一次静态压测可以证明某个配置在某段时间达到某个数字，不能证明高峰、故障、发布和扩容期间仍能兑现承诺。可靠交付需要把基准、可观测性、服务目标、故障恢复和责任后果接成闭环，少一环，性能就只是实验结果。可复现基准先固定十五个变量：模型与权重版本、分词器、硬件具体型号与数量、显存与互联、精度与量化、引擎与内核版本、并行方式、KV 配置、长度分布、共享前缀、数据集、到达过程、并发、流式设置、预热和持续时间。这些条件缺失，吞吐和延迟无法解释；尤其不能把随机短提示词的峰值吞吐，拿来支持共享前缀的 agent 或长上下文业务。行业基准通过规定场景、质量门槛和计时规则提高可比性，可作外部标准化证据，但不能替代企业自己的真实链路和故障验收。核证据是逐级变硬的：规格说明可能，基准证明受控条件，动态压测证明负载曲线，试运行证明真实链路，SLA 把口径、监控、补偿和退出写进合同，上层结论不能由下层数字自动推出。

23.2 观测三层

可观测性至少分三层：请求层记请求标识、租户、模型、输入输出 token、首字、出字、端到端、取消、拒绝和错误；调度层记等待与运行请求、批次 token、KV 使用率、前缀命中、抢占、路由决策和冷启动；硬件层记温度、功耗、GPU 错误事件、ECC、各管线活动、显存、互联、网卡、存储和主机资源。只有请求层，知道用户慢却不知道为什么；只有硬件层，知道芯片忙却不知道谁受影响，三层要用请求、副本、节点和版本等稳定标识关联。核采集本身不是结果，必须连接责任人和处置动作：指标看趋势，日志记事件，追踪串链路，之后还要接值班人、处置手册、自动摘流或扩缩动作；问监控平台能触发什么动作，而不是看有多少图表。

23.3 目标协议

三个词各自解决什么：SLI 是实际测量值，SLO 是希望达到的区间，SLA 是带责任后果的对外约定，三者不能互换。核生成服务的 SLO 不宜只写 P99 小于两秒：要说明是首字、出字还是端到端，长度属于哪个桶，统计窗口多长，哪些错误纳入，客户端取消和超长输入怎样处理；否则服务方可以通过截短输出、拒绝长请求或改分词器来达标。一个 SLO 至少写六项：对象、指标、目标、窗口、排除与数据源，缺任一项，双方可能各自拿出一份达标报告。服务目标要从用户旅程倒推。同一个端点可能同时服务交互聊天、批量摘要和 agent 工具调用：聊天关心首字与持续生成，批量关心截止时间和总量，agent 还关心副作用和重试。把三者塞进同一个可用率，诊断意义和经营意义会一起丢掉。

23.4 错误预算

错误预算把可靠性目标变成可运营资源：SLO 为某窗口内 99.9% 成功，可接受失败预算就是剩余的 0.1%；预算消耗过快时，暂停高风险发布、增加容量或降低非关键流量。它的用处是给产品速度与可靠性的争论一个共同尺度。预算还应按原因分解：容量不足、软件发布、硬件故障、上游模型、网络和客户无效流量的处置各不相同，总预算告诉团队是否超标，原因预算告诉谁该做什么；一个依赖长期消耗大部分预算，需要的是架构隔离或合同边界，不是每月重复解释。

23.5 故障演练

故障恢复的稳健顺序是：发现异常、就绪检查摘流、停止新请求、尽量排空或迁移在途状态、重启或替换、校验权重与链路、预热、小流量回接、恢复全量。KV 是易失的请求状态：节点失败后重新 prefill 要付重复计算，迁移或恢复 KV 要付网络与一致性成本，相关的状态迁移研究说明这条路可走，不代表所有生产引擎已具备等价能力。核上线前至少演练：单卡错误、单节点失联、互联降速、对象存储不可达、权重校验失败、网关过载、路由配置错误、发布回滚和容量骤降。每次演练记录检测时间、摘流时间、在途请求结果、容量恢复时间、数据与计量一致性，以及错误预算消耗。演练还要包含负向场景：告警没触发、就绪检查失效、扩容拿不到节点、回滚版本不兼容。只证明最后恢复了，等于没有测到控制系统。

23.6 恢复目标

恢复目标要拆时间与状态损失：RTO 回答故障后多久恢复服务，RPO 在传统数据系统里回答能接受丢多少数据。在线推理的权重可重新装载，难点在在途请求、KV、计量和工具副作用：哪些状态可丢、哪些必须重建、哪些必须去重。对无副作用的文本生成，丢 KV 重新 prefill 可接受但增加延迟；对长上下文，重算可能超时；对已执行工具的 agent，简单重放会重复动作。恢复容量还要区分能接少量流量和完全恢复：新副本装载完、健康检查通过后，缓存仍冷、内核未预热，直接全量回接会产生二次延迟峰值，更稳的流程是金丝雀小流量、观察错误和 P99、再逐步放大。

技术验收包至少包括：版本基线、负载生成器与数据说明、原始测试结果、可观测字段、告警规则、处置手册、故障演练记录和未解决限制。SLA 里的每个可测条款应能映射到一个指标、一个数据源、一个责任人和一个处置动作。不能监控的条款无法自动执行，无法控制的指标不应由单方承担无限责任；反过来，运营方控制调度、容量与发布，就不能把所有性能偏差推给硬件厂商。这套责任映射怎样写进合同条款，见第 28 章。