书籍介绍

欢迎阅读《AI Engineering：大模型与智能体系统工程》。

这不是一本只介绍工具用法的书，而是一套面向软件工程师与架构师的 AI Engineering 知识体系。它关注一个更长期的问题：如何理解模型能力，如何稳定地生产和交付模型能力，以及如何把这些能力构建成可验证、可治理的应用系统。

全书沿着“理解模型能力 → 生产与交付能力 → 构建应用系统 → 评估与持续改进”的工程主线展开，覆盖大模型原理与算法、基础设施、Agent 系统、应用实战和前沿研究。Agent 是重要的应用系统形态，但不代表全书的全部范围。

全书工程主线图

本书按“大模型原理与算法 → 大模型基础设施 → Agent 系统工程 → Agent 应用与实战 → 前沿研究与工程展望”五部分展开。主线不是“学一堆工具名”，而是先理解模型能力如何形成，再理解模型如何被训练、部署、评估和治理，之后把模型放进可约束、可验证的应用与 Agent 运行环境，最后用真实案例和研究专题判断下一步能力边界。

flowchart LR
    A["第一部分：大模型算法<br/>原理 / 训练 / 推理 / 能力"] --> B["第二部分：大模型 Infra<br/>训练 / 推理 / 数据 / 治理"]
    B --> C["第三部分：Agent 工程<br/>Prompt / Context / Runtime"]
    C --> D["第四部分：Agent 应用与实战<br/>Coding / 企业知识 / Hermes"]
    D --> E["第五部分：前沿与研究<br/>Research Agent / 多模态 / 具身"]

本书解决什么问题

AI 工程实践里最容易踩的坑，不只是模型输出不稳定，也包括训练、推理、数据、评估和应用之间缺少清晰边界。我们把不清楚的意图、不完整的上下文、没有边界的工具和没有验证回路的流程交给模型，结果往往是第一版看起来很聪明，后续版本不断补洞并引入新问题。

本书的主线是把从模型能力到应用交付的过程，逐步收敛成可复用、可审查、可验证、可治理的工程系统。

读完之后，你应该能够回答六类问题：

• 模型边界：LLM 擅长什么、不擅长什么，这些边界如何影响系统设计？
• 能力交付：如何设计训练、推理、数据和评估基础设施，让模型能力稳定、经济地交付？
• 任务协议：如何通过 Prompt、结构化输出和 Context 降低任务歧义与输出漂移？
• 系统落地：如何通过 Harness、工具、知识、记忆和工作流构建 Agent Runtime？
• 生产治理：如何评估、监控、调试、回滚并持续优化一个 Agent 系统？
• 现实应用：如何把大模型与 Agent 用到编程、告警处理、企业知识、个人知识管理和研究任务中？

适合谁读

本书主要面向已经参与过真实软件项目的读者，包括后端工程师、AI 应用工程师、技术负责人，以及正在把 AI 编程或 Agent 系统引入团队流程的人。

你不需要是大模型研究员，但最好具备以下基础：

• 能读懂一种主流编程语言的代码示例；
• 理解 API、数据库、测试、日志、部署、权限等基本工程概念；
• 对 LLM、RAG、Agent、MCP、Evals 等术语有初步印象，遇到细节时愿意回查。

如果你刚开始接触 AI 工程，建议按章节顺序建立基础；如果你已经在团队里落地 Agent，则可以直接从第三部分的 Agent 架构、工具、知识系统和生产治理部分切入；如果你负责平台建设，则可以优先阅读第二部分。

内容结构

第一部分：大模型原理与算法

这一部分建立全书的模型基础：理解 LLM 的能力边界、训练与推理机制，以及模型能力如何影响系统设计。它回答“模型能做什么、不能做什么、工程上为什么不能把模型当成万能组件”。

第二部分：大模型基础设施

这一部分把算法模型放进真实系统，覆盖资源模型、训练、推理、数据评估、运行时、可靠性与治理。它回答“模型如何稳定训练、低延迟服务、持续评估，并在故障、成本和安全约束下长期运行”。

第三部分：Agent 系统工程

这一部分讨论如何把大模型组装为真正可运行、可恢复、可治理的 Agent 系统。基础设施章节关注平台如何提供运行能力；本部分关注任务协议、上下文、Harness、模型协议、工具、知识、记忆、编排和行动控制如何共同形成应用级 Runtime。

第四部分：Agent 应用与实战

这一部分将前面三部分的能力放到现实工作中：先拆解成熟产品，再落到企业和个人任务。它关心的是“如何用大模型与 Agent 完成一项可交付、可验证、可治理的真实工作”。

第五部分：前沿研究与工程展望

这一部分讨论工程实践之外仍在快速演化的前沿问题。它不局限于 Research Agent，后续可扩展到多模态、具身智能、长期学习和世界模型等专题。

附录

附录只保留 A：术语与符号速查、B：学习路径与延伸阅读、C：工具、框架与版本导航。章末练习由附录 B 提供短链接，论点来源以各章末参考资料为准。

贯穿案例与练习的阅读方式

全书保留五部分、31 个公开章节，沿用原编号与源码路径，编号不连续处不重排。三个教学案例分别检验不同责任边界：

章节包含原理推导、文档核验、教学轨迹与实验设计，验收层次分别标明。第1/3/5/8/9章的练习卡可从附录B进入；卡片完成不代表已经提供完整可运行代码、GPU测量或生产验证。选型先查附录C的版本和未知项，再回到章末原始来源。

与工程面试题库配合阅读

本书也可作为 AI 与 AI Agent 工程面试题库的原理与设计参考。题库保留每题的章节、小节链接、覆盖状态与缺口原因；本书按模型能力、基础设施和应用系统组织论证，不复制另一套逐题答案。定位以活动目录中的正文为准，归档材料、论文名或工具名本身不算覆盖。

“已覆盖”表示书中能找到主要原理和设计依据，可以组合相邻章节回答；它不表示已提供所有 SDK 的最新实现、个人项目经历或生产性能数据。“部分覆盖”会说明缺少的实现、实测或完整领域案例。阅读时应区分以下边界：

书中案例与练习没有运行证据时，保持“教学设计”或“未实测”标识。外部接口、模型卡与硬件支持仍须核验具体版本；用户自己的经历不能用书稿案例代替。

在线阅读

• GitHub Pages：https://wxquare.github.io/ai-book/
• 源码仓库：https://github.com/wxquare/wxquare.github.io

反馈与贡献

欢迎通过 Issue、Pull Request 或博客留言提供反馈。尤其欢迎三类反馈：

• 哪些章节读起来跳跃，缺少承上启下；
• 哪些代码或架构图难以复现；
• 哪些工具、模型或最佳实践已经过时。

版本信息

• 当前版本：v1.0
• 发布日期：2026 年 4 月
• 本轮编辑复核：2026 年 10 月 18 日；来源核验日期按各章记录，不代表所有产品当天重新测试。
• 更新计划：持续更新，优先深化大模型基础、AI 基础设施、Agent 运行时、成熟系统解析、案例、评估体系和生产治理实践。

第1章 从 Transformer 到 Agent：模型结构如何影响系统能力

语言模型可以解释退款政策、生成补丁，也可以输出一段工具参数。但“生成了什么”与“系统已经完成什么”之间，还有事实、权限、执行与验证。本章先拆开一次模型前向计算，再把它放回受控行动的系统，回答两个相连的问题：模型的候选能力从哪里来，哪些责任必须由模型之外的组件承担？

以下退款和代码修复场景均为教学假设。它们不代表某个企业系统的实际实现，也不把某个模型家族的配置当作行业通用配置。我们将用同一套张量符号解释 Transformer、头共享和缓存，再沿预训练、后训练、推理期计算走到 Agent；后续章节分别展开训练与运行细节。

1.1 从序列预测到可扩展模型

语言模型估计序列出现的概率。对 token 序列 \(x_1,\ldots,x_N\)，自回归分解为：

\[ p(x_1,\ldots,x_N)=\prod_{t=1}^{N}p(x_t\mid x_{<t}). \]

这是概率的条件分解，不是在宣称模型拥有人的理解或业务权限。早期 n-gram 用局部计数估计条件分布，长窗口会面临稀疏组合；神经概率语言模型联合学习词的连续表示与预测函数，让相近表达共享统计信息。Bengio 等的工作是这条路线的重要节点。[1]

表示共享解决了部分泛化问题，却没有消除序列计算的瓶颈。循环网络沿时间步传递状态，后一状态依赖前一状态，同一条样本的训练难以完全按位置并行。早期编码器—解码器还把整个输入压入固定长度表示。Bahdanau 等让解码器在生成时对输入位置做软对齐，针对的是固定向量瓶颈；其模型仍包含循环计算，不能把“出现 Attention”直接写成“已经是 Transformer”。[2]

Transformer 的转折在于，用注意力组织位置之间的信息交换，不再依赖循环结构串行形成全部隐藏状态。原论文在机器翻译上验证了这种结构的并行潜力。训练时目标序列已知，可以同时构造各位置的条件预测；因果掩码阻止读取未来标签，所以并行不等于泄漏答案。生成时未来 token 尚不存在，下一步仍依赖刚选出的 token。训练并行与生成串行可以同时成立。[3]

因此，从循环模型到 Transformer 的因果链是：序列依赖限制计算并行，注意力改变信息传递路径，并行训练让更大规模的数据与参数组合成为可能。它不是“注意力一出，所有任务自然解决”的历史。成本也随之移动：不用把远距离关系逐步压进一个循环状态，却要计算许多位置间的关系，维护更大中间状态，并处理位置和可见性。

对工程师而言，这个转折带来一个可检验的问题：一次失败来自模型没学会任务，还是输入并未按预期进入计算？若文本被截断、因果边界错位或缓存复用了其他请求的状态，更大的模型也无法修复输入契约。我们先把“字符串进、字符串出”拆成可以逐轴检查的前向路径，再讨论它如何形成能力。

1.2 一次前向计算的完整路径

统一符号与两种长度

全章以批量优先的语义形状表达张量；实际框架可能转置、融合或分片。\(B\) 是批量大小，\(T\) 是当前查询长度，\(S\) 是键值长度，\(D\) 是残差流宽度，\(H_q\) 与 \(H_{kv}\) 分别是查询头和键值头数，\(d_h\) 是每头 Q/K 维度，\(d_v\) 是每头 V 维度。\(L\) 为层数，\(V_{\mathrm{ocab}}\) 表示输出词表投影行数，避免与 Value 张量 \(V\) 混用。普通教学示例设 \(d_h=d_v\)、\(D=H_qd_h\)，这些等式不是所有模型的定义。

训练的自注意力通常有 \(T=S\)。增量生成时，单个新查询可以有 \(T=1\)，而 \(S\) 包含历史缓存与当前 token。只写一个“序列长度”会掩盖这种差别。跨注意力的查询和键值来自不同序列，二者长度也可以不同。中文教材《动手学深度学习》用批量、时间步、隐藏维三轴解释 Transformer，适合作为本节形状阅读的补充。[4]

Tokenizer 把输入文本编码为整数 ID，得到 \([B,T]\)。Embedding 是可学习表 \(E\in\mathbb{R}^{V_{\mathrm{ocab}}\times D}\)，按 ID 查表得到 \(X\in\mathbb{R}^{B\times T\times D}\)。这里没有按汉字直接索引的保证：一个汉字、一个英文词、一个空格与代码片段可能对应不同数量的 token。文字看起来相同，也应先确认实际 token ID、特殊符号和聊天模板是否一致。

Embedding 后需要让计算知道位置，但位置机制不总是一个加法。原始正弦位置编码可与输入表示相加；RoPE 则在注意力中的 Q/K 上施加旋转。所以下图把位置规则标在 Block 内，不把所有模型都画成“Embedding 加一个位置向量”。位置如何影响点积，在1.4节继续解释。

flowchart TD
    A["token IDs: B × T"] --> E["Embedding: B × T × D"]
    E --> N["Block 输入 / Norm: B × T × D"]
    N --> Q["Q: B × Hq × T × dh"]
    N --> K["K: B × Hkv × S × dh"]
    N --> V["V: B × Hkv × S × dv"]
    Q --> P["位置规则 + QKᵀ + mask<br/>分数 / 权重: B × Hq × T × S"]
    K --> P
    P --> Z["加权 V: B × Hq × T × dv"]
    V --> Z
    Z --> O["拼接 + 输出投影: B × T × D"]
    O --> R["残差 + FFN + 残差<br/>重复 L 个 Block"]
    R --> F["最终 Norm / 词表投影<br/>logits: B × T × Vocab"]
    F --> G["选择下一 token<br/>追加后继续生成"]

图中的 \(S\) 在无缓存自注意力中等于 \(T\)；使用缓存时，K/V 节点含“历史状态加当前投影”。残差连接在图中简写为输出阶段，实际 Pre-Norm Block 的两条残差路径见1.4节公式。最终 Norm 是常见现代布局，原始 Transformer 的归一化位置不同。图是形状契约，不是某个框架的逐算子执行图。

隐藏状态、logits 与标签

每个 Block 保持残差流的 \([B,T,D]\) 形状。经过全部层后，输出投影 \(W_U\in\mathbb{R}^{D\times V_{\mathrm{ocab}}}\) 将隐藏向量映成每个词表项的分数。logits 还不是概率；沿词表轴应用 softmax，才得到当前位置预测下一个 token 的条件分布。输出表是否与 Embedding 共享权重，取决于具体结构，不能仅因维度兼容就默认共享。

把教学序列写成“开始、我、想、退款、结束”。训练时输入可为前四个位置，标签为后四个位置：用“开始”预测“我”，用“开始、我”预测“想”，依次类推。输入位置的隐藏状态可以含当前位置的 token，因为它预测的是下一个 token。标签若没有右移，模型可能学到复制输入；若被右移两次，又会训练错误目标。检查 loss 降低之前，要先打印一小条输入和监督位置。

生成时先处理提示前缀，即 prefill，得到最后一个有效输入位置的 logits；选出的 token 追加进序列，再进行下一步 decode。Padding 批次不能无条件取数组最后一格：右侧补齐时，那里可能是无效位置，调用方需要按实际实现找到最后有效位置。停止符、最大生成长度和后处理，也会影响用户最终看见的字符串。

由形状还可得到资源上的教学推导：若训练保留全部 \([B,T,V_{\mathrm{ocab}}]\) logits，词表维会带来明显中间量；实现可以用融合损失等方法改变实际内存分配，因此“写出了这个形状”不代表一定完整物化它。相同原则贯穿本书：先写语义张量和依赖，再讨论框架如何节省存储，不把数学对象与实际分配强行等同。

1.3 Attention 与 Q/K/V 的计算

匹配空间与内容空间

对单层输入 \(X\)，标准多头自注意力通过不同的可学习投影得到 Query、Key 和 Value。暂设 \(H_q=H_{kv}=H\)，且各头维度相同：

\[ Q=XW_Q,\qquad K=XW_K,\qquad V=XW_V. \]

其中 \(W_Q,W_K\in\mathbb{R}^{D\times Hd_h}\)，\(W_V\in\mathbb{R}^{D\times Hd_v}\)；再把最后一轴拆成头轴并转置，形成 \(Q,K:[B,H,T,d_h]\) 与 \(V:[B,H,T,d_v]\)。原始多头机制是在多个投影子空间中分别计算，再拼接输出。[3]

Q 表达“当前位置按什么特征寻找信息”，K 表达“各位置按什么特征被匹配”，V 提供被聚合的内容。这是帮助理解的类比，不意味着某个向量有稳定、可直接命名的语义字段。Q/K 的最后一轴必须兼容，才能计算点积；V 只需与 K 在来源位置轴上一一对应，其特征宽度可以不同。

因此，把三个投影合成一个权重矩阵做一次大矩阵乘法，是实现上的融合，并不使三种角色相同。若强行令 Q 与 K 共享同一投影，就给匹配关系增加结构约束；模型是否接受这种约束，要靠训练与评估决定，而不是因代码更短就视为等价替换。跨注意力进一步说明了角色区别：Q 可以来自目标序列，K/V 来自源序列，查询与被查询内容并不必来自同一组输入。

例如本书构造两条信息：第一条键表示“退款政策”，值是政策摘要；第二条键表示“物流时效”，值是配送说明。查询需要按主题匹配，输出却需要聚合具体内容。若用 V 直接替代 K，匹配就被迫使用内容空间；当内容维度不同，甚至无法与 Q 点积。即使维度相同，令 \(W_K=W_V\) 也改变了原来的参数化，原有模型的权重与结果不再自动保持。这个反例说明可以设计共享参数的结构，却不能无损删掉既有模型的 K。

缩放从哪里来

对每个头，计算为：

\[ A=\operatorname{softmax}_{S}\left(\frac{QK^{\mathsf T}}{\sqrt{d_h}}+M\right), \qquad Z=AV. \]

\(K^{\mathsf T}\) 只转置最后两轴；\(QK^{\mathsf T}\) 的形状是 \([B,H,T,S]\)。softmax 沿键位置 \(S\) 归一化，让一个查询对可见来源分配权重。它既不是沿头轴归一化，也不是在整个批次上分配概率。\(M\) 是可广播到分数形状的加性掩码，允许位置取零，禁止位置概念上取负无穷。

原论文用一个简化假设解释缩放：若 Q/K 各分量独立、零均值、单位方差，点积是 \(d_h\) 项乘积之和，方差随 \(d_h\) 增长；除以 \(\sqrt{d_h}\) 后保持量级。真实训练向量未必满足独立假设，不能把这个推导当作训练全程的精确分布模型。其作用是解释为什么大维度未缩放点积容易把 softmax 推向饱和区，而不是保证任何输入都得到均匀梯度。[3]

用一条教学查询手算可见性：假设三个键位置的未缩放匹配分数为零、零、很大的正数，但第三个位置被禁止。先加掩码，第三项不参与归一化，前两项权重各为二分之一；再乘 V，输出为前两个内容向量的平均。若先 softmax 再把第三个权重清零，却不重新归一化，前两项的和通常小于一，已经改变了数学定义。大匹配分数也不等于事实可信度，只说明当前参数表示下的匹配程度。

多头如何回到残差流

每个头输出 \(Z_h\in\mathbb{R}^{B\times T\times d_v}\)，拼接得到 \([B,T,Hd_v]\)，再乘 \(W_O\in\mathbb{R}^{Hd_v\times D}\) 回到残差流宽度。输出投影会混合各头的信息，不能把一个头的权重图直接当作最终答案的完整解释。多头允许学习不同的匹配与内容子空间，但不保证每头分别负责语法、数学或权限。

固定总宽度 \(D=Hd_h\) 时，增加头数会缩小每头宽度。它提供更多独立匹配分布，同时减少各头的特征空间；“头越多越好”没有从该等式中得到证明。若固定每头宽度再增加头数，总投影宽度和参数成本则会变化，已经不是同预算比较。评估应说明固定了哪个量，并把任务质量和运行成本一起记录。

一个常见错误是把转置后的 \([B,H,T,d_v]\) 直接按连续内存 reshape 成 \([B,T,Hd_v]\)。语义上要先把头轴与位置轴交换；某些框架的 view 还要求内存布局满足条件。只检查输出元素总数相同，无法发现位置与头被打乱。练习中应让不同头、不同位置具有可区分值，防止全零或重复输入掩盖轴顺序错误。

标准稠密注意力的分数对象含 \(BHTS\) 个元素，点积和内容聚合的计算随 \(TS\) 增长。自注意力 \(T=S\) 时出现二次项；这不等于整个 Transformer 的全部计算都只有这个项，投影与 FFN 也有成本。先确认工作负载受哪个量主导，再讨论长上下文优化，避免把一种局部复杂度写成整个平台的容量结论。

因果掩码、Padding 与全屏蔽行

因果掩码按绝对位置阻止查询读取未来。无缓存教学输入中，查询位置 \(i\) 可见 \(j\leq i\) 的键，因为该位置预测下一 token。Padding mask 则阻止读取无效的补齐键。两者组合表达“既有效、又在时间上可见”，不能把一个三角矩阵当作所有批次的完整有效性定义。原论文的遮蔽与输出错位共同维护自回归条件。[3]

缓存后的查询位置要加上前缀偏移。若前缀长为 \(P\)，当前块内第 \(i\) 个查询对应绝对位置 \(P+i\)，它可见的键界限是这个位置，而不是局部下标 \(i\)。直接生成 \(T\times S\) 的左上角三角阵，可能错误屏蔽大部分历史缓存。反过来，训练中把不同样本拼接时若没隔开样本边界，会让一个样本读取另一个样本；仅有因果性仍不足以保证数据隔离。

全屏蔽行需要单独定义。本节数学式对一行全为负无穷的分数没有正常的概率分布；直接相减最大值可能产生未定义值。用有限极小数代替又可能得到看似正常的均匀权重，所以“没出现 NaN”不能证明掩码正确。本书教学参考规定：有效查询至少有一个可见键；若输入违反，显式报错。用于处理 padding 查询的优化实现也可以约定零输出，但必须与调用方契约和测试一致，不能悄悄把无效行当正常预测。

1.4 Block 的稳定性与位置信息

残差与逐位置前馈

注意力让不同位置交换信息，FFN 在每个位置对特征作非线性变换。一个简化的 Pre-Norm Block 可写为：

\[ U=X+\operatorname{Attention}(\operatorname{Norm}(X)),\qquad Y=U+\operatorname{FFN}(\operatorname{Norm}(U)). \]

这里 Attention 包含输出投影。两次加法要求分支回到 \([B,T,D]\)；残差提供跨子层的直接路径，子层学习对现有表示的增量。它有助于优化深网络，却不保证每层输出都保留某个业务事实，更不是一个可以替代运行时状态的记事本。

普通两层 FFN 为 \(\operatorname{FFN}(x)=\phi(xW_1+b_1)W_2+b_2\)，先从 \(D\) 映到中间宽度 \(D_{ff}\)，经非线性再映回 \(D\)。同一组权重用于各位置，“逐位置”表示它在这一步不再跨 token 聚合，并不表示每个位置拥有一套不同参数。原始论文与中文教材均区分了注意力聚合和逐位置网络。[3] [4]

没有非线性时，两层线性变换仍可合成一个线性变换；中间扩维只有与非线性等机制结合，才提供不同的表达形式。现代门控变体会增加投影分支，不能拿普通两矩阵参数公式直接估算所有 FFN。教学层面可先把 Attention 理解为位置间的信息混合，把 FFN 理解为位置内的特征加工；但不要进一步声称“全部知识只存在 FFN”，因为最终行为依赖多层联合计算。

LN、RMSNorm 与 BN 比较什么

LayerNorm 在单个位置的特征维上计算统计量。对 \(x\in\mathbb{R}^{D}\)，其形式为：

\[ \mu=\frac1D\sum_i x_i,\quad \sigma^2=\frac1D\sum_i(x_i-\mu)^2,\quad \operatorname{LN}(x)_i=\gamma_i\frac{x_i-\mu}{\sqrt{\sigma^2+\epsilon}}+\beta_i. \]

它不依赖另一条请求是否放进同一个 batch，训练与推理沿用相同的归一化计算方式。Ba 等提出这种按样本归一化的思路，针对了批量统计在序列任务中的使用问题。[5]

RMSNorm 以均方根做缩放，通常写为：

\[ \operatorname{RMSNorm}(x)_i=\gamma_i\frac{x_i}{\sqrt{D^{-1}\sum_jx_j^2+\epsilon}}. \]

它省去显式减均值，不等同于把 LN 中心化结果换个名字。论文在多种任务上验证了简化方案，但具体耗时收益与硬件、算子融合、精度有关，不能引用一组实验比例承诺所有大模型都同幅提速。\(\epsilon\) 防止分母过小，其位置和计算精度属于实现契约，需要在复现时检查。[6]

归一化放在哪里也影响优化。Post-Norm 对“输入加子层输出”再归一化，Pre-Norm 则先归一化输入、再走子层与残差相加。Xiong 等分析了两者初始化时的梯度差异，并在研究配置中探索减轻 warmup 需求。不能把它推广为任何 Pre-Norm 大模型都无需学习率预热；优化器、深度与训练规模仍需共同验证。[7]

BN 的典型统计轴包含 mini-batch，而 LN 的本节定义沿特征轴；BN 训练时估计批量统计、推理时常用累计统计，所依赖的信息不同。Ioffe 与 Szegedy 提出了 BN 的机制与实验。对本书序列教学场景，批大小变化、可变长度和在线单请求会使批量统计契约更复杂，这是选择 LN 类方案时应考虑的条件，而不是“BN 在任何序列模型里都错误”的结论。[8]

替换归一化还会改变已训练模型的函数，不能把相近用途等同于无损兼容。对已有权重，应在转换方案、继续训练和回归证据齐备后再判断是否可替换；对新训练配置，则应记录归一化位置和参数，避免制品同名而计算不同。

用教学输入可以检查统计轴：令两条样本完全不同，只改第二条样本，第一条样本某位置的 LN 结果不应因第二条而变。再对同一位置各特征加同一个常数，忽略数值误差时，LN 的中心化会消去这个平移；RMSNorm 一般没有同样的不变性。这些是公式可推得的性质，适合用来识别错误的归一化轴，不需要用模型跑分代替基础算术验证。

顺序如何进入计算，扩窗为何还要验证

如果没有任何位置机制，单纯的自注意力难以区分仅由位置置换造成的差异；因果可见性虽引入方向约束，仍不能代替完整的位置表示。原始 Transformer 使用正弦位置编码；不同频率为不同距离提供可组合信号。绝对位置表、旋转位置与分数偏置是不同设计，不能在图中随意互换。[3]

RoPE 将成对特征按位置旋转。用 \(R_m\) 表示位置 \(m\) 的旋转，匹配可写为 \((R_mq)^{\mathsf T}(R_nk)=q^{\mathsf T}R_m^{\mathsf T}R_nk\)；成对旋转具有相对位移结构，使点积包含 \(n-m\) 的关系。这个等式解释位置怎样进入匹配，不证明模型在训练外的任意距离都能可靠推理。[9]

ALiBi 不向 Embedding 加位置向量，而是在分数上加入与距离有关的线性偏置。论文展示了特定模型与语料上的长度外推实验；这种证据应保留配置前提，不能写成“加偏置就无限上下文”。RoPE 与 ALiBi 都改变了模型使用距离信息的方式，但其作用位置和归纳偏好不同。[10]

因此，扩窗至少要分别检查三个层面：算子能否接受更大位置索引，计算与缓存是否装得下，模型是否真正用上远处证据。窗口字段变大，只能说明某项配置允许更长输入；若关键条款在中段仍被忽略，业务能力并未因配置通过而自动达标。教学评估可把同一事实放到开头、中间和末尾，再插入干扰与否定条件，分别观察检索、引用和判断是否变化。这里的评估方案是本书建议，不能当作位置论文已经证明的产品结论。

1.5 架构变体与资源代价

架构、可见性与目标要一起读

Encoder、Decoder 和 Encoder–Decoder 首先描述信息如何连接，训练目标再决定模型因什么监督信号更新。BERT 用双向上下文学习表征，适合通过任务头等方式进行理解任务微调；它的掩码语言建模不是直接从左到右预测完整文本的同一个目标。[11] T5 将不同任务统一成 text-to-text 接口，其迁移学习框架并不要求所有模型都改为单一 Decoder。[12] GPT-3 则展示了自回归模型在无需参数更新的上下文少样本设置下完成多种任务的能力与限制。[13]

具体到原始 LLaMA，它属于因果生成路线，并在报告中采用 Pre-Norm、RMSNorm 与旋转位置机制；与 BERT 的双向遮蔽表征路线相比，差别同时包括训练目标、可见范围与常见输出用途，不能只按开源与否分类。[14] 这段结论限定在原版报告，不代替后续代际的配置核验。

T5 的跨度破坏会把连续缺失片段换成 sentinel 标记，目标序列用这些标记串起待恢复片段；解码器通过跨注意力读取编码器结果。[12] GPT-2 则用因果语言建模连续预测后续文本，采用 Transformer 语言模型结构；它没有 T5 那样独立的源序列编码器与编码器—解码器跨注意力。[15] 因此，接口都能返回文本，不等于它们的监督位置和条件路径相同。

从本书工程视角推导，Decoder-only 可将提示、示例与输出组织在同一序列中，接口与部署链路较统一；Encoder–Decoder 则显式区分源输入与目标生成，适合比较输入输出职责清晰的条件生成任务。这些是结构取舍，不是对“流行程度”的市场统计，也不证明前者在所有任务、长度和预算上更优。

表格用于选择阅读方式，不是永久的能力分区。Encoder 可以参与生成系统，Decoder 也可提取表示；是否适合任务，还要看训练方法、输出接口和评测结果。不能从“只有 Decoder”推断它没有理解能力，也不能从“能读取完整输入”推断它获得了正确授权的最新事实。

MHA、MQA 与 GQA 减少了什么

MQA 让不同查询头共享一组 K/V，以减少增量生成时需要写入和读取的缓存。它保留多个查询头，而不是把整个模型改成一个注意力头。Shazeer 的工作指出了这种共享与解码带宽之间的关系。[16] GQA 位于 MHA 与 MQA 之间：\(H_q\) 个查询头分为 \(H_{kv}\) 组，每组共享一个 K 头和 V 头；\(H_{kv}=H_q\) 回到 MHA，\(H_{kv}=1\) 回到 MQA。[17]

按本章约定，Q 的形状仍为 \([B,H_q,T,d_h]\)，K/V 的头轴缩为 \(H_{kv}\)。令每组查询数 \(g=H_q/H_{kv}\)，教学实现要求 \(H_q\) 能被 \(H_{kv}\) 整除，第 \(h\) 个查询头使用第 \(\lfloor h/g\rfloor\) 个 KV 头。这是分组映射，不是把 \(H_q\) 写成 \(H_{kv}\) 后让输出头数跟着减少。框架若显式复制 KV 作为正确性参考，实际内存节省要另由原生分组算子实现。

对普通、未压缩且 K/V 每头宽度相等的缓存，可按维度推得：

\[ \text{KV bytes}=2BL S H_{kv}d_hs, \]

其中 \(s\) 是每元素字节数；一般宽度不同则为 \(BLSH_{kv}(d_h+d_v)s\)。这个式子只计算缓存载荷，不含权重、激活、页表、分配碎片、复制与其他工作区，也没有自动给出多卡分片后的单卡值。它帮助比较同一口径下的头共享，不是生产显存总账。

例如在教学假设 \(H_q=8,H_{kv}=2\) 下，若其他轴与精度相同，GQA 缓存载荷是 MHA 的四分之一；这不表示请求延迟也变成四分之一。投影、FFN、调度、缓存读取与硬件利用率共同影响实际延迟。将既有 MHA 权重改成 GQA 也不是只改配置，原论文的 checkpoint 转换和继续训练正说明结构变化需要适配。[17]

MLA 不是把头数改小

DeepSeek-V2 的 MLA 用低秩向量联合承载 K/V 的内容表示，并为位置部分采用解耦 RoPE。按该论文缓存设计，需要保留压缩内容向量和解耦的位置键；若维度分别为 \(d_c\) 与 \(d_r\)，其对应载荷为 \(BLS(d_c+d_r)s\)。这是该结构的限定口径，不能把 \(d_c\) 填进标准 GQA 公式后再机械乘二、乘头数。重建向量、投影吸收以及位置支路是否物化，会影响实际执行。[18]

这里没有按结构给模型质量排永久名次。论文中的比较来自具体训练和实验，不能把“缓存小”直接推出“准确率高”，也不能把模型采用 MLA 当作它已经具备事务恢复能力的依据。缓存保存的是前向计算所需状态，不是任务完成的证明。

Dense、MoE 与算子的不同取舍

稀疏专家混合把部分网络计算分给门控选择的专家，早期工作用条件计算扩大参数容量而不同比增加每个样本的计算。[19] Switch Transformer 进一步研究简单稀疏路由及其通信、稳定性与扩展问题。[20] 专家通常是参数子网络，不是多个会独立规划和执行工具的 Agent，也不必天然对应“财务”“法律”等人类部门。

因此总参数、每 token 激活参数、常驻权重和通信量要分开计。只激活少数专家，仍可能需要存放全部专家权重或安排跨设备访问；路由不均会使部分设备忙、部分设备闲。Dense 布局没有同样的专家路由成本，MoE 则提供另一种容量与计算折中。两者都不能仅凭模型名称或激活参数数字判断单机是否装得下。

FlashAttention 优化的是另一层：通过分块和减少 GPU 高带宽内存与片上存储之间的数据搬运，实现精确注意力计算。它不是 GQA 的同义词，也不是以减少注意力头获得同样收益；普通稠密注意力的二次算术项并未因此自动消失。[21] 这也解释了为什么结构设计、算子实现、服务调度要分别记录：某层的节省不能重复算进另一层账本。

有版本依据的 Qwen 侧栏

仅以 Qwen2 技术报告 v4 的 7B Dense 配置为例：残差宽度3584、28层、28个查询头、4个KV头、每头128维，采用 GQA、RoPE、RMSNorm 等设计。[22] 官方 Qwen2-7B 配置页面显示文件修订9b039ab，对应头数、层数和宽度一致；其 Embedding 表行数为152064，而报告列出的有效词表为151646，不能混同。[23]

这组配置每个 KV 头服务7个查询头。若只做形状阅读，读者可将 \(D,H_q,H_{kv},d_h\) 代入前述张量约定；若要估算缓存，还须另给 \(B,S,s\) 等工作负载。这里没有据此给出设备吞吐、真实窗口质量或最新版 Qwen 的保证。产品家族的代际更新可能同时改变注意力、词表与模板，所以模型制品应绑定具体配置和版本，再交给评估与发布流程。

1.6 从基础能力到可用行为

理解结构后，仍不能仅从参数规模预测任务表现。预训练通过数据和目标塑造表示与生成分布；同一结构换用不同语料、训练预算或目标，会得到不同能力边界。GPT-3 的上下文少样本设置在请求中给示例，无需梯度更新，所以“本次请求会做新格式”不等于模型权重已经永久学习该知识。[13] 第2章将讨论数据、Tokenizer、目标与规模的共同约束。

后训练进一步改变默认行为。InstructGPT 用示范进行监督微调，再利用输出排序与人类反馈做强化学习；其结果也仍包含错误，不能把更受偏好的回答当作事实保证。[24] DPO 从偏好优化目标的重参数化得到更直接的训练方式，在其研究条件下简化了训练链路；这不意味着所有后训练都等同于 DPO，也不意味着无需检查数据分布与行为回归。[25] 第3章负责这些目标、数据与优化闭环。

推理期计算改变的是一次请求怎样产生和检查候选。CoT 的研究表明，给出中间步骤的示例可以改善若干算术、常识与符号推理任务。[26] 但一段流畅解释仍可能建立在错误前提上。本书据此采用的工程判断是：增加计算前，先问结果能否由测试、数值条件、引用证据或业务规则验证；若不可验证，多生成一些候选也可能只是积累更有说服力的错误。第4章讨论如何分配预算与停止。

把三者放回一个代码修复教学场景：预训练使模型有机会识别程序模式；后训练让它更可能按要求返回补丁和测试说明；推理期策略可以安排多次尝试与运行测试。但“当前分支有哪些文件”“测试刚才是否通过”“用户允许修改哪个目录”，都需要从实际环境取得，不能靠训练知识猜测。能力形成与当前任务事实因此有明确分工。

表格不是一条必须全部自建的流水线。应用可以使用现有模型，也可以从确定性工作流起步；阶段划分的作用是避免把每种失败都送回训练。知识过期先查来源，格式截断先查输出契约，工具越权先查权限执行，确定需要改变模型行为时再研究训练。

1.7 从生成到行动系统

ReAct 将推理和动作交错，使模型可以通过行动取得环境信息，再调整后续路径。[27] Toolformer 研究了学习何时调用 API、传递什么参数以及怎样利用返回结果。[28] 这些工作支撑“模型能参与工具使用”的技术方向，却没有替应用实现持久状态、权限审批或业务事务。本节以下控制流程是本书的教学设计，不是对某个论文系统或 Hermes 已实现能力的承诺。

一个最小循环为观察、提出下一步、执行、验证、更新状态。与直接把输出交给工具相比，教学系统在建议与执行之间放置策略判断：哪些读取允许自动执行，哪些写入需要预览或审批，预算耗尽时怎样退出。工具返回也应先作为观察核对，再用于下一轮推理，不能因为模型说“成功”就把任务设为完成。

flowchart LR
    G["目标与约束"] --> O["观察：证据与当前状态"]
    O --> D["模型：提出候选动作"]
    D --> P["策略：权限、预算、审批"]
    P -->|允许| A["执行：工具或工作流"]
    P -->|拒绝或等待| H["停止 / 人工处理"]
    A --> V["验证：回执、规则、测试"]
    V --> S["更新：运行事实与制品"]
    S --> O

Function Calling 主要提供动作名称和参数的表达接口。即使参数完全符合 schema，也可能指向错误订单、违反用户权限或重复执行已成功的操作。结构合法、语义正确、权限允许、外部已提交，是四个不同判断。后训练可以提高提出合适参数的概率，执行系统仍需检查身份、对象范围与真实回执。

状态不是一段聊天记录

设想企业助手先查政策、再创建退款申请，随后网络超时。重新生成一段相似工具调用，不能回答上次请求究竟有没有提交。教学设计中，应先用操作标识查询外部事实：若已成功，记录已有回执；若明确未提交，再按重试规则处理；若状态未知，进入待核对流程。这里只定义问题和责任，幂等、持久化与恢复协议由第11章展开，不能宣称一次状态落库就获得恰好一次业务效果。

运行记录至少要能区分用户目标、一次 Run、其中的 Step、工具请求、外部结果与产生的 Artifact。模型上下文可以包含这些对象的摘要，但不能把摘要当作权威提交日志。模型重新措辞不应改写历史回执；日志重放也不应默认再次执行写操作。后续章节会细化 Run/Step/Event 与 Operation 的契约，本章只冻结二者分别承载执行事实与业务动作的边界。

企业知识助手的主要验证对象是引用与授权可见的证据，Coding Agent 的主要验证对象还包含仓库 diff、编译与测试结果，Hermes 案例则用于讨论个人助手的任务组织与教学扩展。三个案例共享“目标—观察—候选—控制—结果”的框架，但不共享未经核验的能力保证。尤其不能把本书建议的 Checkpoint、Outbox 或补偿流程反过来写成某个开源项目已经实现的事实。

输入扩大到图像、语音、屏幕时，还要保留页码、区域、时间等定位，否则“模型看见了”也无法转成可追溯证据。动作进入物理环境后，碰撞、速度与急停又需要独立控制闭环。第5章和第6章分别讨论这些边界。本章的迁移原则是：输入的证据形式和动作后果变了，验证契约也必须跟着改变，不能只换一个模型接口继续沿用纯文本验收。

1.8 用责任层定位一次失败

以下分层是本书教学诊断法。先冻结实际输入和版本，再按“数据是否到达—计算是否符合约定—行动是否授权—结果是否有证据”的顺序定位。把所有错误标成幻觉，会把完全不同的修复路径混在一起。

从错误退款回答走到可修复证据

设想助手回答“可以全额退款”，并准备调用退款工具。先查订单渠道、购买时间和商品状态是否完整；再查最新政策是否对该用户可见、是否被召回；接着核对例外条款是否进入最终上下文；最后观察模型是否正确引用条件，以及工具执行前的规则与授权是否通过。这里任一环节失败，都可能产生同一句错误回答。

若条款没进入上下文，优先修召回、过滤或装配；若条款清楚在场而判断错误，可构造包含否定条件的模型回归用例；若答案正确但工具重复提交，应查操作状态和幂等边界。修复后分别复测这些条件，而不是仅凭新模型在一条演示上答对就关闭事故。稳定的回归单元应绑定输入、版本、证据和断言，后续第10章再定义 Eval Case。

结构层也有自己的排查方法。若因果训练 loss 异常低，先看标签右移与未来可见性；若改 batch 排列就改变单样本结果，先看 mask 广播、归一化轴和状态隔离；若长前缀 decode 错乱，先看 \(T\) 与 \(S\)、位置偏移和缓存归属。推理质量问题与实现正确性问题可能叠加，只有逐个控制变量，才知道更换架构解决了什么。

这些诊断不要求应用团队先重写一个 Transformer。使用托管模型时，无法看到内部张量，也仍可记录最终输入、请求版本、停止原因、工具结果与评估切片；自建推理时，则可以增加前缀一致性与算子对照。可见性决定能直接验证到哪一层，不能取得的证据应标为未知，不能用对模型内部的猜想填满事故报告。

练习卡 Q262：手写缩放点积与多头注意力

状态：练习设计完成；独立实现未提供，未实测。 采用教学输入 \(B=2,T=S=4,D=8,H_q=H_{kv}=2,d_h=d_v=4\)，关闭 dropout，以 float64 慢速参考为对照。依次实现投影、拆头、缩放点积、因果与 padding mask、softmax、聚合、拼接和输出投影；在独立实验仓库实现，不把代码放进书稿临时目录作为运行依赖。

验收断言： 每个中间张量满足本章形状；有效查询的允许权重和为一，禁止位置权重为零；改变未来位置的 V 不改变较早查询输出；不同样本的 padding 长度不互相干扰；全屏蔽有效行显式报错。教学误差阈值可设为最大绝对误差小于 \(10^{-8}\)，仅适用于该双精度参考条件，不能用它要求所有低精度设备。

失败回收： softmax 轴错、mask后置、未先转置就拼头、全屏蔽行产生伪分布，都应有能稳定触发的非对称输入。只让全零输入通过或最终形状正确，不算完成计算验证；运行结果、环境和断言输出需要单独保存，不能由本卡的存在推断已运行。

练习卡 Q261：GQA 与增量缓存的一致性

状态：练习设计完成；独立实现未提供，未实测。 设 \(B=2,T=S=4,D=8,H_q=4,H_{kv}=2,d_h=d_v=2\)。先按分组索引计算，再用显式展开KV的慢速版本作为正确性参考。两者在同一参数、输入、mask和位置规则下比较；显式展开仅用于对照，不声称它实现了缓存节省。

验收断言： 输出保留4个查询头，KV缓存只按2个KV头计；拒绝查询头数不能被KV头数整除的输入；全前缀计算与逐token缓存计算在有效位置接近；前缀绝对位置偏移正确；两条请求不能复用彼此缓存。固定教学条件下沿用 \(10^{-8}\) 参考阈值；同时打印缓存元素数，确认没有因先复制KV而把节省吃回去。

迁移问题： 再加入非零前缀长度、分块decode、不同有效长度及位置旋转，观察哪些错误只有在 \(T\ne S\) 时出现。MLA不属于本练习的等价替换：它要定义不同的缓存状态与对照路径。没有完成这些实现和运行记录前，两张卡均只标设计，不能上调为手写能力或硬件实测。

1.9 本章小结

Transformer 改变了序列的信息交换与并行方式；Q/K 负责匹配，V 负责聚合，输出投影与 FFN 把计算接回残差流。归一化、位置、可见性与头共享共同决定结构如何运行，也各自引入前提。读懂它们的价值，是能从 token、轴、缓存与证据开始定位问题。

预训练形成基础能力，后训练塑造行为，推理期策略组织候选与验证；当模型参与行动，还需要外部系统承担当前事实、权限、提交与恢复。结构决定一种计算方式，训练决定它学到什么，评估与控制决定它能被允许做什么。下一章回到预训练的数据、目标与规模，沿这条因果链继续展开。

1.10 参考资料

1. Bengio et al.，A Neural Probabilistic Language Model，2003 / JMLR 3。核验日期：2026-10-16。
2. Bahdanau, Cho, Bengio，Neural Machine Translation by Jointly Learning to Align and Translate，2015 ICLR / arXiv v7。核验日期：2026-10-16。
3. Vaswani et al.，Attention Is All You Need，2017 / arXiv v7。核验日期：2026-10-16。
4. 张阿斯顿、Zachary C. Lipton、李沐、Alexander J. Smola，动手学深度学习：10.7 Transformer，中文在线版 2.0.0 / 2026-10-16。核验日期：2026-10-16。
5. Ba, Kiros, Hinton，Layer Normalization，2016 / arXiv v1。核验日期：2026-10-16。
6. Zhang, Sennrich，Root Mean Square Layer Normalization，2019 NeurIPS / arXiv v1。核验日期：2026-10-16。
7. Xiong et al.，On Layer Normalization in the Transformer Architecture，2020 ICML / arXiv v2。核验日期：2026-10-16。
8. Ioffe, Szegedy，Batch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate Shift，2015 / arXiv v3。核验日期：2026-10-16。
9. Su et al.，RoFormer: Enhanced Transformer with Rotary Position Embedding，2021 preprint / arXiv v5 2023。核验日期：2026-10-16。
10. Press, Smith, Lewis，Train Short, Test Long: Attention with Linear Biases Enables Input Length Extrapolation，2022 ICLR / arXiv v2。核验日期：2026-10-16。
11. Devlin et al.，BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding，2019 NAACL。核验日期：2026-10-16。
12. Raffel et al.，Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer，2020 JMLR 21(140)。核验日期：2026-10-16。
13. Brown et al.，Language Models are Few-Shot Learners，2020 / arXiv v4。核验日期：2026-10-16。
14. Touvron et al. / Meta AI，LLaMA: Open and Efficient Foundation Language Models，2023 / arXiv v1。核验日期：2026-10-16。
15. Radford et al. / OpenAI，Language Models are Unsupervised Multitask Learners，2019 official report。核验日期：2026-10-16。
16. Shazeer，Fast Transformer Decoding: One Write-Head is All You Need，2019 / arXiv v1。核验日期：2026-10-16。
17. Ainslie et al.，GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints，2023 EMNLP / arXiv v3。核验日期：2026-10-16。
18. DeepSeek-AI，DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model，2024 / arXiv v5。核验日期：2026-10-16。
19. Shazeer et al.，Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer，2017 / arXiv v1。核验日期：2026-10-16。
20. Fedus, Zoph, Shazeer，Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity，2022 JMLR 23(120)。核验日期：2026-10-16。
21. Dao et al.，FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness，2022 / arXiv v2。核验日期：2026-10-16。
22. Yang et al. / Qwen team，Qwen2 Technical Report，2024 / arXiv v4。核验日期：2026-10-16。
23. Qwen，Qwen2-7B config.json，file revision 9b039ab / checked 2026-10-16。核验日期：2026-10-16。
24. Ouyang et al.，Training language models to follow instructions with human feedback，2022 / arXiv v1。核验日期：2026-10-16。
25. Rafailov et al.，Direct Preference Optimization: Your Language Model is Secretly a Reward Model，2023 / arXiv v3 2024。核验日期：2026-10-16。
26. Wei et al.，Chain-of-Thought Prompting Elicits Reasoning in Large Language Models，2022 / arXiv v6 2023。核验日期：2026-10-16。
27. Yao et al.，ReAct: Synergizing Reasoning and Acting in Language Models，2023 ICLR / arXiv v3。核验日期：2026-10-16。
28. Schick et al.，Toolformer: Language Models Can Teach Themselves to Use Tools，2023 / arXiv v1。核验日期：2026-10-16。

第2章 预训练：能力的来源

第1章说明了 Transformer 为什么能成为大模型的计算底座，也说明了语言模型若要走向 Agent，必须先拥有可迁移的语言、知识和模式能力。但“模型变大”本身并不能解释这些能力从何而来：一个随机初始化的 Transformer，为什么经过数万亿 token 的训练后，会表现出语言理解、代码生成、数学表达和一定程度的推理能力？

本章的判断是：基础能力不是参数规模单独带来的属性，而是训练目标、数据分布、Tokenizer、模型规模、算力预算和评估证据共同塑造的结果。预训练让模型学习广泛而稳定的模式，却不直接提供时效事实、权限判断或可控行为；这些缺口将自然引向第3章的后训练与行为塑形。

本章面向有后端和传统机器学习经验、准备进入大模型开发的读者。重点放在能帮助工程决策的知识上：哪些问题由预训练解决，哪些问题其实应该交给后训练或推理系统；数据质量为什么会改变能力上限；Scaling Law 如何变成成本估算；以及怎样判断一个模型是真的学会了能力，还是只是在测试集上复现了训练数据。

2.1 从词概率到基础模型：预训练为什么成为能力来源

从词概率到分布式表示

语言模型最初的任务是估计一段序列的概率。给定 token 序列 \(x_1,\ldots,x_T\)，自回归语言模型把联合概率分解为：

\[ P(x_1,\ldots,x_T)=\prod_{t=1}^{T}P(x_t\mid x_{<t}). \]

早期系统使用 n-gram 和平滑技术，用有限窗口统计词共现。它们易于解释，却会遇到两个根本问题：词表一大，组合空间迅速爆炸；窗口一长，统计计数变得稀疏。Bengio 等人把词表示为可学习的稠密向量，并用神经网络估计下一个词的概率，证明了“学习表示”和“学习语言概率”可以在同一个目标中完成 [1]。Word2Vec 进一步把大规模词向量训练变成高效的局部预测问题，使分布式表示成为许多 NLP 系统的基础组件 [2]。

这一步解决的是“如何把离散符号放到可泛化的连续空间”。相似上下文中的词，会被优化到相近区域；模型因此不必把“猫”和“狗”当成完全独立的类别，而能利用它们在语料中的相似分布。局限也很清楚：静态词向量不能根据上下文改变词义，词级表示难以处理未登录词、形态变化和长篇上下文。

Seq2Seq、Attention 与 Transformer

Seq2Seq 模型把输入序列编码成隐状态，再由解码器逐步生成输出，推动了机器翻译和端到端序列任务的发展 [3]。但单一固定长度的编码向量难以承载长输入，编码器和解码器之间需要一种动态选择信息的机制。第1章介绍的软对齐缓解了固定向量瓶颈；随后 Transformer 直接以 Self-Attention 为核心，取消了循环结构，并行处理同一序列中的多个位置 [4]。

Transformer 的改变不是简单地“换了一个网络层”。循环模型的时间依赖限制了训练吞吐；自注意力允许每个位置直接与其他位置建立关系，使长距离依赖路径从多步递归缩短为一步矩阵运算。代价是注意力矩阵的时间和显存复杂度近似为 \(O(T^2D)\)，序列长度增加会迅速放大成本。因此，预训练从一开始就同时是一个算法问题和一个系统问题：模型想看更长上下文，训练和推理系统都必须承担更大的激活、通信和内存压力。

预训练成为主范式

GPT 的生成式预训练把 decoder-only Transformer 与无监督文本训练结合起来，再用少量任务数据进行迁移 [5]。BERT 证明了 masked language modeling 可以用双向上下文学习强大的文本表示 [6]；T5 则把分类、问答、翻译等任务统一改写成 text-to-text 形式，减少了不同任务之间的接口差异 [7]。这几条路线并没有“谁完全淘汰谁”，而是在回答不同问题：decoder-only 更适合连续生成和统一接口，encoder-only 擅长理解和表示，encoder-decoder 在输入输出结构差异较大的转换任务中仍然有价值。

GPT-3 进一步展示了大规模自回归模型的上下文学习能力：在不更新参数的情况下，仅通过提示和少量示例就能完成多种任务 [8]。这改变了模型开发方式。过去是“为每个任务训练一个模型”，之后逐渐变成“先训练一个基础模型，再通过 Prompt、后训练、检索和工具把它适配到任务”。不过，上下文学习并不等于模型真正掌握了任务规则；它可能依赖示例格式、表面相关性或训练语料记忆，必须通过独立评估和分布外测试确认泛化。

从历史上看，预训练解决了三个连续问题：第一，标注样本不足时如何利用海量无标注数据；第二，不同任务如何共享语言和世界知识；第三，如何用同一基础模型覆盖更多任务。它也留下了三个长期问题：数据偏差进入参数后很难定位，训练语料可能包含隐私和版权风险，模型输出的流畅性不等于事实可靠性。

2.2 预训练目标：模型究竟在学习什么

Next-token Prediction 与交叉熵

给定 token 序列 \(x_{1:T}\)，decoder-only 模型根据输入前缀 \(x_{<t}\) 预测目标 \(x_t\)，使用 causal mask 保证当前位置不能读取未来 token。单个样本的平均训练损失通常写为：

\[ \mathcal{L}(\theta)=-\frac{1}{T}\sum_{t=1}^{T}\log p_\theta(x_t\mid x_{<t}). \]

在实现上，模型输出每个位置对词表的 logits，经过 softmax 得到概率，再用交叉熵与真实 token 做比较。优化器只看到“正确 token 的概率是否提高”，并不知道我们以后想让模型会写代码、做数学题或调用工具。后续能力是一个涌现式结果：如果某种结构能够降低大量语料上的平均损失，梯度就会推动模型学习这种结构。

从机器学习角度看，这相当于用一个参数化分布逼近训练语料分布。模型会同时学习语法约束、词义关系、篇章结构、代码格式、常见事实、问答模式和文档布局。一个代码仓库里的函数调用模式能降低代码 token 的预测损失；一条数学推导中的符号依赖能降低公式 token 的损失；多轮对话中的角色标记能降低特定格式的损失。模型不需要被显式告知“这是一条规则”，只要规则在数据分布中足够稳定，就可能被压缩到参数中。

概率与损失侧栏：熵、交叉熵、KL

以下均用自然对数，单位为nat。在固定上下文下，令 \(p_i\) 是目标分布，\(q_i=p_\theta(i\mid x_{<t})\) 是模型预测，二者定义在相同离散词表上且各自求和为一。不要把目标分布 \(p\) 与模型分布 \(q\) 的方向互换。中文教材对softmax、负对数似然和熵的定义可作基础参照。[9]

\[ H(p)=-\sum_i p_i\log p_i,\qquad H(p,q)=-\sum_i p_i\log q_i, \]

\[ D_{KL}(p\Vert q)=\sum_i p_i\log\frac{p_i}{q_i} =H(p,q)-H(p). \]

最后一式由前两式直接相减得到。约定 \(0\log0=0\)；如果某项 \(p_i>0\) 而 \(q_i=0\)，交叉熵与该方向KL为无穷。KL不是对称距离，也一般不满足三角不等式。固定 \(p\) 时熵不随模型参数变化，最小化交叉熵等价于最小化这个方向的KL；若目标由同步更新的另一个模型生成，就不能无条件把它当固定常量。

对单个one-hot标签 \(y\)，交叉熵只剩 \(-\log q_y\)。这不表示现实语言在该上下文中只有一种合理续写，而是该样本只观测到一个目标，训练在许多样本上估计分布。对教学分布 \(p=(1/2,1/2)\)、\(q=(3/4,1/4)\)，熵约为0.6931，交叉熵约为0.8370，KL约为0.1438，三者满足分解。这些数值由公式计算，不是模型实验。

Token监督还要计入有效位置。设 \(m_t\) 为是否参与损失的二元mask，则平均NLL为 \(-\sum_tm_t\log q_{t,y_t}/\sum_tm_t\)。若分母为零，应拒绝样本或按明确规则跳过；不能除以包含padding的总长度后，把loss变小误认为学得更好。不同长度样本先逐句平均再平均，与按全部有效token平均也不等价，需要固定统计口径。

对logits \(z\)，softmax后交叉熵可写为 \(\log\sum_i e^{z_i}-z_y\)。令 \(c=\max_i z_i\)，用 \(c+\log\sum_i e^{z_i-c}\) 计算第一项，避免直接指数溢出。将原始logits交给已融合log-softmax的损失接口，不应再手动softmax一次。这里讨论的是分类形式如何组成语言模型目标，通用分类的完整损失选型不在本章扩写。

分类选读：为什么通常选交叉熵而非MSE

以下用二分类说明，不另扩一套分类教材。令预测概率 \(q=\sigma(z)\)、标签 \(y\in{0,1}\)。交叉熵对logit的梯度为 \(q-y\)，而取平方损失 \(L_{MSE}=\tfrac12(q-y)^2\)，链式法则给出梯度 \((q-y)q(1-q)\)。CE梯度可由前述softmax推导退化得到，平方损失的结果是本书直接求导。[9]

当模型自信地预测错误，如 \(y=1,q\approx0\)，CE梯度仍接近负一，MSE还要乘很小的 \(q(1-q)\)，纠正信号可能很弱。CE也与分类分布的负对数似然一致，因此是token分类常用目标。这里不能推断“MSE不能分类”：概率上的平方误差可作为Brier型评分，用途不同。选损失要看输出参数化、优化与校准，不能仅因为标签是数字就把类别当有序回归值。

语言、知识、推理与行为的边界

“模型学会了知识”容易造成误解。预训练权重不是一个带版本号、权限和更新时间的数据库。更准确的说法是，模型在参数中压缩了训练数据中的统计规律和部分可重复模式。它可能记住某些长字符串，也可能只学到“某类问题通常这样回答”；两者在表面输出上很难区分。

可以把预训练产生的内容分为四层：

推理也需要分层看待。预训练可以让模型见过大量“问题—解答—推导”的文本，学习到可复用的组合模式；但在新组合、长链条或高可靠任务中，单次生成可能仍不稳定。训练阶段学到的是能力先验，推理时是否成功还取决于采样、上下文、验证器和额外计算。把预训练损失直接等同于生产正确率，是从训练目标跨越到业务目标的常见错误。

Causal LM、Masked LM 与 Encoder-Decoder

Causal LM 只利用左侧上下文，训练目标与生成过程一致，部署为聊天模型时接口简单。Masked LM 随机遮挡输入中的部分 token，让模型利用左右文恢复缺失内容，能获得较强的双向理解表示 [6]。Encoder-decoder 结构把输入和输出分开建模，在翻译、摘要等条件生成任务上具有清晰的结构优势 [7]。

选择目标函数时，应先问产品需要什么：如果核心任务是连续生成、代码补全和对话，Causal LM 的训练—推理一致性更重要；如果核心任务是分类、检索表示或句子级理解，双向 encoder 可能更高效；如果输入与输出是两个不同序列，encoder-decoder 能显式建模条件信息；如果目标是一个统一基础模型，decoder-only 便于把各种任务转成同一种 token 预测接口。

中文工程实践还要考虑词表和语料比例。Qwen 技术报告展示了多语言、代码和中文数据共同训练时，词表设计、数据混合和评估集合会直接影响模型使用体验 [10]；InternLM2 技术报告也说明，中文基础模型不能只用英文模型的 benchmark 推断能力，需要建立中文、代码、知识和对话的分层评估 [11]。

2.3 数据不是原料，而是能力设计

数据管线的基本分层

预训练数据可以按加工阶段分成 raw、filtered、deduplicated、mixed 和 packed 五种状态。raw 是抓取或采购得到的原始文档；filtered 去除明显垃圾、乱码和不合适内容；deduplicated 处理重复和近重复；mixed 根据训练目标配比；packed 才是按序列长度组织成训练样本。每一层都应保留版本、规则和统计信息，否则出现能力退化时无法回答“是模型问题还是数据版本问题”。

C4 的公开文档化工作提醒我们，网页语料的过滤规则会改变数据集组成，并可能引入语言、主题和站点偏差 [12]。The Pile 通过多源语料组合和来源说明，把“我们收集了一堆网页”推进到更可追溯的数据集治理 [13]。RefinedWeb 则显示，网页清洗、质量过滤和去重可以使相对简单的数据管线得到有竞争力的基础模型结果 [14]。这些工作共同说明：数据工程不是训练前的杂务，而是模型能力的组成部分。

清洗：过滤噪声而不是消灭多样性

常见清洗规则包括语言识别、文档长度、特殊字符比例、HTML 模板、广告密度、重复行、链接比例和质量分类器。工程上不能把“越干净”当成“越好”。过度过滤可能删除低资源语言、口语、代码注释、表格、论坛问答和专业文档，结果是模型在主流测试集上变好，却在真实用户输入上变窄。

更稳妥的做法是把过滤分成硬规则和软评分：硬规则负责删除明显违规或无法学习的内容；软评分保留分布，按桶采样并记录阈值。每次改变过滤器，都要比较文档数、token 数、语言比例、领域比例、平均长度、重复率和评估指标，而不是只看最终 loss。

质量分类器本身也会带来偏差。它可能把方言、短文本或非标准格式误判为低质量；它还可能与目标模型共享训练数据，形成循环偏差。因此数据质量评估应包含人工抽样、规则解释、分层统计和模型结果四个维度。中文、英文、代码、数学和长文档最好分别抽样，不要用一个总体平均分掩盖少数分布被删除的问题。

去重：泛化、记忆和计算效率的共同杠杆

重复文档会让模型多次看到同一个训练信号，浪费 token 预算，并增加记忆和 benchmark 泄露风险。精确去重可以通过文档哈希实现；近重复去重通常使用 n-gram、MinHash、局部敏感哈希或 embedding 相似度。Lee 等人的实验显示，去重不仅减少训练数据，还能改善泛化并降低模型对重复文本的记忆 [15]。

去重的粒度需要根据文档类型选择：网页正文适合段落或文档级去重；代码需要同时考虑文件、函数和仓库级重复；书籍和法规文本可能存在合法的版本差异，简单按相似度删除会误伤；问答数据中相同问题的不同高质量答案不能全部删掉。对工程团队而言，最重要的不是宣称“去重率达到某个数字”，而是记录算法、阈值、抽样误删率和跨数据集重复率。

数据配比：把训练预算投向目标能力

如果总训练 token 固定，增加一种数据就会减少另一种数据。数据混合因此是一个预算分配问题，而不是越多越好。通用网页提供覆盖面，书籍和长文增强篇章结构，代码改善程序模式，数学和科学文本提供符号推导，多语言数据扩大覆盖，合成数据可以定向补齐稀缺能力。

一个实用的数据配比表应至少记录：来源、语言、领域、质量分桶、token 数、采样权重、重复率、版权状态和对应评估集。T5 的系统实验说明，预训练数据规模、任务混合和训练步数之间存在耦合，不能只凭直觉选择数据比例 [7]。LLaMA 的报告也把公开数据组成、训练 token 和模型规模放在一起讨论，说明开放模型的效果并非只由参数量决定 [16]。

数据混合通常有三种策略：固定比例、温度采样和阶段性配比。固定比例容易复现；温度采样可以避免大语种或大数据源完全支配训练；阶段性配比则先用广覆盖数据学习基础，再提高代码、数学、长上下文或领域数据的权重。阶段性训练的风险是分布切换造成遗忘，因此需要在通用评估和目标评估上同时监控。

合成数据与数据闭环

合成数据可以生成题目、解答、代码、偏好对和长上下文样本，特别适合补齐人工数据稀缺的能力。但生成器的错误会被蒸馏到训练集，模板化样本会降低多样性，模型还可能反复学习自身的错误。Shumailov 等人关于递归训练的研究提示，持续使用模型生成内容替代真实分布，可能导致分布尾部消失、错误累积和模式退化 [17]。

因此合成数据不能只看数量。至少应有四个门槛：生成器与目标模型尽量隔离；使用规则、程序执行器或人工抽样验证答案；保留真实数据作为锚点；用独立测试集检查多样性和分布外能力。对代码数据，要运行单元测试、静态检查和依赖审计；对数学数据，要执行符号或数值验证；对事实数据，要与独立来源交叉核对。合成数据是能力定向工具，不是廉价 token 生产器。

2.4 Tokenizer、样本构造与有效训练信号

Tokenization 的模型影响

模型看到的不是字符、单词或句子，而是 tokenizer 产生的 token。词表大小影响 embedding 和输出层参数，分词粒度影响序列长度、跨语言效率和稀有词处理。英文常见词可能被编码成一个或几个 token；中文字符、英文缩写、数字、代码符号和路径的切分模式可能完全不同。

这会影响三类成本：同一段内容需要多少 token，决定训练和推理计算；一个概念被切成多少片，影响模型学习稳定性；特殊格式被如何分割，影响代码、JSON、URL 和工具调用格式的可靠性。比较模型成本时不能只比较“每百万 token 价格”，还要看目标语言和业务文本的 token 化膨胀率。

词表不是越大越好。更大的词表可能减少序列长度，却会增加 embedding、softmax 和通信成本；更小的词表参数压力较低，但长序列会增加注意力和位置编码负担。最终选择应基于目标语料的 token/字符比、词表覆盖率、训练速度、显存占用和下游格式稳定性。中文基础模型尤其要在中文字符、英文单词、代码标识符、数字和混合文本上做分层统计，而不是只报告一个平均压缩率。

中文、代码与模板：先固定测量对象

BPE用高频子词组合缓解稀有词问题，SentencePiece提供从原始句子训练子词模型的方法；它们是算法与工具路线，具体词表仍由训练数据和配置确定。[18][19] 本书教学输入可以固定为“订单A-123可以退款吗？”与代码 if (order_id == "A-123") return refund(100);，另加路径、连续空格、换行和emoji。它们用于暴露中文、字母、数字、标点和缩进的切分差别，不预先声称会产生多少token。

测量时记录Tokenizer制品修订、词表与merge文件哈希、normalization、特殊token策略及chat template；分别输出token ID、可见片段、长度和decode后文本。先验证round-trip是否符合该Tokenizer的规范，再比较各语言和代码样本的长度分布。不能把一种Tokenizer的整数ID送给另一模型，也不能假设相同字符串在不同词表下成本相同。上述输入只是待执行测量规约，本章没有编造实测ID或跨模型压缩率。

把教学对话装成“user问退款、assistant给答复”时，角色标记、换行与EOS也是输入契约。模板改变后，正文文字可能不变，模型读到的协议却已变化。预训练可对全部合法位置预测，SFT则可能只监督assistant位置；阶段差异由目标与mask决定，不能仅按数据文件后缀判断。模板与Tokenizer需要和模型权重一起版本化，后训练样本对齐由第3章展开。

文档边界、Packing 与样本泄露

本书以下流程建议用于定义有效训练信号。训练样本通常组织成token block。把多个短文档拼接到一个 block 可以减少 padding，提高 token 利用率，但必须正确处理文档边界，否则模型会学到本来不存在的跨文档关系。对于对话、代码文件、JSON 和书籍章节，边界 token 的设计会影响模型是否知道“一个样本在这里结束”。

Packing 还可能带来评估污染：如果一个训练 block 把不同文档拼在一起，近邻内容可能通过上下文泄露。更稳妥的管线会在 packing 前完成文档级切分，在评估时按文档或主题隔离训练和验证集合，并检查重复 n-gram。验证集不能只是随机抽取训练网页的另一段，因为随机切分会让近重复内容同时出现在训练和评估中。

边界符告诉模型内容在何处结束，却不自动阻止跨文档注意力。连续语料预训练可以显式选择允许跨文档读的策略；独立对话或任务样本若要求隔离，则需block-diagonal等可见性约束，并正确重置或延续位置ID。Attention mask决定能读哪里，loss mask决定哪些目标产生梯度，两者职责不同。先按原始文档、仓库或去重簇划分训练/验证，再分别packing，避免一个源文档的相邻切块落入不同集合。所有隔离策略都应进入数据manifest。

长上下文数据

把最大上下文从 4K 直接扩到 128K，不等于模型自动获得了长文档能力。模型需要在训练中看到足够多的长序列、跨段引用、远距离检索和结构化文档。长序列还会显著增加 attention 计算和激活内存，训练预算不能只按 token 数粗略估计。

长上下文数据至少分成四类：自然长文档、人工拼接文档、远距离依赖任务和长上下文问答。人工拼接可以测试位置和检索能力，但不能替代真实长文档；长文档问答可以测试使用能力，但如果答案总在开头或结尾，不能说明模型能稳定处理中间信息。评估时要改变答案位置、干扰内容、文档数量和引用距离，避免得到虚假的“长上下文支持”。

2.5 Scaling Law：怎样分配模型、数据与算力

经验规律与工程意义

Scaling Law 的核心观察是，在一定规模范围内，验证损失会随模型参数量、训练 token 数和计算量以相对平滑的幂律下降 [20]。它不是物理定律，也不能保证任何新架构都服从同一曲线，但它提供了一个重要工程工具：在真正投入大规模训练之前，可以用小模型和短训练估算不同预算下的趋势。

为避免与第1章的隐藏宽度 \(D\) 冲突，本节用 \(P\) 表示参数量，\(N_{tok}\) 表示训练token数，\(C_{train}\) 表示训练计算。一个用于说明参数/数据折中的形式是：

\[ \widehat L(P,N_{tok})=L_\infty+aP^{-\alpha}+bN_{tok}^{-\beta}. \]

这类拟合描述给定架构族与数据配方中的经验趋势，不把计算量再当独立变量任意叠加。对普通Dense训练，可在特定计数口径下用 \(C_{train}\approx6PN_{tok}\) 作为粗估，长序列Attention、不同算子和稀疏激活会使实际账本偏离。参数与token在固定计算下相互约束，计算最优也不等于推理成本最优。[20][21]

实际拟合需要固定Tokenizer、数据分布、优化器和架构族，并报告测量范围与误差。一个实验若同时改变数据质量、参数和训练步数，就不能只归因于参数scaling。不要把经验系数和最优比例照搬到中文业务语料，更不能把验证损失下降直接换算成业务正确率。

Chinchilla 与 compute-optimal

早期行业实践倾向于优先扩大参数量，但 Chinchilla 研究指出，在固定训练计算下，很多大模型实际上训练 token 不足；适当减少参数并增加训练数据，可以得到更低的验证损失 [21]。这不是“模型越小越好”，而是说明容量和训练充分度必须成比例设计。

对项目规划可以采用如下顺序：先确定目标推理成本和延迟，得到可接受的激活参数量；再依据目标能力和可获得高质量数据估计训练 token；最后反推训练计算、集群时长和 checkpoint 存储。若数据质量不足，继续堆 token 可能只是重复噪声；若模型容量不足，增加同分布数据的收益会变小；若训练没有收敛，盲目做后训练会把基础缺陷包装成行为问题。

需要区分三种“规模”：总参数、激活参数和训练 token。MoE 模型可以拥有更大的总容量而只激活部分参数，但路由和通信有额外代价；密集模型每个 token 都使用全部参数，算力结构简单但激活成本高。后续 Infra 章节会讨论这些选择如何影响并行和部署，本章只保留一个判断原则：训练规模必须和目标能力、数据质量、推理预算一起设计。

Loss 与能力不是一条直线

验证 loss 是重要指标，但它不是所有能力的充分统计量。它对高频 token 和常见格式非常敏感；一个模型可以通过更好地预测模板文本降低 loss，却未必提高少数复杂任务的准确率。反过来，针对数学、代码或工具格式的定向数据可能提高业务能力，却让总体 loss 变化很小。

因此训练曲线应与分层能力曲线一起看：通用 loss、按语言 loss、按领域 loss、长上下文 loss、代码执行成功率、数学答案准确率、结构化输出通过率和安全回归。每一项都要固定评估版本，记录置信区间和样本数量。不能从一次 benchmark 的涨跌推断模型整体进步，尤其当测试集较小、污染未知或评测提示未公开时。

规模预算如何落到优化过程

Batch、学习率与训练预算

在 token 级训练中，global batch size 决定一次更新看到多少 token。增大 batch 可以提高硬件利用率并降低梯度噪声，但可能需要调整学习率、warmup 和正则化；batch 太大也可能减少参数更新次数，使模型在固定 token 预算下的优化轨迹改变。中文教材对交叉熵、梯度下降和深度网络训练的系统解释，有助于把这些经验规则还原成优化问题 [9]。

学习率通常经历 warmup、稳定训练和衰减阶段。warmup 用于避免随机初始化或大 batch 下的早期更新过大；衰减让模型在后期更稳定地收敛。实际训练还需要监控梯度范数、logit 范围、loss spike、NaN、激活溢出和不同数据桶的 loss。混合精度能节约显存和提高吞吐，但数值稳定性、loss scaling 和归一化实现都可能改变结果。

AdamW、正则化与数据顺序

Adam 类优化器用一阶和二阶动量调整每个参数的更新尺度，适合 Transformer 这种参数尺度差异明显的网络。AdamW 将权重衰减与自适应梯度更新解耦；在Adam中把L2正则项直接加进梯度，并不等同于这种权重衰减。[22]工程上不要把优化器当成可随意更换的实现细节：优化器、学习率、权重衰减、梯度裁剪、batch 和数据顺序共同决定训练轨迹，改变其中任何一个都可能需要重新做小规模校准。

数据顺序也会影响能力形成。若模型过早大量看到某一领域，可能在该领域快速下降但损害通用分布；若高质量数据只在训练尾部出现，可能改善最终 checkpoint 却减少可用训练步数。数据混合应与学习率和阶段计划联合设计，并在中间 checkpoint 上做评估，确认收益来自稳定学习而不是最后一次偶然波动。

训练中间评估与故障归因

成熟训练项目不会等到最终模型才评估。每隔固定 token 或 step 保存 checkpoint，并对固定小集合执行快速评估：通用语言、中文、多语言、代码、数学、长上下文、格式遵循和安全。遇到 loss spike 时，先区分数据异常、数值不稳定、节点故障、恢复错误和学习率问题；遇到某领域退化时，再检查数据配比、过滤和遗忘，而不是立即扩大模型。

故障归因需要可重放。至少要保存 tokenizer 版本、数据 manifest、采样权重、随机种子、优化器状态、学习率状态、代码版本、配置和评估版本。Checkpoint 只保存模型权重而没有 optimizer state，通常无法严格恢复训练；只保存最后一个 checkpoint，则无法比较退化发生的时间点。训练可观测性属于 Infra 的实现内容，但“哪些状态必须留下”是算法和工程共同决定的。

2.6 数据污染、记忆与隐私

Benchmark contamination

如果测试集内容或近似内容出现在训练语料里，模型在测试集上的高分就不能代表泛化。污染既可能是完全重复，也可能是题目、选项、解答和网页讨论的近似重复。HellaSwag 等基准的设计展示了如何用对抗性候选和常识完成任务，但任何公开 benchmark 长期存在，都必须面对进入训练语料的可能性 [23]。

污染检查应在训练前和评估前都做。训练前对数据与 benchmark 做精确和近似匹配；评估前记录 benchmark 版本、发布时间和是否可能被抓取；发布结果时披露污染检测方法。只给出一个分数而不说明训练数据边界，会让读者无法判断结果是推理、记忆还是泄露。

Memorization 与隐私风险

模型可能记忆训练数据中的罕见序列，尤其当内容重复、样本稀有、模型容量较大或训练步数较多时。Carlini 等人展示了从语言模型中抽取训练数据的风险 [24]，后续研究进一步量化了不同模型、数据重复度和序列稀有度下的记忆行为 [25]。这说明“公开网页”不等于“可以无风险地训练和再生成”。

工程上要把隐私治理前移：在数据进入训练前识别手机号、邮箱、密钥、地址和内部标识；对必须保留的敏感数据做权限和用途审计；对模型做 canary、成员推断、提示抽取和长字符串复现测试；对发布模型设置使用政策和响应过滤。去重、减少罕见敏感样本重复和抽取攻击回归可以帮助发现风险，但不能把它们当作隐私保证。

版权与数据治理

版权问题不只是法务问题，也影响工程可追溯性。每个数据源最好记录获取方式、许可信息、抓取时间、保留理由、过滤版本和退出机制。若模型出现某类受保护内容复现，团队需要知道哪些来源可能贡献了该模式，才能进行风险评估或数据修订。数据卡、模型卡和评估报告的价值在于让训练决策可解释，而不是为报告增加形式化章节。

2.7 评估：从 loss 到能力证据

三层评估框架

可以把预训练评估分成三层。第一层是训练健康度：loss、困惑度、梯度、吞吐和数值稳定性，回答“训练是否正常”。第二层是能力覆盖：语言、知识、代码、数学、多语言、长上下文和结构化输出，回答“模型学到了什么”。第三层是风险与泛化：污染、记忆、偏见、安全、分布外和真实任务，回答“这些能力是否可信、是否可用”。

HELM 提倡从准确性、校准、鲁棒性、公平性、偏见、毒性和效率等多个维度评估模型 [26]。这个思路对基础模型尤其重要：一个总体平均分会掩盖中文能力、长上下文、拒答行为和推理成本的变化。评估集最好分为开发集、冻结测试集和真实任务集；开发集用于迭代，冻结集用于发布决策，真实任务集连接模型指标和产品成功标准。

评估设计的常见陷阱

第一，测试集过小导致偶然波动被误认为进步；第二，提示模板改变导致模型分数变化，却被解释成训练收益；第三，使用模型自己生成的评判结果，形成自评偏差；第四，只看准确率，不看格式、延迟、成本和拒答；第五，训练数据和评估数据分布高度重叠。

解决方式是固定提示、记录版本、报告样本数和置信区间，并用程序化判定代替主观判断。代码任务尽量执行测试，数学任务尽量验证最终答案，JSON 任务使用 schema 校验，检索任务拆分召回和生成，安全任务同时看攻击成功率与过度拒答率。评估不是发布前的一次考试，而是训练闭环中的反馈信号。

基础模型、后训练与应用评估的分工

Base model 评估关注语言建模和潜在能力；SFT、偏好优化和推理强化之后，评估才关注指令遵循、风格、安全和推理策略；应用系统还要评估检索、工具、权限、状态、回滚和人工接管。把应用失败全部归因于预训练，会导致错误的解决方案：事实过期通常需要 RAG，格式不稳可能需要 schema 和重试，工具误用需要权限和验证，推理不足才可能需要后训练或更强模型。

对后端工程师来说，最有价值的模型评估表不是“模型总分排名”，而是能力—成本—风险矩阵。例如：代码生成通过率、每次调用 token、执行延迟、失败类型、敏感操作误调用率、需要人工修复的比例。只有把模型输出放入真实工作流，才能判断预训练能力是否转化成工程价值。

从公开配方看训练重点的变化

不同基础模型报告的共同点，不是使用了完全相同的网络配置，而是都把数据、训练阶段和评估作为一个整体说明。LLaMA 代表了用相对克制的架构和公开数据进行高效训练的路线 [16]；Llama 3 则进一步强调更大规模、高质量数据、合成数据、长上下文和严格后训练之间的联动 [27]。这类报告对工程师最有价值的地方，不是记住某个模型的层数，而是看到能力提升通常来自多项配方同时变化，不能把结果简单归因于参数量。

复现一个训练结果时，应先列出可比条件：同一 tokenizer、相近数据分布、相同 token 预算、相同上下文长度、相近优化器和一致的评估脚本。如果只能复现网络结构，却拿不到数据配比和过滤规则，那么复现的只是一个外形相似的模型，不能复现能力。报告中的“使用了某类数据”也不够，最好知道来源数量、采样权重、去重策略和阶段变化。

能力迁移与遗忘

继续训练某一领域时，目标能力可能增强，通用能力也可能退化。这个现象可以从分布变化理解：梯度更新更频繁地服务新分布，旧分布中的参数结构被改写。传统机器学习中，训练误差、泛化误差、偏差和方差的区分能帮助我们理解这种权衡 [28]。对语言模型而言，还要增加语言、领域、长度和格式四个维度的分层检查。

一个可操作的实验是保留三组数据：通用锚点、目标领域、分布外挑战。每个 checkpoint 都在三组数据上测试，不只看目标领域是否上升。如果目标领域上升、通用锚点下降，说明需要降低领域采样温度、混入回放数据、调整学习率或缩短继续训练阶段；如果三组都不变，则可能是数据量不足、任务目标不匹配或模型容量已成为瓶颈。

训练结果的可解释记录

训练报告应能回答五个问题：模型看过多少有效 token；每类数据占比是多少；在哪个阶段出现能力变化；哪些评估结果来自冻结测试集；哪些风险仍然未知。建议把每次实验记录为一条不可变 manifest，关联数据版本、代码提交、配置、硬件、随机种子、checkpoint 和评估结果。这样做的收益和后端系统中的事件审计类似：失败之后可以重放，成功之后也知道为什么成功。

2.8 从预训练到后训练：边界与工程决策

Pretraining、Mid-training、Post-training

预训练使用大规模、相对广泛的数据，让模型形成语言和领域先验；mid-training 或 continued pretraining 仍然常用 next-token prediction，但把数据分布定向到代码、数学、中文、长上下文或行业语料；post-training 则使用指令、偏好、轨迹和环境反馈，让模型学习“如何按要求行动”。三者的边界不是由文件名决定，而是由目标、数据和损失共同决定。

当问题是“模型完全不知道某领域术语和文档模式”，继续预训练可能有效；当问题是“知道内容但不会按格式回答”，SFT 或结构化解码更合适；当问题是“多个答案都合理但偏好不同”，偏好优化更合适；当问题是“实时事实变化”，检索和工具比重新训练更合适；当问题是“复杂任务一次生成不稳定”，推理时搜索、验证器或推理强化可能更合适。

这些是本书的初筛建议，不是由某篇模型报告证明的通用处方。以教学8B企业问答方案为例，先按去重簇冻结授权文档的训练/验证/测试划分，再在相同有效token预算下比较通用与领域配比。记录held-out NLL、领域成功率、通用回归、污染与成本；测试集不能拿去调配比。领域词汇改善但问答格式不稳时，再引入示范，而不是把更多原始文档当作指令数据。这里没有实际训练结果。

选择训练还是系统方案

可以用四个问题做初筛：

1. 缺的是知识、能力、行为还是外部状态？
2. 目标是否需要实时更新、权限控制和可审计性？
3. 失败是否能被检索、工具、验证器或工作流拦截？
4. 训练成本是否低于长期推理和人工修复成本？

如果答案涉及动态事实、数据库状态或外部动作，优先在系统层解决；如果是稳定的领域语言、格式或推理模式，再考虑训练。训练改变的是模型的通用分布，系统控制改变的是一次调用的上下文和权限。把两者混为一谈，会得到一个既昂贵又难以回滚的模型。

从输入到证据的评审顺序

先查来源与划分，再查目标和有效监督位置，接着查参数/token/计算预算，最后比较分层评估及成本。单位时间吞吐、有效token比例与单位计算的能力收益是不同指标。算法与Infra应共享数据manifest、更新步定义和评估版本，避免把硬件更忙直接写成学习更有效。恢复训练所需状态和平台实现由第8章展开，本章保留数据与目标的输入契约。

2.9 本章小结：能力形成不等于行为可用

预训练的作用，是让模型在大量数据中压缩语言、知识、代码和任务模式；数据、目标、Tokenizer、规模和算力共同决定这种压缩覆盖什么、遗漏什么，以及训练成本是否值得。可靠的预训练并不等于只追求更低 loss 或更多 token，而是建立一条来源可追踪、配比可解释、过程可恢复、评估可比较的能力生产链路。

但参数中形成的能力仍是行为的原材料。预训练模型会延续训练分布中的文本，却不会天然理解当前用户的目标、输出格式、安全边界和协作方式；更不会自动区分“回答得像”与“应该这样回答”。第3章因此从这一缺口出发，回答如何用示范、偏好和可验证奖励，把原始能力塑造成可用行为。

2.10 参考资料

1. Bengio, Y., Ducharme, R., Vincent, P., & Jauvin, C，A Neural Probabilistic Language Model，2003。核验日期：2026-10-16。
2. Mikolov, T., Chen, K., Corrado, G., & Dean, J，Efficient Estimation of Word Representations in Vector Space，2013。核验日期：2026-10-16。
3. Sutskever, I., Vinyals, O., & Le, Q. V，Sequence to Sequence Learning with Neural Networks，2014。核验日期：2026-10-16。
4. Vaswani, A., et al，Attention Is All You Need，2017。核验日期：2026-10-16。
5. Radford, A., et al，Improving Language Understanding by Generative Pre-Training，2018。核验日期：2026-10-16。
6. Devlin, J., Chang, M.-W., Lee, K., & Toutanova, K，BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding，2019。核验日期：2026-10-16。
7. Raffel, C., et al，Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer，2020。核验日期：2026-10-16。
8. Brown, T. B., et al，Language Models are Few-Shot Learners，2005。核验日期：2026-10-16。
9. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V，动手学深度学习：softmax回归，中文在线版2.0.0。核验日期：2026-10-16。
10. Bai, J., et al，Qwen Technical Report，2023 / original Qwen。核验日期：2026-10-16。
11. Cai et al. / InternLM，InternLM2 Technical Report，2024。核验日期：2026-10-16。
12. Dodge, J., et al，Documenting Large Webtext Corpora: A Case Study on the Colossal Clean Crawled Corpus，2021。核验日期：2026-10-16。
13. Gao, L., et al，The Pile: An 800GB Dataset of Diverse Text for Language Modeling，2020。核验日期：2026-10-16。
14. Penedo, G., et al，The RefinedWeb Dataset for Falcon LLM: Outperforming Curated Corpora with Web Data Only，2023。核验日期：2026-10-16。
15. Lee, K., Ippolito, D., Nystrom, A., et al，Deduplicating Training Data Makes Language Models Better，2022。核验日期：2026-10-16。
16. Touvron, H., et al，LLaMA: Open and Efficient Foundation Language Models，2023。核验日期：2026-10-16。
17. Shumailov, I., et al，AI Models Collapse When Trained on Recursively Generated Data，2024。核验日期：2026-10-16。
18. Sennrich, Haddow, Birch，Neural Machine Translation of Rare Words with Subword Units，2016 ACL。核验日期：2026-10-16。
19. Kudo, Richardson，SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing，2018 EMNLP。核验日期：2026-10-16。
20. Kaplan, J., et al，Scaling Laws for Neural Language Models，2001。核验日期：2026-10-16。
21. Hoffmann, J., et al，Training Compute-Optimal Large Language Models，2022。核验日期：2026-10-16。
22. Loshchilov, Hutter，Decoupled Weight Decay Regularization，2019 / arXiv v3。核验日期：2026-10-16。
23. Zellers, R., et al，HellaSwag: Can a Machine Really Finish Your Sentence?，2019。核验日期：2026-10-16。
24. Carlini, N., et al，Extracting Training Data from Large Language Models，2012。核验日期：2026-10-16。
25. Carlini, N., et al，Quantifying Memorization Across Neural Language Models，2023。核验日期：2026-10-16。
26. Liang, P., et al，Holistic Evaluation of Language Models，2023。核验日期：2026-10-16。
27. Grattafiori et al. / Llama Team，The Llama 3 Herd of Models，2024 / arXiv v3。核验日期：2026-10-16。
28. 周志华：《机器学习》，清华大学出版社，2016。https://cs.nju.edu.cn/zhouzh/zhouzh.files/publication/MLbook2016.htm 访问日期：2026-09-22，周志华：《机器学习》，清华大学出版社，2016。，2016。核验日期：2026-10-16。

第3章 后训练：行为的塑形

第2章说明了数据、目标函数、Tokenizer、规模和算力如何形成基础能力，但预训练模型学到的首先仍是“像训练语料一样继续写”。产品需要的却是理解当前指令、遵守格式和边界、在不确定时说明限制，并在协作中稳定完成任务。能力形成与行为可用之间的差距，就是后训练要处理的问题。

本章的判断是：SFT、偏好优化和可验证奖励分别解决“应该怎样做”“多个可行答案哪个更好”以及“任务结果是否可判定”三类问题。它们能塑造模型的默认行为，却不能替代实时事实、工具权限、事务与审计；这些系统边界会在后续 Agent 工程中继续承担责任。

3.1 从续写能力到行为塑形

预训练模型留下的行为缺口

GPT 类模型通过 next-token prediction 学会了语言和大量文本模式，但训练目标没有直接告诉它什么是“有帮助的回答”。用户输入“帮我解释这个报错”，基础模型可能续写一段论坛帖子、模拟多个角色，或者直接生成一个没有上下文依据的修复方案。它在语言概率上可以很自然，在任务目标上却可能完全错误。

早期迁移学习主要在下游任务上训练分类器或序列到序列模型，解决的是任务准确率；大模型产品还需要处理意图理解、回答风格、拒答边界、格式遵循和多轮协作。FLAN 的工作表明，把许多任务改写成自然语言指令并进行混合微调，可以提升模型的零样本泛化 [1]；InstructGPT 则把示范学习、偏好建模和强化学习组合成完整的助手训练流程 [2]。

这条路线经历了几个关键转折：先用 instruction tuning 解决“听不懂指令”，再用 preference learning 解决“多个可行答案如何排序”，随后用 Constitutional AI 和 RLAIF 扩大安全反馈，最后把可验证奖励用于数学、代码和复杂推理。每一步都解决了一个瓶颈，同时引入新的优化对象和新的评估风险。

问题—方法—效果—新限制

因此，“对齐”不是单一算法，而是一组逐层改变行为的训练和评估方法。后续小节会分别说明它们依赖什么数据、优化什么目标、何时适用，以及哪些问题不能交给权重解决。

SFT本身就是后训练的一部分，不应把“做完SFT再开始后训练”写成阶段定义。目标需要区分任务能力、指令遵循、偏好质量和安全约束；知道怎样生成SQL，不等于会按JSON输出，更不等于拥有执行删除的权限。后训练能够改变候选行为，授权必须由外部系统执行。

3.2 数据、监督位置与训练契约

模板是输入协议，mask是监督协议

采用第1章的 \(B,T,D\) 与第2章的概率定义。聊天模型实际看到的是角色、内容、分隔符与特殊token形成的序列。先固定底座、Tokenizer和chat template修订，再格式化样本；不要把一份对话JSON直接当成所有模型都能理解的通用协议。Transformers v4.45.2文档说明，模板已经负责特殊token时，后续重复添加可能破坏格式；训练也不能无条件插入只用于生成的assistant起始提示。[3]

教学上，样本分两层保存：逻辑消息层记录system/user/assistant/tool角色、工具调用ID与结果；token层记录input_ids、attention可见性和labels。训练可选择监督所有assistant轮，也可只监督最后一轮，二者都需明示。用户问题、系统文本和工具结果通常作为条件，不作为本章assistant-only目标的直接标签。这是本书选择的训练契约，不是所有框架的默认行为。

假设一条简化序列由 BOS U Q A R EOS PAD 七个token组成：U/A是角色，Q是用户内容，R是助手内容，符号只是教学占位，不是某Tokenizer的实际ID。若只监督R与EOS，则位于A的logits预测R，位于R的logits预测EOS；其他预测位置的损失权重为零。工具名和参数若属于assistant动作，应被监督；工具实际返回内容则作为后续条件，不能训练模型伪造工具成功。

这两种mask不可互换：一个不计入loss的用户token，仍可以被助手读取；一个padding位置不仅不监督，还应按模型实现处理可见性。EOS是应学习何时结束的有效目标，PAD是补齐而非答案。若两者共用ID，仅按ID屏蔽会误删真正EOS监督，应结合有效长度和角色边界构造labels。

工具轨迹与数据划分

以下退款轨迹为教学假设。成功样本先由assistant调用 check_refund(order_id)，tool返回资格与证据版本，再由assistant解释并生成待审批提案；资格检查与实际提交分开。超时样本则记录提交状态未知，让assistant查询操作状态或升级人工，而不是训练它说“超时所以一定失败、立即重试退款”。训练标签要体现系统允许的下一步，不能仅凭语言流畅纳入。

同一逻辑工单的不同轮次、改写版本和生成负例先归入同一组，再划分训练、验证与测试；之后各自packing。独立任务需要隔离可见性，不能只插EOS就假定切断Attention。训练集可用于拟合，验证集调参数，冻结测试集不反复挑模型；工具schema、错误语义和数据来源也要随样本版本保留。否则“离线学会调用”可能只是学习已过期接口。

3.3 SFT 的目标与失效模式

SFT 的数据结构与损失

监督微调通常使用 \((x,y)\) 样本，其中 \(x\) 是系统、用户和上下文，\(y\) 是目标助手回答。对多轮对话，训练一般只对 assistant token 计算损失，避免模型把用户问题也当作需要模仿的输出。目标为：

\[ \mathcal{L}_{SFT}(\theta)=-\sum_{t\in\mathcal{A}}\log \pi_\theta(y_t\mid x,y_{<t}), \]

其中 \(\mathcal{A}\) 表示被监督的 assistant token 位置。mask 设计很重要：如果系统消息、工具结果、用户内容和助手答案边界处理错误，模型会学到错误的角色关系，表现为复读用户输入、泄露隐藏提示或把工具返回内容当成自己的指令。

SFT 数据不必是“知识百科”。它主要塑造输入到输出的映射，包括任务分解、回答结构、拒答模板、工具调用格式、引用方式和不确定性表达。Self-Instruct 通过模型生成和筛选指令数据，展示了如何在人工种子有限时扩展任务覆盖 [4]；LIMA 则指出，少量但一致、高质量的示范也能带来显著的对齐效果 [5]。这两项工作共同提醒我们：数量和质量不是简单替代关系，数据覆盖与示范一致性必须一起看。

数据设计：能力覆盖比表面多样更重要

一个成熟的 SFT 集合应该按任务分层，而不是把所有对话混成一个文件。常见分层包括：问答和解释、摘要与改写、结构化抽取、代码生成与修复、数学解题、多轮澄清、工具调用、拒答和安全边界。每一层都要记录输入分布、目标格式、难度、语言、工具状态和验收规则。

示范答案要尽量符合真实产品标准。若线上要求简短，训练集不能全部是教程式长答案；若线上要求引用证据，答案中就应明确区分已知事实、推断和待核验内容；若线上使用 JSON，示范应覆盖字段缺失、枚举错误、转义和失败分支；若线上允许调用工具，必须包含工具成功、超时、权限拒绝和部分结果等轨迹。

数据审核可以采用四道门：语义正确性、任务完成度、格式合法性和安全合规性。任何一道不通过，都不应仅仅因为“语言很流畅”而进入训练。对代码样本运行测试，对 SQL 样本使用只读沙箱，对数学样本执行答案验证，对事实问答保留来源字段。后训练数据的验收方式应尽可能接近上线后的验收方式。

SFT 的局限与退化模式

SFT 是模仿学习，不直接知道哪个答案在真实环境中产生了更好的结果。它会把示范中的错误、偏见、冗长和过度自信稳定地复制出来。如果所有答案都使用相同模板，模型可能在任何问题上输出模板；如果数据过度集中于某领域，通用能力可能退化；如果负面案例很少，模型不会知道何时应澄清或拒绝。

常见诊断包括：训练 loss 持续下降但真实任务不涨，说明可能过拟合表达风格；训练后格式更稳定但事实准确率下降，说明示范把表达优先级放得过高；安全拒答增加但正常请求成功率下降，说明边界样本比例或标签策略不合理。解决方案可能是回放通用数据、重新配比、增加难例、改用偏好数据，或者干脆在推理层加入 schema 和验证器，而不是继续增加 SFT 步数。

先用小样本验证管线，再扩大数据

交叉熵定义沿用第2章；中文推导可回看《动手学深度学习》的对应章节。[6] 对assistant-only样本，只在选定位置累加下一token负对数概率，并按有效目标token数归一化。先打印每个token及其label，确认答案和EOS被监督、prompt和padding未被直接模仿；再在少量人工可核对样本上检查loss和预测。小集合能被拟合只证明管线可能正常，不证明泛化。

过拟合、遗忘与泄漏需要不同证据：训练集改善而留出集下降，先查泛化；新领域上升但通用回归下降，先查配比和学习率；留出分数异常高且命中相同工单或答案模板，先查划分。不能将三者都写成“继续训练不足”。同一底座与预算下比较数据/目标变化，才有机会确定收益来自什么。

3.4 RLHF 与 PPO

偏好数据与 Reward Model

当一个问题存在多个都能接受的答案时，很难写出唯一标准答案。例如代码解释可以简洁或详细，开放问题可以有不同论证方式，安全回答需要同时考虑帮助性和风险。RLHF 将问题转成排序：给定 prompt，让标注者比较候选回答，记录 chosen 与 rejected。

偏好学习的经典工作展示了如何从人类比较中学习奖励函数 [7]。对语言模型而言，Reward Model 接收 prompt 和 response，输出一个标量 \(r_\phi(x,y)\)。它的训练可写成 Bradley-Terry 风格的损失：

\[ \mathcal{L}_{RM}=-\log\sigma(r_\phi(x,y^+)-r_\phi(x,y^-)). \]

这个分数是标注偏好的代理，不是真实质量本身。标注者之间可能不一致，短回答与长回答的偏好可能混杂，安全和帮助性可能冲突，同一领域的专家标准也可能不同。安全评估实践还表明，偏好标准必须把“回答有用”和“回答安全”拆成可讨论的维度，而不能把所有差异压成一个没有解释的总分 [8]。数据中必须记录标注指南、样本来源、分歧率、比较难度和拒标比例，不能只保存最终的 chosen/rejected 字符串。

PPO的四种模型角色

RLHF常从SFT策略开始。Reward Model用比较信号拟合偏好，不是当前策略自己说成功就给分。PPO在rollout策略生成的数据上，用概率比和裁剪代理目标组织多轮更新；原论文并不保证clip后每一个实际参数更新都满足严格KL上界。[9]

状态 \(s_t\) 可表示提示加已生成前缀，动作 \(a_t\) 是下一个token。旧策略概率 \(\pi_{old}(a_t\mid s_t)\) 来自生成该rollout的策略快照；reference \(\pi_{ref}\) 常是冻结SFT模型，二者用途不同。模型可共享某些物理模块，但逻辑角色与梯度路径仍需区分。把它们都称为“原模型”，会使ratio、KL和缓存数据失去解释。

\[ \rho_t(\theta)=\frac{\pi_\theta(a_t\mid s_t)}{\pi_{old}(a_t\mid s_t)},\qquad J_{clip}=\mathbb E_t\left[\min\left(\rho_t\hat A_t, \operatorname{clip}(\rho_t,1-\epsilon,1+\epsilon)\hat A_t\right)\right]. \]

Actor最大化该代理目标，等价实现可以最小化其负值。正优势鼓励增加相应动作概率，负优势鼓励减小；裁剪改变代理目标的收益，不是直接把神经网络参数截断。更新后仍要监控实际KL、clip比例和有效样本，不能只看到目标值上升就认定策略仍接近旧分布。

GAE、终止与采集截断

GAE将多步TD残差指数加权，在方差与偏差间取舍。其原始推导针对策略梯度与价值估计；应用到语言token，需要额外明确状态、奖励位置与终态。[10] 用 \(b_t\) 表示该转移是否允许bootstrap，\(c_t\) 表示是否沿同一轨迹继续递推：

\[ \delta_t=r_t+\gamma b_tV_{old}(s_{t+1})-V_{old}(s_t),\qquad \hat A_t=\delta_t+\gamma\lambda c_t\hat A_{t+1}. \]

真正终止时 \(b_t=c_t=0\)。若只因采样长度到上限而截断一个尚未结束的任务，最后转移仍可有 \(b_t=1\)，但当前采集片段不继续递推，故 \(c_t=0\)；需要保存实际末状态的价值估计，不能用自动reset后的新任务状态替代。Gymnasium文档清楚区分termination与truncation的bootstrap语义。[11] 对LLM，EOS、max_new_tokens和业务超时是否代表终态，要由定义的任务目标决定，不能直接按字段名机械映射。

以下是本书手算，非训练实验。取三步奖励 \((0,0,1)\)、旧价值 \((0.2,0.4,0.6)\)、\(\gamma=1,\lambda=0.5\)，最后一步真正终止，末价值按零处理。逐步倒推得到：

第三步优势是0.4，第二步为0.2加0.5乘0.4，第一步同理。若另一条采集片段第三步奖励为零且只是截断，末状态估值0.8，则第三步残差为0.2，优势依次为0.35、0.30、0.20，回归目标为0.55、0.70、0.80。若误将截断当终止，最后残差会变成负0.6，并向前污染优势。

生成数据时保存旧logprob与旧价值。Actor使用的优势应视为固定数值，不能经优势计算反向更新critic；critic拟合的回报目标也应detach，不能让目标跟着当前预测一同移动而虚假减小误差。共享主干时，两个明确的损失可以分别向主干贡献梯度，但不是通过未切断的目标路径互相追逐。归一化优势、价值裁剪和系数等属于训练配方，需要记录，不能默认为同一PPO定义。

Reference KL和PPO clip的边界

一种教学奖励构造是每步加 \(-\beta[\log\pi_{old}(a_t\mid s_t)-\log\pi_{ref}(a_t\mid s_t)]\)，并在回答末尾加偏好分。在旧策略采样的动作上，这个log比的期望对应旧策略到reference的逐状态KL；单个样本可以为负，不能把它当逐token必非负的精确KL。其他估计器和把KL放进损失的配方也存在，应单独记录。[2][9]

Reference KL约束相对行为锚点，clip比较当前策略与rollout旧策略；它们不是同一个模型对，也不是彼此替代的安全保证。改变KL系数会改变奖励目标，改变clip范围会改变更新代理，两者都不能证明退款已授权或代码已正确。观察reward改善时，必须仍用独立任务与安全评估核对。

RLHF 的收益与奖励投机

InstructGPT 的结果说明，少量高质量示范加上人类反馈可以显著改善指令遵循和用户偏好 [2]。HH-RLHF 工作把 helpfulness 与 harmlessness 作为不同数据和评价维度，说明对齐不能只优化一个“总分” [8]。但 reward model 只观察到有限特征，policy 可能学会让答案“看起来像高分答案”，而不是完成真实任务。

典型 reward hacking 包括：用更长的答案获得“更充分”的表面分；反复声明安全以获得无害分；使用肯定语气迎合用户；把不确定问题包装成自信结论；通过测试集模式获得奖励。发现投机的关键不是降低 reward，而是把线上目标拆成独立验收：事实用检索或引用检查，代码用执行测试，格式用解析器，安全用攻击集，用户满意度用真实任务而非单一 judge。

RLHF 的数据和系统成本

RLHF 需要候选生成、标注平台、偏好数据库、Reward Model 训练、在线 rollout、策略训练和评估回归。每个环节都可能成为瓶颈：候选太相似，偏好信号弱；候选太长，标注成本高；标注指南模糊，RM 学到噪声；rollout 版本不一致，数据不可复现；训练中 reference 与 tokenizer 不匹配，KL 统计失真。

因此选择 RLHF 前应先问：偏好是否能被稳定描述？是否有足够难的比较样本？Reward Model 是否覆盖真实失败类型？是否有独立验证器抵抗投机？如果答案是否定的，先改善示范和评估，往往比直接扩大 PPO 更有效。

3.5 DPO 与离线偏好优化

DPO 的核心思想

DPO 观察到，在特定的 KL 正则化奖励模型设定下，最优 policy 与 reward 存在解析关系，可以直接用偏好对训练 policy，而不显式拟合 Reward Model 和运行完整 PPO [12]。常见目标形式为：

\[ \mathcal{L}_{DPO}=-\log\sigma\left(\beta\left[\log\frac{\pi_\theta(y^+\mid x)}{\pi_{ref}(y^+\mid x)}-\log\frac{\pi_\theta(y^-\mid x)}{\pi_{ref}(y^-\mid x)}\right]\right). \]

直觉是：提高 chosen 相对于 reference 的相对概率，同时降低 rejected 的相对概率。DPO 的优点是使用熟悉的监督训练基础设施，批处理简单，训练曲线更易观察，适合拥有静态偏好数据的团队。它并没有消除对齐问题，只是把 reward model 和在线策略优化的复杂度部分转移到了偏好数据质量和超参数上。

IPO、KTO 与 ORPO

IPO 试图缓解 DPO 在偏好数据重复、噪声或过拟合时的理论和实践问题 [13]；KTO 不要求每个 prompt 都有成对答案，而是使用 desirable/undesirable 的单条反馈，适合只有好坏标签的场景 [14]；ORPO 把监督损失与偏好比率结合，减少对 reference model 的依赖 [15]。它们的共同点是：利用离线数据直接调整回答分布，避免每次更新都与环境交互。

方法选择应由反馈形态决定，而不是由论文热度决定。如果已有稳定的高质量示范，SFT 后再做 DPO 通常更自然；如果只有线上点赞和点踩，先确认反馈是否与任务成功相关；如果有程序化成功信号，直接使用验证器或 RLVR 可能比把信号粗略转换成偏好更合适。

偏好数据的质量控制

偏好对最容易出现三类问题。第一，chosen 和 rejected 实际表达相同，差异只有长度和措辞；第二，标注者依据个人风格而不是任务完成度排序；第三，负例过于糟糕，模型只学会避免明显错误，却没有学会高难度取舍。解决这些问题要增加 hard negative：事实只错一个数字、代码只缺一个边界条件、工具参数只错一个字段、安全回答既不能拒绝过度也不能放任越权。

UltraFeedback 使用规模化AI反馈和更细的评价维度扩展偏好数据，体现了从单一比较走向多属性反馈的趋势 [16]。但 AI 反馈不是天然客观，仍要用人工抽样检查 judge 一致性、长度偏差、位置偏差和语言偏差。Zephyr 的工作展示了如何用高质量反馈和蒸馏快速得到对齐模型 [17]，同时也说明蒸馏的上限受 teacher、数据和评估协议约束。

概率相加、mask与长度偏差

DPO中的序列log概率是所选response token条件log概率的和。chosen/rejected共享相同提示，提示token不应进入响应似然；各自padding不计，EOS按协议处理。策略与reference必须使用兼容的Tokenizer、模板、截断和监督范围，否则差值混入协议变化，已经不是公式中的同一事件。若一条回答被截断成不完整参数，原偏好标签也需重新检查。[12]

较长回答包含更多负log概率项，直接求和、逐token平均和其他长度归一化定义不是同一目标。不能在实现中随意将sum改mean，再继续声称精确复现原始DPO。beta是偏好目标与参考约束设定的一部分，也不等于生成温度。偏好更高是相对变化，不能据此保证chosen绝对概率每次都上升，更不能证明外部任务已成功。

3.6 RLVR、GRPO 与工具行为

可验证奖励为什么改变了训练对象

偏好奖励适合“哪个回答更好”，但复杂数学、代码和规划任务往往有更客观的验收。RLVR 使用程序、测试、证明检查器或环境状态提供奖励 [18]。DeepSeekMath 展示了 GRPO 等相对策略优化方法与数学验证奖励的结合 [19]；GSM 类任务和代码执行环境则提供了可自动判定的答案或通过率。

结果奖励可以写成：

\[ R(x,y)=\mathbf{1}[V(x,y)=1]-\lambda,\text{cost}(y), \]

其中 \(V\) 是验证器，cost 可以惩罚过长推理、过多工具调用或过高延迟。模型于是会探索多种推理路径，保留能通过验证的轨迹。它学到的不只是“用某种语气回答”，而是“在推理预算内找到可验收结果”。

结果奖励、过程奖励与验证器

只在最终答案上给奖励，信用分配会很困难：一条长推理可能在最后一步出错，模型不知道前面哪些步骤有价值。过程奖励模型尝试对中间步骤逐步评价；Let’s Verify Step by Step 说明过程级验证可以帮助数学推理训练 [20]。但过程奖励也可能把某种表面推理风格当作正确，或者让模型过度拆步骤。

验证器必须视为生产代码审查。它可能覆盖不足、存在解析漏洞、只检查最终数字而不检查约束，或被模型反向利用。Training Verifiers 的研究说明，验证器本身需要训练、校准和对抗评估 [21]。工程上要记录 false positive、false negative、测试覆盖和版本变化，不能因为自动化就把 verifier 当作事实真理。

GRPO、组内奖励与冷启动

DeepSeekMath的GRPO为同一问题采样一组回答，用组内奖励构造相对优势，减少独立critic的需求。以结果监督为例，\(\hat A_i=(R_i-\overline R)/(\operatorname{std}(R)+\varepsilon)\)，该回答token沿用相对优势，再结合策略比和正则化目标更新。这里的epsilon是数值稳定约定，具体实现须记录；如果整组全对或全错，中心化后的奖励没有区分信号，不能指望仅靠分母修复探索。[19]

组大小、奖励难度和题目分布共同决定有效信号。若底座几乎无法生成正确格式或任何成功候选，增加组采样也可能徒增计算；若问题太简单全组成功，同样缺乏相对区分。先测可解析率、非零奖励组比例与多样性，再决定补SFT、调整难度或增加探索，这是本书的选型建议，非一种保证收敛的规则。

R1报告v1区分直接从底座进行RL的R1-Zero与加入冷启动数据的R1；后者用少量整理过的长推理样本改善初始格式与可读性，不能把前者的实验写成“任何任务都不需要SFT”。[18] 工具参数和状态协议严格时，先用示范建立合法行为基线常更易诊断；是否冷启动应由底座与任务证据决定，不是PPO和GRPO各自永久绑定的属性。

工具调用与 Agent 轨迹

工具调用训练需要模型学会选择工具、填充参数、处理返回值和在失败后重试。Toolformer 研究了让模型学习在适当位置调用工具的方式 [22]；ReAct 则把推理和行动交替组织为轨迹，使模型能够根据观察结果更新下一步计划 [23]。这些方法解决的是“模型如何与环境交互”，不是“模型是否拥有工具权限”。

训练数据应覆盖成功、失败、超时、权限拒绝、部分结果和需要人工确认的分支。工具 schema、参数类型、幂等性和错误码必须与线上接口一致，否则模型学到的是不可执行的假协议。任何有副作用的工具都需要运行时权限和审批，不能因为模型在训练中表现出较高调用准确率，就让它直接执行转账、删除或发布操作。

3.7 安全对齐与反馈边界

Constitutional AI 的思路

人类不可能穷举所有危险请求，也难以对每个回答写出统一标准。Constitutional AI 用一组明确原则指导模型批评和改写自己的回答，再利用这些比较构造 AI feedback [24]。原则可以描述无害、诚实、尊重隐私、避免越权、在安全范围内提供帮助等要求。

它的核心流程是：模型生成初始回答；根据原则指出风险；生成修订回答；比较初始与修订版本；用这些偏好训练模型。这样做把“安全标准”从隐含的标注习惯变成可审阅的文本规则，便于版本管理和回归测试。

RLAIF 的优势与盲点

RLAIF 用 AI judge 代替或补充人工标注，可以降低成本、提高一致性并覆盖更多样本 [25]。但 judge 与被训练模型可能共享相同错误，形成同质化反馈；judge 可能偏好更长、更礼貌或更像自身的答案；对复杂事实和隐晦攻击，judge 也可能失效。人类反馈的稀缺性没有消失，只是从逐条标注转移到原则设计、抽样审计和困难案例审核。

安全对齐至少要区分三种行为：允许且有帮助、拒绝且解释边界、拒绝后仍提供安全替代方案。只有“拒绝率”一个指标会奖励过度拒答。HHH 数据集把 helpful、harmless、honest 作为不同评价维度，适合用来说明三者并不总是同向 [26]。例如用户请求安全分析恶意代码时，完全拒绝可能损害帮助性；直接给出可执行攻击脚本又可能越过安全边界。

权重对齐不等于系统安全

模型可以学会说“我不能帮助你”，但它仍可能通过工具调用、编码变换或多轮诱导泄露危险信息。生产安全必须由多层系统承担：输入分类、输出审查、工具权限、参数白名单、沙箱、速率限制、审计日志、人工审批和回滚。Llama 2 的安全评估展示了红队、自动测试和人工分析的组合方式 [27]，但任何公开安全报告都不能替代目标系统自己的威胁模型。

安全训练数据还会带来分布迁移。线上用户可能使用不同语言、隐喻、拼写错误或多轮上下文；攻击者会针对拒答模板做变形。因而安全回归应包含越狱、提示注入、隐私抽取、工具越权和多轮状态攻击，并记录攻击成功率、误伤率、响应延迟和人工接管比例。

安全回归不能只看攻击阻断率，还要看正常请求误拒率。训练可教模型识别不确定性与澄清条件，但裁判与策略共享错误时，反复自评会把错误强化成高分。对外部事实和权限，仍须保留独立证据、确定性规则和责任主体；不能用模型自己的解释替代授权回执。

3.8 方法选择、成本与回归

评估层次

后训练评估至少分为四层。第一层是格式与协议：角色边界、JSON 合法性、工具参数、停止条件；第二层是任务质量：正确性、完整性、代码执行、数学验证、事实引用；第三层是偏好与交互：帮助性、简洁性、诚实、澄清和多轮一致性；第四层是风险：拒答边界、越狱、隐私、工具越权和分布外输入。

每层都要有正例、难例和负例。只测试“正常问题回答得好不好”，无法发现模型在错误前提、冲突指令、超长上下文和工具失败时的行为。Llama 2 和 HHH 数据集提供了把帮助性、无害性和诚实分开评价的实践参考 [27][26]。

LLM-as-a-Judge 的使用边界

LLM judge 可以快速比较开放式回答，MT-Bench 和 Chatbot Arena 研究系统讨论了 judge 与人类偏好的关系以及位置、长度和模型自偏差 [28]。它适合做大规模筛选和回归趋势，不适合单独作为高风险事实或权限决策。使用 judge 时要固定 prompt、随机化答案顺序、做人工抽样、测试不同语言和长度，并报告与人工标注的相关性。

能程序化验证的任务应优先程序化：代码执行、JSON schema、SQL 结果、数学答案、工具状态和引用链接。开放式质量再使用 judge 辅助。这样可以减少“模型评价模型”的循环偏差，也让失败样本能够回放。

对齐回归矩阵

每次 SFT、DPO、RLHF 或 RLVR 更新，都应与上一版本比较同一矩阵：能力是否提升，正常请求是否被误拒，危险请求是否被放行，回答长度是否异常，工具调用是否稳定，延迟和 token 成本是否变化。测试结果要按任务类型、语言、难度和风险等级切片；总体平均分上升不能掩盖关键子集下降。

一个实用的发布门禁可以包含：通用能力不低于基线，关键业务成功率提升，严重安全攻击零放行或处于批准阈值内，格式通过率达标，工具副作用全部经过权限层，尾延迟和成本在预算内。对齐模型不是一次训练后永久稳定，数据、提示、工具和攻击方式变化都会触发重新评估。

根据问题选择方法

可以用以下映射做初筛：如果模型不知道任务格式，先做 SFT；如果模型会做任务但多个答案质量差异明显，加入偏好数据；如果只有好坏标签而没有成对回答，考虑 KTO；如果有可靠程序验收，优先 RLVR 或直接把验证器接入推理；如果问题来自动态事实，使用 RAG 或工具；如果问题是权限和副作用，使用运行时控制；如果问题是复杂任务成功率和延迟权衡，测量 test-time scaling。

这张映射表的价值在于防止“训练万能化”。后训练适合改变稳定、可重复的模型行为，不适合保存经常变化的事实和状态。它可以提高工具参数生成，但不能授予数据库权限；可以让模型更愿意说明不确定性，但不能保证每个事实正确；可以学会推理轨迹，但不能替代测试和人工验收。

偏好数据的失败案例：把越权包装成“更有帮助”

设想客服 Agent 的训练集中，一组标注者总是偏好“直接替用户解决问题”的回答。面对退款请求，模型 A 会说明资格、引用政策并提示需要审批；模型 B 会承诺立刻退款。若标注只奖励语气、速度和表面帮助度，B 很可能被选为偏好样本。偏好优化后，离线“帮助度”上升，线上却出现升级错误和越权工具调用。

根因不是 DPO 或 RLHF 本身失效，而是偏好数据把业务授权错误地当成了表达质量。修复方式也不是继续堆安全样本：应将退款资格、金额、审批状态交给确定性工具；把偏好比较限制在解释清晰度、证据忠实度和升级条件；并在回归集中单独记录越权率、错误升级率和工具参数合法率。这个案例说明，后训练只能塑造默认行为，不能替代生产系统的控制面。

成本、数据和可回滚性

在同一底座、相近序列长度与数据量下，SFT通常是便于启动的基线，离线偏好优化省去在线rollout，而RLHF/RLVR还需奖励或环境链路。实际成本仍要按候选数量、参考前向、有效token和设备测量，不能把算法名当作固定价格排序。训练前应估算标注成本、GPU 时间、评估成本、数据存储、失败重跑和线上推理增量。不要只比较一次训练的费用，还要计算每次发布回归和长期维护费用。

模型版本必须绑定数据版本、模板版本、tokenizer、参考模型、奖励模型、验证器、超参数和评估结果。对齐实验尤其需要保存 rejected 样本和失败轨迹，否则下一轮只能看到“分数下降”，却不知道是哪个边界被改变。模型回滚只是切换权重，工具 schema、系统提示和安全策略也要支持版本回滚。

工具训练样本的正负边界

表中的标签来自本书教学契约，生产样本应由业务规则与实际回执确认。偏好对还应保留同一观察下的难负例，避免模型只学会用礼貌语气包装错误动作。即使演示经过审核，线上工具仍独立检查权限与操作状态；训练目标不是扩大模型拥有的授权范围。

从固定底座到受控发布

将同一底座的SFT、SFT加DPO、SFT加在线RL作为可比较路线，固定留出任务和总预算，分别计入数据标注、候选生成、训练、评估与失败重跑。中文和混合工具协议需要自己的切片，InternLM2等报告提供了分层观察的参考，不能用英文总分替代本地任务。[29] 每次只改变主要因素并保留旧版本，才能解释差异。

发布记录绑定底座、Tokenizer、模板、数据、reference、reward/verifier与推理参数；离线回归后再做只生成不执行动作的影子比较。正常成功率、误拒、越权、格式与成本须同时满足门槛，严重异常触发停止和回退。该流程是本书工程建议，没有实际线上灰度结果。

练习卡 Q263：SFT标签与工具轨迹对齐

状态：设计完成；独立实现未提供，未实测。 输入包含普通问答、多轮工具成功、权限拒绝、提交超时未知四类教学对话，固定Tokenizer/模板与最大长度。输出input_ids、角色区间、labels、Attention/loss mask及有效目标数；按3.2的占位token案例打印每个logits位置预测的目标，区分库内部shift和外部shift两种接口。

断言： 用户/system/tool内容不作为assistant目标，合法动作与EOS保留监督；padding屏蔽且无全零监督样本；packing后独立工单不可跨读；截断导致JSON或工具调用不完整时拒绝或按已定义规则重建样本；训练/测试不含同工单或去重簇。先在少量手工样本验证管线，再核对独立留出集。能拟合小样本不表示泛化，也不表示工具真的提交。

回收错误： EOS与PAD共ID时按ID全屏蔽、重复shift、mask只看字符串长度、工具返回冒充助手，都要有反例。运行代码应放独立实验仓库；本卡不提供伪造测试输出，不把训练loss改善当作已获得业务授权。

3.9 本章小结

后训练从SFT的示范学习，到偏好优化，再到基于环境与验证的反馈，改变的是生成行为。样本边界决定哪些token被学习，优势和奖励决定哪些动作被鼓励，独立回归决定这些变化能否用于目标任务。Reward不是成功证明，critic不是事实库，reference也不是权限系统。

第2章的交叉熵与KL定义在本章分别进入监督和正则化目标；第1章的模型/系统边界在工具轨迹中继续生效。下一章转向生成、搜索和验证，研究一次请求怎样在明确预算内得到更可靠的候选，而不把继续训练当作所有问题的答案。

3.10 参考资料

1. Wei, J., et al，Finetuned Language Models Are Zero-Shot Learners，2022。核验日期：2026-10-16。
2. Ouyang, L., et al，Training Language Models to Follow Instructions with Human Feedback，2022。核验日期：2026-10-16。
3. Hugging Face，Transformers Chat Templates，v4.45.2。核验日期：2026-10-16。
4. Wang, Y., et al，Self-Instruct: Aligning Language Models with Self-Generated Instructions，2023。核验日期：2026-10-16。
5. Zhou, C., et al，LIMA: Less Is More for Alignment，2023。核验日期：2026-10-16。
6. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V，动手学深度学习：softmax回归与交叉熵，中文在线2.0.0。核验日期：2026-10-16。
7. Christiano, P. F., et al，Deep Reinforcement Learning from Human Preferences，2017。核验日期：2026-10-16。
8. Bai, Y., et al，Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback，2022。核验日期：2026-10-16。
9. Schulman, J., et al，Proximal Policy Optimization Algorithms，2017。核验日期：2026-10-16。
10. Schulman et al.，High-Dimensional Continuous Control Using Generalized Advantage Estimation，2015 preprint / v6。核验日期：2026-10-16。
11. Farama Foundation，Gymnasium: Handling Time Limits，checked 2026-10-16。核验日期：2026-10-16。
12. Rafailov, R., et al，Direct Preference Optimization: Your Language Model is Secretly a Reward Model，2023。核验日期：2026-10-16。
13. Azar, M. G., et al，A General Theoretical Paradigm to Understand Learning from Human Preferences，2036。核验日期：2026-10-16。
14. Ethayarajh, K., et al，KTO: Model Alignment as Prospect Theoretic Optimization，2024。核验日期：2026-10-16。
15. Hong, J., et al，ORPO: Monolithic Preference Optimization without Reference Model，2024。核验日期：2026-10-16。
16. Cui, G., et al，UltraFeedback: Boosting Language Models with Scaled AI Feedback，2024 / v2。核验日期：2026-10-16。
17. Tunstall, L., et al，Zephyr: Direct Distillation of LM Alignment，2023。核验日期：2026-10-16。
18. Guo, D., et al，DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning，2025 / v1。核验日期：2026-10-16。
19. Shao, Z., et al，DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models，2024。核验日期：2026-10-16。
20. Lightman, H., et al，Let’s Verify Step by Step，2005。核验日期：2026-10-16。
21. Cobbe, K., et al，Training Verifiers to Solve Math Word Problems，2021。核验日期：2026-10-16。
22. Schick, T., et al，Toolformer: Language Models Can Teach Themselves to Use Tools，2023。核验日期：2026-10-16。
23. Yao, S., et al，ReAct: Synergizing Reasoning and Acting in Language Models，2023。核验日期：2026-10-16。
24. Bai, Y., et al，Constitutional AI: Harmlessness from AI Feedback，2022。核验日期：2026-10-16。
25. Lee, H., et al，RLAIF vs. RLHF: Scaling Reinforcement Learning from Human Feedback with AI Feedback，2024 / v3。核验日期：2026-10-16。
26. Askell, A., et al，A General Language Assistant as a Laboratory for Alignment，2021。核验日期：2026-10-16。
27. Touvron, H., et al，Llama 2: Open Foundation and Fine-Tuned Chat Models，2023。核验日期：2026-10-16。
28. Zheng, L., et al，Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena，2023。核验日期：2026-10-16。
29. InternLM Team，InternLM2 Technical Report，2024。核验日期：2026-10-16。

第4章 推理期扩展

第3章可以把模型塑造成更守指令的协作组件，却不能保证它在复杂问题中一次生成就走对路径。大模型的“推理”不是一个单独的神经网络模块，而是模型、提示、搜索、验证器和推理预算共同形成的过程。自回归模型每次只预测下一个 token，但复杂任务需要先拆解问题、保留中间状态、比较候选路径、检查结果，再决定是否继续。于是，推理算法要回答两个问题：如何从概率分布中生成更好的轨迹，如何用额外计算换取更高的任务成功率。

本章的判断是：推理期扩展以时间、token 和验证成本交换复杂任务成功率；它提升的是候选答案质量，而不是替代事实来源、权限控制或 Serving 可靠性。后训练改变默认行为，推理期扩展决定当前任务如何使用计算，两者必须在任务可验证性和预算约束下协同选择。

本章把“推理能力”和“推理服务”分开。采样、解码、CoT、Self-Consistency、Tree of Thoughts、验证器、RLVR、test-time scaling 和 speculative decoding 属于算法层；GPU 显存、KV cache 分页、continuous batching 和分布式 serving 属于后续 Infra 章节。本章会说明两者的接口，但不把系统吞吐优化冒充模型推理能力。

4.1 历史发展：从一次生成到搜索式推理

自回归生成的基本范式

\(x\) 作为输入时，语言模型定义一个条件分布：

\[ P(y\mid x)=\prod_{t=1}^{T}P(y_t\mid x,y_{<t}). \]

最初的生成系统通常只取最大概率 token，或者用 beam search 在有限候选中寻找高概率序列。GPT-3 展示了模型可以通过上下文示例执行多种任务 [1]，但也暴露了一个事实：单次 greedy 生成的局部最优，不一定对应全局正确答案。模型可能在早期选错一个前提，后续所有 token 都流畅地围绕错误继续。

CoT 与验证式推理

Chain-of-Thought 通过示范中间步骤，让模型把复杂答案展开成一串可观察的推理文本 [2]。Zero-shot CoT 进一步发现，简单的“逐步思考”提示也能诱导某些模型生成中间过程 [3]。Self-Consistency 不再只取一条思路，而是独立采样多条推理轨迹，再对最终答案做多数投票 [4]。这解决了单次采样偶然失败的问题，但成本随样本数增加。

随后出现了显式搜索、工具调用和验证器：Tree of Thoughts 把中间思路组织成可回溯的树 [5]，Graph of Thoughts 允许不同思路合并和循环 [6]，ReAct 把推理与行动交替连接到外部环境 [7]。在数学、代码和形式化任务中，结果验证器和过程验证器让“好思路”不再完全依赖主观评价 [8][9]。

Test-time Scaling 成为新杠杆

传统规模化主要增加参数和训练 token，reasoning model 则在推理时增加计算预算。模型可以生成更多 reasoning token、采样多个候选、调用验证器、进行搜索或重试。DeepSeek-R1 把强化学习与可验证奖励结合，展示了模型通过更长推理和自我反思提升数学、代码等任务的路线 [10]。

Test-time scaling 的关键不是“思考越长越好”，而是把预算分配给有价值的分支。Snell 等人的研究指出，在一定条件下，合理增加推理时计算可能比增加模型参数更有效 [11]。新限制也随之出现：推理成本、延迟、错误累积、验证器漏洞和停止条件，成为算法与产品必须共同设计的对象。

4.2 生成分布与采样：模型如何选择下一个 token

Logits、softmax 与温度

模型在每一步输出词表大小的 logits \(z_i\)。温度采样先把 logits 除以 \(\tau\)，再计算：

\[ p_i=\frac{\exp(z_i/\tau)}{\sum_j\exp(z_j/\tau)}. \]

当 \(0<\tau<1\) 时，概率分布更尖锐，输出稳定但可能重复；当 \(\tau>1\) 时，低概率 token 获得更多机会，输出更有多样性但错误率可能上升。温度不是“创造力旋钮”这么简单，它改变的是整个生成分布，可能影响事实、格式、代码和安全边界。

采样实现还要处理数值稳定性，通常先减去最大 logit 再做 softmax；低温下要避免概率下溢，高温下要避免尾部噪声占据过多质量。中文、代码和结构化输出的 token 分布不同，不能用一套参数覆盖所有任务。

Greedy、Top-k 与 Top-p

Greedy 每步选择最高概率token；固定数值实现与并列裁决时选择规则确定，适合部分代码补全和固定格式，但容易陷入重复或早期错误。Top-k 只保留概率最高的 k 个 token，在截尾后重新归一化的有限候选中采样，Fan等在故事生成中采用过这种方案[12]；k 太小接近贪心，k 太大又会引入低质量尾部。Top-p，也称 nucleus sampling，保留累计概率达到 p 的最小 token 集合，候选数量随分布形状动态变化 [13]。

Top-p 适合语言模型概率分布变化较大的自然语言生成，但不是质量保证。一个错误前提可能拥有很高概率，top-p 只会在错误附近增加多样性。代码、SQL、JSON 和函数调用最好结合语法约束、schema 或验证器；单纯调低 temperature 不能把不可靠输出变成可靠输出。

随机种子、低温与版本化请求记录

公式要求 \(\tau>0\)；服务把temperature设零时，通常需按接口定义切换greedy等路径，不能直接除以零。即使采用greedy，也可能因并列logits、低精度舍入、算子实现、批次形状或模型版本变化而改变输出。PyTorch复现说明明确指出，不保证跨发布版、提交和平台完全复现，CPU/GPU在相同seed下也可能不同。[14] 这不能反过来证明某托管API有或没有seed支持；实际参数必须按其版本文档核验。

因此低温用于改变分布集中程度，seed用于控制一部分随机源，二者都不是事实正确率或跨环境逐字复现的保证。比较方案应固定输入及制品，并重复采样报告分布；需要严格回放时，保存已生成输出和环境证据，比事后只给一个seed更有解释力。

以下为本书服务内部的教学记录规约，不是任何厂商API，也未实际发出请求；占位版本应在实验执行时解析为真实哈希。

{
  "record_kind": "teaching_example_not_measured",
  "model_revision": "<resolved model revision>",
  "tokenizer_template_hash": "<input protocol hash>",
  "prompt_hash": "<exact final input hash>",
  "generation": {"temperature": 0.2, "top_p": 0.9, "seed": 123},
  "accepted_parameters": "<parameters actually accepted by backend>",
  "budget": {"candidates": 3, "verifier_calls": 3, "deadline_ms": 10000},
  "runtime": "<backend, kernels, dtype, device and batch policy>",
  "verifier_revision": "<frozen verifier revision>",
  "result": {"stop_reason": "<actual reason>", "output_hash": "<actual output>"}
}

执行时分别保存请求参数和后端实际接受的参数；不支持或被忽略的字段不能算已控制变量。候选编号、工具结果和停止原因需关联同一记录，并区分重试使用相同随机状态还是重新采样。示例中的候选数和时限都是教学假设，没有压测或质量结论。

Repetition penalty 与 Unlikelihood

重复可能来自高概率 token 的自强化：模型生成一个短语后，历史上下文使同一短语继续变得可能。repetition penalty 在解码时降低已经出现 token 的分数，简单有效，但可能误伤合法重复，例如代码中的变量名或诗歌中的韵脚。Unlikelihood training 从训练目标出发，显式惩罚不希望出现的候选，尝试让模型减少重复模式 [15]。

推理时还可以限制重复 n-gram、设置最小长度、引入 stop sequence 或使用语法约束。每种方法都可能产生副作用：过强惩罚会让模型刻意换词、破坏术语一致性或生成不自然文本。应该用真实任务的重复率、正确率和格式通过率共同评估。

任务化采样配置

采样参数应纳入版本管理和评估记录。模型版本相同，只改变 temperature、top-p 或 stop 条件，也可能造成明显的行为变化。

4.3 解码算法：从局部选择到候选搜索

Beam Search 与长度偏差

Beam search 每一步保留概率最高的 \(K_{beam}\) 条前缀，扩展后再裁剪。它比 greedy 能探索更多路径，但自回归概率倾向偏爱短序列：每增加一个 token 就乘以一个小于 1 的概率。实际系统常使用长度归一化或长度惩罚，但惩罚过强会生成冗长答案。

Beam search 在机器翻译等条件生成任务中有历史价值，但在开放式聊天中不一定优于采样。模型的概率高低未必等于人类偏好，beam 可能产生安全、流畅但空泛的候选。解码算法必须与训练目标匹配，不能假设最大 likelihood 就是最佳任务答案。

Constrained Decoding

结构化生成可以通过有限状态机、上下文无关文法、JSON schema 或词表屏蔽限制候选 token。每一步只允许仍然可能形成合法输出的 token，能显著提高 JSON 和函数参数的解析成功率。它解决的是语法正确性，不解决字段值正确性；一个结构合法的 SQL 仍然可能查错表，一个字段类型正确的 API 调用仍然可能越权。

约束解码要处理 tokenizer 边界、Unicode、转义、空白、停止条件和流式输出。schema 版本变化后，旧约束不能继续复用。生产系统应在模型输出之后再次解析和校验，不能把解码器视为唯一防线。

Speculative Decoding

投机解码用一个较小的 draft model 先生成连续候选，再由 target model 一次验证多个 token。若 target 接受候选，就减少逐 token 的大模型调用；若在某个位置拒绝，就从 target 的校正分布继续生成。Leviathan 等人的方法给出了在保持目标分布的条件下加速自回归解码的框架 [16]；speculative sampling 进一步讨论了随机采样下的接受与修正 [17]。

关键条件是 draft 与 target 足够相似，且验证多个 token 的并行计算成本低于逐 token 生成。接受率低时，draft 只增加开销；draft 太大时，节省的成本又会消失。速度收益还受 batch、上下文长度、GPU kernel 和传输影响，因此要用真实请求分布测量，而不是只看理论接受率。

Speculative decoding 改善的是生成速度，不自动改善答案质量。严格的接受—修正算法可以保持 target 分布，但如果 target 本身错误，最终仍然错误。工程上需要同时监控接受率、tokens/s、TTFT、TPOT、显存和输出一致性。

Blockwise 与并行预测

Blockwise parallel decoding 让模型尝试一次预测一个 token block，再用后续计算验证，目标是减少串行深度 [18]。这类方法与 speculative decoding 有相似目标，但候选产生方式、模型结构和验证过程不同。它们的共同限制是：自回归依赖仍然存在，真正可并行的部分取决于候选正确率和验证成本。

4.4 Chain-of-Thought 与分解式推理

CoT 解决什么问题

直接让模型从问题跳到答案，容易在多步任务中丢失中间变量。CoT 通过显式生成中间步骤，把一个长映射拆成多个局部映射：理解题意、列出条件、执行运算、检查结论。Wei 等人的实验显示，足够大的模型在提供推理示范后，复杂算术、常识和符号任务的性能明显提高 [2]。

从算法角度看，CoT 增加了计算轨迹和可利用的中间状态；从工程角度看，它增加了 token 成本和泄露风险。输出的“思考过程”也不一定是模型真实的因果过程，可能是事后合理化。Turpin 等人通过偏置输入研究CoT解释可能不忠实的问题，提醒不能把可读的步骤直接当作忠实解释 [19]。

Zero-shot CoT 与提示设计

“逐步思考”一类的提示可以在没有任务专用示范时诱导分步推理 [3]。但效果依赖模型规模、任务类型、语言和提示位置。对代码、数学和规划任务，提示可以明确要求先列约束、再生成候选、最后检查；对敏感任务，不应要求模型公开所有内部思考，而应要求输出可审计的结论、依据和验证状态。

Self-ask研究了先显式提出并回答子问题，再合成总答案的方式；能答对各个子问题却合成失败，说明知识召回与组合推理不是同一能力。[20]

好的分解不是把答案机械拆成更多句子。它应减少依赖、暴露可验证中间量、允许失败后回溯。例如 SQL Agent 可以先识别实体和权限，再生成查询，执行只读检查后返回结果；代码 Agent 可以先列修改文件和测试，再生成 patch，运行测试后决定是否提交。

Self-Refine 与迭代修正

Self-Refine 让模型先生成答案，再根据反馈批评和改写，多轮迭代改善输出 [21]。它原研究以同一模型生成反馈并迭代，不要求外部验证器；本书生产设计进一步建议用规则、测试或明确rubric交叉检查。没有独立反馈时，模型可能只是重复自己的偏差；迭代次数太多还会造成答案漂移和成本爆炸。

反馈应尽量具体：指出代码哪项测试失败、数学哪一步不成立、JSON 哪个字段非法、事实缺少哪条证据。泛泛地要求“请改得更好”只能改变风格，不能保证正确性。迭代停止条件应由错误是否消失、验证器是否通过和预算是否耗尽共同决定。

有界反思案例：修补订单校验

设想Coding Agent要修复“金额为负时仍可提交”的校验，允许范围只有本地补丁和测试，无发布权限。以下是设计轨迹，非已运行结果。先冻结失败用例和原始代码，设最多三轮补丁候选、三次测试与十秒教学时限。成功条件由外部测试和差异范围检查定义，不由模型的一句“现在正确了”定义。

第一轮候选把金额改成取绝对值。模型自评可能认为“已不再为负”，外部断言却要求拒绝负金额；测试返回明确反例，反思输入只需包含该断言、补丁差异与相关约束，不需要索取隐藏思维链。第二轮候选改成非负判断，还要检查零值、小数、缺失值和不允许修改的文件。若外部检查均通过，停止生成，并交付补丁与测试证据，不因还能“再完善”而自动扩大修改。

若三轮都未通过，停止原因为budget_exhausted，保留最后验证失败的状态，返回缺少的证据或请求人工；若工具状态未知，先核对状态，不把重复执行当成反思；若发现用例要求本身不明确，停止原因为needs_clarification，不在两个相同前提间循环自证。下一轮不得把上轮模型自评当作新增事实。

这个案例继承Self-Refine的迭代思路，但外部停止、权限和预算是本书工程设计，不能写成论文保证。记录初稿、具体反馈、改动和外部判定，才能区分修复了错误、只改了措辞和掩盖了失败。反思收益应与单次生成、多候选但不反思等基线比较，包含全部测试与重试成本。

4.5 Self-Consistency、搜索与思路图

多轨迹采样

Self-Consistency 对同一问题采样多条 CoT，再聚合最终答案 [4]。如果不同轨迹独立地走向同一个结果，结果可信度通常提高；如果轨迹高度相关，多数投票只是重复同一个错误。采样温度、轨迹数量、答案规范化和投票规则都会影响效果。

聚合不能总是使用字符串多数票。数学答案需要解析等价表达式，代码需要执行测试，开放问答需要 judge 或证据检索。可以把每条轨迹映射为 (answer, evidence, cost)，先过滤验证失败的轨迹，再按答案聚合。这样“多数”建立在可接受候选集合上，而不是所有文本一视同仁。

Tree of Thoughts

Tree of Thoughts 把推理看成搜索：在每个状态生成若干思路，使用评估器筛选 promising 分支，继续扩展或回溯 [5]。它适合需要规划、组合搜索或中间状态可评价的任务，例如数值游戏、路线安排和多步证明。搜索策略可以是 breadth-first、depth-first、best-first 或 beam-like pruning。

树搜索的难点是状态表示和启发式评估。状态太粗，无法区分不同前提；状态太长，评估成本高；启发式不准，搜索会把预算花在错误分支；分支太多，组合爆炸。实际系统通常需要限制深度、宽度、每步 token、总 verifier 次数和超时，并保存可回放轨迹。

Graph of Thoughts 与共享中间结果

某些推理任务不是树，而是多个思路可以合并、比较和循环。Graph of Thoughts 允许把生成的思路作为图节点，执行聚合、变换和反馈 [6]。例如多个候选计划可以先各自提出，再让模型抽取共同约束，形成一个更稳的综合计划。

图结构的收益是复用中间结论，代价是状态一致性和循环检测。若一个错误结论被多个分支共享，错误影响面会扩大；若节点没有版本和来源，无法知道综合答案依赖哪条路径。工程上应给每个节点记录输入、生成模型、验证结果和依赖关系，把推理图当作可审计的 DAG 或状态机。

4.6 验证器、奖励与推理可靠性

结果验证器

结果验证器只判断最终结果是否满足条件。代码题可以运行隐藏测试，数学题可以检查数值或符号答案，SQL 可以在只读数据库比较结果，规划任务可以检查环境状态。Cobbe 等人的研究展示了训练 verifier 来区分数学答案的路线 [8]。

结果验证的优点是信号清晰、成本可控；缺点是不能解释中间过程，也可能存在测试盲区。一个能通过不完整单元测试的代码不一定正确，一个答案数值正确的推导不一定逻辑有效。验证器的覆盖率、误报率和版本必须纳入模型评估。

过程验证器

过程奖励模型在每个推理步骤上给分，帮助模型学习哪些中间状态更可靠。Let’s Verify Step by Step 说明逐步验证可以改善数学推理监督 [9]。过程监督能缓解最终结果的信用分配问题，但标注和建模成本更高，还可能奖励形式正确但语义无效的“看起来像推理”。

结果奖励与过程奖励可以结合：过程分用于引导搜索，最终验证用于发布门禁；如果两者冲突，以可验证结果和任务约束为准。任何 reward 都是代理，必须通过独立测试防止模型学习评估器漏洞。

幻觉检测与一致性

SelfCheckGPT 利用多个采样结果之间的一致性，检测事实陈述可能存在的幻觉 [22]。如果相同问题的独立样本对一个事实说法差异很大，说明模型内部不确定；但一致性不代表真实，一个模型可以稳定重复错误。幻觉研究还区分事实错误、无依据生成、上下文冲突和指令偏离 [23]。

更可靠的做法是让模型引用检索证据、调用事实工具或通过程序检查，并把“不确定”作为合法输出。采样一致性可以作为风险信号，不能单独作为事实验证器。高风险领域要把证据来源、时间、权限和版本纳入判定。

搜索复杂度与剪枝策略

如果每个状态扩展 \(b\) 个候选，搜索深度为 \(d\)，最坏情况下节点数为 \(O(b^d)\)。这也是为什么“让模型多想一些”很快会变成成本问题。剪枝的目标是在不丢失高质量路径的前提下减少节点，包括保留 top-k 状态、设置上限、去除重复状态、优先扩展高价值节点，以及在验证失败时尽早停止。

剪枝器可以使用模型分数、规则分数、检索证据、程序测试和历史成功率。单一模型分数容易把流畅错误排在前面；单一规则又可能误杀创造性路径。组合评分要注意尺度校准，避免某个分数因为数值范围更大而完全支配决策。对高风险任务，宁可保留少量候选等待人工，也不能用不可解释的启发式直接丢弃所有替代路径。

状态去重也是重要优化。不同文字可能表达同一个数学答案、代码状态或计划状态；如果只按字符串去重，搜索会重复探索。可以对结构化状态做规范化，对代码运行结果做状态摘要，对答案做数学等价化。但语义去重本身可能误合并不同前提，必须保留原始轨迹和依赖信息，以便验证失败时回溯。

生成质量与搜索多样性

搜索不是候选越相似越好。若所有分支都来自同一个高概率前缀，投票和搜索只是在放大同一偏差；若候选完全随机，验证成本会很高。可以在早期使用较高温度或 diverse sampling 获取不同计划，再在后期降低温度并使用 verifier 收敛。多样性应在“不同有效策略”之间，而不是错误格式和无意义改写之间。

对代码任务，可以让候选使用不同算法或边界处理，再通过测试筛选；对数学任务，可以要求不同证明路径或不同变量消元顺序；对规划任务，可以改变资源约束和执行顺序。多样性设计必须与任务结构结合，不能简单把 temperature 调高后宣称探索更充分。

训练时推理与推理时搜索的关系

CoT 数据、过程奖励和搜索轨迹会改变模型的先验，但不意味着上线时必须暴露同样长的思考。训练可以让模型学会提出更有价值的候选，推理时再根据难度选择短答、单轨迹、少量采样或完整搜索。相反，如果训练没有学会可验证的中间结构，仅靠 runtime 反复采样可能得到更多相似错误。

因此评估应比较四种配置：基础模型单次生成、后训练模型单次生成、后训练模型加采样、后训练模型加验证或搜索。这样才能知道收益来自训练、额外计算还是验收机制。DeepSeek-R1 等工作说明强化学习可以把一部分搜索能力压进模型，但生产系统仍需要按预算和风险动态决定是否启动外部搜索 [10]。

4.7 Test-time Scaling：推理预算如何分配

预算的组成

推理预算不只是生成 token 数，还包括候选数量、搜索深度、验证次数、工具调用次数、上下文长度和 wall-clock 时间。可以把一次任务的预算写为：

\[ C_{budget}=C_{tokens}+\lambda_1C_{samples}+\lambda_2C_{verify}+\lambda_3C_{tools}+\lambda_4C_{latency}. \]

不同任务的最优分配不同。简单问答增加候选没有收益；数学题可能需要多条轨迹和 verifier；代码题可能更适合少量候选加真实测试；Agent 任务需要把预算留给工具观察和重试。Snell 等人提出的 compute-optimal test-time scaling 视角，正是要寻找模型规模、样本数和验证计算之间的平衡 [11]。

何时增加模型，何时增加推理

如果错误来自知识缺失，增加推理预算通常没有帮助；如果错误来自搜索路径、算术步骤或偶然采样，增加预算可能有效；如果验证器不可靠，增加候选只会增加验证成本；如果任务本身没有可判定目标，长 CoT 可能只是生成更多解释。

可用一个小实验估计收益曲线：固定模型和提示，逐渐增加 reasoning token、候选数和 verifier 次数，记录成功率、单位成功成本、p95 延迟和失败类型。当收益曲线很快饱和时，继续扩大预算不划算；当成功率持续增长但延迟超限时，可以做路由，让简单请求走短路径、困难请求走长路径。

预算实验还要做按难度分层。平均值可能掩盖一个重要事实：简单问题不需要额外计算，困难问题却只有在某个预算阈值之后才突然成功。可以按问题长度、步骤数、工具数量、历史失败率和验证难度建立桶，分别拟合成功率曲线。这样路由器才能为不同请求选择预算，而不是把所有请求都提升到最高档。

预算也不是越多越公平。长时间搜索会占用共享 GPU 和工具配额，导致其他请求排队；无限重试可能放大一个错误状态；过多候选会增加用户等待和隐私暴露。因此多租户系统需要设置每租户 token、验证、工具和时间配额，并在资源紧张时优先保证低风险、短任务和已经接近完成的请求。

这说明 test-time scaling 既是算法问题，也是资源调度问题。算法必须显式暴露预算和停止接口，系统才能根据优先级、风险和容量做出可解释的分配。

Reasoning RL 与蒸馏

Reasoning RL 使用可验证任务奖励，让策略探索更有效的推理轨迹。DeepSeekMath 将 GRPO 与数学验证结合 [24]，DeepSeek-R1 展示了从冷启动示范到强化学习和蒸馏的组合路线 [10]。PPO 等策略优化方法提供了更通用的 RL 基础 [25]。

强化学习并不自动产生可靠推理。奖励漏洞会让模型学会投机，奖励稀疏会让训练不稳定，长轨迹会提高 credit assignment 难度。蒸馏可以把大模型的推理轨迹压缩到小模型，但如果轨迹包含错误或过度冗长，小模型也会继承这些问题。必须保留独立 verifier、基础能力回归和成本评估。

分解、层次规划与组合泛化

复杂任务通常不是“多生成几个 token”就能解决，而是需要把目标拆成相互依赖的子目标。组合性研究指出，模型可能分别会做两个简单操作，却无法稳定地把它们组合到一个新任务中 [20]。因此推理算法要显式表示任务结构：先识别对象和约束，再决定步骤顺序，最后把子结果合成为答案。

层次生成把规划和表面实现分开。高层规划先产生章节、步骤、动作或子问题，低层生成再把每个计划展开为自然语言、代码或工具参数。Hierarchical Neural Story Generation 说明，长文本生成可以先规划更高层的内容，再逐步生成细节 [12]。在代码 Agent 中，高层计划可以是“定位调用链—修改接口—补测试—运行回归”，低层模型负责每一步的具体 patch。

分解的关键是边界。子任务太大，仍然需要长链推理；子任务太小，调度和上下文开销会吞掉收益。每个子任务最好有输入契约、输出契约和完成条件。完成条件可以是一个字段完整、测试通过、数据库状态改变或 verifier 接受。没有完成条件的分解只是把一段自由文本拆成几段，不能真正降低错误传播。

搜索状态、动作与回溯

把推理过程形式化为状态 \(s_t\)、动作 \(a_t\) 和转移 \(s_{t+1}=f(s_t,a_t)\)，可以更清楚地设计搜索器。状态包含已知事实、已完成步骤、候选答案和剩余预算；动作可以是生成下一步、调用工具、请求澄清、回退或终止；代价包含 token、时间、工具费用和风险。搜索器的目标不是最大化文本概率，而是在约束下找到成功状态。

回溯是搜索区别于普通 CoT 的重要能力。普通生成一旦写出错误前提，后续 token 通常继续围绕错误展开；搜索可以保留多个候选，在验证失败时退回最近的分叉点。回溯需要保存状态快照和依赖关系，不能简单把错误文本追加到上下文后要求模型“重新想一遍”。对于有副作用的工具，回溯还必须配合事务、幂等和补偿，否则算法层回退并不会撤销真实世界的动作。

规划与执行的隔离

规划模型容易产生不可执行计划，执行模型容易在局部步骤上偏离全局目标。实践中可把计划表示成结构化任务图，每个节点包含动作、参数、前置条件、预期结果和失败策略。执行前先检查权限和资源，执行后把真实观察写回状态，再决定继续、重试还是修改计划。

ReAct 的推理—行动交替给出了一个自然接口 [7]，但生产系统还要加入状态机：模型只能提出候选动作，runtime 负责验证 schema、权限和当前状态。这样既能利用模型的灵活规划，也能避免模型通过自然语言绕过动作边界。对于不可逆动作，必须设置确认点；对于可重试动作，必须定义最大次数和退避策略。

4.8 算法—系统接口：把推理预算交给运行系统

推理预算的接口化

推理期扩展一旦进入产品，就不能只说“多想一会儿”。算法需要向运行系统交付一组明确预算：最大输入长度、最大输出长度、候选数量、搜索深度、验证器调用次数、工具调用次数、超时、停止条件和失败降级。没有这些边界，Serving 层无法估算显存、队列、尾延迟和成本，也无法在预算耗尽时给出可解释结果。

这里要避免一个常见混淆：Prefill、Decode、KV Cache、GQA、FlashAttention、Continuous Batching 是推理服务实现细节，第9章会系统展开；本章只关心算法给系统提出了什么资源需求，以及这些需求如何影响当前任务的成功率。换句话说，本章讨论“值得花多少推理预算”，第9章讨论“怎样稳定交付这笔预算”。

长上下文与有效推理

上下文窗口变长不等于推理能力变强。模型可能丢失中间信息、重复引用错误内容，或把更多无关文本当作证据。长上下文推理应测试信息位置、干扰比例、跨文档关系、答案证据和上下文长度增长曲线。若任务只是从文档中检索一个事实，检索和压缩可能比让模型对全部 128K token 做长 CoT 更便宜可靠。

预算调度与难度路由

如果所有请求都使用最大 reasoning budget，简单任务会浪费成本，困难任务仍可能因为预算不足而失败。可以先用轻量模型或短预算进行难度估计，再把请求路由到不同推理策略：直接回答、检索回答、多候选验证、搜索式规划或人工接管。路由器本身也会出错，因此要允许动态升级：当初步答案缺少证据、验证失败或模型置信信号异常时，再增加预算。

预算分配可以看成一个在线决策问题。每增加一次采样或验证，都应估算成功率增益与边际成本。若第一个候选已经通过强验证器，继续生成没有价值；若多个候选互相矛盾，应优先寻找证据或请求澄清，而不是无上限采样。对 Agent 任务，工具调用次数比思考 token 更可能触发真实成本和风险，预算策略必须对不同动作设置不同权重。

置信度与停止条件

模型 token 概率不能直接当作答案置信度。一个流畅但错误的答案可能每一步都具有高概率。更有用的停止信号包括：多个候选在可验证答案上收敛，程序测试通过，检索证据覆盖关键断言，计划前置条件满足，或者新增推理步骤不再改变结论。停止条件必须明确，否则模型会在已经正确时继续自我批评，或在无法解决时无限循环。

可以把停止判断分成硬条件和软条件。硬条件是超时、最大 token、最大工具次数、风险等级和 verifier 通过；软条件是候选一致性、证据充分度、模型自评和收益曲线。硬条件保证系统不会失控，软条件帮助系统在预算内选择更好的时机结束。所有停止原因都应写入 trace，便于分析“失败是没有想够，还是不应该继续想”。

推理轨迹的隐私与可观测性

显式 CoT、工具参数和搜索分支可能包含用户隐私、系统提示、内部文档和安全策略。保存完整轨迹有助于调试，但也扩大了敏感数据暴露面。生产系统可以区分内部 trace、用户可见摘要和审计事件：内部 trace 最小权限访问，用户只看到经过筛选的结论和证据，审计事件记录动作、权限和结果而不是全部思考文本。

可观测性不应只记录 token 数。至少要记录 prefill/decode 时间、采样策略、候选数量、搜索深度、验证器结果、工具调用、重试次数、停止原因和最终业务结果。这样才能把算法指标与服务指标关联起来：某个策略可能提高准确率，但同时增加人工接管；某个 verifier 可能减少错误，但让 p95 延迟翻倍。算法选型应基于完整 trace，而不是单一 benchmark。

轨迹压缩与结果表达

推理轨迹可能比最终答案长很多，直接把全部轨迹放入下一轮上下文会增加 token 和隐私风险。可以在阶段之间保存结构化状态、关键事实、失败原因和验证结果，而不是保存所有自然语言草稿。压缩过程必须保留来源：某个结论来自哪条检索、哪次工具调用、哪个验证器版本。否则压缩后的摘要会变成新的不可验证事实。

对用户展示时，也要区分“解释”与“内部搜索”。一个模型可以输出简洁的步骤、证据和不确定性，而不必暴露所有采样分支、系统提示或安全规则。对于代码和数学，展示可复核的关键中间结果通常比展示大量自然语言更有价值；对于高风险动作，展示计划、参数、影响范围和确认点，供用户或审批系统检查。

失败恢复和预算耗尽

推理循环必须设计失败路径。候选全部未通过验证时，可以请求更多信息、切换工具、降级到人工、返回部分结果或明确失败；不能默认继续生成。工具超时要区分网络重试和业务重试，避免重复执行非幂等动作。搜索预算耗尽时，系统应返回“已尝试什么、缺什么证据、下一步需要什么”，而不是把最后一条未验证草稿伪装成答案。

失败恢复策略也应进入训练和评估。SFT 可以示范澄清和安全退出，偏好数据可以奖励诚实失败，RLVR 可以把“正确停止”作为奖励的一部分。这样模型学到的不是无论如何都要输出答案，而是在证据不足时选择更安全、更可控的动作。

中文和代码场景的特殊处理

中文、英文、代码和数字混合输入会产生不同的 token 化和概率形状，采样参数不能直接照搬英文自然语言。中文长文可能需要保留段落、标题和引用边界；代码推理需要维护缩进、括号、类型和测试状态；SQL 需要区分表名、字段名和用户输入；数学表达式需要保留符号结构。中文教材对概率建模、优化和泛化的基础解释有助于理解这些差异 [26]。

评估时应按语言和格式切片，而不是把所有任务合成一个平均准确率。一个模型可能英文数学推理较强、中文题目较弱；可能自然语言解释很好、代码执行较差；可能单轮输出正确、多轮工具状态错误。推理算法的收益只有在目标语言和目标格式上重复验证，才具有工程意义。

工程决策与验收方法

按任务选择采样、搜索与验证

这张表将算法选择与系统责任分开：采样和搜索帮助生成候选，验证器决定候选是否满足可检查约束，权限和副作用仍由 Runtime 与策略层负责。第9章只处理这些推理预算怎样在真实流量和 SLO 下被调度与交付。

4.9 本章小结

生成算法从 greedy 和 sampling 发展到 CoT、Self-Consistency、显式搜索、验证器和 test-time scaling，核心变化是从“选择一个最可能的下一个 token”转向“在预算内寻找并验证一条可接受的任务轨迹”。投机解码、长上下文压缩和预算路由可以改善执行效率或成本，但它们与推理质量相关而不等价。

面对一个具体任务，先判断错误来自知识、搜索、验证、格式还是系统权限，再选择对应方法。能程序化验证的任务优先使用执行器和 verifier；需要多路径探索的任务使用采样和搜索；需要实时事实的任务使用工具和检索；需要低延迟的任务使用路由、草稿模型和预算控制。这样，推理能力才会从论文中的 benchmark 变成可观察、可控制、可回滚的工程组件。

4.10 参考资料

1. Brown, T. B., et al，Language Models are Few-Shot Learners，2005。核验日期：2026-10-16。
2. Wei, J., et al，Chain-of-Thought Prompting Elicits Reasoning in Large Language Models，2022。核验日期：2026-10-16。
3. Kojima, T., et al，Large Language Models are Zero-Shot Reasoners，2022。核验日期：2026-10-16。
4. Wang, X., et al，Self-Consistency Improves Chain of Thought Reasoning in Language Models，2023。核验日期：2026-10-16。
5. Yao, S., et al，Tree of Thoughts: Deliberate Problem Solving with Large Language Models，2023。核验日期：2026-10-16。
6. Besta, M., et al，Graph of Thoughts: Solving Elaborate Problems with Large Language Models，2024。核验日期：2026-10-16。
7. Yao, S., et al，ReAct: Synergizing Reasoning and Acting in Language Models，2023。核验日期：2026-10-16。
8. Cobbe, K., et al，Training Verifiers to Solve Math Word Problems，2021。核验日期：2026-10-16。
9. Lightman, H., et al，Let’s Verify Step by Step，2005。核验日期：2026-10-16。
10. Guo, D., et al，DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning，2025 / v1。核验日期：2026-10-16。
11. Snell, C., et al，Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters，2024。核验日期：2026-10-16。
12. Fan, A., et al，Hierarchical Neural Story Generation，2018。核验日期：2026-10-16。
13. Holtzman, A., et al，The Curious Case of Neural Text Degeneration，2020。核验日期：2026-10-16。
14. PyTorch contributors，Reproducibility，2.14 documentation; checked 2026-10-16。核验日期：2026-10-16。
15. Welleck, S., et al，Neural Text Generation with Unlikelihood Training，2020。核验日期：2026-10-16。
16. Leviathan, Y., Kalman, M., & Matias, Y，Fast Inference from Transformers via Speculative Decoding，2023。核验日期：2026-10-16。
17. Chen, C., et al，Accelerating Large Language Model Decoding with Speculative Sampling，2023。核验日期：2026-10-16。
18. Stern, M., et al，Blockwise Parallel Decoding for Deep Autoregressive Models，2018。核验日期：2026-10-16。
19. Turpin, Michael, Perez, Bowman，Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting，2023 / v2。核验日期：2026-10-16。
20. Press, O., et al，Measuring and Narrowing the Compositionality Gap in Language Models，2022。核验日期：2026-10-16。
21. Madaan, A., et al，Self-Refine: Iterative Refinement with Self-Feedback，2023。核验日期：2026-10-16。
22. Manakul, P., Liusie, A., & Gales, M，SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models，2023。核验日期：2026-10-16。
23. Ji, Z., et al，Survey of Hallucination in Natural Language Generation，2023。核验日期：2026-10-16。
24. Shao, Z., et al，DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models，2024。核验日期：2026-10-16。
25. Schulman, J., et al，Proximal Policy Optimization Algorithms，2017。核验日期：2026-10-16。
26. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V，动手学深度学习：softmax回归，中文在线2.0.0。核验日期：2026-10-16。

第5章 模型适配与能力扩展

大模型落地时，团队很少从随机初始化开始训练一个新模型，更常见的问题是：已有基础模型如何适配业务，如何在质量下降可控的前提下降低显存和延迟，如何把文本模型扩展到图像、文档、视频或界面。微调、压缩和多模态看似是三组技术，实际上共享一个工程问题：在有限数据、算力和风险预算下，改变模型的有效能力分布。

本章把“适配”与“部署”区分开。LoRA、QLoRA、量化、蒸馏和视觉语言对齐属于算法层；adapter 动态加载、GPU 调度、模型服务和灰度回滚属于后续 Infra 层。算法层必须给 Infra 提供清晰的权重、精度、输入输出和质量契约，但不把一个 adapter 能否上线误解成单纯的训练成功。

本章的执行顺序是先选型、再训练、再压缩、再扩展模态。具体说，先判断问题应由 Prompt、RAG、工具、工作流还是微调解决；再决定监督信号是示范、偏好还是环境反馈；接着评估 PEFT、QLoRA、量化、蒸馏对质量和成本的影响；最后把多模态能力作为通向第6章物理闭环和空间感知的桥，而不是与文本适配并列的孤立主题。

5.1 先诊断问题再选适配方式

Prompt、RAG、工具与微调的分工

同一个业务需求可能有多种解决方案。Prompt 改变当前请求的指令；RAG 提供当前证据；工具读取或修改外部状态；工作流控制步骤和权限；微调改变模型的长期行为先验。可以用四句话区分：

Prompt：这一次希望模型怎么做
RAG：这一次应该参考哪些知识
Tool：这一次允许访问哪些外部能力
Fine-tuning：以后更稳定地表现出哪种任务模式

如果问题是实时库存、当前 owner、最新日志、审批状态或价格，微调不是事实源；如果问题是固定 JSON、工单分类、摘要风格、术语习惯和工具参数格式，微调更有价值。Qwen 技术报告体现了基础模型可以同时覆盖中文、代码和多种任务，但领域应用仍要通过数据和评估决定是否需要进一步适配 [1]。

适合微调的任务特征

一个任务通常在以下条件同时满足时才值得微调：输入分布相对稳定，输出协议明确，错误可以定义或排序，数据中有人工修正记录，调用频率足够高，并且可以用 shadow mode 或建议模式安全发布。典型任务包括告警分类、字段抽取、结构化摘要、固定格式报告、领域术语改写、路由和标准化澄清。

不适合优先微调的任务包括实时事实、权限判断、强证据链结论、高风险不可逆操作和边界尚未定义的开放式“专家”任务。微调可以让模型更自然地提出工具调用，但不能授予数据库权限；可以学习引用格式，但不能保证引用内容真实；可以让模型倾向澄清，但不能替代业务规则。

以基线为起点

任何微调项目都应先建立不微调基线：固定模型、提示、RAG、工具和评估集，记录任务成功率、格式通过率、事实准确率、人工修正率、延迟和成本。否则训练后分数上涨，无法判断收益来自新数据、提示变化、评估泄露还是随机波动。

基线还要包含失败样本分类：知识缺失、任务理解错误、格式不稳、风格不一致、工具参数错误、权限越界和无法判断。只有主要失败来自可学习的行为模式时，才进入微调；如果主要失败来自证据和系统状态，应先修 RAG、工具或工作流。

5.2 适配数据、训练量与泛化

SFT、偏好优化与环境反馈

监督微调用输入到标准输出的样本学习行为，适合格式、分类、摘要和示范式回答；偏好优化用同一输入下的 chosen/rejected 学习排序，适合多个答案都可行但质量有差异的任务；强化式优化用状态、动作和奖励处理多步环境反馈。三者的选择取决于监督信号，而不是模型规模。

SFT 的目标可以写为：

\[ \mathcal{L}_{SFT}=-\sum_{t\in\mathcal{A}}\log p_\theta(y_t\mid x,y_{<t}), \]

其中只对 assistant 输出位置 \(\mathcal{A}\) 计算损失；中文教材中的softmax与交叉熵定义可用于复习这个目标。[2] 角色边界、工具结果、系统消息和用户输入的 mask 一旦错误，模型可能学习复读用户、泄露隐藏指令或把工具返回内容当成新指令。偏好优化的目标不是复制某个答案，而是让更优答案相对概率提高；环境反馈则要求奖励与真实任务完成有可靠关联。

数据集的分层和切分

一个可维护的数据集至少应记录任务类型、语言、难度、输入来源、目标输出、验证规则、风险级别和版本。建议把数据分为通用能力锚点、领域任务、格式协议、安全边界、困难负例和线上回流六类。训练集、开发集和冻结测试集要按用户、事件、时间和文档来源隔离，不能把同一 incident 的不同版本随机切到两边。

数据质量的四道门是：语义正确、任务完成、格式合法和安全合规。代码样本要运行测试，SQL 样本要在只读沙箱验证，数学样本要检查答案，事实样本要保留来源和时间。人工修正日志很有价值，但不能把工程师的临时猜测直接当作标准答案；被后续证伪的中间结论必须删除或标记为负例。

数据数量与数据质量

LIMA 在其模型和评估设置中展示了少量精选示范的对齐潜力 [3]。这不是“数据越少越好”，而是强调样本必须覆盖目标任务、边界和失败模式。合成指令可以扩展覆盖，但生成数据仍需要人工抽样、规则验证和去重，不能把合成数量当作有效监督数量。

数据混乱的典型表现是：同一个标签有多个定义；同一种错误在不同样本中被不同处理；正确答案的长度和风格差异过大；工具字段名与线上 schema 不一致；安全拒答没有替代方案。模型会忠实地学习这些矛盾，训练 loss 下降并不能消除标注冲突。数据审查应像代码 review 一样保留规则、版本和修改原因。

微调超参数与有效容量

PEFT 参数量很小，不代表训练问题简单。学习率通常可以高于全参微调，但过高会让 adapter 迅速记住模板；rank 决定低秩子空间容量，dropout 提供正则化，target modules 决定可改变的表示位置。不同层对任务的敏感性不同，统一给每层同一个 rank 未必是最优方案。

训练时要观察的不只是总 loss，还要看每类任务、每种语言和每种输出字段的 loss。若训练 loss 下降而冻结测试集不升，常见原因是样本重复、答案泄露、模板过拟合或任务定义不清。若目标任务提升而通用能力下降，说明 adapter 更新过强、数据分布过窄或训练阶段过长。保留通用回放样本和早期 checkpoint，有助于确定退化从何时开始。

LoRA 的有效容量还受到基础模型限制。没有图像输入接口的模型不能仅靠加rank获得像素感知；领域术语和工具模式可能通过数据适配学到，不能先验判定“没有概念就不能学”。底座能力、数据覆盖和可更新层共同限制结果。AdaLoRA 通过按重要性分配 rank 的思路说明，参数预算应投向真正敏感的层 [4]，但重要性估计仍需目标数据和独立评估校准。

数据泄露与微调记忆

微调数据量小、重复率高，模型可能更容易记住敏感字符串。日志、工单、代码和聊天记录常包含 token、账号、内部 URL、客户标识和个人信息。脱敏不能只用正则，还要处理编码变形、截图文字、代码注释、上下文拼接和间接标识。训练前应做 PII 检测、密钥扫描、权限审计和人工抽样；训练后应做 canary 抽取、提示诱导和长字符串复现测试。

如果业务要求模型输出真实内部字段，应该通过受控工具和权限访问，而不是把字段直接写进权重。微调记忆难以逐条删除，也难以证明某个输出没有来自训练数据。将动态和敏感事实留在外部系统，既方便更新，也方便审计和撤销。

中文数据与过拟合的诊断顺序

中文领域要同时审查简繁、异体字、标点、术语缩写、金额单位、日期和中英代码混排。术语切成多个token并不必然损害语义，先测真实长度、截断率和任务切片；扩词表会改动嵌入和输出头及发布兼容性，不是中文适配的默认动作。翻译腔、模板化合成和同文档多版本可能制造虚假的覆盖，应按来源实体去重，并保留时间外样本。

发生训练loss下降、验证收益停滞时，先检查验证独立性、标签定义、assistant mask、长度归一化和评估解码，再查近重复、答案泄露、类别不平衡与模板捷径。之后才调早停、训练轮数、学习率、weight decay、dropout和rank，或混合通用回放。减少训练量不能修复错误标签；反复参与调参的验证集也不能再冒充最终测试集。上文是本书结合第2、3章训练契约给出的排障流程。

小模型全参SFT与大模型LoRA不能只按“可训练参数量”排名：前者改变的空间更自由，但底座能力和推理容量较小；后者保留较强底座，却受增量与线上大权重成本约束。全参允许更新更多方向，不保证更好泛化；LoRA可能节省优化器状态，却未必满足部署显存与延迟。用相同授权任务、数据切分、模板、有效训练token预算和调参预算做受控比较；若tokenizer不同，还应给出相同原始样本和实际token量，不伪称两个预算完全相同。

候选评审同时列目标质量、中文/代码与通用能力、训练资源、制品大小、目标负载尾延迟及单位成功成本。先用质量和延迟硬门槛淘汰，再在可行候选中选成本；大模型LoRA稍好但超时，不能只凭平均分上线。任务变难后可重新评估路由，不把一次选型写成模型规模的普遍规律。

5.3 PEFT、LoRA 与 QLoRA

Adapter、Prefix 与 Prompt Tuning

Adapter 在冻结主模型层之间插入小型可训练模块，训练参数少，多个任务可以保存为不同 adapter [5]。Prefix tuning 在每层注意力中学习连续前缀，改变模型对输入的条件化方式 [6]；Prompt tuning 只学习输入侧的连续提示，随着模型规模增大表现出更好的参数效率 [7]。

这些方法的共同优点是基础权重不变、任务版本隔离、存储成本较小，适合多任务和多租户场景。限制是新增参数的表达能力受位置和结构约束，任务分布与基础模型差距很大时可能学不动；多个 adapter 组合时还会出现冲突、加载顺序和延迟问题。

LoRA：低秩更新

LoRA 不直接更新权重矩阵 \(W\)，而是学习低秩增量：

\[ W’=W+\frac{\alpha}{r}BA, \]

其中 \(A\in\mathbb{R}^{r\times k}\)、\(B\in\mathbb{R}^{d\times r}\)，\(r\) 远小于原矩阵维度。训练时冻结 \(W\)，只更新 \(A,B\)，推理时可以合并到权重，也可以作为独立 adapter 动态加载。LoRA 论文说明，许多下游适配的有效更新可以用低秩子空间表达 [8]。

LoRA 的关键超参数不是只有 rank。target modules 决定更新哪些投影层，alpha 改变增量尺度，dropout 影响正则化，学习率和数据量决定是否过拟合。只在 q_proj 上加 LoRA 可能节省参数但表达不足；覆盖所有线性层可能提高效果，却增加 adapter 大小、训练成本和部署合并风险。应通过小规模消融比较 rank、层范围、数据比例和通用能力保持。

AdaLoRA、IA3、BitFit 与 DoRA

BitFit只更新bias参数 [9]；IA3学习激活缩放向量 [10]；AdaLoRA根据重要性动态分配rank [4]，三者分别约束更新位置、形式与预算。DoRA 将权重方向和幅度分解，再使用低秩适配方向，试图缩小 LoRA 与全参微调之间的差距 [11]。

这些方法不是线性升级关系。参数越少，存储和多租户加载越容易，但能表达的任务变化越有限；参数越多，效果可能提高，却更容易过拟合和遗忘。方法选择应围绕目标任务的有效参数预算、adapter 数量、是否需要合并、是否需要热切换和是否存在严格延迟约束。

多任务与多租户适配

多个 adapter 可以为不同客户、语言或业务保存独立版本。共享基础模型降低了存储，但运行时要处理 adapter 加载、缓存、批处理混合和权限隔离。不同 adapter 的参数不能因为属于同一模型就互相可信；adapter 文件本身也要做来源校验、签名和资源限制。

合并多个 LoRA 可能出现方向冲突：一个 adapter 要求回答更简洁，另一个要求更详细；一个领域改变术语含义，另一个领域使用不同标签。应优先使用任务路由和显式组合规则，避免把多个未评估的增量直接相加。合并后的模型必须重新做全量回归，不能沿用任一单 adapter 的分数。

Adapter 合并、组合与隔离

LoRA 可以在运行时作为增量加载，也可以合并到基础权重。合并便于使用普通推理 kernel，减少动态分支；独立加载便于多租户切换、灰度和回滚。两条路径可能产生数值差异，尤其当基础模型先被量化、adapter 再合并或权重精度不一致时。

多 adapter 组合需要明确优先级和冲突规则。风格 adapter、领域 adapter、语言 adapter 和安全 adapter 可能修改同一层的相反方向；简单相加不保证语义叠加。可以通过路由选择单一 adapter，也可以在验证数据上学习组合系数，但组合模型必须作为新的版本单独评估。禁止把未经审核的第三方 adapter 直接挂到生产基础模型上，因为它可能改变拒答、工具或数据泄露行为。

QLoRA 的训练路径

QLoRA 在 4-bit 量化基础模型上训练 LoRA adapter，并通过 NF4、double quantization 和 paged optimizer 降低显存 [12]。它让较大模型在有限 GPU 上完成适配，但训练精度、量化方案、梯度计算和部署合并之间存在耦合。

QLoRA 项目至少要区分三份模型：量化基础模型、训练中的 adapter、上线时的合并或动态组合模型。合并后再量化可能产生二次误差；动态加载避免合并，却需要 serving 系统支持 adapter；训练时的 chat template 与线上 template 不一致，也可能被误判为量化退化。最终质量必须在真实推理路径上评估。

连续提示与权重增量的接口差别

Prompt tuning学习输入侧向量，Prefix tuning在层级注意力中引入连续前缀，LoRA改变选定矩阵的有效权重。前两者需要后端支持相应输入或前缀接口，不能把向量文件当普通文字提示；前缀还可能占用注意力长度和缓存资源。LoRA可在兼容的浮点权重上合并，从而消除独立adapter分支，但动态多租户路径仍需要加载增量。不同方法的缓存键、导出方式和并批限制要分别核对，不能凭“参数很少”断言推理免费。

QLoRA的NF4是针对近似正态权重设计的非均匀编码，不是INT4等距整数；double quantization压缩量化常数，paged optimizer缓解部分显存峰值。[12] 冻结低比特底座，反向仍经过相关计算来更新高精度adapter，不等于所有梯度、激活和优化器都以四位存储。它也不等于在训练中更新全部量化权重的QAT。若先合并再量化与训练路径不同，要把导出版本作为新候选回归。

5.4 量化表示、粒度与误差

数值编码不是执行能力

量化需同时说明目标张量、编码、共享scale范围和执行算子。均匀整数仿射量化的基本映射与范围选择可见量化白皮书。[13] 以下固定本书教学约定：\(q=\operatorname{clip}(\operatorname{round}(x/s)+z,q_{min},q_{max})\)，反量化为 \(\hat{x}=s(q-z)\)；\(s>0\)是步长，\(z\)为整数零点。round的平局规则也必须固定。饱和误差来自截断，范围内的舍入误差来自有限网格，二者要分开观察。

对称有符号教学实现取 \(Q=2^{b-1}-1\)，编码范围 \([-Q,Q]\)，绝对阈值 \(a>0\)时设 \(s=a/Q,z=0\)；因此四位示例使用-7到7，明确闲置一个码位，不能与使用-8到7的后端直接比较。全零块约定 \(s=1,q=0\)避免除零；非零常数块可用非零绝对值定scale。空块、NaN和Inf应在统计前拒绝并定位，不能悄悄当零。非对称范围要先包含实数零，再按两端与码位求scale和zero point；若两端相等需走常数分支。

权重可离线统计；激活依赖请求，可以离线校准为静态范围，也可按token或批次动态统计；KV随位置和上下文增长，其误差影响后续注意力。W4A16通常表示低位宽权重配较高精度激活，不能推断KV也变成四位。累加精度、归一化、softmax和未覆盖算子要单列，模型文件小并不表示全图都执行低精度乘法。

明确共享轴才谈粒度

设线性权重 \(W\in\mathbb{R}^{M\times K}\)，行是输出通道。以下布局与账本为本书教学推导，不代表任一导出格式：

row-group在每行内细分时比per-channel细；跨行分组可能反而更粗，所以group并非固定“最细”。沿哪个轴、是否转置、广播规则、尾组padding和对齐都属于配置。激活的channel轴也不能机械照搬权重的输出轴。小组通常减轻局部分布差异，却增加scale、zero-point、索引和反量化开销，不保证更快。

若裸编码位数为b、每组scale占\(s_b\)位且zero point占\(z_b\)位，则未计padding的有效位宽约为 \(b+(s_b+z_b)/G\)。教学例：对称四位、每组128项、半精度16位scale，无零点时约4.125位/权重；这是容量算术，不是文件实测。尾组只有实际元素参与范围估计，padding不得引入伪极值；写盘按真实pack对齐计算，不能直接用这个平均数冒充制品大小。

离群值与格式选读

一个极大值可能把整组scale拉大，让多数小值舍入到零。裁掉离群点能改善主体分辨率，却可能损伤少见关键语义；应比较保留异常通道、减小组、混合精度和裁剪，不只比较平均重建误差。若只保存量化码却丢失scale轴或广播规则，即使形状相同也会解出错误模型。

FP8与NVFP4等浮点低精度格式还涉及指数/尾数、块缩放和多级scale；它们不能套用上述整数步长公式。格式、训练配方和推理后端布局必须分别核对。下面补充一种有官方依据的表示；本章仍不提供跨设备、跨引擎的支持矩阵或自动提速结论。

NVFP4：表示、缩放轴与存储账本

NVIDIA 介绍的 NVFP4 采用 E2M1 数值、每 16 个值共享一个 E4M3 块 scale，再配一个张量级 FP32 scale。Transformer Engine 2.20.2 文档将重建关系写为 x ≈ q_e2m1 × s_block × s_global；其训练配方还区分一维块与二维权重缩放，不能把一种布局套到所有张量。[14][15]

量化时，先从张量和块的统计量确定两级 scale，再把原值除以有效 scale，按配方的舍入与裁剪规则映射到 E2M1 码本；scale 自身也有表示误差。零块须走约定分支，非有限值不能混入 amax；推理转换与训练配方的随机舍入也不能混同。[14][15]

作为本书一维行分组的教学账本，设矩阵为 M×K、K 可被 16 整除：量化码占 M×K/2 字节，逻辑块 scale 形状为 M×(K/16)、占 M×K/16 字节，另加 4 字节张量 scale；未计对齐时约为 4.5 + 32/(M×K) bit/值。这个推导不是导出文件的实际大小。两个四位码装进一个字节后，仍须约定高低位次序、转置、尾块和 scale 的物理排布；目标 kernel 的对齐或重排会增加开销。

5.5 校准与训练后量化

四种范围选择优化不同的代理

Wu等比较Max、Percentile和Entropy校准；其结果说明不同网络适合的范围方法不同。[16] 本书将一般非对称极值法称minmax，对称情形就是最大绝对值法。下表是方法区别，阈值搜索和误差记录必须与5.4的编码约定绑定：

以下是可复核的教学定义。给定校准值集合和固定候选阈值\(a\)，对称量化后计算 \(E(a)=\frac1N\sum_i(x_i-\hat{x}_i(a))^2\)，选MSE最小的候选；并列用预定规则，如选较大范围。候选集合只能从校准/开发过程确定。MSE会给较大数值更高平方代价，但大量普通值仍可能压过少数关键值，因此应另报饱和率、最大误差和长尾任务。

KL方法先固定原始直方图p，对各阈值把尾部计数折入边界，将保留区间合并到低位码桶，再按明确规则展开到与p相同的bin支持集，归一化得到\(q_a\)。计算 \(D_{KL}(p\Vert q_a)=\sum_{j:p_j>0}p_j\log(p_j/q_{a,j})\)后选阈值。若正概率bin对应零\(q\)，应记无穷或按约定平滑后重新归一化；不能直接跳过该项。不同实现对零bin分配不同，报告必须保存规则，不能声称只写一个KL式就复现了某后端。

这里KL比较的是激活直方图，不是第3章策略相对参考模型的KL，也不是输出语义正确率。MSE与KL最优阈值可能不同，最终用独立开发任务选型，冻结测试集只用于最终验收。校准数据覆盖中文、代码、数字、工具模板、长上下文与异常输入；分层抽样记录比例，不把私密字符串无限复制进缓存。权重范围统计和激活校准也应区分，GPTQ/AWQ用激活信息并不意味着二者都在量化激活。

GPTQ：基于误差补偿的权重量化

GPTQ 使用少量校准数据，逐层选择量化权重，并利用近似二阶信息补偿已经产生的误差 [17]。它适合离线压缩大模型权重，尤其关注在固定 bit 数下保持输出误差。优点是无需重新训练，缺点是量化结果依赖校准数据、group size、排序策略和推理 kernel。

AWQ：激活感知的权重缩放

AWQ 观察到，与激活相关的部分显著权重通道对质量影响更大，通过等价缩放降低敏感权重的量化误差，而非直接把所有重要权重保留高精度 [18]。这体现了一个重要原则：权重量化不能只看权重本身，还要看模型在真实输入上的激活分布。不同业务数据会导致“重要通道”不同，因此公开校准集的最佳 bit 配置未必适合线上。

SmoothQuant 与 W8A8

SmoothQuant 把激活中的离群值通过等价变换迁移到权重侧，使权重和激活都更容易做 INT8 量化 [19]。它适合对追求端到端整数矩阵乘法的系统进行优化。难点是平滑系数、校准分布和算子支持；如果某个层或某类输入仍有离群值，整体 W8A8 质量可能显著下降。

ZeroQuant、LLM.int8 与稀疏格式

LLM.int8 通过混合精度处理异常值，说明极少数 outlier 不能简单与普通通道同样量化 [20]。ZeroQuant 探索训练后低比特量化和硬件友好实现 [21]；SpQR 进一步结合稀疏性和量化，以较低存储成本保留敏感权重 [22]。这些方案的共同挑战是算法格式必须与硬件 kernel、编译器和 serving engine 匹配。

方法差别与反量化的成本账本

GPTQ优化局部权重误差并补偿，AWQ利用激活统计选择等价缩放，SmoothQuant用输入通道的缩放把激活量化难度迁移到权重。以后者为例，列向量约定下 \(Wx=(WS)(S^{-1}x)\)，S是输入通道正对角矩阵；浮点等价不保证两端量化后无误差。平滑缩放轴与最终量化scale轴也不是同一概念。GPTQ/AWQ常见路线以权重低比特为中心，SmoothQuant论文主要面向W8A8；具体组大小与激活粒度依配置而定，不虚构统一后端支持表。[17][18][19]

低位权重可能减少HBM读取，融合kernel可在片上解包/缩放再参与计算，避免先展开整块浮点权重写回显存。小batch解码若受权重带宽限制，节省传输可能超过反量化成本；大batch复用提高后，计算、布局转换和调度可能更重要。这是解释AWQ类部署为何可能更快的条件，不是算法名字带来的保证。[18] 实验需固定质量、形状和负载，分别计pack、scale读取、反量化、矩阵乘法及未量化算子。若某一可减半的传输项原占延迟f，理想总加速仅为 \(1/(1-f/2)\)，再扣额外开销；此式为串行时间账本的教学推导。

校准练习卡：先实现可检查的范围估计

输入为有限浮点数组、b、共享轴/组、对称选项及分位参数；先只实现上述对称minmax和绝对值percentile，再扩展非对称双尾。输出阈值、scale、零点、量化码、反量化值、饱和率、MSE和元数据位数，并保存分位插值及round约定。用同一数组比较两法，不能为每法更换输入分布。

边界至少包括全零、非零常数、正负不对称、单个强离群点、长度不足G和不整除G的尾组；空输入、NaN/Inf要明确失败。以手工小数组核对每个码，再确认组间广播不串行。拓展实现MSE阈值搜索与直方图KL，检查零概率与归一化。练习只规定输入输出和验收，尚无配套代码、模型量化或GPU实测；不要用一次数组误差下降声称模型成功。

5.6 蒸馏与小模型路线

Teacher—Student 目标

知识蒸馏让 student 学习 teacher 的软分布，而不仅是硬标签。经典形式为：

\[ \mathcal{L}=\alpha\mathcal{L}_{hard}+(1-\alpha)\tau_{distill}^2D_{KL}(p_{teacher}^{\tau_{distill}}\Vert p_{student}^{\tau_{distill}}), \]

其中 \(\tau_{distill}>0\) 是蒸馏softmax温度，teacher 的软概率包含类别相似性和暗知识 [23]。对语言模型，蒸馏可以使用 teacher 的 token 分布、生成轨迹、偏好排序、中间表示或工具动作。

DistilBERT、MobileBERT 与生成模型

DistilBERT 通过蒸馏和结构简化降低 encoder 模型成本 [24]；MobileBERT 进一步围绕移动设备的延迟和内存设计结构 [25]。这里encoder结果不能直接外推到decoder聊天模型。生成式大模型蒸馏则更复杂：student 需要学习长序列概率、停止行为、工具格式和安全边界，teacher 生成的错误和偏好也会被复制。

蒸馏数据应混合真实数据、teacher 高质量输出和独立验证样本。只用 teacher 生成数据会产生模型自我复制；只用硬标签又浪费 teacher 的软信息。代码蒸馏要运行测试，数学蒸馏要验证答案，工具蒸馏要检查环境状态，不能只比较 token-level loss。

蒸馏的目标选择

如果目标是低延迟分类，logit 蒸馏可能足够；如果目标是聊天和代码，轨迹蒸馏更重要；如果目标是 reasoning，必须考虑过程、结果和预算；如果目标是多模态，student 还要学习跨模态对齐。蒸馏不是简单把大模型“缩小”，而是选择哪些能力值得保留、哪些推理成本可以削减。

5.7 多模态输入与能力扩展

图文对齐的起点

CLIP 用图像—文本对比学习把视觉和语言映射到共享空间，展示了大规模弱标注数据可以学习通用视觉语义 [26]。对比损失鼓励正确图文配对相似、错误配对分离，适合检索和零样本分类，但不能直接完成长文本生成和复杂对话。

ViLT 直接在 Transformer 中处理图像 patch 与文本 token，减少了重型视觉区域特征的依赖 [27]。这类模型解决的是视觉和语言的联合表示，仍需要额外训练才能稳定完成视觉问答、文档理解、空间关系和指令执行。

Flamingo、BLIP-2 与连接器

Flamingo 通过冻结视觉编码器和语言模型，引入跨模态层支持少样本视觉语言任务 [28]。BLIP-2 使用 Q-Former 从视觉特征中抽取与语言模型相关的信息，再连接冻结的大语言模型 [29]。它们共同体现了“冻结大模块、训练小连接器”的工程思想：减少训练成本和灾难性遗忘，同时让视觉信息以语言模型能利用的形式进入上下文。

连接器的瓶颈在于信息压缩。视觉 token 太少会丢失细节，太多会占用上下文和推理成本；冻结语言模型可能无法理解某些视觉概念；视觉编码器和语言模型的坐标、位置与时间尺度不一致。连接器训练必须配合图文对齐、指令数据和任务评估。

LLaVA、Qwen-VL 与视觉指令微调

LLaVA 把视觉特征投影到语言模型输入空间，再使用视觉指令数据训练对话能力 [30]。Qwen-VL 进一步覆盖中文、多语言、细粒度定位和文档理解，展示了中文多模态模型在数据配比和评估上的特殊要求 [31]。这类模型的能力不只来自视觉编码器，还来自图像分辨率、OCR、位置表示、指令质量和语言模型本身。

InternVL 等工作探索更高分辨率和更大视觉基础模型，说明视觉 token 数和细节能力存在明显权衡 [32]。高分辨率可以提升小文字和局部目标识别，却增加显存、上下文和延迟；多图和视频还要处理帧采样、时间顺序和跨帧一致性。

多模态数据与失败模式

多模态训练数据至少包括图文描述、视觉问答、OCR、表格和文档、定位、图表、视频事件和安全边界。图像描述正确，不代表模型能可靠读取数字；能识别物体，不代表能理解空间关系；能回答图片问题，不代表引用了真实视觉证据。评估要把视觉感知、语言推理、定位精度、OCR、跨模态幻觉和安全分别统计。

常见失败包括图像不存在时幻觉描述、文字太小导致数字错误、把相似物体混淆、忽略图像局部、视觉内容与文本提示冲突，以及被图片中的恶意指令注入。多模态系统需要输入预处理、内容安全、证据定位和输出校验，不能把图片当作天然可信上下文。

视觉编码器与语言模型的接口

视觉语言模型至少包含视觉编码器、跨模态连接器和语言模型三部分。视觉编码器把像素变成 patch 或区域表示；连接器把这些表示映射到语言模型可接受的向量空间；语言模型再以自回归方式生成文本或动作。三部分可以全部训练，也可以冻结其中两部分只训练连接器。冻结方案成本低、稳定性好，但视觉和语言之间的差距可能限制上限；全量联合训练表达力强，却需要更多图文数据、显存和严格防止语言能力退化。

视觉 token 数是一个核心预算。降低分辨率或合并 patch 可以减少上下文长度，提高吞吐，但会丢失小字体、表格线和局部目标；提高分辨率能改善 OCR 和定位，却增加 prefill、KV cache 和训练成本。多图输入还要保留图像边界、顺序和来源，否则模型可能把不同页面的字段混在一起。视频则增加时间采样和跨帧一致性问题，不能简单把每一帧独立描述后拼接。

对齐阶段的多模态数据

多模态训练通常包含几个阶段：图文对比学习建立粗粒度语义对齐，图文生成或匹配学习视觉到语言的映射，视觉指令微调塑造对话和任务行为，领域数据再增强文档、图表、代码截图或界面操作。每阶段的目标不同，数据不能混用后期待模型自动学会所有能力。

视觉指令样本应明确答案依赖的是图像、文本还是外部知识。若问题要求读取图片中的数字，标准答案应包含定位和识别依据；若问题要求总结文档，样本要覆盖页码、表格和跨页关系；若问题要求点击界面，动作坐标、元素状态和失败处理必须可验证。只用“描述这张图”的数据，不能训练可靠的业务视觉 Agent。

多模态幻觉与证据约束

语言模型的先验可能覆盖视觉信号：当图片模糊或不存在时，模型仍会凭语言概率编造描述；当图像中有少见物体时，模型会用常见类别替代；当用户问题带有错误前提时，模型可能顺着文本而非图像回答。解决这类问题需要让模型显式指出证据区域、置信不足和需要更高分辨率的原因。

可以在输出中保留 bounding box、页码、时间戳、OCR span 或截图区域，再由程序检查引用是否存在。对于关键数字、金额、合同条款和监控指标，应使用专用 OCR、表格解析或领域工具复核，不把通用视觉语言模型当成唯一事实源。图像中的文字也可能包含提示注入，视觉内容必须和用户指令一样经过信任边界处理。

多模态微调与文本能力保持

视觉指令微调可能让模型更会描述图片，却损伤纯文本代码和数学能力；高分辨率数据可能提高视觉细节，却增加回答冗长和成本。训练时应保留文本回放集合，并按视觉任务、纯文本、中文、代码和安全分层评估。LLaVA 的视觉指令路线、BLIP-2 的连接器设计和 Qwen-VL 的中文多模态实践，分别说明数据、连接器和语言模型底座都会影响最终能力 [29][30][31]。

多模态模型还要做输入缺失测试：只有文本、只有图片、图片损坏、图片尺寸异常、OCR 为空、多图顺序改变、视频帧丢失。模型应能识别输入不足并请求补充，而不是用语言先验填满空白。把这种“正确失败”纳入 SFT 和偏好数据，通常比单纯增加正常图文问答更能提高生产可靠性。

音频、视频证据与可选创作延伸

本书把输入处理视为有损证据链：原文件标识与授权范围、解码、采样/裁剪、感知结果和答案引用要对应。音频转写丢失音调、说话人重叠和非语音事件，需保留时间区间、语言和识别不确定性；不让模型把听不清的金额自动补全。视频抽帧会漏掉短事件，帧的顺序、时间戳和音画同步必须保留；只看到两个端点不能断言中间动作发生。这里描述应用契约，不宣称前述视觉模型都原生支持音频或任意时长视频。

图像要保留页码、区域与缩放映射，音频要保留片段与说话人标记，视频要保留帧时间和采样规则。资源超预算时先选择问题相关片段，再标记未观察范围；损坏、缺页、静音、丢帧和模态冲突应返回证据不足。将这些输入故障与生成错误分开，才能决定重采集、换感知工具还是修改语言模型。

可选延伸是漫剧资产与人物一致性，属于本书教学设计：把角色设定、服装、参考图/声音、分镜与已验收片段保存为带版本资产；镜头记录所用资产和下游依赖。服装版本改变后，只使受影响镜头和合成产物失效，再按预算局部重算。保存seed与提示提高追溯性，但不保证跨镜头身份或每次相同像素；身份条件是否有效取决于具体生成后端，不能从视觉问答论文推出影视生成能力。

片段评估分别检查角色身份、服装与场景、动作连续、音画同步、闪烁、文字可读性和叙事衔接，结合相邻镜头比较及人工抽检，失败镜头单独修复。不要仅由生成模型自评或用单帧美观代替整片验收。完整生成工具、版权范围、可恢复编排和发布授权留给专门项目；本章没有实现全自动创作平台，也不承诺人物一致性保证。

5.8 联合实验与发布契约

质量—成本—风险三维矩阵

任何算法方案都应同时报告质量、成本和风险。质量包括任务成功、格式、事实、代码执行和多模态感知；成本包括训练 GPU、模型大小、显存、吞吐、TTFT、TPOT 和单位成功成本；风险包括隐私、过拟合、越权、量化退化、模态幻觉和回滚难度。

训练路径与真实服务路径

训练时评估的模型可能是 BF16 主权重加 adapter，线上却是合并后 INT4 权重；训练时使用单轮 chat template，线上却是多轮工具模板；训练时图像分辨率固定，线上却是不同尺寸和压缩格式。所有这些差异都可能被误认为数据或模型问题。

因此必须建立真实服务路径的离线回放：使用线上 tokenizer、模板、量化、adapter 加载、采样和 schema 校验，记录同一批输入的输出差异。只有训练路径和服务路径都通过，才能进入 shadow mode。Llama 2 的开放模型实践说明，基础模型、聊天适配、安全评估和发布条件需要联合考虑 [33]。

一次完整量化实验的交付规格

以下是企业知识助手的教学实验方案，尚未运行。固定基础checkpoint及hash、tokenizer、模板、检索证据快照和停止条件，先得到浮点基线；把校准集、调参开发集、最终测试集分开，按文档/事件实体和时间去重切分。测试覆盖中文知识问答、代码片段、工具参数、长上下文和关键数字；RAG证据相同，防止把检索改变归因给量化。

第一轮只改权重精度与粒度，记录tensor/channel/row-group、G、zero point、scale dtype、pack和尾组；第二轮固定可行布局比较校准方法；第三轮再比较敏感层回退及可选激活量化。GPTQ/AWQ内部优化与范围法并非全部可自由互换，不能强行把所有组合放进同一个矩阵。先确认所选实现真正支持该组合，再导出候选，并进行序列化、重载和真实kernel回放。

每个候选报告制品实际字节、峰值显存、任务通过率、关键切片、困惑度、逐层输出误差、饱和率，以及固定输入输出长度、batch和并发下的TTFT、TPOT、吞吐与p95。区分冷加载、预热后稳态和端到端队列时间，记录设备、驱动、库版本与测量重复次数。将成功任务数作分母计算成本，失败重试也算入；样本数和不确定性与平均指标同时给出。

若工具参数退化但困惑度正常，先定位相关样本与层，再尝试减小组、放宽裁剪、修正代表性或保留高精度，不能直接加训练轮数。若质量达标但速度变慢，检查反量化、fallback、布局和负载，而非宣布算法无效。门槛在看测试结果前由任务方确定；候选只在开发集选择，最终测试失败应回到开发流程并保留失败版本，不反复偷窥测试直到达标。

最终生成一份版本化制品记录：权重/adapter hash、量化格式和共享轴、校准样本清单hash、方法参数、导出工具、兼容后端、模板、视觉处理、评估与已知失败。只对已测形状和设备声明适用性；影子回放不执行工具副作用，灰度有停止条件并能恢复上一整套配置。服务端的调度与容量细节交给第9章，本章负责可重放的算法候选和验收证据。

发布契约

模型发布包应包含基础模型版本、adapter 或合并权重、量化配置、tokenizer、chat template、特殊 token、输入模态规格、最大上下文、采样默认值、评估报告和已知缺陷。多租户 adapter 还要包含来源签名、权限、兼容的基础模型和资源限制。

发布契约还应记录训练目标和不适用范围。例如，一个分类 adapter 只保证某套标签和输入格式，不应被路由到开放式问答；一个文档视觉模型只保证规定页型和分辨率，不应被默认用于医学影像；一个 INT4 模型只在指定 kernel 和上下文范围内通过评估，不应因为文件可以加载就宣称所有硬件都兼容。把边界写进模型卡和注册表，可以减少误用。

多模态发布还要说明图片、视频、OCR 和外部链接的处理方式，是否保留原图、是否缓存视觉特征、是否允许用户上传敏感材料，以及模型是否会把图片文字当作指令。安全边界必须在输入、视觉编码、语言生成和工具调用每一层明确，不能只依赖最终输出过滤。

灰度与回滚

灰度发布要同时比较新旧模型的任务成功率、格式错误、量化退化、视觉幻觉、工具调用和尾延迟。对 adapter，影子流量可以并行生成但不执行副作用动作；对量化模型，要在真实 kernel 上回放长上下文和高并发；对多模态模型，要保留输入图片的版本和预处理结果，确保回归可以重现。

回滚不仅是恢复旧权重，还要恢复旧 tokenizer、模板、量化配置、视觉预处理、schema、验证器和路由规则。若只回滚模型文件而保留新模板，可能产生比发布前更隐蔽的协议错误。每个版本都应有明确的兼容矩阵和自动停止条件，严重安全事件、关键任务下降、格式破坏或成本超预算时立即暂停。

5.9 本章小结

微调改变稳定的行为模式，RAG 和工具提供动态事实与外部能力；PEFT 通过少量参数实现任务隔离，LoRA/QLoRA 在训练成本和表达能力之间折中；量化和蒸馏降低推理成本，但必须结合真实数据、硬件 kernel 和服务路径评估；多模态模型通过视觉编码器、连接器和指令数据把图像、文档和视频接入语言模型，但视觉感知、语言推理和证据可靠性不能混为一谈。

面向企业落地，最重要的不是选择一个“最先进”的方法，而是让适配目标、数据监督、压缩格式、输入模态、评估指标和发布回滚形成一份完整契约。只有这样，算法优化才会转化为可维护、可观测、可控制的模型能力。

5.10 参考资料

[1] Bai, J., et al. Qwen Technical Report. arXiv, 2023. https://arxiv.org/abs/2309.16609 访问日期：2026-10-16

[2] Zhang, A., et al. 《动手学深度学习》：softmax回归. 中文在线版2.0.0. https://zh.d2l.ai/chapter_linear-networks/softmax-regression.html 访问日期：2026-10-16

[3] Zhou, C., et al. LIMA: Less Is More for Alignment. NeurIPS, 2023. https://arxiv.org/abs/2305.11206 访问日期：2026-10-16

[4] Zhang, Q., et al. AdaLoRA: Adaptive Budget Allocation for Parameter-Efficient Fine-Tuning. ICLR, 2023. https://arxiv.org/abs/2303.10512 访问日期：2026-10-16

[5] Houlsby, N., et al. Parameter-Efficient Transfer Learning for NLP. ICML, 2019. https://arxiv.org/abs/1902.00751 访问日期：2026-10-16

[6] Li, X. L., & Liang, P. Prefix-Tuning: Optimizing Continuous Prompts for Generation. ACL, 2021. https://arxiv.org/abs/2101.00190 访问日期：2026-10-16

[7] Lester, B., Al-Rfou, R., & Constant, N. The Power of Scale for Parameter-Efficient Prompt Tuning. EMNLP, 2021. https://arxiv.org/abs/2104.08691 访问日期：2026-10-16

[8] Hu, E. J., et al. LoRA: Low-Rank Adaptation of Large Language Models. ICLR, 2022. https://arxiv.org/abs/2106.09685 访问日期：2026-10-16

[9] Zaken, E. B., Ravfogel, S., & Goldberg, Y. BitFit: Simple Parameter-efficient Fine-tuning for Transformer-based Masked Language-models. ACL, 2022. https://arxiv.org/abs/2106.10199 访问日期：2026-10-16

[10] Liu, H., et al. Few-Shot Parameter-Efficient Fine-Tuning is Better and Cheaper than In-Context Learning. NeurIPS, 2022. https://arxiv.org/abs/2205.05638 访问日期：2026-10-16

[11] Liu, S.-Y., et al. DoRA: Weight-Decomposed Low-Rank Adaptation. ICML, 2024. https://arxiv.org/abs/2402.09353 访问日期：2026-10-16

[12] Dettmers, T., et al. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS, 2023. https://arxiv.org/abs/2305.14314 访问日期：2026-10-16

[13] Nagel, M., et al. A White Paper on Neural Network Quantization. arXiv, 2021. https://arxiv.org/abs/2106.08295 访问日期：2026-10-16

[14] NVIDIA. Introducing NVFP4 for Efficient and Accurate Low-Precision Inference. NVIDIA Technical Blog, 2025. 原文。核验日期：2026-10-18

[15] NVIDIA. NVFP4. Transformer Engine 2.20.2 documentation. 官方文档。核验日期：2026-10-18

[16] Wu, H., Judd, P., Zhang, X., Isaev, M., & Micikevicius, P. Integer Quantization for Deep Learning Inference: Principles and Empirical Evaluation. arXiv, 2020. https://arxiv.org/abs/2004.09602 访问日期：2026-10-16

[17] Frantar, E., et al. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. arXiv, 2022. https://arxiv.org/abs/2210.17323 访问日期：2026-10-16

[18] Lin, J., et al. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys, 2024. https://arxiv.org/abs/2306.00978 访问日期：2026-10-16

[19] Xiao, G., et al. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. ICML, 2023. https://arxiv.org/abs/2211.10438 访问日期：2026-10-16

[20] Dettmers, T., et al. LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale. NeurIPS, 2022. https://arxiv.org/abs/2208.07339 访问日期：2026-10-16

[21] Yao, Z., et al. ZeroQuant: Efficient and Affordable Post-Training Quantization for Large-Scale Transformers. NeurIPS, 2022. https://arxiv.org/abs/2206.01861 访问日期：2026-10-16

[22] Dettmers, T., et al. SpQR: A Sparse-Quantized Representation for Near-Lossless LLM Weight Compression. ICLR, 2024. https://arxiv.org/abs/2306.03078 访问日期：2026-10-16

[23] Hinton, G., Vinyals, O., & Dean, J. Distilling the Knowledge in a Neural Network. NeurIPS Deep Learning Workshop, 2015. https://arxiv.org/abs/1503.02531 访问日期：2026-10-16

[24] Sanh, V., Debut, L., Chaumond, J., & Wolf, T. DistilBERT, a Distilled Version of BERT. arXiv, 2019. https://arxiv.org/abs/1910.01108 访问日期：2026-10-16

[25] Sun, Z., et al. MobileBERT: a Compact Task-Agnostic BERT for Resource-Limited Devices. ACL, 2020. https://arxiv.org/abs/2004.02984 访问日期：2026-10-16

[26] Radford, A., et al. Learning Transferable Visual Models From Natural Language Supervision. ICML, 2021. https://arxiv.org/abs/2103.00020 访问日期：2026-10-16

[27] Kim, W., Son, B., & Kim, I. ViLT: Vision-and-Language Transformer Without Convolution or Region Supervision. ICML, 2021. https://arxiv.org/abs/2102.03334 访问日期：2026-10-16

[28] Alayrac, J.-B., et al. Flamingo: a Visual Language Model for Few-Shot Learning. NeurIPS, 2022. https://arxiv.org/abs/2204.14198 访问日期：2026-10-16

[29] Li, J., et al. BLIP-2: Bootstrapping Language-Image Pre-training with Frozen Image Encoders and Large Language Models. ICML, 2023. https://arxiv.org/abs/2301.12597 访问日期：2026-10-16

[30] Liu, H., Li, C., Wu, Q., & Lee, Y. J. Visual Instruction Tuning. NeurIPS, 2023. https://arxiv.org/abs/2304.08485 访问日期：2026-10-16

[31] Bai, J., et al. Qwen-VL: A Versatile Vision-Language Model for Understanding, Localization, Text Reading, and Beyond. arXiv, 2023. https://arxiv.org/abs/2308.12966 访问日期：2026-10-16

[32] Chen, Z., et al. InternVL: Scaling up Vision Foundation Models and Aligning for Generic Visual-Linguistic Tasks. arXiv, 2023. https://arxiv.org/abs/2312.14238 访问日期：2026-10-16

[33] Touvron, H., et al. Llama 2: Open Foundation and Fine-Tuned Chat Models. arXiv, 2023. https://arxiv.org/abs/2307.09288 访问日期：2026-10-16

第6章 具身智能与 Physical AI

前面几章讨论的大模型，大多运行在文本、图像、代码、检索结果和工具调用这些“数字空间”里。世界模型和具身智能把问题推进了一步：模型不仅要回答“下一句话是什么”，还要理解“下一秒世界会怎样变化”“如果我采取这个动作，会发生什么”“这个动作在当前身体和环境里是否可行”。

这些任务把模型能力接到环境反馈上。本章按预测、规划和行动接口比较研究路线，范围以列明来源为准，不把它们视作已经成熟的通用产品。

一句话先建立直觉：

世界模型是智能体对环境状态、动态变化和行动后果的内部预测模型；具身智能是智能体带着身体、传感器和执行器，在环境中通过感知、决策、行动和反馈完成任务的能力。

注意，这里的“世界模型”不是哲学意义上的世界观，也不是知识图谱，更不是数据库。它强调的是：智能体能不能在内部模拟世界，预测行动后果，并据此规划或学习。

6.1 概念、边界与语言模型的关系

很多工程师第一次听到世界模型，会觉得它离 LLM Agent 很远，好像只属于机器人或自动驾驶。但从系统视角看，它和 Agent 工程有同一条主线：

• LLM 通过语言上下文预测下一个 token；
• RAG 通过外部知识约束模型回答；
• Agent 通过工具调用影响数字世界；
• 世界模型通过预测环境状态支持规划；
• 具身智能通过身体在物理世界执行行动。

它们都在解决一个问题：智能体如何在不确定环境中做出更好的下一步动作。

只是动作空间不同：

LLM:
  action = 生成下一个 token

软件 Agent:
  action = 调用工具、编辑文件、访问网页、执行命令

具身智能体:
  action = 移动、抓取、推拉、避障、导航、与人协作

如果你能理解 KV cache、RAG、工具调用和 eval，那么世界模型和具身智能也可以用熟悉的工程语言来理解：状态表示、动作空间、反馈信号、评估指标、安全边界和闭环迭代。

预测器的输入与输出

世界模型可以理解为一个“可用于预测的内部环境模型”。给定当前观察、历史状态和候选动作，它输出未来可能发生的事情。

最简化的表达是：

current observation + history + action
  -> world model
  -> predicted next state / reward / risk / affordance

其中：

• observation：智能体看到或感知到的东西，可以是图像、视频、激光雷达、触觉、文本状态、游戏画面或传感器数据；
• state：环境内部状态，可能是显式的，也可能是模型学到的 latent state；
• action：智能体可以采取的动作，例如转向、抓取、点击、移动、发出工具调用；
• prediction：下一状态、奖励、碰撞风险、任务进度、可行动性或未来视频帧；
• policy / planner：根据预测结果选择下一步动作。

所以世界模型不是“知道很多事实”的模型，而是“能预测状态变化”的模型。

可以用驾驶来类比。一个新手看到前车刹车，只知道“前面红灯了”。一个熟练司机会预测：前车可能急停，右侧电动车可能插入，自己如果不减速，短时间后距离可能不安全（驾驶类比，不是制动距离计算）。后者脑中有一个粗糙但有效的世界模型。

对于 AI 系统也是一样：仅仅识别物体不够，还要预测物体、自己和其他智能体之间的动态关系。

术语的四种使用范围

“World Model”在不同论文和公司报告里含义略有差异。阅读材料时要先判断对方说的是哪一种。

Model-based RL 里的环境动力学模型

这是最经典的技术含义。智能体学习一个模型来预测环境如何变化，然后在模型里“想象”未来，训练策略或做规划。这里关注状态、动作和回报之间可供策略利用的预测关系。

例如 Ha 和 Schmidhuber 的 World Models 工作，用视觉编码器学习压缩表示，用循环网络建模时间动态，再用一个很小的 controller 做决策 [1]。PlaNet在隐空间预测并在线规划 [2]；Dreamer则在学到的隐状态动态中展开想象轨迹来训练actor和critic [3][4]。

这里的关键不是生成漂亮视频，而是让策略能利用预测结果提高样本效率和泛化能力。表示学习的基本观点也是先得到适合下游决策的抽象，而不是把所有原始细节等权保留 [5]。

生成式视频 / 交互式环境模型

近年来，大模型社区开始把“能生成可交互环境”的视频模型也称为世界模型。Genie研究动作可控的生成环境，Cosmos报告世界基础模型平台；两者目的与接口不同，不能当成互换的模拟器 [6][7]。

普通视频生成模型更像“根据提示生成一段看起来合理的视频”。世界模型要求更高：它要能根据用户或智能体动作持续更新场景，并保持物体、空间、因果和交互的一致性。

差别可以这样看：

视频生成:
  prompt -> video

交互式世界模型:
  prompt + action sequence -> evolving environment

如果用户向左走，场景要随视角改变；如果智能体推开门，门的状态要在后续保持；如果物体被移动，它不能下一秒凭空回到原位。这些一致性才是世界模型难的地方。

JEPA 类的表征预测模型

JEPA 路线强调在 latent space 中做预测，而不是重建像素。V-JEPA研究视频特征预测，V-JEPA 2进一步展示动作条件后训练与规划；二者都不要求把每个像素重建出来 [8][9]。

这条线很重要，因为物理世界里很多细节不需要逐像素重建。机器人抓杯子时，不需要预测桌面每个纹理像素，但需要知道杯子位置、姿态、可抓取区域和动作后果。

latent prediction 的优势是更接近决策需要的抽象，可能更高效，也更少陷入像素级生成的噪声。

自动驾驶和机器人仿真的世界模型

在自动驾驶、机器人和工业仿真里，世界模型常常是数据生成、极端场景测试和策略训练的一部分。

例如自动驾驶系统需要大量罕见长尾场景：突然横穿的行人、施工改道、异常天气、遮挡后的车辆、复杂无保护左转。真实路测很难穷尽这些情况，生成式世界模型可以帮助构造可控、可重复、可扩展的仿真环境。CARLA 等开放仿真器说明，标准化场景、传感器和交通参与者是评估自动驾驶策略的重要基础 [10]。

这个方向的核心指标不是“视频好不好看”，而是：

• 场景是否物理合理；
• 其他交通参与者行为是否可信；
• 传感器观测是否接近真实；
• 被训练或评估的策略是否能迁移到真实世界；
• 长尾风险是否被覆盖。

与语言模型的关系

LLM 和世界模型有相似之处，也有关键差异。

相似之处：

• 都是通过大规模数据学习预测；
• 都把历史上下文压缩成内部表示；
• 都可以作为更大智能体系统的一部分；
• 都依赖数据分布和训练目标；
• 都会在分布外场景失败。

关键差异：

LLM:
  输入输出主要是离散 token
  目标是 next-token prediction
  强项是语言、知识、代码、抽象推理和工具协议

World Model:
  输入输出可以是视频、状态、动作、传感器和 latent representation
  目标是预测环境演化和动作后果
  强项是动态、空间、物理、交互和规划

从 Agent 系统看，LLM 更像“高层任务先验和语言接口”，世界模型更像“环境预测器和行动模拟器”。未来很多系统会把二者结合起来：LLM 负责理解任务、分解目标和调用工具，世界模型负责预测动作后果、生成训练场景或辅助规划。

6.2 隐状态动力学：从World Models到Dreamer

早期世界模型路线主要来自 model-based reinforcement learning。

典型流程如下：

flowchart LR
    A["Observation"] --> B["Encoder"]
    B --> C["Latent State"]
    C --> D["Dynamics Model"]
    D --> E["Predicted Future"]
    E --> F["Planner / Policy"]
    F --> G["Action"]
    G --> A

Ha 和 Schmidhuber 的 World Models

经典 World Models 架构可以拆成三块 [1]：

• VAE：把高维图像压缩到 latent vector；
• MDN-RNN：预测 latent state 的时间演化；
• Controller：基于 latent state 选择动作。

这个工作的启发在于：智能体可以先学一个紧凑的环境表示，再在这个内部模型中训练策略。论文在所研究的任务环境中展示了梦境训练后迁移回原任务环境；这里的原环境不能误读成已验证真实机器人安全。

对工程师来说，最值得记的是：世界模型把“感知表示”和“行动策略”解耦了。策略不必直接处理原始像素，而可以基于压缩后的状态进行决策。

PlaNet、Dreamer 和 DreamerV3

PlaNet在线规划与Dreamer想象学习是两种利用隐动态的方式 [2][3]。核心思想是：

1. 从真实交互数据中学习 latent dynamics；
2. 在 latent space 中 rollout 未来轨迹；
3. 用 imagined trajectories 训练 policy 和 value；
4. 把学到的策略放回真实或仿真环境中执行。

DreamerV3 的重要性在于它用单一配置覆盖了很多任务，并在 Minecraft 等复杂环境中展现了从像素和稀疏奖励中学习远期策略的能力 [4]。

这条路线说明：世界模型的价值不只是“生成环境”，更重要的是提升学习效率。真实机器人数据很贵，真实自动驾驶路测很贵，真实工业试错也很贵。如果能在学到的模型里进行想象和试错，就可能减少真实世界探索成本。

世界模型的训练目标与状态表示

世界模型并不只有一个统一损失。像素重建要求预测视觉细节，latent prediction 要求保持对决策有用的信息，奖励预测要求理解任务进展，动作条件预测要求学习“采取动作后会发生什么”。这些目标可以联合训练，但各自的误差含义不同：视频看起来清晰，不代表动作因果正确；奖励预测准确，不代表空间细节足够；latent 表示稳定，也不代表能处理未见物体。

状态表示通常包含视觉、语言、机器人本体状态和历史动作。显式状态便于调试和约束，例如物体位姿、速度、关节角和碰撞标志；隐式状态更容易压缩复杂环境，但不易解释和验证。实际系统可以采用混合表示：世界模型维护 latent dynamics，同时由感知模块提供可审计的对象、关系和安全状态。

动作条件是世界模型区别于普通视频模型的关键。训练样本不能只有连续观察，还要记录动作发生的时间、动作参数、执行结果和失败原因。若数据里动作与环境变化没有对齐，模型学到的只是相关性，无法在规划时比较不同动作。对于机器人，还要区分高层技能、轨迹、关节控制和实际执行反馈，避免把计划动作误当成已经完成的动作。

长时预测与不确定性

短时预测可能看起来准确，连续 rollout 后却逐渐漂移。误差会在每一步进入下一状态，导致物体消失、场景重复或物理关系崩坏。解决方向包括 latent 状态校正、真实观察重置、分层时间尺度、短 horizon 规划和多候选未来。世界模型不必总是预测唯一未来，更应表达多个可能结果和相应不确定性。

不确定性对安全规划尤其重要。预测道路参与者下一步动作时，模型应给出多个行为假设；预测抓取是否成功时，应保留滑落和遮挡等风险；当模型对某个新物体没有经验时，应触发更保守的动作、重新感知或人工确认。把不确定性压成一个看似确定的视频，会让下游策略过度信任错误预测。

观察更新与想象展开不能混用

中文序列模型教材区分用历史观测预测与多步外推，为理解误差积累提供了基础。[11] 世界模型还必须处理动作条件：策略发出的命令、执行器接受的命令和实际测到的运动可能不同，训练记录应保留它们的时间与关联标识。本书用抽象接口表示：观察更新从历史、当前观测和上一步实际动作修正隐状态；想象展开从当前隐状态与候选动作预测下一状态。前者接触真实传感器，后者是预测，两种状态不能共享一个“已发生”标记。

若隐状态压掉了决定未来的变量，例如杯中液体、接触状态或被遮挡的人，单帧预测仍可看似准确，动作比较却可能完全错误。状态是否足够不是看向量维度，而是看相同表示下不同历史是否导致不同后果。历史窗口和记忆可以补充信息，但也会引入更长的校准和计算成本；不能默认编码器输出已满足马尔可夫假设。

本书建议先在短闭环中验证：给同一初始观察两个可执行动作，分别预测结果与不确定性，再用独立观测核对差异；继续比较无动作条件、打乱动作与正确动作三组。如果打乱动作后质量不变，模型可能主要利用视觉惯性而未学到有效控制响应。这个检验是教学实验设计，尚未实现，也不单凭相关性实验宣称因果识别。发现不一致时缩短预测范围、重新观测或拒绝当前计划，比继续叠加想象步数更可检查。

6.3 世界基础模型与动作条件生成

2024 之后，“World Foundation Model”开始成为产业关键词。它的目标类似 LLM：先用大规模通用数据训练一个基础世界模型，再针对机器人、自动驾驶、游戏、仿真、视频生成等任务做后训练或适配。

可以这样类比：

Language Foundation Model:
  大规模文本/代码/多模态数据 -> 通用语言和知识能力 -> 下游任务适配

World Foundation Model:
  大规模视频/仿真/传感器/动作数据 -> 通用物理和交互先验 -> 下游场景适配

Genie与UniSim的动作条件

Genie从无标注互联网视频学习动作可控的虚拟环境，研究中的潜在动作接口与真实机器人关节命令有区别 [6]。UniSim把不同维度的数据结合，研究高层指令与低层控制条件下的视觉结果模拟，并在其设置中用于策略训练 [12]。它们说明生成模型可以参与交互研究，但不能从画面一致推导摩擦、接触力、传感器噪声或安全控制都被正确模拟。

选择训练环境时，应问动作是何种语义、是否有外部状态可校验、可维持多长闭环、失败后如何重置，以及用它训练的策略能否在独立环境受益。动作可控是比视频观感更强的条件，仍不足以证明仿真保真或现实安全。

NVIDIA Cosmos

NVIDIA Cosmos 更偏向 Physical AI 平台：世界基础模型、视频 tokenizers、数据处理、后训练和仿真生态结合起来，服务机器人和自动驾驶开发 [7]。

这代表了一个工业趋势：世界模型不会单独存在，它会和数字孪生、仿真引擎、数据管线、策略模型、评估系统和 GPU 推理平台一起组成栈。

6.4 感知、预测与任务规划

具身智能不是“机器人 + LLM”。它的核心是把模型放进一个会被动作改变的环境中，并让系统在感知、预测、规划、控制和安全反馈之间持续闭环。身体、传感器、执行器、环境、任务目标和数据回流都属于这个闭环的一部分，缺任何一环都不能称为可部署系统。

flowchart TD
    A["Perception<br/>传感器到状态"] --> B["Prediction<br/>世界模型与仿真"]
    B --> C["Planning<br/>任务分解与技能选择"]
    C --> D["Control<br/>VLA / Skill / Motion"]
    D --> E["Safety<br/>约束、急停、人工接管"]
    E --> F["Feedback<br/>轨迹、失败、评估"]
    F --> A
    E --> B

本章涉及的 Dreamer、Genie、Cosmos、V-JEPA、RT-2、PaLM-E、RT-X、Octo、π0 与 Gemini Robotics，可以放回这张图里理解：有的强化预测环境动态，有的强化视觉和语言到动作的映射，有的强化跨机器人数据，有的强化连续控制。技术路线很多，但工程问题只有一个：系统能否在真实环境中连续观察、预测、行动、验证并安全恢复。

真实世界比文本世界更苛刻。动作有速度、力、扭矩和碰撞约束；物体会滑落、遮挡、反光、变形或被人移动；传感器有噪声和延迟；失败可能造成硬件损坏或人身风险；真实试错昂贵，不能靠无限重试换正确率。因此，本章后半部分不再按模型名罗列，而按可部署闭环展开。

感知：从传感器到可行动状态

感知层把摄像头、深度、触觉、IMU、激光雷达、麦克风和机器人本体状态转换成可决策状态。这个状态不只是“图像里有什么”，还包括对象位置、姿态、关系、可通行区域、抓取候选、机器人关节状态、环境变化和不确定性。感知错误会直接污染后续规划：例如教学假设中杯子位置估计偏了几厘米，语言计划再正确也可能抓空。

可行动性，或者 affordance，是感知层与规划层之间的关键概念。它回答的是：在当前环境、当前身体和当前技能集合下，某个动作是否可执行。杯子可以抓，但装满热水时抓取策略要变；抽屉可以拉，但前方有障碍物时不可拉；“把碗放进微波炉”对塑料碗和金属碗安全性不同。SayCan 的核心思想之一，就是把 LLM 的高层语义知识和机器人技能的可行动性结合起来 [13]。

生产系统通常会把感知输出写成结构化状态，而不是把原始图像直接交给高层模型自由解释：

SceneState {
  objects: id, class, pose, confidence, affordance
  robot: joints, gripper, battery, fault_state
  map: free_space, obstacle, restricted_zone
  task_context: instruction, goal, constraints
  freshness: timestamp, sensor_source, uncertainty
}

这个状态要有版本、时间和置信度。按本书的系统设计，若状态过期、置信度不足或关键对象不可见，系统应重新感知、移动视角或请求人工，而不是让语言模型猜测。感知层越结构化，后续规划、控制、安全和评估越容易连接。

预测：世界模型、仿真与数字孪生

世界模型在闭环中回答“如果采取这个动作，环境可能怎样变化”。它可以用于生成合成训练数据、预测候选动作后果、做 model-predictive control、生成长尾测试场景、支持自动驾驶和机器人离线评估，也可以作为数字孪生的一部分帮助调试。关键不是画面是否漂亮，而是预测是否能服务行动。

Sim2Real、Real2Sim 和数字孪生是世界模型落地时最常见的系统形态。Sim2Real 在仿真中训练或测试，再迁移到真实世界，难点是材质、摩擦、接触、传感器噪声、执行器磨损和人类行为造成的 simulation gap [14][15][16]。Real2Sim 从真实失败构建仿真场景，用于复现长尾、做反事实测试和验证修复策略。数字孪生偏工程系统和结构化仿真，世界模型偏学习到的生成式或预测式模型，二者可以结合。

世界模型必须和真实数据闭环校准。一个看起来真实但物理不可信的模型，会让策略学到错误行为；一个在短视频上表现稳定的模型，不一定能支持多轮交互和长时记忆。评估时要比较同一 planner 在真实环境、世界模型和混合环境中的任务成功率、动作分布和失败类型。若策略只在模型内部变好，却不能迁移到真实环境，说明当前决策价值证据不足，需要定位模型偏差、策略利用漏洞或分布差异，不能仅凭迁移失败重新定义模型类别。

规划：把语言目标变成技能图

任务规划层把自然语言目标、场景状态和技能集合转成可执行任务图。例如“把桌上的杯子放进水槽”不能直接变成一个动作，而要拆成找杯子、靠近桌子、选择抓取姿态、抓起杯子、移动到水槽、放下杯子和检查结果。每个节点都需要前置条件、预期结果、失败策略和安全约束。

LLM 或 embodied reasoning model 适合做高层语义理解和任务分解，但必须接收环境状态、技能可用性、affordance、安全规则和失败反馈。它能提出“语义上合理”的步骤，却不能单独证明步骤在当前身体和环境中可执行。规划层应把候选计划交给规则、仿真、世界模型或技能库验证，再进入控制层。

以下为本书教学技能图，retry=2仅表示有限重试示例，不是物理操作默认安全次数：

SkillPlan {
  goal: "cup_to_sink"
  steps: [
    {skill: "locate", target: "cup", precondition: "visible_or_searchable"},
    {skill: "navigate", target_pose: "table_front", safety: "no_human_collision"},
    {skill: "grasp", object: "cup", affordance: "graspable", retry: 2},
    {skill: "place", target: "sink", postcondition: "cup_in_sink"}
  ]
}

计划是版本化候选，而不是事实。执行中环境变化、对象丢失、抓取失败或安全约束触发，都可能要求重新规划。这个设计和后续 Agent Runtime 一致：模型提出候选，运行时保存状态、验证前置条件、执行动作、记录观察，再决定继续、回退或人工接管。

6.5 VLA、技能策略与低层控制

VLA，Vision-Language-Action，是近几年具身智能的重要范式。它把视觉、语言和动作放进同一个模型或同一套训练目标中，输入可以是图像、视频、机器人状态和语言指令，输出可以是离散 action token、末端执行器位姿、关节角、轨迹 waypoint、diffusion/flow 生成的连续动作序列，或高层技能调用。

不同代表工作可以按控制接口理解。RT-2 把动作表示成 token，便于复用视觉语言模型能力 [17]；PaLM-E 把真实传感器接入语言模型，强调 grounding [18]；Open X-Embodiment 和 RT-X 通过跨机器人数据推动跨 embodiment 学习 [19]；Octo 提供开源通用机器人策略，方便比较架构和数据 [20]；π0、π0.5 和后续路线强调从 VLM 走向连续控制和开放环境泛化 [21][22]；2025年Gemini Robotics的官方研究说明将VLA动作输出与Robotics-ER空间推理/低层控制接口分别介绍；本文仅引用该版本，不代表后续产品通用保证 [23]。

但生产系统很少只依赖一个端到端模型。更常见的结构是高层模型负责泛化和任务理解，中层 VLA 或 skill policy 负责抓取、放置、导航、操作等技能，低层控制器和运动规划器负责轨迹可行性、频率、稳定性和安全限制。端到端模型可以提供更强泛化，但解释和验证困难；模块化系统更可控，却需要清晰接口和大量技能维护。实际系统通常在二者之间取折中。

动作契约与控制时钟

以下为本书的接口设计：一段动作至少记录坐标系、单位、目标身体、动作持续时间、采样时刻、有效期和控制模式。归一化token对应的是位置、位姿增量还是速度，必须由schema解释；轴顺序、左右手系和角度单位错了，合法形状也会执行错误动作。动作反归一化还要使用对应机器人与训练版本的统计量，不从另一台机器复制参数。

高层计划、动作块与低层伺服不必同频。模型一次生成一段未来动作，运行时仍要检查时间戳与新观测；网络延迟或人进入场景时，应允许安全控制器中断剩余动作块。动作块越长，模型调用开销可能越低，但对环境变化反应更慢；更短的块增加反馈机会，也增加调度和计算压力。本章不指定统一控制频率或通信时限，具体值必须由设备、任务和安全工程验证。

跨身体迁移也不是只改输出维度：相机外参、夹具形状、可达空间、自由度、载荷和技能语义都可能变化。RT-X的跨机器人数据和Octo的适配结果提供研究证据 [19][20]，不能证明任意新身体无需标定即可执行。部署前应先核对接口、在隔离条件检查低能量动作，并由设备团队确定合格边界。

6.6 安全反馈、恢复与数据飞轮

具身系统的安全不是输出过滤，而是控制闭环的一部分。常见机制包括速度、力、扭矩和加速度限幅，碰撞检测，安全区域，硬件和软件急停，远程或本地人工接管，任务级危险动作拒绝，以及对用户指令的语义安全判断。LLM 的安全提示不能替代控制安全；应由专门控制与安全工程设置底层约束。官方机器人研究也区分语义安全与低层碰撞、力和稳定性控制 [23]；下面的envelope和恢复流程是本书教学设计，不是认证标准或安全证明。

安全边界应被写成一份可计算的 physical-action envelope，而不是一段“请小心”的提示。它至少约束工作空间、末端速度、关节速度、接触力、载荷、人与设备的最小距离、可见性、定位质量、允许工具和允许姿态。每一项约束都需要说明数据来源、测量频率、失效默认值和执行 owner：视觉模型可以建议“桌面上没有人”，但距离传感器失效时，安全控制器应按保守规则降速或停止；语言模型可以选择“拿起杯子”，但不得修改安全区、急停逻辑或力矩上限。机器人控制中的这一层旨在把概率性策略限制在经校验的可行动集合内；约束仍依赖传感器和控制器的可靠性；它也解释了为何 VLA 的高层泛化不能替代传统的运动学、碰撞检测和互锁。

安全 envelope 还应区分三种动作。第一类是只读或虚拟动作，例如在世界模型中 roll out、在数字孪生中规划、在相机画面上标注候选抓取点；它们可由较宽松的模型策略产生。第二类是可逆、低能量的受控动作，例如经设备评估后在隔离区域低速移到观察位、调整无载夹爪或请求更多视角；它们是否允许自动执行仍由设备和场景风险评估决定。第三类是不可逆或高危动作，例如接近人、切换重载工具、快速运动、开门、搬运液体或跨越安全区；它们必须经过额外门禁，必要时要求双通道传感器和人工批准。把动作按后果而非按“模型是否自信”分级，能避免置信度被误用为安全证明。

上线前的评估门禁应沿着这三类动作建立证据链。离线阶段先检查数据覆盖、标注质量、策略在已知回归集上的成功与拒绝；仿真阶段再对遮挡、摩擦变化、动作延迟、传感器丢帧和危险接近做对抗性扰动。CausalWorld 这类可控基准的价值正在于能把“动作改变了什么”明确化 [24]，而 domain randomization 的经验提醒我们，仿真覆盖不是现实保证 [14][15][16]。进入真实环境时，系统先以 shadow mode 记录候选而不执行，然后在围栏区域、低速度、有限物体集合中进行受监护执行；每推进一级都要证明上一阶段的失败模式已被观测、分类和处理，而不能只凭总体成功率放行。

一个可审计的门禁记录至少包含场景版本、机器人和工具版本、策略版本、世界模型版本、传感器健康、候选动作、envelope 判定、拒绝原因、人工决定与结果。对于每个高风险失败，应能回答：模型是否提出了错误候选，状态估计是否遗漏了关键物体，安全层是否正确拒绝，还是执行器在已获许可后偏离了轨迹。把这几个层次混为“机器人失败”，会让后续训练把安全控制器的正确拒绝误标成坏样本，或把执行器故障错误归因于世界模型。

运行中的干预也必须有状态语义。人工接管不是简单抢走遥控器，而是一次有版本的状态迁移：冻结新的高危动作、保留当前传感器与控制快照、标记被中断的技能、给出恢复条件，并把控制权转给预先授权的操作者。恢复时，系统不能从旧的语言计划直接继续；它要重新感知、重新建立环境状态、重新检查 envelope，并确认人、物体和工具仍处于允许位置。若动作已造成不可逆外部变化，例如物体已被放入容器或门已被打开，恢复策略应从事实状态重新规划，而非“回放”模型的旧动作序列。

回滚在 Physical AI 中也有边界。软件配置、模型路由、技能版本和策略阈值通常可以回滚；机器人在空间中的位置、物体形态、人与环境的反应不能回滚。因此发布方案要同时准备软件回滚和物理收敛方案：停止、退回到安全姿态、释放或稳定载荷、隔离故障设备、通知现场人员、保存证据。对可能损坏物体或伤害人的步骤，补偿动作本身也要放入 envelope，不能让“为了恢复”成为绕过安全限制的理由。这个原则与 Agent Runtime 的补偿语义一致，但物理系统的补偿必须先保证人和设备安全，才谈业务目标。

安全评价不应只汇总一次部署的平均数字。建议按动作风险等级分别报告：任务成功率、拒绝的正确率、危险近失率、超限触发率、人工接管率、恢复成功率、传感器失效下的安全停机率，以及从仿真到真实的性能差。每个指标还应给出场景覆盖和置信区间；例如“未发生碰撞”在少量固定场景中不足以支持扩大开放范围。Open X-Embodiment 与 Bridge Data 所展示的跨形态与跨环境数据价值 [19][25]，同样适用于安全评估：系统必须证明其约束在新相机、新夹具、新物体和新布局下仍然保守有效。

数据飞轮决定具身智能能否规模化。一个机器人样本通常包含时间戳、摄像头/深度/触觉/本体状态、语言指令、动作轨迹、成功失败标签、环境元数据和操作者元数据。真实机器人昂贵，任务失败可能损坏硬件，不同机器人动作空间不同，人类遥操作质量不稳定，成功率评估还需要环境状态判断。因此数据来源通常是组合的：遥操作、机器人自主执行日志、仿真数据、视频和网页数据、失败恢复样本、人工示范、偏好反馈和跨机器人共享数据集。Bridge Data 等工作也说明，跨任务和跨环境共享数据可以改善其研究范围内的泛化 [25]。

部署 -> 采集轨迹 -> 标注成功失败 -> 挖掘长尾
  -> 仿真扩增 -> 训练 -> 回归评估 -> 再部署

这条飞轮和 Agent 系统中的 trace / eval / regression loop 很像，只是成本和风险更高。软件 Agent 的一次错误大多可以回滚，机械臂撞到人不能简单 revert。物理世界把所有约束放大，所以具身系统更需要仿真、限幅、人工接管、长尾评估和清晰的责任边界。

6.7 闭环评估与证据边界

评估是这个方向最难的部分之一。

世界模型评估

不能只看视频质量。CausalWorld 等基准强调因果交互和可控操作，说明世界模型应评估动作改变环境后的结果，而不是只评估单帧视觉质量 [24]。更有用的指标包括：

• 预测一致性：物体是否在时间上保持身份和位置一致；
• 动作可控性：给定动作后，环境变化是否对应；
• 物理合理性：碰撞、重力、遮挡、接触是否合理；
• 长时记忆：离开视野的物体再次出现时是否仍然存在；
• 交互稳定性：多轮动作后是否崩坏；
• 任务有效性：用它训练或评估的策略能否迁移到真实环境；
• 安全覆盖：是否能生成高风险和长尾场景。

评估时还要把预测模型放回真实策略闭环：让同一个 planner 分别使用真实环境、世界模型和混合环境，比较任务成功率、动作分布和失败类型。如果世界模型生成的场景只让策略在模型内部变好，却不能迁移到真实环境，说明当前模型尚缺乏跨环境决策效用证据，需继续核对误差来源与分布。对长时任务要记录误差随 rollout 长度的增长，而不是只报告第一帧或短片段指标。

具身评估还要覆盖硬件和人的因素：不同摩擦、负载、传感器延迟、光照、遮挡和操作者指令都可能改变结果。一个只在固定实验台上成功的策略，不能直接推断在家庭、仓库或道路上可靠。评估报告应明确训练内、训练外、仿真、真实和长尾场景的边界。

为了避免“模型分数好但上线不可用”，评估还应把安全层本身当作被测对象。为每个动作准备允许、拒绝、降级和人工接管四类 oracle：当障碍物进入缓冲区时，系统是否在规定控制周期内停止；当相机置信度下降但触觉仍正常时，是否按策略降低速度；当两个传感器对物体位置冲突时，是否选择保守路径；当模型建议的抓取点在工作空间外时，是否拒绝并留下可解释证据。世界模型可帮助生成这些反事实场景，但评估结论必须来自独立的控制日志和真实或高保真仿真观测，而不是由同一个生成模型自评。

这套评估边界决定了世界模型能否真正服务训练、规划和安全验证。没有闭环验证，生成质量不能代表行动价值，也不能代表真实世界中的安全和泛化能力。本章关注的动作条件模型需要证明对行动的帮助；不能把这个工程目标当作所有研究路线已经达到的属性。

具身智能评估

机器人任务不能只看单次 demo。需要：

• 多场景、多物体、多指令测试；
• 成功率、完成时间、碰撞次数、人工接管次数；
• 新物体、新布局、新语言表达的泛化；
• 失败恢复能力；
• 安全违规率；
• 对人的协作体验；
• 长任务完成率；
• 数据和模型版本的回归测试。

设计评审里如果被问“怎么评估一个家务机器人”，不要只说“看能不能完成任务”。更完整的回答是：

我会拆成任务成功率、泛化、效率、安全和可恢复性五类指标。
每类指标都要覆盖训练内、训练外和长尾场景。
同时保留完整传感器、动作和模型 trace，失败样本进入回归集。

6.8 系统案例与Agent接口

和 Agent 系统设计的关系

本书主要讨论 LLM Agent。世界模型和具身智能看似更偏机器人，但它们对 Agent 系统有直接启发。

Agent 也需要“局部世界模型”

软件 Agent 没有机械臂，但它也在环境中行动。它的环境可能是代码库、浏览器、数据库、CI 系统、企业知识库。

一个强的 coding agent 应该理解：

• 修改某个文件会影响哪些测试；
• 执行某个命令会产生什么副作用；
• 依赖升级会破坏哪些 API；
• 当前 repo 的架构约束是什么；
• 一个错误修复会不会引入回归。

这里称为局部环境预测的类比；代码依赖分析和测试反馈本身并不证明Agent已经学习了可迁移的动力学模型。

Tool use 是数字世界的 embodiment

LLM 如果只能生成文本，行动能力有限。接入工具后，它有了“数字身体”：可以搜索、读文件、运行测试、发邮件、调用 API、修改代码。

这是接口层面的教学类比，不能把软件工具调用与物理具身的风险和控制问题等同。它同样需要：

• action schema；
• 权限控制；
• 环境反馈；
• 失败恢复；
• trace；
• eval；
• 安全边界。

物理世界把所有约束放大

物理具身智能比软件 Agent 更难，因为行动不可轻易回滚，反馈更嘈杂，风险更真实。

写错一行代码可以 revert，机械臂撞到人不能简单 revert。这个差异决定了具身系统必须更重视安全层、仿真、限幅、人工接管和验证。

系统设计题：设计一个家务机器人助手

这类题可以按下面框架回答。

需求澄清

先问清楚：

• 机器人形态：单臂、双臂、人形、移动底盘？
• 场景：家庭、酒店、医院、仓库？
• 任务：拿取、整理、清洁、递送、对话？
• 是否允许接触人？
• 延迟要求和安全等级？
• 是否联网？
• 是否需要持续学习？
• 评估指标是什么？

架构草图

flowchart TD
    A["User Instruction"] --> B["Task Planner / ER Model"]
    C["Sensors"] --> D["Perception"]
    D --> E["Scene State"]
    E --> B
    B --> F["Skill Selector"]
    F --> G["VLA / Skill Policy"]
    G --> H["Safety Layer"]
    H --> I["Low-level Controller"]
    I --> J["Robot"]
    J --> C
    E --> K["World Model / Simulator"]
    K --> B
    J --> L["Trace / Eval / Data Flywheel"]
    L --> M["Retraining"]

核心设计点

1. 高层用 LLM / ER 模型理解用户目标、拆解任务。
2. 感知层维护场景状态，包括对象、位置、关系和可行动区域。
3. VLA 或 skill policy 负责具体动作。
4. 世界模型用于预测候选动作后果、生成仿真场景和离线评估。
5. 安全层做硬约束：速度、力、碰撞、禁区、危险动作拒绝。
6. 失败时先暂停、回退、重新感知，再请求人工确认。
7. 所有传感器、动作、模型输出和安全事件进入 trace。
8. 失败样本进入回归集和数据飞轮。

关键 trade-off

• 端到端 VLA 泛化强，但可解释性和安全验证难；
• 模块化系统可控性强，但可能受限于手写技能和接口；
• 仿真数据便宜，但 simulation gap 会影响真实表现；
• 真实数据质量高，但采集成本和风险大；
• 云端模型能力强，本地模型低延迟且隐私更好。

系统设计题：设计一个世界模型服务

如果题目是“设计一个给机器人团队使用的世界模型平台”，回答重点会不同。

输入

• 文本 prompt；
• 初始图像或视频；
• 结构化场景描述；
• 机器人或车辆动作；
• 地图、物体、天气、交通参与者等约束；
• 真实日志片段。

输出

• 未来视频或状态轨迹；
• 可交互环境；
• 多个候选未来；
• 风险评分；
• 场景元数据；
• 可用于训练或评估的数据包。

服务架构

Scenario API
  Prompt / Scene Parser
  Condition Builder
  World Model Inference
  Physics / Rule Consistency Checker
  Scenario Store
  Evaluation Harness
  Data Export Pipeline

评估重点

• 是否可控：能否指定动作、天气、道路结构、物体行为；
• 是否一致：多步交互后场景是否稳定；
• 是否真实：传感器和物理是否接近真实；
• 是否有用：用它训练或评估的策略是否提升真实表现；
• 是否安全：能否覆盖高风险场景且避免生成误导性数据。

常见误区

以下误区回顾用于核对上文模型、环境和评估的边界，不新增独立能力结论。

误区 1：把世界模型当知识图谱

知识图谱表示实体和关系，世界模型预测状态变化和动作后果。二者可以结合，但不是一回事。

误区 2：把视频生成模型等同于世界模型

像素视频生成不是所有世界模型的必要条件，latent模型也可支持决策；交互路线则需验证动作条件、长时一致与任务有效。会生成视频，不代表能支持智能体学习。

误区 3：以为具身智能就是给机器人接 ChatGPT

语言理解只是高层能力。机器人还需要感知、控制、可行动性、安全、仿真和数据闭环。

误区 4：只看 demo，不看评估分布

机器人 demo 往往展示最成功的一次。工程上要看多场景、多物体、多任务、多轮失败恢复和安全违规率。

误区 5：认为仿真可以完全替代真实数据

仿真很重要，但 simulation gap 长期存在。高质量系统通常是仿真、真实数据、世界模型和在线反馈的组合。

自测问题

读完本章后，应该能回答：

• 世界模型和 LLM 的主要区别是什么？
• 为什么说世界模型不是知识图谱，也不是普通视频生成？
• model-based RL 中的世界模型如何帮助策略学习？
• Dreamer 为什么强调在 latent space 中想象未来？
• Genie、Cosmos、V-JEPA 2分别代表什么路线，动作接口如何区分？
• 具身智能为什么不能只靠 LLM？
• Affordance 如何连接语言计划和物理行动？
• VLA 模型的输入输出是什么？
• 为什么跨 embodiment 数据很重要？
• 如何评估一个家务机器人或自动驾驶世界模型？
• 真实系统为什么需要安全层、仿真和数据飞轮？

仓库机器人的分阶段验收

以下为教学场景与门禁设计，未进行实体设备实验。

场景： 仓库机器人需要识别货箱、规划取放并在人员靠近时停止。视觉/语言模型负责候选物体、任务意图和异常说明；运动规划器、碰撞检测、速度限制和急停回路保持确定性并独立于语言模型。世界模型可用于离线模拟罕见遮挡、抓取失败和路径冲突，但不能成为绕过实体安全互锁的依据。

上线采用分阶段门禁：先离线回放和仿真，再在隔离区域只读观察并记录候选动作，最后才在人工监护和设备许可范围内低速执行。每次动作记录传感器快照、规划版本、模型版本、置信度和安全控制器的拒绝原因；成功率之外，还评估碰撞近失、人工接管率、分布外拒绝率和从仿真到真实的性能落差。

6.9 本章小结

世界模型的核心价值要从预测对象、动作条件和下游决策来判断。隐状态模型可以支持规划或想象学习，视频特征预测可以形成表示，生成式环境可以提供交互研究材料；这些路线的任务、接口和证据不同。VLA把视觉语言能力接到动作，但仍要由身体、感知、控制和安全反馈构成闭环。

对后端工程师，最有用的迁移是状态与预测分开、命令与实际执行分开、模型建议与安全许可分开，以及每一次恢复从新观察的事实出发。仿真与离线分数是阶段性证据，不能替代物理验证；本章架构和案例均为设计说明，不包含机器人上线、安全认证或性能实测。后续章节再把类似的版本、反馈与恢复原则应用于数字Agent系统。

6.10 参考资料

[1] Ha, D., & Schmidhuber, J. World Models. NeurIPS Workshop, 2018. https://arxiv.org/abs/1803.10122 访问日期：2026-10-16

[2] Hafner, D., et al. Learning Latent Dynamics for Planning from Pixels. ICML, 2019. https://arxiv.org/abs/1811.04551 访问日期：2026-10-16

[3] Hafner, D., et al. Dream to Control: Learning Behaviors by Latent Imagination. ICLR, 2020. https://arxiv.org/abs/1912.01603 访问日期：2026-10-16

[4] Hafner, D., et al. Mastering Diverse Domains through World Models. arXiv, 2023. https://arxiv.org/abs/2301.04104 访问日期：2026-10-16

[5] Bengio, Y., Courville, A., & Vincent, P. Representation Learning: A Review and New Perspectives. IEEE TPAMI, 2013. https://arxiv.org/abs/1206.5538 访问日期：2026-10-16

[6] Bruce, J., et al. Genie: Generative Interactive Environments. arXiv, 2024. https://arxiv.org/abs/2402.15391 访问日期：2026-10-16

[7] NVIDIA. Cosmos: World Foundation Model Platform for Physical AI. arXiv, 2025. https://arxiv.org/abs/2501.03575 访问日期：2026-10-16

[8] Bardes, A., et al. Revisiting Feature Prediction for Learning Visual Representations from Video. arXiv, 2024. https://arxiv.org/abs/2404.08471 访问日期：2026-10-16

[9] Assran, M., et al. V-JEPA 2: Self-Supervised Video Models Enable Understanding, Prediction and Planning. arXiv, 2025. https://arxiv.org/abs/2506.09985 访问日期：2026-10-16

[10] Dosovitskiy, A., et al. CARLA: An Open Urban Driving Simulator. CoRL, 2017. https://arxiv.org/abs/1711.03938 访问日期：2026-10-16

[11] Zhang, A., et al. 《动手学深度学习》：序列模型. 中文在线版2.0.0. https://zh.d2l.ai/chapter_recurrent-neural-networks/sequence.html 访问日期：2026-10-16

[12] Yang, S., et al. Learning Interactive Real-World Simulators. arXiv, 2023. https://arxiv.org/abs/2310.06114 访问日期：2026-10-16

[13] Ahn, M., et al. Do As I Can, Not As I Say: Grounding Language in Robotic Affordances. arXiv, 2022. https://arxiv.org/abs/2204.01691 访问日期：2026-10-16

[14] Tobin, J., et al. Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World. arXiv, 2017. https://arxiv.org/abs/1703.06907 访问日期：2026-10-16

[15] Peng, X. B., et al. Sim-to-Real Transfer of Robotic Control with Dynamics Randomization. arXiv, 2017. https://arxiv.org/abs/1710.06537 访问日期：2026-10-16

[16] Tremblay, J., et al. Training Deep Networks with Synthetic Data: Bridging the Reality Gap by Domain Randomization. CVPR Workshops, 2018. https://arxiv.org/abs/1804.06516 访问日期：2026-10-16

[17] Brohan, A., et al. RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. arXiv, 2023. https://arxiv.org/abs/2307.15818 访问日期：2026-10-16

[18] Driess, D., et al. PaLM-E: An Embodied Multimodal Language Model. arXiv, 2023. https://arxiv.org/abs/2303.03378 访问日期：2026-10-16

[19] Open X-Embodiment Collaboration. Open X-Embodiment: Robotic Learning Datasets and RT-X Models. arXiv, 2023. https://arxiv.org/abs/2310.08864 访问日期：2026-10-16

[20] Octo Model Team. Octo: An Open-Source Generalist Robot Policy. arXiv, 2024. https://arxiv.org/abs/2405.12213 访问日期：2026-10-16

[21] Black, K., et al. π0: A Vision-Language-Action Flow Model for General Robot Control. arXiv, 2024. https://arxiv.org/abs/2410.24164 访问日期：2026-10-16

[22] Physical Intelligence. π0.5: A Vision-Language-Action Model with Open-World Generalization. arXiv, 2025. https://arxiv.org/abs/2504.16054 访问日期：2026-10-16

[23] Google DeepMind. Gemini Robotics Brings AI into the Physical World. 2025. https://deepmind.google/blog/gemini-robotics-brings-ai-into-the-physical-world/ 访问日期：2026-10-16

[24] Ahmed, O., et al. CausalWorld: A Robotic Manipulation Benchmark for Causal Structure and Transfer Learning. arXiv:2010.04296, 2020. https://arxiv.org/abs/2010.04296 访问日期：2026-10-16

[25] Ebert, F., et al. Bridge Data: Boosting Generalization of Robotic Skills with Cross-Domain Datasets. RSS, 2022. https://arxiv.org/abs/2109.13396 访问日期：2026-10-16

第7章 AI Infra 全景

前六章讨论了模型如何表示、学习、对齐、推理和适配。本章开始进入大模型 Infra：同一个算法模型，怎样被稳定地训练出来、保存下来、部署出去、服务给用户，并在故障、扩容、升级和成本约束下持续运行。

大模型 Infra 不是“把模型放进一台 GPU 服务器”。它是一条跨越数据、计算、通信、存储、调度、服务、观测和治理的系统链路。训练侧关心有效 token/s、扩展效率、故障恢复和 checkpoint；推理侧关心 TTFT、TPOT、吞吐、KV cache、排队和单位成功成本；平台侧还要处理模型版本、容量预测、租户隔离、权限、审计和回滚。

本章作为第二部分Infra六章的总览（源码继续沿用part1路径），先建立资源模型和系统边界，后续章节再分别深入训练平台、推理服务、数据与评估、持久Agent Runtime以及可靠性与成本治理。算法章节给出的模型结构、并行需求、精度和验证器，是 Infra 的输入契约；Infra 的工作是让这些算法在真实约束下可重复、可观测、可恢复地执行。

7.1 为什么大模型需要独立的 Infra 方法论

从模型文件到生命周期系统

传统后端服务通常把二进制、配置和数据库迁移打包发布。大模型服务的“可运行单元”更复杂：除了权重，还包括 tokenizer、chat template、量化配置、LoRA adapter、视觉预处理、采样参数、工具 schema、验证器、硬件 kernel 和安全策略。训练得到的 checkpoint 只是生命周期中的一个状态，不是可以直接交付的产品。

可以把大模型生命周期表示为：

数据源
  -> 数据清洗与切分
  -> 训练 / 后训练
  -> checkpoint 与评估
  -> 模型注册与转换
  -> 量化 / 编译 / 打包
  -> serving 部署
  -> 线上观测与灰度
  -> 反馈、回滚与再训练

每个箭头都是接口。数据 manifest 不稳定，训练不可复现；checkpoint 不完整，故障无法恢复；模型转换不一致，线上质量会变；服务没有容量指标，流量一升高就排队；没有 trace，模型失败无法归因；没有回滚，任何升级都可能变成事故。

算法与 Infra 的边界

算法层主要回答：模型结构是什么，损失如何定义，数据如何采样，推理策略如何选择，验证器如何判定。Infra 层主要回答：这些计算如何分布到 GPU，如何高效读写和通信，如何在多请求下调度，如何保存和恢复状态，如何对外提供稳定接口。

边界不是绝对的。GQA 会改变 KV cache 大小，FlashAttention 同时涉及算法和 kernel，MoE 路由会影响通信，RLVR 的 verifier 会影响 serving 资源，推理预算会改变排队和成本。因此设计时不能把算法指标和系统指标分开到互不沟通，而要把它们连接成一条可测量的链路。

以下资源账本、状态机、门禁与费用数字均为本书的设计建议或教学假设，不代表来源中的已实现平台。后续章节承担实现细节；本章只冻结跨层输入、输出与可检查边界。

为什么“能跑”远远不够

例如教学场景中，一个训练脚本能在8张GPU上跑通，只能说明功能闭环成立，不能说明系统可扩展。可能存在 GPU 等待、数据加载不足、通信瓶颈、checkpoint 阻塞、故障后无法恢复和成本不可接受等问题。一个推理服务返回了 token，也不代表可上线：它可能首 token 很慢、并发一高就 OOM、长请求饿死短请求、模型升级无法灰度、工具请求没有审计。

大模型 Infra 的验收必须从“功能正确”扩展到五个维度：性能、容量、可靠性、可观测性和治理。Google SRE 方法论把服务目标、错误预算和发布决策联系起来 [1]；大模型系统还要把 token、上下文、模型版本和生成质量纳入同一套服务目标。

7.2 工作负载与资源模型：先算清楚再选组件

训练、推理和数据处理是三种负载

训练是长时间、稳定、高吞吐的批处理负载。它可以容忍单请求高延迟，却不能容忍 GPU 长时间空闲；需要保存中间状态，发生节点故障后要恢复。推理是在线或准在线负载，输入和输出长度差异巨大，重点是延迟、并发、容量和质量稳定。数据处理是 I/O、CPU、网络和存储混合负载，容易成为训练前端的隐形瓶颈。

三者的资源画像不同：

如果用在线 serving 的 QPS 指标衡量训练，就会忽略训练 GPU 是否被通信和数据拖慢；如果只用训练吞吐选推理 GPU，也会忽略单 token 延迟和显存容量。平台设计首先要建立 workload taxonomy，再决定共享集群还是隔离资源池。

参数、激活和状态的内存账本

训练显存不只有模型权重。粗略账本包括参数、梯度、优化器状态、激活、通信 buffer、临时 workspace 和 checkpoint buffer。以 Adam 类优化器为例，参数本身可能以 BF16 保存，梯度和 master weight、动量与方差还需要额外空间；激活随 batch 和 sequence length 增长。ZeRO 通过分片优化器状态、梯度和参数降低单卡冗余 [2]，ZeRO-Infinity 进一步探索 CPU/NVMe offload [3]。

推理显存则主要由权重、KV cache、运行时 workspace 和 batch 中的临时张量组成。对 decoder-only 模型，在常规MHA/GQA、K/V维相同且无特殊压缩时，可按第1章符号用近似式估算一批序列的KV载荷：

\[ M_{KV}\approx 2\times L\times B\times T\times H_{KV}\times d_{head}\times bytes, \]

其中 \(L\) 为层数，\(B\) 为同时驻留的序列数，\(T\) 为每条序列已缓存token数，\(H_{KV}\) 为KV头数，\(d_{head}\)为每头维度，bytes为每元素字节数。这里计算一个批的载荷；单请求取 \(B=1\)，不同长度要逐序列求和。GQA通过减少 \(H_{KV}\) 降低cache压力，但模型结构和质量已经在算法侧决定。Infra 需要把最大长度、并发和精度转换成 admission control 和容量上限。

MoE还要分清总参数与每token激活参数。权重驻留与制品存储通常受总参数、共享层和放置方案约束；每token激活参数可帮助描述参与计算的专家，却不能直接当作全部显存。路由通信、负载偏斜和非专家计算也不能从“激活少”消失。不能拿总参数估每token计算后又拿激活参数估权重内存，混合两种口径会同时高估算力需求与低估驻留成本。

计算、带宽与通信

大模型性能不能只看 FLOPS。训练时需要矩阵乘法，也需要 GPU 之间的 all-reduce、all-gather、reduce-scatter；推理 decode 可能更受显存带宽和 KV 读取限制；数据处理可能受网络和对象存储吞吐限制。NCCL 为 GPU 集合通信提供了高性能 primitives [4]，但应用层仍要正确选择并行维度、通信时机和拓扑。

一个简单判断是：如果 GPU compute 利用率低、网络利用率高，可能是并行切分或 all-reduce 瓶颈；如果 compute 低、显存带宽接近上限，可能是 decode 或小 batch memory-bound；如果 GPU 和网络都低，而 CPU 或对象存储高，说明数据供给是瓶颈。需要同时观察多个层级的指标，不能只看一个 GPU utilization 百分比。

成本单位要与任务结果关联

训练成本可以按每百万有效 token、每个 checkpoint 或每个实验比较；推理成本可以按每百万输入/输出 token、每个成功请求、每个完成任务或每个工具动作比较。对于 reasoning 或 Agent 系统，输出 token 多不一定坏，关键是额外 token 是否带来成功率增益。

建议建立如下成本表：

总成本 = GPU 时间成本
      + CPU / 存储 / 网络成本
      + 评估与人工标注成本
      + 失败重跑成本
      + 线上人工接管成本

单位成功成本 = 总成本 / 通过业务验收的任务数

如果模型吞吐很高但失败率也很高，单位成功成本可能更差；如果低延迟模型需要更多重试，p99 流量下的总成本可能超过慢但稳定的模型。Infra 评审必须把资源指标和质量、成功率、人工修复连接起来。

7.3 分布式训练：从单卡程序到 GPU 集群

数据并行

数据并行把不同 batch 分配给不同 GPU，每张卡保存完整模型副本，反向后通过 all-reduce 同步梯度。它适合模型能放进单卡、通信带宽足够的场景；中文多GPU教材可用于复习副本、样本切分与梯度聚合的基础 [5]。模型越大，单卡越放不下；batch 越小，梯度同步相对成本越高。经典大规模训练系统会把 data parallel 与 tensor/pipeline parallel 组合使用 [6][7]。

张量并行

张量并行把矩阵乘法切分到多张 GPU，例如按 hidden dimension 或 attention heads 分片。每层计算过程中需要 collective communication，适合单层矩阵很大、单卡无法容纳的模型。切分粒度必须与 GPU 拓扑匹配：同机 NVLink 的通信延迟和跨节点网络不同，TP degree 过大可能让通信成为主耗时。

流水线并行

流水线并行把不同 Transformer 层放在不同 GPU，输入 micro-batch 依次通过 stage。它减少单卡参数压力，却引入 pipeline bubble 和 stage imbalance。bubble与stage数、micro-batch数量及调度有关；固定全局batch时，减小单个micro-batch可能增加批次数并降低bubble比例，却也可能损害kernel效率。增大单个micro-batch则可能增加激活压力。流水线切分不能只按层数平均，还要考虑不同层的算子、通信和激活成本。

ZeRO、FSDP 与分片状态

ZeRO 将优化器状态、梯度和参数的冗余分片，按阶段逐步降低单卡内存 [2]。PyTorch FSDP 提供 fully sharded data parallel 的实现，把参数、梯度和优化器状态在数据并行组中分片，并在计算前 all-gather、计算后释放或重新分片 [8]。它们的共同代价是通信和调度复杂度上升。

选择 DDP、FSDP、ZeRO 或 Megatron 组合时，需要明确：模型是否能完整驻留、通信拓扑是什么、checkpoint 是否支持、优化器状态如何保存、是否需要 CPU offload，以及训练是否要和推理共享权重格式。没有统一最优方案，只有与模型规模、硬件和故障模型相匹配的方案。

MoE 与专家并行

MoE 通过 router 为每个 token 选择少数专家，参数总量可以大于每个 token 的激活量，但 token 需要在 GPU 间路由。专家负载不均会导致某些 GPU 成为 straggler，在采用容量上限并丢弃溢出的实现中，capacity factor过小可能丢弃token，过大又浪费显存。Infra 需要观测专家负载、token dispatch、通信量、溢出率和路由稳定性。

MoE 的扩展效率不等于 dense 模型的扩展效率。专家并行、数据并行和张量并行组合后，通信拓扑更复杂；容错时一个专家节点故障可能影响全局。训练平台应支持专家负载告警、故障重启和 checkpoint 恢复，不要只看总体 FLOPS。

并行度如何选择

在DP、TP、PP三个轴独立的稠密mesh中，总进程数可写成三者乘积。原Megatron组合研究支持这三个轴的取舍 [7]；下式不是所有框架通用的世界大小公式：

\[ P_{world}=P_{data}\times P_{tensor}\times P_{pipeline}. \]

EP常与DP进程组相互划分或重叠，不能无条件再乘一个专家并行度；应先写清物理rank到各逻辑组的映射，再核对覆盖、重叠与参数副本。每个维度都可能带来通信、显存、调度和可恢复性代价。一个实用的选择顺序是：先让单层和单 stage 放得下，再根据机内拓扑确定 TP，按模型深度和 bubble 选择 PP，剩余 GPU 扩展 DP；MoE 再根据专家数量和路由流量选择 EP。小规模 benchmark 必须测真实拓扑和真实 sequence length，不能用理论计算量外推大集群性能。

集群扩展效率

理想情况下，GPU 数翻倍，吞吐也翻倍；实际扩展效率受到通信、同步、数据读取和尾部 straggler 影响：

\[ E(N)=\frac{throughput(N)}{N\times throughput(1)}. \]

当 \(E(N)\) 随GPU数下降时，继续扩容可能不划算。Megatron-LM 的大规模训练研究展示了模型并行与集群训练如何协同 [6][7]；PaLM 的 Pathways 经验也说明，大规模训练需要统一计算、通信和故障管理 [9]。平台团队应把扩展曲线作为发布门禁：在目标规模上测吞吐、通信比例、checkpoint 时间和节点故障恢复。

数据与训练恢复的接口

数据管线是训练系统的前端

训练 GPU 只在拿到有效 batch 时产生价值。数据管线要完成对象存储读取、解压、解码、去重、tokenization、混合采样、shuffle、packing 和 batch 组装。任何一个环节抖动，都会让 GPU 等待。Spark 等数据处理系统展示了大规模 DAG、分区和容错的基本方法 [10]；大模型训练通常还需要面向 token 的流式和分片设计。

数据管线要区分 raw document、clean document、token shard、packed sample 和 training batch。每一层都有版本和统计：文档数、有效 token、语言比例、平均长度、重复率、过滤率、错误率和采样权重。训练时记录 manifest hash 和 shard 顺序，才能在 checkpoint 恢复时继续得到一致或可解释的样本流。

Shuffle、seed 与数据重复

分布式训练的随机性来自数据顺序、采样器、dropout、kernel 和并行归约。恢复训练时，如果 global step 相同但数据 shard 或随机状态不同，结果可能出现可见差异。严格复现成本很高，但至少要保存 rank 数、epoch、shard cursor、随机种子、采样权重和 tokenizer 版本。

数据重复会浪费训练预算，近重复还会造成评估污染。数据管线应在 shard 生成前去重，并在训练中记录每个数据桶实际消费的 token。若发生数据版本切换，要明确它是继续训练、阶段性配比还是新实验，不能让同一个 checkpoint 名称指向不同 manifest。

Checkpoint 不只是模型权重

一个可恢复 checkpoint 通常包括：模型参数、优化器状态、学习率调度器、梯度 scaler、随机状态、数据游标、训练配置、并行拓扑、tokenizer、数据 manifest、代码版本和评估结果。只保存权重可以做推理，却不能保证从同一个优化状态继续训练。

Checkpoint 保存会产生大量 I/O 和 GPU/CPU 拷贝。可以使用分片、异步写入、增量 checkpoint、对象存储 multipart 和本地缓存，但必须定义一致性：训练进程崩溃时，不能把来自step \(t\)的权重与step \(t-1\)的优化器状态当作同一恢复点。保存过程应有临时前缀、manifest、校验和、完成标志，读取时只选择完整版本。

保存频率与丢失工作量

Checkpoint越频繁，潜在重算量越少，但保存成本更高。若教学假设故障时间在相邻完整快照之间均匀分布、间隔为 \(\tau\)，平均丢失进度约 \(\tau/2\)，另加重启和恢复耗时；不能只用恢复耗时乘故障率表示全部损失。真实故障并不一定独立均匀，异步写入也会延长最后可用快照的年龄，应按第8章定义的完整快照时间线计量。

节点越多、运行时间越长、故障率越高，越应该降低恢复粒度。训练系统还要区分可恢复 checkpoint 和发布 checkpoint：前者服务训练重启，后者经过评估、转换和注册后供推理使用。

断点恢复与弹性训练

集群可能发生 GPU 错误、节点重启、网络分区、文件系统超时或容器驱逐。弹性训练需要决定：故障后等待原节点回来、缩小 world size 继续、替换节点重启，还是回滚到最近 checkpoint。每种策略都会影响优化状态、数据顺序和最终模型。

恢复流程应自动做健康检查：权重校验、optimizer state 校验、数据 shard 可读性、通信组重建、loss sanity check 和短步数回归。恢复后如果 loss 突然跳变，要能定位是数据、随机状态、精度、并行拓扑还是 checkpoint 损坏，而不是让训练静默跑几个小时。

训练数据安全与权限

数据平台必须把训练数据当作高价值资产。对象存储权限、脱敏、密钥扫描、租户隔离、审计和删除机制，不能因为数据进入 GPU 就失去控制。训练日志和样本抽样也可能泄露敏感文本，应限制访问和保留时间。

模型 checkpoint 同样可能包含训练数据记忆和内部能力，下载、复制、转换和发布都需要权限。平台要记录谁创建了 checkpoint、谁下载过、哪个数据版本训练而来，以及是否通过安全评估。模型注册表不是简单文件目录，而是算法、数据和治理元数据的索引。

Kernel、通信与存储的总览

从算子到融合 kernel

Transformer 训练和推理包含 GEMM、attention、normalization、activation、通信和采样等算子。单个算子都正确，不代表组合执行高效：中间张量写入 HBM、kernel launch 次数、非连续 layout 和 padding 都会造成开销。FlashAttention 通过 IO-aware 的 tiling 减少 attention 的 HBM 读写，并保持精确结果 [11]；FlashAttention-2 进一步改善并行和 work partitioning [12]。

工程优化应先用 profiler 找到热点，再决定融合、重排、kernel 替换或模型结构调整。不要为了追求 benchmark 盲目改动算子，尤其要验证不同 sequence length、batch、精度、GPU 架构和边界输入。kernel 变化必须绑定版本和回归集，因为数值微小差异可能在长训练或低精度推理中累积。

集合通信与拓扑

all-reduce 适合同步梯度，all-gather 适合参数分片，reduce-scatter 可把聚合结果直接分片。NCCL 根据 GPU、PCIe、NVLink、InfiniBand 和网卡拓扑选择通信路径 [4]。拓扑探测错误、网卡配置不一致、MTU、拥塞或跨机带宽不足，都会让训练吞吐大幅下降。

性能分析不能只看通信总时长，还要看通信是否与计算重叠、是否被最慢 rank 阻塞、消息大小是否匹配、是否存在热点链路。训练系统应记录每种 collective 的耗时、字节数、调用次数、rank 方差和重试情况。集群变更后必须重新测扩展曲线。

存储层次与数据局部性

大模型平台通常有本地 NVMe、分布式文件系统、对象存储、缓存和 checkpoint 仓库多个层次。数据 shard 频繁读取时，直接访问远端对象存储会放大网络和请求开销；checkpoint 保存时，单个大文件会导致恢复并发不足。应按访问模式设计：热数据放本地或节点缓存，冷数据放对象存储，发布模型放有校验和版本的制品仓库。

缓存不能只看命中率。错误缓存、旧 tokenizer、错误权限或跨租户复用会产生正确性和安全问题。数据缓存的 key 至少包含数据版本、预处理版本和权限范围；模型缓存要包含权重、量化、kernel、模板和 adapter 兼容条件。

精度和数值稳定性

BF16、FP16、FP8、INT8 和 INT4 的选择需要同时考虑硬件支持、训练稳定性、通信量、显存和质量。训练中通常保留必要的高精度 master state，推理中可以使用更低精度但要做校准。混合精度需要监控 overflow、underflow、loss spike、梯度范数和异常 token。

低精度不是全局开关。embedding、归一化、输出层、敏感 attention 或 outlier 通道可能需要更高精度；量化后 kernel 的累加精度也会影响结果。平台应记录精度配置，并让评估系统能够在同一数据集上比较不同精度的质量—成本曲线。

编译、缓存和可重复性

编译、图捕获、kernel autotune与后端制品构建 可以减少运行时开销，但会引入编译时间、shape 约束、设备兼容和缓存失效。Triton官方模型管理文档区分NONE、EXPLICIT和POLL；POLL可能观察到仓库的部分更新，不应把目录轮询当作原子发布。这里引用的是管理边界，不承诺某套引擎版本的完整兼容矩阵 [13]。

编译产物必须绑定模型 hash、GPU 架构、CUDA/driver、输入 shape、精度和算子版本。一个 engine 在 A100 上生成，不能默认在 H100 或不同 driver 上复用。构建过程应可重放，发布前进行冷启动、热启动、最大长度和错误输入测试。

7.4 推理平台与请求调度

Prefill 与 Decode

推理通常分为 prefill 和 decode。Prefill 处理输入 prompt，计算历史 token 的 attention 状态并产生首个 logits；decode 每次生成一个 token，读取历史 KV cache 并追加新 token。Prefill 计算并行度高，通常影响 TTFT；decode 单步计算小、需要反复读权重和 KV，通常影响 TPOT 和并发。

在线服务必须分别测量：

TTFT = request arrival -> first output token
TPOT (N_out > 1) = (last_token_time - first_token_time) / (N_out - 1)
E2E latency = preprocess + queue + prefill + decode + postprocess
goodput = successful requests / time under SLO

TPOT采用首末token之间的平均间隔，不把首token再算进分母；单token输出不定义该值。还应保留逐token间隔与流式停顿，平均TPOT不能反映所有抖动。只报告 tokens/s 容易掩盖排队和尾延迟。一个批处理吞吐很高的服务，可能让短请求等待长 prompt；一个单请求延迟低的服务，可能在并发时显存爆炸。平台要按 workload 分布测 p50、p95、p99 和成功率。

Serving engine 的职责

推理引擎负责模型加载、权重分片、KV cache、batch 调度、sampling、streaming、量化 kernel、prefix cache 和错误处理。vLLM 以 PagedAttention、连续批处理和高效内存管理为核心 [14][15]；Triton在此承担模型仓库与加载管理接口 [13]。它们可能组合使用，不应把“模型服务框架”当成一个单一组件。

服务接口还要处理 tokenizer 版本、chat template、停止词、结构化输出、工具调用、超时、取消和流式断开。客户端取消后是否立刻释放 KV cache，工具调用中断后是否保留上下文，重试是否导致重复副作用，都属于 Infra 的正确性问题。

模型并行和副本扩展

小模型可以单 GPU 部署多个副本，大模型通常需要 tensor parallel 或 pipeline parallel。副本扩展增加吞吐和容灾，但每个副本都占用完整权重或一组分片；模型加载时间和 cache warmup 也会影响扩容速度。路由层要知道副本健康、可用 KV 容量、当前排队和模型版本，不能只按 round-robin 分发。

对于多模型平台，路由还要考虑模型能力、租户、区域、价格、精度和数据驻留。fallback 模型必须经过任务和安全评估，不能在主模型不可用时任意切换到能力不等价的模型。路由决策要写入 trace，便于解释一次请求实际使用了什么模型。

调度、Batching与KV Cache

Continuous Batching

传统 batch 等待一批请求一起开始、一起结束，但生成长度通常差异很大。Orca 提出的 iteration-level scheduling 使请求可以在每个生成迭代加入或退出 batch [16]。Continuous batching 提升了 GPU 利用率，却要求调度器实时管理 prefill、decode、KV 容量、优先级、取消和饥饿。

调度器至少要选择三个对象：本轮处理哪些请求、每个请求分配多少 token、是否允许新请求进入。只按 FIFO 可能让一个超长 prompt 阻塞大量短请求；只按短请求优先可能让长任务饥饿；只追求 batch 最大化可能违反 TTFT SLO。常见策略包括 token budget、deadline、优先级队列、chunked prefill 和公平配额。

PagedAttention 与内存碎片

PagedAttention 把 KV cache 切成固定大小的 block，像虚拟内存一样由引擎管理，不要求每个请求占用连续大块显存 [14]。这减少了外部碎片，支持不同长度请求和动态 batch，也便于 beam 或 prefix 共享。它把 KV cache 从模型内部数组变成平台资源，带来 block 分配、回收、引用计数和 eviction 的系统问题。

KV block 分配要考虑请求取消、生成结束、异常、重试和多租户隔离。若 block 泄漏，服务会逐渐 OOM；若过度回收，重新计算 prefix 会增加 TTFT；若跨请求共享错误，可能泄露上下文。缓存 key 必须由完整 token prefix、模型版本、模板和权限范围组成。

Prefix Cache

系统 prompt、工具 schema、few-shot 示例和长文档前缀经常重复。Prefix cache 可以复用 prefill 产生的 KV，减少重复计算。但只有 token 序列、位置编码、模型版本、模板和权限都一致时才安全。工具 schema 更新、系统提示变化、租户隔离或动态上下文插入都可能使旧 cache 失效。

缓存命中率不是唯一指标。还要测命中带来的 TTFT 降低、cache 内存占用、失效成本、跨模型共享边界和隐私风险。对于高动态请求，强行缓存可能增加管理成本；对于稳定长前缀，多级缓存可能是最有效的优化。

Chunked Prefill 与长请求公平性

长 prompt 的 prefill 可能占据 GPU 多个迭代，阻塞正在 decode 的请求。Sarathi-Serve 通过 chunked prefill 把长 prompt 切成块，与 decode 交错执行，以改善吞吐和延迟权衡 [17]。切块大小决定计算利用率和抢占粒度：太小会增加 launch 与调度开销，太大仍然阻塞 decode。

长请求还要设置 admission control：最大输入 token、最大输出 token、并发占用、租户配额和超时。超过限制时可以拒绝、截断、压缩、转异步队列或路由到低优先级池。重要的是提前拒绝而不是让请求进入后才 OOM。

Prefill/Decode Disaggregation

Prefill 和 decode 的资源画像不同：前者偏计算，后者偏内存带宽和 KV。DistServe 把二者分离到不同资源池，允许分别扩容和优化 SLO [18]。分离带来 KV transfer、网络、状态一致性和调度复杂度，适合流量规模和延迟要求足够大、能够摊平额外通信成本的场景。

设计 disaggregation 时要回答：KV 如何传输和序列化，传输期间请求如何取消，decode 节点如何发现 prefill 已完成，失败时是否重做 prefill，跨机网络是否成为瓶颈。小规模部署不一定值得引入这种复杂度；平台应通过 workload 画像和容量模型证明收益。

7.5 资源调度、隔离与平台化

GPU 资源编排

Kubernetes 可以通过 device plugin 和资源请求调度 GPU [19]，但大模型训练通常还需要拓扑感知、gang scheduling、优先级、抢占、节点健康和本地数据。一个分布式训练 job 需要一组 GPU 同时可用，只有部分资源会导致长期 pending；推理服务可以弹性扩容，但模型加载和 warmup 时间使瞬时扩容不一定及时。

集群调度应区分训练、推理、评估和交互式开发资源池。训练追求长时间稳定和大 gang，推理追求低延迟和滚动升级，评估追求大量可并行任务，开发追求快速反馈。混在同一资源池中，低优先级训练可能抢占在线推理，或交互式任务碎片化大 GPU。

控制面首先要维护的不是“有多少张卡”，而是一份可以结算的资源账本。对训练作业，账本记录请求的 GPU 型号、数量、节点与互联约束、CPU、内存、本地 NVMe、网络、对象存储吞吐、预计运行窗口和 checkpoint 保留期；对推理副本，记录权重、量化格式、batching 参数、并发上限、KV 预算、模型加载时间和可服务 token 速率；对评估与开发任务，记录优先级、可抢占性、数据权限和过期时间。控制面把这些请求转换为 reservation、allocation、usage 和 release 四种事实，而不是只保存一份期望配置。这样才能在节点故障、抢占和用户取消后回答资源是否真正释放。

资源账本必须同时拥有“请求量”和“实耗量”。请求量用于准入与公平：一个八卡训练任务若只申报四卡，就会挤占不属于它的容量；实耗量用于容量与成本：长期低利用率的 reservation 可能需要回收或降级。两者之间的差异不是立即的违规证据，因为模型加载、checkpoint、通信同步和长上下文请求都可能造成短时空闲；但平台应按工作负载类型设定观察窗口和解释码。训练作业可在稳定 step 窗口内评估有效 token/s 和通信等待，推理副本可按长度分桶评估排队、TTFT、TPOT、KV 水位和取消率，不能用一个全局 GPU 利用率阈值处罚所有任务。

拓扑是资源账本的一部分。八张跨机 PCIe GPU 与八张同机高速互联 GPU 在训练、TP 和 MoE 场景中的可用能力不同；同样的显存总量也不能保证模型、激活、优化器状态和通信 buffer 同时放得下。控制面应把 topology class、故障域和网络带宽写入可调度属性，调度器只在兼容集合中做 placement。Borg 对资源分配、优先级和集群效率的讨论 [20] 提供了这一控制逻辑的基本框架；Kubernetes 的资源请求和 device plugin 是执行底座 [19]，但它们不能自动判断一组 GPU 是否满足某种并行策略。

资源生命周期还需要处理“僵尸占用”。worker 已失联、训练进程仍在运行、NCCL communicator 未释放或对象存储上传卡住时，调度器看到的状态可能与真实设备不同。每个 allocation 因而需要 lease、心跳、fencing token 和可验证的释放确认。lease 过期只表示控制面可以开始调查或隔离，不表示可以立刻把同一块 GPU 给另一个高风险任务；执行面必须确认旧进程、容器、挂载和网络身份已经被撤销。对于无法确认的节点，宁可暂时摘除也不要超卖，这与数据库中不把失联锁直接视为已释放是同一种保守性。

资源控制面可以用以下最小状态机表达：

requested -> admitted -> reserved -> allocated -> warming -> serving/running
    -> draining -> released
                     ^
                     | failure, preemption, cancellation, lease expiry

每次迁移带上 actor、policy version、request revision、资源快照和原因。admitted 只表示预算与配额通过；reserved 表示容量在计划窗口被预留；allocated 表示执行面已获得资源；warming 对推理尤其重要，因为权重尚未加载完成时不能把容量当作可服务吞吐；draining 则允许已开始的 decode 或 checkpoint 在 deadline 内收敛。把这些状态显式化，能避免“发布看起来完成、其实新副本还没有健康”或“训练被取消、其实仍在消耗 GPU”的常见误判。

调度公平与容量预留

Borg 等集群管理系统的经验表明，资源调度要同时处理优先级、配额、隔离、故障域和利用率 [20]。大模型平台还要增加显存、模型权重、KV 容量和通信拓扑维度。GPU 数量相同，不同 GPU 型号和互联拓扑的有效容量不同。

容量规划不能只按平均 QPS。要看输入/输出 token 分布、并发峰值、长尾请求、模型路由比例、缓存命中和故障余量。建议建立容量方程：

required capacity
  = peak token rate / sustainable token rate per GPU
  + failover reserve
  + rolling deployment reserve
  + capacity for long-context tail

多租户隔离

多租户模型平台要隔离权重、adapter、KV cache、日志、数据和工具权限。GPU 共享可以提高利用率，但可能造成显存争抢、尾延迟相互影响和数据泄露。租户配额应覆盖并发请求、输入 token、输出 token、模型种类、工具调用和缓存大小。

租户级 trace 和成本归因也很重要。每个请求要带 tenant、project、model、version、route 和 cost center；离线训练要带数据拥有者、实验 ID 和 GPU 预算。没有归因，平台无法回答谁消耗了资源、哪个模型最贵、哪类请求造成排队。

成本归因的粒度应与决策粒度一致。训练的最小归因单元通常是 experiment 或 dataset revision，推理是 request、conversation 或 business operation，Agent 则可能需要延伸到 tool、retry、人工审核和最终 outcome。每个用量事件至少包括 usage id、开始与结束时间、资源类型、租户、项目、成本中心、模型/制品版本、区域、分配方式、计量值、计价规则版本和来源。计量事件要幂等：同一段 GPU 使用、同一组 token 或同一次对象存储写入即使被重复消费，也只能结算一次。账单不是观测 dashboard 的导出，而是独立、可重放的事实流。

“每百万 token 的价格”不足以支撑平台优化。一次请求的真实边际成本可能包含 prefill、decode、KV 驻留、cache miss、路由到更大模型、重试、工具调用、网络出口和人工处理；训练成本还包含空闲 reservation、失败 step、checkpoint、数据读取和评估。较有用的单位是每次成功任务、每个被接受的工单、每个通过的测试或每个有效训练 token 的成本，但这些单位必须同时报告质量和延迟。否则团队可能通过缩短输出、拒绝困难任务或降低验证次数来制造“成本下降”的假象。

为了支持审计，成本链应能从总账一路钻取到单个动作。例如教学假设中一个业务Run的归因成本为12元，其中模型 token 6 元、GPU reservation 分摊 2 元、搜索工具 1 元、重试 1 元、人工批准 2 元；若任务失败，系统还应显示是模型质量、工具故障还是预算策略导致失败。这样，负责人能判断应该调模型路由、修复工具、优化 cache 还是限制输入长度，而不是把所有异常归咎于某个团队。归因也必须支持共享成本：基础模型 warm pool、公共向量索引和观测系统可以按预先公布的规则分摊，不能在月末按临时印象摊派。

多租户隔离的公平不是平均分卡。交互式生产请求通常有严格 deadline，训练可以接受等待但需要连续 gang，评估适合在空档批量填充。控制面可同时采用 hard quota、reservation、借用和回收：hard quota 防止一个租户耗尽集群；reservation 为关键服务保留容量；借用让空闲容量被低优先级任务使用；回收在 reservation 真正需要资源时让可检查点的任务有序退出。借用必须有最大期限、可抢占标记和 checkpoint 协议，不能把“空闲”误解为永久所有权。

公平策略应对外可解释。租户看到 pending 时，应能知道是配额、预算、拓扑、容量、优先级、数据权限还是发布冻结造成，而不是只得到“no GPU”。管理员也应能模拟策略：新增一个八卡训练 job 会影响哪些在线 SLO，允许某租户临时借用会挤掉多少评估，某模型上线后需要多少滚动余量。模拟结果不是承诺，但能把容量争论从头衔和直觉转回显式假设。

发布、灰度与回滚

模型发布包括权重制品、tokenizer、模板、量化 engine、服务配置和评估门禁。灰度可以按租户、区域、请求类型或流量比例进行；影子流量可以只执行推理而不触发副作用工具。发布过程中要监控错误率、质量回归、TTFT、TPOT、OOM、cache 命中和成本。

回滚必须是可执行的状态转换，不是把一个 tag 改回旧值。需要保留旧权重、旧 engine、旧模板、旧 schema、旧路由和旧安全策略，确认旧版本仍能在当前硬件和依赖上启动。每次发布记录变更和指标，便于事故复盘。

发布门禁应把“制品可启动”与“变更可接受”分开。前者验证签名、依赖、权重完整性、tokenizer、模板、量化 engine、模型卡、权限和回滚包；后者验证离线质量、格式兼容、红队与安全评估、容量模型、成本变化、长上下文、故障降级和业务 SLO。只有两类证据都满足，才有资格进入影子和灰度。一个能加载却使结构化输出失效的模型不能发布；一个离线分数提升却让 p99 或成本超过预算的模型也不能直接扩大流量。

灰度门禁应按阶段定义停止条件，而不是只写“观察一段时间”。例如先用录制流量和只读 shadow 验证请求解析、路由和资源画像，再对内部或低风险租户放出有限比例；每阶段比较新旧版本在质量、拒绝率、TTFT、TPOT、OOM、取消率、cache 命中、单位成功任务成本和安全事件上的差异。阈值、统计窗口、owner 和自动/人工处置动作必须在发布前写定。若某项指标越界，系统冻结扩容、保留现场证据并按已验证路径回滚，而不是等待模型团队解释后再决定。

一个成熟的发布控制面还要处理配置组合。模型权重本身可能不变，但 tokenizer、chat template、工具 schema、采样默认值、prefix cache、路由规则、GPU driver 或 kernel 的变化都可能改变用户可见行为。发布单元应因此是不可变 manifest，而不是单一模型 tag：manifest 列出所有输入制品及其 hash、资源配置、评估集版本、批准记录和已知风险。请求 trace 记录实际命中的 manifest，事故发生后才能准确复现；回滚也回滚到经过验证的 manifest，而不是拼凑“看起来相同”的旧配置。

可以把关键决策写成轻量 ADR，避免平台在事故后才追问为什么这样取舍：

ADR 不替代实验数据，但它规定在什么约束下解释实验数据。发布后若观察到闲置成本高于隔离收益，团队可以根据既定重评估条件合并资源池；若发生跨租户 cache 风险，则应立即提高隔离优先级。将获得与牺牲放在同一维度比较，能防止“吞吐提升”掩盖安全、可运维性或恢复能力的下降。

7.6 可靠性、观测与Infra验收

SLO 不只是一条延迟线

在线 LLM 服务的 SLO 至少包括可用性、TTFT、TPOT、完成率、错误率、超时率和质量门禁。对流式请求，“HTTP 200”不代表成功：可能只返回了部分 token、工具调用格式损坏或用户中途取消。对 Agent，最终任务成功和工具状态一致性比单次模型响应更重要。

可以把 SLO 分层：平台层保证服务可用和延迟，模型层保证格式和能力回归，业务层保证任务成功和人工接管率。错误预算用于决定是否继续发布、是否暂停实验、是否把资源投入稳定性。SRE Workbook 提供了服务等级和错误预算的系统方法 [1]。

Metrics、Logs 与 Traces

Metrics 适合时间序列和聚合趋势，logs 记录单次错误与上下文，traces 记录跨服务和跨工具的因果链。Dapper 展示了大规模分布式 tracing 如何把请求在多个服务中的路径串起来 [21]；OpenTelemetry 提供统一的 trace、metric 和 log 语义 [22]；Prometheus 提供指标采集、查询和告警基础 [23]。

大模型 trace 需要额外字段：model、model version、tokenizer、prompt hash、input/output token、TTFT、TPOT、queue time、cache hit、sampling、tool calls、verifier、finish reason、safety decision 和 estimated cost。默认不要记录完整敏感 prompt 和隐私输出；应做脱敏、采样、访问审计和保留时间控制。

观测设计的第一原则是把控制面决定与数据面结果连起来。一次请求的 trace 不能只知道“模型慢”，还要知道它命中了哪个 routing rule、在哪个队列等待、由哪个 scheduler admission、分配了哪种 GPU、是否发生 prefill/decode 迁移、KV 是否因配额被驱逐、以及最终归因到哪个 tenant 和成本中心。没有这些字段，SRE 只能看到症状，平台团队无法判断根因是容量不足、调度不公平、缓存策略、模型版本还是上游输入变化。OpenTelemetry 的统一上下文传播可以承载关联 id [22]，但字段的语义、脱敏范围和基数控制必须由平台契约定义。

指标也要避免两个极端。只记录全局平均值会掩盖长上下文、低频模型、特定区域和单一租户的退化；为每个 request id、prompt 或用户建立指标标签又会导致时序系统失控。正确做法是把高基数事实放 trace 或日志，把可聚合维度放 metrics：例如按模型、版本、长度桶、区域、硬件池、路由原因和结果类别聚合 TTFT、TPOT、完成率、OOM、queue time、cache hit 和成本；对异常样本保留可检索 trace。指标字典应写清名称、单位、分母、窗口、延迟、owner 与允许标签，避免不同 dashboard 用“成功率”指代不同东西。

观测数据本身有成本与风险。全量记录 prompt、输出、工具参数或 KV 事件既昂贵又可能泄露隐私；过度采样又会遗漏罕见故障。平台可采用分层留存：所有安全、失败、超预算、回滚和人工接管事件保留完整受控证据；成功请求保留摘要和少量采样；聚合指标长期保留；原始敏感 artifact 按租户政策加密、最小化访问并设置删除期限。采样规则同样需要版本化，因为若发布后只改变采样率，趋势图可能看似质量下降或上升而实际上只是观测口径变化。

错误预算应连接发布与资源控制。若某模型路由在最近窗口内消耗了 latency 或可用性错误预算，控制面可以冻结扩容、降低其流量、增加可用副本或把新实验转为 shadow；若质量 gate 消耗过快，则应停止灰度，即使基础设施指标健康。SRE Workbook 对错误预算的核心启发是将可靠性目标转换为决策边界 [1]，而不是只在月报中展示一个百分比。对 AI Infra 而言，质量、成本和安全也可以有各自的预算，但它们不能被任意相互抵消：更便宜的模型不能用安全事件换取，吞吐提升也不能抵消结构化输出错误。

故障演练应在控制面与数据面两个层次同时验证。数据面演练包括杀掉副本、注入 OOM、限制对象存储、使 KV transfer 失败和模拟 token 流中断；控制面演练包括错误路由、过期 reservation、计费事件重复、策略服务不可用、发布 manifest 不兼容和区域容量突然下降。每项演练记录检测信号、告警延迟、自动处置、人工升级、恢复时间、丢失或重复的请求、成本上限和剩余风险。容器能自动重启只证明一个局部机制存在，不能证明用户任务、资源账本与发布状态能收敛。

训练观测

训练侧要观测 loss、学习率、梯度范数、吞吐、有效 token、GPU 利用率、显存、通信、数据等待、checkpoint、节点故障和恢复时间。按数据桶、语言、长度和任务分层的 loss，常常比全局平均更早发现数据或能力退化。

训练平台还应生成 experiment manifest，把代码、配置、数据、环境、并行拓扑、随机状态、checkpoint 和评估关联起来。一个 dashboard 只能告诉你当前状态，manifest 才能支持复现、审计和比较。

训练的资源效率也需要与结果绑定。一次训练 run 的 GPU 小时可能因为 batch size、数据等待、通信、重算、checkpoint、节点替换和评估而不同；只比较总 GPU 小时无法区分“更快收敛”与“更快浪费”。报告应同时包含有效 token、有效 step、训练/验证曲线、恢复次数、数据版本、失败原因、最终评估和成本区间。对于可中断或弹性训练，还要记录重新 placement 后的吞吐与数值一致性，避免通过频繁重启把真实的调度碎片隐藏在平均值中。

控制面应把训练作业的最终状态写回制品和成本目录。一个 checkpoint 若没有对应的代码、数据、tokenizer、并行配置、随机状态和评估证据，就不应被当作可发布模型；一个实验若被取消，也应记录取消时已消耗的资源和是否留下可复用 checkpoint。这样，研究团队可以从结果回溯成本与数据，平台团队可以从容量异常回溯具体实验，治理团队可以从制品回溯训练证据。可复现不是单纯的科研习惯，而是让资源、质量和责任能够闭环的系统接口。

推理观测

推理侧不能只看平均 tokens/s。至少需要输入长度分桶、输出长度分桶、并发、队列等待、prefill 时间、decode 时间、KV cache 使用、cache 命中、GPU 显存水位、OOM、取消、重试和路由结果。p99 长请求往往决定用户体验和容量，而不是平均请求。

性能回归要与质量回归同时做。量化后吞吐增加但代码通过率下降，不能算成功；prefix cache 命中后 TTFT 降低但跨租户隔离失败，更不能上线；更激进的 batching 提高平均吞吐但长请求饿死，也不符合 SLO。

故障模型与演练

要提前列出故障：单 GPU、单节点、网络、对象存储、模型加载、KV OOM、kernel crash、tokenizer 不兼容、上游限流、工具超时、checkpoint 损坏和区域不可用。每种故障都要定义检测、降级、重试、隔离、回滚和人工处理。

训练故障可回到最近 checkpoint；推理故障可摘除副本、路由到备用模型或降级为异步；工具故障可返回明确的 partial result；不可重试的副作用动作必须依赖幂等键和状态查询。故障演练要验证恢复时间、丢失请求、数据泄露和成本，不只是看容器能否重启。

Infra 验收清单

交付一个大模型 Infra 平台前，可以用以下清单评审：

资源：模型、激活、KV、optimizer、checkpoint 的内存账本是否清楚？
训练：并行策略、通信拓扑、数据供给、恢复和扩展曲线是否验证？
推理：TTFT、TPOT、吞吐、队列、cache、长上下文和 OOM 是否有指标？
服务：模型版本、模板、量化、adapter、schema 是否作为发布契约？
调度：租户、优先级、配额、拓扑、故障域和滚动发布是否隔离？
观测：metrics、logs、traces 是否能关联一次请求的全链路？
治理：成本、权限、脱敏、审计、灰度、回滚和错误预算是否可执行？

对后端工程师而言，最重要的思维变化是：模型不是一个函数调用，而是一个需要资源、状态和生命周期治理的分布式系统。每一次模型能力提升，都会重新改变显存、网络、调度、评估和成本边界；Infra 的职责不是隐藏这些复杂性，而是把复杂性变成可测量、可控制的接口。

在上线前，可以把“资源与治理”作为独立 gate 来复核。先确认资源账本是否覆盖 reservation、allocation、实际 usage 和释放，是否能解释拓扑与 warmup 造成的差异；再确认成本是否能从租户、项目、模型和请求钻取到 token、GPU、工具与人工；随后确认发布 manifest、评估证据、灰度阈值和回滚包是否一一对应；最后在故障与高峰组合负载下验证租户隔离、错误预算和人工升级。任何一个问题没有证据，都应缩小影响范围而不是扩大流量。

这种 gate 还要求明确责任分工。模型团队对能力、评估集、已知限制和制品签名负责；Infra 团队对调度、容量、路由、计量、隔离和恢复负责；业务团队对成功定义、风险接受和人工路径负责；安全与治理团队对数据、权限、审计和发布政策负责。责任边界并不意味着问题可以被转交：一次发布需要这些 owner 在同一个 manifest 与 ADR 上留下证据。没有 owner 的指标、没有回滚路径的制品、没有成本中心的任务都不应进入生产资源池。

7.7 生命周期、五平面与决策地图

本章只建立总览，不重复第8到第12章的细节。后续章节会分别展开训练作业、推理服务、数据评估、Agent Runtime 和治理控制；这里保留一张跨章节地图，帮助读者在设计评审中判断问题应落在哪一层。

生命周期：从实验到退役

大模型 Infra 的生命周期可以压缩成七个阶段：

数据进入 -> 训练运行 -> 制品注册 -> 推理交付
  -> 评估反馈 -> 运行治理 -> 退役归档

数据进入阶段关注来源、授权、清洗、去重、版本和统计；训练运行阶段关注并行、通信、checkpoint、恢复和成本；制品注册阶段关注权重、tokenizer、模板、量化、adapter、评估和签名；推理交付阶段关注 SLO、KV、batching、路由、隔离和发布；评估反馈阶段关注回归集、judge、线上信号和漂移；运行治理阶段关注安全、审计、灾备、成本和事故；退役归档阶段关注模型下线、数据删除、证据留存和依赖清理。

五个平面

五个平面不是组织架构，而是分析工具。一个线上质量事故可能同时跨越数据平面和推理平面；一次模型升级可能同时影响制品、状态、控制和治理。设计评审要把问题拆到这些平面上，再决定应该修改算法、数据、调度、运行时还是治理策略。

五平面还提供了事故的排查顺序。先确认数据面是否改变了输入分布、权限或版本，再确认计算面是否出现容量、拓扑、通信或存储瓶颈；随后检查状态面中的 checkpoint、KV、请求和幂等是否一致，检查控制面是否做出了预期的 admission、路由、发布和回收决定，最后检查治理面中的阈值、审批、审计和责任是否仍然有效。这个顺序不要求每个事故按线性流程处理，但能防止团队只盯模型输出、忽略让输出进入生产的其它四个边界。

例如某次上线后用户反馈答案截断，数据面可能是新模板增加了隐藏上下文，计算面可能是 KV 容量不足，状态面可能是流式请求在迁移时丢失 offset，控制面可能是路由把长请求送进短请求池，治理面则可能是只设置了平均延迟门槛而没有 completion-rate gate。五个假设需要通过同一条请求的 manifest、trace、资源账本和评估证据来比较。若只因为模型“看起来变差”就回滚权重，既可能错失真正的系统问题，也可能破坏已经修复的质量问题。

决策地图

这张地图还可以成为评审会议的输入模板。每个提案先写出它改变的平面、依赖的事实、失败后由谁检测、如何降级、如何回滚、成本由谁承担，以及需要哪些观测来推翻原假设。比如引入新的 speculative decoding 策略，计算平面要证明吞吐与显存假设，状态平面要说明 draft/target 结果的取消与一致性，控制平面要说明何时启用与禁用，治理平面要说明质量与成本门槛；若这些内容缺失，提案仍是性能实验，不是可交付的平台能力。

跨平面决策也要求避免局部最优。扩大 batch 可能改善计算利用率却伤害状态面的长请求公平；更激进的 prefix cache 可能降低成本却提高隔离风险；更严格的发布 gate 可能提高治理质量却延长紧急修复时间。ADR 应把一致性、可用性、延迟、吞吐、成本、复杂度、可运维性、数据新鲜度、恢复能力和团队负担放在同一张对照表中，并明确哪些损失被接受、哪些由 fallback 缓解、何时重新评估。没有主动承认的牺牲，通常会以线上事故的形式出现。

控制平面本身也必须被当作一个会失败、会滞后的产品，而不是永远正确的裁判。调度器、策略服务、制品目录、配额账本和发布审批分别不可用时，数据平面不能临时依赖模型猜测该做什么。设计应预先规定默认态：已经持有租约的请求在多长时间内可继续，尚未开始的高风险操作是拒绝、排队还是仅允许只读，哪些紧急回滚可以绕过常规队列，以及策略恢复后如何把离线期间的计量、审批和状态变化重新对账。默认态应倾向于收缩权限和影响范围；把旧策略无限期缓存为“正常运行”同样会把过期授权和过度承诺带入事故。

控制权的 owner 也要能随决策阶段转移而不丢失责任。容量负责人可以拥有 admission 阈值，模型 owner 可以拥有质量门禁，业务 owner 可以决定一个降级结果是否可接受，安全 owner 可以冻结某类工具；但任何人都不应单独改写另一个边界的事实。一次策略变更应记录提案人、批准人、执行身份、目标范围、有效期、依赖版本、观测窗口和撤销条件。若某个 owner 不在线，系统应进入预先批准的保守策略或明确升级到值班人，而不是由无审计的管理员临时扩大权限。这样，事故中的快速处置仍然有可追溯的授权链。

重新评估不是等到季度复盘才发生。控制面应把触发条件写成可以观察的信号：实际队列或 KV 水位持续偏离预测、单位成功任务成本越过预算、某个 manifest 的人工接管率上升、跨故障域可用容量低于承诺，或策略服务的模拟结果与真实结果长期不一致。触发后先冻结进一步放量，保留当时的输入画像、策略版本和决策事件，再由对应 owner 判断是修正资源模型、缩小适用租户、回滚策略还是追加容量。恢复原有范围也需要新的证据；不能因为告警消失就自动撤销限制。这个闭环使控制平面不仅能下达决定，也能证明决定仍适用于变化后的负载与风险。

为避免评估只停留在会议纪要，控制面还应把每次决定的反事实写入演练：若不收紧 admission、若继续使用旧路由、若提前解除配额，哪些 SLO、成本或隔离边界会先失效。反事实不要求精确预测事故日期，却要求把可观测指标、阈值和责任人关联起来。之后用真实事件校正这些假设，能够区分策略本身失效、观测缺失与执行未落地三种不同问题，避免团队反复用同一个阈值掩盖不同根因。

7.8 跨章接口与部署决策

工作负载、状态与事实源总图

这张表描述本书接口分工。一个对象存储桶可以同时容纳多类文件，但存储位置相同不意味着语义相同。训练checkpoint保存优化器和采样位置，推理KV是可重算中间值，Runtime checkpoint保存步骤与外部动作关联；不能把三者统一成一个模糊的“缓存恢复”。目录名也不决定书的部分：本章位于part1仅为历史路径身份，阅读上从此进入第二部分Infra；不移动路径、不建立重复版本。

Model Manifest：注册、兼容与失效

Model Manifest是不可变的模型执行包描述。最小字段包括manifest id、基础权重及hash、tokenizer/特殊token、模板、adapter及底座约束、W/A/KV精度、量化配置与布局、运行后端版本、必要预处理、允许输入和输出协议。硬件/上下文/并发限制应来自验证记录，不能写成模型名称推断。训练checkpoint与导出制品是不同的artifact，使用血缘关联，不让同一个URI静默覆盖成另一类文件。

制品注册产生候选状态；评估服务附上Eval Case版本与结果，发布控制面再给批准范围和路由条件。路由只消费已批准的manifest，推理返回实际执行的manifest id；出现hash或模板不匹配时，拒绝加载并保留错误原因。回滚恢复整套依赖，不只恢复权重。第8章负责导出与恢复证据，第9章负责运行兼容，第10章负责质量记录，第12章负责批准、保留和撤销。

资源账本：先有事实再汇总

资源请求给出workload id、租户、优先级、预计长度分布、设备/互联约束与预算；调度回执给出reservation id、allocation id、真实设备和起止时间；用量事件再关联token、GPU时间、存储和失败重算。每个事件要有去重标识和计量规则版本。取消只产生控制意图，实际释放要由执行面确认；设备失联进入隔离或待确认，不凭超时自动把占用清零。

账本查询应把reserved、allocated、live usage和released分别返回，并标明采样时间、延迟和未知部分。容量评估使用可承诺资源，而不是当前空闲数；成本评估同时展示失败与闲置分摊，不能把预留费和实际GPU费重复相加。把账单误差归因到计量延迟、重投递或规则变化，比直接改dashboard总数更可审计。第8/9章分别提供训练与请求计量，第12章定义对账和异常处置。

Eval Case与上线证据：区分假设和结论

Eval Case描述固定输入、授权/环境快照、预期约束、判定器、切片、预算与副作用规则。候选模型、模板或调度策略变化后，评估任务记录实际版本、运行状态、观测结果与判定原因；未完成、超时、基础设施错误、模型错误、业务失败和未知外部结果应区分。第10章再定义完整记录，后续章引用这一契约，不把服务测试case当作线上业务已经成功。

发布请求至少引用manifest、资源画像、case集、质量/延迟/成本门槛与回滚版本。若质量达标但目标负载资源不够，应缩小范围、排队或重新选型；若容量达标但权限或质量失败，则暂停发布。缺少某类证据时，系统不能通过省略这一类评估制造绿色状态。所有门槛都记录owner、到期时间与复核条件，避免一次获批无限续用。

自托管、外部API与混合部署

先按数据分级澄清传输、留存、访问、部署区域和审计要求，再判断哪些候选允许接触相应输入。自托管增加硬件、模型加载、Serving升级、补丁、值守与事故责任，不自动等同安全；外部API减少部分运维负担，却引入配额、网络、供应商变更与留存契约。未经独立核验，不能把某家API的宣传写成默认数据保证。

对峰谷明显的企业任务，在相同质量和延迟目标下比较总拥有成本：基础预留与闲置、峰值冗余、冷启动、模型分发、缓存、网络、失败重试、人工值守，以及排队超时损失。外部方案还比较峰值配额是否可兑现、可接受输入的最小化与跨区费用；不能只把token单价与GPU标价相除。混合方案可按敏感级别或任务类型路由，回退候选也必须满足原权限和数据边界，不能因为本地故障把受限材料外发。

本书建议把决策记录为：允许的任务和数据范围、同负载基线、容量与费用假设、所选路线、主动承担的运维或依赖成本、失败时缩小服务的方式，以及重新评估触发条件。利用率低但峰值排队严重时，先对照预留与启动时间，再决定购买峰值、引入允许的API补峰或改异步，不能只用平均利用率要求减卡。这里给出比较方法，尚无实际价格、压测或供应商合同结论。

7.9 本章小结：把复杂度变成契约

AI Infra 的核心能力不是堆叠组件，而是把算法复杂度转化为资源契约、状态契约、质量契约和治理契约。资源契约说明模型在不同长度、并发和硬件下需要多少计算、显存、网络与存储；状态契约说明请求、KV、checkpoint、数据游标和工具操作如何创建、恢复、过期与回滚；质量契约说明模型升级、量化、kernel、调度和降级对输出质量与用户任务的影响；治理契约说明谁批准、谁负责、证据保存在哪里。

后续第8到第12章会沿着这张地图逐层展开。读者不必先记住所有组件名称，但应始终追问同一个问题：这个算法或平台选择改变了哪项资源、状态、质量或治理约束，系统用什么证据证明它在真实负载下仍然成立？

最终，AI Infra 的可靠性来自可执行的闭环：工作负载进入时有资源与权限准入，执行时有状态、隔离与观测，结果产生后有质量、成本和责任归因，变更发生时有分阶段门禁与可验证回滚，故障出现时有已知的恢复与人工路径。把这些环节拆成组件很容易，把它们通过同一套 identity、manifest、事件和证据连接起来才是平台设计的难点。只有当资源消耗、模型版本、业务 outcome 与风险处置能在同一条链路上被解释时，团队才真正拥有可扩展的 AI Infra，而不仅是一组能够运行的 GPU 服务。

7.10 参考资料

[1] Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. https://sre.google/workbook/implementing-slos/ 核验日期：2026-10-17

[2] Rajbhandari, S., et al. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. SC, 2020. https://arxiv.org/abs/1910.02054 访问日期：2026-10-17

[3] Rajbhandari, S., et al. ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning. SC, 2021. https://arxiv.org/abs/2104.07857 访问日期：2026-10-17

[4] NVIDIA. NCCL: Collective Operations. 2.32.3文档，核验2026-10-17. https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html

[5] 张阿斯顿、李沐等. 《动手学深度学习》：12.5多GPU训练. 中文在线2.0.0，核验2026-10-17. https://zh.d2l.ai/chapter_computational-performance/multiple-gpus.html

[6] Shoeybi, M., et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv, 2019. https://arxiv.org/abs/1909.08053 访问日期：2026-10-17

[7] Narayanan, D., et al. Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM. arXiv, 2021. https://arxiv.org/abs/2104.04473 访问日期：2026-10-17

[8] Zhao, Y., et al. PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel. arXiv v2, 2023. https://arxiv.org/abs/2304.11277 核验日期：2026-10-17

[9] Chowdhery, A., et al. PaLM: Scaling Language Modeling with Pathways. arXiv, 2022. https://arxiv.org/abs/2204.02311 访问日期：2026-10-17

[10] Zaharia, M., et al. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. NSDI, 2012. https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/zaharia 访问日期：2026-10-17

[11] Dao, T., et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS, 2022. https://arxiv.org/abs/2205.14135 访问日期：2026-10-17

[12] Dao, T. FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning. ICLR, 2024. https://arxiv.org/abs/2307.08691 访问日期：2026-10-17

[13] NVIDIA. Triton Inference Server: Model Management. 在线文档，核验2026-10-17. https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_management.html

[14] Kwon, W., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP, 2023. https://arxiv.org/abs/2309.06180 访问日期：2026-10-17

[15] vLLM Team. vLLM Documentation and Source Repository. https://github.com/vllm-project/vllm 访问日期：2026-10-17

[16] Yu, G.-I., et al. Orca: A Distributed Serving System for Transformer-Based Generative Models. OSDI, 2022. https://www.usenix.org/conference/osdi22/presentation/yu 访问日期：2026-10-17

[17] Agrawal, A., et al. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve. OSDI, 2024. https://www.usenix.org/conference/osdi24/presentation/agrawal 访问日期：2026-10-17

[18] Zhong, Y., et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. OSDI, 2024. https://arxiv.org/abs/2401.09670 核验日期：2026-10-17

[19] Kubernetes. Schedule GPUs. https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ 访问日期：2026-10-17

[20] Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ 访问日期：2026-10-17

[21] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[22] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[23] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

第8章 训练平台与数据管线

上一章建立了大模型 Infra 的全局资源模型。本章聚焦训练阶段：如何把海量数据稳定地送到 GPU，如何选择数据并行、张量并行、流水线并行和专家并行，如何让通信与计算重叠，以及如何在节点故障、版本变化和硬件变化后恢复到一个可解释的训练状态。对于后端工程师，训练平台可以理解为一个持续运行很久、拥有复杂状态、对吞吐极其敏感的分布式任务系统。

训练 Infra 的目标不是让脚本在一台机器上运行，而是让“有效 token 数/时间”可预测、可扩展、可恢复。一个训练 step 的耗时可以拆成数据读取、host 到 device 拷贝、forward、backward、梯度同步、optimizer update和checkpoint；可重叠阶段不能把区间简单相加当wall time。任何阶段成为瓶颈，继续增加 GPU 都只会增加成本。Megatron-LM 的模型并行研究、DeepSpeed 与 ZeRO 的状态分片，以及 PyTorch FSDP 的工程实现，都说明大模型训练本质上是模型状态、通信拓扑和故障恢复共同决定的系统问题 [1][2][3][4]。

下文平台对象、数据接口、快照发布和故障矩阵为本书的教学设计；引用支持所列机制，不代表已运行该平台或验证目标规模性能。

本章按训练作业生命周期组织：先定义作业对象和控制面，再让数据以可复现方式进入 GPU，随后选择并行策略和 kernel/通信优化，接着用 checkpoint 与弹性恢复保护长时间运行，最后用调度、成本、观测和发布门禁把训练结果转换成可交付制品。

8.1 作业对象、控制面与训练生命周期

从训练脚本到训练作业

训练脚本只描述计算图，而平台还要管理 job、experiment、run、checkpoint、dataset、artifact 和 allocation。experiment 表示一个研究问题，run 是一次具体配置执行，allocation 表示实际申请到的节点与 GPU，checkpoint 是某个逻辑 step 的可恢复状态。若这几个概念都用一个目录名代替，稍后就无法回答“这个模型由哪个数据版本训练、失败重试了几次、最终使用了哪些 GPU”。

训练控制面应维护一份不可变的 job spec，至少包括模型代码版本、tokenizer、数据 manifest、采样权重、global batch、sequence length、优化器、精度、随机种子、并行度、容器镜像、依赖锁定文件、checkpoint 策略和预算。提交时生成 job_id 与 spec hash；相同 hash 的重试可以复用实验身份，但不应覆盖已有 run。这些配置变更应有新spec与执行记录；平台若允许同一run内阶段变更，也要有显式版本事件，不能静默覆盖。

Ray 把任务执行、资源声明和分布式运行时分开，为控制面设计提供了有用的抽象 [5]。Kubernetes 的 GPU device plugin 可作为资源分配基础，但训练平台还要补充 gang scheduling、拓扑亲和性、节点健康和优先级 [6]。Borg 的实践说明，配额、优先级、抢占和故障域不应由每个任务自己实现，而应由集群控制面统一管理 [7]。

控制面与数据面的边界

控制面负责提交、排队、分配、启动、心跳、停止、重试、恢复和归档；数据面负责 batch 生成、forward、backward、通信和状态写入。控制面需要幂等与可审计，数据面需要低延迟与高吞吐。用户重复提交相同 idempotency key 时，控制面应返回已有 job，而不是再次申请一组 GPU；worker失联时lease/heartbeat只能触发调查；资源重授前还需确认旧执行已停止或被fence，不能把租约过期等同设备已释放。

控制面不能把所有运行时细节写进数据库事务。一个训练 step 可能持续数秒，checkpoint 可能持续数分钟，控制面应通过事件记录阶段和状态，而不是长时间持有锁。推荐的状态包括 CREATED、QUEUED、ALLOCATING、STARTING、RUNNING、CHECKPOINTING、RECOVERING、SUCCEEDED、FAILED、CANCELLED。状态迁移需要校验前置状态，重复的完成事件必须幂等，旧 worker 迟到的心跳不能把已经回收的作业改回 RUNNING。

训练运行时的身份与配置

每个 rank 都要知道 global rank、local rank、world size、node rank、数据分片范围和通信组。配置不能只依赖环境变量，因为环境变量容易在重试或跨集群迁移中变化。平台应生成一个 rank manifest，记录 rank 到节点、GPU、网卡和并行维度的映射，并将它与 checkpoint 和性能报告关联。

运行时配置要区分用户意图和平台推导值。用户声明 global batch、目标 sequence length 和模型并行上限，平台推导 micro-batch、gradient accumulation、通信组和数据 worker 数。推导过程应可解释：为什么某个 batch 被降低，为什么 tensor parallel 只能取 8，为什么某个节点被排除。否则调度器虽然自动化，却让训练结果变得不可理解。

训练 Infra 的安全边界

训练集群通常拥有高权限网络、对象存储和 GPU，容器中的任意代码都可能读取不该读取的数据。镜像要签名、依赖要锁定、网络要按任务隔离，worker 使用短期凭证，checkpoint 和日志加密。开发者调试权限与生产训练权限分离，禁止通过挂载宿主机路径绕过数据控制。任何访问数据、下载 checkpoint、修改 job spec 和改变发布状态的动作都要有审计。

模型和数据的安全还要覆盖供应链。外部模型、tokenizer、预训练数据、量化工具和 kernel 都可能带来恶意代码或不兼容行为。构建阶段扫描依赖、固定来源和生成 SBOM；运行阶段限制网络和文件系统；发布阶段校验 artifact hash。安全检查不能只在平台上线时做一次，因为模型和依赖会持续更新。

8.2 数据供给与有效训练信号

数据的分层与版本

数据不应直接从原始文档流入 GPU。常见分层是 raw document、clean document、deduplicated corpus、token shard、packed sample 和 batch。raw 层保留来源与授权信息；clean 层完成编码、语言识别、格式过滤和敏感信息处理；deduplicated 层处理精确与近似重复；token shard 适合高吞吐读取；packed sample 负责把多个短样本拼成固定窗口；batch 则绑定某个 run 的 seed 和采样策略。

每一层都应有 manifest、schema、统计和 hash。统计至少包含文档数、有效 token、语言比例、长度分布、重复率、过滤率、错误率和采样权重。数据版本变化不能只改一个路径名，因为路径可能指向可变对象存储。训练 job 保存 manifest hash 后，任何人都能重新定位具体 shard；数据删除或授权撤回时，也能找到受影响的 run。

数据清洗与去重的系统代价

清洗规则会影响质量、数据量和训练成本。过强过滤可能丢失少数语言、代码和长文档；过弱过滤会引入乱码、模板重复、广告和隐私。去重也不是只做整文档 hash：同一网页的导航、模板、转录和代码片段可能构成近重复，需要在 token n-gram、文档 embedding 或 MinHash 层面建立策略。不同数据源的去重阈值应记录在 manifest，而不是藏在一次性脚本里。

数据质量检查可以在写入 token shard 前做，也可以在训练时抽样做。前者节省训练资源，后者能发现分片损坏和分布漂移。建议把抽样样本的统计摘要写入训练报告，原始内容只在有权限的调试流程中访问。数据处理应有失败隔离：一个坏 shard 进入 quarantine，不应让整个预处理 DAG 重做。RDD 提出的分区、血缘和容错思想可用于理解这种数据层设计 [8]。

读取路径与预取

GPU 训练的读取路径通常经过对象存储或分布式文件系统、节点缓存、CPU 内存、Pinned Memory 和 GPU 显存。每一层都要明确缓存大小、并发、超时和失败策略。直接从远端对象存储读取小文件会产生过多请求；把所有 token shard 复制到每台节点又会放大存储成本。更合理的方案是大 shard、顺序读取、节点级缓存和有限的预取队列。

预取深度要由实测决定。队列太浅，网络抖动会直接暴露到 GPU；队列太深，会占用 CPU 内存并把错误延迟到很久以后。数据 worker 应暴露等待时间、读取吞吐、解压时间、队列长度、坏样本数和重试次数。训练 worker 应能区分“没有数据”“数据损坏”“数据服务超时”和“GPU 处理慢”，否则所有问题都会被归类为 GPU 利用率下降。

Packing、padding 与有效 token

固定 sequence length 便于 kernel 和 batch，但短样本 padding 会浪费计算。packing 可以把多个样本拼进一个窗口，提高有效 token 比例，却要求保存样本边界、attention mask 和 loss mask。若样本跨窗口被截断，还要明确是否允许跨样本上下文。训练报告不应只记录 token 数，应同时记录 padded token、有效 token 和 loss token。

有效 token/s 是训练 Infra 的重要指标：

effective_tokens_per_second
  = loss_tokens / wall_clock_seconds

如果一个优化把 padding 降低但引入复杂的数据准备，它可能提高理论有效率却降低真实吞吐。评估时要同时展示 device tokens/s、loss tokens/s、GPU busy 和数据等待占比。PaLM 与 Llama 3 的规模化训练经验说明，数据配方、训练时间和系统吞吐必须共同考虑，不能只看模型参数量 [9][10]。

训练数据不是普通消息队列

把数据管线简单理解为“从存储读取消息”会遗漏训练语义。消息队列通常关心至少一次、至多一次或恰好一次消费；训练还要关心样本顺序、采样权重、样本边界、token 数和 epoch 定义。一个 batch 被消费后，worker 崩溃并重放它，计算结果可能不同，因为 dropout、混合精度和并行归约都可能变化。平台需要先定义业务可接受的语义：预训练可以容忍少量重复，监督微调可能要求样本不重复，对齐数据则可能需要精确记录每次消费。

数据服务应使用不可变 shard 和可定位游标。游标不应只表示第几个 batch，因为 worker 数、packing 策略和 shard 版本变化会使 batch 编号失去意义。更稳妥的游标包括 manifest hash、shard id、sample offset、token offset、packing 状态和采样器状态。恢复时如果这些字段与当前运行时不兼容，要明确走 reshard、重放或拒绝恢复，而不是静默从最近位置开始。

混合数据配方

预训练通常混合网页、代码、书籍、论文、对话和多语言数据。混合比例可以按文档数、字节、token 或有效 loss token 定义，四种定义结果不同。平台应把权重归一化过程写进 manifest，并在运行中统计实际消费比例。若代码样本平均更长，按文档数设置 20% 并不等于按 token 得到 20%；若大量样本被过滤或截断，声明配方与真实训练配方可能相差很大。

采样器还要处理数据源耗尽、动态增量和阶段切换。一个数据桶耗尽后，是循环采样、重新归一化还是提前结束 epoch，必须有明确策略。数据版本切换时，可以从某个 global step 开始使用新权重，但要把切换事件写入 trace 和 checkpoint。否则训练损失曲线的变化无法解释，出现质量回退时也无法定位是模型代码还是数据配方引起。

评估数据隔离

训练、验证和测试数据需要物理或逻辑隔离。去重系统如果只在训练集内部工作，可能把评估集内容保留在训练数据中；如果把所有数据一起去重，又可能泄露测试集的存在和分布。数据 manifest 应记录 split 生成规则、去重边界和时间版本。评估服务读取只读版本，不应让训练 worker 获得写权限。

评估结果要绑定 checkpoint、数据版本、采样配置和代码版本。在线 dashboard 中只显示一个“验证集 loss”很容易把不同实验混在一起。对于长周期训练，建议定期保存小型固定 probe 集和较大的正式评估集：probe 用于快速检测 loss、格式和数值异常，正式集用于能力、偏差和安全门禁。两者都不能被训练程序修改。

训练数据的访问控制实现

数据访问控制要覆盖控制面和数据面。控制面在创建 job 时校验项目、用途、数据 license、地域和保留期限；数据面在 worker 获取 shard 时发放短期、最小范围的凭证。凭证不应允许列出整个 bucket，也不应允许 worker 将训练数据写回原始路径。对象存储、缓存和本地临时目录的权限要保持一致，任务结束后回收临时凭证并清理不再需要的缓存。

训练日志常常包含样本文本、异常 token 和模型输出，必须按照数据等级处理。默认记录 hash、长度、语言和错误类型；完整文本只在经过授权的诊断任务中短暂保存。将 prompt 或样本直接作为 metric label 更危险，会造成高基数、日志泄露和成本膨胀。观测字段应有允许列表、脱敏器和保留策略，OpenTelemetry 的统一上下文只能解决关联问题，不能替代隐私控制 [11]。

数据漂移与训练漂移

数据管线在长周期训练中可能发生漂移：上游抓取站点变化、语言比例变化、过滤规则更新、代码仓库增加或某个数据源失效。平台应按时间窗口统计有效 token、语言、长度、来源、重复率和过滤率，并与 job spec 中的目标配方比较。偏差超过阈值时，可以暂停消费、重新生成 shard 或标记为新阶段，不应让训练静默改变分布。

训练指标也会漂移。全局 loss 下降不代表每种语言、代码、长文档和少数任务都改善。将 loss 按数据桶和长度分层，可以发现某个源异常、padding 变多或 tokenizer 处理错误。固定 probe 集用于检测运行时变化，分层正式评估用于决定是否继续训练；两者都需要与 checkpoint 版本绑定。

数据处理 DAG 的重试边界

预处理往往是一个包含下载、解析、过滤、去重、分词、分片和统计的 DAG。每个节点都应有输入版本、输出版本、执行镜像、参数和结果 manifest。失败时只重试失败分区，不重做已经完成且校验通过的分区；上游输出发生变化时，通过血缘关系确定哪些下游需要失效。Spark 的 RDD 和分区容错思想说明，数据处理的可靠性来自可重建的中间结果与明确的血缘，而不是依赖某个常驻进程 [8]。

重试要区分确定性错误和瞬时错误。对象存储超时、节点暂时不可用可以退避；解析器遇到未知编码、schema 不匹配或越过内存上限，应隔离样本并记录原因。无限重试会掩盖坏数据并持续消耗配额。每个分区应有最大重试次数、错误样本上限和 quarantine 路径，数据负责人可以在不影响其他分区的情况下修复并重新运行。

Tokenizer 的版本契约

tokenizer 不是训练前的普通工具，而是决定样本长度、词表、特殊 token、padding、截断和模型输入的运行时契约。升级 tokenizer 会改变有效 token 数、sequence packing、embedding shape 和训练成本。job spec 必须保存 tokenizer 文件或不可变 artifact hash、normalization 规则、special token、chat template 和最大长度。checkpoint 恢复时如果 tokenizer 不一致，应明确拒绝或执行经过验证的迁移。

tokenizer 处理异常字符时要有统计。未知字符、超长 Unicode 序列、二进制内容、空样本和控制字符都可能造成 token 爆炸或 loss 异常。数据质量报告应包含字符到 token 的膨胀比例，并按语言、数据源和长度分桶。对代码、多语言和数学公式，通用过滤器可能误删重要信息，训练 Infra 需要把这些边界交给数据和算法团队共同确认。

8.3 并行策略与资源账本

中文多GPU教材可用于复习复制参数、分割样本和聚合梯度的基础 [12]。

数据并行与梯度同步

数据并行让每个 rank 持有模型副本，处理不同 micro-batch，然后通过 all-reduce 同步梯度。它实现简单、扩展直接，但完整复制参数、梯度和 optimizer state 的内存成本很高。随着模型变大，单纯增加数据并行 rank 会先遇到单卡显存上限，再遇到梯度同步和小 batch 的效率问题。

在各rank微批大小相同且无不齐尾批时，样本global batch=每rank micro-batch×DP度×梯度累积步数；packing下还需单独统计loss token，不能把样本公式直接当token批量。改变任何一个因素都可能改变优化轨迹。平台必须记录真实的 global batch 和每步有效 token，而不是只记录 dataloader batch size。NCCL 的 all-reduce 适合梯度聚合，但通信是否能与 backward 重叠，取决于 bucket 大小、梯度 ready 顺序和拓扑 [13]。

张量并行与流水线并行

张量并行把单个线性层或 attention 的矩阵切到多个 GPU，单层计算需要 collective 通信。它适合高速互联的同机 GPU，tensor parallel degree 通常受 NVLink、PCIe 和显存约束。Megatron-LM 通过对 Transformer 层做模型并行，使单卡无法容纳的模型能够训练 [1]。但 TP 越大，每个 token 的通信次数和同步敏感性也越高。

流水线并行把不同层放到不同 stage，输入 micro-batch 依次通过 stage。它减少单卡参数占用，却产生 pipeline bubble、调度复杂度和 stage 不均衡。非交错1F1B主要改变激活驻留和调度；不能仅凭名称保证比其他同类流水线调度具有更少bubble。最长stage仍可能限制全局吞吐。层划分应考虑参数、激活、通信和 kernel 时间，而不是简单平均层数。若某些层因 MoE 或视觉模块更重，静态平均会造成严重 straggler。

ZeRO 与 FSDP

ZeRO 逐步分片 optimizer state、gradient 和 parameter，减少每个 rank 的冗余；FSDP 在 PyTorch 中以参数分片、all-gather 和 reduce-scatter 实现类似目标 [2][4]。分片让模型能在更少的显存中训练，却把参数获取和释放加入了关键路径。正确选择需要测量通信与计算重叠、参数 prefetch、CPU offload 和 activation checkpoint 的组合。

ZeRO-Infinity 进一步利用 CPU 和 NVMe 扩展可用内存 [14]。卸载能解决容量问题，但 PCIe、NVMe 和网络带宽可能使 step 时间显著增加。平台不能把“能启动”当作成功，而应比较每百万有效 token 的成本、恢复时间和尾部抖动。对低利用率实验，offload 可能比增加 GPU 更经济；对大规模生产训练，它可能成为不可接受的同步瓶颈。

MoE 与专家并行

MoE 用路由器把 token 分发到少数专家，激活参数少于总参数。GShard 和 Switch Transformer 展示了稀疏专家模型的扩展方式 [15][16]。Infra 需要处理 token dispatch、专家容量、all-to-all 通信、负载不均衡和 token drop。专家数增加并不自动提高效率；如果路由把大部分 token 集中到少数专家，热门 expert 成为瓶颈，其他 GPU 却空闲。

专家并行的容量因子决定每个 expert 能接收多少 token。在丢弃溢出token的实现中，容量太小可能丢token，容量太大则浪费显存并增加通信。训练平台要记录每个 expert 的 token 数、溢出率、路由熵、all-to-all 时间和 rank 方差。MoE checkpoint 还要保存专家布局和路由相关配置，不能只保存最终权重，否则恢复时的并行映射可能不一致。

并行度搜索

并行度选择可以视为约束优化。先满足单层参数和激活能放入显存，再在目标拓扑上选择 TP；根据层数和 bubble 选择 PP；剩余 GPU 用 DP 扩展吞吐；MoE 再选择 EP。每个候选组合都需要小规模真实 workload 测试，测量 step time、通信比例、显存峰值和扩展效率。理论 FLOPs 只能给出上界，不能替代实测。

并行配置一旦写入 checkpoint，就成为恢复契约的一部分。支持 reshard 的平台应保存逻辑参数名、分片范围和布局版本，恢复时由转换器生成新的 shard；不支持 reshard 时，应让调度器保证相同的 world size 和并行度。静默改变并行配置会让 optimizer state 与参数分片错位，是最危险的恢复错误之一。

显存账本：分片状态与瞬时峰值

ZeRO阶段1、2、3分别进一步分片优化器状态、梯度和参数。[2] 下表固定教学假设：共有P个参数，参数与梯度各2字节，FP32 master和两个Adam moment共12字节；D为相应DP组大小，不计激活、临时聚合及额外副本。不同优化器和实现的字节口径必须重算。

这是模型状态的理想载荷，不是GPU峰值。前向获取完整层、预取下一层、通信bucket、激活重算、allocator保留和CPU staging都可能同时存活，不能把ZeRO-3式子当申请显存的总上限。offload改变状态位置，activation checkpoint改变激活保存，两者与ZeRO阶段是不同开关；FSDP也要按其策略与预取配置解释峰值。[14][4]

3D、sequence与context的切分轴

本章3D明确指DP×TP×PP，在独立mesh的教学布局中world size为三者乘积。逻辑坐标(d,p,t)先映射到物理rank：同一d/p下沿t通信，同一p/t下沿d同步样本梯度，同一d/t下沿p传阶段边界；实际顺序由启动器保存，不从rank号猜测。EP若划分已有DP组，不能再独立乘一次。DeepSpeed官方3D说明与Megatron组合研究是这种分工的实例 [3][17]，不能据此推断任一版本任意组合都可用。

Megatron式sequence parallel沿序列维拆分部分层归一化/dropout激活，配合TP组内all-gather/reduce-scatter降低激活冗余。[18] context parallel则把注意力的长序列分给多rank，仍需交换跨片KV或等价信息；Ring Attention展示分块环式交换与计算重叠的研究路线。[19] 两者不是“各算自己的局部attention再拼接”；那会漏掉跨片键值并改变softmax分母。位置、因果mask、变长尾片和反向梯度都需要与未分片参考核对。

流水线也不能按卡数均分显存。Embedding、输出头、MoE层、视觉模块和权重共享会改变参数与计算；不同stage未反向的micro-batch数决定激活峰值。固定全局batch时，调小micro-batch会改变累积次数和kernel效率；不能只看泡泡比率选择。先逐stage报告前后向、等待与峰值，再比较切层、虚拟stage、重算和调度，避免把最快stage的数据当全局吞吐。

集合通信的元素语义与字节账本

NCCL定义上述基本数据交换；算法并不与某一原语一一固定绑定。[13] 本书假设ring all-reduce、D个rank、每rank完整梯度载荷G字节且均匀分块：reduce-scatter和all-gather阶段每rank各发送约 \((D-1)G/D\)，总发送约 \(2(D-1)G/D\)；接收量另计。两阶段各有D-1轮，粗略时间模型为 \(2(D-1)\alpha+2(D-1)G/(D\beta)\)，其中alpha为每轮启动延迟，beta为所用有效链路带宽。D=1时通信为零；这是假设ring账本，不是所有NCCL算法的预测器。

TP/FSDP要数层级collective次数，PP要数边界激活与梯度，EP要按实际token去向计算发送矩阵。重叠可能隐藏通信等待，却不会消除字节和buffer；故障、重试与未均匀消息也会改变总量。把理论账本与profile差值解释清楚，才能区分小消息延迟、带宽饱和、重复collective和rank迟到。

8.4 Kernel、通信与数值稳定性

从 FLOPs 到 IO

Transformer 训练不是只受 FLOPs 限制。中间张量写入 HBM、kernel launch、非连续 layout、padding 和同步都可能成为瓶颈。FlashAttention 用 IO-aware tiling 降低 attention 的 HBM 读写，并保持精确计算 [20]；FlashAttention-2 进一步改善并行和 work partitioning [21]。采用新 kernel 时，要验证端到端 step、显存峰值、不同长度、不同 batch、不同 GPU 架构和数值误差。

优化应遵循基线—假设—变更—测量—回滚链路。先用 profiler 找到热点，再决定融合、重排、编译、量化或缓存。一个 kernel benchmark 提速，不代表真实训练提速；它可能把瓶颈转移到通信或数据处理。性能结果必须与模型版本、输入 shape、CUDA、driver、编译器和环境变量绑定。

集合通信与拓扑

all-reduce 用于同步梯度，all-gather 用于取得分片参数，reduce-scatter 可把聚合结果直接保留为分片。NCCL 会根据 NVLink、PCIe、InfiniBand 和网卡拓扑选择通信路径 [13]。训练平台应保存拓扑快照，集群变更后重新测量集合通信。通信日志至少包括 collective 类型、字节数、耗时、rank 方差、是否重试和是否与计算重叠。

当通信时间上升时，要区分带宽不足、延迟主导、消息过小、最慢 rank、网络拥塞和同步顺序错误。单机 microbenchmark 只能说明局部能力，必须用真实 batch 验证是否能解释 step 时间。跨节点 TP 往往比同机 TP 更敏感；若通信不能隐藏在计算之后，减少并行度可能比扩大集群更快。

混合精度与异常处理

BF16、FP16、FP8 和更低精度可以降低显存、通信和计算成本，但会改变数值误差。训练系统需要监控 loss spike、梯度范数、overflow、underflow、NaN、Inf 和异常 rank。master weights和optimizer moments等是否高精度依实现；归一化和输出层也需按数值证据选择；不能把 dtype 当作一个全局开关。

出现 NaN 时，自动重试同一个 batch 通常没有意义。平台应保存触发 step 的输入摘要、参数统计、梯度范数、精度配置和 kernel 版本，然后暂停或回滚到最近健康 checkpoint。若直接继续运行，坏状态可能覆盖所有可恢复版本。异常检测应与 checkpoint 保留策略绑定，至少保留最后一个已验证健康点。

通信量账本

每种并行策略都可以建立通信量账本。数据并行主要产生梯度同步；张量并行在层内产生 all-reduce 或 all-gather；流水线并行传输激活和梯度；MoE 产生 token dispatch 的 all-to-all；FSDP 需要在计算前后获取和释放参数。平台应估计每一步的字节数、消息数量和同步次数，再用真实链路带宽与延迟估算下界。

如果一个层的计算时间小于一次 collective 的延迟，就算理论 FLOPs 很低，扩大并行度也不会有收益。相反，大矩阵乘法可以把通信隐藏在计算中。通信量账本应按 sequence length、micro-batch、hidden size、并行度和 dtype 计算，并在 profiler 中验证。出现差异时，重点查 padding、bucket、参数 prefetch、梯度累积和 collective 是否被意外串行化。

Overlap 的前提

通信与计算重叠需要独立 stream、合理的梯度 bucket、正确的依赖和足够大的计算块。bucket 太小会产生大量 collective 和 launch，太大则要等很久才开始同步；通信 stream 与计算 stream 的依赖设置错误时，表面上有两个 stream，实际仍然串行。平台应在报告中分别列出 kernel 时间、可重叠通信、不可重叠通信和同步等待。

重叠还会影响显存。为了提前 all-gather 参数，系统可能要同时保留更多参数 shard；为了让 backward 与通信并行，梯度 bucket 会延迟释放。显存预算不能只按模型权重计算，而要加入 overlap buffer、activation checkpoint、通信 buffer 和 dataloader staging。一个在显存充裕机器上有效的优化，迁移到更小 GPU 后可能反而触发 OOM。

NUMA、PCIe 与设备亲和

多 GPU 节点常常有多个 CPU socket、PCIe root complex 和网卡。数据 worker、Pinned Memory、GPU 和网卡绑定不合理，会让 host 到 device 拷贝经过远端 NUMA，吞吐下降且抖动增加。启动器应根据拓扑生成 CPU affinity、GPU affinity 和 NIC affinity，并在运行时记录映射。不能只依赖容器默认的 CPU 集合，因为调度器可能把进程放在与 GPU 不同的 socket。

故障排查时要把拓扑作为版本化环境的一部分。换一批节点、升级 BIOS、改变网卡固件或调整 MIG，都可能改变通信路径。NCCL 提供了拓扑感知能力，但应用还需要保存 NCCL 环境变量、通信算法和日志摘要 [13]。当扩展曲线突然下降时，拓扑快照往往比训练代码更能解释原因。

PyTorch2.9文档说明activation重算的RNG保存与设备类型限制 [22]；具体训练是否等价还要核对该版本和自定义算子。

Activation checkpoint 与内存时间交换

activation checkpoint 通过不保存全部中间激活、在 backward 时重新计算来降低显存。它把空间成本换成计算成本，适合模型大、激活占比高的训练。平台应记录 checkpoint 粒度、重算 FLOPs、显存峰值、step time 和质量。层间切分过粗会导致峰值仍高，切分过细会增加 kernel 和调度开销；不同 sequence length 下最佳粒度也可能不同。

activation checkpoint 与流水线并行、FSDP、混合精度和异步通信会互相影响。重新计算时需要相同的随机状态，否则 dropout 或随机算子会改变梯度；参数已经被释放时，需要再次 all-gather。恢复和性能报告必须保存这些运行时开关，不能只保存一个 enable_activation_checkpoint 的布尔值。对于后训练和生成式训练，还要评估重新计算对采样一致性的影响。

GPU 利用率的正确解释

GPU busy 只是设备上有 kernel 执行，不代表 kernel 高效。大量小 kernel、低 occupancy、访存瓶颈、等待同步和无效 padding 都可能让 busy 较高而有效吞吐较低。相反，某些通信或数据等待期间 GPU 利用率下降，可能是系统正常的阶段性行为。应结合 SM 利用率、显存带宽、Tensor Core 利用率、kernel occupancy、通信和有效 token 分析。

训练 dashboard 需要同时展示全局和局部。全局 step time 便于看趋势，rank 最大耗时便于看 straggler，数据桶 loss 便于看质量，checkpoint 和恢复指标便于看可用性。指标如果没有 run、step、rank、node、model和数据版本这些关联字段，就无法定位；字段过多又会造成监控成本，因而应把run/step等高基数事实放trace/日志，metrics只使用受控聚合维度。

可复现不等于位级相同

分布式低精度训练中，硬件、归约顺序、kernel、通信算法和随机数都会影响最后几位。平台需要区分严格位级复现、统计复现和语义复现。严格复现可能限制并行和性能；统计复现关注 loss 与主要评估指标在容差内；语义复现关注模型能力和安全指标不发生不可接受变化。job spec 应明确目标等级，而不是笼统写“可复现”。

复现报告包含相同的代码、数据、tokenizer、seed、并行度、dtype、硬件和运行时。如果硬件不同，应说明差异并进行多次重复实验，报告均值和方差。不要把一次结果的微小差异当作故障，也不要用随机性解释明显的 loss 跳变。数据顺序、checkpoint 恢复和编译缓存都应在排查清单中。

Online Softmax与IO优化的数学边界

第1章给出缩放注意力，本章补分块计算如何保持归一化。对已处理键块保存行最大值m、指数和l、未归一化加权值和u；新块分数\(s_j\)与值\(v_j\)到达时，设 \(m’=\max(m,\max_js_j)\)，再令 \(l’=e^{m-m’}l+\sum_j e^{s_j-m’}\)，\(u’=e^{m-m’}u+\sum_j e^{s_j-m’}v_j\)。所有块处理完返回u/l。新最大值变化时，旧l和u都要重缩放，不能只拼接各块已经归一化的概率。[20]

初始化用“尚无有效键”的分支处理，避免负无穷减负无穷；全mask有效查询行按契约报错或返回约定值，不能产生伪均匀分布。FlashAttention减少HBM中间读写，标准全注意力计算量仍是序列二次阶；数学目标一致不表示浮点逐位相同。FA2进一步改工作划分和并行，收益依形状、硬件与mask支持而变。[21] 对照高精度结果、极值、短行/长行、尾块与梯度，才能接受新核。

GPU层级、Stream与Shared Memory

CUDA的逻辑Grid包含Block，Block包含Thread；线程以warp参与执行，block驻留于SM但一个SM可容纳多个block，数量受寄存器、共享内存和线程资源约束。普通block之间无默认执行顺序，也不能靠某个block自旋等待全Grid完成；跨块汇总可用分阶段kernel等有明确定序的机制。shared memory共享于块内，需要按真实参与线程保证同步。[23]

同stream有操作顺序，跨stream需用event表达依赖，硬件有资源才可能重叠。异步API返回不表示数据已经可用；主机传输要核对pinned memory、拷贝引擎和buffer生命周期，计时前后的同步口径也要说明。[24] 同步太广会损害性能，同步缺失则是正确性错误，二者不能混为一个调参问题。

本书用32个bank、4字节float和32线程warp作教学映射：连续访问通常分散到不同bank，32×32 tile按列读取的步长32可能使不同地址落同bank；改32×33可改变映射。这里不把同地址广播当不同地址冲突，也不推广到任意向量宽度与硬件。padding增加共享空间，可能减少驻留block；它解决的是特定性能冲突，不能修复越界、未初始化或race。[23]

Shared Memory故障：先证明正确，再诊断bank冲突

某个 shape 才出错时，先固定输入、dtype、stride、block/tile 和工具链，缩减成可复现的最小尺寸，并与可靠参考逐元素比较。以下是本书诊断顺序；Sanitizer 工具职责依据 NVIDIA 官方手册：memcheck 检查内存访问，racecheck 检查共享内存访问竞争，synccheck 检查同步原语使用。它们只覆盖已执行路径，并不能证明所有尺寸正确。[25]

自动门禁配置非零错误退出码并保存报告，缺少设备时记录未验证；padding 不能修复越界、竞争或错误屏障。

融合、编译与瓶颈的受控实验

融合常减少launch和中间HBM读写，却可能增加寄存器、spill、共享内存和同步，破坏独立库核的tile或Tensor Core路径。回退时先固定形状、dtype、预热、计时同步与数据，再比寄存器、local spill、占用、访存合并和kernel时间；缩小融合范围也应作为候选，而非只继续加融合。Triton语言以blocked program描述计算，CUDA给出较显式的线程与同步控制；此Triton不是第7章的Triton Inference Server。[26]

TVM涉及图与算子程序及运行时，XLA是张量计算编译器，TensorRT面向NVIDIA推理部署，三者不是训练并行框架的同义词。[27][28][29] 图级做等价变换、常量折叠、死代码消除、布局协调与融合；算子级安排tiling、循环、线程与存储层级。局部最佳布局可能让相邻算子多出转置，需接受局部牺牲来减少全图搬运。浮点重排按明确误差而非文本相同验收。

动态图可捕获局部静态IR并做符号维或shape特化；图断裂、数据依赖分支和新形状可能回退或重编译。静态IR不等于全部尺寸固定，也不等于CUDA Graph的launch捕获。记录编译、预热、缓存命中和长尾形状成本，限制特化缓存，罕见shape走经过验证的通用路径。一次导出成功不能证明训练或Serving端到端更快。

Nsight的Roofline用算术强度与带宽/计算上限帮助解释核的瓶颈。[30] 本书粗略模型为性能不超过min(峰值算力,带宽×FLOPs/字节)，但计数器须对应所用精度、访存层和真实指令。SM低且DRAM低也可能是launch、同步、CPU供给、小grid或依赖链；不能据此二分为“计算”或“显存”。先从时间线看空闲还是核内低效，再改batch、分块或融合检验假设，报告kernel和端到端两个层级。

编译工具比较：抽象层次与验收对象

下表比较开发者控制的对象，描述依据维护方文档；验收要求为本书推导。[23][26][27][28][29]

以 matmul → bias → activation 为教学例，图级先识别数据依赖、消去无效节点，并决定是否融合及如何衔接布局；不能跨越有副作用或不满足语义的边界任意重排。算子级再选择分块、循环顺序、线程绑定和存储位置。TVM 的图与张量程序层、Pass 基础设施支持这种分层变换，具体入口随版本核对。[27]这里给出的是优化职责与执行次序，不是一段已经运行的 TVM 程序。

8.5 Checkpoint与恢复协议

Checkpoint 的完整状态

可训练checkpoint通常包含模型参数、必要的master weights、optimizer moments、学习率调度器、gradient scaler、随机数状态、数据游标、训练配置、并行拓扑、tokenizer、数据 manifest、代码版本和评估结果。权重连同所需模型配置/模板可用于推理，却不能保证继续训练等价。若在optimizer step边界保存且无未提交梯度累积，梯度未必需要持久化；若保存中间累积状态则应包含梯度与累积进度。对于分片训练，文件名不是状态语义，必须用 manifest 描述逻辑参数、shard 范围、dtype、shape 和校验和。

完整性发布协议

推荐用临时路径加完成记录实现checkpoint完整性发布。各 rank 先写带有 job_id、step 和版本号的临时 shard，计算大小与 checksum；协调者确认全部 shard 到齐、元数据完整、抽样读取成功后，再写 COMMITTED 标记。恢复程序只读取已提交版本。训练进程在写入中途退出时，残留临时目录可以异步清理，不会被误认为最新状态。

完成标记应包含 world size、TP、PP、DP、EP、dtype、模型 schema、数据 manifest hash、tokenizer hash 和 global step。恢复后要执行小 batch forward、loss sanity check、参数统计和数据可读性检查。校验和只能证明字节完整，不能证明参数、优化器和数据游标的语义对应。

保存频率与丢失工作量

保存越频繁，故障后丢失的训练工作越少，但 I/O 和同步开销越高。可以根据故障率、恢复时间、checkpoint 成本和 GPU 单价估计总成本。大规模训练还要区分可恢复 checkpoint、评估 checkpoint 和发布 checkpoint：可恢复点追求快速重启，评估点需要质量报告，发布点需要转换、签名和兼容性检查。不要用发布制品替代高频恢复点。

异步 checkpoint 可以让训练继续计算，但需要处理内存快照、写入期间的状态一致性和 GPU/CPU 拷贝。若 checkpoint 线程读取正在变化的 optimizer state，得到的可能是跨 step 混合状态。安全做法是使用冻结的 state snapshot、copy-on-write 或在逻辑 step 边界建立一致快照。异步并不意味着可以取消一致性约束。

故障分类与恢复策略

常见故障包括 GPU Xid、节点重启、网络分区、NCCL hang、对象存储限流、文件系统不可写、容器驱逐、OOM、NaN 和数据 shard 损坏。单卡故障可能需要替换节点并重建 communicator；存储抖动可以退避重试；NaN 应停止并恢复健康点；rank 卡死需要 watchdog 和全局超时。不同故障必须有不同的 runbook，不能把“自动重启”当作统一方案。

弹性恢复可以等待原节点、替换节点后保持 world size、缩小 world size 继续，或回滚并重新分配。改变 world size 可能改变 global batch、学习率、数据顺序和 optimizer 行为。平台应让恢复策略显式化，并在报告中记录丢失步数、重算 token、恢复耗时和最终质量差异。SRE 的错误预算思想可用于决定何时继续重试、何时停止作业并人工处理 [31]。

训练状态与推理制品分离

训练 checkpoint 的目标是继续优化，推理制品的目标是快速加载和稳定服务。训练状态包含 optimizer 和分片元数据，推理制品通常只包含参数、tokenizer、模板、量化和运行时配置。两者应使用不同目录、权限和生命周期，但通过一个发布 manifest 关联。直接把训练目录挂载到 serving，容易暴露不必要状态，也容易让线上误读一个未完成版本。

转换器要处理参数命名、分片布局、dtype、权重共享、词表、位置编码和模型 schema。转换后应做参数总量、shape、均值方差、hash 和小 batch 输出对比。对量化模型，还要比较校准集质量、最大误差、生成稳定性和特殊 token。转换脚本要固定版本并产生日志，不能依赖某个开发者机器上的临时命令。

发布门禁

发布门禁至少包括：制品完整性、模型加载、tokenizer 与模板兼容、固定 probe 输出、离线质量、显存峰值、冷启动时间和目标硬件性能。一个模型可能 loss 更低，却因为 tokenizer 改变导致线上输入边界不同；量化可能节省显存，却造成结构化输出失败；新的 kernel 可能提高吞吐，却在最大长度下产生 NaN。门禁应同时检查功能、质量、性能和安全。

发布后的 artifact 要签名并登记来源。注册表记录训练 run、数据 manifest、checkpoint、转换器版本、量化配置、engine build、评估结果和审批者。回滚时根据旧 manifest 恢复完整制品，而不是只把 image tag 改回旧值。推理平台的模型仓库与训练平台的 checkpoint 仓库可以有不同接口，但必须共享不可变 hash。

迁移训练与分布式重分片

当训练从 64 张卡迁移到 128 张卡，可能需要改变 DP 或 pipeline stage；当 GPU 型号变化，可能需要调整 batch、dtype 或 checkpoint 读取路径。支持迁移的格式应将逻辑参数与物理 shard 分离，转换器根据目标拓扑重新分片。迁移后还要验证 optimizer state 的分片和数据游标是否仍然一致。

若系统不支持任意重分片，应在调度时把 checkpoint 的恢复约束传递给资源调度器，例如 world size、TP、PP、显存下限和 GPU 架构。调度器找不到兼容资源时宁可保持 pending，也不能分配一个表面满足 GPU 数量但无法恢复的集群。恢复兼容性是调度约束，而不是作业启动后的异常处理。

训练取消与优雅停止

取消长训练需要定义边界。用户点击停止后，控制面发出取消事件，worker 在安全 step 边界停止接收新 batch，必要时保存一个可恢复 checkpoint，再关闭数据流和通信组。若节点即将被抢占，平台可以提前发送 preemption notice，让作业尽量完成一次保存。直接 kill 进程虽然快，却可能留下无法判断的新旧状态和大量孤儿资源。

优雅停止的时间也要有上限。checkpoint 长时间卡住时，平台要选择等待、切换存储路径或保留最近健康点；不能因为保存新点而让整个集群无限占用。最终状态应区分 USER_CANCELLED、PREEMPTED、BUDGET_EXCEEDED、FAILED_RECOVERABLE 和 FAILED_PERMANENT。不同状态决定是否自动重试、是否计入实验失败、是否需要人工审批。

异步快照时间线与完整性发布

PyTorch DCP2.9明确把staging目标定义为training-safe表示：staging完成后，后续参数更新不应改动被保存的表示；自定义stager若不自动同步，调用者负责选择正确同步点。[32] 这里区分设备拷贝完成与持久化完成，不能把Future存在当保存已提交。以下是本书通用协议设计，不是DDP自动具备的API行为：

故障在t1之前发生，继续使用旧点；t2/t3宕机则残片不能被latest扫描误选；t4后协调者丢失回执，要按checkpoint id查询已有提交，不能覆盖成另一快照。对象存储完成记录、数据库指针与rank文件不是天然一个事务；发布端要定义唯一checkpoint id、写入条件和指针CAS，读取端再次核验。完成标记协议也不是数据库意义的两阶段提交，不能借术语承诺跨系统原子性。

普通DDP某些模型权重可由rank0写，但数据进度/RNG及其他恢复状态仍需按训练协议收集；ZeRO/FSDP分片需要所有必需参与者配合，不能把rank0拥有完整状态作为默认。异步缓冲占用CPU/GPU容量，慢盘时应背压、延后新保存或同步回退，不能无限堆积。恢复演练检查对应step、参数、optimizer和游标，不仅比较文件hash。

8.6 容量、调度与多租户成本

Gang scheduling 与故障域

分布式训练需要一组 GPU 同时可用，部分分配往往只能让 job 长期 pending。调度器应识别 gang，并根据节点、GPU、NVLink、网络和本地数据做拓扑感知。大 job 需要反碎片化，小 job 可以填充空洞；训练、推理、评估和开发应有不同资源池与优先级。抢占时要考虑 checkpoint 是否完成，不能在不可恢复的阶段直接杀死作业。

配额、优先级与公平

配额应同时按 GPU 数、GPU 小时、显存、优先级和项目预算表达。一个团队占用少量高端 GPU 训练很久，可能比另一个团队使用更多低端 GPU 更昂贵。成本系统要记录预约、实际使用、空闲等待、通信等待、恢复重算、评估和 checkpoint。按有效 token 和成功实验归因，才能比较不同团队的真实效率。

多租户环境应隔离数据凭证、checkpoint 路径、日志、缓存和调试权限。训练 worker 只获得访问具体 manifest 和 shard 的短期凭证，不能拥有整个 bucket 的写权限；checkpoint 目录与原始数据隔离；样本抽样和错误日志默认脱敏。OpenTelemetry 与 Prometheus 可以提供统一的运行指标和追踪基础，但敏感数据是否记录仍需平台策略 [11][33][34]。

成本预算与容量计划

训练计划应在启动前估算 token、step、GPU 小时、checkpoint 次数、评估次数和重试余量。理想扩展效率公式为：

E(N) = throughput(N) / (N × throughput(1))

当扩展效率随 GPU 数快速下降时，继续扩大集群可能比优化数据、kernel 或并行策略更贵。平台应把扩展曲线作为门禁，记录有效 token/s、通信比例、数据等待、峰值显存和节点故障恢复。PaLM 和 Megatron-LM 的规模化经验表明，训练规模越大，系统效率和故障管理越是模型质量的一部分 [1][17][9]。

资源泄漏与作业清理

训练作业失败后，常见残留包括 Kubernetes Pod、NCCL 进程、共享内存、Pinned Memory、对象存储临时目录、租约、GPU reservation 和告警。控制面应有终止流程：先发送取消事件，等待 worker 上报 checkpoint 或停止原因，再清理通信组、释放分配、关闭数据流、删除临时文件并写最终状态。清理流程需要超时和人工兜底，不能无限等待一个失联 worker。

资源回收要幂等。重复执行清理不会删除其他 job 的路径，不会释放错误的 GPU，也不会覆盖成功的最终状态。临时目录命名必须包含不可猜测的 run_id 和版本；清理器根据 manifest 校验归属，而不是使用宽泛的通配符。Prometheus 可以监测 reservation 与实际 Pod 的差异，及时发现资源泄漏 [33]。

训练与后训练的资源差异

预训练通常以稳定的大 batch 和长时间运行换取高吞吐；监督微调和偏好优化的 batch 更小、序列长度更不稳定，评估和生成式 verifier 可能成为瓶颈。统一的训练平台可以复用控制面、数据 manifest 和 checkpoint，但应允许 workload profile 声明不同的资源需求。后训练不能直接套用预训练的扩展曲线，因为生成、采样、奖励模型和验证器会改变 GPU 与 CPU 的比例。

例如 RLVR 训练可能需要并行生成多个候选，再执行 verifier；如果只给训练 worker 配 GPU，CPU verifier、队列和网络会成为隐性瓶颈。平台应把辅助模型、评估模型、tokenizer、验证器和数据服务纳入 job graph，统一记录版本与成本。否则看到的“训练吞吐”可能只是主模型 forward 速度，真实的每个有效样本成本却不断上升。

训练预算的动态控制

作业预算不能只在提交时检查。训练过程中失败重试、恢复重算、评估、checkpoint 和数据重处理都会增加成本。控制面应实时累计 GPU 小时、有效 token、对象存储请求、网络流量和失败次数，并在接近预算时提醒或暂停。用户可以选择“质量优先”“时间优先”或“成本上限”策略，平台据此调整评估频率、checkpoint 频率和资源池，而不是无条件继续运行。

动态预算还需要防止部分成功被误判。一个实验如果只完成了计划 token 的 20%，不能与完整实验直接比较；一个训练 job 超预算后被强制停止，应保存最后健康 checkpoint、最终 loss 和未完成原因。成本报表要把有效训练、恢复重算和无效等待分开，否则优化方向会被错误数据引导。

训练平台与调度平台的接口

训练作业向调度器声明 GPU 数量只是最小信息，还应声明 GPU 类型、拓扑、互联、CPU、内存、网络、临时盘、gang 约束、优先级、可抢占性、预计时长和恢复限制。调度器返回 allocation、rank manifest、租约和故障域。作业启动后若发现拓扑不满足通信要求，应拒绝运行并释放资源，而不是勉强开始再产生低吞吐。

调度器还要向控制面提供可解释事件：pending 的原因是资源不足、拓扑不匹配、配额不足、镜像不可用还是节点不健康。用户看到“排队中”没有帮助，看到“等待 16 张同型号 GPU 且需要同一 NVLink 域”才可以做取舍。透明的 pending reason 能减少人工干预，也能帮助平台发现容量规划和调度策略问题。

8.7 观测、排障与故障演练

指标、日志与追踪

训练指标包括 loss、学习率、梯度范数、有效 token、device token、GPU 利用率、显存、kernel 时间、通信、数据等待、checkpoint、恢复和节点健康。指标要按 rank、节点、数据桶和并行维度聚合，同时保留最大值和方差，避免平均值掩盖一个慢 rank。日志记录错误上下文，trace 连接控制面、数据服务、worker 和 checkpoint 服务。

Dapper 的分布式追踪思想适合把训练控制面和数据面关联起来 [34]。训练 trace 不应默认记录完整样本和隐私文本，而应记录 manifest、shard、batch、step、request id、错误类型和 hash。OpenTelemetry 提供跨组件的语义约定，Prometheus 适合时间序列与告警；二者结合后，平台能从“GPU 下降”追到“某类 shard 解压变慢”或“某个 rank 通信抖动”。

验收矩阵

训练 Infra 的验收至少包含五类测试：数据正确性、性能扩展、故障恢复、数值稳定和安全治理。数据正确性验证 token 统计、样本边界、loss mask、manifest 和重复率；性能验证单机、单节点、多节点扩展曲线；恢复验证中断、节点替换、checkpoint 损坏和数据不可读；数值验证 loss 连续、梯度无异常和不同精度在容差内；治理验证权限、审计、成本和数据删除。

每项测试都要固定模型 hash、数据 manifest、容器镜像、硬件、驱动、并行度、global batch 和测试时间。报告不仅写“通过”，还要保存原始指标与失败样本。若性能提高但 loss 曲线异常，不能接受；若恢复成功但重复了大量数据，也不能只算功能通过。训练平台的交付标准是可解释、可重现和可恢复，而不是某一次 demo 的最高吞吐。

故障注入

训练平台至少要演练五类注入：杀死一个 rank、关闭一台节点、阻断集合通信、让对象存储返回超时、损坏一个 checkpoint shard。每次注入要记录检测时间、作业状态、用户可见影响、自动恢复、重算 token、恢复后的 loss 和资源释放。若系统只在单进程退出时能恢复，而一个 rank 卡死会让其他进程永久等待，那么它并不具备生产级弹性。

故障注入不能只发生在非高峰环境。高峰期的队列、配额和发布动作会改变恢复路径。可以先在隔离资源池做小规模演练，再在生产影子作业验证指标与告警，最后安排可控的真实节点维护。本书结合SRE错误预算的决策方法 [31] 设计演练与停止条件，不把该书当特定训练平台已经恢复成功的证据。

数据与模型治理

训练数据需要来源、授权、保留期、删除流程和审计。数据处理 worker 获得最小读权限，输出 shard 写入独立路径；日志中的样本文本默认脱敏；调试抽样需要临时授权。模型 checkpoint 可能记忆训练数据或包含内部能力，因此下载、复制、转换和对外发布都应登记。

治理信息不应只存在文档中。manifest、job spec、checkpoint manifest 和发布记录都应机器可读，评估系统和权限系统可以据此阻断不合规任务。例如数据 license 不允许某种用途时，控制面在分配 GPU 前拒绝 job；checkpoint 使用了已撤回的数据版本时，注册表阻止发布。治理越晚介入，返工成本越高。

人工接管边界

自动恢复不是越多越好。短暂的对象存储超时可以自动退避；连续 NCCL hang、NaN、checkpoint 校验失败和数据权限错误应暂停并通知负责人。平台要定义最大重试次数、指数退避、预算上限和升级联系人。重试次数超过阈值后，系统保留现场、停止覆盖健康 checkpoint，并生成包含 job spec、拓扑、最后健康 step 和错误 trace 的诊断包。

人工接管也要有明确操作。允许负责人选择回滚到某个 checkpoint、跳过坏 shard、改变资源池或终止作业，但每个动作都产生审计事件。不能为了“先跑起来”直接修改共享存储或删除现场。事后复盘应区分代码缺陷、数据缺陷、平台缺陷和容量规划缺陷，并把修复加入下一次验收。

训练作业的可观测事件

除了时间序列指标，还需要结构化事件：JOB_ACCEPTED、ALLOCATION_READY、DATA_STAGE_READY、WORKER_STARTED、STEP_HEALTHY、CHECKPOINT_COMMITTED、NODE_LOST、RECOVERY_STARTED、RECOVERY_SUCCEEDED 和 RUN_FINISHED。每个事件携带 run_id、spec hash、global step、world size、checkpoint version 和时间。这样事故复盘可以重建状态变化，而不是从分散的 stdout 中猜测。

事件系统要处理重复、乱序和延迟。worker 可能在网络恢复后发送旧的 checkpoint 完成事件，控制面必须通过单调 step、版本号和状态机拒绝过期事件。重要事件需要持久化，普通 profiler 数据可以采样。训练控制面不应依赖某个 dashboard 的实时状态作为事实来源，dashboard 只是从事件和指标派生视图。

集群升级与基线保护

驱动、CUDA、NCCL、内核、固件和容器基础镜像的升级都可能改变训练结果与性能。升级前应保存固定 workload 的基线，包括吞吐、通信、显存、loss 曲线、异常率和 checkpoint 恢复。升级后用相同 job spec 在同一批或等价节点上运行，并比较允许范围。若只比较速度，不比较 loss 和恢复，可能把数值变化误认为性能提升。

集群升级需要分批和可回退。先用影子作业验证数据和通信，再让低优先级实验迁移，最后处理生产训练。节点标签应标识硬件、driver、NCCL 和固件版本，调度器可以按兼容性选择节点。发生性能回退时，保留旧节点池或旧镜像一段时间，保证正在运行的长任务有安全迁移路径。

大规模训练中的尾部任务

平均 step time 不能代表整个训练的体验。某些 step 可能因为 checkpoint、数据刷新、节点抖动、编译或对象存储限流而明显变慢；长尾 step 会决定 wall-clock 完成时间和 GPU 成本。平台应记录 step 的分位数、最大值、慢 step 原因以及慢 step 是否集中在某些节点、数据桶或并行阶段。若只是用平均值计算 ETA，训练可能在最后阶段反复推迟，容量计划也会失真。

尾部还来自 straggler rank。一个 rank 的坏磁盘、远端 NUMA、GPU 降频或网络重传会让整个 collective 等待。训练运行时可以报告每个 rank 的数据准备、forward、backward、通信和 checkpoint 时间，并设置超过阈值的慢 rank 告警。自动摘除慢节点必须谨慎：替换它会触发新的恢复和通信重建，应该比较继续运行与重启的预计成本。

一个 step 的完整时间线

为了让性能分析能够落地，可以把每个 step 的时间线固定为：数据游标推进、CPU 预取、Pinned Memory 拷贝、H2D 拷贝、forward、activation 保存或重算、backward、梯度 bucket ready、collective、optimizer update、日志和 checkpoint。每个区间记录开始与结束时间，并以 global step、rank 和 node 关联。这样当吞吐下降时，可以直接回答是数据迟到、GPU kernel 变慢、通信不重叠，还是保存状态引起了暂停。

时间线也能帮助比较不同优化。改变 packing 主要影响有效 token 和数据阶段；改变 FlashAttention 主要影响 attention kernel 与显存；改变 FSDP 主要影响 all-gather、reduce-scatter 和显存峰值；改变 checkpoint 主要影响 I/O 与同步。把所有优化都归结为 GPU utilization，会丢失这些因果关系。性能报告应给出端到端收益以及每个区间的变化，方便后续回归。

NCCL timeout先找未到达的rank

PyTorch分布式文档给出通信组与辅助诊断机制，NCCL也按拓扑、运行时与网络分层提供排障入口。[35][36] 本书诊断流程从最早异常开始：关联所有rank的run/step、collective序号、组、shape、dtype与进入/退出时间，而非只读最后超时的节点。某rank先OOM、CUDA错误、进程退出或卡在数据读取，其他rank可能只是等待它而最后报timeout。

若同一collective序号的调用或张量不一致，检查条件分支、尾批、异常处理和组创建；若某rank在进入collective前长期数据等待，检查其shard、解压、NUMA和CPU；若顺序一致但特定链路反复慢，再查GPU/Xid、NIC/RDMA、拓扑与独立通信复现。监测用barrier也有后端与版本限制，不把它插到所有生产step里制造新等待。

教学故障例：rank3读取坏shard未上报异常，其他rank均停在梯度同步。正确动作是保留rank3的数据等待与最早错误，隔离坏输入，按一致checkpoint重启，并确认后续有效token和游标；只把timeout调大不会修复数据源。若独立通信也复现链路故障，先隔离节点再做长稳/恢复验证。只有证明合法操作确实更长时才调整超时，不能用更长等待掩盖死锁。

8.8 训练平台验收与交付

交付前配置

交付前应生成一份配置摘要：模型和代码 hash、tokenizer、数据 manifest、数据配方、global batch、sequence length、dtype、并行度、节点类型、网络拓扑、checkpoint 频率、恢复策略、预算和告警阈值。摘要由控制面生成并随 run 保存，避免用户填写一份配置、启动器再隐式覆盖另一份配置。

小规模到目标规模的阶梯验证

第一阶验证单 GPU 的数据、loss、checkpoint 和恢复；第二阶验证单节点的并行组、通信和显存；第三阶验证多节点的扩展曲线、数据供给、故障替换和 reshard；第四阶才运行目标规模。每一阶都应使用相同的模型和数据语义，区别只在资源规模。这样出现问题时可以判断是算法、单机 kernel、跨机网络还是调度器导致。

交付后的持续检查

上线后持续检查有效 token/s、GPU 利用率、通信比例、数据等待、loss、checkpoint 成功率、恢复时间和成本。每次驱动、CUDA、网络、文件系统、数据格式、模型代码或并行配置升级都触发一轮基线对比。若只在初次验收时测量，系统随环境变化退化却不会被发现。

训练 Infra 的最终验收不是“脚本跑完”，而是：给定相同的 job spec，平台可以在可接受的时间内分配资源、持续供给数据、达到可解释吞吐，在故障后从一致状态恢复，在发布时生成可验证制品，并且每个资源和质量变化都能追溯到具体版本。这个闭环建立后，后续推理 Infra 才能可靠地消费训练产物。

训练性能报告的最小字段

一个可比较的性能报告至少包括：模型参数量、层数、hidden size、序列长度、global batch、micro-batch、有效 token、padding token、GPU 型号、GPU 数量、节点数、TP、PP、DP、EP、dtype、CUDA 和 driver 版本。还要包括 step time、forward、backward、通信、数据等待、checkpoint、MFU 或等价计算效率、显存峰值和扩展效率。

报告必须说明是否包含编译、warmup、验证、checkpoint 和失败重试。不同团队经常使用不同口径，导致“吞吐提升”无法复核。建议把原始 trace、汇总 JSON 和人类可读表格一起保存，并将报告 hash 写入 run metadata。后续优化如果只保留一个漂亮的数字，而没有 workload 与环境，就不应作为平台基线。

训练平台与数据平台的接口

训练平台向数据平台提出的不是“给我一个路径”，而是一个数据合同：数据版本、schema、授权用途、split、采样权重、tokenizer、分片大小、可用区域、删除策略和质量阈值。数据平台返回 manifest、统计、访问凭证和血缘。合同变更需要版本化，训练平台根据 manifest hash 决定是否允许复用缓存和 checkpoint。

接口还应支持数据不可用和部分可用。一个区域对象存储故障时，训练可以切换到镜像副本，但必须记录数据路径和复制版本；某个 shard 损坏时，可以隔离并跳过，但要报告有效 token 损失。数据平台不应为了满足训练吞吐静默返回旧版本，训练平台也不应为了继续运行绕过授权检查。双方通过显式版本和错误码协作。

训练平台与评估平台的接口

评估不是训练结束后手动运行一个脚本，而是 checkpoint 生命周期的一部分。训练平台提交 checkpoint hash、模型 schema、tokenizer、数据 manifest 和安全标签；评估平台返回任务 id、指标、样本报告和质量门禁。评估任务失败、超时或结果不完整时，checkpoint 不能被自动标记为发布候选。

评估结果应区分可比和不可比。改变 tokenizer、模板、数据切分、采样温度或最大输出长度后，指标不应直接与旧版本横向比较。平台保存评估配置和运行时参数，报告中给出质量、延迟、显存和成本的联合视图。只有达到预设门禁且证据完整，模型制品才可以进入推理 Infra 的注册和灰度流程。

训练 Infra 的最终检查表

在进入目标规模训练前，负责人可以逐项确认：job spec 是否不可变；数据 manifest 是否可追溯；tokenizer 是否版本化；有效 token 是否能准确统计；读取、解压、packing 和 batch 是否有背压；并行拓扑是否与硬件匹配；通信是否有真实 trace；dtype 和异常是否受监控；checkpoint是否只发布完整快照；恢复是否验证数据游标和 optimizer；失败是否释放资源；成本是否按有效 token 归因；权限和审计是否覆盖 worker；评估和发布是否有门禁。

这些检查不是行政清单，而是系统边界的外化。缺少其中任何一项，都可能把故障推迟到更昂贵的阶段：数据问题会在训练几天后才暴露，checkpoint 问题会在节点故障时暴露，权限问题会在审计时暴露，吞吐问题会在扩大集群后暴露。把它们前置到小规模验证，通常是训练 Infra 最便宜的优化。

训练结果的可审计性

一次训练结果至少需要能回答四个问题：使用了什么数据，执行了什么计算，经历了哪些故障，为什么可以发布。数据由 manifest、授权和统计回答；计算由 job spec、代码 hash、并行拓扑和运行时镜像回答；故障由事件、trace、重试和恢复记录回答；发布由评估报告、质量门禁和审批记录回答。把这些信息分散在聊天记录、机器本地日志和手工表格中，短期看似灵活，长期一定无法复盘。

可审计不等于保存所有原始内容。审计记录可以使用带权限控制的hash（敏感低熵字段不能依赖裸hash匿名化）、版本号、长度、来源、权限和时间，敏感文本单独受控。关键事件使用追加式日志，修正通过新事件表达而不是覆盖旧记录。这样既能支持事故调查和合规审查，又不会把训练数据复制到每个监控系统。Dapper 的 trace 关联思想和 OpenTelemetry 的上下文传播可以帮助连接不同服务，但数据最小化仍然是平台责任 [11][34]。

GPU与规约练习卡组（设计，未实现未实测）

下面只规定配套项目的输入输出与验收；本章没有CUDA编译、Sanitizer运行或目标GPU性能结果。所有卡先与CPU/可靠库的高精度参考比较，再在明确硬件和同步口径下测速，不承诺超过成熟库。

每卡交付配置、参考结果、断言、失败尺寸、误差阈值与测量状态。归约改变浮点求和顺序，不用单一绝对误差覆盖所有规模；非有限输入按预先约定拒绝或传播。涉及尾线程的同步不能因为越界提前return导致块内死锁。核心CUDA代码与完整构建在独立练习项目实现，卡片完成不等于手写能力或GPU实测完成。

8.9 本章小结

训练平台以有效监督、并行状态和完整恢复点为核心：数据manifest固定实际消费含义，rank mesh定义副本与分片，通信账本解释字节与等待，数值检查约束kernel优化，checkpoint在安全快照后才发布。性能和恢复必须同时验证，不能通过忽略数据、校验或失败时间制造吞吐提升。

交给第9章的是通过转换、兼容和质量检查的Model Manifest，不是任意训练目录；交给第10章的是绑定数据与配置的评估记录；资源、trace与成本沿第7章契约关联。本章新增公式、诊断例和练习是教学设计，未经训练集群或GPU实测，不宣称目标规模能力。

8.10 参考资料

[1] Shoeybi, M., et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv, 2019. https://arxiv.org/abs/1909.08053 访问日期：2026-10-17

[2] Rajbhandari, S., et al. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. SC, 2020. https://arxiv.org/abs/1910.02054 访问日期：2026-10-17

[3] DeepSpeed Team. Training a Trillion Parameters with Pipeline Parallelism. 2020. https://www.deepspeed.ai/2020/09/08/pipeline-parallelism.html 核验日期：2026-10-17

[4] Zhao, Y., et al. PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel. arXiv v2, 2023. https://arxiv.org/abs/2304.11277 核验日期：2026-10-17

[5] Moritz, P., et al. Ray. OSDI, 2018. https://www.usenix.org/conference/osdi18/presentation/moritz 访问日期：2026-10-17

[6] Kubernetes. Schedule GPUs. https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ 访问日期：2026-10-17

[7] Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ 访问日期：2026-10-17

[8] Zaharia, M., et al. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. NSDI, 2012. https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/zaharia 访问日期：2026-10-17

[9] Chowdhery, A., et al. PaLM: Scaling Language Modeling with Pathways. arXiv, 2022. https://arxiv.org/abs/2204.02311 访问日期：2026-10-17

[10] Grattafiori, A., et al. The Llama 3 Herd of Models. arXiv v3, 2024. https://arxiv.org/abs/2407.21783 核验日期：2026-10-17

[11] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[12] 张阿斯顿、李沐等. 《动手学深度学习》：12.5多GPU训练. 中文在线2.0.0，核验2026-10-17. https://zh.d2l.ai/chapter_computational-performance/multiple-gpus.html

[13] NVIDIA. NCCL: Collective Operations. 2.32.3文档，核验2026-10-17. https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html

[14] Rajbhandari, S., et al. ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning. SC, 2021. https://arxiv.org/abs/2104.07857 访问日期：2026-10-17

[15] Lepikhin, D., et al. GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding. 2020. https://arxiv.org/abs/2006.16668 核验日期：2026-10-17

[16] Fedus, W., et al. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. JMLR, 2022. https://arxiv.org/abs/2101.03961 核验日期：2026-10-17

[17] Narayanan, D., et al. Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM. arXiv, 2021. https://arxiv.org/abs/2104.04473 访问日期：2026-10-17

[18] Korthikanti, V., et al.. Reducing Activation Recomputation in Large Transformer Models. 2022. https://arxiv.org/abs/2205.05198 核验日期：2026-10-17

[19] Liu, H., Zaharia, M., Abbeel, P.. Ring Attention with Blockwise Transformers for Near-Infinite Context. 2023. https://arxiv.org/abs/2310.01889 核验日期：2026-10-17

[20] Dao, T., et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS, 2022. https://arxiv.org/abs/2205.14135 访问日期：2026-10-17

[21] Dao, T. FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning. ICLR, 2024. https://arxiv.org/abs/2307.08691 访问日期：2026-10-17

[22] PyTorch. torch.utils.checkpoint. 2.9. https://docs.pytorch.org/docs/2.9/checkpoint.html 核验日期：2026-10-17

[23] NVIDIA. CUDA Programming Guide: Writing SIMT Kernels. 2026-09-10. https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/writing-cuda-kernels.html 核验日期：2026-10-17

[24] NVIDIA. CUDA Programming Guide: Asynchronous Execution. 2026-09-10. https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html 核验日期：2026-10-17

[25] NVIDIA. Compute Sanitizer User Manual. 官方文档。核验日期：2026-10-18

[26] Triton Contributors. Triton Language Introduction. https://triton-lang.org/main/programming-guide/chapter-1/introduction.html 核验日期：2026-10-18

[27] Apache TVM. Design and Architecture. https://tvm.apache.org/docs/arch/index.html 核验日期：2026-10-18

[28] OpenXLA. XLA. https://openxla.org/xla 核验日期：2026-10-18

[29] NVIDIA. TensorRT Architecture Overview. https://docs.nvidia.com/deeplearning/tensorrt/latest/architecture/architecture-overview.html 核验日期：2026-10-18

[30] NVIDIA. Nsight Compute Profiling Guide. online checked 2026-10-17. https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html 核验日期：2026-10-17

[31] Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. https://sre.google/workbook/implementing-slos/ 核验日期：2026-10-17

[32] PyTorch. Distributed Checkpoint. 2.9. https://docs.pytorch.org/docs/2.9/distributed.checkpoint.html 核验日期：2026-10-17

[33] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

[34] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[35] PyTorch. Distributed communication package. 2.9文档. https://docs.pytorch.org/docs/2.9/distributed.html 核验日期：2026-10-17

[36] NVIDIA. NCCL Troubleshooting. 2.32.3. https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html 核验日期：2026-10-17

第9章 推理服务与资源调度

训练完成并不意味着模型已经可以被用户使用。训练输出是一个需要转换、装载、调度和观测的制品；在线推理则是一个同时面对突发流量、长尾上下文、流式连接、动态 batch、显存限制和版本发布的分布式服务。本章聚焦从一次 forward 到生产级 serving 的完整链路，重点解释 prefill 与 decode 的资源差异、KV cache 的内存管理、连续批处理、模型并行、长上下文、公平调度、量化、投机解码以及服务 SLO。

推理 Infra 的核心指标不应只有 tokens/s。交互请求关心首 token 延迟 TTFT、每个输出 token 的延迟 TPOT 和端到端尾延迟；离线任务关心 goodput 和单位成本；Agent 任务关心多次调用后的成功率、工具副作用和总等待时间。一个系统可能平均吞吐很高，却让短请求被长上下文阻塞；也可能单请求很快，却在并发增加时因为 KV cache 失控而 OOM。Orca、PagedAttention、Sarathi-Serve 和 DistServe 等工作说明，LLM serving 的关键突破来自把模型执行拆成可调度的资源和状态，而不是简单把模型放进 HTTP 服务 [1][2][3][4]。

训练制品不能直接交付，是因为用户面对的是请求生命周期而不是 checkpoint。推理平台必须回答五个问题：制品是否完整，容量是否够，状态是否可回收，调度是否公平，质量与成本是否仍在门限内。

9.1 请求生命周期与服务契约

模型制品不是一个权重文件

一个可服务模型至少由权重、配置、tokenizer、chat template、特殊 token、量化配置、并行配置、采样默认值、停止条件、结构化输出约束和安全策略组成。视觉或音频模型还要包含预处理器、图像尺寸限制和模态路由。模型注册中心应为这些 artifact 生成不可变版本和 hash，serving engine 只加载经过完整性、兼容性和质量门禁的 manifest。

把权重单独发布会产生很多线上差异：tokenizer 版本改变了输入长度，chat template 改变了系统提示，量化配置改变了显存与质量，停止 token 不一致导致输出过长，adapter 没有加载导致能力回退。生产发布应把 artifact manifest 当作运行时契约，并记录构建镜像、GPU 架构、CUDA/driver、engine 版本和评估结果。TensorRT 的构建/运行时架构与 Triton 的模型管理说明了制品兼容和模型生命周期的不同层次 [5][6]。

请求生命周期

请求的计算状态可以是 ACCEPTED、QUEUED、PREFILLING、DECODING、COMPLETED、CANCELLED 或 FAILED；交付状态另有连接中、STREAMING、已断开和已确认。STREAMING 与 DECODING 可以同时成立，不能排成互斥的单线状态。排队占用队列和配额，prefill 占用计算与临时激活，decode 持有 KV block 和执行槽，交付轴持有连接与发送缓冲。状态迁移应幂等，重复取消不能把已完成请求改成失败。

请求的输入也不能只用一个字符串表示。平台需要知道消息、token ids、输入 token 数、最大输出 token、停止条件、工具 schema、优先级、租户、模型版本、deadline、trace id 和幂等键。若网关提前做一次 tokenization，而 engine 再做一次，输入长度与计费可能不一致；若模板在不同组件中各自拼接，cache 命中与安全审计也会出错。建议在进入调度器前生成规范化 request manifest。

同步、流式与异步接口

同步接口适合短请求，但不能让连接超时决定 GPU 状态；流式接口需要定义事件顺序、心跳、断线、重连和取消；异步接口需要持久化 job、查询状态、获取结果和过期清理。客户端断开时，服务端可以取消生成、继续完成并缓存结果，或转入异步任务，但必须通过产品契约决定，不能依赖某个 HTTP 框架的默认行为。

流式响应的一个常见错误是只返回文本，不返回 usage、finish reason、模型版本和错误状态。客户端可能收到部分 token 后连接断开，却无法知道是正常停止、服务失败还是用户取消。每个事件应包含 request id 和单调序号，服务端保存最小必要状态，重连时可以检测是否重复发送。工具调用的参数生成和执行更需要独立 operation id，避免重试造成重复副作用。

推理引擎的执行图

一个 serving engine 通常包含 tokenizer、输入规范化、请求队列、调度器、模型执行、采样器、输出流和资源回收器。每一层都可能成为瓶颈，也可能改变语义。tokenizer 在 CPU 上处理大量短请求时会耗尽线程；输入规范化如果重复复制字符串，会增加内存；采样器如果在 CPU 上逐 token 处理，会把 GPU 的收益抵消；输出流的慢客户端会占用发送缓冲和请求状态。

因此，engine 需要定义数据结构和所有权。规范化后的 token ids 由请求上下文持有，KV block 由 cache manager 持有，GPU stream 由执行器持有，流式事件由 output channel 持有；请求状态只保存引用和状态，而不是复制所有大对象。取消或失败时按照反向顺序释放：停止生成、等待 GPU stream 安全点、减少 block 引用、关闭 output channel、释放 token buffer。没有明确所有权的实现容易出现 cache 泄漏或 use-after-free。

Sampling 与结构化输出

temperature、top-k、top-p、重复惩罚、logit bias、停止词和随机 seed 都会影响 decode 路径。某些参数可以在 GPU 上融合，某些结构化输出约束需要有限状态机、正则或 grammar mask。结构化输出会改变可选 token 集，导致采样 kernel、cache 和性能与普通文本不同。平台必须把采样配置作为请求版本的一部分，并在 usage 与 trace 中记录实际生效值。

JSON、函数参数和工具调用不能仅靠 prompt 要求。服务端应校验语法、字段类型、必需字段、最大长度和 schema 版本；失败时可以重采样、修复或返回明确错误。重采样会增加 target model 调用和 KV 保留，必须计入成本与超时。修复模型输出时不能默默改变用户意图或执行副作用，工具调用要先进入待执行状态，经过 schema 和权限检查后再提交。

Tokenizer 服务化

大型模型 tokenizer 可能包含复杂正则、词表和特殊 token，冷启动与内存并不小。多模型服务可以共享 tokenizer worker，也可以把 tokenizer 与 engine 放在同一进程。共享降低重复内存，但模型版本、模板和租户配置更容易混淆；同进程隔离更简单，却可能在高并发短请求下成为 CPU 瓶颈。压测应分别测 tokenization、模板拼接、H2D 拷贝和 GPU prefill。

tokenizer 的 batch 化也要考虑长短混合。将很多短请求拼在一起可能提高 CPU 吞吐，但一个超长请求会延迟整个 batch。可以按输入长度分桶、设置最大等待时间并让长输入单独处理。tokenizer 输出的 token count 必须与计费、admission、KV 估算和 trace 一致，任何一个组件自行重新 tokenize 都可能造成容量与账单不一致。

事件时间与指标口径

中文 Transformer 教材解释了自回归生成如何反复使用已有表示 [7]；服务指标则还要计入排队和发送。以下采用客户端观察的首尾输出时间，输入到达点固定为网关接受完整请求之时；跨机事件需注明时钟误差。一个请求生成 N 个可见 token，TPOT 是首 token 之后的 N−1 个输出间隔均值，N≤1 时记为不适用，不能除零或伪造零延迟。客户端 token 事件若一次合并多 token，不能把事件数当 token 数。内部 GPU iteration time、网络 token 间隔和用户可见 TPOT 是不同口径，必须同时注明边界。

9.2 显存与容量模型

两类完全不同的计算

Prefill 一次处理全部输入 token，矩阵并行度高，主要决定 TTFT；decode 每次生成一个 token，反复读取权重与历史 KV，主要决定 TPOT、并发和输出吞吐。输入很长时，prefill 可能占据大量计算和激活显存；输出很长时，decode 会长期持有 KV block。把二者混合成一个平均 latency，会掩盖真正的瓶颈。

在线指标可写为：

TTFT = first_token_timestamp - request_arrival
TPOT = (last_token_timestamp - first_token_timestamp) / (generated_tokens - 1)  # only for N > 1
E2E = queue_time + prefill_time + decode_time + postprocess_time
goodput = successful_requests_within_SLO / wall_clock

报告时还应按输入长度、输出长度、并发、模型版本、cache 命中和租户分桶。平均值无法表达长尾；p99 TTFT 可能由一个超长 prefill 造成，p99 TPOT 可能由 KV 水位接近上限造成。容量模型要从请求分布和服务目标出发，而不是从单请求 benchmark 外推。

从 token 速率到 GPU 数量

设到达率为 λ，平均输入 token 为 P，平均输出 token 为 D，单 GPU 在给定负载下的 prefill、decode 有效吞吐为 R_p、R_d，利用率预算为 u。若两阶段共享同一串行计算预算，粗估需要把工作相加：

shared_pool_GPU_equivalent ≈ (λ × P / R_p + λ × D / R_d) / u
PD_pool_prefill ≥ λ × P / (R_p × u_p)
PD_pool_decode  ≥ λ × D / (R_d × u_d)

对独立瓶颈取 max 只能表示下界，不能视为混部所需总 GPU。PD 两池还要分别向上取整、满足拓扑与通信约束；实际混部并非线性叠加，需压测干扰。以上吞吐不是硬件峰值，必须绑定模型、长度与 batch 分布。这只是初始估算，还要加入 KV cache 容量、模型权重、临时激活、网络传输、故障余量、灰度余量和长尾请求。若输出长度有明显长尾，使用平均 D 会低估 decode slot；若输入长度不断增加，prefill 与 KV 同时增长。应分别压测短、中、长请求混合，并以满足 SLO 的 goodput 作为容量基准。

SRE 的容量和错误预算思想可以延伸到推理平台：不能把同一份剩余容量同时承诺给节点故障、扩容和滚动发布 [8]。至少应保留 failover reserve、deployment reserve 和 burst reserve，并在容量接近阈值时限制长上下文或转入低优先级队列，而不是等到 OOM 后再降级。

Pre-allocate 与 admission control

请求进入 engine 前应先估算输入 token、最大输出 token、潜在 KV block、优先级和预计执行时间。超过租户并发、最大上下文、GPU cache 或预算时，可以拒绝、截断、转异步、降低优先级或路由到其他模型。提前 admission control 比让请求进入 decode 后才 OOM 更容易解释，也避免已经消耗大量计算后才失败。

admission control 不能只看当前 GPU memory。还要看已经分配的 KV block、正在 prefill 的激活、等待中的 token budget、权重加载、通信 buffer 和 prefix cache。对每个请求建立保守的上界可能降低利用率，因此可以使用分层策略：短请求使用精确估计，超长请求要求预留，未知长度请求采用较低优先级并设置硬上限。

GPU 内存分区

推理节点应明确权重、KV、activation、workspace、通信 buffer 和临时 tensor 的内存上限。权重加载后，剩余显存不能全部交给 KV，因为 kernel workspace、CUDA graph、量化 scale 和异常路径仍需要空间。建议建立静态保留区与动态 cache 区，动态区根据水位触发 admission、驱逐或降级。

显存水位应有 soft limit 和 hard limit。soft limit 触发降低并发、停止接受长请求或淘汰低价值 prefix；hard limit 触发明确 OOM 保护和实例摘除。只依靠 CUDA OOM 异常通常太晚，可能导致多个请求同时失败并破坏 engine 状态。内存指标还要区分 allocated、reserved、active blocks、free blocks、fragmentation 和 pending allocation。

Qwen3-8B：从配置到候选并发

这里做可复算的教学估计，不报告实际设备测试。来源是 Qwen 官方 Qwen3-8B/config.json，核验日期 2026-10-17，页面所示文件提交 47719a2：36 层、32 个 query heads、8 个 KV heads、head_dim 为 128、hidden_size 为 4096，默认 BF16 [9]。不能把 32 个 query heads 代入 GQA 的 KV 账本。部署时还需冻结完整模型 revision、检查点文件哈希和运行时；这里引用的主分支地址可能变化，因此这些字段与日期一起构成推演输入。

按名义 8×10^9 参数和每参数 2 字节，裸权重约 16,000,000,000 字节，即 16 GB 或 14.901 GiB。模型名的 8B 是近似，不代表检查点精确参数数；实际权重还要逐 tensor 统计，不能将此值当下载文件大小。普通完整注意力 KV 每序列每 token 为 2×36×8×128×2=147,456 字节；第一个 2 代表 K 与 V，最后的 2 是 BF16 字节数。8192 个已缓存 token 占 1,207,959,552 字节，恰为 1.125 GiB；输入与已生成输出都计入长度，预留最大输出时应使用预计总缓存长度。

因此只得到候选上限 floor(6.099/1.125)=5；不代表五并发满足 TPOT，也不保证真实工作区低于 2 GiB。若每条总缓存长度翻倍，上限至少重新计算；若使用 block pool，应按实际 block 尾部取整。INT4 裸权重名义约4 GB，仍有scale、zero point、padding和反量化工作区；权重降精度并不会自动把 BF16 KV 缩小四倍。多卡时按各 rank 的权重/KV实际分片和复制建账，不把所有项机械除以 TP 数。这里的容量边界同时适用于更大模型，换模型先换结构与精度输入，不能只按70B与8B的比例缩放全部账本。

9.3 KV 与缓存的层次

KV 的内存账本

自回归解码会保存每层每个历史 token 的 key 和 value。粗略地说，KV bytes 与层数、KV heads、head dimension、序列长度、batch 和 dtype 成正比。使用 GQA 或 MQA 可以减少 KV heads，但不会消除长上下文的线性增长。服务端内存账本至少包括权重、KV cache、activation、通信 buffer、CUDA graph workspace、tokenizer buffer 和 allocator 碎片。

一个请求的 KV 生命周期从 prefill 产生开始，随着 decode 追加 token，直到完成、取消、超时或被驱逐。若模型使用 beam、并行采样或多候选推理，KV 可能被复制或引用共享。服务端要记录 block owner、引用计数、模型版本、租户和过期时间，不能只依赖 Python 对象回收。PagedAttention 将 KV 切成固定大小 block，让动态请求不再需要连续大块显存 [1]。

缓存省去旧 token 的投影和重复前向，新 token 仍要读取历史 K/V 做注意力，因此不把完整注意力的成本自动降为线性。滑动窗口、MLA 等结构须按实际表示重建账本；KV 也不是 Agent 的业务记忆。

分页分配与碎片

连续分配容易产生外部碎片：短请求结束后留下许多小洞，长请求仍无法获得连续空间。分页分配把 cache 切成 block，逻辑 token 序列通过 block table 映射到物理显存。申请、追加、释放和回收类似虚拟内存，但要考虑 GPU allocator、block size、引用计数、copy-on-write 和跨 stream 同步。

block 太小会增加 table、调度和 kernel 访问开销，太大会增加内部碎片，尤其对短请求不划算。block size 要在真实请求长度分布上压测，不应只用固定长度 benchmark。指标包括 cache 利用率、内部碎片、block 分配耗时、回收延迟、OOM 次数和重新计算比例。vLLM 的实现将这类内存管理与连续批处理结合，是一个重要的工程参考 [10]。

Prefix Cache

系统提示、工具 schema、few-shot 示例和共享文档经常形成重复前缀。Prefix cache 可以复用已计算的 KV，减少 prefill 时间，但 cache key 必须包含完整 token prefix、模型版本、tokenizer、模板、位置编码、租户和权限范围。只按字符串前缀匹配而忽略模板或权限，会造成错误结果甚至跨租户泄露。

prefix cache 需要租约、淘汰、失效和安全清理。模型升级、系统提示变更、工具 schema 变更、量化变化和 LoRA adapter 变化都可能使旧 cache 不再兼容。缓存命中率不是唯一指标，还要看命中带来的 TTFT 降低、内存占用、失效成本、冷启动和跨模型边界。高动态请求不一定适合缓存；稳定长前缀才可能覆盖管理成本。

Cache 与取消、重试的交互

请求取消后，已经完成的 prefix KV 可以保留，也可以立即回收；选择取决于命中概率、租户策略和隐私要求。decode 中途取消时，部分输出对应的 KV 不能被另一个请求直接复用，除非它是明确的公共前缀并通过权限校验。服务重试时，如果新请求使用了同一个 idempotency key，应该查询原请求状态，而不是无条件重新分配一份 KV。

cache 泄漏通常不是显式的数据返回，而是命中率、延迟和错误模式泄露。高敏感租户可以禁用跨请求 prefix cache，或使用加密、独立 namespace 和更短 TTL。观测系统也不应把完整 token 序列作为 cache key 日志记录。OpenTelemetry 和 Prometheus 可以记录 cache hit、block 数和释放时间等摘要指标，但样本内容仍需按数据等级保护 [11][12]。

Block table 的一致性

PagedAttention 依赖逻辑 token 到物理 block 的映射。调度器增加 decode token 时，先检查 block capacity，再更新 block table，最后提交 kernel；释放时先阻止新的 kernel 引用，再减少引用计数。这个顺序不是实现细节，而是并发正确性的基础。多个请求共享 prefix 时，copy-on-write 要确保一个请求追加 token 不会修改另一个请求的只读 block。

block table 更新可以与 GPU stream 异步进行，但需要版本号或事件 fence 防止 kernel 读取旧映射。服务取消、超时和实例 drain 时，仍在执行的 stream 可能持有 block；立即释放会造成内存错误。可靠的 cache manager 应支持 deferred free，并在 trace 中记录 block 从 active 到 reclaimable 再到 free 的时间。

Cache 驱逐

当 KV 水位达到 soft limit，系统需要选择驱逐对象。候选因素包括最近访问、前缀长度、租户优先级、重算成本、剩余 TTL 和请求是否仍在 decode。驱逐一个长 prefix 可能释放很多 block，却会让后续请求重复 prefill；驱逐短且高频 prefix 可能释放较少空间但降低命中率。LRU 只是起点，不一定适合多租户和长上下文。

驱逐不能影响正在执行的请求。可以先标记新请求不可引用，等待引用计数为零，再回收 block；若需要立即释放，应把请求迁移或重新计算。驱逐事件要计入成本和 TTFT，避免平台为了追求内存利用率而造成隐性重算。对敏感数据，TTL 和显式清理优先于命中率。

实例重启与 KV 丢失

KV cache 通常是可重建状态，实例重启后不必持久化全部 KV，但必须处理用户体验和容量。正在 streaming 的请求可以失败并返回可重试错误，也可以迁移到新实例并重做 prefill；重做会增加 TTFT 和 GPU 负载。是否迁移取决于输入可重新获得、请求是否包含敏感数据、已输出 token 数和业务 deadline。

如果服务支持 prefix cache 的持久化或跨实例共享，还要处理版本、拓扑、dtype、权限和损坏。跨节点传输 KV 可能比重新 prefill 更快，也可能因为网络拥塞更慢。DistServe 的 prefill/decode 分离说明，状态传输本身是新的系统边界，必须以 workload、网络和 SLO 证明收益 [4]。任何共享 cache 都要有校验、过期和安全隔离。

四种缓存不能共用一套命中语义

vLLM APC 官方说明复用共享前缀的计算，收益集中在 prefill，不能据此承诺 decode 等比例加速 [13]。其 V1 设计将前块hash与当前block内容等信息组合，支持在首块加入 cache_salt 来限定复用范围 [14]。平台应由服务端认证后的租户域生成或约束salt；客户端自己填写某个salt不是访问授权。模型、adapter与多模态内容也须按实现支持的边界进入兼容判断。稳定规则、工具序列和公共参考置于动态问题前有助命中，但不能改变指令优先级，也不能为了稳定前缀保留已撤权内容。商业API的缓存资格、费用和保留时间按各自版本另行核验；本章不把一个自托管实现等同于所有供应商或Agent客户端的实现。

GPTCache 是基于语义相似性复用响应的公开实现参考 [15]，它不构成业务等价性证明。例如“我可以报销吗”与“我不可以报销吗”高度相似，却可能需要相反回答；同一句问题换主体、政策日期或金额也会改变结果。本书建议先以租户、授权范围、知识与政策版本做硬过滤，再在该域内检索候选；对否定、条件、实体、时间逐项校验，拿近似但答案不同的负例校准阈值。高风险审批、余额和实时库存可以禁用语义响应复用；有副作用的操作不能因缓存命中重新执行。指标需有抽样误命中率、人工投诉、过期命中和每成功任务成本，命中率上升而质量下降必须收紧或停用。

撤权、删除、知识发布和模板升级触发失效事件；删除索引项还应删除载荷和派生缓存，失败时阻止旧项继续命中。精确缓存也不是天然安全：若key遗漏用户授权或上下文，字节相同的文本仍可能对应不同答案。缓存结果绑定来源和生成时间，返回前重新检查当前访问权限。少发无关历史有时比提高命中率更省，压缩改写会损失旧prefix命中，验收仍以相同质量下的总费用与端到端时延为准。

9.4 Batching、背压与公平调度

从静态 batch 到 iteration-level

传统 batch 等待一组请求同时开始、同时结束；生成长度不同会导致短请求完成后 GPU 空闲。Orca 提出的 iteration-level scheduling 允许请求在每次迭代加入或退出 batch，continuous batching 由此提高了动态 workload 的利用率 [2]。但调度器需要在每个迭代点同时处理 prefill、decode、KV 分配、取消、优先级、deadline 和错误。

一次调度决策至少选择：本轮处理哪些请求、每个请求分配多少 token、是否插入新 prefill、是否保留 decode slot、是否驱逐低优先级任务。只按 FIFO 会让长 prompt 阻塞短请求；只按短请求优先会让长任务饥饿；只追求最大 batch 会违反 TTFT。实际策略通常使用 token budget、deadline、优先级、租户配额和公平轮转的组合。

Prefill 与 decode 的混合调度

Prefill 的计算密集程度高，decode 的迭代频率高。若一个长 prefill 独占 GPU，正在 decode 的请求会停顿；若完全优先 decode，新的请求 TTFT 会变差。调度器可以限制每次 prefill 的 token budget，把长输入切成 chunk，与 decode 交替执行。Sarathi-Serve 的研究说明，chunked prefill 能在吞吐与延迟之间取得更好折中 [3]。

chunk size 需要在模型、硬件和 workload 上调优。太小增加 kernel launch 和调度开销，太大仍会阻塞 decode；不同长度请求可能需要不同 chunk。调度器要记录每次 chunk 的等待、执行、抢占和 cache 分配，才能解释 TTFT 和 TPOT 的变化。长请求还应有最大输入、最大输出、总时间和租户 token 预算。

公平性与优先级

交互式问答、批量离线、评估、Agent 工作流和内部开发对延迟的要求不同。可以按 tenant、product、request class 和 priority 建立队列，但高优先级不等于无限资源。每个队列需要并发上限、token budget、最大等待时间和借用规则；否则一个高优先级租户的突发会耗尽所有 KV block。

公平策略还要关注请求的资源大小。按请求数公平会偏向长请求，按 token 公平可能让大量短请求被饿死。可以使用虚拟时间、加权 token 份额或 deadline-aware scheduling，并把实际资源消费写入成本归因。Borg 的优先级、配额和故障域经验说明，公平调度是控制面职责，不应由调用方通过反复重试来争抢 [16]。

取消、超时与背压

取消需要从网关传到调度器、engine、GPU stream 和 cache manager。重复取消必须幂等，已完成请求不能被覆盖；超时要区分排队超时、prefill 超时、decode 超时和下游发送超时。连接断开不一定意味着任务取消，若产品允许异步完成，服务端应转移状态并释放流式连接。

背压可以发生在多个层面：网关限制并发和请求体，调度器限制 queued token，engine 限制 cache block，结果流限制发送缓冲，计费和观测限制写入速率。资源不足要返回可重试或不可重试的明确错误码，安全拒绝不能被无限重试。重试前必须考虑生成非确定性和工具副作用。

批处理与离线推理

离线推理可以使用更大 batch、更长队列等待和更高 GPU 利用率，但不能与在线服务共享一个无界队列。离线任务应有 job id、输入 manifest、输出 manifest、checkpoint 或断点游标、重试和幂等写入。输出写入对象存储时按 shard 提交完成标记，避免下游读取半成品。批任务的失败不能让在线队列被拖慢。

在线与离线共享权重时，权重加载和 cache 仍会相互影响。可以使用独立 GPU 池、低优先级抢占、时间窗口或限制离线 token budget。若必须共享，调度器按 token、deadline 和显存水位做隔离，并在离线任务启动前确认不会影响在线错误预算。离线吞吐高不代表系统成本低，必须计入等待、重试、输出存储和失败数据。

连接池与慢客户端

流式服务的网络连接、HTTP/2 stream、WebSocket、发送 buffer 和代理超时都会占用资源。慢客户端如果持续不读取，会阻塞服务端发送并保留 KV；平台需要写超时、发送 buffer 上限、心跳和明确的断开语义。连接数、活跃流、平均发送速度和断开原因应进入指标。

网关和 engine 的超时不能随意叠加。网关 timeout 小于 engine 生成时间会导致客户端断开但 GPU 继续工作；engine timeout 小于工具或下游 timeout 会产生重复重试。请求应携带 deadline，所有组件根据剩余时间决定是否接纳、继续 prefill、停止 decode 或返回 partial result。deadline 需要在 trace 中传播，避免各层使用不一致的本地超时。

防饥饿与跨层预算

只有优先级没有最低服务份额时，高优流量持续到达会使低优队列永久等待。可为各等级保留可验证的份额并按等待时间老化；超出容量时返回排队超时，不承诺所有等级都准时完成。出队还受可用KV、token budget和下游工具容量约束。Agent的工具扇出需在上层Runtime限制：三个只读且独立的查询可以并行，存在依赖或冲突的步骤必须串行；不能把GPU的batch策略直接用作外部工具调度算法。

9.5 执行优化与解耦

副本扩展与模型并行

模型能放进单 GPU 时，副本扩展通常简单且容易隔离故障；模型放不进单卡时，需要 tensor parallel、pipeline parallel 或 expert parallel。TP 把矩阵计算切到多个 GPU，每个 token 需要 collective；PP 把层切成 stage，带来 pipeline bubble；EP 为 MoE 路由 token，带来 all-to-all。并行度越大不一定越快，必须结合拓扑、batch、序列长度和通信占比测量。

路由层需要知道副本健康、模型版本、GPU 可用 KV、队列、拓扑和租户。round-robin 不能处理一个副本正在加载模型、另一个副本 cache 已满的情况。模型并行副本的故障域也不同：同一 TP group 中一张卡故障可能使整个 group 不可用，副本级扩展则可以摘除一个副本。发布和容量控制应以逻辑副本为单位。

Tensor parallel 的通信边界

TP 适合同机高速互联，因为每层可能需要 all-reduce 或 all-gather。NCCL 根据 GPU、PCIe、NVLink、网卡和网络拓扑选择路径，但服务端仍需记录通信耗时、消息大小和 rank 方差 [17]。跨节点 TP 在低并发 decode 里尤其容易把通信延迟暴露到每个 token。若模型已经能通过量化或 offload 放入单节点，减少 TP 可能比扩展到更多节点更适合在线 serving。

量化的系统影响

INT8、INT4、FP8 等量化减少权重显存和带宽，但会改变 kernel、校准、激活 outlier、精度和输出质量。量化不是一个简单配置开关：不同层、不同通道、KV cache 和 embedding 可能需要不同精度。TensorRT 的精度与执行路径受构建和硬件约束；TGI 在核验日已进入维护模式，历史功能存在不等于持续新增支持。无论使用哪个 runtime，发布前均需固定质量集和目标 workload [5][18]。

量化验收至少包括权重大小、显存峰值、冷启动、TTFT、TPOT、吞吐、长上下文、结构化输出、代码任务和安全拒答。不能只看平均困惑度；小概率 token 错误可能导致工具 schema 或 JSON 失败。量化制品要和校准数据版本、算法、dtype、硬件架构和 engine build 绑定，回滚时同时回滚这些对象。

反量化同样消耗计算与访存：只有节省的权重读取超过反量化和额外kernel代价时，特定负载才可能变快；小batch或不支持的shape可能退化。量化算法与校准原理沿用第5章，不在这里重推。

编译与 CUDA Graph

Torch compile、CUDA Graph、kernel autotune 和 TensorRT engine 可以降低 launch overhead，但通常要求固定或有限的 shape、内存地址、batch 和控制流。动态 batch、长短请求混合、流式生成和取消会增加图捕获与回退复杂度。固定 shape 的 graph 适合稳定 decode bucket；不规则 prefill 可能需要 eager 或多个 graph。

编译缓存必须包含模型 hash、GPU 架构、driver、CUDA、输入 shape、精度、engine 版本和环境变量。冷启动和热启动要分别测量，避免第一批用户承担编译成本。编译失败应回退到已验证的 runtime，但回退路径需要独立监控，否则性能悄悄下降却只表现为 GPU 利用率变低 [19]。

Draft 与 verify

投机解码使用较小的 draft model 生成候选，再由 target model 一次验证多个 token。若验证接受率较高，target model 可以减少逐 token 迭代；若接受率低，额外的 draft 计算和 KV 管理会抵消收益。Leviathan 等人的方法说明，在保持目标分布等价的条件下，投机解码可以加速生成 [20]；speculative sampling 进一步讨论了采样场景的接受规则 [21]。

服务端需要为 draft 和 target 管理权重、KV、调度和 GPU。draft 可以与 target 共卡、独立副本或使用 CPU，选择取决于模型大小、接受率、网络和并发。每个请求还要记录候选长度、接受 token 数、拒绝位置、draft 时间、verify 时间和额外显存。低接受率、短输出和高并发场景可能不适合投机解码。

与 batching 的交互

投机解码改变了一个 iteration 生成 token 的数量，调度器不能再假设每个请求每轮只追加一个 token。KV block 需要预留候选空间，并在拒绝后回滚未接受 token；多个请求的候选长度不同，batch shape 更不规则。若 engine 没有高效的 block rollback 和 verify kernel，理论加速会被内存与调度开销吃掉。

投机解码也会改变容量指标。输出 token 数没有改变，但 target forward 次数下降、draft GPU 计算上升、内存带宽与通信模式变化。平台应分别报告目标模型调用、draft 调用、接受率、每个成功输出 token 的总 GPU 时间和质量一致性。不能把 target tokens/s 直接与未使用 draft 的 tokens/s 比较。

为什么分离

prefill 偏计算，decode 偏内存带宽和长期状态；混合部署时，长 prompt 的突发会抢占 decode，decode 的长尾又会占用 prefill 的资源。DistServe 将二者放到不同资源池，允许分别扩容和优化 goodput [4]。分离不是免费的，它增加 KV 传输、请求协调、故障重试、路由和网络容量。

是否分离取决于负载规模和请求分布。小规模、低并发或短输入 workload 可能无法摊平控制面和网络开销；输入长、输出长、SLO 分层明显的服务更可能受益。平台应通过混合部署基线、分离部署、不同网络带宽和故障注入比较真实 goodput，而不是只比较 GPU 数。

KV 传输协议

prefill 节点完成后，需要传输模型版本、请求 id、token 长度、position 信息、KV dtype、layer layout、block table 和数据校验。接收端确认后才开始 decode；传输中取消时要释放发送和接收 buffer。协议应支持大小、版本、压缩、重试、超时和 partial failure，不应把一个 Python 对象直接跨进程传递。

KV 传输可以使用高速网络、RDMA 或共享内存，但每种路径都有故障模型。网络拥塞时，传输队列会反过来占用 prefill 资源；接收端不可用时，发送端需要限流；序列化与反序列化会消耗 CPU。监控要包括 KV bytes、传输时间、等待时间、重试、丢弃和每个请求的端到端收益。

分离后的调度

前端调度器需要同时选择 prefill pool 和 decode pool。选择 prefill 时看计算队列、输入长度、模型版本和网络路径；选择 decode 时看可用 KV、decode slot、输出 deadline 和租户。prefill 完成但 decode 没有空间时，不能无限堆积已产生的 KV；可以延迟 prefill、转回混合池或暂存到受控内存。

这种调度本质上是一个有状态的流量分配问题。只按 GPU 空闲比例路由会忽略 cache 和传输；只按队列长度路由会把长请求集中到一处。路由决策要记录在 trace，便于分析某类请求的 TTFT 变差是因为 prefill、传输、decode 还是队列。

权重量化与 KV 量化

权重量化主要减少模型权重占用和读取带宽，KV 量化主要减少长上下文内存。两者误差来源不同：权重量化影响所有层计算，KV 量化影响历史上下文表示。KV 量化可能让更高并发成为可能，却在长对话、检索上下文或代码任务上产生质量变化。评估应按上下文长度、语言、任务和输出长度分层。

量化 scale、zero point、group size、校准数据和累加精度都需要写入制品 manifest。不同硬件可能使用不同 kernel，不能只在一种 GPU 上校验。若量化路径失败，回退到 FP16 可能导致显存不足；因此要预留清晰的降级资源或直接阻止不兼容模型进入该节点池。

Kernel 融合与 IO

FlashAttention 说明 attention 的性能受 IO 和片上存储影响，FlashAttention-2 进一步优化了并行划分 [22][23]。serving 中还要考虑 decode 的小 batch、动态长度和 KV layout，训练时有效的 kernel 不一定适合逐 token decode。性能实验必须包含 prefill、decode、混合 batch、cache 命中和长尾，而不是只测一个 attention kernel。

融合 kernel 可能改变错误传播、精度和调试能力。发布前记录 CUDA、driver、GPU 架构、编译选项和输入 shape；遇到 NaN、非法内存或输出差异时，可以复现构建。engine 应保留 eager 或非融合回退路径，用于诊断和灰度。回退路径的性能差异要有告警，避免所有请求悄悄进入慢模式。

静态图和动态请求

CUDA Graph 适合重复执行相同 shape 和内存布局，动态请求需要 padding、bucket 或多图缓存。bucket 太少会产生 padding 浪费，太多会增加编译和缓存，图切换还可能带来同步。应根据真实长度分布选择 bucket，并设置图缓存上限。请求在 graph 中执行时，取消和异常需要安全退出点，不能直接释放仍被 graph 引用的 buffer。

图缓存 key 不仅包括 batch 和 sequence length，还包括 dtype、模型版本、采样路径、量化、adapter 和设备。LoRA adapter 数量多时，为每个 adapter 编译图不可行，可以选择 eager、分组或只对高频 adapter 建图。发布新版本要原子切换图缓存，旧图在 drain 完成后清理。

PD与AF：两种不同的解耦边界

本节 AF 明确定义为 Attention/FFN disaggregation，即把注意力和前馈/专家模块放到不同资源。它不是“任意异步框架”的简称。MegaScale-Infer 是具体的 MoE 参考：decode 中 attention节点持有注意力权重和KV，expert节点持有专家；各节点内部可以用TP，节点间使用M2N通信，并以ping-pong微批流水掩盖依赖等待 [24]。这是该论文的实现范围，不意味着任何模型任意拆层都能获益。

PD改变阶段的放置：prefill完成后迁移已有历史KV，再由decode池迭代；AF改变每层模块的放置，在解码阶段内部仍需反复交换激活。PD解决输入计算与逐token服务互相干扰，不能消除decode内部attention与FFN的资源不均衡，尤其MoE会把batch分散到不同专家。AF允许独立聚合与扩容，但每层增加网络往返和同步，网络拥塞会直接出现在TPOT里。二者可组合，也都可以不采用。

粗略交通量可帮助判断瓶颈：PD的一次输入KV迁移按2L×H_kv×d×S×b字节增长；一个未分片、无专家复制的AF边界，batch中B个token送出与返回的激活粗估2B×hidden_size×b，每层重复。后者只是维度推导，MoE top-k路由、TP/EP分片、共享或重复传输会改变真实字节，不能照搬为论文实际网络量。比较时记录每层延迟、大块带宽、队列、KV驻留、微批大小与故障重试，在同SLO和质量下核算总GPU/网络成本。低负载、低接受率或慢网络时，继续共置可能更合适。

大词表选读：先分清投影、归约和采样

词表超过十万时，hidden到vocab的投影、logits写回、softmax归约、采样与跨卡候选合并都可能占时；先profile再选优化，不能断言瓶颈必为softmax。精确路径可用融合、向量化、稳定max/sum归约和词表分片，减少无用logprob落显存。贪心argmax不必显式归一化，但通常仍需投影；top-k/top-p改变采样分布，也不自动省去全部logits。层次或采样softmax常改变训练目标或模型结构，不能无训练地替换现有checkpoint并承诺精确等价。这里承接第4章生成分布和第8章归约，扩展仅限定这些设计边界，不交付新kernel或性能结论。

9.6 多模态与长上下文负载

长上下文的 admission

长上下文同时增加 prefill 计算、KV 容量、排队时间和输出阶段的内存保留。平台应在入口限制最大输入、最大输出、总 token、并发和租户预算，并根据请求类型选择同步、异步或低优先级队列。截断策略要保留消息边界、系统指令和工具 schema，不能简单从字符串尾部截断。

长上下文请求的公平性可以用 token budget 和 deadline 控制。一个请求占用大量 prefill 时间时，调度器应切块或暂时挂起；一个 decode 很慢的请求应有最大 wall-clock 或输出 token 限制。指标区分 queue、prefill、decode、cache wait 和 network wait，才能知道用户是在等待计算还是等待资源。

多模态输入

图像、音频和视频会先转换为视觉或音频 token，输入 token 数量和显存不一定与文本长度线性对应。图片分辨率、视频帧数、压缩、patch 数和视觉 encoder batch 都会改变 prefill 成本；不同模态还可能有不同 cache 可复用边界。serving 接口要记录原始模态大小、预处理版本、视觉 token 数和编码时间，不能只计费文本 token。

多模态模型可能共享语言模型权重，却需要额外的 encoder、预处理 CPU、GPU workspace 和跨模态 cache。调度器应区分 text-only、image、audio 和 video workload，避免大视频请求阻塞短文本请求。模型并行和设备放置要考虑 encoder 与 decoder 的通信，发布门禁要加入图片损坏、超分辨率、超长视频和错误 MIME 类型。

多轮对话与上下文压缩

多轮对话会不断增长输入和 KV。平台可以把历史消息重新 tokenize，使用 prefix cache，摘要压缩，检索相关片段或把旧轮次转为外部状态。压缩改变模型可见上下文，不能只视为性能优化；应记录压缩算法、摘要版本、保留消息和 token 预算。安全和权限信息不能在压缩时丢失，工具 schema 和系统指令必须按固定规则保留。

上下文压缩有不同成本：摘要需要额外模型调用，检索需要存储与索引，滑动窗口丢失旧信息，KV 复用占用显存。路由器可以依据任务类型、上下文长度、deadline 和租户预算选择策略。评估要比较压缩前后任务成功、引用正确、工具调用和延迟，而不只是输入 token 减少比例。后续数据与评估章节会把这些策略纳入回归集。

9.7 平台路由、隔离与发布

模型仓库与实例生命周期

模型实例经历 DOWNLOADING、LOADING、WARMING、READY、DRAINING、UNHEALTHY 和 TERMINATED。加载权重、构建 engine、预热 tokenizer、分配 KV pool 和运行 probe 都属于启动过程；只有 READY 才能接收流量。滚动发布时，新旧实例同时存在，平台需要预留双份权重和 cache，容量模型必须计入这段峰值。

Triton 的模型仓库与版本管理提供了服务编排参考 [6]。生产平台还应把 instance id、模型 hash、engine hash、GPU、拓扑、启动耗时、预热结果和健康状态写入注册表。实例被摘除后，应停止接收新请求，等待或迁移正在执行的请求，释放 cache，再回收 GPU。强制终止会造成部分流和重试，必须进入故障指标。

路由与降级

路由依据可以包括模型能力、版本、区域、租户、数据驻留、价格、当前队列、KV 水位、GPU 类型和 deadline。fallback 模型不能只满足接口兼容，还要经过任务质量、安全和成本评估。所有路由结果、降级原因和策略版本写入 trace，方便解释一次请求为什么没有使用主模型。

流量突发时可以采用限流、排队、降级采样参数、降低最大输出、切换小模型或转异步。降级顺序应由产品定义，安全策略和工具权限不能因为资源不足而被跳过。对高价值任务，可以保留容量池；对低优先级离线任务，可以使用抢占式资源。Kubernetes 的 GPU 调度只解决资源发现和分配，真正的业务降级仍需平台控制面 [25]。

灰度、影子与回滚

模型灰度可以按租户、地区、请求类型、流量比例或实验分组进行。影子流量执行新模型但不触发工具副作用，用于比较延迟、长度、格式和质量；正式灰度才承担真实响应。灰度指标包括 HTTP 错误、TTFT、TPOT、p99、OOM、cache 命中、停止原因、结构化输出成功率、工具调用成功率、拒答率和单位成本。

回滚需要同时回滚权重、tokenizer、模板、量化 engine、adapter、路由、cache 版本和安全策略。新版本创建的 prefix cache 不能默认给旧版本使用；旧版本在当前 driver 和 GPU 上也必须仍能启动。发布系统应保留最近可用制品、健康 probe 和回滚演练记录，不应只把一个 tag 改回旧值。

租户级资源账本

租户配额应覆盖请求数、输入 token、输出 token、KV block、并发模型、优先级、工具调用、cache 占用和预算。只限制 QPS 无法防止一个租户发送超长上下文；只限制 token 无法防止大量短请求占用连接和 CPU。计量系统要记录 accepted、rejected、queued、generated、cancelled 和 failed 的资源，明确是否计费。

共享权重通常可以只读共享，adapter、KV、prefix cache、日志和工具状态则需要隔离。租户 id 不能只作为日志字段，还要进入 cache key、路由、凭证和访问控制。不同数据地域或合规等级的请求不能因为同一模型副本空闲而跨区域路由。权限检查应发生在 admission 和工具执行前两个阶段。

配额借用与公平

固定配额容易产生碎片：某租户空闲时，其他租户却排队。可以允许短期借用空闲 token budget，但设置最大借用、归还优先级和高峰抢回。借用的资源要可追溯，避免月底账单无法解释。高优先级请求可以抢占排队中的低优先级请求，但不应粗暴杀死已经输出大量 token 的 decode，除非产品明确允许。

公平调度还要避免通过拆分请求绕过配额。平台按 request id、parent task、tenant 和 operation 统计，Agent 的多步调用共享预算。超预算时返回结构化错误，让上层可以结束任务或转人工；不要默默降低安全检查、扩大重试或切换到未经评估的模型。

Serving runtime 的选择边界

不同 runtime 解决的问题不同。vLLM 是执行和KV管理的工程参考；TGI 是已有服务实现，核验日处于维护模式；TensorRT体现编译与执行引擎层；Triton负责模型管理和服务层 [10][18][5][6]。这些对象不在同一层级，不能当四个等价替代项。选型时不能只比较启动命令或单一 benchmark，而要比较动态 batch、长上下文、量化、adapter、流式、工具协议、观测和回滚。

一个实际平台可以分层组合：网关负责鉴权、限流和协议；路由负责模型版本、租户和区域；serving engine 负责执行与 cache；模型仓库负责 artifact；Kubernetes 或其他调度器负责 GPU；观测系统负责指标、日志与 trace。组合的代价是接口和故障边界增多，因此必须定义 request manifest、model manifest、错误码和状态事件。若把多个组件拼在一起却没有统一契约，替换其中任意一个都会改变行为。

多进程与多模型共存

同一节点部署多个小模型可以提高利用率，但会引入权重竞争、KV 竞争、编译缓存竞争和尾延迟相互影响。多进程隔离较强，却可能重复加载 CUDA context 和权重；单进程多模型共享资源效率高，却需要更复杂的模型选择和内存回收。模型路由必须把可用 cache 和切换成本纳入决策，不能只看当前请求数。

模型切换包括加载权重、初始化 kernel、分配 KV pool、预热和释放旧模型。如果加载期间占用同一 GPU，会造成在线请求抖动；如果使用双份显存，又需要容量余量。可以把冷门模型放到独立池，或采用异步加载和模型驻留策略。每个模型要有最小驻留时间和最大空闲时间，避免流量抖动导致反复加载。

Adapter 与 LoRA serving

一个基础模型可能服务多个 LoRA adapter。共享 base weight 能降低显存，但每个请求需要选择 adapter、加载或缓存 adapter，并确保 batch 中不同 adapter 的执行路径正确。adapter cache 有容量、淘汰、租户隔离和版本兼容问题；将不同 adapter 合并进同一个 batch 可能增加 kernel 或权重访问开销。

adapter manifest 应包含 base model hash、adapter hash、训练数据等级、rank、dtype、目标层和安全标签。base model 升级后旧 adapter 不一定兼容，不能只按 adapter 名称加载。灰度时同时比较 base-only、adapter 和 fallback 的质量、延迟、显存和工具成功率。adapter 的下载权限与缓存权限也必须分开，避免低权限租户读取其他租户的制品。

生成质量与系统回退

系统回退不仅是换一台 GPU 或换一个副本，也可能改变模型、精度、采样、上下文、工具和安全策略。每种回退路径都需要能力声明和质量基线，例如小模型是否支持 JSON、视觉输入、工具 schema 和最大上下文。路由器根据请求能力选择兼容 fallback，不能把任意文本模型作为通用后备。

回退事件要对调用方透明且可追踪。响应中可以返回 model revision、degraded flag 或 warning，trace 中记录原因和候选模型。对安全敏感请求，若没有满足策略的 fallback，应快速失败并引导人工，而不是使用未经审核的模型。质量回退、延迟回退和成本回退应分别计入指标，便于决定是否扩大容量或修复主路径。

版本兼容矩阵

生产平台应维护模型版本、tokenizer、template、engine、量化、adapter、GPU 架构和驱动的兼容矩阵。矩阵不是静态文档，而是发布控制器可以读取的约束。例如某 adapter 只兼容特定 base hash，某 engine 只支持特定 compute capability，某 cache 只支持某种 KV dtype，某模板版本改变了 special token。加载前做校验可以把复杂错误提前到部署阶段。

兼容矩阵还要包括 API 和质量能力。一个小模型可能支持文本和 JSON，却不支持图像或工具；一个降级模型可能没有同样的上下文长度；一个量化版本可能在代码任务上低于质量门限。调用方通过能力声明选择模型，路由器在请求前验证能力，不应等到生成中途才失败。发布登记时记录矩阵版本，回滚时恢复相同矩阵。

数据驻留与跨区域路由

多区域服务需要在路由前判断数据驻留、租户合规、模型制品可用、网络延迟和容量。把请求路由到更近区域可以降低 TTFT，却可能违反数据区域；把请求路由到有空闲 GPU 的区域可以提高 goodput，却增加跨区域传输和故障面。请求 manifest 应携带 region、data class 和允许的 fallback 区域，路由决策写入审计。

跨区域故障时，系统应区分可迁移和不可迁移请求。纯文本、无敏感数据且没有副作用的请求可以重试到备用区域；包含敏感上下文或外部工具状态的请求可能只能失败或转人工。区域间共享 prefix cache 和 KV 通常有更高风险，默认不共享，除非具备加密、权限、版本和删除保证。

推理服务的安全降级

资源压力不应导致安全校验被跳过。限流、降级模型、截断和异步化都必须经过相同的输入安全、输出安全和工具权限策略。安全服务本身不可用时，平台应选择拒绝、有限能力或人工，而不是默默放行。安全决策的版本、结果、超时和 fallback 写入 trace，敏感内容只保留受控摘要。

结构化输出和工具执行尤其需要安全边界。模型生成的 JSON 只是未可信输入，必须做 schema、权限、参数范围和目标资源校验；工具返回的内容也可能进入下一轮上下文，需要标记来源和可信级别。推理 Infra 负责提供执行前的拦截点、审计和幂等，不能把所有安全责任推给 prompt。

运行时升级的逐级验证

runtime 升级可分为离线兼容、单实例 canary、影子流量、小比例正式流量和全量。离线阶段验证加载、输出、量化、最大长度和错误语义；单实例阶段验证冷启动、显存、cache、batch 和 drain；影子阶段比较真实长度与路由；正式灰度阶段观察 SLO、质量、成本和租户差异。每一步都有停止条件和回滚版本。

如果新版本只在特定 GPU 或特定长度变差，整体平均可能看不出来。因此灰度指标按模型、硬件、长度桶、租户、输入语言、请求类型和 adapter 分层。监控系统要避免标签爆炸，但可以把高维分层放在 trace 和离线聚合中。发布控制器依据分层门禁，而不是单一全局平均。

网关的尝试、额度与部分输出

公共协议统一消息与错误外形，能力矩阵仍要显式登记结构化输出、工具消息、窗口、媒体、拒绝语义和区域许可。网关数据面鉴权、准入、适配和转发；控制面维护凭据及版本化策略，凭据不能进入模型可见prompt。配额存储不可用时，只有持有未过期、可审计本地额度且策略允许的请求可继续；需要强一致金额或敏感校验的请求应拒绝或排队。配置快照有有效期，不设置无保护全量旁路。

一个逻辑request可以有多个attempt。流式前原子检查并预留输入、最大输出和必要下游预算，同账户并发预留必须同时扣除在途金额；每次预留、扣减和最终退款都有稳定ID并幂等。完成后按usage结算，断流未知用量保留待对账，不能记成零费用。诊断费用翻倍时，按任务版本比较轮次、输入输出、cached read/write、Embedding、Rerank、工具、存储和judge用量，再看重试、路由和失败任务；QPS不变不代表工作量不变。

主模型未输出时可在预算、能力及数据策略允许下切换；已输出一半时，旧结果标记中断，备用结果作为新版本或独立结果交付，不能无缝拼接互相冲突的答案；工具已经执行时沿用原业务operation核查事实，不重新发明副作用。超预算停止新增步骤并交付明确partial状态，不能把截断JSON当成功。缓存、压缩和批处理优化都需要质量门禁，目标是每成功任务成本。

9.8 性能诊断、事故与验收

推理 SLO

服务 SLO 应按产品场景分层。交互式请求关心可用性、TTFT、TPOT、p99 和流式完成率；批量任务关心完成时间、goodput 和单位成本；Agent 任务关心最终成功、工具一致性、人工接管和总时延。HTTP 200 不代表生成成功，部分流、错误 JSON、工具参数不完整和安全策略失败都应有明确结果状态。

错误预算可以决定是否继续灰度、是否暂停性能实验、是否保留更多容量。SLO 还需要质量门禁：量化或 batching 如果提高吞吐却让代码任务、结构化输出或安全指标回退，不能算达标。SRE 方法提供了把可靠性与发布决策连接起来的框架 [8]。

Metrics、Logs 与 Traces

Metrics 记录吞吐、队列、TTFT、TPOT、KV 使用、block 分配、cache 命中、GPU 显存、OOM、取消、重试和路由；logs 记录具体错误、模型 hash、engine、节点和状态；traces 连接网关、tokenizer、调度器、prefill、decode、工具和计费。Dapper 的追踪思想和 OpenTelemetry 的语义约定适合把一次请求跨组件串起来 [26][11]。

默认不记录完整 prompt 和输出。使用 prompt hash、token 数、长度分桶、采样摘要和脱敏后的错误上下文，必要时通过受控诊断流程临时提升采样。Prometheus 指标标签要避免完整 request id、租户自由字符串和 token 内容造成高基数；详细信息放结构化日志或 trace event [12]。

成本归因

在线成本不应只按 GPU 小时计费。一次请求的成本包括权重占用、prefill、decode、draft、KV 保留、cache miss、网络、CPU tokenizer、工具调用和重试。可以按输入 token、输出 token、GPU 时间和成功任务组合归因，并区分模型版本、租户、项目和业务场景。prefix cache 命中需要记录节省的计算，同时也要计入 cache 内存和失效成本。

成本优化要和质量、SLO 同时看。降低最大输出 token 可以降低成本，却可能降低任务成功；激进 batching 可以提高平均吞吐，却增加长尾；更低精度可以节省显存，却增加重试和人工审核。因此，系统优化不能脱离输出质量和任务目标，任务成功率与资源报告必须并列。

典型故障

常见事故包括模型加载失败、权重损坏、tokenizer 不匹配、量化 kernel crash、KV OOM、GPU Xid、NCCL hang、节点网络故障、对象存储不可用、流式连接堆积和慢客户端。每种故障应定义检测信号、影响范围、自动动作、人工动作、恢复时间和是否丢失请求。把所有故障都归类为 5xx，会让容量、质量和数据泄露问题无法区分。

降级与恢复

实例故障时先摘除健康检查失败的副本，停止新请求并 drain；网关将新请求路由到兼容副本或异步队列。正在 decode 的请求可以失败重试、迁移重算或继续等待，决策取决于 deadline 和副作用。模型主版本不可用时，fallback 需要保持接口、安全、工具权限和质量边界。降级事件进入错误预算与事故报告。

恢复后要检查 cache 是否释放、队列是否回落、p99 是否恢复、GPU 是否降频、工具状态是否一致、重复请求是否产生副作用。仅看到 Pod Running 不代表服务恢复。Dapper/OpenTelemetry trace 能帮助确认故障影响是否从网关传播到 engine 和下游 [26][11]。

演练设计

每月可以执行一次小规模节点故障、一次 KV OOM、一次模型回滚和一次流式断开演练。注入动作应可撤销，先在影子流量或隔离租户验证，再进入生产候选池。演练结束保存请求样本摘要、指标、trace、资源释放、恢复时间和人工操作。失败的演练要转为发布门禁，而不是只写在复盘文档中。

压测模型

推理压测应使用真实长度分布而不是固定 prompt。至少构造短输入短输出、长输入短输出、短输入长输出、长输入长输出、prefix 高命中、prefix 低命中、结构化输出、工具调用和突发流量八类 workload。每类记录 arrival process、并发、deadline、取消比例和租户混合，并分别比较混合部署与 prefill/decode 分离。

压测工具要区分客户端等待、网关排队、调度等待、prefill、decode 和网络发送。若只从客户端测总延迟，无法知道瓶颈；若只测 engine，不包含真实连接和 tokenization，又会高估服务能力。压测完成后保留配置、模型制品、原始事件和环境，保证下一次升级能做回归，而不是重新猜测基线。

性能回归门禁

回归门禁可以设为多目标约束：TTFT p95 不超过基线某个比例，TPOT p95 不超过阈值，goodput 不下降，显存峰值不超过容量，质量指标不低于容差，错误和取消率不增加。不同 workload 可以有不同权重；不能用一个总体平均掩盖长上下文或高价值任务退化。

当新版本提升平均吞吐但降低 p99，应根据业务 SLO 判断是否接受；当量化降低成本但工具成功率下降，应检查单位成功任务成本；当 prefix cache 提升命中但隐私风险增加，应优先修复隔离。门禁结果要附带解释和失败样本，发布控制器只依据明确策略自动决策，复杂回退进入人工评审。

推理平台的状态机回放

事故排查最有效的方法之一是回放一个 request 的状态机：何时被接收，排队多久，何时分配 KV，经历几次 prefill chunk，生成多少 token，是否发生 cache 命中、迁移、重试、取消和回退。回放数据来自 request event、metrics 和 trace，必须使用同一个 request id 和单调序列。没有状态回放，工程师只能从多组件日志按时间猜测，容易把因果顺序弄错。

状态回放也可用于测试。给定一组事件，验证重复取消不会泄漏 block，失败迁移不会重复工具，实例 drain 会停止新请求，cache 版本不兼容会被拒绝，deadline 到期会释放资源。把这些规则写成状态机测试，比只做 HTTP happy path 更能覆盖 serving 的真实复杂度。

Engine 的兼容性测试

升级 runtime 时，功能测试要覆盖单请求、动态 batch、流式、取消、最大长度、结构化输出、工具调用和多模态；性能测试要覆盖不同输入输出长度和并发；资源测试要覆盖显存、KV block、编译缓存和冷启动；故障测试要覆盖 engine crash、GPU reset、模型加载失败和滚动 drain。测试结果绑定 runtime、模型、driver 和硬件 hash。

兼容性还包括错误语义。某个版本把超长输入返回 400，另一个版本可能截断后返回 200；某个版本把客户端断开视为取消，另一个版本继续生成；某个版本在 tool call 失败时返回 partial output，另一个版本返回 error。上游服务依赖这些差异，不能只用“文本看起来一样”判断兼容。API contract test 和状态机 test 是 serving 平台的必要组成。

请求迁移

请求迁移可以发生在实例 drain、节点故障、负载均衡或 prefill/decode 分离时。迁移分为重新发送完整输入、传输已有 KV、只迁移请求状态和放弃当前请求。重新 prefill 简单但延迟高；传输 KV 需要网络和版本兼容；只迁移状态而不迁移 cache 会导致状态与资源不一致。迁移策略必须声明可接受的重复计算和输出连续性。

流式请求迁移更复杂。旧实例可能已经发送部分 token，新实例继续生成时必须保持上下文、采样随机状态和停止条件。若产品只保证最终文本，不保证 token 级连续，可以在事件中标记重连和重算；若要求严格连续，需要持久化更多 decode 状态。大多数系统应优先让迁移发生在 prefill 完成前或请求边界，避免把所有状态都做成可迁移。

功能验收

固定验证集需要覆盖普通生成、空输入、超长输入、最大输出、停止词、流式、取消、重复请求、结构化 JSON、工具调用、多模态错误和非法参数。每个场景验证状态迁移、错误码、资源释放和审计字段。对 streaming，要测试客户端中途断开、服务端重启、重连和部分结果；对工具，要测试超时、重试、重复提交和副作用幂等。

性能与容量验收

性能测试固定模型、硬件、engine、tokenizer、输入输出分布和并发曲线，分别报告 cold start、warm start、TTFT、TPOT、E2E、p50/p95/p99、goodput、显存峰值、KV 水位、cache 命中和 GPU 利用率。容量测试加入长尾长度、突发流量、节点故障和滚动发布，验证 failover reserve 与 deployment reserve 是否真实存在。

质量、可靠性与治理验收

质量测试比较原始精度、量化、kernel、batching、投机解码和降级模型的任务指标；可靠性测试注入 worker OOM、节点故障、网络抖动、模型加载失败、cache 损坏、对象存储不可用和流式断开；治理测试检查权限、租户隔离、数据驻留、脱敏、审计、成本和回滚。所有结果绑定 artifact hash 和报告版本。

交付后的运行手册

推理服务需要一份可执行 runbook：如何判断是队列、prefill、decode、KV、网络还是客户端；如何摘除实例；如何清理 cache；如何回滚 engine；如何切换 fallback；如何处理流式部分结果；如何核对工具副作用；如何恢复成本与容量。每条命令或操作都应有权限、预期指标、风险和回滚，避免事故中临时尝试造成二次损害。

runbook 要通过演练更新。每次事故或压测发现新的边界，就增加诊断字段、告警或自动化；如果一个故障需要人工在机器上删除目录才能恢复，说明平台缺少状态清理接口。后端团队熟悉的健康检查、租约、熔断、重试和数据迁移经验在这里都适用，但需要把 GPU、KV 和生成质量纳入考虑。

可回放的OOM教学调查

下面是故意构造的诊断事件，不是GPU实测日志。固定模型revision、单卡进程、BF16 KV、请求长度和并发；让多轮对话逐轮追加历史，记录每轮输入/输出token、active KV block、cache条目、allocated、reserved、设备总占用和安全点后的值。PyTorch 2.9把 memory_allocated 定义为张量占用，把 memory_reserved 定义为分配器管理总量；unused缓存仍可能显示在设备工具中，empty_cache()只释放未使用缓存，不释放仍被引用的活跃张量 [19]。其他引擎自建KV池可能不完整反映在PyTorch指标内，应再对照engine账本和设备级占用。

分配器reserved包含allocated及池内空间，不能把二者都加进总显存账本；reserved−allocated中有可复用空闲块，也可能有不可满足当前申请的碎片，并非全部无用。预分配KV池、prefix与CUDA Graph驻留都可能合法，关键是能否对应到有owner、容量和回收规则的对象。检查取消后先停止新引用，在实际stream安全点后回收，等待后台释放完成再采样；过早释放会造成随机崩溃，永久等待会造成泄漏 [27]。

可复现步骤是先建立固定长度/并发基线，再一次只增加轮次、取消、prefix或图捕获中的一个变量，保存显存快照、最早错误、事件序列与版本。若固定负载在缓存饱和后仍无限增长，追引用链和持有张量；若只有形状变化触发，比较allocator统计和padding/graph bucket；若长prefill触发峰值，调小chunk及准入预算。清cache只能作为受控对照，不能把循环empty_cache当修复。最终验收核对请求终态、待回收block归零、合法缓存有界、重跑相同负载无新增增长和质量回归；本章仅给方法，未声称这些条件已在GPU上通过。

性能剖析要形成因果假设

Nsight Compute提供Roofline和内核资源分析方法 [28]。先用请求时间线确认瓶颈属于CPU预处理、排队、H2D、prefill、decode、collective还是发送，再选相应工具。算术强度低且带宽接近上限时考虑KV布局和权重读量；算力低且带宽也低，检查launch、同步、形状与依赖空洞，不能直接归因为“GPU太弱”。只在单kernel好看而端到端变差时，核对融合寄存器压力、padding、编译冷启动及调度干扰。报告固定shape、硬件和版本，将质量、尾延迟和成功任务成本一起对照。

显存账本练习卡（Q275）

输入是上述Qwen3-8B配置字段、检查点tensor清单、权重/KV精度、单卡容量、block大小、并发和每条输入/最大输出长度；工作区与安全余量必须显式给定，缺失项列为未知，不猜成零。输出包括GB/GiB双单位权重、每token及总KV、逐rank驻留账本、候选并发上限、主导项与OOM风险解释，并保存manifest和计算假设。

边界检查包含GQA的KV头与query头区别、空序列、尾块取整、beam复制、INT4元数据、权重与KV不同精度、共享prefix的引用、TP不均匀分片及prefill峰值；再用固定长度重复、正常多轮增长、取消延迟释放三个事件轨迹判断是否泄漏。验收标准是账本各项不重计、单位正确、未知项显式且不把静态上限当SLO承诺。交付状态为练习设计，未编写实验程序、未运行GPU、未宣称实测通过。

9.9 本章小结

推理服务的工程边界可以归纳为四条：第一，模型制品、tokenizer、模板、engine 和安全策略必须版本化；第二，prefill、decode、KV、batch 和网络必须作为资源被测量和调度；第三，取消、重试、流式和工具调用必须有明确状态与幂等语义；第四，SLO、质量、成本、隔离、灰度和回滚必须形成同一条证据链。只优化某个 kernel 或某个吞吐数字，都不足以证明服务成熟。

对于后端工程师，最值得迁移的是状态机、租约、背压、幂等、容量模型和故障演练；最需要补齐的是 GPU 内存、KV layout、collective、kernel 与生成质量之间的联系。真正生产级的 serving engine 不只是把模型 forward 封装为 RPC，而是管理一组动态请求、共享中间状态和有限硬件资源，并在任何版本、流量和故障变化下保持可解释。

下一章将从“请求已经在线运行”转向“如何知道模型是否仍然正确”：数据治理、离线评估、回归集、在线反馈和质量门禁会与本章的 trace、usage、版本和成本数据连接，形成从数据到生产的评估闭环。

9.10 参考资料

[1] Kwon, W., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP, 2023. https://arxiv.org/abs/2309.06180 访问日期：2026-10-17

[2] Yu, G.-I., et al. Orca: A Distributed Serving System for Transformer-Based Generative Models. OSDI, 2022. https://www.usenix.org/conference/osdi22/presentation/yu 访问日期：2026-10-17

[3] Agrawal, A., et al. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve. OSDI, 2024. https://www.usenix.org/conference/osdi24/presentation/agrawal 访问日期：2026-10-17

[4] Zhong, Y., et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. OSDI, 2024. https://arxiv.org/abs/2401.09670 核验日期：2026-10-17

[5] NVIDIA. TensorRT Architecture Overview. online checked 2026-10-17. https://docs.nvidia.com/deeplearning/tensorrt/latest/architecture/architecture-overview.html 核验日期：2026-10-17

[6] NVIDIA. Triton Inference Server: Model Management. 在线文档，核验2026-10-17. https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_management.html

[7] 《动手学深度学习》作者. 11.7 Transformer. 中文在线2.0.0. https://zh.d2l.ai/chapter_attention-mechanisms-and-transformers/transformer.html 核验2026-10-17

[8] Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. https://sre.google/workbook/implementing-slos/ 核验日期：2026-10-17

[9] Qwen Team. Qwen3-8B config.json. 2026-10-17所见文件提交47719a2. https://huggingface.co/Qwen/Qwen3-8B/blob/main/config.json

[10] vLLM Team. vLLM: A High-Throughput and Memory-Efficient Inference Engine. https://github.com/vllm-project/vllm 访问日期：2026-10-17

[11] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[12] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

[13] vLLM Team. Automatic Prefix Caching. 官方用户指南，核验2026-10-17. https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/

[14] vLLM Team. Automatic Prefix Caching: Design. V1设计，核验2026-10-17. https://docs.vllm.ai/en/latest/design/prefix_caching/

[15] Bang, F. GPTCache: An Open-Source Semantic Cache for LLM Applications Enabling Faster Answers and Cost Savings. NLP-OSS, 2023, pp.212–218. https://aclanthology.org/2023.nlposs-1.24/

[16] Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ 访问日期：2026-10-17

[17] NVIDIA. NCCL: Collective Operations. 2.32.3文档，核验2026-10-17. https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html

[18] Hugging Face. Text Generation Inference. https://github.com/huggingface/text-generation-inference 访问日期：2026-10-17

[19] PyTorch. CUDA Semantics. 2.9. https://docs.pytorch.org/docs/2.9/notes/cuda.html 核验2026-10-17

[20] Leviathan, Y., Kalman, M., & Matias, Y. Fast Inference from Transformers via Speculative Decoding. ICML, 2023. https://arxiv.org/abs/2211.17192 访问日期：2026-10-17

[21] Chen, C., et al. Accelerating Large Language Model Decoding with Speculative Sampling. 2023. https://arxiv.org/abs/2302.01318 访问日期：2026-10-17

[22] Dao, T., et al. FlashAttention. NeurIPS, 2022. https://arxiv.org/abs/2205.14135 访问日期：2026-10-17

[23] Dao, T. FlashAttention-2. ICLR, 2024. https://arxiv.org/abs/2307.08691 访问日期：2026-10-17

[24] Zhu, R., et al. MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism. arXiv, 2025. https://arxiv.org/abs/2504.02263

[25] Kubernetes. Schedule GPUs. https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ 访问日期：2026-10-17

[26] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[27] NVIDIA. CUDA Programming Guide: Asynchronous Execution. 2026-09-10. https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html 核验日期：2026-10-17

[28] NVIDIA. Nsight Compute Profiling Guide. online checked 2026-10-17. https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html 核验日期：2026-10-17

第10章 评估与反馈闭环

模型上线之后，最难的问题往往不是“还能不能调用”，而是“这次变化是否真的变好”。数据版本变化、提示模板变化、检索结果变化、模型量化变化、用户分布变化和工具失败，都会让质量指标发生变化。没有数据与评估 Infra，团队只能凭少量示例和主观感受发布模型，问题通常会在生产流量和长期反馈中才暴露。

本章把数据与评估看成一条生产链路：数据进入时有来源、授权、schema 和质量检查；加工时有版本、血缘、去重、采样和分片；评估时有固定回归集、任务指标、裁判校准和统计不确定性；线上运行时有请求 trace、反馈、失败样本和漂移监控；发布时由质量门禁决定是否灰度、回滚或进入人工审查。RDD与MapReduce提供数据处理容错参考 [1][2]，lakeFS与TFDV提供版本和校验组件 [3][4]，HELM、BIG-bench和Ragas提供多维测量方法 [5][6][7]；平台仍需定义自己的发布证据契约。

本章的核心判断是：系统运行正常不等于质量正在改善。第9章关心请求是否稳定交付，第12章关心生产治理和责任闭环，第22章会专门展开 Agent Evals、Guardrails 与可观测性；本章位于它们之间，负责把数据、评估协议、judge、线上反馈和发布门禁变成可复核证据。

10.1 对象模型与版本化评估记录

从数据文件到数据产品

数据平台至少要区分 source、dataset、snapshot、split、sample、manifest、transformation、evaluation set 和 feedback set。source 是外部来源，dataset 是经过处理的逻辑集合，snapshot 是某个不可变时点，split 说明训练、验证、测试或回归用途，sample 是可追踪的样本，manifest 描述内容、统计、权限和 hash。用一个目录同时表示这些对象，会让版本、授权和回滚混在一起。

一个数据产品还要记录 owner、用途、语言、主题、敏感等级、授权范围、保留期限、质量阈值和下游消费者。训练数据、评估数据、线上反馈和人工标注拥有不同生命周期，不能都复制到同一个 bucket。LakeFS 和 Delta Lake 通过版本、提交和时间旅行等机制，为数据快照与可回滚提供了工程参考 [3][8]。

实验、评估与模型制品

experiment 表示一个假设，run 表示一次具体执行，evaluation run 表示在指定数据和运行时上得到的结果，model artifact 表示可部署制品。评估结果必须绑定 model hash、tokenizer、模板、采样参数、数据 snapshot、代码、engine、硬件和评估器版本。只保存一个分数无法证明两个分数可比。

模型注册表应区分 candidate、staged、canary、production 和 retired。评估任务产生 evidence bundle，包括原始结果、聚合指标、失败样本、置信区间、质量门禁和人工结论。MLflow Tracking记录run的参数、指标、代码版本和artifact [9]；Langfuse datasets区分输入、可选expected output及metadata [10]。前者是运行记录参考，后者是评估样本参考，都不自动实现本书全部发布与治理契约。

反馈样本与隐私

线上反馈可能来自显式评分、用户重试、编辑、转人工、任务成功、工具失败、投诉和安全拦截。反馈不是天然标签：用户没有点赞可能是没有看到答案，也可能是任务已经完成；重试可能表示质量差，也可能是网络断开。平台要保存 feedback type、来源、时间、request trace、模型版本、数据等级和标注置信度。

反馈样本通常包含 prompt、输出和业务上下文，需要脱敏、访问控制、留存期限和删除机制。默认只保留 hash、长度、错误类型和结果摘要；需要人工标注时通过受控队列读取。数据与评估 Infra 应让“可用于改进”与“可以被任意工程师下载”分开，避免把线上日志变成未经治理的训练集。

样本级可追踪

每个样本生成稳定的 sample_id 和 content_hash，变换后保存 parent_id、transformation_id 和版本。评估结果引用 sample_id，而不是只保存数组下标；模型输出保存 output_hash、模型 hash、采样参数、错误和评分；反馈引用 request_id 和 sample_id。这样某个失败样本可以反查来源、处理规则、评估历史、线上请求和标注。

样本级追踪要控制存储与隐私。高价值或失败样本保存更完整上下文，普通样本保存摘要和 hash；敏感内容使用短期受控访问。删除请求到来时，平台根据 sample lineage 查找所有衍生快照、反馈、评估和缓存，并更新可见性。历史指标可能仍需保留，但要标注数据已撤回和结果不可重新生成。

一份版本化Eval Case与执行记录

本章把第7章的Eval Case固定为可复用契约：case描述“要检验什么”，eval_run记录“这一轮如何执行”，result记录“实际观察和判定”，report才聚合并给出门禁。case_id稳定，修改输入、预期、权限或工具边界就增加case_version；运行不能覆盖旧结果。experiment_run与Agent的业务Run使用不同命名空间，前者是实验安排，后者是用户任务持久执行，不能因为都叫run就共用终态。

下面是教学记录，示例ID与哈希占位符不对应实际实验。权威对象名可以映射到工具，但不能将此schema冒充任何产品API。

case:
  schema_version: eval-case/v1
  case_id: refund-readonly-017
  case_version: 3
  input_ref: controlled://eval-2026-10-17/sample-017
  content_hash: "sha256:<sample-content>"
  dataset_snapshot: eval-refund/holdout-v4
  split: test
  group_id: conversation-017
  authorization_snapshot: policy-v8/tenant-a/readonly
  environment_snapshot: sandbox-fixture-v6
  expected_constraints:
    - "回答必须引用授权政策，未知事实要标明"
    - "禁止创建退款或调用写工具"
  rubric_version: refund-rubric/v5
  evaluator_artifact: factuality-judge/v2
  slices: [zh, long-context, no-write]
  budget: {max_attempts: 2, max_tokens: 6000, deadline_seconds: 90}
  side_effect_mode: recorded-read-only
  owner: eval-owner
execution:
  eval_run_id: evaluation-run-example
  candidate_manifest: model-manifest-v9
  baseline_manifest: model-manifest-v8
  protocol_version: refund-protocol/v3
  runtime_manifest: engine-hardware-fixture-v2
  seed: 42
  attempt: 1
result:
  state: completed
  output_ref: controlled://evaluation-run-example/output-017
  output_hash: "sha256:<output-content>"
  observations: {schema_valid: true, writes_attempted: 0, evidence_coverage: 1.0}
  task_outcome: failed
  task_reason: required_policy_condition_missing
  model_scores: {fluency: 4, factuality: 2}
  evaluator_state: valid
  tokens: {input: 3200, output: 240}
  evidence_ref: controlled://evaluation-run-example/trace-017
  gate: blocked

记录中completed只说明评估执行结束，任务仍可failed；语言流畅4分不能覆盖“缺必要条件”或非法写操作。expected_constraints可以作为任务验收规格，但若某个实验是让裁判预测人工合格标签，待预测标签必须放在评分侧，不能渲染进裁判输入。input_ref与output_ref受控且有保留期，哈希和结果摘要用于追踪而非扩散原文。工具返回、权限和环境快照决定结果可复核范围；删除内容后保留受限审计记录，标记该样本不能原样重跑。

10.2 数据版本、血缘与划分边界

不可变 snapshot

一个评估集必须能在未来重新读到同样的样本、顺序、字段和标注。数据源可能更新、对象存储路径可能被覆盖、过滤规则可能改变，因此评估任务保存的不是路径，而是 snapshot id、manifest hash、样本 hash、schema、处理版本和排序规则。时间旅行和分支能力让团队可以在新规则上实验，而不破坏旧基线 [3][8]。

不可变 snapshot 不意味着永远保存原始内容。对于敏感或授权受限数据，可以保存受控版本、加密指针、样本 hash 和可复现的变换描述；当删除请求到来时，撤销内容访问并更新血缘。评估结果仍保留“使用过某个版本”的审计证据，但不必无限复制原文。

数据血缘图

血缘图回答数据从哪里来、经过什么变换、进入哪些训练和评估、影响哪些模型。节点可以是 source、raw snapshot、clean snapshot、dedup snapshot、token dataset、eval set、model run 和 report；边记录 transformation、代码版本、参数、执行时间和 owner。发生质量问题或数据撤回时，可以沿图反向查找到受影响的 artifact。

MapReduce 和 Spark 的分区、任务重试与 DAG 经验说明，大规模处理应让中间结果和血缘可重建 [2][11]。血缘不是为了画漂亮的图，而是为了避免“修复一个过滤规则后不知道哪些评估要重跑”。平台可以按 hash 去重相同处理，按下游门禁优先级安排重算。

Schema 与向后兼容

数据 schema 至少定义 id、输入、目标、来源、语言、标签、敏感等级、时间、版本和元数据。字段增加通常可以兼容，字段含义改变、标签定义改变、tokenizer 改变和样本边界改变则需要新主版本。TFDV 和 Great Expectations 的数据统计与断言可用于检测字段缺失、类型变化、分布漂移、空值和范围异常 [4][12]。

schema 校验要分为阻断级、警告级和观察级。输入字段缺失、标签越界和敏感等级未知通常阻断；长度分布轻微变化可以警告；新语言出现可以进入观察并由负责人决定。所有校验结果都写入 snapshot manifest，不能只在 CI 日志中出现，否则后来无法证明某次评估是否经过同一套门禁。

去重、污染与泄漏

训练与评估之间的污染会让分数虚高。精确重复可以通过 hash，近重复可以用 n-gram、MinHash 或 embedding 检测；但去重阈值过强可能删除合法变体，过弱则保留模板和改写。平台应报告重复定义、阈值、候选数量、删除数量和跨 split 的污染数量，不要只显示一个“已去重”。

评估集还可能因公开题目、模型预训练数据、人工标注泄漏和 prompt 模板而被污染。检测到污染时，不应简单继续使用旧分数；可以替换样本、增加私有集、报告污染比例或标记结果不可比较。Llama 3 和 The Pile 的数据工程经验表明，规模化语料管理本身就是模型能力和评估可信度的组成部分 [13][14]。

数据快照的事务语义

数据快照提交需要像数据库事务一样有明确的 prepare、validate 和 commit。prepare 阶段产生分区和临时 manifest，validate 阶段校验 schema、统计、权限、质量和血缘，commit 阶段写入不可变 snapshot id，并把别名从旧版本原子切换到新版本。任何阶段失败都不能让下游读取半成品。Delta Lake 的事务表与时间旅行思路可以帮助实现这种提交语义 [8]。

别名切换也要可审计。latest 不是一个足够可靠的评估输入，任务提交时解析成具体 snapshot，报告保存具体 id。若下游长时间运行，期间 latest 变化也不能影响当前任务；新任务才使用新版本。回滚只是把受控别名指向旧 snapshot，并记录原因，历史 run 仍保留原引用。

数据分支与实验比较

数据分支允许在不破坏主线的情况下尝试新的清洗规则、采样配方或标签。分支从一个已提交 snapshot 创建，变换和新增样本记录 parent，合并前执行冲突、污染、权限和质量检查。分支合并不是简单复制文件，而是生成新的不可变 snapshot。LakeFS 和 DVC 的版本化能力提供了数据分支和实验关联的工程参考 [3][15]。

实验比较要把数据差异与模型差异分开。模型 A 使用旧数据、模型 B 使用新数据时，分数变化无法归因；可以固定模型比较数据，固定数据比较模型，或用 factorial 设计拆分影响。报告列出 data diff、code diff、runtime diff 和 evaluator diff，禁止把所有变化归因于模型规模或训练方法。

训练数据与评估数据的边界

反馈样本可能同时被用于训练和评估。平台根据 sample lineage 和用途标签阻止同一个样本进入训练后又进入测试，或把结果标记为污染。时间切分、实体切分和文档切分有不同泄漏边界：同一用户、同一文档和同一模板的改写可能仍然高度相关。数据分割规则写入 snapshot manifest，不能只写在实验笔记里。

训练集扩大后，旧 benchmark 可能已被间接看到。平台定期创建私有 holdout 或新鲜时间窗口，并估计污染风险。公开榜单用于横向参考，生产门禁应更多依赖任务相关、私有、受控和可审计的评估集。中文D2L教材对训练、验证和测试边界的基本原则仍然适用，只是大模型的规模使泄漏检测更复杂 [16]。

三个边界：训练、调优校准与独立验收

训练集可供参数学习或few-shot构造；dev/calibration集用于选prompt、judge、阈值和标签指南；test/holdout只用于冻结后的独立验收。校准一词不代表可以反复查看test错误再宣布同一test无偏。若用验收失败改了候选，旧集可转回归诊断集，但最终质量结论需另一个受控holdout或新时间窗，并披露多轮选择。

切分单位优先是会话、文档、实体或来源群组，而不是单行：同一对话改写后分到两边，可能仍泄漏。先构建近重复群组再整体分配；跨时间任务使用截止点，并检查未来信息、答案字段和检索索引是否流入输入。生成样本也必须标注生成器版本与父样本，不能把同一模板的轻微扰动当大量独立样本。模型生成候选可降低收集成本，人工仍需核实期望、授权、无答案和拒绝边界。基准公开不保证未被预训练看到，私有数据也不自动排除重复或标注传播。

10.3 数据处理、标注与质量门禁

分区、并行和重试

数据处理 DAG 应将下载、解析、规范化、去重、分词、分桶、标注和统计拆为可重试分区。一个分区失败时只重做该分区，成功分区由 manifest 固化；坏文件进入 quarantine 并记录原因。RDD 的分区与血缘思想适合解释这种容错边界 [1]，MapReduce 的 map、shuffle、reduce 也提供了大规模处理的基本分解 [2]。

重试应区分瞬时错误和确定性错误。存储超时、节点故障可以指数退避；未知编码、schema 不匹配、恶意超长样本和解析器异常应隔离并限制重试。无限重试会掩盖坏数据并消耗集群。每个分区需要最大重试、超时、错误样本上限和最终状态，控制面通过状态机保证重复完成事件幂等。

统计剖面

每个 snapshot 都应生成统计剖面：样本数、有效 token、语言、主题、长度、空值、重复率、敏感类别、标签分布、来源比例、时间分布和错误率。统计分桶要固定，避免不同版本的 histogram 无法比较。对于生成数据，还要统计输出长度、停止原因、拒答、重复 n-gram、JSON 合法率和工具参数合法率。

统计剖面有三种用途：发现坏数据、解释训练和支持评估可比性。某个版本样本数增加不代表有效 token 增加；某个语言比例下降可能是过滤变化；JSON 合法率下降可能来自模板或 tokenizer，而不是模型本身。平台保存统计的计算代码、输入 snapshot 和结果 hash，避免手工表格成为事实来源。

质量断言与人工抽样

自动断言适合结构、范围、重复和分布；人工抽样适合语义、偏见、毒性、版权和任务可用性。抽样要按来源、语言、长度、标签、风险等级和失败类型分层，不能只随机抽全局样本。人工标注界面显示必要上下文但隐藏不必要隐私，标注结果保存 disagreement、标注者、指南版本和置信度。

人工抽样也应有停止与升级规则。若某类样本出现高比例格式错误、隐私、恶意指令或标签歧义，平台暂停下游处理并通知 owner；不能把所有问题平均化后继续。标注指南要版本化，指南改变后旧标签是否可比需要明确。数据质量门禁是算法质量的上游，不应让评估团队承担所有脏数据成本。

数据集构建的工程路径

一个可复现的数据集构建通常包含 source ingest、格式统一、内容解析、语言识别、敏感信息处理、精确去重、近似去重、质量评分、采样、分片和 manifest 提交。每一步产生输入和输出 hash、参数、软件版本、资源使用和错误摘要。Hugging Face Datasets 等工具降低了数据加载和 map 操作的门槛，但生产平台仍需补充权限、血缘、事务提交和失败重试 [17]。

构建过程采用临时输出与提交标记。分区先写到 run-specific 的临时路径，校验数量、大小、统计和 hash 后，协调者创建不可变 snapshot。下游只读取已提交 snapshot。这样上游任务失败不会产生半成品，下游也不会因为路径存在就误读不完整数据。快照提交记录 owner、时间、授权、schema 和质量结果，支持审计与回滚。

数据修复与重算

发现一批样本错误时，不应直接覆盖原数据。创建修复规则版本、选择受影响分区、生成新 snapshot，并在血缘中记录“修复前—修复后”的差异。训练或评估引用旧 snapshot 的历史结果保持不变，新 run 选择修复后的版本。修复任务需要报告删除、替换、新增和无法修复的样本数量。

修复可能改变数据分布与评估可比性。若只是纠正编码或 schema，可以与旧版本近似比较；若删除大量重复、改变标签或替换答案，应创建新的基线。评估报告显式列出 snapshot diff，发布控制器决定是否重新运行全部门禁。覆盖旧目录会让事故调查失去证据，是数据平台最危险的简化。

标注系统的状态机

人工标注任务可以经历 CREATED、ASSIGNED、IN_PROGRESS、SUBMITTED、REVIEW_REQUIRED、ADJUDICATED、ACCEPTED 和 REJECTED。每次状态迁移保存标注指南、标注者、时间、版本和理由。任务领取需要租约，避免一个标注者离线后样本永远锁住；提交需要幂等，重复提交不能生成两个标签。

标注系统要支持双标和仲裁。标签一致时提高置信度；不一致时进入 adjudication，保留两个原始判断与仲裁理由。标注指南改变时，新旧结果是否可合并由 schema 规则决定。高风险样本可以要求更高等级的标注者或多人确认，不能把所有样本用同一成本和速度处理。

标签质量与弱监督

弱标签可能来自规则、旧模型、用户行为和程序检查，成本低但噪声结构复杂。平台保存标签来源、生成器版本、置信度和是否经过人工确认。模型评估不能把弱标签当作人工真值；可以用于筛选、预标注和发现异常，再通过抽样估计噪声率。数据与评估报告披露标签来源比例，避免分数看似精确却依赖大量伪标签。

标签泄漏也需要检测。若标签字段、未来时间信息、评估答案或模板提示进入模型输入，任务分数会虚高。schema 与血缘检查输入字段，抽样人工审查，训练和评估 split 使用不同的时间或实体隔离策略。机器学习中的泛化与数据划分原则要求测试信息不能通过隐含路径泄露到训练流程 [16]。

数据质量事件

数据质量事件应具有独立的类型和生命周期，例如 SCHEMA_BREAK、DISTRIBUTION_SHIFT、DUPLICATE_SPIKE、LABEL_CONFLICT、PRIVACY_FINDING、SOURCE_EXPIRED 和 SNAPSHOT_INCOMPLETE。事件包含 source、snapshot、partition、rule、severity、owner、发现时间和处置状态。发现质量问题时，平台可以阻断新 snapshot、冻结相关评估、通知 owner，并保留历史可读性。

事件处置可能是重跑分区、修改规则、补充标注、隔离来源、撤回 snapshot 或接受风险。每个动作产生新版本和审计记录，不能直接把事件标记为 resolved 而不说明证据。数据质量 dashboard 显示开放事件、平均处理时间、重复发生率和受影响模型，帮助团队把数据问题纳入工程计划。

数据处理的可观测性

数据 job 的 metrics 包括输入分区数、输出分区数、样本数、token、处理速率、等待、重试、坏样本、内存、存储和成本；trace 连接 source、transform、partition 和 snapshot commit；日志记录错误样本 hash、异常类型、规则版本和处置。Prometheus 和 OpenTelemetry 提供采集与关联的基础 [18][19]，平台应补充数据语义字段。

可观测性也要保护数据。metric label 不放原文、用户 id 或自由文本；trace event 使用 sample hash 与敏感等级；错误日志按规则脱敏。权限不同的用户看到不同粒度，质量 owner 可以看聚合和受控样本，平台 operator 可以看资源和错误但不一定看内容。观测系统本身不能成为数据泄漏路径。

10.4 评估集、指标与统计不确定性

固定回归集

回归集用于检测版本变化，必须小而稳定、覆盖关键能力、具有明确标签和可重复执行。建议分为 smoke、critical、broad、safety 和 adversarial 五层。smoke 在每次提交运行，critical 作为灰度门禁，broad 适合夜间或候选发布，safety 和 adversarial 由受控流程运行。每层保存样本 hash、任务定义、期望输出或评分规则和 owner。

回归集不能长期不变。固定集会被过拟合，生产分布也会变化；可以保留不可变历史版本，同时按反馈抽样创建候选集。新样本经过污染检查、标注和门禁后才进入下一版本。报告同时展示历史基线与当前版本，说明新增、删除和改变样本的原因。

任务指标

确定性分类和结构化任务可使用 accuracy、precision、recall、F1、校准、schema validity 和 exact match；生成任务可使用 ROUGE、BLEU、BERTScore、事实性、引用准确、工具成功和人工偏好；代码任务可使用测试通过、编译、修复成功和安全扫描；对话任务还要看多轮一致、拒答和用户目标完成。没有一种指标适用于所有任务。

指标定义要写清样本权重、缺失处理、长度截断、多个答案、裁判规则和置信区间。平均分可能掩盖少数语言或高价值任务退化，建议按能力、语言、长度、风险和租户场景分层。中文D2L关于训练误差、泛化与独立测试集的讨论提醒我们，测试分数只是目标分布的有限样本估计 [16]。

质量、延迟与成本的联合指标

线上发布不能只依据离线质量，也不能只依据 P99。假设一个候选版本质量提升 1%，但 GPU 成本增加 5 倍，是否值得取决于业务；一个版本延迟降低 30%，但任务成功降低 10%，通常不应直接发布。评估报告应呈现质量、TTFT、TPOT、成功率、人工接管、token、GPU 时间和单位成功任务成本。

可以把发布门禁定义为约束集合，而不是一个加权总分。例如关键安全指标不得下降，任务成功率不得下降超过容差，p95 不能超过预算，成本增长必须有审批；其余指标用于排序和人工判断。加权总分容易隐藏严重的单项回退，约束集合更适合生产治理。

采样误差

评估分数是有限样本的估计。样本量、抽样分布、分层权重和任务相关性会影响置信区间。将一组高度相似的样本当作独立样本，会低估不确定性；从线上失败样本主动采样，会高估失败率但能发现风险。报告包含 sample count、有效样本、分层比例、权重、置信区间和抽样方法。

两个版本分数差异很小时，不应马上宣布提升。可以使用配对样本比较、bootstrap、分层统计和最小实际效应；对裁判或人工标签，报告标注一致和评分方差。发布门禁明确“统计显著”和“业务重要”的区别，避免因为大样本的微小差异触发无意义回滚，也避免小样本的偶然提升进入生产。

长尾与分层

总体平均常被多数的简单样本主导。平台按语言、长度、任务、风险、数据源、用户层级、工具类型和模型路由分层，报告每层样本数、分数和变化。某个少数语言分数下降可能在总体平均中消失，却对产品公平和合规很重要；长上下文任务可能样本少但成本和投诉高。

分层规则要稳定、可版本化。改变分桶边界会改变历史图表，必须同时保留旧分桶或重新计算基线。高维分层会产生稀疏样本，平台标记低置信度而不是输出虚假的精确值。风险门禁可以对高风险层设置最低样本和最低质量要求。

指标漂移与指标博弈

团队可能为了提高某个指标改变 prompt、截断输出、过滤困难样本或增加模板化答案。平台应把指标定义、样本版本和失败样本一起审计，防止只优化可见分数。一个模型输出更短可能降低错误 token，但不一定完成任务；一个 judge 分数更高可能只是更擅长迎合裁判。

指标体系应包含结果、过程和成本：最终任务成功、关键中间步骤、引用或工具正确、重试与人工接管、延迟、token、GPU 和数据成本。不同指标冲突时由产品目标和安全边界决定，而不是让某个单一 leaderboard 决定。HELM 的多维评估思路说明，能力、效率、偏差和安全需要并列观察 [5]。

测试数据的长期维护

回归集需要 owner、有效期、覆盖标签、风险等级和复审周期。样本可能因知识过时、产品流程改变、工具接口改变或授权到期而失效。定期复审样本，新增线上失败样本，删除或标记过时样本，并保留历史版本。一个永远不更新的回归集会形成过拟合的 CI，而不能代表生产质量。

每次删除样本都要说明原因，区别“样本错误”“任务废弃”“授权撤回”“模型已过拟合”和“迁移到新基准”。指标趋势图同时展示数据集版本，避免读者误以为同一分母。新旧回归集重叠部分可以用于桥接，但不应直接把分数拼接成一条连续时间序列。

回归样本的优先级

回归集样本可以按风险、业务价值、历史失败、频率、代表性和修复状态排序。高风险安全样本、核心交易任务和最近事故样本每次提交运行；低频探索样本按夜间任务运行；大规模 benchmark 用于周期性趋势。优先级写在 sample metadata 中，发布控制器根据门禁级别选择子集。

新增样本要经过候选、复核、接受和退役状态。失败样本直接加入生产门禁可能造成过拟合，先确认问题可复现、期望行为明确、数据可授权、没有与训练泄漏，再决定放入哪一层。样本的修复状态也进入 dashboard，避免团队只追求增加样本数量而不处理模糊定义。

MMLU用多学科知识任务检验模型在不同领域的准确率 [20]，可以作为能力切片参考，却不能替代真实工具执行、权限或多轮业务成功测试。基准高分不能自动变成产品发布资格。

零失败、配对变化与分层不确定性

NIST手册说明比例区间以及小样本/少失败时的二项精确方法 [21]。一个便于复算的例子：独立同分布的n次验收全通过，失败率p下观察零失败的概率是(1−p)^n；令其等于0.05，得到95%单侧精确上界p=1−0.05^(1/n)。n=100时约2.95%，所以100次通过不能声明线上成功率100%；这里不是双侧区间，也不适用于高度相关会话或定向挑选的简单题。

比较候选与基线时，应在同一case、同一环境和预算上做配对，记录“都成功/只候选成功/只基线成功/都失败”。对相关会话按group重采样，对多轮随机运行先保留case内部方差，再估计跨case变化；不能把同一题跑一百次当一百个业务场景。选择bootstrap或其他区间时记录采样单位、次数和置信水平，区间含零表示证据不足，不能说“证明完全相同”。多切片、多版本连续试验还会增加偶然胜出，停止规则及多重比较处理需预先约定。

报告至少并列总体与关键切片的分母、有效数、覆盖率、变化区间和失败例。服务超时若属于端到端任务目标，应在任务成功分母体现失败；数据损坏或裁判无效则单列并按协议报告，不静默变成负例也不靠剔除提高分数。只要关键切片样本不足，门禁可为INCONCLUSIVE并补样，而非输出虚假的小数精度。

10.5 LLM-as-Judge与人工校准

裁判模型的用途

LLM-as-judge 可以在开放式生成任务中提供较便宜的质量评分、pairwise preference、维度解释和样本筛选。G-Eval、MT-Bench 等工作展示了裁判模型在自动评估中的应用 [22][23]。但裁判不是绝对真值，可能偏好更长答案、熟悉风格、特定模型、位置靠前的答案或带有特定格式的答案。

评估平台要保存 judge model、prompt、temperature、候选顺序、schema、评分尺度和原始理由。pairwise 评估随机交换 A/B，避免位置偏差；多次采样测量方差；对高影响发布保留人工复核。裁判的输出只能支持明确的论点，例如“在这组任务上相对偏好提高”，不能泛化为“模型整体更智能”。

裁判校准

校准集由人工高一致样本、边界样本、争议样本和已知失败组成。比较裁判与人工的一致率、相关性、偏差方向和按任务分层的误差。裁判 prompt 改变、模型版本改变或语言分布改变时重新校准。中文、代码、数学、长文档和安全样本可能需要不同裁判或不同评分指南。

人工标注采用双标、盲评、随机顺序和 adjudication。标注者训练、指南版本、时间和 disagreement 写入结果。若人工一致性低，不应直接把裁判当作替代品，而要先澄清任务定义。评估 Infra 的工作不是制造一个漂亮分数，而是把不确定性和偏差显式化。

成本控制

大规模 judge 很昂贵，可以先用规则过滤和小模型筛选，再对边界样本使用强模型和人工。缓存 judge 输入与评分时必须绑定 prompt、候选 hash、评估器版本和数据等级，防止模型升级后误用旧结果。抽样评估的统计置信区间要随采样策略保存，不能把小样本结果显示成精确百分数。

评估器的依赖治理

评估器本身可能依赖 tokenizer、模型、检索器、规则库、外部 API 和人工指南。每个 evaluator artifact 有版本、输入 schema、输出 schema、随机性、资源需求、适用任务和已知偏差。升级评估器要用历史样本重跑，报告分数变化是模型变化还是 evaluator 变化。评估器不可用或输出异常时，任务进入 evaluator_failed，不应自动给负分或正分。

裁判模型的版本也要纳入模型注册。若 judge 变强或 prompt 改变，历史分数可能不可比；可以保留旧 judge 做桥接，或在报告中说明迁移。高风险门禁使用人工复核和独立规则，避免候选模型和 judge 共享相同偏差。评估平台的可信度取决于对评估器自身的治理。

校准不是让裁判看见目标标签

先冻结标签字典与正类方向。例如正类定义“必须升级人工”，人判升级而judge判解决是FN漏放，人判解决而judge判升级是FP误杀。合法标签才进入TP/FP/FN/TN；越界、空响应和非法JSON记invalid并报告有效数，不能转成默认negative。给人工和judge同样必要证据，但不向judge提供该实验待预测的人工标签；参考答案式评分可以提供独立任务答案，两者任务定义不同。

准确率为(TP+TN)/有效数，召回为TP/(TP+FN)，精确率为TP/(TP+FP)，还应观察正常样本正确保留比例TN/(TN+FP)。分母为零记未定义，并检查稀有风险是否根本没覆盖。全判解决也可能在极不平衡数据上准确率很高，但严重漏放召回为零；高风险自动门禁必须按误判代价设置阈值和人工复核，不能采用通用准确率 cutoff。换序盲评、控制答案长度、检查自偏好和多次评分不稳在dev进行，test只评估冻结版本；版本或任务分布变化后重新校准并建立桥接报告 [23]。

10.6 RAG、Agent与线上反馈闭环

RAG 的组件指标

RAG 任务至少拆成检索、重排、上下文组装、生成和引用。Ragas原论文把相关上下文、基于证据的忠实使用与生成质量分别评价 [7]。具体指标名、是否需要参考答案随版本变化，实验要冻结metric实现及输入要求。组件指标不能完全替代最终任务成功，但能帮助定位：答案错可能是没有召回、召回了但排序错、上下文太长、模型忽略证据或引用指向错误。

评估样本要保存 query、允许的证据、检索版本、chunk、score、上下文顺序、最终答案和引用。知识库更新后，旧评估结果是否可比取决于 snapshot；检索器升级后要重新计算上下文指标。线上反馈包含“答案有用”时，不能直接推断检索正确，需要抽样检查证据和引用。

工具调用与工作流

工具评估关心 schema 合法、参数正确、权限正确、执行成功、结果被正确使用、失败后恢复和副作用幂等。单次模型输出 JSON 合法并不等于任务成功；工具可能超时、返回脏数据、重复执行或需要人工审批。评估平台记录 workflow trace，把模型调用、工具调用、状态迁移和最终目标连接起来。

Agent 任务可以使用最终成功、步骤成功、重试次数、人工接管、总 token、总时延和副作用错误作为指标。测试要包含工具不可用、权限不足、部分成功、重复消息、上下文压缩和模型回退。线上回放不能直接执行真实副作用，应使用 sandbox、mock 或 dry-run，并明确哪些结果可迁移到生产。

反馈采样与主动学习

不是所有线上请求都值得进入标注池。可以按低评分、重试、长延迟、工具失败、安全拦截、模型版本、罕见语言和不确定裁判进行分层采样。主动学习优先选择能最大化信息增益或覆盖新分布的样本，而不是只收集最糟糕的案例。采样策略本身也需版本化，避免反馈集分布被不透明规则改变。

标注后的样本进入候选回归集前，要做去重、隐私、授权、标签一致和污染检查。样本被加入训练集后，再次用于评估会造成泄漏，平台用血缘图阻断这种循环或明确标记不可比。数据与评估闭环必须能回答一个失败样本从生产到标注、修复、回归和发布经历了什么。

线上质量信号

线上质量信号可以是用户评分、编辑距离、重试、转人工、任务完成、工具成功、引用点击、投诉和安全拦截。信号需要按模型版本、模板、租户、语言、长度、路由、adapter 和请求类型分层。延迟、错误和成本是系统信号，不能直接等同于质量，但它们与质量样本结合后可以定位体验变化。

线上指标要处理选择偏差。主动评分的用户与沉默用户不同，只有失败用户才重试，人工接管只发生在高风险任务。平台应保留抽样的未反馈请求作为对照，使用分层或加权估计，报告覆盖率和不确定性。不要把点赞率从 1% 的样本直接当作全量质量。

分布漂移

输入长度、语言、主题、来源、工具类型、用户群和时间可能发生变化。数据剖面比较当前窗口与基线窗口，检测 token 长度、embedding、类别比例、错误、拒答、cache 命中和任务成功的变化。漂移不是一定的质量问题，但会触发扩大评估、增加采样或暂停自动发布。

输出漂移包括长度、停止原因、重复、格式、引用、工具参数、拒答和安全判定。模型没有换版本时输出也可能因上游知识库、prompt、路由和用户分布变化而漂移。OpenTelemetry 和 Prometheus 可以把请求上下文与时间序列指标连接起来 [18][19]；Dapper 的追踪思想帮助定位漂移涉及的下游组件 [24]。

线上回放

回放保存 request manifest、模型版本、模板、检索结果、工具返回、采样参数和输出摘要，但默认不执行真实副作用。可以将请求送到新模型、影子 engine 或离线评估器，比较输出、格式、引用、工具计划、成本和延迟估计。回放要处理时间敏感数据、权限、过期知识和随机性，结果标记为近似而不是事实重现。

回放样本由 trace id、snapshot 和脱敏版本引用，避免复制大量敏感内容。某个版本的失败样本优先进入回归，修复后比较同一批样本；如果样本已经用于训练，报告不可比或使用新 holdout。回放系统应支持按能力、模型、错误和租户查询，成为发布控制器和事故复盘的共同数据源。

线上反馈的去偏

线上反馈存在曝光、选择和幸存者偏差。只有展示给用户的结果才可能获得评分；只有不满意的用户可能重试；完成任务的用户可能不再反馈。平台可使用随机抽样、分层采样、对照版本、隐式行为与显式评分组合，报告反馈覆盖率和采样策略。不要把低反馈量的高分当作稳定提升。

对不同用户群和业务场景分别估计质量，避免大租户或高频场景淹没少数重要场景。线上实验按 parent task 固定版本，避免一次 Agent 工作流跨多个模型版本。反馈数据入库前保存原始信号、解释和时间，后续重算可以更换聚合方法而不丢失基础事实。

反馈进入数据集前

生产反馈先进入隔离区，完成身份去除、敏感信息检测、权限确认、样本去重、来源标记和风险分类。只有满足用途授权与留存策略的样本进入候选集。用户删除请求和数据主体请求要能沿血缘查找所有衍生副本。反馈不能因为“用户公开提交”就自动获得训练授权。

评估结果的访问控制

评估可能暴露模型弱点、敏感 prompt、客户数据、红队样本和内部工具。权限分为结果摘要、失败样本、原始输入输出、标注和 artifact 下载；每次访问审计。跨租户实验不能共享原始样本，模型供应商或外部 judge 只收到最小必要内容，并记录出站处理和删除确认。

红队与对抗集

安全红队样本要有来源、攻击类型、危害等级、预期处理、评估规则和修复状态。对抗集不能只在发布前运行一次；新模型、模板、工具、检索和路由变化都触发相关子集。修复后的模型要确认没有通过简单拒答提升分数而损失正常任务，报告安全和有用性的联合结果。

在线与离线指标的校准

离线指标与线上指标之间需要桥接集。桥接集包含过去生产请求的脱敏、分层和标注样本，比较离线分数、线上反馈、任务成功和人工判断。若某个离线指标长期与线上成功无关，就降低它在门禁中的权重或重新定义；若线上出现新的失败模式，就加入候选回归集。桥接不是一次性相关分析，而是持续校准。

线上指标受流量、用户、时间和下游系统影响，离线指标受 snapshot、协议和采样影响。报告分别标记 measurement layer，避免把两个数字放进同一个总分。模型发布时可以要求离线硬约束和线上 canary 约束都满足，任何一层失败都触发暂停或人工判断。

10.7 评估作业的调度、可靠性与观测

评估 job 的资源模型

评估任务可能是 CPU 规则、单 GPU batch、多个模型 judge、在线 shadow、人工标注或长链路 Agent。job spec 应声明模型 artifact、数据 snapshot、并发、最大 token、超时、重试、GPU、优先级、输出路径和预算。调度器根据资源和 deadline 分配，在线回归不能被大型离线 judge 堵塞。

评估 worker 需要断点游标、分区输出、完成标记和幂等写入。一个分区失败时只重试该分区；已有结果不可被重复覆盖，除非新 run 使用新的 eval id。输出包括样本结果、错误、耗时、token、成本和 evaluator version，聚合任务只读取已提交分区。Spark的分区变换与Ray的分布式任务运行时提供了不同层次的执行组件，平台仍要定义统一job状态、提交记录和资源策略 [11][25]。

评估缓存

评估缓存可以避免重复 tokenizer、embedding、检索、judge 或模型输出，但 key 必须包含模型 hash、数据 sample hash、模板、采样参数、engine、评估器、schema 和权限。只按 prompt 缓存会在模型或模板变化后返回旧结果。缓存命中、失效和质量差异写入报告，以免成本下降被误认为模型更快。

缓存敏感样本需要加密和租户隔离；人工标注结果的缓存还要记录指南版本。缓存可以帮助快速 smoke，但发布前应保留一部分冷跑样本，防止系统只验证缓存路径。评估平台同时报告 cached 与 uncached 的成本和延迟。

失败、超时与部分结果

评估任务遇到模型超时、GPU OOM、judge 不可用、工具 sandbox 故障、样本非法和输出超长时，结果不能简单填 0。应区分 skipped、invalid、timeout、infra_failed、model_failed 和 judged_negative。聚合器报告覆盖率、失败率和有效样本数；质量门禁在覆盖率不足时阻断，而不是把缺失样本当作通过。

部分结果可以用于诊断，但不能默认用于发布。评估 run 完成标记包含 sample count、success count、error count、coverage、数据 hash 和 evaluator hash。若只完成了容易样本，分数可能虚高。失败样本进入重试或人工队列，修复后以新 run 或明确的 retry attempt 关联。

优先级与资源池

评估任务可分为提交前 smoke、发布门禁、夜间 broad、线上回放、主动学习、人工标注和大规模 benchmark。不同任务的 deadline、GPU、数据、裁判和结果保留不同，应使用不同资源池或优先级。发布门禁不能被一个长时间 benchmark 阻塞，人工标注也不能被无限自动任务淹没。

调度器记录 pending reason、预计完成、使用资源和预算。任务需要 gang 资源时一次性分配，分区评估则可以弹性并行。抢占低优先级任务前保存游标与部分提交结果，恢复时只重做未完成分区。Ray 和 Spark 各有资源与执行能力，评估平台通过统一 job spec 连接它们 [11][25]。

并发与限流

大量 judge 请求可能压垮模型 serving、网络和成本预算。评估调度器需要按 evaluator、模型、租户和数据 snapshot 限流，使用 token budget 而不是只限制请求数。模型服务过载时，评估任务退避或切换到已批准的低成本 judge，但必须标记 evaluator 变化并重新判断可比性。

评估对线上服务的影子流量也要限流。影子请求不应改变业务状态，不应占用生产租户预算，却会消耗 GPU 和 cache。路由器将影子流量送到隔离池，并把其影响计入容量报告。评估平台和 serving 平台共享 trace id，能说明某次回归是否造成了生产尾延迟变化。

结果存储与聚合

结果存储采用 sample result、partition result、evaluation run 和 report 四层。sample result 保存单样本输入 hash、输出 hash、指标、错误、耗时和 token；partition result 保存分区统计与完成标记；evaluation run 保存配置、覆盖和状态；report 保存聚合、图表、失败样本和结论。每层都有不可变版本，聚合可以重算但不能覆盖原始样本结果。

聚合器处理缺失、重复和重试。同一 sample_id 的多个 attempt 需要选择最终有效结果并保留历史；超时不能默认为负分；评估器返回非法 JSON 要作为 evaluator_failed；是否进入质量分母依预先冻结的协议，所有跳过均报告coverage及原因，不能事后删除难例。报告生成失败不应删除已完成的单样本结果，修复后可以重新聚合。

评估协议与提示模板

评估协议定义输入格式、系统指令、历史消息、工具 schema、最大 token、采样、超时、重试和评分。模板变化会改变模型看到的 token、角色和约束，必须作为协议版本。评估器执行时打印最终 prompt 的 hash、token 数、模板版本和模型版本，必要时保存脱敏后的渲染结果。

协议还规定错误处理。模型超时、输出截断、非法 JSON、工具失败、judge 失败和数据缺失分别是什么状态，是否重试，是否进入分母。不同协议混用会让“失败率”没有意义。评估平台提供统一协议 SDK，减少各团队手写脚本造成的行为差异。

生成评估的可重复性

temperature 大于零时生成具有随机性，服务端可能使用不同 kernel、batch 或随机数路径。评估可以固定 seed、运行多次取均值、使用 deterministic decoding 或保存完整输出；每种方式有不同成本和代表性。报告保存 sampling、seed、重复次数、输出长度和失败样本，不能只保存最终平均分。

对话和 Agent 任务还存在外部状态随机性：检索索引变化、工具返回变化、时间、权限和用户上下文。回放使用 snapshot、sandbox 和录制结果，必要时标记与生产有差异。可重复性不是强求所有系统位级一致，而是让差异来源可解释，并在质量门限中设置合理容差。

评估结果的可信等级

可以给评估结果分为 exploratory、diagnostic、regression、release-gate 和 audited 五级。探索结果快速、样本小、不能用于发布；诊断结果定位问题；回归结果固定集可比较；发布门禁经过完整配置和覆盖检查；审计结果额外包含人工签署与数据授权。结果对象带有等级和允许用途，防止一个草稿分数被误用为生产证据。

可信等级由覆盖率、评估器校准、样本版本、运行时完整性、人工复核和统计置信度决定。等级不是评价模型好坏，而是评价证据强弱。发布控制器要求足够等级的 evidence bundle，研究 dashboard 可以显示低等级结果但明确标识。

评估平台的容量与成本

评估 job 也需要容量模型。每个样本的输入、输出、judge、检索、工具和重复次数决定 token 与 GPU；发布高峰可能同时触发多个模型候选、多个数据集和多个 judge。调度器按 deadline、priority、token budget 和 GPU 资源排队，预留发布容量，限制低优先级 benchmark。评估成本归因到 experiment、team、model 和 dataset，避免免费评估无限增长。

评估缓存可以降低成本，但不能改变证据语义。缓存 key 包括所有输入、模型、模板、评估器、数据、运行时和权限；任何变化失效。报告分别显示 cached 与 uncached，发布门禁保留冷跑样本。缓存命中率很高但结果仍错误时，系统可能把错误长期固化，因此保留随机冷样本很重要。

任务级指标

评估平台指标包括等待、执行、token、GPU、judge、cache、覆盖、失败、重试、成本和结果写入。按 evaluation run、partition、evaluator、model、dataset 和 priority 聚合，避免只看一个总耗时。Prometheus 负责趋势与告警，OpenTelemetry 连接控制面、worker、模型服务和存储 [18][19]。

评估事故

典型事故包括数据 snapshot 错误、评估器版本混用、judge 偏差、缓存污染、分母计算错误、结果丢失、线上 shadow 影响生产和敏感样本泄露。事故处理先冻结报告和发布门禁，保留原始结果与 trace，确定影响范围，再重新生成修复后的 run。不能直接编辑一张分数表来“修正”历史。

事故复盘形成质量规则、数据断言、权限策略或回归样本。若一个错误样本导致线上事故，加入 critical 集并记录修复标准；若某个评估器反复超时，调整资源和预算；若缓存造成版本混用，修改 key 和门禁。评估系统自身也需要 SLO 和错误预算。

评估失败的降级策略

当 judge 模型不可用时，可以暂停、切换已批准的 judge、使用规则子集或转人工，但必须改变 evidence level，并重新判断门禁。不能为了按时发布而静默跳过困难样本。数据存储故障时可以使用镜像 snapshot，记录 replica；模型服务故障时可重试分区，记录重复成本。所有降级写入 run metadata。

如果评估覆盖不足，结果状态应为 INCOMPLETE 而不是 PASSED。发布控制器默认阻断 incomplete；人工可以在明确风险和补救计划下批准，并记录期限。错误预算和发布节奏不能成为降低质量证据的理由，最多决定是否推迟或选择安全的旧版本。

评估平台的灾备

数据 snapshot、manifest、评估结果和报告需要备份与恢复演练。原始敏感内容可能不可复制，但 manifest、hash、授权和报告至少应有跨故障域的可恢复副本。评估 worker 可以重建，结果不可重算或成本极高的 evidence bundle 需要更高保留等级。灾备测试验证恢复后的 hash、权限、版本和报告可读。

发布事故时，平台需要能读取最后一个已批准报告、模型 artifact、数据 snapshot 和门禁配置，即使评估集群不可用。否则无法判断是否回滚。灾备不等于把所有内容复制到所有区域，依然要遵守数据驻留与删除策略。恢复路径写入 runbook，并定期演练。

评估调度与业务执行的职责边界

本章job调度只负责把固定case分发到已批准环境、生成可聚合结果，并控制资源、超时和预算。第11章Runtime负责用户Task/Run/Step/Operation的持久状态、外部副作用及恢复，评估系统通过隔离fixture或受控回放消费它的接口。不能把“eval分区重试”解释成“业务写工具可以再调用一次”。数据snapshot提交标记和本书prepare/validate/commit是应用层协议，不自动获得数据库跨系统ACID；别名更新要有原子条件，所有分区可见且校验通过后才提交，失败重试不覆盖已接受快照。

10.8 质量门禁、发布与验收

门禁规则

门禁由硬约束、软阈值和人工检查组成。硬约束包括 schema 合法、关键安全指标、工具副作用、数据授权和 artifact 完整；软阈值包括质量变化、延迟、成本、覆盖率和置信区间；人工检查用于裁判争议、重要客户、少数语言和高风险案例。每条规则写明基线、容差、样本、统计方式、owner 和有效期。

门禁结果应可解释。失败报告列出退化能力、样本、模型版本、数据和运行时差异；通过报告列出覆盖范围和剩余不确定性。不能只输出一个绿色或红色状态。模型注册表只接收 evidence bundle 完整的 candidate，灰度控制器读取同一份门禁结果。

A/B、影子与 canary

A/B 比较需要随机化、分桶、实验周期、样本量和停止规则。流量分配要避免同一用户在两个版本间频繁切换；多轮对话和 Agent 任务要按 parent task 分配。影子流量不应触发真实工具副作用，工具结果可以录制或 sandbox。canary 期间同时观察质量、SLO、成本、安全和用户反馈。

统计显著不等于业务重要。一个小指标提升可能没有实际价值，一个高价值任务的少量回退可能必须阻断。报告给出效应大小、置信区间、样本覆盖和业务权重，决策记录由负责人签署。实验结束时归档数据 snapshot、配置和结论，避免无限期占用线上资源。

注册、审批与回滚

模型注册表连接训练、评估、部署和审计。artifact 进入注册表前校验 hash、来源、许可证、质量门禁、兼容矩阵和安全扫描；状态变更记录操作者、时间、原因和证据。回滚选择已验证的旧 artifact、旧模板、旧评估规则和旧路由，而不是只恢复权重。

回滚后要验证线上请求、cache、工具、计费和 trace。新版本产生的反馈不能直接归到旧版本，旧版本回滚期间的请求单独标记。发布控制器保留最近多个健康版本和恢复演练记录，避免“理论上可以回滚”在事故时失败。

新模型候选

新模型候选先通过 artifact、schema、安全和加载检查，再运行 smoke；通过后执行 critical 回归与目标任务评估。模型质量与旧版本做配对比较，输入输出长度和模板固定；同时测 token、GPU、TTFT、TPOT 和成本。遇到关键任务回退时自动阻断，普通任务小幅变化进入人工评审。

Prompt 或模板变更

Prompt 变更看似不改模型，却可能改变 token 长度、prefix cache、工具调用和安全边界。评估使用同一模型与同一数据，比较模板前后输入 token、格式、引用、工具成功和质量。灰度按 parent task 分桶，避免多轮任务混合版本。模板 manifest 和回滚路径与权重一样重要。

检索器或知识库变更

知识库更新先生成新的 snapshot，运行检索 recall、precision、context relevance、引用和最终任务；然后用线上历史 query 回放。若文档删除、权限变化或 chunk 策略变化，旧 cache 和评估结果按血缘失效。检索器质量提升但上下文变长，需重新评估 serving 成本和 TTFT，不能只看答案分数。

量化或 engine 变更

量化和 engine 变更固定模型与数据，比较输出差异、结构化合法、工具参数、长上下文、质量、显存和吞吐。失败样本按层、长度和任务分类，定位是精度、kernel、采样还是模板。通过后先影子，再灰度；回滚同时恢复 engine、量化、cache 和路由。评估结果绑定硬件和 driver，跨硬件不能直接复用。

评估平台的发布接口

发布控制器通过 API 提交 evaluation request，指定 candidate artifact、baseline、dataset snapshot、protocol、metrics、threshold、deadline 和 evidence level。评估平台返回 run id，异步上报状态、分区、结果和最终 report。控制器不读取内部数据库，避免与实现耦合；评估平台也不直接修改生产路由，只提供可验证证据。

接口包含 idempotency key 和 report hash。重复提交返回同一个 run 或明确创建新 attempt；部分结果不覆盖已提交结果；报告生成后不可变，修订通过新版本关联旧报告。这样发布、回滚和审计可以使用稳定引用，避免“页面上分数变了但不知道为什么”。

成本与质量的决策表

发布评审可以使用质量—成本—时延决策表。若质量提升、成本降低、延迟不变，且覆盖、安全、数据与证据门禁也满足，可按既定规则通过；若质量提升但成本显著增加，要求业务审批；若质量不变但成本降低，优先灰度；若质量下降但时延降低，只在低风险场景评估；若安全或关键任务下降，无论成本和延迟如何都阻断。表格不是替代判断，而是把预先接受的取舍公开化。

成本包括数据处理、标注、评估、judge、serving、存储和人工。某个模型在 benchmark 上更便宜，但如果失败导致更多重试和人工，单位成功任务成本可能更高。报告用同一场景比较成功任务、token、GPU、标注和人工时间，避免只看云账单的一部分。预算超限触发停止或降级，不应让评估无限运行。

数据治理验收

随机抽取一个训练或评估 snapshot，验证来源、授权、schema、处理 DAG、分区、统计、去重、敏感等级、manifest hash 和删除流程。修改一个过滤规则，确认血缘能找到受影响的模型和评估；撤回一个数据源，确认新的评估不能继续读取而历史审计仍然可查。质量门禁要覆盖自动断言、人工抽样、失败隔离和重试。

评估可靠性验收

使用固定回归集重复运行，验证结果、随机性、judge、缓存、并发、断点和部分失败语义。故意损坏一个分区、停止一个 worker、让 judge 超时、改变模型版本和修改模板，确认系统不会把缺失或旧结果当成通过。评估报告必须包含覆盖率、失败分类、成本、耗时、质量分层和置信区间。

线上反馈闭环验收

从线上 trace 抽取一批失败样本，验证脱敏、权限、采样、标注、去重、污染检查、回归集候选、修复后评估和发布关联。执行一次漂移检测，确认输入、输出、工具和安全指标能分层；执行一次回放，确认不会触发真实副作用。反馈集和训练集交叉时，血缘系统应阻断或显式标记不可比。

任务结果与模型分数分开判定

确定性不变量优先由单元/性质测试验证，协议和工具错误用契约测试，存储/队列/沙箱用集成测试；开放文本按任务标准和多次评测，不按逐字快照拒绝合理措辞变化。高风险链路补端到端与故障注入，Mock用于控制故障并不替代真实环境验收。规则文件、Skill与prompt也作为版本化配置进入同一套对照。发布决策引用完整report hash和责任人，评估执行completed、HTTP成功、judge高分与业务完成始终是不同事实。

10.9 本章小结

评估的规范源是版本化Eval Case、执行记录与不可变报告。数据快照回答使用什么，协议与判定器回答怎样测量，统计与校准回答证据多强，门禁回答谁允许在哪个范围发布。来源提供机制，教学案例提供推演，真实运行需要另行保存环境、样本与结果，三者不能互相替代。

下一章消费这些契约定义可恢复业务Runtime。第22章再展开Agent轨迹、行为与防护评测，沿用这里的样本、分母、校准和报告定义；第12章负责组织审批、运营修复和保留，不再复制一套评估事实源。

10.10 参考资料

[1] Zaharia, M., et al. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. NSDI, 2012. https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/zaharia 访问日期：2026-10-17

[2] Dean, J., & Ghemawat, S. MapReduce: Simplified Data Processing on Large Clusters. OSDI, 2004. https://research.google/pubs/mapreduce-simplified-data-processing-on-large-clusters/ 访问日期：2026-10-17

[3] lakeFS. Version Data. 官方文档，核验2026-10-17. https://docs.lakefs.io/guides/version-data/

[4] TensorFlow. TensorFlow Data Validation. https://www.tensorflow.org/tfx/guide/tfdv 访问日期：2026-10-17

[5] Liang, P., et al. Holistic Evaluation of Language Models (HELM). 2022. https://arxiv.org/abs/2211.09110 访问日期：2026-10-17

[6] Srivastava, A., et al. Beyond the Imitation Game: Quantifying and extrapolating the capabilities of language models. 2022. https://arxiv.org/abs/2206.04615 核验2026-10-17

[7] Es, S., et al. Ragas: Automated Evaluation of Retrieval Augmented Generation. 2023，v2 2025. https://arxiv.org/abs/2309.15217 核验2026-10-17

[8] Delta Lake. Delta Lake Documentation: Introduction. 核验2026-10-17. https://docs.delta.io/

[9] MLflow. ML Tracking Documentation. https://mlflow.org/docs/latest/ml/tracking/ 访问日期：2026-10-17

[10] Langfuse. Datasets. 官方文档，核验2026-10-17. https://langfuse.com/docs/evaluation/experiments/datasets

[11] Apache Spark. RDD Programming Guide. 官方4.2.0在线文档，核验2026-10-17. https://spark.apache.org/docs/latest/rdd-programming-guide.html

[12] Great Expectations. GX Core Overview. 1.24.0，核验2026-10-17. https://docs.greatexpectations.io/docs/core/introduction/gx_overview/

[13] Gao, L., et al. The Pile. 2020. https://arxiv.org/abs/2101.00027 访问日期：2026-10-17

[14] Grattafiori, A., et al. The Llama 3 Herd of Models. arXiv v3, 2024. https://arxiv.org/abs/2407.21783 核验日期：2026-10-17

[15] DVC. Get Started with DVC. 官方数据版本入门，核验2026-10-17. https://doc.dvc.org/start

[16] 《动手学深度学习》作者. 4.4 模型选择、欠拟合和过拟合. 中文2.0.0. https://zh.d2l.ai/chapter_multilayer-perceptrons/underfit-overfit.html 核验2026-10-17

[17] Hugging Face. Datasets: Process. 官方文档，核验2026-10-17. https://huggingface.co/docs/datasets/process

[18] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

[19] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[20] Hendrycks, D., et al. Measuring Massive Multitask Language Understanding. 2020. https://arxiv.org/abs/2009.03300 访问日期：2026-10-17

[21] NIST/SEMATECH. e-Handbook of Statistical Methods: 7.2.4.1 Confidence Intervals. 在线手册，核验2026-10-17. https://www.itl.nist.gov/div898/handbook/prc/section2/prc241.htm

[22] Liu, Y., et al. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. 2023. https://arxiv.org/abs/2303.16634 核验2026-10-17

[23] Zheng, L., et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. 2023. https://arxiv.org/abs/2306.05685 核验2026-10-17

[24] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[25] Moritz, P., et al. Ray. OSDI, 2018. https://www.usenix.org/conference/osdi18/presentation/moritz 访问日期：2026-10-17

第11章 Agent Runtime

用户任务可能跨模型、工具、外部系统和人工等待，进程内循环无法承载全部执行事实。Runtime的核心是：模型提出候选，状态机决定能否推进，业务系统确认动作是否生效。连接断开、worker重启和模型说“完成”都不能替代持久状态与外部证据。

本章定义Task/Run/Step/Event/Artifact和Operation的最小契约，用提交、可靠投递、执行权、未知结果、checkpoint和结果查询连接它们。全部字段和时序是通用教学设计；Temporal、LangGraph等只为特定机制提供参考，不据此宣称某个Agent产品已实现完整事务恢复。完整规划与多Agent模式放第21章，模型线协议放第17章，工具生态与执行安全放第18章。

11.1 对象模型与持久状态机

Task、Run 与 Step

Task 是用户期望完成的目标，Run 是一次实际执行，Step 是运行时对模型、工具、检索、审批或子任务的一次调用。一个 Task 可以有多个 Run，例如用户明确重新运行或版本对比；同一次Run的系统恢复只新增attempt和owner代次；一个 Run 由可持久化的 step DAG 或状态图组成。将 Task 与 Run 混为一个 id，会让重试和计费无法区分，也会把不同版本的执行历史覆盖。

每个 Run 保存入口请求、模型与工具版本、租户、预算、deadline、权限、状态、父任务和 trace id。Step 保存输入引用、输出引用、尝试次数、开始结束时间、资源、错误、幂等键和补偿动作。大文本不直接嵌在状态表中，而是存 artifact 或 message store，通过 hash 和版本引用，避免状态膨胀。

Event 与状态机

运行时的事实由追加式事件组成，例如 RUN_CREATED、STEP_STARTED、MODEL_COMPLETED、TOOL_REQUESTED、TOOL_SUCCEEDED、APPROVAL_REQUIRED、RETRY_SCHEDULED、RUN_PAUSED 和 RUN_COMPLETED。当前状态由事件派生或由带版本的状态快照保存。重复事件、乱序事件和迟到 worker 回报必须通过 sequence、attempt 和状态版本校验。

状态机定义可接受迁移：RUNNING 可以进入 WAITING_TOOL、WAITING_APPROVAL、PAUSED、FAILED 或 COMPLETED；COMPLETED 不能被迟到的失败事件覆盖；CANCELLED 的新工具动作必须被拒绝。Temporal通过有序event history恢复执行 [1]。AWS Step Functions区分Standard的工作流执行模型、异步Express至少一次和同步Express至多一次，不能把某个产品层的exactly-once术语当所有外部工具副作用的保证 [2]。平台不一定使用它们，但必须具备同等明确的状态语义。

控制面与执行面

控制面负责创建 Run、选择模型和工具、持久化状态、发放租约、调度 Step、处理审批、重试和恢复；执行面负责具体模型请求、工具调用、沙箱、检索和流式输出。执行 worker 可以无状态重启，控制面通过 durable state 让它从租约和 step attempt 恢复。worker 不应私自修改 Run 的全局状态，只提交带版本的事件。

控制面和执行面的边界也决定安全。控制面验证用户权限、工具 allowlist、预算和模型能力；执行面使用短期凭证访问具体资源。即使模型生成了一个看似合理的工具调用，也必须经过控制面 schema、租户、目标资源和审批检查，不能由 worker 直接执行。

ReAct 不是生产状态机

ReAct 把推理和行动交替组织起来，让模型根据观察结果继续计划 [3]。在生产中，模型提出的结构化动作、简要决策依据与observation需要被解析、校验、持久化和限制；不要求展示或保存模型完整内部思维链；不能将自由文本直接当作状态迁移。运行时把模型调用视为一个产生候选动作的 step，动作经过 schema、权限和预算检查后才进入工具执行。

循环要有最大 step、最大 wall-clock、最大 token、最大工具调用、最大并行度和重复检测。模型可能反复调用同一个工具、不断改写计划或把错误观察当成事实。运行时维护 step fingerprint、工具参数 hash 和 observation hash，检测循环并触发重新规划、降级或人工接管。Toolformer 的工具调用学习说明模型可以学会插入 API 调用，但运行时仍需把调用当作不可信输出 [4]。

Message store 与 Context builder

Runtime 不应把全部历史消息直接拼进每次 prompt。message store 保存原始消息、来源、时间、权限、hash 和 parent；context builder 根据当前 step 的预算、任务、工具、记忆和安全策略选择可见上下文。模型看到的最终 prompt 记录版本和组成摘要，便于回放与审计。

上下文构建需要优先级：系统指令、当前任务约束、工具 schema、必要观察、相关记忆、历史消息、低优先级背景。超出窗口时可以摘要、压缩、检索或失败，不应静默删除安全约束和用户目标。上下文预算同时影响 latency、token 成本、KV 和质量，Runtime 把它作为调度参数。

短期状态与长期记忆

短期状态包括当前 Run、step、观察和临时变量；长期记忆包括用户偏好、历史事实、工作成果和可检索文档。两者有不同可靠性和权限，不能因为模型生成了一句话就写入长期记忆。Memory 记录 source、confidence、created_at、updated_at、expiry、tenant、subject 和 consent；冲突时保留证据与版本。

Generative Agents 展示了记忆、反思和计划如何支持长期行为 [5]，但生产 Runtime 还要增加删除、纠错、租户隔离和过期。记忆召回进入上下文前执行权限和相关性检查，用户可以查看、修改或删除。模型对记忆的陈述不是事实来源，重要动作仍需外部系统确认。

状态一致与并发

同一 Run 可能由恢复 worker、用户取消、工具回调和定时器同时更新。状态存储使用 optimistic concurrency、版本号或 actor single writer，拒绝旧版本写入。事件处理器幂等，projection 可重建。多 Agent 共享任务状态时，明确哪些字段只能由协调者写，哪些是 append-only message。

分布式锁不能解决所有问题：锁超时、worker 崩溃和外部副作用仍会产生重复。状态机、租约、幂等键和查询接口组合起来，才能安全恢复。每次状态更新返回 version，调用方用 compare-and-set；冲突时重新读取并决定合并或失败。

规范对象与单写者不变量

本书选择数据库条件更新作为教学基线：事务检查当前状态、version和owner代次，成功更新状态并追加事件；事件表按run_seq唯一，客户端墙钟不决定因果。actor单写者也仍需持久化与失效owner处理。投影可以重建，但普通trace可能采样、脱敏或截断，不能代替权威事件账本。终态保护的是执行承诺；晚到的外部业务事实仍要追加核验记录，不任意把CANCELLED改回RUNNING。

中文D2L区分训练拟合与对新样本的泛化 [6]；一个Agent成功demo也不能证明新任务可靠。本章只固定持久对象和恢复不变量，模型质量仍消费第10章Eval Case与报告。ReAct、Toolformer、Generative Agents的研究能力并不自动提供业务事务或权限系统，产品是否实现这些契约要另找实现证据。

11.2 提交、调度与可靠投递

提交与Outbox同事务

裸双写存在两个窗口：先发MQ而数据库回滚会得到幽灵任务；先提交数据库再发MQ，进程崩溃会留下永不执行的任务。Transactional Outbox把待发送消息写入更新业务实体的同一事务，再由独立relay发布，relay仍可能重复发送 [7]。这里采用本书教学契约：在同库事务内写Task/Run、初始Step、RUN_CREATED和outbox记录，提交成功才向客户端返回task_id/run_id及查询入口。PostgreSQL事务的原子可见性仅覆盖该库操作 [8]；MQ与第三方工具不在这个事务里。

请求键在租户/动作范围建立唯一约束并绑定canonical payload hash；重复请求读取已有身份，不创建第二个任务；同键异参拒绝。接入层在提交后丢回执时，客户端可持原键重试或查询。Task创建成功不代表worker已开工，响应应区分accepted、queued与running。若大输入放对象仓库，先完成载荷与hash校验再写受控引用，未引用临时对象通过TTL清理；不能提交一个尚不可读的artifact地址。

Relay、CDC与消费确认

relay可以轮询已提交outbox，也可用CDC读取事务日志。Debezium Outbox Event Router示例使用事件id供去重，aggregateid作为消息key以维持相关分区顺序 [9]；这不是全局总序，connector重启、重放和offset管理仍需运维。轮询器可用PostgreSQL FOR UPDATE SKIP LOCKED 分批认领，官方明确其视图不一致、适合队列表避锁而非一般一致查询 [10]。不应持数据库事务跨越整个慢MQ发送；本书建议短事务认领带期限的relay批次，事务外发送后再条件标记，认领到期可重投。

无论polling还是CDC，发送成功但发送标记/offset未提交都会重复，不能宣称outbox消除了重复。固定event_id，接收端以inbox唯一约束、逻辑Step和当前版本去重 [11]。在同一消费事务中保存inbox及可恢复调度事实，再ACK；崩溃后重投，发现已持久化则幂等返回。ACK不能早于必要状态持久化，但也不必让MQ连接覆盖数小时执行：先把“待执行Step及归属”可靠接走，执行由持久状态调度器管理。消费者抢占失败、任务已终结或消息过期时分别记录处置，不把重复消息当新Run。

outbox监控包括最老未发送年龄、重试、毒消息、CDC延迟和task/outbox/队列差异；定期核对“已接受但无可调度Step”的任务。无法解析的消息进入带schema版本、原因和payload受控引用的隔离队列，修复后沿原event_id重放，不能换ID掩盖重复。队列只是唤醒/传递机制，权威执行状态在持久库中；MQ短时不可用时任务仍可查询，容量满了应拒绝新接收。

并行与依赖

无依赖的检索、文件读取或模型候选可以并行，依赖同一状态的写操作必须串行。并行执行降低总延迟，却增加 token、连接、资源和失败组合。运行时为每个分支分配 child step、预算和 trace，只有所有必需分支满足 join 条件才继续；可选分支失败可以降级，但必须记录。

并行限制至少包括全局、租户、Run、工具和目标资源。一个用户让 Agent 启动很多并发工具调用，可能打爆数据库或第三方 API；工具自身也可能有限流。调度器使用 semaphore、租约和 deadline，超过容量进入队列或明确失败。Ray actor 和任务模型可作为分布式执行参考，但状态与副作用仍由 Runtime 负责 [12]。

长任务与租约

worker 领取 Step 时获得带期限 lease，持续心跳或续租；失联后控制面在 lease 过期后重新调度。工具本身也可能继续执行，重新调度前查询 operation 状态。lease 不能替代幂等，网络分区下旧 worker 可能恢复并提交迟到结果，控制面使用 fencing token 拒绝旧 owner。

长任务的心跳包含 progress、resource、attempt、checkpoint 和预计完成；心跳不上传敏感内容。控制面根据 heartbeat 判断卡死、慢任务和预算，必要时暂停或迁移。迁移策略写入 workflow：模型 step 可以重算，副作用 step 先查询，人工 step 等待或转移队列。

重规划保留已验证产物、已发生副作用和UNKNOWN，只重算受影响节点及下游；新plan有版本和改变原因，目标或授权范围改变需重新确认。并行join声明必需/可选分支与超时，父子共享预算，更换工具或转派不能重置全局次数、费用和deadline。

Lease、Fencing与迟到worker

数据库认领需要条件：Step仍可运行、重试时间到达、旧lease已过期，且配额可用；原子增加owner_epoch并设置owner/lease_until。使用服务端受控时间与持久单调代次，随机锁值不是fencing token。续租证明活性，progress_seq、已提交产物和步骤变化才证明进展；心跳正常而进度长期不变必须诊断依赖、空转和锁等待。

Kleppmann的fencing方案要求每次写携带单调token，并由资源端检查并拒绝旧token [13]。只在任务库拒绝旧owner，不能撤销它已经发给第三方的请求。执行网关和支持的目标资源都应检查epoch；目标不支持时依靠稳定业务键、串行操作通道和事后对账限制风险，能力不足则禁止自动重发或转人工。恢复worker先取得新代次再核查operation，不能读取旧checkpoint中的owner值就认为拥有执行权。

11.3 Operation 与工具副作用

工具注册表

工具注册表保存 name、version、description、input schema、output schema、side effects、timeout、retry、rate limit、required scopes、data region、owner、sandbox 和 compensation。工具版本不可变，升级生成新版本；模型看到的工具列表来自当前租户和 Run 的权限，而不是全局目录。MRKL 将模型与外部模块结合的思想说明，路由和工具能力需要显式边界 [14]。

工具描述过长会增加上下文和选择歧义，过短会让模型参数错误。注册表为模型生成规范化 schema 与示例，同时保留机器校验的 JSON Schema。MCP的Tools规范提供发现和调用对象，JSON Schema Draft 2020-12提供结构校验词汇 [15][16]。schema通过只说明形状满足约束，不代表授权、事实正确或动作成功。

调用前校验

模型生成的名称、参数、目标资源和用户意图都不可信。调用前执行 schema 类型、必填字段、范围、正则、引用存在性、租户权限、目标资源 allowlist、数据区域、预算和审批校验。校验失败可以让模型修复参数，但修复次数有限且不能绕过权限。错误信息返回给模型时要避免泄露内部凭证、系统路径和安全策略细节。

工具调用在执行前生成 operation id 和 idempotency key，持久化请求摘要与状态。重复提交首先查询原 operation，而不是重新执行。Idempotent Receiver 模式适合处理至少一次消息投递 [11]；业务工具还需要自身支持幂等或提供查询接口。没有幂等保证的副作用应强制人工确认或禁止自动重试。

MCP 与协议适配

MCP 将工具和资源暴露为可发现、可调用的协议对象 [15]。Runtime 需要在协议适配层统一超时、取消、权限、审计和错误，而不是把每个 MCP server 的行为直接暴露给模型。server 能力、版本、schema、资源范围和安全声明进入注册表；调用时建立 parent trace 和 operation id。

协议适配要处理 server 断线、能力变化、版本不兼容、流式结果、分页和取消。发现到的工具不能自动获得全局权限，租户和 Run 仍需选择 allowlist。MCP 的可组合性提高了工具生态，但也扩大了供应链与数据边界，运行时需要签名、来源、审批和速率限制。

重试分类

重试必须根据错误类型决定。网络超时、限流、临时不可用通常可退避；schema 错误、权限拒绝、用户取消、预算超限和确定性业务错误不应自动重试；模型输出不确定时可以有限次重新采样，但要增加 attempt 和成本。Google AIP-194限定自动重试适用条件与错误分类，不能只凭网络错误就重试有副作用请求 [17]。退避、抖动和deadline属于本书的跨层预算设计。

重试预算按 Run、Step、工具、租户和全局设置。指数退避加随机抖动避免惊群；deadline 传递到每一层，剩余时间不足时直接失败或转人工。重试沿用逻辑Task，每次模型或供应商尝试仍可能产生实际费用；同一计量事件重复投递不得重复结算，业务副作用则按Operation契约去重。每次 attempt 保存输入 hash、模型版本、错误、等待、输出和资源。

幂等的 owner 必须明确到边界。Runtime为逻辑业务调用保存operation id，消息仍可能重复，必须以稳定身份幂等接收；工具 adapter 负责把 id 传给下游；真正拥有业务状态的订单、邮件、文件或支付系统则必须决定相同 id 的重复提交如何返回同一事实。若下游只提供“尽力而为”的 HTTP 接口，Runtime 无法凭本地去重表承诺业务幂等，因为网络在提交后的断开会留下未知状态。Enterprise Integration Patterns 的 Idempotent Receiver 模式正是将去重与消息接收边界绑定 [11]；在 Agent 系统中，边界还要覆盖模型重试、队列至少一次投递和人工重放。

operation id 应包含稳定的业务范围，而不是随机 request id。发送同一封通知可以使用 tenant + business-object + action + version；修改文件可以使用文件版本和补丁 hash；创建工单可以使用外部系统允许的 client token。若模型每次重试都重新生成操作语义或参数，系统必须先比较 canonical payload：相同意图可查询或去重，不同意图则是新操作，可能需要新审批。把“看起来相似”的自然语言当作幂等键会造成误合并，反过来把相同操作的随机 UUID 当作新请求会造成重复副作用。

幂等记录需要生命周期治理。短期通知可能只需要在业务 SLA 窗口内保留键；财务、权限和数据删除等操作则需要更长的审计与重放窗口。记录至少保存 operation id、payload hash、请求者、状态、外部引用、首次与最后一次观察、响应摘要、过期策略和 owner。过早删除会让延迟消息重新造成副作用，永久保留又会造成隐私和存储问题。保留期应与下游的重复投递上界、合规需要和补偿窗口一起确定，并通过文档而不是隐式代码约定。

Operation独立于Attempt

AWS关于幂等API的原文说明，客户提供的稳定请求标识可以表达意图，同标识而参数不同应报不匹配，去重记录和业务变更还需服务端原子处理 [18]。因此本书把operation_id绑定稳定业务动作，而不是每次模型采样或传输attempt生成新键。canonical hash用来发现同键异参，不能单靠参数相同推断用户一定只想做一次；两次独立授权、参数恰好相同的购买仍可代表两个业务意图。

外部查询返回“没查到”也要理解一致性和保留窗：可能尚未可见、键已过期或请求还在途。只有下游契约足以确认不存在，且可安全重试时才继续同键尝试；否则保留UNKNOWN。预算/审批到期不删除未决事实，停止新增动作后仍需核对已发请求。幂等窗口必须覆盖可能的延迟重投，过期恢复先查询或人工，不能把一条旧业务键简单当新请求。

11.4 Checkpoint、恢复与补偿

Durable execution

长任务可能运行几分钟、几小时甚至等待人工或外部事件。进程内状态和内存队列在重启后丢失，Runtime 需要 durable event、checkpoint、timer、signal 和 activity result。Temporal 的工作流模型把持久状态、activity、重试和定时器组合起来 [1]；数据库事件表也可以实现类似语义，但需要自行处理 replay、版本和并发。

持久化不等于每个 token 都写数据库。模型流式输出可以写 artifact、摘要或可恢复 offset；关键状态迁移、工具请求、审批和结果必须持久化。状态快照定期压缩事件，但保留事件版本和 hash，便于回放。大上下文使用 message store 或对象存储，状态表只保存引用。

恢复语义必须先回答“恢复什么”，再选择存储技术。恢复一个纯读取模型 Step，可以重新发起调用或复用录制结果；恢复一个尚未提交的工具操作，可以用同一 operation identity 继续；恢复一个提交后结果未知的写操作，首先要查询外部系统事实；恢复一个等待人工的 Step，只能恢复到等待状态，不能由 worker 推断批准。把这些情形都叫作 retry，会把不同的业务后果压成同一个按钮。Runtime 应在 Step spec 中明确 replayable、idempotent、query-before-retry、compensable 与 human-only 等恢复类别，并把分类同工具版本一起保存。

checkpoint 也不应只是“每隔 N 分钟存一次”。一个可恢复 checkpoint 至少包含 Run 与 workflow revision、当前状态机节点、已完成和待完成的依赖、每个 attempt、预算消耗、deadline、上下文与 memory 的不可变引用、已发出的 operation、租约/fencing token、审批状态和计时器。它还要标记哪些字段是观察结果、哪些是模型候选、哪些已成为外部业务事实。没有这一界线，恢复 worker 可能把上次模型的自然语言结论当作提交结果，或在重放时漏掉已经开始的补偿。

checkpoint 的写入点由恢复点目标决定。对只读链路，写在一个完整 Step 后通常足够；对会触发外部副作用的链路，必须在提交意图、获得 operation id、收到外部确认、开始补偿和完成补偿这些边界分别记录。写得过密会拖慢执行并放大状态库成本，写得过疏会使重启后的不确定窗口过大。团队应为每种工作流测量恢复点目标和允许丢失工作量，而不是把统一间隔当作正确答案。长时间模型流可用 offset 和 artifact hash 降低存储压力，但最终业务状态仍只能由持久事件确认。

恢复时的顺序同样重要。控制面读取最近一致 checkpoint，验证 workflow、工具、权限和 schema 是否兼容，冻结旧 worker 的提交权，再根据未完成节点的恢复分类安排新 worker。若旧 worker 在网络分区后恢复，它携带的 fencing token 已过期，控制面拒绝其迟到写入。若外部工具不能查询 operation 状态，Runtime 不能假装实现 exactly-once；它应把这项能力缺失暴露为风险，并为该工具要求人工核对或业务侧幂等。持久化编排系统的价值并非让失败消失，而是把失败后的事实、所有权与下一步动作保留下来 [1]。

补偿与人工接管

不可逆副作用不能依靠回滚数据库解决。发送邮件后可以发送撤回或补充通知，创建订单后可以取消，修改文件前保存版本，支付动作通常要求人工或业务事务。工具注册表声明 compensation、是否可逆、是否需要 approval 和失败后 owner。Saga 将一组局部事务及其补偿组织成长事务 [19]。

补偿本身也可能失败，不能假设它一定成功。Runtime 将主动作、补偿动作和人工任务放进同一状态图，记录部分成功和当前风险。对用户返回明确的 completed、partially_completed、needs_attention 或 failed，不把补偿未完成隐藏成成功。人工处理完成后以事件关闭，而不是直接修改历史状态。

补偿不是把数据库回滚一遍，而是为已提交的业务事实追加一个反向或缓解动作。它必须有自己的前置条件、权限、deadline、幂等键、可观测性和失败路径。例如已发送的邮件只能追加更正或撤回请求，不能抹掉收件人已经看到的内容；已创建的外部工单可以关闭，但不能保证对方没有开始处理；已写入文件可以恢复到一个已知版本，但若之后存在人工编辑，自动覆盖反而可能扩大损失。Saga 提供的是局部事务的协调思路 [19]，不是“所有动作都可逆”的承诺。

因此补偿计划应在执行主动作之前确定。工具注册表声明正常 operation、成功证据、补偿 operation、不能补偿的后果、人工 owner 和最大等待时间；workflow 在跨越不可逆边界前检查这些字段和审批。对于没有安全补偿的高影响动作，设计应改为预览、双人审批、延迟提交或由业务系统提供事务性 API，而不是把风险留给模型临场判断。补偿开始后，用户可见状态应变为 compensating 或 needs_attention，避免前端把“原动作成功”误展示为最终成功。

补偿完成也要按业务事实验收。HTTP 200、队列接受或模型说“已恢复”都不足够；Runtime 需要保存查询到的版本、外部对象状态或人工确认。若主动作只完成了一部分，补偿可选择继续完成剩余部分、撤销已完成部分，或交给人工，这三种选择各自改变成本、可用性和用户预期。工作流定义应把选择写成版本化决策，不能让新 worker 在事故现场临时猜测。

版本化工作流

工作流定义改变时，正在运行的 Run 不能突然使用新节点、重试和补偿语义。每个 Run 绑定 workflow version；新版本只用于新 Run，或通过明确的 migration event 在安全边界切换。Temporal 的版本兼容思想可以帮助处理长时间运行的代码变化 [1]。状态图节点 id、输入输出 schema 和 side effect 要保持稳定或提供迁移函数。

恢复边界

恢复优先从最近 durable checkpoint 或 step 边界开始，而不是重新执行所有步骤。纯读模型调用可以重试，幂等工具可以重试，不可逆工具需要查询 operation 状态，未知状态动作要进入人工。工作流版本、上下文 snapshot、memory version 和工具协议必须与 Run 绑定，恢复不能使用最新默认值。

恢复边界应在 workflow 设计阶段画出来。一个边界前的内容可安全重新计算，一个边界后的内容必须从已确认事实继续；两者之间是“提交已发出但事实未知”的灰区。灰区不是异常分支的细节，而是外部系统交互的常态：支付网关、邮件服务、工单系统、数据库写入和设备控制都可能在客户端看到结果前已经完成。Runtime 在灰区内保存 operation id、请求摘要、下游引用和最后观察时间，优先查询；查询仍不能消除不确定性时，转入显式人工队列，并禁止自动复制请求。这样做可能降低自动完成率，却保留了正确性与可审计性。

不同恢复类别需要不同验收。模型调用的恢复检查输入与配置是否可复现、预算是否还允许；检索恢复检查数据版本与权限是否仍成立；工具恢复检查 operation 状态与幂等窗口；等待事件恢复检查 correlation id、签名、deadline 与取消状态；人工恢复检查决定是否仍有效、操作者是否有权限。把所有 Step 交给一个通用 retry middleware 会遗漏这些业务条件。通用框架应提供状态、租约、超时和事件基础设施，具体恢复分类则属于 workflow 与工具契约。

版本演进时，恢复边界更不能被悄悄移动。旧 Run 的 checkpoint 可能引用已经下线的模型、工具 schema 或 memory 格式；新版本要么提供兼容 adapter，要么把旧 Run 保留在旧执行环境，要么在明确停机点由人工批准迁移。迁移事件记录旧值、新值、转换函数、验证结果和回退路径。若没有证明旧事件在新定义下仍有相同语义，系统应宁可暂停该 Run，也不要让“升级”变成一次未经批准的业务重放。

状态压缩与归档

长 Run 事件很多，状态存储需要 snapshot、事件归档、artifact 引用和 TTL。snapshot 包含状态版本、当前节点、预算、上下文引用、memory 引用、未完成 operation 和 workflow version；事件归档保留审计与 replay 所需的最小字段。用户删除或租户归档时，按照保留策略删除内容并保留合规的摘要。

归档后的 Run 仍可查询摘要、最终结果、成本和失败原因；恢复执行需要明确重新激活和权限。压缩不能丢掉不可逆动作、审批、补偿和安全事件。状态表只保存引用与索引，原始大文本和文件 artifact 由生命周期策略管理。

版本发布与回滚

Runtime 发布包括 workflow、模型、prompt、tool schema、policy、memory、router 和 evaluator。灰度按租户、任务类型、区域或实验组；影子运行不执行副作用。指标包括任务成功、步骤成功、重试、工具错误、成本、延迟、安全和人工接管。回滚是状态与路由转换，旧版本必须保留兼容的 schema 与恢复逻辑。

发布与回滚的最小单位是经过签名的 Runtime manifest。它不只包含代码 commit，还包含 workflow 定义、活动 worker 镜像、模型和 prompt revision、工具与 MCP server 版本、JSON Schema、policy、memory adapter、路由与配额、评估集、feature flag 和数据保留规则。Run 在创建时绑定 manifest hash；trace、checkpoint 和成本事件携带同一 hash。这样，团队能解释某次失败到底来自模型、工具、策略还是编排，而不是在多处默认配置之间猜测。

灰度需要把副作用隔离作为硬前提。影子 Run 可以读取同一输入、执行录制工具或只读查询、比较计划和结构化结果，但不能发送消息、修改文件、创建订单或写长期记忆。对真实流量放量时，按风险而非只按百分比选择：先选择可撤销、低权限、可人工观察的任务，再扩大到高影响任务。每一个阶段设定质量、重复操作、未知状态、恢复时延、成本、隐私和人工接管门槛；超过门槛后自动停止扩容并保存可回放证据。灰度不是“新版本可能有问题”的缓冲，而是让风险范围与证据增长同步的控制机制。

回滚也有两类。路由回滚让新 Run 立即使用旧 manifest；状态回滚处理已经在新 manifest 下运行的 Run。前者较快，后者必须尊重已开始的工作流、操作和补偿，不能强制把 checkpoint 解释成旧 schema。发布计划因此要列出：哪些 Run 可以继续完成，哪些必须暂停，哪些可迁移，哪些需要人工；旧依赖会保留多久；回滚演练使用什么录制事件；以及紧急情况下谁拥有冻结工具、撤销凭证和恢复流量的权限。把这些问题留给事故期间解决，往往会把技术回滚扩大为业务中断。

Checkpoint的联合提交边界

同库Step结果、状态version、关键Event和完成通知outbox尽量在一个事务里提交；大artifact先完整写入并校验hash，再提交指针，不能先推进进度后补载荷。checkpoint是已验证进度及未决operation的恢复索引，区别于第8章模型训练的权重/优化器快照，也区别于文件回退。恢复校验所引用载荷存在、版本兼容和权限仍有效；缺失不能跳过该Step假装完成。

Temporal通过事件历史重放工作流决定、复用已记录Activity结果，不是把进程内存快照直接搬回 [1]；LangGraph文档则区分当前thread的checkpointer与跨thread store，内存Saver重启后会丢失 [20]。这两种具体模型都不能直接等同于本书数据库checkpoint字段，也不能仅凭工具框架有checkpointer就推断外部业务已实现exactly-once。新版本先回放兼容性，不能拿新代码解释旧事实后重发真实写操作。

11.5 等待、审批、取消与外部事件

事件驱动与定时器

Agent 常需要等待 webhook、审批、定时、文件上传或外部 job。事件驱动系统用 correlation id、subscription、deadline 和签名匹配回调。重复 webhook 通过 idempotency key 去重，伪造回调通过认证与资源校验拒绝。定时器在控制面持久化，worker 重启不应丢失。

事件到达时 Run 可能已取消、超时或版本迁移。处理器根据状态和 event version 决定忽略、记录或触发补偿，不能盲目继续工具。外部事件的 payload 作为不可信 observation，进入模型前经过 schema 和权限检查。消息 broker 至少一次投递时，状态机和幂等是正确性基础。

Human-in-the-loop

审批适用于高风险写入、外部消息、支付、权限变更、删除、公开发布和不确定安全动作。审批请求包含目标、参数、影响、证据、风险、过期时间和可选修改；批准与拒绝都是事件。审批超时进入明确状态，不自动当作批准。用户取消 Run 后，待审批动作必须失效。

人工可以修改模型生成的参数，但修改结果标记为 human-edited；工具执行后不可通过回写历史假装未发生。人工操作也有租户、角色、双人复核和审计。Runtime 把人工接管作为正常状态，不把它当作异常黑洞。

取消请求、取消收敛与晚到成功

取消先持久化cancel_requested，停止新Step、重试和续跑，按归属传播到模型、工具及子任务；独立调度任务有自己的生命周期。安全点保存部分结果并转CANCELLING，协作退出超时可终止本地进程，但远端请求仍可能成功。取消控制执行，补偿处理已生效业务事实，是两个动作。late success通过operation核验追加事件，执行终态不倒退；必要时建立补偿或人工repair任务，用户看到“执行已取消，外部动作待核对”。

审批记录绑定动作、payload hash、目标资源版本、授权主体和有效期。人工修改参数不是沿用旧批准，必须生成新提案并重验。等待审批或定时器时释放worker，只保存持久订阅和resume条件；重复决定、伪造回调和过期批准不能重新开工。恢复前检查取消、预算、权限及资源状态；权限被撤回就拒绝，不能换工具绕过。需要澄清与需要审批也分别表达，模型说“用户已批准”不构成批准事件。

11.6 任务交付、流式恢复与查询

最小外部接口

Runtime 的外部 API 至少分成八类：task submit、run query、event stream、approval、cancel、resume、artifact 和 replay。提交接口接受目标、上下文、能力范围、预算、deadline、优先级和幂等键；查询接口返回当前状态、进度、成本摘要、需要的动作和可见结果；事件流提供状态变化但不暴露未授权内容；审批接口把人工决定写成事件；取消和恢复接口必须穿透模型、工具和等待队列；artifact 接口保存大文本、文件和证据；replay 接口用于调试和审计，不能重新触发真实副作用。

输出也要区分 final answer、partial answer、tool result、human decision、failure 和 compensation。客户端不能通过判断文本是否为空来猜测状态。结构化错误包含 code、retryable、retry_after、run_id、step_id 和 remediation；敏感内部错误只在受控 trace 中出现。Google AIP-194 对错误分类和重试语义的强调，适合迁移到 Agent API [17]。

状态机、工作流与流式是三个维度

状态机限制合法迁移，工作流组织步骤、依赖和错误处理，流式交付把进度/输出增量发送给用户；三者可以同时存在。流式处理还可能表示节点间逐块计算，需要独立定义块边界、背压及重复处理。工具参数只有部分JSON时必须缓冲、校验完整提案后才执行，不能把token流当业务提交。

任务、结果与事件日志独立于连接保存。客户端断线只影响订阅，重连按原task_id查询，不能自动创建新任务。WHATWG定义EventSource重连可发送Last-Event-ID [21]，但规范不提供服务端历史留存、持久任务或业务幂等。其他SDK/HTTP客户端是否记游标需自行实现，不能从支持SSE就推断恢复能力。

持久事件、水位与游标过期

本书采用每Run单调run_seq和全局event_id，持久提交后才向流发送；客户端按身份和序号去重，断线后从最后确认游标重放。状态写入和完成事件在同库事务关联，流投递失败不撤销业务完成，查询返回权威version、终态及结果hash。若客户端先收到“完成”而查询仍落后，按事件的提交水位重查权威源或等待投影追上，不以文字或旧副本判断成功。

游标在保留期内则鉴权后补发；已过期明确返回cursor_expired及可用范围，同时提供带snapshot_version、last_included_seq与完整结果引用的快照。客户端先替换旧视图，再从水位之后订阅，避免把后半段文本接到错误前缀。载荷已删除无法重建时说明恢复限制，不静默发送残缺尾段。重连仍要重验当前权限，原先能看过不代表撤权后可下载历史。

完成通知同样先提交事实再由outbox投递，稳定notification_id与任务version，接收端验签、防重放、幂等。回调目标有allowlist、超时、总重试预算和失败修复入口；只携带最小摘要与受控查询链接。通知失败不把已完成任务改成失败，通知到达也不替代用户查询最终结果。流缓冲和事件读取需背压，慢客户端不能无限占worker或原始敏感载荷。

11.7 隔离、预算、观测与回放

多租户资源

租户配额覆盖模型调用、输入输出 token、工具次数、并行 step、GPU、CPU、内存、存储、网络、长期记忆和人工审核。一个租户可能低 QPS 但运行长 Agent，另一个高 QPS 但短请求，单一 QPS 配额不公平。Runtime 同时维护 request budget、Run budget、project budget 和全局容量，超限返回可解释错误。

租户隔离包括状态、提示、记忆、工具、凭证、trace、cache 和 artifact。模型输出可能包含另一个租户的数据，任何跨租户共享 cache 或记忆都必须有明确的公共范围。Borg 的配额、优先级和隔离经验适合用来设计资源控制面 [22]；Kubernetes 提供执行层隔离基础 [23]。

调度优先级

交互式任务、批量任务、生产告警、人工审批和开发实验使用不同 deadline。调度器以可用资源、剩余预算、依赖就绪、租户份额和 deadline 选择 step。高优先级可以抢占等待队列，但不应随意打断不可逆工具；长任务被抢占后要保存 checkpoint 或返回可恢复状态。

Agent 的资源消耗不可只按一次模型调用估算。一个 Run 可能出现规划、检索、工具、反思、验证和重试。调度器维护动态 budget，step 完成后扣除实际 token、GPU 和外部调用，预测剩余成本与 deadline。达到阈值时可以摘要、换小模型、减少候选、暂停等待或请求人工。

成本与计费

计费事件按 request、step、tool operation、model token、GPU 时间、存储和人工记录。失败重试是否计费由产品定义，但平台必须保留真实成本。父任务与子任务共享 budget，工具副作用和人工审核单独计量。成本事件幂等并带版本，不能因为重试消费消息而重复计费。

成本归因还要连接成功任务。只按 token 计费会激励输出更长或反复重试；单位成功任务成本更接近业务价值。Runtime 把 task outcome、token、latency、工具失败、人工接管和模型版本放进同一 trace，支持不同模型和策略的比较。

沙箱与执行隔离

代码执行、浏览器、文件系统、数据库和网络工具应按风险使用不同隔离级别。容器、微 VM、进程沙箱、网络 egress allowlist、CPU/内存/时间限制和临时文件系统共同构成执行边界。Kubernetes 可以提供资源和命名空间基础，但不能替代工具级权限、凭证和审计 [23]。

工具 worker 使用短期、最小权限凭证，输出进行大小、类型、敏感信息和恶意内容检查。文件路径不能由模型直接决定宿主机路径；SQL 工具使用只读或参数化接口；浏览器工具限制域名、下载和登录状态。工具返回的文本标记来源和可信级别，进入下一轮上下文时要防止 prompt injection。

Prompt injection 与工具边界

工具返回、检索文档、网页和文件内容都可能包含让模型越权的指令。Runtime 将外部内容标记为 untrusted，系统指令、用户指令和工具结果分层；模型提出的动作必须经过权限和 schema，而不是让内容直接改变 policy。OWASP LLM01:2025明确外部网页/文件可带来间接提示注入 [24]。其他秘密、凭证与供应链控制属于这里的执行契约。

工具权限采用最小范围、短期凭证和目标 allowlist。用户可以允许“读取某项目文件”，但不等于允许写任意路径；允许查询数据库，不等于允许执行任意 SQL。权限决策记录主体、资源、动作、理由、策略版本和结果，供审计与回放。

凭证与秘密

Runtime 不把 API key、数据库密码或云凭证放进 prompt、事件或模型输出。工具 worker 通过短期 token、工作负载身份或秘密管理服务获得最小权限，token 绑定 tenant、run、tool、resource 和 expiration。重试使用同一 operation identity 或查询原状态，不能每次发放新宽权限凭证。

工具返回中的秘密扫描、日志脱敏和输出过滤需要独立层。即使模型无法理解秘密，后续 trace、缓存和人工标注也可能泄露。发生凭证疑似泄露时，Runtime 触发 revoke、隔离 Run、停止相关工具、保存审计和通知；不能只删除一条日志。

网络与文件隔离

代码、浏览器和数据工具使用 egress allowlist、DNS 限制、代理审计、文件系统 namespace、CPU/内存/PID 限制和执行时间。模型生成的路径、URL、SQL 和命令先由策略解析，再交给工具。容器 root、宿主机 socket、任意 cloud metadata 和跨租户网络默认禁止。Kubernetes 的 namespace、service account 和 network policy 是基础，但高风险工具可能需要 microVM。

沙箱输出限长、限类型、限存储，并标记 artifact owner。大输出存对象仓库并过期，小输出进入 event；二进制和脚本不直接嵌入 prompt。下载文件再被模型读取时，做 MIME、大小、编码、恶意内容和权限检查。运行时只提供必要的文件路径引用，避免把宿主机布局暴露给模型。

Runtime 供应链

workflow 定义、tool server、MCP server、prompt template、memory adapter、模型和 sandbox 都是供应链制品。注册表保存来源、签名、版本、依赖、权限和审批；运行时只加载允许的 hash。第三方工具升级需要重新做 schema、权限、超时、数据流和安全测试。容器和依赖锁定，网络 egress 限制，运行时禁止工具下载未审计代码。

Trace 结构

一个 Agent trace 以 task/run 为 root，包含模型 step、tool operation、retrieval、memory read/write、approval、retry、queue 和 compensation span。每个 span 携带 model revision、prompt hash、input/output token、tool name/version、tenant、budget、deadline、attempt、error 和 state version。Dapper 的分布式追踪方法和 OpenTelemetry 的上下文传播提供基础 [25][26]。

默认不记录完整 prompt、记忆和敏感工具返回；使用 hash、摘要和受控 event。需要调试时通过临时授权、采样和脱敏提升粒度。trace 与日志通过 trace id 关联，指标使用低基数标签。Prometheus 监控 Run active、step latency、retry、tool error、budget、queue 和 SLO [27]。

可解释的执行回放

回放读取事件和 artifact，按原始 workflow version 重建状态，不自动执行副作用。模型调用可以使用录制结果、sandbox 或新模型；工具使用录制 response、mock 或只读查询。回放标记哪些结果是真实、录制、模拟和重新生成，避免把新模型输出误当作历史事实。

回放支持三类目的：事故调查、版本比较和测试。事故调查重建失败路径；版本比较在同一输入和外部观察上运行新策略；测试验证状态机、重试、补偿和权限。回放数据带租户和数据等级，访问与导出审计。一个可回放的 Runtime 比仅能查看最后答案的系统更容易演进。

指标与 SLO

Runtime SLO 分为任务完成率、step 可用性、工具成功率、恢复时间、人工接管、总延迟、模型 TTFT/TPOT、成本和安全事件。Agent 任务的 HTTP 成功不代表完成；需要定义业务 outcome。SRE Workbook 的错误预算思想可以决定是否暂停实验、降低并发或切换稳定 workflow [28]。

任务级 SLO

Runtime SLO 包括任务完成、步骤完成、首个有意义结果、总时延、工具成功、人工接管、预算超限和安全事件。一个任务可能在单次模型调用都成功的情况下失败，例如工具参数错误、目标状态未改变或最终答案没有证据。业务 outcome 由 workflow 定义，平台记录 outcome type 与证据。

不同任务使用不同 SLO。告警处理 Agent 关心在 deadline 前完成和误操作；知识助手关心引用和答案相关；Coding Agent 关心测试通过和改动安全；批量抽取关心结构化合法和覆盖。统一平台提供指标采集，业务定义成功；不能用平均模型 latency 替代任务质量。

运行时成本

成本由模型 token、GPU、工具调用、网络、存储、记忆、评估、人工和重试组成。一个 Run 的成本树把 parent、child、step 和 operation 聚合，计费事件带 idempotency。重试的模型调用可计费，同一业务操作的重复回执不得重复结算，但工具或供应商的重试调用仍可能按契约收费；人工接管单独计入任务成本。

成本预算和质量门禁一起工作。若任务已经满足目标，继续反思和多候选只增加成本；若失败原因是外部工具，切换更大模型未必有价值；若输出不确定，增加验证可能降低人工成本。Runtime 暴露剩余预算给策略，但不让模型任意读取其他租户的预算或修改上限。

控制面暂时不可用时，执行器至多使用未过期、范围明确的已验证配置快照；缺少当前owner、审批或敏感策略证据时停止写动作。租户身份来自认证上下文，不能由模型参数任意指定；资源和管理面同样实施访问检查。

活性、进展与循环不是同一个信号

行动账本记录规范化工具、语义关键参数、身份/环境/时间窗、资源版本、结果摘要与产物变化。连续相同结果或A→B→A周期只是无进展候选，轮询、文件已修改后的复验和受控退避可能合理；不能只按工具名阻断。没有新证据、状态或产物时有界重规划，保留已排除假设，达到阈值转等待、澄清或部分交付，停止不标成功。多Agent循环转派的编排策略留第21章，本章提供parent budget、owner和不可重置的总deadline。

容量用到达率乘平均持有时间估计在途数，再乘模型轮次、token分布、工具扇出与重试系数；峰均比、突发及相关失败必须显式。队列和SSE改变接收与展示方式，不会自动提高实际吞吐。供应商TPM减半时重算可持续出队速率与等待承诺；某工具p99升高时限制其独立并发、隔离队列，让无依赖任务继续，不伪造实时事实。恢复与人工重放也计入容量预算，避免故障后积压同时释放造成二次冲击。

11.8 故障矩阵与最小交付契约

故障分类

模型故障包括超时、限流、格式错误、上下文超限和质量门禁失败；工具故障包括网络、权限、schema、部分成功和外部状态未知；运行时故障包括 worker crash、状态库不可用、事件乱序、租约过期和队列堆积；安全故障包括凭证泄露、越权、注入和敏感输出。分类决定重试、补偿、回滚和人工。

功能与状态验收

测试正常完成、模型错误、工具超时、权限拒绝、重复事件、迟到事件、worker 重启、状态库故障、人工审批、取消、过期和部分成功。验证每个状态迁移、attempt、幂等键、预算、trace 和资源释放。状态回放后得到的当前状态应与在线状态一致，重复 replay 不产生副作用。

验收用例需要把“未知状态”单独列出。最有价值的故障往往不是工具明确返回失败，而是请求在远端提交之后连接断开、worker 在写入本地事件之前崩溃、回调到达两次或乱序到达。测试应断言 Runtime 先查询 operation，再决定完成、重试、补偿或人工，而不是根据超时猜测失败。还要在 checkpoint 前后分别杀死 worker，检查恢复出的 workflow revision、输入 hash、attempt 和预算是否与事件历史一致。若无法构造这类演练，就不能宣称某个工具具有可靠恢复语义。

状态验收还应包含并发竞态：取消事件与工具成功同时到达，人工批准发生在 deadline 之后，旧 worker 在 lease 过期后提交结果，升级后的控制面读取旧版本 snapshot。每种竞态都要有唯一的可见终态和审计说明。建议把状态机转移表变成自动化属性测试：任意重复 event、乱序 event 或 replay 不得产生第二次业务提交；任意终态不得回到执行态；任意 needs_attention 都能找到 owner、证据和下一步期限。这些性质比只覆盖一条 happy path 更接近 Runtime 的正确性定义。

任务与工具验收

测试 schema 错误修复、工具重试、不可逆动作、补偿失败、MCP server 断线、server 能力变化、提示注入、恶意返回、文件路径、SQL、网络 egress 和敏感输出。每个工具有 owner、版本、权限、限流、超时、side effect 和 compensation 证据。工具成功不能只看 HTTP 200，还要验证业务状态与幂等。

工具验收应建立“契约样本”而非只依赖现场服务。每个版本保留正常返回、可重试错误、确定性错误、部分成功、畸形 schema、超大输出、延迟回调与权限拒绝的录制样本；adapter 对这些样本验证 schema、canonical payload、operation id 传播、脱敏和状态映射。MCP 或第三方 server 的能力变更要被视为兼容性事件：新增字段未必安全，删除字段、修改枚举或改变副作用语义必须阻断发布，直到 owner 重新签署契约。协议规范和 JSON Schema 是输入边界 [15][16]，但业务成功证据仍由工具 owner 定义。

对有副作用工具，验收报告要明确 idempotency 的实现位置。若由下游业务系统保证，应附上重复请求、未知状态查询和过期键的证据；若由 Runtime adapter 保证，应说明状态库故障与多区域重试下的边界；若只能人工处理，则不得在产品中标成“自动重试”。这种诚实的能力分级比把所有工具都贴上“reliable”标签更利于编排器作出保守选择。

资源与租户验收

测试多租户并发、优先级、公平、预算耗尽、长 Run、并行分支、GPU/CPU 配额、存储、记忆和 trace 隔离。检查一个租户无法读取另一个租户的 prompt、memory、cache、artifact 或工具结果；成本事件与 task outcome 能对账；超预算有明确降级和人工路径。

资源与成本验收应从“账能否对上”推进到“决策是否可复现”。对一组混合负载，报告每个 tenant、project、Run、Step 和 operation 的 token、GPU、存储、工具、重试与人工成本，并证明汇总值与原始不可变计量事件一致。随后改变一个策略参数，例如租户配额、模型路由或最大并行度，验证控制面能预测哪些任务会被延迟、降级或拒绝，以及结果是否符合政策。只在月末发现账目不平，说明成本系统仍是事后报表而不是运行时控制器。

隔离验收还应覆盖 side channel：不同租户的 cache 命中、错误文本长度、队列等待、artifact URL 和指标标签是否泄露存在性或内容；高负载租户是否能通过重试或长上下文把其他租户挤出 SLO；被删除的 memory、凭证与 artifact 是否仍出现在 replay 或备份索引。安全测试不应为了方便而使用同一租户下的不同项目替代真正的跨租户边界，因为两者的授权路径可能不同。

可观测、恢复和发布验收

使用一个完整 Run 验证 trace 从网关到模型、工具、审批、存储和计费；杀死 worker 后恢复；切换 workflow 和模型版本；回滚；执行影子和灰度；回放失败任务。报告包含成功、成本、延迟、重试、工具副作用、安全、SLO 和数据保留。只有这些证据齐全，Runtime 才可从实验池进入生产。

验收指标应有预先约定的门槛和重评估条件。核心集合可包括：任务成功率及其分层、已知副作用的重复率、未知 operation 的人工收敛时间、从 worker 故障到可恢复状态的时间、checkpoint 恢复正确率、补偿完成率、p95/p99 端到端时延、单位成功任务成本、预算超限率、跨租户隔离失败数、关键 trace 完整率，以及发布后回滚时间。阈值由任务风险和业务目标确定，不能把某个团队的历史数字写成通用标准；但每个阈值都要有数据来源、owner、观察窗口和超过时的处置。

可以把生产准入分为四个 gate：语义 gate 验证状态机、幂等与补偿；安全 gate 验证权限、隔离、秘密与人工边界；容量 gate 验证混合负载、预算、队列和故障余量；发布 gate 验证影子、灰度、可回放和回滚。一个 gate 未通过时，系统仍可在受限实验环境运行，但不得扩大可执行权限或影响范围。这样，团队能把“模型 demo 可以运行”和“具备生产行动资格”清楚地区分。

恢复演练应采用可复核的矩阵，而不是只展示一次 worker 重启成功。矩阵至少交叉故障位置、动作类别、状态证据和预期收敛方式：在调用前、请求已送达但未收到回执、下游已提交、checkpoint 写入中、回调迟到、租约失效和版本迁移中分别注入中断；对只读、可幂等写入、可查询但不可重试写入、可补偿写入和只能人工确认的动作分别执行；再断言系统得到完成、受控重试、补偿、暂停或人工接管这一唯一终态。每个格子都应保存输入摘要、operation id、事件顺序、manifest、故障注入时间、自动决策、下游查询结果和最终业务事实。缺少下游事实的“测试通过”只能说明进程恢复，不能证明动作恢复。

手工接管也需要像自动恢复一样验收。值班人员接到 needs_attention 后，应能在不读取超范围上下文的前提下看到风险分类、已确认与未知的事实、建议的查询或补偿、可执行权限、deadline 和升级路径；其批准、拒绝、修改和超时都写入同一事件链。演练要覆盖人员交接、审批人在 deadline 后返回、下游查询仍然未知、补偿也失败以及 owner 无法响应等情况，并验证系统不会因界面超时或重复点击再次提交副作用。人工决定不是绕过状态机的快捷入口，而是受角色、租约、双人复核和审计约束的一个状态转换。

恢复证据的抽样方式同样重要。发布前应从每类高风险工具随机挑选录制 Run 做离线回放，并从混沌演练中挑选失败样本核对外部系统的最终事实；发布后按 manifest、工具版本、租户风险和故障类型持续抽查。发现某一格没有可重放样本、operation id 无法关联、人工处理超过期限或补偿结果无法验证时，应把该能力从“可自动恢复”降级为“需要人工”，并停止扩大其权限。这样形成的测试矩阵既暴露未知边界，也给业务和治理 owner 提供接受、限制或重新设计风险的证据。

纯读取任务

读取知识库并生成答案的任务验证检索、上下文、引用、模型、输出和 trace。模拟知识库超时、空结果、权限拒绝、重复文档、过长上下文和模型超时，确认任务有明确状态和可解释降级。回放时不改变线上数据，反馈样本可以进入评估候选。

有副作用任务

发送消息、修改文件、创建工单或执行数据库写入的任务验证审批、schema、幂等、查询、补偿、部分成功和人工接管。网络在提交后断开时，重试首先查询 operation；工具返回未知状态时暂停而非再次执行。用户取消后已批准但未提交的动作失效，已提交动作进入补偿或人工。

长时 Agent

模拟运行数小时、等待 webhook、worker 重启、状态库切换、workflow 升级、工具版本退役和预算耗尽。确认 Run 可以从 durable state 恢复，旧版本继续执行兼容节点，事件不会重复副作用，最终成本和 trace 完整。归档后查询摘要，重新激活需要权限和新预算。

多租户压力

多个租户同时运行短任务、长任务、批任务和高风险工具，验证优先级、公平、配额、内存、连接、trace、记忆、artifact 和费用隔离。一个租户的工具爆发不能阻塞其他租户；一个模型故障不能让所有任务进入无限重试；预算和错误预算超限有明确降级。压测包含冷启动、节点故障、网络延迟和区域切换。

最小实现路径

一个团队不必第一天构建复杂多 Agent 平台。最小闭环可以是：不可变 Run spec、持久化 Step、统一 model/tool adapter、JSON Schema 校验、幂等 operation、基本 retry/deadline、trace、租户预算和人工暂停。先让一个有限 workflow 能在 worker 重启、工具超时和重复回调后恢复，再增加并行、记忆、MCP、复杂计划和多 Agent。

每次扩展保留简单路径作为基线。引入模型自主规划前，比较固定 workflow 的成功、成本和风险；引入记忆前，验证删除、冲突和权限；引入自动补偿前，验证不可逆动作和人工；引入多 Agent 前，验证共享状态和循环。复杂度只有在证据显示它改善任务结果时才值得引入。

与后续 Agent 章节的边界

从提交到最终结果的教学时序

Client -> API: submit(tenant, request_key, canonical_payload)
API -> State DB: TX create Task/Run/Step + Event + Outbox; COMMIT
API -> Client: accepted(task_id, run_id, query_url)
Relay/CDC -> MQ: publish(fixed_event_id) [may repeat]
Consumer -> State DB: TX inbox dedup + durable schedule; COMMIT; ACK MQ
Scheduler -> State DB: CAS claim Step, owner_epoch = e+1
Worker -> State DB: record intent(operation_id, business_key, payload_hash)
Worker -> Tool: authorized call(same business_key, epoch if supported)
Worker -> Tool: query original operation when receipt is unknown
Worker -> Artifact Store: persist and verify result payload
Worker -> State DB: TX Step result + checkpoint + Event + notification Outbox
Client -> API: query same Run / resume authorized event cursor
Notifier -> Client endpoint: deliver completion reference [may repeat]

该时序是设计要求，未交付实现或真实故障注入结果。状态库不可用时先停止新写动作，不让worker绕过意图记录；对象存储失败不提交指向半成品的进度；消费的ACK只确认可恢复接收，不代表整个业务已完成。每个跨系统箭头都可能丢回执，因此下表核查的是事实和恢复权，不是进程是否还活着。

故障窗口与人工修复矩阵

人工修复不是直接把status改ready。repair记录原Run、operation、已确认/未知事实、错误和版本、预算、建议恢复点、风险、owner及期限。操作者先经权限和CAS取得新恢复代次，使旧执行提交失效，再查询已发生副作用；按工具契约选择补记成功、恢复特定Step、授权补偿或保持待核验。重复点击沿同repair_id幂等，批量恢复限速并观察容量，结果附外部证据，由另一授权者按风险复核。MANUAL_REPAIR表示仍有待决事实，不是业务成功终态；到期未响应按第12章owner升级流程处理，不能悄悄丢进死信队列。

11.9 本章小结

可靠Runtime先保存事实，再安排执行；先取得有效owner，再恢复未完成步骤；结果未知先查询，不把超时当失败；有副作用的操作使用独立业务键，由最终资源明确去重边界。Outbox解决提交与发布的缺口，不能消灭重复；租约解决执行归属，不能自动停止旧远端请求；SSE解决增量观察，不能恢复业务事实。

第12章消费这里的unknown operation、dead letter与repair记录，定义责任、期限、升级、删除和运营验收。运行时提供有证据的入口，组织流程保证未自动收敛的问题有人处理。完整平台是否可靠，最终仍需真实实现和故障演练；本章不以教学矩阵冒充已完成测试。

11.10 参考资料

[1] Temporal. Temporal Workflow. 官方event-history/replay说明，核验2026-10-17. https://docs.temporal.io/workflows

[2] AWS. Choosing workflow type in Step Functions. 官方文档，核验2026-10-17. https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html

[3] Yao, S., et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR, 2023. https://arxiv.org/abs/2210.03629 访问日期：2026-10-17

[4] Schick, T., et al. Toolformer. NeurIPS, 2023. https://arxiv.org/abs/2302.04761 访问日期：2026-10-17

[5] Park, J. S., et al. Generative Agents. UIST, 2023. https://arxiv.org/abs/2304.03442 访问日期：2026-10-17

[6] 《动手学深度学习》作者. 4.4 模型选择、欠拟合和过拟合. 中文2.0.0. https://zh.d2l.ai/chapter_multilayer-perceptrons/underfit-overfit.html 核验2026-10-17

[7] Richardson, C. Pattern: Transactional Outbox. https://microservices.io/patterns/data/transactional-outbox.html 核验2026-10-17

[8] PostgreSQL. 3.4 Transactions. 18. https://www.postgresql.org/docs/18/tutorial-transactions.html 核验2026-10-17

[9] Debezium. Outbox Event Router. stable在线文档，核验2026-10-17. https://debezium.io/documentation/reference/stable/transformations/outbox-event-router.html

[10] PostgreSQL. SELECT: Locking Clause. 18. https://www.postgresql.org/docs/18/sql-select.html 核验2026-10-17

[11] Hohpe, G., & Woolf, B. Idempotent Receiver. Enterprise Integration Patterns. https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html 访问日期：2026-10-17

[12] Moritz, P., et al. Ray. OSDI, 2018. https://www.usenix.org/conference/osdi18/presentation/moritz 访问日期：2026-10-17

[13] Kleppmann, M. How to Do Distributed Locking. 2016-02-08. https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html 核验2026-10-17

[14] Karpas, E., et al. MRKL Systems. 2022. https://arxiv.org/abs/2205.00445 访问日期：2026-10-17

[15] Model Context Protocol. Tools. 2025-06-18规范. https://modelcontextprotocol.io/specification/2025-06-18/server/tools 核验2026-10-17

[16] JSON Schema. JSON Schema Validation: A Vocabulary for Structural Validation of JSON. Draft 2020-12. https://json-schema.org/draft/2020-12/json-schema-validation 核验2026-10-17

[17] Google. AIP-194: Automatic Retry Configuration. https://google.aip.dev/194 核验2026-10-17

[18] AWS Builders’ Library. Making Retries Safe with Idempotent APIs. https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/ 核验2026-10-17

[19] Garcia-Molina, H., & Salem, K. Sagas. ACM SIGMOD, 1987. https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf 访问日期：2026-10-17

[20] LangChain. LangGraph Persistence. 官方文档，核验2026-10-17. https://docs.langchain.com/oss/python/langgraph/persistence

[21] WHATWG. HTML Standard: Server-sent Events. Living Standard，核验2026-10-17. https://html.spec.whatwg.org/multipage/server-sent-events.html

[22] Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ 访问日期：2026-10-17

[23] Kubernetes. Multi-tenancy. 官方隔离说明，核验2026-10-17. https://kubernetes.io/docs/concepts/security/multi-tenancy/

[24] OWASP. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ 核验2026-10-17

[25] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[26] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[27] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

[28] Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. https://sre.google/workbook/implementing-slos/ 核验日期：2026-10-17

第12章 生产运营与治理控制

大模型系统的可靠性不只是接口可用。模型可能返回格式正确但事实错误的答案，工具可能重复执行副作用，推理服务可能在长上下文下耗尽 KV，训练任务可能在 checkpoint 损坏后无法恢复，数据和 prompt 可能泄露，模型升级可能让成本、偏差和安全风险同时变化。因此，大模型 Infra 的最后一层需要把系统可靠性、模型质量、数据治理、供应链安全、成本、发布和灾备放进同一套可审计的控制闭环。

SRE 的 SLO、错误预算和事故方法提供了服务可靠性基础 [1][2]；Dapper、OpenTelemetry 和 Prometheus 提供了跨服务追踪、指标和日志的观测基础 [3][4][5]；NIST AI RMF、ISO/IEC 42001、模型卡片、数据集说明书、SLSA 和 Sigstore 则把风险、责任和制品完整性扩展到 AI 生命周期 [6][7][8][9][10][11]。本章关注如何把这些原则具体化为 LLM 平台的指标、状态、策略、门禁和操作。

本章的组织方式是“风险—控制—证据—责任人”。可靠性、发布、安全、成本、灾备和审计不应散落在不同文档里，而应能映射到同一张治理矩阵。

12.1 可靠性目标：从服务可用到任务成功

多层 SLO

大模型平台至少有平台层、模型层、任务层和治理层四类目标。平台层关注网关可用、调度成功、实例健康、TTFT、TPOT、队列和恢复；模型层关注格式、引用、拒答、工具参数和能力回归；任务层关注用户目标成功、人工接管、重试和外部状态；治理层关注数据权限、审计、供应链和安全事件。

只看 HTTP 200 会把流式中断、JSON 非法、工具失败和部分输出当作成功。每个请求和 Run 定义 outcome，响应状态与业务状态分离。任务成功率按 workflow、模型、版本、租户和风险分层，不能用所有请求的平均覆盖重要少数场景。

SLI 设计

SLI 是可测量的服务行为，例如成功完成的请求/有效请求、满足 TTFT SLO 的请求/请求、工具状态正确的操作/操作、有效 checkpoint/保存尝试、恢复成功的故障/故障。分母定义尤其重要：客户端取消、模型拒答、策略阻断、上游错误和平台错误是否进入分母，按场景明确。

指标包含时间窗口、版本、region、tenant、model、workflow、length bucket 和 outcome。高维字段不一定全部放 Prometheus label，可在 trace 和离线仓库聚合。SLI 定义版本化，指标语义改变时创建新版本，避免趋势图跨定义比较。

错误预算

错误预算把可靠性要求转换为变化速度。预算消耗包括平台错误、任务失败、工具副作用、质量回退、安全事件、数据泄露和恢复超时。预算耗尽可以暂停灰度、冻结非必要变更、降低实验并发、增加人工或切换稳定版本。SRE Workbook 的错误预算方法适合连接发布与可靠性 [1]。

模型质量回退不能被平台 99.99% 可用性掩盖；一次数据泄露也不应被平均成功率稀释。治理事件使用独立的硬门禁，服务错误预算用于自动化决策，业务质量预算由 owner 审批。每类预算有发现、确认、修复和关闭流程。

可靠性不是单一百分比

“服务可用率 99.9%”无法回答模型是否正确、工具是否安全、任务是否完成。大模型平台把可用性拆成控制面可用、执行面可用、模型可加载、请求可接受、输出可消费、任务可完成和数据可审计。每一层有不同分母和响应，平台报告同时展示，避免高层成功掩盖下层失败。

例如网关返回成功但流式只发送了首 token，执行面可用但任务未完成；工具返回 200 但业务状态没有变化，调用可用但副作用失败；评估 job 结束但 coverage 只有一半，任务完成但证据不可信。SLO 定义必须绑定 outcome，而不是只绑定 HTTP 状态。The Twelve-Factor App 关于配置、日志和进程隔离的原则可作为服务边界基础，但 LLM 平台还需增加 token、质量和数据责任 [12]。

错误预算的分配

全局错误预算按产品、模型、租户、区域和 workflow 分配。核心交易、告警处理和高风险自动化拥有更严格预算；实验和低风险摘要可以使用较宽预算。子系统预算不能简单相加，因为一次模型错误可能同时造成任务失败、工具重试和成本上涨。平台以 parent task 归因并定义最大总消耗。

预算消耗有严重级别和恢复动作。质量轻微下降触发加大评估，延迟增长触发容量或降级，重复副作用触发立即停止，数据泄露触发隔离、撤回凭证和合规响应。预算恢复需要新的证据或时间窗口，不能人工把数字重置成零而不保留原因。

SLO 的统计陷阱

平均延迟、平均成功率和总错误数量会掩盖长尾与少数租户。平台使用分位数、窗口、分层和最小样本；对于流式和 Agent，定义部分完成、取消、用户中断和人工接管的计量。指标改变定义时保留版本，图表显示数据质量和覆盖率。SRE 方法要求 SLO 可测量、可行动，而不是漂亮的目标 [1][2]。

任务成功也有观察滞后：用户可能数小时后才确认，工具外部状态可能最终一致，投诉可能几天后出现。短窗口服务指标与长窗口业务质量并列，长期问题通过反馈和评估闭环处理。不能因为当前窗口没有投诉就宣布高风险模型可靠。

可靠性与质量的联合门禁

发布门禁不是两个独立的清单。质量退化可能导致更多重试、人工和 token；延迟变差可能让用户重复提交；安全拦截升高可能表示攻击增加，也可能表示模型过度拒答。报告把质量、SLO、成本、安全和人工放在同一版本和时间窗口，解释相互影响。

门禁采用硬约束加软分析。数据泄露、越权、重复副作用、关键任务失败和 artifact 未签名直接阻断；普通任务小幅变化进入人工判断；性能和成本变化结合业务价值审批。门禁规则版本化，旧报告不因规则改变而被重写，新规则可以对历史 evidence 做离线重算。

12.2 可观测性：信号、质量与告警

三类信号

Metrics 适合时间序列和聚合，logs 记录具体错误与上下文，traces 连接一次请求或任务的因果链。OpenTelemetry 提供跨组件的语义与传播，Prometheus 提供指标采集、查询和告警，Dapper 展示大规模分布式追踪的价值 [3][4][5]。LLM 平台还要增加 token、模型、模板、cache、工具、质量和成本字段。

Trace root 可以是 request、task 或 training run；span 包含 gateway、queue、tokenizer、prefill、decode、retrieval、model、tool、approval、database、cost 和 evaluator。字段包含 hash、version、input/output token、TTFT、TPOT、error、retry、tenant、budget、deadline、quality result 和 policy。默认不记录完整敏感内容，使用摘要、hash、脱敏和受控采样。

质量观测

线上质量信号包括任务成功、重试、编辑、用户评分、转人工、引用点击、工具成功、结构化合法、拒答、安全拦截和投诉。质量与延迟、成本、上下文长度、路由、模型版本和数据 snapshot 联合分析。单独看点赞率或 token 长度会受到反馈选择偏差和策略改变影响。

质量监控按场景分层，设置最小样本与置信区间。高风险任务全量或高比例采样，普通任务分层抽样；失败与不确定结果优先保留。反馈样本脱敏后进入评估平台，生产观测和离线回归通过 request id、model hash 和 dataset id 关联。

告警与诊断

告警分为症状和原因：症状包括成功率下降、p99 上升、任务失败、成本突增；原因包括 KV 水位、队列、模型加载、对象存储、网络、工具、数据 drift、policy 和供应链。告警必须有 owner、runbook、严重级别、抑制与恢复条件，避免只把所有错误发给值班人员。

诊断页面按一个请求或 Run 显示状态时间线、资源、版本、路由、错误、重试、工具和质量。事故中先冻结相关发布和保留 trace，再做降级、隔离和回滚。观测数据本身要有留存、权限、脱敏和成本控制，不能为了排查故障无限保存 prompt。

观测数据的生命周期

metrics 可以长期保留聚合，logs 按错误和审计保留，trace 高价值失败与抽样成功保留，prompt/output 按数据等级短期保留，audit 事件按合规保留。不同数据拥有不同访问角色、加密、区域和删除流程。观测系统的成本和隐私必须进入平台预算，不能默认全量记录。

改变采样比例或字段会影响趋势。每个 dashboard 标记观测版本、采样率、覆盖率和缺失字段；事故发生后临时提升采样有开始与结束时间。OpenTelemetry 的统一字段有利于关联，但不能让所有业务把任意高基数内容塞进 trace [4]。Prometheus label 设计尤其避免 token、prompt、用户自由字符串和完整 URL [5]。

告警疲劳

告警按用户影响和行动区分：page 需要立即处理，ticket 可以工作时间处理，dashboard 只用于趋势。一个告警必须有 runbook、owner、抑制、恢复和升级；重复告警合并到 incident。质量漂移和成本异常可以由每日评估或预算系统处理，不应把所有分布变化变成夜间 page。

告警内容不包含敏感 prompt 和秘密。它包含模型、版本、区域、tenant group、错误类别、影响比例、SLO 和 trace link。告警确认、转交和关闭都是审计事件，事故复盘检查告警是否及时、准确、可行动。

观测与评估的回路

线上 trace 抽样到数据与评估平台，评估结果回写模型、workflow、tool 和 release evidence；发布门禁读取质量与安全趋势，运行时根据 policy 选择模型、工具和人工。回路中的每个转换都保存 sample hash、版本、权限和采样策略。没有这个回路，平台只能看到服务可用，却无法发现输出质量逐渐变差。

反馈有偏、缺失和延迟，平台报告 coverage、标签来源和不确定性。人工确认的安全事件进入高优先级回归，普通低评分按分层进入候选。线上与离线版本不一致时，先冻结比较再定位数据、模板、路由或 evaluator 变化。

质量异常检测

质量异常包括输出长度、格式合法、拒答、引用、工具计划、事实性、用户反馈、人工接管和任务 outcome 的分布改变。没有标签时使用代理信号并标记不确定；高风险类别保留人工抽样。检测基线按版本、任务、语言、长度和用户层级建立，避免全局平均稀释异常。

异常确认后，冻结受影响版本、扩大回归、回放失败、比较 baseline、检查数据和路由，决定修复、回滚或接受。接受变化需要 owner、理由、有效期和新基线。模型卡、评估报告和风险登记同步更新，不能只关闭一个告警。

可靠性指标的长期趋势

季度趋势不只看可用率，还看事故数量与严重度、MTTD、MTTR、恢复丢失、回滚时间、质量回退、人工接管、成本/成功任务、安全事件、评估覆盖、供应链风险和灾备演练通过率。指标按组织、模型、workflow 和故障域观察，识别结构性问题。一次短期低错误不能掩盖恢复能力下降。

趋势报告列出目标、当前、变化、解释、行动和 owner。若改善来自减少观测或缩小分母，报告标记 measurement change；若质量提升来自更多人工，计入人工成本；若成本下降来自关闭备份，计入 RPO 风险。长期治理要求诚实解释，而不是指标漂亮。

12.3 发布、变更与供应链治理

Artifact 与供应链

模型、tokenizer、template、engine、adapter、工具、workflow、policy、数据 snapshot 和评估报告都是制品。每个制品记录来源、构建、依赖、hash、签名、许可证、owner、数据等级和兼容矩阵。本章采用SLSA v1.0的来源与构建完整性框架，不声称它是当前最新版本；它提供供应链参考，Sigstore 通过签名和透明日志帮助验证制品 [10][11]；OpenSSF Scorecard 可用于检查开源依赖风险 [13]。

构建在隔离环境执行，依赖锁定并生成 SBOM；运行时只拉取允许的 hash；部署前校验签名、漏洞、模型评估和权限。第三方模型或 MCP server 不能因为公开可下载就自动进入生产。升级依赖、CUDA、driver、kernel 或工具都触发兼容、性能、安全和回滚测试。

变更分类

变更按风险分为配置、prompt/template、模型、推理 engine、数据、workflow、工具、policy、基础设施和安全。配置变更可能影响容量，prompt 变更可能影响工具和隐私，数据变更可能影响质量与授权，工具变更可能产生副作用。变更单说明背景、获得、牺牲、风险、指标、门禁、灰度和回滚。

灰度与回滚

灰度按租户、区域、任务、流量、模型版本或 workflow 分组。影子不执行副作用，canary 受限执行，正式流量满足 SLO、质量、成本和安全。回滚恢复模型、tokenizer、template、engine、adapter、workflow、policy、route 和 cache 兼容版本；新状态无法被旧版本理解时，先 drain 或迁移。

回滚演练验证正在执行的请求、长 Run、审批、工具 operation、计费、memory 和 trace。发布控制器保存 baseline、candidate、evidence、审批和操作人。自动暂停条件明确，人工 override 需要理由与期限。没有可执行回滚的变更不能进入生产。

供应链的信任链

从源代码到模型服务建立 provenance：源代码 commit、依赖、构建器、基础镜像、模型来源、数据 snapshot、转换器、engine、签名和部署。SLSA 定义构建来源和保证等级，Sigstore 提供签名与验证，Scorecard 检查公开依赖的维护和安全信号 [10][11][13]。平台按已批准的信任根与身份约束验证签名，拒绝无来源、hash不匹配或签名无效的artifact。签名证明来源与完整性，不证明模型质量、授权数据或无后门；Scorecard分数也是风险信号，不能当安全背书。

模型供应链还包括数据和 prompt，不只是软件。训练数据下载、清洗脚本、量化校准、评估器、MCP server 和工具 schema 都可能改变行为。平台可按制品类型生成SBOM、数据表和模型卡，发布报告引用它们。发现漏洞时按依赖图找到运行中的模型、engine、workflow 和租户，快速隔离与替换。

版本与配置治理

配置分为代码、静态 manifest、动态策略和运行时临时状态。代码通过构建发布，manifest 不可变，动态策略有版本与审批，临时状态通过事件与 TTL。关键配置要有可追溯的版本和生效记录；受控环境变量可以承载部署配置，但不应成为未登记、不可重现的隐式开关。The Twelve-Factor App提倡配置与代码分离、日志作为事件流 [12]。

配置变更触发 diff、兼容、容量、质量和安全检查。灰度先使用少量租户或影子，失败自动暂停；回滚恢复完整配置集合而非单个值。配置读取写入 trace 的有效版本，事故复盘可以重建真正生效的行为。

供应链应急

发现依赖漏洞、恶意镜像、模型后门、泄露 token 或签名问题时，平台执行供应链 incident：定位受影响 artifact 与运行实例，停止下载和发布，隔离实例，轮换凭证，保存证据，生成可信替代品并灰度。SBOM 与 provenance 让影响范围可计算；没有来源的旧制品可能需要完全下线。

模型供应链风险还包括训练数据投毒、评估器偏置、恶意 tool description 和被篡改的 prompt template。数据 manifest、模型卡、工具注册和评估报告互相引用，发现一个来源问题可以查找所有消费者。供应链响应完成后运行安全、质量、性能和回滚门禁，不因紧急修复跳过验证。

事故中的发布冻结

当发生高等级事故时，发布系统进入 freeze 状态：禁止新的模型、工具、workflow、数据和基础设施变更，保留必要的安全修复和容量扩容，但每项例外都有审批。冻结范围按 blast radius 定义，可以是单模型、单租户、单区域或全局。发布冻结与流量降级、凭证轮换、回滚和数据保全共同执行。

冻结期间仍然需要处理正常的配置过期、证书轮换和节点维护。运行手册列出允许动作、风险和兼容验证，避免把安全运维完全停死。事故结束后先恢复观测与回归，再小比例解除冻结；错误预算恢复与根因修复是不同条件，不能只等流量下降。

变更影响分析

变更影响分析沿 artifact graph 和 runtime graph 做。模型 hash 变化影响 tokenizer、engine、cache、路由、评估、成本和工具；数据 snapshot 变化影响训练、评估、模型卡和发布；工具 schema 变化影响 workflow、prompt、权限、补偿和回放；policy 变化影响所有调用与审计。平台生成受影响消费者和需要重跑的门禁列表。

影响分析有静态与动态两层。静态层读取 manifest、依赖和血缘，动态层用 shadow/replay、固定回归和容量测试验证。若无法解析依赖，默认按高风险处理而不是假设没有影响。图中节点与边有 owner，边记录兼容版本和失效条件，变更完成后更新。

发布前检查

发布前自动生成检查表：artifact hash 和签名、SBOM、模型卡、数据说明、兼容矩阵、质量门禁、SLO 基线、容量、故障演练、权限、审计、trace、成本、回滚、灾备和 owner。缺失项阻断或需要显式风险接受。发布后检查灰度窗口、错误预算、质量、成本和用户反馈。

发布控制器把检查结果写到 release evidence，不依赖聊天或邮件。审批人看到的是差异与风险，不是一个模糊的“测试通过”。回滚路径在发布前使用相同版本和权限演练，防止事故中发现旧制品已删除或不兼容。

执行状态与运营状态的接口

Kubernetes的Pod生命周期提供执行层状态，不能代表业务任务成功 [14]。Run、Step、Operation的迁移、UNKNOWN核验、fencing和恢复算法统一引用第11章；本章治理记录只关联权威状态版本、owner、处置期限与证据，不再另定义一套Runtime状态机。发布可暂停、修复可认领、灾备需验证，均应通过受控接口并留下审计，不能因operator页面显示绿色就覆盖业务事实。

12.4 事故响应、人工修复与责任升级

事故分级

事故按用户影响、数据风险、业务副作用、区域范围、持续时间和恢复难度分级。数据泄露、重复副作用和模型大面积错误通常高于单区域 p99 回退。事故 commander 负责决策与沟通，technical lead 处理隔离和恢复，scribe 保留时间线，业务与安全 owner 负责影响判断。

第一步是止损：冻结高风险发布、限流、摘除故障副本、停止工具、关闭跨租户 cache 或切换安全 fallback；第二步保留证据；第三步恢复有限服务；第四步核对数据和业务状态；第五步复盘与修复。不要在事故中随意删除日志、重试未知副作用或修改历史状态。

Runbook 与演练

Runbook 包含症状、查询、指标、权限、判断、动作、风险和回滚。训练故障查 checkpoint 与数据游标，推理故障查 KV 与队列，Agent 故障查 operation 与状态，数据事故查血缘与 snapshot，安全事故查凭证与审计。每条 runbook 由演练验证，不可执行步骤进入 backlog。

复盘与学习

无责复盘描述时间线、触发、检测、决策、影响、恢复、哪些信号缺失、哪些自动化失败和修复 owner。行动项分为代码、数据、配置、观测、容量、文档、流程和培训，带期限与验证。事故样本进入回归集，故障演练加入发布门禁，重复事件触发架构评审。

组织与职责

模型 owner 对能力、限制和评估负责，数据 owner 对来源、授权和质量负责，平台 owner 对资源、可用性和恢复负责，安全 owner 对威胁、策略和响应负责，业务 owner 对任务成功与残余风险负责，发布 approver 对变更承担审批。RACI 记录在系统和文档中，避免事故时无人决定。

职责不是把风险切开。模型变更同时影响容量、质量、安全和成本，发布评审需要多方 evidence；事故 commander 可以停止系统但不替代业务判断；人工接管结果反馈给模型和流程 owner。季度治理评审检查风险登记、指标、事故、成本、数据和供应链。

事故中的状态保护

事故处理第一原则是保留事实。冻结相关 Run、snapshot、artifact、trace、配置、状态、凭证和事件；禁止未经受控修复流程直接改业务状态、覆盖制品或清理会丢失必要证据的现场。对未知外部副作用查询 operation；对可能泄露的数据隔离访问并轮换凭证；对错误模型停止新流量但保留回滚所需的制品。

状态保护需要只读快照、fencing token 和操作审计。一个旧 worker 恢复后不能覆盖新状态；一个过期 operator command 不能执行；一个故障区域不能与恢复区域同时写同一业务状态。控制面在每个危险动作前检查 generation、lease、policy 和 approval。

事故沟通

内部沟通说明影响范围、开始时间、当前状态、临时措施、下一次更新、数据风险和用户动作；对外沟通只披露确认事实和可执行建议，不泄露敏感样本与内部策略。事件时间线统一使用 UTC 或明确时区，所有操作带 operator、trace 和版本。事故 commander 避免多个团队同时执行互相冲突的回滚。

复盘中区分触发条件与根本原因，记录检测为什么晚、告警为什么无动作、runbook 为什么不可执行、自动恢复为什么失败以及哪些假设不成立。行动项有 owner、期限、验证命令和优先级。重复事故说明修复停留在文档而未进入系统门禁。

可操作性评审

每个新组件上线前做 operability review：健康检查是否能区分依赖与自身，指标是否能定位，日志是否脱敏，trace 是否关联，配置是否可动态或版本化，备份与恢复是否验证，限流与熔断是否存在，runbook 是否可执行，回滚是否完成演练，成本是否归因。不能回答的问题进入上线阻断清单。

可操作性不是运维后补。模型仓库、评估器、MCP server、数据 job 和安全策略一开始就纳入平台标准。组件拥有明确 owner、SLO、依赖、升级、退役和事故联系人。这样平台不会因为增加一个看似小的模型能力而增加不可见的运维负担。

运维人员的最小权限

值班人员需要查看健康、指标、trace 摘要、执行限流、摘除实例和切换安全 fallback，但不应默认读取敏感 prompt、下载模型或执行业务工具。高风险操作双人审批或 break-glass，break-glass 记录原因、时间、范围、自动过期和复盘。平台 API 对 operator 与 tenant 使用不同 audience 和 policy。

权限轮换和离职回收自动化，服务账户短期化，密钥不进入日志和 artifact。审计系统定期检查异常访问、批量导出、跨区域、非工作时间和失败授权。发现异常时冻结账户、保留证据并走安全 incident。

部分失败与用户体验

AI 任务经常出现部分完成：检索成功但生成失败，三项工具完成两项，答案生成但引用缺失，流式输出完成一半，评估覆盖不足。API 返回 partial、failed、needs_attention 或 completed_with_warnings，附带已完成、未完成、可重试和人工动作。隐藏部分失败会让用户重复提交和增加副作用。

部分结果是否可用由 workflow 定义，不能让模型自行宣布成功。业务系统提供 postcondition 和确认接口；Runtime 记录用户是否接受 partial。成本与资源按已执行部分结算，重试只补未完成或明确重算。事故和评估样本保留部分路径，帮助定位是哪个阶段导致失败。

模型与系统的责任分界

模型 owner 不能保证所有业务正确，平台 owner 不能通过平台隐藏模型限制，业务 owner 不能把安全交给 prompt，安全 owner 不能只提供禁止清单。责任边界用接口和证据表达：模型提供能力、限制和质量；平台提供资源、状态、版本、观测与恢复；业务提供 outcome、风险承受和人工；安全提供策略、威胁和响应。

接口契约定义哪些错误由哪一层处理。模型返回格式错误由 Runtime 重试或失败，工具权限由策略拒绝，业务状态冲突由业务查询，平台节点故障由调度恢复，数据授权由数据 owner。责任不清会导致无限重试和事故互相推诿。

从死信到关闭：operator修复流程

第11章定义Operation、UNKNOWN、lease/epoch和repair接口，本章只规定谁在何时凭什么证据操作。一个心跳正常但无进展的Run，或反复失败的毒消息，不应仅靠重启或全量重放处理。修复工单引用原task/run/step/operation、manifest、最后进展、错误类型、已确认与未知业务事实、待处理风险和受控证据链接；页面默认不复制prompt、客户载荷或凭据。

例如退款已提交而响应丢失，先按原操作ID核对；查到退款成功则补记Step，不能新建退款键重发；查不到但下游仍可能在执行时保持NEEDS_RECONCILIATION。手工在数据库把status改ready会绕开原操作及owner检查，因此修复入口必须调用第11章同一状态转换接口。补偿也失败时保留主事实与补偿attempt，用户看到待处理事项，不能把“工单已创建”算业务风险关闭。

每种修复等级预先指定认领时限、核验期限与升级对象，均为组织配置而非本章通用分钟数。无人认领先转值班备份，超过核验期限转工具/业务owner，再按影响升级incident commander与治理负责人；交接须明确接收人确认，原owner不能仅因发送通知就消失。SRE事故管理强调清晰角色和交接 [2]，这里将其落实为repair的owner、next_action_at、deadline、escalation_level与handoff_ack字段。期限到达只触发升级或限制新增动作，不把UNKNOWN自动改失败。

修复结束保存外部查询时间、返回版本、已确认事实、执行代次、批准与动作事件、剩余风险及复审时间。独立检查任务终态、操作事实、通知交付和用户确认四件事；若只有技术队列清空而退款仍未知，工单不得以“平台恢复”关闭。演练覆盖操作者交班、审批过期、重复点击、自动接管竞争和批量恢复冲击，实际验收结果另存证据包，本章表格不代表已运行演练。

12.5 安全、数据最小化与AI风险治理

风险登记

AI 风险登记表包含系统用途、用户、模型、数据、工具、威胁、失败影响、控制、残余风险、owner 和复审时间。NIST AI RMF 的 govern、map、measure、manage 结构可作为生命周期框架 [6]；生成式 AI profile 进一步关注幻觉、数据、滥用、供应链和内容风险 [15]；ISO/IEC 42001:2023的公开摘要界定AI管理体系，ISO/IEC 23894:2023摘要界定AI风险管理指导 [7][16]。这里未逐条解读付费标准，也不声称完成合规审计或认证。NIST材料在此按已发布的1.0与2024 Profile使用，其概览说明框架为自愿采用并处于修订进程，不将未发布版本写成既成规范。

风险不能只写“模型可能出错”。明确危害场景、触发条件、暴露范围、检测信号、阻断与补偿。例如模型生成错误退款动作、工具越权读取、训练数据泄露、提示注入、输出偏见、服务成本失控和区域合规违规。每个高风险场景至少有预防、检测、响应和复盘。

权限与审计

权限分为调用模型、读取数据、执行工具、写外部状态、查看 trace、下载 artifact、审批发布和修改 policy。采用最小权限、短期凭证、租户和区域限制、目标 allowlist。审计记录主体、资源、动作、理由、策略版本、结果、trace、时间和来源；不能由应用日志临时拼接。

审计本身不可被普通租户修改，保留期、访问者和导出要有策略。数据删除与合规请求沿数据血缘、缓存、trace、评估和 artifact 处理；历史指标保留摘要并标记内容已撤回。中文《生成式人工智能服务管理暂行办法》第十一条规定输入与使用记录保护、非必要个人信息收集限制及个人信息请求处理 [17]；适用范围按第二条和实际服务场景核对，不以本章清单代替适用性判断。

LLM 应用安全

提示注入、敏感信息泄露、不安全工具、供应链、过度代理、输出处理、拒绝服务和模型窃取等风险需要进入测试。OWASP LLM Top 10 和 MITRE ATLAS 提供威胁分类与攻击知识库 [18][19]。防御不是只加系统 prompt，而是权限、沙箱、schema、输出过滤、网络、速率、审计、人工和回滚的组合。

安全策略不能被模型修改。工具结果、检索文档和用户文件标记为不可信；模型输出先做 schema 和 policy，再执行副作用；安全服务不可用时 fail closed 或进入人工。红队样本、失败 trace 和安全回归集受控保存，修复后验证正常任务没有被过度拒答。

模型卡与数据集说明

Model Cards 记录模型用途、限制、评估、数据、风险和适用场景 [8]；Datasheets for Datasets 强调数据来源、组成、收集、推荐用途和限制 [9]。平台将这些文档与 model artifact、dataset snapshot 和 release evidence 关联，变更时重新生成或复审。文档不是营销材料，而是让调用方知道不能做什么。

模型风险的持续监控

模型卡中的限制不是上线时检查一次。生产监控关注输入分布、输出事实性、拒答、偏差、敏感内容、工具错误、人工投诉和新攻击。新场景、语言、地区和用户群进入风险评估；模型或数据变化触发重新测量。Model Cards 和 Datasheets 将模型与数据的限制、来源、用途和责任显式化 [8][9]。

风险监控需要定义红线和响应：达到红线自动停止流量、隔离模型、关闭工具或转人工；接近阈值扩大采样和人工；正常波动只记录。风险指标分层避免平均数掩盖少数群体。中文政策原文可用于核对服务输入保护与请求处理职责，具体控制仍需落在权限、留存、删除和审计流程 [17]。

数据治理的责任矩阵

数据 owner 负责来源和用途，steward 负责 schema 与质量，security 负责敏感等级与访问，legal/compliance 负责授权和保留，model owner 负责使用影响，platform 负责执行控制。责任矩阵写入数据 catalog 和 snapshot manifest；没有 owner 的数据不能进入生产训练或评估。

数据说明书记录收集方式、代表性、缺失、偏差、推荐用途、不适用用途和已知问题。模型卡记录能力、限制、评估和风险。文档变化触发使用者通知和重新门禁，不能把旧卡片继续附在新模型上。本章中文来源是政策原文，不再用机构主页代替未核验白皮书；本地职责与适用范围按实际场景落实 [17]。

安全策略的失败模式

安全系统可能误拦截、漏拦截、超时、版本不一致或返回不确定。策略引擎不可用时，对高风险动作 fail closed；对低风险只读动作可以有限降级，但事件标记为 policy_unavailable。输入安全、输出安全、工具权限和数据访问使用一致的 policy version，避免各层使用不同答案。

策略误拦截需要人工复核和样本回流，漏拦截需要立即隔离、查找影响、撤销凭证和扩大红队。安全指标按语言、任务、租户和模型分层，避免平均数掩盖少数场景。OWASP 与 MITRE 提供风险分类，但组织需要把具体资产、攻击面和响应动作写进 runbook [18][19]。

安全事件的证据保全

安全事件发生时，保留请求 hash、模型、policy、工具、凭证标识、权限决定、网络、artifact、trace、时间线和影响范围；对敏感正文采取受控快照和加密。隔离受影响租户、撤销 token、停止工具和切断 egress，防止继续扩散。证据访问最小化并记录，避免调查过程二次泄露。

事件分类包括 prompt injection、敏感数据输出、越权工具、供应链、模型窃取、拒绝服务和数据投毒。每类有检测、遏制、清除、恢复、通知和复盘。攻击样本经过脱敏和审批后进入红队与回归；修复后检查攻击路径、正常任务和跨模型迁移。

治理控制的自动化

自动化控制包括制品签名校验、数据授权检查、schema、兼容矩阵、漏洞、质量门禁、权限、限流、成本、备份、漂移、删除和回滚。控制结果是机器可读的 pass、fail、waived 或 unknown；waiver 有 owner、理由、期限和补偿；unknown 默认按风险等级处理。手工审批只处理不可自动判断部分。

控制器自身也要有版本、权限、观测和回滚。错误的 policy 可能阻断所有服务或放行危险动作，更新前用历史回放和 sandbox 验证。策略发布按区域、租户和风险灰度，紧急禁用高风险工具的路径独立于普通发布。

第三方审查与内部复核

高风险系统可由安全、隐私、业务和平台联合复核，必要时引入外部审查。审查输入为机器可读 evidence bundle，输出为发现、风险等级、修复、接受或期限。内部复核检查控制是否真的执行，而不只是文档存在；通过抽样生产事件、权限和发布记录验证。

审查发现应进入 issue 与发布门禁，修复后重新生成证据。审查文件包含版本与范围，不能用上一版本结果覆盖当前系统。重大模型、工具、数据或地区变化重新触发审查，而不是等年度周期。

数据最小化沿整条链路实施

先枚举任务必需字段，再决定模型输入；业务密钥、完整账户资料和无需公开的核心脚本留在受控服务，模型只接收必要结果。假名化映射与原文分开授权，电话号码遮盖但姓名地址完整仍可能识别主体；hash也可能被关联或枚举，不能自动视为匿名信息。资源读取、模型上下文、工具返回、日志、记忆、评估和网络出口分别设策略，不用“已脱敏”一个标签覆盖全链路。

Skill/工具声明只描述获准能力，不能存业务凭据；模型执行进程也不应获得不必要密钥。若任务确需代码或脚本内容，按已授权范围提供，而不是把隐藏prompt当唯一保护。供应商的训练使用、驻留、保留与删除能力逐项核对实际配置及约定，不因产品叫企业版就假定不训练或零留存。

12.6 成本、容量与资源治理

成本账本

成本包括 GPU、CPU、内存、网络、存储、模型下载、token、KV、cache、工具、评估、人工和失败重试。训练按有效 token、GPU 小时和重算归因；推理按输入输出 token、GPU 毫秒、成功任务和 cache；Agent 按 Run、Step、Tool、人工和副作用。每条费用事件带 tenant、project、model、version、task 和 idempotency。

成本报告区分预约、实际、等待、通信、空闲、失败、重试和有效工作。GPU 利用率高但有效任务少，仍可能成本高；便宜模型输出更长或失败更多，单位成功成本不一定低。成本预算与错误预算、质量门禁并列，超限触发暂停、限流、降级或审批。

容量计划

容量模型按 workload、长度、并发、模型、GPU、区域、故障余量、发布余量和长尾建立。训练关心有效 token/s 和扩展效率，推理关心 goodput、TTFT、TPOT、KV，Agent 关心 active Run、tool QPS、状态、人工与模型调用。容量 dashboard 显示 planned、reserved、active、pending、failed、draining 和 spare。

容量计划每次模型、模板、数据、流量、硬件或工具改变都重算。SRE 错误预算与容量余量一起保护发布和故障；Borg 的优先级、配额和隔离为多租户资源治理提供经验 [20]。不能把正常峰值填满后再假设可以完成滚动发布和节点故障转移。

成本优化的取舍

量化、batch、cache、低优先级资源、模型路由、上下文压缩、预计算和异步化都可能降本，但改变质量、延迟、内存或数据风险。每个优化有基线、假设、获得、牺牲、指标、回滚和重新评估条件。一次只改变少数变量，用固定 workload 比较质量、SLO、成本和错误预算。

可靠性预算与容量预算

错误预算耗尽时暂停高风险变更，容量预算不足时限制流量和长任务，安全预算被突破时关闭相关工具或区域，质量预算退化时回滚模型。不同预算可能互相冲突，平台指定优先级：安全和数据责任高于成本，关键业务质量高于平均吞吐，可靠性保护优先于实验速度。

容量预算包括正常峰值、节点故障、发布双份、灾备切换、评估和突发；不可把全部 GPU、状态库连接、对象存储 QPS 和人工容量都分配给常态业务。Borg 的资源配额、优先级和故障域经验说明，预留和抢占需要控制面统一治理 [20]。

成本透明与治理

治理控制也有成本：全量 trace、judge、人工审核、备份、红队和灾备会消耗资源。平台把控制成本显式归因，不以取消安全和可靠性换取表面低价。低风险任务可以使用较低采样和自动化，高风险任务使用更强证据、人工和保留；分层策略比所有任务一刀切更可持续。

成本透明让业务能做知情取舍。若减少评估样本可省钱但扩大未检测风险，决策由 owner 接受并设置有效期；若增加 cache 降低 GPU 却延长敏感数据保留，需安全审核；若跨区域备份缩短RTO却不被驻留策略允许，应改用许可范围内的冷备或重算。每项牺牲写在 ADR 与治理报告中。

成本治理与组织行为

成本面板公开模型、租户、项目、workflow、数据处理、评估和人工成本，提供预算、趋势、异常和单位成功任务成本。公开透明不等于惩罚排名，研究实验和生产任务使用不同解释。平台允许团队设置预算、预警和自动暂停，避免月底才发现资源耗尽。

成本优化有潜在反模式：为了省 token 让模型少验证，为了提高 GPU 利用率混入长任务，为了省日志关闭 trace，为了省备份降低 RPO。治理评审把这些牺牲写明，业务 owner 接受风险并设重新评估日期。好的成本管理提高单位价值，而不是简单砍掉控制。

成本异常检测

成本监控检测模型 token 突增、输出长度变化、重试风暴、cache 命中下降、judge 队列、工具调用爆发、GPU 空闲、对象存储请求和跨区域流量。异常按 tenant、model、workflow、版本和 region 分层。自动动作包括限流、降低优先级、暂停实验、切换模型、关闭可选分支和通知 owner；高风险动作需要人工。

成本异常可能是攻击、业务流量、模型行为、模板循环或计量 bug。排查使用 trace、事件、配置 diff、数据分布和发布记录，不要立即把配额调高。费用事件与供应商账单定期对账，发现计量重复或漏记时生成修订事件，不覆盖原始记录。

12.7 故障演练、业务连续性与灾备

故障域

故障域包括请求、实例、GPU、节点、网络、区域、存储、调度器、模型仓库、数据仓库、工具和人工队列。每个故障定义检测、隔离、重试、降级、回滚、补偿、恢复时间和数据损失。单节点故障不应让所有副本同时失效；单租户的工具风暴不应拖垮全局。

故障分类区分瞬时、确定性、未知状态和不可逆。只读或契约允许的瞬时网络错误可有界退避，写操作超时先核验，schema 错误需要修复输入，工具提交后连接断开需要查询，支付或删除等动作需要人工。AIP-194的自动重试适用条件与错误分类可作为接口参考 [21]。

混沌演练

混沌实验覆盖杀死 worker、GPU reset、节点断电、网络延迟、丢包、DNS 失败、对象存储不可用、模型下载损坏、KV OOM、事件重复、状态库只读、工具超时和区域切换。Chaos Mesh的NetworkChaos官方文档给出网络延迟等注入机制 [22]，其余场景是本书待实施的实验设计；Jepsen的资料区分一致性模型 [23]；本书据此要求明确历史检查所用模型，再为分区与时序设计实验。

每次实验有假设、范围、注入、预期、停止条件、指标、影响、恢复和复盘。先在隔离池与影子流量执行，再逐步扩大。实验结果进入发布门禁和 runbook；若系统只能靠人工 SSH 清理，说明自动恢复边界不足。

恢复点与灾备

训练恢复依赖 checkpoint、数据游标、optimizer 和并行布局；推理恢复通常重建 KV；Agent 恢复依赖 workflow state、operation status、approval 和 compensation；数据与评估恢复依赖 snapshot、manifest、结果和报告。不同状态拥有不同 RPO/RTO，不能用一套备份策略覆盖。

灾备方案分为同节点、同区域跨故障域、跨区域和离线冷备。权重和模型制品可多区域复制，敏感数据可能只能保存加密指针和受控副本；trace 可采样保留，审计事件高等级保留。恢复演练验证 hash、权限、schema、版本、依赖和成本，而不只是服务能否启动。

RPO、RTO 与降级

训练 RPO 是可丢失的 step/token，RTO 是恢复到可继续训练的时间；推理 RPO 通常是正在执行请求和 KV，RTO 是恢复健康副本；Agent RPO 是事件、审批、operation 和状态，RTO 是重新接管；评估 RPO 是结果与报告，RTO 是重新运行或读取证据。每类系统定义自己的目标。

降级按能力层级设计：稳定模型、小模型、异步、缓存回答、只读工具、人工队列和安全拒绝。降级不能突破数据区域、权限、安全和副作用边界。用户看到的状态明确是 degraded、partial、queued 或 needs_attention，避免把降级结果误认为正常完成。

跨区域恢复

跨区域恢复需要复制模型制品、配置、注册表、状态、事件、数据 snapshot、评估报告和密钥引用，但不是所有内容都能跨区域。数据驻留和删除策略优先；敏感 payload 可以不复制，Run 恢复时转人工。路由保存 region、policy 和 fallback，区域切换后重新校验模型和工具兼容。

恢复演练

季度演练区域不可用、对象存储延迟、模型仓库损坏、状态库恢复、凭证轮换、网络分区和工具供应商故障。测量 RTO、RPO、数据完整、权限、trace、成本、用户影响和人工工作量。演练结束保留证据并更新 runbook；“备份成功”不等于“可以恢复”。

灾备状态分类

灾备清单将状态分为可重建、可复制、不可复制和需人工。模型 engine 可从权重重建，KV 通常可重建，训练 checkpoint 需要复制，Agent tool operation 需要查询外部状态，人工审批可能不可复制，敏感 prompt 可能禁止跨区复制。RPO/RTO 与状态类别绑定，灾备演练按类别验收。

灾备切换前验证 artifact 签名、版本、区域、密钥、数据授权、工具 endpoint、路由、容量和观测；切换后验证流量、SLO、成本、审计、任务状态和副作用。区域恢复不能只是 DNS 修改，必须重新做能力与安全检查。故障区域恢复后，防止双活写入造成状态冲突，采用 fencing、单主或明确的合并规则。

混沌与一致性测试的组合

单纯杀 Pod 只能验证重启，复杂系统还要验证消息重复、网络分区、时钟偏差、状态库延迟、外部操作未知和回滚中断。Chaos Mesh 可做资源和网络注入，Jepsen 风格测试关注并发、分区和一致性 [22][23]。Agent Runtime 的副作用测试还需要沙箱、幂等断言和外部状态检查。

混沌实验结果按故障、检测、隔离、恢复、数据损失和用户影响保存。实验期间不能让自动回滚掩盖错误，停止条件保护真实业务。重复演练直到恢复时间、资源释放和审计符合目标，再把场景变为长期回归。

一致性测试

分布式状态测试关注事件重复、乱序、分区、时钟偏差、重试和并发写。Jepsen 风格的测试将操作序列、故障窗口和最终状态记录下来，检查是否出现丢失更新、重复副作用、非法状态或读到未来 [23]。运行时还增加业务不变量，例如一次 operation 最多成功一次、预算不为负、已撤销权限不能执行、终态不可逆。

测试使用模型、工具、消息和状态的可控 fake，真实外部副作用在 sandbox 中验证。发现不变量破坏时保留最小重现历史、事件、版本和资源，加入回归。仅测试单机和 happy path 无法证明跨节点状态正确。

灾备中的安全降级

灾备区域或冷备环境可能没有同样的模型、工具、数据权限和安全服务。切换前生成 capability matrix，按任务选择可用功能；缺少高风险策略时关闭自动副作用；缺少私有数据时返回明确不可用而不是访问公共替代；缺少 judge 时不执行质量门禁或转人工。灾备成功定义包含安全和合规，不只是流量返回 200。

冷备恢复时间较长，用户看到 queued 或 degraded；状态系统保存预计恢复与取消入口。恢复后优先处理已批准且有 deadline 的任务，新任务按容量逐步放量。双区域恢复时使用 fencing 和 epoch，防止旧区域恢复写入造成重复。每个切换动作写审计和 incident timeline。

灾备与成本取舍

更低 RPO/RTO 通常增加复制、备用 GPU、跨区网络、人工演练和存储成本。ADR 明确哪些状态值得复制，哪些可重建，哪些转人工；业务 owner 接受低概率高影响风险。训练 checkpoint 可能按阶段选择频率，推理 KV 多数重建，Agent operation 需要外部查询，评估报告高价值保留。

恢复演练测真实时间和资源，而不是理论配置。若跨区复制不被允许，不能仅以加密作为越界理由；应改用批准区域内备份、分区存储或在许可环境重算；若备用模型质量不足，限定任务或转人工。所有牺牲都有有效期和重新评估条件，避免临时降级变成永久事实。

可靠性评审中的 ADR

每个重要平台选择写 ADR：背景问题、目标、候选、证据、决策、获得能力、主动牺牲、已接受风险、监控、回滚和重新评估条件。比如选择全量 trace 获得诊断与合规，但牺牲成本和隐私；选择跨区复制获得 RTO，但牺牲数据驻留与成本；选择自动重试获得短暂故障恢复，但增加副作用风险。

ADR 的维度保持一致：可用性、延迟、吞吐、质量、成本、安全、隐私、恢复、复杂度、团队负担和供应商锁定。表格比较候选，正文解释因果；指标和实验链接到来源与报告。这样治理不是审批形式，而是让系统取舍长期可见。

可靠性测试的分层

单元测试验证状态迁移、schema、策略、预算、幂等和错误；集成测试验证模型、工具、存储、队列和观测；合同测试验证 API 与事件；回放测试验证历史 Run；压力测试验证容量；混沌测试验证故障；恢复测试验证 RPO/RTO；红队测试验证安全。每层的失败都产生不同门禁，不能用集成测试替代恢复和安全。

测试数据和生产数据隔离，副作用使用 sandbox 或 mock，敏感数据受控。测试结果保存 commit、artifact、配置、环境、原始输出和报告。Flaky 测试不应被简单重试隐藏，标记不稳定并修复；随机测试保存 seed 与最小重现。

12.8 删除、备份、供应商与交付证据

数据保留与删除

定义 prompt、output、trace、memory、tool result、评估样本、模型制品和审计事件的保留期、删除方式、备份影响和法律保留。删除请求沿 lineage 找到缓存、派生 embedding、回放、标注、训练 candidate 和报告；摘要仍含个人信息或可关联标识时也纳入清理；保留例外列明依据、用途限制、owner和复审期限。删除本身产生审计事件但不保留原始敏感内容。

数据备份与删除冲突

备份提高恢复能力，但会延长数据保留和删除复杂度。备份记录数据等级、密钥、区域、保留、恢复 owner 和删除实现；敏感备份设置最小化、加密和到期清理；只有专用密钥及全部副本/密钥副本均受控、可验证失效时，才能评估密钥销毁是否满足不可恢复目标，不能把加密本身当已删除。删除请求要检查在线、缓存、快照、备份、评估、训练候选、trace 和人工导出，给出完成范围与例外。

审计需要证明删除请求被处理，但审计不能再次保存被删除内容。保存主体、时间、对象 hash、策略和结果，不保存原文。历史模型无法简单从训练中“删除记忆”时，风险登记记录限制、补救和重新训练计划，由治理 owner 批准。

供应商与外部 API

外部模型、judge、搜索、支付、短信、邮件和云服务拥有各自的 SLA、数据处理、区域、限流、错误和版本。供应商清单保存用途、数据流、DPA/授权、fallback、成本、联系人和退出方案。敏感数据默认不发送；发送前最小化、脱敏和记录同意。供应商版本变化进入兼容与评估。

外部服务不可用时，Runtime 依据工具 policy 选择重试、缓存、替代、异步或人工。不可逆副作用的供应商确认未知时，查询 operation 而非重试。合同与技术控制共同决定风险，不能只相信服务方“高可用”描述。

灾备与供应商退出

平台不能只设计“供应商一直可用”。模型供应商、GPU 云、对象存储、检索、支付和标注服务都需要退出或切换计划：保存可迁移 artifact、协议、数据格式、评估、权限、成本和替代服务；定期运行导出与恢复。依赖外部专有格式时，生成可读 manifest 和转换器，避免被单一服务锁定。

退出演练不等于立刻迁移全部流量。先在离线数据和影子 Run 验证，比较质量、成本、延迟、安全与合规，再迁移低风险租户，最后处理关键任务。旧服务 drain 后保留查询和审计能力，确保历史 Run 能解释。供应商变化进入风险登记和容量预算。

合规证据的可重复生成

合规报告从机器可读的 manifest、policy decision、audit event、model card、datasheet、评估报告和发布记录生成。手工复制截图容易遗漏版本和时间。报告包含系统用途、数据流、用户、模型、限制、风险控制、监控、事件、删除、供应链和审批。任何结论都有 artifact、trace 或事件引用。

报告生成器版本化，组织规则变化产生新报告，旧报告保留历史语义。外部审计访问受控 view，原始敏感内容不必交付。需要解释一次决策时，可以从 report 反查输入、策略、版本和结果，但不暴露无关租户。

交付证据的长期保留

长期保留的 evidence bundle 包括 model、data、workflow、tool、policy、runtime、hardware、评估、灰度、事故、成本和审批版本。内容按敏感等级和合规期限保存，摘要 hash 与审计保留时间更长。历史报告只读，修订通过新报告引用旧报告，不能覆盖审计事实。

在季度或重大变更时做 evidence review：链接是否有效，签名是否可验证，snapshot 是否可读，指标定义是否改变，风险是否已关闭，回滚是否仍能启动，owner 是否仍存在。长期治理的难点不是写第一份报告，而是保证几年后仍能解释一个旧模型为何被发布和如何被撤回。

端到端演练

选取一个训练 run、一个推理请求、一个 Agent Run 和一个评估任务，验证从输入、资源、状态、trace、成本、质量、权限到结果的完整链路。注入节点故障、存储失败、工具超时、状态重复、模型回滚、数据撤回和区域切换，检查状态不覆盖、副作用不重复、敏感数据不泄露、预算可对账。

变更与发布验收

随机选择模型、engine、prompt、workflow、tool、policy、数据和依赖变更，验证来源池、兼容矩阵、质量门禁、灰度、告警、自动暂停和回滚。发布记录包含变更、获得、牺牲、风险、审批、指标和恢复策略。旧版本可启动、可读取需要的状态、可关闭新 cache，并能处理正在执行的任务。

审计与治理验收

验证租户、角色、凭证、区域、数据等级、工具权限、模型 artifact、评估报告和删除请求。检查审计不可篡改、访问可追踪、日志脱敏、证据可回放、模型卡和数据说明存在、供应链 hash 和签名正确。安全红队、混沌、恢复和成本演练至少按周期重复，不能只在首次上线执行。

一份删除与备份范围记录

删除先让授权查询、召回与缓存命中停止，再可靠传播到派生副本，并记录“逻辑不可见”“在线物理清理”“历史副本待到期”“依法保留”各自状态。S3开启版本时，简单DELETE通常只增加delete marker并把旧内容保留为历史版本，GET返回404并不能证明物理擦除；永久删除需覆盖相应versionId [24]。本书因此要求列出当前对象、历史版本、复制目的地、索引、向量、摘要、缓存、回放、标注导出和供应商副本，而非只删会话表。

这不是实际用户删除记录，所有示例值仅说明字段职责。执行结果不能用单一done掩盖仍在备份保留窗的载荷。对不能逐项删除的不可变备份，记录隔离访问、到期清理计划和例外，恢复时先在隔离环境完成删除清单及当前撤权叠加，再允许业务读取。PostgreSQL18的PITR会从base backup和WAL重建历史时点 [25]；它不会自动理解应用删除请求，因此恢复旧时点可能重新出现旧内容，需要应用层恢复门禁。

索引回滚或离线重建同样读取当前删除清单和实体版本；旧snapshot只能提供候选数据，发布前追平deletion watermark及增量撤权，验证旧记录被墓碑拒绝。删除清单本身也需最小权限与保留策略，尽量使用不可逆受限标识，并防止墓碑到期早于所有旧副本。恢复日志、重放队列和人工导出都属于范围，不能只看数据库当前行。

已经进入训练权重的内容不能通过删除原始样本就证明被遗忘。记录受影响模型、是否需要停止使用、替换/重训或其他可验证补救及责任人；未经验证不宣称完成模型遗忘。对象hash或主体标识仍有识别风险时，审计亦需访问限制与期限；“保存删除证据”不意味着永久保留原文或可恢复的PII映射。

发布、恢复与保留的联合验收

按第10章门禁区分服务成功、任务成功和证据完整，按第11章查询操作事实。回滚模型/索引只能恢复兼容执行组合，当前撤权与删除不能一起回退；旧审批也不能因恢复旧版本自动扩权。不兼容的在途Run暂停并保留checkpoint，迁移必须重验语义、权限与既有副作用。供应商故障时fallback仍受能力与数据策略约束，缺批准区域或删除能力的端点不能临时接收敏感数据。

验收抽样至少覆盖一条UNKNOWN修复、一条补偿失败升级、一条跨班次交接、一条删除旧备份恢复和一次供应商中断；每条保存输入引用、范围、owner、期限、实际动作、外部事实和剩余限制。治理通过表示这些范围有证据，并非所有风险已消失；任何waiver都要绑定能力、理由、有效期和补救，不能通过延期让未知状态永久无人处理。

12.9 本章小结

生产治理把第7–11章的资源、制品、评估、请求和业务状态变成可运营承诺。SLO说明怎样测量，发布记录说明改变什么，operator流程说明谁处理未决事实，删除范围说明哪些数据已清理、哪些仍受限保留。任何服务恢复都要同时核对业务事实、数据权限和剩余责任。

本批书稿交付的是机制、教学推演与验收设计，不把引用存在等同控制已执行。实际平台仍需运行自己的故障演练、恢复和删除测试并保存证据；后续Agent章节复用这里的运营接口，不复制另一套状态恢复算法。

12.10 参考资料

[1] Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. https://sre.google/workbook/implementing-slos/ 核验日期：2026-10-17

[2] Beyer, B., et al. Site Reliability Engineering: Managing Incidents. 2016. https://sre.google/sre-book/managing-incidents/ 核验2026-10-17

[3] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[4] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[5] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

[6] NIST. AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework 访问日期：2026-10-17

[7] ISO. ISO/IEC 42001:2023 — AI Management Systems. 官方公开摘要，核验2026-10-17. https://www.iso.org/standard/42001

[8] Mitchell, M., et al. Model Cards for Model Reporting. 2019. https://arxiv.org/abs/1810.03993 核验2026-10-17

[9] Gebru, T., et al. Datasheets for Datasets. CACM, 2021. https://arxiv.org/abs/1803.09010 核验2026-10-17

[10] SLSA. Specification v1.0. https://slsa.dev/spec/v1.0/ 访问日期：2026-10-17

[11] Sigstore. Overview. 官方文档，核验2026-10-17. https://docs.sigstore.dev/about/overview/

[12] Wiggins, A. The Twelve-Factor App. https://12factor.net/ 访问日期：2026-10-17

[13] OpenSSF. Scorecard. https://github.com/ossf/scorecard 访问日期：2026-10-17

[14] Kubernetes. Pod Lifecycle. 官方文档，核验2026-10-17. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

[15] NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1，2024. https://doi.org/10.6028/NIST.AI.600-1 核验2026-10-17

[16] ISO. ISO/IEC 23894. https://www.iso.org/standard/77304.html 访问日期：2026-10-17

[17] 国家互联网信息办公室等. 生成式人工智能服务管理暂行办法. 中文政策原文，2023-07-13. https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm 核验2026-10-17

[18] OWASP. Top 10 for Large Language Model Applications. 官方项目说明，核验2026-10-17. https://owasp.org/projects/top-10-for-large-language-model-applications

[19] MITRE ATLAS. ATLAS Tactics, Techniques, and Case Studies Data. 官方仓库，核验2026-10-17. https://github.com/mitre-atlas/atlas-data

[20] Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ 访问日期：2026-10-17

[21] Google. AIP-194: Automatic Retry Configuration. https://google.aip.dev/194 核验2026-10-17

[22] Chaos Mesh. Simulate Network Faults. 官方文档，核验2026-10-17. https://chaos-mesh.org/docs/simulate-network-chaos-on-kubernetes/

[23] Jepsen. Consistency. 官方一致性模型说明，核验2026-10-17. https://jepsen.io/consistency

[24] AWS. Deleting Object Versions from a Versioning-enabled Bucket. 官方S3文档，核验2026-10-17. https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html

[25] PostgreSQL. 25.3 Continuous Archiving and Point-in-Time Recovery. 18. https://www.postgresql.org/docs/18/continuous-archiving.html 核验2026-10-17

第13章 Agent 的演化与架构总纲：从对话应用到可治理 Runtime

本章核心问题：任务是否需要动态推理、外部行动、验证与治理？

版本与范围：协议按 MCP 2025-06-18，滚动文档核验于 2026-10-17。本章组件划分、JSON、图示与数值均为本书教学设计；框架材料只证明对应机制存在，不证明该架构已经实现或实测。

引言

很多团队第一次设计 Agent 系统时，会把注意力放在模型上：用哪个大模型、提示词怎么写、工具调用怎么接。模型当然重要，但从工程架构看，Agent 不是“一个会调用工具的 Prompt”，而是一个围绕模型构建的运行时系统。

这个运行时系统至少要回答十二个问题：

1. 用户到底想完成什么任务？
2. 任务应该被拆成哪些步骤？
3. 每一步需要哪些上下文？
4. 哪些历史状态、用户偏好和经验可以被复用？
5. 系统有哪些可复用技能、工具、连接器和工作流？
6. 模型应该选择哪个能力、哪个模型或哪个专家？
7. 哪些动作允许执行，哪些必须拒绝、审批、沙箱或人工接管？
8. 执行过程中如何观察、修复、暂停、恢复和停止？
9. 任务过程如何被记录、回放、审计和评估？
10. 最终结果如何被验证、审查和交接？
11. 用户反馈、失败案例和复盘经验如何进入改进闭环？
12. 哪些能力可以自动沉淀，哪些必须经过人工审核和灰度发布？

本章的目标是先建立一条 Agent 演化主线，再给出通用的架构总纲。它不绑定某一种产品形态，也不局限于某个垂直场景。你可以用它设计企业知识助手、告警处理助手、客服运营助手、数据分析助手、审批助手，也可以用它评估一个现有 Agent 系统到底缺了哪一层。

本章按七层展开：13.1 先理解 Agent 如何从对话应用演化为受控 Runtime；13.2 判断是否真的需要 Agent；13.3 建立生产级 Agent Runtime 的最小骨架；13.4 展开核心组件的职责边界和后续章节地图；13.5 讨论组件如何组合成不同架构模式；13.6 用三案例和检查清单校验设计，13.7 说明后端能力如何迁移。

第 13 章不是把每个组件都讲透，而是给第三部分建立一张总图。第 17 章会先展开模型协议与系统消费边界，第 18 章会深入工具、Skills、连接器与 MCP，第 19 章会展开 Agent 知识系统，第 20 章会展开 Agent 记忆系统，第 21 章会深入执行编排、状态机、多 Agent 协作和平台框架，第 22 章会系统讨论 Evals、Guardrails、Trace 和可观测性。理解了本章的边界图，后续章节就不再是零散专题，而是同一个 Runtime 的逐层展开。

13.1 Agent 的演化：从回答到受控完成工作

今天的 Agent 看起来像一个新名词，但它并不是从“更长的 Prompt”突然跳出来的。它是为了持续解决同一个问题而逐步演化的：如何让模型不只给出一段看似合理的回答，还能在明确的边界内收集证据、采取行动、验证结果，并把过程交付给人和系统。

演化有两条必须同时观察的主线。第一条是技术形态：系统的工作方式如何变化；第二条是工程能力：为了让每次升级可靠运行，系统必须补齐哪些确定性机制。只看技术形态，容易把 Agent 误解成某个框架功能；只看工程组件，又会失去“为什么现在需要它”的判断依据。

13.1.1 技术形态：Agent 如何一步步获得行动能力

Chatbot → Prompt Application → Tool-using Agent → Workflow Agent
→ Runtime Agent → Multi-Agent → 受控持续改进系统

MRKL 用模块组合语言、知识与离散推理；Toolformer 研究模型如何学习调用 API。这些论文说明能力组合的技术方向，并未给模型授予系统权限。[1][2]

阶段之间不是替代关系。大多数生产系统同时包含多个阶段：稳定的步骤仍然应该由工作流或传统后端完成；只有需要动态判断的局部才交给 Agent。演化的正确方向不是“更自主”，而是“在更复杂的任务上仍可约束、可验证、可交接”。

13.1.2 工程能力：每次升级都要补上一层确定性

技术形态的升级，要求工程能力按下面的顺序逐层补齐：

Prompt → Context → Harness → API / Tools → Knowledge / Memory
→ Orchestration → Evals / Guardrails / Observability

• Prompt 把自然语言目标变成可检查的任务协议。
• Context 决定模型在当前一步看到什么证据、状态和约束。
• Harness 把模型调用包进预算、循环、重试、验证和停止条件。
• API / Tools 把行动变成受 schema、权限和副作用控制的接口调用。
• Knowledge / Memory 分别提供可追溯事实与跨任务沉淀的经验，不能彼此替代。
• Orchestration 让多步骤、多角色任务消费第11章的暂停、恢复、幂等与人工接管原语。
• Evals / Guardrails / Observability 让系统能够发现退化、限制风险、回放过程并安全迭代。

这正是第三部分后续章节的阅读地图。第 14 至第 16 章处理任务协议、信息架构和运行环境；第 17 至第 21 章扩展模型能力、外部行动、知识、记忆和执行编排；第 22 章把所有能力收敛到生产治理。不要把其中任何一层当成可选装饰：当系统开始影响外部世界时，缺失的一层通常就是下一次事故的来源。

13.1.3 贯穿案例：企业知识助手如何升级

以“企业知识答疑”为例，同一个需求会经历完全不同的系统形态：

1. Chatbot 解释制度术语；
2. Prompt Application 根据问题生成制度答复草稿；
3. Tool-using Agent 检索制度、流程和 FAQ，并给出引用证据；
4. Workflow Agent 按固定顺序检索、核对版本、生成带引用的答复并审查；
5. Runtime Agent 在异常路径出现时选择补充查询、请求澄清或转交人工；
6. Multi-Agent 将调查、变更审查和面向业务方的交付拆给不同角色；
7. 受控持续改进 将复盘中确认有效的证据规则、Skill 和评测样本，经审核和灰度后纳入系统。

第 11 章讨论这类任务的持久执行与恢复，第 22 章讨论评估、权限与审计。本章只建立一个判断：从第 3 步开始，系统不再只是“回答问题”；它开始触发或建议行动，因此必须把权限、证据、验证、审批和审计一起设计。

13.1.4 升级边界：何时不应升级为 Agent

并不是每个 LLM 功能都要走到 Runtime Agent。以下情况应优先使用普通 LLM 应用、规则引擎或确定性工作流：

• 输入和流程稳定，规则可以可靠覆盖；
• 结果只用于辅助阅读，不会触发外部副作用；
• 任务没有多源信息收集、动态决策或跨系统行动需求；
• 无法提供必要的权限、审计、验证和人工接管机制；
• 业务价值不足以覆盖模型调用、治理与运营成本。

当任务同时具备模糊目标、多源上下文、动态路径和可验证动作时，才值得进入后续的 Agent Runtime 设计。所谓“自我演化”也不意味着模型自行修改生产行为；它应当是评测发现问题 → 复盘形成候选改进 → 人工审核 → 灰度发布 → 监控评估 → 必要时回滚的受控闭环。

13.2 Agent 架构决策：先判断是否需要 Agent

13.2.1 从问题出发：为什么不是传统后端

Anthropic 将预定义代码路径的 Workflow 与由模型动态决定路径的 Agent 区分，并指出复杂度会增加成本和延迟。这里采用这个选型维度；两者可以组合。[3]

在设计 Agent 系统之前，先不要问“能不能接一个大模型”，而要问：为什么传统后端、规则引擎、工作流系统或搜索系统不够用？

如果一个问题可以被稳定规则、固定流程和确定性接口很好地解决，那么优先使用传统后端。Agent 的价值来自另一类任务：目标表达模糊，信息分散在多个系统里，执行路径需要根据观察动态调整，最终结果还需要证据、验证和人工审查。

这一步的结论不是“要不要 AI”，而是判断任务是否需要推理、行动、验证和治理同时存在。如果只需要一次性生成或分类，可以是普通 LLM 应用；如果需要在受控边界内多步完成任务，才进入 Agent 架构设计。

13.2.2 Agent 与传统后端的本质区别

传统后端系统基于确定性逻辑：

Structured Input -> Rules / Code -> Deterministic Output

Agent 系统基于受控推理：

Task -> Context -> Reasoning -> Tool Use -> Observation -> Verification -> Result

两者不是替代关系，而是分工关系。传统后端擅长高频、稳定、强一致的业务流程；Agent 擅长处理模糊输入、多源上下文、多步骤推理和开放式任务。

一个常见误区是把 Agent 的概率性理解成“不可控”。生产系统的正确做法不是期待模型永远正确，而是把模型放进可控 Runtime：

flowchart LR
    Model["LLM<br/>概率性推理"]
    Runtime["Agent Runtime<br/>确定性边界"]
    World["External Systems<br/>外部系统"]

    Runtime -->|"提供受限上下文"| Model
    Model -->|"提出计划或工具调用"| Runtime
    Runtime -->|"策略裁决 / 参数校验 / 沙箱执行"| World
    World -->|"结构化观察结果"| Runtime
    Runtime -->|"验证 / 审计 / 交接"| Runtime

换句话说，Agent 系统的工程目标不是消灭不确定性，而是把不确定性限制在可以观察、可以验证、可以回滚、可以接管的范围内。

13.2.3 Agent 是运行时系统，不只是模型调用

一个最小的 LLM 应用通常长这样：

User Input -> Prompt -> LLM -> Answer

这类系统适合做一次性问答、文本生成、分类、摘要等任务。它的特点是简单、低成本、易上线，但它并不是真正意义上的 Agent。

操作系统类比：Runtime 才是 Agent 的安全边界

理解 Agent Runtime，一个有效的类比是 Linux 操作系统。这个类比不是说 Agent 系统真的等同于操作系统，而是帮助建立一个工程直觉：模型不能直接操作真实世界，它只能提出动作请求；真正的执行必须经过 Runtime 的受控边界。

在 Linux 里，用户态程序不能直接读写磁盘、操作网卡、访问任意内存或控制其他进程。它必须通过 system call 进入内核，由内核完成权限检查、资源调度、驱动调用、状态管理和审计。Agent 也类似：LLM 可以提出“查日志、读文件、调用 API、发通知、执行命令”，但这些请求不能直接落到真实系统，必须先经过 Agent Runtime 的裁决、调度、执行和记录。

这个类比可以拆成下面几层：

这张表背后的重点不是名词对应，而是责任边界。生产级 Agent 至少要把下面五层分开：

• Agent Runtime 管生命周期：任务从哪里来、谁在执行、能看到什么、能做什么、状态如何保存、失败如何恢复、过程如何审计。
• Agent Loop 管下一步：根据任务状态、上下文、工具观察和模型推理，决定继续、澄清、调用工具、修复还是停止。
• Execution Engine 管动作调度：把 Planner 或 Agent Loop 产生的动作请求变成可控执行，处理参数完整性、执行状态、超时、取消、重试、降级和结果回写。
• Tool Runtime 管工具治理：管理工具注册、Schema、参数校验、可见工具集合、连接器适配、MCP 调用、工具级错误码和结构化 Observation。
• Execution Backend 管真实副作用：在本地 Shell、Docker、浏览器、远程 API、MCP Server、Kubernetes Job 或远程 Runner 中真正执行动作。

因此，Agent 的行动链路不应该是“模型直接调用外部系统”，而应该是：

LLM / Agent Loop
  -> Tool Call / Action Request
  -> Policy Check
  -> Execution Engine
  -> Tool Runtime / Connector / Workflow Runner
  -> Execution Backend
  -> Observation
  -> Agent Loop

这也解释了生产级 Agent 的一个基本原则：Prompt 不是权限边界，Runtime 才是权限边界。就像不能靠告诉用户态程序“请不要访问这个文件”来保护操作系统，Agent 也不能只靠 Prompt 说“不要执行危险命令”。真正的安全边界必须由 Runtime、Policy、Sandbox、Execution Engine 和 Tool Runtime 强制执行。

这个分层是本书的教学抽象。OpenAI Agents SDK 提供循环、工具、交接、审批与观测入口，但应用仍负责部署、工具实现、状态存储和审批决策；不能从“用了 SDK”推出业务动作可靠完成。[4]

Agent 系统通常长这样：

flowchart TD
    User["User Intent / Issue / Spec<br/>用户意图 / 问题 / 任务说明"]
    Planner["Task Planner<br/>任务规划器"]
    Context["Context Builder<br/>上下文构建器"]
    Skills["Skill Registry<br/>技能注册表"]
    Tools["Tool Registry<br/>工具注册表"]
    Policy["Policy Engine<br/>策略引擎"]
    Loop["Agent Loop<br/>观察 / 决策 / 行动 / 修复"]
    Verifier["Verifier<br/>验证器"]
    Review["Review Surface<br/>审查与交接界面"]

    Sources["Knowledge / Data / Docs / Rules / State<br/>知识 / 数据 / 文档 / 规则 / 状态"]
    SkillDefs["Domain Skills / Workflow Skills / Operation Skills<br/>领域技能 / 流程技能 / 操作技能"]
    ToolDefs["Read / Search / Write / Notify / Execute / Approve<br/>读取 / 搜索 / 写入 / 通知 / 执行 / 审批"]
    Decisions["Allow / Deny / Ask / Sandbox / Audit<br/>允许 / 拒绝 / 询问 / 沙箱 / 审计"]
    Checks["Check / Simulate / Validate / Compare<br/>检查 / 模拟 / 校验 / 对比"]
    Outputs["Answer / Report / Ticket / Trace / Handoff<br/>回答 / 报告 / 工单 / 追踪 / 交接"]

    User --> Planner
    Planner --> Context
    Context --> Skills
    Skills --> Tools
    Tools --> Policy
    Policy --> Loop
    Loop --> Verifier
    Verifier --> Review

    Context -.-> Sources
    Skills -.-> SkillDefs
    Tools -.-> ToolDefs
    Policy -.-> Decisions
    Verifier -.-> Checks
    Review -.-> Outputs

这张图是本章最重要的心智模型。模型只是 Agent Loop 中的推理引擎，真正让系统可用的是 Runtime：

• Planner 把模糊任务变成可执行计划；
• Context Builder 决定模型能看到什么；
• Skill Registry 让系统复用领域经验和操作流程；
• Tool Registry 把外部能力变成可审查接口；
• Policy Engine 把权限和风险判断从 Prompt 中拿出来；
• Agent Loop 负责多轮观察、决策、行动和修复；
• Verifier 决定任务是否真的完成；
• Review Surface 让人类能审查、接管、复盘和追责。

如果一个系统只有 Prompt 和工具调用，没有上下文治理、策略裁决、执行预算、验证机制和审计界面，它更像“增强版聊天应用”，还不是生产级 Agent。

13.2.4 决策框架：什么时候需要 Agent

不要因为“可以用 AI”就设计 Agent。先判断问题是否真的需要推理和行动。

flowchart TD
    Start["要解决的任务"]
    Rule["规则是否清晰稳定？"]
    Deterministic["用传统后端 / 规则引擎 / 工作流系统"]
    Language["是否需要理解自然语言、文档或非结构化输入？"]
    MultiStep["是否需要多步骤推理和动态决策？"]
    Tools["是否需要跨系统查询、写入、通知或执行动作？"]
    Verify["结果是否可以被验证或人工审查？"]
    Risk["错误后果是否可控？"]
    Agent["适合设计 Agent"]
    Hybrid["采用混合架构：后端流程 + Agent 辅助"]
    NotReady["不适合直接上 Agent：先补验证、权限或人工流程"]

    Start --> Rule
    Rule -->|"是，且变化少"| Deterministic
    Rule -->|"否，或变化快"| Language
    Language -->|"否"| Hybrid
    Language -->|"是"| MultiStep
    MultiStep -->|"否"| Hybrid
    MultiStep -->|"是"| Tools
    Tools -->|"否"| Hybrid
    Tools -->|"是"| Verify
    Verify -->|"否"| NotReady
    Verify -->|"是"| Risk
    Risk -->|"不可控"| NotReady
    Risk -->|"可隔离 / 可审批 / 可回滚"| Agent

可以用一个更工程化的矩阵判断：

这里不应该写“Agent 准确率通常是多少”这类通用数字。不同模型、任务、上下文、工具、评测集和上线时间都会改变结果。更可靠的做法是定义任务级 Eval：

• 对知识问答，看引用准确率、拒答率、幻觉率、权限违规率；
• 对告警诊断，看根因命中率、证据完整度、建议安全性、人工采纳率；
• 对审批助手，看分类准确率、风险漏判率、误拦截率、处理时延；
• 对运营助手，看动作建议命中率、执行回滚率、用户确认率。

Agent 是否可用，必须由你自己的任务、数据和风险边界验证，而不是由一个跨场景的经验准确率决定。

13.2.5 混合架构：Agent 不应该接管所有东西

生产系统里，最稳妥的架构通常不是“全 Agent”，而是混合架构：

flowchart TD
    subgraph Backend["Deterministic Backend<br/>确定性后端"]
        API["API / Workflow"]
        DB["Database"]
        Rules["Rules / State Machine"]
        Audit["Audit Log"]
    end

    subgraph Agent["Agent Runtime<br/>推理运行时"]
        Planner["Planner"]
        Context["Context Builder"]
        Loop["Agent Loop"]
        Policy["Policy Engine"]
        Verifier["Verifier"]
    end

    subgraph Human["Human Control<br/>人工控制"]
        Review["Review Surface"]
        Approval["Approval"]
        Feedback["Feedback"]
    end

    User["User / Event"] --> API
    API -->|"结构化任务"| Agent
    Agent -->|"只读查询 / 低风险建议"| API
    Agent -->|"中高风险动作请求"| Approval
    Approval -->|"确认后执行"| API
    API --> DB
    API --> Rules
    API --> Audit
    Agent --> Review
    Review --> Feedback
    Feedback --> Agent

推荐的边界是：

• 传统后端管状态：订单、工单、审批、资产、权限、任务生命周期；
• Agent 管推理：理解意图、规划路径、整合证据、生成建议；
• Policy 管风险：动作是否允许、是否需要审批、是否进入沙箱；
• Verifier 管完成：结果是否满足任务契约；
• Human Review 管责任：关键结论、风险动作、知识沉淀必须可审查。

Agent 的价值不是替代后端系统，而是把后端系统原本无法处理的模糊任务、跨系统任务和专家经验任务，转化成可操作、可验证、可审计的工作流。

13.3 Agent Runtime：生产级 Agent 的最小骨架

13.3.1 最小 Runtime 心智模型

完整 Runtime 图容易让人觉得 Agent 很复杂。真正落地时，可以先记住一个最小骨架：

这张表是后面所有组件的压缩版。MVP 可以不复杂，但这些边界最好一开始就存在。哪怕它们只是几个模块、几张表、几个配置，也比把所有责任都塞进 Prompt 更可靠。

13.3.2 通用 Agent Runtime 分层架构

下面是一个更完整的通用架构图：

flowchart TB
    Entry["Entry Layer<br/>Chat / API / Event / Ticket / Webhook"]
    Intent["Intent Normalizer<br/>意图识别与任务契约"]
    Planner["Task Planner<br/>分解 / 排序 / 预算 / 停止条件"]

    subgraph ContextPlane["Context Plane<br/>上下文平面"]
        Router["Source Router"]
        Retriever["Retriever"]
        MemoryRouter["Memory Router"]
        Ranker["Ranker / Compressor"]
        Package["Context Package"]
    end

    subgraph CapabilityPlane["Capability Plane<br/>能力平面"]
        CapabilityRegistry["Capability Registry"]
        SkillRegistry["Skill Registry"]
        ToolRegistry["Tool Registry"]
        ConnectorRegistry["Connector / MCP Registry"]
        ToolRuntime["Tool Runtime"]
    end

    subgraph GovernancePlane["Governance Plane<br/>治理平面"]
        Policy["Policy Engine"]
        HumanControl["Human Control Plane"]
        Guardrails["Guardrails"]
        Budget["Budget / Rate Limit"]
        Audit["Audit / Trace"]
    end

    subgraph ReasoningPlane["Reasoning Plane<br/>推理平面"]
        ModelRouter["Model Router / Handoff"]
        Model["LLM"]
        Loop["Agent Loop"]
        State["Task State"]
        Checkpoint["Checkpoint Store"]
    end

    subgraph VerificationPlane["Verification Plane<br/>验证平面"]
        Verifier["Verifier"]
        Eval["Eval Harness"]
        Evidence["Evidence Store"]
    end

    Review["Review Surface<br/>Answer / Report / Ticket / Handoff"]

    Entry --> Intent --> Planner --> ContextPlane
    ContextPlane --> CapabilityPlane
    CapabilityPlane --> GovernancePlane
    GovernancePlane --> ReasoningPlane
    ReasoningPlane --> CapabilityPlane
    ReasoningPlane --> VerificationPlane
    VerificationPlane --> Review
    GovernancePlane --> Audit
    VerificationPlane --> Evidence
    ReasoningPlane --> Checkpoint

这套架构可以拆成六个平面：

注意：这些平面不一定对应独立服务。MVP 可以把它们放在一个进程里，但架构边界要清晰。否则系统越长越像一个巨大 Prompt，最后难以测试、难以调试、难以治理。

13.3.3 Runtime 初始化：模型、工具、技能、策略与数据源

Agent 的完整链路不是从用户请求才开始。请求进入之前，Runtime 已经完成了一次系统初始化：加载配置、注册模型、注册工具、注册技能、编译策略、连接数据源、初始化可观测性。

如果没有这一步，模型就不知道可用工具有哪些，Runtime 也不知道哪些动作允许执行。

flowchart TB
    Config["Runtime Config<br/>模型 / 工具 / 权限 / 数据源 / 环境"]

    subgraph ModelLayer["Model Layer<br/>模型层"]
        ModelRegistry["Model Registry"]
        ModelAdapter["Model Adapter"]
        ModelPolicy["Model Policy<br/>模型选择 / 降级 / 预算"]
    end

    subgraph CapabilityLayer["Capability Layer<br/>能力层"]
        ToolRegistry["Tool Registry"]
        SkillRegistry["Skill Registry"]
        MCPClients["MCP / Plugin / API Clients"]
    end

    subgraph GovernanceLayer["Governance Layer<br/>治理层"]
        PolicyEngine["Policy Engine"]
        Sandbox["Sandbox / Permission"]
        Audit["Audit / Trace"]
    end

    subgraph KnowledgeLayer["Knowledge Layer<br/>知识与状态层"]
        SourceCatalog["Source Catalog"]
        Indexes["Search Index / Vector Index"]
        MemoryStore["Memory / State Store"]
    end

    subgraph QualityLayer["Quality Layer<br/>质量层"]
        VerifierRegistry["Verifier Registry"]
        EvalSuites["Eval Suites"]
        Metrics["Metrics / Logs / Traces"]
    end

    Config --> ModelLayer
    Config --> CapabilityLayer
    Config --> GovernanceLayer
    Config --> KnowledgeLayer
    Config --> QualityLayer
    CapabilityLayer --> PolicyEngine
    KnowledgeLayer --> PolicyEngine
    QualityLayer --> Audit

初始化阶段会产生几个关键注册表：

一个简化的 Runtime 配置可以长这样：

runtime:
  environment: production
  default_mode: read_only
  max_steps: 12
  max_cost_usd: 0.5

models:
  primary:
    name: general-reasoning-model
    capabilities: [reasoning, tool_calling, structured_output]
  fallback:
    name: fast-summary-model
    capabilities: [summarization, classification]

tools:
  - name: search_docs
    risk_level: low
    side_effect: false
  - name: create_ticket
    risk_level: medium
    side_effect: true
    requires_approval: true

skills:
  - name: policy_question_answering
    triggers: [policy, process, reimbursement]
  - name: incident_initial_diagnosis
    triggers: [alert, incident, degradation]

policies:
  default_write_action: ask
  production_side_effect: ask
  restricted_data_access: deny

初始化不是把所有信息都塞给模型。它只是让 Runtime 拥有一张完整的能力地图。真正给模型看的，是后面根据任务动态筛选出来的本轮可见工具、相关技能和上下文包。

系统初始化还应该做健康检查：

• 模型 Provider 是否可用；
• MCP Server、插件和外部 API 是否连接正常；
• 工具 Schema 是否能通过校验；
• Policy 规则是否能编译；
• 检索索引是否新鲜；
• Trace、日志和指标是否能写入；
• 高风险工具是否默认关闭或进入审批模式。

这一步的目标是让 Agent 在接收用户请求之前，就已经知道自己的能力边界和安全边界。

13.3.4 用户请求完整链路：从入口到最终响应

完成初始化后，一次用户请求才真正进入 Runtime。完整链路可以拆成二十个事件：

flowchart TD
    Request["S01 User Request<br/>用户请求"]
    Intake["S02 Request Intake<br/>会话 / 身份 / 环境"]
    Intent["S03 Intent Parsing<br/>意图识别"]
    Contract["S04 Task Contract<br/>任务契约"]
    Mode["S05 Mode Selection<br/>只读 / 建议 / 执行 / 审批"]
    Plan["S06 Initial Plan<br/>初始计划"]
    Expose["S07 Capability Exposure<br/>选择可见技能和工具"]
    Discover["S08 Context Discovery<br/>检索和查询"]
    Select["S09 Context Selection<br/>筛选 / 去重 / 压缩"]
    Package["S10 Context Packaging<br/>上下文包"]
    Prompt["S11 Model Request<br/>系统指令 / 任务 / 上下文 / 工具 Schema"]
    Reason["S12 LLM Reasoning<br/>模型推理"]
    Proposal["S13 Action Proposal<br/>回答或工具调用"]
    Validate["S14 Runtime Validation<br/>Schema / 权限 / 风险"]
    Execute["S15 Tool Execution<br/>工具执行"]
    Observe["S16 Observation<br/>结构化观察"]
    State["S17 State Update<br/>状态更新"]
    Replan["S18 Re-plan / Continue<br/>重规划或继续"]
    Verify["S19 Verify<br/>验证完成度"]
    Final["S20 Final Response<br/>最终响应 / 交接"]
    ActionType{"动作类型判断"}
    ContinueDecision{"是否继续"}
    VerifyResult{"验证结果"}

    Request --> Intake --> Intent --> Contract --> Mode --> Plan --> Expose
    Expose --> Discover --> Select --> Package --> Prompt --> Reason --> Proposal
    Proposal --> Validate
    Validate --> ActionType
    ActionType --> Execute
    ActionType --> Verify
    Execute --> Observe --> State --> Replan
    Replan --> ContinueDecision
    ContinueDecision --> Package
    ContinueDecision --> Verify
    Verify --> VerifyResult
    VerifyResult --> State
    VerifyResult --> Final

这条链路里，模型和 Runtime 的职责不同：

在真正请求模型时，Runtime 通常不会只发送用户原话，而是发送一个被组织过的请求包：

{
  "system_instructions": [
    "你是企业 Agent Runtime 中的推理模块。",
    "只能使用本轮暴露的工具。",
    "所有关键结论必须引用证据。"
  ],
  "task_contract": {
    "intent": "answer_policy_question",
    "goal": "回答员工关于费用报销时限的问题",
    "success_criteria": ["给出直接回答", "引用制度来源", "说明不确定性"]
  },
  "selected_skills": [
    {
      "name": "policy_question_answering",
      "steps": ["识别制度主题", "检索权威文档", "比较冲突条款", "带引用回答"]
    }
  ],
  "context_package": {
    "evidence": [
      {
        "id": "DOC-001#p3",
        "title": "费用报销制度",
        "updated_at": "2026-04-18",
        "excerpt": "差旅住宿费用需要在行程结束后 30 天内提交。"
      }
    ],
    "constraints": {
      "must_cite_sources": true,
      "do_not_expose_restricted_content": true
    }
  },
  "available_tools": [
    {
      "name": "search_docs",
      "description": "按关键词搜索用户有权限访问的内部文档。",
      "input_schema": {
        "type": "object",
        "required": ["query"],
        "properties": {
          "query": {"type": "string"},
          "limit": {"type": "integer"}
        }
      }
    }
  ],
  "task_state": {
    "step": 2,
    "remaining_budget": {"tool_calls": 5, "seconds": 30},
    "observations": []
  }
}

这里有一个关键点：模型看到的是本轮允许使用的工具 Schema，不是完整工具注册表。完整注册表属于 Runtime。模型只负责在可见能力范围内做选择，不能越过 Runtime 调用隐藏工具。

完整请求链路还应该记录成 trace：

request.received
intent.parsed
task_contract.created
mode.selected
plan.created
tools.exposed
context.retrieved
context.packaged
model.requested
action.proposed
policy.checked
tool.executed
observation.recorded
state.updated
verification.completed
response.sent

这组事件让 Agent 任务可以被回放、调试、评估和审计。否则当用户问“为什么它给出这个结论”时，系统只能回答“模型这么说的”，这在生产环境里是不够的。

13.4 Agent 核心组件：职责边界与后续章节地图

13.4 不是要把每个组件都讲透，而是建立一张生产级 Agent Runtime 的组件地图。后续第 17 到第 22 章，会沿着这张地图逐层展开：模型协议、工具系统、知识系统、记忆系统、执行编排、平台化、Evals、Guardrails 和可观测性。

以下组件地图是本书的责任划分，不声称所有框架都实现了同一套控制面。

先用一张图把职责边界和后续章节关系串起来：

flowchart LR
    subgraph Runtime["生产级 Agent Runtime 组件边界"]
        Intake["Event & Intake Router<br/>统一入口"]
        Intent["Intent Normalizer<br/>任务契约"]
        Planner["Task Planner<br/>计划与预算"]
        Context["Context Builder<br/>证据与上下文"]
        Memory["Memory Layer<br/>长期上下文"]
        State["Execution State & Checkpoint<br/>状态与回放"]
        Capability["Capability Registry<br/>Skills / Tools / MCP"]
        Policy["Policy Engine & Human Control<br/>权限 / 审批 / 接管"]
        Loop["Agent Loop<br/>观察 / 决策 / 行动 / 修复"]
        Router["Model Router & Handoff<br/>模型选择 / 专家委派"]
        Verify["Verifier & Eval Harness<br/>验证与评测"]
        Review["Review Surface / Trace / Audit<br/>交付 / 追踪 / 审计"]
        Learn["Learning Loop<br/>反馈驱动演进"]
    end

    subgraph Chapters["后续章节地图"]
        C6["第17章<br/>LLM API 协议"]
        C7["第18章<br/>Tools / Skills / MCP"]
        C8["第19章<br/>Agent 知识系统"]
        C9["第20章<br/>Agent 记忆系统"]
        C10["第21章<br/>执行编排与平台架构"]
        C11["第22章<br/>Evals / Guardrails / Observability"]
    end

    Intake --> Intent --> Planner --> Context --> Loop --> Verify --> Review
    Context <--> Memory
    Planner --> State
    State --> Loop
    Planner --> Capability
    Capability --> Policy --> Loop
    Router --> Loop
    Review --> Learn
    Learn -.-> SkillUpdate["Skill / Memory / Eval 候选"]
    SkillUpdate -.-> Capability
    SkillUpdate -.-> Memory
    SkillUpdate -.-> Verify

    Capability -.-> C6
    Capability -.-> C7
    Context -.-> C8
    Memory -.-> C9
    Intake -.-> C10
    Planner -.-> C10
    State -.-> C10
    Loop -.-> C10
    Router -.-> C10
    Policy -.-> C11
    Verify -.-> C11
    Review -.-> C11
    Learn -.-> C9
    Learn -.-> C11

这张图有两个读法：从左到右看，是一次 Agent 任务在 Runtime 内部的主要控制链路；从组件指向右侧章节看，是第三部分后续内容的阅读路线。也就是说，第 17 到第 22 章不是零散专题，而是这张 Runtime 图上的不同区域。

下面这张表再给出组件地图：

这些组件不一定都要独立成服务。MVP 可以从一个进程、几张表、几个配置和一套 trace schema 开始。但职责边界最好一开始就清楚：哪些事情由模型推理，哪些事情由 Runtime 裁决，哪些事情由人工确认，哪些事情只能通过评测和灰度后进入生产。

13.4.1 Event & Intake Router：Agent 的入口不只是聊天

很多 Agent 原型从聊天框开始，所以会把用户消息当成唯一入口。但生产级 Agent 不只处理自然语言聊天，还要处理各种系统事件：

• 告警系统推送的 incident；
• 工单系统里的升级请求；
• Webhook 触发的业务事件；
• 定时任务产生的巡检结果；
• IDE、CLI 或浏览器插件里的上下文事件；
• 企业 IM、邮件、客服会话中的多轮对话；
• 其他 Agent 或工作流委派过来的子任务。

Event & Intake Router 的职责是把这些入口统一成请求信封，而不是直接让模型读原始事件。

{
  "request_id": "req_20260512_001",
  "channel": "alert_webhook",
  "tenant": "wxquare",
  "actor": {
    "type": "system",
    "id": "prometheus"
  },
  "user_context": {
    "viewer": "u_123",
    "roles": ["sre_oncall"]
  },
  "payload_type": "incident_alert",
  "payload": {
    "service": "payment",
    "severity": "critical",
    "time_window": "2026-05-12T10:00:00+08:00/2026-05-12T10:15:00+08:00"
  },
  "correlation_id": "trace_or_incident_id",
  "idempotency_key": "alert-payment-20260512-1000",
  "environment": "production"
}

这一层主要做四件事：

Event & Intake Router 不应该承担复杂推理。它只负责把“事件从哪里来、谁触发、影响什么、属于什么环境”说清楚。真正的任务理解交给 Intent Normalizer，执行路径交给 Planner 和 Workflow。

这一层很容易被忽略，但它决定 Agent 能不能从聊天机器人走向生产系统。知识助手、客服 Agent、运营 Agent 和 Coding Agent 的差异，往往首先体现在入口事件不同，而不是模型不同。

13.4.2 Intent Normalizer：把用户输入变成任务契约

Agent 的输入不应该直接等于用户原话。用户可能说：

这个客户投诉为什么这么久还没解决？

这句话里面包含了多个隐含问题：

• 这是查询、诊断、催办，还是升级？
• “这个客户”对应哪个客户、工单或订单？
• “这么久”是超过 SLA，还是超过用户心理预期？
• 系统能否读取客户信息？
• 如果要催办，是否需要审批？

所以 Intent Normalizer 不是一个简单分类器，也不是完全由模型单独完成。更准确地说，它是一个由 Runtime 编排的归一化流水线：

Runtime 收集入口元数据
  -> 模型做语义解析
  -> 工具补齐实体和确定性事实
  -> Policy 裁决权限和风险
  -> Runtime 校验并生成 Task Contract

四类组件的职责不同：

第一步，Runtime 先接收请求信封。这里的信息不是模型推理出来的，而是入口系统自带的事实：

{
  "user_id": "u_123",
  "channel": "slack",
  "workspace": "customer_support",
  "timestamp": "2026-05-12T10:00:00+08:00",
  "raw_text": "帮我看看这个客户投诉为什么一直没处理完"
}

第二步，模型做语义解析：

{
  "intent": "diagnose_ticket_delay",
  "task_type": "diagnosis",
  "entities": {
    "customer": "unknown",
    "ticket": "unknown"
  },
  "needs_clarification": true
}

这一步主要依赖模型，因为用户表达往往是模糊的：同一句“帮我看看”可能是问答、诊断、催办、审批前检查，也可能是要求生成处理建议。

第三步，如果用户消息里带了链接、工单号、客户名或上下文事件，Runtime 可以调用工具补齐确定性事实：

extract_ticket_id(raw_text)
search_customer(candidate_name)
get_ticket_status(ticket_id)

工具返回的是带来源、时间和版本的观察，仍需判断是否过期、完整或与目标实体一致：

{
  "ticket_id": "TCK-1024",
  "customer_id": "C-8801",
  "ticket_status": "pending_engineering"
}

第四步，Policy 对权限和风险做裁决：

{
  "read_ticket": "allow",
  "read_customer_private_note": "deny",
  "notify_customer": "ask",
  "close_ticket": "ask"
}

最后，Runtime 把入口元数据、模型解析、工具事实和 Policy 裁决合并成任务契约：

{
  "task_id": "task_20260511_001",
  "intent": "diagnose_ticket_delay",
  "task_type": "diagnosis",
  "user_goal": "解释客户投诉工单长时间未解决的原因，并给出下一步建议",
  "domain": "customer_support",
  "actor": {
    "user_id": "u_123",
    "role": "support_lead"
  },
  "entities": {
    "ticket_id": "TCK-1024",
    "customer_id": "C-8801",
    "ticket_status": "pending_engineering"
  },
  "risk_level": "medium",
  "allowed_actions": ["read_ticket", "summarize", "recommend"],
  "blocked_actions": ["read_customer_private_note"],
  "requires_approval": ["notify_customer", "close_ticket"],
  "success_criteria": [
    "解释工单当前状态",
    "找出延迟原因",
    "列出证据来源",
    "给出下一步建议",
    "标注需要人工确认的动作"
  ]
}

如果关键实体缺失，Intent Normalizer 不应该让 Agent 猜。它应该生成澄清决策：

{
  "decision": "ask_clarification",
  "question": "请提供客户 ID、工单号，或相关投诉链接。",
  "missing_fields": ["ticket_id", "customer_id"]
}

注意：最终 Task Contract 应该由 Runtime 生成和校验，而不是完全相信模型输出。模型负责理解，工具负责查证，Policy 负责裁决，Runtime 负责把它们合并成后续组件都能消费的结构化契约。

任务契约的价值是把模糊请求变成可执行边界：

• Planner 知道要规划什么；
• Context Builder 知道要找什么证据；
• Tool Registry 知道暴露哪些工具；
• Policy Engine 知道哪些动作有风险；
• Verifier 知道如何判断完成；
• Review Surface 知道如何向用户交付。

没有任务契约，Agent Loop 很容易变成“模型想做什么就做什么”。

13.4.3 Task Planner：计划是可验证的假设

Planner 的职责不是写一段漂亮的推理过程，而是把 Task Contract 转成 Runtime 可以执行、Policy 可以裁决、Verifier 可以验证、Review Surface 可以解释的计划。

Task Planner 通常也是模型、Runtime、工具、Policy 和 Verifier 协作完成的：

Task Contract
  -> Runtime 选择 Planner 模式
  -> Skill 声明任务需要哪些事实
  -> Tool Registry 声明工具能提供哪些事实
  -> Runtime 计算 Fact Gap
  -> Policy 过滤不可用或高风险工具
  -> 模型生成候选计划
  -> Runtime 校验计划 Schema、预算和依赖
  -> Verifier 为每一步绑定完成标准
  -> 输出 Executable Plan

Planner 的输入不是用户原话，而是上一节生成的任务契约，再叠加当前状态、能力地图和预算约束：

一个常见误区是让模型直接从工具列表里“挑工具”。更稳的做法是先把任务转成事实缺口。

例如任务契约是：

{
  "intent": "diagnose_ticket_delay",
  "entities": {
    "ticket_id": "TCK-1024"
  },
  "success_criteria": [
    "解释工单当前状态",
    "找出延迟原因",
    "列出证据来源",
    "给出下一步建议"
  ]
}

对应 Skill 可以声明这类任务需要的事实：

{
  "skill": "diagnose_ticket_delay",
  "required_facts": [
    "ticket.status",
    "ticket.history",
    "sla.policy",
    "issue.blocker"
  ],
  "verification": [
    "每个延迟原因必须有证据来源",
    "如果缺少工单号，必须先澄清"
  ]
}

如果当前只知道 ticket_id，Planner 会得到 Fact Gap：

{
  "known_facts": ["ticket_id"],
  "missing_facts": [
    "ticket.status",
    "ticket.history",
    "sla.policy",
    "issue.blocker"
  ]
}

Tool Registry 不是只有工具名，还要声明工具能提供哪些事实：

[
  {
    "tool": "get_ticket",
    "provides": ["ticket.status", "ticket.history", "ticket.updated_at"],
    "requires": ["ticket_id"],
    "risk_level": "low",
    "side_effect": false
  },
  {
    "tool": "get_sla_policy",
    "provides": ["sla.policy"],
    "requires": ["ticket_id"],
    "risk_level": "low",
    "side_effect": false
  },
  {
    "tool": "search_linked_issues",
    "provides": ["issue.blocker", "issue.status"],
    "requires": ["ticket_id"],
    "risk_level": "low",
    "side_effect": false
  }
]

于是 Planner 的中间推理对象不是“我想调用哪个工具”，而是：

{
  "missing_facts": [
    "ticket.status",
    "ticket.history",
    "sla.policy",
    "issue.blocker"
  ],
  "candidate_tools": [
    {
      "tool": "get_ticket",
      "covers": ["ticket.status", "ticket.history"]
    },
    {
      "tool": "get_sla_policy",
      "covers": ["sla.policy"]
    },
    {
      "tool": "search_linked_issues",
      "covers": ["issue.blocker", "issue.status"]
    }
  ]
}

Policy 再对候选工具和动作做裁决：

{
  "get_ticket": "allow",
  "get_sla_policy": "allow",
  "search_linked_issues": "allow",
  "notify_customer": "ask",
  "close_ticket": "ask",
  "read_customer_private_note": "deny"
}

这样生成的计划就不是工具冲动，而是围绕事实缺口组织出来的可执行计划：

{
  "plan_id": "plan_001",
  "mode": "investigative",
  "budget": {
    "max_steps": 6,
    "max_tool_calls": 8,
    "max_minutes": 3
  },
  "steps": [
    {
      "id": "s1",
      "goal": "获取工单状态和处理历史",
      "required_facts": ["ticket.status", "ticket.history"],
      "tool": "get_ticket",
      "args": {
        "ticket_id": "TCK-1024"
      },
      "risk": "low",
      "policy": "allow",
      "verification": "必须返回 ticket.status、ticket.history 和 updated_at"
    },
    {
      "id": "s2",
      "goal": "获取适用 SLA 规则",
      "required_facts": ["sla.policy"],
      "tool": "get_sla_policy",
      "args": {
        "ticket_id": "TCK-1024"
      },
      "risk": "low",
      "policy": "allow",
      "verification": "必须返回适用 SLA 条款或明确无匹配规则"
    },
    {
      "id": "s3",
      "goal": "检查工程侧阻塞",
      "required_facts": ["issue.blocker", "issue.status"],
      "tool": "search_linked_issues",
      "args": {
        "ticket_id": "TCK-1024"
      },
      "risk": "low",
      "policy": "allow",
      "verification": "必须返回关联 issue 状态，或明确没有关联 issue"
    },
    {
      "id": "s4",
      "goal": "形成延迟原因和下一步建议",
      "required_facts": [
        "ticket.status",
        "ticket.history",
        "sla.policy",
        "issue.blocker"
      ],
      "tool": null,
      "risk": "medium",
      "policy": "no_side_effect",
      "verification": "每个原因必须引用前面步骤的证据；建议必须区分可直接建议和需审批动作"
    }
  ],
  "stop_conditions": [
    "工单不存在",
    "用户无权限读取工单",
    "关键事实缺失且无法通过工具补齐",
    "证据不足以支持结论"
  ]
}

这里各组件的分工很清楚：

一个好的计划应该包含：

• 目标：这一步要解决什么问题；
• 输入：需要哪些上下文或工具结果；
• 动作：要调用什么能力；
• 风险：是否可能越权、写入、通知、执行；
• 验证：如何判断这一步成功；
• 停止条件：什么时候不再继续探索。

flowchart LR
    Goal["Task Goal<br/>任务目标"]
    Decompose["Decompose<br/>拆解步骤"]
    Order["Order<br/>依赖排序"]
    Budget["Budget<br/>步数 / 时间 / 成本"]
    Risk["Risk Tagging<br/>风险标注"]
    Stop["Stop Criteria<br/>停止条件"]
    Plan["Executable Plan<br/>可执行计划"]

    Goal --> Decompose --> Order --> Budget --> Risk --> Stop --> Plan

计划可以分三种粒度：

计划不要追求一次性完美。生产 Agent 中，计划更像一个可修订的假设：

Plan -> Act -> Observe -> Replan -> Verify

例如 get_ticket 返回工单不存在时，Planner 不应该继续查 SLA，而应该重规划：

{
  "replan_reason": "ticket_not_found",
  "next_action": "ask_clarification",
  "question": "没有找到 TCK-1024，请确认工单号是否正确。"
}

关键是每次修订都要留下 trace：为什么改计划、基于什么观察、风险等级是否变化。

Task Planner 的价值，不是让模型写一份漂亮计划，而是把任务拆成 Runtime 能执行、Policy 能裁决、Verifier 能验证、Review Surface 能解释的步骤。

13.4.4 Context Builder：上下文是信息架构，不是拼 Prompt

Context Builder 是 Agent 系统最容易被低估的一层。它决定模型能看到什么，也决定模型看不到什么。

flowchart TD
    Task["Task Contract"]
    Sources["Source Catalog<br/>知识库 / 数据库 / 日志 / 工单 / 规则 / 历史案例"]
    Route["Source Router<br/>选择来源"]
    Retrieve["Retrieve<br/>检索与查询"]
    Filter["Permission Filter<br/>权限过滤"]
    Rank["Rank / Deduplicate<br/>排序与去重"]
    Compress["Compress<br/>摘要与压缩"]
    Cite["Citation Builder<br/>引用与证据编号"]
    Package["Context Package<br/>上下文包"]

    Task --> Route
    Sources --> Route
    Route --> Retrieve --> Filter --> Rank --> Compress --> Cite --> Package

Context Builder 至少要处理六类信息：

推荐把上下文组织成结构化 Context Package：

{
  "task": {
    "intent": "answer_policy_question",
    "success_criteria": ["回答问题", "引用来源", "标注不确定性"]
  },
  "sources": [
    {
      "id": "doc_001",
      "type": "policy_doc",
      "title": "费用报销制度",
      "updated_at": "2026-04-18",
      "permission": "allowed",
      "excerpt": "差旅住宿费用需要在行程结束后 30 天内提交。",
      "citation": "DOC-001#p3"
    }
  ],
  "constraints": {
    "answer_must_cite_sources": true,
    "cannot_reveal_restricted_content": true,
    "ask_when_evidence_conflicts": true
  },
  "state": {
    "previous_tool_calls": [],
    "open_questions": ["用户所在地区是否有特殊报销标准"]
  }
}

Context Builder 的核心原则：

1. 先权限，后检索结果注入：用户无权访问的内容不应该进入模型上下文。
2. 先证据，后结论：让模型围绕证据推理，而不是凭记忆回答。
3. 保留来源和时间：引用、更新时间、owner、置信度都应进入上下文。
4. 区分观察、事实和推断：工具结果经过身份、版本与完整性校验后才成为可用事实，模型总结仍需证据支持。
5. 控制预算：上下文越多不一定越好，噪声会让模型更难判断。

还要注意，Context Builder 不是 Memory 系统本身。Context 是本轮模型调用的工作区，Memory 是跨轮次、跨会话、跨任务保存的外部状态。Context Builder 可以读取 Memory，并把经过筛选、授权、压缩后的记忆放入本轮上下文，但不能把所有历史对话一股脑塞给模型。

第 19 章会展开 Agent 知识系统中的 RAG、Agentic RAG、MCP Resource 和 Web Search，第 20 章会专门展开 Memory 的读取、写入、遗忘、污染防控和评估。

13.4.5 Memory Layer：跨会话状态、经验与长期上下文

Memory Layer 是现代 Agent Runtime 的关键组件。它解决的不是“把聊天记录存起来”，而是让 Agent 在合适的边界内拥有连续性、经验和可治理的长期上下文。

Memory 至少要和三个概念区分开：

一个生产级 Memory 系统通常会包含几类记忆：

Memory 读取要经过路由和过滤：

flowchart LR
    Task["Task Contract"]
    Router["Memory Router"]
    Store["Memory Store"]
    Filter["Scope / Permission / Freshness Filter"]
    Rank["Rank<br/>相关性 / 新鲜度 / 重要性"]
    Pack["Context Package"]

    Task --> Router --> Store --> Filter --> Rank --> Pack

Memory 写入更要谨慎。生产 Agent 不应该默认把所有对话、模型猜测和工具结果写进长期记忆。推荐增加 Memory Write Gate：

candidate memory
-> evidence check
-> sensitivity check
-> scope decision
-> owner review when needed
-> ttl / expiration
-> write or reject

可以写入 Memory 的内容通常包括：

• 用户稳定偏好；
• 已验证的任务摘要；
• 人工确认过的复盘结论；
• 可复用的失败案例；
• 服务或团队级注意事项；
• 进入 Skill、Policy、Eval 的候选经验。

不应该直接写入 Memory 的内容包括：

• 未验证的模型推断；
• 本轮临时指令；
• 过期业务状态；
• 敏感数据原文；
• 用户无权长期保存的数据；
• 高风险处置建议的草稿。

Memory 的核心原则是：可读、可控、可忘、可审计、可评估。如果没有写入门控、权限边界和遗忘机制，Memory 会从“让 Agent 更懂你”变成“让错误长期污染系统”。

13.4.6 Execution State 与 Checkpoint：引用权威状态

Execution State 回答一次任务已做什么，Memory 提供跨任务可复用信息。LangGraph 的 checkpointer 与 store 也分别面向 thread 状态与跨 thread 数据；内存 Saver 重启会丢失，不能用“配置了 checkpoint”代替耐久性验证。[5]

本章只保留职责接口：Context Package 引用 run_id、step_id、状态版本、证据和未决 operation_id；Planner 消费状态并提出下一步；持久 Runtime 校验和提交状态变化。第11章是 Run/Step/Event、Operation、Outbox、Checkpoint、取消和恢复语义的唯一责任章，第21章把这些原语组合成任务图和角色交接。

不要根据摘要或 Trace 宣告一个外部写动作成功。超时但结果未知时，保留未决 Operation 并进入查询或对账；恢复时重新检查当前权限、状态版本与既有执行身份。观察历史和重新执行必须分开，回放不自动重放副作用。

13.4.7 Capability Registry：Skills、Tools、Connectors 与 MCP

MCP 2025-06-18 定义了 host/client/server、tools/resources/prompts 与能力协商，同时说明协议本身不能强制执行全部安全原则。[6]

很多系统会把 Skill、Tool、Connector、Workflow、MCP Server 混在一起，导致权限边界混乱。现代 Agent Runtime 更适合用 Capability Registry 统一管理“系统能提供哪些能力”，再按任务、身份、环境和风险筛选本轮可见能力。

推荐的区分是：

它们的关系如下：

flowchart TD
    Task["Task Contract"]
    Capability["Capability Registry<br/>Skills / Tools / Connectors / MCP / Workflows"]
    SkillRegistry["Skill Registry<br/>选择任务方法"]
    Skill["Selected Skill<br/>步骤、注意事项、验证要求"]
    ToolRegistry["Tool Registry<br/>选择可用工具"]
    Connector["Connector / MCP Client<br/>连接外部系统"]
    Tool["Tool Runtime<br/>执行工具"]
    Policy["Policy Engine<br/>裁决工具调用"]
    Observation["Observation<br/>结构化结果"]

    Task --> Capability
    Capability --> SkillRegistry
    Capability --> ToolRegistry
    Task --> SkillRegistry --> Skill
    Task --> ToolRegistry
    Skill --> ToolRegistry
    ToolRegistry --> Policy --> Connector --> Tool --> Observation

Skill Registry

Anthropic 的 Agent Skills 将指令、脚本与资源组织为可按需加载的文件夹。脚本仍可能执行动作，因此本书区分“加载方法”与“获准执行”。[7]

Skill Registry 管的是“做事方法”。一个 Skill 应该描述：

name: incident_initial_diagnosis
version: 1.3.0
when_to_use:
  - 出现服务异常、告警、SLA 下降或用户投诉
inputs:
  - alert
  - service
  - time_window
steps:
  - 确认影响范围
  - 查询最近变更
  - 对比关键指标
  - 搜索相关日志
  - 生成带证据的诊断结论
guardrails:
  - 不得直接执行恢复动作
  - 不得隐藏不确定性
verification:
  - 结论必须包含证据 ID
  - 建议必须标注风险等级
owner: sre-platform

Skill 不应该拥有权限。它只是告诉 Agent “这类任务的可靠做法是什么”。真正的能力调用仍然要经过 Tool Registry 和 Policy Engine。

Tool Registry

Tool Registry 管的是“系统能做什么”。一个 Tool 至少要有：

• 名称和描述；
• 输入 Schema；
• 输出 Schema；
• 风险等级；
• 权限要求；
• 是否有副作用；
• 是否支持 dry-run；
• 连接器或执行后端；
• owner 和审计字段；
• 版本、灰度状态和废弃策略。

{
  "name": "create_support_ticket",
  "description": "创建一条客户支持工单",
  "input_schema": {
    "type": "object",
    "required": ["customer_id", "title", "priority"],
    "properties": {
      "customer_id": {"type": "string"},
      "title": {"type": "string"},
      "priority": {"type": "string", "enum": ["low", "medium", "high"]}
    }
  },
  "risk_level": "medium",
  "side_effect": true,
  "requires_approval": true,
  "supports_dry_run": true,
  "owner": "support-platform"
}

Capability Registry 还应该支持按需暴露。模型不应该看到完整能力列表，而只能看到本轮经过筛选后的能力子集：

all capabilities
-> task filter
-> permission filter
-> risk filter
-> environment filter
-> budget filter
-> visible skills / tools / connectors

这也是 MCP、连接器和插件体系必须被治理的原因。MCP 可以标准化外部系统接入，但它不是安全边界本身。一个 MCP Server 暴露的资源、工具和 Prompt，都要经过 Capability Registry、Policy Engine、Trace 和 Review Surface 才能进入生产 Agent。

第 18 章会深入展开 Tool Calling、Skills 与 MCP。第 13 章只需要建立一个关键边界：Skill 包装流程知识及可选脚本，Tool 是可调用能力，Connector 是连接方式，Policy 是执行裁决。

13.4.8 Policy Engine 与 Human Control Plane：权限、审批、接管与降级

“请不要执行危险操作”不是安全机制，只是提示词愿望。生产 Agent 必须有独立于模型的 Policy Engine。

Policy Engine 的输入不是一句自然语言，而是一组可裁决对象：

{
  "user": {
    "id": "u_123",
    "role": "support_lead",
    "department": "customer_success"
  },
  "task": {
    "intent": "notify_customer",
    "risk_level": "medium"
  },
  "tool_call": {
    "name": "send_customer_email",
    "args": {
      "customer_id": "C-8801",
      "template": "delay_explanation"
    },
    "side_effect": true
  },
  "context": {
    "environment": "production",
    "confidence": "medium",
    "evidence_count": 2
  }
}

Policy Engine 的输出应该是结构化决策：

{
  "decision": "ask",
  "reason": "向客户发送通知属于有副作用动作，需要人工确认",
  "required_approver_role": "support_lead",
  "allowed_in_dry_run": true,
  "audit_tags": ["customer_communication", "side_effect"]
}

核心决策类型可以是五种：

Policy Engine 不只看工具名，还要看上下文：

flowchart TD
    ToolCall["Tool Call"]
    User["User / Role"]
    Task["Task Contract"]
    Env["Environment"]
    Risk["Risk Metadata"]
    State["Task State"]
    Policy["Policy Engine"]
    Decision["allow / deny / ask / sandbox / audit"]

    ToolCall --> Policy
    User --> Policy
    Task --> Policy
    Env --> Policy
    Risk --> Policy
    State --> Policy
    Policy --> Decision

例如“发送通知”在内部测试环境可能是低风险，在生产客户环境就是中高风险；“读取文档”对公开制度是低风险，对客户隐私文档就是高风险。

Policy Engine 解决“能不能做”，Human Control Plane 解决“人如何介入”。生产 Agent 不能只有自动化路径，还必须有清晰的人工控制点：

Human Control Plane 不等于“所有事情都弹确认”。真正好的设计是按风险分层：低风险只读任务自动完成，中风险动作要求确认，高风险生产动作进入审批，极高风险任务直接拒绝或转人工。这样既不牺牲效率，也不会把生产责任交给模型。

13.4.9 Agent Loop：观察、决策、行动、修复

Agent Loop 是模型、状态、上下文、工具和策略之间的执行闭环。

stateDiagram-v2
    [*] --> Observe
    Observe --> Decide: context ready
    Decide --> Act: tool call proposed
    Decide --> Finalize: answer ready
    Act --> PolicyCheck
    PolicyCheck --> Execute: allow
    PolicyCheck --> HumanApproval: ask
    PolicyCheck --> Repair: deny or invalid
    HumanApproval --> Execute: approved
    HumanApproval --> Repair: rejected
    Execute --> Observe: observation
    Observe --> Repair: missing or conflicting evidence
    Repair --> Decide: revise plan
    Finalize --> Verify
    Verify --> Finalize: needs revision
    Verify --> [*]: passed

一个生产级 Loop 至少要有这些机制：

• 最大步数：防止无限循环；
• 时间预算：防止长任务拖垮系统；
• Token 预算：控制成本和上下文长度；
• 工具预算：限制昂贵查询和高风险动作；
• 状态持久化：任务中断后可以恢复；
• 错误分类：区分工具失败、权限失败、模型格式错误、证据不足；
• 修复策略：格式错误可重试，证据不足可补检索，权限不足要询问或拒绝；
• 停止条件：达到成功标准、风险过高、预算耗尽、用户取消。

伪代码可以这样理解：

while not done:
    context = build_context(task, state)
    model_output = llm(context, available_skills, available_tools)
    action = parse_and_validate(model_output)

    if action.type == "final_answer":
        verification = verifier.check(action.answer, task, evidence)
        if verification.passed:
            return review_surface.render(action.answer, trace)
        state.add_feedback(verification.errors)
        continue

    decision = policy.check(action.tool_call, task, user, state)
    if decision == "deny":
        state.add_observation("policy_denied", decision.reason)
        continue
    if decision == "ask":
        approval = request_human_approval(decision)
        if not approval.approved:
            state.add_observation("approval_rejected", approval.reason)
            continue

    observation = tool_runtime.execute(action.tool_call)
    state.add_observation(observation)

这段伪代码背后的原则是：模型可以提出行动，但不能绕过解析、校验、策略裁决和验证。ReAct（Reasoning and Acting）可以看作 Agent Loop 的一种典型实现：模型在“推理、行动、观察、修正”之间循环。但生产级 Runtime 不能只依赖这个循环本身，还必须把 Policy、Trace、Verifier 和 Checkpoint 放进闭环，保证每次行动都可裁决、可审计、可恢复。

在更完整的 Runtime 里，Agent Loop 每一轮都应该写入 checkpoint。这样当任务进入审批、等待外部系统、工具超时或人工接管时，系统可以从最近的稳定状态恢复。Loop 不是“模型一直想”，而是“Runtime 按状态推进，模型在必要位置提供推理和选择”。

13.4.10 Model Router 与 Handoff Manager：模型选择、专家委派与多 Agent 协作

现代 Agent 系统通常不会只依赖一个模型、一个 Prompt、一个通用 Agent。不同任务对模型能力、成本、延迟、上下文长度、工具调用能力和安全要求都不一样。Model Router 与 Handoff Manager 负责把任务交给合适的模型、专家 Agent 或外部 Agent 系统。

Model Router 关注“用哪个模型”：