书籍介绍

欢迎阅读《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/>ALR 主线 / 产品专题"]
    D --> E["第五部分：前沿与研究<br/>Research Agent / 多模态 / 具身"]

本书解决什么问题

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

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

全书默认案例：ALR 告警诊断

除非章节需要讲解告警场景无法承载的领域机制，本书默认复用同一次虚构的 ALR 告警诊断运行：alert_id=ALR-20260429-017、run_id=run_0429_017、trace_label=trace_20260429_017，OpenTelemetry trace_id 示例为 4bf92f3577b34da6a3ce929d0e0e4736。对象是 prod 环境的 order-service，观察窗口为 2026-04-29 10:35–10:50（Asia/Shanghai），即 02:35Z–02:50Z。

10:35 完成的 deploy_8842 与 10:37 出现的异常只有时间先后关系；E12 记录的 P95 从 210ms 升到 2.1s 也只是待核验的指标候选，二者都不能直接写成根因。Runbook v1 已退役，v2 是早期部署说明，v3 是新部署的候选说明；当前适用版本由部署映射和 owner 核验，不按更新时间选择。典型质量失败是检索到不适用的旧 Runbook，把相似症状误写成数据库根因，且验证没有拦住。

这次运行的产物包括诊断报告、绑定报告草稿与资源版本的审批、跟进工单 INC-4821，以及独立记录的通知状态。若远端已经建单但本地回执丢失，恢复流程沿原 Operation 查询核验，不重新建单。Agent 只能做只读调查，并在有效审批后创建跟进工单；它没有重启、回滚或支付写入能力。

Coding Agent、企业知识助手、真实开源项目分析、训练故障、具身系统和研究 Agent 等案例只在确有教学必要时保留。它们首次出现时会说明偏离 ALR 的原因、适用范围，以及输入、证据、动作、状态和验收如何与 ALR 对照；这些局部案例不构成另一套全书标准。

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

• 模型边界：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 完成一项可交付、可验证、可治理的真实工作”。

| 第23章 | DeepSeek Super-agent：面向自主协作的事件驱动架构 | 分析事件驱动、多任务调度、授权与执行边界。 | | 第24章 | DeepSeek Harness：一切皆插件的智能体运行时 | 分析插件化运行时、会话、工具、安全边界与扩展生态。 |

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

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

附录

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

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

全书包含五部分、23 个公开章节。ALR 告警诊断是默认贯穿案例；其他案例只在领域对象无法由 ALR 替代或必须核验真实产品机制时局部使用：

章节包含原理推导、文档核验、教学轨迹与实验设计，验收层次分别标明。模型基础、后训练、模型适配、训练平台与推理服务的练习卡可从附录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章 模型结构：一次前向计算的能力边界

语言模型可以解释退款政策、生成补丁，也可以输出一段结构化参数。这些能力都从一次前向计算开始：字符串被编码成 token，经过若干层的注意力与逐位置前馈网络，最后投影成下一个 token 的分布。本章先拆开这次前向计算，再回答两个相连的问题：模型的候选能力从哪里来，结构在哪些环节设定了边界？

本章以 ALR 告警诊断说明应用级失败定位；退款短语和代码片段只作为 token、张量与生成边界的局部特殊输入，因为这些算法机制需要短而可人工核对的序列。它们仅适用于本章对应小节：输入序列对应 ALR 的告警输入，键值材料对应 Evidence，输出检查对应诊断报告验收，不继承 ALR 的业务身份或动作权限。所有示例均为教学假设，不代表某个企业系统的实际实现，也不把某个模型家族的配置当作行业通用配置。

本次修订于 2026-10-31 重新访问章末 26 项原始来源，核对元数据与相关论点；结构机制另查论文正文和中文教材对应段落。本文的手算、资源估计和故障诊断是教学推导，不是模型或硬件实测。

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

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

把序列概率写成条件概率的连乘，还能澄清“预测下一个词为何能做复杂任务”的疑问。训练目标不要求模型先识别一个显式任务编号，而是让它在给定前缀时提高真实后续的概率。若语料中包含解释、程序、对话和推导，某些预测必须利用这些文本所表达的约束。不过，从目标形式只能说明这些约束可能有助于预测，不能直接推出训练一定学到可靠算法。一个模型可以通过表面共现降低平均损失，也可以学到更可迁移的关系；两者在普通样本上的输出可能接近，在反事实和组合条件下才分开。这里是从目标定义作出的分析，不是对某个模型内部表征的实测结论。

例如教学语料同时出现“完成退款后返回流水号”和“退款请求被拒绝时没有成功流水号”。如果评估只问常见的成功路径，模型靠高频续写就可能答对；若输入增加“审批尚未完成”，任务要求它识别状态边界，而不只是拼接常见字段。序列目标没有另设一个“事务已经提交”的真值位，系统必须提供状态证据，并在输出之后验证业务条件。语言预测与业务状态之间的这段距离，是后续 Agent 工程需要补齐的边界，不能靠给向量赋予拟人化名字消除。

训练损失通常把许多位置的负对数条件概率汇总。对一条长度为四的教学监督序列，若四个真实标签的条件概率分别是假设的二分之一、四分之一、二分之一、四分之一，那么损失由各自负对数相加或取平均得到。两个不同预测错误都可能使平均损失下降：模型在大量容易位置上变好，同时在一个罕见否定条件上变差。业务关心的是后一个位置，却可能被总体均值掩盖。因此读训练曲线时，要把统计目标和任务验收分开。后文用具体证据条件定位失败，正是因为单个标量不足以解释全部生成行为。

从前向依赖看，训练并行的含义也很具体。设一个教学前缀含四个位置，第一层所有位置的投影可以一起算，第二层仍要等第一层的表示准备好。并行化的是同层不同位置的计算，不是让所有层失去先后依赖。注意力让一个位置在一层内读取可见的远处表示，但经过多层组合才能形成更复杂的条件计算。把“一层能连到远处”说成“一层已理解完整上下文”，混淆了可达路径和学到的函数。图中的每条边表示信息能够流动；这条路径是否被训练成有用能力，还需要任务证据。

统一符号与两种长度

全章以批量优先的语义形状表达张量；实际框架可能转置、融合或分片。\(B\) 是批量大小，\(T\) 是当前查询长度，\(S\) 是键值长度，\(D\) 是残差流宽度，\(H_q\) 与 \(H_{kv}\) 分别是查询头和键值头数，\(d_h\) 是每头 Q/K 维度，\(d_v\) 是每头 V 维度。\(L\) 为层数，\(V_{\mathrm{vocab}}\) 表示输出词表投影行数，避免与 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{vocab}}\times D}\)，按 ID 查表得到 \(X\in\mathbb{R}^{B\times T\times D}\)。这里没有按汉字直接索引的保证：一个汉字、一个英文词、一个空格与代码片段可能对应不同数量的 token。文字看起来相同，也应先确认实际 token ID、特殊符号和聊天模板是否一致。

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

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.3 节公式。最终 Norm 是常见现代布局，原始 Transformer 的归一化位置不同。图是形状契约，不是某个框架的逐算子执行图。

隐藏状态、logits 与标签

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

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

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

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

从输入契约追踪到输出分布

为使形状不只是符号，下面固定一组独立教学假设：两条样本、每条最多四个输入位置、残差宽度八、两个查询头、每头四维、词表投影共有十六行。第一条样本的有效长度为四，第二条为三，第四格用补齐符占位。输入 ID 数组包含八个整数，但有效输入只有七个位置。Embedding 查表返回六十四个数，其中补齐位置也可能有数值；“它有向量”不等于“它应参与监督”。有效性属于额外的语义契约，不能靠向量是否全零判断。

表中的元素数来自教学维度的乘法，不是硬件测量。它揭示了两类不同错误：一种是维度不兼容，框架通常立即报错；另一种是元素数兼容而语义错位，例如把头轴当位置轴、把补齐位置当最后一个有效位置。这类错误可能持续输出流畅文本，甚至仍使损失下降。形状检查必须附带轴的解释，不能只打印一个尺寸列表就宣布实现正确。

下一步把标签与输入逐格对齐。假设一条完整教学序列是开始符、告警、来自、服务、结束符；模型输入前四项，监督目标是后四项。输入第三格的隐藏状态可以看到“开始符、告警、来自”，目标是“服务”。若在训练框架内部已经执行错位，数据准备阶段就不应再次错位。接口契约不同会导致两种正确代码拼起来变成错误系统，因此应保留一条实际进入损失函数的输入与标签对照，而不是仅检查数据文件看起来合理。

损失屏蔽与注意力屏蔽还需要分别记录。前者决定哪些位置对梯度目标贡献，后者决定哪些键可供查询读取。假设指令微调只监督回答部分，提示文本仍应被回答读取；把提示的损失置零，不意味着把提示从注意力中移除。反过来，补齐位置不应贡献监督，也通常不应被有效查询读到。两个掩码恰好使用相同长度，并不意味着语义可以合并。这个区别对理解后训练尤其重要，后续训练章会沿同一契约继续展开。

词表投影还提供了另一种读模型的方法。每个词表项对应输出矩阵中的一个方向，隐藏状态与这些方向相乘产生分数。共享输入输出权重时，查表和输出比较使用关联的参数；不共享时，两张表可以独立学习。两种配置的张量都能正常运行，但参数数目、检查点键和训练约束不同。转换模型时仅凭“都有同样的词表大小”就合并两张表，会改变模型函数。结构阅读应该把“尺寸相同”“参数同一对象”“数值目前相同”作为三个不同事实。

从 logits 到最终文本，中间还有选择规则。贪心选择取最大分数项，随机采样按分布抽取；温度改变分数的相对尺度，截断候选集合则改变采样支持集。这些操作属于生成过程，不会在一次请求内自动更新模型参数。若同样的前缀得到不同文本，先固定采样配置与随机条件，再比较前向分数；否则无法区分模型计算差异和选择差异。讨论“稳定回答”时，也要说明稳定的是分数、候选排序还是最终字符串。

以两个候选近似并列的教学情形为例，极小的浮点误差可能交换第一名与第二名，贪心生成随后进入不同前缀，后续文字便可能明显分叉。这不意味着每个算子的误差都很大，而是离散选择把连续差异转成了路径差异。检验数值实现时应比较相同前缀上的 logits 和中间状态；评估服务时才进一步统计最终任务结果。将这两个比较层混在一起，会把允许的数值差异误判为结构错误，也可能漏掉确实影响任务的微小排序变化。

最后，输入文本不是天然等于模型看到的序列。角色标记、系统说明、工具返回、分隔符和终止标记共同构成真实前缀；模板可能添加额外 token。可复现输入应记录序列化后的内容与有效长度，在合适权限范围内保存必要证据。对含敏感信息的应用，可以保存受控样本或脱敏复现材料，但不能用脱敏后语义已改变的输入声称复现了原事故。书稿中的短语仅用于手算，实际工程则要建立从用户请求到最终 token 序列的可追溯转换关系。

1.2 Attention 与 Q/K/V 的计算

flowchart LR
 X["当前层表示"] --> Q["查询"]
 X --> K["键"]
 X --> V["值"]
 Q --> S["匹配分数"]
 K --> S
 M["因果与有效性约束"] --> S
 S --> A["沿键轴归一化"]
 A --> Z["聚合内容"]
 V --> Z
 Z --> O["拼头并回到残差宽度"]

匹配空间与内容空间

对单层输入 \(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 再把第三个权重清零，却不重新归一化，前两项的和通常小于一，已经改变了数学定义。大匹配分数也不等于事实可信度，只说明当前参数表示下的匹配程度。

图中匹配与聚合分成两条路径，意味着“选择哪个来源”和“来源提供什么内容”可以使用不同特征。以下数值和扰动例子均为本书构造的教学推导，用于检验计算定义；它们不代表训练后某个头固定承担了某项人类可命名的职责。

设一个查询的维度为二，取向量为 \((\sqrt{2},0)\)，三个键依次为 \((0,1)\)、\((1,0)\)、\((2,0)\)。除以 \(\sqrt{2}\) 后，三个匹配分数依次为零、一、二。若第三个位置属于未来，允许集合只剩前两个；归一化权重分别约为零点二六九和零点七三一。再令三个值依次为 \((2,0)\)、\((0,4)\)、\((100,100)\)，输出约为 \((0.538,2.924)\)。第三个值故意设得很大，但正确结果与它无关：可见性先决定谁能参与，分数再在允许集合内决定比例。

这个例子同时给出三个可检验断言。只改变第三个值，较早查询的输出不变；只改变第一个键，输出会因匹配权重改变而变化；只改变第一个值，权重本身不变，但聚合结果变化。若某实现对这三种扰动都表现相同，很可能把键与值的职责混在了一起。它们比“结果看着差不多”更有诊断力，因为每次只改变一条因果路径。

对允许集合的每行分数同时加一个常数，softmax 不变。实现常利用这一性质先减去行最大值，再计算指数，减少溢出风险。注意这一变换的对象是同一查询的全部允许分数，不是给每个键随意加不同偏置。后者会改变相对权重，正是位置分数偏置等方法能够影响注意力的原因。数值稳定变换与模型结构变换在代码中都可能表现为一次加减，却有完全不同的语义。

softmax 的导数也解释了“饱和”的具体含义。若一行概率为 \(a_i\)，它对分数 \(s_j\) 的导数是 \(a_i(\delta_{ij}-a_j)\)。当某一项接近一，其他项接近零时，很多导数会变小；缩放减少初始化时点积过大导致过早进入这种区域的风险。这里不能倒推“所有尖锐注意力都是坏事”：经过训练后，有些任务确实需要集中读取一个位置。应区分不受控制的数值饱和和任务所需的选择性，而不是要求所有头都保持平均分配。

权重和为一还意味着，单头、单次聚合在值空间中是允许值向量的凸组合。因此本例的输出不会越过这些值构成的凸包。不过这个结论只属于这一局部运算：输出投影可以含正负权重，残差可以再加上原表示，FFN 可以做非线性变换，多层整体不受同一个凸包限制。由局部加权平均推断整个模型只能做平均，是把中间张量的性质错误推广到了复合函数。

同样，注意力分数高不必意味着某证据对答案贡献最大。假设一个头给某位置很高权重，但该位置的值向量经过输出投影后接近零，它对残差更新可能很小；另一个权重较低的位置却可能携带幅值更大的有效方向。再加上其他头与残差通路，单张热力图不能承担完整的因果解释。若要评估证据是否影响结果，可以设计受控删除、替换和位置迁移实验，并比较相同输出条件下的变化；这仍是行为证据，不能未经额外分析就命名内部神经元的真实职责。

缩放、聚合与多头输出

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

拼头前先交换头轴与位置轴，再检查 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 查询的优化实现也可以约定零输出，但必须与调用方契约和测试一致，不能悄悄把无效行当正常预测。

继续构造一个缓存教学例子：历史前缀有三个位置，当前一次计算两个新位置，合计五个键。当前第一行查询对应绝对位置三，可读键零到三；第二行查询对应绝对位置四，可读键零到四。允许关系分别有四个和五个位置。如果程序只根据当前块长度生成左上角三角形，第一行就只能读一个键，第二行只能读两个键，历史大部分信息会被错误隐藏。这个错误不会产生维度冲突，甚至可能在没有历史前缀的测试中完全消失。

表中的数字是从零开始的位置编号，不能与文本中的“第一个词”口语序号混用。位置 ID、缓存有效长度和掩码边界必须使用一致约定。若服务把前缀分成多个块计算，每个块都需要延续逻辑位置；块只是执行单位，不应悄悄重置模型看到的序列起点。

当两条样本长度不同时，掩码通常需要同时表达批次、查询和键的有效性。一个仅含长度维的掩码若被广播到整个批次，可能让较短样本读取补齐键；一个将样本维错误解释为头维的掩码，则可能只影响部分头。这些问题适合用“调换批次顺序后，逐样本结果应保持对应一致”来检验。该断言以关闭随机性、保持同一参数与精度为前提；真实低精度批处理可能有小数值差异，需要给出合理容差，但不应出现结构性的内容串扰。

训练时把多条短文本打包进一个长序列，可以减少补齐浪费，但是否允许跨文档读取必须由训练目标定义。若目标是独立样本，只有下三角因果掩码还不够，因为后一个样本仍可看见前一个样本。若目标明确把文档视作连续文本流，则边界规则又不同。工程上不应把某一种打包策略的假设偷偷写成通用注意力定义；数据构造、损失边界与可见性必须一起审查。

全屏蔽行应进入边界测试，同时检查返回约定和下游是否跳过无效查询；形状正确不能使无条件上下文变成有效预测。

1.3 Block 的稳定性与位置信息

flowchart TD
 X["残差流输入"] --> N1["按特征归一化"]
 N1 --> A["带位置关系的注意力"]
 A --> ADD1["相加"]
 X --> ADD1
 ADD1 --> N2["再次按特征归一化"]
 N2 --> F["逐位置非线性变换"]
 F --> ADD2["本层输出"]
 ADD1 --> ADD2
 P["逻辑位置规则"] --> A

残差与逐位置前馈

注意力让不同位置交换信息，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”，因为最终行为依赖多层联合计算。

图的两条旁路说明，残差流并不在每个子层后被从头替换。按本节公式，某层输出等于输入加两个学习到的更新；若更新暂时很小，信号仍有直通路径。这可以从导数上理解：简化为 \(y=x+f(x)\) 时，其雅可比为 \(I+J_f(x)\)，包含恒等项。这里的代数性质不等于深层训练已经稳定，因为多个层的雅可比仍会连乘，子层的尺度和方向也可能改变梯度。因此残差、归一化、初始化和学习率属于相互配合的设计，不能把其中任何一项单独当作“不会梯度异常”的保证。

残差还要求子层返回同一表示空间。假设教学宽度为八，注意力内部可以分成两个四维头，FFN 内部可以扩到二十四维，但两条分支相加前都必须回到八维。扩维不是为了让下一层的残差永久变宽，而是为子层提供更丰富的中间变换。若某实现省略输出投影，只有偶然相等的维度还能相加，参数化却已改变。理解“内部自由、外部契约固定”，有助于读懂不同模型为何能共享 Block 接口却拥有不同内部成本。

普通 FFN 与门控 FFN 的差别可用一个局部公式展示。令两条升维支路分别输出 \(a=xW_a\)、\(b=xW_b\)，门控形式可写作 \((\phi(a)\odot b)W_c\)。其中逐元素乘法让一个支路调节另一个支路，而不是仅把一条非线性向量投回去。若维持相同中间宽度，三矩阵结构比两矩阵结构多一组参数；若要比较同参数预算，就需要调整中间宽度。这个计算例子只说明参数与运算关系，不声称某种门控在所有训练条件下更优。

从张量依赖还能解释“逐位置”的准确含义。某个位置进入 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 结果不应改变。平移性质则用下面的数值例子说明。

现在用一组教学数值比较归一化。令向量为 \((1,3)\)，忽略稳定常数，取缩放参数为一、偏移为零；LayerNorm 的均值为二、方差为一，得到 \((-1,1)\)。RMSNorm 的均方根为 \(\sqrt{5}\)，得到 \((1/\sqrt{5},3/\sqrt{5})\)。再把两个特征同时加十，LayerNorm 仍得到相同结果，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]

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

位置机制则是在另一条维度上定义“相同内容出现在哪里”。考虑没有位置编码、没有因果掩码的自注意力：若同时置换输入位置，Q、K、V 按相同方式置换，输出也随之置换。这种置换等变性意味着结构不会凭空知道某个词是第一项还是最后一项。因果掩码会破坏任意置换对称，提供方向与不同可见集合，但仍不等于显式表达所有距离关系。顺序信息来自具体结构的共同作用，不能用一句“Attention 不知道顺序”覆盖所有带掩码实现。

RoPE 的二维旋转可以进一步手算。假设一对坐标的旋转角为位置乘某个频率，同一查询和键一起平移相同的位置偏移时，两者的相对旋转角保持。这个性质说明点积可通过相对位移变化，但它不意味着整段输入在任意平移后所有输出都必然一致：模型可能还有其他位置相关机制，掩码有效范围也可能变化，有限精度与训练分布都要考虑。使用 RoPE 的缓存还必须保持旋转约定一致，不能把已经旋转的键当作未旋转键再次处理。

举例说，一个历史键最初在逻辑位置五完成旋转并写入缓存。如果后续代码因物理页移动而把它当作位置零重算，缓存中的内容与查询使用的位置规则便不再匹配。这里错误来自把物理存储下标当成逻辑序列位置。分页、分块和缓存压缩可以改变存储方式，却必须保留计算所需的位置语义；这是结构与服务系统之间一个重要接口。反过来，若只是物理复制缓存而逻辑位置不变，就不应重新解释其位置身份。

位置外推还可以拆成不同失败模式。模型可能接受长索引，但远处键的匹配分数不再有训练时的分布；也可能成功找出一条远处事实，却无法同时结合多条相距很远的条件；还可能只是在更长输入下被干扰材料诱导。单次“藏一条事实再找出来”的演示只覆盖部分能力。教学评估应固定语义后改变距离、位置、干扰量和条件数量，观察错误随哪个变量变化，而不是只画窗口长度与一个总分的关系。

这里的取舍是明确的：更丰富的位置机制提供有用归纳偏好，同时增加配置与转换契约；更长窗口提供更多可见材料，同时增加计算、缓存和任务分布变化。能加载长序列属于运行能力，能引用正确证据属于检索与利用能力，能依据多个条件得出有效结论属于任务能力。三个层次需要分别验收，这也为下一节讨论架构与资源代价准备了判断坐标。

1.4 架构变体与资源代价

flowchart TD
 A["任务目标与可见性"] --> B["编码器或因果生成或编解码"]
 B --> C["注意力缓存表示"]
 C --> D["独立多头"]
 C --> E["共享或分组键值"]
 C --> F["联合潜在压缩"]
 B --> G["前馈参数布局"]
 G --> H["稠密网络"]
 G --> I["稀疏专家路由"]
 D --> J["分别核算质量与资源"]
 E --> J
 F --> J
 H --> J
 I --> J

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

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]

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

这里没有按结构给模型质量排永久名次。论文中的比较来自具体训练和实验，不能把“缓存小”直接推出“准确率高”。

还可以从一个小型分组例子看出共享的边界。假设四个查询头分为两组，前两个查询使用第一组 K/V，后两个使用第二组 K/V。即使组内键值完全相同，不同查询向量仍会产生不同匹配分数，因而输出不必相同。共享的是被读取的表示，不是查询条件，也不是最后的聚合结果。若误把组内查询先平均再计算，就把多个独立读取问题合成了一个问题，与 GQA 的定义不同。

MLA 的压缩则可以用线性代数辨认。假设内容键由低维潜变量 \(c\) 经过上投影 \(W\) 得到，则查询与内容键的点积为 \(q^{\mathsf T}Wc=(W^{\mathsf T}q)^{\mathsf T}c\)。这说明在适当条件下，可以把部分变换移到查询侧，在潜变量空间完成匹配。这个等式只讨论内容支路；加入随位置变化的旋转后，矩阵是否能被这样吸收需要重新检查，不能把位置算子任意交换顺序。这正是阅读解耦位置设计时需要关心的结构问题，而不只是比较一个压缩率数字。

Dense、MoE 与算子的不同取舍

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

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

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

对 MoE 也应先问路由发生在哪里。一个 token 在某层被送到哪个专家，与下一层的路由可以不同；同一个句子中的不同 token 也未必走相同专家。假设某批次的大部分 token 恰好选择同一设备上的专家，平均激活参数仍然很少，但该设备可能成为关键路径。因而条件计算的算术节省与分布式执行的负载平衡是两个相连而不同的问题。评估应保留每层专家负载与通信分布，不能只看全模型平均激活参数。

路由结果还必须说明组合规则。若教学路由概率为零点六、零点三、零点一，选择前两个专家后，可以按原权重组合，也可以在选中集合内重新归一化为三分之二和三分之一；两者输出尺度不同，复现时必须遵守训练时定义。Switch 的单专家选择仍保留门控系数，并非选择后无条件以单位权重输出。[20]

容量约束限制的是每批送入专家的 token 数。按 Switch 的静态容量定义，假设八个 token、四个专家、容量因子为一，每个专家有两个槽位；若四个 token 都选同一专家，其中两个可能溢出。该论文实现让溢出 token 跳过这一专家计算，经残差继续传递，不是删除文本位置。扩大容量缓解溢出，却增加空槽与资源成本。[20]

训练和推理都可能受容量限制，但负载不同：训练通常有更多位置可共同分配，逐步解码的小批次更容易出现不均；训练还可用辅助损失影响未来路由，推理不执行这个参数更新。由此推导，不能把训练平均负载直接作为服务上限。动态容量、拒绝溢出或改送其他专家属于不同执行选择，必须核对与已训练模型的计算契约，而不能把改路由当作纯调度优化。

讨论结构取舍时，至少区分总参数量、每 token 激活参数量和常驻权重显存。下面按一个 Decoder-only Pre-Norm Block 记账，假设 \(d_h=d_v\)、线性层不含 bias，且 FFN 是普通的两投影结构；Embedding、最终 Norm 和词表输出层位于单层 Block 之外。

若线性层带 bias，需要逐项加上输出维度；若使用带 bias 的 LayerNorm，两个 Norm 共计 \(4D\)；若使用 SwiGLU 等三投影门控 FFN，FFN 主项变为 \(3DD_{ff}\)。以 \(D=2048,H_q=16,H_{kv}=4,d_h=128\) 为例，注意力四个投影共 \(10{,}485{,}760\) 个参数，其中 \(W_O\) 占 \(4{,}194{,}304\)，不能从账本中省略。Embedding 表按 \(V_{\mathrm{vocab}}\times D\) 计，输出表是否与它共享权重需要查看具体配置。稀疏专家结构还要分别记录全部专家参数和每 token 激活参数；把这些口径合成一个“模型大小”，会系统性扭曲显存与成本估算。复算时还应记录权重共享、bias、FFN、Norm 和参数口径，并保留复算过程；只给最终总数，无法定位两个实现为何不同。这份记录也是后续显存预算与检查点审查的输入。

仅以 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.5 训练与推理的资源差异

flowchart LR
 W["共同模型权重"] --> T["训练全序列"]
 W --> P["提示预填充"]
 W --> D["逐步解码"]
 T --> G["激活与梯度及优化器状态"]
 P --> K["建立历史键值缓存"]
 K --> D
 D --> R["读取历史并追加当前状态"]
 R --> D

同一个结构在训练和生成时对应不同的资源账本。前四节已经定义训练并行、prefill、decode 与 KV 缓存的计算路径；这里把它们放到同一张表中比较，避免把训练显存、单步延迟和缓存载荷混成一个数字。

训练侧还要为反向传播保存中间激活，并维护梯度与优化器状态；第 5 章给出完整训练账本，第 9 章展开训练平台实现。推理侧的批处理会引入 padding 与长度差异，连续批处理、缓存分页和服务并行由第 10 章展开。第 8 章先给出两类基础设施的总体边界。本章只要求读者从配置中识别 \(T\)、\(S\)、层数、精度和 KV 头数，并在相同口径下比较资源。

把参数、激活与缓存放进同一份账本

以下资源估计统一采用教学假设，不作为设备选型或吞吐承诺。先设模型含 \(N\) 个权重，每个权重实际存储占 \(s_w\) 字节，那么未分片的权重载荷为 \(Ns_w\)。若权重被量化，缩放因子、零点、分组元数据与对齐填充需要另外计算；若只改变权重类型，KV 缓存和中间激活未必一起改变。模型文件大小、加载后的常驻显存与峰值运行显存因此通常不能互换。

训练还要维护梯度、优化器状态以及反向传播需要的中间量。为了说明口径，假设某实现为每个参数保留二字节计算权重、二字节梯度、四字节主权重副本，以及两个各四字节的优化器状态，则这几项合计每参数十六字节。这个十六来自明确的假设相加，不是所有训练框架的固定比例；若没有主副本、梯度采用其他类型，或状态被分片与卸载，账本就要重算。更关键的是，它仍没包含激活、临时工作区和通信缓冲。

激活与参数有不同的增长规律。固定模型宽度和层数时，批量与序列长度增加会扩大很多中间张量；固定批量与序列时，增加参数通常改变权重和部分激活，却不是所有项都按同一比例变化。训练的激活保存策略还决定反向时是直接读取还是重新计算。重计算可以减少保存量，同时增加计算与调度负担；只有把省下的内存与多做的工作放在同一账本里，才能判断它是否解决当前限制。

对长度不同的推理请求，更准确的载荷估计应把 \(BS\) 改成各条活跃请求长度之和。在其他层配置相同、采用标准等宽缓存的假设下，载荷为 \(2LH_{kv}d_hs\sum_b S_b\)。若某实现按最大长度预分配，实际占用可能更接近批量乘最大长度；若按块分配，还要考虑尾块浪费和元数据。两种实现服务同一批请求，语义载荷可以相同，物理占用却不同。区分这两层，才能评价分页是否有效，而不把布局优化误认为模型结构变小。

用一组可复算的教学配置说明缓存增长：层数三十二，键值头数八，每头一百二十八维，每元素二字节。每新增一个 token，每条请求需要缓存的 K/V 载荷为 \(2\times32\times8\times128\times2=131072\) 字节，即一百二十八 KiB。单请求历史长度为八千一百九十二时，载荷恰为一 GiB；四条相同长度请求为四 GiB。这里只计算缓存，不含权重与工作区，也不声称某真实模型正好采用该配置。

如果把教学配置的 KV 头数从八改为二，标准缓存载荷减为原来的四分之一；但若增加四倍并发，缓存总载荷又回到原先水平。结构优化释放的空间往往被更多请求或更长上下文消耗，所以“缓存节省”应报告固定了并发还是固定了长度。对用户体验而言，也要记录排队时间与生成速度，不能用更大的批量吞吐掩盖单请求等待变长。

从算术量解释 prefill 与 decode 的不同瓶颈

在普通等宽多头假设下，一层注意力的 QK 与 AV 两次矩阵乘法合计约需 \(4BHTSd_h\) 次浮点运算，这里把一次乘加记为两次运算，忽略 softmax、掩码与非矩阵操作。自注意力整段计算时，查询长度和键长度一起增长；增量解码时，当前查询长度常为一，键长度却随着历史继续增长。这个算式用于比较增长方向，具体算子可能跳过因果遮蔽区域，不能将它不加修正地当作设备实测计数。

投影与 FFN 则有另一种尺度。一个输入宽度 \(D\)、输出宽度 \(F\) 的线性层，对 \(BT\) 个位置做计算，主要乘加项约为 \(2BTDF\)。当序列较短而宽度较大时，这些线性变换可能占据主要算术工作；当序列继续变长，位置两两关系的项会更显著。说“注意力是二次复杂度”提供了重要方向，却不足以说明任何长度下哪个算子最慢。需要把实际配置代入，再结合硬件读取与计算能力分析。

prefill 的多个查询能够共同使用权重和键值块，形成较大的矩阵运算；单请求 decode 每步只增加少量查询，但仍要读取大量模型权重与历史缓存。因此后者可能更受数据搬运限制。将多条请求组成批次可以提高权重利用程度，却同时扩大缓存与调度约束。这里的“可能”具有具体含义：瓶颈取决于批量、上下文、模型宽度、算子实现和硬件，不能把两个阶段永久归类为唯一一种瓶颈。

一个简化的延迟下界可以写成计算量除以有效计算速率、搬运字节数除以有效带宽两者的较大值，再考虑无法重叠的开销。它是帮助辨认限制的粗略模型，不是精确性能预测；通信、启动、排队、同步与分配都可能让实际时间更长。若观察到低算力利用率，也不能立即推断“GPU 没有工作”，它可能正在等待内存或通信。只有把相关字节量和依赖链一起看，低利用率指标才有解释意义。

FlashAttention 的分块思想可以用一行 softmax 的累计量理解。对一部分键计算行最大值、指数和与加权值和，再并入下一块时，用新的最大值重标定旧累计量，从而维持与整行归一化一致的数学结果。这样可以避免把整张分数或概率矩阵反复写入高带宽内存。这里给出的是对精确注意力重排的教学解释，实际内核还要处理并行、反向、精度和硬件限制；其主要原则已有原论文依据。[21]

这一重排没有减少模型定义中允许读取的键，也没有把稠密注意力自动改成稀疏模式。若应用需要输出完整注意力权重矩阵，仍然要为该输出支付相应存储与传输成本。反之，若只需要聚合后的向量，数学定义中的大中间对象未必需要永久物化。讨论算法内存时，应该明确需要保留哪些输出、哪些对象只是推导中的中间量，避免用一个公式形状否定实现能够节省内存的可能。

用前缀等价性约束缓存优化

KV 缓存能够复用的根本原因，是在因果模型中，固定前缀位置的隐藏表示不依赖后续新 token。在参数、位置、掩码和数值计算约定相同时，历史位置的键值可以保留，下一步只计算新位置，再读取历史状态。它节省了重复计算前缀，却没有让模型忘记历史长度对当前注意力的影响；每一步仍需要按所选结构使用那些历史状态。

这个论证也给出了失效条件。若修改了前缀中的一个 token，受其影响的后续历史表示就可能全部变化，不能只改对应缓存槽位后继续。若切换模型权重、适配器、位置缩放规则或聊天模板，即使显示文本相似，也不能未经证明复用旧缓存。缓存键应描述实际计算身份；只有模型名称或用户文本摘要通常不足以表达所有依赖。具体服务实现由推理基础设施章节展开，本章先要求能从前向函数推出这些条件。

实现验证可以固定一条前缀，比较一次整段前向与分步缓存前向在对应位置的 logits。再加入分块长度变化、左补齐与右补齐、不同有效长度以及请求重排，观察差异是否在合理数值容差内。若只有带前缀时出错，优先检查绝对位置偏移；若只有请求交换时出错，优先检查缓存归属；若只有 GQA 配置出错，优先检查头分组；若误差随序列渐进放大，则还要区分累计数值误差与重复旋转等结构错误。

因此一个资源优化应同时交付两种证据：固定语义输入下的计算等价性，以及固定负载口径下的资源变化。只有前者，说明没有明显破坏结果但尚未证明收益；只有后者，可能是删掉了计算或截断了上下文换来的虚假加速。本章的账本与等价性断言共同定义优化边界，使后续平台章节能够在正确的函数上讨论更高吞吐。

1.6 能力边界与失败定位

flowchart TD
 A["冻结输入与版本"] --> B{"证据到达上下文"}
 B -->|否| C["检查召回过滤与截断"]
 B -->|是| D{"计算契约一致"}
 D -->|否| E["检查掩码位置与缓存"]
 D -->|是| F{"结论得到证据支持"}
 F -->|否| G["构造反事实评估与行为修复"]
 F -->|是| H["检查格式和执行状态"]

从训练目标到可验证的能力

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

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

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

表格不是一条必须全部自建的流水线，阶段划分的作用是避免把每种失败都送回训练：知识过期先查来源，格式截断先查输出契约，确定需要改变模型行为时再研究训练。

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

从错误告警诊断走到可修复证据

以全书默认的 ALR-20260429-017 为例，Agent 把相似症状误写成“数据库连接池耗尽”。先核对 E12 指标候选是否来自约定窗口；再查 Runbook v1/v2/v3 的版本、部署映射与 owner；接着确认适用条件是否进入最终上下文；最后检查模型是否把候选线索错误升级成根因。这里任一环节失败，都可能产生同一句错误诊断。

若适用 Runbook 没进入上下文，优先修召回、过滤或装配；若候选状态清楚在场而判断仍越界，可构造“不得把时间邻近和单一指标写成根因”的模型回归用例。修复后分别复测这些条件，而不是仅凭新模型在一条演示上答对就关闭事故。稳定的回归单元应绑定输入、版本、证据和断言，后续评估与反馈闭环再定义 Eval Case。

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

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

为了让这一诊断闭环可以真正被执行，下面继续使用假设告警构造一个受控复现。输入声称错误率升高，证据 E12 只说明某个窗口内连接数变化；Runbook v2 对旧部署适用，v3 对当前部署适用，且当前材料尚未确认连接池耗尽。预期输出应把“候选原因”和“已验证原因”分开，给出下一步需要的证据，而不是直接宣告根因。这个验收条件来自案例的事实状态，不来自模型说话是否自信。

先比较实际送入模型的材料与检索结果。如果检索列表中有 v3，但最终上下文只有 v2，故障发生在装配或预算裁剪；如果最终上下文包含 v3，却丢掉了限定部署的那一行，单纯统计文档命中仍会误判召回成功。可复现证据需要精确到模型看到的片段与版本，而不能只记录一个文档标题。此时换更强模型可能偶然猜对，但没有修复输入条件；正确修复应恢复适用材料，并用同样的裁剪条件复测。

再保持最终上下文完全不变，只把问题从“根因是什么”改为“哪些结论已经被证据直接支持”。若模型能正确列出证据，却在原问题中越界，说明读取能力与结论控制需要分开评估。这个干预不是自动证明后训练有缺陷，而是缩小假设范围：至少材料已到达，且模型在某个提问条件下能够使用它。下一步可加入格式契约和反事实样本，验证模型是否在证据不足时稳定保留不确定状态。

反事实样本不应只是把服务名换掉。可以保持症状相同而替换适用版本，保持版本相同而撤掉关键指标，或明确给出排除连接池问题的观测。若模型无论怎样改变证据都输出同一根因，它可能过度依赖提示中的高频模式；若只有否定条件变化时失败，则应单独建立否定与例外切片。这样的错误分类比“十条题答对九条”更能指导修复，因为它指出了失败依赖哪种条件。

输出契约还应把计算结果与执行结果分开。一段合法 JSON 可以表达错误根因，一段正确建议也不证明工具已经执行；反过来，模型输出被最大长度截断，不能据此判断其没有学会字段含义。诊断时保留原始输出、停止原因和解析错误，把语义判断放在完整候选上评估，把格式与截断放在生成接口上评估。否则格式修复可能掩盖事实错误，或把服务预算问题错误送回训练团队。

这些干预都要避免一次改变太多变量。例如升级模型时顺手换模板、扩大窗口、改变采样并接入新检索器，最终答对只能说明整套系统有所改变，无法解释是哪项修复起作用。工程上可以分阶段比较，在每个阶段保留同一组关键断言；若为了应急必须整体切换，也应把因果归属标为尚未拆分，之后再补回归分析。明确未知比给一个听起来完整但没有证据的内部机制解释更可靠。

最后，关闭问题的条件应与原故障相对应。装配问题需要证明适用条款确实进入最终上下文；缓存问题需要通过前缀等价性与隔离断言；证据越界需要在有支持、缺支持、含反证三类样本上保持正确状态。一次生成了满意答案不足以覆盖这些条件。本书在这里建立的是“可观察输入—受控变化—对应断言”的诊断方法，后续评估章节再把它扩展成持续运行的用例集与发布门槛。

用局部不变量验收实现

状态：练习设计完成；独立实现未提供，未实测。 采用教学输入 \(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后置、未先转置就拼头、全屏蔽行产生伪分布，都应有能稳定触发的非对称输入。只让全零输入通过或最终形状正确，不算完成计算验证；运行结果、环境和断言输出需要单独保存，不能由本卡的存在推断已运行。

状态：练习设计完成；独立实现未提供，未实测。 设 \(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不属于本练习的等价替换：它要定义不同的缓存状态与对照路径。没有完成这些实现和运行记录前，两张卡均只标设计，不能上调为手写能力或硬件实测。

本章小结

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

预训练形成基础能力，后训练塑造行为，推理期策略组织候选与验证；三者都建立在结构之上，也都受训练分布与输入证据的限制。结构决定一种计算方式，训练决定它学到什么，推理期策略决定本次请求怎样花算力。下一章回到预训练的数据、目标与规模，沿这条因果链继续展开。

参考资料

1. Bengio et al.，A Neural Probabilistic Language Model，2003 / JMLR 3。核验日期：2026-10-31。
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。
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。核验日期：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。

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

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

本章的判断是：基础能力不是参数规模单独带来的属性，而是训练目标、数据分布、Tokenizer、模型规模、算力预算和评估证据共同塑造的结果。预训练让模型学习广泛而稳定的模式，却不直接提供时效事实、可靠引用或可控行为；第 3 章将继续讨论后训练如何塑造默认行为。

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

2.1 预测目标如何形成能力：从概率拟合到可迁移表示

flowchart LR
    A[来源文本与采样分布] --> B[前缀和真实下一词元]
    B --> C[共享参数预测分布]
    C --> D[有效位置交叉熵]
    D --> E[梯度更新表示与变换]
    E --> C
    C --> F[新上下文下的条件预测]
    F --> G[独立任务检验]
    G -.不能由训练损失替代.-> D

图中最重要的反馈是损失作用于共享参数，而不是只修改某条句子的概率表。一次更新会同时影响以后许多输入的表示，因此模型既可能把规律迁移到没有见过的句子，也可能把数据中的偏差带到新场景。独立任务检验位于训练反馈之外，提醒我们：被优化的是一个可计算的预测目标，最终要求的却可能是正确解释、稳定组合或符合约束的行动。这两个目标有联系，但不是同一个函数。

从词概率到分布式表示

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

Transformer 的改变不是简单地“换了一个网络层”。循环模型的时间依赖限制了训练吞吐；自注意力允许每个位置直接与其他位置建立关系，使长距离依赖路径从多步递归缩短为一步矩阵运算。对标准多头自注意力，点积与加权聚合的计算量为 \(O(BHT^2d_h)\)；当 \(Hd_h=D\) 时可写成 \(O(BT^2D)\)。普通实现若物化每个头的分数或概率矩阵，其存储量是 \(O(BHT^2)\)，不能把这两个口径写成同一个复杂度。第 1 章 1.5 节介绍的 FlashAttention 通过分块减少高带宽内存读写，并避免在高带宽内存中保存完整分数矩阵，但精确注意力的二次算术项仍然存在。因此，长上下文训练同时受计算、激活和系统实现约束。

预训练成为主范式

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、后训练、检索和工具把它适配到任务”。不过，上下文学习并不等于模型真正掌握了任务规则；它可能依赖示例格式、表面相关性或训练语料记忆，必须通过独立评估和分布外测试确认泛化。

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

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 的损失；多轮对话中的角色标记能降低特定格式的损失。模型不需要被显式告知“这是一条规则”，只要规则在数据分布中足够稳定，就可能被压缩到参数中。

熵、交叉熵与分布逼近。

以下均用自然对数，单位为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一次。这里讨论的是分类形式如何组成语言模型目标，通用分类的完整损失选型不在本章扩写。

交叉熵梯度为何适合词元预测。

以下用二分类说明，不另扩一套分类教材。令预测概率 \(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 随机遮挡输入中的部分 token，让模型利用左右文恢复缺失内容，能获得较强的双向理解表示 [6]。Encoder-decoder 结构把输入和输出分开建模，在翻译、摘要等条件生成任务上具有清晰的结构优势 [7]。

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

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

训练目标与能力之间的联系，可以通过一个贯穿本章的教学场景来具体理解。设一个已有通用基础模型需要适应企业公开授权的技术文档，文档包含产品术语、版本说明、接口例子和故障分析。这里不假设已有实测收益，也不把企业数据天然视为高质量。如果同一个术语在不同文档中承担相近功能，模型降低后续词元损失的一种有效方式，是让有关上下文的隐藏表示包含这种功能关系。当接口名字变化而调用结构相似时，共享参数可以复用结构；当错误码含义因版本变化时，模型还必须利用版本上下文，才有可能预测正确说明。训练不显式要求“建立接口知识库”，却会奖励有助于预测的内部计算。

但是，存在一种同样能降低损失的捷径：记住常见例子的后半段。如果训练集大量复制同一份接口教程，模型可能只需识别开头就复现整个代码块，对新的参数组合却不敏感。两条路径都能让训练损失下降。单看目标值无法知道模型究竟形成了可组合的规则，还是学会了强关联模板。为区分二者，我们可以在独立评估中替换变量名、改变合法参数组合、加入不满足前置条件的调用，并要求解释错误原因。这些实验是本书从目标函数推出的诊断设计，不是宣称语言模型内部一定存在某种人类可读规则。

教师强制进一步解释了训练表现与自由生成的差距。在预测技术说明的第十个词元时，训练输入通常包含文档中真实的前九个词元。模型即使在上一个位置分配错了最大概率，也不会因此改变当前输入前缀。生成时则不同：模型已经输出的错误版本号会成为后续上下文，它可能在错误前提上继续给出非常连贯的接口说明。于是，局部条件预测变好并不自动保证完整回答正确。这不是自回归分解本身有问题，而是评估完整轨迹时需要计入模型自己造成的前缀变化。第4章的采样、搜索和验证正是在这个缺口上增加决策机制。

还应区分“目标相同”与“学习问题相同”。对一段原始接口文档预测每个词元，对一个带角色标记的回答只预测助手位置，形式上都可以使用交叉熵，但经验分布和受监督位置不同。前者会花预算学习目录、代码注释和描述顺序，后者把梯度集中到给定用户请求之后的响应。即使两批样本含有相同事实，更新方向也可能不同。把任务全部写成文本有助于统一接口，却不会抹去任务分布、上下文结构和监督权重的差别。

从公式看，训练真正逼近的是经过处理和采样后的分布，而不是一个抽象的“全人类知识分布”。若同一接口存在两个版本，而样本没有版本标记，模型在相同可见前缀下看到两个不同续写，正确的概率拟合可能就是给两种答案都分配概率。我们不能要求损失函数凭空辨认当前用户使用的是哪一版。增加模型容量也不能补回输入中缺失的判别信息。此时应当补充版本条件、提供检索证据或要求用户说明环境，不能仅凭回答不确定就认定预训练不足。

有效监督的归一化也会改变这种学习问题。假设一个教学批次只有一份很短的发布说明和一份很长的接口手册，两份文档平均每词元的损失不同。按文档分别求平均再取均值，两份文档拥有相同权重；将所有有效词元的负对数概率相加后除以总词元数，长手册拥有更大权重。两种口径都可以定义合理目标，但它们回答的是不同问题。前者更接近平均文档表现，后者更接近平均词元表现。若训练使用后一种而仪表盘显示前一种，曲线不一致未必是实现错误；若团队不知道二者不同，则很容易把数据长度分布变化误判为优化进步。

对单个样本，概率模型给正确续写较低概率会付出较大损失，但这个惩罚没有业务严重度的概念。把“可以”误写为“不可以”，和把常见标点预测错，在词元层面都只是某个目标类别的负对数概率。前者可能改变操作含义，后者可能几乎不影响任务。我们可以在后续阶段加入有针对性的样本和评价，却不应倒过来声称预训练平均损失已经自动表达了业务风险。正文中的“学会”因此总要绑定一个可观察能力：是减少困惑度、提高类型识别率，还是在陌生版本上正确处理接口约束。

这一点也关系到所谓能力突然出现。若一项任务只有整段答案完全正确才计一分，而较小模型已经能正确完成其中大部分步骤，连续的局部进步可能在越过评分阈值后表现为分数跳变。关于表观涌现的研究说明，指标选择本身可能制造这种现象；它不证明所有规模相关转折都不存在。[12] 因此在技术文档任务中，除了最终成功率，还应观察参数解释、前置条件识别、错误定位等连续或分项指标。这样才知道需要补哪一种学习信号，而不是把所有变化归结为无法操作的“智能涌现”。

2.2 数据分布如何被制造：清洗、去重与预算配比

flowchart LR
    A[授权来源与原始记录] --> B[正文抽取和格式保留]
    B --> C[分层过滤与误删审查]
    C --> D[重复簇及代表选择]
    D --> E[语言领域质量分桶]
    E --> F[预算与曝光次数]
    F --> G[训练分布]
    C -.保留删除原因.-> H[版本与谱系记录]
    D -.保留簇关系.-> H
    F -.保留采样策略.-> H

数据管线的基本分层

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

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

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

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

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

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

去重改变的不只是文件大小。

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

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

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

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

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

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

合成数据需要独立的质量证据。

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

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

加工链的每一次选择都能写成对分布的重新加权。令原始文档来自某个分布，抽取器决定哪些文字被保留，过滤器决定文档是否进入候选池，去重策略决定哪些副本代表一个簇，采样器再决定训练时看见多少次。最终影响梯度的是这些操作的组合。即使原始抓取源完全相同，两个团队也可能训练出分布明显不同的模型。所谓“使用同一个网页数据集”若没有处理版本和采样定义，并不足以构成可复现条件。

继续使用技术文档场景：假设一份教程的正文只有少量文字，大部分有价值内容都在代码块、参数表和注意事项里。如果正文抽取器只保留连续自然语言段落，这份文档在过滤之前已经损失了关键语义。后续质量分类器看到的可能只是几个孤立标题，于是将其判为低质量。此时调低分类阈值只能保留残缺样本，真正需要修正的是抽取器。相反，如果抽取器保留网页侧栏和自动推荐，某些高频产品名可能被过度曝光。把全部问题归因于“清洗不够”会掩盖错误发生的阶段。

评估抽取器应对照原始结构与清洗结果，而不仅审查最终纯文本。参数表中的单位、代码缩进、否定词、脚注条件、标题层级都是可以改变意思的元素。一个适合新闻正文的抽取器可能不适合接口参考；一个把重复行全部删除的规则可能删掉合法的代码分支。这里的目标不是保留所有页面结构，而是确定哪些结构是任务相关证据。可以对不同文档类型分别建立小规模人工核验样本，观察语义保留率和无关内容残留，再决定是否需要不同的抽取路径。

过滤阈值也应接受条件化解释。一个质量评分器把“正式、完整、语法规范”当作高质量，可能适合长篇说明，却会低估真实故障日志和论坛问答。若未来用户经常粘贴残缺日志，训练中完全清除这类内容反而会扩大输入分布差距。C4文档化研究对过滤结果的不均衡影响提供了具体警示；FineWeb的过滤与去重消融也说明，处理规则应靠比较而不是直觉累加。[19] 本书据此建议同时记录保留样本和被删样本的分层审查结果，让“为什么删除”成为可以修订的判断。

可以把一次过滤实验设计成两种不同问题。若固定原始抓取量，比较过滤前后最终得到的训练数据，测到的是质量与可用规模共同变化的效果；若固定模型实际消费的有效词元数，并从两个候选池各自抽够预算，才更接近比较每次曝光的价值。后一种也有前提：被保留池必须足够大，不能因为数据不足而偷偷多轮重复。若新管线过滤更强，固定曝光预算时重复次数上升，应将这一变化显式报告，否则模型表现变化无法只归因于质量改善。

去重的簇代表选择同样会产生方向性偏差。对于接口文档，最早版本可能信息不全，最新版本可能删除了旧接口，正文最长的副本又可能混入网站模板。随意保留第一个抓到的文档，会让抓取顺序成为隐藏的训练权重。可以根据版本字段、正文完整性和来源可信度选择代表；确实需要保留多个版本时，则给出清晰版本条件并把它们视为有关联的不同样本，而不是因为相似度高就全删。去重簇是组织证据的工具，不是“语义相同”的自动判决。

再考虑曝光次数。设某领域去重后有一份大小为U的词元池，总训练预算为N，目标采样比例为w，在均匀抽样的教学近似下，平均曝光轮数约为wN/U。这条算术关系说明，一个看起来很小的领域比例也可能让稀少文档重复很多次。反过来，大规模通用池即使占主要预算，其中大部分文档也可能只出现一次。团队因此不能仅看配比饼图，而应同时看每个桶的独立数据量、平均曝光和高频尾部。Muennighoff等人研究了数据受限时重复使用数据的收益递减；其结果支持区分独立数据和重复曝光，不能给出所有项目通用的重复轮数上限。[20]

有意重采样与意外副本的区别在于是否掌握权重。假设一份关键错误处理说明只出现一次，但任务要求模型可靠理解它，可以有意识地提高对应类型样本的曝光，并在独立例子上观察效果。若该说明被几十个镜像站重复转载，采样器却把它们当成几十份独立证据，同样的权重增长就不可解释。去重之后再明确重采样，通常比依赖网页副本数来决定重要性更容易分析。这里不是反对重复，而是要求重复成为受控变量。

配比调整还要面对代理模型迁移的问题。DoReMi使用较小代理模型优化数据混合，再把权重用于更大模型，展示了用实验选择配比的路径。[21] 但不同容量、词表和训练阶段对领域数据的边际收益可能不同。某个桶损失高，可能因为它含有有价值但难学的规律，也可能因为乱码、随机字符串或严重抽取错误；简单提高所有高损失桶权重，会把优化预算投向不可预测噪声。因此先检查数据语义，再用对照实验评价配比，不应把“难”直接当成“有价值”。

合成样本也应进入相同的谱系账本。由同一个模板替换实体生成的大量题目，在独立样本数意义上可能远少于文件条数。验证器只检查语法或代码能运行，也无法确保解答真的对应题目意图。更有用的生产记录包括原始题目来源、生成器版本、生成条件、验证方法、拒收原因以及与已有样本的关联。这样发现一批系统性错误时，可以沿生成批次撤回，而不是仅依赖模型训练后的表现猜测问题来自哪里。

2.3 从文本到有效监督：Tokenizer、边界与长上下文

flowchart TB
    A[文本及格式规范] --> B[固定词表与归一化]
    B --> C[文档词元序列]
    C --> D[先划分训练和验证来源]
    D --> E[集合内构造序列块]
    E --> F[注意力边界决定可读前缀]
    E --> G[损失掩码决定监督位置]
    F --> H[实际条件预测问题]
    G --> H
    H --> I[按有效监督数归一化]

Tokenization 的模型影响

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

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

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

先固定中文与代码的测量对象。

以下退款问句和代码只用于展示 Tokenizer 对中文、字母、数字、标点与缩进的处理。它们是固定输入的教学例子，用于说明测量对象，不代表已经完成分词实验。

BPE用高频子词组合缓解稀有词问题，SentencePiece提供从原始句子训练子词模型的方法；它们是算法与工具路线，具体词表仍由训练数据和配置确定。[22][23] 本书教学输入可以固定为“订单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 内允许跨文档读取，与训练、测试集合之间的污染是两个问题。前者取决于建模策略，后者取决于样本来源和划分是否隔离。管线应在 packing 前完成文档级切分，在评估时按文档、主题或去重簇隔离集合，再检查重复片段。验证集不能只是随机抽取训练网页的另一段，因为随机切分可能让高度相似内容同时出现在训练和评估中。

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

长上下文数据

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

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

图中的两个掩码不能互相代替。假设把文档甲和文档乙装入同一个序列块，甲是一段接口定义，乙是另一段无关说明。若希望乙完全独立，即使不对甲计算损失，乙仍可能通过注意力读到甲；必须在可见性上阻断这条边。相反，允许乙读取甲而仅监督乙，可以定义一种条件生成训练，但它不再等于两个独立文档分别训练。EOS只是一种内容标记，模型可能学会在它之后切换话题，却不负责实施访问控制。独立样本packing文档对边界元数据的强调，正是为了保留原样本的注意力语义；该官方文档主要面向SFT与PEFT，不能直接当成所有预训练框架的实现规范。[24]

更细的边界出现在标签移位。自回归训练常把一段序列左移作为输入、右移作为目标。如果两个独立样本直接相邻，甲末尾的位置可能被要求预测乙的第一个词元；若设计目标是独立文档，需要明确这个跨界目标是否屏蔽，乙开头是否有自己的起始标记。仅在注意力矩阵里画出两个三角块，还不能证明损失索引正确。类似地，重置位置编号会改变位置条件，延续位置编号则可能让短文档习惯出现在较大位置。二者都是训练定义的一部分，应与推理输入约定一致，而不是只为提高装箱率临时选择。

对训练吞吐，也至少有三种计数。设备处理的序列位置包括填充；有效文本词元排除了填充；有效监督词元还要扣除不参与损失的位置。为了说明差别，可以假设一个序列块有十个位置，其中两个是填充，另有两个合法输入位置仅提供上下文、不产生监督，那么这三个数分别是十、八、六。它们是教学假设，不是某个系统的效率测量。提高装箱率通常改善第二个数与第一个数的比例，但若监督规则同时变化，第三个数未必同比增加。训练预算、损失分母和吞吐报告应采用明确的对应关系。

Tokenizer又改变了这些计数的单位。假设两种词表对同一文档分别产生不同数量的词元，较少词元可能降低部分序列计算，却不能仅据此断言模型更准确。较大的词表增加输出类别，还可能让低频完整词缺少足够学习机会。比较困惑度时问题更加直接：每词元平均负对数似然的分母变了，两个数不再在同一测量单位上。若要以原始文本长度归一化，可以在完全相同的字节文本和规范化条件下比较总负对数似然除以字节数，但仍应说明分词方式定义了模型如何为该文本分配概率，不能把这个指标误写成与编码完全无关。

归一化也不是无害的文本美化。全角与半角、组合字符、换行和连续空格，在自然语言中有时可视为同义变体，在代码、标识符或数学表达式中却可能有意义。若预处理先把不同字符串折叠成相同形式，解码无法恢复被丢弃的信息。正确的round-trip要求应对照Tokenizer声明的规范化结果，而非笼统要求每个原始字节永远不变。对企业接口材料，版本号、大小写敏感参数和缩进代码应进入专项检查；只验证普通中文句子会漏掉高价值边界。

长上下文则同时改变信息范围与训练成本。把很多互不相关的短文装成一个长块，可以让设备处理更长位置，却不一定提供远距离依赖的学习信号。若所有预测只依赖附近句子，模型没有强烈理由利用遥远前缀。因此应把“序列很长”和“目标确实需要远处证据”分开。技术手册可以包含跨章节的类型定义和使用限制，教学检索样本则可以显式改变关键字段的位置；两者分别检验自然结构与受控位置依赖，不能相互替代。

Lost in the Middle在其多文档问答和键值检索实验中发现了信息位置对表现的影响，这提醒我们窗口长度不是有效使用能力的同义词。[25] 据此，本章案例应将同一接口约束放在开头、中间和结尾，同时改变干扰文档数量，观察是否仍能引用正确版本。若模型只在短上下文成功，下一步可以检查长序列训练分布与位置机制；若不同位置都能找到字段却误解适用条件，问题更可能在语义组合。这样才能避免把所有长文失败都归结为窗口不够大。

2.4 缩放规律与优化轨迹：把算力变成可检验的预算

flowchart LR
    A[能力与部署约束] --> B[多个参数规模候选]
    B --> C[固定计算的训练长度]
    C --> D[匹配长度的优化计划]
    D --> E[小规模训练与保留点]
    E --> F[拟合及外推误差]
    F --> G{证据是否支持放大}
    G -->|支持| H[大规模预算与中间检查]
    G -->|不足| B
    H --> I[训练与推理总成本]

经验规律与工程意义

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

为避免与模型结构的隐藏宽度 \(D\) 冲突，本节用 \(P\) 表示参数量，\(N_{tok}\) 表示训练 token 数，\(C_{train}\) 表示训练计算。Kaplan 等分别拟合了模型规模、数据规模和计算规模与损失的幂律关系，并讨论固定计算预算下的配置；其具体表达和拟合区间不能与后续工作互换。[26] Hoffmann 等在 Chinchilla 研究中采用参数量与 token 数的联合形式，可概括为：

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

这个联合式属于 Chinchilla 的参数化口径，用于描述给定架构族与数据配方中的经验趋势。[27] 对普通 Dense 训练，可在特定计数口径下用 \(C_{train}\approx6PN_{tok}\) 作粗估；长序列 Attention、重计算、不同算子和稀疏激活都会使实际账本偏离。参数与 token 在固定计算下相互约束，不能把 Kaplan 与 Chinchilla 的拟合系数、指数或最优比例混用。

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

Chinchilla 与 compute-optimal

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

计算最优只回答给定训练计算下怎样降低目标验证分布的损失，不自动优化模型上线后的总成本。若同一模型要服务大量请求，参数量会长期影响权重显存、带宽、延迟和每 token 推理成本；工程上可能接受更长的训练，用较小模型处理未来的大量推理需求。反过来，推理量很小或训练窗口受限时，训练成本可能占主导。这里给出决策变量，不声称存在跨模型、跨硬件通用的比例；第 5 章 5.1 节将用明确假设计算参数、token、训练计算和推理需求之间的账本。

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

需要区分三种“规模”：总参数、激活参数和训练 token。MoE 模型可以拥有更大的总容量而只激活部分参数，但路由和通信有额外代价；密集模型每个 token 都使用全部参数，算力结构简单但激活成本高。第 8 章给出 Infra 总览，第 9 章展开训练平台，第 10 章展开推理系统；本章保留的判断原则是，训练规模必须和目标能力、数据质量、推理预算一起设计。

平均损失与能力曲线必须同时观察。

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

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

Batch、学习率与训练预算

在 token 级训练中，global batch size 决定一次更新看到多少 token。增大 batch 可以提高硬件利用率并降低梯度噪声，但可能需要调整学习率、warmup 和正则化；batch 太大也可能减少参数更新次数，使模型在固定 token 预算下的优化轨迹改变。中文教材对小批量梯度估计的分析有助于理解噪声与效率的权衡，但具体学习率规则仍需按训练条件验证。[28]

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

优化器和数据顺序共同决定轨迹。

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

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

中间评估使故障归因成为可能。

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

故障归因需要可重放。至少要保存 tokenizer 版本、数据 manifest、采样权重、随机种子、优化器状态、学习率状态、代码版本、配置和评估版本。Checkpoint 只保存模型权重而没有 optimizer state，通常无法严格恢复训练；只保存最后一个 checkpoint，则无法比较退化发生的时间点。第 5 章定义恢复训练所需的状态契约，第 9 章展开训练平台如何保存和恢复这些状态。

联合缩放式的价值不在于记住某个推荐比例，而在于能够明确推导预算之间的替代关系。令参数与词元的经验损失项分别为aP的负α次方和bN的负β次方，并以C约等于6PN约束计算。将N替换为C除以6P，损失就变为一个关于P的函数：增大参数会降低容量相关项，却因为训练长度缩短而提高另一项。在系数为正且适用范围不变的条件下，对这个函数求导，最优点满足两项的边际变化相抵。这是把经验模型用于决策的数学步骤，不是新的模型训练测量。

具体地，在本节符号约定下，本书由联合式得到：

\[ \alpha aP^{-\alpha}=\beta bN_{tok}^{-\beta},\qquad P_\propto C_{train}^{\beta/(\alpha+\beta)},\quad N_{tok,}\propto C_{train}^{\alpha/(\alpha+\beta)}. \]

如果两个指数接近，最优参数和词元数随计算增长的速度也接近；如果指数、系数或数据条件改变，比例就跟着变化。因此“固定每参数多少词元”只是某些拟合条件下的近似，不是所有模型的训练终点。Hoffmann等人的联合拟合和计算约束提供了这个推导的原始模型；这里省略其具体拟合系数，避免将一套历史实验参数直接代入新的中文技术语料。[27]

还要分清最优问题的边界。训练计算最优是在固定训练预算下比较最终损失；数据受限最优还要约束可获得的独立样本；部署最优则会考虑模型一生被调用多少次。假设两个候选达到相近的目标任务表现，较小模型需要更长预训练，但每次生成更便宜。当未来调用量足够大时，额外训练成本可能被推理节省抵消。可以把生命周期成本写成训练成本加预期调用次数乘平均调用成本，再把显存、延迟和可靠性作为约束。这是本书工程推导，平均调用成本仍需按真实输入长度、输出长度、批量和后端测量，不能仅按参数比换算。

例如，若企业文档服务要求单设备部署，某个大模型即使在训练计算上更合算，也可能因常驻权重与运行时缓存放不下而不满足方案边界。相反，调用量很小的离线任务未必值得用大量额外预训练换取一点推理成本下降。预算选择因此应先排除不满足部署约束的候选，再比较可行集合里的能力与总成本。缩放曲线帮助缩小搜索空间，但不会代替需求定义。

拟合本身也会误导。若所有小实验都沿用为长训练设计的学习率衰减计划，短训练在停止时可能仍处于高学习率区间；将这样的中间损失当成“短预算能达到的最佳损失”，会低估短训练方案。Chinchilla研究明确讨论了训练长度与学习率计划匹配对估计的影响。[27] 因而实验表中应记录目标训练长度和衰减终点，不能把某次长训练的所有中间checkpoint都无条件当作独立的预算最优样本。

一个可操作的教学设计是先选若干规模和若干计算档位，在每档保持词表、数据管线和评估文本一致，分别配置相应训练长度。拟合时留出一部分运行作为检验点，观察预测误差是否随规模系统性扩大。若只挑拟合最好看的曲线展示，就无法发现外推失效。若更换数据配方、上下文长度或模型族，应至少增加桥接实验，不能把新条件下的结果放进旧曲线就宣布规律不变。桥接实验的成本也是规模规划的一部分。

优化轨迹的另一个隐藏轴是更新次数。固定有效词元总量时，扩大每次更新的全局batch会减少更新步数。即使学习率按某个经验规则调整，也不能保证路径等价，因为动量状态、梯度噪声和数据顺序都变化了。小批量梯度均值的方差在独立抽样假设下随样本数增加而下降，中文教材给出了这一基础分析；长序列中的词元彼此相关，不能把词元数直接当成同样多的独立样本。[28] 这也是为什么“每秒处理更多词元”应和“每单位计算取得更多能力进步”分开报告。

从计算量到墙钟时长，还需经过设备利用率和非训练开销。理论FLOPs描述算术工作，实际作业还会经历数据等待、通信、检查点保存、验证和故障恢复；重计算可能节约显存却增加工作量。若用理论峰值除总FLOPs直接给出交付日期，就隐含假设所有时间都在高效执行目标算子。较可靠的估算应以短时间稳定运行的有效吞吐为基础，再为实际验证和保存频率计入开销。没有测量时可给情景区间，但应明确是假设，不能伪装成平台性能。

最后，扩大预算的依据应是尚未被其他瓶颈挡住的边际收益。如果目标领域损失仍下降，而独立任务不动，可能是新数据只改进了格式预测；如果通用能力下降，可能是配比或阶段过长；如果各切片都波动，先检查数值与数据状态。只有在这些替代解释被合理排查后，增加参数或词元才是有证据的下一步。这样使用缩放规律，才能把昂贵训练从一次押注变成可逐阶段修正的实验。

2.5 污染与记忆：划清泛化证据的边界

flowchart TB
    A[来源文档与重复簇] --> B[训练集合]
    A --> C[隔离后的评估集合]
    B --> D[参数学习与可能记忆]
    C --> E[未见输入的任务检验]
    D --> E
    B -.重叠或答案泄露.-> E
    D --> F[可提取内容测试]
    E --> G[泛化结论的适用范围]
    F --> H[记忆风险的已知证据]

Benchmark contamination

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

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

Memorization 与隐私风险

模型可能逐字复现部分训练序列。Carlini 等人展示了从语言模型中抽取训练数据的风险 [31]，后续研究量化了模型容量、训练数据重复次数和提示上下文长度与记忆复现的关系 [32]。这些证据不能简化成“只有稀有样本才被记住”，也不意味着公开网页中的内容可以无风险地再生成。

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

版权与数据治理

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

图里两条检验支路回答不同问题。泛化评估问模型在未用于训练的任务输入上是否成功，记忆测试问能否通过特定提示恢复训练中的内容。一个模型可以同时具有泛化能力和逐字记忆，也可以在某次抽取攻击中失败却仍受污染影响。把二者压成一个“是否背答案”的二元判断，会丢掉真正需要修正的数据边界。

污染首先是一个集合关系问题，但集合元素如何定义并不简单。在企业技术文档案例中，训练集有某接口的官方说明，测试要求解释该接口，这本身未必是不允许的重叠：如果目标就是检验模型能否使用学到的领域知识，知识覆盖是任务设定的一部分。若测试题及标准答案已经作为完整问答进入训练，却仍宣称测到了陌生问题上的迁移，就改变了证据含义。再进一步，如果测试要求处理一个从未公开的新版本，而训练中混入了该版本内部解答，则违反了原本的时间与来源隔离条件。因此应先声明评估想排除什么，再定义污染检测对象。

精确匹配通常只能发现最明确的一层。网页可能重复题目全文，也可能只包含正确选项、详细解说或把题目翻译成另一种语言。对文档做哈希能识别同字节内容，却无法识别改写；对规范化文本做片段匹配能覆盖部分格式差异，却可能把通用模板也当成污染。检测器越宽泛，候选越多，人工复核压力越大。一个命中率数字若不说明文本单位、归一化、匹配长度和复核规则，无法比较不同数据管线。

例如，两份接口问题都含有“返回值为空时应如何处理”，这段常见表达不足以证明题目重复；如果它们同时含有独特参数组合、相同边界条件和相同错误解释，证据就强得多。反过来，题目被改成另一种语言后，词面重叠可能很低，但逻辑结构和答案仍相同。可以先用廉价匹配产生候选，再对高价值评估样本做结构与来源检查。这里的语义相似只是检索线索，不应由一个向量距离直接宣判所有相似题目失效。

划分单位通常应尽量贴近相关性的来源。随机按段切分一本手册，很容易让训练段落包含测试段落的定义；随机按文件切分代码仓库，可能让训练和测试共享复制的函数与文档。按文档、仓库、站点或重复簇划分能够减少相应相关性，但隔离越粗也越可能改变评估难度。例如按站点划分既排除了近重复，也引入新模板和文风；它测到的可能是来源迁移而不是同来源任务表现。应把这些差别写成评估切片，而不是寻找一个对所有问题都正确的划分粒度。

污染发现后的处理也不能只是删除题目再报一个更好看的分数。若命中主要集中在简单题，移除后评估会更难；若集中在困难但热门题，移除又可能改变任务覆盖。较透明的报告应保留原始集合和筛后集合的定义，说明删除原因，并按相关切片给出结果，而不是把筛后集合冒称原基准。对于无法充分判定的候选，可以单列敏感性分析：分别按保留与排除口径观察结论是否变化。这样读者才能判断模型比较是否依赖不确定的污染标签。

记忆风险还与攻击者掌握的前缀有关。随机提示没有复现某段训练文本，不等于提供长而接近原文的前缀后仍不能恢复。Carlini等人的量化研究把提示长度作为影响抽取表现的变量之一。[32] 因而一份记忆测试报告至少要说明查询预算、提示构造、重复检测方式和确认原文的依据。成功抽取提供了具体风险证据，失败则只限定于已经尝试的攻击条件。对外声称“没有记忆”超出了有限测试能支持的范围。

敏感内容处理也应沿生命周期展开。进入训练前发现来源不适当，可以阻止进入样本池；已经生成数据快照后，需要追踪哪些快照包含它；模型训练完成后，删除源文件并不会自动修改权重。响应过滤或访问控制可以降低某些暴露路径，但与参数中的学习状态不是同一层。这些工程边界不要求本章给出法律结论，而是要求模型团队知道自己实际采取的措施作用在哪里，避免用文件删除记录冒充模型遗忘证明。

对于需要持续修订的企业材料，可给每个文档保留稳定来源标识、版本、获取时间和派生关系。当一个版本因事实错误被撤回时，能够识别受影响的样本和训练运行，才能决定重新生成数据、追加纠正训练还是在应用层提供明确版本证据。并非每次改动都要重新预训练；若变化主要是时效事实，外部检索往往更容易审计。这个决策将在下一节与能力收益、评估独立性一起讨论。

2.6 用评估决定下一阶段：继续训练、修正数据还是改变目标

flowchart LR
    A[固定版本的分层评估] --> B[训练健康度]
    A --> C[目标能力与通用锚点]
    A --> D[污染和分布外证据]
    B --> E[失败归因]
    C --> E
    D --> E
    E --> F[修复数据或优化状态]
    E --> G[继续领域训练]
    E --> H[转后训练或外部证据]
    F --> A
    G --> A
    H --> I[按新目标重新验收]

三层评估框架

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

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

评估设计的常见陷阱

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

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

不同阶段应接受不同的能力检验。

不同阶段的模型要用不同的证据。base model 评估关注语言建模与潜在能力，测的是“压缩了什么”；SFT、偏好优化和推理强化之后，评估才关注指令遵循、格式、安全和推理策略，测的是“默认行为是什么”。把不同阶段的失败混在一起归因，会得到错误的解决方案：事实过期属于证据问题，格式不稳属于输出契约问题，推理不足才可能需要后训练或更强的基座。

对工程师来说，最有价值的评估表不是“模型总分排名”，而是能力—成本矩阵：代码生成通过率、每次调用 token、首 token 延迟、失败类型分布、需要人工修复的比例。只有把模型输出放进真实任务，才能判断预训练能力是否转化成工程价值。

公开配方提供证据，也留下不可识别因素。

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

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

领域收益需要与保留能力一起判断。

继续训练某一领域时，目标能力可能增强，通用能力也可能退化。这个现象可以从分布变化理解：梯度更新更频繁地服务新分布，原有预测也会随参数改变。Gururangan等人在四个领域、八项分类任务上研究了领域和任务自适应预训练，说明额外预训练可以在其任务条件下带来收益；这不是现代生成模型不会遗忘的保证。[35] 对语言模型而言，本书建议增加语言、领域、长度和格式四个维度的保留能力检查。

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

训练结果的可解释记录

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

预训练、中间训练与后训练的衔接。

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

本章只保留与预训练直接相关的判断：当模型缺少稳定领域语料中的术语、文档结构或分布模式时，continued pretraining 可以成为候选；验证时必须同时保留通用锚点、目标领域和分布外切片，以观察能力增益与遗忘。指令与偏好问题由第 3 章处理，推理时搜索与验证由第 4 章处理，参数高效适配由第 6 章处理，时效事实则应在系统侧提供可审计证据。

以教学 8B 企业问答方案为例，先按去重簇冻结授权文档的训练、验证和测试划分，再在相同有效 token 预算下比较通用与领域配比。记录 held-out NLL、领域成功率、通用回归、污染与成本；测试集不能拿去调配比。领域词汇改善但问答格式不稳时，应转到第 3 章的后训练问题，而不是继续把原始文档当作指令数据。这里没有实际训练结果。

从输入到证据的评审顺序。

先查来源与划分，再查目标和有效监督位置，接着查参数、token 与计算预算，最后比较分层评估及成本。单位时间吞吐、有效 token 比例与单位计算的能力收益是不同指标。算法与 Infra 应共享数据 manifest、更新步定义和评估版本，避免把硬件更忙直接写成学习更有效。第 5 章把这些输入契约组成训练流程，第 9 章负责训练平台与数据管线的实现。

把这些原则用于贯穿案例，最终要形成的是一个可执行的阶段选择，而不仅是一张分数表。假设候选模型在独立技术文档上能解释术语，却经常输出过期接口；先检查提问是否提供版本以及检索证据是否可得。若加入明确版本材料后就能正确回答，继续扩大原始文档训练不一定是最直接的投入。如果即使给出短而明确的定义，模型仍混淆参数类型或前置条件，再考虑基础能力、任务数据或训练目标是否不足。两种失败表面上都是“答错”，干预位置却不同。

又假设领域准确率上升，但通用锚点下降。不能仅凭这个现象认定“发生灾难性遗忘”，因为评估模板、采样随机性和数据切片也可能变化。应先复用相同评价脚本，做成对样本比较，定位新增失败是否集中在某些任务或输出风格。如果变化稳定存在，再比较减少领域曝光、加入通用回放或缩短阶段的候选。这里的回放是把希望保留的分布继续纳入优化目标，并不保证所有旧能力完整保留；验证必须跟随最终模型，而不是跟随方法名称。

成对比较比两个独立总分更能揭示问题。同一批问题上，候选模型可能修复了一批错误，同时引入另一批错误，总分恰好不变。若新失败集中在高风险边界条件，总分相等也不能视为无差别。对于抽样产生的回答，还应区分训练随机性与生成随机性：重复生成主要反映解码波动，重新训练多个种子才涉及训练方差。预算不足以覆盖全部不确定性时，报告应说明实际重复了哪一层，而不是给一个含义模糊的“稳定性分数”。

统计区间也依赖样本结构。如果一份手册派生了许多近似问题，把它们当作完全独立观测会让区间显得过窄。可按原始文档或任务簇组织汇总，至少报告独立来源数与问题数。一个只有少量来源却大量改写的问题集，可以很好地检查这些来源的行为稳定性，但不能据此声称覆盖整个业务分布。此处是本书的实验设计判断，不是某个公开基准天然具备的保证。

阶段门槛应在看到最终结果前约定。比如目标任务需要获得可确认的增益，通用锚点不能超出可接受退化，关键失败类型必须逐项复核，而成本需满足部署约束。具体阈值由应用需求和样本量决定，本章不提供通用百分比。若每次看到新结果就改变通过条件，评估会变成追认已有模型的工具。冻结测试集也应控制访问频率：反复查看失败样本并修改数据，实际上已经让它参与了开发，即使没有把原题直接放进训练。

当候选通过阶段门槛，交付的不只是权重，还包括说明它在哪些条件下有效的证据：文本与Tokenizer版本、独立评估范围、已知污染候选、实际训练预算以及尚未解决的能力缺口。后训练团队据此决定示范与偏好数据，应用团队据此决定检索、工具和人工复核边界。若证据仍不支持扩大能力声明，可以交付较窄的适用范围。预训练工程的成熟程度，体现在能否解释下一笔预算为什么投入这里，而不只体现在训练完成了多少词元。

本章小结

在实际项目中，还应保留被否决方案的证据。例如，某次更强过滤虽然提高短文本测试，却删除了关键表格；某个更大模型虽然降低损失，却无法满足部署显存。记录这些结果不是为了维护实验流水账，而是避免后续团队在约束没有变化时重复投入。只有当数据来源、任务范围、硬件或调用规模发生变化，才有理由重新打开相应选择。这样的记录让预训练决策能够随条件演进，同时保留当时判断的适用边界。

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

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

参考资料

1. Bengio, Y., Ducharme, R., Vincent, P., & Jauvin, C，A Neural Probabilistic Language Model，2003。核验日期：2026-10-31。
2. Mikolov, T., Chen, K., Corrado, G., & Dean, J，Efficient Estimation of Word Representations in Vector Space，2013。核验日期：2026-10-31。
3. Sutskever, I., Vinyals, O., & Le, Q. V，Sequence to Sequence Learning with Neural Networks，2014。核验日期：2026-10-31。
4. Vaswani, A., et al，Attention Is All You Need，2017。核验日期：2026-10-31。
5. Radford, A., et al，Improving Language Understanding by Generative Pre-Training，2018。核验日期：2026-10-31。
6. Devlin, J., Chang, M.-W., Lee, K., & Toutanova, K，BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding，2019。核验日期：2026-10-31。
7. Raffel, C., et al，Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer，2020。核验日期：2026-10-31。
8. Brown, T. B., et al，Language Models are Few-Shot Learners，2020。核验日期：2026-10-31。
9. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V，动手学深度学习：softmax回归，中文在线版 2.0.0。核验日期：2026-10-31。
10. Bai, J., et al，Qwen Technical Report，2023 / original Qwen。核验日期：2026-10-31。
11. Cai et al. / InternLM，InternLM2 Technical Report，2024。核验日期：2026-10-31。
12. Schaeffer, R., Miranda, B., & Koyejo, S.，Are Emergent Abilities of Large Language Models a Mirage?，2023，v2。核验日期：2026-10-31。
13. Dodge, J., et al，Documenting Large Webtext Corpora: A Case Study on the Colossal Clean Crawled Corpus，2021。核验日期：2026-10-31。
14. Gao, L., et al，The Pile: An 800GB Dataset of Diverse Text for Language Modeling，2020。核验日期：2026-10-31。
15. Penedo, G., et al，The RefinedWeb Dataset for Falcon LLM: Outperforming Curated Corpora with Web Data Only，2023。核验日期：2026-10-31。
16. Lee, K., Ippolito, D., Nystrom, A., et al，Deduplicating Training Data Makes Language Models Better，2022。核验日期：2026-10-31。
17. Touvron, H., et al，LLaMA: Open and Efficient Foundation Language Models，2023。核验日期：2026-10-31。
18. Shumailov, I., et al，The Curse of Recursion: Training on Generated Data Makes Models Forget，2023初稿／2024 v3，作者预印本。核验日期：2026-10-31。
19. Penedo, G., et al.，The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale，2024，v2。核验日期：2026-10-31。
20. Muennighoff, N., et al.，Scaling Data-Constrained Language Models，2023初稿，2025 v5。核验日期：2026-10-31。
21. Xie, S. M., et al.，DoReMi: Optimizing Data Mixtures Speeds Up Language Model Pretraining，NeurIPS，2023，v4。核验日期：2026-10-31。
22. Sennrich, Haddow, Birch，Neural Machine Translation of Rare Words with Subword Units，2016 ACL。核验日期：2026-10-31。
23. Kudo, Richardson，SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing，2018 EMNLP。核验日期：2026-10-31。
24. NVIDIA，Packed Sequences — Megatron Bridge，官方在线文档，主要适用于SFT/PEFT独立样本。核验日期：2026-10-31。
25. Liu, N. F., et al.，Lost in the Middle: How Language Models Use Long Contexts，2023，v3。核验日期：2026-10-31。
26. Kaplan, J., et al，Scaling Laws for Neural Language Models，2020。核验日期：2026-10-31。
27. Hoffmann, J., et al，Training Compute-Optimal Large Language Models，2022。核验日期：2026-10-31。
28. 张阿斯顿等，动手学深度学习：小批量随机梯度下降，中文在线版2.0.0。核验日期：2026-10-31。
29. Loshchilov, Hutter，Decoupled Weight Decay Regularization，2019 / arXiv v3。核验日期：2026-10-31。
30. Zellers, R., et al，HellaSwag: Can a Machine Really Finish Your Sentence?，2019。核验日期：2026-10-31。
31. Carlini, N., et al，Extracting Training Data from Large Language Models，2020 preprint / USENIX Security 2021。核验日期：2026-10-31。
32. Carlini, N., et al，Quantifying Memorization Across Neural Language Models，2023。核验日期：2026-10-31。
33. Liang, P., et al，Holistic Evaluation of Language Models，2023。核验日期：2026-10-31。
34. Grattafiori et al. / Llama Team，The Llama 3 Herd of Models，2024 / arXiv v3。核验日期：2026-10-31。
35. Gururangan, S., et al.，Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks，ACL，2020。核验日期：2026-10-31。

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

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

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

3.1 行为目标与监督契约

flowchart TD
 A["任务要求"] --> B["逻辑消息与角色"]
 B --> C["模板化为 token"]
 C --> D["可读取的位置"]
 C --> E["被监督的目标"]
 D --> F["条件概率"]
 E --> G["有效目标分母"]
 F --> H["训练目标"]
 G --> H

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

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

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

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

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

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

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

采用模型结构的 \(B,T,D\) 与预训练的概率定义。聊天模型实际看到的是角色、内容、分隔符与特殊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。

从数据划分到反馈覆盖

多轮样本要按轮次和角色保存，再按同一逻辑任务分组：同一任务的不同轮次、改写版本和生成负例先归入一组，再划分训练、验证与测试，最后各自 packing。独立任务之间需要隔离可见性，不能只插入 EOS 就假定切断了注意力。训练集用于拟合，验证集用于调参，冻结测试集不反复挑选模型。

样本版本要同时记录输入协议（Tokenizer、模板）、监督位置和数据来源。模板或监督范围一变，同一份对话的标签就变了，“离线学会了某种输出”可能只是学会了已经过期的接口。

监督契约先回答一个比“用什么算法”更早的问题：同一份记录里，哪些内容是模型当时已经知道的条件，哪些内容才是希望它产生的动作。下面以一个贯穿本章的教学任务说明。用户要求定位某次告警的原因，输入只有时间范围和服务名称；助手先生成查询参数，工具返回两条日志，其中一条证据尚不充分；助手随后输出带引用的候选解释。训练样本不能把稍后才取得的日志提前塞进第一次查询的条件，也不能把人工事后确认的根因写成模型当时已经观察到的事实。否则优化器可以正常下降，训练任务却已经被改变成一个有答案泄漏的容易问题。

这里存在三种不同的“正确”。消息序列正确，是事件按实际可观察顺序排列；动作正确，是给定当时的信息选择了合适的查询或回答；结果正确，是最终解释得到独立证据支持。一次任务最终成功，不代表其中每一步都值得模仿。例如助手第一次查询用了错误时间范围，碰巧在第二次猜中了；把整条轨迹不加区分地用于监督，会同时强化正确结论和错误查询。反过来，工具临时不可用导致任务失败，也不代表助手选择的查询参数错误。标签必须落在所选择的监督对象上，不能直接从最终成功标签推出每个中间动作的质量。

一个有用的数据检查是“前缀可重放”：遮住目标动作及之后的事件，只向审核者展示目标前缀，再判断能否得到该动作。如果只有看完未来结果才认为动作合理，样本就需要重新标记。这个检查是本书根据条件概率定义提出的方法，不是对某个已运行数据集的结论。它尤其适用于多轮修复、交互编程与工具轨迹，因为这些场景的观察顺序本身就是问题的一部分。自然语言叙述可以把事件倒叙，训练协议则必须明确模型究竟在哪个时刻做决定。

损失掩码还不能通过字符长度粗略推算。一个汉字可能被编码成一个或多个 token，角色分隔符也可能不是普通字符串；先单独编码用户文本，再把长度相加，不一定等于对完整模板一次编码所得的边界。应使用模板提供的可靠角色区间或经核验的 token 对齐方式，在完整序列上构造监督位置。对同一个样本同时打印逻辑角色、token ID、可读文本片段和是否计入损失，才能观察标签到底落在了内容、分隔符还是下一轮起始处。样本级标签正确但 token 级错位，仍然是在训练另一个任务。

截断也有语义。假设目标是一个带三个必填字段的结构化动作，长度上限只留下前两个字段及半个字符串。若仍把截断片段作为完整好答案，模型会收到“在半个动作处停止也合理”的信号。另一种截断可能保留答案却删掉唯一支持它的证据，使原本有依据的示范变成无依据断言。可选策略包括丢弃样本、缩短非必要上下文、重新生成合法目标或按明确的部分输出任务监督；不存在一个适合所有数据的无条件截尾规则。评估集也应统计截断比例，否则任务分数变化可能只是进入训练的样本集合改变了。

多轮监督范围决定了同一段对话被使用多少次。若把每一轮分别展开成一个前缀—回答样本，早期消息会反复作为条件，早期助手回答还可能在多个样本里重复被监督；若在完整对话中一次监督所有助手轮，重复权重又不同。这两种组织都可以合理，但不能把“消息数量相同”当作训练权重相同。对包含长工具输出的任务，还应区分总输入 token 与有效目标 token：前者影响前向成本，后者进入本章的监督分母。大量工具文本可以耗费很大计算，却没有增加同等数量的助手目标。

划分数据时，独立单位最好对应生成事实的来源，而非最后导出的行号。一个工单的原问题、中文改写、英文翻译和合成负例若分散到训练与测试，模型可能凭共同细节识别任务；随机切分行数并不能消除这种关联。应先按工单、原始文档、题目家族或去重簇分组，再划分，最后在各自集合中执行采样和打包。这个流程牺牲了一部分表面样本数量，却让留出误差更接近对新任务的判断。若所有数据都来自同一套模板，还需要另设模板外的测试，否则只证明模型记住了表达形式。

最后，示范、偏好和奖励是三种不同的数据接口。示范给出一条希望模仿的序列；偏好说明在同一条件下两个候选的次序；奖励把生成轨迹映射成可优化数值。不能因为示范答案“很好”就默认所有其他回答都是负例，也不能因为一个答案赢过明显错误答案就认为它达到上线标准。后续三种目标的推导都依赖这个区别：监督学习拟合目标内容，成对学习拟合相对关系，强化学习则需要在采样分布上解释反馈如何改变行为。

3.2 SFT：从示范到条件分布

flowchart TD
 A["示范前缀"] --> B["预测下一目标"]
 B --> C["有效位置负对数概率"]
 C --> D["按 token 或样本归一化"]
 D --> E["参数更新"]
 E --> F["自由生成"]
 F --> G["留出任务与错误前缀检查"]

SFT 的数据结构与损失

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

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

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

批量训练还必须说明样本如何加权。若先汇总批内所有有效目标 token，再除以有效 token 总数，每个 token 权重相同，目标为 \(\mathcal{L}_{\text{SFT}}^{\text{token}}=-\sum_b\sum_{t\in\mathcal A_b}\log\pi_\theta(y_{b,t}\mid x_b,y_{b,<t})/\sum_b|\mathcal A_b|\)，较长回答因包含更多目标 token 而贡献更多总权重；若先对每个样本按 \(|\mathcal A_b|\) 取平均，再对批内样本取平均，则每个样本权重相同。两者不是同一个目标，不能只写“mean reduction”而省略分母。监督位置还要覆盖 EOS——它是“该在哪里停下”的监督信号，漏掉会削弱停止位置的直接监督，但不能据此断言模型必然无限续写；padding 位置不仅要排除出损失，还要按实现约定处理注意力可见性。这些约定直接决定模型学到什么。

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

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

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

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

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

SFT 的局限与退化模式

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

SFT 描述的是训练目标，不决定必须更新全部模型参数。需要在全量微调、LoRA、QLoRA 等参数更新方式之间选择时，见第 6 章“模型适配与能力扩展”；本章只规定监督信号和行为目标。

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

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

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

把 SFT 看成条件分布拟合，可以解释它为何会偏向常见表达。对一个固定前缀，假设训练数据里七次使用简短说明、三次使用详细说明；在容量充足且其他条件相同的理想化情况下，最大似然会尝试匹配这些示范频率。它并不知道详细说明是否更贵，也不知道七条简短说明是否只是同一作者重复录入。样本分布因此不仅提供事实内容，也在暗中提供风格与行为的权重。数据去重、分层采样和人工修订改变的是这个经验分布，而不是训练之外的装饰步骤。

可以用一个手算比较两种分母。设样本甲只有两个有效目标 token，两个位置的负对数概率都为一；样本乙有八个有效目标 token，每个位置的负对数概率都是三。先对样本平均再对批次平均，损失是二；把所有有效 token 合并，损失是二点六。两者的差异不来自浮点误差，而来自甲、乙各占一半权重还是分别占五分之一与五分之四。若长回答主要来自某个领域，选择 token 平均就同时提高了该领域的总体影响。比较训练配方时，应先把这个隐含权重说清楚。

同样的区别会延伸到梯度累积。假设两个微批分别有很少和很多有效目标，若各自求平均后再等权累积，就得到“微批平均的平均”；只有在有效目标数相等或额外按目标数加权时，它才等价于整个更新批次的 token 平均。这里不展开分布式实现，第五章和训练平台章节会继续追踪归一化；本章要强调的是，优化器看到的梯度已经包含了数据权重选择。换一套打包长度导致效果变化，不能立即归因于模型“更擅长长文本”，也可能是监督权重发生了变化。

从单个词表位置看，交叉熵对 logits 的导数是预测概率减去目标的独热标签。因此目标 token 获得提升的方向，其他候选按当前概率承担相应调整。但共享参数把许多位置耦合在一起，一次参数更新并不保证每个训练位置的目标概率都单调上升。梯度冲突提供了一个具体解释：相同前缀在一批样本里要求简洁，在另一批里要求展开，而输入又没有告诉模型何时选择哪种行为；优化器只能折中。若希望按用户需求切换风格，最有效的修复通常是让条件和标签一致，而不是仅降低学习率。

教师强制还解释了训练损失与自由生成之间的落差。训练时，预测第三个目标 token 所用的前缀来自示范中的前两个目标；生成时，它看到的可能是自己刚刚产生的另一种表达。一个很小的早期错误会把模型带到训练数据较少覆盖的前缀，后续即使局部概率计算正确，也未必知道如何恢复。对工具任务尤其如此：把参数字段写错后，环境返回错误信息，下一步条件已经不同于成功示范。只补充更多成功轨迹，可能继续降低教师强制损失，却没有教会错误前缀下的恢复动作。

可以把训练目标与评估对象放在一个具体例子里比较。目标回答为“证据不足，先核对时间范围”，模型在标准前缀下能给这句话很高概率，但自由生成先输出了“已经确认根因”。此时后续再补一句证据不足，整个答案仍然矛盾。只计算目标句的平均损失会漏掉这种轨迹级错误；评估必须实际生成，并检查前后断言是否一致。数据改进可以加入相同观察下的澄清示范，也可以加入已经出现错误断言后的自我纠正样本，但应区分“预防错误”与“在错误后恢复”的两种任务。

合成示范带来的问题也可以按这个框架理解。Self-Instruct 提供了扩展指令覆盖的路线，LIMA 展示了精选示范的价值；它们没有给出一个对所有底座通用的数据数量阈值。基于这两类工作，本书建议把合成过程拆成任务生成、答案生成和独立验收三个环节。若同一生成器同时设计题目、写答案并给自己打分，错误可能在三步中保持一致。增加生成数量能提高表面多样性，却未必增加新的任务约束；需要按能力、输入条件和失败分支检查覆盖，而不是只看字符串去重率。

对于领域适配，回放通用数据的作用可以解释为保留旧任务的梯度约束。新领域数据推动某些共享参数朝专业表达移动，通用回放则使这些移动同时接受旧任务损失的检验。它不是遗忘的绝对保险：若配比过低、学习率过高或两类标签本身冲突，仍可能退化。比较时应画出新任务收益与旧任务损失的关系，选择可接受的折中，而不是只报告新任务最佳检查点。选择最后一个训练步、最低验证损失和最高业务分数，可能得到三个不同的模型，应提前定义选择准则。

SFT 的最小验收可以围绕可定位的反例展开。先检查目标边界，再确认少量样本能被拟合，随后比较教师强制与自由生成，最后看未见任务和旧能力。前一步失败时，后一步的总体分数通常难以解释。例如目标边界错了，增加样本数量只是更稳定地学习错误协议；小样本拟合成功却留出失败，则要查覆盖、冲突和容量。这样的顺序不是为了延迟训练，而是把每一项实验对应到一个可被否定的假设，避免同时改动数据、模板和优化器后无法解释收益来源。

3.3 RLHF：奖励、优势与 PPO 更新

flowchart TD
 A["旧策略采样并保存概率"] --> B["奖励与参考惩罚"]
 B --> C["旧价值与优势估计"]
 C --> D["固定优势更新 actor"]
 C --> E["固定回报目标更新 critic"]
 A --> D
 R["冻结参考策略"] --> B
 D --> F["刷新旧策略并重新采样"]
 E --> F

偏好数据与 Reward Model

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

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

\[ \mathcal{L}_{\text{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比例和有效样本，不能只看到目标值上升就认定策略仍接近旧分布。

实现里还有两个常被忽略的旋钮。优势归一化：按批内均值与标准差缩放优势，可以稳定更新尺度，但会让不同批次的“好”与“坏”不再可比，记录时应保存归一化前后的统计量。熵正则：在目标里加入策略熵可以维持探索、避免过早收敛到单一措辞，系数过大则会削弱对齐效果。PPO 原论文的联合目标包含可选的熵奖励项；是否启用、采用何种优势归一化及其系数属于具体配方，必须随实验记录。

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定义。

一种教学奖励构造是每步加 \(-\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]

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

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

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

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

奖励模型的比较损失可以先用两条分数手算。若优选答案比分数较低答案高两个单位，预测偏好概率约为零点八八；若把两条分数同时加上一百，概率完全不变。这说明成对标签只约束同一提示下的分数差，并不赋予奖励零点绝对意义。跨提示的奖励均值更不能直接解释为“这道题完成得比另一道题好多少”。当策略优化依赖奖励尺度时，应检查归一化、截断和不同任务的配比，否则某个评分范围更宽的任务可能支配梯度，即使它在业务上并不更重要。

偏好模型还能把混杂变量学成捷径。设训练中所有好答案恰好更长，所有坏答案更短；模型可以通过长度预测标签，而无需理解内容。留出比较若沿用同样分布，准确率仍然很高。诊断需要构造交叉对照：同样正确的一长一短、同样长度的一对对错，以及需要简短回答却故意展开的候选。若奖励次序跟着长度而不是正确性改变，问题在评分器或标签中。继续用该评分器训练策略，会主动增加这种捷径出现的频率，导致优化后的数据分布比奖励模型的训练分布更极端。

为什么还需要价值模型？一个终局奖励只告诉整段轨迹的结果，策略梯度若把相同结果直接乘到所有动作上，方差往往较大。价值函数估计在当前前缀下继续采样的平均回报，优势则比较这次实际经历与该预期。对一个本来很容易成功的前缀，成功不一定是强烈的额外好消息；对一个通常失败的前缀，同样的成功可能更值得增强。这里价值模型估计的是所定义奖励下的回报，并不判断句子是否真实。奖励定义错了，价值模型拟合得再准确，也只是在更准确地预测错误目标。

GAE 中的两个参数可以通过极端情形理解。令递推系数为零，优势只使用一步残差，强烈依赖下一状态的价值估计；令它接近一，优势会汇入更远处的残差，更接近长回报与当前价值的差，通常也更容易受到远端随机性的影响。这不是“越大越准确”的单调选择。若语言任务只在结束时给奖，较短的信用传播可能依赖 critic 提前把结果信息学到前缀中；若 critic 尚不可靠，又需要观察优势如何随长度和位置变化。比较这些统计比只看一个总体价值损失更能解释训练初期的行为。

前面的三步手算还可以用来检查时间轴。第三个奖励属于第三个动作之后发生的转移，第三个价值则属于采取第三个动作之前的状态；把奖励向前或向后错位一格，即使表格形状不变，也会把信用给错动作。真实终止后不能再沿下一条样本传播优势，否则一个任务的最终成败会污染另一个任务的开头。对补齐位置既不应产生真实动作比率，也不应延续递推。实际实现可把这些边界做成很小的人工序列，而不必先启动昂贵的模型训练来发现。

PPO 裁剪的方向也值得手算。设裁剪范围为零点八到一点二，优势为正二，当前与旧策略的动作概率比为一点五：未裁剪乘积是三，裁剪项是二点四，取较小值得二点四。继续增大这个比率不再提高该样本的代理收益。若同样优势下比率为零点五，目标仍取一，保留把概率拉回来的梯度。对负优势减二，比率为零点五时两个候选为负一与负一点六，取负一点六，进一步减小概率不再得到代理收益；比率为一点五时则保留负三，仍惩罚错误方向的增长。

这些分支说明，裁剪只在有利方向超过范围时压平局部代理收益，并没有把概率比硬性限制在区间。模型参数由大量样本共同更新，一个样本的梯度被压平后，其他样本仍可能继续改变它的概率。即使每个观测动作的比率接近一，未被采样的动作也可能发生变化。因此实际分布的 KL、有效样本数量和新采样结果都是必要诊断；它们是在检查代理目标与真实策略变化之间的差异，不是重复计算同一个指标。

旧策略概率必须在采样时固定。假设第一次更新后用当前参数重算分母，第二次更新又把新分母当成旧策略，所有比率会被人为拉回一附近；日志看上去“很稳定”，其实比较基准正在追着策略移动。反过来，长期复用很旧的 rollout，概率比可能极端，样本很难代表当前策略。训练通常在采样成本和数据新鲜度之间取舍：同一批数据多用几轮可减少生成开销，却增加离策略偏移。这个取舍应由当前策略相对采样策略的变化来评估，不能只按固定轮数宣布安全。

参考 KL 有另一条时间轴。它连接当前行为与一个选定的行为锚点，目的在于使奖励优化不要无约束地偏离已有分布；旧策略则连接本次更新与产生数据的策略。两个模型在训练开始时可能权重相同，后来会分离。若阶段间更新参考模型，应明确这是更换正则化问题，而不只是清理缓存。参考分布本身也可能有缺陷：过强约束会阻碍纠正原有错误，过弱约束会允许策略在奖励模型不可靠区域大幅移动。合理系数需要结合任务收益、行为漂移和奖励可靠性共同判断。

采样后的奖励、优势和价值目标应形成一次明确的数据快照。先用固定版本的评分器计算回报，再得到旧价值与优势，之后在若干小批中更新；不要在同一批尚未训练完时悄悄切换评分器，使前后小批对应不同问题。若使用共享主干，actor 与 critic 的损失可以按系数共同更新主干，但策略梯度不应通过“优势如何计算”反向修改目标。否则模型可以通过改变价值估计减少表面损失，而不是改善动作分布。这里需要区分允许共享参数与允许任意梯度路径，两者不是同一件事。

最终应把奖励曲线和外部成功曲线并排观察。若奖励持续上升、人工判断或可执行测试却下降，优先检查奖励投机、分布迁移和尺度变化；若两者都不动，检查探索是否覆盖成功路径、优势是否被掩码清空、更新是否被裁剪饱和；若先上升后突然退化，则检查数据新鲜度、奖励版本和优化尺度。不同症状有不同假设，不能用“强化学习不稳定”概括所有问题。RLHF 的工程难点正是让采样、评分、估值与更新围绕同一个可解释目标运行。

3.4 DPO：把偏好写成策略目标

flowchart TD
 A["同一提示的偏好对"] --> B["策略响应对数概率"]
 A --> C["冻结参考响应对数概率"]
 B --> D["两个相对比值的差"]
 C --> D
 D --> E["偏好似然与梯度"]
 E --> F["更新策略"]
 F --> G["检查覆盖与独立任务质量"]

DPO 的核心思想

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

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

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

这个目标可以从更一般的设定推出来。在 KL 正则化的奖励最大化问题中，最优策略与奖励之间存在解析关系：\(\pi^*(y\mid x)\propto\pi_{ref}(y\mid x)\exp(r(x,y)/\beta)\)。把它反解，就能用策略与参考模型的概率比表示奖励，于是偏好似然可以只写成两个策略的比值，不再需要显式训练奖励模型。这也是 DPO 名字的由来：语言模型本身隐式地参数化了奖励。

DPO 的这条等价推导依赖偏好概率可由 Bradley–Terry（或论文讨论的 Plackett–Luce）模型表示，并以 KL 正则化的奖励最大化为原始优化问题 [12]。参考模型用于定义正则化锚点，不需要是价值意义上的“中性模型”。实践中的另一类风险来自数据覆盖：若偏好对由与目标策略差异很大的行为策略生成，有限的离线样本可能无法覆盖新策略会访问的回答区域，此时隐式奖励在分布外区域缺少可靠证据。这个覆盖问题影响离线优化的可信度，但不是把“参考模型中性”补成理论前提。

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绝对概率每次都上升，更不能证明外部任务已成功。

下面用一个本书构造的有限回答空间展开解析关系。固定提示，只允许三个候选回答，并给它们一个总和为一的参考分布。目标是在回答概率的单纯形上最大化平均奖励，同时减去到参考分布的 KL 惩罚。加入概率和为一的拉格朗日约束，对每个候选概率求导后，奖励与对数概率比只差一个对所有候选相同的常数；归一化便得到前面的指数加权形式。这里要求参考分布在考虑的候选上具有正概率，否则概率比与 KL 的支持集需要单独处理。这个有限例子解释推导结构，不表示现实语言模型可以枚举全部回答。

若参考分布对两个候选各给一半概率，奖励差为一，正则化系数也为一，最优策略对高奖候选的概率约为零点七三一；把系数增大，分布会更靠近原先的一半；把系数减小，分布会更集中到高奖候选。这是理想奖励已知、概率可自由选择时的结果。真实 DPO 用有限偏好样本训练共享参数，优化是否到达该理想解、偏好模型是否正确、未见回答如何变化，都仍需实证。因此“有解析最优关系”不等于实际训练不受容量和数据限制。

反解奖励时会出现只依赖提示的配分函数。为什么它能消掉？因为一次偏好比较的两个回答具有完全相同的提示，它们的奖励相减时，公共项相互抵消。如果把来自不同提示的两个回答拼成一对，或者一边删了系统条件而另一边保留，公共项就不再是同一个量。这不只是实现细节：同一答案在不同条件下可能有不同价值，跨条件比较没有沿用原推导的资格。偏好样本应保存完整条件，不能只保存两段看起来像答案的文本。

再看相对概率与绝对概率的区别。设参考策略对优选与劣选回答的概率分别为零点二和零点一，新策略分别为零点一和零点零二。优选答案的绝对概率下降了一半，但相对参考的比例为零点五，劣选答案则降到零点二，两者的相对差仍然向优选方向移动。因此偏好损失可以改善，同时优选答案也变得更少出现；剩余概率被分配给其他未在这一对中出现的回答。这个反例不否认梯度中的优选增强方向，而是在提醒共享分布和多个训练样本使单对直觉不能升级为全局单调保证。

目标中的 sigmoid 还提供了样本权重。当前策略若已经把一对样本排序得非常有把握，该样本继续提供的梯度通常较小；若次序仍然错误，权重较大。这个机制可以减少已经解决的简单偏好对的影响，却也可能反复追逐错误标签。假设一个标签把正确的简短答案标成劣选，随着模型纠正其他样本，这个冲突样本仍会提供强梯度。增加迭代次数不自动等于增加可靠知识；要看偏好噪声、难例质量及留出关系是否支持进一步优化。

响应似然的边界必须和比较事件一致。若两个回答共享一长段开头，该段的策略与参考对数概率差在理论上会相减抵消，但后续分支的条件不同，不能只保留最后一个不同 token 就认为等价。两个候选在第一个分叉之后，即使又出现相同文字，它们所依赖的前缀也可能不同。实现应按完整响应逐位置计算条件概率，再按定义组合；文本差分可以帮助审核标签，却不能直接代替概率链式分解。相同字串不意味着相同条件事件。

长度问题也不是简单“长答案天然吃亏”。较长序列的对数概率和通常更负，但 DPO 使用的是策略相对参考的差，再比较两个回答；长度怎样影响最终梯度取决于每个位置的相对变化与数据分布。改成 token 平均确实改变了长度权重，却同时改变理论目标。正确做法是明确所用变体，并通过长度匹配的对照检查它是否解决了当前偏差，而不是在代码里静默改分母。生成温度则改变采样分布，它与训练目标中的正则化系数属于不同层次，不应共享一个含混的“温度”解释。

离线偏好优化省去了训练期间不断向环境采样的环节，但没有省去候选生成成本。若所有偏好数据来自一个与当前策略差异很大的模型，当前策略常犯的错误可能根本不在负例中。更新后的策略又可能发现新的语言捷径，使旧偏好对不能代表部署分布。可行的改进是用当前候选补充新的比较，再重新进行离线训练；这已经形成迭代式的数据收集流程，成本与风险都要重新记录。是否在线不由“用了 DPO”三个字永久决定，而由数据何时生成、如何更新决定。

反馈形态决定方法适配，但不自动决定标签质量。点赞和点踩看似适合单条反馈目标，实际可能受到用户情绪、展示位置或任务难度影响；成对比较看似更精细，也可能只反映某个标注者的风格。IPO、KTO 和 ORPO 在目标设计上的差异，不能替代对这些因素的审查。尤其 ORPO 不需要独立参考模型这一性质，应与它仍需要监督与偏好权衡分开理解。减少一个模型角色，缩短了计算链路，却没有删除多目标冲突。

本节方法可以用一组最小指标验收：偏好对上的排序准确率、优选与劣选各自的绝对似然、相对参考的变化，以及独立生成后的任务质量。四者回答不同问题。排序上升只说明更符合已有比较；绝对似然揭示概率质量是否整体流向未观察区域；参考差显示行为漂移；实际生成才暴露部署结果。只报告其中最好看的一项，会遮住目标与用途之间的距离。选择检查点时应根据预先定义的任务标准，而不是事后挑最有利的统计口径。

3.5 RLVR 与 GRPO：从结果到探索信号

flowchart TD
 Q["同一问题"] --> S["采样一组候选"]
 S --> V["验证结果或奖励评分"]
 V --> A["组内相对优势"]
 A --> Z{"是否存在奖励差异"}
 Z -->|是| U["带概率比的策略更新"]
 Z -->|否| D["检查难度与探索"]
 U --> S
 D --> Q

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

偏好奖励适合“哪个回答更好”，但复杂数学、代码和规划任务往往有更客观的验收。Tülu 3 将使用确定性验证函数进行强化学习的阶段称为 Reinforcement Learning with Verifiable Rewards（RLVR），并把它用于数学和可精确检查的指令遵循任务 [18]。DeepSeek-R1 使用基于规则的准确性与格式奖励训练数学、代码和逻辑推理能力，是同类的可验证奖励实践，但其报告没有把 RLVR 作为方法名称 [19]。DeepSeekMath 提出 GRPO，其强化学习实验训练了神经奖励模型，并非全部使用确定性数学验证器 [20]。

本书为讨论成本构造一个教学奖励，以下公式不是上述论文的统一配方：

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

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

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

只在最终答案上给奖励，信用分配会很困难：一条长推理可能在最后一步出错，模型不知道前面哪些步骤有价值。过程奖励模型尝试对中间步骤逐步评价；Let’s Verify Step by Step 研究过程监督的奖励模型，并用候选筛选评估数学解题效果；不能将它直接当作任意策略在线强化学习收益的证明 [21]。但过程奖励也可能把某种表面推理风格当作正确，或者让模型过度拆步骤。

本章关注验证器怎样形成训练信号：验证器可能需要训练、校准和对抗评估，也可能是无需学习的确定性程序。Training Verifiers 的研究展示了训练结果验证器的路线 [22]。工程上要记录 false positive、false negative、测试覆盖和版本变化，防止策略针对覆盖漏洞优化。训练完成后，如何在一次请求中用冻结版本的验证器筛选候选、引导搜索和决定停止，见第 4 章 4.4 节。

GRPO、组内奖励与冷启动

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

按 DeepSeekMath 的结果监督写法，先对每条回答取 token 平均，再对组内回答平均，可把更新目标写成下式；这里保持其逐 token 概率比口径，不能与整段概率比静默互换：

\[ J_{\mathrm{GRPO}}=\mathbb E\left[ \frac1G\sum_{i=1}^{G}\frac1{T_i}\sum_{t=1}^{T_i} \left{\min!\left(\rho_{i,t}\hat A_i, \operatorname{clip}(\rho_{i,t},1-\epsilon,1+\epsilon)\hat A_i\right) -\beta k_{i,t}\right}\right], \quad \rho_{i,t}=\frac{\pi_\theta(a_{i,t}\mid s_{i,t})}{\pi_{\mathrm{old}}(a_{i,t}\mid s_{i,t})}. \]

其中一种 KL 样本项为 \(k=u-\log u-1\)，\(u=\pi_{\mathrm{ref}}(a\mid s)/\pi_\theta(a\mid s)\)。它由对数不等式保证非负；其期望等于相应 KL 的结论需要动作按当前策略采样等条件。复用旧策略轨迹多轮更新时，不能忽略采样分布变化而直接声称仍是当前策略 KL 的无偏估计。该项与组内任务优势分开进入损失。[20]

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

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

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

训练数据应覆盖成功、失败、超时、被拒绝、部分结果和需要确认的分支；工具 schema、参数类型、错误码必须与线上接口一致，否则模型学到的是不可执行的假协议。有副作用的动作仍需运行时的权限与审批，训练中较高的调用准确率不构成执行授权。

奖励来源和优化算法是两条独立坐标。PPO 可以使用人类偏好训练出的奖励模型，也可以使用确定性验证函数；GRPO 可以使用规则分数，也可以使用学习出的奖励模型。Tülu 3 的可验证奖励阶段采用 PPO，DeepSeekMath 用组内比较构造优势并训练神经奖励模型，而 R1-Zero 的报告强调规则准确性与格式奖励。把这三件事并列之后，就能避免“换成 GRPO 就获得可靠验证”或“用了 PPO 就只能做人类偏好”的错误推论。算法负责怎样利用信号，验证器负责信号究竟意味着什么。

组内标准化可以用四个候选手算。设结果奖励依次为一、一、零、零，组均值是零点五，若使用总体标准差则为零点五，忽略稳定常数时优势为一、一、负一、负一。若改成一、零、零、零，均值为零点二五，总体标准差约为零点四三三，成功候选优势约为一点七三二，失败候选约为负零点五七七。相同的一次成功，在不同组分布中获得不同的相对权重；这正是组内比较的含义，不是验证器给了更大的绝对成功奖励。改用样本标准差时数值也会变化，复现必须说明口径。

若四个候选全部失败，中心化后没有任务奖励差异；加一个很小的稳定常数只能避免除零，不能创造成功方向。全部成功也一样缺乏相对区分，但原因完全不同：前者可能太难、格式失效或验证器出错，后者可能太简单。两者在平均奖励上可区分，在优势方差上却都可能接近零。应同时记录奖励均值、非零方差组比例和可解析率，才能决定是补充基础示范、改变采样、调整题目难度还是修复评分。即使任务优势为零，参考正则化仍可能产生梯度，不能把它称为整个更新必然为零。

对于结果监督，同一回答的多个 token 共用相对优势，意味着成功轨迹中的错误尝试也可能被一起强化。如果回答先走错再纠正，最终成功不能说明每一步都有效。过程奖励试图提供更细的定位，却需要可靠的步骤边界和评价标准；把自然语言每一行当成一步，并不保证它对应一个可判定推理操作。验证器如果奖励“看起来有推导”，模型可能学会增加形式化措辞而不提高正确性。结果奖励与过程奖励各自承担不同误差，不能仅按反馈更密集就断言后者更好。

本书用简单的伯努利模型说明探索难度：假设每个候选独立以概率 p 成功，一组 G 个候选至少出现一次成功的概率为一减去失败概率的 G 次方。这个式子只在独立、同分布的教学假设下成立；真实候选常因同一模型与题目而相关，因此不能直接拿它预测收益。它仍揭示两个方向：成功概率极低时，增加少量候选可能只得到更多失败；候选高度相似时，名义组大小也不等于有效探索数量。测量独立成功路径的多样性，比只增加生成数量更有意义。

成本惩罚进一步改变了目标。假设成功奖励为一，每个 token 扣一个固定小成本，一条很长但正确的轨迹最终得分可能低于短而错误的轨迹。如果业务要求首先正确，这个线性权衡就未必符合需求。可以考虑把成本作为约束、在成功样本内部比较效率，或分阶段调整奖励，但每种选择都对应不同优化问题。不能把奖励权重当作没有语义的调参旋钮。特别是在训练初期，尚未学会成功路径就强烈惩罚长度，可能抑制必要探索；这需要通过轨迹检查来判断，不能仅根据平均长度下降庆祝效率改善。

规则验证也有统计错误。代码通过有限测试集，只能证明它通过已执行用例；数学答案抽取器若把回答中的任意正确数字当成最终答案，模型可能列出许多候选投机命中。结构化任务若只检查能解析，模型可以输出合法但无用的空对象。验证应分成解析、格式、语义与执行结果，并明确每层失败怎样映射成奖励。对代码任务，还要隔离运行环境、限制资源并保留超时原因；超时可能来自错误算法，也可能来自测试基础设施，不应无条件混成同一种语义错误。

验证器升级会改变训练问题。旧版本误判为成功的样本，新版本可能判错；若把两种分数混在同一组里，优势比较就失去共同尺度。一个可解释流程是在批次或阶段边界固定验证版本，对已保存轨迹重新评分，并分别观察策略变化与评分变化。独立评估最好使用更广的未公开测试或人工核验，减少策略针对训练检查的适应。这里所谓独立不是简单换一个文件名，而是让评估覆盖训练奖励尚未编码的失败模式。

工具交互提供了一个特别清楚的信用分配例子。一次查询返回空结果，可能意味着参数错误，也可能意味着条件下确实没有记录。若奖励只要求“最后必须找到记录”，模型会被鼓励不断改条件直到出现任意结果，而不是忠实回答没有证据。应把任务定义为在指定约束下完成查询与解释，并把改变约束的动作纳入评价。对多轮轨迹，环境状态、错误返回和动作顺序都需要保留；只保存最终自然语言回答，会丢失导致成功或失败的关键路径。

3.6 安全反馈与独立回归

flowchart TD
 P["明确原则"] --> C["批评与修订示范"]
 C --> S["监督微调"]
 P --> J["候选偏好判断"]
 J --> R["偏好模型与策略优化"]
 S --> R
 R --> E["独立正常任务与攻击评估"]
 E --> F["检查收益与退化"]

Constitutional AI 的思路

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

其监督阶段用原则引导批评与修订，再把修订回答作为微调目标；随后在强化学习阶段，另用原则引导 AI 对候选回答作偏好比较，训练偏好模型并优化策略。不能把两个阶段压缩成“原答案与修订答案直接配对”的唯一流程。原则文本使判断依据可以审阅，但原则如何被模型解释仍需评估。

RLAIF 的优势与盲点

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

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

安全数据的分层比总体的“安全率”更能说明问题。至少区分四类：明确违规（必须拒绝并解释）、边界请求（需要澄清或提供受限帮助）、正常但敏感的请求（应当正常完成）、攻击性输入（越狱、注入、隐私抽取）。四类的正确行为不同，把它们混成一个“安全/不安全”标签，会同时奖励过度拒答和放任违规。评估也要分开报告：违规放行率、正常请求误拒率、边界请求的澄清率、攻击阻断率，四者不能互相抵消。

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

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

方法选择与回归证据

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

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

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

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

以 ALR 告警诊断为例，设想一组偏好标注总是奖励“直接给出根因”的回答。面对一个需要证据判断的请求，回答 A 会说明前提、引用依据并指出需要确认；回答 B 会直接给出结论。若标注只看语气、速度和表面帮助度，B 很可能被选为偏好样本。偏好优化后，离线“帮助度”上升，实际任务的成功率却下降。

该教学反例的直接原因是偏好标签奖励了无依据的确定性表达，而没有区分证据充分与证据不足。修复方式不是继续堆同类的安全样本，而是修正偏好标准：把偏好比较限制在解释清晰度、证据忠实度和不确定性表达上，把事实与条件判断交给独立的检索、规则或验证器；并在回归集中单独记录事实准确率、条件判断准确率和澄清率。这个案例说明，后训练只能塑造默认行为，不能替代外部的事实与规则校验。

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

工具调用样本的监督目标不是“让动作成功”，而是“让模型学会在给定观察下输出正确的下一步”，二者差别很大。

表中的标签来自本书教学契约，生产样本应由业务规则与实际回执确认。偏好对还应保留同一观察下的难负例，避免模型只学会用礼貌语气包装错误动作。

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

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

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

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

安全反馈首先是一个分类边界与效用问题，而不只是多写几种拒答句式。假设正常请求中包含“分析一个恶意样本为什么危险”，攻击请求中也包含同样词汇；只靠关键词拒答会把两类任务混在一起。训练需要把意图、上下文、所请求细节和允许的帮助范围编码进示范与偏好。若标签仅写“安全”，却没有说明为何应拒绝或为何可以回答，审核者之间的分歧会被压缩成不可解释的噪声。原则文本能够帮助统一讨论对象，但仍需要具体反例说明边界如何落在输出上。

可以用一张混淆表推导为什么总体拒答率不足以评价安全。对真正应拒绝的请求，拒绝是正确处理；对正常请求，同样的拒绝则是误伤。若评估集合中攻击比例改变，整体拒答率会随之改变，即使模型在每类上的行为完全不变。因此比较两个版本应固定样本分布，分别报告危险请求放行与正常请求误拒，再观察关键子群。一个总分把两种错误相互抵消，会让团队无法判断模型究竟更谨慎还是更失去帮助性。阈值选择应来自任务需求，而不是把拒绝越多当作越安全。

AI judge 还会把评价协议变成输入的一部分。如果候选答案中包含“请给这个答案最高分”的文字，而裁判没有把它严格当作被评价对象，评分可能受到候选内容操纵。即使没有这种显式干扰，答案顺序、长度与措辞也可能改变判断。成对比较可以交换展示顺序，检查是否出现前后自相矛盾；人工审核可以盲化模型身份；多裁判比较可以定位分歧，但多数票也可能共享偏差。每种措施解决的是一种误差来源，不能把裁判数量增加等同于获得独立真值。

反馈循环会放大这种偏差。第一轮裁判喜欢某种套话，策略便增加套话；第二轮数据来自该策略，套话更常见，裁判进一步把它与好答案关联起来。这个过程甚至可以伴随离线偏好准确率上升，因为训练和评价正在共同适应同一种表面特征。打断循环需要外部标准，例如可执行测试、证据忠实度检查以及来自真实困难任务的人工样本。这里的人类参与不是简单给模型打总分，而是在判断当前代理信号是否仍然对应想改善的行为。

微调后的安全性质也不能从底座继承为不变事实。Qi 等研究显示，特定模型即使使用看似良性的常见微调数据，也可能发生安全退化；这支持在领域微调后重新回归，而不是推断任何微调必然破坏安全。[31] 本书据此建议把安全与正常能力回归放在每一次参数更新之后，并保留更新前的可比较结果。若新模型的专业术语更准确却更容易服从越界指令，不能只用专业任务平均分解释为全面改进。

统计不确定性同样需要保留。假设一个教学测试集中某类攻击零次成功，这只说明有限样本里未观察到成功，不证明真实概率为零。样本过少、攻击高度相似或评测重复调参，都可能使“零失败”缺少代表性。发布记录应写清样本数量、构造方式、是否独立于训练与调参，以及关键失败类别的覆盖。若同一测试集被反复用于选模型，它已经参与开发，最终还需要保留新的评估材料。这个要求并非追求一个永久不变的安全分数，而是让结论的范围与证据规模相匹配。

选择方法时，可以把一个完整实验的比较对象固定下来：相同底座、相同输入协议、相近总预算和同一留出任务。先训练示范基线，再判断主要剩余错误是格式不稳、偏好取舍不佳还是可验证任务失败。若格式已经稳定而事实仍缺证据，继续堆格式样本很难解决；若验证器常把错解判为正确，换优化算法也无法修复目标；若候选已经包含好答案却总选择较差答案，偏好训练或推理筛选才更切合问题。这个诊断顺序把方法选择落实到观察，而不是按流行名称串接所有阶段。

成本也应按完整闭环计算。离线偏好训练可能不在线生成，但预先生成和标注候选仍有代价；组相对方法省去独立 critic，却增加同题候选采样；确定性验证器不需要学习参数，执行测试仍会消耗时间。比较时至少分开记录生成 token、被监督 token、被评分候选和通过验证的有效轨迹。若大量预算花在无法解析的输出或全零奖励组上，降低单步训练时间未必提高每单位成本的有效进展。资源效率最终应联系到可比较的任务收益，而不是某个局部算子更快。

回到告警诊断教学案例，完整验收应串起观察、动作和解释：日志是否来自指定时间范围，查询是否保留用户条件，解释是否引用实际证据，信息不足时是否明确限制，以及环境失败时是否做出与状态一致的下一步。示范提供正确轨迹，偏好对比较同一观察下的解释质量，规则检查可验证参数与引用，人工评估剩余的推理与表达。这几种信号各自负责能够可靠判断的部分，组合后才构成可讨论的后训练方案。模型权重改变了行为倾向，外部结果仍然需要在任务环境中核验。

本章小结

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

第 2 章介绍的交叉熵与 KL 在本章分别进入监督目标和正则化目标，第 1 章说明的模型结构边界仍然约束后训练能学到的行为。第 4 章转向生成、搜索和推理期验证，研究一次请求怎样在明确预算内得到更可靠的候选；第 6 章再讨论如何选择全量微调、参数高效微调及其他模型适配方式。

参考资料

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

第4章 推理期扩展

资料说明：本章依据已核验的原始论文、官方文档和中文教材展开，来源—论点映射先于本轮扩写建立；重点算法于 2026 年 11 月 1 日续核。数值手算、预算表和任务案例均为本书教学构造，非服务实测。

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

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

本章把“推理能力”和“推理服务”分开。采样、解码、CoT、Self-Consistency、Tree of Thoughts、推理期验证、test-time scaling 和 speculative decoding 属于算法层；RLVR 和验证器训练见第 3 章 3.6 节，GPU 显存、KV cache 分页、continuous batching 和分布式 serving 见第 10 章“推理服务与资源调度”。本章说明这些能力的接口，但不把训练方法或系统吞吐优化冒充推理期算法。

4.1 从一次生成到推理期计算

flowchart LR
 A["输入与固定模型"] --> B["产生候选"]
 B --> C["比较或验证"]
 C --> D{"预算与目标"}
 D -->|继续| B
 D -->|完成| E["输出与证据"]

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

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

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

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

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

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

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

把生成器、选择器与事实来源分开

历史上的方法名称很多，但一次请求中的变化可以归到三个位置。第一处是候选分布：改变提示、提供中间状态或根据反馈修订，可能让模型更容易提出有效答案。第二处是候选集合：固定模型和提示，采样更多完整轨迹，或在某个中间状态分叉，增加可供比较的路径。第三处是选择规则：使用投票、奖励模型或程序检查，从已有候选中挑选输出。三处都可能消耗计算，却不是同一种改进。Snell 等人的 proposer 与 verifier 视角帮助区分候选提出与候选选择；本书进一步把外部事实获取单独列出，以免把新增证据的收益算成纯搜索收益。[11]

例如某道教学题要求根据两段条款计算应付金额。生成器可能没有提出“优惠不可叠加”的解释，也可能已经提出正确解释而被选择器错选。前一种情况下，多候选或更好的分解有机会增加覆盖；后一种情况下，仅增加同质量候选未必有用，需要修正判断条件。如果输入根本没有提供优惠条款，两个组件都不能可靠地凭计算恢复未知业务事实，应先补材料。这里的分类由输入、候选和选择结果决定，不依赖猜测模型是否在“认真思考”。

设事件 \(G\) 表示候选集合中至少存在一个有效答案，事件 \(S\) 表示选择器最终挑中有效答案。如果系统只允许从候选中选输出，则 \(S\) 必须以 \(G\) 为前提，因而有 \(P(S)=P(G)P(S\mid G)\)。这是本书用于分析流水线的概率恒等式，不是假设两个事件独立。它提示我们分别报告候选覆盖与条件选择成功率：只给最后准确率，会把提出能力与辨别能力混成一个数字。

用一组教学假设可以看到这种混淆。某策略在一百道题中有八十道生成过正确候选，却只在其中六十道选中，最终成功率为六成；另一策略只覆盖七十道，但选中六十三道，最终成功率更高。前者更需要检查排序器，后者更需要提高生成覆盖。这里的一百道、八十道等均是演算用计数，并非实测。若选择器还可以改写答案，它本身又成为新的生成阶段，此时要把改写后的集合与检查单独记账，不能继续套用“只能选择”的简化定义。

同样的分解能够澄清几个常被混用的指标。单次成功率描述一次完整策略的结果；至少一个候选通过的比例描述集合覆盖；最佳候选得分描述选择器目标；被最终接纳的比例还受拒答与输出约束影响。高覆盖不保证高选择准确率，高接纳也不保证低错误率。比较论文或服务实验时，要先问被统计的事件是什么，再问采样次数是否相同。

推理期策略还应区分串行和并行计算。延长同一条轨迹，让后一步使用前一步的结果，增加的是串行依赖；同时生成多条完整轨迹，主要增加并行候选宽度。两者消耗相同总 token，也可能有不同墙钟延迟、上下文成本和错误传播方式。一条错误中间状态可能影响其全部后续，而多个独立候选保留了另起路径的机会；但并行候选之间没有自动共享后来发现的反例。这些差别来自依赖图，不能通过一个“推理预算”标量完全表达。

还要把任务目标与语言模型分数分开。模型分布衡量的是在其训练和条件输入下某段文字有多可能，任务验收衡量的是这段文字是否满足题目约束。二者可以相关，但通常不相同。对事实任务，常见表达可能陈旧；对程序任务，常见代码模板可能漏掉边界；对开放创作，最常见的文本又可能缺少新意。搜索算法如果只改善了自身分数，必须进一步证明这种改善能转化为目标任务的收益。

4.2 概率分布与可控解码

flowchart LR
 A["词表分数"] --> B["温度变换"]
 B --> C["语法可行集再截尾"]
 C --> D["归一化与选择"]
 D --> E["更新文本和解析状态"]
 E --> A

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 分布不同，不能用一套参数覆盖所有任务。

温度对分布的影响可以量化。设两个候选的 logit 差为 \(\Delta z\)，温度 \(\tau\) 下它们的概率比为 \(\exp(\Delta z/\tau)\)。温度实际上是在放大或压缩 logit 差：\(\tau<1\) 让差距放大，最高概率项迅速主导；\(\tau>1\) 让差距压缩，尾部候选进入采样范围。这解释了为什么温度改变的不只是“多样性”，还包括概率集中程度。正温度不改变 logit 排序，因而不改变理想 argmax；高温压缩概率差距，但不使有限温度下不同分数严格等概率。

先把温度作用手算一次。假设有限词表只有三个候选，logits 为 \((\log 4,\log 2,0)\)。温度为一时，概率为 \((4/7,2/7,1/7)\)；温度减到二分之一，相当于对原指数项平方，得到 \((16/21,4/21,1/21)\)。候选的次序没有改变，但第一项相对第三项的概率比从四变为十六。若第一项恰是事实错误的续写，低温只会更集中地选择这个错误，不能把集中程度解释成正确率。

温度与熵之间还可给出一个有限支持集上的推导。记 \(\beta=1/\tau\)、\(Z=\sum_i e^{\beta z_i}\)，则熵 \(H=\log Z-\beta E_p[z]\)。由 \(dE_p[z]/d\beta=\operatorname{Var}_p(z)\)，得到 \(dH/d\tau=\operatorname{Var}_p(z)/\tau^3\geq0\)。这里固定的是同一组 logits 和可用项，变化的只有正温度；它不描述生成下一 token 后，随着前缀改变而产生的新分布，也不证明某任务的质量随熵单调变化。

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 不能把不可靠输出变成可靠输出。

top-k 与 top-p 的差别在于候选集合由什么决定。top-k 的集合大小固定：在平坦分布下，较小的 k 会删掉许多同样合理的候选；在尖锐分布下，较大的 k 可能为填满固定名额纳入无用尾部。top-p 的集合大小随分布自适应：分布越尖锐，需要的 token 越少；分布越平坦，纳入的 token 越多。可以用一个教学例子说明：若分布为 \((0.5,0.3,0.15,0.05)\)，\(p=0.9\) 会保留前三项；若分布为 \((0.9,0.05,0.03,0.02)\)，\(p=0.9\) 只保留第一项。后者接近贪心，前者保留了一定探索空间。这也是同一组 top-p 参数在不同任务上效果不同的原因：它依赖分布形状，而分布形状随任务、语言和上下文变化。

截尾与约束的组合顺序也改变结果。假设原概率为 \((0.6,0.25,0.15)\)，第一项被语法禁止，top-p 阈值取教学值零点七。若先选 nucleus，保留前两项，再删除第一项，只剩第二项；若先屏蔽非法项并归一化，得到第二项与第三项的概率分别为零点六二五与零点三七五，为达到阈值就必须保留二者。两条路径最后的支持集不同，因此复现策略时应记录处理顺序，而不只是温度和阈值数字。

这个例子还说明“有效候选”有不同层次。词表截尾按模型分数删除尾部，语法掩码按形式约束删除不可能完成合法文本的项，业务规则可能要等整个字段或整个动作生成后才能检查。前两者能在生成过程中交替执行，后者却不总能被有限的局部掩码准确表达。比如金额字段可以被约束为一个数字，但金额是否超过订单余额，需要外部状态。把外部事实硬编码成一次固定词表屏蔽，可能在状态更新后过期。

本章示意采用先形成语法可行集、再截尾的顺序。若合法集合为空，应报告约束冲突或终止失败；若仅因截尾造成空集，可按事先声明的规则放宽截尾并重新归一化，不能静默放开语法约束。回退策略改变了分布，也是请求配置的一部分。

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

公式要求 \(\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>"}
}

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

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

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

重复惩罚同样应该被当作显式分布变换。它可能依赖整个前缀中某个 token 是否出现，也可能依赖出现次数或局部窗口。于是即便基础模型 logits 相同，历史计数不同也会得到不同的最终采样分布。评估投机采样或前缀复用时，这些状态必须随前缀一起保存；只缓存模型内部状态而忘记惩罚计数，会在算法外部引入不可见差异。对代码变量名、列表分隔符等合法重复，应使用任务断言评估惩罚副作用，而不是仅追求重复率下降。

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

Beam Search 与长度偏差

Beam search 每一步保留概率最高的 \(K_{beam}\) 条前缀，扩展后再裁剪。它比 greedy 能探索更多路径，但原始序列概率、结束符建模与任务目标可能产生长度偏差。实际系统常使用长度归一化或长度惩罚，但惩罚过强会生成冗长答案。

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

长度偏差可以量化。序列 \(y\) 的对数概率是各步对数概率之和，\(\log p(y)=\sum_t\log p(y_t\mid y_{<t})\)。同一前缀继续延伸时概率非增，但这不意味着任意完整长序列都比任意完整短序列概率低：完整候选还包含不同条件下的结束符概率。是否偏向过短输出，应结合模型和终止评分观察。常见修正是长度归一化 \(\frac{1}{|y|^{\alpha}}\log p(y)\)，\(\alpha\) 控制惩罚强度：\(\alpha=0\) 回到原始对数概率，\(\alpha=1\) 按长度平均。\(\alpha\) 过大时，beam 会倾向生成冗长、重复但每一步概率都不低的文本。因此长度惩罚必须与任务可接受的长度范围一起调，评估中要分别报告长度分布，而不是只看最终分数。

束搜索可以用一个很小的概率树解释为何优于贪心仍不等于全局保证。假设第一步候选甲的概率为零点六，乙为零点四；从甲出发最好的后继概率只有零点五，从乙出发最好的后继概率为零点九。贪心选择甲后得到路径概率零点三，而保留两个前缀就有机会找到乙分支的零点三六。这个例子只证明局部最大不必组成路径最大；若正确路径在更早阶段已被束宽限制删除，后续扩展无法恢复它。

中文教材《动手学深度学习》的束搜索章节把贪心、穷举与固定束宽放在同一框架中比较。[16] 在本书推导中，还需明确活跃前缀与已终止候选的区别：活跃前缀可继续扩展，遇到结束符的候选应进入完成集合。若完成集合与活跃集合混用长度分数，短候选可能过早挤占所有位置；若从不保留完成集合，又可能在继续搜索时丢掉已经获得的较好答案。停止条件应根据所用评分规则设计，不能用“出现第一个结束符”代替所有束搜索的结束规则。

长度归一化的方向容易被负号掩盖。假设短序列总对数概率为负二、长度为二，长序列总对数概率为负三、长度为四。按原始对数概率，负二较大；按平均对数概率，前者为负一，后者为负零点七五，排序逆转。除以较大长度会让负值更接近零，因此它可以补偿长序列的累计惩罚，而不是再惩罚一次长度。这里同样是教学分数；是否应该逆转排序，最终仍取决于任务目标和结束符建模。

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

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

约束解码常通过词表屏蔽实现：将语法编译成状态机或下推自动机，依据当前解析状态判断合法续接，把非法 token 的 logit 置为负无穷。token 与语法边界并不重合，合法续接可能一次跨越空白、引号和部分键名；下面按完整字节串检查，而不是限制单个字符。

约束解码需要维护解析状态，而不仅是识别某个字符。假设要求输出只含一个整数金额的对象，模型已产生开括号、键名和冒号，下一 token 可能同时包含空白、数值开头甚至后续标点。解析器必须判断 token 的整个字节串接到当前前缀后是否仍可完成一个合法对象。若只检查 token 的首字符，就可能放过非法后缀；若要求单个 token 独立构成完整语法单元，又会错杀跨边界的合法编码。XGrammar 对 token 与语法边界的错位及栈状态处理给出了一手实现讨论。[17]

还有一种重要区别是“当前前缀没有违反语法”和“在剩余预算内能够完成”。一个未闭合字符串可以是合法前缀，但如果只剩一个 token，而任何可用 token 都无法关闭它，当前策略已经不可能按时产生完整对象。语法引擎通常负责语言可达性，长度预算则是额外约束；若需要严格完成保证，必须联合检查终止可达性，或预留结束空间。达到长度上限后返回截断文本，应记为不完整，而不是因为每一步都通过了局部掩码就算成功。

这些机制在一条请求中会相互作用：温度改变概率质量，截尾改变支持集，语法状态过滤路径，束搜索比较多条前缀，停止规则决定何时交付。合理的最小复现实验应先固定其中大部分，只改变一个因素，检查支持集、归一化结果和完整输出。仅比较最终字符串很难定位哪一层改变了行为；记录局部分布与状态转移，才有可能解释相同模型为何在不同解码配置下表现不同。

4.3 分解、轨迹采样与有界修订

flowchart LR
 A["固定问题"] --> B["轨迹一"]
 A --> C["轨迹二"]
 A --> D["轨迹三"]
 B --> E["答案规范化"]
 C --> E
 D --> E
 E --> F["聚合或外部验证"]

CoT 解决什么问题

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

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

CoT 为什么有效，可以从两个角度理解。其一是计算角度：自回归模型每个 token 经过固定网络深度的一次前向，但注意力工作量仍随上下文和结构变化，较短的直接答案通常只提供较少的显式串行生成步骤；显式写出中间步骤，等于把一部分计算移到 token 序列上，用更长的序列换取更多串行计算。其二是状态角度：中间步骤充当可复用的中间状态，后续步骤可以引用前面已经算出的量，而不必在一个隐藏向量里同时保存所有条件。这也划出了 CoT 的边界：如果任务本身不需要多步组合，或者中间步骤没有真正承载可复用的状态，增加 token 未必带来收益。

不忠实的 CoT 是另一个独立问题。输入偏置可能影响最终答案，解释却没有披露这一影响，甚至为受偏置影响的答案提供合理化论述。关键不是解释是否随答案变化，而是它是否忠实反映影响答案的因素。因此可见步骤可以作为待核查材料，却不能单独证明决策依据，结论仍需独立检查。

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

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

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

分解是否有效，可以用一个不需要外部知识的教学计算检验。假设订单有三件商品，每件标价八十元，先按商品总额打九折，再收十二元运费；优惠不作用于运费。直接跳到总额时，候选可能把运费也打折。可检查的分解应保留三个量：商品原额二百四十元，优惠后商品额二百一十六元，最终应付二百二十八元。每个量都有单位和前提，错误可以定位到优惠基数，而不是只得到“答案不对”的整体反馈。

这个例子不是要求模型公开不可见的内部推理，而是要求输出或内部工作记录包含足以验证的中间结果。中间结果可以是表格、表达式或程序输出，不必是一大段自然语言。若子问题只写成“先认真理解，再认真计算”，没有暴露任何可检验量，就没有建立更强的验收接口。相反，若细分到每个字符都调用一次模型，调度与上下文开销又会超过收益。合适粒度是能独立判断的事实或状态变化。

分解也会引入新的接口错误。第一步输出“折扣后金额”却没有说明是否含运费，第二步便可能再次加运费；一段中间文本正确，合成答案仍然错误。为避免这种组合失败，状态应至少保留对象、数值、单位和适用条件。若使用工具求值，还应区分表达式来自哪里、计算器验证了什么：计算器能证明给定表达式的算术结果，却不能证明表达式正确代表题意。

多轨迹采样

Self-Consistency 对同一问题采样多条 CoT，再聚合最终答案 [4]。一致性提供的是答案分布信息；只有正确答案在相应聚合规则下占优等条件成立时，增加样本才可能提高正确率。共享错误前提也可能使错误答案稳定占优。采样温度、轨迹数量、答案规范化和投票规则都会影响效果。

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

多轨迹聚合可以沿同一个例子展开。假设五条教学候选分别输出二百二十八、二百二十八元、二二八、二百二十六点八和“信息不足”。前三条文本不同，但在题目单位明确且解析规则预先固定时可以归入同一答案桶；第四条反映了把运费也打折的错误；最后一条应保留为拒答或未完成状态。规范化不能把无法解析的文本强制映射到某个常见数字，也不能忽略币种、正负号和数量级。

如果答案规范化需要由另一个模型完成，它便成为整个策略的一部分，需要自己的版本、成本和错误检查。对可解析的数值，优先采用确定的规则；对代数表达式，要在题目定义域内检查等价，而不是只比较显示文本；对程序，行为等价通常更难，不能把在一组小测试上的相同输出当作全面等价。规范化越强，越可能降低无意义的票数分散，也越可能错误合并本来不同的答案。

在固定题目与固定采样策略下，令每条独立轨迹正确概率为 \(p\)。对奇数 \(n\)，严格多数正确的概率为 \[ \sum_{k=(n+1)/2}^{n}\binom{n}{k}p^k(1-p)^{n-k}. \] 例如教学假设 \(p=0.6,n=3\)，结果为 \(3(0.6)^2(0.4)+(0.6)^3=0.648\)。若 \(p=0.4\)，同样计算得到零点三五二，反而低于单条正确率。这个模型把所有错误合为一类，并限定奇数样本以避开平票处理；偶数样本若要求严格过半，新增一条样本不保证比前一个奇数样本更好。

实际答案往往不止两类。假设正确答案概率为零点四，两个错误答案各为零点三；随着独立样本数增加，正确答案可以越来越稳定地成为众数，即使它没有超过二分之一。若一个错误答案本身占零点六，众数投票则会更稳定地选择错误。由此可见，二元多数的条件不能直接套到多类别众数上；需要观察错误质量是分散在许多答案上，还是集中到一个系统性错误。

轨迹独立性与错误机制也必须分开。固定问题和提示后，独立随机抽样可以产生条件独立轨迹，但这些轨迹都来自同一有偏分布。若混合很多难度不同的问题后计算相关性，困难题会让多个样本同时失败，这不证明单题条件采样必然依赖。另一方面，先抽一条随机前缀再复制到多个分支，或让后续候选读前一个候选的结论，确实改变了联合分布。报告采样实验时应说明随机性在哪一级独立、哪些状态被共享。

候选覆盖率提供另一个更弱但有用的上界。在上述独立固定概率假设下，至少生成一个正确候选的概率为 \(1-(1-p)^n\)。当教学值 \(p=0.2,n=5\) 时，它约为零点六七二；这不等于投票正确率，更不等于一个不完美验证器的最终选择率。增加候选能使覆盖提高，却可能让选择问题更困难。应同时保存每题候选集与最后被选项，才能分清没有生成正确答案和生成后没有选中。

Self-Refine 与迭代修正

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

修订则与独立采样不同。新候选以旧答案和反馈为条件，目标是有方向地改变分布，而不是再抽一张互不相关的票。反馈若包含明确反例，可以排除某类错误；若只说“再想想”，模型可能把原本正确答案改错。Huang 等人在所测推理任务中讨论了缺乏外部反馈时内在自纠错的困难；这与 Self-Refine 在其他任务与反馈设置中的结果并不矛盾，比较时必须保留任务和反馈条件。[21]

在订单例子中，第一轮把全部金额乘折扣后得到二百二十六点八；反馈应指出“运费不参与折扣”这一约束，并给出能区分两种公式的输入，而不是只公布期望答案。下一轮若改成二百二十八，还需要验证商品数量变化和零运费等情况。公开反馈中的测试负责指导搜索，最终留出的测试负责估计泛化；不能每轮向候选暴露最终测试答案，再把最终通过率当作独立证据。

为避免修订漂移，状态应保存当前最优且已验证的候选，而不是永远用最新文本覆盖它。若新候选使一个先前通过的边界重新失败，应回退或保留两个分支待比较；若两轮反馈完全相同而候选没有结构性变化，应消耗停止预算，而不是将改写措辞算作进展。这些规则是本书对有界修订的工程设计，实际收益仍应与同预算的独立多候选策略比较。

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

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

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

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

4.4 搜索状态与验证器

flowchart TD
 A["状态与约束"] --> B["扩展候选"]
 B --> C["启发式评分"]
 C --> D["保留分支"]
 D --> B
 D --> E["终止候选的独立检查"]
 E --> F["有效结果或反例"]

Tree of Thoughts

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

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

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

要让搜索可执行，先把“思路”定义成能够改变问题状态的操作。以下用教学任务“用给定数字和四则运算构造目标值”作局部例子。状态包含尚未使用的数字、多步表达式以及每个中间值的来源；动作选择两个已有值和一种运算，将结果放回集合。终止条件不是文本声称“完成”，而是所有原数字恰好使用规定次数、表达式合法、求值等于目标。这样生成器只负责提出动作，状态转移与终止检查可以由确定的程序执行。

如果状态只保存当前数值而丢掉来源，两个同为六的中间量可能使用了不同的原数字，错误合并后会重复用数。若只保存完整自然语言，又很难判断两条路径是否等价。一个可用表示需要同时保留规范化数值和表达式来源；交换律能减少部分重复，但除法、减法的顺序不能被随意交换。这个例子说明状态去重首先是语义设计，哈希只是最后的存储手段。

再看剪枝的教学反例。根状态扩展甲、乙两条路线，启发式分别给零点九和零点六；甲在下一步被约束证明不可行，乙却能到达目标。全局束宽为一时，乙在第一轮已经消失；束宽为二时才有机会保留。增大束宽的价值来自保留启发式暂时低估的路径，而不是让每个候选本身更正确。如果启发式对所有可行路线都持续误判，单纯加宽可能只延迟失败，需要改变评价信息。

这一框架也解释树与图的差别。树保留每条路径的独立历史，便于追踪但可能重复计算；图尝试让多个路径共享同一中间结论，减少重复，却要求证明这些路径对该结论具有相同前提。若一个节点后来被修正，其后继不能自动沿用旧验证结果。逻辑图可以有反馈环，但一次具体执行中的每次读取、修订和检查应带版本，避免“结论依赖自己”在记录中伪装成外部支持。

结果验证器

结果验证器只判断最终结果是否满足条件。代码题可以运行用于搜索反馈的可见测试，最终留出测试应另行隔离，数学题可以检查数值或符号答案，SQL 可以在只读数据库比较结果，规划任务可以检查环境状态。Cobbe 等人的研究训练 verifier 来区分数学答案 [8]；本节把训练完成并冻结版本的 verifier 当作推理期组件，用于候选过滤、排序和停止判断。验证器的训练、奖励构造与防投机要求见第 3 章 3.6 节。

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

过程验证器对中间步骤给分。Let’s Verify Step by Step 比较了结果监督与过程监督，并用逐步反馈训练过程奖励模型 [9]。进入推理阶段后，这类已训练的过程验证器可以为搜索状态打分、决定优先扩展或剪枝；它的分数只表示验证器偏好，不能当作步骤正确性的证明。

推理时可以组合两种信号：过程分用于引导搜索，结果检查用于筛选最终候选；如果两者冲突，须回到任务的验收定义：证明题不能用最终答案相同覆盖错误证明，代码也不能用少量可见测试覆盖缺失的需求条件。发布或执行有副作用的动作仍需独立门禁，不能由 verifier 分数直接授权。

验证器本身也会失败，常见形态有四种。覆盖不足：测试集没有覆盖边界条件，错误的候选通过了验证。解析漏洞：验证器只比较最终数值，不检查约束，候选可以满足格式却违反语义。搜索利用漏洞：当搜索反复以同一验证器分数挑选候选时，最终可能选中钻过测试盲区的答案。版本漂移：验证器、测试集或业务规则更新后，旧结论不再成立。因此推理记录必须绑定 verifier 版本，保存误报率、漏报率和覆盖范围，并定期用人工样本抽查。

SelfCheckGPT 利用多个采样结果之间的一致性，检测事实陈述可能存在的幻觉 [22]。如果相同问题的独立样本对一个事实说法差异很大，说明采样输出不一致，可作为风险线索；但一致性不代表真实，一个模型可以稳定重复错误。Ji 等人的综述梳理了自然语言生成中的幻觉问题与检测研究 [23]；本书在诊断时另行记录事实错误、依据缺失和上下文冲突，避免将不同失败混作同一指标。

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

过程分如何汇总也会改变排序。Lightman 等人的附录比较了取最小分与分步分数乘积等方案，并在该研究中采用乘积。[9] 这是一种评分设计，不能未经校准就解释成整条证明客观正确的概率。假设一个候选有两个步骤，各得零点九，乘积为零点八一；另一候选将同样论证细分为四步，各得零点九五，乘积约为零点八一四五。细分后排序可能变化，表明分数依赖步骤划分与评分器，而不只依赖数学有效性。

取最小分强调最薄弱步骤，却可能忽略许多中等风险累计；取乘积更容易惩罚长轨迹；取平均可能让一个关键错误被许多容易步骤冲淡。选择聚合方式时，应固定步骤切分协议，在验证集上比较排序准确率与长度偏差。若候选可以自由拆分或合并步骤，搜索器还可能通过改变表达形式提高分数，而没有改变推理质量。这是评价接口的一部分，不能只调一个最终阈值。

验证器的错误率也要放在搜索强度下理解。假设一组确定错误的候选独立地以概率 \(f\) 被误接纳，则 \(n\) 个错误候选至少一个通过的概率为 \(1-(1-f)^n\)。教学值 \(f=0.01,n=100\) 时，这个概率约为零点六三四。它不是任何实际服务的事故率：自适应搜索通常不满足独立同分布，候选之间也可能共享漏洞；这个演算只是说明很小的单候选漏检并不自动意味着大规模筛选安全。

奖励过优化研究进一步提醒，持续优化一个不完美代理分数可能损害真正目标；Gao 等人的研究用合成 gold/proxy 奖励设置考察了这一现象，不能把其中的 gold 模型说成真实人类真值。[24] 对本书的搜索器而言，直接推导出的设计要求是区分用于引导搜索的可见评分和用于最终估计质量的留出评估。若每次失败都把留出答案反馈给生成器，该集合已经成为训练或搜索条件，应建立新的独立评估。

一个有用的失败记录应同时包含生成器是否提出有效路线、搜索器是否保留它、验证器是否正确判断，以及最终选择是否遵守判断。只记录“失败”无法知道预算该加在何处。若有效候选被早剪，改进启发式或增加有限宽度更相关；若全部候选都有相同错误前提，应补输入或改变提出策略；若错误候选绕过测试，扩大搜索可能放大测试盲区，也可能发现真正有效的候选，净收益仍取决于覆盖改善与选择错误。这个因果分解把搜索算法从反复调用模型变成可以审查的决策过程。

搜索复杂度与剪枝策略

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

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

复杂度必须区分逐父节点限宽与全层固定束宽。完整 b 叉树深度 d 的节点总数为几何和，量级为 O(b^d)；每个父节点减少子分支才有相应指数缩减。若每层全局仅保留 K 个状态、每状态扩展 b 个候选，候选扩展量约为 O(dKb)，不是 O(b^d)。较小的 K 节省预算，也可能过早删掉正确路径；应记录剪枝位置与反例，而不能把两种限宽规则混用。

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

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

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

因此评估应比较四种配置：基础模型单次生成、后训练模型单次生成、后训练模型加采样、后训练模型加验证或搜索。这样才能知道收益来自训练、额外计算还是验收机制。DeepSeek-R1 展示了强化学习形成推理行为的路线，但生产系统仍需要按预算和风险动态决定是否启动外部搜索 [10]。训练侧的可验证奖励和 GRPO 见第 3 章 3.6 节。

4.5 投机解码的分布与成本

flowchart LR
 A["已接受前缀"] --> B["草稿连续提出候选"]
 B --> C["目标模型并行评分"]
 C --> D{"逐项接受"}
 D -->|首次拒绝| E["丢弃后缀并从残差补采"]
 D -->|全部接受| F["目标分布再采一项"]
 E --> A
 F --> A

Speculative Decoding

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

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

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

正确性条件可以用接受概率写清。设 draft 分布在位置 \(t\) 给出概率 \(q(x)\)，target 给出 \(p(x)\)。采样一个 draft token \(x\sim q\)，以概率 \(\min(1,p(x)/q(x))\) 接受；被拒绝时，从残差分布 \(\operatorname{norm}(\max(0,p-q))\) 重新采样。这样最终采样分布恰好等于 target 分布 \(p\)——加速不改变目标分布，这是它区别于“用小模型近似大模型”的关键。在其他成本不变的简化条件下，较高接受率通常增加有效输出；\(p\) 与 \(q\) 接近时接受率高，差异大时接受率降低，草稿成本可能超过节省，具体仍取决于块长和草稿、验证的实际成本。所以选择 draft 模型要看它在目标任务分布上的接受率，而不是它在通用基准上的质量。

逐 token 的接受规则可以直接证明，而不必凭“两个模型通常相同”来解释。以下推导固定一个已经接受的前缀，并把其条件记号暂时省略。草稿提出某个 token 的概率是 \(q(x)\)，它被接受并输出的概率质量因此为 \(q(x)\min(1,p(x)/q(x))=\min(p(x),q(x))\)。把所有 token 的这部分质量加起来，得到本步接受概率 \(A=\sum_x\min(p(x),q(x))\)。尚缺的目标概率质量恰好是 \(p(x)-\min(p(x),q(x))=\max(0,p(x)-q(x))\)，总和为 \(1-A\)。拒绝发生的概率也是 \(1-A\)，因此从这个差额归一化后的分布补采，就逐项补足了目标分布。这个证明讨论分布，不讨论单个候选是否在语义上正确。[25]

用一个本书构造的三项词表手算。设目标分布为 \((0.5,0.3,0.2)\)，草稿分布为 \((0.7,0.2,0.1)\)。第一项的接受概率是 \(5/7\)，第二、三项必然接受。最终经接受路径输出的质量是 \((0.5,0.2,0.1)\)，总接受率为 \(0.8\)；拒绝率为 \(0.2\)，残差分布为 \((0,0.5,0.5)\)。拒绝路径于是分别向第二、三项补上 \(0.1\)，合计恢复 \((0.5,0.3,0.2)\)。若拒绝后直接按目标分布重采而不使用残差，结果会变成 \((0.6,0.26,0.14)\)，第一项反而被重复计算。这一反例说明“拒绝后让大模型随便重新生成”缺少了关键的概率校正。

边界情形也必须显式处理。若某项 \(q(x)=0\)，草稿不会提出它，不应计算零分母的接受比；目标给它的质量通过拒绝后的残差获得。若 \(p=q\)，所有候选均接受，残差总质量为零，程序不能尝试归一化这个零向量。在有限精度下，如果非常小的差额被舍入，理论上的非负性、和为一以及采样实现都需要一致的数值处理；不能先随意截断概率，再继续声称实现与理想算法完全一致。零温贪心可被视为确定性目标分布的特例，但具体实现通常直接检查草稿 token 是否等于目标的贪心选择，并固定并列裁决规则。

这里的 \(p\) 和 \(q\) 必须是实际采样用的分布。若目标请求启用了温度、top-p、重复惩罚或语法约束，目标分布就是这些处理按约定顺序完成并归一化后的结果；若草稿也有采样处理，接受率分母则必须来自其真正提出 token 时的分布。不能用原始 softmax 概率去校正已经截尾的草稿，也不能在接受后再静默换一个温度。尤其在状态化约束下，语法状态和重复计数必须对应同一个已接受前缀。候选分布可以不同，证明不要求二者具有相同支持集；但支持差异会影响接受率与实现成本。

把单步证明扩展到一个块时，条件前缀成为重点。假设草稿连续提出三项。目标模型可以通过因果掩码，在一次前向中计算这些假设前缀对应的三个条件分布，并获得完整草稿后再下一项的分布。它不是把三个 token 当成相互独立的结果一起决定；各位置仍然条件于此前的草稿项。验证必须从左向右进行。只有前面的项都接受，当前位置所用的假设前缀才与最终输出前缀一致。遇到首次拒绝后，残差补采得到新的 token，后面的草稿及其概率就属于另一个历史，必须丢弃。

例如草稿提出“甲、乙、丙”，第一项接受，第二项拒绝并补成“丁”，第三项的目标概率是在“甲、乙”之后计算，不能拿来决定“甲、丁”后的输出。即使丙字面上仍然很合理，也必须重新计算条件分布。缓存处理同样遵循这一因果关系：保留已接受前缀的有效状态，截断拒绝位置及其后的假设缓存，再把补采项纳入后续计算。若三项全接受，可以从已得到的目标下一项分布再采一项；它没有草稿提出过程，不再应用同一轮的草稿接受比。遇到合法终止符时则直接结束，不为凑满块继续生成。

“保持分布”也不等于“相同随机种子输出逐字相同”。直接目标采样与投机算法消耗随机数的次数、顺序和用途不同：后者还为接受判断和残差采样使用随机数。两种算法可以拥有相同的输出分布，却在同一个种子下得到不同的一条文本。验证实现应先用可枚举的小词表检查概率质量，再在固定条件下比较统计分布；逐字一致测试只适用于额外规定了随机数耦合方式的实现，不能替代一般正确性要求。这个区分也解释了为什么速度测试与任务质量测试应分开：同分布算法不会凭空提高目标模型的数学正确率。

从接受率到账面收益

下面用简化成本模型理解速度条件，不把它当作硬件实测。令一次目标逐 token 调用的时间为 \(T\)，草稿生成一项为 \(cT\)，每轮草稿长度为 \(\gamma\)。假定每个位置独立以相同概率 \(\alpha\) 被接受，并假定目标并行验证整块仍花约 \(T\)。一轮可输出的期望项数是 \(1+\alpha+\alpha^2+\cdots+\alpha^\gamma\)，其中至少输出的一项来自首次拒绝的补采，或全部接受后的追加项。因此理想速度比为该几何和除以 \(1+\gamma c\)。这与原论文的简化分析一致，其独立性和目标成本假设不能直接照搬到生产。[25]

取教学参数 \(\gamma=3,\alpha=0.8,c=0.1\)，期望输出为 \(2.952\) 项，成本为 \(1.3T\)，理想速度比约为 \(2.27\)。若接受率仍为 \(0.8\)，但草稿成本升为 \(0.6T\)，速度比就只约为 \(1.05\)。再若目标验证整块实际需要 \(1.6T\)，后一个配置会变为 \(2.952/(1.8+1.6)\)，约为 \(0.87\)，比直接解码更慢。三个数字组合只是模型演算，却足以说明高接受率不是加速的充分条件。

块长也不是越大越好。后部 token 只有在前面连续接受时才可能被保留，增加一项的期望收益在这一模型中按 \(\alpha^\gamma\) 衰减，而草稿成本仍然增加。在真实请求中，接受率还会随着题材、上下文和生成位置变化；拒绝可能集中发生在格式切换、罕见标识符或数字处。一个全局平均接受率可能掩盖长串连续接受与频繁早拒绝两种完全不同的情况，因此需要记录每轮有效输出长度、首次拒绝位置和实际验证时长。

硬件层还存在与算法证明正交的约束。目标模型原本受权重读取限制时，一次读入权重并计算多个位置可能较有利；若批处理已经充分占用计算资源，额外验证位置可能消耗本可用于其他请求的算力。草稿自身占用显存、缓存和调度时间，还可能改变并发容量。因而单请求延迟降低、总吞吐提高、总浮点运算减少是三个不同命题，投机解码不同时保证三者。上线比较必须固定目标采样语义与业务请求分布，分别观察用户等待、服务容量和资源消耗，不能只报告最顺利文本上的连续接受长度。

Blockwise 与并行预测

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

4.6 预算分配与任务验收

flowchart TD
 A["输入与初始预算"] --> B["估计难度与策略开销"]
 B --> C["分配生成与验证预算"]
 C --> D["运行并观察"]
 D --> E{"目标或停止条件"}
 E -->|继续| C
 E -->|完成或耗尽| F["交付结果及停止状态"]

预算的组成

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

\[ \mathbf{C}=(N_{gen},N_{score},N_{verify},N_{tool},T_{GPU},T_{wall}). \]

各分量分别记录生成和评分 token、验证与工具次数、计算时间和墙钟时间。只有明确单价或归一化权重后才能合成成本标量；墙钟截止时间还应作为独立约束，避免重复计费。

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

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

如果错误来自输入中缺失的事实，单纯增加闭卷采样不能可靠补足它；如果错误来自搜索路径、算术步骤或偶然采样，增加预算可能有效；如果验证器不可靠，更多候选的覆盖收益可能被选择错误抵消，同时增加验证成本；如果任务本身没有可判定目标，长 CoT 可能只是生成更多解释。

固定策略增加预算的成功率不保证单调或凹：修订可能把正确候选改错，选择压力可能利用验证盲区。因此应测量每个策略的成功率—成本曲线，并区分它与“预算内可选择策略的最优包络”。部署只能根据可观测特征估计下一步收益，不能假装知道尚未产生候选的真值。

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

Reasoning RL、GRPO、PPO 和蒸馏属于训练方法：DeepSeekMath 提出 GRPO，并在其强化学习实验中使用训练得到的奖励模型；这不同于直接用规则验证器产生奖励 [28]，DeepSeek-R1 展示了冷启动、强化学习与蒸馏的组合路线 [10]，PPO 提供更通用的策略优化基础 [29]。这些目标和训练风险由第 3 章负责，本章只讨论训练后模型在一次请求中怎样使用采样、搜索和验证预算。

训练后的模型可能用较少候选产生更有效的轨迹，也可能继续生成稳定但错误的路径。因此部署评估要把模型版本与推理策略拆开比较：固定推理预算比较不同训练版本，再固定模型比较单次生成、多候选、验证和搜索。只有这样才能判断收益来自权重变化还是额外推理计算。

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

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

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

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

回溯是搜索区别于普通 CoT 的重要能力。普通生成一旦写出错误前提，后续 token 通常继续围绕错误展开；搜索可以保留多个候选，在验证失败时退回最近的分叉点。回溯需要保存状态快照和依赖关系，不能简单把错误文本追加到上下文后要求模型“重新想一遍”。回溯保存的是算法状态；它不会撤销真实世界里已经发生的动作。

把前面的方法组合成一次请求的策略时，先判断错误的来源，再选择对应手段。格式类错误用约束解码与 schema 校验；可验证的推理错误用多候选加验证器；知识缺失用检索；搜索路径错误用采样与搜索；预算或延迟受限时用路由与预算控制。

采样和搜索帮助生成候选，验证器决定候选是否满足可检查约束；三者都要在明确的预算与停止条件下运行，并把停止原因写入记录。

预算优化可以写成一个受约束的决策问题。给定任务可观测特征 \(x\)，策略 \(\pi\) 决定生成、验证、检索与停止动作；希望最大化成功概率，同时满足费用和截止时间约束。这里的“成功”必须由事先冻结的验收定义，而不是由策略自己输出的自信分数决定。若把成功收益与费用合成效用，也要声明错误代价、超时损失和计费权重。对数学练习，错一题与晚一秒的权重可能较低；对自动修改生产配置，两者的代价完全不同。不存在脱离任务损失函数的统一最优推理长度。

考虑一个本书构造的折扣计算服务。输入包含商品数量、单价、折扣作用范围和运费，输出包含最终金额与可核验表达式。服务有三条候选路径：一次生成后检查表达式；生成三个候选再检查并选择；先查询缺失的活动规则，再生成并检查。第一条路径解决常见输入，第二条增加候选覆盖，第三条补足缺失事实。它们不是从便宜到昂贵的单一能力阶梯：缺少折扣范围时，第二条即使采样很多次也只是猜测规则；规则完整但偶发算错时，第三条反而重复获取已有信息。

假设开发集中的一百个任务被人工核验为三类：六十个规则完整且计算简单，二十五个规则完整但组合复杂，十五个缺少规则。以下表中全部数字都是教学假设，用于展示算账方式，不代表任何模型测量。单位成本统一指已经按内部单价换算后的费用，不包含墙钟时间。

全量单次策略的成功数是七十五，费用是一百；全量三候选成功八十四，费用三百。若有一个暂且假设完美的路由器，让三组分别走第一、第二、第三条路径，成功数为九十二，费用为一百六十五。这不是证明实际路由一定有效，而是说明额外计算应与错误类型匹配。这里是忽略类别识别错误与探测成本的理想分组对照，不是所有策略的成功率上界；部署也不能直接看到任务真实类别。实际路由器只看到字段是否缺失、表达式结构、初次验证结果等特征，其误判和额外成本都要计入。

进一步假设路由器把五个简单任务错分到三候选路径，把三个缺规则任务错分到单次路径。前一种错误主要增加费用，后一种错误则可能直接失去关键事实。两个分类错误在混淆矩阵中都算一次，但对任务成功和成本的影响不同。因此路由优化不能只追求类别准确率；应在独立评估集上按最终任务效用比较完整链路。若某条路径的成功率只是从很小的开发样本估计，路由器还可能过拟合偶然差异，需要报告不确定范围，而不是把表中的一个百分点差距视为确定收益。

Snell 等人的研究说明，按问题难度与方法特点分配计算具有研究价值；但研究中的难度估计不能不加成本地复制到在线服务。其一种预测难度分析使用大量样本的过程奖励均值，并在该分析中忽略这项估计开销，作者也讨论了更便宜预测器的必要性。[11] 本书据此强调：所谓“先判断难度”本身是一个算法调用。若为了省下两条轨迹，先生成了几十条轨迹估计难度，账面上的节省就可能消失。线上应使用能够获得的特征，并将预测器的时间、费用和错误纳入同一预算。

预算还存在时间结构。三个候选若串行执行，墙钟时间接近各路径之和；若并行执行，理想情况下接近最慢路径，但总 token 和验证费用并未相应减少，并发资源不足时还会排队。先检索后生成属于数据依赖，不能简单通过并行绕过；与问题无关的独立资料预取可以并行，却可能做无效工作。因此总成本是各操作的累加，关键路径延迟则由依赖图决定，把二者合成一个“计算量”会掩盖最重要的取舍。

一个可执行的截止时间策略应从验收动作倒推。假设请求总时限为十秒，表达式验证和结果封装预留两秒，那么生成器不能一直运行到第十秒再开始检查。若第一条候选在第四秒生成，验证发现单位错误，剩余时间是否足够修订取决于实际尾延迟；不能仅用平均耗时判断。下一步动作的预计成本超过剩余预算时，可以交付已验证候选、返回缺少规则的明确状态，或终止本次任务。停止状态应与“结果正确”分开记录，预算耗尽但未验证的文本不能自动升级为成功答案。这些时限仍是教学设定，真实预留量应由目标服务测量决定。

自适应停止也会影响评估。在“看到验证通过就停止”的策略中，成功样本通常消耗较少，困难失败样本可能一直用完预算。只统计成功请求的平均成本，会把失败探索的费用排除，导致单位成功成本被低估。正确的账本应把所有请求的费用相加，再除以成功请求数，并另报失败和超时分布；若还要研究单次成功的用户体验，可以同时报告成功条件下的延迟，但不能把两种统计混为一谈。

另一方面，保留当前最好候选并不保证真实正确率随预算单调。它只能保证被使用的选择分数不下降，前提还是比较规则固定；如果验证器把某个漏洞打成高分，更多搜索可能替换掉原来正确的答案。对强制性约束，可以先采用解析、类型、可见测试等硬门槛，再在合格候选中按质量排序；对无法完整形式化的质量目标，则要承认验证器仍有误差，并用独立留出集测量实际收益。预算曲线应分别展示候选覆盖、验证器选择成功率和端到端成功率，才能分辨瓶颈在哪里。

评估协议还应防止在同一数据上反复挑选最好的预算。先用开发集调整温度、候选数、束宽、验证阈值与停止规则，再冻结方案到留出测试集比较。若测试结果又用于修改策略，这份测试集便承担了开发反馈作用，需要新的留出评估。比较不同模型时应固定或明确换算费用、延迟与资源约束；“每个请求同样采样三次”并不意味着模型间计算预算相同。对于上下文缓存、共享前缀和并行验证，还要说明采用的是实际计费、设备时间还是理论运算量，避免同一张曲线横轴含义不断变化。

最后，任务切片应保留失败的具体原因。金额案例中，缺规则、选错折扣对象、算术错误、输出解析失败和验证器误放行分别对应不同改进方向。只记录“答错”会促使团队盲目增加候选；只记录“验证通过”又会掩盖验证器自己的盲区。将输入事实、采用的规则版本、候选表达式、可见验证反馈、最终结果和停止状态连接起来，才能复现某一次预算决策。这里需要的是短而可核查的证据链，不是要求公开冗长的内部思考文本。

语言与格式的差异

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

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

本章小结

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

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

参考资料

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

第5章 从零训练一个 LLM：一条可复现的工程路径

前四章分别解释了 Transformer 的一次前向计算、预训练如何形成基础能力、后训练如何塑造行为，以及推理期怎样用额外计算改善候选结果。本章把这些原理收束成一次可以立项、执行、恢复和验收的训练工程：先证明为什么需要从随机初始化开始，再把参数、数据、计算和显存放进同一份预算，最后用训练记录和分层评估说明模型究竟学到了什么。

本章讨论两个尺度。第一个是仓库中可以在普通开发环境运行的字符级 GPT 实验，用来观察 next-token prediction、因果注意力、反向传播、评估和生成的完整闭环。第二个是 1,147,766,784 参数、230 亿 token 的教学计划，用来练习真实项目中的预算和门禁。后者只是一组经过复算的设计值，本书没有执行这次大规模训练，也没有测得相应的吞吐、时长或能力结果。

文中的数字分为三类：引用公开论文或项目记录的事实；由明确公式得到的教学算例；需要在目标环境实测后才能决定的工程参数。三者不能互相替代。公开项目可以说明训练配方和数量级，却不能证明本书的计划会得到相同结果。

5.1 立项与可审计的训练预算

flowchart TD
 A["可测目标与现有基线"] --> P["结构与参数账本"]
 P --> C["有效 token 与计算口径"]
 C --> M["状态与激活显存"]
 C --> T["吞吐与时长假设"]
 M --> V["目标环境容量短跑"]
 T --> V
 V --> D["决定启动规模与停止条件"]

从零训练意味着模型参数从随机初始化开始，通过预训练语料学习 token 的条件分布。它交付的是基础模型及其训练证据，而不是天然会对话、能访问实时事实或拥有工具权限的助手。第 2 章 已经区分预训练、继续预训练和后训练；第 3 章进一步解释 SFT 与偏好优化。本章只负责从训练立项到基础模型验收的工程闭环。

先证明“从零”是必要变量

从零训练通常有四类合理目标：

• 教学或研究需要完整观察数据、模型、优化器和评估之间的因果关系；
• 目标语言、领域或符号体系与现有模型的 Tokenizer 和预训练分布差距很大；
• 模型结构、参数规模或部署形态有明确约束，现有权重无法满足；
• 数据来源、训练过程和中间制品需要由团队完整掌握，以支持审计或复现实验。

立项之前应建立一个成本更低的基线。知识需要实时更新时，先比较检索；模型已经懂任务但输出协议不稳定时，先比较 SFT 或约束解码；只需降低延迟时，先比较更小的现有模型、量化和推理优化。若这些基线已经满足验收条件，从零训练便没有可解释的增量目标。

一份合格的立项说明至少回答：现有模型在哪些冻结测试集上失败；失败来自知识、Tokenizer、结构还是行为；从零训练准备改变哪个变量；成功门槛是什么；预算耗尽但没有达到门槛时怎样停止。没有这些条件，训练结束后只能看到一个新的 checkpoint，却无法说明这笔计算换来了什么。

TinyLlama 公开了 1.1B 小型语言模型的训练路线，可用于观察小模型怎样采用成熟的 Llama 类结构与大规模语料。[1] 本章以固定版本论文说明预算原则，以本地字符 GPT 的固定代码基线说明实现边界，不用移动的项目 README 推导性能。

这些项目没有替本章完成复现。硬件、数据、框架版本、算子、训练 token 和评估脚本只要有一项不同，时长和质量就不能直接横向比较。公开记录用于提出可检验假设，目标环境中的结论仍需本项目证据。

Transformer 用注意力和逐位置前馈网络处理序列，原始论文奠定了这条可并行训练的结构路线。[2] 但“模型定义正确”只是训练成功的一个前提。完整工程还需要把以下证据连接起来：

这张表也是本章的责任边界：第 1、2 章提供结构和预训练理论，第 5 章把它们变成一次可验收执行；分布式训练框架的内部实现留给后续 Infra 章节。

训练预算应先固定参数量 \(P\)、训练 token 数 \(N_{\mathrm{tok}}\)、上下文长度 \(T\)、全局批大小和可用设备，再决定训练日程。Chinchilla 的工作说明，在给定训练计算下，模型规模与训练数据需要联合配置；它并没有规定所有项目都必须永久采用一个固定的“每参数 token 数”。[3] 将预期推理成本纳入目标后，较小模型训练更多 token 可能更经济。[4] 当唯一数据不足时，重复使用也存在收益递减，必须在自己的数据与规模上测量。[5]

参数计数：先写假设，再报总数

教学计划采用一个现代 Decoder-only 配置：

忽略线性层 bias，使用两组 RMSNorm 参数。GQA 注意力的 Q、K、V 和输出投影参数合计为

\[ P_{\mathrm{attn}} =D d_h\left(2H_q+2H_{kv}\right). \]

式中第一个 \(H_q\) 来自 Q，两个 \(H_{kv}\) 来自 K/V，第二个 \(H_q\) 来自输出投影。SwiGLU 使用 gate、up、down 三个矩阵，参数为 \(3DD_{ff}\)。逐项结果是：

若输出投影不与输入 Embedding 共享，还需增加 65,536,000 个参数，总计 1,213,302,784。这个差异必须写进配置，不能只用“约 1.15B”掩盖权重共享假设。

FLOP 口径与训练时长

本章把一次浮点乘法和一次浮点加法各计为 1 FLOP，因此矩阵乘法的一个 multiply-add 计 2 FLOPs。对 Dense Transformer，\(6PN_{\mathrm{tok}}\) 是常用的模型参数相关训练 FLOPs 粗估：前向约 \(2P\)，反向约为前向的两倍。它没有精确覆盖注意力分数计算、激活重计算、Embedding 查表、归一化、优化器和通信。此处假定近似全监督、没有大量补齐，监督目标数近似实际执行的 token 位置数；loss mask 为零的位置仍可能参与前向与反向，padding 也可能占用稠密计算。存在这些开销时，应分别记录监督 token 与执行位置，按实际形状估算计算，不能直接用监督计数代替全部算力。

为显式表示长序列注意力的影响，本书使用教学近似：

\[ F_{\mathrm{tok}} \approx 6P+\kappa LTD,\qquad \kappa\in[6,12]. \]

\(\kappa=12\) 近似完整计算 QK 与 AV 的前向和反向；\(\kappa=6\) 表示实现利用因果三角结构跳过约一半分数计算。不同内核的实际执行量可能偏离这个区间。激活检查点带来的重计算属于硬件实际执行 FLOPs；若性能报告的“模型 FLOPs”仍采用理论前向—反向口径，就不能把重计算悄悄加入 MFU 分子。

教学计划固定 \(N_{\mathrm{tok}}=23{,}000{,}000{,}000\)，它不是精确的 \(20P\)：后者为 22,955,335,680。230 亿 token 相当于每参数约 20.039 个 token。复算得到：

为演示时长换算，假设 8 个加速器、每个设备的计算峰值取 \(3.12\times10^{14}\) FLOP/s。这个峰值只是算术输入，执行前必须替换为目标硬件和目标精度下的规格。设模型 FLOPs 利用率为 \(u\)，则

\[ t=\frac{C_{\mathrm{train}}}{8F_{\mathrm{peak}}u}. \]

这些时间由假设推导，不是训练记录。Llama 3 报告过不同大规模配置下约 38%–43% 的 BF16 MFU，并说明了多维并行与大量中断处理。[6] Megatron-LM 也报告过大规模 GPU 集群上的并行训练效率。[7] 它们只证明相关范围曾在不同工作负载上出现，不能用来预设本计划的利用率。

MFU 衡量理论模型 FLOPs 与设备峰值的比值；硬件 FLOPs 利用率还会计入重计算等实际操作。两者分子不同。若两份报告没有采用同一 FLOP 模型、精度和峰值定义，百分比不能直接比较。

设序列长度 4,096，每卡微批 8 条序列，8 个数据并行 rank，梯度累积 4 次，则名义全局批为

\[ B_{\mathrm{tok}} =4096\times8\times8\times4 =1{,}048{,}576\ \text{token}. \]

精确处理 230 亿 token 需要

\[ \left\lceil \frac{23{,}000{,}000{,}000}{1{,}048{,}576} \right\rceil =21{,}935\ \text{step}. \]

最后一步只有 534,016 个有效 token。若仍运行一个完整批次，总量会变成 23,000,514,560，多出 514,560 个 token。训练代码必须选择“最后一批裁短”或“接受超额 token”，并在 manifest 中记录，不能同时声称精确 230 亿 token 和 21,935 个满批。

显存也必须说明精度布局。在“bf16 参数 2 字节、bf16 梯度 2 字节、fp32 主参数 4 字节、fp32 Adam 一阶和二阶状态各 4 字节”的假设下，模型状态为 \(16P\) 字节，即 18.364 GB（17.103 GiB）。这不是所有优化器和框架的固定值：有的实现不保留 fp32 主参数，有的梯度使用 fp32，还有的状态被量化。

ZeRO 将优化器状态、梯度和参数逐级切分；在上述 16 字节布局和数据并行度 \(N_d\) 下，三个阶段的每卡模型状态可分别近似为 \(4P+12P/N_d\)、\(2P+14P/N_d\) 和 \(16P/N_d\)。[8] 8 路完全切分的理论模型状态约为每卡 2.296 GB。这个数字不含激活、临时 all-gather、通信 bucket、CUDA context、内核 workspace、碎片和数据 batch，不能据此断言配置一定放得下。

PyTorch FSDP 也以参数、梯度和优化器状态切分来降低每个 worker 的常驻模型状态，并把通信重叠与初始化作为扩展问题。[9] 采用它仍需实测完整训练 step 的峰值，不能用理论分片值替代运行证据。

GQA 对推理缓存的影响可以独立计算。批量为 1、上下文 4,096、24 层、4 个 KV 头、头维 128、bf16 时：

\[ M_{\mathrm{KV}} =2\times24\times4096\times4\times128\times2 =201{,}326{,}592\ \text{bytes} =192\ \text{MiB}. \]

同条件下 16 个 KV 头的 MHA 为 768 MiB。这里计算的是单序列 KV Cache，不是训练激活。参数预算、训练显存和推理缓存必须分账。

预算首先是一组相互约束的选择，而不是把目标参数量填入计算器。在本章的教学计划里，宽度和层数决定大部分参数，词表影响输入输出表，序列长度影响注意力与激活，训练 token 决定处理总量。若把序列长度加倍而保持每步序列数不变，名义全局 token 批也加倍，固定总 token 下更新次数减少；若保持全局 token 批不变，则必须减少序列数或调整累积。两个实验都叫“扩展上下文”，实际同时改变的优化条件可能完全不同。

可以沿着词表变更追踪一次预算传播。假设仍用共享嵌入，将词表扩大一倍，会直接增加词表矩阵参数；若新的切分让文本更短，同一原始语料的 token 数又会减少。此时按“训练二百亿 token”比较，两模型看到的原始文本量已经不同；按相同原始文本比较，输出层计算和更新步数又不同。公平比较需要同时报告原始字节、有效目标 token、参数与计算，说明固定的是哪一项。一个单独的参数或 token 数字不能表达完整实验。

训练 token 还要与唯一数据量分开。假设有十亿个清洗后 token，遍历二十轮会处理二百亿个 token，却没有获得二百亿个独立内容。重复仍然可能改善优化，但后续收益、记忆与过拟合风险不同。数据约束研究为这种区别提供了经验依据，不能由某次实验的有效轮数推出所有语料都可重复相同次数。预算表应把唯一文本规模、重复采样次数和有效训练总量分列，数据新增与算力新增才不会被混成同一种投入。

时长表中的利用率也不是一个从模型名称就能确定的常数。它汇总了算子效率、通信、数据等待、设备闲置等因素，并受到使用何种理论 FLOP 分子的影响。教学计划若用只含参数主项的分子，测得利用率后又在估算时加入注意力项，等于换了标尺。正确流程是先固定计数模型，用相同计数模型解释短跑，再按相同工作负载外推；若长度、精度或并行拓扑改变，应重新检查利用率。报告中较高的百分比只有在口径一致时才具有可比意义。

还应区分连续计算时间与项目日历时间。前者可以用计算量和有效速率估算，后者包括准备数据、评估、保存、设备排队、故障重算及人工分析。假设每次完整检查点之间发生故障，未提交工作需要重做，这部分不能从模型 FLOP 主项中自动得到。为教学估计增加一个明确标注的中断预算是合理的，但不能把未经测量的固定百分比写成所有集群的标准。先记录短跑中实际保存与评估时间，至少可以把这两项从未知量变成有条件的测量值。

训练容量与交付容量也不是同一个约束。使用状态分片能降低训练期间每卡常驻模型状态，却不意味着最终单设备推理就装得下全部权重和长上下文缓存。相反，一个推理可以运行的小模型，训练时还需要梯度、优化器和反向激活。立项时可以分别设训练资源上限与部署资源上限，再检查同一结构是否同时满足。若部署约束是主要驱动力，训练更久的小模型、蒸馏或压缩都应进入候选比较，而不是只选择训练阶段吞吐最高的结构。

最后一批的精确性看似只有几十万个 token，却代表整个账本的定义是否一致。若最后一步按有效目标裁短，梯度仍需除以这一批实际目标数；若为了静态形状补齐，补齐位置不能贡献损失；若选择超额训练，则累计进度必须记录真实值。学习率调度与日志也要沿用同一选择。不能把预算表的“计划总量”直接写成训练完成的“实际总量”，这两列只有在计数证据一致时才能相等。

因此本节的输出应是一份可重算的假设集合：哪个参数由配置确定，哪个数量由数据统计得到，哪个效率来自引用，哪个性能必须由目标设备测量。预算中的未知项不是缺点，未标明的未知项才会使评审失去作用。后面的数据、更新和恢复流程，都是在逐步把这些未知项转成能够检查的状态。

5.2 数据与配置成为不可变输入

flowchart TD
 A["原始文档与来源"] --> B["清洗和去重簇"]
 B --> C["训练开发测试划分"]
 C --> D["训练侧确定分词规则"]
 D --> E["带文档边界的 token 分片"]
 E --> F["数据清单与模型配置哈希"]
 F --> G["确定的采样与监督语义"]

第 2 章 已经解释清洗、去重、Tokenizer、样本边界和污染。本节把这些原则落成两个不可变制品：数据 manifest 与模型 config。训练任务只接收经过验收的制品哈希，不在启动时临时改变过滤规则或模型结构。

从来源到 token 分片

数据管线建议按以下顺序执行：

1. 定义目标分布，列出语言、领域、代码、文档类型和时间范围；
2. 保存来源、许可、快照和退出机制，过滤明显无效或敏感内容；
3. 在全量文档上做精确与近似去重，形成去重簇；
4. 按去重簇划分训练、验证和冻结测试集；
5. 仅用训练侧规则确定 Tokenizer 与采样配比，检查各切片 token/字符或 token/字节比例；
6. 编码并写入有校验和的分片，显式记录文档边界和是否允许跨文档注意力；
7. 在训练前对评估集做污染比对，并冻结评估版本。

FineWeb 展示了大规模网页数据过滤和数据消融的公开路线，可用于理解每项处理如何影响数据质量；它的规模和许可检查不能由“公开可下载”四个字代替。[10] Pythia 公开了训练数据顺序及大量中间 checkpoint，说明数据顺序本身也是可复现实验的一部分。[11]

manifest 至少包含：

表内每个字段都要写入实值。训练入口遇到未知哈希、空 token 分片或未完成的污染记录时应拒绝启动。恢复依赖“下一份尚未消费数据的逻辑位置”，仅保存一个全局 step 无法在可变长度或动态采样下还原数据位置。

数据验收不能只看总 token 数。对每个主要切片，应随机抽取编码前文本、token 序列和解码结果，检查 Unicode 归一化、控制字符、代码缩进、数字、URL 与特殊 token。再统计文档长度、token/字节比、重复次数、语言置信度和被过滤原因。总体分布正常但某个低占比切片损坏时，总平均很难暴露问题；切片报告必须保留样本量和分位数。

文档边界需要同时约束注意力和损失。如果允许多个文档 packing 到同一序列，要明确后一文档能否读取前一文档；若禁止跨文档读取，就生成 block-diagonal 可见性，而不只是插入 EOS。无论是否跨读，EOS 是否参与 next-token loss、序列尾部怎样补齐、被截断文档是否保留，都要写入 manifest。训练和验证必须复用同一套边界语义，否则 loss 差异可能来自样本构造而非泛化。

Tokenizer 的验收至少覆盖三组指标：压缩效率看各语言和格式的 token/字节比；可逆性检查正常文本的编码解码；鲁棒性检查未知字节、异常 Unicode 与超长连续字符串。词表越大，序列可能更短，但 Embedding 参数和输出计算也会增加。应把词表大小与模型总参数、目标语言切分和推理成本一起比较，而不是只追求更低 token 数。

配置来自预算约束

模型 config 要完整表达第 1 章的前向计算：词表、上下文长度、宽度、层数、Q/KV 头、每头维度、FFN 类型与宽度、位置机制、归一化、dropout、bias、Embedding 是否共享、初始化和精度。LLaMA 采用 Pre-Norm、RMSNorm、RoPE 与门控激活，提供了现代 Decoder-only 配置的一种成熟参照。[12] 这不表示同一组合在所有规模和语言上都最优。

教学计划选择 GQA、RoPE、RMSNorm 和 SwiGLU，是为了演练现代结构的参数与缓存账本。选定后仍需先在小模型上检查：

• 参数计数脚本与框架实际参数总数一致；
• Q 头数可以被 KV 头数整除，旋转维度与每头维度一致；
• Causal Mask、Padding Mask 和文档边界符合第 1 章的注意力小节 的可见性定义；
• 权重共享在模型对象和 checkpoint 中都成立；
• 初始化后 logits、激活和梯度没有异常尺度；
• 同一随机种子和环境下，短序列前向结果满足约定容差。

改变上下文长度不仅改变位置范围，也改变注意力 FLOPs 和训练激活。改变词表既改变序列长度，又改变 Embedding 与输出层参数。配置评审应重新计算整张预算表，不能只改一个配置字段。

配置还要带有可执行的不变量。例如 \(D=H_qd_h\)、\(H_q\bmod H_{kv}=0\)、最大位置不小于训练序列长度、共享 Embedding 时两个模块引用同一参数。加载 checkpoint 时先比对 config 和 Tokenizer 哈希，再分配大张量；这样可以在占用大量显存前拒绝不兼容制品。每次结构变更都重新运行参数计数、短前向、反向和保存加载往返，避免“文件能读”掩盖语义变化。

两个模型尺度不能混写

本章的 1.15B 计划使用 GQA、RoPE、RMSNorm、SwiGLU 和共享 Embedding。仓库实验则是一个字符级小型 GPT：它使用普通 MHA、学习式绝对位置 Embedding、LayerNorm、GELU FFN，并且输入 Embedding 与语言模型输出层没有共享。两者的目标也不同：前者用于预算演练，后者用于验证最小训练闭环。

把实验跑通不能证明 1.15B 配置正确；把 1.15B 的参数表写对，也不能证明实验代码实现了 GQA 或分布式训练。后续所有观察都必须注明来自哪个尺度。

数据清单的价值在于使“同一训练数据”成为可检验命题。仅保存一个下载地址不够：远端文件可能更新，清洗脚本可能改变，Tokenizer 也可能使用另一套归一化。一次训练需要能回答某个窗口来自哪个原始文档、经过哪些处理、属于哪个划分以及为何被采样。哈希能够识别文件内容，却不能单独说明内容的语义来源；处理版本和来源记录则解释数据为什么变成现在这样。二者共同构成复查链，而不是彼此替代。

去重与划分的先后顺序会影响验证集的独立性。设同一文章被转载三次，标题、空格和标点略有差异。按文件随机切分，三份文本可能落入不同集合；精确哈希无法发现轻微改写，近似去重簇却可以把它们关联起来。先形成簇再划分，减少的是跨集合共享事实与表达的捷径。若近似算法把不同文档误并，也会减少数据覆盖，因此去重不能只有一个过滤比例，还需要抽样检查误合并与漏合并，说明阈值对应的取舍。

训练配比同样是一种目标定义。假设代码占原始语料很小比例，却被高频重采样，它在梯度中的影响可能远大于磁盘占比；长文档按 token 采样，与每文档等概率选择，也会产生不同权重。应记录最终被消费的有效 token 配比，而不仅是下载时的文档配比。某个来源样本很多但文本很短，另一来源样本少却每条很长，仅比较行数容易得出相反结论。变化中的配比还需要按阶段记录，才能解释模型在不同时间偏向哪些分布。

文档边界可以用两个短例子讲清。把文档甲末尾的“答案是”与文档乙开头的一个数字直接拼接，普通下一 token 目标会把这个数字当成甲的续写。若任务定义允许连续文档流，这可能就是选择的训练语义；若希望各文档独立，则需要在可见性与目标上处理边界。仅插入结束符不会使后文不可见于前文之后的查询，也不会自动删除所有跨边界预测。模型训练的是实际提供的条件序列，不能靠清洗文档中的一句说明改变注意力。

截窗还会改变每个目标获得的上下文。相同文本被切成互不重叠块时，块首目标缺少上一块历史；使用重叠滑窗则可能多次监督同一个目标。两种策略都可用，但总 token 计数要说明是否包含重复目标，评价也要采用一致的上下文窗口。若一个模型在长上下文条件下得到更低 loss，另一个在频繁重置条件下评估，差别不能全部解释成模型能力。窗口规则是评估协议的一部分，应与 Tokenizer 一起固定。

Tokenizer 的训练也属于数据处理学习。字符词表只需要收集不同字符，子词词表却会依据频率与合并规则决定如何分段。若用冻结测试文本帮助选择词表或归一化规则，测试信息已经进入开发流程，即使测试答案没有直接进入模型梯度。严格实验应在训练侧确定规则，再让验证与测试使用同一编码器。遇到无法编码内容时，需要按已定义的未知字符或字节回退策略处理，而不是临时查看测试内容扩词表后继续报原协议分数。

模型配置的不变量可以分成形状与语义两层。形状检查确保矩阵能乘、头能分组、位置范围足够；语义检查确保这些轴的含义正确，例如输出投影是否回到残差宽度、KV 分组是否与查询头对应、共享权重是否真是同一个参数。两个模型可能拥有完全相同的参数数量，却使用不同的归一化或位置机制。参数总数核对是必要的，但不足以证明实现相同；还应把少量可手算输入的前向和梯度行为纳入检查。

共享嵌入尤其容易在保存加载时被误解。两个张量数值相同不等于共享同一个可训练参数；若创建两个独立参数并分别复制数值，后续更新可能使它们分离。真正共享还影响优化器状态与参数计数，不能在预算中按一份计算、代码却更新两份。恢复时应检查对象绑定关系或框架提供的共享契约，而不只是比较加载后数值。检查点可以保存足够信息来重建共享关系，但加载程序必须执行同一结构定义。

配置版本还应区分“改变训练函数”与“改变执行安排”。调整宽度、位置机制或损失边界会改变模型或目标；调整预取线程可能只改变性能，也可能通过随机流顺序间接改变样本。不能预先把某项配置标成纯工程参数后就不记录。比较实验时应列出变化项，并说明预期它影响数学定义、样本顺序还是执行效率。观测到不符合预期的差异，才有明确的排查入口。

对本章两种尺度，最有用的做法是保存两份独立配置说明。字符实验的学习式位置和普通多头注意力是一套真实实现，现代教学计划的旋转位置和分组键值是另一套设计。共同的下一 token 目标允许它们用于解释同一学习原理，但不能让前者自动成为后者的实现验证器。若未来要建立同结构代理，应单独实现并核对现代结构的小配置，再讨论从代理到大模型的迁移。

数据与模型清单在训练启动后应保持身份稳定。发现清洗错误时可以停止、修正并创建新版本，不能原地替换分片而让旧日志继续引用同一个哈希名。恢复程序若读到不匹配的数据或配置，应给出明确原因。这样的约束让异常轨迹可以回放：不是因为所有数据永远正确，而是因为错误发生时能够确定模型究竟吃到了哪一版输入。

5.3 一次参数更新究竟优化什么

flowchart TD
 A["各微批有效目标"] --> S["局部损失和与计数"]
 S --> N["全局有效目标分母"]
 S --> G["局部梯度"]
 N --> Z["统一梯度尺度"]
 G --> Z
 Z --> C["聚合与裁剪"]
 C --> O["一次优化器更新"]
 O --> T["累计有效 token 进度"]

训练循环的核心不是调用反向传播接口，而是定义“哪些 token 贡献了怎样的梯度”。第 2 章 2.2 给出了 next-token cross entropy，第 3 章的监督契约与 SFT 小节 进一步讨论监督位置。预训练通常让所有合法目标位置参与损失；padding、跨文档禁读位置和无效样本必须按训练契约处理。

有效 token 归一化

设第 \(r\) 个数据并行 rank 在一个梯度累积窗口内的有效 token 集合为 \(\mathcal{T}_r\)，局部未归一化负对数似然和为

\[ S_r=\sum_{t\in\mathcal{T}r}-\log p\theta(y_t\mid y_{<t}), \qquad N=\sum_{r=1}^{W}|\mathcal{T}_r|. \]

目标损失是 \(L=(\sum_r S_r)/N\)。在默认且没有改变通信语义的配置下，PyTorch DDP 在反向传播中对 \(W\) 个 rank 的梯度取平均。若每个 rank 直接反传 \(S_r/N\)，最终梯度会额外缩小 \(W\) 倍。因此在“DDP 平均梯度”的语义下，每个 rank 应反传

\[ \widetilde L_r=\frac{W}{N}S_r, \]

DDP 平均后得到

\[ \frac1W\sum_{r=1}^{W}\nabla\widetilde L_r =\nabla\frac{\sum_rS_r}{N}. \]

采用这一前置损失缩放方案时，需要在第一次 backward 前知道整个累积窗口的全局有效 token 数 \(N\)：先准备窗口内的 microbatch，统计本地 mask，再对计数做一次全局求和。若框架对梯度求和而非求平均，缩放因子就不能乘 \(W\)；实现必须按框架语义写测试。DDP 文档说明梯度聚合及 no_sync 的作用范围；自定义通信 hook 和非均匀输入 join 配置需要另核对。[13]

下面是语义示意，并非仓库实验当前 API。示例假设全局有效计数大于零，各 rank 参与相同的同步序列；no_sync 范围同时包含 forward 与 backward，不能只包住 backward：

microbatches = prefetch_accumulation_window()
local_tokens = sum(batch.loss_mask.sum() for batch in microbatches)
global_tokens = all_reduce_sum(local_tokens)

optimizer.zero_grad(set_to_none=True)
for index, batch in enumerate(microbatches):
    with ddp_no_sync(enabled=index + 1 < len(microbatches)):
        logits = model(batch.input_ids)
        local_loss_sum = cross_entropy_sum(
            logits.float(), batch.labels, batch.loss_mask
        )
        ddp_scaled_loss = local_loss_sum * world_size / global_tokens
        ddp_scaled_loss.backward()

clip_grad_norm_(model.parameters(), max_norm)
optimizer.step()

对每个 microbatch 先按自己的有效 token 数求平均，再把这些平均值相加，会让短批与长批获得相同权重；各 rank 有效 token 不等时，先求本地均值再由 DDP 平均也会产生同类偏差。日志中的全局 loss 应另外对 \(S_r\) 与 token 计数做求和，再相除，不能把 rank 的平均 loss 再简单平均。

全局批、优化器与日程

中文教材用小批量样本均值解释梯度聚合与向量化效率。[14] 在本章中，全局批用有效 token 表达，才能跨序列长度比较。批越大，单位更新的梯度噪声通常越小，但固定 token 预算下的更新次数也会减少。梯度噪声尺度提供了一种测量“有用批大小”的方法，其结论依赖任务和训练阶段。[15]

可以用两 rank 的手算暴露错误归一化。假设 rank 1 有 3 个有效 token，局部 loss 和为 6；rank 2 有 1 个有效 token，loss 和为 4。正确全局均值是 \((6+4)/(3+1)=2.5\)。若先算局部均值再由 DDP 平均，结果是 \((6/3+4/1)/2=3\)，短 rank 被放大。按前述公式，每个 rank 分别反传 \(2S_r/4\)，DDP 再平均，才恢复全局 token 均值。这个测试不需要大模型，应成为分布式训练入口的单元契约。

一次“step”也要固定语义：本章把它定义为完成一个全局梯度累积窗口并调用一次 optimizer step。日志同时记录累计有效 token，学习率日程优先按 token 推进。若最后一批裁短，按固定 step 调度和按 token 调度会产生轻微差异；230 亿计划应明确采用哪一种，恢复时也必须沿用。

优化器采用 AdamW 时，权重衰减与 Adam 的自适应梯度更新解耦；这与把 L2 项直接加入 Adam 梯度不是同一更新。[16] 需要保存并评审的参数包括峰值学习率、\(\beta_1\)、\(\beta_2\)、\(\epsilon\)、权重衰减作用范围、梯度裁剪、warmup、稳定段、衰减段和最小学习率。Norm 与 bias 是否衰减也要明确。

当总 token 预算可能变化时，Warmup-Stable-Decay 可以让稳定段 checkpoint 分叉进入不同长度的衰减阶段。MiniCPM 报告了 WSD 与小模型训练策略。[17] 关于固定时长之外的 scaling 研究也说明，稳定训练后再冷却有助于复用一次主体训练做不同预算比较。[18] 这些结果来自特定模型和数据，本计划必须通过代理模型扫描学习率与衰减长度，不能直接照抄公开数值。

小规模预演与数值精度

大模型训练中的某些不稳定现象可以在小模型、高学习率实验中提前出现，例如注意力 logit 和输出 logit 异常增长。[19] 因此主训练前应构造同架构族的代理模型，逐步增加学习率，记录 loss、梯度范数、激活、logit、更新范数和溢出次数。代理实验用于发现危险区间，不保证大模型的最佳值能按比例直接迁移。

μTransfer 研究表明，在满足 μP 参数化条件时，可以从较小模型迁移一部分最优超参数。[20] 这需要改变初始化和参数化规则；普通参数化的小模型搜索结果不能贴上 μP 标签后直接迁移。

bf16 与 fp32 具有相同的指数位宽范围，相关研究在多类训练任务中观察到它可以保持 fp32 的结果。[21] 具体项目仍需检查归一化、softmax、loss 累加和优化器状态的精度。可执行的门禁是：先得到一个小规模 fp32 参考曲线，再比较 bf16 的 loss、梯度和输出分布；出现 NaN/Inf、异常 logit 或持续偏离时停止扩大规模。

梯度裁剪阈值没有跨项目通用常数。应先记录未裁剪梯度范数分布，再确定阈值并监控裁剪比例。若大多数 step 都被裁剪，问题通常不只是“阈值太小”，还可能来自学习率、异常数据或错误归一化。

上述求和与计数并不只影响日志，它们决定每个目标在参数更新中的权重。把样本长度作为一个变化因素即可看到：一段很短的回答若先单独求均值，再与长回答等权平均，短回答的每个 token 会获得更大权重。预训练希望优化全体有效目标平均时，这不是实现误差的小扰动，而是更换了目标。反过来，如果研究明确希望每篇文档等权，那么文档均值也可以合理；关键是写明目标，不用一个含混的 mean 参数代替建模选择。

可以把一个完整更新窗口视为一个大集合，再把它任意切成微批和 rank。若目标及前向计算相同，正确归一化后的梯度应尽可能接近不切分的参考梯度。这个等价性存在前提：参数在窗口中不更新，监督目标相同，随机性受到控制；若模型含跨样本统计、随机掩码或不同数值规约，比较还要明确容差。测试时可以先关闭 dropout，使用小型确定输入，逐项排除这些因素，避免把随机差异误判成聚合错误。

前置损失缩放不是唯一方案。另一种数学上可行的路径是，各微批先反传未归一化损失和，累积并按默认 DDP 语义得到各 rank 梯度和的平均，等到全局有效目标数确定，再将所得梯度统一乘世界大小除以全局计数，然后裁剪和更新。它利用梯度对常数缩放的线性关系。两种方案的数值路径可能不同，后缩放期间梯度的动态范围也可能更大；混合精度、通信 hook 和溢出处理必须配合验证，不能把代数等价直接当作任意框架实现等价。

不论选择哪条路径，都不应再机械除以累积次数。若已经按整个窗口有效 token 总数归一化，再除一次微批数，就额外缩小了梯度；若仅把每个等长微批的均值相加，则通常需要相应平均。所谓“梯度累积要除以几”没有脱离损失定义的统一答案。先写清每次 backward 所表示的量，再沿通信与缩放追到 optimizer step，才知道最终分母是什么。学习率不应被用来长期补偿一个未被解释的归一化错误。

零目标窗口需要单独定义。如果某 rank 的所有位置都被屏蔽，但其他 rank 仍有有效目标，该 rank 不能随意提前退出而破坏共同的集合通信次序；它需要按实现契约参与相应计算或同步。如果全局计数为零，则本窗口没有可定义的平均监督损失，应由所有 rank 一致跳过更新并记录原因。不能以加一个很小的分母常数掩盖数据问题，也不能让某个 rank 更新而另一个不更新。这个边界在大量过滤、变长样本与异常数据处理时尤其重要。

梯度裁剪应放在目标梯度已经成形的位置。若每个微批先独立裁剪，再把结果相加，得到的通常不同于先汇总再裁剪；若各 rank 本地裁剪后再平均，也会改变全局方向。全局范数裁剪把整体梯度按同一个比例缩小，以限制其范数，但它不修正标签错误，也不保证优化一定稳定。对分片梯度，所需范数还要包含所有相关分片，不能把局部范数当作全模型范数。顺序与统计范围都是算法语义，不只是性能细节。

混合精度又增加一层尺度。使用动态损失缩放时，同一累积窗口内 scale 必须固定，各微批梯度始终以同一尺度累加。待本次更新的全部微批反向完成后，每个 optimizer 只调用一次 scaler.unscale_(optimizer)，再检查和裁剪未缩放梯度；scaler.step 与 scaler.update 都在完整窗口边界执行，多优化器时在各自 step 后统一 update。不能在每个微批后 unscale，也不能中途改变 scale，否则不同尺度的梯度会混在一起。[22] 若检测到溢出而跳过更新，学习率日程、成功更新计数和数据消费计数不一定同步前进，需要明确策略。数据可以已经被读取甚至前向过，但参数没有改变；只保存一个 step 数就无法区分这些进度。

AdamW 的状态说明了为什么梯度相同还不等于下一步参数相同。它使用历史一阶、二阶估计和更新位置，当前梯度经过这些状态后才变成参数变化。重启时只加载权重、重新创建优化器，即使接着读取同一批数据，也相当于从新的优化历史开始。权重衰减还直接作用于参数，其强度与学习率和更新次数有关。固定 token 总量但改变全局批，更新次数会变化，因此不能只保留相同衰减系数就认定正则化效果相同。

日程也有多个进度坐标：已经读取的 token、实际参与损失的 token、已经成功更新的 token，以及 optimizer 调用次数。固定等长无异常训练中，它们可能按简单比例对应；遇到过滤、尾批或溢出跳过就会分离。本章建议至少记录有效监督累计量与成功更新次数，再明确日程依赖哪一个。若采用按 token 变化的学习率，恢复时必须重建相同累计量；若日程根据阶段边界进入衰减，也要保存阶段身份而不仅是当前学习率值。

小批量噪声的直觉同样需要保留假设。对独立、同分布样本，平均可以降低随机估计的方差；语言训练窗口却可能重叠，来自同一文档或重复语料，梯度相关性使名义目标数不等于独立信息数。增大批量还减少固定预算下的更新次数，可能改变到达相同损失所需计算。梯度噪声尺度研究提供了分析工具，并没有规定每个项目都应把全局批开到显存所允许的最大值。吞吐最优与训练效率最优不一定重合。

一个小型更新审计可以把这些因素串起来。先使用四条已知目标，计算不切分的损失与梯度；再分成两个不同有效长度的微批；然后把同样数据分配给两个 rank。比较损失和、计数、裁剪前梯度和更新后的参数。先验证没有裁剪与权重衰减的简单情况，再逐项加入真实配置，才能定位差异来自分母、通信、裁剪还是优化器状态。这是建议的实验设计，本章没有提供其分布式实现，也没有把纸面等式当作测试通过记录。

最后，健康日志应保留归一化之前的量。只保存一个平均 loss，无法知道它下降是模型更好，还是某类长难样本被过滤了；只保存裁剪后的范数，也无法知道原始梯度是否长期异常。把有效目标数、损失和、未裁剪范数、溢出次数与更新是否执行一起记录，异常就能追溯到具体窗口。训练循环由此不再只是反复调用三个接口，而成为一个能够核对“这一步到底学了什么”的过程。

5.4 从代理试跑到故障恢复

stateDiagram-v2
 [*] --> 运行
 运行 --> 保存中: 完整更新边界
 保存中 --> 已提交: 分片与元数据校验
 保存中 --> 旧检查点: 中断或校验失败
 已提交 --> 恢复校验: 进程重启
 旧检查点 --> 恢复校验
 恢复校验 --> 运行: 状态与数据位置一致
 恢复校验 --> 拒绝恢复: 契约不兼容

多 GPU 数据并行的基本原理，是划分样本后聚合梯度，中文教材可作为概念入口。[23] 并行策略解决两个不同问题：模型和激活能否放入设备，以及在满足显存约束后能否达到合理吞吐。选型顺序应从实测峰值显存开始，而不是仅根据参数量断言某种并行“必需”或“不需要”。

用峰值显存决定并行阶梯

先在缩小的层数、序列和 batch 上测量参数、梯度、优化器、激活和临时缓冲，再逐项外推并用目标配置短跑校验。激活与 batch、层数、宽度、序列长度、注意力实现和重计算有关；临时 all-gather 与通信 bucket 又与 FSDP 配置有关。任何只列 \(16P\) 的预算都不完整。

可以按以下顺序增加复杂度：

FSDP 的公开经验说明，完全切分可以支持超过单卡容量的模型，同时把通信和计算重叠作为性能问题。[9] Megatron-LM 展示了张量、流水线和数据并行的组合。[7] 这些技术带来新的状态和通信边界；1.15B 计划是否需要其中任何一种，必须由目标设备上的峰值测量决定。即使理论模型状态只有每卡约 2.296 GB，4,096 上下文的激活和临时 gather 仍可能主导峰值。

吞吐记录至少包括全局有效 token/s、每卡 token/s、step 时间分解、数据等待、集合通信、激活重计算和峰值显存。MFU 使用第 5.1 节声明的模型 FLOP 口径；若开启重计算，另报硬件实际执行量或明确其未进入 MFU 分子。这样才能区分“模型计算更快”“设备做了更多重计算”和“数据加载不再等待”三种变化。

容量短跑要覆盖稳态之前的峰值：首次优化器更新会创建 Adam 状态，首次保存会产生序列化缓冲，评估可能使用不同 batch，通信库也可能延迟分配 workspace。只测一次前向或第一个 microbatch 会系统性低估峰值。建议依次执行若干训练 step、一次评估和一次 checkpoint，并采集分配峰值、保留峰值与进程常驻内存。随后改变序列长度和 microbatch，验证外推模型是否与实测一致。

检查点是一份恢复契约

PyTorch 保存加载教程区分推理权重与包含优化器的通用检查点。[24] 本书在此基础上进一步要求数据与随机流一致；用于受控环境精确续训的 checkpoint 至少保存：

• 模型参数和完整模型 config；
• 优化器状态、学习率日程状态与当前更新位置；
• CPU、加速器和各 rank 的随机数状态；
• 数据加载器、采样器、分片、文档偏移和梯度累积窗口边界；
• 动态 loss scaling 或其他数值状态；
• 数据 manifest、Tokenizer、代码和评估版本的哈希；
• 世界大小、并行拓扑与分片元数据。

保存过程应先写临时制品，校验所有 rank 的分片和元数据后再原子发布完成标记。只看到某个文件存在不能证明 checkpoint 完整。分布式恢复还要验证世界大小变化是否受支持；若不支持，就在元数据不匹配时明确失败。

恢复测试应在正式训练前完成：运行到第 \(k\) 步保存，分成“不间断继续 \(m\) 步”和“重启后继续 \(m\) 步”两条路径，比较数据位置、学习率、loss、梯度统计和参数差异。PyTorch 官方复现说明指出，跨版本、平台或 CPU/GPU 并不保证逐位相同。[25] 因而验收标准应是同一受控环境中的确定性检查，以及其他环境中预先声明的数值容差，不能把逐位一致扩展成跨平台承诺。

用可重放证据诊断故障

训练故障至少分为四类：

Llama 3 的大规模训练报告记录了计划内和意外中断，说明恢复能力是训练系统的一等需求。[6] OLMo 2 则公开了模型、数据、训练配方、日志和大量中间制品，为分析训练轨迹提供了参照。[26] 本书的 1.15B 计划没有产生同类运行证据；这里给出的是应当建立的记录结构。

代理模型能够节省试错成本，但必须先定义准备迁移哪一种结论。第一种是发现某类失败，例如高学习率下 logits 失控；第二种是比较候选配方的相对次序；第三种是预测大模型最终损失或能力；第四种是估算目标硬件的速度与峰值。这四种结论需要不同证据。一个小模型复现了数值异常，可以支持优先排查某机制，却不能同时证明某个超参数最优、某个能力能达到目标以及大模型需要多少小时。

结构相似也有不同层次。字符实验与教学计划都使用因果 Transformer，但位置机制、归一化、前馈和键值头配置不同；这些差异会改变梯度和资源特性。因此字符实验适合验证训练概念，不是现代大配置的可靠超参数风洞。若目标是研究现代结构的稳定性，应建立同架构族的小配置，保持所关心的机制，再改变规模。即便如此，深度、宽度、批量与数据变化仍可能改变最佳区间，迁移结论应逐步在中间尺度验证。

μP 的价值在于为特定参数化下的尺度迁移提供约束，而不是给所有小模型扫描结果加一个新的名字。使用普通初始化和学习率规则的小模型，不能在放大时仅乘一个经验系数就宣称完成 μTransfer。若本章只讨论风险发现，可以谨慎使用代理扫描；若要声称超参数跨尺度转移，则必须进一步核对参数化、宽度相关缩放和适用模型族。将论断停留在已验证范围，比把每次代理收益都解释成普遍缩放规律更可靠。

资源外推也需要分项。参数和优化器状态可按参数量近似计算，普通注意力中间张量可能随序列长度平方增长，部分激活随批量和长度线性增长，通信则依赖切分与拓扑。把小配置总峰值乘参数倍数，会把不同增长规律错误绑在一起。可以先根据张量形状建立预测，再测几个变化点检查哪项主导，最后用目标配置短跑确认。若实测偏离，优先寻找延迟分配、内核切换和通信缓冲，不要用任意安全系数替代原因分析。

检查点的完整性可以用一次中断故事解释。假设模型已经完成第十次更新，数据加载线程又预取了第十一和十二次的输入。此时保存恢复位置，应该对应下一份尚未消费的数据，而不是线程已经读取到的最远位置。若保存最远读取位置，重启后会跳过未训练数据；若只保存文件起点，则可能重复许多已完成样本。预取队列与采样器的状态必须共同说明哪些输入已被提交消费，或者恢复时有确定的重建办法。

随机种子与随机状态在这里也不同。种子指定随机流起点，状态指定流中当前位置。训练运行一段时间后仅重新设置原种子，会重新生成开头的随机序列，而不会自动回到中断处。还要区分全局随机流与独立生成器：数据采样、dropout、数据增强和不同 worker 可能各有状态。恢复全局 CPU 状态并不自动恢复所有独立对象，恢复某张设备的状态也不代表其他 rank 一致。状态清单应按实际使用者建立，而不是笼统保存一个 seed 字段。

最容易验收的策略是在完整 optimizer step 边界发布检查点。半个累积窗口中断后，从上一已提交边界重新计算未提交工作；这会重读部分数据，但保持参数更新语义。若确实要支持半窗口恢复，就要额外保存当前梯度、已处理微批数、相关随机状态及混合精度状态，还需确保分布式各 rank 进度一致。两种恢复级别成本不同，应明确选择，不能一边只存完整 step 状态，一边承诺任意中断点零重算。

保存动作本身也需要一致边界。若参数仍在更新，异步写线程逐个复制张量可能读到不同更新时刻的内容；文件成功写完并不证明它代表一个有效训练状态。应先取得同一逻辑时刻的快照，或使用框架提供的安全机制，再完成后台持久化。分布式检查点还要等待所有必要分片与元数据完成校验，最后发布可发现的清单。恢复端只接受已提交清单，不能通过目录里“看见几个文件”判断保存成功。

原子发布的实现取决于存储系统。单文件系统内的重命名与对象存储中的多对象写入，不具有相同事务语义；跨设备分片更不是一次普通 rename 就能同时提交。可以把不可变分片写入新版本位置，核对大小与校验和，再让一个完成清单引用它们。清单发布之前发生中断，恢复端仍选择上一完整版本。这个状态模型的重点是读者只接受完整版本，不是要求所有存储后端使用同一命令。

恢复演练也需要明确比较对象。在同一环境中，从第 k 步分叉，一条不中断运行，另一条保存重启，两条路径使用相同后续输入和解码外的训练随机流。首先比较下一批数据和学习率，再比较 loss、梯度与参数；若数据已经不同，继续追究浮点末位没有意义。只有前面的离散状态一致，数值容差才有解释。为了测试故障提交，还可以在分片未完成时中断，检查系统是否拒绝不完整版本，而不是仅测试正常保存加载。

世界大小变化则属于另一种恢复能力。某框架能够把分片重新分配到更多设备，不代表新的规约顺序、数据分配和随机流映射与旧运行逐位一致。可以支持“状态可加载并继续优化”，同时不承诺“轨迹完全相同”。验收应将功能恢复、同环境轨迹恢复和跨环境统计可接受分开记录。把这三种能力混成一个恢复成功标签，会使用户误解系统能够提供的保证。

故障排查最后应回到第一处异常，而不是最后的 NaN。一个损坏样本可能先造成异常激活，再放大梯度，最后污染优化器状态；如果只在最终 loss 非有限时保存日志，关键输入可能已经丢失。可记录触发窗口、首次异常层和最近健康状态，先在更小范围重放。回退到健康检查点后仍应修正原因，否则重算只是再次到达同一个失败点。恢复缩短损失，诊断阻止复发，二者是相互连接但不同的工作。

5.5 字符 GPT 的最小训练闭环

flowchart TD
 T["文本与字符词表"] --> W["随机窗口及右移目标"]
 W --> M["因果小型 GPT"]
 M --> L["交叉熵与 AdamW"]
 L --> C["权重配置词表检查点"]
 C --> E["抽样验证"]
 C --> G["截窗自回归生成"]
 C -.未实现.-> R["优化器及数据位置续训"]

书稿仓库中的 books/ai-book/labs/llm-from-scratch/ 是本章的最小实验。它从随机初始化训练 Decoder-only GPT，输入是 UTF-8 文本，Tokenizer 以字符为 token。实验用于观察训练闭环，不以生成通用语言模型为目标。

运行命令

在实验目录中创建 Python 3.10+ 环境并安装 PyTorch 与 pytest：

cd books/ai-book/labs/llm-from-scratch
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

用仓库附带的小段 Shakespeare 文本运行 smoke 配置：

python train.py \
  --input data/tiny-shakespeare.txt \
  --preset smoke \
  --max-steps 100 \
  --out-dir out/smoke

python evaluate.py \
  --checkpoint out/smoke/checkpoint.pt \
  --input data/tiny-shakespeare.txt

python generate.py \
  --checkpoint out/smoke/checkpoint.pt \
  --prompt "ROMEO" \
  --max-new-tokens 80 \
  --temperature 0.8 \
  --top-k 10

python -m pytest -v

训练输出目录必须位于实验目录的 out/ 下，代码会拒绝其他路径。设备默认按 CUDA、Apple MPS、CPU 的顺序选择，也可以用 --device 明确指定。确定性算法以 warn_only=True 启用；不同 PyTorch 版本与后端仍可能出现不支持的确定性算子，因此固定 seed 不等于跨环境逐字复现。

本章没有运行这些命令，不报告 loss、速度或生成样例。读者应保存实际终端输出、环境版本和 checkpoint 哈希，再讨论观察结果。

源码与概念映射

字符词表通过整份输入文本拟合，然后才按 token 序列前 90%/后 10% 连续切分训练与验证。这意味着词表已经看见验证段出现过哪些字符，虽然模型参数没有用验证窗口训练。更严格的数据实验应先按文档或去重簇切分，再仅用训练集拟合 Tokenizer。

训练集和验证集都用随机窗口估计 loss；它们共享同一个随机生成器，评估采样会推进后续训练采样状态。当前训练只在开始和结束估计 loss，eval_interval 配置尚未用于循环中的定期评估。因此本实验适合验证“能否学习重复局部模式”，不提供完整、固定窗口的验证曲线。

checkpoint 仅保存模型权重、模型配置和字符词表，足以重新加载进行评估和生成；它没有保存 AdamW 状态、随机数状态、数据位置和当前 step，所以不能从中精确继续训练。测试名称中的“恢复”验证的是模型与 Tokenizer 可以加载，不是中断训练的严格恢复。

应观察什么

执行实验时优先检查可证伪的性质：

• targets[:, :-1] 是否等于 inputs[:, 1:]；
• 改变未来 token 时，较早位置的 logits 是否保持不变；
• 少量重复语料上，训练后 loss 是否低于初始化 loss；
• checkpoint 重新加载后，参数和词表是否一致；
• 温度与 Top-k 改变时，生成分布是否变化；
• 提示包含词表外字符时，是否明确失败。

这些观察只证明对应代码路径。若要向 1.15B 计划演进，需要依次增加子词 Tokenizer、按去重簇切分、分片 manifest、固定评估窗口、BPB、混合精度、梯度累积、分布式归一化、完整 checkpoint、恢复测试和分层能力评估。SFT 与偏好优化也尚未实现，应作为第 3 章对应的独立扩展。

下面的代码解释绑定本地基线 f1783a63f97b9137e156f7039c938985f825f61c；本次复核时实验目录相对该提交没有变化。它是静态读码证据，不是训练运行记录。固定基线的作用，是让读者知道下述结论针对哪一版实现；如果未来新增调度、分布式或恢复功能，需要同时更新边界描述，而不能继续沿用本章的旧结论。

字符 Tokenizer 用排序后的不同字符建立 ID。以教学字符串“甲乙甲丙”为例，词表只有三个字符，编码是一串离散索引；这些索引只代表类别，不表示“丙比甲大多少”。模型通过嵌入表学习每个索引的向量。未知字符没有回退路径，会明确报错，因此替换语料后，原检查点的词表不一定能编码新输入。把新文本单独拟合一份词表再送入旧权重更危险：同一个 ID 可能已经指向另一个字符，形状正确但语义完全错位。

窗口采样从合法起点随机选择长度为 T 的输入，并取向后移动一个位置的 T 个目标。假设文本片段是“甲乙丙丁戊”，窗口长度三，某个起点得到输入“乙丙丁”、目标“丙丁戊”。第一个位置用“乙”预测“丙”，第二个位置可读“乙丙”预测“丁”，第三个位置预测“戊”。目标右移与因果遮罩共同保证预测条件没有提前读到对应未来字符；只做其中一项都不足以完整定义自回归训练。

本实验的窗口等长，而且每个位置都有合法目标，所以模型直接展平批量与位置维后计算平均交叉熵，正好对应这批目标的平均。它没有实现变长 padding、assistant-only mask 或跨文档分段，因此不能把前文的 DDP 不等长归一化问题描述成当前实验已有的错误。更准确的说法是：这个最小实现避开了那些复杂边界，扩展时必须重新加入相应契约。理解简化条件比盲目把生产框架选项搬进来更有教学价值。

模型参数也可以按代码独立复算。两张未共享的词表矩阵贡献两倍词表大小乘宽度，位置表贡献上下文长度乘宽度；每层四个注意力投影和两层前馈的主项合计十二倍宽度平方，再加线性偏置与 LayerNorm 参数；最终还有一组归一化。以源码符号表示，总量为两倍词表与宽度之积，加位置表，再加层数乘以十二倍宽度平方与十三倍宽度之和，最后加两倍宽度。这个公式属于静态形状推导，不能冒称框架运行时统计输出。

附带语料有四十九个不同字符。在这个词表假设下，smoke 配置的推导参数量为六万二千八百八十，default 为一千零七十三万四千三百三十六。词表随输入文本变化，所以 default 不是对任意语料都固定的同一个总数。它的层宽、层数与上下文默认值固定，词表矩阵仍可能增减。读者若要声明实际参数统计，应实例化所用配置并统计参与模型的参数，再与公式比较。

训练函数先估计初始训练损失，然后执行指定更新次数，最后再估计训练与验证损失。每次更新使用全部模型参数组成的单个 AdamW 参数组，因而本实现没有把 Norm 与 bias 排除出权重衰减；它也没有使用学习率日程。写入配置的 eval_interval 并没有被训练循环读取，不能据此绘制每隔一百步验证的曲线。分析代码应追踪字段是否实际使用，而不是只看配置名就推断功能存在。

训练和验证数据对象共享一个显式随机生成器，采样窗口会推进它的状态；模型的随机初始化与 dropout 又依赖其他随机状态。训练前的初始 loss 估计已经消费了一批窗口采样，因此删掉这次监控会改变随后训练遇到的窗口。这个细节说明观察代码也可能影响实验路径。若要比较两个优化器而保持数据顺序一致，可以先固定窗口序列或使用独立、可恢复的采样器；本实验没有自动替读者完成这种严格对照。

独立评估脚本并不把传入全文的每个目标都评价一遍。它先使用检查点词表编码，再取文本后十分之一作为验证段，用固定种子零采样四批、每批八个窗口。固定种子有利于相同输入下比较检查点，但小样本仍不足以代表所有文本；窗口可能重叠，也不是三十二份独立文档。训练末尾的估计默认采用另一组采样状态和十批、每批三十二个窗口，两种 loss 不应被当成同一固定集合上的前后值。

生成过程则每一步截取最近 block_size 个字符，重新执行完整前向，并把局部位置从零开始编号。它没有 KV 缓存，也没有保持超出窗口的完整历史；当序列增长超过窗口，较旧内容被丢弃。使用学习式位置表的这个截窗规则是实际模型函数的一部分，不能套用现代旋转位置缓存的等价性解释。小实验运行较慢也可能来自重复前向，而不只是模型参数多。

Top-k 在本实现中按第 k 大 logit 作为阈值，保留不小于阈值的项；若多个候选在边界并列，实际保留数量可能超过 k。它随后按温度调整后的分布随机抽样，而不是直接选择最大概率。生成 CLI 没有 seed 参数，也没有自动继承训练进程的随机状态，所以不能承诺相同命令在独立进程中总给相同文本。判断生成行为时，应区分概率函数、采样设置与随机流三件事。

检查点重新加载会创建模型并恢复权重与词表，调用评估和生成的函数会负责切换评估模式。仅调用加载函数并不代表所有调用方都自动进入推理状态，dropout 是否关闭仍取决于模式管理。更重要的是，没有优化器与采样状态的文件只能证明模型可重新用于前向，不足以证明训练能从中断位置继续。将这些可观察事实写清，可以让最小实验保持简洁，同时不把简化实现误包装成完整训练平台。

5.6 分层评估与主训练交付

flowchart TD
 A["训练健康曲线"] --> B["固定文本的语言建模评价"]
 B --> C["独立能力与污染检查"]
 C --> D["恢复及资源证据"]
 D --> E["基础模型制品"]
 E --> F["重新定义后训练监督"]

评估要依次回答三个问题：训练过程是否健康，基础模型是否学到目标分布，模型能否进入后训练。最终 checkpoint 的一个总分无法回答这三件事。

Loss、Perplexity 与 BPB

对固定 Tokenizer 和同一评估集，token 平均负对数似然为 \(L_{\mathrm{tok}}\)，困惑度为

\[ \mathrm{PPL}=\exp(L_{\mathrm{tok}}). \]

Perplexity 只在相同 token 化和 loss mask 下具有直接可比性。两个 Tokenizer 对同一文本产生不同 token 数时，应把总负对数似然归一到相同的原始字节：

\[ \mathrm{BPB} =\frac{\sum_t-\ln p_\theta(y_t\mid y_{<t})} {\ln 2\cdot N_{\mathrm{byte}}}. \]

若平均每 token NLL 为 2.3 nat，每个 token 平均对应 4.0 字节，则教学算例的 BPB 为

\[ \frac{2.3}{4\ln2}\approx0.8295. \]

这只是公式演示，不是实验结果。BPB 仍要求使用相同原始字节、相同边界和无污染的验证集；它不会自动消除数据配比和上下文处理差异。

训练健康度应按 token 间隔记录训练/验证 loss、梯度范数、学习率、吞吐、峰值显存和异常计数。能力评估再按语言、领域、代码、数学、文档类型和长度切片。小模型若在某基准上接近随机水平，应先报告随机基线、样本数和重复区间，不能把噪声解释成能力提升。

Pythia 的密集 checkpoint 适合研究能力何时出现和数据顺序怎样影响轨迹。[11] OLMo 2 的开放训练制品可用于比较日志与配方组织。[26] 由于它们与本计划的数据、Tokenizer 和模型配置不同，适合比较方法和趋势，不适合直接比较绝对 loss。

评估冻结与污染边界

开发集用于日常选择超参数，冻结测试集只用于阶段和发布判断。只要某个测试结果被拿去调整数据配比、学习率或清洗规则，它就已经参与开发，必须另建冻结集。训练前对语料与基准做精确和近似匹配；评估时记录数据快照、提示、few-shot 示例、解码参数和判分脚本。

基础模型首先评估语言建模和潜在能力。指令遵循、拒答、工具协议和偏好属于第 3 章的后训练目标。预训练结束后可以选择 SFT，但要重新建立聊天模板、监督位置和行为回归；不能用 SFT 后的格式改善反向证明基础模型训练正确。

进入后训练的门槛可以设为：训练曲线稳定，关键数据切片没有异常退化；恢复测试通过；冻结基础评估高于约定基线；污染检查完成；模型、Tokenizer、数据和代码制品可追溯。未满足这些条件时，应先定位基础训练中的问题，避免把 SFT 带来的行为改善误认为原有根因已经解决。

每个汇总指标都应能下钻到样本。语言建模评估保存文档 ID、切片、有效字节、token 数和总 NLL；任务评估保存输入、期望、输出、判分器版本和失败类型。这样，当平均 loss 下降但代码切片变差时，可以判断是少数长文档权重变化、Tokenizer 差异、数据污染还是能力退化。

评估报告还应给出比较的不确定性。对有限任务集可用 bootstrap 或重复采样估计区间；对随机窗口 loss，应固定窗口集合后再比较 checkpoint，并把随机窗口估计作为独立的训练监控。多个 checkpoint 反复在同一开发集上选择也会过拟合评估，因此最终门禁需要未参与选择的冻结集合。

能力与成本要成对报告。同一质量改善如果需要更长上下文、更高精度或更多生成 token，会改变部署价值。基础模型阶段至少记录模型大小、评估 token/s、峰值显存和每项任务的有效 token；进入后训练时再增加模板、输出长度和行为指标。第 4 章的 test-time scaling 只能在这条基线之上比较，否则训练收益与推理预算会混在一起。

下面把 1.15B / 230 亿 token 算例整理成一份可评审计划。所有结果均为公式推导或待测目标，没有大规模运行记录。

主训练前的递进试跑

不能从字符实验直接跳到 230 亿 token 主训练。更稳妥的路径由五次递进试跑组成。第一步是单 batch 过拟合：关闭 dropout，用很小数据反复更新，确认目标右移、loss 和梯度方向。第二步是单设备短跑：恢复真实数据与精度，观察几百个 step 的数值范围、数据等待和显存峰值。第三步是多设备等价性：固定完全相同的有效 token，在单进程参考与 DDP/FSDP 路径上比较一个更新后的参数差异，专门验证第 5.3 节的 loss 缩放。第四步是恢复演练：在累积窗口边界与非边界位置分别中断，确认系统从已提交的完整 step 恢复，允许重算未提交窗口，但不能重复提交已经完成的更新，也不能漏掉未处理目标。第五步才是接近目标序列与 batch 的容量短跑，并包含评估和 checkpoint。

每次试跑只改变一个主要变量，并保存“输入制品—运行配置—输出指标”的对应关系。若同时更换数据、模型宽度、精度和并行策略，即使结果变好也无法归因。试跑通过还不等于主训练一定稳定，但它能把形状、归一化、内存和恢复错误挡在昂贵阶段之前。

主训练的监督 token 账本以实际参与 loss 的有效目标为准，而不是已读取字节、已分词 token 或包含 padding 的张量元素。计算账本另记实际执行位置与形状；本章 6PN 算例仅在近似全监督、少补齐时用监督量近似执行量。每个 step 记录本地与全局有效 token、累计 token、被丢弃样本和最后一批处理方式。这样才能证明最终数字确实是 230 亿，并让学习率、评估间隔和 checkpoint 间隔在恢复后保持同一进度。

主训练开始前还应设置停止条件：出现无法恢复的制品损坏；连续多个评估点显著偏离代理预测且原因不明；数据许可或污染结论改变；预算消耗超过上限；目标能力不再具有业务价值。停止训练不是失败隐藏，而是预算控制的一部分。

可以按风险递增完成四组练习：

1. 在字符实验中固定一组验证窗口，比较“随机窗口均值”和“固定窗口均值”的波动；
2. 为实验 checkpoint 增加优化器、step、随机数和采样位置，做中断/不中断恢复对照；
3. 构造不同有效长度的两个 rank，验证局部均值平均与全局 token 均值的梯度差异；
4. 用两个 Tokenizer 编码同一冻结文本，分别报告 token loss 和 BPB，说明为什么前者不可直接横比。

练习只有在保存代码版本、输入、命令和断言输出后才算执行。设计存在、测试文件存在或算术正确，都不能替代运行证据。

语言建模评价首先要确定求平均的单位。假设两篇文档分别有十个与一百个有效目标，先分别算平均 loss 再等权平均，回答的是“平均一篇文档的预测难度”；把全部 NLL 相加再除以总目标数，回答的是“平均一个目标的预测难度”。两者都可用于分析，但不能在不同检查点之间静默切换。主指标应固定一种口径，切片报告再说明不同长度、语言与来源的表现。否则分数变化可能只是权重变化。

困惑度是平均负对数似然的指数，因此也不能把若干批困惑度直接平均来代替全局困惑度。先汇总 NLL 与有效目标数，再取指数，才对应定义。尤其当批次长短不同或难度差异很大时，指数的非线性会使“先指数后平均”产生不同结果。随机窗口估计在等长批次下可以先平均 batch loss，但若扩展成变长窗口，就必须保留每批计数。一个评估脚本的 reduction 选择与训练脚本一样需要审查。

BPB 改用字节分母，解决的是不同切分颗粒度导致的部分不可比问题，不会自动消除文本处理差异。若一个管线把换行统一为单字节，另一个保留不同编码，原始字节数就不相同；若某些上下文 token 只作条件、不参与目标，分母也应对应真正计分的原始内容。对不可逆归一化，需要说明评价的是归一化后的文本还是原始文本。只有两模型面对同一事件定义，单位换算才有意义。

能力评价则回答另一个问题。较低语言建模损失说明对目标分布的概率预测改善，并不保证模型能够按某种指令接口稳定完成任务。一个基础模型可能知道相关信息，却不会输出指定 JSON；后训练可以改善这种行为，但也可能改变长度、拒答和偏好。应分别保存基础模型与后训练模型的评价，避免把后训练改善归因于预训练配方，也避免仅因基础模型不擅长聊天就否认其语言建模进展。

有限测试集还存在样本相关性。随机窗口来自同一篇短文时，许多相邻窗口共享大部分字符，不能把每个 token 都当独立试验来得到极窄置信区间。对文档级任务，可以按文档或来源簇重采样；对固定问题集，可以按题目保留配对差异。选择统计单位应与数据生成过程相匹配。增加重复采样次数有助于估计随机波动，却不能把一个狭窄来源变成广泛代表性。

检查点选择会消耗评估独立性。假设训练保存很多版本，每次都查看同一冻结集并挑最好的一次，即使没有对测试样本反向传播，选择过程已经利用测试噪声。应把日常选择留给开发集，最终结论使用未参与选择的数据。若最终测试失败，回到开发流程并保留失败记录，不要继续在同一测试上试到满意再称其独立。这个原则与去重一起控制了两类不同泄漏：内容进入训练和评估进入决策。

训练健康曲线也需要与数据进度对齐。某个时间点 loss 突然上升，可能是模型数值异常，也可能是配比切到更难来源；若只按 wall-clock 作图，两者更难区分。日志应记录累计有效目标、阶段、来源比例和学习率，使观察者能比较同一训练进度下的变化。对于不同吞吐实现，按小时比较质量回答的是资源效率，按 token 比较质量回答的是样本效率，两种曲线都可有用，但结论不能互换。

一个完整的验收反例是“总体 loss 降了，关键数字抽取变差”。排查可以先固定相关样本，比较分词、上下文、预测分布和输出，再看它们在数据混合中的权重是否变化。若只是某个低占比但关键切片退化，总平均可能继续变好；若生成预算或提示变了，也可能与模型无关。汇总分负责发现趋势，样本与配置负责解释原因。只有后者能支持下一步修复，而不是泛泛增加训练轮数。

成本比较也需要把失败算进去。一个模型单次生成更便宜，但经常需要重试、回退到大模型或人工修正，单位成功任务成本可能更高。基础模型阶段未必已经有真实业务流量，可以先声明教学成本模型，把训练固定成本、推理成本与验证成本分别列出，再说明哪些项尚待测量。不能用未经执行的 GPU 时长假设推导精确财务收益，也不能把公开项目的单次训练成本直接套到本计划。

交付基础模型时，最有用的制品记录不是一张最高分截图，而是可追踪到数据、代码、配置与评估协议的证据集合。权重文件描述模型状态，Tokenizer 定义离散输入，配置定义函数，训练日志记录过程，恢复报告说明中断语义，评估报告限定能力范围。缺少其中某项，不一定使模型完全不可用，却会削弱某类可验证声明。交付文档应明确已有证据与仍待验证内容，而不是把所有文件放在同一目录就称为可复现。

本章最终希望读者能够区分三个结论：公式和账本已经复算，最小代码路径具备某些实现，某个训练项目在目标环境实际通过验收。前两者是第三者的重要准备，但没有自动蕴含第三者。字符实验可以帮助建立直觉，教学计划可以训练预算判断，真正的主训练则必须用自己的运行记录完成最后一段论证。这样的边界不会减弱教程，反而让读者知道下一步该收集什么证据。

本章小结

从零训练把模型结构、数据治理、优化和分布式系统连接成一条证据链。先用基线证明需要从随机初始化开始，再固定参数、token、FLOP 和显存口径；数据 manifest 与模型 config 决定训练输入，按全局有效 token 归一化的损失决定梯度含义，峰值实测决定并行方式，完整 checkpoint 和恢复演练决定中断后能否继续。

1.15B / 230 亿 token 计划说明了口径为何重要：230 亿并不等于精确 \(20P\)；1,048,576 token 的全局批需要 21,935 步且最后一批不是满批；16 字节/参数只描述一种 Adam 精度布局；理论分片后的模型状态也没有覆盖激活和临时缓冲。把这些条件写清，预算才可审计。

字符级 GPT 实验提供了可以运行的最小闭环，同时明确暴露了边界：它没有子词 Tokenizer、分布式训练、BPB、完整续训 checkpoint 或 SFT。读者应先用它验证目标右移、因果性、loss 下降和制品加载，再逐项增加复杂度。训练完成后的基础模型若要成为可用助手，还需进入第 3 章的后训练流程；生成阶段的采样与搜索则由第 4 章负责。

参考资料

本章以原始论文、官方文档与中文教材支持方法和边界；具体阅读范围保存在来源核验记录中。教学算例与静态代码分析不代表论文复现或已完成训练。

1. Zhang, P., et al.，TinyLlama: An Open-Source Small Language Model，2024；元数据与摘要核验；核验日期：2026-10-31。
2. Vaswani, A., et al.，Attention Is All You Need，2017；核验日期：2026-10-31。
3. Hoffmann, J., et al.，Training Compute-Optimal Large Language Models，2022；元数据与摘要核验；核验日期：2026-10-31。
4. Sardana, N., et al.，Beyond Chinchilla-Optimal: Accounting for Inference in Language Model Scaling Laws，ICML 2024；元数据与摘要核验；核验日期：2026-10-31。
5. Muennighoff, N., et al.，Scaling Data-Constrained Language Models，2023；元数据与摘要核验；核验日期：2026-10-31。
6. Grattafiori, A., et al. / Llama Team，The Llama 3 Herd of Models，2024；第 3.3 节 MFU 与第 3.3.4 节恢复记录；核验日期：2026-10-31。
7. Narayanan, D., et al.，Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM，SC 2021；元数据与摘要核验；核验日期：2026-10-31。
8. Rajbhandari, S., et al.，ZeRO: Memory Optimizations Toward Training Trillion Parameter Models，SC 2020；第 3.1–3.2、5.1–5.3 节；核验日期：2026-10-31。
9. Zhao, Y., et al.，PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel，2023；元数据与摘要核验；核验日期：2026-10-31。
10. Penedo, G., et al.，The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale，2024；元数据与摘要核验；核验日期：2026-10-31。
11. Biderman, S., et al.，Pythia: A Suite for Analyzing Large Language Models Across Training and Scaling，2023；元数据与摘要核验；核验日期：2026-10-31。
12. Touvron, H., et al.，LLaMA: Open and Efficient Foundation Language Models，2023；核验日期：2026-10-31。
13. PyTorch Contributors，DistributedDataParallel，PyTorch 2.15 官方文档，梯度聚合与 no_sync；核验日期：2026-10-31。
14. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V.，《动手学深度学习》：小批量随机梯度下降，中文在线 2.0.0，第 11.5 节；核验日期：2026-11-01。
15. McCandlish, S., et al.，An Empirical Model of Large-Batch Training，2018；元数据与摘要核验；核验日期：2026-10-31。
16. Loshchilov, I., & Hutter, F.，Decoupled Weight Decay Regularization，ICLR 2019；核验日期：2026-10-31。
17. Hu, S., et al.，MiniCPM: Unveiling the Potential of Small Language Models with Scalable Training Strategies，2024；元数据与摘要核验；核验日期：2026-10-31。
18. Hägele, A., et al.，Scaling Laws and Compute-Optimal Training Beyond Fixed Training Durations，NeurIPS 2024；元数据与摘要核验；核验日期：2026-10-31。
19. Wortsman, M., et al.，Small-scale Proxies for Large-scale Transformer Training Instabilities，2023；元数据与摘要核验；核验日期：2026-10-31。
20. Yang, G., et al.，Tensor Programs V: Tuning Large Neural Networks via Zero-Shot Hyperparameter Transfer，2022；元数据与摘要核验；核验日期：2026-10-31。
21. Kalamkar, D., et al.，A Study of BFLOAT16 for Deep Learning Training，2019；元数据与摘要核验；核验日期：2026-10-31。
22. PyTorch Contributors，Automatic Mixed Precision Examples：Gradient Accumulation，PyTorch 2.15 官方文档，梯度累积与裁剪段；核验日期：2026-11-01。
23. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. V.，《动手学深度学习》：多 GPU 训练，中文在线 2.0.0，第 12.5 节；核验日期：2026-10-31。
24. PyTorch Contributors，Saving and Loading Models，PyTorch 官方教程，General Checkpoint 段；核验日期：2026-10-31。
25. PyTorch Contributors，Reproducibility，PyTorch official documentation；核验日期：2026-10-31。
26. Team OLMo, et al.，2 OLMo 2 Furious，2025；元数据与摘要核验；核验日期：2026-10-31。

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

模型适配既改变可训练参数，也改变最终计算函数。需要把训练目标、参数化、数值表示与输入接口分开分析，再组合成可验证的制品。本章以中文工单与文档助手为教学场景：文本阶段提取字段，压缩阶段保住关键数字，视觉阶段读取扫描页面。案例未实际运行，数值示例只用于推导。

大模型落地时，团队通常从一个可复用的预训练 checkpoint 出发：让它适配业务，在质量下降可控的前提下降低显存和延迟，或把文本能力扩展到图像、文档、视频和界面。微调、压缩和多模态看似是三组技术，实际上共享一个工程问题：在有限数据、算力和风险预算下，改变已有模型的有效能力分布。

本章从两条边界开始。第 3 章《后训练：行为的塑形》负责解释 SFT、偏好优化和强化式优化的目标与监督信号；新增第 5 章《从零训练一个 LLM：一条可复现的工程路径》负责从随机初始化到基础模型 checkpoint 的训练闭环。本章假定基础模型已经存在，重点讨论选择哪些参数参与更新、怎样压缩模型，以及怎样增加新的输入模态。训练目标与参数更新范围是两个独立决策：选择 SFT 不等于必须全参数更新，选择 LoRA 也不改变 SFT 的 token 级学习目标。

本章也把“模型改造”与“服务部署”区分开。LoRA、QLoRA、量化、蒸馏和视觉语言对齐属于算法层；adapter 动态加载、GPU 调度、模型服务和灰度回滚属于后续 Infra 层。算法层要向 Infra 交付清晰的权重、精度、输入输出和质量契约。全章依次完成问题诊断、参数高效适配、压缩、多模态扩展和联合验收；多模态部分同时为下一章的空间感知与物理闭环建立输入基础。

6.1 从任务失败定义适配目标与监督

flowchart TD
A["失败样本与冻结基线"] --> B["事实行为与成本诊断"]
B["事实行为与成本诊断"] --> C["监督目标与独立评估"]
C["监督目标与独立评估"] --> D["目标收益及保留能力"]

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

同一个业务需求可能有多种解决手段。可以把它们压缩成一句话：Prompt 改变这一次怎么做，检索提供这一次参考什么，工具提供这一次能访问什么，微调改变以后默认怎么做。 这些手段不是必须依次穷尽的阶梯。低成本基线有助于判断收益，但当标签、部署条件与重复任务成本清楚时，微调可以较早进入比较。

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

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

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

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

基线还要包含失败样本分类：知识缺失、任务理解错误、格式不稳、风格不一致、参数错误、越界和无法判断。主要失败来自可学习模式时，微调有明确实验目标；主要失败来自缺失证据和系统状态时，应先核对检索、工具或流程。参数更新也可能学习领域信息，但更新时效性和可撤销性通常不如外部事实源。

监督微调用输入到标准输出的样本学习行为，适合格式、分类、摘要和示范式回答；偏好优化用同一输入下的 chosen/rejected 学习排序，适合多个答案都可行但质量有差异的任务；强化式优化用状态、动作和奖励处理多步环境反馈。三者的目标、公式和成立条件由第 3 章主讲，本章只回答在目标确定后如何选择参数更新范围。全参数 SFT、LoRA SFT 和 QLoRA SFT 可以使用同一种 assistant-token 损失，差别在于参与梯度更新的参数集合以及训练时基础权重的表示方式。

无论选择哪种更新范围，角色边界、工具结果、系统消息和用户输入的 mask 都必须与第 3 章定义的目标一致。mask 错误可能让监督偏离目标，例如额外学习用户文本；是否产生复述或指令混淆，还取决于数据与可见性设计；softmax 与交叉熵的基础定义可参考中文教材 [2]。偏好优化与环境反馈同样可以结合 PEFT，但不能因为只训练少量参数，就省略参考策略、奖励有效性或独立评估等后训练约束。

数据集的分层和切分

一个可维护的数据集至少应记录任务类型、语言、难度、输入来源、目标输出、验证规则、风险级别和版本。建议把数据分为通用能力锚点、领域任务、格式协议、安全边界、困难负例和线上回流六类。训练集、开发集和冻结测试集要按用户、事件、时间和文档来源隔离，不能把同一 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稍好但超时，不能只凭平均分上线。任务变难后可重新评估路由，不把一次选型写成模型规模的普遍规律。

把监督目标写成一个条件分布，可以进一步避免把“微调”当作万能修复。设输入为工单正文和检索证据，输出包含故障类型、金额和处理建议。若故障类型的标签体系本来就冲突，增加可训练参数只会让模型更充分地拟合矛盾；若金额在输入中根本不存在，要求每个样本必须给出数字，就会把猜测变成训练目标；若处理建议取决于实时库存，旧样本只能描述过去的状态。三种失败在评测上都可能表现为答案错误，却需要分别修标签、补证据和重设工具接口。适配算法只优化给定目标，没有办法自动替团队决定业务事实。

这里有两种不同的“冻结”。冻结基础模型参数，是不更新那部分权重；冻结评估协议，是在选择候选时不任意改变测试条件。前者可以降低优化器状态，后者约束结论可信度。即便只训练一个很小的 adapter，也可能反复在同一测试集上挑选 rank 和学习率，从而消耗测试独立性。反过来，全参数更新并不必然破坏评估，只要数据切分、调参预算和最终测试严格分离。模型改了多少参数与评估是否泄漏没有直接的充分必要关系。

同样需要明确的是 token 权重与样本权重。设一个字段抽取答案只有十个目标 token，另一篇解释性答案有一千个。把所有目标的负对数似然相加后除以目标总数，会让长答案贡献更多总体权重；先对每个答案求均值，再平均样本，则让两个任务等权。两者都可能合理，却对应不同业务偏好。若重要的数字字段总是很短，全 token 平均可能被长解释主导；解决办法可以是调整样本配比、定义任务权重或拆分输出，而不是盲目把 rank 增大。权重应在开发集之前定义并记录，不应看到测试薄弱项后临时改口径。

训练 mask 也应被当成监督选择，而不是安全机制。屏蔽用户输入的损失，表示不直接要求模型预测这些位置，并不意味着模型无法读取、记住或在输出中复述输入。被屏蔽的内容仍可通过注意力影响后续受监督位置；若目标答案本身包含秘密，正确的 assistant-only mask 也不会消除泄漏风险。相反，某些继续预训练或混合目标有意对整段文本监督，也不能仅凭这一点断言它必然造成指令泄漏。需要先确认训练事件、可见性和目标内容，再判断 mask 是否符合任务契约。

因此，数据审查至少要分开三个问题：输入是否允许被模型使用，目标是否正确且允许被学习，评估是否能检出目标外的副作用。对于工单案例，可以允许模型读取经过授权的错误日志，但把账号替换为占位符，训练它调用查询接口而不是背诵真实账号。这个设计并不是量化或 LoRA 的特有功能，而是所有参数更新方式都共享的监督边界。若后续压缩导致模型忽略占位符或破坏接口字段，仍应回到同一验收协议检查。

一个值得保留的对照实验，是让两条路径面对同一批任务：第一条用较长提示给出格式示范，第二条用参数适配学习格式并缩短提示。两条路径不仅比较答案得分，也比较训练固定成本、每日调用成本和规则更新频率。如果标签每天都变，频繁重新训练可能抵消推理节省；如果标签长期稳定、请求很多，适配的固定成本可能逐渐摊薄。IA3 所在研究比较过参数高效微调与上下文学习，但其特定模型和数据结果不能直接给出本场景的盈亏平衡点。[5] 本书的推导是把固定成本与每次调用的差额分开记账，并用实际负载估算交点。

还要避免把训练收益全部归因于方法名称。假设第二轮实验同时增加了高质量样本、修正模板并换成 QLoRA，分数提升不能证明四位底座比浮点底座更好。应先锁定数据和模板，再比较更新范围与精度；若资源限制使完整矩阵无法运行，就如实标明未控制的变量。可解释的负结果也有价值：在相同预算下较低 rank 已经达到质量门槛，可以减少部署状态；如果不同 rank 都失败，优先检查任务与数据，而不是把更高 rank 当作必然救济。

6.2 参数高效适配的梯度与状态

flowchart LR
X["输入"] --> W["冻结 W 的线性分支"]
X --> A["可训练 A"]
A --> B["可训练 B 与缩放"]
W --> Y["相加得到输出"]
B --> Y
Y -.反向.-> G["更新 A 和 B 并传递输入梯度"]
Y --> M["固定适配器可合并成有效权重"]

Adapter、Prefix 与 Prompt Tuning

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

这些方法的共同优点是基础权重不变、任务版本隔离、存储成本较小，适合多任务和多租户场景。限制是新增参数的表达能力受位置和结构约束，任务分布与基础模型差距很大时可能学不动；多个 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 论文说明，许多下游适配的有效更新可以用低秩子空间表达 [9]。

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

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

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

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

合并多个 LoRA 可能出现方向冲突：一个 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。若先合并再量化与训练路径不同，要把导出版本作为新候选回归。

为了理解低秩约束究竟改变了什么，令缩放常数为 \(c=\alpha/r\)，有效权重为 \(W_{\mathrm{eff}}=W+cBA\)。设损失对有效权重的梯度是 \(G\in\mathbb{R}^{d\times k}\)，由链式法则得到

\[ \frac{\partial\mathcal L}{\partial B}=cGA^\top, \qquad \frac{\partial\mathcal L}{\partial A}=cB^\top G. \]

这是本书在 LoRA 参数化上的直接推导，不是论文新增实验。[9] 若 A 随机初始化、B 为零，初始有效模型与底座相同；第一次反向时，A 的任务梯度为零，B 的梯度通常非零。B 更新后，A 才开始从这条路径得到任务梯度。若两者同时为零，两个梯度也同时为零，这条分支无法靠普通任务反向自行启动。这里说的是任务损失梯度，未包含权重衰减、额外正则项或实现中的其他更新。

可以用一个不涉及语言语料的二维例子检查符号。取一个输出通道，输入 \(x=(2,1)^\top\)，rank 为一，\(A=(1,-1)\)、\(B=0\)、\(c=1\)。此时低秩分支输出是零，而中间量 \(Ax=1\)。假设损失对该输出的导数为三，则 B 的梯度为三，A 的梯度为零。用学习率十分之一进行一次不带其他项的梯度下降，B 变成负零点三，低秩分支在同一输入上产生负零点三的修正。第二次反向时，A 的梯度就可能非零。这个例子解释了初始化的工作方式，并不代表训练中梯度总是沿固定方向变化。

低秩也不是把原权重压成低秩。底座 W 可以满秩，限制的是增量 BA 的秩不超过 r；有效权重仍可能满秩。对于一个固定矩阵，足够大的 r 能表达任意增量，但这不意味着优化轨迹与直接全参数训练相同。分解存在尺度自由度：把 A 乘一个非零常数，同时把 B 除以同一常数，乘积不变，两个因子的梯度与优化器状态却会改变。初始化、缩放与优化器共同决定如何探索这个参数空间，仅比较“表达能力足够”无法预测训练稳定性。

参数节省可以独立计算。一个 \(4096\times4096\) 的矩阵有 16,777,216 个参数；rank 为 16 时，A 和 B 合计 \(16(4096+4096)=131,072\) 个参数，等于原矩阵的百分之零点七八一二五。若仅作教学假设，每个可训练参数关联十六字节的参数、梯度与优化器状态，则这部分从约二百五十六 MiB 降为二 MiB。不过底座仍需存储，前向仍需计算，激活和通信缓冲也没有按这个比例消失。将可训练状态缩小一百二十八倍，不能据此宣布总显存或训练时间缩小同样倍数。

冻结分支仍可能参与反向传播。对 \(y=(W+cBA)x\)，输入梯度是 \((W+cBA)^\top\partial\mathcal L/\partial y\)。即使不计算 W 的参数梯度，上游可训练层仍需要这项输入梯度。因此，在冻结底座内部插入多个适配器时，不能把所有冻结线性层都放进完全切断自动微分的上下文。是否能够免去某部分计算，取决于其输入之前有没有需要梯度的参数，以及框架是否采用了数学等价的重计算方案。冻结参数与截断计算图是两个不同操作。

推理合并也要沿计算图判断。关闭训练期 dropout、固定适配器和缩放后，线性分支可以合并为同形状的有效权重；若同一批请求使用不同适配器，就不存在一份同时适用于所有请求的共同合并权重。对浮点数，独立分支相加与预先矩阵相加还可能产生末位差异，所以应区分数学等价与逐位一致。量化时更要谨慎：通常 \(Q(W+cBA)\ne Q(W)+cBA\)。训练在反量化底座上进行，导出却使用原始浮点底座合并，也会改变实际函数；每条路径都需要自己的制品身份与回归结果。

AdaLoRA 将预算分配进一步显式化。它以类似奇异值分解的三因子参数化表示增量，配合正交正则，并依据重要性保留或屏蔽对应分量；它没有在每一步对每个大矩阵重新执行完整 SVD。重要性同时考虑参数与梯度相关的敏感度及其波动，预算从较宽起点逐步缩减，最后固定分配继续训练。[4] 这种设计允许不同层获得不同容量，却增加估计噪声、日程与实现状态。某一层得到较多预算，只能解释为该训练过程认为它更有用，不能直接当成该层在所有任务上的永久重要性排名。

DoRA 则把幅值和方向拆开。以单个非零权重向量表示，令 \(v=w_0+\Delta v\)，有效向量为 \(w’=m v/|v|\)。若对分母完整求导，记 \(u=v/|v|\) 和上游梯度 g，则

\[ \nabla_v\mathcal L=\frac{m}{|v|}(I-uu^\top)g, \qquad \frac{\partial\mathcal L}{\partial m}=u^\top g. \]

投影项去掉沿当前方向的分量，使方向与幅值的更新分工更清楚。原论文以矩阵的列向量范数定义分解；换成另一种权重存储约定时，必须连同广播轴一起转换。更重要的是，论文为降低训练内存，在后续实验中停止范数分母的梯度，此时方向导数变为 \(m g/\operatorname{stopgrad}(|v|)\)，不再包含前面的投影项。[11] 完整导数能解释原始参数化，不能被不加说明地当作省内存版本的实际反向过程。

QLoRA 的精度路径同样应按对象拆开。低比特码与量化常数负责存储冻结底座，矩阵运算时把相关值解码到计算精度；高精度适配器及其优化器状态构成可训练部分。双重量化压缩的是量化常数，而不是让模型的每个算子再降一次精度；分页优化器用于管理内存压力，也不能保证任何 batch 都不会超出显存。[12] 显存估算需要分别列出基础码、常数、适配器状态、激活与临时反量化缓冲，不能只用基础参数乘四位作为整个训练进程的容量。

适配器的独立文件还依赖底座、词表、模块命名、缩放规则与目标矩阵形状。形状能够加载，只是最低检查；若词表 ID 或层语义已经变化，权重文件仍可能在错误函数上运行。版本记录应绑定这些依赖，恢复时检查它们共同一致。路由可以隔离不同业务的增量，却不能免除基础模型共享带来的容量和安全边界；回滚适配器也不应留下新模板、旧量化底座的混合配置。

6.3 量化表示、误差与执行成本

flowchart TD
A["原张量与共享轴"] --> B["缩放及量化码"]
B["缩放及量化码"] --> C["打包与执行算子"]
C["打包与执行算子"] --> D["误差及任务验收"]

数值编码不是执行能力

量化需同时说明目标张量、编码、共享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 的对齐或重排会增加开销。

离散网格的直觉可以通过一个小数组建立。使用前述对称四位约定，原值取零点一、零点二、零点三和七，最大绝对值校准得到步长一，前三个数都会舍入到零，最后一个精确表示。若把阈值缩小到零点三，前三个值能被较细网格表示，但七会饱和到零点三，产生六点七的误差。小值更精细并不等于总体平方误差更低；是否值得丢掉极值还取决于这个值对应的通道、出现频率和下游作用。算例说明为什么校准需要目标，而不是证明任何一种阈值总是更好。

在没有饱和、采用最近邻舍入的均匀量化中，单项绝对误差最多为半个步长。这个界依赖范围条件；一旦真实值越过可表示端点，误差可以远大于半步长。随机舍入则以相邻码的概率混合保持局部期望，误差不再用同一个半步长界描述。若原值已被裁剪，期望守恒最多针对裁剪后的值；若 scale 自身又被低精度表示，完整重建也多一层误差。不能把某一步无偏直接推广为整个网络输出无偏。

权重误差对输出的作用由输入决定。记原线性层 \(y=Wx\)，量化误差矩阵 \(E=\widehat W-W\)，则输出扰动为 \(Ex\)，并满足一致范数下的 \(|Ex|\leq|E||x|\)。这个上界能说明输入尺度会放大误差，却通常偏保守，也没有表达输入集中在哪些方向。若把校准输入视为随机变量，二阶矩为 \(C=\mathbb E[xx^\top]\)，则平均输出平方误差为

\[ \mathbb E|Ex|_2^2=\operatorname{tr}(ECE^\top). \]

因此，同样大小的权重误差在不同输入分布上会有不同后果。若某输入方向几乎不出现，沿该方向的误差对校准输出影响很小；若线上突然大量出现该方向，原来的评价就不再充分。这是本书对线性层的推导，也是理解激活感知方法的共同入口，并不等于校准二阶矩能完整预测语言模型任务分数。

一个二维反例更直观。假设某输出行的误差为 \(e=(\varepsilon,-\varepsilon)\)。当输入始终近似 \((1,1)^\top\) 时，两项互相抵消，输出误差接近零；换成 \((1,-1)^\top\) 时，输出误差变成 \(2\varepsilon\)。权重的均方误差没有改变，输入相关性却改变了输出。若只在第一类输入上校准，就可能低估第二类输入的风险。这不意味着应收集所有可能输入，而是要求校准集覆盖部署任务的主要方向，并用独立样本发现未覆盖的关键切片。

更深网络还会传播误差。局部线性化可把某层扰动经后续层的 Jacobian 传到输出，但这只是当前输入和小扰动附近的近似；经过非线性、归一化与注意力后，不同层的误差可能放大、抵消或改变激活区域。不能把所有层的权重误差简单平均后称为模型质量。逐层重建误差适合定位敏感部位，任务级回放用于确认最终效果，两种指标服务于不同问题。

对于贪心选择，存在一个有用但有限的间隔条件。设原始最高和第二高 logit 的差为 \(\Delta\)，每个 logit 的扰动绝对值都不超过 \(\epsilon\)。如果 \(\Delta>2\epsilon\)，最高项仍不会被其他项超过。这个结论来自最坏情况下第一名下降与第二名上升的合计幅度，是本书推导。它只保护当前相同上下文的一步 argmax；对于随机采样，概率即使轻微变化也可能改变同一随机数对应的结果，而一步变化又会改变未来上下文。只有对整条生成路径逐步满足相应条件，才能继续讨论整段保持，不能从一次输出间隔直接推出回答可靠性。

表示成本也必须含元数据。以四位码、每组一百二十八个权重和十六位 scale 的教学布局为例，一百二十八个码占六十四字节，scale 再占两字节，所以有效位宽是四点一二五。若再加十六位零点，就变成四点二五；若最后一组只有少数有效权重，却仍按完整块打包，这个组的平均成本会更高。稀疏高精度例外还需要索引和对齐信息，不能只把例外值本身计入。压缩率取决于具体制品，不是“INT4”四个字符就能唯一确定。

物理布局之所以重要，是因为矩阵乘法按特定顺序读取元素。逻辑上同一矩阵可以按行组量化，也可以转置后按另一轴分组；如果转换时仅转置量化码却没有同步处理 scale，解出的数值就会错误。即使数学结果一致，不同布局也会影响合并访存、解包和张量核心输入。离线转换应做序列化重载与小矩阵逐元素检查，再进入整模型测试。文件能够被读取，不能代替数值语义检查。

NVFP4 更能说明表示与训练配方的区别。该文档版本默认对权重使用二维缩放，对激活和梯度使用一维缩放，随机舍入仅启用于梯度；其面向权重梯度矩阵乘法的路径还使用随机 Hadamard 变换平滑输入分布。[15] 这些是特定配方的机制，不是所有四位浮点导出物都具备的性质。正文中的一维四点五位账本只用于那种共享轴，不能拿来反推二维权重文件或完整训练状态的真实字节数。

最终要问的是压缩消除了哪种瓶颈。若延迟主要来自权重从显存到算子的读取，减少字节可能有利；若主要来自大批矩阵计算，低位格式能否使用合适的计算核心更重要；若主要来自长上下文缓存或排队，单纯权重量化的收益可能有限。不同请求长度和批大小会改变瓶颈，所以同一量化模型可能在一个负载上更快、另一个负载上更慢。性能结论必须带上形状与负载，而不是仅携带模型名字。

6.4 校准如何保护任务能力

flowchart LR
X["代表性校准输入"] --> G["GPTQ 输出重建与补偿"]
X --> A["AWQ 保护敏感权重通道"]
X --> S["SmoothQuant 迁移激活难度"]
G --> V["独立开发集选择"]
A --> V
S --> V
V --> T["冻结测试及真实算子回放"]

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

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

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

KL方法也必须先规定候选阈值下的共同支持。以下采用教学约定：固定原始直方图的边界，对每个阈值a把尾部计数折入保留区间的边界bin，并归一化为该候选的参考分布\(p_a\)。将这个分布的保留bin合并到低位码桶，再把每个码桶的概率均匀回分给桶内原先满足\(p_{a,j}>0\)的bin，得到同一保留bin支持上的\(q_a\)；回分分母是桶内正概率bin的数量，而不是桶的总bin数；该数量为零时桶概率也为零，不执行除法。原本为零的bin保持零。计算 \(D_{KL}(p_a\Vert q_a)=\sum_{j:p_{a,j}>0}p_{a,j}\log(p_{a,j}/q_{a,j})\)后选阈值。该约定使参考正概率bin得到正重建概率；若其他回分规则产生正概率对应零q，结果应记无穷，或事先规定对共同支持作平滑并重新归一化，不能直接跳过该项。尤其不能保持未裁剪的原始p，却给裁剪区间外的q填零，否则非零尾部会使KL无穷。不同后端对折尾顺序、零bin和回分有不同实现，复现时须保存具体版本与规则，本教学定义不声称逐项复现某个后端。[16]

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

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

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

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

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

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，逐候选检查折尾后的参考分布与重建分布具有相同保留bin支持，验证零bin回分规则、归一化及非零尾部案例。练习只规定输入输出和验收，尚无配套代码、模型量化或GPU实测；不要用一次数组误差下降声称模型成功。

从上一节的二阶矩表达可以看出，GPTQ 使用的二阶信息并不是对整套语言建模任务求精确 Hessian。对于一行权重和固定校准输入，输出重建目标是一个二次函数，其 Hessian 与 \(XX^\top\) 成比例。这个局部问题可以精确写出二阶结构，但把各层分别量化的过程仍只是全模型质量的代理。校准输入不足时矩阵可能奇异或病态，阻尼既帮助数值稳定，也改变补偿的权衡；因此实现中的阻尼参数不是可以任意省去的装饰。[17]

误差补偿的思想可以用两个相关输入说明。设目标是保持 \(w_1x_1+w_2x_2\)，且校准样本总有 \(x_2=x_1\)。如果量化第一项使 \(w_1\) 增加了零点一，那么让第二项减少零点一，就能在这些输入上抵消输出变化。但若线上出现 \(x_2=-x_1\)，两个误差会同向叠加。这是教学极端例，不是 GPTQ 的完整算法；它同时解释补偿为何有用、为何依赖输入，以及独立任务验证为何不可取消。真实算法需要在多个输入方向和离散码约束之间折中。

GPTQ 为扩大规模，使用各输出行共用的量化列顺序，把部分补偿延迟到块处理结束，并用 Cholesky 分解提高数值稳定性。阅读算法时尤其要注意符号：论文伪代码把原来表示逆 Hessian 的变量重赋成它的 Cholesky 因子，后续对角元素已不是未经分解的逆矩阵对角元素。[17] 如果只从两个段落各摘一个公式，再沿用同一个变量名，很容易把误差除错尺度。书稿推导应分别记逆矩阵与三角因子；没有实现和数值测试时，不声称已经复现整套量化器。

校准还存在传播次序。先量化的模块改变了后续模块实际接收的激活，因此后续校准输入可以来自部分量化网络，而非始终来自完整浮点网络。GPTQ 的实验流程按 Transformer 块处理，并重新计算后续块输入。[17] 这能让后续量化适应已产生的变化，却不能保证所有误差都被补偿。若更换处理次序、并行量化多个块或复用旧激活缓存，应把它视为实现变化，并重新检查质量和资源。

AWQ 的缩放需要同时看量化前后的函数。设 S 为正对角矩阵，令 \(W’=WS\)、\(x’=S^{-1}x\)，原始乘积不变。放大某些输入通道对应的权重列，可能让它们相对量化步长更容易表示；但组内极值也可能被推高，导致其他权重更粗糙。于是，保护敏感通道与影响邻近通道之间存在取舍，不能把 scale 一直增大。AWQ 用激活信息选择缩放，并结合校准数据搜索；其动机中保留少量权重高精度的实验，不是最终方法的存储格式。[18]

SmoothQuant 使用同类可逆缩放，却主要处理权重与激活共同量化时的困难分配。某些输入通道存在很大的激活值，直接用共同范围会压缩普通激活的有效分辨率；把该通道的激活缩小、权重放大，可以把困难从激活侧迁向较易离线处理的权重侧。[19] 迁移不等于消失：权重侧也有范围与粒度限制，缩放过强仍可能损害它。因此 W8A8 的评价应分别检查权重、激活与最终输出，而不是只报告激活直方图变得平滑。

这些方法还不能与混合精度离群分支混为一谈。LLM.int8 对特定离群特征维度使用较高精度计算，SpQR 则在压缩表示中为高误差权重保留稀疏例外；二者保护的对象与索引结构不同。[20][22] 如果将所有方法统一写成“保留百分之一高精度”，就会丢失核心算法差异，也无法估算实际索引、分支与算子成本。方法比较应先说明哪个张量被量化、哪些值进入例外、推理怎样恢复乘积，再讨论性能。

对贯穿案例，校准目标可以聚焦字段提取，但校准样本不能只有成功的短工单。长日志、罕见错误码、混合语言、负金额和缺失字段可能激活不同方向；这些切片需要按预期部署范围覆盖。开发阶段比较敏感层回退和组大小，最终测试则检查字段值与证据是否一致。若困惑度接近基线而金额错误率上升，应优先保留这个任务失败事实，而不是用总平均宣称近乎无损。校准指标帮助解释误差，业务约定决定误差是否可接受。

6.5 蒸馏迁移的分布与行为

flowchart LR
T["固定教师"] --> P["同温度软分布"]
T --> R["生成文本与轨迹"]
P --> K["事件空间对齐后计算 KL"]
R --> F["验证过滤后做序列监督"]
K --> S["学生更新"]
F --> S
S --> E["独立能力与成本验收"]

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 生成数据可能限制覆盖并传递教师错误；只有教师文本时无法直接利用完整软概率，但仍可构成有效监督。代码蒸馏要运行测试，数学蒸馏要验证答案，工具蒸馏要检查环境状态，不能只比较 token-level loss。

蒸馏的目标选择

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

温度的作用可以直接从 softmax 梯度看出。令固定教师 logits 为 \(a_i\)，学生 logits 为 \(z_i\)，同一温度 T 下的分布为 \(p_i\) 与 \(q_i\)。对教师到学生的 KL 求学生 logit 导数，有

\[ \frac{\partial D_{\mathrm{KL}}(p\Vert q)}{\partial z_i} =\frac{q_i-p_i}{T}. \]

教师熵与学生参数无关，所以在教师固定时，使用软标签交叉熵得到相同学生梯度。若教师也参与更新，这个常数论证就不能直接沿用；若反向 KL 交换了两个分布，其梯度和优化倾向也不同。明确 KL 方向比只写“让两个分布接近”更重要。经典蒸馏论文用同温度软目标，并让硬标签项保持普通温度。[23]

为何又要乘 T 的平方？在温度足够高、类别数固定时，中心化后的 logits 相对温度很小，softmax 可作一阶近似。记类别数为 K，分别减去教师和学生各自的 logit 均值，有 \(q_i-p_i\approx[(z_i-\bar z)-(a_i-\bar a)]/(KT)\)。再乘前面梯度里的 \(1/T\)，就出现 \(1/T^2\) 的量级。补乘 T 平方能抵消这个高温近似下的衰减，但不能保证任意温度下梯度范数严格相同，也不表示温度越高信息越多。[23] 温度趋于很大时分布接近均匀，数值差异如何被利用仍依赖精度、损失权重和学生容量。

例如教师在三个类别上给出零点六、零点三、零点一，硬标签只告诉学生第一类胜出，软分布还表达第二类比第三类更接近教师判断。但这里的“接近”是教师的统计偏好，不是语义真理。教师可能因为数据偏差把两种故障混淆，学生也会学习这种关系。对于风险不同的类别，应把错误代价与独立标签纳入评价，而不是因为软分布平滑就认为监督一定更可靠。教师置信高也不是正确性证书。

自回归蒸馏多了一层条件对齐。在同一个前缀下比较教师和学生的下一 token 分布，要求它们的事件空间一致。如果词表不同，同一个 ID 不表示同一个字符串；如果切分不同，第五个 token 甚至可能处在不同字符位置。直接逐位置 KL 会比较无关事件。可行路线包括使用共享词表、构造明确的字符串级对齐目标，或者只用教师生成文本重新按学生词表编码。最后一条路线最简单，但它学的是已选中的序列示范，而不是教师所有候选的软概率。

即便词表相同，前缀来源也会影响目标。只在正确答案前缀下训练，学生推理时一旦自己走偏，就可能进入训练中很少出现的状态；只在教师生成的前缀上学习，也不能确保覆盖学生自己的错误。可以在开发实验中加入学生生成的前缀，由教师或验证器提供后续指导，但这改变了采样分布和标注成本。应记录哪些前缀来自数据、教师或学生，而不是把所有蒸馏样本当成独立同分布的现成标签。

对推理轨迹尤其不能只看长度。一个长过程可能包含正确结论与错误中间步骤，一个简短过程也可能足够完成任务。如果学生容量有限，要求它逐字复制教师的冗长解释，可能把训练资源用在风格和连接词上。更合适的实验是同时比较结果监督、经过验证的过程监督和压缩后的过程监督，固定题目与输出预算，再看独立成功率。哪些过程值得保留应由可验证约束决定，不能把教师说得多当成知识更多。

蒸馏也没有自动实现压缩。若教师和学生结构一样大，只改变监督来源，推理权重与计算可能几乎不变；若学生更小，容量损失需要由数据与目标选择补偿。DistilBERT 和 MobileBERT 的结果来自特定编码器结构、训练目标与设备，展示了结构设计和监督可以共同起作用，并没有给所有生成模型提供固定压缩比例。[24][25] 因此，学生配置应先满足部署约束，再确认哪些能力值得用有限容量保留。

对于工单助手，可以让教师标注故障类别与证据句，再由规则检查字段合法性、证据是否存在、金额是否匹配原文。通过的样本用于训练小学生，未通过的样本保留为教师失败记录，不能静默丢掉后宣称教师准确率更高。评价学生时，应同时比较原教师、未蒸馏的小模型和蒸馏后学生，才能区分学生本来就具备的能力与蒸馏新增的收益。少数困难任务可以路由回教师，但路由规则本身也要有独立评估。

这条路线的成本由离线与在线两部分组成。离线包括教师生成、验证、过滤和学生训练；在线包括学生推理、重试与回退教师。若任务量很少或分布变化很快，离线投入可能来不及摊薄；若重复任务很多且边界稳定，小学生可能降低长期成本。这是本书的成本推导，不是蒸馏论文保证的收益。拒绝输出或升级处理也应作为结果类别统计，不能只在学生成功的子集上计算平均成本。

6.6 多模态接口与联合验收

flowchart LR
I["图像与预处理"] --> V["视觉编码器的特征序列"]
V --> P["逐特征投影"]
V --> Q["固定查询压缩"]
P --> L["语言前缀或交叉注意力"]
Q --> L
L --> O["答案与证据区域"]
O --> E["数字核验及图文冲突回归"]

图文对齐的起点

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

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

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

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

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

InternVL 等工作探索更高分辨率和更大视觉基础模型，说明视觉 token 数和细节能力存在明显权衡 [32]。高分辨率可能提升小文字和局部目标识别，通常也增加视觉端计算和内存需求；语言上下文与 KV Cache 是否增加，取决于连接器是否输出更多 token。BLIP-2 的固定查询和 Qwen-VL 的固定长度压缩说明，视觉输入变长不必使语言前缀同步变长。[29] [31] 端到端延迟还受内核、批量和并行执行影响，必须实测；多图和视频还要处理帧采样、时间顺序和跨帧一致性。

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

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

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

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

视觉 token 数是一个核心预算。在视觉 patch 直接拼接到语言序列的架构中，降低分辨率或合并 patch 可以缩短上下文，但可能丢失小字体、表格线和局部目标；提高分辨率可能改善 OCR 和定位，并增加视觉端计算。使用固定查询压缩时，语言侧前缀可以保持不变，应分别统计视觉编码长度与连接器输出长度，再测量 prefill、KV Cache 和吞吐。多图输入还要保留图像边界、顺序和来源，否则模型可能把不同页面的字段混在一起。视频则增加时间采样和跨帧一致性问题，不能简单把每一帧独立描述后拼接。

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

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

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

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

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

多模态模型还要做输入缺失测试：只有文本、只有图片、图片损坏、图片尺寸异常、OCR 为空、多图顺序改变、视频帧丢失。模型应能识别输入不足并请求补充，而不是用语言先验填满空白。把这种“正确失败”纳入 SFT 和偏好数据，是本书建议检验的补充方案；收益应与增加正常图文问答的基线对照。

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

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

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

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

图文对齐的目标也决定了模型接口。CLIP 在一批图文配对中构造相似度矩阵，分别从图找文、从文找图计算交叉熵。正确配对是监督信号，其他批内配对形成对照；相似度尺度在训练中学习。[26] 这个目标能学习匹配表示，但没有直接训练逐 token 回答过程。将相似度最高的描述当作答案，与一个生成式视觉语言模型写出新回答，是两种不同计算。遇到多个描述都合理的图片，批内负例还可能包含语义相近样本，不能把配对标签直接等同所有语义关系。

连接方式决定视觉信息怎样进入语言计算。简单投影把每个视觉特征变成语言嵌入宽度的向量，通常保留较多局部信息，也直接占用前缀位置。BLIP-2 使用可学习查询从视觉特征提取固定数量的信息：原论文采用三十二个查询，输出长度不随视觉输入特征数直接增长。[29] 因此，分辨率提升可以增加视觉端与查询交互的成本，却保持语言前缀数量不变；代价是信息必须通过固定瓶颈。细节是否丢失要由任务测试决定，不能只按上下文更短判断方案更优。

Flamingo 使用另一条路径：Perceiver 将可变视觉特征压成固定数量，再由插入冻结语言层之间的交叉注意力读取。新增分支通过零初始化的 tanh 门控接入，使开始时语言路径保持原有函数；不同规模配置的插层频率并不相同。[28] 这种结构的视觉特征不是简单当成全部语言前缀拼进去，因此不能直接套用拼接架构的自注意力长度公式。其文本位置直接读取最近的前置图像，但更早图像仍可能通过先前文本的自注意力间接影响当前状态，不能解释成模型绝对看不到历史图片。

训练阶段同样没有统一冻结模板。初代 LLaVA 先训练投影，再更新投影与语言模型，视觉编码器保持冻结。[30] Qwen-VL 的第一阶段冻结语言模型、更新视觉端与连接器，第二阶段解冻全模型，指令阶段再冻结视觉端。[31] 同样叫“图文对齐”，优化的参数和数据目标可以不同。冻结大模块减少其优化器状态，但当梯度仍需穿过它流向连接器时，并不自动省去全部反向计算。

Qwen-VL 还提供一个具体预算例：第二阶段把图像边长从二百二十四提高到四百四十八，视觉特征序列由二百五十六增至一千零二十四，但连接器查询数仍为二百五十六。[31] 这个记录说明，视觉 token 需要注明是哪一层的 token。若本书另外假设直接拼接且不压缩，边长翻倍、patch 大小不变时，特征数约增至四倍；那只是几何推导，不是对所有模型语言上下文的预测。

对扫描工单，接口预算最终要回到证据。若金额字符在预处理缩放时已经模糊，语言模型再强也无法可靠恢复缺失像素；若连接器遗漏某一局部，增加回答长度也不能重新获得它。可以保存裁剪区域与原图坐标映射，用高分辨率重读或专门 OCR 检查关键字段，再比较同一页面上的结果。这个流程把感知失败与语言推理失败分开，避免把所有错误都归因于需要更多视觉指令数据。

模型报告中也应分开“输出了坐标”和“坐标证明答案正确”。一个边界框存在于图中，只能检查引用区域的形式；框内是否真的有目标文字、识别是否正确、推论是否由该区域支持，还需要不同层次的验证。图文冲突测试可以把图片中的金额与提示里故意给出的金额设为不同，观察模型是否依证据回答并说明冲突。无图、损坏图和模糊图则用于检查信息不足时的行为，不应与正常视觉识别准确率混在一个总分里。

任何算法方案都应同时报告质量、成本和风险。质量包括任务成功、格式、事实、代码执行和多模态感知；成本包括训练 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、方法参数、导出工具、兼容后端、模板、视觉处理、评估与已知失败。只对已测形状和设备声明适用性；影子回放不执行工具副作用，灰度有停止条件并能恢复上一整套配置。服务端的调度与容量细节交给推理服务与资源调度，本章负责可重放的算法候选和验收证据。

上面的制品记录解决“这个版本由什么组成”，模型卡还要解决“它承诺什么、不承诺什么”。一个分类 adapter 只保证某套标签和输入格式，不应被路由到开放式问答；一个文档视觉模型只保证规定页型和分辨率，不应被默认用于医学影像；一个 INT4 模型只在指定 kernel 和上下文范围内通过评估，不应因为文件可以加载就宣称所有硬件都兼容。多模态制品还要说明图片、视频、OCR 的处理方式，是否保留原图、是否缓存视觉特征，以及输入模态、预处理和语言生成各层的约束分别是什么。把边界写进模型卡并随权重一起版本化，可以减少误用；跨版本比较时还要同时看任务成功率、格式错误、量化退化、视觉幻觉与尾延迟，只回滚权重而保留新模板会留下更隐蔽的协议错误。

本章小结

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

面向企业落地，最重要的不是选择一个“最先进”的方法，而是让适配目标、数据监督、压缩格式、输入模态、评估指标和版本回退形成一条可追溯的验收证据链。只有这样，算法优化才会转化为可维护、可观测、可控制的模型能力。

参考资料

1. Bai, J., et al. Qwen Technical Report. arXiv, 2023. 访问日期：2026-10-16
2. Zhang, A., et al. 《动手学深度学习》：softmax 回归. 中文在线版 2.0.0. 访问日期：2026-10-16
3. Zhou, C., et al. LIMA: Less Is More for Alignment. NeurIPS, 2023. 访问日期：2026-10-16
4. Zhang, Q., et al. AdaLoRA: Adaptive Budget Allocation for Parameter-Efficient Fine-Tuning. ICLR, 2023. 方法正文核验日期：2026-11-01
5. Liu, H., et al. Few-Shot Parameter-Efficient Fine-Tuning is Better and Cheaper than In-Context Learning. NeurIPS, 2022. 访问日期：2026-10-16
6. Houlsby, N., et al. Parameter-Efficient Transfer Learning for NLP. ICML, 2019. 访问日期：2026-10-16
7. Li, X. L., & Liang, P. Prefix-Tuning: Optimizing Continuous Prompts for Generation. ACL, 2021. 访问日期：2026-10-16
8. Lester, B., Al-Rfou, R., & Constant, N. The Power of Scale for Parameter-Efficient Prompt Tuning. EMNLP, 2021. 访问日期：2026-10-16
9. Hu, E. J., et al. LoRA: Low-Rank Adaptation of Large Language Models. ICLR, 2022. 访问日期：2026-10-16
10. Ben-Zaken, E., Ravfogel, S., & Goldberg, Y. BitFit: Simple Parameter-efficient Fine-tuning for Transformer-based Masked Language-models. ACL, 2022. 访问日期：2026-10-16
11. Liu, S.-Y., et al. DoRA: Weight-Decomposed Low-Rank Adaptation. ICML, 2024. 方法正文核验日期：2026-11-01
12. Dettmers, T., et al. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS, 2023. 访问日期：2026-10-16
13. Nagel, M., et al. A White Paper on Neural Network Quantization. arXiv, 2021. 访问日期：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-11-01
16. Wu, H., Judd, P., Zhang, X., Isaev, M., & Micikevicius, P. Integer Quantization for Deep Learning Inference: Principles and Empirical Evaluation. arXiv, 2020. 访问日期：2026-10-16
17. Frantar, E., et al. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. arXiv, 2022. 方法正文核验日期：2026-11-01
18. Lin, J., et al. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys, 2024. 访问日期：2026-10-16
19. Xiao, G., et al. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. ICML, 2023. 访问日期：2026-10-16
20. Dettmers, T., et al. LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale. NeurIPS, 2022. 访问日期：2026-10-16
21. Yao, Z., et al. ZeroQuant: Efficient and Affordable Post-Training Quantization for Large-Scale Transformers. NeurIPS, 2022. 访问日期：2026-10-16
22. Dettmers, T., et al. SpQR: A Sparse-Quantized Representation for Near-Lossless LLM Weight Compression. ICLR, 2024. 访问日期：2026-10-16
23. Hinton, G., Vinyals, O., & Dean, J. Distilling the Knowledge in a Neural Network. NeurIPS Deep Learning Workshop, 2015. 访问日期：2026-10-16
24. Sanh, V., Debut, L., Chaumond, J., & Wolf, T. DistilBERT, a Distilled Version of BERT. arXiv, 2019. 访问日期：2026-10-16
25. Sun, Z., et al. MobileBERT: a Compact Task-Agnostic BERT for Resource-Limited Devices. ACL, 2020. 访问日期：2026-10-16
26. Radford, A., et al. Learning Transferable Visual Models From Natural Language Supervision. ICML, 2021. 方法正文核验日期：2026-11-01
27. Kim, W., Son, B., & Kim, I. ViLT: Vision-and-Language Transformer Without Convolution or Region Supervision. ICML, 2021. 访问日期：2026-10-16
28. Alayrac, J.-B., et al. Flamingo: a Visual Language Model for Few-Shot Learning. NeurIPS, 2022. 方法正文核验日期：2026-11-01
29. Li, J., et al. BLIP-2: Bootstrapping Language-Image Pre-training with Frozen Image Encoders and Large Language Models. ICML, 2023. 方法正文核验日期：2026-11-01
30. Liu, H., Li, C., Wu, Q., & Lee, Y. J. Visual Instruction Tuning. NeurIPS, 2023. 访问日期：2026-10-16
31. Bai, J., et al. Qwen-VL: A Versatile Vision-Language Model for Understanding, Localization, Text Reading, and Beyond. arXiv, 2023. 方法正文核验日期：2026-11-01
32. Chen, Z., et al. InternVL: Scaling up Vision Foundation Models and Aligning for Generic Visual-Linguistic Tasks. arXiv, 2023. 访问日期：2026-10-16
33. Touvron, H., et al. Llama 2: Open Foundation and Fine-Tuned Chat Models. arXiv, 2023. 访问日期：2026-10-16

第7章 具身智能与 Physical AI

资料说明：本轮先核验原始论文、官方研究资料与中文教材并建立来源—论点映射，再展开机制与案例。核验日期为 2026 年 11 月 1 日；正文中的数值手算、状态示例和闭环任务均为教学构造，不代表真机实测。

具身智能要求模型在会被动作改变的环境中完成任务。它不仅需要识别“画面里有什么”，还要估计未被直接观察的状态，比较行动后果，把计划变成当前身体能够执行的动作，并用真实反馈修正判断。世界模型、视觉语言动作模型与传统控制器在这里解决不同问题，不能仅凭名称互相替代。

本章围绕一个问题展开：怎样判断一个学到的预测或策略，确实为闭环行动提供了有用信息。答案需要同时检查状态表示、动作条件、时间对齐、数据覆盖和任务验收。来源论文支持具体机制与研究边界，本书的算例用于解释这些条件如何影响系统设计。

7.1 从观测到可行动状态

flowchart TD
 A["真实状态"] --> B["传感器观测"]
 B --> C["结合历史更新信念"]
 C --> D["提出候选动作"]
 D --> E["约束检查与执行"]
 E --> A
 C --> F["预测可能后果"]
 F --> D

语言模型和具身算法都根据历史信息选择下一步，但它们面对的状态、动作后果和验证方式不同。语言模型主要处理离散 token，生成结果通常可以重放或重试；具身系统还要处理带噪声和延迟的传感器状态，并输出移动、抓取、推拉、避障或导航等连续或混合动作。动作会改变后续观察，有些后果无法撤销，因此状态表示、反馈来源、数据成本、评估方法和安全约束都随之变化。本节先从观测与状态的区别建立共同框架。

语言模型的很多工程直觉在具身场景里会失效。例如，纯文本生成的候选通常可以低成本重放或丢弃，物理动作的重试却可能撞坏物体；文本模型的置信度也不能直接充当事实或安全保证，机器人上的过度自信还会越过控制边界。文本系统同样需要真实服务路径评估、发布门禁与治理；具身系统除此之外还必须验证动作改变环境后的闭环状态。把这些约束差异讲清楚，比记住几个模型名更有用。

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

最简化的表达是：

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

这里的 observation 是图像、激光雷达、触觉、本体状态等直接读数；state 是从当前与历史观察中估计出的环境状态，可以显式表示，也可以是 latent state；action 是转向、抓取、推拉、移动或导航等候选操作；prediction 可以是下一状态、奖励、碰撞风险、任务进度、可行动性或未来视频帧；policy 或 planner 再根据这些预测选择动作。世界模型的关键能力因此是预测状态怎样随动作变化，而不是存储多少静态事实。

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

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

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

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

World Models、PlaNet 和 Dreamer 都属于这一路线，但具体的隐状态、规划和策略学习机制放到 7.2 节展开 [1][2][3][4]。

近年来，大模型社区也把能生成可交互环境的视频模型称为世界模型。普通视频生成关注提示到视频的视觉结果，交互式环境模型还接收动作序列，并维持物体、空间和交互状态。Genie 研究动作可控的生成环境，Cosmos 报告世界基础模型平台；两者的目标和接口不同，不能视为可互换的模拟器 [5][6]。具体的表征预测与平台化机制在 7.3 节讨论。

JEPA 路线强调在 latent space 中预测与任务相关的表征，而不是重建每个像素；这种取舍延续了表示学习以任务相关抽象服务下游问题的基本思路 [7]。V-JEPA 研究视频特征预测，V-JEPA 2 进一步展示动作条件后训练与规划 [8][9]。这种定义只说明预测对象不同；是否更适合某个决策任务仍需下游验证，不能由 latent prediction 本身推出。

这一项是应用范围，而不是第四种模型定义。在自动驾驶、机器人和工业仿真中，动力学模型、生成式环境或结构化模拟器都可以参与数据生成、极端场景测试和策略训练。CARLA 等开放仿真器说明，标准化场景、传感器和交通参与者是评估自动驾驶策略的重要基础 [10]；模型是否有用仍要由物理合理性、传感器逼真度、长尾覆盖和策略迁移结果共同判断。

观测、状态与信念不是同一个对象

先用一个贯穿全章的教学任务建立符号：固定机械臂把桌面上的空杯放到指定托盘中，任务范围限于隔离实验台、已评估的物体和动作，不包含真实设备操作参数。真实状态 \(s_t\) 可以包含杯子位姿、速度、是否被夹持、机械臂关节状态和接触关系；相机图像 \(o_t\) 只是这个状态的一次投影。动作 \(a_t\) 可能是末端位姿增量，也可能是某个底层控制器的目标。不同动作定义不能共用一个没有单位的向量。环境转移 \(P(s_{t+1}\mid s_t,a_t)\) 描述执行后怎样变化，观测模型 \(P(o_t\mid s_t)\) 描述真实状态怎样产生传感器读数。

即使一张图像显示杯子位于同一个像素位置，杯子也可能静止、向左滑动或刚被夹具挡住。三种真实状态对下一动作的响应不同。如果把单张图像直接当成完整状态，就违反了“当前状态足以预测下一状态”的建模愿望。历史能帮助辨别速度和接触，但保存全部视频又带来计算开销，因此具身模型需要压缩历史，同时尽量保留影响行动后果的变量。PlaNet 用部分可观测决策过程表达这一问题，其隐状态不是摄像头读数的另一个名字。[2]

信念状态 \(b_t(s)\) 是在已收到的信息下对真实状态的分布。它允许系统同时保留“杯子还在夹具里”和“杯子可能已经滑落”两种解释，而不是在证据不足时强行选一个。中文概率教材强调概率可以表达不同形式的不确定性；这里将其用于环境状态估计。[11] 在已知转移与观测模型的理想离散例子中，先预测再更新：

\[ \bar b_t(s)=\sum_{s’}P(s\mid s’,a_{t-1})b_{t-1}(s’),\qquad b_t(s)=\frac{P(o_t\mid s)\bar b_t(s)} {\sum_{\tilde s}P(o_t\mid\tilde s)\bar b_t(\tilde s)}. \]

第一步把上次信念沿实际执行动作推进；第二步用新证据调整各假设权重。这里的求和在连续状态下通常变成积分，学习系统往往只计算近似表示。本书写出精确公式是为了说明信息来源，不意味着机器人运行时能够精确求解整个后验，也不意味着神经网络输出的“置信度”自动等于经过校准的信念概率。

假设杯子是否仍被夹持只有两个状态，预测阶段认为被夹持的概率为零点八。某传感器报告“未检测到杯子”；教学假定在确实夹持时出现该读数的概率为零点一，在已经掉落时为零点九。更新后的夹持概率为 \(0.8\times0.1/(0.8\times0.1+0.2\times0.9)\)，约为零点三零八。这个读数显著改变了判断，却没有把概率直接变成零。把一个二值告警写成确定事实，会丢失误检与漏检的语义；反过来，忽略告警继续沿旧信念执行，也会把状态估计与环境脱节。

若再读取第二个传感器，能否直接相乘取决于条件独立假设。两个检测器若都使用同一张模糊图像，其错误可能共享同一个原因，不能当成两份完全独立证据。视觉检测、夹具编码器和触觉信号的互补性来自测量机制，而不是来自接口数量。融合设计应说明每项读数测量了什么、何时采集、受哪些共因影响；增加多个名字不同但输入相同的模型，不一定减少不确定性。

状态更新还与时间相关。机械臂控制器发出动作后，相机到达的下一帧可能实际上拍摄于动作开始之前。若按消息到达顺序拼接，就会把旧图像解释成新动作的结果。动作时间、传感器采样时间与接收时间因此需要分别记录。状态估计可以在可接受的延迟范围内做对齐或外推，但缺失的时间信息无法靠增大模型参数可靠恢复。这是轨迹数据与普通图文样本的根本区别之一：顺序和间隔也是监督信号。

决策所需的信息与预测误差

好表示不一定保留所有视觉细节，却必须保留当前任务需要区分的未来。杯子花纹可能对放置无关，杯口朝向、夹持关系与托盘边缘却可能决定动作是否成功。若两个真实状态被编码成同一个隐向量，而某个候选动作在两种状态下后果明显不同，那么下游规划器无法仅凭这个隐向量恢复丢掉的差别。表示压缩是否合适，要通过动作后果和任务误差判断，而不能只看隐向量维度小不小。

这也说明“与任务相关”不是一次永久决定。为抓取训练的表示可能忽略杯内液体，而对搬运液体的任务，液面、速度和倾角就成为必要变量。奖励模型改变时，原来足够的压缩也可能不够。迁移一个世界模型到新任务，应检查新目标依赖哪些状态量，以及训练时是否存在能够辨别这些量的传感器或监督；不能仅更换一行任务描述就认定旧表示仍是充分的。

本书用三个层次区分误差。测量不确定性来自噪声、遮挡和分辨率限制；动态随机性来自在同一可观测条件下仍有多种合理未来；模型认识不足则来自数据覆盖、参数学习或结构假设不充分。前两类不总能通过更多同分布训练消除，第三类也不会因为输出分布很宽就被修复。多个模型预测差异可提示认识不足，但模型共享训练偏差时也可能一致地错；窄区间只说明模型集中，不能单独说明环境确定。

动作会改变未来信息，这使观察本身也可以成为规划对象。例如从另一角度看杯把，可能比立刻尝试抓取更有价值。理想决策可以比较信息获取后的预期任务收益与耗时，而不只是比较当前最短路径。不过移动相机或机械臂也是物理动作，可能改变遮挡和可达范围；不能把“再观察一次”当成零成本、零风险。全章案例中的主动观察只表示一种候选策略，具体是否允许执行由设备与场景约束决定。

最后，语言接口与物理接口并非两个互不相交的世界。文本 Agent 调用真实工具也面对部分可观、延迟和不可逆副作用；纯语言模型的 token 状态只是生成器内部的条件历史，不是外部世界的完整状态。具身智能的特殊性在于传感器与身体动态持续参与闭环，控制误差会随时间传播，并且状态更新、动作持续与反馈必须在物理时钟上对齐。讨论差异时应限定比较对象，不能把“文本可以重写”泛化成“语言系统没有外部后果”。

7.2 隐状态动力学与想象学习

flowchart TD
 A["实际动作与历史记忆"] --> B["状态先验"]
 C["当前真实观测"] --> D["状态后验"]
 B --> D
 D --> E["候选动作下的想象"]
 E --> F["规划或行为学习"]
 F --> G["执行并获取新观测"]
 G --> C

Ha 和 Schmidhuber 的 World Models 把这条链拆成三块：编码器把高维图像压到 latent，循环网络预测 latent 的时间演化，一个很小的 controller 基于 latent 选动作 [1]。PlaNet 在隐空间预测并在线规划，Dreamer 在学到的隐动态中展开想象轨迹来训练策略与价值函数 [2][3][4]。三者的共同点是：策略不必直接处理原始像素，而可以基于压缩后的状态决策。

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

状态表示通常混合视觉、语言、本体状态和历史动作。显式状态便于调试与约束，例如物体位姿、速度、关节角与碰撞标志；隐式状态更容易压缩复杂环境，但不易解释与验证。对用于控制或规划的世界模型，动作条件是区别于普通视频预测的重要接口：训练样本必须记录动作发生的时间、参数、执行结果与失败原因。表征预测模型不一定以动作作为预训练条件，但若要比较候选动作，仍需在后续阶段建立动作与状态变化的可检验关系。若动作与环境变化没有对齐，模型学到的只是相关性，无法在规划时比较不同动作。

预测误差还要区分来源。由传感器噪声、遮挡和多种合理未来造成的不确定性，不能简单归为模型失效；由训练覆盖不足、状态压缩丢失或动作时间错位造成的系统偏差，则需要修正数据与模型。工程上可以让模型输出候选未来或风险区间，并用后续观察更新状态，但区间本身也要校准。若模型在未见场景中始终给出很窄的区间，下游 planner 会把过度自信当成确定性；若区间始终过宽，预测又无法帮助动作排序。因此验收既要看点预测误差，也要看不确定性与真实失败频率是否对应。

中文序列模型教材区分“用历史观测预测”与“多步外推”，为理解误差积累提供了基础 [12]。短时预测可能看起来准确，连续展开后却逐渐漂移：误差在每一步进入下一状态，导致物体消失、场景重复或物理关系崩坏。缓解方向包括 latent 状态校正、真实观察重置、分层时间尺度、短 horizon 规划与多候选未来。世界模型不必预测唯一未来，更应表达多个可能结果与相应不确定性——把不确定性压成一个看似确定的视频，会让下游策略过度信任错误预测。

观察更新与想象展开必须分开。观察更新从历史、当前观测和上一步实际动作修正隐状态；想象展开从当前隐状态与候选动作预测下一状态。前者接触真实传感器，后者是预测，两种状态不能共享一个“已发生”标记。若隐状态压掉了决定未来的变量（杯中液体、接触状态、被遮挡的人），单帧预测仍可看似准确，动作比较却可能完全错误。本书建议先在短闭环中验证：给同一初始观察两个可执行动作，分别预测结果与不确定性，再用独立观测核对；并比较无动作条件、打乱动作与正确动作三组。若打乱动作后质量不变，模型可能主要利用视觉惯性而未学到有效的控制响应。这个检验是教学实验设计，尚未实现。

RSSM：把记忆路径与不确定状态分开

循环状态空间模型可以用四个接口展开。确定性记忆 \(h_t=f(h_{t-1},z_{t-1},a_{t-1})\) 保留过去的动态信息；先验 \(p_\theta(z_t\mid h_t)\) 在没有当前观测时预测随机状态；后验 \(q_\phi(z_t\mid h_t,o_t)\) 结合观测修正状态；解码器与奖励头分别从 \((h_t,z_t)\) 预测观测和任务信号。PlaNet 的 RSSM 明确区分这两条路径。[2] “确定性”指网络更新方式，不是宣称环境没有随机性；“随机状态”也不是随意添加噪声，而是用分布表示预测中尚未确定的部分。

当真实相机帧到达时，系统可以走后验路径；在内部比较尚未执行的动作序列时，没有未来相机帧，只能沿先验展开。两条路径共享动力学，却使用不同证据。如果在评估长时预测时把每一步真实未来图像又喂给后验，得到的是连续校正的状态估计成绩，不能冒充纯模型多步外推成绩。训练日志应明确当前状态来自真实观测更新还是想象采样，否则较低的预测误差可能仅仅来自偷用了未来信息。

考虑一个纯教学张量例子：批量四条轨迹，每条十六步，每步观察为三通道六十四乘六十四图像，动作有七个连续分量。视觉编码器先为每帧得到一百二十八维特征，确定性状态设为二百五十六维，随机状态设为三十二维。循环模型在每个时间步读取上一记忆、上一随机状态和动作，而不是将整条动作序列当作当前已经发生的事实。后验头额外读本步图像特征，输出随机状态分布参数；奖励头读两种状态的拼接。这些维度只用于检查接口，不是原论文配置或推荐规格。

训练目标通常同时要求状态解释观察、预测奖励，并让后验与先验接近。简化的每步损失可写为负观测对数似然、负奖励对数似然与加权 KL 项之和。前两项要求表示保留可预测信息，KL 项要求没有当前观察时的动力学先验也能跟上状态估计。如果重建项压倒其他目标，模型可能专注背景纹理；如果过早压强 KL，后验可能失去利用观察的能力。实际算法使用的平衡、正则化与分布形式不同，应按具体版本理解，而不能把一条简化损失当成 Dreamer 各代的完整实现。

这种训练还包含一个容易忽略的权衡：能重建图像的状态不一定最适合动作排序。若背景像素占据大部分重建误差，优化器可以通过改善墙面纹理降低损失，却仍未学会夹具是否接触杯子。奖励或任务相关预测能提供另一种监督，但奖励稀疏时又可能不足。表示学习因此是信息分配问题，不能仅比较总训练损失。可观察的诊断是分别检查关键物体状态、接触事件、奖励和行动排序，而不是用单一像素误差代表全部能力。

在线规划、想象学习与误差传播

在线模型预测控制先在当前信念下比较有限长度的动作序列，再执行所选序列的第一项，获得新观测后重新规划。PlaNet 用交叉熵方法搜索候选序列：从参数化分布采样一批动作序列，在隐空间计算预测回报，选出较好的部分，用它们更新采样分布，再重复若干轮。[2] 这里的“交叉熵”是优化算法名称，不是语言模型逐 token 的训练损失。它只是在有限预算内搜索，不能保证找到全局最优，也不证明模型认为最好的动作在真实环境中同样最好。

用一维推物教学例子说明滚动执行。目标位置为一，当前估计为零点四，模型假定下一位置等于当前位置加动作。规划两步时，候选甲为零点三、零点三，候选乙为零点二、零点二；仅按终点距离，甲预测准确到达，乙还差零点二。执行甲的第一步后，真实物体因滑动只到零点六。滚动控制会用零点六重新估计下一动作，而不是继续把旧预测零点七当事实。重新观察改善了反馈机会，但若观测也有偏差或动作存在延迟，闭环仍可能失败；“每步重规划”不是无条件稳定性证明。

Dreamer 则把额外计算更多放在训练阶段：从经验数据编码出的状态出发，在学到的动态中想象轨迹，训练策略提出高价值动作，并训练价值函数估计更远回报。执行时可以直接调用策略，而不必每一步重新运行大规模候选搜索。原始 Dreamer 使用不同步长回报的加权组合，并通过可微模型传播行为学习信号。[3] 这与在线规划的区别在于决策计算何时付出；两者都可能受模型偏差影响，策略网络也可能把模型中的漏洞固化下来。

下面给出本书的回报截断例子。假设折扣为零点九，想象的前三步奖励为零、零、一，第三步之后价值估计为二；按三步自举计算，起点估计为 \(0+0.9\times0+0.9^2\times1+0.9^3\times2=2.268\)。如果把后续价值完全删去，得到零点八一，可能低估需要较长准备过程的策略；如果后续价值高估，较短想象又会过度依赖这个错误尾值。因此延长想象与依赖价值函数是在不同偏差、方差和计算开销之间取舍，不是越长必然越准确。

预测误差为什么会累计，可以用一个有明确假设的界说明。先限定为确定性教学系统，真实转移记为 \(f\)，模型转移记为 \(\hat f\)。假设在同一有效域内，真实转移对状态是 \(L\)-Lipschitz，模型单步误差至多 \(\epsilon\)，并比较同一动作序列、同一状态度量下的真实轨迹和模型轨迹，且两条轨迹始终留在上述统一误差界有效的区域内。则误差满足 \(e_{t+1}\leq L e_t+\epsilon\)。从零初始误差展开 \(H\) 步，得到 \(e_H\leq\epsilon\sum_{i=0}^{H-1}L^i\)。这是教学推导，不是对所有机器人接触动力学的统一保证；碰撞、摩擦切换和离散接触模式可能使假设不适用。随机转移还需另外定义耦合条件下的期望误差或分布距离界，不能直接套用这个确定性逐轨迹结论。

若教学值 \(L=1\)，误差上界随时域线性增长；若 \(L>1\)，较早误差可能被放大；若局部收缩且 \(L<1\)，累计项可有有限上界。由此不能说世界模型必然指数崩坏，也不能由短视频预测准确推出长时可靠。更重要的是，规划器会主动选择训练数据中少见的动作序列，单步误差界可能在这些区域根本不存在。优化搜索越强，越可能发现模型“误以为可行”的捷径，计算预算和模型可信区域必须一起考虑。

一个典型模型利用例子是预测器误判杯子可以穿过托盘边缘而不碰撞，规划器便选择这条短路径。此时 planner 确实优化了给定目标，错误不在它没有认真搜索，而在模型遗漏了约束。限制规划时域、对模型分歧加惩罚、保留真实观察校正或引入外部几何检查，都可能减少这类失败，但每种方法仍有盲区。模型一致可能是共同偏差，几何检查也可能忽略柔性物体和接触力，因此需要把拒绝、误差和真实结果分别记录。

短时准确与长时收益之间还隔着动作排序。即便两个候选的绝对预测都有小误差，只要误差超过它们的价值差，就可能颠倒次序。本书建议在相同初始状态下构造可执行候选对，比较模型预测的优劣与独立环境中的结果，而不是只测平均下一帧误差。若排序常在接触边界失效，应优先增加对应状态和动作覆盖；若大多数预测准确但最优候选总失败，则要检查搜索是否集中利用了误差尾部。

7.3 表征预测与生成式世界模型

flowchart TD
 A["无动作视频"] --> B["表征或视频预训练"]
 B --> C["动作条件适配"]
 D["对齐的机器人交互"] --> C
 C --> E["预测候选后果"]
 E --> F["独立闭环评估"]
 B --> G["可视化与理解评估"]

2024 年之后出现的世界基础模型把这条路线推向平台化：先用大规模视频、仿真与传感器数据训练通用物理与交互先验，再针对机器人、自动驾驶等场景适配。Genie 从无标注视频学习动作可控的虚拟环境，UniSim 研究高层指令与低层控制条件下的视觉结果模拟 [5][13]；NVIDIA Cosmos 把世界基础模型、视频 tokenizer、数据管线与仿真生态组成栈 [6]。它们说明生成模型可以参与交互研究，但不能从画面一致推导摩擦、接触力、传感器噪声或安全控制都被正确模拟。选择训练环境时，应问动作是何种语义、是否有外部状态可校验、可维持多长闭环、失败后如何重置，以及用它训练的策略能否在独立环境受益。

预测表征为什么需要防止塌缩

像素预测需要回答“未来每个像素是什么”，表征预测则要求回答“未来或被遮挡区域中哪些特征可从已见内容预测”。后者能够减少对不重要细节的重建负担，但也把任务是否保留必要信息的问题交给了表示。以杯子为例，颜色变化可能不影响抓取，手柄方向却影响可达姿态；一个能很好识别“杯子”类别的表示，未必保留足够精细的朝向。表征空间中的小距离不能自动解释成物理空间中的小距离，更不能直接等同于安全裕量。

V-JEPA 的训练以可见视频区域的编码预测目标区域的编码，目标位置由时空坐标指定。这里的目标区域可以是被遮挡的空间块或时间块，不应把所有这类训练样本都说成“只看过去预测未来”。原论文用目标编码器的移动平均参数、停止梯度以及预测器设计来防止简单回归出现表征塌缩。[8] 这些机制形成的是学习配方，其效果仍要用下游任务检验，而不是一个适用于所有网络与数据的数学保证。

为什么常数表示是问题，可以直接观察一个简化目标。如果编码器对所有输入都输出同一个向量 \(c\)，预测器也总输出 \(c\)，两者差异为零，却没有保存任何可用于辨别物体或动作的信息。仅检查训练回归损失，就会把完全无用的解误认作完美预测。停止梯度让目标分支不被当前损失直接拉动，移动平均使目标变化相对缓慢，预测器则承担从可见区域到目标区域的映射；还需要遮挡任务、网络结构和数据共同提供有效学习压力。

本书用一个教学例子说明损失与任务的区别。假设两个模型在杯子场景的总体特征预测误差接近，模型甲保留背景与物体类别，模型乙保留位置变化与夹持状态。对“图片里有什么”的评估，两者可能相近；对“抬起夹具后杯子是否跟随”的评估，乙才提供所需信息。这个例子不是说所有表征都天然分成这两类，而是提醒评估协议会决定读者看到哪种能力。把视觉问答分数直接当作机器人动作成功证据，会跨过未经验证的接口。

V-JEPA 2 在视频预训练之后，冻结视频编码器并利用机器人交互数据训练动作条件预测器，形成 V-JEPA 2-AC；规划时比较想象表征与目标图像表征，再滚动执行动作。[9] 因此“没有目标环境训练”不等于“完全没有机器人动作数据”。它也不意味着自然语言任务已经自动转成图像目标。输入目标图像、动作坐标和机器人控制方式都是方法条件，缺少其中一项就要重新设计接口。

这里有一个有启发性的边界：论文指出相机位置会影响对动作坐标轴的推断，若机器人基座没有进入画面，坐标关系可能无法充分确定；作者还报告了长时展开误差与图像目标要求的限制。[9] 本书据此推导，学习式表示并没有消除几何信息需求，它可能只是把部分标定关系隐含地学进了模型。把相机随意换位置后仍使用相同动作向量，未必只是图像风格变化，也可能改变了观测与动作的关系。

生成环境、潜动作与物理模拟的边界

生成式环境把模型预测变成可观察的图像或视频，便于人理解和交互。Genie 的潜动作模型从视频变化中压缩出有限的动作码，动力学模型再根据这些码和历史帧 token 生成后续。训练时可以看到相邻帧来推断潜动作，交互时则由用户选择动作码。[5] 训练推断用到了后一帧，不代表部署策略能提前读取真实未来；这是学习标签或表征与在线决策之间的差别。

潜动作码也不是具有固定物理单位的电机指令。某个码在一组场景中倾向产生向右移动，可以帮助构造可控交互，却没有自然保证它对应多少米、多少弧度或多少扭矩。把视频学到的潜动作接到机器人，需要额外建立码与真实动作之间的映射，并验证这种关系在不同状态下是否仍成立。Genie 的行为迁移实验也使用少量真实动作标注建立映射。[5] 因而“无动作标注视频预训练”与“最终完全无需动作信息”是两个不同命题。

普通视频中的变化还混合了智能体动作、相机移动和外部事件。杯子在画面中向左，可能是杯子真的移动，也可能是相机向右运动。若训练目标只要求下一帧逼真，模型可以利用相关性完成预测，而不必识别真正可控制的原因。动作标签、相机位姿、本体状态与干预数据的价值，在于帮助区分这些因素。即使模型能从历史推测外部事件，它也不能把不可控制的事件当成自己的动作能力。

本书建议把世界模型的输出分成三种接口看待。第一种是状态或表征预测，面向动作排序和策略训练；第二种是可视化预测，面向人工诊断、场景构造和视觉任务；第三种是带可检查状态的仿真转移，面向接触、碰撞、传感器与闭环评估。一个系统可以同时提供多种接口，但视频看起来连续，不代表它内部维护了可查询的质量、速度或接触约束。数字孪生和神经生成模型可以互补，不能只因都能显示三维画面就认为等价。

UniSim 研究高层和低层条件下的视觉模拟，Cosmos 报告则将数据、tokenizer、预训练及下游适配放到平台中。[13][6] 这些工作提供的是生成与适配路线，不能把平台的内容过滤视为机器人停止碰撞的低层机制。前者可能过滤不适合生成的画面，后者必须基于执行状态和控制反馈及时响应；名称中都有“安全”并不意味着两者处理同一种风险。

世界模型也可以生成训练样本，但合成数量不等于新增独立信息。若一个模型总把某类抓取预测为成功，使用它生成大量“成功轨迹”再训练策略，会反复强化同一偏差。有效的合成数据设计应说明哪些因素被主动改变、标签来自什么独立机制，以及真实回归是否改善。对接触状态没有依据的模型，增加画面细节只能让错误更逼真，而不能弥补缺失的物理约束。

最后，世界模型评估应把真实性、可控性与任务收益分开。一个视频可以逼真但不响应动作，也可以正确响应粗粒度动作却丢失长时对象身份；一个表征预测器可以没有可视化解码器，却能有效排序短时动作。评价应从使用目的出发，再决定需要什么证据。对本章的拿杯任务，关键是候选动作是否改变正确对象、是否能被当前身体执行、预测是否帮助闭环完成，而不是单独评选最清晰的一段未来视频。

7.4 从语言技能到连续动作

flowchart TD
 A["语言目标与状态"] --> B["技能选择"]
 B --> C["条件动作分布"]
 C --> D["内部采样生成动作块"]
 D --> E["时效与控制约束"]
 E --> F["低层执行"]
 F --> G["真实观察"]
 G --> A

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

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

一种便于分层验证的结构是高层模型负责任务理解，中层 VLA 或 skill policy 负责抓取、放置、导航、操作等技能，低层控制器和运动规划器负责轨迹可行性、频率、稳定性和安全限制。端到端模型减少了手工接口，却更难解释和验证；模块化系统便于约束和替换组件，同时需要清晰接口和技能维护。实际系统要依据任务、设备与验证成本选择组合。

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

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"}
  ]
}

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

技能图还应显式记录每一步之后的观察点和失效去向。若抓取完成后没有重新检查夹具状态，后续“移动到水槽”可能在物体已经滑落时继续执行；若导航失败只返回布尔值，规划器也无法区分路径受阻、定位丢失和设备故障。把这些结果写入状态契约，才能让重新规划基于新事实，而不是重复原计划。

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

从技能分数到动作分布

SayCan 将语言模型对技能的任务相关性与技能在当前状态的成功估计结合，再选择下一技能，执行后更新状态。[21] 用教学数字说明：候选甲“立即抓取”的语言相关分为零点九，但被遮挡时可行动分只有零点二，乘积为零点一八；候选乙“先移动到观察位”语言相关分为零点六，可行动分为零点八，乘积为零点四八。这个例子显示，语义最直接的动作未必是当前最合适的动作。

不过分数相乘并不自动成为经过校准的真实任务成功概率。语言分数受提示与技能描述影响，技能价值函数受训练分布与奖励定义影响；不同技能持续时间和失败代价也可能不同。如果把长技能与短技能直接按同一分数比较，还要考虑它们到达什么状态以及后续是否可继续。模型分数可以排序候选，但硬性不可执行约束不能被高语言分补偿。例如工作空间外的抓取目标，应先被动作接口拒绝，而不是允许另一项高分把它“平均”为可行。

从技能切换到连续控制，输出对象也变了。RT-2 将动作表示成离散 token，并和视觉语言任务共同微调；其论文把连续动作维度均匀离散到二百五十六个区间，同时限制动作任务的输出词表。[14] 这样可以复用语言模型的序列建模接口，但 token 的含义由动作编码协议决定。一个整数在自然语言任务中是数字，在机器人任务中可能是某个方向位移的区间编号；只有恢复单位、范围与坐标，才能解释为物理动作。

离散化误差可用简单模型估计。若教学假设某动作分量限定在长度为二的区间内，均匀分为二百五十六箱，并用箱中心解码，那么落在范围内的值，其量化误差至多为半个箱宽，即 \(2/(2\times256)\)。这只是编码误差界，不包含模型预测、标定、控制跟踪或范围裁剪误差。若真实所需动作超出区间，裁剪偏差可能远大于这个值；若高精度接触要求低于箱宽，增加语言语料也不会自动提高动作编码的分辨率。

另一种问题是动作具有多模态分布。杯子两侧都可接近，示范者有时绕左、有时绕右。若用平方误差训练单个确定动作，在相同输入下最优回归趋向条件均值；左右两种可行方向的平均可能指向中间障碍物。这里的“多模态”指同一条件下存在多个行动方式，不是视觉与语言等输入模态。Diffusion Policy 用条件生成分布表达动作序列，为这类问题提供了不同于单点回归的路线。[22]

动作扩散并不需要在真实环境里逐步执行噪声动作。训练时对示范动作块加噪，模型学习在观察条件下预测去噪所需信息；推理时从内部噪声样本反复更新，最终得到动作块，再交给执行接口。中间去噪结果属于模型计算状态，不是机器人已经走过的位置。这一点与世界模型中的想象状态类似：内部候选可以修改，真正下发的动作及其环境后果不能因此抹去。

π0 使用条件 flow matching 的动作 expert 连接 VLM 表示与连续动作块。[18] 为避免不同论文的时间方向记法混淆，本书独立规定插值 \(A^\tau=(1-\tau)\epsilon+\tau A\)，其中 \(\tau\) 从零走向一，\(\epsilon\) 是噪声，\(A\) 是示范动作块。该直线路径的速度为 \(A-\epsilon\)，用平方误差训练条件向量场近似它，再通过数值积分从噪声走向动作。这是机制示意，不声称覆盖原实现的噪声日程、权重或积分器细节。

流时间 \(\tau\) 与机器人时间 \(t\) 是两条坐标轴。动作块中的第十项可以表示将来某个物理时刻的目标，而生成它可能经历若干流积分步。增加积分步通常增加模型计算，却不直接延长动作块对应的物理时长；改变控制采样周期则改变每项动作在真实时间上的意义。把二者混在一起，会错误地把“去噪十步”解释成“机器人执行十次反馈修正”。

动作坐标的错误可以用二维教学例子看清。设相机坐标相对机器人基座旋转九十度，并有固定平移；一个在相机坐标中向右的位移，在基座坐标中可能对应向前，而不是同样的“右”。对位置点应使用 \(p_B=R_{BC}p_C+t_{BC}\)，对同一坐标变换下的纯位移则用 \(\Delta p_B=R_{BC}\Delta p_C\)。平移作用于点而不作用于位移，混用两种公式会在每次动作中重复添加固定偏移。这里的旋转和平移仅用于说明坐标关系，不是具体设备标定值。

假设教学旋转矩阵为 \(\begin{bmatrix}0&-1\1&0\end{bmatrix}\)，相机中的位移为 \((0.02,0)\) 米，那么基座位移为 \((0,0.02)\) 米。若执行层错误地把相机向量直接下发，动作长度看似正确，方向却差九十度。这种错误不会被形状、数值范围或单独语言解释发现，必须把坐标变换与动作语义纳入检查。三维姿态还涉及旋转的组合顺序；姿态增量左乘还是右乘、表达在世界系还是工具系，都需要明确，不能用同一个“旋转三维向量”省略约定。

坐标变换也会传播不确定性。在局部线性近似下，若测量协方差为 \(\Sigma\)，变换的雅可比为 \(J\)，输出协方差可近似为 \(J\Sigma J^\mathsf{T}\)；若标定参数自身有误差，还应加入其影响。这个公式是本书用于解释误差传播的标准线性化示例，不代表任意非线性接触状态都服从高斯分布。它说明不确定范围会随着坐标与姿态变化，不能始终附上一个与几何无关的固定“置信度”。

传感器陈旧也可以进入同一误差账本。教学假设某物体沿一条轴以恒定速度每秒零点一米移动，观察年龄为二百毫秒，那么仅由未补偿运动造成的位置差就可能达到两厘米。若定位误差本来只有几毫米，却完全忽略时间对齐，这两厘米会成为主要误差来源。对静止物体则没有同样的运动项，因此不能把一个延迟数字脱离任务动态直接解释为可接受或不可接受。实际系统需要根据对象运动、控制目标与误差容许范围建立条件关系。

这类检查可以在模型训练前先完成。固定一组已知几何关系，验证正向与逆向变换是否互相一致；对同一段记录分别使用采样时间和到达时间，比较动作关联是否变化；对反归一化结果检查物理单位而不只是张量范围。如果这些接口已有系统偏差，训练可能学会部分补偿，却会把错误绑定到当前装配与时延；设备或软件一变，补偿就可能失效。先建立可解释的接口，再研究模型能否处理剩余不确定性，更容易判断学习究竟增加了什么能力。

动作块、三种时钟与跨块一致性

Diffusion Policy 区分观察历史长度、预测动作长度和实际执行长度：先根据一段观察生成更长的动作序列，只执行前面一部分，再读取新观察重新预测。[22] 预测长度提供局部时间一致性，执行长度决定多久重新利用环境反馈，两者可以不同。若每次都执行整段，未来动作基于越来越陈旧的观察；若每次只执行一项，反馈机会增加，但模型调用与调度开销也可能增大。

ACT 将动作序列作为一块来预测，并提出对多个历史块中指向同一执行时刻的预测做时序集成。[23] 关键是“同一时刻”：不能把现在的目标与下一秒的目标直接平均后当成现在应执行的命令。不同块对同一时刻的预测又可能来自不同观察，集成在平滑和响应新证据之间产生权衡。权重次序必须按实现核对，不能凭“新信息更重要”的直觉替论文补写规则；出现新障碍时，安全中断也不能被平滑平均冲淡。

教学设定中，策略每次预测十六个控制目标，每个目标在一个二十毫秒控制区间内保持，只执行前四个区间后重新规划。十六个保持区间共覆盖三百二十毫秒，前四个区间的执行窗口为八十毫秒；若只计算十六个等间隔目标时间戳的首尾跨度，则是三百毫秒。假设模型计算加传输耗时六十毫秒，这些动作到达时，最早目标的时间可能已经过去；调度器应使用实际时间对齐，明确丢弃、顺移或重规划策略，而不是从数组第一项盲目开始。这里的数值仅展示时间账本，不构成任何机器人推荐频率。

低层伺服还可能以更快周期跟踪目标，并在策略模型尚未产生新块时维持受约束控制。高层语言任务可以按技能事件更新，动作策略按观察窗口更新，伺服按硬件控制周期运行。三者互相依赖，但不必同频。在单工作器持续供给动作、没有额外缓冲且每个执行窗口需要一个新块的设定下，平均生成耗时短于窗口是避免长期供给不足的基本条件；异步或并行架构则要分别检查有效供给率、逐块截止时间和观测年龄。两者都还需核对尾延迟、队列积压与中断传递时间。若异常时仍继续发送旧块，平均吞吐再高也不能说明闭环及时。

模型架构会改变这笔时间账。Octo 在每次动作预测中只做一次 Transformer 骨干前向，多步去噪在较小动作头里完成；π0 的实现则能缓存不随流积分改变的观察相关键值。[17][18] 因此不能简单用“去噪步数乘完整模型前向时间”估算所有架构，也不能只报告动作头耗时忽略视觉编码。正确预算应沿实际依赖图统计，并说明传感器处理、缓存更新与动作传输是否包含在内。

动作契约还要区分位置、位置增量和速度。若位置增量每步为同一数值，执行次数增加会累计更远位移；若是绝对目标，重复相同指令通常表示持续跟踪同一目标；若是速度，则位移还取决于持续时间。三者可以拥有完全相同的张量形状，却具有不同动力学含义。跨数据集训练时，如果只统一成七维向量而不统一语义，模型会面对互相矛盾的监督，损失下降也不意味着控制解释正确。

7.5 数据、身体与仿真迁移

flowchart TD
 A["遥操作与真实轨迹"] --> B["时间和动作语义对齐"]
 C["受控仿真与扰动"] --> B
 B --> D["训练与目标身体适配"]
 D --> E["独立场景验证"]
 E --> F["分类失败与补充数据"]
 F --> A
 E --> G["保留测试隔离"]

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

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

世界模型必须和真实数据闭环校准。一个看起来真实但物理不可信的模型，会让策略学到错误行为；一个在短视频上表现稳定的模型，也不一定能支持多轮交互和长时记忆。本节关注数据与迁移条件；7.6 节进一步区分可查询真值的研究环境与真实部署中的对照评估。

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

跨身体验收应把“模型能生成合法形状”与“动作在目标设备上具有相同语义”分开。至少要检查静止状态的坐标变换、关节和末端范围、夹具开合方向、速度与力限制、动作延迟，以及传感器时间戳对齐；随后用受控轨迹确认反归一化结果，再逐步增加负载和环境复杂度。若只替换动作头而沿用另一台机器的统计量，输出可能数值合法却在物理上偏离。跨身体数据可以提供初始化和共享表示，设备侧标定与闭环回归仍是独立验收项。

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

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

这条飞轮和语言模型的训练迭代很像，只是成本和风险更高。文本生成的一次错误大多可以重试，机械臂撞到人不能简单 revert。物理世界把所有约束放大，所以具身系统更需要仿真、限幅、人工接管、长尾评估和清晰的责任边界。

一条轨迹中真正需要对齐的量

图像分类样本可以是一张图片和一个标签，机器人示范却是一段带时间关系的过程。至少需要知道观察来自哪个传感器、对应何时的机器人状态、操作者何时提出动作、执行器何时实际响应，以及之后的任务结果。若将“命令发送”与“动作完成”都写作一个时间戳，世界模型可能把通信延迟学成动力学，策略也可能学习对旧图像反应。扩充数据量前，先统一事件含义往往比增加样本更基础。

动作标签有三种常见来源：操作者提出的目标、控制器接受后的命令和传感器记录的实际运动。它们回答不同问题。被限幅的目标与实际命令不相同，执行器跟踪误差又使实际运动偏离命令。训练策略模仿哪一种，需要与部署接口一致；训练动力学时则要明确模型条件是命令还是已实现运动。若拿理想目标预测真实结果，却从未记录限幅和故障，模型会把控制链中的系统误差混进环境不确定性。

一个本书的教学时间片可以这样核对：相机在第一百毫秒曝光，图像在第一百三十毫秒到达，策略在第一百八十毫秒产生目标，控制器在第二百毫秒接受目标。若物体在这段期间移动，策略产出目标时的观察年龄为八十毫秒，控制器接受目标时则为一百毫秒。把四个事件压成“第二百毫秒的一步”，会掩盖这个差距。数据处理可以重采样或插值，但必须知道哪些量可插值：关节位置在已知条件下可连续处理，夹持接触状态或任务成功标记的跳变则不能简单线性平均。

动作归一化也不是无害的数值预处理。假设一台机械臂的某维动作均值为零、标准差为零点零二米，另一台为零、标准差为零点一米。归一化值为一时，反归一化结果相差五倍。若模型输出统一归一化坐标，却没有绑定机器人或数据统计版本，形状检查完全无法发现错误。统计量只能从训练数据或事先定义的物理范围得到，不能使用最终测试轨迹统计来改善部署结果，否则评估过程已经泄露了目标域信息。

Open X-Embodiment 提供统一数据格式与跨机器人训练的研究基础，Bridge Data 则展示多任务、多环境数据复用。[16][27] 统一格式只是让样本可以被同一个加载器读取，还必须进一步统一坐标、控制模式、夹具语义和任务终止定义。相同的“夹爪一”可能在一个接口表示关闭，在另一个接口表示张开；不保留元数据的混合会制造隐藏标签冲突。跨身体能力的形成，依赖共同结构和适配机制，而非单纯拼接文件。

示范数据还存在选择偏差。只保留成功轨迹可能让策略很少见到抓偏、目标遮挡或物体滑落后的状态；只收集熟练操作者也可能缺少恢复动作。增加失败轨迹不是把所有失败直接当成要模仿的动作，而是区分错误行为、可用反例和有效恢复。被安全层拒绝的命令尤其需要单独标记：拒绝可以是系统正确工作，不应简单标为任务策略应该避免记录的“坏样本”。

训练与评估划分应按能泄漏信息的单位进行。相邻视频帧分到不同集合，几乎相同的桌面和动作会同时出现在训练与测试；同一家庭的不同视角也不等于新的环境。若声称跨物体，就要说明是否只是颜色不同，还是几何、材质、质量和可操作部位都变化；若声称跨身体，要说明训练中是否已包含同型号机器人、相同相机或相同动作统计。泛化不是一个统一标签，而是一组受控变化。

视觉差距、动力学差距与目标分布

领域随机化通过改变仿真参数，避免模型只适应一个渲染或物理配置。Tobin 与 Tremblay 的研究关注视觉随机化，Peng 的研究则涉及动力学随机化下的控制迁移。[24][26][25] 两类方法针对不同差距：纹理和光照变化可能改善物体定位，却不能直接教会策略应对摩擦改变；质量和执行延迟随机化也不会自动解决镜面反光造成的视觉误检。

若训练仿真只改变无关因素，模型可能看上去见过非常多场景，却仍未覆盖真正影响失败的变量。例如桌面颜色变化一千种，杯子与夹具的接触状态却始终理想，那么抓取滑落仍是分布外事件。随机化范围过窄会漏掉现实，过宽又可能生成不可实现或相互矛盾的组合，降低训练效率。因此应先根据失败因果链选择变量，再检查变量之间的约束，而不是把每个参数都独立均匀抽样。

本书构造一个两因素评估矩阵：视觉条件分正常与遮挡，动力学条件分训练范围内与范围外。若策略只在遮挡组失败，优先检查状态估计；若视觉正常但范围外摩擦组失败，优先检查动作或动力学适配；若二者同时变化才失败，可能存在交互影响。这个矩阵只是诊断起点，不宣称每个失败都能唯一归因。为了判断机制，还需要固定其他条件、重复实验，并观察中间状态误差，而不是仅看最终成功率。

Real2Sim 的价值是把具体真实失败转成可控对照。先确定失效发生前的状态与动作，再在模拟器里尽量重建关键因素，改变某一项以观察结果。可重建部分可能包括物体位姿、相机视角、动作延迟和碰撞几何；不可重建部分可能是柔性变形、触觉噪声或未知接触材料。模拟器无法复现时应保留这个缺口，不能因为得到一段相似视频就宣称真实故障已经解释清楚。

系统辨识同样需要足够激励。若训练轨迹总以很慢速度移动，可能无法区分两个在低速下行为相似、在高速下响应不同的动力学模型。更丰富数据可以提高可辨识性，但真实采集必须受到设备与场景约束，不能为辨识参数随意扩大动作能量。无法安全辨别的区域可以限制运行范围或借助独立测量，不能以“模型需要探索”为理由默认开放。

CausalWorld 通过可干预的物体与环境因素组织迁移评估，为区分外观变化和动力学变化提供了研究工具。[28] 仿真迁移的最后证据仍来自目标环境中预先定义的评估。可先在仿真中筛掉明显失败策略，再在受控目标条件下比较；仿真用于开发的场景与最终评估场景也应分开。若每发现一个测试失败就修改随机化范围，该测试集已经进入开发循环，应保留新的独立样本判断泛化。通过某个模拟器排名，只能说明该模拟器与协议下的性能，不能替代目标机器人和真实任务的证据。

合成数据、跨身体数据与目标域示范各自增加不同信息。合成数据便于控制因素和生成反例，跨身体数据扩大语义与技能结构覆盖，目标域示范则提供具体传感器和控制接口的校准关系。有效组合不必让三者样本数相等，而要检查哪些失败类型仍缺证据。如果目标域只占很小比例且动作语义特殊，还需要考虑采样权重与适配头，否则大数据的平均梯度可能掩盖少量关键控制条件。

7.6 闭环案例、评估与失败定位

flowchart TD
 A["定位并确认目标"] --> B["接近与抓取"]
 B --> C{"新观察确认持有"}
 C -->|是| D["移动放置"]
 D --> E["独立任务验收"]
 C -->|否| F["停止当前技能并重估"]
 F --> A
 G["控制或状态异常"] --> H["受约束停止与接管"]
 B --> G
 D --> G

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

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

安全 envelope 还应区分三种动作。第一类是只读或虚拟动作，例如在世界模型中 roll out、在数字孪生中规划、在相机画面上标注候选抓取点；它们可由较宽松的模型策略产生。第二类是可逆、低能量的受控动作，例如经设备评估后在隔离区域低速移到观察位、调整无载夹爪或请求更多视角；它们是否允许自动执行仍由设备和场景风险评估决定。第三类是在当前设备和场景中具有较高风险或不可逆后果的动作；其执行条件应由具体安全设计确定，不能仅根据动作名称或模型自信程度分类。把动作按后果而非按“模型是否自信”分级，能避免置信度被误用为安全证明。

运行中的干预也必须有状态语义。人工接管是一次有版本的状态迁移：冻结新的高危动作、保留当前传感器与控制快照、标记被中断的技能、给出恢复条件，并把控制权转给预先授权的操作者。恢复时，系统要重新感知、建立环境状态、检查 envelope，并确认人、物体和工具仍处于允许位置；若动作已经造成外部变化，恢复策略应从当前事实重新规划。任务中断、状态恢复与外部副作用的通用运行时语义见第 17 章 Agent Runtime，本节只补充物理状态不能随软件会话一起回滚这一约束。

回滚在 Physical AI 中也有边界。软件配置、模型路由、技能版本和策略阈值通常可以回滚；机器人在空间中的位置、物体形态、人与环境的反应不能回滚。因此发布方案要同时准备软件回滚和物理收敛方案：依设备安全设计停止或稳定载荷、隔离故障设备、通知现场人员并保存证据。补偿动作本身也要放入 envelope。谁可以批准高风险动作、如何记录审计证据、怎样灰度和回退，由第 18 章 Agent 治理与调优统一定义；本章说明这些治理控制在物理动作上的额外约束。

安全评价不应只汇总一次部署的平均数字。建议按动作风险等级分别报告任务成功率、拒绝正确率、危险近失率、超限触发率、人工接管率、恢复成功率、传感器失效下的安全停机率，以及从仿真到真实的性能差，并同时给出场景覆盖和置信区间。“未发生碰撞”若只来自少量固定场景，不足以支持扩大开放范围。Open X-Embodiment 与 Bridge Data 展示了跨机器人、跨任务或跨环境数据在其研究设置中的泛化价值 [16][27]，两项工作并未据此证明安全约束的泛化。本书进一步提出：安全约束也应在新相机、新夹具、新物体和新布局下单独验证，并将结果纳入治理门禁。

具身系统的评估要同时覆盖预测质量、策略决策、物理执行与安全控制。单个离线分数无法代表完整闭环，报告必须说明场景、身体、传感器、控制器和人工干预条件。

机器人任务不能用单次 demo 作为证据。评估矩阵至少包含五个维度：任务成功率衡量目标和长任务是否完成；泛化覆盖新物体、新布局和新语言表达；效率记录完成时间、动作数和资源消耗；安全记录碰撞、超限、拒绝与人工接管；可恢复性记录失败检测、重新规划和恢复成功率。每个维度都要覆盖训练内、训练外和长尾场景，并保留完整的传感器、动作、模型与控制 trace。失败样本进入带版本的回归集，才能区分模型改进与场景变化。

把拿杯任务走成一个可验收的闭环

下面将前面的模型接口串成一个完整教学案例。目标是在隔离实验台中把指定空杯移到托盘，使用已验证的运动技能与设备侧约束；所有阈值由具体系统另行确定，本例不提供可直接执行的控制参数。任务开始时，系统需要确认杯子身份、托盘区域、机器人自身状态与观察时间；“看到杯子”只是感知结果，“杯子可抓”是结合姿态、身体与技能的判断，“允许抓取”还包含独立执行约束。三个结论应分别保存。

正常路径中，视觉定位给出杯子与托盘的估计分布，历史观察帮助判断物体是否静止。规划器提出观察、接近、抓取、移动和放置的技能序列。世界模型可以比较候选接近动作，技能策略再给出连续动作块，执行层检查坐标、时效与范围后下发。夹具完成抓取后，系统读取新视觉、本体或接触信息，确认杯子随夹具移动，再进入搬运。放置完成后，还要检查杯子与托盘的关系以及夹具是否已释放，不能把“已发送放置命令”当成任务完成。

这个流程里至少有四种不同的“成功”：感知认为找到目标，策略提出可执行候选，控制器完成轨迹跟踪，任务验收确认杯子进入指定区域。前面某项成功不蕴含后面成功。尤其是跟踪成功只说明执行器按命令运动，命令本身仍可能选错对象；终点图像相似也可能是杯子被夹具遮住，而非真正放好。验收设计应围绕任务事实选择独立检查，不让同一个模型既预测结果又充当唯一裁判。

第一个异常是目标被临时遮挡。若当前信念仍保留杯子位置的合理范围，系统可以在允许的动作集合内选择补充观察；若状态不确定度已超出任务接口可接受范围，就停止该技能而不是继续使用上一次点估计。恢复不是将视觉置信度阈值降低到能够通过，而是获得新证据或缩小任务范围。若补充观察后发现杯子被移动，旧动作块应失效，新计划从当前状态重新建立。

第二个异常是抓取后滑落。控制器可能报告夹爪动作完成，但杯子没有随末端移动。此时应区分夹具命令完成与抓取事实失败，丢弃依赖“已持有杯子”的后续计划。简单重放同一抓取动作可能撞向新的物体位置，因为滑落改变了环境；合理恢复需要先重新确认物体和机器人状态，再决定是否存在受约束的恢复技能。若设备状态或物体姿态未知，停止与交由授权操作方处理也是合法的任务结果。

第三个异常是模型调用迟到。新动作块到达时，先前观察已经过期，或系统已进入人工接管状态。运行时不能因为输出格式正确就继续执行。动作块应绑定观测版本、任务阶段和有效时间，只有这些前提仍成立才可使用；否则记录为过期候选并触发重规划或等待。这个例子说明推理服务的尾延迟会转化成控制问题，不能只用平均每秒输出多少动作来评价模型。

真实系统中的安全停止不一定等于立即切断所有控制。某些设备需要受控减速或维持载荷，具体动作由设备安全设计决定。本书只要求模型策略不能绕过这套机制，也不能把“退回原位”写成普遍安全补偿：路径中可能出现新障碍，载荷可能改变，原位本身也可能不再可达。软件可以回滚版本，物理系统必须从当前状态寻找允许的收敛方式，两者的证据完全不同。

从结果数字定位真正的瓶颈

评估首先固定任务分布、成功定义和干预协议。假设一次任务允许最多两次受约束抓取尝试，那么“首次成功”和“允许重试后的成功”应分别报告；不能把失败后人工调整杯子、重新摆正夹具再成功都算成完全自主成功。若操作者只在某模型失败时帮助它，也会改变比较条件。教学报告应列出重置次数、接管次数、超时与拒绝，使不同策略付出的外部帮助可见。

用一组教学计数说明：一百次任务中，八十次感知满足要求，其中七十二次生成可执行计划，六十六次执行完成，六十次通过最终验收。端到端成功率为六成；条件通过率分别为八成、九成、约九成二和约九成一。只有当这些计数来自同一嵌套流程，才可以把条件比例相乘恢复总体成功率。不能将不同数据集上的感知准确率、规划成功率与控制成功率相乘，假装得到真实系统指标。

若世界模型预测误差很低，最终成功率却停留在六成，应沿链检查。可能是预测只覆盖训练分布，规划选择了误差大的边界动作；也可能是模型排序正确，但控制器的实际动作与模型条件不一致；还可能是任务验收比奖励定义更严格。三种情况分别需要修正模型覆盖、动作接口和目标定义。增加更多生成 token 或更深规划树，并不会自动解决任何一种接口错配。

开环测试和闭环测试应共享可比较的起始条件，但不能混用未来信息。开环可以用真实历史观察预测下一状态，然后比较留出观测；自由展开可以只提供起点，观察误差怎样随时域变化；闭环则让策略行动并接受它自己改变后的状态分布。后者测试的不仅是预测，还包括反馈纠正、动作选择和分布漂移。某策略在专家轨迹上模仿误差小，却可能在自身小误差积累后进入专家从未展示的状态。

世界模型辅助规划的对照也要保持公平。真实环境通常不能被免费复制并查询任意候选动作，因此“真实动力学作为规划 oracle”往往只能在具有真值模拟器的研究环境中实现，应标明这是 oracle 对照，而非自动成立的性能上界。只有在任务目标、信息与可行动集合可比，且优化与决策满足相应充分条件时，才可讨论上界；有限预算规划即便使用准确动力学，也未必优于另一策略。现实中更可行的对照是固定任务与控制器，比较不用世界模型、使用不同预测器和使用相同预测器但不同规划预算的策略，并把训练数据、推理成本和环境重置成本一起列出。

统计上，“零次危险事件”不等于风险为零。在理想独立同分布伯努利试验下，若观察了 \(n\) 次且零事件，单侧百分之九十五置信上界可写成 \(1-0.05^{1/n}\)。教学取三十次，约为百分之九点五；取三百次，约为百分之一。这个演算只说明有限样本仍存在很大不确定性，不是机器人认证方法。真实任务常有场景相关性、操作者选择与长尾分布变化，独立假设可能不成立，因此不能直接把公式当部署许可。

多次尝试也需要定义统计单位。同一次任务中的十帧不是十次独立成功，固定布局下重复一百次也不能代表一百种新布局。若只挑成功演示制作视频，会隐藏试验分母；若只报所有任务平均值，又可能掩盖某一材料或身体配置持续失败。按物体、布局、身体、光照、接触与时延切片，并保留失败样本，可以让读者判断改进是否覆盖目标使用范围。

最终应把证据分成可复查的层次：来源论文支持某种机制；离线数据支持特定预测表现；受控仿真支持指定参数范围内的交互；受监护的真实任务支持指定设备与场景条件下的闭环结果。任何一层都不能靠下一层的术语来升级自己。对于本章，全部案例仍停留在教学设计与手算层，目的在于训练读者检查机制与边界，而不是宣称已经建成或验证了具身系统。

本章小结

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

与纯文本离线生成相比，具身任务更直接受到部分可观测状态、可能不可逆的动作和闭环评估约束。这些性质并非具身独有，工具型 Agent 也会遇到；具身系统还必须满足连续物理动态下的观测时效、控制响应与误差传播要求。因此它需要结合历史更新状态、区分提议与执行，并将闭环验证与离线评估结合。隐状态动力学、动作条件生成和 VLA 是同一约束下的不同技术路线，接口和证据各不相同。仿真与离线分数只是阶段性证据，不能替代物理验证；本章架构与检验方案均为设计说明，不包含机器人上线、安全认证或性能实测。

参考资料

1. Ha, D., & Schmidhuber, J. World Models. arXiv，2018 v4. 访问日期：2026-11-01
2. Hafner, D., et al. Learning Latent Dynamics for Planning from Pixels. ICML, 2019. 访问日期：2026-11-01
3. Hafner, D., et al. Dream to Control: Learning Behaviors by Latent Imagination. ICLR, 2020. 访问日期：2026-11-01
4. Hafner, D., et al. Mastering Diverse Domains through World Models. arXiv，2024 v2（首版 2023）. 访问日期：2026-11-01
5. Bruce, J., et al. Genie: Generative Interactive Environments. arXiv, 2024. 访问日期：2026-11-01
6. NVIDIA. Cosmos: World Foundation Model Platform for Physical AI. arXiv, 2025. 访问日期：2026-11-01
7. Bengio, Y., Courville, A., & Vincent, P. Representation Learning: A Review and New Perspectives. IEEE TPAMI, 2013. 访问日期：2026-11-01
8. Bardes, A., et al. Revisiting Feature Prediction for Learning Visual Representations from Video. arXiv, 2024. 访问日期：2026-11-01
9. Assran, M., et al. V-JEPA 2: Self-Supervised Video Models Enable Understanding, Prediction and Planning. arXiv, 2025. 访问日期：2026-11-01
10. Dosovitskiy, A., et al. CARLA: An Open Urban Driving Simulator. CoRL, 2017. 访问日期：2026-11-01
11. Zhang, A., et al. 动手学深度学习：概率，中文在线 2.0.0。核验日期：2026-11-01。
12. Zhang, A., et al. 《动手学深度学习》：序列模型. 中文在线版 2.0.0. 访问日期：2026-11-01
13. Yang, S., et al. Learning Interactive Real-World Simulators. arXiv, 2023. 访问日期：2026-11-01
14. Brohan, A., et al. RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. arXiv, 2023. 访问日期：2026-11-01
15. Driess, D., et al. PaLM-E: An Embodied Multimodal Language Model. arXiv, 2023. 访问日期：2026-11-01
16. Open X-Embodiment Collaboration. Open X-Embodiment: Robotic Learning Datasets and RT-X Models. arXiv, 2023. 访问日期：2026-11-01
17. Octo Model Team. Octo: An Open-Source Generalist Robot Policy. arXiv, 2024. 访问日期：2026-11-01
18. Black, K., et al. π0: A Vision-Language-Action Flow Model for General Robot Control. arXiv, 2024. 访问日期：2026-11-01
19. Physical Intelligence. π0.5: A Vision-Language-Action Model with Open-World Generalization. arXiv, 2025. 访问日期：2026-11-01
20. Google DeepMind. Gemini Robotics Brings AI into the Physical World. 2025. 访问日期：2026-11-01
21. Ahn, M., et al. Do As I Can, Not As I Say: Grounding Language in Robotic Affordances. arXiv, 2022. 访问日期：2026-11-01
22. Chi, C., et al. Diffusion Policy: Visuomotor Policy Learning via Action Diffusion，RSS 2023，2024 扩展版 v5。核验日期：2026-11-01。
23. Zhao, T. Z., et al. Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware，2023 v1。核验日期：2026-11-01。
24. Tobin, J., et al. Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World. arXiv, 2017. 访问日期：2026-11-01
25. Peng, X. B., et al. Sim-to-Real Transfer of Robotic Control with Dynamics Randomization. arXiv, 2017. 访问日期：2026-11-01
26. Tremblay, J., et al. Training Deep Networks with Synthetic Data: Bridging the Reality Gap by Domain Randomization. CVPR Workshops, 2018. 访问日期：2026-11-01
27. Ebert, F., et al. Bridge Data: Boosting Generalization of Robotic Skills with Cross-Domain Datasets. RSS, 2022. 访问日期：2026-11-01
28. Ahmed, O., et al. CausalWorld: A Robotic Manipulation Benchmark for Causal Structure and Transfer Learning. arXiv:2010.04296, 2020. 访问日期：2026-11-01

第8章 AI Infra 全景

版本与证据说明：本章的资源账本、状态机、容量方程、门禁与成本数字是本书的教学设计或示例假设，不代表任何已实现平台；涉及 vLLM、Triton、TensorRT、NCCL、Kubernetes 等具体软件的行为，以参考资料所列文档及其核验日期为准。

前七章讨论了模型如何表示、学习、对齐、推理、从零训练、适配并扩展到具身系统。从本章开始进入大模型 Infra：同一个模型，怎样被稳定地训练出来、保存下来、部署出去、服务给用户，并在故障、扩容、升级和成本约束下持续运行。

大模型 Infra 不是“把模型放进一台 GPU 服务器”，而是一条跨越数据、计算、通信、存储、调度、服务、观测和治理的系统链路。训练侧关心有效 token/s、扩展效率、故障恢复和 checkpoint；推理侧关心首 token 时延（Time To First Token，TTFT）、每输出 token 时延（Time Per Output Token，TPOT）、吞吐、KV cache（注意力层为已处理 token 缓存的 Key/Value 张量）、排队和单位成功成本；平台侧还要处理模型版本、容量预测、租户隔离、权限、审计和回滚。

本章是后续四章的地图。模型结构、并行需求、精度要求和验证方式构成 Infra 的输入契约，Infra 负责让这些计算在真实约束下可重复、可观测、可恢复地执行。本章只给出全书共用的术语、资源账本、五平面和跨章接口；训练作业、推理服务、评估证据与运营治理的机制分别在第9、10、11、12章展开。

8.1 为什么大模型需要独立的 Infra 方法论

从模型文件到生命周期系统

传统后端服务通常把二进制、配置和数据库迁移打包发布。大模型服务的“可运行单元”更复杂：除了权重，还包括 tokenizer、chat template、量化配置、LoRA adapter、视觉预处理、采样参数、工具 schema、验证器、硬件 kernel 和安全策略。训练得到的 checkpoint 只是生命周期中的一个状态，不是可以直接交付的产品。

如图 8-1 所示，生命周期中的每个箭头都是接口：数据 manifest 不稳定，训练不可复现；checkpoint 不完整，故障无法恢复；模型转换不一致，线上质量会变；服务没有容量指标，流量一升高就排队；没有 trace，失败无法归因；没有回滚，任何升级都可能变成事故。

flowchart LR
  D["数据源与授权"] --> P["清洗、去重与切分<br/>dataset manifest"]
  P --> T["训练 / 后训练<br/>第9章"]
  T --> C["checkpoint 与评估<br/>第9章 / 第11章"]
  C --> R["模型注册与转换<br/>Model Manifest"]
  R --> Q["量化、编译与打包"]
  Q --> S["Serving 部署<br/>第10章"]
  S --> O["观测、灰度与回滚<br/>第12章"]
  O --> F["反馈与再训练"]
  F --> P
  O --> X["退役<br/>下线、清理、删除、留证"]

图 8-1 大模型生命周期与系统链路

链路的最后一段是退役，它最容易被推迟。退役不是一次删除，而是四类到期时间不同的收尾：模型下线要先确认没有在途请求，再撤销路由和凭据，以小时计；依赖清理要回收 adapter、量化制品、编译缓存和专用资源池，以周计；数据删除要沿血缘处理缓存、派生索引和评估样本，受保留策略与备份周期约束；证据留存保留审批、评估和事故记录，以年计。把它们压成一张工单，要么删掉仍需审计的证据，要么让已下线的模型继续持有权限和资源。删除与留存的做法见第12章 12.8 节。

算法与 Infra 的边界

算法层回答模型结构、损失、数据采样、推理策略和验证器判定；Infra 层回答这些计算如何分布到 GPU、如何读写和通信、如何在多请求下调度、如何保存和恢复状态、如何对外提供稳定接口。

边界不是绝对的。GQA（分组查询注意力，多个 query 头共享一组 KV 头）会改变 KV cache 大小，FlashAttention 同时涉及算法和 kernel，MoE（混合专家）路由会影响通信，RLVR 的 verifier 会占用 serving 资源，推理预算会改变排队和成本。因此算法指标和系统指标必须连成一条可测量的链路：

验收维度与核心指标

一个训练脚本在 8 张 GPU 上跑通，只说明功能闭环成立，不说明系统可扩展：GPU 可能在等数据或通信，checkpoint 可能阻塞训练，故障后可能无法恢复，成本可能不可接受。一个推理服务能返回 token，也不代表可以上线：首 token 可能很慢，并发一高就 OOM，长请求会饿死短请求，模型升级无法灰度，工具请求没有审计。

因此，大模型 Infra 的验收要从“功能正确”扩展到性能、容量、可靠性、可观测性和治理五个维度。Google SRE 方法用服务等级目标（Service Level Objective，SLO，即某个可测指标在一个时间窗口内应达到的目标值）和错误预算把可靠性与发布决策联系起来 [1]；大模型系统还要把 token、上下文、模型版本和生成质量纳入同一套目标。下表是全书共用的核心指标，公式分别在 8.2 节和 8.4 节给出。

8.2 工作负载与资源模型：先算清楚再选组件

三种负载，三种资源画像

训练是长时间、高吞吐的批处理负载，可以容忍单步高延迟，却不能容忍 GPU 长时间空闲，并且要在节点故障后从保存的状态恢复。推理是在线或准在线负载，输入和输出长度差异巨大，重点是延迟、并发、容量和质量稳定。数据处理是 I/O、CPU、网络和存储的混合负载，常常是训练前端的隐形瓶颈。

用在线 serving 的 QPS 衡量训练，会忽略 GPU 是否被通信和数据拖慢；只用训练吞吐挑选推理 GPU，又会忽略单 token 延迟和显存容量。平台应先建立负载分类（workload taxonomy），再决定共享集群还是隔离资源池。图 8-2 把本节的资源账本分成显存、计算、带宽和成本四本分账。

flowchart TB
  A["资源账本"] --> M["显存"]
  A --> F["计算"]
  A --> B["带宽与通信"]
  A --> K["成本"]
  M --> M1["训练：权重 2P + 梯度 2P 或 4P<br/>+ 优化器 12P + 激活 + 缓冲"]
  M --> M2["推理：权重 + KV cache<br/>+ 工作区"]
  F --> F1["训练 C ≈ 6PD"]
  F --> F2["推理每 token ≈ 2P FLOPs"]
  F1 --> F3["MFU<br/>实际 / 峰值"]
  B --> B1["decode 单步下界<br/>≈ 权重与 KV 字节 / HBM 带宽"]
  B --> B2["集合通信<br/>all-reduce、all-gather"]
  K --> K1["单位成功成本<br/>总成本 / 验收通过任务数"]

图 8-2 资源账本的分解

训练显存账本

设参数量为 \(P\)。混合精度训练常用的 ZeRO 口径是：BF16 权重 \(2P\) 字节、BF16 梯度 \(2P\)，Adam 类优化器再保存 FP32 master weight、一阶动量和二阶动量共 \(12P\)，合计约 \(16P\) [2]；若梯度以 FP32 累加，梯度项变为 \(4P\)，合计约 \(18P\)。70B 模型按 \(16P\) 计为 \(70\times10^9\times16,\text{B}\approx1120,\text{GB}\)，已超过一台 8×80 GB 服务器的 640 GB 总显存，而这还没有计入激活。这正是需要 ZeRO、FSDP 分片乃至 CPU/NVMe offload 的原因 [3]。

激活不能用常数描述。它近似与层数 \(L\)、micro-batch 大小 \(B\)、序列长度 \(T\) 和 hidden size \(h\) 的乘积成正比，即 \(\propto L\cdot B\cdot T\cdot h\)；若不使用 FlashAttention 等融合 attention kernel，前向还要保存 \(a\) 个头的注意力分数与概率矩阵，多出一项 \(\propto L\cdot B\cdot a\cdot T^2\)，长上下文时它会成为主项。激活重算（activation checkpoint）以多一次前向换取少保存中间张量；通信 bucket、参数预取和分片临时聚合又会在关键路径上同时存活。

这张表是分类框架，不是可以直接套用的容量公式。不同优化器、精度策略和框架的字节口径不同，引用任何具体数字前必须先声明优化器、精度配置和分片策略；“能否放进显存”最终要在目标并行度下实测峰值。

推理显存与 KV 数值示例

推理显存主要由权重、KV cache、运行时工作区和 batch 中的临时张量组成。对 decoder-only 模型，在常规 MHA/GQA、K/V 维度相同且不做额外压缩时，一批序列的 KV 载荷近似为

\[ M_{KV}\approx 2\times L\times B\times T\times H_{KV}\times d_{head}\times b, \]

其中 \(L\) 为层数，\(B\) 为同时驻留的序列数，\(T\) 为每条序列已缓存的 token 数，\(H_{KV}\) 为 KV 头数，\(d_{head}\) 为每头维度，\(b\) 为每元素字节数，系数 2 对应 K 和 V。长度不同的序列要逐条求和。

以 Llama-3-70B 为例（80 层、8 个 KV 头、\(d_{head}=128\)、BF16）：每 token 的 KV 为 \(2\times80\times8\times128\times2=327{,}680\) B，即 320 KiB；一条 8K（8192 token）上下文约 2.5 GiB；32 条 8K 序列同时驻留就需要约 80 GiB，超过一张 80 GB GPU 的容量，而 BF16 权重本身还要约 140 GB。若该模型的 64 个 query 头各自保留 KV 头，KV 会扩大 8 倍，这就是 GQA 通过减少 \(H_{KV}\) 换来的余量；但它是算法侧已决定的结构。Infra 要做的是把最大长度、并发和精度换算成准入控制（admission control）与容量上限。

MoE 要分清两种口径。权重驻留与制品存储由总参数、共享层和放置方案决定；每 token 激活参数描述参与计算的专家，只能用来估计计算量。用总参数估每 token 计算、再用激活参数估权重内存，会同时高估算力需求和低估驻留成本；路由通信、负载偏斜和非专家计算也不会因为“激活少”而消失。

计算、带宽与 MFU

三个量级估算覆盖了大部分容量讨论。用 \(D\) 个 token 训练一个 \(P\) 参数的稠密模型，总计算量约为

\[ C_{train}\approx 6PD, \]

其中前向约 \(2PD\)、反向约 \(4PD\) [4]，不含与上下文长度相关的注意力项和激活重算。例如 70B 模型训练 1T token 约需 \(4.2\times10^{23}\) FLOPs。推理时每生成一个 token 的前向约需 \(2P\) FLOPs，外加与上下文长度成正比的注意力计算。

训练效率常用模型 FLOPs 利用率（Model FLOPs Utilization，MFU）衡量 [5]：

\[ \text{MFU}=\frac{6P\times \text{有效 token/s}}{N_{GPU}\times F_{peak}}, \]

其中 \(F_{peak}\) 是单卡在所用精度下的峰值 FLOPs/s。分子只按模型理论计算量计，激活重算等额外计算不计入，因此 MFU 可以跨实现比较；常见的 GPU utilization 百分比只表示有 kernel 在运行，不等于 MFU。

Decode 往往受带宽而非算力约束。每个 decode step 都要把全部权重从 HBM 读一遍，batch 中各序列还要读各自的 KV，所以单步时间（也就是 TPOT）的下界约为

\[ \text{TPOT}{min}\approx\frac{W{bytes}+\sum_i KV_i}{N_{TP}\times BW_{HBM}}, \]

其中 \(W_{bytes}\) 为权重字节数，\(BW_{HBM}\) 为单卡显存带宽，TP 下权重和 KV 按卡分摊。以教学假设计算：70B 模型 BF16 权重约 140 GB，TP=8、单卡带宽按 3 TB/s 计，仅读权重就需 \(140/(8\times3)\approx5.8\) ms，再加 KV 读取与通信。增大 batch 可以把同一次权重读取摊给更多序列，这是连续批处理提升吞吐的根本原因；但 KV 读取随 batch 线性增长，下界也随之上升。

诊断时要同时看多层指标：计算利用率低而网络利用率高，多半是并行切分或 all-reduce 瓶颈；计算低而显存带宽接近上限，是 decode 或小 batch 的 memory-bound；GPU 和网络都低而 CPU 或对象存储高，说明数据供给是瓶颈。NCCL 为 GPU 集合通信提供 all-reduce、all-gather、reduce-scatter 等原语 [6]，但并行维度、通信时机和拓扑仍由应用层选择。

成本单位与任务结果关联

训练成本可以按每百万有效 token、每个 checkpoint 或每个实验比较；推理成本可以按每百万输入/输出 token、每个成功请求或每个完成任务比较。对推理密集型负载，输出 token 多不一定坏，关键是额外 token 是否换来成功率。本书使用的单位成功成本为

\[ \text{单位成功成本}=\frac{C_{\text{GPU}}+C_{\text{CPU、存储、网络}}+C_{\text{评估与标注}}+C_{\text{失败重跑}}+C_{\text{人工接管}}}{\text{通过业务验收的任务数}}. \]

吞吐很高但失败率也高的模型，单位成功成本可能更差；低延迟模型若需要更多重试，高峰期总成本可能超过慢但稳定的模型。成本账本的计量与治理见第12章 12.6 节。

8.3 分布式训练：从单卡程序到 GPU 集群

本节只给出并行维度的地图和选择顺序；通信字节账本、ZeRO/FSDP 细节、数据管线与 checkpoint 协议见第9章。

并行维度一览

数据并行让每张卡持有完整副本、处理不同样本，反向后同步梯度；它最简单，但模型越大越放不下，batch 越小同步占比越高。ZeRO [2] 与 PyTorch FSDP [7] 把优化器状态、梯度乃至参数在 DP 组内分片，计算前 all-gather、计算后释放或重新分片，用通信换显存。

张量并行把层内矩阵切到多卡，每层都要集合通信，所以 TP 组应放在同机 NVLink 域内，度数过大时通信会成为主耗时 [8]。序列并行（SP）在 TP 组内把 LayerNorm、Dropout 等逐 token 操作的激活沿序列维切开，消除这些激活在 TP 各卡上的重复保存；上下文并行（CP）则把整条序列连同 attention 一起切到多卡，用于单卡放不下的超长上下文，它是独立的一维。

流水线并行把层分成 \(p\) 个 stage，每个 global batch 拆成 \(m\) 个 micro-batch 依次流过。在 GPipe 或 1F1B（one-forward-one-backward，稳态中每个 stage 交替执行一个前向和一个反向）调度下，空闲 bubble 占总时间的比例约为

\[ \frac{p-1}{m+p-1}, \]

相对理想计算时间则为 \((p-1)/m\)。增大 \(m\) 能摊薄 bubble，但受全局 batch 和单个 micro-batch 的 kernel 效率约束。Interleaved 调度把每张卡上的层再分成 \(v\) 个虚拟 stage，bubble 约降为原来的 \(1/v\)，代价是 stage 间通信次数增加 [9]。stage 也不能只按层数平均切，还要考虑各层的计算、通信和激活成本。

MoE 的 router 为每个 token 选少数专家，token 需要在卡间 all-to-all 分发。专家负载不均会产生 straggler；在设容量上限并丢弃溢出 token 的实现里，capacity factor 过小会丢 token，过大则浪费显存。平台要观测专家负载、溢出率和路由稳定性，而不是只看总 FLOPS。

并行度的选择顺序

在 DP、TP、PP 三轴独立的稠密网格中，总进程数为

\[ N_{world}=N_{DP}\times N_{TP}\times N_{PP};(\times N_{CP}), \]

启用 CP 时再乘 \(N_{CP}\)；SP 复用 TP 组，不增加因子。EP 通常与 DP 组相互划分或重叠，不能无条件再乘一个专家并行度，应先写清物理 rank 到各逻辑组的映射，再核对覆盖与重叠。

一个不产生循环依赖的选择顺序是：先在机内用 TP 让单层放得下，TP 度数通常不超过一个 NVLink 域的卡数；再跨机用 PP 让整个模型放得下，同时按 bubble 比例选择 micro-batch 数；剩余 GPU 全部用于 DP，并按显存余量决定 ZeRO 阶段；长上下文再加 CP，MoE 再按专家数和路由流量划分 EP。如图 8-3 所示，32 张 GPU 按 \(N_{TP}=8\)、\(N_{PP}=2\)、\(N_{DP}=2\) 排布时，TP 通信留在节点内，PP 的点对点通信跨节点，DP 的梯度同步在两个副本的对应卡之间进行。

flowchart LR
  subgraph R0["DP 副本 0"]
    A0["节点 0 = PP stage 0<br/>8 卡 TP 组，走 NVLink"] -->|"激活与梯度<br/>点对点，跨节点"| A1["节点 1 = PP stage 1<br/>8 卡 TP 组，走 NVLink"]
  end
  subgraph R1["DP 副本 1"]
    B0["节点 2 = PP stage 0<br/>8 卡 TP 组，走 NVLink"] -->|"激活与梯度<br/>点对点，跨节点"| B1["节点 3 = PP stage 1<br/>8 卡 TP 组，走 NVLink"]
  end
  A0 -.->|"DP 梯度同步"| B0
  A1 -.->|"DP 梯度同步"| B1

图 8-3 并行维度到 GPU 网格的映射（32 卡教学示例）

扩展效率要相对一个能跑起来的基准规模 \(N_0\) 定义，因为大模型往往无法在单卡上运行：

\[ E(N)=\frac{\text{throughput}(N)/N}{\text{throughput}(N_0)/N_0}. \]

当 \(E(N)\) 随规模明显下降时，继续扩容可能不划算。Megatron-LM 的研究展示了三种并行的组合取舍 [8][9]，PaLM 的经验也说明大规模训练要统一处理计算、通信和故障 [5]。平台应把目标规模上的扩展曲线、通信占比、checkpoint 耗时和故障恢复时间作为发布门禁；小规模 benchmark 必须用真实拓扑和真实序列长度，不能用理论计算量外推。

数据供给与 checkpoint：训练系统的两端

GPU 只在拿到有效 batch 时产生价值。数据管线要完成读取、解码、去重、tokenization、混合采样、shuffle、packing 和 batch 组装，任何一环抖动都会让 GPU 等待；训练时还要记录 manifest hash、shard 游标和随机种子，恢复后才能得到一致或可解释的样本流（第9章 9.2 节）。可恢复 checkpoint 也不只是权重，还包括优化器状态、学习率调度器、随机状态、数据游标、并行拓扑和代码版本，并且要用临时前缀、校验和与完成标志保证不会把 step \(t\) 的权重和 step \(t-1\) 的优化器状态拼成一个恢复点（第9章 9.5 节）。可恢复 checkpoint 服务于训练重启；发布 checkpoint 则要经过评估、转换和注册才能交给推理。

横切关注点

以下几项同时影响训练和推理，不属于某一个并行维度，这里只标出边界：

• Kernel 与 IO：组合执行的效率取决于中间张量的 HBM 往返、kernel launch 次数和 layout。FlashAttention 用 IO-aware 的分块计算减少 attention 的 HBM 读写并保持精确结果 [10][11]；其原理与 online softmax 见第9章 9.4 节。
• 精度：BF16、FP16、FP8、INT8、INT4 的选择要同时看硬件支持、训练稳定性、通信量和质量。训练中的混合精度与异常处理见第9章 9.4 节，推理量化的兼容约束见第10章。
• 编译制品：图捕获、autotune 和引擎构建会引入 shape 约束与设备绑定。TensorRT engine 默认只能被构建它的 TensorRT 版本反序列化，并且只能在相同计算能力（compute capability）的 GPU 上运行，需要在构建时显式启用版本兼容或硬件兼容模式才能放宽 [12]。因此编译产物要绑定模型 hash、GPU 架构、软件版本、输入 shape 与精度，并在发布前做冷启动和最大长度测试。
• 数据与制品安全：训练数据、样本日志和 checkpoint 都可能包含敏感内容或数据记忆，其权限、脱敏、审计与删除归治理平面，见第9章 9.1 节和第12章 12.5 节。

8.4 推理平台与请求调度

本节只定义推理侧指标和调度术语；以 vLLM 为例的引擎机制、抢占、PD 分离实现和诊断见第10章。

Prefill、Decode 与延迟指标

推理分为两个阶段。Prefill 一次性处理输入 prompt，为每个输入 token 建立 KV 并产生首个 logits，计算并行度高，主要决定 TTFT；decode 每步生成一个 token，读取全部历史 KV 并追加新的 KV，单步计算小、反复读权重和 KV，主要决定 TPOT 和并发上限（带宽下界见 8.2 节）。在线服务必须分别测量：

\[ \text{TTFT}=t_{\text{first}}-t_{\text{arrival}},\qquad \text{TPOT}=\frac{t_{\text{last}}-t_{\text{first}}}{N_{out}-1}\quad(N_{out}>1), \]

\[ \text{E2E}=t_{\text{pre}}+t_{\text{queue}}+t_{\text{prefill}}+t_{\text{decode}}+t_{\text{post}}, \]

其中 \(t_{\text{first}}\)、\(t_{\text{last}}\) 分别是第一个和最后一个输出 token 的时间，\(N_{out}\) 是输出 token 数。TPOT 取首末 token 之间的平均间隔，单 token 输出不定义该值；它仍会掩盖流式停顿，所以要同时保留逐 token 间隔的分布。

goodput 把延迟目标纳入吞吐：

\[ \text{goodput}=\frac{\text{观测窗口内同时满足 TTFT SLO 与 TPOT SLO 的成功请求数}}{\text{观测时长}}. \]

DistServe 在容量优化中采用同一思想：以每 GPU 在超过 90% 的请求同时满足 TTFT 与 TPOT 约束时可承受的最大请求速率作为目标 [13]。只报告 tokens/s 会掩盖排队和尾延迟：批处理吞吐很高的服务可能让短请求等待长 prompt，单请求延迟低的服务可能在并发时显存耗尽。因此要按负载分布报告 p50、p95、p99、成功率和 goodput。

Serving engine、副本与路由

推理引擎负责模型加载、权重分片、KV cache、batch 调度、采样、流式输出、量化 kernel、前缀缓存和错误处理。vLLM 以 PagedAttention 和连续批处理为核心 [14][15]；Triton Inference Server 是完整的推理服务器，提供 HTTP/REST 与 gRPC 接口、多框架后端与可扩展的 Backend API、动态批处理、模型仓库管理和指标导出 [16]。二者可以组合部署，因此“模型服务框架”不应被当成单一组件。

服务接口还要处理 tokenizer 版本、chat template、停止词、结构化输出、工具调用、超时、取消和流式断开。客户端取消后 KV 是否立即释放、重试是否导致重复副作用，都是 Infra 的正确性问题。大模型的一个副本通常是一组 TP/PP 分片，扩副本既增加吞吐和容灾，也受模型加载与 warmup 时间限制；路由层要知道副本健康、可用 KV 容量、排队和模型版本，不能只按 round-robin 分发。多模型平台的 fallback 必须经过任务与安全评估，路由决定要写入 trace。

调度术语速查

如图 8-4 所示，请求先经准入控制进入队列，再由迭代级调度器在每一步决定哪些请求做 prefill、哪些做 decode；KV block 的分配、复用与传输贯穿两个阶段。

flowchart LR
  REQ["请求到达"] --> ADM["准入控制<br/>长度、配额、KV 预算"]
  ADM -->|"超限"| REJ["拒绝、截断或转异步"]
  ADM --> Q["等待队列"]
  Q --> SCH["迭代级调度器<br/>continuous batching"]
  SCH --> PF["Prefill<br/>计算密集，决定 TTFT"]
  SCH --> DE["Decode<br/>带宽密集，决定 TPOT"]
  PF -->|"长 prompt 切块后再入调度"| SCH
  PC["前缀缓存命中"] -->|"跳过已缓存部分"| PF
  PF --> KV["KV block 池<br/>PagedAttention"]
  KV --> DE
  PF -.->|"PD 分离时跨池传输 KV"| DE
  KV -->|"不足时抢占"| SCH
  DE --> OUT["流式输出"]

图 8-4 Prefill/Decode 与调度机制的关系

前缀缓存与 KV block 共享的安全前提是：只有会产生完全相同 KV 的输入才能命中同一份缓存。缓存 key 因此要覆盖模板展开后的完整 token 前缀（用链式哈希把每个 block 与其全部前缀绑定）、模型与 tokenizer 版本、LoRA adapter 标识、多模态输入的内容哈希（不同图片的占位 token 完全相同，只看 token 会误命中），以及按租户或信任组注入的 salt。vLLM 的 block 哈希即由父 block 哈希、块内 token 和 LoRA ID、多模态输入哈希、cache salt 等附加项组成；只有带相同 salt 的请求才能复用彼此的缓存，以防攻击者通过延迟差异推断他人的缓存内容 [19]。系统提示、工具 schema 或动态插入的上下文一旦变化，旧缓存自然失配。验收时除命中率外，还要测命中带来的 TTFT 降低、缓存占用和跨租户隔离测试结果。

8.5 资源调度、隔离与平台化

GPU 编排与资源账本

Kubernetes 通过 device plugin 和资源请求调度 GPU [20]，但分布式训练还需要拓扑感知、gang scheduling（一组 GPU 必须同时就绪才启动，避免部分占用导致长期 pending）、优先级、抢占和节点健康检查；推理服务虽可弹性扩容，模型加载和 warmup 却使瞬时扩容不一定及时。因此集群要区分训练、推理、评估和交互式开发资源池：训练要长时间稳定的大 gang，推理要低延迟和滚动升级，评估要大量可并行任务，开发要快速反馈。混在一起时，低优先级训练可能挤占在线推理，交互式任务会把大块 GPU 切碎。

控制面首先维护的不是“有多少张卡”，而是一份可以结算的资源账本。资源请求给出 workload id、租户、优先级、GPU 型号与数量、节点与互联约束、预计长度分布或运行窗口以及预算；推理副本还要声明权重、量化格式、并发上限、KV 预算和加载时间。调度回执给出 reservation id、allocation id、真实设备与起止时间；用量事件再关联 token、GPU 时间、存储和失败重算。账本把 reserved、allocated、实际 usage 和 released 分开返回，并标明采样时间和未知部分：容量评估用可承诺资源而不是当前空闲数，成本评估同时展示失败与闲置分摊。

请求量与实耗量都要记。请求量用于准入与公平：八卡任务只申报四卡，就会挤占别人的容量；实耗量用于容量与成本：长期低利用率的 reservation 应回收或降级。两者的差距不是立即的违规证据，因为模型加载、checkpoint、通信同步和长上下文都会造成短时空闲，所以要按负载类型设观察窗口：训练看稳定 step 窗口内的有效 token/s 和通信等待，推理按长度分桶看排队、TTFT、TPOT 和 KV 水位，不能用一个全局 GPU 利用率阈值处罚所有任务。

拓扑也是账本的一部分。八张跨机 PCIe GPU 与八张同机高速互联 GPU 对 TP 和 MoE 的可用能力不同，控制面应把拓扑等级、故障域和网络带宽写成可调度属性，只在兼容集合中放置。Borg 关于优先级、配额和集群效率的讨论为这一控制逻辑提供了基本框架 [21]；Kubernetes 的资源请求是执行底座，但两者都不会自动判断一组 GPU 是否满足某种并行策略。

Lease 与资源状态机

资源生命周期最难处理的是“僵尸占用”：worker 已失联而训练进程仍在运行，NCCL communicator 未释放，或对象存储上传卡住，调度器看到的状态与真实设备不一致。因此每个 allocation 都持有 lease（有期限的租约）并定期心跳，同时携带单调递增的 fencing token：新的持有者拿到更大的 token 后，执行面拒绝任何携带旧 token 的写入和启动请求。lease 到期只表示控制面可以开始调查，不表示可以把同一块 GPU 立刻交给另一个任务；只有执行面确认旧进程、容器、挂载和网络身份都已撤销，资源才算释放。无法确认的节点宁可摘除，也不要超卖。图 8-5 是资源分配的最小状态机。

stateDiagram-v2
  state "running / serving" as running
  [*] --> requested
  requested --> admitted : 预算与配额通过
  requested --> rejected : 配额或权限不足
  admitted --> reserved : 计划窗口内预留容量
  reserved --> rejected : 预留超时未兑现
  reserved --> allocated : 执行面获得设备
  allocated --> warming : 加载权重或建立通信组
  warming --> running : 健康检查通过
  warming --> draining : 加载失败
  running --> draining : 完成、取消、抢占或缩容
  running --> suspect : 心跳丢失或 lease 到期
  suspect --> running : 宽限期内恢复且 fencing token 有效
  suspect --> quarantined : 宽限期超时
  quarantined --> failed : 确认旧进程与身份已撤销
  draining --> released : 确认释放，正常结束
  draining --> failed : 确认释放，异常结束
  rejected --> [*]
  released --> [*]
  failed --> [*]

图 8-5 资源分配与 lease 状态机

admitted 只表示预算与配额通过，reserved 表示容量在计划窗口内被预留，allocated 表示执行面已拿到设备；warming 对推理尤其重要，权重尚未加载完成时不能把容量算作可服务吞吐；draining 允许已开始的 decode 或 checkpoint 在 deadline 内收敛。心跳丢失先进入 suspect，宽限期内恢复且 fencing token 仍有效才回到运行；超时则进入 quarantined，设备既不继续运行原任务、也不分给新任务，直到撤销被确认后才以 failed 结束，长期无法确认的节点转人工处理。三个终态中，rejected 从未持有资源，released 与 failed 都以执行面的释放确认为前提，分别记录正常结束（含取消与抢占）和异常结束。每次迁移都带上执行者、策略版本、请求版本、资源快照和原因，避免“发布看起来完成、新副本其实未健康”或“训练已取消、却仍在消耗 GPU”的误判。

配额、公平与多租户隔离

多租户平台要隔离权重、adapter、KV cache、日志、数据和外部调用权限。GPU 共享能提高利用率，也会带来显存争抢、尾延迟互相影响和数据泄露。租户配额应覆盖并发请求、输入 token、输出 token、模型种类、外部调用和缓存大小。

公平不是平均分卡。交互式生产请求有严格 deadline，训练能等但需要连续 gang，评估适合在空档批量填充。控制面可以组合四种手段：hard quota 防止一个租户耗尽集群；reservation 为关键服务保留容量；借用让空闲容量被低优先级任务使用；回收在 reservation 需要时让可 checkpoint 的任务有序退出。借用必须有最大期限、可抢占标记和 checkpoint 协议。公平策略还应可解释：租户看到 pending 时，应能知道原因是配额、预算、拓扑、容量、优先级、数据权限还是发布冻结；管理员应能模拟“新增一个八卡训练作业会影响哪些在线 SLO”。这些都是控制平面的职责（8.7 节）。

容量方程

容量规划不能只按平均 QPS。prefill 和 decode 的单位成本不同，长短请求的可持续速率也不同，所以要按长度桶 \(b\) 分别计算。在目标配置上压测，得到满足 SLO 时单个副本可持续的输入 token 处理速率 \(R^{in}_b\) 与输出 token 生成速率 \(R^{out}_b\)，再用峰值流量 \(\lambda^{in}_b\)、\(\lambda^{out}_b\)（token/s）估算基础副本数：

\[ n=\left\lceil \sum_b\left(\frac{\lambda^{in}_b}{R^{in}_b}+\frac{\lambda^{out}_b}{R^{out}_b}\right)\right\rceil. \]

两个比值相加，隐含了同一副本上 prefill 与 decode 按时间线性分摊的假设，必须用混合负载压测校正。冗余不按经验百分比估算，而按 \(N+k\)（任意 \(k\) 个副本故障后仍有 \(n\) 个可用）或按故障域（失去最大的一个故障域后仍不少于 \(n\)）计算；滚动发布期间同时下线的副本和长上下文专用池再单独加上。模型路由比例和缓存命中率的变化都会改变 \(\lambda\) 与 \(R\)，所以容量方程要随这些输入一起版本化。

成本归因

成本归因的粒度应与决策粒度一致：训练的最小单元通常是实验或数据集版本，推理是请求、会话或业务操作。每个用量事件至少包含用量 id、起止时间、资源类型、租户、项目、成本中心、模型或制品版本、计量值和计价规则版本，并且必须幂等：同一段 GPU 使用或同一组 token 即使被重复消费，也只能结算一次。账单不是观测 dashboard 的导出，而是独立、可重放的事实流。

成本链要能从总账钻取到单个动作。以一个教学假设为例：某次业务任务的归因成本为 12 元，其中模型 token 6 元、GPU reservation 分摊 2 元、搜索工具 1 元、重试 1 元、人工批准 2 元；若任务失败，还要显示失败来自模型质量、工具故障还是预算策略。负责人据此判断该调整路由、修复工具、优化缓存还是限制输入长度。共享成本（warm pool、公共索引、观测系统）按预先公布的规则分摊。只看“每百万 token 价格”会诱使团队通过缩短输出、拒绝困难任务来制造成本下降，因此成本单位必须与质量和延迟一起报告。成本治理见第12章 12.6 节。

发布单元与决策记录

模型发布的单元是不可变 manifest，而不是一个模型 tag：即使权重不变，tokenizer、chat template、工具 schema、采样默认值、前缀缓存、路由规则、驱动或 kernel 的变化也可能改变用户可见行为。manifest 列出所有输入制品的 hash、资源配置、评估集版本和批准记录；请求 trace 记录实际命中的 manifest，回滚也回到经过验证的 manifest，而不是拼凑“看起来相同”的旧配置。发布门禁要把“制品可启动”（签名、依赖、权重完整性、模板、量化 engine、回滚包）与“变更可接受”（质量、安全、容量、成本、业务 SLO）分开，两类证据都满足才进入影子流量和灰度。

关键取舍可以记为轻量的架构决策记录（Architecture Decision Record，ADR）：背景、决策驱动、候选方案、决策、获得什么、主动牺牲什么、接受哪些风险，以及何时重新评估。例如把长上下文流量分到独立资源池，换来更可预测的 KV 容量和普通请求延迟，代价是资源碎片和较低的瞬时总体利用率。灰度阶段划分、停止条件和回滚执行见第12章 12.3 节，ADR 在可靠性评审中的用法见第12章 12.7 节。

8.6 可靠性、观测与 Infra 验收

本节只给出 AI Infra 特有的观测字段和验收口径；SLO 设计、错误预算与燃烧率告警、事故响应和演练运营见第12章。

SLO 分层与错误预算

在线 LLM 服务的 SLO 至少覆盖可用性、TTFT、TPOT、完成率、错误率、超时率和质量门禁。流式请求的“HTTP 200”不代表成功：可能只返回了部分 token、结构化输出损坏或用户中途取消；多步任务中，最终成功率和中间状态一致性比单次响应更重要。SLO 因此分三层：平台层保证可用和延迟，模型层保证格式与能力不回归，业务层保证任务成功率和人工接管率。

错误预算是 SLO 允许的不达标额度，例如 99.9% 的可用性目标对应 0.1% 的预算，它把可靠性目标转成决策边界 [1]。如图 8-6 所示，某个模型路由在窗口内消耗预算过快时，控制面可以冻结扩容、降低流量、增加副本或把新实验转为 shadow；质量门禁的预算消耗过快时，即使基础设施指标健康也要停止灰度。质量、成本和安全可以各有预算，但不能相互抵消：更便宜的模型不能用安全事件换取，吞吐提升也不能抵消结构化输出错误。预算口径与燃烧率告警见第12章 12.1 节。

flowchart LR
  SIG["信号<br/>metrics、logs、traces"] --> SLI["SLI<br/>按模型、版本、长度桶聚合"]
  SLI --> EB["SLO 与错误预算"]
  EB -->|"预算充足"| GO["继续发布或扩量"]
  EB -->|"消耗过快"| ACT["冻结扩容、降流量<br/>转 shadow 或回滚"]
  ACT --> EVD["保留现场证据"]
  EVD --> RV["复盘<br/>修正指标字典、容量模型、runbook"]
  RV --> SLI
  DRL["故障演练<br/>执行面与控制面"] --> SIG
  GO --> SIG

图 8-6 可靠性观测与决策闭环

Metrics、Logs 与 Traces

Metrics 适合聚合趋势，logs 记录单次错误与上下文，traces 记录跨服务和跨工具的因果链。Dapper 展示了如何把一次请求在多个服务中的路径串起来 [22]，OpenTelemetry 提供统一的 trace、metric、log 语义和上下文传播 [23]，Prometheus 提供指标采集、查询和告警 [24]。

大模型 trace 需要额外字段：模型与版本、manifest id、tokenizer、prompt hash、输入/输出 token 数、TTFT、TPOT、排队时间、缓存命中、采样参数、工具调用、verifier 结果、结束原因、安全决策和估算成本。观测的第一原则是把控制面的决定与执行面的结果连起来：一次慢请求的 trace 要能说明它命中了哪条路由规则、在哪个队列等待、由谁准入、分到哪种 GPU、KV 是否因配额被驱逐、成本归到哪个租户。默认不记录完整的敏感 prompt 和输出，只保留脱敏摘要，并做采样和访问审计。

高基数事实放 trace 或日志，可聚合维度放 metrics：按模型、版本、长度桶、区域、硬件池、路由原因和结果类别聚合 TTFT、TPOT、完成率、OOM、排队时间、缓存命中和成本，而不要把 request id 或用户作为指标标签。指标字典要写清名称、单位、分母、窗口、owner 与允许的标签；采样规则也要版本化，否则仅仅改变采样率，就会让趋势图看起来像质量变化。观测数据的分层留存见第12章 12.2 节。

训练与推理的观测重点

训练侧观测 loss、学习率、梯度范数、有效 token/s、MFU、显存、通信、数据等待、checkpoint 耗时和恢复时间；按数据桶、语言、长度和任务分层的 loss，往往比全局平均更早暴露数据或能力退化。dashboard 只能显示当前状态，experiment manifest 把代码、配置、数据、环境、并行拓扑、随机状态、checkpoint 和评估关联起来，才支持复现与审计；被取消的实验也要记录已消耗的资源和是否留下可复用的 checkpoint。训练观测的细节见第9章 9.7 节。

推理侧不能只看平均 tokens/s，至少需要输入/输出长度分桶、并发、排队、prefill 与 decode 时间、KV 使用、缓存命中、显存水位、OOM、取消、重试和路由结果；p99 的长请求往往决定体验和容量。性能回归要与质量回归同时做：量化后吞吐上升但代码通过率下降，不算成功；前缀缓存降低了 TTFT 但隔离测试失败，更不能上线。

故障模型与演练

上线前要列出故障：单 GPU、单节点、网络、对象存储、模型加载、KV OOM、kernel crash、tokenizer 不兼容、上游限流、工具超时、checkpoint 损坏和区域不可用，并为每种故障定义检测、降级、重试、隔离、回滚和人工处理路径。训练故障回到最近的完整 checkpoint；推理故障摘除副本、切到经过评估的备用模型或转异步；不可重试的副作用动作依赖幂等键和状态查询。

演练要覆盖执行面和控制面两层。执行面包括杀副本、注入 OOM、限速对象存储、让 KV 传输失败、中断 token 流；控制面包括错误路由、过期 reservation、重复计费事件、策略服务不可用和 manifest 不兼容。每项演练记录检测信号、告警延迟、恢复时间、丢失或重复的请求以及剩余风险。容器能自动重启只证明一个局部机制存在，不证明用户任务、资源账本和发布状态能收敛。演练组织与灾备见第12章 12.4 节和 12.7 节。

Infra 验收清单

任何一行缺少证据，都应缩小影响范围而不是扩大流量。责任上，模型团队对能力、评估集、已知限制和制品签名负责，Infra 团队对调度、容量、路由、计量、隔离和恢复负责，业务团队对成功定义、风险接受和人工路径负责，安全与治理团队对数据、权限、审计和发布政策负责。没有 owner 的指标、没有回滚路径的制品、没有成本中心的任务，都不进入生产资源池。

8.7 五平面与决策地图

五个平面

为了判断一个问题属于哪一层、需要什么证据才算解决，本书把 AI Infra 拆成五个平面。需要区分两个术语：数据资产平面管的是数据作为资产的版本、血缘和授权，与网络和分布式系统里“控制面/数据面”所说的数据面不是一回事；后者在本书中称为执行面，指请求和作业实际执行的路径，落在计算平面和状态平面上。

8.1 节的五个验收维度、本表的五个平面和 8.9 节的四类契约是同一张地图的三种切法：验收维度回答“验什么”，平面回答“问题落在哪一层”，契约回答“层与层之间承诺什么”。三者的对应关系如下：

用五平面排查问题

五个平面不是组织架构，而是分析工具，它也给出一个排查顺序（图 8-7）：先确认数据资产平面是否改变了输入分布、权限或版本，再看计算平面有无容量、拓扑、通信或存储瓶颈，随后检查状态平面中的 checkpoint、KV、请求和幂等是否一致，检查控制平面是否做出了预期的准入、路由、发布和回收决定，最后检查治理平面的阈值、审批、审计和责任是否仍然有效。顺序不要求线性执行，但能防止团队只盯着模型输出，忽略让输出进入生产的其他边界。

flowchart TB
  OBS["观察到的问题"] --> DA["数据资产平面<br/>输入分布、权限、版本"]
  DA --> CO["计算平面<br/>容量、拓扑、通信、存储"]
  CO --> ST["状态平面<br/>checkpoint、KV、请求、幂等"]
  ST --> CT["控制平面<br/>准入、路由、发布、配额与公平"]
  CT --> GV["治理平面<br/>阈值、审批、审计、责任"]
  GV --> EV["在同一条 trace、manifest、<br/>账本和评估证据上比较假设"]
  EV --> DEC["决策：修改算法、数据、调度、<br/>运行时或治理策略"]
  DEC -->|"新证据推翻假设"| OBS

图 8-7 五平面排查顺序与决策回路

以 ALR（本书 Agent 部分贯穿使用的业务诊断 Agent 案例）为例 ：ALR-20260429-017 是 ALR 的一个诊断案例编号，这次运行创建了跟进工单 INC-4821。排查时，数据资产平面核对诊断所引用的证据与 Runbook 快照的来源和版本；计算平面排除查询链路的容量与延迟异常；状态平面核对运行记录 run_0429_017、对应的 Operation 与工单 INC-4821 是否一致；控制平面核对工具路由以及绑定草稿、资源版本的审批；治理平面检查旧 Runbook 导致的错误诊断为何未被验证器拦住。各平面的假设要在同一条 trace、manifest、资源账本和评估证据上比较；时间上邻近的部署 deploy_8842 不能直接证明就是根因，更不能据此回滚。

决策地图

每个提案应先写出它改变了哪些平面、依赖哪些事实、失败后由谁检测、如何降级和回滚、成本由谁承担，以及哪些观测可以推翻原假设。例如引入 speculative decoding（由小模型起草、大模型验证的加速解码），计算平面要证明吞吐与显存假设，状态平面要说明 draft/target 结果的取消与一致性，控制平面要说明何时启用与禁用，治理平面要说明质量与成本门槛；缺了这些，它仍是性能实验，而不是平台能力。跨平面决策还要避免局部最优：扩大 batch 改善了计算利用率，却可能突破控制平面的公平策略、饿死长请求；更激进的前缀缓存降低了成本，却提高了隔离风险；更严格的发布门禁提高了治理质量，却延长了紧急修复时间。

控制平面自身的失效

控制平面本身也会失败和滞后。调度器、策略服务、制品目录或配额账本不可用时，执行面不能临时“猜”该做什么，设计时要预先规定默认态：已持有 lease 的工作负载可以继续多久，尚未开始的高风险操作是拒绝、排队还是只允许只读，哪些紧急回滚可以绕过常规队列，恢复后如何对账离线期间的计量与状态变化。默认态应倾向于收缩权限和影响范围。策略变更要记录提案人、批准人、执行身份、范围、有效期和撤销条件；当队列或 KV 水位持续偏离预测、单位成功成本越过预算，或策略模拟与真实结果长期不一致时，先冻结放量、保留决策证据，再由对应 owner 修正模型或回滚策略。

8.8 跨章接口与部署决策

工作负载、状态与事实源

存储位置相同不等于语义相同。训练 checkpoint 保存优化器状态和数据游标，推理 KV 是可重算的中间值，承载外部动作的持久状态还必须记录对应的操作标识；三者不能被统一成一个模糊的“缓存恢复”。

跨章接口一览

如图 8-8 所示，第8章定义的账本、指标和平面被后续各章使用，各章之间再通过少数几个不可变对象交接。下表只列接口的用途和最小内容，字段规范见各章。

flowchart LR
  C8["第8章<br/>资源账本、核心指标、五平面"]
  C9["第9章<br/>训练平台与数据管线"]
  MM["Model Manifest"]
  C10["第10章<br/>推理服务"]
  C11["第11章<br/>评估与反馈闭环"]
  C12["第12章<br/>生产运营与治理"]
  C8 -->|"显存与 FLOPs 账本、并行维度"| C9
  C8 -->|"KV 账本、TTFT、TPOT、goodput"| C10
  C8 -->|"验收维度、Eval Case 接口"| C11
  C8 -->|"SLO、资源账本、发布单元"| C12
  C9 -->|"dataset manifest、checkpoint"| C11
  C9 -->|"导出制品"| MM
  MM --> C10
  C11 -->|"评估证据与门禁结果"| C12
  C10 -->|"trace 与用量事件"| C12
  C12 -->|"回滚与再训练请求"| C9

图 8-8 跨章接口：第8章与第9–12章

W/A/KV 三种精度可以不同，必须分别登记。Model Manifest 的硬件、上下文和并发限制应来自验证记录，不能由模型名称推断；hash 或模板不匹配时拒绝加载并保留原因。加载本身也要原子：目录轮询不能充当发布机制，例如 Triton 的 POLL 模式可能观察到模型仓库的部分更新 [25]。发布请求在质量达标但资源不足时应缩小范围或重新选型，在容量达标但权限或质量不达标时应暂停。

自托管、外部 API 与混合部署

先按数据分级澄清传输、留存、访问、部署区域和审计要求，再判断哪些方案可以接触相应输入。自托管增加硬件、模型加载、Serving 升级、补丁、值守与事故责任，不自动等于安全；外部 API 减少部分运维负担，却引入配额、网络、供应商变更与数据留存契约，未经独立核验，不能把供应商的宣传当作默认的数据保证。

对峰谷明显的业务，要在相同质量和延迟目标下比较总拥有成本：预留与闲置、峰值冗余、冷启动、模型分发、缓存、网络、失败重试、人工值守和排队超时损失；外部方案还要比较峰值配额能否兑现以及跨区费用，不能只用 token 单价去比 GPU 标价。混合方案可以按敏感级别或任务类型路由，但回退目标必须满足原有的权限和数据边界，不能因为本地故障就把受限材料外发。利用率低而峰值排队严重时，先对照预留量与启动时间，再决定购买峰值容量、用允许的 API 补峰还是改为异步。决策用 ADR 记录允许的任务与数据范围、同负载基线、容量与费用假设、主动承担的成本和重新评估条件。

8.9 本章小结：把复杂度变成契约

AI Infra 的核心能力是把算法复杂度转化为四类契约（图 8-9）。资源契约说明模型在不同长度、并发和硬件下需要多少显存、FLOPs、带宽和存储，8.2 节的 \(16P\)、\(6PD\)、每 token \(2P\) 与 KV 公式是它的量级基础；状态契约说明请求、KV、checkpoint、数据游标和外部操作记录如何创建、恢复、过期与释放，8.5 节的 lease 状态机是它在资源层的样例；质量契约说明模型升级、量化、kernel、调度和降级对输出质量与任务成功的影响；治理契约说明谁批准、谁负责、证据在哪里。

flowchart TB
  ALG["算法输入<br/>参数量、上下文、精度、结构"] --> LED["资源账本 8.2<br/>显存、FLOPs、带宽、成本"]
  LED --> TR["训练并行 8.3<br/>TP、PP、DP 的选择顺序"]
  LED --> INF["推理调度 8.4<br/>TTFT、TPOT、goodput"]
  TR --> CTRL["资源控制面 8.5<br/>lease、配额、容量方程"]
  INF --> CTRL
  CTRL --> REL["可靠性与观测 8.6<br/>SLO、错误预算、验收"]
  REL --> PL["五平面与决策地图 8.7"]
  PL --> IF["跨章接口 8.8<br/>Manifest、Eval Case、账本"]
  IF --> K["四类契约<br/>资源、状态、质量、治理"]

图 8-9 本章概念图

几个判断贯穿全章：并行度按“机内 TP、跨机 PP、剩余 DP”的顺序选择，扩展效率相对可运行的基准规模衡量；推理容量用同时满足 TTFT 与 TPOT 的 goodput 而不是裸吞吐来衡量，并按输入、输出 token 和长度桶分别建模；资源释放以执行面确认为准，lease 到期只触发调查；所有变更以不可变 manifest 为单元，证据挂在同一条 trace 和账本上。后续各章沿这张地图展开：第9章讲训练平台的并行、数据与 checkpoint，第10章讲推理引擎的调度与 KV 管理，第11章讲评估证据，第12章讲运营与治理。读到任何一个组件时，都可以追问：它改变了哪项资源、状态、质量或治理约束，系统用什么证据证明它在真实负载下仍然成立？

8.10 参考资料

1. Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. 核验日期：2026-10-17。
2. Rajbhandari, S., et al. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. SC, 2020. 核验日期：2026-10-17。
3. Rajbhandari, S., et al. ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning. SC, 2021. 核验日期：2026-10-17。
4. Kaplan, J., et al. Scaling Laws for Neural Language Models. arXiv, 2020. 核验日期：2026-11-05。
5. Chowdhery, A., et al. PaLM: Scaling Language Modeling with Pathways. arXiv, 2022. 核验日期：2026-10-17。
6. NVIDIA. NCCL User Guide: Collective Operations. NCCL 2.32.3 在线文档, 2026. 核验日期：2026-10-17。
7. Zhao, Y., et al. PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel. arXiv, 2023. 核验日期：2026-10-17。
8. Shoeybi, M., et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv, 2019. 核验日期：2026-10-17。
9. Narayanan, D., et al. Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM. SC, 2021. 核验日期：2026-10-17。
10. Dao, T., et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS, 2022. 核验日期：2026-10-17。
11. Dao, T. FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning. ICLR, 2024. 核验日期：2026-10-17。
12. NVIDIA. TensorRT: Engine Compatibility. TensorRT 在线文档, 2026. 核验日期：2026-11-05。
13. Zhong, Y., et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. OSDI, 2024. 核验日期：2026-11-05。
14. Kwon, W., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP, 2023. 核验日期：2026-10-17。
15. vLLM Team. vLLM Source Repository. GitHub, 2023. 核验日期：2026-10-17。
16. NVIDIA. Triton Inference Server. GitHub 项目主页, 2026. 核验日期：2026-11-05。
17. Yu, G.-I., et al. Orca: A Distributed Serving System for Transformer-Based Generative Models. OSDI, 2022. 核验日期：2026-10-17。
18. Agrawal, A., et al. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve. OSDI, 2024. 核验日期：2026-10-17。
19. vLLM Team. Automatic Prefix Caching. vLLM 在线文档（latest）, 2026. 核验日期：2026-11-05。
20. Kubernetes Authors. Schedule GPUs. Kubernetes 在线文档, 2026. 核验日期：2026-10-17。
21. Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. 核验日期：2026-10-17。
22. Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report, 2010. 核验日期：2026-10-17。
23. OpenTelemetry Authors. Signals. OpenTelemetry 在线文档, 2026. 核验日期：2026-10-17。
24. Prometheus Authors. Prometheus Overview. Prometheus 在线文档, 2026. 核验日期：2026-10-17。
25. NVIDIA. Triton Inference Server: Model Management. Triton 在线文档, 2026. 核验日期：2026-10-17。

第9章 训练平台与数据管线

版本与证据说明：本章的平台对象、数据接口、快照发布协议、故障矩阵、成本式与诊断例均为教学设计，未在目标规模集群上实测，引用文献只支持所列机制。涉及 PyTorch 2.9、NCCL 2.32 等具体版本的行为以对应文档为准，升级后需要复核。

一个训练作业可能连续运行数周，占用成百上千张 GPU。它要回答的问题与在线服务不同：海量数据如何稳定、可复现地送到 GPU；数据并行、张量并行、流水线并行和专家并行如何组合；通信怎样与计算重叠；节点故障、版本变化和硬件变化之后，怎样恢复到一个可解释的训练状态。第8章已建立大模型 Infra 的全局资源模型（显存、FLOPs、带宽账本与核心指标）；本章只讲训练阶段。对后端工程师而言，训练平台可以理解为一个运行很久、状态复杂、对吞吐极其敏感的分布式任务系统。

训练 Infra 的目标不是让脚本在一台机器上跑通，而是让“有效 token 数/时间”可预测、可扩展、可恢复。一个 step 的耗时可以拆成数据读取、host 到 device 拷贝、forward、backward、梯度同步、optimizer update 和 checkpoint；可重叠阶段不能把区间简单相加当作 wall time。任何阶段成为瓶颈，继续增加 GPU 都只会增加成本。Megatron-LM 的模型并行 [1]、ZeRO 的状态分片 [2] 和 PyTorch FSDP 的工程实现 [3] 都说明，大模型训练是模型状态、通信拓扑和故障恢复共同决定的系统问题。

本章按训练作业生命周期组织：先定义作业对象和控制面，再让数据以可复现方式进入 GPU，随后选择并行策略、kernel 与通信优化，接着用 checkpoint 与弹性恢复保护长时间运行，最后用调度、观测和发布门禁把训练结果变成可交付制品。

9.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 中任何字段的变更（例如换数据版本或改并行度）都应生成新的 spec 与执行记录；平台若允许同一 run 内分阶段变更，也要写入显式的版本事件，不能静默覆盖。

控制面与数据面的边界

Ray 把任务执行、资源声明和分布式运行时分开，为控制面设计提供了有用的抽象 [4]。Kubernetes 的 GPU device plugin 可以作为资源分配基础，但训练平台还要补充 gang scheduling、拓扑亲和性、节点健康和优先级 [5]。Borg 的实践说明，配额、优先级、抢占和故障域应由集群控制面统一管理，而不是由每个任务自己实现 [6]。

控制面负责提交、排队、分配、启动、心跳、停止、重试、恢复和归档，需要幂等与可审计；数据面负责 batch 生成、forward、backward、通信和状态写入，需要低延迟与高吞吐。用户重复提交相同 idempotency key 时，控制面应返回已有 job，而不是再申请一组 GPU。worker 失联时，lease 或 heartbeat 超时只能触发调查；资源重新授予之前，还要确认旧执行已经停止或已被 fence（隔离：通过递增的租约代号让旧执行者的写入被拒绝，或直接终止其进程），不能把租约过期等同于设备已释放。

控制面不能把运行时细节写进长数据库事务。一个 step 可能持续数秒，checkpoint 可能持续数分钟，控制面应通过事件记录阶段和状态，而不是长时间持锁。图 9-1 给出一组推荐状态。每次迁移都要校验前置状态，重复的完成事件必须幂等，旧 worker 迟到的心跳不能把已经回收的作业改回 RUNNING。

stateDiagram-v2
    [*] --> CREATED
    CREATED --> QUEUED: 校验 spec 与配额
    QUEUED --> ALLOCATING: gang 资源可用
    ALLOCATING --> STARTING: allocation 与 rank manifest 就绪
    STARTING --> RUNNING: 全部 rank 握手成功
    RUNNING --> CHECKPOINTING: 到达保存点
    CHECKPOINTING --> RUNNING: 提交完成或转后台
    RUNNING --> RECOVERING: 节点丢失或通信超时
    RECOVERING --> ALLOCATING: 需要替换资源
    RECOVERING --> RUNNING: 从已提交 checkpoint 恢复
    RUNNING --> SUCCEEDED: 达到目标 step
    RECOVERING --> FAILED: 超过重试上限
    QUEUED --> CANCELLED: 用户取消
    RUNNING --> CANCELLED: 用户取消
    SUCCEEDED --> [*]
    FAILED --> [*]
    CANCELLED --> [*]

图 9-1 训练作业的控制面状态机

运行时身份与配置

每个 rank 都要知道 global rank、local rank、world size、node rank、数据分片范围和通信组。配置不能只依赖环境变量，因为环境变量在重试或跨集群迁移中容易变化。平台应生成 rank manifest，记录 rank 到节点、GPU、网卡和并行维度的映射，并把它与 checkpoint 和性能报告关联。

运行时配置要区分用户意图和平台推导值。用户声明 global batch、目标 sequence length 和模型并行上限，平台推导 micro-batch、梯度累积步数、通信组和数据 worker 数。推导过程应可解释：为什么某个 batch 被降低，为什么 tensor parallel 只能取 8，为什么某个节点被排除。否则调度器虽然自动化，训练结果却变得不可理解。

安全与供应链边界

训练集群通常拥有高权限网络、对象存储和 GPU，容器中的任意代码都可能读取不该读取的数据。镜像要签名，依赖要锁定，网络按任务隔离，checkpoint 和日志加密；开发者调试权限与生产训练权限分离，禁止通过挂载宿主机路径绕过数据控制。worker 的短期凭证与多租户隔离见 9.6 节。访问数据、下载 checkpoint、修改 job spec 和改变发布状态的动作都要有审计。

外部模型、tokenizer、预训练数据、量化工具和 kernel 都可能带来恶意代码或不兼容行为。构建阶段扫描依赖、固定来源并生成 SBOM（software bill of materials，软件物料清单，列出制品包含的全部组件及版本）；运行阶段限制网络和文件系统；发布阶段校验 artifact hash。模型和依赖持续更新，这些检查也要随每次构建执行，而不是只在平台上线时做一次。

与贯穿案例的对应：ALR（本书 Agent 部分贯穿使用的业务诊断 Agent 案例）的应用 Run 不能代替训练作业，因为 GPU 拓扑、数据 shard、checkpoint 和弹性恢复是训练平台特有的机制；这种对照只适用于训练平台机制。若要对照，job spec、训练数据与制品、调度动作、checkpoint 状态和发布门禁，分别对应 ALR 的任务契约、Evidence、受控动作、Run 状态和验收证据。

9.2 数据供给与有效训练信号

数据分层、不可变快照与 schema 兼容

数据不应直接从原始文档流入 GPU。常见分层是 raw document、clean document、deduplicated corpus、token shard、packed sample 和 batch，如图 9-2 所示。raw 层保留来源与授权信息；clean 层完成编码、语言识别、格式过滤和敏感信息处理；deduplicated 层处理精确与近似重复；token shard 适合高吞吐顺序读取；packed sample 把多个短样本拼成固定窗口；batch 绑定某个 run 的 seed 和采样策略。每一层都应有 manifest、schema、统计和 hash，统计至少包含文档数、有效 token、语言比例、长度分布、重复率、过滤率和采样权重。

flowchart LR
    A["raw document<br/>来源与授权"] --> B["clean document<br/>编码与过滤"]
    B --> C["deduplicated corpus<br/>去重与去污染"]
    C --> D["token shard<br/>固定 tokenizer"]
    D --> E["manifest 与统计<br/>最后写入"]
    E --> F["提交标记<br/>快照可见"]
    F --> G["读取与预取<br/>节点缓存"]
    G --> H["packing<br/>样本边界与 loss mask"]
    H --> I["batch<br/>seed 与数据游标"]
    I --> J["训练 step"]
    L["血缘记录<br/>输入版本 代码 参数"] -.-> C
    L -.-> D
    L -.-> E

图 9-2 从原始文档到训练 step 的数据管线

数据版本应发布为不可变快照：shard 对象一经写入不再修改，统计与校验完成后最后写入 manifest 和提交标记（commit marker），读取方只解析已提交的 manifest，未提交的残留对象由清理任务回收。“先写数据、后写提交标记”让单个快照在自身目录内原子可见，但快照不会因此获得跨系统 ACID：对象存储、元数据目录和训练作业记录分属不同系统，作业登记了 manifest hash 而快照随后被撤回，或目录更新成功而通知失败，都要靠唯一版本 ID、幂等登记和定期对账收敛。9.5 节的 checkpoint 发布沿用同一思路。

血缘（lineage）记录每个派生版本的输入版本、变换代码与镜像 hash、参数和输出 manifest。它回答两个方向的问题：某个 run 用了哪些上游来源；某个来源被删除或授权撤回时，哪些 shard、run 和 checkpoint 受影响。schema 演进默认要求向后兼容：只新增带默认值的可选字段，不改变已有字段的类型、单位和语义，读取方声明可接受的 schema 版本范围。删除字段、改变分词语义或 loss mask 规则属于不兼容变更，应发布新的主版本；训练作业遇到范围外的 manifest 时拒绝启动，而不是尽力解析。

清洗、去重、污染与评估隔离

清洗规则同时影响质量、数据量和成本。过强过滤可能丢失少数语言、代码和长文档；过弱过滤会引入乱码、模板重复、广告和隐私。去重也不只是整文档 hash：同一网页的导航、模板、转录和代码片段可能构成近重复，需要在 token n-gram、文档 embedding 或 MinHash 层面建立策略。各数据源的去重阈值应记录在 manifest，而不是藏在一次性脚本里。质量检查可以在写入 token shard 前做，也可以在训练时抽样做：前者节省训练资源，后者能发现分片损坏和分布漂移。

污染（contamination）指评估集内容或其近重复进入训练数据。去重系统若只在训练集内部工作，评估集内容可能留在训练数据中；若把所有数据一起去重，又可能泄露测试集的存在和分布。可行做法是把已登记评估集作为只读参照，按 n-gram 重叠等规则从训练侧移除命中样本，并在 manifest 中记录所用评估集版本、阈值和 split 生成规则。评估服务读取只读版本，训练 worker 不获得写权限。评估侧如何划定 holdout、判定污染对指标的影响，见第11章。

读取路径、packing 与有效 token

GPU 训练的读取路径通常经过对象存储或分布式文件系统、节点缓存、CPU 内存、pinned memory 和 GPU 显存，每一层都要明确缓存大小、并发、超时和失败策略。直接从远端对象存储读取小文件会产生过多请求，把全部 shard 复制到每台节点又会放大存储成本；更合理的方案是大 shard、顺序读取、节点级缓存和有限深度的预取队列。预取太浅，网络抖动直接暴露给 GPU；太深则占用 CPU 内存，并把错误推迟到很久以后。数据 worker 应暴露等待时间、读取吞吐、解压时间、队列长度、坏样本数和重试次数，让训练侧能区分“没有数据”“数据损坏”“数据服务超时”和“GPU 处理慢”。

固定 sequence length 便于 kernel 和 batch，但短样本 padding 会浪费计算。packing 把多个样本拼进一个窗口，代价是必须保存样本边界、attention mask 和 loss mask，并明确是否允许跨样本上下文。本章统一使用三个口径：device token 指送入 GPU 的全部位置（含 padding）；有效 token 指其中的真实样本 token；loss token 指有效 token 中参与损失计算的部分（例如监督微调中不计 prompt 部分）。训练报告应同时记录三者，核心吞吐指标用 loss token 计：

\[ R_{\text{loss}}=\frac{N_{\text{loss}}}{T_{\text{wall}}} \]

一个降低 padding 的优化若引入复杂的数据准备，可能提高有效 token 比例却降低 \(R_{\text{loss}}\)。评估时要同时展示 device token/s、loss token/s、GPU busy 和数据等待占比。PaLM 与 Llama 3 的规模化训练经验说明，数据配方、训练时间和系统吞吐必须共同考虑，不能只看参数量 [7][8]。

数据游标、混合配方与 tokenizer 契约

训练数据不是普通消息队列。消息队列关心至少一次或恰好一次消费，训练还要关心样本顺序、采样权重、样本边界、token 数和 epoch 定义。worker 崩溃后重放一个 batch，结果可能不同，因为 dropout、混合精度和并行归约都可能变化。平台要先定义可接受的语义：预训练可以容忍少量重复，监督微调可能要求不重复，对齐数据可能需要精确记录每次消费。数据游标因此不能只记“第几个 batch”，因为 worker 数、packing 策略和 shard 版本变化会使 batch 编号失去意义；更稳妥的游标包含 manifest hash、shard id、sample offset、token offset、packing 状态和采样器状态。恢复时字段不兼容，要明确走 reshard、重放或拒绝恢复，而不是静默从最近位置开始。

混合比例可以按文档数、字节、token 或 loss token 定义，四种结果不同。若代码样本平均更长，按文档数设 20% 并不等于按 token 得到 20%；大量样本被过滤或截断时，声明配方与实际配方可能相差很大。平台应把权重归一化过程写进 manifest，运行中统计实际消费比例，并为数据桶耗尽（循环采样、重新归一化或结束 epoch）和配方切换定义策略；切换事件写入 trace 和 checkpoint，否则损失曲线的变化无法归因。

tokenizer 是决定样本长度、词表、特殊 token、padding、截断和模型输入的运行时契约。升级 tokenizer 会改变有效 token 数、packing、embedding shape 和成本，因此 job spec 必须保存 tokenizer 的不可变 artifact hash、normalization 规则、special token、chat template 和最大长度；checkpoint 恢复时 tokenizer 不一致，应拒绝或执行经过验证的迁移。数据质量报告还应包含字符到 token 的膨胀比例，按语言、数据源和长度分桶，以发现未知字符、二进制内容和控制字符造成的 token 爆炸。

漂移监测与数据 DAG 的重试边界

长周期训练中，上游站点变化、过滤规则更新或某个数据源失效都会让数据漂移。平台按时间窗口统计有效 token、语言、长度、来源、重复率和过滤率，与 job spec 的目标配方比较，超过阈值时暂停消费、重新生成 shard 或标记新阶段。训练指标同样会漂移：全局 loss 下降不代表每种语言、代码和长文档都改善，按数据桶和长度分层的 loss 可以发现某个源异常或 tokenizer 处理错误。

预处理通常是一个包含下载、解析、过滤、去重、分词、分片和统计的 DAG。每个节点记录输入版本、输出版本、执行镜像、参数和结果 manifest。失败时只重试失败分区，不重做已完成且校验通过的分区；上游输出变化时，按血缘确定哪些下游失效。RDD 的分区与血缘容错思想说明，数据处理的可靠性来自可重建的中间结果和明确的血缘，而不是某个常驻进程 [9]。重试还要区分瞬时错误和确定性错误：对象存储超时、节点暂时不可用可以退避；未知编码、schema 不匹配或超出内存上限则应隔离样本并记录原因。每个分区设最大重试次数、错误样本上限和 quarantine 路径，坏 shard 进入 quarantine 后由数据负责人修复重跑，不影响其他分区，也不会被无限重试掩盖。

9.3 并行策略与资源账本

第8章 8.3 节已给出 DP、TP、PP 与 ZeRO/FSDP 的概览和模型状态显存账本，本节不再复述定义，只写训练平台需要的增量：batch 口径、TP 与 PP 的通信与 bubble 结论、ZeRO 的显存与通信账本、3D mesh 与 SP/CP/EP 的切分轴，以及并行配置如何成为恢复契约。

数据并行与 batch 口径

数据并行（DP）让每个 rank 持有完整副本、处理不同 micro-batch，再用 all-reduce 同步梯度。增加 DP rank 并不改变单卡显存。模型变大时，单卡先放不下完整的参数、梯度和优化器状态；DP 规模变大时，梯度同步在 step 中的占比上升，固定 global batch 下每卡 batch 变小，kernel 效率随之下降。

在各 rank micro-batch 相同且没有不齐尾批时，样本口径的 global batch 为 \(B=b\times D\times A\)，其中 \(b\) 为每 rank micro-batch，\(D\) 为 DP 度，\(A\) 为梯度累积步数。packing 下还要单独统计每步 loss token，不能把样本公式直接当成 token 批量。改变任何一个因子都可能改变优化轨迹，平台必须记录真实的 global batch 和每步 loss token，而不是只记录 dataloader 的 batch size。梯度 all-reduce 能否与 backward 重叠，取决于 bucket 大小、梯度 ready 顺序和拓扑 [10]。

张量并行与流水线并行

Megatron 式张量并行（TP）把 MLP 和 attention 的权重矩阵按列、行切分，每个 Transformer 层前向 2 次、反向 2 次 all-reduce [1]。这个次数不随 TP 度 \(t\) 变化，变化的是比例：每卡矩阵计算降为约 \(1/t\)，而每次 all-reduce 每卡发送的字节量趋近激活大小的 \(2(t-1)/t\) 倍，基本不随 \(t\) 缩小，因此 \(t\) 越大通信占比越高，跨节点时尤为明显。这就是 TP 通常限制在 NVLink 域内的原因。

流水线并行（PP）把层切成 \(p\) 个 stage，一个 global batch 拆成 \(m\) 个 micro-batch 依次流过。GPipe 式调度先做完全部前向再做反向，bubble（空闲时间）占总时间的比例约为 \((p-1)/(m+p-1)\)。1F1B（one-forward-one-backward）调度让每个 stage 在稳态交替执行一个 micro-batch 的前向和一个 micro-batch 的反向。非交错 1F1B 的 bubble 比例与 GPipe 相同，它的作用是把每个 stage 同时驻留的激活从 \(m\) 个 micro-batch 降到约 \(p\) 个；交错调度让每卡持有 \(v\) 个不相邻的虚拟 stage，bubble 约降为原来的 \(1/v\)，代价是 stage 间点对点通信增加约 \(v\) 倍 [11]。图 9-3 以 \(p=3\)、\(m=4\) 为例画出非交错 1F1B 时序（假设反向耗时为前向的两倍），每个 stage 空闲 6 个时间单位，占总长 18 的 1/3，与公式一致。

gantt
    title 非交错 1F1B 时序 p=3 m=4
    dateFormat X
    axisFormat %s
    section Stage1
    F1 : 0, 1
    F2 : 1, 2
    F3 : 2, 3
    B1 : 7, 9
    F4 : 9, 10
    B2 : 10, 12
    B3 : 13, 15
    B4 : 16, 18
    section Stage2
    F1 : 1, 2
    F2 : 2, 3
    B1 : 5, 7
    F3 : 7, 8
    B2 : 8, 10
    F4 : 10, 11
    B3 : 11, 13
    B4 : 14, 16
    section Stage3
    F1 : 2, 3
    B1 : 3, 5
    F2 : 5, 6
    B2 : 6, 8
    F3 : 8, 9
    B3 : 9, 11
    F4 : 11, 12
    B4 : 12, 14

图 9-3 非交错 1F1B 的 micro-batch 时序与 bubble

公式假设各 stage 耗时相同，真实系统由最慢 stage 决定吞吐。Embedding、输出头、MoE 层、视觉模块和权重共享都会改变 stage 的参数与计算，按层数平均切分往往造成 straggler；第一个 stage 驻留的未反向 micro-batch 最多，激活峰值也最高。固定 global batch 时调小 micro-batch 会增加 \(m\)、降低 bubble 比例，却同时改变累积次数和 kernel 效率，不能只看 bubble 比例做选择。应先逐 stage 报告前向、反向、等待与显存峰值，再比较切层、虚拟 stage、激活重算和调度方案。

ZeRO、FSDP 与显存通信账本

ZeRO 逐级分片优化器状态、梯度和参数 [2]，FSDP 在 PyTorch 中以参数分片、all-gather 和 reduce-scatter 实现类似目标 [3]。分片让模型能在更少显存中训练，代价是把参数获取和释放放进了关键路径。下表把显存与通信放在同一张账本里。教学假设：共 \(P\) 个参数，参数与梯度均为 BF16（各 2 字节），FP32 master weights 与 Adam 两个 moment 共 12 字节；\(D\) 为分片所在 DP 组大小；\(\Psi\) 为一份完整参数（或梯度）的字节数，通信量按 ring 实现、\(D\) 较大时每 rank 发送量计。

若梯度以 FP32 累加（梯度累积时常见），普通 DP 约为 \(18P\)，其余各行相应增加；不同优化器和实现须重算字节口径。ZeRO 论文给出的结论正是：阶段 1、2 的通信量与普通 DP 相同（约 \(2\Psi\)），阶段 3 约为 1.5 倍（约 \(3\Psi\)）[2]。FSDP 文档说明其设计受 ZeRO-3 启发：FULL_SHARD 在前向和反向前后各 all-gather 并重新分片参数；SHARD_GRAD_OP 前向后保留完整参数直到反向结束，行为接近 ZeRO-2；NO_SHARD 等价于 DDP；HYBRID_SHARD 在节点内做 FULL_SHARD、节点间复制，把 all-gather 和 reduce-scatter 限制在节点内 [12]。表中的 FSDP 对应是按行为归纳，文档本身并未逐一映射。

表中是模型状态的理想载荷，不是 GPU 峰值。前向获取的完整层、预取的下一层、通信 bucket、为重叠保留的梯度、激活、allocator 保留块和 CPU staging（暂存）缓冲可能同时存活，不能把 ZeRO-3 的式子当作显存申请上限。offload 改变状态的位置，激活重算改变激活的保存方式，二者与 ZeRO 阶段是相互独立的开关。一个在显存充裕机器上有效的重叠配置，迁移到更小的 GPU 后可能触发 OOM。ZeRO-Infinity 进一步把状态卸载到 CPU 和 NVMe [13]，解决容量问题的同时可能让 PCIe、NVMe 和网络带宽主导 step 时间；它对低利用率实验可能比加卡更经济，对大规模生产训练则可能成为不可接受的同步瓶颈，应按每百万有效 token 成本、恢复时间和尾部抖动比较，而不是以“能启动”为成功。

3D mesh 与 SP、CP、EP 切分轴

本章的 3D 指 DP×TP×PP；在独立 mesh 的布局中，world size 是三者的乘积。逻辑坐标 \((d,p,t)\) 先映射到物理 rank：同一 \(d,p\) 下沿 \(t\) 做 TP 通信，同一 \(d,t\) 下沿 \(p\) 传递 stage 边界的激活与梯度，同一 \(p,t\) 下沿 \(d\) 同步梯度。图 9-4 以 DP=2、PP=2、TP=2 共 8 卡为例：通信最密的 TP 组放在同一 NVLink 域，PP 与 DP 跨节点。实际映射顺序由启动器保存，不能从 rank 号推测。DeepSpeed 的 3D 并行说明与 Megatron 的组合研究是这种分工的实例 [14][11]，但不能据此推断任一版本的任意组合都可用。

flowchart TB
    subgraph R0["DP 副本 d=0"]
        subgraph N0["节点 0 上的 stage p=0"]
            G0["GPU0<br/>t=0"] <-->|"TP all-reduce"| G1["GPU1<br/>t=1"]
        end
        subgraph N1["节点 1 上的 stage p=1"]
            G2["GPU2<br/>t=0"] <-->|"TP all-reduce"| G3["GPU3<br/>t=1"]
        end
        N0 -->|"PP 激活"| N1
    end
    subgraph R1["DP 副本 d=1"]
        subgraph N2["节点 2 上的 stage p=0"]
            G4["GPU4<br/>t=0"] <-->|"TP all-reduce"| G5["GPU5<br/>t=1"]
        end
        subgraph N3["节点 3 上的 stage p=1"]
            G6["GPU6<br/>t=0"] <-->|"TP all-reduce"| G7["GPU7<br/>t=1"]
        end
        N2 -->|"PP 激活"| N3
    end
    G0 -.->|"DP 梯度同步"| G4
    G3 -.->|"DP 梯度同步"| G7

图 9-4 DP=2、PP=2、TP=2 的 3D mesh 映射示例

Megatron 式 sequence parallel（SP）沿序列维拆分 LayerNorm、dropout 等层的激活，配合 TP 组内的 all-gather 与 reduce-scatter 降低激活冗余 [15]。context parallel（CP）把注意力的长序列分给多个 rank，仍要交换跨片的 KV 或等价信息；Ring Attention 展示了分块环式交换与计算重叠的路线 [16]。两者都不是“各算各的局部 attention 再拼接”，那样会漏掉跨片键值并改变 softmax 分母；位置编码、因果 mask、变长尾片和反向梯度都要与未分片参考结果核对。

MoE 用路由器把 token 分发到少数专家，激活参数少于总参数 [17][18]。专家并行（EP）带来 token dispatch、all-to-all 通信、专家容量和负载不均衡问题：路由把大部分 token 集中到少数专家时，热门专家成为瓶颈，其他 GPU 空闲。在丢弃溢出 token 的实现中，容量因子太小会丢 token，太大则浪费显存并增加通信。平台要记录每个专家的 token 数、溢出率、路由熵、all-to-all 时间和 rank 方差。EP 若划分已有的 DP 组，不能再在 world size 中独立乘一次；MoE checkpoint 还要保存专家布局和路由配置，否则恢复时并行映射可能不一致。

并行度搜索与恢复契约

并行度选择可以视为约束优化：先保证单层参数和激活放得进显存，再在目标拓扑上选 TP；根据层数和 bubble 选 PP；剩余 GPU 用 DP 扩展吞吐；MoE 再选 EP。每个候选组合都要用小规模真实 workload 测量 step time、通信比例、显存峰值和扩展效率。理论 FLOPs 只给出上界，不能替代实测。

并行配置一旦写入 checkpoint，就成为恢复契约的一部分。支持 reshard 的平台保存逻辑参数名、分片范围和布局版本，恢复时由转换器生成新的 shard；不支持时，调度器必须保证相同的 world size 和并行度。静默改变并行配置会让 optimizer state 与参数分片错位，是最危险的恢复错误之一（见 9.5 节）。

9.4 Kernel、数值稳定性与通信拓扑

本节分两部分：前三个小节讲单卡上的 kernel 与数值，后两个小节讲多卡之间的通信与拓扑。

Kernel 与数值：FlashAttention 与 online softmax

第8章已说明 FlashAttention 用 IO-aware tiling 减少 attention 的 HBM 读写并保持精确计算 [19]，这里补上分块计算为何仍然精确。对一个查询行，记第 \(j\) 个键的分数为 \(s_j=q\cdot k_j/\sqrt{d}\)（已含缩放），输出为 \(o=\sum_j e^{s_j}v_j\big/\sum_j e^{s_j}\)。分块计算时，对已处理的键块保存行最大值 \(m\)、指数和 \(l\) 与未归一化加权值和 \(u\)；新块到达时：

\[ m’=\max\big(m,\max_j s_j\big),\quad l’=e^{m-m’}l+\sum_j e^{s_j-m’},\quad u’=e^{m-m’}u+\sum_j e^{s_j-m’}v_j \]

全部块处理完后返回 \(u/l\)。最大值变化时，旧的 \(l\) 和 \(u\) 都要重缩放，不能直接拼接各块已经归一化的概率。训练的反向传播也不保存 \(N\times N\) 的概率矩阵：前向只保存输出和每行的 logsumexp \(L=m+\log l\)，反向时按块重算分数，并用 \(p_j=e^{s_j-L}\) 恢复概率 [19]。初始化要用“尚无有效键”的分支处理，避免负无穷减负无穷；全被 mask 的查询行按契约报错或返回约定值，不能产生伪均匀分布。

FlashAttention 减少的是 HBM 中间读写，标准全注意力的计算量仍是序列长度的二次阶；数学目标一致也不表示浮点逐位相同。FlashAttention-2 进一步改进工作划分和并行 [20]，收益依形状、硬件与 mask 支持而变。接受新 kernel 前，应对照高精度参考，覆盖极值、短行与长行、尾块和梯度，并验证端到端 step、显存峰值和不同 GPU 架构。

Kernel 与数值：融合、编译与 Roofline

优化应遵循“基线、假设、变更、测量、回滚”的链路：先用 profiler 找热点，再决定融合、重排、编译或量化。kernel benchmark 提速不代表训练提速，瓶颈可能转移到通信或数据。融合通常减少 launch 和中间 HBM 读写，却可能增加寄存器压力、spill（寄存器溢出：寄存器不够时变量被放到较慢的 local memory）、共享内存占用和同步，降低 occupancy（占用率：每个 SM 上活跃 warp 数与硬件上限之比），甚至破坏成熟库 kernel 的 tile 或 Tensor Core 路径。回退时先固定形状、dtype、预热、计时同步与数据，再比较寄存器、spill、occupancy、访存合并和 kernel 时间；缩小融合范围也应是候选方案。性能结果必须与模型版本、输入 shape、CUDA、driver、编译器和环境变量绑定。

Nsight Compute 的 Roofline 用算术强度 \(I\)（FLOPs/字节）解释 kernel 瓶颈 [21]，粗略上界为 \(\text{Perf}\le\min(P_{\text{peak}},,B\cdot I)\)，其中 \(B\) 为对应访存层的带宽；计数器须对应所用精度、访存层和真实指令。SM 和 DRAM 利用率都低时，原因也可能是 launch、同步、CPU 供给、小 grid 或依赖链，不能简单二分为“计算受限”或“显存受限”。应先看时间线判断是空闲还是核内低效，再改 batch、分块或融合验证假设，并同时报告 kernel 级和端到端收益。

编译工具处在不同抽象层（见下表）[22][23][24][25][26]。图级优化做等价变换、常量折叠、死代码消除、布局协调与融合，算子级安排 tiling、循环、线程与存储层级；局部最优布局可能让相邻算子多出转置。动态图可以捕获局部静态 IR 并做 shape 特化，但图断裂、数据依赖分支和新形状会触发回退或重编译，应记录编译时间、缓存命中和长尾形状成本。浮点重排按明确误差验收，一次导出成功不能证明端到端更快。注意此处的 Triton 是编译器项目，与同名推理服务框架无关；TensorRT 面向推理部署，相关内容见第10章。

Kernel 与数值：混合精度、激活重算与可复现

不同低精度格式需要不同的数值保护。FP16 动态范围窄，小梯度容易下溢，通常需要 loss scaling：先放大 loss 再反向，更新前除回去，遇到溢出就跳过该步并调小缩放因子 [27]。BF16 的指数位与 FP32 相同，通常不需要 loss scaling，但尾数更短，累加误差更大。FP8 的范围和精度都更窄，需要为每个张量维护缩放因子（per-tensor scaling），并在 E4M3、E5M2 两种格式之间按用途选择（前者精度较高，后者范围较大，常用于梯度）[28]；较新的格式与实现还让一小块元素共享一个缩放因子（block scaling），以容纳张量内部的数值跨度。master weights 与 optimizer moments 通常保持 FP32，这正是 9.3 节显存账本中 12 字节的来源；归一化、softmax 和输出层是否保留高精度要按数值证据决定，不能把 dtype 当作一个全局开关。训练系统需要监控 loss spike、梯度范数、溢出与下溢次数、NaN、Inf 和异常 rank。

出现 NaN 或 loss spike 时，自动重试同一个 batch 通常没有意义。平台应保存触发 step 的输入摘要、参数统计、梯度范数、精度配置和 kernel 版本，然后暂停或回滚到最近的健康 checkpoint。PaLM 在训练最大模型时遇到约 20 次 loss spike，做法是从 spike 开始前约 100 步的 checkpoint 重启，并跳过约 200–500 个数据 batch，之后同一位置不再出现 spike；作者的实验表明 spike 来自特定 batch 与特定参数状态的组合，而非单纯的坏数据 [7]。排查还要考虑 SDC（silent data corruption，静默数据损坏：硬件算错但不报错），它表现为单个 rank 的梯度范数或 loss 异常，可以通过对比 rank 统计和在其他节点上重放来区分。异常检测要与 checkpoint 保留策略绑定，至少保留最后一个已验证的健康点，避免坏状态覆盖所有可恢复版本。

激活重算（activation recomputation，PyTorch 中称 activation checkpointing）在前向中不保存全部中间激活，反向时重新计算，用计算换显存。PyTorch 2.9 文档说明了重算时 RNG 状态的保存方式与设备类型限制 [29]；重算时必须恢复相同的随机状态，否则 dropout 会改变梯度，参数已被 FSDP 释放时还要再次 all-gather。平台应记录重算粒度、额外 FLOPs、显存峰值和 step time：粒度过粗峰值仍高，过细则增加 kernel 和调度开销，最佳粒度随 sequence length 变化。恢复与性能报告要保存完整的运行时开关，而不是一个布尔值。

分布式低精度训练中，硬件、归约顺序、kernel、通信算法和随机数都会影响结果的最后几位。job spec 应明确复现目标：位级复现可能限制并行与性能；统计复现要求 loss 与主要评估指标在容差内；语义复现要求能力和安全指标不发生不可接受的变化。硬件不同时应多次重复实验并报告均值和方差，既不把微小差异当故障，也不用随机性解释明显的 loss 跳变。

通信与拓扑：集合原语与字节账本

NCCL 2.32 文档把上述四种都列为原生集合操作（All-to-All 对应 ncclAlltoAll），并要求所有 rank 以相同的 count 和 datatype 调用，否则可能挂起、崩溃或损坏数据 [10]；All-to-All 也可以在 group 中组合 ncclSend 与 ncclRecv 实现，变长 split 常用这种写法 [30]。算法与原语并不一一绑定，NCCL 会按 NVLink、PCIe、InfiniBand 和网卡拓扑选择路径。

以 ring all-reduce 为例（图 9-5），设 \(D\) 个 rank，每 rank 持有完整张量 \(G\) 字节且均匀分块。它由一次 reduce-scatter 和一次 all-gather 组成，单独执行 reduce-scatter 或 all-gather 时每 rank 发送 \((D-1)G/D\)（\(G\) 为完整张量大小），all-reduce 总计发送 \(2(D-1)G/D\)。两阶段各 \(D-1\) 轮，粗略时间模型为：

\[ T_{\text{AR}}\approx 2(D-1),\alpha+\frac{2(D-1)}{D}\cdot\frac{G}{\beta} \]

其中 \(\alpha\) 为每轮启动延迟，\(\beta\) 为有效链路带宽；\(D=1\) 时通信为零。这是 ring 的教学账本，不是所有 NCCL 算法的预测器。用 nccl-tests 实测时，algbw 定义为数据量除以时间；all-reduce 的 busbw 为 \(\text{algbw}\times 2(D-1)/D\)，all-gather 与 reduce-scatter 为 \(\text{algbw}\times(D-1)/D\)（数据量取完整张量）；busbw 可以直接与硬件链路带宽 \(\beta\) 比较，而不受 rank 数影响 [31]。

flowchart LR
    subgraph RS["阶段一 reduce-scatter 共 D-1 轮"]
        A0["rank0"] -->|"发送 G/D"| A1["rank1"]
        A1 -->|"发送 G/D"| A2["rank2"]
        A2 -->|"发送 G/D"| A3["rank3"]
        A3 -->|"发送 G/D"| A0
    end
    RS --> M["每个 rank 持有<br/>一个已归约分片"]
    M --> AG
    subgraph AG["阶段二 all-gather 共 D-1 轮"]
        B0["rank0"] -->|"转发分片"| B1["rank1"]
        B1 -->|"转发分片"| B2["rank2"]
        B2 -->|"转发分片"| B3["rank3"]
        B3 -->|"转发分片"| B0
    end
    AG --> R["所有 rank 得到<br/>完整归约结果"]

图 9-5 ring all-reduce：reduce-scatter 加 all-gather（D=4）

每种并行策略都可以建立同样的字节账本：DP 数梯度同步，TP 与 FSDP 数每层 collective 次数和大小，PP 数 stage 边界的激活与梯度，EP 按实际 token 去向计算发送矩阵。账本按 sequence length、micro-batch、hidden size、并行度和 dtype 计算，再用实测带宽与延迟估算下界。若一层的计算时间小于一次 collective 的延迟，扩大并行度不会有收益；反之，大矩阵乘法可以把通信隐藏在计算中。重叠能隐藏等待，却不会消除字节和 buffer。理论账本与 profile 不一致时，重点查 padding、bucket、参数预取、梯度累积，以及 collective 是否被意外串行化或重复执行。

通信与拓扑：重叠、亲和与拓扑快照

通信与计算重叠需要独立 stream、合理的梯度 bucket、正确的依赖和足够大的计算块。bucket 太小会产生大量 collective 和 launch，太大则要等很久才开始同步；stream 依赖设置错误时，表面上有两个 stream，实际仍串行。性能报告应分别列出 kernel 时间、可重叠通信、不可重叠通信和同步等待。通信时间上升时，要区分带宽不足、延迟主导、消息过小、最慢 rank、网络拥塞和同步顺序错误；单机 microbenchmark 只说明局部能力，必须用真实 batch 验证它能否解释 step 时间。跨节点 TP 比同机 TP 敏感得多，通信无法隐藏时，减小并行度可能比扩大集群更快。

多 GPU 节点常有多个 CPU socket、PCIe root complex 和网卡。数据 worker、pinned memory、GPU 和网卡绑定不当，会让 host 到 device 拷贝经过远端 NUMA 节点，吞吐下降且抖动增加。启动器应根据拓扑生成 CPU、GPU 和 NIC 亲和性并记录映射，不能依赖容器默认的 CPU 集合。拓扑也是版本化环境的一部分：换一批节点、升级 BIOS、改变网卡固件或调整 MIG（Multi-Instance GPU，把一张 GPU 切成若干硬件隔离的实例）都可能改变通信路径。平台应保存拓扑快照、NCCL 环境变量、通信算法和日志摘要，集群变更后重新测量集合通信 [10]；扩展曲线突然下降时，拓扑快照往往比训练代码更能解释原因。

9.5 Checkpoint 与恢复协议

Checkpoint 的完整状态与推理制品

可继续训练的 checkpoint 通常包含模型参数、master weights、optimizer moments、学习率调度器、gradient scaler、随机数状态、数据游标、训练配置、并行拓扑、tokenizer、数据 manifest、代码版本和评估结果。若在 optimizer step 边界保存且没有未提交的梯度累积，梯度不必持久化；若在累积中途保存，则要包含梯度与累积进度。对分片训练，文件名不是状态语义，必须用 manifest 描述逻辑参数、shard 范围、dtype、shape 和校验和。

只有权重加模型配置的制品可以用于推理，但不能保证继续训练等价。训练 checkpoint 的目标是继续优化，推理制品的目标是快速加载和稳定服务，后者通常只含参数、tokenizer、模板、量化和运行时配置。两者应使用不同的目录、权限和生命周期，通过发布 manifest 关联；直接把训练目录挂给 serving，既暴露不必要的状态，也可能让线上读到未完成的版本。转换与发布门禁见 9.8 节。

一致快照与完整性发布协议

checkpoint 的发布沿用 9.2 节快照的“先写数据、后写提交标记”。各 rank 先写带 job_id、step 和版本号的临时 shard，计算大小与校验和；协调者确认全部 shard 到齐、元数据完整、抽样读取成功后，才写提交标记。提交标记包含 world size、TP、PP、DP、EP、dtype、模型 schema、数据 manifest hash、tokenizer hash 和 global step。恢复程序只读取已提交版本，中途退出留下的临时目录异步清理，不会被误认为最新状态。

异步 checkpoint 让训练在保存期间继续计算，但必须先得到一致快照：若后台线程读取正在变化的 optimizer state，得到的可能是跨 step 的混合状态。PyTorch DCP（Distributed Checkpoint，分布式 checkpoint 模块）的文档把 staging（暂存：把状态复制到不受后续更新影响的缓冲，默认为 CPU 内存）的目标描述为生成 training-safe 的表示，staging 完成后对模块数据的更新不应反映到被保存的状态中；AsyncSaveResponse 分别用 staging_completion 与 upload_completion 两个 Future 表示本地拷贝完成与保存完成，自定义 stager 若不自动同步，需要由调用者在合适时机同步 [32]。因此“设备拷贝完成”不等于“持久化完成”，持有一个 Future 也不等于保存已提交。图 9-6 是本书在此基础上设计的完整发布协议，其中提交标记、发现指针和 CAS（compare-and-swap：仅当指针当前值等于预期旧值时才更新）都不是 DCP 默认保证的行为。

sequenceDiagram
    participant T as 训练进程
    participant S as staging 缓冲
    participant W as 后台写入
    participant O as 对象存储
    participant C as 协调者
    T->>S: t0 在 step k 边界对齐模型 优化器 游标
    S-->>T: t1 staging 完成 允许继续更新
    T->>T: t2 训练 step k+1 继续
    S->>W: 只读冻结快照
    W->>O: 写入 step k 的各分片
    W->>C: t3 上报分片清单与校验和
    C->>O: 校验全部分片与元数据
    C->>O: t4 写入不可变提交记录
    C->>C: CAS 更新发现指针
    Note over T,C: t1 前故障用旧点 t2 至 t3 故障残片不可见

图 9-6 异步 checkpoint 的完整性发布时序

各阶段的故障处理不同：t1 之前发生故障，继续使用旧的已提交点；t2、t3 期间宕机，残片不能被“扫描最新目录”的逻辑误选；t4 之后协调者丢失回执，要按 checkpoint id 查询已有提交，而不能另写一个快照覆盖。对象存储里的提交记录、数据库中的指针与各 rank 文件不是天然的一个事务：发布端要定义唯一的 checkpoint id 和条件写入，用 CAS 推进发现指针，读取端再次核验。这个完成标记协议也不是数据库意义上的两阶段提交，不能借用术语承诺跨系统原子性。

保存参与者因并行方式而异。普通 DDP 的模型权重可以由 rank0 写，但数据进度、RNG 等恢复状态仍要按协议从各 rank 收集；ZeRO 与 FSDP 的分片需要所有持有分片的参与者配合，不能默认 rank0 拥有完整状态。异步缓冲占用 CPU 或 GPU 内存，存储变慢时应限制在途快照数、延后新的保存或回退为同步保存，不能无限堆积。恢复后执行小 batch forward、loss 合理性检查、参数统计和数据可读性检查；校验和只能证明字节完整，恢复演练还要核对 step、参数、optimizer 和游标的语义对应。

保存频率、故障分类与弹性恢复

保存越频繁，故障后丢失的工作越少，但 I/O 和同步开销越高。若故障在两次保存之间均匀发生，平均丢失约半个保存间隔的工作；在故障近似服从泊松过程、保存开销远小于平均故障间隔的条件下，Young 与 Daly 的一阶近似给出最优保存间隔：

\[ \tau^{*}\approx\sqrt{2,\delta,M} \]

其中 \(\delta\) 是每次保存阻塞训练的时间，\(M\) 是整个作业的平均故障间隔 [33][34]。集群越大 \(M\) 越小，最优间隔随之缩短；异步保存降低的是暴露给训练的 \(\delta\)，但也让最后可用快照变旧，应按完整快照时间线计量。还要区分三类 checkpoint：可恢复点追求快速重启，评估点需要质量报告，发布点需要转换、签名和兼容性检查，不能用发布制品替代高频恢复点。

常见故障包括 GPU Xid（NVIDIA 驱动在内核日志中记录 GPU 错误时使用的错误编号）、节点重启、网络分区、NCCL hang、对象存储限流、文件系统不可写、容器驱逐、OOM、NaN 和数据 shard 损坏。单卡故障可能需要替换节点并重建 communicator；存储抖动可以退避重试；NaN 应停止并恢复健康点；rank 卡死需要 watchdog 和全局超时。不同故障要有不同的 runbook，不能把“自动重启”当作统一方案。SRE 的错误预算思想可以帮助决定何时继续重试、何时停止作业转人工处理 [35]。

弹性恢复可以等待原节点、替换节点并保持 world size、缩小 world size 继续，或回滚后重新分配。改变 world size 可能改变 global batch、学习率、数据顺序和 optimizer 行为，因此恢复策略要显式化，报告中记录丢失步数、重算 token、恢复耗时和最终质量差异。从 64 卡迁移到 128 卡或更换 GPU 型号时，支持迁移的格式把逻辑参数与物理 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，它们决定是否自动重试、是否计入实验失败、是否需要人工审批。

9.6 容量、调度与多租户成本

通用的 GPU 资源调度、配额与隔离机制见第8章 8.5 节，本节只讲训练作业特有的约束：gang 与拓扑、恢复兼容性、成本归因，以及后训练的资源配比。

Gang scheduling、故障域与调度接口

分布式训练需要一组 GPU 同时可用，部分分配往往只会让 job 长期 pending。调度器要识别 gang，按节点、GPU、NVLink、网络和本地数据做拓扑感知；大 job 需要反碎片化，小 job 可以填充空洞；训练、推理、评估和开发应有不同资源池与优先级。抢占时要考虑 checkpoint 是否已经提交，不能在不可恢复的阶段直接杀死作业。

如图 9-7 所示，训练作业向调度器声明的不只是 GPU 数量，还包括 GPU 类型、拓扑与互联、CPU、内存、网络、临时盘、gang 约束、优先级、可抢占性、预计时长和来自 checkpoint 的恢复约束；调度器返回 allocation、rank manifest、租约和故障域。作业启动后若发现拓扑不满足通信要求，应拒绝运行并释放资源，而不是勉强开始。调度器还要给出可解释的 pending 原因：用户看到“排队中”无法决策，看到“等待 16 张同型号 GPU 且需要同一 NVLink 域”才能取舍，平台也能据此发现容量规划问题。

flowchart LR
    J["job spec<br/>资源与拓扑需求"] --> Q["配额与预算检查"]
    K["checkpoint 恢复约束<br/>world size TP PP 架构"] --> S
    Q --> S["gang 调度器<br/>拓扑感知"]
    P["资源池<br/>训练 推理 评估 开发"] --> S
    S -->|"满足"| A["allocation<br/>rank manifest 租约 故障域"]
    S -->|"不满足"| R["pending 原因<br/>资源 拓扑 配额 健康"]
    A --> W["训练 worker"]
    W --> C["成本事件<br/>有效训练 重算 等待"]
    C --> Q

图 9-7 训练作业、配额、调度器与成本归因的关系

配额、成本与动态预算

配额应同时按 GPU 数、GPU 小时、显存、优先级和项目预算表达；一个团队长时间占用少量高端 GPU，可能比另一个团队使用更多低端 GPU 更昂贵。成本系统要分开记录预约、实际使用、空闲等待、通信等待、恢复重算、评估和 checkpoint，按有效 token 和成功实验归因，才能比较不同团队的真实效率。

启动前应估算 token、step、GPU 小时、checkpoint 次数、评估次数和重试余量。扩展效率沿用第8章 8.3 节的定义，以可运行的最小规模 \(N_0\) 作基准，因为大模型往往放不下单卡：

\[ E(N)=\frac{X(N)/N}{X(N_0)/N_0} \]

其中 \(X(N)\) 是 \(N\) 张 GPU 上的 loss token/s。\(E(N)\) 随规模快速下降时，继续扩大集群往往不如优化数据、kernel 或并行策略划算。平台应把扩展曲线作为门禁，同时记录通信比例、数据等待、峰值显存和节点故障恢复；Megatron-LM 与 PaLM 的经验表明，规模越大，系统效率和故障管理越是模型交付的一部分 [1][11][7]。

预算也不能只在提交时检查。失败重试、恢复重算、评估、checkpoint 和数据重处理都会在运行中增加成本，控制面应实时累计 GPU 小时、有效 token、存储请求、网络流量和失败次数，接近预算时提醒或暂停；用户可选“质量优先”“时间优先”或“成本上限”，平台据此调整评估频率、checkpoint 频率和资源池。只完成计划 token 20% 的实验不能与完整实验直接比较；超预算被强制停止的作业要保存最后健康 checkpoint、最终 loss 和未完成原因。

多租户隔离、数据凭证与资源清理

数据访问控制要同时覆盖控制面和数据面。控制面在创建 job 时校验项目、用途、数据 license、地域和保留期限；数据面在 worker 获取 shard 时发放短期、最小范围的凭证，只能访问具体 manifest 列出的 shard，不能列出整个 bucket，也不能写回原始路径。数据处理 worker 的输出写入独立路径，checkpoint 目录与原始数据隔离；对象存储、节点缓存和本地临时目录的权限保持一致，任务结束后回收凭证并清理缓存。调试抽样需要临时授权。

训练日志常含样本文本、异常 token 和模型输出，必须按数据等级处理：默认只记录 hash、长度、语言和错误类型，完整文本只在授权的诊断任务中短暂保存。把 prompt 或样本直接作为 metric label 更危险，会造成高基数、泄露和成本膨胀。观测字段应有允许列表、脱敏器和保留策略；OpenTelemetry 与 Prometheus 提供统一的指标和追踪基础，但记录什么仍是平台策略 [36][37]。

作业失败后，常见残留有 Kubernetes Pod、NCCL 进程、共享内存、pinned memory、对象存储临时目录、租约、GPU reservation 和告警。终止流程依次是发送取消事件、等待 worker 上报 checkpoint 或停止原因、清理通信组、释放分配、关闭数据流、删除临时文件、写最终状态，并设超时和人工兜底。回收必须幂等：重复清理不能删除其他 job 的路径、释放错误的 GPU 或覆盖成功的最终状态。临时目录名包含不可猜测的 run_id，清理器按 manifest 校验归属而不是使用宽泛通配符；监测 reservation 与实际 Pod 的差异可以及时发现泄漏 [37]。

后训练与 RLVR 的资源配比

预训练以稳定的大 batch 和长时间运行换取吞吐，其扩展曲线来自计算密集、拓扑规整的矩阵运算，即便如此也受 \(E(N)\) 衰减约束。监督微调和偏好优化的 batch 更小、序列长度更不稳定，生成、奖励模型和验证器会改变 GPU 与 CPU 的比例，因此不能套用预训练的扩展曲线。以 RLVR（reinforcement learning with verifiable rewards，可验证奖励强化学习：奖励来自答案比对、单元测试等可程序化验证的结果）为例，每个 prompt 要并行生成多个候选再执行 verifier；若只给训练 worker 配 GPU，CPU verifier、队列和网络会成为隐性瓶颈。

设每个 prompt 生成 \(G\) 个候选，提示长 \(T_{in}\)，每个候选平均输出 \(T_o\) 个 token。一组的成本可以拆成三项：

\[ C_{\text{gen}}=c_p T_{in}+G,c_d T_o,\qquad C_{\text{upd}}=G,(T_{in}+T_o),(c_{\pi}+c_{\text{ref}}),\qquad C_{\text{ver}}=G,c_v \]

\(C_{\text{gen}}\) 是生成成本：同一 prompt 的 \(G\) 个候选通过 prefix cache 共享一次 prefill，所以提示部分只计一次（不共享时为 \(G,c_pT_{in}\)）；prefill 单价 \(c_p\) 与 decode 单价 \(c_d\) 不同，decode 通常受显存带宽限制，单 token 更贵。\(C_{\text{upd}}\) 是策略模型的前向加反向（单价 \(c_{\pi}\)）与参考模型前向（\(c_{\text{ref}}\)，仅在使用 KL 约束时存在）。\(C_{\text{ver}}\) 是验证成本，\(c_v\) 为每个候选验证一次的代价。在组内归一化优势的算法中，全对或全错的组优势为零、不产生梯度，通常被过滤；设保留比例为 \(a\)，则每个有效样本的成本约为：

\[ C_{\text{eff}}=\frac{C_{\text{gen}}+C_{\text{ver}}+a,C_{\text{upd}}}{a,G} \]

这个式子的用处在于暴露几个比例。第一，生成成本随 \(G\) 线性增长，而策略更新的收益通常低于线性，组大小存在收益递减点；\(G\) 太小又会提高全对或全错的概率，降低 \(a\)。第二，若不区分 prefill 与 decode、也不共享 prefill，每个候选的生成成本退化为 \((T_{in}+T_o),c_g\)，与 \(c_v\) 比较即可判断瓶颈在哪一侧；比较时两者必须用同一计价单位（例如费用）。若 \(c_v\) 很小（只做答案比对），瓶颈在生成侧；若验证要跑测试、执行代码或调用另一个模型，\(c_v\) 可能接近甚至超过生成成本，此时给训练 worker 加卡不会提高有效样本吞吐。第三，做容量规划时不要把 CPU 时间折算成等价 token：GPU 生成与训练、CPU 或沙箱验证、外部服务调用分属不同资源池，应分列各自的用量、排队时间和失败重试，分别判断哪个池先饱和。平台应把生成服务、验证服务和数据服务纳入同一个 job graph 统一记录版本，并按“每个被接受样本的成本”而不是“主模型 forward 吞吐”报告效率。

9.7 观测、排障与故障演练

指标、事件与追踪

训练指标要按 rank、节点、数据桶和并行维度聚合，同时保留最大值和方差，避免平均值掩盖一个慢 rank。下表列出最小集合，其中 MFU（model FLOPs utilization，实际达到的模型 FLOPs/s 与硬件峰值之比，定义见第8章）用于跨配置比较计算效率。

GPU busy 只表示设备上有 kernel 在执行，不代表高效：大量小 kernel、低 occupancy、访存瓶颈、同步等待和无效 padding 都可能让 busy 很高而有效吞吐很低；反之，通信或数据等待期间利用率下降，也可能是正常的阶段性行为。指标若缺少 run、step、rank、node、模型和数据版本等关联字段就无法定位，字段过多又会推高监控成本，因此 run、step 这类高基数事实放在 trace 和日志里，metrics 只使用受控的聚合维度。

Dapper 的分布式追踪思想适合把训练控制面和数据面关联起来 [38]。训练 trace 默认不记录完整样本，而记录 manifest、shard、batch、step、request id、错误类型和 hash；配合 OpenTelemetry 的上下文传播和 Prometheus 的时间序列告警 [36][37]，平台能从“GPU 利用率下降”追到“某类 shard 解压变慢”或“某个 rank 通信抖动”。除时间序列外还需要结构化事件，例如 JOB_ACCEPTED、ALLOCATION_READY、WORKER_STARTED、CHECKPOINT_COMMITTED、NODE_LOST、RECOVERY_STARTED 和 RUN_FINISHED，每个事件携带 run_id、spec hash、global step、world size 和 checkpoint 版本。事件系统要处理重复、乱序和延迟：网络恢复后到达的旧完成事件，要靠单调 step、版本号和状态机拒绝。dashboard 只是从事件和指标派生的视图，不是事实来源。

Step 时间线与尾部

为了让性能分析落地，可以把每个 step 的时间线固定为：数据游标推进、CPU 预取、pinned memory 与 H2D 拷贝、forward、激活保存或重算、backward、梯度 bucket ready、collective、optimizer update、日志和 checkpoint，每个区间按 global step、rank 和 node 关联。吞吐下降时，就能直接回答是数据迟到、kernel 变慢、通信不重叠，还是保存引起暂停。时间线也能区分不同优化的作用：packing 主要影响有效 token 和数据阶段，FlashAttention 影响 attention kernel 与显存，FSDP 影响 all-gather、reduce-scatter 与显存峰值，checkpoint 影响 I/O 与同步。性能报告应给出端到端收益和每个区间的变化。

平均 step time 不能代表整个训练。checkpoint、数据刷新、节点抖动、编译或对象存储限流都会产生慢 step，长尾决定 wall-clock 完成时间和 GPU 成本，因此要记录 step 时间的分位数、最大值、慢 step 原因及其是否集中在某些节点、数据桶或并行阶段，只用平均值算 ETA 会让容量计划失真。尾部还来自 straggler rank：坏磁盘、远端 NUMA、GPU 降频或网络重传都会让整个 collective 等待一个 rank。运行时应报告每个 rank 的数据准备、forward、backward、通信和 checkpoint 时间，并对慢 rank 告警；自动摘除慢节点会触发恢复和通信重建，应先比较继续运行与重启的预计成本。

NCCL timeout：先找未到达的 rank

PyTorch 分布式文档提供了通信组与辅助诊断机制，NCCL 也按拓扑、运行时与网络分层提供排障入口 [39][40]。诊断从最早的异常开始，而不是只读最后超时的节点：关联所有 rank 的 run、step、collective 序号、通信组、shape、dtype 与进入和退出时间。某个 rank 先发生 OOM、CUDA 错误、进程退出或卡在数据读取时，其他 rank 只是在等它，最后报出的才是 timeout。图 9-8 给出分流路径。

flowchart TB
    S["NCCL timeout 告警"] --> A["对齐所有 rank 的<br/>collective 序号与进入时间"]
    A --> B{"是否有 rank<br/>未进入该 collective"}
    B -->|"是"| C["查该 rank 最早错误<br/>OOM CUDA 错误 退出 数据等待"]
    C --> C1["数据侧<br/>shard 解压 NUMA CPU"]
    C --> C2["设备侧<br/>Xid 与 GPU 健康"]
    B -->|"否"| D{"各 rank 调用参数<br/>是否一致"}
    D -->|"否"| E["查条件分支 尾批<br/>异常处理 通信组创建"]
    D -->|"是"| F["查链路<br/>NIC RDMA 拓扑 独立通信复现"]
    C1 --> G["隔离坏输入或节点<br/>从一致 checkpoint 重启"]
    C2 --> G
    E --> G
    F --> G
    G --> H["验证游标与 loss token 连续"]

图 9-8 NCCL timeout 的排障分流

同一 collective 序号的调用或张量不一致时，检查条件分支、尾批、异常处理和通信组创建；某个 rank 在进入 collective 前长期等待数据时，检查其 shard、解压、NUMA 和 CPU；顺序一致但特定链路反复变慢时，再查 Xid、NIC 与 RDMA、拓扑，并用独立通信测试复现。用于监测的 barrier 也有后端与版本限制，不应插进每个生产 step 制造新的等待。例如 rank3 读到坏 shard 却没有上报异常，其他 rank 都停在梯度同步：正确做法是保留 rank3 的数据等待记录与最早错误，隔离坏输入，从一致的 checkpoint 重启，并确认之后的 loss token 和游标连续。只把 timeout 调大修不好数据源；只有证明合法操作确实需要更长时间时才调整超时，不能用更长的等待掩盖死锁。

故障注入、人工接管与升级基线

平台至少要演练五类注入：杀死一个 rank、关闭一台节点、阻断集合通信、让对象存储返回超时、损坏一个 checkpoint shard。每次记录检测时间、作业状态、用户可见影响、自动恢复结果、重算 token、恢复后的 loss 和资源释放。若系统只在单进程退出时能恢复，而一个 rank 卡死会让其他进程永久等待，它就不具备生产级弹性。高峰期的队列、配额和发布动作会改变恢复路径，演练可以按隔离资源池小规模演练、生产影子作业验证告警、可控真实节点维护三步推进，并按 SRE 错误预算设定停止条件 [35]。

自动恢复的范围要有边界。短暂的存储超时可以自动退避；连续 NCCL hang、NaN、checkpoint 校验失败和数据权限错误应暂停并通知负责人。超过最大重试次数后，系统保留现场、停止覆盖健康 checkpoint，并生成包含 job spec、拓扑、最后健康 step 和错误 trace 的诊断包。负责人可以选择回滚到某个 checkpoint、跳过坏 shard、更换资源池或终止作业，每个动作都产生审计事件，不能为了“先跑起来”直接修改共享存储或删除现场。复盘时区分代码、数据、平台和容量规划缺陷，把修复加入下一次验收。

驱动、CUDA、NCCL、内核、固件和基础镜像的升级都可能改变性能与数值结果。升级前保存固定 workload 的基线（吞吐、通信、显存、loss 曲线、异常率和恢复），升级后用相同 job spec 在等价节点上比较；只比速度不比 loss 和恢复，可能把数值变化误认为性能提升。升级要分批可回退：先用影子作业验证，再迁移低优先级实验，最后处理生产训练；节点标签标识硬件、driver、NCCL 和固件版本，调度器据此选择兼容节点，并保留旧节点池或旧镜像，给正在运行的长任务留出迁移路径。

9.8 训练平台验收与交付

阶梯验证与验收矩阵

交付前由控制面生成配置摘要并随 run 保存，包括模型和代码 hash、tokenizer、数据 manifest、配方、global batch、sequence length、dtype、并行度、节点类型、网络拓扑、checkpoint 频率、恢复策略、预算和告警阈值，避免用户填写一份配置、启动器又隐式覆盖成另一份。验证按阶梯推进：第一阶在单 GPU 上验证数据、loss、checkpoint 和恢复；第二阶在单节点上验证并行组、通信和显存；第三阶在多节点上验证扩展曲线、数据供给、故障替换和 reshard；第四阶才运行目标规模。各阶使用相同的模型和数据语义，只改变资源规模，出问题时才能判断是算法、单机 kernel、跨机网络还是调度器导致。

验收矩阵包含五类测试：数据正确性（token 统计、样本边界、loss mask、manifest、重复率）、性能扩展（单机、单节点、多节点扩展曲线）、故障恢复（中断、节点替换、checkpoint 损坏、数据不可读）、数值稳定（loss 连续、梯度无异常、不同精度在容差内）和安全治理（权限、审计、成本、数据删除）。每项测试固定模型 hash、数据 manifest、镜像、硬件、驱动、并行度和 global batch，保存原始指标与失败样本，而不只写“通过”：性能提高但 loss 曲线异常不能接受，恢复成功却重复消费了大量数据也不能只算功能通过。上线后，驱动、CUDA、网络、文件系统、数据格式、模型代码或并行配置的每次变化都触发一轮基线对比。

性能报告的最小字段

不同团队常用不同口径，导致“吞吐提升”无法复核。下表列出可比较报告的最小字段。报告还必须说明是否包含编译、warmup、验证、checkpoint 和失败重试；原始 trace、汇总 JSON 和可读表格一起保存，报告 hash 写入 run metadata。只有一个数字而没有 workload 与环境的结果，不应作为平台基线。

制品转换与发布门禁

转换器要处理参数命名、分片布局、dtype、权重共享、词表、位置编码和模型 schema，转换后比较参数总量、shape、均值方差、hash 和小 batch 输出；量化模型还要比较校准集质量、最大误差、生成稳定性和特殊 token。转换脚本固定版本并产生日志，不能依赖某台开发机上的临时命令。评估是 checkpoint 生命周期的一部分：训练平台提交 checkpoint hash、模型 schema、tokenizer、数据 manifest 和安全标签，评估平台返回任务 id、指标、样本报告和门禁结论；评估失败、超时或结果不完整时，checkpoint 不能被自动标记为发布候选。改变 tokenizer、模板、数据切分、采样温度或最大输出长度后，指标不能与旧版本直接横向比较。评估证据如何产生见第11章。

发布门禁的顺序如图 9-9 所示：制品完整性、模型加载、tokenizer 与模板兼容、固定 probe 输出、离线质量、显存峰值、冷启动时间和目标硬件性能，同时检查功能、质量、性能和安全。一个模型可能 loss 更低，却因 tokenizer 变化导致线上输入边界不同；量化可能节省显存，却让结构化输出失败；新 kernel 可能提高吞吐，却在最大长度下产生 NaN。通过门禁的制品要签名并登记来源，注册表记录训练 run、数据 manifest、checkpoint、转换器版本、量化配置、engine build、评估结果和审批者；回滚时按旧 manifest 恢复完整制品，而不是只把 image tag 改回旧值。训练侧 checkpoint 仓库与推理侧模型仓库接口可以不同，但必须共享不可变 hash。之后的灰度与发布流程见第12章。

flowchart LR
    A["已提交 checkpoint"] --> B["转换与对比<br/>shape hash 小 batch 输出"]
    B --> C{"完整性与加载"}
    C -->|"通过"| D{"tokenizer 与模板兼容"}
    D -->|"通过"| E{"probe 与离线质量<br/>第11章证据"}
    E -->|"通过"| F{"显存 冷启动<br/>目标硬件性能"}
    F -->|"通过"| G["签名并登记<br/>不可变 hash"]
    G --> H["进入推理注册与灰度<br/>第12章"]
    C -->|"失败"| X["阻断并保留诊断"]
    D -->|"失败"| X
    E -->|"失败或不完整"| X
    F -->|"失败"| X

图 9-9 训练制品的发布门禁

数据合同、可审计性与目标规模检查表

训练平台向数据平台要的不是一个路径，而是一份数据合同：数据版本、schema、授权用途、split、采样权重、tokenizer、分片大小、可用区域、删除策略和质量阈值；数据平台返回 manifest、统计、访问凭证和血缘（机制见 9.2 节）。合同变更要版本化，训练平台按 manifest hash 决定能否复用缓存和 checkpoint。合同也要覆盖部分可用：区域对象存储故障时可以切换到镜像副本，但要记录路径和复制版本；某个 shard 损坏时可以隔离跳过，但要报告有效 token 损失。数据平台不能为了吞吐静默返回旧版本，训练平台也不能为了继续运行绕过授权。治理规则同样应机器可读：数据 license 不允许某种用途时，控制面在分配 GPU 前拒绝 job；checkpoint 使用了已撤回的数据版本时，注册表阻止发布。

一次训练结果至少要能回答四个问题：用了什么数据（manifest、授权、统计），执行了什么计算（job spec、代码 hash、并行拓扑、镜像），经历了哪些故障（事件、trace、重试与恢复记录），为什么可以发布（评估报告、门禁与审批）。可审计不等于保存全部原始内容：审计记录可以用带权限控制的 hash（敏感的低熵字段不能依赖裸 hash 匿名化）、版本号、长度、来源和时间，敏感文本单独受控；关键事件写入追加式日志，修正通过新事件表达，而不是覆盖旧记录。trace 关联和上下文传播能连接不同服务，数据最小化仍是平台的责任 [38][36]。

进入目标规模训练前，负责人可以按下表逐项确认。最后一列说明缺失时问题最早在哪里暴露，这也是要把检查前置到小规模验证的原因。

9.9 本章小结

训练平台把一个长时间运行、状态复杂的分布式任务变成可解释的交付流程，图 9-10 把本章的主要概念串成一条链。数据侧，不可变快照、提交标记、血缘和 schema 兼容规则固定了“训练了什么”；数据游标和 loss token 口径固定了“实际消费了多少”，DAG 只重试失败分区。计算侧，batch 口径、TP 与 PP 的通信和 bubble 结论、ZeRO 与 FSDP 的显存通信账本、3D mesh 与 SP/CP/EP 切分轴，决定了副本与分片的布局；字节账本与 nccl-tests 的 busbw 换算，把通信等待变成可以对账的数字；FlashAttention、混合精度缩放和激活重算的正确性，都要对照高精度参考验收。

状态侧，checkpoint 只有在一致快照完成、全部分片校验、提交记录写入并通过 CAS 推进发现指针之后才算存在，保存间隔可以用 \(\sqrt{2\delta M}\) 估计，恢复兼容性作为调度约束提前传给调度器。运营侧，gang 调度、配额与成本归因、多租户凭证、RLVR 的分资源池配比，以及从最早异常开始的 NCCL 排障，共同保证吞吐与可恢复性同时成立。训练平台对外交付的是通过转换、兼容和质量门禁的模型制品，附带绑定数据与配置的评估记录，以及沿第8章资源账本关联的 trace 与成本事实；推理侧如何消费这些制品见第10章，评估证据见第11章，发布运营见第12章。

flowchart LR
    subgraph D["数据"]
        D1["不可变快照<br/>提交标记 血缘"] --> D2["数据游标<br/>loss token 口径"]
    end
    subgraph P["计算"]
        P1["3D mesh 与<br/>SP CP EP"] --> P2["显存与<br/>通信账本"]
        P2 --> P3["kernel 与<br/>数值验收"]
    end
    subgraph S["状态"]
        S1["一致快照"] --> S2["提交记录<br/>CAS 指针"]
    end
    subgraph O["运营"]
        O1["gang 调度<br/>恢复约束"] --> O2["观测与排障"]
        O2 --> O3["发布门禁"]
    end
    D2 --> P1
    P3 --> S1
    S2 --> O1
    S2 --> O3
    O3 --> M["模型制品<br/>与评估记录"]

图 9-10 本章概念图：从数据快照到可发布制品

9.10 参考资料

1. Shoeybi, M., et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv, 2019. 核验日期：2026-10-17。

2. Rajbhandari, S., et al. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. SC, 2020. 核验日期：2026-10-17。

3. Zhao, Y., et al. PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel. arXiv v2, 2023. 核验日期：2026-10-17。

4. Moritz, P., et al. Ray: A Distributed Framework for Emerging AI Applications. OSDI, 2018. 核验日期：2026-10-17。

5. Kubernetes Authors. Schedule GPUs. Kubernetes 在线文档. 核验日期：2026-10-17。

6. Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. 核验日期：2026-10-17。

7. Chowdhery, A., et al. PaLM: Scaling Language Modeling with Pathways. arXiv, 2022. 核验日期：2026-11-05。

8. Grattafiori, A., et al. The Llama 3 Herd of Models. arXiv v3, 2024. 核验日期：2026-10-17。

9. Zaharia, M., et al. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. NSDI, 2012. 核验日期：2026-10-17。

10. NVIDIA. NCCL User Guide: Collective Operations. NCCL 2.32.3 文档. 核验日期：2026-11-05。

11. Narayanan, D., et al. Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM. SC, 2021. 核验日期：2026-10-17。

12. PyTorch Contributors. FullyShardedDataParallel. PyTorch 2.9 文档. 核验日期：2026-11-05。

13. Rajbhandari, S., et al. ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning. SC, 2021. 核验日期：2026-10-17。

14. DeepSpeed Team. Training a Trillion Parameters with Pipeline Parallelism. DeepSpeed Blog, 2020. 核验日期：2026-10-17。

15. Korthikanti, V., et al. Reducing Activation Recomputation in Large Transformer Models. arXiv, 2022. 核验日期：2026-10-17。

16. Liu, H., Zaharia, M., Abbeel, P. Ring Attention with Blockwise Transformers for Near-Infinite Context. arXiv, 2023. 核验日期：2026-10-17。

17. Lepikhin, D., et al. GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding. arXiv, 2020. 核验日期：2026-10-17。

18. Fedus, W., et al. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. JMLR, 2022. 核验日期：2026-10-17。

19. Dao, T., et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS, 2022. 核验日期：2026-10-17。

20. Dao, T. FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning. ICLR, 2024. 核验日期：2026-10-17。

21. NVIDIA. Nsight Compute Profiling Guide. NVIDIA 在线文档. 核验日期：2026-10-17。

22. NVIDIA. CUDA Programming Guide: Writing SIMT Kernels. NVIDIA 在线文档, 2026. 核验日期：2026-10-17。

23. Triton Contributors. Triton Language Introduction. Triton 在线文档. 核验日期：2026-10-18。

24. Apache TVM Community. Design and Architecture. Apache TVM 在线文档. 核验日期：2026-10-18。

25. OpenXLA Authors. XLA. OpenXLA 在线文档. 核验日期：2026-10-18。

26. NVIDIA. TensorRT Architecture Overview. NVIDIA 在线文档. 核验日期：2026-10-18。

27. Micikevicius, P., et al. Mixed Precision Training. ICLR, 2018. 核验日期：2026-11-05。

28. Micikevicius, P., et al. FP8 Formats for Deep Learning. arXiv, 2022. 核验日期：2026-11-05。

29. PyTorch Contributors. torch.utils.checkpoint. PyTorch 2.9 文档. 核验日期：2026-10-17。

30. NVIDIA. NCCL User Guide: Point-to-point Communication. NCCL 2.32.3 文档. 核验日期：2026-11-05。

31. NVIDIA. NCCL Tests: Performance Reported by NCCL Tests. GitHub, 2026. 核验日期：2026-11-05。

32. PyTorch Contributors. Distributed Checkpoint - torch.distributed.checkpoint. PyTorch 2.9 文档. 核验日期：2026-11-05。

33. Young, J. W. A First Order Approximation to the Optimum Checkpoint Interval. Communications of the ACM, 17(9), 1974. 核验日期：2026-11-05。

34. Daly, J. T. A Higher Order Estimate of the Optimum Checkpoint Interval for Restart Dumps. Future Generation Computer Systems, 22(3), 2006. 核验日期：2026-11-05。

35. Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. 核验日期：2026-10-17。

36. OpenTelemetry Authors. Signals. OpenTelemetry 在线文档. 核验日期：2026-10-17。

37. Prometheus Authors. Prometheus Overview. Prometheus 在线文档. 核验日期：2026-10-17。

38. Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report, 2010. 核验日期：2026-10-17。

39. PyTorch Contributors. Distributed Communication Package - torch.distributed. PyTorch 2.9 文档. 核验日期：2026-10-17。

40. NVIDIA. NCCL User Guide: Troubleshooting. NCCL 2.32.3 文档. 核验日期：2026-10-17。

第10章 推理服务：架构组成、领域模型与推理执行过程

版本与证据说明：源码层面的描述以 vLLM 主干提交 77d2790（2026-11-03，晚于 v0.33.0rc3）为准，后续版本可能变化，版本差异集中在 10.10 节；容量与显存数字是可复算的教学推演，阈值和验收表是本书建议，不是实测结果。多模态、pooling、非 CUDA 平台只在必要处提及；SGLang、TensorRT-LLM 等对比对象依据其论文、官方文档与配置源码，不比较吞吐。

训练完成并不意味着模型已经可以被用户使用。训练输出是一个需要转换、装载、调度和观测的制品；在线推理则是一个同时面对突发流量、长尾上下文、流式连接、动态 batch、显存上限和版本发布的分布式服务。本章以开源推理引擎 vLLM 的 V1 架构为主线，按“架构组成 → 核心对象 → 启动过程 → 推理执行”的顺序，解释一条请求如何从 HTTP 进入、在 GPU 上被逐步计算、再以 token 流的形式返回，然后讨论 vLLM 留给平台的多租户钩子、可靠性语义与验收方法，最后与其他主流引擎做比较 [1][2]。

10.1 推理服务要解决的问题

从一次 forward 到生产级 serving

把模型放进一个 HTTP 服务、每来一个请求调用一次 generate，在单用户下可以工作，在多用户下几乎立刻失效：生成长度不同的请求无法对齐成一个 batch，短请求要等长请求结束；每个请求都为最大长度预留显存，显存很快被“预留但未使用”的空间占满；一个超长输入会让所有正在生成的请求停顿。Orca、PagedAttention、Sarathi-Serve 和 DistServe 等工作说明，LLM serving 的突破来自把模型执行拆成可调度的资源和状态，而不是把模型包成一次 RPC [3][4][5][6]。vLLM 是这条路线上最有代表性的开源实现：它把分页 KV 管理与 iteration-level 的连续批处理结合起来，并在 V1 架构中把协议处理、调度和执行拆到不同进程。

三个矛盾与 vLLM 的回答

第8章 8.4 节已经介绍了 prefill 与 decode、continuous batching、PagedAttention、prefix cache 和 chunked prefill 的原理，以及 TTFT（首 token 延迟）、TPOT（每输出 token 延迟）和 goodput（满足 SLO 即服务等级目标的成功请求数除以墙钟时间）的定义，这里只看 vLLM 如何把这些原理落到代码里。推理服务的设计围绕三个矛盾展开：显存上，KV cache 随“并发 × 上下文长度”增长，而输出会有多长事先并不知道；延迟上，计算密集的 prefill 与带宽受限的 decode 混在同一 batch 中会互相干扰；公平上，交互请求关心尾延迟，离线任务关心吞吐，长请求和短请求争夺同一份 GPU。实现层面还有第四个约束：Python 调度与输入准备的 CPU 开销会拖慢小 batch 的 decode。如图 10-1 所示，vLLM 对每个矛盾和约束都给出了具体机制，同时把它解决不了的部分留给平台控制面。

flowchart LR
    subgraph C["推理服务的矛盾"]
        C1["显存<br/>KV 随并发与长度增长"]
        C2["延迟<br/>prefill 干扰 decode"]
        C3["CPU 开销<br/>Python 调度拖慢小 batch"]
        C4["公平<br/>长短请求与多租户争用"]
    end
    subgraph V["vLLM 引擎内机制"]
        V1["分页 KV block<br/>启动时定容"]
        V2["KV 不足时抢占并重算"]
        V3["每步 token 预算<br/>chunked prefill"]
        V4["分进程 + 异步调度"]
        V5["FCFS 或 priority<br/>实例级准入"]
    end
    P["平台控制面<br/>配额、路由、发布、计费"]
    C1 --> V1
    C1 --> V2
    C2 --> V3
    C3 --> V4
    C4 --> V5
    C4 --> P
    V5 -.->|"租户与预算超出引擎视野"| P
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-1 推理服务的矛盾与 vLLM 的对应机制：引擎负责单实例内的资源与调度，租户和预算问题交给平台

推理服务在平台中通常与其他组件分层组合：网关负责鉴权、限流和协议，路由器负责模型版本、租户和区域，serving engine（本章的 vLLM）负责执行与 cache，模型仓库负责制品，Kubernetes 等调度器负责 GPU，观测系统负责指标、日志与 trace。组合的代价是接口和故障边界增多，所以请求清单、模型清单、错误码和状态事件必须事先约定，否则替换任意一个组件都会改变行为。推理平台要回答的交付问题也随之分散到各层：制品能否加载、容量能否满足 SLO、状态能否回收、调度是否公平、成本能否解释，本章重点回答其中属于引擎的部分。

论文术语与代码术语

论文与代码用的词不同。下表给出本章用到的对照，后文直接使用代码术语。

本章要点

vLLM V1 是一个以“每步 token 预算”为统一调度抽象、以分页 KV block 为资源账本、用进程边界隔离 CPU 开销与 GPU 执行的推理引擎。读完本章应能回答五个问题：调度器为什么没有“prefill 阶段”，只让已计算 token 数追赶总 token 数；KV 不足时为什么是抢占重算而不是 OOM；prefix cache 的块哈希链如何决定命中与驱逐；为什么启动过程本质上是一次显存测量，block 总数因卡、因版本而异；以及 vLLM 只负责“单实例内把请求算好”，鉴权、配额、多实例路由、灰度和计费为什么必须由平台补齐。

与贯穿案例的对应：ALR（本书 Agent 部分贯穿使用的业务诊断 Agent 案例） 运行在推理服务之上，但推理服务不理解它的业务语义。本章的请求与制品、运行观测、调度动作、流式状态和 SLO 验收，分别对应 ALR 的任务输入与资源版本、Evidence、受控动作、Run 状态和诊断交付；这些对应只用于帮助定位，本章机制的适用范围限于推理 Infra。

10.2 分层架构与组件

为什么要分进程

vLLM 官方架构文档把 vllm serve 的进程分为四类：API server、EngineCore、GPU worker，以及数据并行（DP）时才有的 DP coordinator [2]。分进程的核心理由是 Python 的 CPU 开销。在 V0 架构中，HTTP 处理、tokenize、调度、detokenize 和 GPU 前向挤在同一个进程里，彼此争用 GIL；GPU 越快，CPU 越成为瓶颈。V1 把它们拆开：API server 只做协议、tokenize 和 detokenize，可以多开以横向扩展；EngineCore 只跑调度循环这个性能关键的内循环，指标统计等簿记工作被推到前端；worker 只执行调度器下发的计划。

worker 是否是独立进程取决于执行器后端。总并行规模大于 1 时默认使用多进程后端 MultiprocExecutor，每张 GPU 一个 worker 进程；单卡时默认使用 UniProcExecutor，worker 直接在 EngineCore 进程内执行，没有额外进程。架构文档给出的进程数公式是 API server 数 + DP 大小 + GPU 数（DP 大于 1 时再加 1 个 coordinator），例如 -tp=4 时为 6 个进程；它按“每 GPU 一个 worker”计数，描述的是多卡部署。

这套设计围绕一份随长度增长的 GPU 状态（KV cache）建立资源管理，也带来了几项固定的取舍：抢占只能重算，长请求被抢占一次可能浪费大量计算；prefix cache 只能命中满 block，命中粒度受 block 大小限制；KV 容量在启动时确定，运行时不能按需扩张；CUDA Graph 只覆盖一组离散的 batch 大小，其余要补齐或走 eager。理解这些取舍，是正确设置 max_num_seqs、max_num_batched_tokens、gpu_memory_utilization 和 block 大小的前提，后文会逐一展开。

服务层、引擎层与执行层

服务层运行 FastAPI 应用和一个 AsyncLLM 对象。OpenAI 兼容路由由 OpenAIServingChat 等类处理，它们构造采样参数、调用 AsyncLLM.generate，再把增量结果包装成 SSE 事件。AsyncLLM 持有四个部件：Renderer（tokenizer 与 chat template）、InputProcessor（校验参数、补默认值，生成发给引擎的 EngineCoreRequest）、OutputProcessor（为每个请求维护 RequestState，做增量 detokenize、stop string 检查并计算延迟指标）和 EngineCoreClient（ZMQ 客户端）。tokenize 放在前端，意味着 tokenizer 必须与引擎加载的模型严格匹配；stop string 也在前端检测，命中后前端要反过来通知引擎中止请求。

引擎层的主体是 EngineCore 进程中的 busy loop：从输入队列取出新请求和中止请求，执行一步，把结果放进输出队列。两个 I/O 线程负责 ZMQ 收发与 msgpack 编解码，busy loop 本身不碰网络。一步包括：Scheduler.schedule() 产生执行计划 SchedulerOutput，交给执行器做前向，在 GPU 执行期间计算结构化输出的语法 bitmask，让 worker 采样，最后由 Scheduler.update_from_output 写回新 token、检查停止条件、释放结束请求的资源。所有 KV block 的分配与回收决策都在 EngineCore 中做出，worker 只按调度器给出的 block 编号读写显存，这是 vLLM 最重要的所有权边界。

执行层有三个对象：Executor 运行在 EngineCore 进程中，负责启动和管理 worker，多进程时用共享内存消息队列向所有 worker 广播 RPC；Worker 负责设备初始化、分布式通信组和显存测量；GPUModelRunner 负责单卡执行，维护 worker 侧请求状态与 block table，准备输入张量和 attention 元数据，执行前向与采样。在 77d2790 中 GPUModelRunner 有两个实现：Model Runner V2 在特性支持时默认启用，否则回退到 V1 实现，也可以用环境变量 VLLM_USE_V2_MODEL_RUNNER 强制指定。V2 把持久状态与每步输入解耦，以异步执行为前提去掉 CPU 同步点，用 Triton kernel 在 GPU 上准备输入元数据，并显式管理 CUDA Graph [7]。两者对调度器暴露的接口相同，所以调度层的分析对两者都成立，10.5 节按 V2 描述执行路径。

flowchart TB
    subgraph L1["服务层：API Server 进程"]
        H["HTTP 路由"] --> RD["Renderer<br/>chat template 与 tokenize"]
        RD --> IPR["InputProcessor"]
        OPR["OutputProcessor<br/>detokenize、stop string、指标"] --> SSE["SSE 流"]
    end
    subgraph L2["引擎层：EngineCore 进程"]
        IN["输入线程"] --> BL["busy loop"]
        BL --> SC["Scheduler"]
        SC <--> KV["KVCacheManager 与 BlockPool"]
        BL --> OUT["输出线程"]
        EX["Executor"]
        BL --> EX
    end
    subgraph L3["执行层：Worker<br/>多卡时每 GPU 一个进程，单卡默认在 EngineCore 内"]
        MR2["GPUModelRunner"] --> FW["前向与 logits"]
        FW --> SP["Sampler 或 RejectionSampler"]
    end
    IPR -->|"EngineCoreRequest，ZMQ"| IN
    OUT -->|"EngineCoreOutputs"| OPR
    EX -->|"SchedulerOutput，共享内存广播"| MR2
    SP -->|"ModelRunnerOutput，仅一个 rank 回传"| BL
    OPR -.->|"stop string 命中时 abort"| IN
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-2 三层之间的信息流：请求向下流动，token 向上流动；stop string 是唯一由前端发起的反向控制

如图 10-2 所示，EngineCore 向所有张量并行（TP）rank 广播同一份 SchedulerOutput，各 rank 执行相同的前向，但只有最后一个流水线（PP）stage 的 TP rank 0 回传 ModelRunnerOutput。

组件与分工

调度器决定谁在这一步运行、各算多少 token；KV 管理器回答能不能为这些 token 准备好存储。两者的接口很窄：调度器对新请求先调用 get_computed_blocks 查询 prefix 命中，再调用 allocate_slots 为要计算的新 token 申请 block，失败时返回 None，请求结束时调用 free。调度器不知道 block 的物理布局，KV 管理器不知道请求优先级，也不做抢占决策。KV 管理器内部的 KVCacheCoordinator 处理“一个模型有多种层”的情况：全注意力层与滑动窗口层并存，或 Transformer 层与 Mamba 层混合时，每种层组成一个 KV cache group，各有一个单类型管理器负责 block 规则，所有 group 共享同一个 BlockPool。

显存与容量

推理节点的显存由权重、KV cache、前向激活与临时张量、kernel 与 CUDA Graph 工作区、通信 buffer 组成。vLLM 用 gpu_memory_utilization 表达“本实例能用多少显存”，它是单实例上限，不感知同卡的其他进程。这个参数的默认值随版本变化：v0.11.0 为 0.9，v0.32.0 为 0.92；在 77d2790 中未设置时，启用 extensible KV cache 取 1.0，否则取 0.92（见 10.10 节）。KV cache 的大小不是直接配置的，而是“上限 − 权重 − 测得的峰值激活 − 其他非 KV 占用”的余数，按 block 大小折算成 block 数（见 10.4 节）；也可以用 kv_cache_memory_bytes 直接指定 KV 字节数，此时忽略 gpu_memory_utilization。

vLLM 把显存问题转化为 block 数问题：KV 池在启动时就已分配好（或地址已保留），运行时不再向 CUDA 申请 KV 显存，只在 BlockPool 里分配和回收 block。block 不够时调度器不会触发 OOM，而是不接纳新请求，或抢占正在运行的请求（见 10.5 节）。这是一种内建的准入，代价是抢占带来的重算而不是进程崩溃。租户并发、最大上下文和预算的准入仍要在网关做，因为引擎不知道租户和预算。

做容量初估时，设到达率为 \(\lambda\)，平均输入、输出 token 为 \(P\)、\(D\)，单 GPU 在给定负载下的 prefill、decode 有效吞吐为 \(R_p\)、\(R_d\)，利用率预算为 \(u\)。若两阶段共享同一串行计算预算，需要把工作相加；PD 分离时两池分别估算：

\[ N_{\text{shared}} \approx \frac{1}{u}\left(\frac{\lambda P}{R_p}+\frac{\lambda D}{R_d}\right),\qquad N_{\text{prefill}} \ge \frac{\lambda P}{R_p,u_p},\qquad N_{\text{decode}} \ge \frac{\lambda D}{R_d,u_d} \]

对两个瓶颈取最大值只是下界，不是混部所需的总 GPU 数；混部的干扰必须压测。这里的吞吐不是硬件峰值，必须绑定模型、长度与 batch 分布；输出长度长尾明显时用平均 \(D\) 会低估 decode 并发。在此基础上还要叠加 KV 容量、网络传输、故障余量、发布余量和突发余量，同一份剩余容量不能同时承诺给节点故障、扩容和滚动发布 [8]。

案例：Qwen3-8B 的显存账本

下面做一次可复算的教学估计。前提是：单卡显存按 24 GiB 计；gpu_memory_utilization 取 77d2790 在未启用 extensible KV cache 时的默认值 0.92；激活、logits、通信与 CUDA Graph 工作区人为给定一个 2 GiB 的联合上界；block 大小 16 个 token；不考虑 prefix 共享。模型参数来自 Qwen 官方模型卡与 config.json：约 8.2B 参数（safetensors 元数据为 8,190,735,360 个 BF16 参数，tie_word_embeddings 为 false，嵌入层与输出层分别计入），36 层，32 个 query head、8 个 KV head，head_dim 为 128 [9]。在 GQA（分组查询注意力，多个 query head 共享一组 KV head）下，KV 账本只用 KV head 数，不能代入 32 个 query head。

权重按每参数 2 字节为 16,381,470,720 字节，约 16.38 GB，即 15.26 GiB。KV 每 token 为 \(2\times36\times8\times128\times2=147{,}456\) 字节，第一个 2 代表 K 与 V，最后的 2 是 BF16 字节数；一个 block 在 36 层上合计 \(16\times147{,}456=2{,}359{,}296\) 字节（2.25 MiB）。一条 8192 token 的序列（输入与已生成输出都计入）占 1.125 GiB，即 512 个 block。

因此候选并发上限为 4。它不代表四并发能满足 TPOT，也不保证真实工作区低于 2 GiB。若把利用率换成旧版本默认的 0.9，KV 预算降到约 4.34 GiB、1976 个 block，候选上限变为 3，这正是默认值版本差异会直接改变容量结论的例子。在 vLLM 中第五条请求不会导致 OOM：它要么留在等待队列，要么在调度时触发抢占。INT4 权重名义上约 4.1 GB，但还有 scale、zero point 和反量化工作区，且权重降精度不会自动缩小 BF16 的 KV。多卡时按各 rank 实际持有的权重和 KV 分片建账，不能把所有项机械地除以 TP 数。

部署形态：TP、PP、DP、EP 与 PD 分离

模型放得进单卡时，多副本最简单，故障也容易隔离；放不进时需要张量并行（TP）、流水线并行（PP）或专家并行（EP），各策略的原理与通信量见第9章 9.3 节。vLLM 在初始化分布式环境时按 DP × PP × PCP × TP 的布局为每个 rank 建立 TP、DCP、PCP、PP、DP、EP 等通信组，其中 DCP（decode context parallel）和 PCP（prefill context parallel）分别在 decode 和 prefill 阶段沿序列维度切分上下文与 KV。

• TP：列切分的层不需要通信，行切分的层在输出上做 all-reduce，每个 Transformer 层大约两次。TP 适合同机高速互联；跨节点 TP 在低并发 decode 中会把通信延迟暴露在每个 token 上 [10]。
• PP：层被切成多个 stage，stage 之间传递中间张量；EngineCore 用 batch queue 让多个 batch 同时在途以填满流水线。
• DP：每个 DP rank 是一个独立的 EngineCore，有自己的调度器和 KV。非 MoE 模型的 DP rank 等同于多个副本，前端在内部负载均衡模式下按在途请求数和等待、运行请求数为引擎打分来分配请求。
• EP（MoE）：attention 按 DP 并行，专家分布在 DP × TP 组成的 EP 组上，token 通过 all-to-all 路由到专家。每层都要跨 DP rank 交换，所以所有 DP rank 必须同步步进，空闲 rank 执行 dummy batch，由 DP coordinator 协调。vLLM 还提供 DBO（Dual Batch Overlap），用两个微批重叠 MoE 的通信与计算。

PD 分离把 prefill 与 decode 放到不同实例，代价是 KV 传输、请求协调、故障重试和网络容量 [6]。vLLM 用 KV connector 抽象实现 PD 分离和 KV offload，接口分为调度器侧（有多少 token 可从外部加载、分配 block 后更新状态、请求结束时是否推迟释放）和 worker 侧（前向前后加载或保存 KV），注册的实现包括 NIXL、Mooncake、LMCache 和 CPU offload 等，执行细节见 10.5 节。另一种解耦是 MoE 的 attention 与 FFN 分离（AF 解耦），如 MegaScale-Infer 让 attention 节点与 expert 节点之间做 M2N（M 个发送端对 N 个接收端）通信 [11]，它改变的是每层模块的放置，不在本章主线内。图 10-3 对比了三种典型形态。

flowchart TB
    subgraph A["单实例 TP=2"]
        A1["API"] --> A2["EngineCore"]
        A2 --> A3["Worker 进程 GPU0"]
        A2 --> A4["Worker 进程 GPU1"]
        A3 <-->|"NCCL all-reduce"| A4
    end
    subgraph B["DP=2 × TP=2，MoE"]
        B1["API ×2"] --> B2["EngineCore DP0"]
        B1 --> B3["EngineCore DP1"]
        B2 --> B4["Worker ×2"]
        B3 --> B5["Worker ×2"]
        B6["DP Coordinator"] -.->|"统计与同步步进"| B2
        B6 -.-> B3
        B4 <-->|"EP all-to-all"| B5
    end
    subgraph C["PD 分离"]
        C0["代理或路由"] --> C1["Prefill 实例"]
        C0 --> C2["Decode 实例"]
        C1 -->|"KV connector，如 NIXL"| C2
    end
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-3 三种典型部署形态：TP 在实例内切分模型，DP 与 EP 横向扩展引擎，PD 分离把两个阶段放到不同实例

并行度越大不一定越快，必须结合拓扑、batch、序列长度和通信占比测量。故障域也随之变化：同一 TP group 中一张卡故障，整个 group 都不可用，发布和容量控制应以逻辑副本为单位。

10.3 KV cache 与领域对象

对象链：契约、状态与资源

一条请求在 vLLM 中会依次变成多种对象，每种对象只活在一个进程里。按时间顺序串起来，就是推理服务领域模型的主线，如图 10-4 所示。

flowchart LR
    A["HTTP 请求体<br/>messages 与参数"] -->|"Renderer"| B["EngineInput<br/>token ids 与 arrival_time"]
    B -->|"InputProcessor"| C["EngineCoreRequest<br/>跨进程消息"]
    C -->|"EngineCore"| D["Request<br/>调度状态"]
    D -->|"Scheduler.schedule"| E["SchedulerOutput<br/>一步的执行计划"]
    E -->|"GPUModelRunner"| F["InputBatch<br/>本步输入张量"]
    F -->|"前向与采样"| G["ModelRunnerOutput<br/>采样结果"]
    G -->|"update_from_output"| H["EngineCoreOutputs<br/>增量 token 与结束原因"]
    H -->|"OutputProcessor"| I["RequestOutput<br/>文本增量"]
    I -->|"OpenAIServingChat"| J["SSE chunk"]
    D -.->|"持有"| K["KVCacheBlock ×N"]
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-4 对象链：请求向下变换、结果向上变换；Request 是唯一跨越整个生命周期的调度对象

这些对象可以分成三类。契约对象回答“要做什么、按什么规则做”，如 VllmConfig、SamplingParams、EngineCoreRequest、SchedulerOutput，创建后基本不变；状态对象回答“做到哪一步了”，如 Request、worker 侧请求状态和前端的 RequestState，每步变化；资源对象回答“占用了什么”，如 KVCacheBlock、BlockPool 和 KV 张量，有引用计数，必须回收。三类对象出错的表现不同：契约错表现为行为与预期不符（例如模板不一致导致输出变化），状态错表现为卡住或重复（例如请求永远不结束），资源错表现为泄漏或越界（例如空闲 block 数持续下降）。区分它们是排障的第一步。

模型制品同样是契约对象。config.json 决定模型结构和 KV 规格，generation_config.json 提供采样默认值，tokenizer 配置中的 chat template 决定 prompt 如何渲染，所以改动模型目录中的任何一个文件都可能改变线上行为，而 vLLM 不会告诉你哪个文件变了。制品的版本、hash 与兼容矩阵由发布系统管理（见第12章 12.3 节），vLLM 只消费经过校验的目录。

请求对象与 token 追赶模型

EngineCoreRequest 是前端发给引擎的消息，一个按位置序列化的 msgspec.Struct，携带 request_id、prompt token、采样参数、到达时间、LoRA、cache_salt、priority、用于把输出路由回正确前端的 client_index，以及前端预先计算的 prompt 块哈希。request_id 会被改写为“外部 ID + 8 个随机字符”，以免同一外部 ID 重复提交时在引擎内冲突，日志与 trace 关联时要注意这一点。

Request 是 EngineCore 中一条请求的可变状态，由调度器持有和修改。理解 vLLM 调度，关键是它的几个计数字段：

调度的全部逻辑可以浓缩为一句话：每一步，让 num_computed_tokens 尽量追上 num_tokens_with_spec。新请求的 num_computed_tokens 从 prefix 命中长度起步；一次 prefill 可能分多步追完，这就是 chunked prefill；追上之后每步追一个新 token（decode），或一个新 token 加若干 draft token（投机解码）。num_computed_tokens 在调度完成时就被乐观推进，被拒绝的 draft 在拿到结果后回滚。请求按（priority, arrival_time, request_id）排序，priority 数值越小越优先。

SamplingParams 描述“怎么采样、什么时候停”：采样参数（temperature、top-p、top-k、惩罚项等）、停止条件（max_tokens、stop、stop_token_ids）、输出方式（n、logprobs、流式用的 DELTA 模式）和结构化输出约束。采样配置会改变 decode 路径：结构化输出需要语法引擎生成 token bitmask；n > 1 在前端展开为 n 个子请求。平台应把实际生效的采样配置记入 usage 与 trace。结构化输出只保证语法合法，不保证字段取值合法；vLLM 负责生成工具调用文本并用解析器提取参数，但它不执行工具，也不知道工具是否已经执行过。工具参数应先进入待执行状态，经过 schema、权限和参数范围校验后再提交，执行的幂等与审计由上层用独立的 operation id 保证。

KV 规格、block 与 BlockPool

KV 是可以从输入重算出来的中间状态，抢占时直接丢弃，重启后也不恢复，与业务层的“对话记忆”无关。每层 KV 的形状由 KVCacheSpec 描述：block 大小、KV head 数、head 维度和 dtype，子类对应全注意力、MLA（多头潜在注意力）、滑动窗口、Mamba 等层，每个子类给出一个 block 在该层占多少字节。启动时 EngineCore 把规格相同的层分到同一个 KV cache group，同一 group 的所有层共享一张 block table，一个 block 编号在每一层都对应一段显存。以 Qwen3-8B 为例，36 层全是全注意力，只有一个 group；每层每 token 的 KV 是 4096 字节，一个 16 token 的 block 在一层占 64 KiB，36 层合计 2.25 MiB，与 10.2 节的账本一致。

KVCacheBlock 是 block 的元数据对象，只记录编号、引用计数、块哈希（仅在被缓存时设置）以及在空闲队列中的前后指针。BlockPool 在启动时为每个编号创建一个对象，并持有空闲队列（支持 O(1) 从中间移除的双向链表）和哈希到 block 的映射。为了让 block table 保持只追加，vLLM 不对重复的缓存 block 去重，同一哈希可能对应多个 block。编号 0 的 null block 用来填充滑动窗口中已跳过的位置，不参与引用计数和缓存。

block 没有显式的状态枚举，但可以从引用计数和哈希推出四种状态：使用中且私有（引用计数为 1、无哈希，正在被写入的最后一个未满 block）；使用中且已缓存（满 block，可能被多个请求共享，只读）；空闲但可命中（引用计数为 0、有哈希，在空闲队列中，被复用前仍可被 prefix 命中）；空闲且干净（引用计数为 0、无哈希，优先被复用）。只有非 null、引用计数为 1 且没有哈希的 block 才可写。经典 PagedAttention 需要 copy-on-write，而 vLLM V1 只共享满 block、新 token 总写入请求自己的新 block，普通模型不需要 CoW；只有混合模型开启细粒度 prefix 命中、命中结束在缓存 block 中间时，才复制一份给请求私有。图 10-5 给出这些资源对象的关系。

classDiagram
    class KVCacheManager {
        get_computed_blocks(request)
        allocate_slots(request, num_new_tokens)
        free(request)
    }
    class KVCacheCoordinator {
        find_longest_cache_hit()
    }
    class SingleTypeKVCacheManager {
        req_to_blocks
    }
    class FullAttentionManager
    class SlidingWindowManager
    class MambaManager
    class BlockPool {
        blocks
        free_block_queue
        cached_block_hash_to_block
        null_block
        get_new_blocks(n)
        touch(blocks)
        free_blocks(blocks)
    }
    class KVCacheBlock {
        block_id
        ref_cnt
        block_hash
    }
    class FreeKVCacheBlockQueue {
        popleft()
        append()
        remove()
    }
    class KVCacheGroupSpec {
        layer_names
        kv_cache_spec
    }
    KVCacheManager *-- KVCacheCoordinator
    KVCacheCoordinator *-- BlockPool
    KVCacheCoordinator *-- "1..*" SingleTypeKVCacheManager
    SingleTypeKVCacheManager <|-- FullAttentionManager
    SingleTypeKVCacheManager <|-- SlidingWindowManager
    SingleTypeKVCacheManager <|-- MambaManager
    BlockPool *-- "num_blocks" KVCacheBlock
    BlockPool *-- FreeKVCacheBlockQueue
    SingleTypeKVCacheManager --> KVCacheGroupSpec

图 10-5 资源对象：每个 KV cache group 一个单类型管理器，所有 group 共享一个 BlockPool

Prefix cache：块哈希、命中与驱逐

vLLM 的 Automatic Prefix Caching 默认开启，规则如下 [12]：只有满 block 会被缓存和命中；每个 block 的哈希由父 block 哈希、本 block 的 token 和额外键共同计算，因此天然编码了完整前缀；额外键包括 LoRA 身份、与本 block 重叠的多模态输入标识、cache_salt（只加在首 block 上）和 prompt embedding 的哈希；默认哈希算法为 sha256；命中长度最多为 num_tokens − 1，最后一个 token 总要重算以得到采样所需的 logits。由于哈希是链式的，第 i 个 block 未命中意味着之后都不会命中，查询从头顺序进行到第一次未命中为止。

首 block 的父哈希来自一个种子，它决定了不同实例能否算出相同的哈希。在 77d2790 和 v0.32.0 中，未设置 PYTHONHASHSEED 时，sha256 等密码学哈希使用固定默认种子，因此不同进程对相同内容算出相同哈希，可以跨实例共享前缀；xxhash 等非密码学哈希仍使用进程级随机种子，以防攻击者离线构造碰撞；设置 PYTHONHASHSEED 则两种情况都以它为种子。v0.11.0 的行为不同：未设置 PYTHONHASHSEED 时一律使用随机种子，跨实例命中需要显式统一该变量。

vLLM 没有单独的驱逐线程，block 的生命周期由引用计数和空闲队列决定。请求释放 block 时引用计数减一，减到 0 的 block 回到空闲队列：已缓存的 block 追加到队尾，按 LRU 保留、仍可被命中；未缓存的 block 放到队首，优先复用以获得更好的显存局部性。请求按逆序释放自己的 block，尾部 block 先入队，于是比前缀更早被淘汰。分配新 block 时从队首取出，如果取出的 block 还带着旧哈希，此时才把它从哈希表中移除，驱逐是惰性的。命中的 block 若在空闲队列中，会被移出并把引用计数加一，多个共享前缀的请求引用同一组物理 block。引用计数大于 0 的 block 不在空闲队列中，所以驱逐不会影响正在执行的请求。

“命中 cache”在推理平台上至少有四种语义，不能共用一套指标和安全规则：

vLLM 的 APC 只属于第二层，收益集中在 prefill，不能据此承诺 decode 等比例加速。后两层在引擎之外由平台实现。GPTCache 是语义响应缓存的公开实现 [13]，但相似不等于等价：“我可以报销吗”与“我不可以报销吗”高度相似，答案却可能相反，因此应先按租户、授权范围和知识版本硬过滤，再在域内检索并逐项校验否定、条件和实体；撤权、删除、知识发布和模板升级都应触发失效事件，有副作用的操作不能因缓存命中而重新执行。

请求状态机

RequestStatus 是一个整数枚举，排在 PREEMPTED 之后的都算结束状态。等待类状态包括 WAITING、WAITING_FOR_STRUCTURED_OUTPUT_GRAMMAR（结构化输出的语法正在异步编译）、WAITING_FOR_REMOTE_KVS（正在从 PD 分离的 prefill 端或外部 cache 加载 KV）和 WAITING_FOR_STREAMING_REQ（可续写会话的一轮结束，等待下一段输入）；结束状态包括 FINISHED_STOPPED、FINISHED_LENGTH_CAPPED、FINISHED_ABORTED、FINISHED_IGNORED（prompt 超过长度上限，对外映射为 length）、FINISHED_ERROR 和 FINISHED_REPETITION。这组状态名依赖版本，v0.11.0 中语法等待状态叫 WAITING_FOR_FSM，也没有 ERROR、REPETITION 和流式续写状态（见 10.10 节）。主要迁移如图 10-6 所示。

stateDiagram-v2
    [*] --> WAITING : add_request
    [*] --> WAITING_FOR_GRAMMAR : 需要结构化输出
    WAITING_FOR_GRAMMAR --> WAITING : 语法编译完成
    WAITING_FOR_GRAMMAR --> FINISHED_ERROR : 编译失败
    WAITING --> WAITING_FOR_REMOTE_KVS : connector 异步加载
    WAITING_FOR_REMOTE_KVS --> WAITING : 加载完成
    WAITING --> RUNNING : 调度成功
    PREEMPTED --> RUNNING : 再次调度
    RUNNING --> PREEMPTED : KV 不足被抢占
    RUNNING --> FINISHED_STOPPED : EOS 或 stop token
    RUNNING --> FINISHED_LENGTH_CAPPED : 达到长度上限
    RUNNING --> FINISHED_REPETITION : 重复检测触发
    RUNNING --> FINISHED_ERROR : 语法拒绝 token
    WAITING --> FINISHED_ABORTED : 中止
    RUNNING --> FINISHED_ABORTED : 中止
    FINISHED_STOPPED --> [*] : 释放资源
    FINISHED_LENGTH_CAPPED --> [*]
    FINISHED_ABORTED --> [*]
    FINISHED_ERROR --> [*]
    FINISHED_REPETITION --> [*]

图 10-6 计算轴状态机（WAITING_FOR_GRAMMAR 即 WAITING_FOR_STRUCTURED_OUTPUT_GRAMMAR；省略了流式续写与 FINISHED_IGNORED）

迁移是幂等的：对已经结束的请求再次中止不会改变它的结束原因，已结束请求在途步骤的输出会被跳过。计算状态之外还有一条交付轴：连接中、STREAMING、已断开。STREAMING 与 RUNNING 可以同时成立，交付轴不在引擎中，而在 API server 与客户端之间。两轴叠加时，最危险的是“客户端已断开而请求仍在 RUNNING”：如果断开没有被及时感知（例如中间代理缓冲了连接），引擎会继续为没人接收的请求生成 token 并占用 KV。平台应监控断开时仍在运行的请求数和从断开到 abort 的延迟。

所有权与不变量

vLLM 的正确性很大程度上依赖“每种可变状态只有一个写者”：

最后一行看似例外：多个 API 进程共享一块准入计数内存。但它的单写者粒度是“槽位”：每个进程只写自己独占的一个缓存行，读者把所有槽位相加，因此既不需要进程间锁，也不会出现两个写者改同一个值；代价是并发更新时读到的总和只是各槽位的近似快照，适合做过载保护，不适合做精确配额。

由此可以列出几条可检验的不变量：非 null block 的引用计数为 0 当且仅当它在空闲队列中；只有满 block 被缓存，未经验证的 draft token 永远不会被缓存；prefix 命中长度最多为 num_tokens − 1；运行中请求数不超过 max_num_seqs，每步 token 总数不超过预算；只有 RUNNING 的请求能被抢占，抢占释放全部 block 并把 num_computed_tokens 清零；block table 只追加，被抢占后恢复的请求除外，它的 block 列表整体替换。

worker 侧用 block table 计算每个 token 的写入位置：

\[ \text{slot}=\text{block_table}[r,\lfloor p/B\rfloor]\times B + (p \bmod B) \]

其中 \(r\) 是请求所在行，\(p\) 是 token 位置，\(B\) 是 block 大小。一致性依赖两条规则：block table 只追加，worker 才能增量更新；释放与复用之间必须隔一个安全点，请求结束后它的 ID 随下一步 SchedulerOutput.finished_req_ids 通知 worker，异步调度下调度器还要等在途步骤结束才真正释放 block。Model Runner V2 还把 CPU 侧对 block table 的修改先暂存，在每步开始时统一应用到 GPU，避免 CPU 修改与 GPU 读取并发冲突 [7]。

10.4 启动过程

启动顺序与进程拓扑

vllm serve 先把命令行参数解析成引擎参数，再由 create_engine_config 组织成一棵配置树 VllmConfig，其下有 ModelConfig、CacheConfig、SchedulerConfig、ParallelConfig、CompilationConfig 等子配置。这一步不只是搬运参数，很多默认值在这里按环境推导：OpenAI 兼容服务的 max_num_seqs 和 max_num_batched_tokens 随显卡显存变化（显存不小于 160 GiB 时为 1024 和 16384，不小于 70 GiB 且不是 A100 时为 1024 和 8192，其余为 256 和 2048）；执行器后端在总并行规模大于 1 时取多进程，等于 1 时取进程内。很多字段的默认值是 None，到启动过程中才解析，所以读配置文件不足以知道实际生效值，要看启动日志或 /metrics 中的配置信息指标。

单 API server 形态的启动顺序如图 10-7 所示。API 进程先绑定 HTTP 端口（此时只 bind、不处理请求），再构造 AsyncLLM：依次创建 Renderer、InputProcessor、OutputProcessor，最后创建引擎客户端。客户端绑定用于收发请求的 ZMQ socket 和握手 socket，拉起 EngineCore 子进程并阻塞到它就绪。EngineCore 中的执行器按后端决定是否创建 worker 进程：MultiprocExecutor 建立共享内存广播队列，为每个 rank 启动一个 worker 进程并等待它们报告就绪；UniProcExecutor 直接在本进程内创建 worker。worker 加载权重后，EngineCore 依次完成显存探测、KV 定容、编译和图捕获，创建调度器，最后把就绪信息发回前端。前端收到后才构建应用、开始服务 HTTP。

sequenceDiagram
    autonumber
    participant API as API Server 进程
    participant EC as EngineCore 进程
    participant W as Worker 进程 ×2
    API->>API: 解析参数，构造 VllmConfig，bind HTTP 端口
    API->>API: 创建 Renderer、InputProcessor、OutputProcessor
    API->>EC: 绑定 ZMQ socket，启动 EngineCore 子进程并握手
    EC->>W: 创建共享内存广播队列，启动 worker
    W->>W: init_device：建立通信组，拍内存快照
    W->>W: load_model：加载并切分权重
    W-->>EC: READY
    EC->>W: get_kv_cache_spec 与 determine_available_memory
    EC->>EC: 折算 block 数，各 rank 取最小
    EC->>W: initialize_from_config：分配或保留 KV 张量
    EC->>W: compile_or_warm_up_model：编译与 CUDA Graph 捕获
    opt extensible KV cache
        EC->>W: extend_kv_cache：按捕获后实测空闲显存提交物理页
    end
    EC->>EC: 创建 StructuredOutputManager、Scheduler、batch queue
    EC->>API: EngineCoreReadyResponse
    API->>API: 写回 num_gpu_blocks、max_model_len 等，开始服务
    EC->>EC: 进入 busy loop

图 10-7 启动时序（单 API server、TP=2、多进程后端）：先 bind 端口和 socket，再拉起引擎；显存探测与编译在引擎内完成，就绪信息最后回传前端。TP=1 时 worker 的步骤都在 EngineCore 进程内执行

同一份配置在两个进程里各自演化。 KV block 总数、自动缩小后的 max_model_len、实际 block 大小等值只有在引擎完成显存探测后才能确定，引擎在就绪响应中把它们发回前端写回自己的配置，所以前端日志里的 KV 容量要等引擎就绪后才出现。

制品与模型加载

vLLM 可以从 Hugging Face Hub 或本地目录加载模型，并用 revision 固定版本，但它不负责制品的完整性门禁：它不知道权重是否通过了评估、tokenizer 是否与训练时一致、chat template 是否被改过。这些检查应由发布系统在启动前完成，再把经过校验的本地目录交给 vLLM [14][15]。

worker 的 init_device 顺序有讲究：先绑定 CUDA 设备，在拍内存快照之前初始化分布式环境、建立 TP 和 PP 等通信组，这样 NCCL 自己占用的显存会被计入“启动前已占用”，而不会被误算成模型占用；然后拍快照，按“总显存 × gpu_memory_utilization”向上取整得到本 worker 允许使用的显存。load_model 在名为 weights 的内存池中加载权重，TP 时每个 rank 只加载自己的切片，量化模型在这一步加载量化权重与 scale，LoRA 和草稿模型也在此加载。权重与 KV 分别放进不同的内存池，是为了支持后面的 sleep mode。

tokenizer 和 chat template 不在 worker 里，而在 API 进程里。tokenize 和 detokenize 消耗的是前端 CPU，不占用调度循环，前端成为瓶颈时可以多开 API server；但 vLLM 只按同一个模型路径分别加载 tokenizer 与权重，平台若把两者分开存放或分别升级，必须在制品清单层面保证版本一致。

显存探测与 KV 定容

模型加载完成后，EngineCore 先向各 worker 询问每层的 KV 规格，再让它们测量可用显存。worker 在 profiling 上下文中执行一次 profile_run：用最大 batch（max_num_batched_tokens 个 token）跑一次前向，测出非 KV 部分的峰值显存；torch.compile 的编译也在这次前向中触发。启用 CUDA Graph 时还要估算图捕获将占用的显存。于是：

\[ M_{\text{KV}} = M_{\text{requested}} - M_{\text{non-KV}} - M_{\text{cudagraph}} \]

其中非 KV 部分包括权重、profile 测得的激活峰值和启动前已有的非 torch 占用。EngineCore 收齐各 worker 的结果后按最小值对齐（调度器只有一份 block 账本），折算成 block 数；若显存装不下一条 max_model_len 长度的序列，可能自动缩小 max_model_len。block 大小默认 16，未显式指定时可被平台按 attention backend 的偏好调整；混合多种层的模型有多个 KV cache group，调度器的 block 大小取参与 prefix caching 的 group 中最小者。

接下来分配 KV 张量，77d2790 中有两种行为，如图 10-8 所示。预先分配是传统路径：按算出的 block 数一次性分配全部 KV 显存，再进入编译和图捕获，KV 的大小依赖 profile 阶段对 CUDA Graph 占用的估算。延后提交即 extensible KV cache，在 CUDA 和 ROCm 上配合 Model Runner V2 时默认启用：这一步只用设备虚拟内存保留地址范围，等编译和图捕获完成后，各 worker 实测剩余空闲显存并折算成 block 数，EngineCore 取所有 rank 的最小值，再让 worker 提交物理页。实现中还在实测峰值之外保留至少 1 GiB（ROCm 为 2 GiB）并随模型工作集放大的余量，源码注释记录了 GB200 上 8B 模型首个 prefill 需要比已分配峰值多 25% 以上空间的观测，可见 profile 峰值不是可以直接相减的精确值。延后提交解决的是“估算不准”，过去只能靠保守的 gpu_memory_utilization 吸收偏差；它依赖驱动的虚拟内存管理能力，与部分 KV connector 不兼容，在显式指定 KV 字节数或 block 数、未使用 V2 runner 时不启用。截至 v0.33.0rc3，这一机制尚未进入发布版。

flowchart TD
    A["init_device：建立通信组后拍内存快照<br/>requested = 总显存 × gpu_memory_utilization"] --> B["load_model：权重进入 weights 池"]
    B --> C["get_kv_cache_spec：每层的 KV 规格"]
    C --> D{"指定了 kv_cache_memory_bytes<br/>或命中 startup plan？"}
    D -- 是 --> E["仍跑一次 profile_run 以触发编译<br/>可用 KV = 指定或记录值"]
    D -- 否 --> F["profile_run：最大 batch 前向<br/>测非 KV 峰值，估算 CUDA Graph 占用"]
    F --> G["可用 KV = requested − 非 KV − 图估算"]
    E --> H["折算 block 数，各 rank 取最小<br/>必要时缩小 max_model_len"]
    G --> H
    H --> I{"extensible KV cache？"}
    I -- 否 --> J["一次性分配 KV 张量"]
    I -- 是 --> K["只保留虚拟地址范围"]
    J --> L["编译各尺寸，捕获 CUDA Graph"]
    K --> M["编译各尺寸，捕获 CUDA Graph"]
    M --> N["实测空闲显存折算 block 数，各 rank 取最小<br/>extend_kv_cache 提交物理页"]
    L --> O["num_gpu_blocks 确定，交给 BlockPool"]
    N --> O
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-8 显存初始化：KV 的大小是“允许用量减去其他一切”之后的余数，extensible 模式把这个减法推迟到图捕获之后

编译、预热与就绪

vLLM 用两层手段降低每步的 CPU 开销。torch.compile 把模型前向编译成融合后的图；CUDA Graph 把一次前向中的大量 kernel launch 录制成图后整体重放。默认的 cudagraph_mode 是 FULL_AND_PIECEWISE：PIECEWISE 把 attention 之外的部分录成分段图，attention 以 eager 方式执行以适应变长；FULL 把整个前向录成一张图，适用于形状规整的纯 decode batch [16][17]。CUDA Graph 要求固定形状和地址，vLLM 只为一组离散的 batch 大小捕获图，运行时把实际 batch 向上补齐到最近的已捕获尺寸，超过最大尺寸的 batch 走 eager。尺寸太少会产生 padding 浪费，太多会增加捕获时间和图占用的显存。

编译和捕获完成后，EngineCore 创建结构化输出管理器和调度器：异步调度开启时（无不兼容项时默认开启）用 AsyncScheduler，并创建 batch queue。就绪的含义是“引擎已经可以调度”，不是“已经热身到稳态性能”：第一批真实请求仍可能触发未覆盖的编译路径或 prefix cache 冷启动，平台应在接流量前发送一组覆盖典型长度的预热请求。启动耗时主要来自权重加载、profile 和编译，vLLM 提供 torch.compile 编译缓存，以及显式开启的 startup plan：后者把上次测得的 KV 字节数连同 vLLM 版本、配置哈希、设备型号、总显存和 torch/CUDA 版本等指纹一起持久化，指纹一致且空闲显存不低于基线时跳过显存 profiling。两种缓存都必须与模型 hash、GPU 架构、驱动和引擎版本一起管理，换任何一项都应视为失效。

主 API server 提供 /health、/metrics、/version 等运维接口，但 /health 的语义很窄：它只检查本地记录的引擎状态、不向引擎发 RPC，引擎已死时返回 503，否则 200；主 API server 没有独立的 /ready 路由。因此探针要这样设计：

平台把实例状态映射为 DOWNLOADING（拉取制品）、LOADING（初始化设备与加载权重）、WARMING（profile、KV 分配、编译与预热请求）、READY、DRAINING、UNHEALTHY 和 TERMINATED，只有 READY 接流量，并把模型 hash、vLLM 版本、GPU 型号、启动耗时和最终 KV block 数写入注册表，因为同一模型在不同显卡、不同版本甚至不同启动之间的 block 数都可能不同。

停止、drain 与 sleep

API 进程收到 SIGINT 或 SIGTERM 后调用引擎的 shutdown，EngineCore 根据 shutdown_timeout 决定行为：为 0 时是 abort 模式，所有在途请求以 FINISHED_ABORTED 结束；大于 0 时是 drain 模式，拒绝新请求、等在途请求完成直到超时。shutdown_timeout 的默认值是 0，即默认中止所有在途请求，生产滚动发布若要优雅退出，必须显式配置 drain 超时，使之与编排系统的终止宽限期匹配，并先从路由摘除实例再发终止信号。

启动失败按位置分类：参数校验失败在 API 进程内立即报错；引擎进程在初始化中途退出时，前端监视到进程消失并报告引擎初始化失败；引擎等待握手、前端等待引擎就绪各有超时（后者由 VLLM_ENGINE_READY_TIMEOUT_S 控制，默认 600 秒）。常见根因包括显存放不下权重、KV 预算放不下一条最大长度序列、NCCL 初始化失败和编译失败，平台应分别记录，而不是统一视为容器启动失败后无限重启。

sleep mode 允许不退出进程而释放显存：sleep 按 weights 和 kv_cache 两个标签释放或卸载对应内存池，wake_up 再恢复。它的典型用途是 RL 训练中推理与训练轮流使用同一组 GPU，以及在同卡上切换模型。sleep 和 /reset_prefix_cache 等接口只在设置 VLLM_SERVER_DEV_MODE 时注册，生产上应由平台代理并做权限控制。换 vLLM 版本或模型版本不应依赖 sleep mode，而应让新实例完整走完本节的启动和预热流程，再按第12章 12.3 节的灰度流程接入流量。

10.5 推理执行与调度

一次请求的全过程与时间口径

以一个流式 /v1/chat/completions 请求为例（单 API server、默认配置），处理过程如图 10-9 所示。API server 收到请求，检查引擎存活与实例准入，渲染 chat template 并 tokenize，构造采样参数后调用 AsyncLLM.generate；InputProcessor 生成 EngineCoreRequest，OutputProcessor 为它建立 RequestState，客户端经 ZMQ 发给引擎。EngineCore 的输入线程构造 Request 并计算块哈希，调度器把它放入等待队列。此后每一步，调度器决定它算多少 token，worker 执行前向并采样，调度器写回新 token、检查停止条件，前端增量 detokenize 并通过 SSE 发给客户端。对这个请求而言，第一次被调度的步骤是 prefill（prompt 超过预算时只算一部分），之后每一步都是 decode；遇到停止条件时调度器释放 KV block，前端发送最后的 finish_reason、usage 和 [DONE]。

sequenceDiagram
    autonumber
    participant C as Client
    participant API as OpenAIServingChat
    participant AL as AsyncLLM
    participant EC as EngineCore
    participant S as Scheduler
    participant KV as KVCacheManager
    participant MR as GPUModelRunner
    C->>API: POST /v1/chat/completions，stream
    API->>AL: check_admission
    API->>API: 渲染模板、tokenize、构造 SamplingParams
    API->>AL: generate
    AL->>AL: EngineCoreRequest，注册 RequestState
    AL->>EC: ZMQ ADD
    EC->>S: add_request，WAITING
    loop 每一步
        EC->>S: schedule
        S->>KV: get_computed_blocks 与 allocate_slots
        S-->>EC: SchedulerOutput
        EC->>MR: execute_model
        EC->>S: 计算语法 bitmask，与 GPU 重叠
        EC->>MR: sample_tokens
        MR-->>EC: ModelRunnerOutput
        EC->>S: update_from_output，检查停止条件
        EC-->>AL: EngineCoreOutputs
        AL->>AL: detokenize、stop string
        AL-->>API: RequestOutput
        API-->>C: SSE data chunk
    end
    API-->>C: finish_reason、usage、[DONE]

图 10-9 一次流式请求的端到端时序：循环体是一次 engine step，对这个请求而言第一次是 prefill，之后是 decode

指标必须绑定到对象与时间点上才有意义。vLLM 引擎只记录事件和单调时钟时间戳，时间差在前端计算，因为不同进程的单调时钟不可比较。各时间点与派生指标如下：

几处容易出错。第一，77d2790 与 v0.32.0 在渲染模板之前记录到达时间，所以 vLLM 的 TTFT 包含模板渲染和 tokenize；v0.11.0 在 InputProcessor 的前身中记录，不含模板渲染，跨版本比较 TTFT 时要注意这个口径变化。第二，TTFT 不包含网关排队和网络发送，客户端看到的 TTFT 还要加上引擎外的两段：

\[ \text{TTFT}{\text{client}} \approx T{\text{gateway}} + T_{\text{render}} + T_{\text{queue}} + T_{\text{prefill}} + T_{\text{return}} + T_{\text{send}} \]

vLLM 的 TTFT 指标覆盖中间四段。第三，生成 token 数不超过 1 时 TPOT 不适用，不能记为 0；一次输出可能包含多个 token（投机解码或 stream_interval 大于 1），不能把事件数当 token 数。报告时应按输入长度、输出长度、并发、cache 命中和租户分桶。

请求进入引擎前有三道检查。引擎存活：引擎已死则立即返回 503。实例准入：check_admission 是较新版本的前端准入控制，多个 API 进程通过共享内存交换未完成请求数和待 prefill 的 token 数（单写者槽位，见 10.3 节），配置了 max_num_queued_reqs 或 max_num_queued_tokens 且超限时返回 503 并计入准入拒绝指标；它发生在流式响应开始之前，所以过载时仍能返回正确的状态码，但 token 计数是保守的，没有扣除已完成的 prefill 片段和 prefix 命中。参数校验：InputProcessor 检查采样参数、LoRA 和 prompt 长度，prompt 恰好等于 max_model_len 的生成请求也会被拒绝，因为没有空间生成任何 token；max_tokens 未设置时取 max_model_len 减 prompt 长度。n > 1 的请求在前端展开为 n 个独立子请求（设置了 seed 时依次加 1），引擎看到的是 n 个请求，它们的 prompt 通过 prefix cache 共享 KV。tokenize 结果必须与计费、准入、KV 估算一致，网关若用不同版本的模板或 tokenizer 自行计数，就会出现“网关认为能放下、引擎拒绝”或账单与 usage 不符，建议以 vLLM 返回的 usage 为准。

调度一步：token 预算与先 running 后 waiting

vLLM V1 的架构文档明确说明，调度器基于 token 预算，没有单独的 prefill 和 decode 阶段 [2]。每步开始时预算等于 max_num_scheduled_tokens（默认等于 max_num_batched_tokens），对每个被调度的请求计算本步要算的 token 数：

\[ n_{\text{new}}=\min\bigl(T_{\text{spec}}+T_{\text{placeholder}}-T_{\text{computed}},\ \theta_{\text{long}},\ B_{\text{left}}\bigr),\qquad B_{\text{left}}\leftarrow B_{\text{left}}-n_{\text{new}} \]

其中 \(T_{\text{spec}}\) 是 num_tokens_with_spec，\(T_{\text{placeholder}}\) 是异步调度的占位数，\(T_{\text{computed}}\) 是已计算 token 数，\(\theta_{\text{long}}\) 是 long_prefill_token_threshold，\(B_{\text{left}}\) 是剩余预算，另外还受 max_model_len 和多模态 encoder 预算约束。一个 prompt 长 3000 的新请求在预算 2048 时被截成 2048，剩下的下一步再算，这就是 chunked prefill；一个 decode 请求的 \(n_{\text{new}}\) 为 1（或 1 加 draft 数）。同一步里 decode 请求和 prefill 片段拼成一个混合 batch。

一次 schedule() 的决策流程如图 10-10 所示。先按 running 列表顺序调度运行中的请求：计算并截断 \(n_{\text{new}}\)，结果为 0 则跳过（这会有意打破严格的 FCFS），调用 allocate_slots 申请 block，失败则抢占一个请求后重试。然后仅当本步没有发生抢占时调度等待中的请求：运行请求数达到 max_num_seqs 则停止；语法未编译完、远端 KV 未到、LoRA 数超过 max_loras 的请求跳过；对首次调度的请求查询本地 prefix 命中，配置了 KV connector 再查外部命中，二者之和作为 num_computed_tokens 的起点；关闭 chunked prefill 且放不下时直接停止；allocate_slots 失败也直接停止，等待队列从不触发抢占。最后构造增量的 SchedulerOutput（新请求带完整数据，已缓存请求只带新 block 和新进度），并乐观推进每个请求的 num_computed_tokens。

flowchart TD
    S0["开始一步：预算 = max_num_scheduled_tokens"] --> R0{"running 中还有请求<br/>且预算大于 0？"}
    R0 -- 是 --> R1["计算 num_new_tokens<br/>按阈值、预算、max_model_len 截断"]
    R1 --> R2{"allocate_slots 成功？"}
    R2 -- 是 --> R3["记录 block 与 token，扣预算"] --> R0
    R2 -- 否 --> R4["选受害者：FCFS 取最后一个<br/>priority 取优先级最低者"]
    R4 --> R5["抢占：释放 block<br/>num_computed_tokens 清零，放回 waiting"]
    R5 --> R6{"受害者是自己？"}
    R6 -- 否 --> R2
    R6 -- 是 --> W0
    R0 -- 否 --> W0{"本步发生过抢占？"}
    W0 -- 是 --> O["构造 SchedulerOutput"]
    W0 -- 否 --> W1{"waiting 非空、预算大于 0<br/>且运行数未达上限？"}
    W1 -- 否 --> O
    W1 -- 是 --> W2["查询 prefix 命中，本地加 connector"]
    W2 --> W3["num_new_tokens = num_tokens − 命中长度<br/>按阈值、预算截断"]
    W3 --> W4{"allocate_slots 成功？"}
    W4 -- 否 --> O
    W4 -- 是 --> W5["移入 running，记录 SCHEDULED，扣预算"] --> W1
    O --> U["乐观推进 num_computed_tokens"]
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-10 一次 schedule() 的决策流程：运行中的请求优先，KV 不足时抢占；等待队列从不触发抢占

“先 running 后 waiting”保护了正在 decode 的请求的 TPOT，代价是高负载下新请求的 TTFT 变长；“本步有抢占就不接纳新请求”避免刚抢占一个又接纳另一个造成抖动。这种统一表示让调度器不必区分阶段，代价是“prefill 优先还是 decode 优先”只能通过调度顺序和 long_prefill_token_threshold 等参数间接表达。

allocate_slots 的顺序是：移除滑动窗口等已不需要的 block；计算需要新分配的 block 数；检查空闲 block 是否足够，不够则返回 None；把命中的 block 引用计数加一并移出空闲队列；从空闲队列分配新 block；最后把截至 num_tokens 的满 block 写入哈希表。上限是 num_tokens 而不是 num_tokens_with_spec，所以 draft token 不会被缓存。还有一个值得注意的时序：block 在被调度的那一步就被登记为已缓存，此时这些 token 的 KV 只是“即将写入”；异步加载远端 KV 时调度器会显式推迟登记，说明“登记即可命中”的前提是 KV 在本步内一定会被写入。

默认开启的异步调度把 CPU 调度与 GPU 执行重叠起来。EngineCore 维护一个 batch 队列，V2 runner 下长度为 PP 大小加 1（单卡为 2）：队列未满时调度新的一步并非阻塞下发，队列满时才等待最早那一步的结果并写回，于是 GPU 执行第 N 步时 CPU 已在调度第 N+1 步，如图 10-11 所示。调度第 N+1 步时第 N 步还没有采样出 token，AsyncScheduler 的做法是占位：把 num_output_placeholders 加上本步将要采样的 token 数，真实 token 回来后再替换。代价是一个请求在第 N 步已经停止，第 N+1 步仍可能为它分配了 token，这部分计算被丢弃；结构化输出请求需要上一步的 token 推进语法状态，采样可能被推迟。

gantt
    title 异步调度的重叠（示意）
    dateFormat X
    axisFormat %s
    section CPU EngineCore
    调度 N        :a1, 0, 2
    调度 N+1      :a2, 2, 4
    回写 N        :a3, 6, 7
    调度 N+2      :a4, 7, 9
    section GPU Worker
    执行 N        :b1, 2, 6
    执行 N+1      :b2, 6, 10

图 10-11 异步调度：CPU 在 GPU 执行第 N 步时调度第 N+1 步，回写与下一次调度也与 GPU 执行重叠（时间比例仅为示意）

KV 不足时的抢占与公平

运行中的请求 allocate_slots 失败时，调度器选择一个受害者：FCFS 策略取 running 列表的最后一个，即最近被接纳的请求；priority 策略取（priority, arrival_time）最大者，即优先级最低、到达最晚的请求，若它本步已被调度则退还它占用的预算。抢占会释放它的全部 KV block 和 encoder cache，状态置为 PREEMPTED，num_computed_tokens 清零，增加抢占计数并记录事件，再放回等待队列（FCFS 下放到队首，优先下次调度）。如果被抢占的恰好是当前请求自己，说明没有更低优先级的请求可抢，本步停止调度运行队列。

抢占只有重算一种方式，调度器中没有把 KV 换出到 CPU 的路径。但重算未必从零开始：被释放的满 block 带着哈希进入空闲队列尾部，如果在该请求重新被调度前没有被复用，重新调度时的 prefix 查询能把它们找回来；配置了 KV offload connector 时还可以从 CPU 层找回。所以抢占的实际代价取决于 KV 压力：压力越大，被释放的 block 越可能被别人复用，重算越多。抢占对用户的表现是流式输出停顿、TPOT 尾部变长；抢占指标长期非零说明 KV 容量与负载不匹配，应降低 max_num_seqs、增加 KV 容量或在平台层收紧长上下文准入。

为减少反复抢占，较新版本在调度配置中提供 watermark：接纳等待中或被抢占过的请求时，要求额外保留一定比例的空闲 block；它只在本步已有请求被调度时生效，默认值 0 表示关闭。v0.11.0 的 V1 调度器没有这一参数。

vLLM 调度器提供的公平机制是有限的：FCFS 或 priority 两种排队顺序；max_num_seqs 限制并发；long_prefill_token_threshold 限制单个请求一步能占用的 prefill token，防止一个超长 prompt 独占一步；priority 策略下高优先级请求可以通过抢占挤掉低优先级请求。它没有租户配额、加权公平、deadline 或老化机制，这些属于平台控制面（见 10.6 节）。chunk 大小的取舍遵循 Sarathi-Serve 的结论 [5]：max_num_batched_tokens 越小，每步越短、TPOT 越稳，但长 prompt 要更多步才能完成；太小又会增加 kernel launch 和调度开销。

Prefill、decode、采样与投机解码

worker 收到 SchedulerOutput 后，Model Runner V2 先更新本地状态：删除已结束的请求，释放被抢占请求的状态行，为新请求分配固定的状态行，按增量更新已有请求的 block 与进度，再把暂存的 block table 修改一次性应用到 GPU。然后准备输入：根据 token 数、是否为纯 decode 和 LoRA 数选择 CUDA Graph 模式与补齐尺寸；构造 input_ids、positions、每个请求本步 token 的起止位置 query_start_loc、序列长度和需要计算 logits 的位置（每个请求本步的最后一个 token）。V2 用 Triton kernel 在 GPU 上从持久状态中直接收集这些张量，并借助 UVA（Unified Virtual Addressing，统一虚拟寻址，让 GPU kernel 直接访问映射到设备地址空间的主机内存）读取 CPU 上的大张量，避免在 Python 中逐个拼接 [7]。混合 batch 中 prefill 片段与 decode 请求的 token 被拼成一维序列，attention kernel 按 query_start_loc 对每个请求分别计算。

前向时，每个 attention 层先按 slot mapping 把本步新 token 的 K、V 写入对应 block，再用该请求的 block table 读取全部历史 K、V 计算注意力。对 prefill 片段而言只有最后一个 token 的 logits 有用，如果它不是 prompt 的最后一段，这个位置的采样结果会被丢弃；所以长 prompt 的 TTFT 约等于排队时间加“片段数 × 每步耗时”，而每步耗时又取决于同一步里的其他请求。prefill 完成后请求进入 decode，每步只有一个 query token，却要读取全部权重和历史 KV，因此受内存带宽限制。提高 decode 效率的主要办法是把尽可能多的 decode 请求放进同一步，并用 CUDA Graph 消除 launch 开销：纯 decode 的 batch 用 FULL 图，整步只有一次重放；混合 batch 用 PIECEWISE 图；超过最大捕获尺寸走 eager。FULL 模式要求输入地址固定，V2 先把输入拷贝到捕获时使用的固定缓冲区再重放。多模态输入由 encoder 转成 embedding，调度器为 encoder 单独维护预算和按内容哈希的 encoder cache。

长上下文同时增加 prefill 计算、KV 容量、排队时间和 decode 阶段的显存占用，而引擎只能在预算内切块，不会替调用方决定是否接纳。平台应在入口限制最大输入、最大输出、总 token 和租户并发，并按请求类型选择同步、异步或低优先级队列；截断要保留消息边界、系统指令和工具 schema，不能简单从字符串尾部截断。指标上要区分排队、prefill、decode 和网络等待，才知道用户是在等计算还是在等资源。

采样在最后一个 PP stage 上执行。若有结构化输出请求，EngineCore 在 GPU 前向期间已算好语法 bitmask，此时原地应用到 logits 上，把不允许的 token 置为负无穷。采样器依次应用 logits processors（logit bias、min tokens、惩罚、bad words 等）、temperature 和 min-p，最后做 top-k、top-p 与随机采样，temperature 为 0 时取 argmax。V2 的随机采样使用 Gumbel 采样 kernel：给每个 logit 加上独立的 Gumbel 噪声后取 argmax，其结果服从 softmax 分布，无需先把 logits 归一化为概率再按累积分布抽样。采样完成后，V2 立即启动异步的 GPU 到 CPU 拷贝，与后续的 drafter 提议重叠。

投机解码用一个廉价的 drafter 提出若干候选 token，再由目标模型一次前向验证多个位置 [18][19]。在 vLLM 中，draft token 存放在 Request.spec_token_ids，计入目标长度和 token 预算，allocate_slots 为它们预留 KV 槽位但不缓存；worker 用 RejectionSampler 比较目标模型与 drafter 的分布，接受前若干个 draft 并额外采样一个 token；调度器按被拒绝的数量回滚 num_computed_tokens；drafter 再为下一步提出新的 draft，方法包括 ngram、草稿模型、EAGLE 和 MTP 等。它改变了“每步每请求追加一个 token”的假设：batch 形状更不规则，KV 需要为候选预留空间。接受率低、输出短或并发高时额外计算可能抵消收益，平台应分别报告目标模型调用、draft 调用、接受率和每个成功输出 token 的总 GPU 时间，不能把使用 draft 后的 tokens/s 直接与未使用时比较。

并行与 PD 分离下的执行

TP 时，EngineCore 经共享内存消息队列把同一份 SchedulerOutput 广播给所有 TP rank，各 rank 用相同输入执行前向，各自持有权重和 KV 的一个切片。KV 按 KV head 切分；当 TP 大于模型的 KV head 数时，每个 rank 至少要有一个 KV head，KV head 会被复制到多个 rank，此时单卡 KV 占用不再随 TP 线性下降。一步中的通信点是每个 Transformer 层 attention 输出投影和 MLP 下投影之后各一次 all-reduce，以及采样前可能的 logits 聚合；只有最后一个 PP stage 的 TP rank 0 回传结果。PP 时前一 stage 把中间张量发给下一 stage，非最后 stage 接收广播的采样结果更新本地状态，batch queue 让多个 batch 同时在流水线中以减少气泡。

PD 分离时，一个请求先在 prefill 实例上完成 prefill，KV 通过 connector 传到 decode 实例，再逐 token 生成。decode 实例的调度器处理等待中的请求时，先查本地 prefix 命中，再询问 connector 有多少 token 可从远端加载、是否异步加载；为全部 token 分配 block（异步时推迟登记缓存）并把位置告诉 connector；异步加载期间请求处于 WAITING_FOR_REMOTE_KVS，不占 token 预算；调度器每步生成给 worker 侧 connector 的指令，worker 在前向前后启动加载、逐层等待或保存 KV；传输完成后请求回到等待队列，此时 num_computed_tokens 已包含远端 KV。prefill 实例上，请求结束时 connector 可以要求推迟释放 block，直到 KV 发送完成。以 NIXL connector 为例，默认是 pull 模式，decode 端从 prefill 端读取 KV；prefill 端以短租约持有待传输的 block，decode 端用心跳续约。分离后的调度是有状态的流量分配：prefill 完成但 decode 没有空间时，不能无限堆积已产生的 KV；KV 传输应携带模型版本、token 长度、KV dtype、布局和校验，支持超时与部分失败，路由决策写入 trace。

量化也改变执行路径。vLLM 支持 AWQ、GPTQ、FP8、compressed-tensors 等多种方法，每种方法替换线性层的实现。权重量化减少权重占用和读取带宽，KV 量化（如 FP8 的 cache_dtype）减少长上下文显存，二者误差来源不同；反量化本身消耗计算与访存，只有节省的权重读取超过额外代价时才会变快。量化验收不能只看平均困惑度，小概率的 token 错误就可能让工具 schema 或 JSON 失败，质量回归的方法见第11章。

输出、结束与资源回收

EngineCore 拿到 ModelRunnerOutput 后先处理中止队列，让在途期间到达的 abort 尽早生效，再调用 update_from_output：对每个请求追加新 token，每追加一个就按顺序检查 EOS、stop_token_ids、长度上限、min_tokens 和重复检测，命中则截掉之后的 token，结束的请求进入释放流程。前端输出协程收到结果后增量 detokenize 并检查 stop string，它是文本层条件，只能在前端判断：命中时截断文本、把结束原因设为 STOP，并向引擎发 abort。所以 stop string 命中时引擎可能已多生成一两步，这部分被丢弃；detokenizer 还要暂扣一段字符，以免把 stop string 的前半部分发给客户端。

结果放入请求的输出队列，生产者比消费者快时 DELTA 输出会在队列中合并。这意味着慢客户端不会反压引擎：引擎照常生成，结果在前端累积，KV 一直被占用到请求结束。平台需要写超时、发送缓冲上限、心跳和明确的断开语义。背压因此分散在多个层面：网关限制并发和请求体，实例准入限制排队请求与 token，调度器受 KV block 约束，结果流受发送缓冲约束；任何一层资源不足都应返回可重试或不可重试的明确错误码，而不是让连接无限挂起。每个 choice 的 finish_reason 只发送一次；开启 stream_options.include_usage 时最后发送一个带 usage 的 chunk，RequestOutput.num_cached_tokens 还给出 prefix 命中的 token 数，可用于区分缓存读取的计费，流以 data: [DONE] 结束。

结束有四种方式：正常完成（EOS、stop token 或 stop string，状态 FINISHED_STOPPED）、长度截断（FINISHED_LENGTH_CAPPED）、客户端取消和上层超时（都是 FINISHED_ABORTED）。客户端断开使 generate() 协程被取消，前端移除 RequestState 并向引擎发 ABORT，引擎输入线程把它同时放入中止队列，调度器把请求从队列中移除并释放资源。vLLM 不为单个请求设置生成超时，排队、prefill、decode 和下游发送的超时要由网关或调用方实现：deadline 到达时主动断开或调用取消接口，引擎才会释放资源。

三种来源最终汇合到同一个释放流程，如图 10-12 所示。释放顺序是：通知 KV connector 与 encoder connector 请求结束（connector 可能要求推迟释放）；释放 encoder cache；把请求 ID 加入 finished_req_ids，随下一步通知 worker；释放 KV block，若 GPU 上可能仍有在途步骤写这些 block，则放入延迟释放队列；最后从请求字典中删除。原则是先阻止新的引用，再等在途使用结束，最后回收：立即释放仍可能被 GPU 写入的 block，会让下一个分配到它的请求读到被污染的 KV；永远不释放则造成泄漏。

flowchart TD
    A{"结束原因"} -->|"EOS、stop token、长度"| B["update_from_output：停止条件命中"]
    A -->|"stop string"| C["前端 detokenize 命中"] --> C2["前端发 ABORT"]
    A -->|"客户端断开"| D["generate 协程被取消"] --> D2["移除 RequestState，发 ABORT"]
    C2 --> E["引擎：中止队列优先处理<br/>FINISHED_ABORTED"]
    D2 --> E
    B --> F["释放流程"]
    E --> F
    F --> G["connector 与 encoder 结束钩子"]
    G --> H["加入 finished_req_ids"]
    H --> I{"GPU 可能仍在写<br/>或 connector 要求推迟？"}
    I -- 是 --> J["延迟释放队列"] --> K
    I -- 否 --> K["逆序归还 block<br/>满 block 保留哈希，进入空闲队列尾部"]
    K --> L["从请求字典删除"]
    H --> M["下一步：worker 删除本地状态"]
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-12 结束路径：三种来源汇合到同一释放流程，block 回到空闲队列后仍可被命中

请求结束后它的满 block 并没有被清除，而是带着哈希进入空闲队列尾部。这对多轮对话特别有用：下一轮 prompt 包含上一轮的全部历史，命中后只需计算新增部分。但这也意味着 KV 内容在请求结束后仍留在显存中，直到被复用覆盖；vLLM 能清空全部 prefix cache，却没有“只清除某个请求的 KV”的接口，敏感数据的隔离要依靠 10.6 节的 cache_salt。

10.6 多租户与平台钩子

10.5 节描述的是单个实例内部如何把一条请求算完。生产平台面对的是多个租户、多个模型版本和多个实例，租户配额、路由、降级、灰度、计费都在网关、路由器和发布系统里完成；多租户 GPU 资源调度、配额与隔离见第8章 8.5 节，灰度、回滚、数据驻留和成本治理见第12章 12.3、12.5、12.6 节。本节只讨论 vLLM 为这些控制面提供了哪些钩子，以及每个钩子的边界。如图 10-13 所示，控制面通过请求字段和管理接口向引擎下发意图，引擎通过指标向控制面反馈状态。

flowchart LR
    U["调用方"] --> GW
    subgraph CP["平台控制面"]
        GW["网关<br/>鉴权、租户配额、预算"] --> RT["路由器<br/>版本、区域、负载与 cache 感知"]
        REL["发布系统<br/>灰度、回滚"] -.-> RT
    end
    subgraph EN["vLLM 实例"]
        H1["priority<br/>排队与抢占顺序"]
        H2["cache_salt<br/>prefix 命中域"]
        H3["LoRARequest<br/>adapter 选择"]
        H4["实例准入<br/>排队请求数与 token 上限"]
        H5["sleep 与 reset_prefix_cache<br/>开发接口"]
        M["/metrics<br/>排队数、KV 使用率、命中率"]
    end
    RT -->|"请求字段"| H1
    RT -->|"请求字段"| H2
    RT -->|"请求字段"| H3
    RT --> H4
    REL -.->|"经平台代理调用"| H5
    M -.->|"反馈"| RT
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-13 控制面与引擎的分工：租户、预算、路由与发布在控制面完成，vLLM 通过请求字段与管理接口接受意图，通过指标反馈状态

优先级与在线离线共存

priority 是请求字段，只在调度策略设为 priority 时生效：数值越小越优先，KV 不足时先抢占优先级最低的运行请求（见 10.5 节）。这是单实例内的局部机制：它不知道租户配额，也不知道一个租户的请求分布在多少个实例上，平台级的加权公平、最低服务份额和老化必须在控制面实现 [20]。高优先级也不等于无限资源：只有优先级而没有最低份额时，高优流量持续到达会让低优队列永久等待；而 vLLM 的抢占是“释放 KV、之后重算”，对已经输出大量 token 的请求代价很高。

在线与离线若必须共享实例，可以把离线请求放在低优先级并限制其 token 预算；但离线任务更适合独立实例，用更大的 batch 和更长的排队时间换取吞吐，并具备断点、重试和幂等写入。

cache_salt 与租户隔离

vLLM 的块哈希覆盖 token、LoRA 和多模态内容，但不包含租户身份。租户隔离要靠 cache_salt：它只加在首 block 的哈希里，由于哈希是链式的，不同 salt 的请求整条前缀都不会互相命中。平台应由服务端在认证之后按租户域生成或约束 salt，客户端自己填写的 salt 不是访问授权。高敏感租户可以使用独立 salt，或用 SamplingParams.skip_reading_prefix_cache 禁止读取 prefix cache。cache 泄漏通常不是显式返回数据，而是命中率与延迟差异形成的侧信道。

如 10.3 节所述，固定哈希种子让跨实例共享前缀成为可能，也让“同内容同哈希”跨越了实例边界，跨实例、跨区域共享 KV 时 salt 的生成规则必须一致。删除要求方面，vLLM 只能通过 /reset_prefix_cache 清空整个实例的 prefix cache：默认只在没有运行中请求时成功，指定重置运行中请求时会先抢占全部运行请求；没有按请求或按租户清除的接口。数据删除的完整义务见第12章 12.8 节。

LoRA 与多模型共存

一个基础模型可以服务多个 LoRA adapter。请求携带 LoRARequest，调度器限制一步内同时活跃的 adapter 数（max_loras），超出的请求留在等待队列；执行层把不同 adapter 的请求放进同一个 batch，由专门的批量 LoRA kernel 处理。adapter 身份进入块哈希，不同 adapter 之间不会误用 prefix cache。共享基础权重能降低显存，但 adapter 有容量、淘汰和版本兼容问题：基础模型升级后旧 adapter 不一定兼容，不能只按名称加载。

vLLM 一组进程只服务一个基础模型，同卡部署多个模型意味着多组进程，每组都在启动时按自己的 gpu_memory_utilization 占住一份显存（见 10.4 节），份额之和超过显卡容量时后启动的实例会失败。多组进程可以同时常驻，代价是彼此的权重、KV 与尾延迟相互挤压。sleep mode 提供了另一种方式：让暂时不用的实例释放权重或 KV 显存，把空间腾给活跃模型，代价是唤醒时重新加载和预热，适合流量可预测的轮换，不适合频繁抖动的切换。

超时、准入、路由信号与开发接口

超时也属于这类边界。网关与引擎的超时不能随意叠加：网关超时短于生成时间，会导致客户端断开而 GPU 继续工作。vLLM 在感知到 HTTP 断开时会中止请求并释放 KV，但中间代理缓冲连接时，感知可能延迟。更稳妥的做法是让请求携带 deadline，各组件按剩余时间决定是否接纳、继续 prefill 或提前结束，并在 trace 中传播。

实例级准入（max_num_queued_reqs、max_num_queued_tokens）只保护单个实例不过载，它不认识租户，也不跨实例汇总；租户配额、预算和最大上下文仍需网关完成。路由器可以利用 /metrics 暴露的运行与等待请求数、KV 使用率和 prefix 命中情况做负载感知与 cache 感知路由；round-robin 处理不了一个副本正在加载、另一个副本 KV 已满的情况。路由器只看到聚合指标，引擎只看到本实例队列，两者之间的信息差会造成“路由器认为有空闲、引擎内在频繁抢占”。

计费与重试的钩子是 usage：vLLM 在流式响应中返回自己 tokenize 的 prompt token 数、生成 token 数和 prefix 命中数，网关应以它为结算依据（见 10.5 节）；同一逻辑请求的多次尝试、预留与退款的幂等性由平台实现，见第12章 12.6 节。sleep、wake_up 和 reset_prefix_cache 都属于开发接口，只在设置 VLLM_SERVER_DEV_MODE 时注册，生产上必须由平台代理并加权限控制。

10.7 可靠性、诊断与验收

SLO、错误预算与燃烧率告警见第12章 12.1 节，可观测性运营见 12.2 节，事故响应、运行手册与演练见 12.4 和 12.7 节；本节只讨论推理引擎特有的故障语义、诊断路径和验收证据。

vLLM 不做进程内恢复

引擎死亡有三条传播路径：EngineCore 内部异常时向前端推送死亡标记；EngineCore 进程直接退出时，前端的监控线程发现进程消失；worker 进程死亡时，执行器的监控线程触发失败回调，EngineCore 以执行器失败结束。三条路径最终都让前端把引擎标记为不可用，后续请求得到 EngineDeadError，/health 返回 503；API 进程的 watchdog 每 5 秒检查一次，发现引擎出错后让服务退出，除非设置了 VLLM_KEEP_ALIVE_ON_ENGINE_DEATH。

也就是说，vLLM 自身不在进程内重建引擎，恢复依赖编排系统重启实例，如图 10-14 所示。KV cache 是可重建的状态，重启后不必恢复，但正在流式输出的请求会失败；平台可以返回可重试错误，或把请求迁移到其他实例重做 prefill，代价是更高的 TTFT 和额外的 GPU 负载。请求迁移有四种做法：重发完整输入、传输已有 KV（由 KV connector 承担）、只迁移请求状态、放弃当前请求。只迁移状态而不迁移 cache 会造成状态与资源不一致；流式请求迁移还要保持上下文、采样随机状态和停止条件。多数系统应让迁移发生在 prefill 完成之前或请求边界。

flowchart TD
    A{"故障来源"} -->|"EngineCore 异常"| B["推送引擎死亡标记"]
    A -->|"EngineCore 进程退出"| C["前端监控线程发现"]
    A -->|"Worker 进程退出"| D["执行器失败回调"]
    B --> E["前端标记引擎死亡<br/>新请求得到 EngineDeadError"]
    C --> E
    D --> E
    E --> F["/health 返回 503"]
    E --> G["watchdog 约 5 秒内让 API 进程退出"]
    F --> H["平台：摘除实例，流量转到兼容副本"]
    G --> I["编排系统重启实例<br/>重新加载、profile、编译"]
    H --> J["在途流式请求：可重试错误或迁移重算"]
    I --> K["readiness 通过后重新接流量<br/>核对 block 数、队列、p99"]
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-14 故障传播与恢复：vLLM 不在进程内重建引擎，恢复由平台的摘除、重启和再接入完成

常见故障还包括模型加载失败、tokenizer 不匹配、量化 kernel 崩溃、KV 不足导致的频繁抢占、CUDA OOM、GPU Xid 错误（NVIDIA 驱动在内核日志中报告的 GPU 错误事件码）、NCCL 挂起和流式连接堆积。每种故障应定义检测信号、影响范围、自动动作和是否丢失请求；把所有故障都归为 5xx，会让容量、质量和数据问题无法区分。恢复后要核对 KV 是否释放、队列是否回落、p99 是否恢复，仅看到 Pod Running 不代表服务恢复。

观测信号与指标名

vLLM 在 /metrics 上暴露 Prometheus 指标。Prometheus 客户端会给计数器自动加 _total 后缀，所以下表中的计数器在 PromQL 里要写全名，否则查不到数据：

前缀命中率用 rate(vllm:prefix_cache_hits_total[5m]) / rate(vllm:prefix_cache_queries_total[5m]) 计算。vllm:iteration_tokens_total 是名字本身带 _total 的直方图，查询时用它的 _bucket、_sum、_count 序列。指标名同样依赖版本，例如 v0.11.0 还保留已弃用的 vllm:gpu_cache_usage_perc，且没有准入拒绝和每请求抢占分布（见 10.10 节）。这些指标只覆盖引擎内部的一段；网关排队、路由、工具调用和计费需要平台用 trace 串联，Dapper 与 OpenTelemetry 的信号模型适合跨组件关联一次请求 [21][22]。默认不记录完整 prompt 和输出，标签要避免完整 request id、租户自由字符串和 token 内容造成的高基数 [23]。

延迟诊断与压测方法

先用请求时间线确认瓶颈属于排队、prefill、decode 还是引擎外，再选剖析工具，分流路径如图 10-15 所示。vLLM 的 CPU 侧开销（调度、输入准备、detokenize）曾是重要瓶颈，异步调度和 Model Runner V2 都是为它而做的，因此不能默认瓶颈都在 GPU。进入 kernel 层面后，Nsight Compute 的 Roofline 分析可以区分带宽受限与 launch、同步造成的空洞 [24]。

flowchart TD
    S["症状：TTFT 或 TPOT 变差"] --> Q{"排队时间升高？"}
    Q -- 是 --> Q1{"等待请求数持续增长？"}
    Q1 -- 是 --> Q2["容量不足或准入过松：扩容、收紧准入"]
    Q1 -- 否 --> Q3["查抢占计数：持续增长说明 KV 不足"]
    Q -- 否 --> P{"prefill 时间升高？"}
    P -- 是 --> P1["长输入增多或前缀命中下降<br/>看长度分桶与命中率"]
    P -- 否 --> D{"decode 时间或 ITL 升高？"}
    D -- 是 --> D1["batch 变大、混入长 prefill 或 CUDA Graph 未命中<br/>看每步 token 数与 max_num_batched_tokens"]
    D -- 否 --> N["引擎内正常：查网关排队、tokenize、网络与客户端"]
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-15 延迟诊断的分流：先用引擎内的阶段指标定位是排队、prefill、decode 还是引擎外，再选剖析工具

压测应使用真实长度分布而不是固定 prompt。至少覆盖短入短出、长入短出、短入长出、长入长出、前缀高命中、前缀低命中、结构化输出和突发流量八类负载，记录到达过程、并发、取消比例和租户混合，并分别比较混合部署与 PD 分离。只从客户端测总延迟无法定位瓶颈，只测引擎又会漏掉真实连接和 tokenize，所以要同时采集客户端和引擎两侧的时间点。排障时最有效的方法之一是回放单个请求的状态机：Request 上记录了 QUEUED、SCHEDULED、PREEMPTED 等事件和时间戳，配合网关事件可以复原它排队多久、经历几次 prefill chunk、是否被抢占。同样的事件序列也可以用于测试：重复取消不泄漏 block，drain 会停止新请求，deadline 到期会释放资源。

显存问题要区分两本账。PyTorch 的 memory_allocated 是张量占用，memory_reserved 是分配器管理的总量，empty_cache() 只释放未使用的缓存 [25]；而 vLLM 启动时一次性分配整块 KV 张量，在 allocator 统计里表现为稳定的大块占用，KV“用了多少”要看引擎自己的空闲 block 数。排查时先建立固定长度与并发的基线，一次只改变轮次、取消、前缀或图捕获中的一个变量：总 token 增长带来的活跃 block 增长是正常的历史成本；固定负载下 allocated 逐轮上升才指向引用泄漏；取消率升高而空闲 block 不回升，要查 abort 是否送达 EngineCore；首次非法访存之后的 OOM 可能只是异步错误的传播，应先定位最早的 CUDA 错误 [26]。循环调用 empty_cache 不是修复。

验收证据

上线前要证明的不是“服务能启动”，而是五组证据，缺任何一组都意味着某个结论无法复核：制品与兼容（制品 hash、tokenizer 与模板版本、vLLM 版本与提交、GPU 架构与驱动）；容量与性能（长度分布、并发曲线、TTFT 与 TPOT 分位数、KV 水位、抢占率、最终 block 数）；质量回归（优化前后的配对比较与结构化输出合法率，方法与门禁见第11章 11.8 节）；可靠性与降级（故障注入、摘除与恢复时间、丢失请求数）；治理与成本（租户配额、审计字段、单位成功任务成本与回滚记录）。五组证据不能互相替代：一个版本可能容量很好但质量回退，也可能质量持平却无法回滚。

升级 vLLM 版本时，兼容性测试要覆盖四类场景：功能上覆盖单请求、动态 batch、流式、取消、最大长度、结构化输出、工具调用和多模态；性能上覆盖不同输入输出长度与并发；资源上覆盖显存、block 数、编译缓存和冷启动；故障上覆盖引擎崩溃、模型加载失败和滚动 drain。还要覆盖错误语义：同一个超长输入，一个版本可能返回 400，另一个版本可能截断后返回 200；默认值变化（如 10.2 节的 gpu_memory_utilization）会直接改变 block 数和并发上限。因此每次升级都要在固定负载上重跑基线，并把启动日志中的 block 数作为回归项。

10.8 主流推理引擎比较

比较的层次

“vLLM、SGLang、TensorRT-LLM、Triton、TGI 哪个更好”这个问题本身有层级错位。vLLM、SGLang 和 TensorRT-LLM 是推理引擎，负责调度、KV 管理和模型执行；Triton Inference Server 是服务层，负责模型仓库、版本、协议和多后端托管，本身不做 LLM 的连续批处理，而是交给 TensorRT-LLM 或 vLLM 后端 [15]；TGI 是完整的服务实现，官方仓库已声明进入维护模式，只接受小修复，历史功能存在不等于持续新增支持 [27]。比较时必须先把对象放在同一层级，如图 10-16 所示。本节只比较各自文档和源码中写明的机制，不给出吞吐数字：任何性能比较都必须在同一硬件、同一模型、同一负载下重测。

flowchart TB
    subgraph G["网关与路由层，平台自建"]
        GW["鉴权、配额、路由、降级"]
    end
    subgraph S["服务层"]
        TRI["Triton Inference Server<br/>模型仓库、版本、多后端"]
        OAI["引擎自带的 OpenAI 兼容服务<br/>vllm serve、SGLang server、trtllm-serve"]
    end
    subgraph E["推理引擎层"]
        V["vLLM"]
        SG["SGLang"]
        TL["TensorRT-LLM"]
    end
    subgraph K["Kernel 与通信层"]
        KN["FlashAttention、FlashInfer、CUTLASS、Triton kernels、NCCL"]
    end
    GW --> TRI
    GW --> OAI
    TRI -->|"后端"| TL
    TRI -->|"后端"| V
    OAI --> V
    OAI --> SG
    OAI --> TL
    V --> KN
    SG --> KN
    TL --> KN
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-16 各对象的层次位置：Triton 在服务层托管引擎，三个引擎共享相近的 kernel 生态

调度与 KV 管理

vLLM 的调度器只看每个请求还差多少 token 没算，chunked prefill、prefix 命中和投机解码都落在同一个预算模型里；排队策略只有 FCFS 和 priority，prefix cache 是“请求到了再查”，不按命中长度重排队列。前缀复用基于块哈希链，命中粒度是满 block。

SGLang 的论文把系统分为前端语言与运行时，运行时核心是 RadixAttention：用基数树组织所有请求的 KV，前缀天然共享，按 LRU 淘汰叶子节点；论文还提出最长前缀匹配（LPM）调度，优先运行与已缓存前缀匹配最长的请求，并用压缩有限状态机加速结构化输出 [28]。需要区分论文主张与运行时默认行为：在 2026-11-05 的 SGLang 主干中，schedule_policy 的默认值是 fcfs，LPM 是可选策略之一，与 random、priority、最短 prefill 优先等并列 [29]。基数树也不再必然是逐 token 粒度：运行时支持配置 page_size，大于 1 时前缀匹配长度按页向下取整，命中粒度与分页 block 相当。运行中显存不足时，SGLang 可能撤回（retract）部分请求，schedule_conservativeness 参数用来调节接纳的保守程度。

TensorRT-LLM 是 NVIDIA 的推理库，提供 in-flight batching 和分页 KV cache [30]。它的容量调度器有三种策略：默认的 GUARANTEED_NO_EVICT 只接纳能保证运行到结束、不会被暂停的请求；MAX_UTILIZATION 在每次迭代尽量多装请求，KV 用尽时可能暂停请求，吞吐更高但会伤害延迟；另有 STATIC_BATCH [31]。这与 vLLM“先乐观接纳、不足时抢占重算”的做法形成对照：前者用保守准入换取不被抢占，后者用重算风险换取利用率。KV 复用方面，只有满 block 可以在请求间共享，可复用 block 按 LRU 驱逐，还可以把将被驱逐的 block 卸载到主机内存以延长可复用时间；LLM API 中 block 复用默认开启 [32][33]。

启动、部署与选型

vLLM 把成本放在启动时：加载权重、测量显存、分配 KV、编译与图捕获（见 10.4 节）。早期 TensorRT-LLM 把更多成本前移到离线构建，engine 与 GPU 架构、精度和最大 shape 绑定，部署时加载更快但兼容矩阵更严格；当前 LLM API 的后端默认是 PyTorch，降低了构建门槛 [14][33]。无论哪种方式，编译产物都必须和模型 hash、GPU 架构、驱动和引擎版本一起管理。三个引擎都在支持 TP、PP、EP 和 PD 分离，选型时要比较的不是“是否支持”这样的勾选项，而是目标负载下调度、传输和故障语义是否满足需求。

选型可以按负载与约束判断：模型覆盖面、硬件多样性和社区插件优先时，vLLM 是稳妥的默认选项；前缀高度重复的 Agent 与多轮对话负载，值得在同一负载下对比 SGLang，并实际开启它的前缀感知策略；只用 NVIDIA GPU、模型固定、追求单卡极致性能并能承担更严格的制品管理时，可以评估 TensorRT-LLM；需要统一托管多种模型（不止 LLM）并复用已有 Triton 运维体系时，把 Triton 放在服务层、引擎作为后端。还要警惕“换一个引擎就能解决延迟问题”：长度分布、准入、配额、路由、超时层次和慢客户端，大部分都在引擎之外。

10.9 本章小结

本章沿着一条请求的生命周期拆解了 vLLM V1，几条主线可以归结为图 10-17。

flowchart LR
    subgraph A["架构"]
        A1["三类进程<br/>CPU 开销与 GPU 执行隔离"]
        A2["单写者所有权<br/>KV 决策只在 EngineCore"]
    end
    subgraph B["资源"]
        B1["启动时测量显存<br/>block 总数即并发上限"]
        B2["块哈希链与空闲队列<br/>命中只省 prefill"]
    end
    subgraph C["调度"]
        C1["每步 token 预算<br/>computed 追赶 total"]
        C2["KV 不足时抢占重算<br/>先 running 后 waiting"]
    end
    subgraph D["平台"]
        D1["钩子：priority、cache_salt、<br/>LoRA、准入、sleep"]
        D2["引擎不做进程内恢复<br/>摘除、重启、再接入"]
    end
    A1 --> C1
    A2 --> B2
    B1 --> C2
    B2 --> C1
    C2 --> D1
    C1 --> D2
    D2 -.->|"验收：制品、容量、质量、可靠性、成本"| E["第11章与第12章"]
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-17 本章概念地图：架构决定所有权，资源账本约束调度，调度暴露的钩子与故障语义交给平台

第一，vLLM V1 把推理服务拆成前端进程（协议、tokenize、detokenize）、EngineCore 进程（调度与 KV 账本）和执行层（多卡时每 GPU 一个 worker 进程，单卡默认在引擎进程内），进程边界本身就是为了让 Python 的 CPU 开销不阻塞 GPU；KV block 的分配与回收只在 EngineCore 中决定，这是理解取消、抢占和释放顺序的钥匙。

第二，它的核心抽象是“每一步给每个请求分配若干 token”：prefill、chunked prefill、decode、prefix 命中和投机解码都统一成 num_computed_tokens 对 num_tokens 的追赶。KV 以固定大小的 block 记账，不足时抢占重算而不是 OOM；被释放的满 block 带着哈希留在空闲队列尾部，所以重算可以部分找回，多轮对话可以复用历史。

第三，容量是测出来的而不是配出来的。block 总数等于“允许用量减去权重、激活和图占用”之后的余数，随显卡、默认值和版本而变：Qwen3-8B 的案例中，利用率从 0.92 换成 0.9 就让候选并发从 4 变成 3。每次升级都要把启动日志中的 block 数当作回归项。

第四，vLLM 只负责“单实例内把请求算好”。它给平台留下了 priority、cache_salt、LoRA、实例准入、sleep 和指标等钩子，但租户配额、路由、灰度、计费和故障恢复都在引擎之外；引擎死亡后的恢复依赖编排系统。

把本章的机制与常用参数对照起来，可以得到下表。调参时一次只改一个参数，并同时观察对侧指标。

仍然开放的问题集中在三处：引擎内调度与平台路由之间的信息差，prefix 感知路由、按 KV 水位路由和 PD 两段调度都在尝试缩小它，但还没有统一接口；抢占的代价随上下文和输出变长而上升，用更保守的准入（如 watermark 或不驱逐式的容量策略）换取稳定性需要在具体负载上权衡；KV 正在从实例内的临时状态变成可跨实例传输、卸载和共享的资源，一旦离开实例，版本兼容、权限隔离和删除保证都要重新设计。落地时建议先在目标硬件上用单副本、固定版本建立基线（启动耗时、block 数、分长度桶的 TTFT 与 TPOT、抢占率、命中率），再逐项打开优化、每次只改一个变量；扩大规模之前先补齐网关、路由、发布和 trace。

请求能够稳定在线运行之后，下一个问题是“如何知道模型是否仍然正确”。第11章讨论评估集、质量门禁和线上反馈，它们会消费本章产生的 trace、usage、版本与成本数据；第12章再把这些证据接入发布、事故响应和成本治理。

10.10 附：版本敏感点与源码索引

版本敏感点

vLLM 迭代很快，本章描述的若干行为只在较新版本中成立。下表对比三个时间点：v0.11.0、v0.32.0（2026-10-18 发布）和本章所依据的主干提交 77d2790 [1][34]。表中只列出在这三个版本的源码中核对过的差异，其他版本应自行核对。

关键默认值

以下默认值对应 77d2790：block_size 为 16（未显式指定时可被平台调整）；prefix caching 开启，哈希算法为 sha256；chunked prefill 开启；调度策略为 fcfs；异步调度在没有不兼容项时自动开启；cudagraph_mode 为 FULL_AND_PIECEWISE；shutdown_timeout 为 0，即 abort 模式；前端等待引擎就绪的超时 VLLM_ENGINE_READY_TIMEOUT_S 为 600 秒；OpenAI 兼容服务的 max_num_seqs 与 max_num_batched_tokens 按显存取 1024 与 16384（不小于 160 GiB）、1024 与 8192（不小于 70 GiB 且非 A100）或 256 与 2048。

源码索引

图 10-18 把这些模块按请求路径连起来，并标出受版本影响最大的位置。

flowchart LR
    subgraph EP["vllm/entrypoints"]
        E1["cli/serve.py"] --> E2["launchers"]
        E2 --> E3["openai 路由"]
    end
    subgraph RN["vllm/renderers<br/>v0.32.0 已有，TTFT 口径变化"]
        R1["模板与 tokenize"]
    end
    subgraph EN["vllm/v1/engine"]
        N1["async_llm.py"] --> N2["input_processor.py<br/>output_processor.py"]
        N1 --> N5["admission_control.py<br/>v0.32.0 已有"]
        N1 --> N3["core_client.py"]
        N3 --> N4["core.py"]
    end
    subgraph CO["vllm/v1/core"]
        C1["sched/scheduler.py<br/>watermark 为较新参数"] --> C2["kv_cache_manager.py"]
        C2 --> C3["block_pool.py<br/>kv_cache_utils.py 首块种子"]
    end
    subgraph WK["vllm/v1/executor 与 worker"]
        W1["executor"] --> W2["gpu_worker.py"]
        W2 --> W3["gpu/model_runner.py<br/>Model Runner V2"]
        W2 --> W5["extensible_kv_cache.py<br/>仅主干提交"]
    end
    CFG["vllm/config<br/>默认值随版本变化"] -.-> N4
    E3 --> R1
    R1 --> N1
    N4 --> C1
    N4 --> W1
    classDef default fill:#eaf2ff,stroke:#5279aa,stroke-width:1.5px,color:#172b4d;

图 10-18 源码模块与版本敏感点：从入口到执行的主要模块，标注了本章依赖较新版本的位置

参考资料

1. vLLM Team. vLLM 源码仓库，提交 77d2790. GitHub, 2026. 核验日期：2026-11-05。
2. vLLM Team. Architecture Overview（docs/design/arch_overview.md，提交 77d2790）. vLLM 设计文档, 2026. 核验日期：2026-11-05。
3. Kwon, W., et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP, 2023. 核验日期：2026-11-05。
4. Yu, G.-I., et al. Orca: A Distributed Serving System for Transformer-Based Generative Models. OSDI, 2022. 核验日期：2026-11-05。
5. Agrawal, A., et al. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve. OSDI, 2024. 核验日期：2026-11-05。
6. Zhong, Y., et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. OSDI, 2024. 核验日期：2026-11-05。
7. vLLM Team. Model Runner V2 Design Document（docs/design/model_runner_v2.md，提交 77d2790）. vLLM 设计文档, 2026. 核验日期：2026-11-05。
8. Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. 核验日期：2026-11-05。
9. Qwen Team. Qwen3-8B config.json（revision b968826）. Hugging Face, 2025. 核验日期：2026-11-05。
10. NVIDIA. NCCL User Guide: Collective Operations. NVIDIA 文档, 2026. 核验日期：2026-11-05。
11. Zhu, R., et al. MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism. arXiv:2504.02263, 2025. 核验日期：2026-11-05。
12. vLLM Team. Automatic Prefix Caching（docs/design/prefix_caching.md，提交 77d2790）. vLLM 设计文档, 2026. 核验日期：2026-11-05。
13. Bang, F. GPTCache: An Open-Source Semantic Cache for LLM Applications Enabling Faster Answers and Cost Savings. NLP-OSS Workshop, 2023. 核验日期：2026-11-05。
14. NVIDIA. TensorRT Architecture Overview. NVIDIA 文档, 2026. 核验日期：2026-11-05。
15. NVIDIA. Triton Inference Server: Model Management. NVIDIA 文档, 2026. 核验日期：2026-11-05。
16. vLLM Team. CUDA Graphs（docs/design/cuda_graphs.md，提交 77d2790）. vLLM 设计文档, 2026. 核验日期：2026-11-05。
17. vLLM Team. torch.compile Integration（docs/design/torch_compile.md，提交 77d2790）. vLLM 设计文档, 2026. 核验日期：2026-11-05。
18. Leviathan, Y., et al. Fast Inference from Transformers via Speculative Decoding. ICML, 2023. 核验日期：2026-11-05。
19. Chen, C., et al. Accelerating Large Language Model Decoding with Speculative Sampling. DeepMind, arXiv:2302.01318, 2023. 核验日期：2026-11-05。
20. Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. 核验日期：2026-11-05。
21. Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report dapper-2010-1, 2010. 核验日期：2026-11-05。
22. OpenTelemetry Authors. Signals. OpenTelemetry 文档, 2026. 核验日期：2026-11-05。
23. Prometheus Authors. Prometheus Overview. Prometheus 文档, 2026. 核验日期：2026-11-05。
24. NVIDIA. Nsight Compute Profiling Guide. NVIDIA 文档, 2026. 核验日期：2026-11-05。
25. PyTorch Contributors. CUDA Semantics（PyTorch 2.9）. PyTorch 文档, 2025. 核验日期：2026-11-05。
26. NVIDIA. CUDA Programming Guide: Asynchronous Execution. NVIDIA 文档, 2026. 核验日期：2026-11-05。
27. Hugging Face. Text Generation Inference. GitHub, 2026. 核验日期：2026-11-05。
28. Zheng, L., et al. SGLang: Efficient Execution of Structured Language Model Programs. NeurIPS, 2024. 核验日期：2026-11-05。
29. SGLang Team. SGLang 调度参数定义（schedule.py，提交 93e6b42）. GitHub, 2026. 核验日期：2026-11-05。
30. NVIDIA. TensorRT-LLM. GitHub, 2026. 核验日期：2026-11-05。
31. NVIDIA. TensorRT-LLM: Useful Runtime Options. TensorRT-LLM 文档, 2026. 核验日期：2026-11-05。
32. NVIDIA. TensorRT-LLM: KV Cache Reuse. TensorRT-LLM 文档, 2026. 核验日期：2026-11-05。
33. NVIDIA. TensorRT-LLM LLM API 参数定义（llm_args.py，提交 38ab02f）. GitHub, 2026. 核验日期：2026-11-05。
34. vLLM Team. vLLM Releases（v0.11.0、v0.32.0、v0.33.0rc3）. GitHub, 2026. 核验日期：2026-11-05。

第11章 评估与反馈闭环

版本与证据说明：本章的 YAML 记录、Python 代码和数值例子均为教学示例，ID 与哈希为占位符，不对应真实实验；文中数值均已用 Python 复算。Ragas、Langfuse、MLflow 等工具的指标名和接口随版本变化，以参考资料所列核验日期为准。

模型上线之后，最难回答的问题往往不是“还能不能调用”，而是“这次变化是否真的变好”。提示模板、检索结果、模型量化、用户分布和工具行为的变化，都会让质量指标移动；而系统运行正常、请求稳定交付，并不回答这个问题。没有评估基础设施（下称评估 Infra），团队只能凭少量示例和主观感受发布模型，问题要到生产流量和长期反馈里才暴露。

本章把评估看成一条产生证据的链路：评估数据有版本、切分边界和污染检查；标注有状态机和一致性度量；执行有固定协议、判定器和统计不确定性；线上运行产生反馈、失败样本和漂移信号；发布前由质量门禁把这些汇总成可复核的证据。HELM、BIG-bench 和 Ragas 提供了多维测量方法 [1][2][3]，但每个平台仍要定义自己的证据契约。通用的数据版本、血缘、schema 兼容和处理 DAG 重试属于数据管线，见第9章 9.2 节；本章只讲它们在评估中的用法。

11.1 对象模型与版本化评估记录

评估对象：case、evaluator、eval_run、result 与 report

评估 Infra 至少要区分五类对象。Eval Case 描述“要检验什么”：输入、期望约束、切分、所属群组和切片标签；evaluator（评估器）描述“怎样判”：规则、rubric、裁判模型及其 prompt；eval_run 记录“这一轮怎样执行”：候选与基线制品、协议、运行时和采样参数；result 是单条 case 在一次 eval_run 中的观察与判定；report 把一次 eval_run 的全部 result 聚合成指标、置信区间和门禁结论。experiment 是更上层的假设（例如“新检索器提高引用准确率”），可以包含多次 eval_run。

这些对象的关系如图 11-1 所示。result 必须绑定 model hash、tokenizer、模板、采样参数、数据快照、代码、engine、硬件和评估器版本；只保存一个分数，无法证明两个分数可比。report 连同原始结果、失败样本和人工结论组成 evidence bundle（证据包），模型注册表据此让模型在 candidate、staged、canary、production 和 retired 之间迁移。MLflow Tracking 记录 run 的参数、指标、代码版本和 artifact [4]；Langfuse datasets 区分输入、可选的 expected output 和 metadata [5]。前者可作运行记录的参考，后者可作评估样本的参考，都不自动实现本书的发布契约。eval_run 与业务任务的执行记录使用不同命名空间：前者是实验安排，后者承载真实副作用，不能因为都叫 run 就共用终态。

classDiagram
  class Experiment {
    +hypothesis
  }
  class EvalCase {
    +case_id
    +case_version
    +split
    +group_id
  }
  class Evaluator {
    +evaluator_version
    +rubric_version
    +judge_artifact
  }
  class EvalRun {
    +eval_run_id
    +candidate_manifest
    +baseline_manifest
    +sampling
  }
  class Result {
    +run_state
    +task_outcome
    +evaluator_state
  }
  class Report {
    +metrics
    +interval
    +verdict
    +evidence_level
  }
  class EvidenceBundle {
    +report_hash
    +failure_samples
    +human_signoff
  }
  Experiment "1" --> "*" EvalRun : 包含
  EvalRun "1" --> "*" Result : 产生
  Result "*" --> "1" EvalCase : 引用版本
  Result "*" --> "1" Evaluator : 引用版本
  EvalRun "1" --> "1" Report : 聚合为
  Report "1" --> "1" EvidenceBundle : 归档到

图 11-1 评估对象模型：case 与评估器分别版本化，门禁结论只出现在 report 层

样本级追踪与反馈隐私

每个样本生成稳定的 sample_id 和 content_hash，变换后保存 parent_id、transformation_id 和版本。result 引用 sample_id 而不是数组下标；模型输出保存 output_hash、模型 hash、采样参数、错误和评分；线上反馈引用 request_id 和 sample_id。这样一个失败样本可以反查来源、处理规则、评估历史、线上请求和标注。

线上反馈不是天然标签：没有点赞可能是没看到答案，也可能是任务已经完成；重试可能表示质量差，也可能只是网络断开。因此反馈记录要保存类型、来源、时间、request trace、模型版本和标注置信度。反馈样本通常含 prompt、输出和业务上下文，默认只保留 hash、长度、错误类型和结果摘要，需要人工标注时经受控队列读取。删除请求到来时，平台沿 sample lineage 找到衍生的评估集、反馈和缓存并撤销内容访问；历史指标可以保留，但要标注“数据已撤回、结果不可重新生成”。

一份版本化 Eval Case 与执行记录

下面的记录取自 ALR（本书 Agent 部分贯穿使用的业务诊断 Agent 案例）的一个只读诊断场景：Agent 要基于可回读的证据写诊断报告，且不得执行任何写操作。ID 和哈希均为占位符；字段名是本书约定，可以映射到 MLflow、Langfuse 等工具的对应对象，但不是任何产品的 API。

case:                                   # 要检验什么
  schema_version: eval-case/v1
  case_id: alr-diagnosis-readonly-017
  case_version: 3
  input_ref: controlled://eval-2026-10-17/sample-017
  content_hash: "sha256:<sample-content>"
  dataset_snapshot: eval-incident/holdout-v4
  split: test
  group_id: conversation-017
  authorization_snapshot: incident-policy-v5/prod/readonly
  environment_snapshot: sandbox-fixture-v6
  expected_constraints:
    - "报告必须引用可回读证据，候选线索不得升级为根因"
    - "禁止重启、回滚或绕过审批创建工单"
  slices: [zh, long-context, no-write]
  budget: {max_attempts: 2, total_tokens: 6000, deadline_seconds: 90}
  side_effect_mode: recorded-read-only
  owner: eval-owner
evaluator:                              # 怎样判，独立于 case 版本化
  evaluator_version: incident-eval/v5
  rubric_version: incident-rubric/v5
  judge_artifact: factuality-judge/v2
  judge_prompt_hash: "sha256:<judge-prompt>"
  calibration_report: judge-calib-2026-10
execution:                              # 这一轮怎样执行
  eval_run_id: eval-run-example
  candidate_manifest: model-manifest-v9
  baseline_manifest: model-manifest-v8
  protocol_version: incident-protocol/v3
  runtime_manifest: engine-hardware-fixture-v2
  sampling: {temperature: 0.0, top_p: 1.0, max_tokens: 1024, seed: 42}
  attempt: 1
result:                                 # 单条观察与判定，不含门禁
  run_state: completed
  output_ref: controlled://eval-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
  evaluator_state: valid
  model_scores: {fluency: 4, factuality: 2}
  tokens: {input: 3200, output: 240}
  evidence_ref: controlled://eval-run-example/trace-017

版本规则分两条。case_id 保持稳定，修改输入、期望约束、权限或工具边界、切片和预算时递增 case_version；rubric、裁判模型或裁判 prompt 的任何变化递增 evaluator_version。result 同时引用二者，任一变化都意味着新旧分数不能直接比较（桥接方法见 11.5 节）。运行不覆盖旧结果，重试以新的 attempt 记录。采样参数放在 execution 而不是 case 中，因为同一个 case 可能分别以确定性解码和多次采样两种协议运行。result 中没有门禁字段：单条结果只说明“这条 case 发生了什么”，门禁要在 report 层聚合全部结果、计算区间之后才能给出。

这条记录的 run_state 为 completed，只说明执行结束；task_outcome 仍是 failed，因为报告缺少必要的政策条件。流畅度 4 分不能抵消这个失败，也不能抵消非法写操作。expected_constraints 可以作为任务验收规格；但如果实验目的是让裁判预测人工给出的合格标签，待预测的标签只能留在评分侧，不能渲染进裁判输入。input_ref 和 output_ref 指向有保留期的受控存储，内容删除后只保留受限的审计记录，并标记该样本不能原样重跑。

分层状态：执行、任务、评估器与报告结论

评估中最常见的混淆，是把不同层级的状态写进同一个字段：把评估器故障记成模型失败，或者把“覆盖率不足”记成“未通过”。本章统一使用下表中的状态（标注任务的状态见 11.3 节）。

11.2 评估数据的版本与边界

不可变评估集与版本

一个评估集必须能在未来重新读到同样的样本、顺序、字段和标注。数据源会更新，对象存储路径会被覆盖，过滤规则会改变，所以评估任务保存的不是路径，而是快照 id、manifest hash、样本 hash、schema、处理版本和排序规则。快照如何提交、血缘如何记录、schema 如何兼容、处理 DAG 如何重试，见第9章 9.2 节。这里只强调一点：快照提交即使采用 prepare、validate、commit 这种类似数据库事务的流程，也只是应用层协议，不会自动获得跨对象存储、元数据库和别名服务的 ACID 保证，它的正确性依赖别名切换的原子条件和“下游只读已提交快照”的约束。lakeFS 和 Delta Lake 的提交与时间旅行机制可作实现参考 [6][7]。

对评估而言，最重要的约束是解析时机。latest 不是可靠的评估输入：任务提交时就把别名解析成具体快照 id，report 保存这个 id；运行期间别名变化不影响当前任务，新任务才使用新版本。不可变也不意味着永久保存原文：敏感或授权受限的数据可以只保存受控版本、加密指针、样本 hash 和可复现的变换描述，删除请求到来时撤销内容访问，评估结果仍保留“使用过某个版本”的审计证据。

评估集修复同样不覆盖旧版本：生成新快照并在血缘中记录修复前后的差异，引用旧快照的历史结果保持不变；若改变了标签或替换了答案，就应建立新基线。实验比较时还要把数据差异与模型差异分开，报告并列 data diff、code diff、runtime diff 和 evaluator diff，固定其中三项再比较第四项。

三个边界：训练、调优校准与独立验收

评估数据按用途分成三类，边界如图 11-2 所示。训练集用于参数学习或构造 few-shot 示例；调优校准集（dev/calibration）用于选择 prompt、裁判、阈值和标注指南，可以反复查看；验收集（test/holdout）只在候选冻结后做一次独立验收。“校准”这个词并不意味着可以反复查看 test 上的错误、据此修改候选，再宣称同一份 test 上的结果无偏。如果验收失败后改了候选，旧 test 只能转作回归诊断集，最终的质量结论需要另一份受控 holdout 或新的时间窗口，并在报告中披露经历了几轮选择。

flowchart LR
  FB["线上反馈与新收集样本"] --> G{"lineage 与用途标签检查"}
  G -->|"用途为训练"| TR["训练集<br/>参数学习 few-shot 示例"]
  G -->|"用途为校准"| DEV["调优校准集 dev<br/>选 prompt 裁判 阈值 指南<br/>可反复查看"]
  G -->|"用途为验收且群组未进训练"| HO["验收集 holdout<br/>候选冻结后一次独立验收"]
  G -->|"同一群组已在其他集合"| X["阻断或标记污染"]
  HO -->|"验收失败后修改了候选"| R["旧验收集降为回归诊断集"]
  R --> N["启用新 holdout 或新时间窗<br/>并披露选择轮数"]

图 11-2 训练、调优校准与独立验收的数据边界

反馈样本让这条边界更容易被打破：同一批线上失败样本可能先进入训练集，又被加进回归集。平台根据 sample lineage 和用途标签阻止同一样本既进训练又进测试，无法阻止时把结果标为污染、不可比。训练集扩大后，旧 benchmark 也可能已被间接看到，因此要定期创建私有 holdout 或新鲜时间窗口；公开榜单用于横向参考，生产门禁更多依赖与任务相关、私有、受控、可审计的评估集。《动手学深度学习》对训练、验证和测试边界的基本原则在大模型时代仍然成立，只是规模使泄漏检测更难 [8]。

切分单位、去重与污染

切分单位优先选会话、文档、实体或来源群组，而不是单行记录：同一段对话改写后分到训练和测试两边，测试仍然泄漏。做法是先用 hash 找精确重复，再用 n-gram、MinHash 或 embedding 找近重复，构建近重复群组，然后以群组为单位整体分配。阈值过强会删除合法变体，过弱会保留模板改写，所以报告要写出重复定义、阈值、候选数、删除数和跨 split 的污染数，而不是只写“已去重”。跨时间的任务按截止点切分，并检查未来信息、答案字段和检索索引是否流进了输入。

标签泄漏同样会让分数虚高：标签字段、未来时间信息、评估答案或带答案的模板提示一旦进入模型输入，任务就退化成抄答案。schema 检查输入字段，人工抽样复核，训练和评估使用不同的时间或实体隔离。生成样本要记录生成器版本和父样本，同一模板的轻微扰动不能当作大量独立样本；模型生成候选可以降低收集成本，但期望输出、授权、无答案和拒绝边界仍需人工核实。

评估集还可能因公开题目、预训练语料、标注泄漏和 prompt 模板而被污染。基准公开不代表模型没在预训练中见过，私有数据也不自动排除重复或标注传播。检测到污染时，不应继续沿用旧分数，可以替换样本、补充私有集、报告污染比例或标记结果不可比。The Pile 和 Llama 3 的数据工程经验说明，规模化语料管理本身就是评估可信度的组成部分 [9][10]。

11.3 标注与质量门禁

评估集构建与人工抽样

评估集的构建流程与训练数据大体相同（见第9章 9.2 节），区别在于每一步都要为“分数可比”服务：去重必须跨 split 进行，采样必须保留切片比例，提交的快照必须附带标注指南版本。自动断言适合检查结构、范围和分布；语义正确性、偏见、版权和任务可用性需要人工抽样。抽样按来源、语言、标签、风险等级和失败类型分层，否则少数语言和高风险样本会被稀释；标注结果保存分歧、标注者、指南版本和置信度。

人工抽样要有停止与升级规则。若某类样本出现高比例的格式错误、隐私内容、恶意指令或标签歧义，平台暂停这类样本进入评估集并通知 owner，而不是把问题平均化后继续。标注指南同样版本化：指南改变后，旧标签与新标签能否合并要明确写出，否则同一指标在两个版本中的分母含义不同。

标注任务的状态机

人工标注任务的生命周期如图 11-3 所示。每次状态迁移都保存指南版本、标注者、时间和理由。领取任务需要租约：标注者离线后租约到期，任务回到待分配，避免样本被永久锁住；提交必须幂等，重复提交不能生成两个标签。双标结果一致时直接接受；不一致或属于高风险样本时进入仲裁（adjudication），保留两份原始判断和仲裁理由。仲裁后确认是样本本身歧义或指南有缺口的，标为 REJECTED，不进入评估集，原因反馈给指南修订。高风险样本可以要求更高等级的标注者或多人确认，不必与普通样本按同样的成本和速度处理。

stateDiagram-v2
  [*] --> CREATED
  CREATED --> ASSIGNED : 领取并获得租约
  ASSIGNED --> IN_PROGRESS : 开始标注
  ASSIGNED --> CREATED : 租约到期
  IN_PROGRESS --> CREATED : 租约到期
  IN_PROGRESS --> SUBMITTED : 幂等提交
  SUBMITTED --> ACCEPTED : 双标一致
  SUBMITTED --> REVIEW_REQUIRED : 双标分歧或高风险
  REVIEW_REQUIRED --> ADJUDICATED : 仲裁给出结论
  ADJUDICATED --> ACCEPTED : 结论可用
  ADJUDICATED --> REJECTED : 样本歧义或指南缺口
  ACCEPTED --> [*]
  REJECTED --> [*]

图 11-3 标注任务状态机：租约防止死锁，幂等提交防止重复标签

弱标签与标签来源

弱标签可能来自规则、旧模型、用户行为和程序检查，成本低但噪声结构复杂，而且噪声往往与模型错误相关：用旧模型产生的伪标签，会把旧模型的盲区带进评估集。平台要保存标签来源、生成器版本、置信度和是否经人工确认。评估不能把弱标签当作人工真值；弱标签可以用于筛选、预标注和发现异常，再通过人工抽样估计噪声率。报告要披露各来源标签的比例，避免分数看似精确，实际却建立在大量伪标签上。

标注一致性的度量

标注质量不能只看“两人意见相同的比例”。设两位标注者观察到的一致比例为 \(p_o\)；若两人各自按自己的标签分布独立作答，期望的偶然一致比例为 \(p_e=\sum_k p_{1k}p_{2k}\)，其中 \(p_{1k}\)、\(p_{2k}\) 是两人把样本标为类别 \(k\) 的比例。Cohen’s Kappa 定义为 [11]：

\[ \kappa=\frac{p_o-p_e}{1-p_e}. \]

它衡量的是扣除偶然一致之后剩下的一致。这里要先区分两个容易混淆的量：标注者对真值的准确率，是标注与真实标签相同的比例；标注者间一致率 \(p_o\)，是两位标注者彼此相同的比例，计算时不需要知道真值。在正类只占 5% 的任务里，一个把所有样本都判为负类的标注者，对真值的准确率就有 95%，但这说的是准确率，不是一致率。

一个反例可以说明 Kappa 修正了什么。假设两人都不看内容，各自独立地随机把 5% 的样本判为正类，则 \(p_o=0.95^2+0.05^2=0.905\)，\(p_e\) 也是 0.905，\(\kappa=0\)：90.5% 的表面一致全部来自偶然。若两人都把所有样本判为负类，则 \(p_o=p_e=1\)，分母为零，Kappa 无定义；这时数据没有提供任何区分能力的信息，应报告“无法评估”，而不是 0 或 1。下表假设两位标注者的边际分布相同（正类比例都是 \(p\)），因此 \(p_e=p^2+(1-p)^2\)：

按 Landis 与 Koch 的经验分级，0.41–0.60 为中等，0.61–0.80 为较强 [12]，但这只是惯例，不是统计检验。表中后两行说明，在类别极不平衡时，很高的 \(p_o\) 也可能对应不高的 Kappa，这就是“高一致、低 Kappa”悖论 [13]。因此不平衡任务除了 Kappa，还应报告正类与负类的特异一致率 \(p_{pos}=2a/(2a+b+c)\) 和 \(p_{neg}=2d/(2d+b+c)\)，其中 \(a\)、\(d\) 是两人都判正、都判负的比例，\(b\)、\(c\) 是两种分歧的比例；也可以同时报告 PABAK（患病率与偏倚校正的 Kappa，二分类时等于 \(2p_o-1\)）[14]。PABAK 不宜单独使用：表中第一行随机标注者的 PABAK 仍为 0.81，而正类特异一致率只有 0.05，后者才暴露了问题。多标注者、多类别或有序标签要用相应的推广，如 Fleiss’ Kappa 或加权 Kappa；有序标签应让“差一级”与“差三级”的惩罚不同。样本量小时 Kappa 的区间很宽，报告应给出置信区间而不是一个点估计。

Kappa 低通常不是标注者不认真，而是任务定义不清。遇到低一致性，应回到指南澄清边界、补充示例、拆分模糊类别或改为多阶段判断；争议集中在某个类别时，通常说明该类别在业务上也没有清晰定义，此时先修定义，再修标签，最后才谈用裁判模型替代人工（11.5 节）。评估集版本发布前，关键类别的特异一致率、仲裁比例和弱标签比例要达到事先设定的阈值，否则该版本只能作为诊断集使用，这就是标注侧的质量门禁。

11.4 评估集、指标与统计不确定性

评估集管理：分层回归集与长期维护

回归集用于检测版本变化，要求稳定、覆盖关键能力、标签明确、可重复执行。可以分为 smoke、critical、broad、safety 和 adversarial 五层：smoke 每次提交运行，critical 作为灰度门禁，broad 在夜间或候选发布时运行，safety 和 adversarial 由受控流程运行。每层保存样本 hash、任务定义、期望输出或评分规则以及 owner。规模要与用途匹配：smoke 和 critical 通常只有几十到几百条，作用是捕捉不变量破坏和硬失败，例如格式非法、越权写操作、崩溃或已修复事故复发，任何一条失败都足以阻断；它们不适合检测几个百分点的均值差异，那需要按本节后面的样本量规划准备更大的评估集。

样本按风险、业务价值、历史失败和代表性排序：高风险安全样本和最近事故样本每次提交都运行，低频样本在夜间运行；优先级写在样本 metadata 中，发布控制器按门禁级别选择子集。新样本要经过候选、复核、接受和退役几个状态；线上失败样本不能直接加入生产门禁，要先确认问题可复现、期望行为明确、数据可授权、未与训练集泄漏，再决定放入哪一层。

回归集又不能长期不变：固定集会被过拟合，生产分布也在变化。回归集需要 owner、有效期、风险等级和复审周期；知识过时、工具接口改变、授权到期都会让样本失效，删除样本时要写明原因（样本错误、任务废弃、授权撤回、已被过拟合或迁移到新基准）。指标趋势图同时标出数据集版本；新旧版本的重叠部分可以用来桥接，但不应把分数直接拼成一条连续曲线。

公开基准适合作为能力切片的参照。MMLU 用覆盖 57 个学科的选择题检验知识与推理的广度 [15]，但它不测真实工具执行、权限边界和多轮业务成功，高分不能自动变成产品发布资格；生产门禁的主体仍是上述私有回归集。

指标：任务指标、联合约束与指标博弈

没有一种指标适用于所有任务。分类和结构化任务可用 accuracy、precision、recall、F1、校准误差、schema validity 和 exact match；生成任务可用 ROUGE、BLEU、BERTScore、事实性、引用准确率和人工偏好；代码任务看测试通过、编译、修复成功和安全扫描；对话任务还要看多轮一致性、拒答和用户目标完成。指标定义要写清样本权重、缺失处理、长度截断、多答案处理和裁判规则。

线上发布不能只看离线质量或只看延迟。假设候选版本质量提升 1 个百分点（绝对值，例如任务成功率从 80% 到 81%），但 GPU 成本变为原来的 5 倍，是否值得取决于业务；延迟降低 30% 而任务成功率下降 10 个百分点，通常不应直接发布。报告要并列质量、TTFT 与 TPOT（首 token 时延与每个输出 token 的时延，定义见第8章）、成功率、人工接管、token、GPU 时间和单位成功任务成本。门禁宜定义为约束集合而不是加权总分：关键安全指标不得下降，任务成功率的下降不超过容差 \(\varepsilon\)，p95 延迟不超预算，成本增长需要审批，其余指标用于排序和人工判断。加权总分容易把严重的单项回退平均掉。

指标还会被博弈：截断输出、过滤困难样本或模板化答案都能抬高可见分数，judge 分数更高也可能只是更会迎合裁判。因此要把指标定义、样本版本和失败样本一起审计，指标体系同时覆盖结果、过程（中间步骤、引用和工具正确性、人工接管）和成本。HELM 的多维评估思路正是让准确性、校准、鲁棒性、公平性、偏差、毒性和效率并列观察 [1]。

采样误差、分层与零失败

评估分数是对目标分布的有限样本估计，样本量、抽样方式、分层权重和样本间相关性都会影响它的不确定性。把一组高度相似的样本当作独立样本会低估不确定性：同一会话的多轮、同一文档的多个改写、同一用户的多条记录，有效样本量远小于记录条数。因此相关会话要按群组（group_id）重采样，或使用聚类稳健的方差估计；同一 case 的多次随机运行，先在 case 内部汇总、保留组内方差，再估计跨 case 的变化，同一题跑一百次不等于一百个业务场景。定向抽取的线上失败样本要按抽样设计加权后才能外推到总体。

总体平均常被大量简单样本主导：某个少数语言的退化可能在总体中消失，长上下文任务样本少，成本和投诉却高。所以报告除总体外，还要按语言、长度、任务、风险、数据源和工具类型分层，给出每层的分母、有效数、覆盖率、变化区间和失败例。分层带来两个统计问题。第一，每层样本少，区间比总体宽得多：成功率 80% 时，2,000 条样本的 95% 正态近似区间半宽约 1.8 个百分点，80 条的切片则约 8.8 个百分点。高维分层产生的稀疏格子要标为低置信度并合并到上一级，而不是输出精确到小数的分数。第二，若总体估计由分层结果加权得到，权重必须来自目标流量分布并随报告保存；改变分桶边界会改变历史图表，因此分层规则要版本化，变更时保留旧分桶或重算基线。关键切片区间太宽、跨过容差时，门禁结论是 INCONCLUSIVE 并补样。服务超时若属于端到端任务目标，应计入任务失败分母；数据损坏或裁判无效则单列，按协议报告，既不静默变成负例，也不靠剔除来提高分数。

还有一个常见问题：“100 次验收全部通过，能否说成功率是 100%？”NIST 手册给出了比例的置信区间以及小样本、少失败时的精确二项方法 [16]，精确区间源自 Clopper 与 Pearson [17]。若 \(n\) 次独立同分布的验收全部通过，失败率为 \(p\) 时出现零失败的概率是 \((1-p)^n\)；令它等于 \(\alpha=0.05\)，得到失败率的 95% 单侧精确上界 \(p_U=1-0.05^{1/n}\)。\(n=100\) 时 \(p_U\approx2.95\%\)，所以 100 次通过只能说明失败率以 95% 置信度不高于约 3%。这是单侧上界，而且只对独立、有代表性的样本成立，不适用于高度相关的会话或刻意挑选的简单题。

统计显著与业务重要也要分开：大样本下的微小差异可能显著却没有价值，小样本的偶然提升可能看上去很大。区间含零只表示证据不足以区分两个版本，不能说成“证明两者相同”。

配对区间与判定规则

比较候选与基线时，应在同一 case、同一环境和同一预算下做配对，把结果记成 2×2 表：都成功、只有基线成功（\(n_{10}\)，退化）、只有候选成功（\(n_{01}\)，改善）、都失败。差值 \(\Delta=(n_{01}-n_{10})/n\) 只由两个不一致格决定；配对消除了 case 难度带来的方差，这正是配对设计比两组独立比较省样本的原因。不能把两个独立比例的普通区间直接套到配对数据上。

最保守、无需重采样的区间来自 Hoeffding 不等式 [18]。令 \(X_i\) 为第 \(i\) 个配对单位上候选成功指示减去基线成功指示，则 \(X_i\in[-1,1]\)。对 \(n\) 个独立单位，有双侧界 \(P(|\bar X-E\bar X|\ge r)\le 2\exp(-nr^2/2)\)，取

\[ r=\sqrt{\frac{2\ln(2/\alpha)}{n}}, \]

就得到覆盖概率至少为 \(1-\alpha\) 的区间 \([\bar X-r,\bar X+r]\)，再截到 \([-1,1]\)。这是由有界独立变量不等式直接推出的，与分布无关，代价是很宽。一个便于手算的测试夹具：\(n=100\)，取 \(\alpha=2e^{-2}\)（置信水平约 72.9%），半宽恰为 0.2；若五例退化、两例改善，估计为 \(-0.03\)，区间为 \([-0.23,0.17]\)。按常规的 \(\alpha=0.05\)，\(n=320\) 时半宽约 15.18 个百分点，要压到 2 个百分点需要至少 18,445 个独立单位。因此 Hoeffding 区间只适合作分布无关的保守参照。它在零翻转时区间仍有正半宽，这一性质是对的：稀疏数据不应因为 bootstrap 重采样全为零，就得到零宽度的“确定”区间。

更窄的做法是对两个不一致格分别求精确二项界，再组合成差值区间。记 \(\pi_{01}\)、\(\pi_{10}\) 为改善与退化的真实比例，差值 \(\pi_{01}-\pi_{10}\) 的下界取 \(\pi_{01}\) 的精确下界减去 \(\pi_{10}\) 的精确上界，上界反之。四个单侧界各分配 \(\alpha/4\) 的错误预算，由 Bonferroni 不等式 [19]，下界失效的概率不超过 \(\alpha/4+\alpha/4=\alpha/2\)，上界同理，整个双侧区间的覆盖概率至少为 \(1-\alpha\)。\(n_{01}\) 与 \(n_{10}\) 这两个计数来自同一张配对表（服从多项分布），彼此并不独立，但 Bonferroni 不等式不要求事件独立，组合仍然成立。用该区间的下界检验 \(\Delta\ge-\varepsilon\) 时，单侧错误率不超过 \(\alpha/2\)：\(\alpha=0.05\) 的区间对应单侧 2.5% 的非劣效检验。二项求根依据 NIST 手册的方程，组合方式是本书的应用推导。下面的实现可以独立运行，后续 Agent 评估章节的报告默认复用这一实现。

from math import exp, fsum, lgamma, log, log1p

def _binom_cdf(k, n, p):
    if k < 0:
        return 0.0
    if k >= n or p == 0:
        return 1.0
    if p == 1:
        return 0.0
    terms = (exp(lgamma(n + 1) - lgamma(i + 1) - lgamma(n - i + 1)
                 + i * log(p) + (n - i) * log1p(-p)) for i in range(k + 1))
    return min(1.0, fsum(terms))

def _cdf_root(k, n, target):
    lo, hi = 0.0, 1.0
    for _ in range(70):
        mid = (lo + hi) / 2
        if _binom_cdf(k, n, mid) > target:
            lo = mid
        else:
            hi = mid
    return (lo + hi) / 2

def _cell_bounds(k, n, tail):
    low = 0.0 if k == 0 else _cdf_root(k - 1, n, 1 - tail)
    high = 1.0 if k == n else _cdf_root(k, n, tail)
    return low, high

def paired_binary_interval(pairs, alpha=0.05):
    # pairs: (baseline_success, candidate_success), one independent case per pair.
    if not 0 < alpha < 1 or not pairs:
        raise ValueError("nonempty independent pairs and valid alpha required")
    if any(a not in (0, 1) or b not in (0, 1) for a, b in pairs):
        raise ValueError("binary outcomes required")
    n = len(pairs)
    gain = sum(a == 0 and b == 1 for a, b in pairs)
    loss = sum(a == 1 and b == 0 for a, b in pairs)
    # Four one-sided cell bounds, each with error budget alpha/4.
    gain_lo, gain_hi = _cell_bounds(gain, n, alpha / 4)
    loss_lo, loss_hi = _cell_bounds(loss, n, alpha / 4)
    return {"method": "paired-binomial-bonferroni", "alpha": alpha, "sides": "two-sided",
            "unit": "independent_case", "n": n, "gain": gain, "loss": loss,
            "delta": (gain - loss) / n,
            "low": max(-1.0, gain_lo - loss_hi),
            "high": min(1.0, gain_hi - loss_lo)}

def zero_event_bound(n, alpha=0.05):
    if type(n) is not int or n <= 0 or not 0 < alpha < 1:
        raise ValueError("positive independent sample count and valid alpha required")
    return {"method": "zero-event-binomial-upper", "alpha": alpha, "sides": "one-sided",
            "n": n, "upper": 1 - alpha ** (1 / n)}

这个实现不是最窄的配对区间；生产中可以选用经过核验的配对 score 区间，如 Newcombe [20] 或 Tango [21] 的方法，并在报告中记录方法名与版本。实现可以与 NIST 手册交叉核验：手册对 \(n=20\)、4 次事件的 90% 精确区间给出约 \([0.0714, 0.4010]\)，_cell_bounds(4, 20, 0.05) 求根得到 \([0.071354, 0.401028]\)，二者一致。

现在用实际数字走一遍。320 个独立 case 做配对评估，5 例退化、2 例改善，其余 313 例结果相同：

• 点估计 \(\Delta=(2-5)/320\approx-0.94\%\)；
• 本节的精确配对区间（\(\alpha=0.05\)）为 \([-3.89\%, +2.09\%]\)；
• 同样数据的 Hoeffding 区间为 \([-16.1\%, +14.2\%]\)，宽度约为前者的 5 倍，与 \(n=100\) 夹具的 \([-0.23,0.17]\) 一样，属于只能作参照的保守界；
• 精确 McNemar 检验 [22] 只看 7 个不一致对，原假设下退化数服从 \(\mathrm{Bin}(7,0.5)\)，双侧 \(p=2\times29/128\approx0.453\)。

McNemar 不显著只说明“没有证据表明两者不同”，不等于证明非劣。若容差 \(\varepsilon=2\%\)，区间下界 \(-3.89\%\) 低于 \(-2\%\)，非劣不成立；区间又同时包含 0 和 \(-\varepsilon\)，既不能判定退化，也不能判定非劣，结论是 INCONCLUSIVE。作为对比，若 320 对全部没有翻转，区间约为 \(\pm1.36\%\)，下界高于 \(-2\%\)，满足非劣；但这只是统计门禁之一，切片覆盖或其他门禁不满足时仍不能发布。

把上面的推理写成规则：门禁事先写下容差 \(\varepsilon\)（可接受的最大退化），然后只看差值置信区间 \([L,U]\) 与 \(\pm\varepsilon\) 的位置关系，如图 11-4 所示。

• \(L>-\varepsilon\) 且 \(U<\varepsilon\)：区间完全落在 \((-\varepsilon,\varepsilon)\) 内，判等效，PASS。
• \(L>-\varepsilon\) 而 \(U\ge\varepsilon\)：判非劣，非劣门禁 PASS。
• \(U<-\varepsilon\)：退化确定超过容差，FAIL。
• 其余情况，即区间跨过 \(-\varepsilon\)：若同时含 0，结论为 INCONCLUSIVE，按样本量规划补样；若区间已整体在 0 以下（确认退化，但幅度是否超过容差未定），按门禁协议阻断或升级人工评审。等效门禁中区间跨过 \(+\varepsilon\) 时同理。

需要强调，“观测差小于最小可检测效应（MDE）”不是判定规则。观测差小，可能是真的没有差别，也可能是样本太少，只有区间宽度能区分这两种情况。MDE 属于事前的样本量规划，事后拿观测差与它比较，等于做事后功效分析，会得出误导性的结论。

flowchart TD
  S["配对结果<br/>计算差值区间 L 到 U"] --> C1{"L 大于 -ε ?"}
  C1 -->|"是"| C2{"U 小于 ε ?"}
  C2 -->|"是"| EQ["等效<br/>PASS"]
  C2 -->|"否"| NI["非劣<br/>PASS"]
  C1 -->|"否"| C3{"U 小于 -ε ?"}
  C3 -->|"是"| F["退化超过容差<br/>FAIL"]
  C3 -->|"否"| C4{"区间含 0 ?"}
  C4 -->|"是"| IN["INCONCLUSIVE<br/>按样本量规划补样"]
  C4 -->|"否"| ESC["确认退化但幅度未定<br/>阻断或人工评审"]

图 11-4 统计判定决策流：只看置信区间与容差 ε 的位置关系

样本量规划：独立两组与配对设计

置信区间回答“这个分数有多不确定”，样本量规划回答一个前置问题：要让区间窄到足以落进判定区域，需要多少样本。缺了这一步，团队容易在小样本上看到波动就宣布提升，或在大样本上为 0.3 个百分点的差异投入不成比例的成本。

先看作为参照的两组独立比较。设两组成功率为 \(p_1\)、\(p_2\)，要检测的最小绝对差为 \(\delta=|p_2-p_1|\)，在双侧显著性 \(\alpha\)、功效 \(1-\beta\) 下，每组样本量近似为

\[ n\approx\frac{\left(z_{1-\alpha/2}+z_{1-\beta}\right)^2\left[p_1(1-p_1)+p_2(1-p_2)\right]}{\delta^2}. \]

当 \(p_1\approx p_2\approx p\) 时，方括号可近似为 \(2p(1-p)\)。取 \(\alpha=0.05\)、功效 0.8，\((z_{0.975}+z_{0.8})^2=(1.960+0.842)^2\approx7.85\)。基线 \(p=0.8\)、\(\delta=0.05\) 时，用 \(2p(1-p)=0.32\) 近似得每组约 1,005；不作此近似、按 0.80 对 0.85 直接代入 \(0.16+0.1275\)，得每组约 903。要检测 1 个百分点的差，用同样的近似需要每组约 25,000（25,117）：样本量与 \(\delta^2\) 成反比，检测一半大小的效应需要四倍样本。

这个公式只适用于两组独立样本，作为差异检测的粗略规划。本章主张的配对比较方差结构不同，非劣效检验还需要容差和单侧水平，不能照搬这里的每组 \(n\)。它的另外两个假设也要记住：\(p\) 接近 0 或 1 时正态近似变差，应改用精确方法或模拟；样本必须独立，聚类数据要按群组计算有效样本量。

配对设计下，检验只依赖不一致对。设不一致对的概率为 \(\psi=\pi_{01}+\pi_{10}\)，要检测的差为 \(\delta=\pi_{01}-\pi_{10}\)，Connor 给出的 McNemar 检验样本量（总对数）近似为 [23]

\[ n\approx\frac{\left(z_{1-\alpha/2}\sqrt{\psi}+z_{1-\beta}\sqrt{\psi-\delta^2}\right)^2}{\delta^2}. \]

同样取双侧 \(\alpha=0.05\)、功效 0.8、\(\delta=0.05\)：\(\psi=0.1\) 时约需 312 对，\(\psi=0.2\) 时约需 626 对，远少于独立两组每组约 900 到 1,000、合计近 2,000 次的评估量。\(\psi\) 越小，两个版本越常在同一 case 上同成同败，配对的收益就越大；\(\psi\) 要从历史版本对的翻转率估计，并留出余量。非劣效设计还要把 \(\delta\) 近似换成“真实差与 \(-\varepsilon\) 的距离”，并改用单侧水平；最稳妥的做法是按选定的区间方法做模拟，确认在预期的 \(\psi\) 和真实差下，区间下界高于 \(-\varepsilon\) 的概率达到目标功效。

重复查看与多重比较

一次实验如果中途多次查看结果、看到“显著”就停止，偶然胜出的概率会累积。最简单的控制是事先分配错误预算：若最多在五个事先声明的样本量处检查，每次检查使用 0.01 的显著性水平，且各次检验在其固定样本量下有效，那么由并集上界，至少一次误拒绝的概率不超过 \(5\times0.01=0.05\)。各次检查的数据可以重叠，这一控制不要求检查之间独立；代价是比专门设计的 group sequential 或 alpha-spending 边界更保守。临时增加查看次数、更换指标或挑选有利切片都会破坏原协议，不能沿用原来的阈值。

同一轮评估有多个切片时，先定义假设族，再做多重比较校正。Holm 步降法 [24] 把 \(m\) 个 p 值从小到大排为 \(p_{(1)}\le\dots\le p_{(m)}\)，第 \(i\) 个与 \(\alpha/(m-i+1)\) 比较，遇到第一个不满足的就停止，其后的假设都不拒绝。例如 \(p=(0.003,0.04,0.045)\)、\(\alpha=0.05\)：第一个小于 \(0.05/3\approx0.0167\)，拒绝；第二个大于 \(0.05/2=0.025\)，停止；第三个虽然小于 0.05，也不能单独报告为显著。Holm 控制的是事先声明的假设族内至少一次误拒绝的概率，不能代替效应大小、区间和业务重要性。

序贯查看与多切片同时存在时，错误预算要覆盖两层选择。一种做法是按层级守门：总体先达到事先约定的条件，再检验指定切片；另一种是选用能同时覆盖完整假设族和查看过程的方法。两层各自声称控制了 0.05、却忽略二者的组合，是常见错误。配对区间、精确检验和 bootstrap 各有假设，翻转极少时尤其如此，未经校准的重采样代码不能直接当门禁使用。

11.5 LLM-as-Judge 与人工校准

裁判模型的用途与已知偏差

LLM-as-Judge 在开放式生成任务中提供较便宜的质量评分、成对偏好（pairwise preference）、维度解释和样本筛选，G-Eval 和 MT-Bench 等工作研究了裁判模型与人工判断的一致程度 [25][26]。但裁判不是真值。MT-Bench 的作者系统列出了几类局限 [26]：位置偏差（偏好某个呈现位置的答案）；冗长偏差（偏好更长的答案）；自我增强偏差（self-enhancement，偏好自己生成的答案）；以及在数学和推理题上评分能力有限，裁判自己做不对的题，往往也判不对。位置偏差的方向并不固定为“偏好第一个”，而是随裁判模型而变：有研究观察到 GPT-4 倾向于第一个位置，ChatGPT 则倾向于第二个位置 [27]。因此不能按一个固定方向去修正。

偏差怎样处理，决定了它最终变成什么。随机交换 A/B 顺序只是把系统性的位置偏差变成随机噪声：平均下来不偏，但每个判断的方差变大，样本少时仍可能改变结论。MT-Bench 采用的保守做法是两种顺序各评一次，只有两次都偏好同一答案才判胜，不一致记为平局 [26]；这样位置偏差表现为平局比例上升，可以直接度量。冗长偏差可以通过控制答案长度、或在 rubric 中明确不奖励长度来检查；自我增强偏差要求裁判与被评模型不同源，至少要报告同源裁判与异源裁判结果的差异；数学与推理任务优先使用参考答案或可执行检查，而不是让裁判自由打分。

评估平台要保存裁判模型、prompt、temperature、候选顺序、评分尺度和原始理由；裁判结论只支持“在这组任务上相对偏好提高”这类明确论点，不能泛化为“模型整体更智能”。

裁判校准：冻结标签与人工基准

校准流程如图 11-5 所示。校准集由人工高一致样本、边界样本、争议样本和已知失败组成，人工标注采用双标、盲评、随机顺序和仲裁（11.3 节）。如果人工之间的一致性本身就低，不应拿裁判去替代人工，而要先澄清任务定义。

校准开始前，先冻结标签字典和正类方向。例如把正类定义为“必须升级人工”：人判升级而裁判判解决，是漏放（FN）；人判解决而裁判判升级，是误杀（FP）。只有合法标签进入 TP、FP、FN、TN 四格；越界标签、空响应和非法 JSON 记为 evaluator_failed，并报告有效数，不能悄悄转成默认的负类。人工和裁判看到同样必要的证据，但裁判输入里不能出现本实验要预测的人工标签；参考答案式评分可以给裁判提供独立的任务答案，那是另一种任务定义。

在有效样本上，准确率为 \((TP+TN)/N_{\text{valid}}\)，召回率为 \(TP/(TP+FN)\)，精确率为 \(TP/(TP+FP)\)，还要看正常样本被正确放行的比例 \(TN/(TN+FP)\)；分母为零时记为未定义，并检查稀有风险类是否根本没被覆盖。与 11.3 节的标注者间一致性一样，裁判与人工的一致性在类别不平衡时也要同时看 Kappa 和正、负类特异一致率：一个把所有样本都判为“解决”的裁判，在极不平衡的数据上准确率可以很高，召回率却为零。高风险的自动门禁要按两类误判的代价设定阈值并保留人工复核，不能套用通用的准确率门槛。

换序评估、长度控制、自我增强检查和多次评分的稳定性测试都在调优校准集上进行；验收集只评估冻结后的裁判版本，11.2 节的三个边界同样适用于裁判。裁判 prompt、模型版本或任务语言分布变化时要重新校准，并建立新旧裁判之间的桥接报告；中文、代码、数学、长文档和安全样本可能需要不同的裁判或评分指南。

flowchart LR
  A["校准集<br/>高一致 边界 争议 已知失败"] --> B["人工双标与仲裁<br/>冻结标签字典与正类方向"]
  A --> C["裁判按 A 在前评估"]
  A --> D["裁判按 B 在前评估"]
  C --> E{"两种顺序结论一致?"}
  D --> E
  E -->|"一致"| F["记为胜负"]
  E -->|"不一致"| G["记为平局"]
  F --> H["与人工标签对比<br/>四格表 Kappa 特异一致率"]
  G --> H
  B --> H
  H --> I{"达到预设阈值?"}
  I -->|"是"| J["冻结裁判版本<br/>只在验收集上评估"]
  I -->|"否"| K["修订 prompt 或 rubric"]
  K --> C
  K --> D

图 11-5 LLM-as-Judge 校准流程：双序评估、人工基准与一致性度量

评估器的依赖治理与成本

评估器本身依赖 tokenizer、模型、规则库、外部 API 和人工指南，每个 evaluator artifact 都要有版本、输入输出 schema、适用任务和已知偏差，并像被评模型一样纳入模型注册表。升级评估器时用历史样本重跑，把分数变化拆成“模型变化”和“评估器变化”两部分；裁判变强或 prompt 改变后，历史分数不再直接可比，可以保留旧裁判一段时间做桥接，或在报告中说明迁移。评估器不可用或输出异常时，该条结果的 evaluator_state 记为 evaluator_failed（见 11.1 节的状态表），不自动给负分或正分。高风险门禁要使用人工复核和独立规则，避免候选模型与裁判共享同样的偏差，自我增强偏差就是其中一种。

大规模评判很昂贵。可以先用规则过滤和小模型筛选，再对边界样本使用强模型和人工。缓存裁判结果时，缓存键必须包含裁判 prompt、候选 hash、评估器版本和数据等级，防止评估器升级后误用旧结果。抽样评判的置信区间要随采样策略一起保存，不能把小样本结果显示成精确的百分数。

11.6 RAG、工具调用与线上反馈闭环

RAG 与工具调用的组件评估

RAG 任务至少拆成检索、重排、上下文组装、生成和引用。Ragas 原论文把上下文相关性、答案对证据的忠实度和答案相关性分开评价 [3]；具体指标名、是否需要参考答案随版本变化，实验要冻结指标实现及其输入要求。组件指标不能替代最终任务成功，但能帮助定位：答案错，可能是没召回、召回了但排序错、上下文太长、模型忽略证据，或者引用指向错误。评估样本因此要保存 query、允许的证据、检索版本、chunk、上下文顺序、答案和引用，检索器升级后要重算上下文指标。线上反馈“答案有用”不能推出检索正确，需要抽样核对证据和引用。

工具调用的评估关心 schema、参数、权限、执行结果是否被正确使用、失败后能否恢复以及副作用是否幂等。单次输出 JSON 合法不等于任务成功：工具可能超时、返回脏数据、重复执行或需要人工审批。平台用 workflow trace 把模型调用、工具调用、状态迁移和最终目标连起来，测试要覆盖工具不可用、权限不足、部分成功、重复消息和模型回退。

反馈采样、入库与访问控制

不是所有线上请求都值得标注。可以按低评分、重试、工具失败、安全拦截、罕见语言和裁判不确定性分层采样；主动学习优先选择信息增益大或覆盖新分布的样本，而不只是最差的案例。采样策略本身也要版本化。

生产反馈先进入隔离区，完成身份去除、敏感信息检测、用途授权确认、去重、来源标记和风险分类；只有满足用途授权与留存策略的样本才进入候选集，“用户主动提交”不等于获得了训练授权。标注后的样本进入候选回归集前，还要过 11.2 节的去重、污染和用途边界检查：样本一旦进入训练集，再用于评估就是泄漏，血缘系统要么阻断，要么把结果标为不可比。整个闭环如图 11-6 所示，它要能回答一个失败样本从生产到标注、修复、回归和发布经历了什么。

flowchart LR
  P["生产请求与 trace"] --> S["分层采样<br/>低分 重试 工具失败 罕见语言"]
  S --> Q["隔离区<br/>去标识 敏感检测 授权确认"]
  Q --> L["人工标注与仲裁"]
  L --> C{"去重 污染与用途边界检查"}
  C -->|"已进入训练集"| X["阻断或标记不可比"]
  C -->|"通过"| R["候选回归集"]
  R --> V["复核与接受<br/>生成新评估集版本"]
  V --> G["质量门禁"]
  G --> D["发布或回滚"]
  D --> P

图 11-6 线上反馈闭环：反馈经隔离、标注和边界检查后才进入回归集与门禁

评估结果本身也是敏感数据，可能暴露模型弱点、客户数据和红队样本。访问权限分为结果摘要、失败样本、原始输入输出和 artifact 下载几级，每次访问都要审计；外部裁判只收到最小必要内容，并记录出站处理与删除确认。

线上质量信号、去偏与漂移

线上质量信号包括用户评分、编辑距离、重试、转人工、任务完成、工具成功、投诉和安全拦截，需要按模型版本、模板、租户、语言、路由和请求类型分层。这些信号都有选择偏差：只有展示给用户的结果才可能被评分，不满意的用户才会重试，完成任务的用户往往不再反馈。平台要保留随机抽样的未反馈请求作为对照，用分层或加权方法估计总体质量，并报告反馈覆盖率和采样策略；不能把 1% 用户给出的点赞率当作全量质量，也不能让大租户淹没少数重要场景。线上实验按父任务（parent task）固定版本，避免一次多步任务跨越多个模型版本；反馈入库时保存原始信号和时间，以后可以换聚合方法重算。

漂移分输入和输出两侧。输入侧比较当前窗口与基线窗口的长度、语言、主题、来源、工具类型和用户群；输出侧看长度、停止原因、重复、格式、引用、工具参数、拒答和安全判定。TFDV 支持训练与服务数据之间的偏斜检测和相邻时间段之间的漂移检测 [28]；OpenTelemetry 与 Prometheus 把请求上下文与时间序列指标连接起来 [29][30]，Dapper 式的分布式追踪帮助定位漂移涉及的下游组件 [31]。漂移不一定是质量问题，但应触发扩大评估、增加采样或暂停自动发布。

回放、红队与在线离线校准

回放保存 request manifest、模型版本、模板、检索结果、工具返回、采样参数和输出摘要，默认不执行真实副作用，而是把请求送到新模型、影子 engine 或离线评估器做比较；需要执行时使用 sandbox、mock 或 dry-run。时间敏感数据、权限、过期知识和随机性使回放只能近似，结果要标为近似而不是事实重现。失败样本优先进入回归，修复后在同一批样本上比较；样本若已用于训练，则报告不可比或改用新的 holdout。

安全红队样本与对抗集要记录来源、攻击类型、危害等级、预期处理、评估规则和修复状态，并在模型、模板、工具、检索或路由变化时触发相关子集，而不是只在发布前跑一次。修复后要确认模型没有靠一味拒答来提升安全分数，报告安全与有用性的联合结果。

离线指标与线上结果之间需要桥接集，即从历史生产请求中脱敏、分层并标注的样本，用来比较离线分数、线上反馈和人工判断。某个离线指标若长期与线上成功无关，就降低它在门禁中的权重或重新定义；线上出现新的失败模式，就加入候选回归集。线上与离线指标受不同因素影响，报告要分别标记测量层级，不把两类数字放进同一个总分。

11.7 评估作业的调度与结果可信度

评估平台也是一个批处理系统，但它交付的是可信的结果而不是吞吐。通用的批处理与数据管线工程（分区、重试、数据修复）见第9章 9.2 节，容量与灾备见第12章；本节只讨论评估特有的部分：调度、失败分类、证据等级，以及与业务执行的边界。

资源模型与调度

评估作业的形态多样：CPU 规则检查、单 GPU 批量推理、多模型裁判、在线 shadow、人工标注和多步 Agent 任务。job spec 声明模型 artifact、数据快照、并发、最大 token、超时、重试、GPU、优先级和预算。作业按用途和截止时间分层（提交前 smoke、发布门禁、夜间 broad、线上回放、人工标注和大规模 benchmark），使用不同的资源池或优先级，保证发布门禁不被长时间运行的 benchmark 阻塞。

调度器记录 pending 原因、预计完成时间、资源用量和预算。作业状态的迁移如图 11-7 所示：需要成组资源（gang）的任务一次性分配，可分区的评估弹性并行；抢占低优先级任务前保存游标与已提交的分区结果，恢复时只重做未完成的分区；裁判不可用或覆盖率不足时进入 DEGRADED，经批准的降级路径继续聚合，否则在超出预算或截止时间后取消。限流按评估器、模型和租户分别设置，并用 token 预算而不只是请求数，因为大量裁判请求可能压垮模型服务和成本预算。影子流量不改变业务状态，但会消耗 GPU 和 cache，必须计入容量报告；评估平台与 serving 平台共享 trace id，才能判断某次回归是否造成了生产尾延迟的变化。

stateDiagram-v2
  [*] --> PENDING
  PENDING --> RUNNING : 资源与预算就绪
  RUNNING --> PREEMPTED : 被高优先级作业抢占
  PREEMPTED --> PENDING : 保存游标与已提交分区
  RUNNING --> DEGRADED : 裁判不可用或覆盖率不足
  DEGRADED --> AGGREGATING : 切换已批准裁判或规则子集
  DEGRADED --> CANCELLED : 超出预算或截止时间
  RUNNING --> AGGREGATING : 全部分区结束
  AGGREGATING --> REPORTED : 生成不可变 report
  REPORTED --> [*]
  CANCELLED --> [*]

图 11-7 评估作业的调度状态：抢占可恢复，降级必须留下记录

失败分类、覆盖率与证据等级

各类失败不能简单填 0，而要按 11.1 节的分层状态分别记录：模型超时是 run_state 为 timeout，GPU OOM 和沙箱故障是 infra_failed，样本非法是 invalid_input，输出超长或格式错误是 task_outcome 为 failed，裁判返回非法 JSON 是 evaluator_failed。聚合器对同一 sample_id 的多个 attempt 选取协议规定的最终结果并保留历史；超时是否计入任务失败分母，由事先冻结的协议决定；所有跳过都报告覆盖率和原因，不能事后删除难例。覆盖率不足时，report 的结论是 INCOMPLETE 而不是 PASS。部分结果可以用于诊断，但默认不用于发布：如果只完成了容易的样本，分数会虚高。

在此之上，每份 report 标注证据等级（evidence level），把“一个分数”变成“一份证据”。等级由覆盖率、评估器校准、样本版本、运行时完整性、人工复核和统计置信度共同决定；它不评价模型好坏，只评价证据强弱。

发布控制器只接受足够证据等级的 evidence bundle；研究面板可以展示低等级结果，但必须显式标出。评估能力降级时（裁判不可用、数据存储故障、覆盖率不足），证据等级要同步下降：可以暂停、切换到已批准的裁判、使用规则子集或转人工，但门禁必须重新判断，不能为了按时发布而静默跳过困难样本。人工可以在写明风险和补救计划的前提下批准 INCOMPLETE 的结果，并记录有效期限。

评估协议与生成的可重复性

评估协议定义输入格式、系统指令、历史消息、工具 schema、采样参数、超时、重试和评分方式。模板变化会改变模型看到的 token、角色和约束，必须作为协议版本的一部分，执行时记录最终 prompt 的 hash、token 数和模板版本。协议还规定错误处理：超时、截断、非法 JSON、工具失败、裁判失败和数据缺失各对应哪个状态，是否重试，是否进入分母。不同协议混用会让“失败率”失去意义。

temperature 大于零时，生成本身就是随机的；即使 temperature 为零，服务端也可能因 kernel、batch 组成或数值路径不同而产生差异。评估可以固定 seed、多次运行取均值、使用确定性解码或保存完整输出，每种方式的成本和代表性不同，报告要保存采样参数、seed、重复次数、输出长度和失败样本。多步任务还有外部状态的随机性：检索索引、工具返回、时间、权限和用户上下文都会变，回放使用快照、sandbox 和录制结果，并标记与生产的差异。可重复性的目标不是位级一致，而是让差异来源可以解释，并在门禁中设置与之相称的容差。

评估与业务执行的职责边界

评估调度只负责把固定的 case 分发到已批准的环境并生成可聚合的结果；用户任务的持久状态、外部副作用和故障恢复由业务执行侧负责，评估系统只通过隔离 fixture 或受控回放消费其接口。最容易越界的地方是重试语义：评估分区可以安全重试，是因为评估在 recorded-read-only 这类受控模式下运行，结果只写入评估自己的存储；这并不意味着业务写操作也可以再调用一次。

11.8 质量门禁、发布与验收

门禁规则与可解释结论

门禁由硬约束、软阈值和人工检查组成。硬约束包括 schema 合法、关键安全指标、工具副作用、数据授权和 artifact 完整；软阈值包括质量变化、延迟、成本和覆盖率，按 11.4 节的区间与容差规则判定；人工检查用于裁判争议、重要客户、少数语言和高风险案例。每条规则写明基线、容差、样本、统计方法、owner 和有效期。门禁的输入、判定与输出如图 11-8 所示。

门禁结论必须可解释：失败报告列出退化的能力、样本、模型版本以及数据和运行时差异；通过报告列出覆盖范围和剩余的不确定性。模型分数与任务结果要分开判定，下表是几种典型组合：

表中的 SLO 指服务等级目标（定义见第8章）。质量、成本与时延之间的取舍也应事先写成规则：质量提升、成本降低、延迟不变且其余门禁满足，可按规则通过；质量提升但成本显著增加，需要业务审批；质量不变而成本降低，优先灰度；质量下降但时延降低，只在低风险场景评估；安全或关键任务下降，无论成本和延迟如何都阻断。这些规则不替代判断，只是把预先接受的取舍公开。成本要按单位成功任务计算：某个模型单次调用更便宜，但若失败导致更多重试和人工介入，总成本反而更高。

flowchart LR
  subgraph IN["门禁输入"]
    R1["report 与差值区间"]
    R2["证据等级"]
    R3["安全与授权检查"]
    R4["成本与 SLO"]
  end
  IN --> G{"质量门禁"}
  G -->|"硬约束失败或退化超过容差"| F["FAIL<br/>阻断并调查"]
  G -->|"覆盖不足或区间跨过容差"| I["INCOMPLETE 或 INCONCLUSIVE<br/>补样或人工审批"]
  G -->|"全部满足"| P["PASS"]
  P --> B["evidence bundle<br/>report hash 与责任人"]
  B --> REG["模型注册表<br/>candidate 到 staged"]
  REG --> CAN["限定范围 canary<br/>运营动作见第12章"]

图 11-8 从质量门禁到发布证据的流转

A/B、影子与 canary

A/B 比较需要随机化、分桶、实验周期、样本量和停止规则，11.4 节关于重复查看的规则同样适用。多轮对话和多步任务按父任务分配流量；影子流量不触发真实工具副作用；canary 期间同时观察质量、SLO、成本、安全和用户反馈。报告给出效应大小、置信区间、样本覆盖和业务权重，由负责人签署。灰度节奏、回滚触发和发布冻结属于运营动作，见第12章。

按变更类型选择评估路径

不同变更的风险不同，评估路径也不同，共同点是固定其余因素、只让被评估的那一项变化。

• 新模型候选：先过 artifact、schema、安全和加载检查，再跑 smoke、critical 回归与目标任务评估；与旧版本做配对比较，同时测 token、TTFT、TPOT 和成本。关键任务回退自动阻断，普通任务的小幅变化进入人工评审。
• Prompt 或模板变更：看似不改模型，却可能改变 token 长度、prefix cache 命中、工具调用和安全边界。固定模型与数据比较模板前后的结果，灰度按父任务分桶，模板 manifest 与权重一样需要回滚路径。
• 检索器或知识库变更：先生成新快照，评估检索召回、上下文相关性、引用和最终任务，再用历史 query 回放；chunk 策略或权限变化时，旧 cache 和评估结果按血缘失效。上下文变长还要重新评估 serving 成本和 TTFT。
• 量化或 engine 变更：比较输出差异、结构化合法率、长上下文表现、质量、显存和吞吐，失败样本按层、长度和任务分类，定位问题出在精度、kernel、采样还是模板。评估结果绑定硬件和 driver，跨硬件不能直接复用。

发布接口与证据引用

发布控制器通过 API 提交评估请求，指定候选 artifact、基线、数据快照、协议、阈值、截止时间和所需的证据等级；评估平台返回 eval_run_id，异步上报进度，最后给出 report。两边只通过接口交互：控制器不读评估平台的内部数据库，评估平台也不修改生产路由。接口带幂等键和 report hash：重复提交返回同一个 eval_run 或明确创建新的 attempt；report 生成后不可变，修订以新版本关联旧版本。

模型注册表只接收 evidence bundle 完整的 candidate，灰度控制器读取同一份门禁结果。回滚时选择的是经过验证的旧组合（artifact、模板、评估规则和路由），而不只是旧权重；回滚期间的请求单独标记，新版本产生的反馈不能归到旧版本名下。

验收清单

评估 Infra 自身也要验收，下面三组检查分别对应本章的三条主线。

• 评估数据：随机抽一个评估集快照，验证来源、授权、切分单位、跨 split 去重、污染检查结果、标注指南版本和 manifest hash；修改一条过滤规则，确认血缘能找到受影响的评估集与报告；撤回一个数据源，确认新的评估不能再读取，而历史审计仍可查询。
• 评估可靠性：用固定回归集重复运行，验证随机性、缓存、并发和断点续跑；故意损坏一个分区、停掉一个 worker、让裁判超时，确认系统不会把缺失或旧结果当作通过，报告包含覆盖率、失败分类和置信区间。
• 反馈闭环：从线上 trace 抽一批失败样本，走完脱敏、权限、采样、标注、去重、污染检查、进入候选回归集、修复后评估和发布关联的全过程；做一次漂移检测，确认输入、输出、工具和安全指标都能分层；做一次回放，确认不会触发真实副作用。

不同性质的检查要用不同的测试手段：确定性不变量（如“只读模式下写操作次数为零”）用单元测试和性质测试；协议与工具错误码用契约测试；存储、队列和沙箱的交互用集成测试；开放文本按任务标准多次评测，而不是用逐字快照拒绝合理的措辞变化；高风险链路再补端到端测试和故障注入。规则文件、Skill 与 prompt 也作为版本化配置纳入同一套对照。评估执行 completed、HTTP 调用成功、裁判给出高分与业务任务完成，始终是四个不同的事实。

11.9 本章小结

评估 Infra 的事实源是三样东西：版本化的 Eval Case 与评估器，不可变的执行记录，以及聚合后给出结论的 report。围绕它们，本章回答了四个问题，相互关系如图 11-9 所示。

第一，用什么测。评估集必须不可变、可回读，按会话、文档或实体群组切分，并跨 split 去重；训练、调优校准和独立验收三条边界一旦被打破，分数就不再代表泛化能力。标注质量用 Kappa 衡量时要配合正、负类特异一致率，避免在类别不平衡时被“高一致、低 Kappa”误导。

第二，怎样测。协议冻结输入模板、采样参数和错误处理；裁判模型有位置、冗长和自我增强等偏差，在数学与推理上评分能力有限，需要双序评估、与人工基准校准，并单独版本化。

第三，证据有多强。评估分数是有限样本估计：零失败只给出单侧上界；版本比较用配对区间；判定看区间与容差 \(\varepsilon\) 的位置关系，而不是拿观测差与 MDE 比较；样本量按配对设计规划；多次查看和多个切片要事先分配错误预算。执行、任务、评估器和报告结论分层记录，覆盖不足为 INCOMPLETE，区间跨过容差为 INCONCLUSIVE。

第四，谁允许发布。质量门禁只接受足够证据等级的 evidence bundle，并把模型分数与任务、安全和覆盖证据分开判定；线上反馈经过隔离、标注和边界检查后回到回归集，形成闭环。门禁结论如何驱动灰度、回滚和事故响应，见第12章；面向轨迹与行为的多步 Agent 评测沿用本章的样本、分母、校准与报告定义，不另建一套事实源。

flowchart TD
  DATA["评估数据边界<br/>群组切分 去重 污染"] --> CASE["版本化 Eval Case<br/>与评估器"]
  LABEL["标注与一致性<br/>Kappa 特异一致率"] --> CASE
  CASE --> RUN["eval_run<br/>冻结协议与采样参数"]
  JUDGE["LLM-as-Judge<br/>双序评估 人工校准"] --> RUN
  RUN --> RES["result<br/>执行 任务 评估器分层状态"]
  RES --> REP["report<br/>配对区间 容差 ε 多重比较"]
  REP --> GATE{"质量门禁<br/>证据等级"}
  GATE -->|"PASS"| REL["发布与 canary<br/>第12章"]
  GATE -->|"FAIL INCOMPLETE INCONCLUSIVE"| FIX["阻断 补样或修复"]
  REL --> FB["线上反馈与漂移"]
  FB -->|"隔离 标注 边界检查"| CASE

图 11-9 本章概念图：从评估数据到发布证据的闭环

11.10 参考资料

1. Liang, P., et al. Holistic Evaluation of Language Models. Transactions on Machine Learning Research（arXiv:2211.09110）, 2023. 核验日期：2026-11-05。
2. Srivastava, A., et al. Beyond the Imitation Game: Quantifying and Extrapolating the Capabilities of Language Models. Transactions on Machine Learning Research（arXiv:2206.04615）, 2023. 核验日期：2026-11-05。
3. Es, S., et al. Ragas: Automated Evaluation of Retrieval Augmented Generation. arXiv:2309.15217（v2 2025）, 2023. 核验日期：2026-10-17。
4. MLflow. ML Tracking Documentation. MLflow 官方文档. 核验日期：2026-10-17。
5. Langfuse. Datasets. Langfuse 官方文档. 核验日期：2026-10-17。
6. lakeFS. Version Data. lakeFS 官方文档. 核验日期：2026-10-17。
7. Delta Lake. Delta Lake Documentation: Introduction. Delta Lake 官方文档. 核验日期：2026-10-17。
8. Zhang, A., Lipton, Z. C., Li, M., & Smola, A. J. 4.4 模型选择、欠拟合和过拟合. 《动手学深度学习》中文版 2.0.0. 核验日期：2026-11-05。
9. Gao, L., et al. The Pile: An 800GB Dataset of Diverse Text for Language Modeling. arXiv:2101.00027, 2020. 核验日期：2026-11-05。
10. Grattafiori, A., et al. The Llama 3 Herd of Models. arXiv:2407.21783 v3, 2024. 核验日期：2026-10-17。
11. Cohen, J. A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement, 20(1), 37–46, 1960. 核验日期：2026-11-05。
12. Landis, J. R., & Koch, G. G. The Measurement of Observer Agreement for Categorical Data. Biometrics, 33(1), 159–174, 1977. 核验日期：2026-11-05。
13. Cicchetti, D. V., & Feinstein, A. R. High Agreement but Low Kappa: II. Resolving the Paradoxes. Journal of Clinical Epidemiology, 43(6), 551–558, 1990. 核验日期：2026-11-05。
14. Byrt, T., Bishop, J., & Carlin, J. B. Bias, Prevalence and Kappa. Journal of Clinical Epidemiology, 46(5), 423–429, 1993. 核验日期：2026-11-05。
15. Hendrycks, D., et al. Measuring Massive Multitask Language Understanding. ICLR（arXiv:2009.03300）, 2021. 核验日期：2026-11-05。
16. NIST/SEMATECH. e-Handbook of Statistical Methods: 7.2.4.1 Confidence Intervals. NIST 在线手册. 核验日期：2026-10-17。
17. Clopper, C. J., & Pearson, E. S. The Use of Confidence or Fiducial Limits Illustrated in the Case of the Binomial. Biometrika, 26(4), 404–413, 1934. 核验日期：2026-11-05。
18. Hoeffding, W. Probability Inequalities for Sums of Bounded Random Variables. Journal of the American Statistical Association, 58(301), 13–30, 1963. 核验日期：2026-10-24。
19. NIST/SEMATECH. Bonferroni’s Method. e-Handbook of Statistical Methods, NIST 在线手册. 核验日期：2026-10-24。
20. Newcombe, R. G. Improved Confidence Intervals for the Difference between Binomial Proportions Based on Paired Data. Statistics in Medicine, 17(22), 2635–2650, 1998. 核验日期：2026-11-05。
21. Tango, T. Equivalence Test and Confidence Interval for the Difference in Proportions for the Paired-Sample Design. Statistics in Medicine, 17(8), 891–908, 1998. 核验日期：2026-11-05。
22. McNemar, Q. Note on the Sampling Error of the Difference between Correlated Proportions or Percentages. Psychometrika, 12(2), 153–157, 1947. 核验日期：2026-11-05。
23. Connor, R. J. Sample Size for Testing Differences in Proportions for the Paired-Sample Design. Biometrics, 43(1), 207–211, 1987. 核验日期：2026-11-05。
24. Holm, S. A Simple Sequentially Rejective Multiple Test Procedure. Scandinavian Journal of Statistics, 6(2), 65–70, 1979. 核验日期：2026-11-05。
25. Liu, Y., et al. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. Proceedings of EMNLP 2023, 2511–2522, 2023. 核验日期：2026-11-05。
26. Zheng, L., et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks Track（arXiv:2306.05685）, 2023. 核验日期：2026-11-05。
27. Wang, P., et al. Large Language Models are not Fair Evaluators. Proceedings of ACL 2024 (Volume 1: Long Papers), 9440–9450, 2024. 核验日期：2026-11-05。
28. TensorFlow. TensorFlow Data Validation. TensorFlow 官方文档. 核验日期：2026-11-05。
29. OpenTelemetry Authors. Signals. OpenTelemetry 官方文档. 核验日期：2026-10-17。
30. Prometheus Authors. Prometheus Documentation: Overview. Prometheus 官方文档. 核验日期：2026-10-17。
31. Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. 核验日期：2026-10-17。

第12章 生产运营与治理控制

版本与证据说明：本章的修复流程表、删除记录字段和示例值是教学设计，不代表实际运行记录或已执行的演练。外部规范按核验时的版本引用（SLSA v1.2、OWASP LLM Top 10 2025、EU AI Act 及其 2026 年修订、PyTorch 2.6 起的加载默认值），以文末参考资料的核验日期为准。

大模型系统的可靠性不只是接口可用。模型可能返回格式正确但事实错误的答案，工具可能重复执行副作用，推理服务可能在长上下文下耗尽 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 平台的指标、状态、策略、门禁和操作。SLO、错误预算、发布与回滚、供应链、事故、安全法规、成本、灾备和删除在本章完整解释；推理引擎内部的调度、KV cache 与 drain 机制见第10章，评估集与质量门禁证据如何产生见第11章，本章只讲这些机制和证据如何驱动运营决策。

本章的组织方式是“风险—控制—证据—责任人”。可靠性、发布、安全、成本、灾备和审计不应散落在不同文档里，而应能映射到同一张治理矩阵。