推理与训练负载

先看一个请求：恢复 S 个上下文 token，处理 P 个新输入，返回 G 个 token。调用链是 1 次 prefill + (G−1) 次 decode。首个输出来自 prefill；第 j 次 decode（j 从 0 计）开始时已有上下文 S+P+j。

两个阶段用同一套权重，需求却不同：prefill 一次读权重能和 B·P 行输入做乘加，通常受算力限制；低并发 decode 只为 B 行读整组权重，通常受显存带宽限制。只把 token 数相加，会丢掉“它属于哪个阶段、何时能执行”。

3.1.2 先写清什么算完成，再决定统计什么

时间线上标三个事件：到达 t_a、首个 token t₁、最后一个 token t_G。

T_TTFT = t₁ − t_a　　T_request = t_G − t_a　　T_token = (t_G − t₁) / (G − 1)

等待也占容量：状态占用面积

A_M = ∫ M(t) dt　（单位 byte·s）　　稳定时等待中的平均占用 ≈ λ · M₀ · τ

成本也一样要按“完成”来算：成功任务成本 = 所有尝试（含失败生成、工具测试、环境运行）的成本 ÷ 成功任务数。一批零成功时，只能记录消耗与失败原因，不能报出成功成本。

3.1.3 请求分布：空闲的算力存不起来

负载描述要保留到达时间与输入、输出长度的联合分布。不同客户有的主要交长文档、有的主要要长回答，各自速率一变，整体负载的形状就变（ServeGen 在生产服务中观察到了这种现象）。

排队既可能因为算得不够快，也可能因为状态没释放：KV 池填满后，就算部分计算单元空着，新请求也得等。

多轮对话的下一次请求通常带着之前的上下文。第 i 轮输入 I_i、可复用前缀 K_i，则本轮新处理 P_i = I_i − K_i，恢复 S_i = K_i。投影和 FFN 只算新 token，注意力仍要让新查询访问完整前缀。

缓存复用减少了重算，却没有把旧上下文从后续计算里删掉，而且要求系统继续保留旧状态。

3.2.2 多花计算换正确率，值不值

推理时多花计算有三种方式：延长一条回答的思考、同时生成多份再选、按难度分配次数和长度。判断标准只有一个：每个成功任务的成本。

C_success = c / p　　新方法更省 ⇔ p₂/p₁ > c₂/c₁

3.2.3 智能体：模型、工具、再模型

代码 Agent 先生成修改，工具写文件、跑测试，模型再读测试结果决定下一步。工具日志成为下一轮输入：少一点无关日志，就少一点下一轮的 prefill 和上下文状态；少一次无效修改，就少一个循环。检索增强问答同理：质量相同时，检索返回越少，后续 prefill、KV 和读取越省。

关闭思考时 12 轮里读文件 1 次、改写 5 次、跑测试 6 次，缓存命中率约 83.4%，仍没修好。开启后原定两项检查全过，但额外的无别名检查只过了 710 个，另 303 个仍与输入共享子列表：完成标准必须具体到可执行的验证。

3.2.4 分支、工具等待与状态驻留

把模型调用和工具执行的先后画成依赖图：串行路径时间相加，独立分支可以同时开始，汇合点等较慢的那支。累计耗时最长的路径是关键路径，决定任务最早何时完成。

图片进入语言模型前要经过预处理、视觉编码和投影。记 E 为视觉编码、P 为语言 prefill、D 为 decode，视觉问答就是 E → P → D。图片大小决定 E 的工作量，编码后的视觉 token 数决定语言部分的工作量，两者分开算。

n_v = H_img·W_img / (p_patch² · r²)

特征拼接增加的是宽度，图片变大增加的是 token 数。边长加倍，视觉 token、EC、视觉 KV 都变四倍。问题放在图片之前，换问题就会改变视觉 token 的 KV；放在之后，因果注意力让视觉 KV 不变。

三种表示对应三个交接位置：第 8 章安排同卡执行，第 9 章比较阶段交接，第 12 章放到端、边、云链路上。

3.3.2 输出是声音或图像时，循环换了形状

3.3.3 实时播放：每一块都要按时到

B_audio(t) = A(t) − P(t)　（已到达的可播放时长 − 已播放时长）

播放期间 P(t) 每秒涨 1 秒，A(t) 随数据块跳跃增长。余量降到零而下一块没到，声音就断。两次语音实测里，用户停说到首块音频到达约 400 ms、370 ms，后续块到达间隔中位数约 94 ms。

任务不同，时间要求也不同：有的要尽快开始（TTFT），有的要持续流畅（播放），有的要尽早全部完成。RAW 图片精修就只关心成片何时完成，而且必须保留原始图像信息，视觉理解用的 EC 替代不了原图。

推理用权重求输出；训练还要用输出与目标的差异调整权重。以 y = x·w 为例：后一层传回 ∂ℒ/∂y，要算 ∂ℒ/∂w 就需要当时的 x，要把梯度传给前一步就需要 w。所以前向的某些输入要一直留到反向用完。

3.4.2 预训练、中期训练与 SFT：都归结为三个数

输入多少 token，哪些 token 参与损失，多少个 micro-batch 后更新一次。Qwen3：通用阶段 4096 长度训练超过 30 万亿 token，再加 STEM、代码、reasoning 与合成数据约 5 万亿，长上下文阶段扩到 32768。

3.4.3 从 6ND 粗算到逐项核算

参数投影随输入行数涨，注意力随查询—键配对数涨，优化器更新随参数量和更新次数涨。序列越短，更新开销占比越高；用重计算省容量，重做的前向要加回 F_train。新增的前向操作（上下文压缩、mHC、MoE 选中专家）都会带来对应的反向。

RL 把推理和训练接成一个环：当前策略先生成回答（rollout），再由反馈决定如何更新，更新后的策略继续产生下一批数据。代码、数学这类易检查任务的反馈来自规则或测试（DeepSeek-R1 的可验证奖励）；需要实际操作的任务要跑工具和环境；奖励若由另一个模型给，还要额外推理。DeepSeek V4-Flash 先用 SFT + RL 训领域专家，再用多教师同策略蒸馏（OPD）合成一个模型：学生自己生成轨迹，教师在这些位置给出概率分布。

n_generate ≈ n_keep / a　　F_cycle(n) = n(f_g + f_r) + F_u

总预算 C ≈ 6ND：多给参数 N，就得少给数据 D。Scaling Law 用实验拟合参数、数据与验证损失的关系：

L(N, D) = E + A/N^α + B/D^β　⇒　N_opt = (αA/βB)^1/(α+β) (C/6)^β/(α+β)，D_opt ∝ C^α/(α+β)

计算最优只在“固定训练预算、不计推理成本”时成立。上线后要服务大量请求时，最优会偏向更小、训练更充分的模型：Beyond Chinchilla-Optimal 用 47 个模型（150M–6B）把推理需求纳入分析，150M 训练量最高达每参数 10,000 token。

3.6.2 从 Llama 到 Qwen：数据越给越多

按 Chinchilla 约每参数 20 token，8B 模型约 160B token 就是“计算最优”；实际投入 1T–36T，超出一至两个数量级。这不是拟合算错，而是目标不同：开发者把上线后的服务成本也算了进去。

质量门槛要按自己的任务定：Llama 3 8B 与 Llama 2 70B 在 MMLU 上 66.6／69.7，在 TriviaQA-Wiki 上 78.5／87.5，两项差距不同。MoE 要分别列总参数和激活参数：DeepSeek-V3 671B／约 37B、预训练 14.8T；V4-Flash 284B／约 13B、32T；V4-Pro 1.6T／约 49B、33T。V4-Flash 主干专家 18·n_L·h·f·(6+1) ≈ 45.4495 GFLOPs/token，32T 累计约 1.45438×10²⁴；V4-Pro 约 169.2465 GFLOPs/token、5.58513×10²⁴。损失权重不是执行比例：MTP 权重 0.3 不表示只做 30% 的辅助计算。

后续章节要用的负载记录

两分钟请求中，各时段的输入输出比例决定积压何时出现；代码 Agent 中，工具依赖决定等待多久、状态保存多久；RL 中，筛选前后的样本数决定生成与更新各处理多少数据。第 4 章把这些矩阵尺寸、状态大小和访问次数放到芯片的算力、容量与带宽上。