第零部分 · 入门定位 · 第 1 章

全栈一览

作者Changkun Ou

阅读时长约 12 分钟

AI 系统有两段历史。第一段发生在用户到来之前：收集数据、训练模型、调整模型行为，再部署模型权重。第二段从请求进入已部署的系统开始：模型服务生成词元，智能体运行时调用工具，测试或其他观测结果决定下一步。两段历史在部署处相接，却不是同一个过程。

本章会沿着这两段历史各走一遍。区分它们很重要，因为预期的运行时负载会反过来改变前期设计。一个训练成本不高的模型，服务成本可能很高。能够调用工具的智能体，也比只生成文本的模型更需要严格的评测和安全边界。后续章节会详述每项机制，本章只负责建立它们之间的联系。

图 1.1. 技术栈中的五层，以及每层面临的三类压力。训练阶段以能力为主，服务阶段以效率为主；系统开始通过工具采取行动后，信任变得更加重要。图中仅为理想化的相对权重，并非实测数据。

贯穿本章的任务很简单：用户让助手在一个小型代码仓库中找出缺陷、提出修复方案并说明原因。 构建这种能力需要训练；真正执行请求则需要模型服务、工具，以及代码仓库提供的反馈。把两个阶段分开，才能看清它们如何彼此依赖。

我们用两个已经发布的系统来说明具体架构。Llama 3 采用稠密 Transformer，几乎每个词元都会经过模型的全部层和参数 (Grattafiori and others 2024)。DeepSeek-V3 则采用混合专家（MoE），每个词元只激活少数几个专家子网络；在其 6710 亿个参数中，每个词元实际激活 370 亿个 (DeepSeek-AI 2024)。这两个模型并不是能力相当的受控对照，选择它们是因为两者呈现了不同的成本结构。后续模型继续向稀疏容量发展：Meta 于 2025 年 4 月发布首批采用混合专家架构的 Llama 模型 (Meta AI 2025)，DeepSeek 则于 2026 年 4 月发布稀疏 V4 系列的预览版 (DeepSeek-AI 2026)。

构建能力：数据与词元

用户的请求不会经过训练语料库，但系统处理这项请求的能力来自训练语料库。训练语料库汇集文本、代码和其他数据，再清除低质量记录与重复内容。去除近似重复项很重要，因为同一个代码仓库如果被复制多次，就会获得超出预期的影响力。去污染则检查评测题目或与其高度相似的内容是否进入了训练集。如果不做这项检查，基准测到的可能是记忆，而不是泛化能力。第 6 章会详述这些选择。

Llama 3 最大的模型使用了 15.6 万亿个预训练词元 (Grattafiori and others 2024)，DeepSeek-V3 使用了 14.8 万亿个 (DeepSeek-AI 2024)。词元是输入片段对应的整数标识，不一定就是一个完整的词。分词器及其词表会决定 readUserConfig 这样的变量名被视为一个熟悉的整体，还是被切成若干更小的片段。这种表示方式会影响序列长度、多语言文本，以及模型学习代码的效率。第 7 章会从字节讲到词元标识，完整说明这个过程。

预训练产出基座模型

预训练会反复给模型一段前缀，让它预测下一个词元。例如，面对 if err != nil {，如果模型把较高概率分配给 return，它的损失就会低于把概率分配到其他词元的模型。每个训练步骤都会计算预测误差，反向传播，再更新模型参数。对大规模语料反复执行这一过程，最终得到基座模型。它是一个能够预测常见续写的通用模型，还不是可靠的助手。

在固定的算力预算下，模型规模和训练词元数不可能同时无限增长。经验扩展律估计损失会如何随参数量、数据量和算力变化 (Kaplan et al. 2020)。Hoffmann 等人进一步研究了在训练算力预算内，参数量与词元数怎样搭配才能尽量降低损失 (Hoffmann et al. 2022)。第 5 章会说明这些拟合能够预测什么，又不能预测什么。完成预测的 Transformer 组件包括注意力、残差连接和归一化，它们始于 Vaswani 等人的工作 (Vaswani et al. 2017)，并在第 8 章中展开。

架构会改变预训练的成本。Llama 3 的 4050 亿参数模型采用稠密架构，因此每个词元都会运行绝大多数带参数的计算 (Grattafiori and others 2024)。DeepSeek-V3 保存了更大的专家参数池，但每个词元只激活其中一部分。它还结合多头潜在注意力（MLA），也就是一种能够缩小推断时缓存的注意力设计 (DeepSeek-AI 2024)。稀疏激活减少了每个词元的算术运算，但完整的专家参数池仍须分布在服务系统的加速器内存中；在专家之间路由词元，也会增加通信和负载均衡工作。第 9 章会分析这项取舍。

达到这种规模后，训练系统本身也成为模型设计的一部分。数千个加速器需要交换梯度、从硬件故障中恢复，并避免等待速度较慢的工作节点。第 10 章会结合多个实例讲解这些问题，其中包括 DeepSeek-V3 的 FP8 混合精度训练，以及其完整训练流程报告的 278.8 万 H800 GPU 小时 (DeepSeek-AI 2024)。

许多训练流程会在后训练前加入中段训练（mid-training）。这个阶段会把数据配比转向高质量或专门领域的材料，例如代码和数学，也可能延长序列长度。对于本章的示例，增加代码数据的占比，可以在指令调优开始前提高模型理解代码仓库的能力。第 11 章会解释这个阶段为何既不同于宽泛的预训练，也不同于之后的行为塑造。

第一部分把这套完整流程称为「基座模型形成」：数据准备、预训练和中段训练共同产出原始模型，随后再对它进行适配。

后训练塑造行为

基座模型会续写文本，而部署后的助手必须理解请求、遵守约束，并给出有用的结果。监督微调（第 17 章）让模型学习理想回答的示范，由此迈出从基座模型转向助手的第一步。行为规格和偏好数据集进一步说明标注者或自动评分器更偏好哪些回答（第 18 章）。

偏好训练通常有两条路径。在基于人类反馈的强化学习中，奖励模型先学习如何给回答打分，再把语言模型当作策略进行优化，使其获得更高分数（第 19 章）。直接偏好方法则使用被接受与被拒绝的回答对进行训练，不再单独训练奖励模型（第 20 章）。安全调优还会规定哪些指令优先，以及模型应在什么情况下拒绝请求（第 22 章）。

对于修复缺陷的任务，后训练会把看似合理的代码续写转化为一系列有用行为：检查代码仓库、说明计划、使用工具，并解释补丁。面向推理的训练和测试时方法，还可能为困难步骤分配更多计算。第四部分会沿着这条线，从推理能力的引出与搜索，一直讲到验证、蒸馏和推断时路由（第 24 章至第 30 章）。

部署把权重变成服务

训练完成的检查点只是一组权重。服务系统必须加载这些权重、接收并发请求、调度加速器工作，还要在延迟预算内返回词元。处理输入提示的阶段称为「预填充」，通常需要大量算术运算。生成后续词元的阶段称为「解码」，它会反复读取模型权重，性能通常受内存带宽限制。

生成期间，注意力机制需要使用先前词元已经算出的键和值。KV 缓存（key-value cache）会保存这些状态，避免模型在每一步重新计算整个前缀，但缓存会随着词元数和活跃请求数增长。第 31 章会引出这项成本；第 32 章会解释如何批处理请求并为缓存分页。推测解码先以较低成本提出多个词元，再由目标模型验证（第 33 章）。量化则以较低精度存储部分权重或缓存值，从而减少内存与带宽需求，但也可能损害准确性（第 34 章）。

运行时：请求进入系统

直到此时，用户提交的缺陷报告才真正进入系统。智能体运行时把请求发送给模型服务，将返回结果解释为文本或工具调用，执行获得许可的操作，再把观测结果交回模型。一条典型轨迹会读取文件、运行测试、查看失败信息、修改代码，然后再次运行测试。模型提出动作，运行时负责执行权限检查并落实动作，代码仓库和测试运行器提供判断结果的证据。

第 38 章会讲解这套控制循环，第 41 章则讨论包围它的运行时。有些系统使用检索增强生成（第 44 章），从索引中选择相关材料；代码智能体也可以直接使用文件搜索和代码仓库工具。两种方式面对的都是第 46 章讨论的有限上下文问题：下一次模型调用应带上哪些指令、文件、工具结果和摘要。

图 1.2 将模型生命周期与请求运行时分开绘制。部署后的权重连接两条路径：训练产出供服务加载的工件，请求本身只经过运行时路径。

图 1.2. 两条相互连接的路径。模型生命周期产出部署后的权重；运行期间，智能体向模型服务发送请求，并与工具和代码仓库交换动作与观测结果。

不同时间尺度上的三个过程

三个过程贯穿全书，但只有两个存在嵌套关系。训练发生在上游，负责产出模型权重。一次模型调用会使用固定权重，逐个解码词元。一项智能体任务可能包含多次模型调用，调用之间穿插着工具动作和观测结果。

训练循环处理一批批数据、计算损失，再用梯度更新参数。它的成本由一个发布的模型版本分摊。解码循环发生在每次模型调用内部：每生成一个词元，就把它加入下一步的输入，而权重保持不变。它的成本取决于输入和输出长度。智能体循环发生在任务层，模型调用与环境中的动作交替进行。整条轨迹上的成本和失败概率会不断累积。

图 1.3 展示了这些关系。智能体循环包含模型调用，每次调用又包含逐词元解码。训练位于上游，是另外两个过程的依赖，并不包含在其中。因此，可以得到三个实用的核算单位：每个模型版本、每个词元和模型调用、每项任务。

图 1.3. 三个以不同时间尺度反复运行的过程。训练在发布前更新参数；一次模型调用使用固定权重解码词元；一项智能体任务可以包含多次模型调用和工具交互。

图 1.4. 三个过程的节奏示意图。解码随每个词元推进，智能体在模型调用和工具步骤之间推进，训练则发生在模型版本发布之前。同心布局只表示相对节奏，不表示三者在字面上彼此包含；训练位于另外两个过程的上游。

这些过程在时间上相互分离，成本却彼此耦合。因此，预期的运行时需求可能改变训练阶段的决策。

下层约束

训练算力的扩展问题，是在固定训练预算下寻找使损失尽量小的参数量与词元数分配 (Hoffmann et al. 2022)。部署还会增加第二项成本：模型的预期服务费用。当需求足够高时，多花训练成本得到一个更小、每个生成词元成本更低的模型，可能反而更经济。这是一项有条件的结论，并不意味着小模型总是更好 (Sardana et al. 2024)。第 31 章中的服务负载，向上影响了第 5 章所研究的训练决策。

稀疏模型通过架构体现了相近的压力。DeepSeek-V3 的 6710 亿个参数中，每个词元激活 370 亿个，减少了专家计算，却要承担更大的常驻参数池，以及路由、通信和负载均衡成本 (DeepSeek-AI 2024)。考虑推断成本的模型规模选择，与混合专家路由是两种不同技术，但都说明下游成本为何必须进入上游设计。

无需把两个已发布模型假装成受控实验，也能写出生命周期成本的比较。对于设计 $j$ ，定义

C_j(V) = T_j + V I_j,

其中， $C_j(V)$ 是服务量为 $V$ 时的生命周期总成本， $T_j$ 是一个模型版本的一次性训练成本， $I_j$ 是每单位服务量增加的服务成本。假设设计 B 的训练成本高于设计 A，即 $T_B>T_A$ ，但服务成本更低，即 $I_B<I_A$ 。只有服务量超过以下盈亏平衡点时，B 的总成本才会更低：

V^* = \frac{T_B-T_A}{I_A-I_B}.

这个简化模型没有计入硬件利用率、提示处理、内存容量和工程人力。它的目的很明确：说明预期的运行时账单在什么条件下足以抵消更高的前期训练成本。

import numpy as np
import matplotlib.pyplot as plt

# 达到同一目标质量的两种假想设计。
# 成本使用归一化算力单位；服务量以十亿词元计。
designs = {
    "A：训练成本较低": dict(train=100, serve=0.80),
    "B：服务成本较低": dict(train=140, serve=0.35),
}
served = np.logspace(-1, 3, 200)
for name, d in designs.items():
    plt.plot(served, d["train"] + served*d["serve"], label=name)

a, b = designs.values()
break_even = (b["train"] - a["train"]) / (a["serve"] - b["serve"])
plt.axvline(break_even, color="grey", linestyle="--")
print(f"盈亏平衡服务量：{break_even:.1f} 十亿词元")
plt.xscale("log")
plt.xlabel("生命周期服务量，十亿词元")
plt.ylabel("归一化生命周期算力成本")
plt.legend(); plt.tight_layout(); plt.show()

评测系统：能力、效率与信任

上面的三个过程解释系统如何运行。另一条贯穿全书的线索，则用三个彼此独立的问题来评判设计。这三者不是固定预算中的三项配额，其中一项改善，也不一定会让另一项变差。

维度	问题	修复缺陷任务中的证据
能力	系统能够完成哪些任务，可靠程度如何？	找到缺陷、生成正确补丁，并解释改动。
效率	得到结果需要多少算力、内存、延迟、能源和资金？	端到端耗时、模型调用次数、生成词元数、加速器占用和工具成本。
信任	哪些证据表明必要属性成立，并且故障可以被发现或控制？	能复现问题的测试、回归测试、代码审查、受限的工具权限、来源记录和回滚路径。

一项通过的测试，只能为一组特定条件下的一种行为提供证据。它本身不足以证明补丁可信，因为测试可能不完整，其他路径可能发生回归，智能体也可能越过权限边界。因此，信任针对的是整个系统，包括模型、运行框架、工具、上下文和运营控制。

后续评测章节会分阶段建立这些证据：第 47 章讨论静态分数能够测量什么，第 48 章讨论观测差异中的不确定性，第 51 章讨论生成内容背后的依据，第 52 章讨论多步轨迹，第 55 章讨论如何约束有能力的系统。第 76 章则把能力和资源消耗连接到部署能够承受的价格。

接下来怎么读

下一章第 2 章会把这些机制放进全书的完整结构。此后，读者既可以按生命周期顺序阅读，也可以从眼前的工程问题切入，再通过交叉引用补齐它所依赖的内容。

第一次走完全栈后，应当记住两个区别。模型开发与请求执行是两条相互连接的时间线，而不是同一段旅程。能力、效率和信任必须针对完整的已部署系统进行评测，不能只凭模型架构推断。全书后续内容将逐一展开支撑这两个判断的机制。