大模型推理系统工程：性能、诊断与优化

第1章 一次推理请求的完整路径

核心论点：先确定研究对象和测量边界，再讨论模型快慢；一次业务任务、一次接口请求和一次模型执行不是同一个单位。

本章导航

读完本章，你应该能够：

1. 给一次业务完成过程分层命名——任务、请求、模型调用、尝试、会话——并把客户端状态、服务端状态、任务结果与资源释放分成四张互不混淆的账；
2. 在同一个可比时间域内定义端到端时间，并按依赖图而不是按日志列表重建关键路径；
3. 说出"同一个模型名称"之外还必须固定哪些制品身份，以及可复现性有哪四个层次；
4. 把流式响应中的协议事件、观测层间隔与 Token 数分开识别，知道块边界不等于分词边界；
5. 把引擎拆成前端、调度器、Model Runner、执行后端等职责层，并知道"声明支持"与"实际启用"需要用不同强度的证据；
6. 对账发出、接收、完成、取消、超时和未终结的请求，识别幽灵负载与重试放大，并知道重试放大的假设边界。

---

1.1 系统边界：任务、请求、会话与模型调用

本节要回答的问题：我们究竟在优化哪一种完成单位？

一个团队报告"我们的大模型服务很慢，端到端要 6.7 秒"。这句话没有错，但它几乎不包含可执行的优化信息：这 6.7 秒里有检索、有工具查询、有模型调用、有客户端渲染，而团队准备购买的新型加速卡只能影响其中的一段。工程判断的第一步永远是拆分与命名——把"慢"这个形容词，换成一张谁都能核对的账本。

1.1.1 业务任务与接口请求

设想一个合同审查助手。用户上传一份 30 页的 PDF，点击"分析风险点"，约 6.7 秒后看到结果。用户感知到的是一次业务任务（task）：从点击到答案可读。系统内部的动作序列必须写清楚，尤其是依赖关系——哪些步骤必须等别人先完成。

本例采用的结构是：主模型生成与条款查询工具之间是独立预取关系，即工具在任务早期被触发（触发点 = 文档解析完成后），其结果只供最后的结果组装消费（消费者 = S8），且必须在 S8 开始前完成（汇合点 = S8 起点，早于 S6 结束）。只有在这三个条件被实际记录证实之后，才能把工具耗时视为可被覆盖的区间；若工具结果要被答案本身消费（"工具提出调用 → 执行 → 结果回填 → 后续生成"），它就是串行的一段，不能自动隐藏。

以上数值为构造数据。其中列入配套E0清单的算术关系已执行自动检查，其余项不据此宣称程序验证：

由此得到的结论必须写成条件句：在本案例中，假设 S7 与解码的重叠关系已被事件记录确认，且调整后其他阶段与关键路径不变，端到端时间为 6.70 秒。将 3.10 秒的解码耗时缩短 30%，可减少 0.93 秒，使端到端降至 5.77 秒。仅优化解码，即使将其耗时理想化为零，剩余串行阶段仍为 3.60 秒，因此单靠这一段无法达到 3 秒目标。这并不证明同时优化 Prefill、检索、重排或任务结构也无法达标。 另外，3.60 秒是把一个阶段理想化到零得到的乐观下界，用于判断"单段优化能否达成目标"，不可用作任何可达性能的承诺。

这段推导的价值在于：它能在花钱之前识别出哪些路径不可能达成目标。 在上面的假设下，"只优化 Decode"这条路径被排除；至于同时优化 Prefill、检索、重排，或改变任务结构（流式呈现、先要点后全文、进一步并行化检索与工具）能否达到 3 秒，本账本没有给出结论——它需要各自的账与各自的实验。不要把"单段优化不可行"扩大成"只有改任务结构才可行"。

要把这类账本写对，先要把对象分层。下表给出五类常被混用的对象；注意它们不全是"完成单位"——会话是上下文容器，不是一种完成：

两个常被忽略的细节：

• 一次生成不等于一次前向。 通常所说的"生成 900 个 Token"在实现上意味着数百次迭代执行；把 model call 写成"一次前向 + 生成"是不准确的。评分类调用（如上面的 S4 重排）与生成类调用的资源特征也不同，不应共用一套口径。
• 会话不必是任务或请求的严格父级。 多个任务可以共享一个会话，一个任务也可以横跨多个会话；用 session 作为统计层级的根节点会算错。

另设一个“主请求发生一次重试”的映射变体（不属于前述首次尝试即成功的 6.70 s 时间线），避免"一次任务等于几次调用"停留在口头：

之所以不写"7 次请求"，是因为那需要另一份调用图；没有映射的数量不要出现在案例里。

1.1.2 会话状态与多次调用

多轮对话让完成单位进一步复杂化。第二轮请求必须携带第一轮的上下文，而上下文的存放位置至少有三种：客户端拼接后重发、服务端按会话标识保存、以及模型服务内部复用 KV 状态。三者的性能含义完全不同，但对外表现可能一模一样。

按结构划分，负载至少有四类，它们在本书后续章节中会反复出现：

线性会话的增长要小心表述。历史长度逐轮变大，但实际需要处理的 Token 数取决于有多少被复用：若引擎命中了前缀缓存，需要处理的是未复用的那部分；若没有命中，才是全部历史。算法工作量（与未复用 Token 数相关）与墙钟时间之间还隔着排队、批组成与设备占用，因此不能把"输入变长 8 倍"直接写成"耗时增加 8 倍"。正确做法是分开记录四个量：历史 Token 数、未复用 Token 数、算法工作量、墙钟时间，缺哪一个都无法复核。

多分支的成败判定必须预先写进任务契约，而不是事后解释。举例：

任务契约规定"三个并行分支须在 8 秒内全部返回，否则降级为部分结果"。实测三个子调用的服务端终态都是 completed，但最慢的那个在 8.3 秒才返回，超过截止时间，于是 task_outcome 记为 partial_success（按契约降级）。

这不是矛盾：三个子调用成功描述的是调用层，部分成功描述的是任务层。两者分属不同层次，靠 task_id 聚合。

反过来也成立："任一子调用失败即任务失败"不是通则，它只适用于全部分支必需、且没有回退、重试、冗余或降级策略的流程。有降级路径的任务，子调用失败可能只导致质量下降。任务是否成功，永远由契约判定，不由某一个子调用的状态判定。

1.1.3 系统内外责任边界

确定了完成单位之后，还要划定被测系统（System Under Test，SUT）的边界。同一次合同审查，若 SUT 只定义为"主模型推理服务"，那么 S2 的解析与 S3 的检索都是外部依赖；若 SUT 定义为"合同审查应用整体"，它们就是内部段。两种定义都合理，但不能混用：在 A 定义下优化检索取得的收益，不能记到 B 定义的账上。

判断一段耗时归属，可以反复问三个问题：

1. 引入者是谁？ 这段代码/服务由谁部署、谁配置、谁升级？
2. 能否单独测量？ 有没有一个接口或事件，可以在不触发其他段的情况下测到它？不能单独测量的段，只能整体观测，也就无法单独归因。
3. 优化后谁负责维护？ 若一段耗时优化后无人承接回归测试，这个收益会在下一个版本悄悄消失。

外部依赖必须单独记账，而不是笼统归入"其他"。至少保留三条记录：调用次数、墙钟耗时分布（不只是均值）、失败与超时次数。很多"推理服务变慢"的事故，根因其实是下游检索服务的 P99 从 80 ms 涨到 900 ms——而如果压测时把检索 mock 掉了，这个变量永远不会出现在你的实验里。

一个实用的做法是维护"责任边界表"，随每次实验档案一起保存：

责任边界表
--------------------------------------------------
SUT 定义          : 主模型推理服务（HTTP 接口 /v1/chat）
包含              : 网关鉴权、排队、prefill、decode、流式返回
外部依赖          : 向量检索、条款查询工具、重排模型
外部依赖记账方式  : 单独计时 + 记录失败；不并入主服务延迟
工具依赖假设      : 条款查询为独立预取，汇合于结果组装前（待事件记录确认）
排除              : 客户端渲染、公网链路（用同机房压测客户端规避）
--------------------------------------------------

本节要点

• 任务、请求、模型调用、尝试是完成相关对象，会话是上下文容器；四者的失败语义互不相同，且会话不是它们的严格父级。
• 端到端时间不是各段之和；只有按依赖建立的关键路径可以直接相加，并须说明重叠已被什么证据确认。
• 单段优化的收益上限由该段在关键路径中的占比决定；"某段归零"只是条件化乐观下界。
• 任务成功由预先定义的契约判定；子调用状态与任务结果分属不同层次。

常见误区

• 误："服务吞吐 120 QPS"描述了业务能力。 正：先说明分母是任务、请求还是 attempt，是否含重试与外部依赖耗时。
• 误：把日志中所有耗时相加得到端到端时间。 正：先在同一可比时间域定义 \(T_{\text{end}}-T_{\text{start}}\)，再按依赖图重建路径；盲目相加可能高估，也可能低估。
• 误：任一子调用失败，任务必然失败。 正：取决于契约是否允许降级、重试、冗余或部分结果；不能作为通则。
• 误：接口全部返回 200，所以任务都成功了。 正：多调用任务需按 task_id 与截止时间聚合判定。

本节验收

1. 你能为自己的系统写出"任务—请求—模型调用—attempt"映射表，并标出每层各自的失败语义。
2. 你能按依赖图算出某一优化手段对端到端的改善上限，而不是只看局部加速比。
3. 你能写出 SUT 边界与外部依赖记账方式，并说明工具/依赖的触发点、消费者与汇合点。
4. 你能指出 linear session 中"历史长度、未复用 Token、算法工作量、墙钟时间"四个量各自的取值来源。

依据与核验入口：R18；工具调用的接口分工待按所选引擎文档核验，见章末 CH01-G07。

---

1.2 从客户端发出到最后一段响应

本节要回答的问题：时间消耗在哪里，哪些阶段可以重叠，以及用什么时间域才能合法地相减？

1.2.1 请求进入与排队

一次请求从发出到进入模型计算，要经过若干道"门"：

1. 连接建立：DNS、TCP、TLS 握手。连接复用（HTTP keep-alive / HTTP/2 多路复用）可以把这部分摊薄到接近零，但压测工具若每次新建连接，就会把握手成本算进每一次请求。
2. 网关与鉴权：限流、鉴权、配额检查、请求体校验。反向代理可能缓冲请求体，也可能缓冲响应体，缓冲策略直接改变用户看到的首字节时间。
3. 准入与排队：队列可能有多级——网关一级、引擎前端一级、调度器内还有一级。请求可能在任意一级被拒绝（429 或 503），而被拒绝的请求若不计数，成功率就是被过滤过的。
4. 批组装：调度器决定本轮把哪些请求放进同一个批次（第5章）。一个请求从入队到真正开始计算的等待，常常比计算本身更长，且分布是重尾的。

排队之所以关键，是因为它对负载敏感：在到达率接近服务能力的区域，排队延迟随负载非线性增长。但不要因此否定轻载测量——轻载的价值是建立基础开销与诊断对照：同配置下的连接开销、鉴权耗时、单请求纯计算时间，都是后续排队的基线。它的不足在于不足以单独预测高负载下的容量与尾延迟，这才是要在受控过载实验中补齐的部分。

1.2.2 模型运行与输出返回

请求被选中后进入两段性质不同的工作，这里的表述需要带上适用条件：

• Prefill：逻辑上处理输入序列并构建每层的键值状态。实现上不一定"一次性算完整段"：引擎可以把长输入切成块（chunked prefill）与推理请求组批，命中前缀缓存时只需处理未复用的那部分。
• Decode：每次生成一个 Token 并访问已缓存的状态。

常见的概括是"Prefill 计算密集、Decode 带宽密集"。这个概括在典型 Transformer 模型、典型批量与上下文长度、给定设备的条件下很有用，但它不是定义，也不能替代测量。真实瓶颈由算术强度、所选执行路径（注意力后端、是否有 CUDA Graph、量化内核）、是否需要跨卡通信以及实测共同决定；某些形状与批大小下 Decode 也可能回到计算受限。因此本书把这句话当作待验证的起点假设，而不是结论。（第3章给出 Roofline 与该判断的量化方法；第11、12章给出不同侧的证据。）

由此得到一条可直接使用的规则：长输入短输出与短输入长输出是两类不同的负载，用其中一类测出的结论不能外推到另一类。

生成开始后输出以流式返回。路径上至少有三个独立缓冲点：服务进程写缓冲、网关响应缓冲、客户端读缓冲与渲染节流。任何一个都可能把"早就生成好了"变成"用户还在等"。

还有一个容易被忽略的真相：多个请求的工作可以在同一次调度迭代中被组织到一起，但这不等于它们在设备上"同时执行"，更不能推出"某个请求自己的 Prefill 与它后续的 Decode 没有先后依赖"。例如 vLLM 的优化文档说明，其核心调度把待处理的 decode 请求排在前面，在 max_num_batched_tokens 预算允许的范围内再调度 prefill，放不下的 prefill 会被自动切块 SOURCE_REGISTERED。这说明的是批的组织方式，把它读成"Prefill 与 Decode 的时间可以任意重叠"就越界了。更严格地说，某些引擎在请求被抢占后会重新执行 prefill 阶段——任何"prefill 只发生一次"的假设都需要按实现核验。

1.2.3 关键路径、时间域与不发生重复计入

第一层：端到端的定义。 端到端时间首先是在同一个可比时间域内的两个事件之差：

\[ T_{\text{e2e}} \;=\; t_{\text{end}} - t_{\text{start}} , \quad t_{\text{end}}, t_{\text{start}} \in \text{同一个已确认可比的 clock\_domain} \]

在此之前谈论"关键路径"是没有意义的，因为跨时间域的差值是伪精确量。

第二层：用依赖图重建路径。 只有当事件依赖图覆盖了等待、计算、传输等相关区间，并按实际依赖建立偏序之后，才能用路径上的区间之和重建端到端。这是一套重建方法，不是对任意日志都成立的恒等式。两个方向的反例都必须记住：

• 只记录了 100 ms 的内核耗时、遗漏了 900 ms 的排队等待时，日志之和（100 ms）小于真实的端到端（1000 ms）；
• 若同一区间被嵌套 span 或多处记录重复登记，日志之和又可能大于端到端。

因此不能写"所有已记录组件耗时之和 ≥ 端到端"这样的无条件结论。（上述反例是逻辑构造，用于说明定义边界，不是任何系统的测量值。）

第三层：分流水去重。 最常见的重复计入来自把服务端区间与客户端区间混在同一列。正确做法是每条流水各自重建，每行写明 start_event、end_event、clock_domain 与是否落在当前观测路径上。

服务端流水（时钟域：server_monotonic；下表时间戳通过带误差上界的跨机关联与 client.send 对齐，误差上界记为 \(\varepsilon\)）：

服务端自 engine.enqueued 起的总计：\(119+480+14+7+3569+3 = 4192\) ms，等于 \(4213-21\)，无重复计入。

客户端流水（时钟域：client_monotonic）：

客户端总计：\(12+7.5+1.5+647+3582 = 4250\) ms，等于 \(4250-0\)，同样无重复计入。注意这里不再把 \(641 \rightarrow 668\) 的 27 ms 单列——它已包含在 647 ms 区间内，若再单列一次，总和会变成 4277 ms，凭空多出 27 ms。这是重复计入的典型形态：同一区间被登记两次。凡是"求和"的表格，都应给出这样一条交叉验证。

由此可以报告三个合法的"端到端/首字"数字，以及它们的口径：

• 服务端视角端到端：4192 ms（engine.enqueued → done_event，服务端时钟域）；
• 客户端视角端到端：4250 ms（client.send → client.rendered，客户端时钟域）；
• 服务端视角 TTFT：\(634-21 = 613\) ms（必须从入队时刻起算，不是 634 ms）；
• 客户端视角 TTFT：\(668-0 = 668\) ms；
• 两者之差 55 ms：由进入引擎前的 21 ms（客户端时钟域）与 634→668 的 34 ms 组成；34 ms 在带误差上界 \(\varepsilon\) 的关联下可以报告为一段传播/网关缓冲时间，但它不是两个 TTFT 口径之差本身。若两个时间域无法校准，则只报告本地间隔与因果顺序，不输出伪精确的单向延迟。

本节要点

• 端到端的定义是同一可比时间域内的两事件之差；依赖图上的路径重建是方法，不是无条件恒等式。
• 日志之和相对真实端到端既可偏小也可偏大，取决于遗漏还是重复登记。
• 服务端流水与客户端流水必须分别重建，每行标注起止事件、时钟域与是否在路径上。
• 轻载测量用于建立基线开销与诊断对照；不能单独推出高负载容量与尾延迟。

常见误区

• 误：组件耗时之和一定大于等于端到端。 正：遗漏等待会偏小，嵌套/重叠记录会偏大；两种都要防。
• 误：服务端日志显示 200 ms，客户端测到 800 ms，所以有一方测错了。 正：两者都对，差额来自网络、网关缓冲与客户端处理，需逐段定位而不是否定一方。
• 误：连续批处理意味着 Prefill 与 Decode 的时间可以随意重叠。 正：它描述的是批的组织策略；同一请求自身的阶段先后依赖仍然存在，"是否重叠"要按实现和 trace 判断。
• 误：轻载下测出的延迟没有什么参考价值。 正：它给出基础开销基线；不足的是不能据此预测高负载行为。

本节验收

1. 你能为自己的服务写出至少两条流水的区间表，标注 start/end 事件、时钟域与是否在关键路径上。
2. 你能自证流水区间之和没有重复计入，并给出交叉验证算式。
3. 你能指出哪些区间因缺乏跨时间域映射而无法进一步拆分，并把它们保留为不可拆分，而不是猜测补齐。
4. 你能给出自己系统中 Prefill/Decode 瓶颈假设的验证计划，而不是把它当作既定事实。

依据与核验入口：R16 R18

---

1.3 模型制品、Tokenizer 与聊天模板

本节要回答的问题：同一个模型名称为什么还不足以定义测试对象？

两份实验报告都写"使用某 8B 模型，输入 2000 字中文"，结果相差 40%，而两者都没有撒谎。差异可能来自权重提交号、聊天模板、分词器版本或停止条件。模型名称是一个品牌标签，不是实验对象的完整身份。本节给出必须固定的最小制品集合，并纠正两个常被写错的推论。

1.3.1 权重与配置身份

一个可复现的模型对象至少包含：

• 仓库与修订号：组织名/模型名 + revision（commit sha）。浮动分支会随上游更新而改变内容，实验记录里必须写 sha，不能写分支名。
• 权重文件与格式：分片数量、文件名与哈希、参数格式。权重损坏或分片缺失往往表现为"能加载但输出异常"，比直接报错更危险。
• 配置文件：层数 \(L\)、隐藏维度 \(d_{\text{model}}\)、注意力头数 \(h\)、键值头数 \(h_{kv}\)、词表大小 \(V\)、最大位置长度、位置编码类型、量化配置字段。
• 精度与量化方案：存储精度、是否带缩放因子、量化粒度、哪些层被排除在量化之外。

其中 \(h_{kv}\) 直接决定每个 Token 的 KV 状态规模。同一个家族里，MHA（\(h_{kv}=h\)）、GQA（\(h_{kv}<h\)）、MQA（\(h_{kv}=1\)）的显存占用可能相差数倍。实验报告不写 \(h_{kv}\)，任何关于显存与容量的结论都无法复核。

量化配置尤其不能被压缩成一个词。名义上的"4 bit 模型"可能是：权重 4 bit、激活 16 bit、累加 FP32、KV 保持 BF16；也可能是权重与激活都 4 bit、KV 也 4 bit；还可能是分块缩放格式，若干元素共享一个缩放因子，实际每位存储开销高于标称值。三种方案的速度、显存与质量完全不同，把它们统称为"4 bit"会让所有比较失去意义（第11章给出完整的存储字节账本）。

1.3.2 分词和模板展开

模型看到的是 Token 序列，不是字符串。映射由分词器与聊天模板共同决定，二者必须分开理解，因为归因时需要隔离变量。

分词器负责把文本切成 Token 并映射为 id，需要记录文件哈希、词表大小、特殊 Token 集合、归一化与预分词规则。聊天模板则把多轮对话渲染成模型实际看到的字符串，决定角色标记格式、系统提示位置、分隔方式、工具定义如何展开。

下面的算例刻意把两个因素分开。算例 1：消息与工具定义完全相同，只有模板不同：

算例 1（仅模板不同，用于隔离模板变量）
输入：system="你是严谨的法务助理"  user="列出三个风险点"   两份样例均不带工具定义

模板 A（简洁标记）
  <|system|>你是严谨的法务助理<|end|><|user|>列出三个风险点<|end|><|assistant|>
  → 展开后 Token 数：34

模板 B（完整角色描述）
  <|im_start|>system
  你是严谨的法务助理
  <|im_end|>
  <|im_start|>user
  列出三个风险点
  <|im_end|>
  <|im_start|>assistant
  → 展开后 Token 数：41

算例 2：在模板 A 的基础上增加工具 Schema：

算例 2（仅增加工具定义，用于说明另一类输入膨胀）
模板 A + 工具定义（约 180 Token 的 JSON Schema）
  → 展开后 Token 数：约 226

两个算例支持的结论不同，不能混着用：算例 1 说明模板差异可以带来约 20% 的输入长度差异；算例 2 说明工具定义可以让输入膨胀近 7 倍。若在对比实验中同时改了模板和工具定义，就只能说"完整模型输入不同"，不能把差异归因到模板本身。

由此得到硬性记录要求：必须同时记录用户原文的受控标识、模板版本、展开后的完整输入文本（或其哈希）与实际输入 Token 数。禁止用字符数估算 Token 数——中英混排、代码、数字、标点的 Token 密度差异极大。正确做法是用所选分词器实际编码后计数，并把计数脚本与分词器版本一并存档。

1.3.3 生成配置与停止条件

输出长度不是模型的自由意志，它由生成配置决定：

不要把 max_tokens 不同直接判成"结果不可比"。正确做法是先记录差异，再判断它在本次实验中是受控自变量（例如专门研究长度上限的影响），还是需要在相同档位下比较，或是可作分层对比（按是否触到上限分组）。只有当实际输出触到上限时，它才是真实的混淆因素。

1.3.4 可复现性的四个层次

固定 seed 不等于结果可复现，这是常识；但不能因此把"可复现"降格为"分布稳定"了事。可复现性至少有四个层次，声明哪一层就提供哪一层的证据：

为什么 L2 不能轻易放弃：某些框架已经提供了条件化的确定性路径。以 vLLM 官方文档为例（来源记录见本书来源编号）：

"vLLM does not guarantee the reproducibility of the results by default, for the sake of performance." SOURCE_REGISTERED

要获得可复现结果，离线模式可关闭多进程以获得确定性调度（文档同时警告这会改变用户代码的随机状态），或启用 batch invariance；在线模式的官方途径只有 batch invariance。并且文档明确限定：

"Even with the above settings, vLLM only provides reproducibility when it runs on the same hardware and the same vLLM version." SOURCE_REGISTERED

batch invariance 自身的状态也必须写清：官方文档标注 beta，有独立的功能跟踪 issue，仅在满足硬件条件（NVIDIA 计算能力 8.0 及以上，或支持 Triton 的 Intel XPU）时可用，通过环境变量启用；实现上会使用确定性内核并关闭部分非确定性优化（如张量并行下的某些自定义 all-reduce），因此官方提示可能带来性能损失，并给出已验证模型清单 SOURCE_REGISTERED。这些已核验信息共同说明一个边界：存在明确的、有代价的、带适用范围的确定性路径，不能因为默认不可复现就只谈统计稳定。

反过来，统计稳定也不能替代语义正确，更不能作为确定性回归失败的免责条件。某项声明要验收哪一层，就提供那一层的证据。

制品清单可以固化成下面这张表，随每次实验保存：

本节要点

• 模型名称不是实验身份；\(h_{kv}\) 与精度方案缺一项，容量与性能结论就无法复核。
• 模板差异与工具定义膨胀是两类不同变量，归因时必须隔离；禁止用字符数估算 Token 数。
• max_tokens 差异要先记录、再判定是否构成混淆因素，不要直接判为不可比。
• 可复现有四个层次；框架已提供条件化确定性路径，但带 beta 状态、硬件要求与性能代价。

常见误区

• 误："我们用的是同一个 8B 模型"，可以直接比较。 正：核对 commit sha、量化方案、模板与停止条件；缺项即说明不可比的具体理由。
• 误：设了 seed，结果就应该每次一样。 正：默认不保证可复现；需要 L2 时要走条件化确定性路径并说明适用范围。
• 误：只要质量分布稳定，就说明可复现性没问题。 正：那是 L3；若声称 L2（数值一致），必须用同版本同硬件下的数值对比来验证。

本节验收

1. 你能列出完整制品清单，让另一人复原同一套输入 Token 序列。
2. 你能区分模板变量与工具定义变量，并说明各算例支持哪个结论。
3. 你能说明权重、激活、累加、KV 四项精度分别是什么。
4. 你能指出本次实验验收可复现的哪一层，并给出对应证据类型。

依据与核验入口：R29 DOC-W02

---

1.4 API、网关、流式事件与会话状态

本节要回答的问题：首字节、首个内容事件和首个可见答案为什么不同，以及"块"能证明什么、不能证明什么？

1.4.1 协议事件不必互斥，内容分类用于定义指标

一次流式响应由一系列事件组成。按内容性质可以分为五类，用于决定"什么算第一个内容"：

这五类不是互斥的：同一个事件可以同时携带内容、工具调用信息结束标志与用量统计。分类的目的是确定指标口径，不是把每个事件强行归到一格。

本书统一使用四个时间戳（工具字段映射见《指标字典与最小测量样例》§4）：

• \(t_{\text{first-byte}}\)：客户端收到第一个响应字节；
• \(t_{\text{first-content-event}}\)：客户端收到第一个非空内容事件（注意：不是第一个协议事件）；
• \(t_{\text{first-visible}}\)：客户端收到第一个可见答案 Token；
• \(t_{\text{done}}\)：收到终端事件。

对于先输出推理内容再输出正式答案的模型，\(t_{\text{first-content-event}}\) 与 \(t_{\text{first-visible}}\) 之间可能相隔数秒。若压测工具统计前者、业务方关心后者，就会出现"监控显示首 Token 800 ms，用户却说等了 5 秒"的经典矛盾。这不是某一方错了，是两个指标名字相近而定义不同。

1.4.2 Token 数、间隔与"块"不能互相替代

这里有一组必须分开的量，混用会让性能结论失效：

由此得到一条操作规则：按 delta 字段累加可以重建内容，但不能据此宣称拿到了准确的 Token 数或逐 Token 生成时刻。如果只能取得分块到达时刻，就只能报告"该观测层的 intervals"，并在报告中写明观测层。

指标定义上也有同样的坑。以 vLLM 官方指标文档为例（参见所列来源正文与版本记录）：vllm:inter_token_latency_seconds 按流式输出事件采样，记录相邻输出之间的墙钟间隔；vllm:request_time_per_output_token_seconds 则按已完成请求记录一次，定义为 \((端到端延迟 - TTFT) / (输出 Token 数 - 1)\)；文档明确指出，当一个输出包含多个 Token 时（文档举例为推测解码），或聚合权重不同时，两者会不一致，并且对输出不超过一个 Token 的请求，TPOT 记为 0 而基准统计会排除它们，因此 Prometheus 直方图与基准统计的 TPOT 可能不同 SOURCE_REGISTERED。所以"ITL 的均值等于 TPOT"只在每个输出恰好一个 Token 的近似下成立。

工具调用还带来一个额外区分：模型返回调用信息与调用方实际执行函数是两个环节。官方工具调用文档明确区分这两者 SOURCE_ENTRY_ONLY（尚未独立取到该页正文，故此处只作机制说明，具体字段名按所选引擎版本核验）。编排层等待外部函数的时间，不应记入模型生成时间，也不应把它算进"模型很慢"的结论里。

最后，工具迁移要按版本解释。AIPerf 与 GenAI-Perf 的字段映射必须结合工具版本与 parser 版本读取，同名字段不代表同口径 SOURCE_REGISTERED（与本书既有登记 S17 指向同一入口）；完整算例见《指标字典与最小测量样例》§5 的 Sample-B0，本书正式编排时并入第7—9章。

1.4.3 网关、分块与客户端呈现

中间环节会改变用户观测到的时刻：

• 网关响应缓冲：反向代理若开启响应缓冲，攒够字节或时间才下发，流式会退化成"批量下发"，首字节显著变长而服务端日志毫无变化。
• 压缩：引入额外缓冲窗口，小分块可能被压在一起下发。
• 分块粒度：服务端可能每生成若干个 Token 或每若干毫秒写一次，一个 SSE 块不等于一个 Token。
• 协议转换：HTTP/1.1 与 HTTP/2、SSE 与 WebSocket 的转换层可能合并或拆分帧。
• 客户端处理：JSON 解析、UI 更新、渲染节流都会让"收到"与"看到"分离。

诊断办法是两端同时采集：客户端按事件打时间戳，服务端在同一进程内记录写出时刻。服务端写出均匀而客户端呈台阶状 → 问题在传输或客户端；服务端写出本身就有长间隔 → 问题在上游生成或调度。把两端对齐到同一时间域的方法见第9章，并须遵守 1.2.3 的时间域规则；各项指标的定义、分母与剔除规则见《指标字典与最小测量样例》§2—3。

1.4.4 有状态 API 与模型缓存是三个不同的层

现代推理服务提供不同层次的"记忆"，语义完全不同：

1. 协议层会话：服务端按会话标识保存消息历史，客户端只发增量。节省的是网络传输与客户端拼接，模型仍可能重算全部上下文。
2. 引擎内前缀缓存：复用已计算的 KV 状态，节省的是 Prefill 计算，与协议层是否保存历史无关。
3. 外部缓存服务：独立进程或存储池，跨实例共享，涉及传输成本与一致性问题。

把"API 有状态"与"复用了 KV 状态"混为一谈，会导致错误的容量判断。还有一个陷阱：保存下来的状态不等于仍然有效。模型 revision、模板或配置变化后，旧缓存可能与当前模型不对应，复用会带来难以察觉的质量退化；状态失效策略的键应包含模型 revision、模板版本与配置哈希。

【版本化实现】有状态接口的存储与重试行为会随版本变化，必须按所选版本核验。已登记快照：SGLang 发布记录涉及 Responses 相关存储行为变更（v0.5.20，发布日 2026-09-18，查阅日 2026-09-29，body_verified=true，runtime_verified=false）SOURCE_REGISTERED。选择此类接口时至少核验四项：会话身份如何生成、重新请求的行为、服务重启后可恢复的范围、客户端取消能否传播到服务端。API 名称相似不代表状态语义相同。

本节要点

• 事件分类用于确定指标口径，类别之间不必互斥；工具调用事件要与答案正文分开。
• 四个时间戳中，\(t_{\text{first-content-event}}\) 与 \(t_{\text{first-visible}}\) 必须区分，否则会与用户体感脱节。
• 生成 Token ID、服务端 usage、重新分词与网络块数是四件不同的事；块边界不是分词边界。
• ITL 与按请求计算的 TPOT 在多 Token 输出下会不一致；工具迁移按版本与 parser 解释。

常见误区

• 误：按 delta 累加，就得到了准确的 Token 数与逐 Token 时刻。 正：只能得到该观测层的内容与到达时刻；Token 数应以服务端计数为准。
• 误：首个流式事件就是用户开始看到答案的时刻。 正：可能是推理内容或工具调用信息；可见答案要按 \(t_{\text{first-visible}}\) 统计。
• 误：服务端用了有状态 API，上下文重算的开销就省掉了。 正：协议层保存与引擎/外部缓存复用是不同机制，需分别取证。
• 误：缓存命中就代表结果正确。 正：revision、模板或配置变化后旧状态可能失效，必须有失效键。

本节验收

1. 你能把一次真实流式响应按五类标注，并给出四个时间戳。
2. 你能说明 Token ID / usage / 重新分词 / 块数四者在本系统的取值差异。
3. 你能解释 ITL 与 TPOT 在何种条件下相等、何种条件下不一致。
4. 你能为有状态接口列出需按版本核验的四项行为。

依据与核验入口：R01 R12 S17 DOC-W07

---

1.5 引擎、调度器、Model Runner 与执行后端

本节要回答的问题：前端、调度器、执行器分别掌握什么信息，以及如何取证"实际走了哪条路径"？

把推理引擎看成一组职责，而不是背诵某个版本的类名。具体实现可以合并或拆分这些职责，但诊断时必须找到等待、决策和执行各发生在哪里。

1.5.1 职责分解

这张表的价值在于按职责逐格排除：排队时间长 → 看准入与调度；首字节慢但生成快 → 看输出与序列化；生成慢但队列空 → 看 Runner 与后端。调度展开在第5章，观测展开在第9章。

1.5.2 Model Runner、图执行与采样

Model Runner（模型执行器）不是"模型本身"，而是持有权重、组织一次前向过程、管理输入输出张量与状态块映射的执行层。它决定：张量形状（批大小 × 序列长度 × 隐藏维度）、逻辑请求到物理状态块的映射（第4章）、是否走图执行、采样在哪个设备完成。

图捕获不是"匹配就重放、不匹配就 eager"这样一个二选一结局。 以某个引擎的 CUDA Graph 设计为例，形状差异的处理至少包含以下机制（设计正文见本书 N27）SOURCE_REGISTERED：

• padding + 描述符匹配：批次用 padded 后的 num_tokens、num_reqs、uniform、has_lora 组成 BatchDescriptor 作为分派键，num_tokens 可以是补齐后的长度；
• 形状桶（bucket）：可用分派键由 cudagraph_capture_sizes 等配置初始化，命中则复用或按需要捕获并缓存；
• 已捕获图的复用：uniform-decode 批次可以复用相同 batch_size 的 non-uniform 图；
• 多种模式：NONE（全部 eager，调试与暖身用）、PIECEWISE（仅部分算子入图，attention 保持 eager）、FULL、FULL_DECODE_ONLY、FULL_AND_PIECEWISE；
• 运行时分派与自动降级：分派器按 FULL → PIECEWISE → NONE 的优先级查找，找不到键则返回 NONE 走 eager；后端能力不足时按 AttentionCGSupport（ALWAYS / UNIFORM_BATCH / UNIFORM_SINGLE_TOKEN_DECODE / NEVER）自动降级到最接近的受支持模式；特定路径（如 cascade attention）被固定分派到 PIECEWISE 或 NONE；
• 捕获时机：图在 runner 首次以非 NONE 模式调用前向（dummy run）时捕获，暖身过程由 GPU model runner 用 NONE 模式执行。

这段机制说明的重点不是让读者记住模式名，而是：同一份形状变化，在不同引擎、不同模式、不同后端下可能落到不同的分支，结局可能多于两种。各模式的具体取值、优先级与适用后端属于版本化实例，完整枚举与固定版本的取值放在第11章，本章只保留"形状 → 描述符/桶 → 分派 → 可能的降级"这条关系链。因此正文只写机制与分支结构，具体默认值与优先级一律按固定版本另行登记。该文档是浮动页面，上述内容未固化 commit，不能被当作任意版本的出厂默认值。

编译与图优化同样有代价：编译耗时、缓存失效条件、产物与形状/硬件的绑定关系。第11章讨论"如何证明实际用了编译产物"。

采样也不是免费的：构建候选集合、排序、温度与惩罚、停止串判定、结构化约束下的合法 Token 掩码，都可能占用可观的每步时间。

把"第一次请求特别慢"拆开，通常会命中下表中的一个或多个来源，它们共同构成冷启动成本（第16章纳入容量模型）：

1.5.3 内核 dispatch 与四种状态

真正完成计算的是注意力内核、GEMM、MoE 路由与通信内核。引擎通常准备多条候选路径，按硬件型号、数据类型、张量形状与功能开关选择，选择失败则按 1.5.2 的分派规则落到其它分支。记录时统一用四个状态：

"声明支持"不等于"实际启用"。形状不在支持范围、数据类型组合不被接受、后端能力等级不足、编译依赖缺失，都会让运行时走到另一条路径。但反过来说，也不是"只要不满足就静默回退"——某些实现会显式报错，某些会降级到相邻模式，某些通过 padding 命中已有桶。写成哪一种，都必须有该版本的证据。

证据强度分三档，不可混用：源码阅读证明"可能走这条路径"；启动日志与配置回显证明"声明了什么"；trace 中的内核名与调用次数才能证明"这一次实际走了哪条路径"。第9章给出把三者分开记录的方法。

1.5.4 固定版本调用图和运行身份

             ┌──────────────────────────────────────────────┐
客户端 ──────▶│ 协议前端  (协议解析 / 模板展开 / 参数校验)      │
             └───────────────┬──────────────────────────────┘
                             ▼
             ┌──────────────────────────────────────────────┐
             │ 准入与队列  (限流 / 排队 / 抢占)                │
             └───────────────┬──────────────────────────────┘
                             ▼
             ┌──────────────────────────────────────────────┐
             │ 调度器  (连续批处理 / 批组成 / 状态块分配)        │
             └───────┬───────────────────────┬──────────────┘
                     ▼                       ▼
        ┌────────────────────┐   ┌──────────────────────────┐
        │ 缓存/状态管理       │   │ Model Runner              │
        │ (块表 / 命中 / 回收) │◀──│ (权重驻留 / 前向组织 / 图) │
        └────────────────────┘   └────────────┬─────────────┘
                                              ▼
                     ┌──────────────────────────────────────┐
                     │ 执行后端 (attention / GEMM / MoE / 通信)│
                     │   命中 → 执行；未命中 → 降级/显式报错/eager│
                     └────────────────────┬─────────────────┘
                                          ▼
                     ┌──────────────────────────────────────┐
                     │ 采样与停止判定 → 输出写出                │
                     └──────────────────────────────────────┘

让这张图对应到具体系统，必须记录运行身份：

【版本化实现】以下快照只说明这些版本"写了什么"，runtime_verified=false：

• vLLM v0.29.0（发布日 2026-09-09，查阅日 2026-09-29，body_verified=true）：Model Runner V2 默认化、保留特定回退、旧入口弃用 SOURCE_REGISTERED。此处的 V2 指模型执行器，不是整个产品的新代际名称，不应简写为"vLLM V2"。
• SGLang v0.5.20（发布日 2026-09-18，查阅日 2026-09-29）：CPU-only Simulator、Responses 存储变更、Prefill CP v1 路径移除 SOURCE_REGISTERED。"路径移除"是兼容性变化，旧教程里的开关在新版本可能已不存在。
• TensorRT-LLM v1.3.0rc28（发布日 2026-09-23，查阅日 2026-09-29）：预发布状态，具体遗留入口清理条目仍需逐项核验，不能据此直接生成迁移步骤 SOURCE_REGISTERED。RC 不能写成 GA，也不一定是主实验环境的合适选择。

三条记录共同说明：旧教程的命令与开关不能默认等价于当前入口。实验前先读所选版本的发布说明，把"移除/弃用/改名"记进实验档案（第18章版本治理）。

【前沿与验证缺口】1.5.2 引用的设计文档是浮动页面，未固化 commit，其模式名称与默认值不得当作任意发布版的事实。要确认某个版本的实际路径，需要固定版本的启动日志与 trace；在此之前只能写"该版本说明……"。

本节要点

• 按七项职责排除问题，而不是按组件名猜测。
• Model Runner 是组织一次前向的执行层；图执行通过 padding、形状桶、复用与自动降级处理形状差异，结局多于两种。
• 内核路径要按默认启用、显式开启、回退/降级、不支持四态记录，并由该版本证据支撑。
• 运行身份八项必填，且必须标注每项的证据强度。

常见误区

• 误：形状不匹配就一定会重捕获，否则一定 eager。 正：可能 padding 命中已有桶、复用相邻模式的图、自动降级或显式报错；取决于版本与后端能力等级。
• 误：配置里开了某个内核，运行时就用了它。 正：形状、dtype、硬件能力与编译依赖任一不满足都会改变落点；必须用 trace 取证。
• 误：读源码确认了分支，就等于验证了执行路径。 正：源码证明可能性，trace 证明事实；两者分开记录。
• 误：浮动文档（stable/latest）里写的默认值就是当前发布行为。 正：浮动页面需固定 commit 或存档后才能作为版本行为证据。

本节验收

1. 你能按七项职责把一次变慢归因到责任单元。
2. 你能说明自己系统处理形状差异的分支结构，并指出默认模式的取值依据来自哪个版本。
3. 你能给出至少一条"声明支持但实际落到其它分支"的场景及其取证方式。
4. 你能填出运行身份表并标注每行证据强度。

依据与核验入口：R01 R23 S02 S04 DOC-W05

---

1.6 超时、取消、重试与资源回收

本节要回答的问题：客户端不再等待后，服务端是否还在工作，以及这段工作该记在哪本账上？

1.6.1 四本账，而不是一张状态表

之前版本把所有层次塞进一张状态表，导致"超时到底是终态还是中间状态"说不清。正确的做法是维护四本互相独立、靠标识关联的账：

要点：

• created 不等于 sent。前者是构造完成，后者是实际发出；混用会让"请求丢在哪"无法判断。
• client_timeout 不是服务端的互斥终态。客户端超时那一刻，服务端的 server_status 可能是 running、completed，甚至因为还在等下游而处于 queued。
• task_outcome 由契约判定，不由任一层的状态机械推导（见 1.1.2 的例子）。
• 关联靠 task_id / session_id / request_id / attempt_id，且会话不必是其余三者的严格父级。

1.6.2 超时语义不止一种

本段讨论的是客户端等待超时。但它不是唯一的截止时间语义，至少还有三类需要区分：网关或反向代理的超时、服务端处理自身的截止时间、以及服务端作为客户端调用下游 RPC 时的 deadline。

这一点在 gRPC 官方指南里写得很清楚（参见所列来源正文与版本记录）：deadline 是客户端不愿再等待的时间点；服务端超过该时间点后，客户端会以 DEADLINE_EXCEEDED 失败，同时 gRPC 服务端会在客户端 deadline 过后自动以 CANCELLED 取消该调用；但服务端应用自身有责任停止它为这个 RPC 启动的活动——官方建议长时间运行的流程周期性检查 RPC 是否已被取消 SOURCE_REGISTERED。该文档还说明了 deadline 传播的实现方式：由于 deadline 是绝对时间点，跨机传播会受时钟偏差影响，gRPC 将其转换为已扣除消耗时间的 timeout SOURCE_REGISTERED。

这段引述给出三个工程含义：（1）"超时"在不同层有不同动作，不能只当作客户端概念；（2）即便框架自动取消，应用层的清理仍是应用自己的责任；（3）跨服务传播 deadline 时必须处理时钟偏差，这与 1.2.3 的时间域规则是一致的。

1.6.3 取消的验收：不要要求"立刻打断前向"

平台层打断一个正在与同批其它请求共享的前向，在很多实现里既不安全也不经济。因此取消的验收应写成如下检查清单，按所选实现逐项核验：

1. 取消何时被接收：哪一层的哪个事件标志着服务端知道客户端不要了（连接关闭、收到取消语义、代理转发了 FIN）？
2. 是否停止调度新的工作：该请求是否立刻不再被排入后续批次？这是最先应满足的一条。
3. 已提交工作如何安全结束：是等到当前迭代结束、还是允许中途终止？共享批如何处理？
4. 输出如何被抑制：后续 Token 是否仍会被写出？客户端是否会收到本应丢弃的内容？
5. 资源何时可安全回收，以及释放到了哪个层级。

第 5 条要特别注意分级：

显存读数的短期变化不能作为是否泄漏的判断依据。很多运行时出于性能考虑会缓存分配而不立即归还；判断"取消后资源没被回收"需要上述分层的证据，而不是一次 nvidia-smi 快照。此项需要按所选实现的源码或内部观测验证 [SOURCE_ENTRY_ONLY]。

1.6.4 重试放大与其假设边界

重试把一次逻辑请求变成多次物理尝试。设每一轮的条件失败概率恒为 \(p\)、且只有前一次失败后才发起下一次重试，最多重试 \(r\) 次，则每个逻辑请求的期望物理尝试次数为：

\[ \mathbb{E}[N_{\text{attempt}}] \;=\; 1 + p + p^{2} + \cdots + p^{r} \;=\; \frac{1 - p^{\,r+1}}{1 - p}, \quad 0 \le p < 1 \]

\(p\) 为无量纲概率。例如 \(p = 0.2\)、\(r = 2\) 时 \(\mathbb{E}[N_{\text{attempt}}] = 1.24\)，即到达率被放大 \(24\%\) [DERIVED]。

这两条假设必须写在结论前面，否则公式会被误用：真实系统中各轮失败概率通常不同（重试往往发生在已经变慢的长尾请求上，其条件失败概率高于平均值），而且重试本身会进一步提高 \(p\)，形成正反馈——这也是为什么可靠性工程强调退避、抖动与放弃条件 SOURCE_REGISTERED。

另一个常见错误是把请求数放大直接当成资源放大。请求数放大 \(24\%\) 不等于显存或算力放大 \(24\%\)：被重试的请求确实偏向长尾（输入长、输出长），资源放大系数因此通常高于请求数放大，但具体倍数取决于长度分布与到达过程，必须由你自己的数据算出来，不能引用通用倍数。本书不给这个倍数，也不声称任何 40% 一类的通用值。

还有一类重复工作不来自重试，而来自幂等性缺失：任务内部子调用被重复触发、缓存键设计不当导致同样的工作每次重算、上游超时后整单重排队。识别办法是把 attempt 与 model_call 分别计数，观察"每任务的模型调用次数"这一比值——它在稳定系统中应基本恒定，突然升高通常意味着重复工作。

本节要点

• 客户端状态、服务端状态、任务结果、资源释放是四本账，靠四级标识关联，不能合并成一张单列状态表。
• 超时语义至少有客户端等待超时、网关超时、服务端截止时间、下游 RPC deadline 四类。
• 取消的验收是五项行为清单，其中"不再调度新工作"是首要项；不要要求无条件立刻打断共享前向。
• 资源释放有四个层级；显存读数不能单独证明或否证泄漏。
• 重试放大公式的前提是"各轮条件失败概率相同且仅在前次失败后重试"；请求数放大不等于资源放大。

常见误区

• 误：超时后重试，成功率高就说明系统健康。 正：重试掩盖长尾失败并放大最贵请求的负载；应按 attempt 统计，并按契约判定任务结果。
• 误：取消了就等于资源释放了。 正：要区分"请求不再持有块""块可再分配""进程归还显存"三个层级。
• 误：请求数放大 24%，资源也放大 24%。 正：长尾请求的资源强度不同，倍数须由自身数据测得。
• 误：客户端超时后服务端肯定停止了。 正：取决于取消是否被接收并传播；必须查服务端终态。

本节验收

1. 你能为自己的系统建立四本账，并用一个请求走完它们。
2. 你能列出所选协议/框架的超时与取消传播机制。
3. 你能给出取消的五项行为检查结果，并注明哪些未能取证。
4. 你能写出重试策略的边界（次数、退避、抖动、放弃条件）与所用假设。

依据与核验入口：R25 S18

---

1.7 实验：为一条请求建立可解释档案

本节要回答的问题：最少需要哪些记录，才能重建一次请求？

1.7.1 系统档案与事件采集

系统档案回答"被测对象是什么"，包含五项：SUT 边界与依赖假设（1.1.3）、制品清单与可复现层次（1.3）、运行身份（1.5.4）、观测点清单、时钟约定（含主机、时间命名空间、时钟种类、校准状态与误差上界）。

采集顺序是"先两端、后内部"。但要修正一个权限假设：拥有接口调用权限（E1）不等于拥有服务端日志、调度日志或显存观测权限。因此观测能力必须按资源层级分层评估。

1.7.2 时间线重建与时间域规则

四种情形覆盖基本形态：短请求、长输入、长输出、主动取消。

关于时钟，规则要写成以时间域为边界，而不是以进程为边界：

• 在同一个已确认可比的 clock_domain 内可以相减。Python 官方文档说明 monotonic() 自 3.5 起、macOS 自 3.10 起、Windows 的 perf_counter() 自 3.10 起，时钟在所有进程间共享；同时强调返回值的参考点未定义，只有两次调用之差有效 SOURCE_REGISTERED。所以"只有同一进程才能相减"过强，但"参考点未定义，只能做差"是硬要求。
• 跨主机需要同步墙钟、时钟映射或带误差上界的关联方法，并把 \(\varepsilon\) 记入事件记录。
• 无法校准时，只报告本地间隔与因果顺序，不输出伪精确的单向延迟。

（顺带一处机制旁证：vLLM 指标设计要求由 engine core 统一记录 QUEUED、SCHEDULED、PREEMPTED、NEW_TOKENS 等事件时间戳，理由正是前端看不到某些事件的时刻，且区间必须基于同一进程的单调时间戳计算 SOURCE_REGISTERED。这说明"同域相减"是真实工程约束，而不仅仅是学院式洁癖。）

重建完成后把每个区间标注为四类之一：实测（有可关联的起止事件）、推导（由其它量算出，写清算式与假设）、仿真（写明模型与输入）、未知（保持空白）。允许标注清楚的估计进入时间图，禁止的是把估计伪装成实测。有假设的推导是有效信息，伪装才是问题。

1.7.3 观测缺口说明

缺口要写成结构化条目（谁影响、补齐需要什么、当前状态），随结论一起保存。它有两个作用：提醒读者结论边界；作为下一次补齐证据的待办清单。

1.7.4 最小事件档案：两条请求走完四本账

前面分散在各节的案例，这里用同一组原始事件串起来。档案含两条请求，全部为构造数据：

R1（正常完成）——即 Sample-B0：

R2（客户端超时、服务端稍后完成，随后重试成功）：

从同一档案导出四本账：

三处必须由档案直接读出的东西：

1. 同一时刻的两本账可以不同：2000 ms 时客户端记 timeout，服务端仍在 running——这不是矛盾，是两个观测层。
2. 幽灵负载有成本：A1 在服务端停留至 5100 ms，其中计算、排队和状态占用须分项取证；它没有向客户端交付结果；它必须进成本分子。
3. 任务成功不等于浪费为零：R2 的任务结果是 success，但它的资源账包含两次尝试。

剩余未知（写入缺口，不猜测补齐）：内部排队与批组成的细分时刻、实际执行路径、释放层级。

E0 可运行样例（输入 → 期望输出）。本档案同时充当事件解析器的单元测试输入——不需要 GPU：

内部采集（排队细分、执行路径、释放层级）继续属于 E2，不因为有了这份档案就变成"已验证"。

本节要点

• 系统档案五要素，其中时钟约定要含误差上界。
• 时钟规则以时间域为界：同域可相减、跨主机需映射、无法校准只报本地间隔。
• 四类标注：实测 / 推导 / 仿真 / 未知；禁止的是伪装，不是估计。
• E1 权限不等于服务端观察权限，实验需分层设计。

本节验收

1. 你能提交五要素齐全的系统档案。
2. 你能为四种情形各给出一条带 start/end 事件与时钟域的时间线。
3. 你能把每个区间归入四类标注之一，未知区间保持空白。
4. 你能说明本章哪些结论因资源层级限制只能停在 client 侧。

依据与核验入口：R16 S01 DOC-W07

---

1.8 深化：关键路径的敏感性，以及取消后还剩多少工作

1.8.1 不是给活动排序，而是给依赖求最长路

把阶段表示为有向无环图。节点 \(v\) 的持续时间为 \(d_v\)，前驱集合为 \(pred(v)\)，则最早完成时间满足

\[E_v=d_v+\max_{u\in pred(v)}E_u,\]

没有前驱时取最大值为零。多个终点再接一个零耗时汇合节点，即可得到整个任务的完成时间。这一递推同时处理串行与并行，不需要先猜“哪些时间应该相加”。图中的边应表达实际依赖，而不是日志打印顺序；并行工具只有被后续消费者等待时，才可能影响汇合点。

第1.1节的工具在 S2 结束即启动：S2 完成于0.43 s，工具完成于0.88 s；主模型 Prefill 完成于3.13 s。在这组固定参数下，工具比主路径至少早2.25 s，即使 Decode 耗时归零也不会接管关键路径。原来的泛化提醒“解码变快后工具可能成为瓶颈”，对另一些图成立，却不适用于这个数值实例。

更一般地说，局部阶段缩短 \(\delta\) 不一定使端到端也缩短 \(\delta\)。假设两条并行分支分别耗时2 s和5 s，汇合耗时为5 s。把短分支从2 s优化为1 s，端到端不变；把长分支从5 s优化到1 s，端到端只能降到2 s。优化过程中最长路会切换，所以局部占比仅在一段参数区间内有解释力，不能无限外推。

图中数据来自本章参数及依赖递推，不是某个实际应用的观测。配套程序对6.70 s、5.77 s、3.60 s以及工具完成时刻执行断言；图只回答算术和依赖是否一致。

1.8.2 单向延迟需要误差预算

设主机A的时间戳误差不超过 \(\varepsilon_A\)，主机B不超过 \(\varepsilon_B\)。即使两台机器都使用墙钟，\(t_B-t_A\) 仍应解释为一个误差不超过 \(\varepsilon_A+\varepsilon_B\) 的区间，而不是一个无误差的点。若估计传输仅20 μs、同步误差却达100 μs，报告20 μs没有诊断意义；此时应改用同端往返时间、发送与确认事件，或明确只保留因果先后。

同样，两个本地持续时间之间可以比较长短，但这不会自动产生网络的单向分解。例如客户端668 ms与引擎613 ms之差可作为边界残差讨论，前提是同一次调用、可比时钟速率与端点语义已经固定；要再把残差拆成进入引擎前与离开引擎后，必须增加跨域映射证据。边界残差还可能包含未入账的串行化、代理和异步处理，不能全命名为网络耗时。

1.8.3 资源账是积分，不是把请求停留时间相加

请求超时后还占用多少显存，应记录随时间变化的持有量 \(M_i(t)\)，其占用成本可表示为 \(\int M_i(t)dt\)，单位为 GiB·s。设备计算成本则可按归属明确的执行活动或共享批分摊策略记录；排队一秒不等于计算一秒。对共享块应先按物理身份去重，再讨论按请求如何分摊，避免四个分支持有同一块就收费四份物理显存。

因此，取消闭环至少有两个独立终点：业务不再等待的时刻，以及资源重新可用的时刻。二者之差并非都能消除：当前共享前向可能需要安全完成。但是这个窗口若随取消量持续累积，就会降低后续准入能力。第4章检查物理块，第9章检查观测证据，第12章进一步处理跨进程的所有权与租约。这里建立的是这些后续分析共同使用的时间和资源单位。

---

章末检查问题

1. 如何证明"慢在模型外"，而不是仅凭端到端时延猜测？

答案方向：先按 1.1 定义 SUT 边界与完成单位并写清依赖关系；再按 1.2 在同一时间域内定义端到端，用依赖图重建关键路径，把每个区间标为实测/推导/仿真/未知；最后用干预 + 复测验证——例如把检索替换为固定返回的桩服务，观察端到端是否按预期下降。若下降量与检索段耗时不符，说明存在重叠或口径问题。关键在于干预，而不是看比例推断（第10章展开）。注意：轻载下的这条结论不能外推到高负载。

2. 网关重试两次后成功，任务是否成功？各自怎么记账？

答案方向：四本账分开写。client_status：两次 timeout、第三次收到完整响应。注意客户端超时不是服务端终态——不能顺手把前两次直接记为服务端失败。server_status：三次 attempt 必须逐一对账，取值可能是 completed、cancelled、failed 或仍未确定（服务端可能在客户端放弃后仍完成/仍在运行），每一项都要有服务端记录支撑，不能用客户端的超时推断。task_outcome：按预先定义的任务契约判定——契约若规定"最终收到可用答案且总耗时在契约内即成功"，则为 success；若规定了总截止时间或不允许重试，则需按契约条款判定。resource_release_status：前两次尝试占用的资源是否释放，必须按 1.6.3 的层级取证，未取得证据时记 unknown。成本侧还要把两次失败尝试消耗的资源计入，而不是被"最终成功"掩盖。

3. 如何证明实际使用了配置要求的 runner 与内核，而不是落到其它分支？

答案方向：按 1.5.4 填运行身份表并标证据强度——源码只证明可能性；启动日志的配置回显证明声明；运行期trace或等价插桩，结合调用关联、形状和编译身份，才能支撑这一次的实际路径；内核名称本身不总是唯一身份。同时按 1.5.2 记录形状差异的处理分支（padding / 桶命中 / 降级 / eager / 报错），并记录形状、dtype、后端能力等级等触发条件；输出长度或形状变化后必须重新取证。

---

本章验收清单

---

配套资料

新增图表与数据 · 来源登记 · E0测试清单 · 修订记录

第2章 Prefill、Decode 与模型执行

核心论点：模型结构决定需要做哪些工作，负载与实现决定这些工作怎样消耗资源；不能把阶段名称直接当成瓶颈结论。

本章导航

读完本章，你应该能够：说清"生成一个 Token"需要经过哪些步骤，以及推测解码如何改变"每轮一个 Token"的基线；分别估算 Prefill 与 Decode 的工作量与访存量；用模型配置算出每个 Token 的状态字节数，并知道常规公式何时失效；区分 MoE 的总参数、激活参数与驻留权重；把推理内容、可见答案、媒体输入、结构化约束与外部工具等待分别计量。

单位约定：状态容量用二进制单位（KiB/MiB/GiB），带宽与算力用十进制（GB/s、TFLOP/s）。两者混写是本书明文禁止的做法（写作规范 §6）。

---

2.1 自回归生成与一次解码迭代

本节要回答的问题：生成一个新 Token 需要哪些已有信息？

2.1.1 条件概率与前向计算

自回归模型在每一步做的是同一件事：给定已有上下文 \(x_{1:t}\)，计算下一个 Token 的条件分布 \(P(x_{t+1}\mid x_{1:t})\)，再从中取出一个。计算过程是一次前向：

1. 输入 Token 经嵌入层得到形状为 \([B,\,S,\,d_{\text{model}}]\) 的张量（\(B\) 批大小、\(S\) 序列长度、\(d_{\text{model}}\) 隐藏维度）；
2. 依次通过 \(L\) 层，每层做注意力与前馈计算，输出同形张量；
3. 最后一层经输出投影得到 logits，形状为 \([B,\,S,\,V]\)（\(V\) 为词表大小）；
4. 取最后一个位置的 logits 做采样。

在未命中前缀、未分块的普通 Prefill 示意中，\(S\) 等于输入长度；分块时 \(S\) 是本轮实际处理的位置数。普通 Decode 每个序列通常输入一个待消费 Token；推测验证可以一次处理多个位置，不能再说每次前向只推进一个位置。这就是两阶段工作量差异的根源：同样的权重，处理的 Token 数量差了几个数量级。

2.1.2 采样与停止

logits 经温度、top-p/top-k 等处理得到采样分布，抽出一个 Token id，再判定是否停止（EOS、停止串、max_tokens、结构化约束完成）。采样与停止判定不是免费的：构建候选集合、排序、掩码计算都要时间，批很大或词表很大时它们是可观的每步开销。

2.1.3 计算图与生成循环

生成循环与模型层内部计算要分开描述。伪代码如下（不冒充任何框架源码）：

# 伪代码；不是具体引擎 API。
# 不变量：cache 只包含已经经过目标模型前向的位置。
cache, logits = prefill(prompt_tokens)
pending = sample(logits_at_last_prompt_position(logits))
outputs = [pending]                 # 刚采样的 Token 尚未写入目标 KV
while not should_stop(outputs):
    cache, logits = forward_and_commit(cache, pending)
    # 上一步把 pending 的 K/V 写入 cache；不是把下一个 Token 的状态提前写入。
    pending = sample(logits)
    outputs.append(pending)

# 推测解码的接口层示意：实现还要处理验证失败与截断。
# target_cache 保留已消费的位置，pending 是最近采样但尚未消费的位置。
drafts = propose_drafts(pending, k)
provisional_cache, distributions = verify_target(target_cache, [pending] + drafts)
accepted_prefix, correction_or_bonus = exact_accept_reject(distributions, drafts)
target_cache = keep_consumed_prefix(provisional_cache, pending, accepted_prefix)
outputs.extend(accepted_prefix)
outputs.append(correction_or_bonus)  # correction/bonus 暂为新的 pending
pending = correction_or_bonus
# 若停止符落在 accepted_prefix 内，应先截断并同步裁剪状态与输出。

首个采样结果就触发停止时，不再无条件执行一步 Decode。推测分支里，“提交了哪些 KV 位置”和“对外接受了哪些 Token”仍是两笔账：校正 Token 通常尚未经过目标模型前向。

"每轮只产生一个 Token"只适用于普通自回归基线。开启推测解码后，一次前向可能验证多个候选，因此必须区分三个量：前向次数、解码迭代次数、最终接受的 Token 数。把"迭代次数"当成"输出 Token 数"会让所有吞吐指标失真（第7章 7.3.2 已规定：被拒的候选不进产出分子）。

推测解码必须区分两个不同的计数：

\[ \mathbb{E}[\text{接受的草稿数}] = \sum_{i=1}^{k}\alpha^{i} \qquad \mathbb{E}[\text{本轮推进量}] = \sum_{i=0}^{k}\alpha^{i} \]

后者包含被拒后的校正 Token（或全部接受时的额外 Token），因此比前者多 1 个量级为 1 的项。可算例：\(k=4\)、\(\alpha=0.7\) 时两者分别为 1.7731 与 2.7731——不能把它们都叫"接受草稿数"。

若整轮相对成本（含提出草稿、目标验证、校正与相关开销）为普通一步的 \(c=1.3\) 倍，则每 Token 相对成本为 \(1.3/2.7731 = 0.469\)，理论加速约 2.13 倍。注意这里的 \(c\) 必须是整轮成本：只给目标验证的成本不足以推出整个系统的加速比；接受率随负载、批大小与模型而变，不是常数；被拒的 Token 消耗资源但不产出内容。

本节要点

• 前向次数 ≠ 解码迭代次数 ≠ 接受的 Token 数，三者必须分开计数。
• Prefill 逻辑上处理输入中未复用的位置，可分成多次前向；普通 Decode 与推测验证的输入长度和推进量分别计数。
• 采样与停止判定有成本，批大或词表大时不可忽略。
• 推测解码的理想加速 = 期望总推进量 ÷ 整轮相对成本，且依赖接受率这一实测变量。

常见误区

• 误：迭代 300 次就是生成了 300 个 Token。 正：开启候选验证后两者不同；分别计数。
• 误：推测解码开启就等于快 \(k\) 倍。 正：实际倍数由接受率与验证成本决定，可能小于 1（反而变慢）。
• 误：采样只是选个数字，不花时间。 正：排序、掩码与停止判定在每步都有成本。

本节验收

1. 你能区分前向次数、解码迭代次数与最终接受 Token 数。
2. 你能用接受率与相对成本估算推测解码的收益区间。
3. 你能说明被拒绝的候选在吞吐与成本两处分别如何记账。

依据与核验入口：R04

---

2.2 Prefill：从输入序列构建状态

本节要回答的问题：输入长度增加，会增加哪些工作？

2.2.1 批量处理已知输入

Prefill 处理的是已经给定的上下文：整段输入可见，因此可以在序列维度与批维度上充分并行。它的实际工作量取决于两件事：实际需要计算的 Token 数（若命中前缀缓存，未复用的部分才是真正要算的）与批内有效 Token 的编排方式（引擎可能把长输入切成块与解码请求组批，第1章 1.2.2、第5章）。

2.2.2 注意力与线性层工作量

Prefill 的计算量大致分两块：

• 线性层：\(\text{FLOPs}_{\text{lin}} \approx 2\,P\,T\)，其中 \(P\) 为参与计算的参数量，\(T\) 为实际计算的 Token 数；
• 注意力：\(\text{FLOPs}_{\text{attn}} \approx 4\,L\,S^{2}\,d_{\text{model}}\)（含 \(QK^{\top}\) 与 \(AV\) 两次矩阵乘）。

可算例：取 \(L=32\)、\(d_{\text{model}}=4096\)、稠密 \(P=7\times10^{9}\)、\(S=T=4096\)：

\[ \text{FLOPs}_{\text{attn}} = 4\times32\times4096^{2}\times4096 \approx 8.8\ \text{TFLOP} \qquad \text{FLOPs}_{\text{lin}} = 2\times7\times10^{9}\times4096 \approx 57.3\ \text{TFLOP} \]

先说清口径：15.3% 是"注意力 ÷ 线性项"；若按"注意力 ÷ 两项总和"计，则为 13.30%。两个口径都合法，但必须声明。

长度翻 4 倍后注意力占比从 13.30% 升到 38.03%，但它仍未超过线性项——所以不能不加定义地写"注意力成为主要项"。按这个简化公式，两项相等的长度为

\[S^{\ast} = \frac{2P}{4Ld_{\text{model}}} = \frac{2\times7\times10^{9}}{4\times32\times4096} \approx \mathbf{26703} \ \text{Token}\]

这是代数阈值，来自简化公式，不是硬件上瓶颈真正切换的实测点。

还要说明 \(4LS^{2}d\) 的形式：它按完整方阵计数。因果语言模型只需下三角（约为一半），实现是否真正跳过被掩码的部分取决于内核与布局；因此"理论有效计算量"与"实际执行计算量"要分开记账。上表是内部一致性复算，不构成对该公式全部适用范围的认证。

补充推导：命中前缀之后究竟省掉什么。 设已有 \(H\) 个前缀 Token 的状态可完全复用，本次新增 \(U\) 个 Token，采用标准全因果注意力，暂不考虑稀疏、滑窗、共享层与重算。新增的第 \(i\) 个 query 仍需关联它之前的 \(H+i\) 个位置，因此新增的有效 query-key 对数为

\[N_{\text{pairs}} = \sum_{i=1}^{U}(H+i) = UH + \frac{U(U+1)}{2}\]

在每个 query-key 对的 \(QK^{\top}\) 与 \(AV\) 合计约 \(4d_{\text{model}}\) 次运算、共 \(L\) 层的模型下，注意力部分的有用计算量约为 \(4Ld_{\text{model}}\,[\,UH + U(U+1)/2\,]\)。

算例：\(H=4096\)、\(U=128\)：

两个结论：复用长前缀后新增128个Token，与独立128个Token请求的注意力工作量不同（本例有效query-key对数相差约64.5倍，不代表全请求耗时同倍）；命中前缀相对全部重算省下约 94% 的注意力对数，但这是注意力部分，投影/前馈的线性项仍随实际处理的 Token 数走，所以不能把"命中率"直接换算成端到端提速。实际内核的块形状、数据读取、padding 与调度另需取证。

2.2.3 首输出与状态建立

Prefill 的产出是两样东西：第一个输出 Token 的 logits，以及后续生成所需的每层状态。因此它的结束位置与"首 Token 时间"高度相关，但不能把端到端 TTFT 全部算成 Prefill 计算——其中还包含排队、网络与网关缓冲（第1章 1.2.3、第7章 7.2.2）。

状态规模是第4章的主角，这里只给出后续会反复引用的基本式。对常规注意力（MHA/GQA/MQA），每个 Token、每层需要存 K 与 V 两份：

\[ b_{\text{token}} = 2 \cdot h_{kv} \cdot d_{\text{head}} \cdot L \cdot b_{\text{dtype}} \quad [\text{byte/token}] \]

取 \(h_{kv}=8\)、\(d_{\text{head}}=128\)、\(L=32\)、\(b_{\text{dtype}}=2\)（BF16）：

\[ b_{\text{token}} = 2\times8\times128\times32\times2 = 131072\ \text{B} = \mathbf{128\ KiB/token} \]

一条 4096 Token 的序列即 \(128\ \text{KiB}\times4096 = \mathbf{512\ MiB}\)。这个数字后面会一直用到。

本节要点

• Prefill 处理已给定上下文，可充分并行；实际工作量取决于未复用 Token 数与批内编排。
• 在本节全注意力简化模型中，线性项随 \(S\) 增长、注意力项随 \(S^2\) 增长；是否占主导还取决于结构、长度区间和执行内核。
• 首 Token 时间与 Prefill 强相关，但 TTFT 不等于 Prefill 计算时间。
• 常规 KV 公式给出 128 KiB/token、4096 序列 512 MiB 的量级参照。

常见误区

• 误：输入 4096 Token，Prefill 时间就是"每 Token 耗时 × 4096"。 正：注意力项是平方增长，且排队与网络不属于 Prefill。
• 误：命中了前缀缓存，输入长度还是按全部计入。 正：实际计算的是未复用部分；两者都要记录。
• 误：KV 公式对所有模型都成立。 正：压缩/共享/递归结构必须换公式（见 2.4）。

本节验收

1. 你能解释"输入更长"与"实际需要重算的输入更多"的区别。
2. 你能算出本例在 4096 与 16384 两种长度下注意力项的占比变化。
3. 你能给出本模型每个 Token 的状态字节数，并说明公式成立的前提。

依据与核验入口：R03 R07

---

2.3 Decode：逐步生成与状态访问

本节要回答的问题：为什么并发、上下文和输出长度都影响生成表现？

2.3.1 单步权重与状态访问

Decode 每一步要读三样东西：权重、已有状态、以及上一步的输出 Token。以 7B 稠密 BF16 模型为例，单步访存为

\[ M_{\text{weights}} = P \cdot b_{\text{dtype}} = 7\times10^{9}\times2 = 14\ \text{GB} \] \[ M_{\text{state,seq}} = b_{\text{token}} \cdot S = 128\ \text{KiB}\times4096 = 512\ \text{MiB} \approx 0.5369\ \text{GB} \]

注意第二项随上下文长度增长，第一项与上下文无关但与模型大小成正比。批大小为 \(B\) 时，在"权重一次读入后在同一批内被复用"的理想近似下，权重访存被摊薄，状态按序列累加：

\[ M_{\text{step}} \approx M_{\text{weights}} + B \cdot M_{\text{state,seq}} \]

取 \(B=8\)：\(M_{\text{step}} \approx 14 + 8\times0.5369 = \mathbf{18.29\ GB}\) [DERIVED]。若设备带宽为 \(2.0\ \text{TB/s}=2000\ \text{GB/s}\)，则单步下界

\[ t_{\text{step}} \approx \frac{18.29}{2000} = 9.15\ \text{ms} \]

对应单序列约 \(109\ \text{token/s}\)、整批 \(8/0.00915 \approx 874\ \text{token/s}\)。这是理想流量下界：它假设权重与状态各读一次、无额外拷贝，并假设计入的权重与状态必须从该层存储读入。实际 DRAM 流量可因临时缓冲、重复加载而增加，也可因片上缓存命中而低于“全部从 HBM 读取”的估算，因此"理想流量 / 带宽"只在该流量假设成立时给出时间下界，不能当作预测值；两者的差额本身就是诊断对象（第9章）。这是带宽下界的粗略估算，不是实测值：它忽略了内核效率、缓存命中、通信与调度开销（第3章给出完整模型）。

2.3.2 活跃序列与批次复用

上式已经说明了批处理的价值：权重访存被 \(B\) 个序列摊薄。算术强度（FLOP/byte）随 \(B\) 上升——\(B=1\) 时约 \(14\ \text{GFLOP}/14.54\ \text{GB}\approx0.96\)，\(B=8\) 时约 \(112\ \text{GFLOP}/18.29\ \text{GB}\approx6.12\) [DERIVED]。这就是为什么批大小是 Decode 阶段最关键的变量之一（调度策略见第5章）。

但批大小受制于显存：每个活跃序列都要驻留自己的状态，\(B\) 与 \(S\) 的乘积决定容量上限（第4章）。

2.3.3 长输出的累计成本

Decode 的成本是逐步累加的，且随输出变长而恶化：状态随已生成 Token 增长，每步都要读更多数据。因此长输出的边际成本递增，这与 Prefill 一次性付清的形态完全不同。

所以"Decode 永远是显存带宽瓶颈"这句话只能当作起点假设：随并发、上下文、并行策略与模型结构变化，瓶颈可能迁移——大批长上下文时可能是容量不足导致抢占与重算（第4、5章），多卡时可能变成通信（第6章），小批短上下文时可能是内核启动与调度开销占主导。正确的做法是给出工作量分解，并写成至少两种可区分的假设，再用第9章的观测去判别。

本节要点

• 单步访存 = 权重（与模型大小成正比）+ 状态（随上下文与并发增长）。
• 批处理摊薄权重访存、提高算术强度，但受显存容量约束。
• 全注意力下，随上下文增长的状态访问项会累积；总耗时是否明显超线性仍取决于权重项、缓存、调度以及是否为滑窗或递归结构。
• "Decode 一定是带宽瓶颈"是待验证假设，不是结论。

常见误区

• 误：Decode 慢就一定是显存带宽不够。 正：还可能是容量不足、通信、调度开销或内核效率；要写竞争假设并测量。
• 误：批大小越大越好。 正：受显存容量与尾延迟约束；过大可能引发抢占与重算。
• 误：输出长度翻倍，耗时也翻倍。 正：不能无条件按倍数推断；全注意力状态访问含增长项，权重主导或有界窗口时可以接近线性。

本节验收

1. 你能为同一模型写出至少两种不同的 Decode 瓶颈假设。
2. 你能说明区分这两种假设需要哪些测量（并指向第9章的哪一类证据）。
3. 你能估算本模型在给定批大小与上下文下的单步访存量。

依据与核验入口：R04 R30

---

2.4 注意力与状态结构：全量、压缩、稀疏与混合

本节要回答的问题：模型结构如何改变状态的种类、增长方式和实际缓存布局？

2.4.1 MHA、GQA、MQA 与常规 K/V 账本

查询头数 \(h\) 与键值头数 \(h_{kv}\) 的关系决定状态的份数：

沿用 2.2.3 的参数（\(d_{\text{head}}=128\)、\(L=32\)、\(b=2\)）：GQA（\(h_{kv}=8\)）为 128 KiB/token，MQA（\(h_{kv}=1\)）为 16 KiB/token——相差 8 倍，正好是 \(h_{kv}\) 之比。这就是为什么 \(h_{kv}\) 必须写进实验记录：只看"模型 7B"推不出状态规模。

2.4.2 MLA 与压缩表示：常规公式在这里失效

压缩潜在表示（如 MLA）不存两份 K/V，而是存一个低维潜在向量（外加少量用于位置编码的解耦部分）。此时不能套用 \(2\,h_{kv}\,d_{\text{head}}\) 公式，必须按其真实维度计算：

\[ b_{\text{token}}^{\text{MLA}} = \left(d_{c} + d_{r}\right)\cdot L \cdot b_{\text{dtype}} \]

取 \(d_c=512\)（潜在维度）、\(d_r=64\)（解耦位置部分）、\(L=32\)、\(b=2\)：

\[ b_{\text{token}}^{\text{MLA}} = (512+64)\times32\times2 = 36864\ \text{B} = \mathbf{36\ KiB/token} \]

与同规模 GQA 的 128 KiB 相比为 \(131072/36864 \approx \mathbf{3.56}\) 倍。

但"压缩存储"不等于"执行时也是压缩的"：后端可能展开、复制或另行缓存。因此状态预算要分三栏记：逻辑字节（按模型设计算）、后端实际布局、实测分配。三者不一致时，容量规划引用实际执行层，而差异本身要登记为证据缺口。

2.4.3 稀疏索引、压缩主缓存与重算

稀疏注意力减少的是参与计算的位置，不自动等比例减少被保存的状态。三类机制要分开：

判断这类结构对容量的影响，只能靠逐项账本，不能靠"它用了稀疏所以显存一定更小"的直觉。

2.4.4 跨层共享、递归状态与混合层

还有一种容易算错的情形：跨层共享的状态按物理身份只计一次，不能按层数重复相加。若 \(m\) 层共享同一份状态，它在容量账本里是一份，而不是 \(m\) 份。

递归类结构（线性注意力、门控增量规则等）的状态大小与上下文长度无关（常数级 per layer per sequence），但每层都有一份。混合层布局（部分层用注意力、部分层用递归）必须逐层记账：

2.4.5 模型卡、配置与实际后端布局的三重对照

最后要回答一个高频问题：模型卡写 FP4，而后端记录的是另一种存储格式，该引用哪一层？

答案是：容量与带宽预算引用实际执行层（后端实际分配与访问的格式），因为它是真正占用显存与带宽的量；但模型卡的设计意图也要登记，因为它是判断"这个数字为什么是这样"的依据，也是版本变化时复核的抓手。两者不一致时，把差异写进证据缺口，而不是挑一个好看的数字。

作为版本化资料案例：某模型卡描述了压缩/跨层共享结构与模型侧低精度主缓存，某引擎发布说明记录了特定硬件路径上的分块低精度存储 SOURCE_REGISTERED S02。这两项记载用于说明"模型设计"与"后端落实"必须分开看，不能用于推算未经运行的显存或吞吐（均为页面快照，runtime_verified=false）。

本节要点

• 常规 KV 公式只在 MHA/GQA/MQA 且无压缩共享时成立；\(h_{kv}\) 是必须记录的配置字段。
• 压缩表示按真实潜在维度计算；同规模下与 GQA 可差 3.5 倍以上。
• 稀疏减计算不自动减存储；跨层共享只计一次；递归状态不随上下文增长。
• 三重对照：逻辑字节 / 后端实际布局 / 实测分配；容量引用实际执行层。

常见误区

• 误：用了 MLA，就把 \(h_{kv}\) 填进常规公式。 正：公式不适用；按潜在维度算，并核对后端是否展开。
• 误：稀疏注意力省显存。 正：省的是计算；存储要按账本算，索引器还可能新增占用。
• 误：跨层共享的状态乘以层数。 正：按物理身份计一次。
• 误：模型卡写了 FP4，就按 FP4 算显存。 正：以后端实际分配为准，并登记两者差异。

本节验收

1. 你能指出常规 KV 公式在何种结构下必须替换。
2. 你能为一份模型配置写出分项状态账本（类型/增长/共享/重算/分配位置）。
3. 你能说明模型设计与后端布局不一致时，容量预算引用哪一层及理由。

依据与核验入口：R04 R28 S12

---

2.5 Dense、MoE 与混合状态模型

本节要回答的问题：参数总量为什么不能直接代表每步计算与驻留内存？

2.5.1 三张清单：参与计算、占用存储、发生传输

MoE 与 Dense 的根本区别在于：计算只走被选中的专家，但所有专家都要在内存里。因此必须用三张清单分别记账，而不是用一个参数量预测全部性能：

可算例：设某 MoE 总参数 \(80\times10^{9}\)（BF16 下 160 GB 驻留），每 Token 从 64 个专家中选 2 个、激活参数 \(8\times10^{9}\)。则：

• 单步计算量 \(=2\times8\times10^{9} = 16\ \text{GFLOP/token}\)（按激活参数）；
• 驻留显存 \(= 80\times10^{9}\times2 = \mathbf{160\ GB}\)（按总参数）；
• 计算量与驻留的差异达到 10 倍。

因此"MoE 的激活参数等于 8B，所以可以当 8B 稠密模型用"是错的：其参数参与的线性计算项按约 8B 计、未卸载权重驻留按约 80B 计；这不等于与 8B Dense 同速。

2.5.2 专家路由与通信工作量

路由把每个 Token 送到被选中的专家；跨卡部署时，这需要在设备间搬运 Token 表示。通信量的量级为

\[ M_{\text{route}} \approx 2 \cdot B \cdot d_{\text{model}} \cdot b_{\text{dtype}} \cdot k \]

其中 \(k\) 为每 Token 选择的专家数，系数 2 表示去程（dispatch）与回程（combine）。取 \(B=8\)、\(d_{\text{model}}=4096\)、\(b=2\)、\(k=2\)：

\[ M_{\text{route}} \approx 2\times8\times4096\times2\times2 = 262144\ \text{B} = \mathbf{256\ KiB/步} \]

这个数字必须带边界说明：它是一层上的逻辑 payload（\(B\) 个 Token、top-2、去回程合计），不是"整模型每步网络量"。要写成后者，还需说明：是否所有专家都跨设备（同设备命中不产生网络流量）、同一 Token 是否被重复发送到多个 rank、是否计元数据与填充、以及是全局批还是单个 rank 的批。单看字节数不大，但这是每一步都要发生的同步等待：它的耗时取决于延迟与同步频率，而不是带宽（第6章展开）。此外还有两个工程问题：

• 专家偏斜（skew）：某些专家被过度选择，导致持有它们的设备成为尾延迟来源；
• 容量因子与丢弃：超过专家容量的 Token 可能被丢弃或改路由，影响质量。

2.5.3 注意力状态与递归状态并存

混合状态模型可能同时维护注意力缓存与递归状态。两者增长规则不同（前者随上下文线性增长，后者常数），不能合并成一个"KV 大小"，也不能用其中一个的经验去推另一个。分层记账见 2.4.4 的表。

2.5.4 混合结构的模型与后端证据

作为资料案例：某模型卡描述了门控增量规则与稀疏注意力的混合结构，且在该快照中明确标注为实验预览 SOURCE_REGISTERED。使用这类结构时有两条纪律：

1. 预览/实验状态不等于可复现的主实验环境——主案例应选择版本可冻结、行为可验证的对象（第1章"三层写作结构"）；
2. 激活参数量不等于同参数稠密模型的等价性能——计算、存储、传输三条账要分别算，路由与通信的实测留到第6章。

本节要点

• MoE 要分三张清单：计算按激活参数、存储按总参数、传输按路由量。
• 线性计算项按激活参数、未卸载驻留按总参数——激活参数不能代表驻留内存。
• 路由通信是每步同步，关注延迟与偏斜，不只是字节数。
• 混合状态模型要分层记账；预览模型不作主实验环境。

常见误区

• 误：MoE 激活 8B，显存就按 8B 算。 正：未选中的专家仍需驻留；按总参数算存储。
• 误：路由传输才 256 KiB，通信可以忽略。 正：它是每步同步，瓶颈常在延迟与偏斜而非带宽。
• 误：混合结构只需一个"状态大小"数字。 正：注意力与递归状态增长规则不同，分层记账。

本节验收

1. 你能分别估计 MoE 的计算量、权重驻留与会话状态。
2. 你能说明路由通信的瓶颈形态（带宽 vs 延迟/同步）。
3. 你能说明预览状态模型在本书中的使用边界。

依据与核验入口：R05 R30 S12

---

2.6 推理模型、多模态与结构化生成负载

本节要回答的问题：文本之外的输入与输出约束如何进入性能分析？

2.6.1 内部生成与可见答案

推理（思考）型模型会先产生一段内部生成，再输出可见答案。这带来三条计量规则：

1. 三者分开计数：内部生成 Token、可见答案 Token、以及计费/用量字段可能互不相等；
2. 两个"首次"分开记录：首内部 Token 与首可见 Token 对应不同体验（第7章 7.2.1 的 TTFT/TTFO）；
3. 观测不到的内部生成记未知，不得用可见长度反推，也不得填 0。

结构化输出还要额外记录：格式约束类型（JSON Schema / 语法）、解析成功率、以及因约束失败而重生成的次数——后者消耗资源但不产出内容，与推测解码被拒的候选属同一类（不进产出分子，进成本分子）。

2.6.2 编码器与媒体输入

多模态负载在文本之外多了三段：媒体读取与解码、预处理（缩放/分块/采样）、编码器执行。这三段通常发生在主机或独立编码器上，应单独计时，不要并入文本 Prefill 的时间。

记录字段建议：媒体类型与尺寸、分辨率或时长、分块与采样策略、编码后产生的 Token 数、以及编码器耗时。不要把"图像数量"强行换算成通用文本 Token——不同模型的投影方式与 Token 数差异很大，换算只能来自该模型的实际编码结果。

2.6.3 结构约束与工具调用

工具调用负载要区分三段时间：模型生成调用信息、编排层等待外部函数、以及结果回填后的续生成。其中编排层等待属于外部依赖，不计入模型生成时间（第1章 1.1.3、第8章 8.3.3）。实验里建议用注入的固定延迟代替真实外部调用，以便复现与解释。

多轮分支任务还要同时报告两件事：模型工作量（Token 与状态）与任务完成条件（必需分支、容错策略、截止时间），后者按 task_id 判定（第7章 7.5）。

本节要点

• 内部生成、可见答案、用量字段分开计数；不可观测的内部生成记未知。
• 多模态的读取/预处理/编码三段单独计时；媒体 Token 数来自实际编码。
• 工具调用的编排等待不进模型生成时间；实验用注入延迟替代真实外部调用。
• 分支任务同时报告模型工作量与任务完成条件。

常见误区

• 误：可见答案 300 Token，所以生成了 300 Token。 正：内部生成可能数倍于此；分开记录或标记为未知。
• 误：一张图约等于 N 个文本 Token。 正：取决于模型与预处理；只能实测编码结果。
• 误：工具调用慢就是模型慢。 正：编排等待是外部依赖，单独计时。

本节验收

1. 你能把模型服务时间与外部工具时间分开，并各给一个测量点。
2. 你能为媒体输入列出记录字段与实际编码 Token 数。
3. 你能同时报告格式/任务质量，而不只报速度。

依据与核验入口：R06 R18 S17

---

2.7 实验：把请求映射为工作量

本节要回答的问题：怎样从配置和 trace 校验工作量估计？

2.7.1 张量尺寸提取

从模型配置文件提取决定工作量的字段：\(L\)、\(d_{\text{model}}\)、\(h\)、\(h_{kv}\)、\(d_{\text{head}}\)、\(V\)、最大位置、精度方案；若为 MoE 则加专家数、每 Token 激活专家数、专家容量因子；若为混合结构则加递归状态维度与层布局。提取结果随实验存档，并绑定模型 revision（第1章 1.3.1）。

2.7.2 输入输出分离扫描

两个方向分开扫描，一次只动一个变量：

• 固定输出、扫输入：固定 max_tokens 与实际输出长度，输入按 512 / 2048 / 8192 / 32768 变化，观察首 Token 时间与状态占用；
• 固定输入、扫输出：固定输入，让输出自然停止，记录实际输出长度分布（不是设置上限），观察单步时间与端到端时间。

再叠加并发档位，观察单步时间随批大小的变化，验证 2.3.2 的"权重访存被摊薄"预期。

2.7.3 模型估计与实际执行对照

把估计值（逻辑字节、理论 FLOPs、带宽下界）与实测放同一张表，分栏比较：

无法解释的残差本身就是诊断材料——它指向第9章的观测与第10章的假设检验。实验的目标不是证明"某阶段一定更慢"，而是检验工作量模型能解释哪些变化。

无 GPU 时的支线：只做模型配置解析（E0），产出逻辑字节账本与理论工作量，不填写实际分配与实测栏。

本节要点

• 配置字段绑定 revision；MoE 与混合结构要额外提取对应字段。
• 输入输出分开扫描，输出长度取实际分布而非设置上限。
• 估计与实际分栏对照；残差是后续诊断的输入。
• 无资源时只做配置解析，不填实测栏。

常见误区

• 误：max_tokens=1024，所以输出是 1024 Token。 正：那是上限；必须记录实际停止原因与长度分布。
• 误：理论 FLOPs 与实测对不上，说明公式错了。 正：残差通常来自内核效率、缓存命中与调度，是诊断线索。

本节验收

1. 所有曲线的自变量来自真实 Token 计数，而非设置上限。
2. 你至少交付一份经典结构与一份当代结构的分项状态账本。
3. 未测量的实际分配栏保持空白，不填推算值冒充实测。

依据与核验入口：R04 S11 S02

---

2.8 深化：从真实模型配置到状态字节，再到注意力执行

2.8.1 模型不能冒充任意同规模模型

参数规模相近的模型可以有不同层数、KV头数和状态结构。官方 Qwen2.5-7B-Instruct 配置给出28层、隐藏维度3584、28个查询头和4个KV头 N11。在标准GQA、头维128、BF16、全部28层均保存K/V的假设下，本书由配置推得

\[b_{token}=2\times28\times4\times128\times2=57344\text{ B}=56\text{ KiB}.\]

一条4096 Token序列为224 MiB，而不是贯穿模型的512 MiB。前者来自真实结构字段加上明确的存储假设，后者来自32层、8个KV头的独立设定。它们都可以用于，但不应在不同章节不加说明地替换。这个例子选择较早的模型，是为了提供可核查的结构基线，不是推荐它代表最新性能。

对MLA，直接读取 num_key_value_heads 后套常规双份K/V公式可能高估。DeepSeek-V3 配置中的潜在维度512、独立RoPE维度64、61层提供了另一种计算入口 N12。若执行后端每层仅缓存一份512维潜在向量和一份64维位置键，二者都用BF16，主体状态为

\[61(512+64)\times2=70272\text{ B}=68.625\text{ KiB/token}.\]

这是指定压缩缓存布局下的推导，未计MTP、暂存、索引、对齐和复制；若后端展开成逐头K/V，实际容量和流量就不是这个数。由此得到的工程顺序应当是：配置识别结构，源码或运行元数据识别布局，分配记录确认实际字节。

2.8.2 为什么MLA的存储公式和执行公式可以不同

设第 \(j\) 个注意力头的键由潜在状态 \(c_t\) 投影而来，\(k_{t,j}=W^K_jc_t\)。对暂不含位置编码的内积分数，

\[q_j^T k_{t,j}=q_j^TW^K_jc_t=(W_j^{K\,T}q_j)^Tc_t.\]

这说明可以把键投影吸收到查询侧，然后直接与潜在状态做内积，而不必把全部历史键显式展开。若值也为 \(v_{t,j}=W^V_jc_t\)，则加权和满足 \(\sum_t a_tW^V_jc_t=W^V_j\sum_t a_tc_t\)，同样允许改变计算次序。

这些等式解释了压缩缓存为什么有实现空间，却不能证明任意位置编码与精度路径都能如此交换。RoPE的作用位置、缩放、混合精度以及分组布局可能要求保留额外状态或选择不同内核。性能判断还要比较“避免的历史展开”与“新增的查询投影、潜在空间计算和布局转换”，不能只把潜在维度除以头数当成加速比。

2.8.3 FlashAttention减少什么，并不减少什么

FlashAttention论文将注意力优化放在分层存储和IO感知计算上 N13。用数学推导可以理解它为什么不必把整个 \(S\times S\) 分数矩阵长期放到HBM：对一行分数，把当前处理区间的最大值记为 \(m\)，指数和记为 \(\ell\)，未归一化的加权值和记为 \(o\)。新块分数为 \(s\)、对应值为 \(V\)，则可以更新

\[m'=\max(m,\max s),\] \[\ell'=e^{m-m'}\ell+\sum e^{s-m'},\] \[o'=e^{m-m'}o+\sum e^{s-m'}V.\]

最后输出 \(o'/\ell'\)。旧块只需保留三个归约状态，不必保存所有历史分数。这是分块后维持同一softmax数学结果的关键；它并不把全注意力的有效query-key对数从平方级改成线性级。有限精度下计算次序改变，仍需按相应数值契约验收。

性能收益因此要分成三个问题：分数矩阵的中间读写减少多少；分块、流水和硬件指令是否适合该形状；引擎本次是否调用该实现。只在第二层展示一个漂亮的微基准，不能省掉第三层的路径取证，也不能证明整个业务请求按相同比例变快。

2.8.4 2026结构变化应写成状态分类，而不是产品名堆砌

本次核对的DeepSeek-V4.1-Flash模型卡描述了CED和跨层共享的CSA2；Qwen3.8-Flash-Next模型卡将Gated DeltaNet与稀疏注意力组合，并标明实验预览属性 N20。这些结构说明，经典“每层两份KV、每一步同等工作量”的假设不能无限延用。

更稳健的表达是为每类状态登记三个函数：驻留字节 \(M(S)\)、每步读取 \(Q(S)\)、更新计算 \(F(S)\)。递归状态可能使 \(M\) 对长度有界，但中间检查点仍需空间；稀疏访问可能降低 \(Q\)，却未必等比例降低必须保留的 \(M\)；共享层可以减少物理份数，却不保证每层都不再访问同一数据。新模型出现时更新这三个函数，比再加一行“某模型支持”更能帮助读者做工程决策。

---

章末检查问题

1. 相同激活参数的 Dense 与 MoE 为什么不能直接等价比较？

因为三条账不同：Dense 的计算、存储、传输都由同一组参数决定；MoE 的计算按激活参数、存储按总参数、传输按路由量。2.5.1 的算例里，激活 8B 而驻留 160 GB（80B 总参数的 BF16），线性计算项按激活参数、未卸载驻留按总参数，相差 10 倍。此外 MoE 还有每步同步的路由通信与专家偏斜，这些在稠密模型里不存在。因此只能用"参与计算 / 占用存储 / 发生传输"三张清单分别比较，不能用一个参数量换算。

2. 推测解码中"每轮延迟"和"每 Token 时间"如何区分？

"每轮延迟"是一次验证迭代的墙钟时间（含提出候选、一次前向、接受判定），"每 Token 时间"是最终被接受的输出 Token 分摊到的时间。若每轮最终推进 \(m\) 个 Token（含校正或额外 Token）、每轮耗时为普通一步的 \(c\) 倍，则每 Token 相对成本为 \(c/m\)。\(m\) 由接受率决定（\(k=4,\alpha=0.7\) 时 \(m\approx2.77\)），而 \(c\) 是完整验证轮相对普通一步的实测成本，不预设其固定值。只看每轮延迟会漏掉接受率，只看接受率会漏掉验证成本，两者都要报；被拒绝的 Token 不进产出分子但要进成本分子。

3. 模型卡用 FP4 而后端记录不同存储格式时，状态预算应该引用哪一层？

引用实际执行层——即后端真正分配与访问的格式，因为它决定显存占用与带宽消耗；同时登记模型卡的设计意图与两者差异，作为版本变化时的复核抓手（2.4.5）。资料记载中存在这种不一致：模型卡描述模型侧的低精度主缓存，而引擎发布说明记录特定硬件路径上的另一种分块低精度存储 SOURCE_REGISTERED S02。这些是页面快照（runtime_verified=false），可以用来说明"模型设计与后端落实必须分开看"，但不能用来推算未经运行的显存或吞吐。

---

本章验收清单

---

配套资料

新增图表与数据 · 来源登记 · E0测试清单 · 修订记录

第3章 计算、显存、带宽与通信模型

核心论点：性能模型用于给出有条件的边界与可检验预测，不是把理论峰值包装成业务吞吐。

本章使用的设备参数

为避免"峰值算术"脱离单位，全章统一使用一组显式声明的参数（非任何具体产品）：

ridge point 是两条理想吞吐上界的交点。强度低于 500 FLOP/byte 时，带宽屋顶更低；高于它时，计算屋顶更低。这只是在给定计量层级和流量假设下判断哪个上界更紧，不能排除启动、依赖、通信或低占用率把实际性能压在两条屋顶之下。真实设备须按有效精度与实际资源重新建模。

---

3.1 资源清单：单卡、服务器、互联域与资源池

本节要回答的问题：哪些资源数字真正属于这次部署？

规格书给的是边界条件，实际分配到这个实例的手才是当前的账。要记录的不只是加速器：

一个易被忽略的事实：容器里看到的"可用资源"可能与实际独占性不一致。显存可能被其它实例共享、CPU 配额可能被限流而不产生错误、网络路径可能经过额外的代理层。因此资源账至少分三列：额定规格 / 运行观测 / 人工假设，任何未实测的项都要标为假设。

产品形态与成熟度也要分开登记：公开发布（GA）、维护版、预览（Preview/RC）、路线图与"已可获取"是五种不同状态，预览与路线图不能作为容量承诺的依据。以整系统级平台为例，机柜级产品资料会给出卡数、机柜内互联域与跨节点网络的边界，可用来练习"整系统资源账本"，但产品页规格不构成某个时间点的完整产品排行榜。成熟的上一代环境（如 H100 一类）仍可继续作为可重复基线 SOURCE_REGISTERED S22。

依据与核验入口：R17 R30 S22

---

3.2 计算量、数值精度与有效算力

本节要回答的问题：FLOPs、FLOP/s 与实际执行工作量如何对应？

3.2.1 计数约定

先统一计数，否则所有比较都无效：一次乘加（MAC）记为 2 FLOPs。于是形状为 \([M,K]\times[K,N]\) 的 GEMM：

\[ W = 2MKN \quad [\text{FLOP}] \]

稠密与稀疏的峰值不能混用。某些硬件提供结构化稀疏（如每四个元素保留两个非零的 2:4）的加速路径，其标称峰值可达稠密的 2 倍，但这只在权重满足相应稀疏布局、且内核真正走该路径时成立。用稀疏峰值解释稠密执行，是最常见的一类"理论对不上实测"。

3.2.2 四项精度要分开写

"这个模型是 FP8"或"4 bit"这类说法承载不了工程判断，必须分四项：

不能从权重文件的扩展名推断全部执行精度：量化制品可能带缩放因子、可能排除某些层、也可能在加载时被反量化成另一精度参与计算。判断依据是实际内核与配置回显（第1章 1.5.3）。

3.2.3 分块缩放、填充与额外字节

低精度格式大多带缩放元数据，因此"标称位宽"不等于"实际位宽"。以分块缩放格式为例（需按所选版本核验块大小）：若每 16 个元素共享一个 8 bit 缩放因子，则

\[ b_{\text{eff}} = 4 + \frac{8}{16} = \mathbf{4.5\ \text{bit/元素}} \]

元数据占 \(0.5/4.5 \approx \mathbf{11.1\%}\)。相应地，块越大元数据占比越低，但量化误差通常上升——这是精度与开销的交换，不是一个可以只看标称位宽决定的问题 SOURCE_REGISTERED。

还有两类"额外字节"要计入：填充（形状对齐带来的浪费）与临时展开（某些结构在执行时把压缩表示展开成更大的张量）。第2章 2.4.2 已说明压缩存储与执行布局可能不同，本节只需记住：容量与带宽账要按执行时的实际张量算，而不是按磁盘上的字节数算。

3.2.4 有效算力：一步 GEMM 的完整演算

取第2章 Decode 中的一个隐藏层 GEMM：权重 \([K=4096]\times[N=4096]\)，本步 \(M=8\) 个 Token，BF16（\(b=2\)）：

\[ W = 2\times8\times4096\times4096 = \mathbf{268{,}435{,}456}\ \text{FLOP} \approx 0.268\ \text{GFLOP} \]

理想访存（权重 + 输入激活 + 输出，各按 \(b=2\) 字节）：

\[ Q \approx 4096\times4096\times2 \;+\; 8\times4096\times2 \;+\; 8\times4096\times2 = 33{,}554{,}432 + 65{,}536 + 65{,}536 = \mathbf{33{,}685{,}504\ \text{B}} \]

运算强度：

\[ I = \frac{W}{Q} = \frac{268{,}435{,}456}{33{,}685{,}504} \approx \mathbf{7.97\ \text{FLOP/byte}} \]

（这与"权重主导时 \(I\approx 2M/b = M\)"的直觉一致：\(M=8\) 时约 8。）

对照本章设备的 ridge point \(500\) FLOP/byte：\(7.97 \ll 500\)，这一步明显在访存受限区。它的时间下界取两者之大：

\[ T \ge \max\left(\frac{W}{F_{\text{peak}}},\ \frac{Q}{B_{\text{peak}}}\right) = \max\left(\frac{2.684\times10^{8}}{1.0\times10^{15}},\ \frac{3.369\times10^{7}}{2.0\times10^{12}}\right) = \max(0.268\ \mu\text{s},\ \mathbf{16.84\ \mu\text{s}}) \]

于是这一步在上述理想流量假设下的吞吐上界为

\[ F_{\text{roof}} = \frac{W}{T_{\min}} = \frac{2.684\times10^{8}}{16.84\times10^{-6}} \approx \mathbf{15.9\ \text{TFLOP/s}} \]

该带宽屋顶对应约 15.9 TFLOP/s，即所设计算峰值的 1.6%，并非已经测得的有效算力。对方阵 \(K=N=d\)、BF16、计入权重与输入输出激活的模型，有

\[I(M)=\frac{2Md^2}{2d^2+4Md}=\frac{Md}{d+2M}.\]

当 \(d=4096\)、目标 \(I=500\) 时，\(M=500\times4096/(4096-1000)\approx661.50\)，所以最小整数是 662。忽略激活时得到的 \(M\approx500\) 只是权重主导近似；接近交点时必须恢复被忽略项。真实计算受限的切换点还受实际带宽、算力、布局与效率约束。

三个必须一并说明的限制：这是理想下界（忽略 L2/片上复用、内核效率、排队与同步）；实际 DRAM 流量必须测量，缓存命中与重复加载可能使其低于或高于本近似（第2章 2.3.1）；有效算力必须用与估算相同的计数约定才能与估算值比较。

依据与核验入口：R21 S10 S22

---

3.3 Roofline：计算与数据移动的约束

本节要回答的问题：什么时候值得优化算术，什么时候应该减少搬运？

3.3.1 运算强度

运算强度定义为针对某个存储层级统计的比值：

\[ I = \frac{W\ [\text{FLOP}]}{Q\ [\text{byte}]} \]

关键在于 \(Q\) 统计在哪一层：是设备显存（HBM）、还是片上缓存、还是跨节点网络。同一个算子在不同层级上强度不同，从而可能在不同层级分别受限。写作时必须写明层级，否则 Roofline 图无法解释。

3.3.2 两个时间下界取大，两个吞吐上界取小

\[ T \;\ge\; \max\left(\frac{W}{F_{\text{peak}}},\ \frac{Q}{B_{\text{peak}}}\right) \]

它给出的是不可逾越的下界，不是预测值。3.2.4 已演示：访存项（16.84 µs）比计算项（0.268 µs）大两个数量级，因此优化方向是"减少搬运或提高复用"，而不是"让 GEMM 算得更快"。

同理，第2章 Prefill 的注意力项与线性项也可以用同一张图思考：大 \(M\)（长输入、大批）时强度高、趋近计算受限；Decode 的 \(M\) 小、强度低、趋近访存受限。两阶段落在 Roofline 的不同区域，这是它们优化手段不同的根本原因。

3.3.3 模型遗漏了什么

Roofline 只覆盖计算与某一层的数据移动，它不解释以下开销，报告时必须显式列出：

还有一个常被颠倒的推论：库的 IO 复杂度更低，不自动保证端到端更快。算法的数据移动模型、内核库实现、以及引擎实际 dispatch 到哪条路径是三层不同的事；必须先在 trace 中确认调用了哪个实现，再把实际形状与精度放回强度模型 SOURCE_REGISTERED S09。同理，一个高利用率百分比不能证明"贴近上界"——3.2.4 的例子里设备很忙，有效算力却只有峰值的 1.6%。

依据与核验入口：R22 S08

---

3.4 显存预算：权重以外还有什么

本节要回答的问题：为什么权重能装下不等于服务能稳定运行？

3.4.1 逐项预算

沿用第2章的 7B BF16 模型、4096 上下文、批 8，把账本补齐（需按环境替换）：

（\(14+4.29+1.5+0.5+0.8 = 21.09\)；\(\times1.1 = 23.20\) GB。）

在一张 24 GB 设备上余量只剩 0.80 GB，运行时很容易触到上限；在 40 GB 设备上则宽松得多。这张预算表只说明 24 GB 设备余量偏薄，不能推出组合一定装不下——容量是负载的函数，不是模型尺寸的函数。

3.4.2 初始化峰值与稳态不同

加载期、预热期与稳态期的峰值并不相同：加载时可能同时存在磁盘缓冲、权重暂存与转换中间量；预热时图捕获与形状桶会额外占用；稳态才收敛到可复用水平。因此预算要分阶段采样，而不是只报一个数。

某些内存被预留但并非全部活跃使用——因此必须区分三种口径：allocated（进程向运行时申请）、reserved（运行时缓存未归还设备）、设备占用（驱动视角）。用其中一个解释另一个，是容量争议的常见来源。

3.4.3 共享对象与常驻代价

跨层共享或多请求共享的状态按物理存储身份去重（第2章 2.4.4），不能按引用次数重复计入。反过来，权重常驻（快速启动一类机制）带来启动收益的同时，也带来常驻资源代价与失效恢复路径，收益与代价必须分列登记 SOURCE_REGISTERED。

依据与核验入口：R04 R31 S02

---

3.5 主机、互联与通信下界

本节要回答的问题：哪些等待不在加速器计算里？

3.5.1 主机供给与 NUMA

主机侧的三类成本常被算进"模型时间"：预处理（分词、模板展开、媒体解码）、批组装与调度、以及输出序列化。此外还有 NUMA 与跨 socket 访存、容器 CPU 配额被限流、以及页错误/换页。判断方法见第9章 9.3：时间关联 + 干预，而不是资源占用率。

3.5.2 传输与集合通信

通信的最简模型是"启动开销 + 字节/带宽"：

\[ T_{\text{comm}} \approx \alpha + \frac{M}{B_{\text{link}}} \]

其中 \(\alpha\) 为每次同步的固定开销（µs 级），\(M\) 为消息字节，\(B_{\text{link}}\) 为该链路的有效带宽。取参数 \(\alpha=6\ \mu\)s、\(M=256\) KiB、\(B_{\text{link}}=200\) GB/s：

\[ T_{\text{comm}} \approx 6 + \frac{262144}{2.0\times10^{11}}\times10^6 = 6 + 1.31 = \mathbf{7.31\ \mu s} \]

字节传输只占 1.31 µs，而固定开销占 6 µs——这说明小消息的通信由延迟主导，不是带宽主导。于是：

这就是"低字节量的频繁同步也可能拖慢单请求"的机制：频率比字节数更重要。批量增大后占比下降，也解释了为什么同一套并行配置在轻载与满载下的表现不同。

3.5.3 域内、跨域与远程状态

必须区分三类路径，它们的数量级差异很大：

机柜级产品会给出"机柜内汇总显存"一类的指标，便于理解 scale-up 域的容量边界，但汇总容量不等于无代价的统一内存：跨域访问仍然要穿过网络，带宽与延迟相差数量级，并且可能有副本与一致性开销 SOURCE_REGISTERED。通信字节应按上述三条边界分别记账，不能合并成一个"网络流量"。

依据与核验入口：R08 R30 S14

---

3.6 端到端组合与局部优化上限

本节要回答的问题：一个算子加速后，整体最多能改善多少？

3.6.1 Amdahl 式估算

若某段在基线中占时间比例 \(p\)，该段被加速 \(s\) 倍，且其余阶段耗时不变、各阶段互斥，则

\[ T_{\text{new}} = T_{\text{base}}\left[(1-p) + \frac{p}{s}\right] \qquad S_{\text{overall}} = \frac{1}{(1-p) + p/s} \]

算例：

“速度提高 5.26%”与“延迟降低 5%”不是同一个百分比。第三行只演示暴露占比已经由依赖图确定为 5% 的情况，不能把任何“重叠一半”的活动都机械折半。若一个占关键路径 8% 的阶段提速三倍，总延迟下降 \(0.08(1-1/3)=5.33\%\)，整体加速约 1.0563×。

3.6.2 两个假设必须写在结论里

1. 各阶段互斥：若存在重叠，被优化的那部分可能根本不在关键路径上（第三行演示了占比减半的后果）。引用第1章的结论时尤其要注意：连续批处理让不同请求的工作在同一调度迭代中被组织，不等于它们的执行时间可以相互覆盖。
2. 其余阶段不变：这在真实服务里往往不成立。局部变快会改变批组成、显存压力与排队行为；第9章 9.5.4 已说明，开环负载下服务时间下降通常带来端到端改善，而在闭环或自适应到达下收益可能被吸收。

因此这类估算的正确用法是给出上限与采用门槛，而不是给出承诺值。最终判断仍然回到端到端对照（第8章）。

依据与核验入口：R17

---

3.7 实验：从估算到校准

本节要回答的问题：偏差是参数错误、模型遗漏，还是测量问题？

3.7.1 先登记预测，再看结果

测试前写下三类预测：工作量（FLOPs、访存字节）、容量（逐项预算）、时间区间（下界与期望区间）。预测必须带上参数来源标签：规格 / 微基准 / 拟合 / 假设。先登记后跑是为了避免"看到结果再倒推参数"的拟合幻觉。

3.7.2 残差按来源分类

示例：3.2.4 那一步 GEMM 的理想下界为 16.84 µs，观测为 21.3 µs，残差 +4.46 µs（+26.5%）。残差只能归为三类并逐条取证：

残差不能通过"调参数"消化掉：只有能独立验证的参数才允许调整，否则就是把拟合当成校准。

3.7.3 只在覆盖区间内校准

校准点与验证点必须分开：用一部分负载点拟合，用留出的负载点检验预测能力。对高负载、不同拓扑、不同并行度外推时必须重新核验——几个贴合点不能证明模型普适。

无设备时的可行工作：校验单位与配置、用公开资料登记整系统资源账本、完成显存与工作量预算表；资料规格不作为校准点，也不把峰值规格当作容量结论。

依据与核验入口：R22 S21

---

3.8 深化：分层Roofline、逐算子下界与模型失配

3.8.1 先按依赖分段，再合成屋顶

对一个计算阶段，\(\max(F/P,Q/B)\) 表示理想情况下计算和搬运可重叠时的下界。对两个严格串行且性质不同的阶段，应先分别求界，再求和：

\[T_{serial}\ge\sum_j\max(F_j/P_j,Q_j/B_j).\]

把全部FLOPs和全部字节先相加，再求一次最大值，得到的仍可能是一个更松的乐观界，却丢掉了瓶颈交替。反例：阶段A的计算下界10 ms、访存下界1 ms，阶段B为1 ms和10 ms。逐段下界合计20 ms，聚合后却只有11 ms。差出的9 ms不是实现低效，而是聚合模型错误地允许两个串行阶段互相覆盖。

同理，HBM、L2、共享内存和跨设备链路不是同一份带宽预算。一个算子可以在HBM层复用良好，却受片上访存或指令发射限制；系统也可能在计算屋顶之下先遇到主机供给限制。只画一张HBM Roofline并不能完成诊断，但它能帮助排除一些不可能的解释。

图中采用本章的设备参数，不对应具体产品。曲线由算术强度公式生成，不是采样点。配套CSV同时保存 \(M\)、FLOPs、字节和屋顶值，便于读者更换参数后重画。

3.8.2 峰值、可持续带宽与工作量效率必须分开

若使用厂商峰值带宽 \(B_{peak}\)，\(Q/B_{peak}\) 是更乐观的界；若使用同种访问模式微基准的持续带宽 \(B_{sustained}\)，则是校准模型的输入。两者不能混名。对不同访问粒度、读写比例或并发规模，持续带宽也可能不同；拿大块连续拷贝校准不规则分页读取，仍可能留下系统性误差。

计算端同样如此。\(2P\) 每Token是一种工作量近似，不是实际发射指令数。稀疏跳过、填充、重算、路由、归一化与输出投影会使真实工作量不同。为了发现差异，应同时记录“有用工作量”和“执行工作量”：前者衡量任务所需，后者解释资源实际消耗。低精度或稀疏硬件峰值只能与其适用的数据路径匹配，不能将稠密工作量除以稀疏峰值来制造更短时间。

3.8.3 用残差定位模型遗漏，不用一个效率系数掩盖一切

可以从 \(T=\alpha+F/P_{eff}+Q/B_{eff}\) 这样的校准式开始，但它并不自动描述计算搬运重叠。拟合前需声明这是串行近似、分阶段模型还是经验预测模型，避免把拟合参数再解释成物理峰值。

设预测误差 \(e_i=T_i^{obs}-T_i^{pred}\)。若残差随小批量增大，可能遗漏了固定启动开销；随上下文增长而增大，可能遗漏了状态读取或稀疏索引；只在特定形状突然跳变，优先检查内核选择、padding或图回退。若用一个“统一效率0.6”把所有误差压平，就失去了这种判别力。

校准还应保留训练形状与留出形状，分别报告误差分布。对留出的大上下文或不同并行布局，模型参数未必可迁移。真正有用的性能模型不是处处给出一个精确数字，而是能说明哪些区间已校准、哪些属于外推，以及一个新观测能推翻哪个假设。

---

章末检查问题

1. 一个占总时间 10% 的算子提速两倍，串行假设下整体如何变化？

按 \(S=1/[(1-p)+p/s]\)：\(p=0.10\)、\(s=2\) 时 \(S = 1/0.95 = \mathbf{1.0526}\)，即端到端改善约 5.26%，而不是 10%。若这 10% 中有一半并不在关键路径上（与其它段重叠），有效占比降到 5%，改善只剩 2.56%。所以拿到"内核快 2 倍"这类结论时，第一件事是问它占端到端的多少、且是否互斥。

2. 权重除以 HBM 带宽何时只能当粗下界？

\(W/B\) 只对"权重必须整体读一遍、且完全无复用"的情形成立。它在以下情况会失真：批量较大时权重被多个 Token 摊薄（按 3.2.4，达到 ridge point 需要约 500 个 Token）；存在片上缓存命中或预取；实际 DRAM 流量高于理想流量（额外拷贝、临时缓冲、未命中）；以及并发排队与同步占据的时间未被计入。它是下界，不是预测值，用于判断"这个配置至少不可能快于多少"。

3. 机柜汇总显存为何不能直接当作无代价统一内存？

因为"汇总容量"描述的是可寻址的容量上界，而不是访问代价。跨出 scale-up 域的访问要穿过网络，带宽与延迟与域内相差数量级，还可能引入副本、一致性与传输开销 SOURCE_REGISTERED。所以正确做法是：把域内带宽/延迟与跨域带宽/延迟分别登记，把远程状态访问单独计时，容量账与传输账分开写。

---

本章验收清单

---

配套资料

新增图表与数据 · 来源登记 · E0测试清单 · 修订记录