从芯片微架构、内存与互联，到训练与推理的每一层优化手法——一份把「算力为什么会被浪费、怎么被抢回来」彻底讲清楚的教材式长文。基于国内外一线论文、工程博客与官方文档编写，全部来源可溯。
先建立一张地图。后面九章讲的每一种优化手法，都是在这条旅程的某个路段上抢时间。
你在对话框里敲下"帮我写个排序函数"，按下回车。接下来发生的事，可以拆成一条清晰的物理链路——理解这条链路，就理解了算力优化的全部战场。
第一步：文字变数字。分词器（tokenizer）把这句话切成若干 token（约 10 个），每个 token 变成一个整数 ID，再通过嵌入表（embedding table）查表变成一个向量——比如 4,096 维的浮点数组。此刻数据量还很小，几十 KB。
第二步：数据进入显存。模型权重早已驻留在 GPU 的 HBM（高带宽显存）里。以 70B 参数的模型、BF16 精度计算，权重占 70×10⁹ × 2 字节 = 140 GB——一张 80GB 的 H100 装不下，所以必须切开放到至少两张卡上（这就是模型并行的物理起因：不是为了快，首先是为了装得下）。
第三步：逐层计算。输入向量穿过几十到上百层 Transformer 层，每层做同样的两件事：注意力（Attention）——让每个 token 去"看"上下文里的其他 token；前馈网络（FFN/MLP）——对每个 token 做一次独立的非线性变换。这两件事的绝大部分计算量都是矩阵乘法（GEMM），这就是为什么 GPU 里专门造了 Tensor Core 这种"只会算矩阵乘"的电路。每一层的计算都需要：把这一层的权重从 HBM 搬到芯片内部的缓存 → 搬到计算单元 → 算 → 结果写回。注意这个"搬"字——它是全文最重要的动词。
第四步：跨卡通信。如果模型被切在 8 张卡上，那么每一层算完（甚至算的中间）都需要卡与卡交换数据：把各自算的一部分结果汇总（all-reduce），或者把 token 分派给不同的专家（all-to-all）。这些通信走 NVLink（卡间）或 InfiniBand/RoCE（机间）。通信时计算单元在等待——这是有效算力被吃掉的第一大口。
第五步：出第一个字，然后逐字往外蹦。穿过所有层后得到 logits（词表上的概率分布），采样出第一个 token。到这里叫 Prefill（预填充）阶段结束，用户看到第一个字，这段耗时就是 TTFT。接着进入 Decode（解码）阶段：把刚生成的字接到序列末尾，再走一遍所有层，生成下一个字——每生成一个字，都要把 140 GB 的权重完整读一遍。这就是为什么 decode 阶段是被显存带宽卡死的，而不是被算力卡死。
第六步：省下的功夫。每个 token 在注意力里算出的 Key 和 Value 会被缓存下来（KV Cache），下一个 token 就不用重算前面所有 token 的 K/V——用显存换算力。上下文越长，这块缓存越大，长对话之所以贵就贵在这里。
把上面的链路翻过来看，就是一张优化清单：① 数据搬运的时间（内存墙）→ 用算子融合、量化、KV 压缩来少搬；② 跨卡通信的等待（通信墙）→ 用并行策略设计、通信计算重叠来藏起来；③ 计算单元的空转（利用率）→ 用批处理、连续批处理、PD 分离来填满；④ 数值精度的浪费 → 用混合精度、低比特量化来降本；⑤ 故障与重算的损失 → 用容错、checkpoint、弹性训练来挽回。本文余下九章，就是这五件事的展开。
训练的旅程比推理多两段：算完前向要沿着同一条路反向传播算梯度（计算量约为前向的两倍），再用优化器（如 Adam）更新权重。所以训练不但要存权重，还要存梯度和优化器状态——显存压力是推理的好几倍，通信压力也是（每一步都要在成千上万张卡之间同步梯度）。这就是训练比推理难得多的根本原因。
算力优化的一切上限都由硬件设定。这一章把"卡"拆开来看：算的部件、存的部件、连的部件。
CPU 的设计目标是把一条复杂的指令流跑到最快，所以它花了大量晶体管在分支预测、乱序执行、大容量缓存上——像几个博士，各自能解难题。GPU 的设计目标相反：把成千上万条相同的简单运算同时跑完，所以它把晶体管几乎全部铺成计算单元——像几万个小学生，每人只会算加减乘除，但可以同时开工。
GPU 的组织方式叫 SIMT（Single Instruction, Multiple Threads，单指令多线程）：硬件把线程按 32 个一组打包成 warp，一个 warp 里的 32 个线程在同一时刻执行同一条指令、只是作用在不同数据上。这个设计的代价是"分支分歧"（warp divergence）——如果 warp 内有一半线程走 if、一半走 else，硬件只能先跑完一支再跑另一支，效率对半砍。这就是为什么 GPU 讨厌带条件判断的代码，喜欢整齐的大块数据运算。
物理上，GPU 由几十到上百个 SM（Streaming Multiprocessor，流式多处理器）组成，每个 SM 内部有一批通用计算核心（CUDA Core）、若干 Tensor Core、寄存器堆和共享内存。Tensor Core 是 AI 时代的关键发明：它不是"更多的算术单元"，而是一个专门的矩阵乘加电路——一条指令就完成一个小矩阵（如 16×16）与另一个小矩阵的乘加，把原本需要几百条指令的工作压成一条。代价是它只会做这一件事。这带来一个极其重要的性能事实：
芯片上的存储不是一块，而是一座金字塔：越靠近计算单元的越快越小，越远的越慢越大。
上图最后一行是全文的枢纽：现代加速器的算力增长远快于内存带宽增长（业界称"内存墙"）。H100 的 BF16 算力约 990 TFLOPS，HBM 带宽约 3.35 TB/s，两者相除得到一个"硬件期望的计算密度"——约 300 次浮点运算/字节。任何低于这个密度的计算，都注定跑不满算力。这个数字是下一章 Roofline 分析的核心。
再看一个直觉：大矩阵乘法（GEMM）的计算密度可以做到很高（矩阵越大，每搬一个元素能参与的乘加次数越多），所以它能吃满 Tensor Core；而逐元素运算（如给张量每个数加个偏置）搬一个字节只算一次，密度约 1，比硬件期望低了两个数量级——这类算子无论在什么卡上都只能跑到峰值算力的百分之几，它们的耗时几乎完全由带宽决定。这就是为什么优化的第一原则往往不是"算得更快"，而是"少搬数据"。
单卡装不下大模型，于是有了多卡；多卡需要交换数据，于是互联带宽成了新的瓶颈。层级从内到外：
| 层级 | 技术 | 带宽量级 | 典型用途 |
|---|---|---|---|
| 卡内 | HBM 显存总线 | TB/s 级 | 权重与激活读写 |
| 节点内（同一台服务器 8 卡） | NVLink + NVSwitch（NV 系）／HCCS 等（国产系） | 数百 GB/s ～ 1 TB/s 级 | 张量并行——通信最频繁，必须放在这一层 |
| 节点间（机架内/跨机架） | InfiniBand 或 RoCE（以太网承载 RDMA） | 每卡 200–400 Gb/s 量级 | 数据并行的梯度同步、流水线并行的层间传递 |
| 集群 | 胖树（Fat-Tree）／轨道优化（rail-optimized）拓扑 | 收敛比决定实际可用带宽 | 万卡规模的整体组网 |
两个必须理解的概念：NVSwitch 与"全互联"——早期 GPU 之间是点对点连线，任意两卡之间带宽有限且不均等；加入交换芯片后，节点内任意两张卡都能以全带宽通信，这对张量并行至关重要（它的通信模式是全体参与的 all-reduce）。一个集群"能不能做大张量并行"，直接由节点内有没有交换式全互联决定——这也是评价国产集群方案的关键指标之一，也是"超节点"路线的技术动机：用更大的高带宽域（把几十到上千张卡纳入一个近似全互联的域）来弥补单卡能力的不足。
InfiniBand 与 RoCE 的取舍——IB 是为高性能计算设计的专用网络，天生具备无损传输与低延迟，但贵且封闭；RoCE 是在以太网上跑 RDMA，成本低、生态开放，但需要精细的拥塞控制与流控调优（PFC/ECN），否则丢包重传会让集合通信性能雪崩。国产大规模集群多走 RoCE 路线，于是"网络调优"成了国产集群交付里一项独立的高价值手艺。
GPU 是"通用并行处理器"，而 AI 芯片还有一条路线叫 DSA（Domain-Specific Architecture，领域专用架构）：既然负载主要是矩阵乘，那就造一块专门算矩阵乘的电路，把通用性砍掉换能效。谷歌 TPU 的脉动阵列（systolic array）是经典代表——数据像脉搏一样在计算单元阵列中流动，每个单元只做"乘加并把结果传给邻居"，几乎没有取指、调度、访存的额外开销，能效极高，但只对规整的大矩阵乘友好。
华为昇腾的达芬奇架构是同一思路的另一种实现：每个 AI Core 内部分成三个单元——Cube（矩阵计算单元，一拍完成大量乘加，对应 Tensor Core 的角色，是算力主体）、Vector（向量单元，处理归一化、激活、逐元素运算）、Scalar（标量单元，做控制流与地址计算）；配合多级片上缓冲（L0 用于 Cube 的输入输出、L1 与统一缓冲 UB 用于更大块的数据暂存）。它与 GPU 的关键差别在于片上内存需要程序员显式管理：CUDA 编程时你主要管线程逻辑、缓存由硬件自动打理；而在达芬奇上写算子（Ascend C）必须自己规划数据怎么分块（Tiling）、什么时候从 HBM 搬进 UB、怎么在 Cube 与 Vector 之间编排流水。
① CUDA 算子无法翻译，只能按硬件重写——生态迁移不是编译问题，是重写工作量问题；② Cube 强而 Vector 相对弱，模型里"不像矩阵乘"的部分容易成为瓶颈，对算子融合的依赖更重；③ 矩阵与向量单元之间的数据倒手若缺少共享的高速缓冲，像 FlashAttention 这种"矩阵—向量交替"的核心算子实现难度陡增；④ 显式内存管理意味着性能与开发者水平强相关——同一块硬件，高手和新手写出的算子可能差数倍。这四条合起来，就是"同样的卡，会用和不会用差一倍以上"的物理解释。
2025 年 9 月至 2026 年 6 月，华为陆续发布了两份技术纲领性文件——《昇腾 950 NPU 架构白皮书》与灵衢（UnifiedBus）2.0 技术规范及配套的《基于灵衢的超节点参考架构白皮书》。它们把前四节讲的所有权衡（单卡 vs 系统、SIMT vs DSA、消息语义 vs 内存语义）摆到了一个具体的技术路线上，值得单独一节精读。
口径说明：本节标注【白皮书】的数据出自《昇腾 950 NPU 架构白皮书》（2026 年 6 月，40 页）正文与表格；标注【发布会】的出自 2025 年 9 月华为全联接大会主题演讲与官方新闻稿；标注【第三方】的为非华为来源的分析或估算。三者不可混用——例如白皮书正文全程只称"高速片上内存"，从未出现 HiBL / HiZQ 这些内存品牌名，那些名称只见于发布会口径。
950PR 与 950DT 是共架构、同源同 die 的两款芯片【白皮书】，物理构成为多 die 合封：2 个 AI die + 2 个 IO die + 若干高速片上内存模块，通过片间互联构成统一内存访问（UMA）整体。完整规格含 36 个第三代达芬奇 AI 子系统（每个 = 1 个 Cube Core + 2 个 Vector Core）、4 个 AI CPU 集群、128MB 统一 L2 Cache，Cube 阵列仍是 16×16×16 FP16。
真正区分两款产品的是内存：
| 项目 | 昇腾 950PR | 昇腾 950DT | 参照：H100 SXM |
|---|---|---|---|
| 定位 | 推荐系统、大模型 Prefill、多模态推理 | 预训练、后训练、推理全流程（含 Decode） | 通用 |
| FP8 类算力（HiF8/MXFP8/FP8） | 919 TFLOPS | 1,034 TFLOPS | 1,979（稠密） |
| MXFP4 算力 | 1,784 TFLOPS | 2,007 TFLOPS | —（Hopper 无 FP4） |
| BF16 / FP16 | 486 TFLOPS | 547 TFLOPS | 989 |
| 片上内存容量 | 128 GB | 144 GB | 80 GB |
| 内存带宽 | 1.6 TB/s | 4 TB/s | 3.35 TB/s |
| 对外互联带宽 | 2 TB/s（2,016 GB/s 双向） | 同左 | 0.9 TB/s（NVLink4） |
算力数据为白皮书表 3-1 的顶配值（该表还列出了 28/32 核等裁剪档位）。发布会口径的"1 PFLOPS FP8 / 2 PFLOPS FP4"是约整说法，精确值即上表。H100 数字为官方稠密口径，供量级对照。
这张表里有三个值得停下来想的事实。第一，访存带宽已经反超。950DT 的 4 TB/s 高于 H100 的 3.35 TB/s（HBM3），逼近 HBM4 级别——回想第 1.2 节的结论"搬比算贵"、第 2 章的"Decode 阶段被带宽卡死"，带宽领先在推理场景的价值被严重低估了。第二，FP8 稠密算力仍有数倍差距（对比同期的 B300 更明显），这是制程代差的直接体现，短期无解。第三，用内存切分产品线是垂直整合才有的自由度：同一颗 die 配低成本大容量内存就做 Prefill 与推荐（发布会称硬件投资成本降低 40% 以上，访存粒度从 512 字节降到 128 字节），配高带宽内存就做训练与 Decode。向外采购 HBM 的厂商做不到这件事——而 HBM 供应此前恰恰是国产算力真正的瓶颈（不是制程，是内存买不到就直接停摆）。
第 5.2 节讲过 FP8 的困境：8 位的动态范围太窄，业界主流方案（MXFP8）靠外挂一个 8 位缩放因子把数值拉回可表示范围。HiF8 走了另一条路——把自适应机制做进格式内部【白皮书】。
它的编码用一段变长前缀码（白皮书称"点位域 Dot"）来显式指示"这个数的阶码占几位"：Dot=0 表示阶码为 0，Dot=1 表示 ±1，Dot=2 表示 ±[2,3]，Dot=3 表示 ±[4,7]，Dot=4 表示 ±[8,15]；阶码用原码编码并隐藏 1 个固定比特不存储，确保不同位宽的阶码表达范围不重复——即无冗余编码。加上非规格化数的处理，综合阶码范围达到 [-22, 15] 共 38 个阶码，而 FP8 的 E4M3 格式只有 18 个（FP16 是 40 个）。
① 不需要额外的缩放因子。白皮书原文明确对比：相比 MXFP8，HiF8 无需那 8 位 MX 缩放因子——省掉的是缩放因子的存储、传输与对齐开销，量化策略也从"逐张量/逐块搜 scale"部分转向"信任格式本身"。② 锥形精度（tapered precision）。数值靠近 1 时精度最高（有效位 4 bit），远离 1 时精度按 1 bit 逐级渐变、无跳变——这恰好匹配神经网络中数值分布集中在 1 附近的特性。代价是工具链负担：需要专门的转换算子、校准流程与混合精度搜索策略。
算力上的对应关系很干净：同频下 HiF8/MXFP8/FP8 = 2× FP16，MXFP4 = 4× FP16。MXFP4 那 4 倍算力是最大的诱惑也是最大的难题——要真正吃到，需要解决 4 bit 下权重与激活的可用性，这是算法与 Infra 的共同课题。（顺带一个易错点：HiF4 是下一代昇腾 960 的特性，不在 950 上。）
如果说昇腾 950 是这条路线的"点"，灵衢就是把点连成面的东西——也是这两份白皮书里技术含量最高的部分。官方定义："华为定义的统一的互联标准协议，更高效地支持计算原生的内存语义、IO 语义和网络通信语义"【白皮书术语表】。名字取自"九省通衢"，寓意大规模算力的联通。
它要解决的问题，正是第 1.3 节那条铁律的成因：传统架构里"网络层"与"内部架构层"之间有一道墙——数据跨节点要"打包、发送、等待、解包"，每次都要开门再关门。灵衢的做法是直接拆掉这道墙：底层用网络的逻辑连设备，上层用架构的逻辑管资源。灵衢团队自己的说法是做"算力普通话"——一套协议同时覆盖超节点内的 CPU/NPU 沟通与超节点间的集群互联，不用中途换语言。
灵衢 2.0 的关键指标【发布会 / 白皮书】：互联时延 2.1 微秒（1,024 卡系统的端到端往返时延低至 3 微秒，为另一口径）、互联距离超过 200 米、故障检测与保护达 100 纳秒级、光互联可靠性提升 100 倍、单芯片 UB 带宽 2,016 GB/s 双向、最大支持 8,192 卡的高带宽域（上一代是 384 卡）、共享内存空间最高 128 TB。官方给出的实测收益是 AI 大模型训练端到端提升 20% 以上。
开放策略：2025 年 9 月发布并开放灵衢 2.0 技术规范，公开的文件包括《灵衢基础规范 2.0》《灵衢固件规范 2.0》《灵衢使能操作系统参考设计 2.0》《基于灵衢的超节点参考架构白皮书》，并配套第三方协议验证机制（厂商按标准实现后可验证合规）。从物理层到事务层的规范全部公开，路径是"先企标、再团标、乃至国标"。这与 NVLink 的封闭形成鲜明对照，也是它试图撬动生态的关键筹码——不过截至目前，已公开的加入厂商名单仍是信息缺口。
| 项目 | Atlas 950 SuperPoD | Atlas 960 SuperPoD | 当前商用单元 |
|---|---|---|---|
| 卡规模 | 8,192 张 950DT | 15,488 张 960 | 1,024 卡 |
| FP8 / FP4 总算力 | 8 / 16 EFLOPS | 30 / 60 EFLOPS | 1 / 2 EFLOPS |
| 总内存（统一编址） | 1,152 TB | 4,460 TB | 256 TB |
| 互联总带宽 | 16.3 PB/s | 34 PB/s | TB 级/卡 |
| 机柜 / 占地 | 160 柜 / 约 1,000 m² | 220 柜 / 约 2,200 m² | 20 柜 |
| 上市 | 2026 Q4 | 2027 Q4 | 已商用（PUE < 1.15） |
官方给出的对比口径全部是系统级的：Atlas 950 超节点相对英伟达 NVL144，NPU 数量 56.8 倍、总算力 6.7 倍、内存容量 15 倍、互联带宽 62 倍【发布会】。再往上还有集群层：64 个超节点组成的 SuperCluster 达 52 万卡、524 EFLOPS（FP8）；2027 年规划百万卡级、2 ZFLOPS。
这是一条明确的"规模换效率"路线：用互联能力与系统集成，把单 die 的制程劣势在系统层抹平。代价是实打实的：8,192 卡要 160 个机柜、约 1,000 平方米场地；第三方评估认为单位算力能效约差 2.3 倍（非官方口径，且官方未公布超节点整体功耗，引用需谨慎）。换句话说，这条路线的成立前提是电力与场地成本相对可承受——在电价低廉、土地充裕的地区它非常合理，换个约束条件结论就会不同。对本文的读者，这是一个绝佳的案例：没有绝对最优的架构，只有在给定约束下最优的架构。
最后回到第 4 章要用的那条结论：高带宽域从 384 卡扩到 8,192 卡，是并行策略设计空间的质变。张量并行不再被"单机 8 卡"的墙锁死，序列并行不再受机内卡数限制，MoE 的专家可以整体放进一个高带宽域而不被机器边界撕裂——而最痛的 all-to-all 通信还被 CCU 硬件接走了。具体这对优化工作意味着什么，第 9.6 节会接着讲。
优化之前必须先回答一个问题：这段代码是被算力卡住，还是被带宽卡住？Roofline 模型给出可计算的答案。
任何一段计算都可以用三个数字刻画：需要做多少次浮点运算（FLOPs）、需要从显存搬多少字节（Bytes）、以及两者的比值——算术强度（Arithmetic Intensity，也叫计算密度）：
给一个 BF16 张量每个元素加个偏置：读 2 字节、写 2 字节，只做 1 次加法 → AI = 1 ÷ 4 = 0.25 FLOPs/Byte。距拐点 295 差了三个数量级，可达性能 ≈ 0.25 × 3.35 TB/s ≈ 0.84 TFLOPS，只有峰值的 0.08%。结论：这类算子的耗时纯粹由访存量决定，唯一的优化是把它"融合"进相邻算子里，省掉一次显存往返。这就是 kernel fusion 的全部收益来源。
70B 模型、BF16 权重（140 GB），batch=1 时每生成一个 token 必须把全部权重读一遍：AI ≈ 2×70e9 FLOPs ÷ 140e9 Bytes = 1 FLOPs/Byte——严重带宽受限。理论速度上限 = 3.35 TB/s ÷ 140 GB ≈ 24 token/s（单卡若装得下的情况下）。关键洞察：把 batch 提到 64，权重只需读一次却服务 64 个请求，算术强度和吞吐几乎线性提升，而单请求速度几乎不变。这就是连续批处理（continuous batching）为什么是推理优化的第一杠杆——它把 decode 从带宽受限往算力受限的方向拖。
Prefill 阶段一次处理整段输入（如 2,048 个 token），权重读一次服务 2,048 个 token 的计算，算术强度轻松达到数百以上 → 落在平顶区，是 compute-bound。推论：Prefill 与训练比的是算力和算子实现质量；Decode 比的是带宽、显存和批处理策略。同一套硬件上，这是两门不同的手艺——这也正是第 7 章 PD 分离的理论依据。
Roofline 给出的不只是解释，更是一套动作指引：
| 诊断 | 症状 | 有效手段 | 无效手段 |
|---|---|---|---|
| 带宽受限 | 算力利用率极低，改用更强算力的卡毫无提升 | 算子融合、量化（减少字节）、KV Cache 压缩、提高 batch、重排数据布局提升缓存命中 | 换算力更高的卡、优化数学运算次数 |
| 算力受限 | 已接近峰值算力的合理比例 | 用上 Tensor Core（对齐尺寸/精度）、更优的分块与流水、降低精度（BF16→FP8） | 继续减少访存 |
| 延迟受限 | 算力与带宽都不满，卡在等指令或等同步 | 消除 host 瓶颈（图模式/CUDA Graph）、增大并发、异步化、通信计算重叠 | 单纯优化单个算子 |
| 通信受限 | 单卡指标正常但集群扩展性差 | 调整并行策略、拓扑感知放置、通信压缩与重叠、网络调优 | 优化单卡算子 |
工程实践上，这四类诊断靠 profiling 工具（NVIDIA 侧的 Nsight Systems/Compute，昇腾侧的 msprof/MindStudio）给出的时间线来区分：看计算流、通信流、host 侧调度三条时间线上谁在忙、谁在等。不做 profiling 就动手优化，是这一行最常见的浪费。
硬件的能力要经过一整条软件链路才能被模型用上。任何一层不成熟，上面的性能就漏水——这是"生态"二字的技术含义。
| 层 | 职责 | NVIDIA 生态 | 昇腾生态 |
|---|---|---|---|
| ① 驱动 / 固件 | 操作系统与芯片对话，设备管理 | NVIDIA Driver | Ascend Driver + 固件 |
| ② Runtime | 内存分配、任务下发、流与事件同步 | CUDA Runtime | CANN Runtime（ACL 接口） |
| ③ 算子库 | 预先写好并调优的高性能计算内核 | cuBLAS / cuDNN / CUTLASS | aclnn 算子库 / Ascend C 自定义算子 |
| ④ 通信库 | 多卡集合通信（all-reduce 等） | NCCL | HCCL |
| ⑤ 编译器 / 图引擎 | 把计算图优化并编译为设备可执行 | NVCC、TensorRT、torch.compile/Inductor | GE 图引擎、毕昇编译器、AOE 自动调优 |
| ⑥ 框架 | 定义与执行模型，自动微分 | PyTorch（一等公民）、JAX | MindSpore（原生）、torch_npu（适配层） |
| ⑦ 分布式 / 服务引擎 | 大规模训练与推理的调度编排 | Megatron-LM、DeepSpeed、vLLM、SGLang | MindSpeed、上述引擎的昇腾适配版本 |
这张表解释了两件事。第一，为什么"能跑"和"跑得好"差距巨大：模型能跑起来只需要③⑥两层最基本的功能可用；而跑得好要求③的算子逼近硬件峰值、④的通信高效、⑤的编译能做全局优化、⑦的调度不留空转——任何一层短板都直接砍掉有效算力。第二，为什么迁移的工作量被系统性低估：迁移不是"改个 device 名"，而是要在③④⑤三层逐一验证性能与数值，而这三层恰好是最需要硬件纵深知识的地方。
算子（Operator / Kernel）是计算图的最小执行单位：一次矩阵乘、一次 softmax、一次归一化都是一个算子。一个大模型跑起来是几百上千个算子按顺序执行。三个必须理解的概念：
同一个模型有三种执行方式，性能差异显著：
CPU 逐个算子向设备下发指令。灵活、易调试（Python 里可以单步看每个中间结果），但每个算子都有固定的下发开销。当单个算子的执行时间小于下发开销时，设备就在等 CPU——这就是 host bound。
先把整张计算图捕获下来，做全局优化（融合、常量折叠、内存复用）后一次性交给设备执行。性能好，但要求形状静态、调试困难、动态控制流受限。昇腾的"整图下沉"、TensorFlow 的静态图都属于这一路。
折中方案：把一串算子的下发过程"录制"成一个可重放的单元，之后一次调用重放全部。消除 CPU 下发开销而不必重写模型，对 decode 这种小算子密集的场景收益显著，vLLM/SGLang 默认启用。
编译器的角色与局限。AI 编译器（TVM、XLA、torch.compile、昇腾侧的图算融合与 AOE）自动完成"图 → 高效设备代码"的翻译，能自动做算子融合、内存规划与部分调优。但业界的现实是：编译器自动生成的算子在关键路径上通常仍打不过顶尖手写实现（手写能利用编译器难以自动发现的数学等价变换与硬件细节）。因此专业团队的标准打法是"手写关键算子攻性能、编译器铺长尾补覆盖"——这也是评估一个优化团队深度的试金石：只会调编译器参数的是使用者，能手写关键算子的才是能解决问题的人。
一个模型放不进一张卡，就必须切开。怎么切决定了通信量，通信量决定了集群效率——这是大规模训练最核心的设计决策。
训练一个 70B 模型，显存需求远不止权重那 140 GB。用 Adam 优化器的混合精度训练，每个参数需要存：
加上前向过程中必须保存下来供反向使用的激活值（与批大小、序列长度成正比，长序列场景下可能比权重还大），显存就是大规模训练的第一约束。于是有了下面这一整套"怎么切"的技术谱系。
做法：每张卡保存一份完整模型，各自处理不同的数据批次，反向算完梯度后所有卡做一次 all-reduce 求平均，再各自更新权重——保证所有卡的模型始终一致。
通信量：每步需要同步全部梯度，通信量约为 2 × 参数量（ring all-reduce 的经典结论：每张卡发送与接收的数据量各约等于梯度总量，与卡数几乎无关，这是它扩展性好的原因）。70B 模型 BF16 梯度约 140 GB，即每一步都要在网络上搬运百 GB 量级的数据——所以数据并行的规模上限往往由网络带宽和梯度同步能否与反向计算重叠决定。
局限：每卡都要装下完整的权重 + 梯度 + 优化器状态。这直接催生了 ZeRO（第 5 章）——它把"每卡一份完整状态"改成"状态也切开"，在保持数据并行简洁性的同时解决显存问题。
做法：把单个权重矩阵切开。以 Transformer 的 FFN 为例：第一个矩阵按列切（每卡算一部分中间结果，无需通信），第二个矩阵按行切（每卡算出部分和，然后 all-reduce 求和得到正确结果）。注意力部分则按注意力头切分——天然并行，每卡算一部分头。这套切法是 Megatron-LM 的经典设计，妙处在于一层里只需要在特定位置做两次通信（前向一次 all-reduce、反向一次）。
代价：通信次数与层数成正比，且位于计算的关键路径上（下一步计算必须等通信完成）。所以 TP 有一条铁律：张量并行组必须放在同一节点内、走 NVLink 级的高带宽域。跨节点做 TP 会让通信开销吞掉全部收益。这也解释了第 1 章的结论：节点内是否有交换式全互联，直接决定这个集群能做多大的 TP，进而决定能训多大的模型。
做法：把模型按层切成若干"段"（stage），每卡负责一段，数据像流水线一样依次穿过。通信量最小——只在段与段之间传递激活值。
气泡（bubble）：朴素实现下，卡 1 在算的时候卡 2、3、4 都在等，利用率极低。解法是把一个批次切成多个 micro-batch 依次注入，让各段同时忙起来。但流水线的填充和排空阶段仍有空转：
专家并行是 MoE 模型的专属切法：把不同的专家放到不同卡上，每个 token 经路由器决定去哪几个专家。通信模式是 all-to-all——每张卡都要把自己的 token 发给持有对应专家的所有卡，再把结果收回来。这是最"吵"的通信模式，对互联带宽的要求比 all-reduce 更苛刻；再叠加专家负载不均（热门专家所在的卡忙死、冷门专家的卡闲着），使 MoE 的工程难度显著高于稠密模型。DeepSeek 等团队的做法是大规模 EP（把专家摊到上百张卡）配合冗余专家副本与精细的通信—计算重叠。
序列并行 / 上下文并行解决的是长序列问题：当上下文长到 128K、1M，单卡连一条序列的激活值都存不下，于是把序列本身切开分到多卡。注意力需要每个 token 看到全部上下文，因此要用 Ring Attention 之类的方案，让各卡的 K/V 分块像接力一样环形流转，边传边算。
实际的万卡训练是多种并行的乘积组合，例如 TP=8 × PP=4 × DP=32 共用 1,024 卡。业界形成的配置原则相当稳定：
| 并行方式 | 通信模式与频率 | 通信量级 | 放置位置 | 主要作用 |
|---|---|---|---|---|
| 张量并行 TP | all-reduce，每层数次 | 高（激活值级 × 层数） | 节点内，通常 ≤8 | 降低单层显存与单卡算力压力 |
| 专家并行 EP | all-to-all，每 MoE 层两次 | 高且不规则 | 节点内优先，可跨节点 | 承载 MoE 的巨大总参数量 |
| 序列/上下文并行 | 环形 P2P 或 all-gather | 中（与序列长度相关） | 节点内优先 | 支撑超长上下文 |
| 流水线并行 PP | 点对点，每段边界一次 | 低（只传边界激活） | 跨节点 | 把超大模型摊到更多节点 |
| 数据并行 DP | all-reduce，每步一次（可与反向重叠） | 中（梯度级，可重叠隐藏） | 最外层，跨机架 | 扩大吞吐、消化更多数据 |
① 从内到外按通信频率排列：TP/EP 在最内（节点内），PP 居中（跨节点），DP 在最外——让最吵的通信走最短的线；② TP 规模不超过单节点卡数（通常 8），除非有超节点级的大高带宽域；③ 先用 TP 把单卡显存压下来，再用 PP 扩到装得下，剩下的卡全部给 DP 提吞吐；④ micro-batch 数量至少是流水线段数的 4 倍以上，否则气泡吃掉的比并行省下的更多；⑤ 一切以 profiling 结果为准——同样的模型换一种网络拓扑，最优配置可能完全不同。"并行策略定制"这项服务的技术含量就在这里：它是一个受硬件拓扑、模型结构、序列长度、批量大小共同约束的搜索问题，没有通用最优解。
并行解决"装得下"，这一章解决"跑得快、算得准、省得下"——以及如何用一个数字衡量全部成果。
ZeRO（Zero Redundancy Optimizer）的洞察极简：在数据并行里，每张卡都存着完全相同的优化器状态、梯度和权重——这是纯粹的冗余。既然如此，不如切开，每卡只存 1/N，需要时再临时通信取回：
| 阶段 | 切分内容 | 显存降幅（N 卡数据并行） | 额外通信 | 典型用法 |
|---|---|---|---|---|
| ZeRO-1 | 优化器状态 | 约降至 1/4（占比最大的部分被切） | 基本无额外（reduce-scatter 替代 all-reduce） | 几乎无脑开启 |
| ZeRO-2 | + 梯度 | 约降至 1/8 | 轻微 | 常用默认 |
| ZeRO-3 | + 权重（用时 all-gather 取回） | 约 1/N（线性下降） | 显著：每层前向/反向都要收集权重 | 显存极度紧张时；需与计算重叠 |
| Offload | 状态挪到 CPU 内存 / NVMe | 显存几乎不受限 | 受 PCIe 带宽严重限制 | 小规模/单机场景救急 |
激活重计算（gradient checkpointing）是另一把利器：前向时只保存少数"检查点"层的激活，其余丢弃；反向需要时用检查点重新算一遍。典型效果是激活显存降低到平方根量级，代价是额外约 30% 的前向计算量——标准的时间换空间。这也引出了一个重要的指标区分：MFU 与 HFU。HFU（Hardware FLOPs Utilization）把重计算的额外计算也算作"有用工作"，MFU 只算模型本身所需的计算。所以同一次训练 HFU 总是高于 MFU，比较两个团队的成绩时必须确认口径一致——这是行业里常见的"数据打架"来源之一。
| 格式 | 总位数 | 指数位 / 尾数位 | 特点 | 用途 |
|---|---|---|---|---|
| FP32 | 32 | 8 / 23 | 范围与精度都够用，慢且占显存 | 主权重、优化器状态、敏感计算 |
| TF32 | 19（存储仍占 32） | 8 / 10 | 范围同 FP32、精度降低，Tensor Core 可加速 | NVIDIA 上的默认矩阵乘加速档 |
| FP16 | 16 | 5 / 10 | 精度尚可但动态范围窄，易上溢/下溢 | 需配 loss scaling；推理常用 |
| BF16 | 16 | 8 / 7 | 范围与 FP32 相同，精度更低但训练更稳 | 现代训练的默认选择 |
| FP8 | 8 | E4M3 / E5M2 两种 | 再快一倍、再省一半，但需精细的缩放策略 | 前沿训练与推理，工程门槛高 |
这张表里最关键的一行是 BF16 与 FP16 的对比。FP16 只有 5 个指数位，能表示的最小正常数约 6×10⁻⁵——而深度学习里梯度经常比这更小，于是直接变成 0（下溢），训练失败。历史上的解法是 loss scaling：把损失乘上一个大系数（如 1024）把梯度整体抬进 FP16 的可表示范围，更新前再除回去。BF16 用 8 个指数位换掉 3 位尾数，动态范围与 FP32 一致，从此不再需要 loss scaling——训练稳定性的价值超过了那点精度损失，这是深度学习数值实践中最重要的一次取舍。
FP8 的挑战在于 8 位的动态范围实在太窄，必须做细粒度的缩放（per-tensor 甚至 per-block 的缩放因子）、并对敏感环节（如注意力的累加、优化器更新）保留更高精度。DeepSeek V3 的技术报告展示了一套完整的 FP8 训练方案（细粒度量化 + 高精度累加 + 关键路径保留 BF16），是这条路线上最重要的公开工程参考。
浮点加法不满足结合律：(a+b)+c ≠ a+(b+c)。而不同硬件的归约顺序、累加位宽、并行拆分方式各不相同，于是同一个数学表达式在两块芯片上得到的结果在最后几位就是不同的。单步差异微不足道，但训练要走几十万步，误差会被反复放大、与学习率和梯度裁剪相互作用，最终可能表现为 loss 曲线分叉、发散或收敛到更差的点。这就是"精度对齐"工作的本质：不是要求两块卡逐位一致（通常做不到），而是要把差异控制在不影响收敛的范围内，并具备逐层定位差异来源的能力。标准方法论是分层对标——先固定随机性（种子、确定性算子）→ 单算子逐个比对（输入相同，看输出的相对误差与最大绝对误差）→ 逐层前向比对 → 反向梯度比对 → 短程训练 loss 曲线比对 → 长程收敛验证。每一步都要有工具支撑（dump + 自动比对），这是国产卡训练交付里最耗人力、也最难替代的一环。
注意力机制的朴素实现分四步：算 S = Q·Kᵀ（得到一个 N×N 的矩阵，N 是序列长度）→ 做 softmax → 乘 V → 输出。问题出在那个 N×N 矩阵：序列 8K 时它是 6,400 万个数，必须写进 HBM 再读出来，显存占用和访存量都随序列长度平方增长。按第 2 章的 Roofline 分析，这是典型的带宽受限灾难。
FlashAttention 的核心思想：永远不把那个 N×N 矩阵完整地写进显存。做法是分块（tiling）——把 Q、K、V 切成能装进片上共享内存的小块，在片上完成"算一块 → 局部 softmax → 乘 V → 累加到输出"，然后用 online softmax（在线归一化）技巧，边算边修正之前的归一化因子，保证分块计算的结果与一次性算全局 softmax 数学等价。
三代演进的脉络：FlashAttention-1 确立了分块 + online softmax 的 IO 感知思路；-2 改进了工作划分与并行维度（沿序列维度并行、减少非矩阵乘运算占比），把 GPU 利用率进一步推高；-3 针对 Hopper 架构利用异步执行与低精度（FP8）特性再次提速。这条演进线本身就是一个重要启示：同一个算子，随着对硬件特性的挖掘不断改进，性能可以持续翻倍——而每一代改进都需要对目标硬件的深入理解，这正是"新硬件上缺少顶尖算子实现"造成的性能差距的来源。
前面所有优化的成果，最终收敛到一个数字：MFU（Model FLOPs Utilization）= 模型实际所需的浮点运算量 ÷（硬件峰值算力 × 训练时间）。计算它需要一个经典公式：
题目：70B 参数，训练 15T token，用 1,024 张 H100（BF16 峰值 990 TFLOPS/卡），MFU 假设 40%。
第一步 · 总计算量：6 × 70e9 × 15e12 = 6.3e24 FLOPs
第二步 · 集群有效算力：1024 × 990e12 × 0.40 ≈ 4.06e17 FLOPs/s
第三步 · 时间：6.3e24 ÷ 4.06e17 ≈ 1.55e7 秒 ≈ 180 天
关键推论：若把 MFU 从 40% 提到 50%（相对提升 25%），训练时间缩短到约 144 天，省下 36 天 × 1,024 张卡的机时。按当前市场的卡时价格，这是数千万元量级的差异——而工作量只是几个人几周的调优。这就是算力优化的商业价值最直白的算法。
反过来，这个公式也是尽调工具：听到"我们用 X 张卡训了 Y 天做出 Z 参数的模型"，用 6ND 一算就能反推出对方的 MFU 是否可信。行业参照：顶级团队在 NVIDIA 集群上的稠密模型训练 MFU 通常在 35–50% 区间，MoE 模型因通信更重通常更低；国产卡集群普遍在 30% 上下甚至更低，能稳定做到 45%+ 属于顶尖水平。
万卡集群跑上几十天，硬件必然会坏。有效算力等于"峰值算力 × MFU × 正常运行时间比例"——第三个因子往往被低估。
规模带来的统计规律很残酷：单张卡的故障率乘上一万，再乘上几十天，故障就从"意外"变成"日常"。Meta 公开的 Llama 3 训练记录是这方面最有价值的公开数据：在 16,384 张 H100 上训练 54 天，共发生 466 次作业中断，其中 419 次为非预期故障，硬件问题（GPU 故障、HBM 故障、网络）占绝大多数——平均每天约 8 次以上非预期中断。他们最终仍把有效训练时间维持在 90% 以上，靠的是一整套自动化的检测、隔离与恢复机制。
不仅要发现"进程挂了"，还要发现更难缠的慢节点（straggler）——某张卡因降频、ECC 错误或网络劣化变慢，由于集合通信要等最慢的那个，整个集群被拖到它的速度。检测手段：逐 step 时间监控、各 rank 通信等待时间比对、定期健康巡检。
存得太频繁浪费时间（TB 级状态写盘很慢），太稀疏则故障损失大。工程要点：异步 checkpoint（先拷到 CPU 内存再后台落盘，训练不停）、分片并行写、只存必要状态。最优频率由"写一次的成本"与"平均故障间隔"共同决定。
热备节点池 + 故障自动隔离 + 拉起新 rank 后重建通信域。理想状态是训练框架能在不重启整个作业的情况下完成成员变更（弹性训练），把恢复时间从小时级压到分钟级甚至秒级。
出问题要能重现，否则无从调试。需要固定随机种子、使用确定性算子实现、记录完整的运行配置与数据顺序。代价是性能通常会损失几个百分点——所以通常只在排查阶段开启。
这一章的内容在商业上常被低估：客户容易理解"MFU 提升 20%"，不容易理解"有效运行时间从 70% 提到 92%"其实是同等量级甚至更大的收益。实际交付中，长稳工程往往是第一个月最先见效、也最容易让客户产生信任的部分。
训练是一次性投入，推理是每天都在流血的成本。这一章从物理下限出发，逐层拆解把成本降下来的每一种手法。
推理优化的一切讨论都应该从两个数字开始。
把这两个数字并列，推理优化的全部逻辑就清楚了：算力有 7,000 的能力，带宽只允许 24 的产出——两者相差近 300 倍，这就是"decode 阶段算力大量空转"的准确含义。于是所有推理优化都在做同一件事的变体：让每次昂贵的权重读取服务更多的计算。
最直接的手段是提高批量（batching）：把 64 个请求攒在一起，权重仍然只读一次，却同时算出 64 个 token。算力占用增加 64 倍（反正原本空转），带宽占用几乎不变——吞吐提升近 64 倍，而单个用户的速度几乎不受影响。这就是为什么推理服务的第一优化永远是批处理策略，也是为什么"单请求延迟"和"系统吞吐"是两个必须分开谈的指标。
| 阶段 | 计算特征 | 算术强度 | 瓶颈 | 优化方向 |
|---|---|---|---|---|
| Prefill（读题） | 一次处理整段输入的所有 token，大矩阵乘 | 高（数百以上） | 算力 | 算子质量、并行策略、FP8；长输入要防显存爆 |
| Decode（作答） | 每步只处理 1 个 token × batch，瘦长矩阵 | 低（≈batch 量级） | 显存带宽 | 提高 batch、量化权重、KV 压缩、投机解码 |
注意力机制要求每个新 token 与之前所有 token 计算相关性。若每步都重算全部历史的 Key/Value，计算量随长度平方增长；把它们缓存下来，就变成每步只算新 token 的 K/V——这就是 KV Cache，用显存换算力的经典交易。代价是这块显存随上下文线性增长，且必须一直驻留。
以一个 70B 级模型为例（80 层、8 个 KV 头（GQA）、head_dim 128、BF16）：
单 token 每层 KV = 2 × 8 × 128 × 2 字节 = 4 KB；全模型单 token = 4 KB × 80 层 = 320 KB
那么：8K 上下文 ≈ 2.5 GB／单请求；128K 上下文 ≈ 40 GB／单请求。
结论：一张 80GB 的卡装完 140GB 权重的一半后所剩无几——所以长上下文服务必须多卡、必须压缩 KV。若不用 GQA 而是 64 个 KV 头的传统多头注意力，上面的数字要再乘 8（128K 上下文将占 320 GB），这就是 GQA/MQA/MLA 这类"KV 压缩"架构成为标配的原因。
传统推理框架为每个请求预留一整块连续显存，大小按可能生成的最大长度算。问题显而易见：一个实际只生成 100 个 token 的请求，却按 2,048 预留，剩下的全部浪费；而且这些连续大块会造成外部碎片——总显存够，却找不到连续的一块。vLLM 论文测得传统方式的显存浪费高达 60–80%。
PagedAttention 的解法直接借自操作系统的虚拟内存：把 KV Cache 切成固定大小的"块"（如 16 个 token 一块），逻辑上连续的序列在物理显存里可以散落各处，用一张块表（block table）记录映射。收益有三层：
PagedAttention 让"共享"成为可能，RadixAttention（SGLang 提出）则让共享变成自动的：用一棵基数树（radix tree）组织所有活跃与近期请求的 KV Cache，新请求进来时自动在树上匹配最长公共前缀，命中的部分直接复用、不再重算。
为什么这在 2026 年格外重要？因为现代负载的前缀重复率极高：① 系统提示词——每个请求都带着相同的几百上千 token 的指令；② 多轮对话——第 N 轮的前缀就是前 N-1 轮的全部内容；③ Agent 场景——同一个任务模板反复调用，工具描述、少样本示例大段重复；④ 文档问答——同一份长文档被多个问题反复引用。命中前缀缓存意味着 Prefill 的计算被整段跳过，TTFT 大幅下降、成本大幅下降。这就是为什么各家 API 都推出了"缓存命中"的差别定价，命中与未命中的输入价格可以相差一个数量级以上。
7.1 节说明了批处理是第一杠杆，但传统的静态批处理有个致命问题：一批请求必须一起开始、一起结束。而生成长度天然不齐——有的请求生成 20 个 token，有的生成 2,000 个，短的早早算完却必须占着位置等最长的那个，造成大量空转。
连续批处理（Continuous Batching，源自 Orca 论文的 iteration-level scheduling）把调度粒度从"一批"细化到"一次迭代"：每生成一个 token 就检查一遍，谁完成了就立即释放位置、把等待队列里的新请求补进来。批次的成员在不断流动，硬件始终满载。
第 2 章证明了 Prefill 是算力受限、Decode 是带宽受限；7.5 节的连续批处理又带来一个新矛盾：当一个超长输入的 Prefill 插进来时，它会占用大量算力，导致同批次里所有正在 decode 的请求卡顿——用户感受是"打字突然停顿"（TPOT 抖动）。
PD 分离（Prefill-Decode Disaggregation，DistServe、Mooncake 等系统的核心设计）的思路：把两个阶段拆到不同的硬件池，各自用最适合的配置与并行策略，Prefill 完成后把 KV Cache 传给 Decode 池继续。收益是三重的：互不干扰（延迟指标稳定）、各自可独立扩缩容（按实际负载配比）、可用不同硬件（Prefill 用算力强的卡、Decode 用带宽大显存大的卡）。代价是 KV Cache 的跨节点传输开销——这对互联带宽提出要求，也是这套架构在国产集群上落地的主要难点与手艺所在。
既然 decode 受带宽限制，而带宽消耗正比于权重字节数，那么把权重从 16 位压到 8 位或 4 位，速度就能接近翻倍或翻两倍——量化是推理降本最直接的杠杆。方法按"压什么"分为几类：
| 方法 | 压什么 | 核心思想 | 典型效果 | 注意 |
|---|---|---|---|---|
| GPTQ | 仅权重（W4/W8） | 逐层做二阶近似的最优舍入，逐列量化并补偿误差 | 4 bit 下精度损失小 | 需校准数据；计算时反量化回高精度做矩阵乘 |
| AWQ | 仅权重 | 识别对输出影响大的"重要通道"并保护其精度 | 与 GPTQ 相当，实现更简洁 | 同样需要少量校准数据 |
| SmoothQuant | 权重 + 激活（W8A8） | 把激活的离群值"平滑"迁移到权重上，让两者都好量化 | 可用整数 Tensor Core，吞吐提升明显 | 激活离群值是 LLM 量化最大难点 |
| FP8 推理 | 权重 + 激活 | 用硬件原生 FP8 格式，无需复杂校准 | 接近 2 倍提速，精度损失很小 | 需硬件支持 FP8（部分国产卡尚缺） |
| KV Cache 量化 | KV 缓存（8 bit / 4 bit） | 缓存本身降精度存储 | 直接放大可服务的并发与上下文 | 长上下文场景收益最大 |
工程铁律：任何量化都必须配套精度评测——不只看困惑度（PPL）这类粗指标，要在真实业务的评测集上比对优化前后的效果，把"可接受的效果损失"写成明确的验收标准。这是把量化从"技术尝试"变成"可交付服务"的关键一步。
投机解码（Speculative Decoding）利用了一个不对称性：验证比生成便宜。做法是让一个小的"草稿模型"（或模型自身的浅层、或额外的预测头如 Medusa/EAGLE）一次性猜出接下来的 k 个 token，然后让大模型一次前向并行验证这 k 个猜测——猜对的部分直接采纳，第一个猜错处截断重来。因为验证 k 个 token 的前向与生成 1 个 token 的前向成本几乎相同（都受带宽限制、算力有余），所以只要接受率够高，就能把单请求速度提升 1.5–3 倍。关键指标是"接受率"：草稿模型越接近大模型的分布，接受率越高、收益越大；但草稿模型越大，本身的开销也越大——这是一个需要按场景调优的平衡。
MoE 服务的挑战在第 4 章已埋下伏笔：推理时每个 token 只激活少数专家，但显存必须装下全部专家。于是大规模 MoE 推理走"大规模专家并行"路线：把专家摊到很多卡上（业界已有 EP 上百的部署），每张卡只存一部分专家。这带来两个必须解决的工程问题：① all-to-all 通信成为主要开销，需要精细的通信—计算重叠与拓扑感知放置；② 专家负载天然不均（热门专家被更多 token 选中），需要冗余副本、动态重平衡等手段，否则少数卡成为全系统的瓶颈。这也是 DeepSeek 等团队公开的推理基础设施里最有技术含量的部分。
第一层（必做，收益最大）：连续批处理 + PagedAttention + 前缀缓存——这三项是现代推理引擎的默认配置，不开启等于白扔一半算力。第二层（按场景选）：量化（成本敏感）、PD 分离（延迟敏感且规模大）、KV 量化（长上下文）、投机解码（单请求速度敏感）。第三层（深水区）：算子级优化与缺失算子补齐、MoE 的 EP 部署与负载均衡、跨硬件适配调优——这一层需要芯片级知识，也是新兴硬件上性能差距的主要来源。
2025 年之后，算力的增量重心从预训练转向强化学习后训练。它把训练和推理两种截然不同的负载塞进同一个循环，是当前最难的系统工程。
经典 PPO 需要同时持有四个模型：actor（既要训练又要生成）、critic（训练）、reward model（只前向打分）、reference model（只前向，用于约束偏离）。系统的全部复杂度都源于这个组合：两个训练态 + 两个推理态 + 一个横跨两态的 actor。
为什么 rollout 吃掉这么多时间？回到第 7 章的物理：解码是带宽受限且耗时随序列长度线性增长，而训练是算力受限、能靠批处理摊平。再叠加长尾拖尾（straggler）——同一批里有的回答 200 个 token 就结束、有的写了 8,000 个思维链 token，而同步屏障让所有卡等最慢的那一条。长思维链和 Agent 场景把这个问题放大到极致。
算法侧的演进也在减轻系统负担：GRPO 用组内相对奖励替代价值网络，直接删掉 critic，把"带优化器状态的模型"从 2 个减到 1 个；DAPO 增加动态采样（过滤掉全对或全错的组，避免零梯度浪费）与超长惩罚；GSPO 把重要性采样从 token 级抬到序列级，理由是长序列上 token 级修正会累积高方差噪声，可能导致不可逆的模型崩塌——在 MoE 上尤其明显。
训练与生成分时复用同一批卡。Rollout 阶段把优化器状态、梯度卸载到 CPU 腾出显存给 KV Cache，训练阶段再搬回来；权重同步可走同卡的显存共享（CUDA IPC），几乎零传输。优点：卡不空转、利用率高。代价：显存腾挪本身耗时，且两个伸缩行为完全不同的阶段被绑在同一资源池。
推理集群与训练集群物理分开，各自选最优并行策略、甚至用不同型号的硬件（生成侧要大显存大带宽，训练侧要算力）。优点：各自最优、易于集成异构引擎。代价：跨集群传权重；且在同步模式下，必有一端空转等待另一端。
主流框架的分野正在这里：veRL（字节，HybridFlow 论文）的核心贡献是一套混合编程模型——上层数据流用"单控制器"（driver 有全局视野，一段 PPO 逻辑几十行 Python 就能表达），下层每个模型的分布式计算用"多控制器/SPMD"（保留原生训练框架的效率）。它的工程红利极大：只改一处资源池映射就能在共置与分离之间切换，控制逻辑一行不动。论文另一项贡献 3D-HybridEngine 解决 actor 在"训练并行布局"与"生成并行布局"之间的重分片，做到不额外多存一份推理权重。
| 框架 | 技术栈 | 定位与差异 |
|---|---|---|
| veRL | Megatron/FSDP + vLLM/SGLang + Ray | 通用；混合控制器；共置/分离皆可；生态最大，已支持多硬件后端与 Agent 循环 |
| OpenRLHF | Ray + vLLM + DeepSpeed ZeRO-3 | 出发点就是"不要把四个模型全挤在同一批卡上"，用 Ray 做细粒度放置 |
| slime | Megatron + SGLang + Data Buffer | 把单一路径做深；把多轮工具调用与沙箱交互当作"数据生成工作流"接进同一循环，面向 Agent 与长轨迹 |
| AReaL | SGLang + Megatron | 完全异步的代表：可中断 rollout + 解耦的 PPO 目标，报告相对同步系统最高约 2.8× 加速 |
同步 RL 的浪费是结构性的：生成时训练卡闲着，训练时生成卡闲着，而且每一步都要等最慢的那条轨迹。三种异步手法：
这是本章最值得记住的一节。同一份权重，在训练框架和推理引擎里算出的 logprob 不一样。原因不是 bug，而是两套系统用了不同的算子实现、不同的融合策略、不同的归约顺序、不同的注意力内核（甚至不同的量化）。浮点加法不满足结合律，于是结果在最后几位不同。
后果非常严重：名义上的 on-policy 训练被隐式变成了 off-policy——重要性比值的分母本身就是错的，梯度估计有偏，表现为训练不稳定甚至崩塌。更微妙的一层是批大小相关的非确定性：不同的 batch size 会改变内核的归约切分方式，于是同一个输入在不同负载下得到不同的输出。有研究指出，即使把推理引擎打补丁让它吐出真实采样概率、把输出头转成 FP32 对齐，不一致依然存在——这是混合后端设计的固有问题。
① 截断重要性采样（TIS）：对"训练概率 ÷ 生成概率"的比值做单边上截断，压住极端权重——最便宜且有效，即使 rollout 走量化也能稳住。② 直接换分母：把推理引擎返回的 logprob 当作行为策略概率，从定义上消除不一致。③ 数值兜底：关键路径用 FP32、显式重算 logprob。④ 批不变内核（batch-invariant kernels）：让 RMSNorm、矩阵乘、注意力这三类算子使用与 batch 无关的单一归约策略，从根上实现确定性推理——已有推理引擎落地了这条路，且兼容分块预填充、图模式与前缀缓存，配合采样种子还能做到"多样但可复现"（这正是 GRPO 需要的）。
权重同步的工程细节也值得一提：每步要把几十到几百 GB 权重从训练侧搬到推理侧。通道上，同卡共置走显存共享句柄，跨卡走集合通信广播。但真正的成本在重分片：训练侧的分片布局（DP+PP+TP+EP+CP）与推理侧（DP+TP+EP）不一致，主流做法要先在若干源节点上把分片聚成完整张量、转成目标布局再广播，产生多余流量和热点。优化手段是分桶传输 + 通信与拷贝重叠 + 原地更新避免双份显存——有团队报告把大 MoE 模型的权重传输优化了约一个数量级。
当 RL 的对象从"回答问题"变成"完成任务"，系统面临全新的瓶颈：一个训练批次可能触发上千次代码执行、网页访问、工具调用。这些是 CPU 密集甚至 IO 密集的工作，而昂贵的 GPU 在旁边干等。业界的应对是把环境服务化——用专门的隔离沙箱服务承接高并发执行，并把"亚秒级启动"作为硬指标（沙箱绝不能成为饿死 GPU 的延迟瓶颈）。
另一个被放大的问题是调度不均：标准 RL 把 rollout 静态均分到 GPU，本已因长度差异造成空等；Agent 场景下每条轨迹跨多个回合、每回合 token 数还不均匀，这种不均衡会在每个回合重复出现并累加，最坏延迟被逐轮放大。当前的趋势是把多轮 rollout 的完整生命周期从训练栈解耦（rollout as a service），让算法与 Agent 设计独立演进。
前八章的原理是硬件无关的。这一章落到具体：在昇腾生态里，这些优化分别对应什么工具、什么坑、什么手艺。
把第 3 章的七层结构落到具体产品，这张对位表值得背下来——它是与昇腾生态工程师对话的基础词汇：
| 层 | 昇腾（CANN） | NVIDIA 对位 |
|---|---|---|
| 驱动 / 固件 | Ascend Driver + 固件（npu-smi） | NVIDIA Driver（nvidia-smi） |
| Runtime | AscendCL / acl（aclrtStream、aclrtMemcpy） | CUDA Runtime（cudaStream、cudaMemcpy） |
| 单算子库 | aclnn / AOL；大模型算子库 ATB | cuBLAS + cuDNN；FlashAttention 类库 |
| 模板库 | Catlass（含 Python DSL） | CUTLASS |
| 图引擎 / 编译 | GE 图引擎 + 融合 Pass；毕昇编译器；AOE 自动调优 | TensorRT / XLA / torch.compile |
| 通信库 | HCCL（底层 HCOMM） | NCCL |
| 框架适配 | MindSpore（原生）、torch_npu（适配层） | PyTorch CUDA 后端 |
| 大模型套件 | MindSpeed / MindSpeed-LLM（Megatron 的 NPU 适配） | Megatron-LM / DeepSpeed |
CANN 已大规模开源并迁移代码托管：算子库拆成独立仓库开放（神经网络算子、大模型 Transformer 算子、矩阵乘融合模板、自动融合、并行分块虚拟指令集等），配套训练调优与推理部署的实践仓库也已公开。Ascend C 编程接口新增了四层 API 体系，其中最值得注意的是新增了支持业界通用 SIMT 编程模型的 API 层——这是昇腾主动向 CUDA 心智模型靠拢的信号；同时推出 Python 风格的算子 DSL（对位 Triton 的生态位），号称把编译时间相比 C++ 模板缩短八成以上。结论：生态在快速补齐，但"补齐"与"追平"之间仍隔着社区厚度与长尾算子覆盖。
第 1 章讲了达芬奇架构的硬件差异，这里是它在编程模型上的直接后果。核函数以特定修饰符声明、由主机侧下发，编程范式是 SPMD——多核执行同一份指令，唯一差别是核编号，每个核按编号取自己那一片数据。片上存储层次为：全局显存(HBM) → L2 → L1 → UB（向量单元统一缓冲）/ L0A、L0B（矩阵单元输入）→ L0C（矩阵单元累加输出），一个典型矩阵乘的数据流是 GM→L1→L0A/L0B→Cube→L0C→UB。
| # | CUDA 的做法 | Ascend C 的做法 | 对开发者的含义 |
|---|---|---|---|
| 1 | 并行粒度是 thread / warp，几万线程掩盖延迟 | 并行粒度是"核"，核少但单核强 | 切分策略偏大块；不能靠海量线程隐藏延迟 |
| 2 | 缓存自动命中、访存自动合并 | 必须显式搬运（DataCopy） | 数据流由你规划，写错就慢几倍 |
| 3 | __syncthreads() 隐式同步 | 队列 / 屏障显式同步 | 流水编排是核心手艺 |
| 4 | 索引可在核内随意计算 | Tiling 参数须在主机侧算好传下去 | 分块方案是独立的设计工作 |
| 5 | 硬件调度延迟隐藏 | 开 DoubleBuffer 让搬运与计算重叠 | 这是第一档提速手段，几乎必做 |
一条硬约束值得单独记：统一缓冲（UB）容量有限（数百 KB 量级），分块必须满足 (输入缓冲 + 输出缓冲 + 中间变量) × 数据宽度 × 双缓冲系数 ≤ UB 容量。这个不等式决定了分块的上限，也是算子性能调优的核心旋钮。至于融合算子（矩阵单元输出喂向量单元、再喂回矩阵单元，典型如把矩阵乘 + 缩放 + 掩码 + softmax 融成 FlashAttention），是这一层最有价值也最难的活。
PyTorch 迁移的标准三步是：引入适配包 → 设备标识换名 → 设备相关 API 换名。官方提供了三条路径：自动迁移（引入一个转换模块，运行时把 CUDA 接口映射到 NPU，常见场景近乎零改动）、工具迁移（扫描脚本并产出算子支持情况与改动清单）、手工迁移。真正吃时间的是下面五类问题：
部分算子或部分用法没有原生实现，前向直接中断。对策按成本递增：等价组合改写 → CPU 回退（慢）→ 自己写 Ascend C 算子。迁移前先跑一遍算子支持性扫描，是最省时间的一步。
自动混合精度的实现逻辑与 CUDA 侧不同，梯度出问题未必立刻报错。实践口径：先跑通 FP32 → 再开混合精度 → 加梯度裁剪；优先 BF16 而非 FP16（第 5 章的动态范围原因）。
矩阵单元与向量单元偏好的数据排布不同（ND vs NZ 等），跨单元流动会自动插入格式转换算子——而它常常比矩阵乘本身还贵。profiling 里看到大片转换算子，就要提前统一格式或调整算子顺序。非连续张量同理会触发额外拷贝。
驱动/固件、CANN 工具包、框架适配包三者必须严格按官方配套表对齐（适配包版本号本身就编码了框架版本与 CANN 版本）。版本错配是"装不上、跑不起来"的第一大原因。
大模型并行直接用官方的 Megatron 适配套件（已适配张量/流水/序列并行与分布式优化器，并提供权重格式转换与全链路脚本），不要自己从零拼——这是过来人最一致的建议。
第 5 章解释了精度差异的物理原因，这里是把它变成可交付工作的方法论。主力工具是官方的精度调试套件（能力覆盖精度预检、溢出检测、精度比对、梯度监控，同时支持两大框架）。
注意第 ② 步的代价：开启确定性计算、同时关闭可能引入不确定性的融合与并行归约优化，通常会损失几个百分点的性能——所以它只在排查阶段开启，定稿后关闭。这也是"可复现"与"最快"之间的经典取舍。
工具链分四块：采集（命令行 profiler 同时采软件栈层与硬件层，框架侧也有对应的 profiler）；可视化（时间线视图，读四条泳道——算子执行、通信、调度下发、内存）；自动分析（把与对标平台的性能差距拆成算子执行 / 未被掩盖的通信 / 调度开销 / 内存四个维度，并能在集群规模上定位慢节点、慢卡、慢链路）；自动调优（分子图调优、算子调优、梯度切分调优三个引擎，官方推荐顺序是先子图后算子——因为子图切分确定后算子形状才最终确定）。
第 3 章讲过 host bound 的普遍原理，它在昇腾上格外常见：主机 CPU 要把算子逐个下发成任务到设备流，当设备执行快于主机下发时，时间线上出现大片"空闲"。对策有三层：开启任务队列流水下发；绑核（把下发线程绑定到固定的 CPU 核心，避免调度抖动）——官方案例把空闲占比从 18% 压到 0.38%；根治手段是模型下沉，把控制流、集合通信、计算整体下沉到设备侧执行，从根本上减少主机与设备的交互。这一条是国产卡调优里"投入产出比最高"的一类工作：不改模型、不改算法，只调执行方式，往往就能拿到两位数的提升。
通信库提供的原语与 NVIDIA 侧基本一一对应（全归约、广播、全收集、归约散射、全对全、点对点等），架构上分集合通信库与基础通信层两级。工程上有几个要点：通信域通过配置文件（含节点列表、设备、编号、IP）建立；关键环境变量控制通信缓冲区大小（默认值随版本变动，大消息与 MoE 全对全场景常需调大，但会吃显存）与各类超时；算法上实现了环形、网格、递归折半倍增等多种方案并自动选择，经验规则是机内走网格（全互联）、机间走递归折半或环形。
超节点改变了优化策略。当几百张卡通过总线语义互联、全局内存统一编址（官方口径包括数百 GB/s 级的卡间双向带宽、几十 TB 的统一编址内存、纳秒级单跳时延），第 4 章的那条铁律就松动了：可以用内存语义（直接读写远端显存）替代消息语义，专家并行域能开得更大，张量并行跨机不再是绝对禁区。这是国产路线"用互联规模弥补单卡差距"的核心逻辑，也解释了为什么它在通信占比高的 MoE 模型上收益最明显。
灵衢 2.0 与昇腾 950 的发布把这件事推得更远（技术细节见 1.5 节）。当高带宽域从 384 卡扩到 8,192 卡、共享地址空间达 128 TB、跨节点访存变成原生 Load/Store 指令时，优化工作的重心会发生四处迁移：①并行策略的搜索空间变大——张量并行与序列并行不再被单机卡数锁死，专家并行可以整体放进一个域，第 4 章的"TP ≤ 8"经验法则需要按实际高带宽域重新标定；②编程范式从"通信库调优"转向"共享内存编程"——需要掌握一致性与同步原语、按 die 分组的亲和性调度、以及本质上是超大规模 NUMA 的非均匀访存延迟，写"看起来像单机、实际是数千卡"的代码是一项新技能；③集合通信算法必须按拓扑重写——nD-Mesh、Clos、混合拓扑各有最优算法，且域内可用硬件集合通信引擎卸载、域间走以太扩展，分层算法的设计空间显著扩大；④算子优化多了几个新抓手——新增的 HiF8 数据格式需要配套的量化与校准策略（它不需要外挂缩放因子，量化思路与 MXFP8 不同），多维数据搬运引擎可以把手写的分块与转置代码下沉硬件，矩阵单元与向量单元之间的直连通路允许随路做精度与排布转换（这意味着融合算子的边界需要重新划分），而 128MB 的 L2 需要像写 CPU 缓存感知代码那样显式管理（可标注哪些数据留在 L2、哪些直写显存以免污染）。
MoE 场景的两项针对性优化值得记住：① 分发/合并的通算融合——把通信与计算在底层深度融合，减少数据搬运与排序次数；② 支持动态形状的全对全通信，以适配逐 token 变化的不等长负载。官方给出的口径是在数十卡以上规模部署大型 MoE 时启用这些优化可获得两位数百分比的性能提升。
| 通用方法（章节） | 在昇腾生态里的具体落点 | 难度与价值 |
|---|---|---|
| Roofline 诊断（第 2 章） | 用 profiler 时间线区分算子执行 / 通信 / 下发 / 内存四维 | 低难度、必做的第一步 |
| 算子融合（第 3、5 章） | 图融合 Pass + Ascend C 手写融合算子（含 FlashAttention 类） | 高难度、高价值——生态长尾的主要缺口 |
| 并行策略（第 4 章） | Megatron 适配套件 + 通信掩盖（把矩阵乘与集合通信拆细流水并发） | 中高难度，超节点下策略空间更大 |
| 混合精度（第 5 章） | 优先 BF16；FP8 支持取决于芯片代际，需确认硬件能力 | 中难度，代际相关 |
| MFU 提升（第 5 章） | 自动调优 + 手工算子调优 + 格式转换消除 + 绑核消 host bound | 最直接可量化的交付成果 |
| 长稳工程（第 6 章） | 集群分析工具定位慢卡慢链路 + 断点续训 + 故障隔离 | 中难度，见效最快 |
| 推理优化（第 7 章） | 推理引擎的昇腾适配版 + 缺失算子补齐 + 量化 + 大规模 EP 部署 | 高难度，直接决定单位 Token 成本 |
| RL 基础设施（第 8 章） | RL 框架的昇腾后端 + 训推一致（在双套数值实现上难度更高） | 最前沿、最稀缺 |
| 精度对齐（第 5、9 章） | 六步流程 + 官方精度工具套件 | 人力密集、最难替代，是信任的基石 |
这张表也是全文的收束：算力优化不是一项技术，而是一条从芯片微架构一直贯通到业务指标的完整链路。每一层都有可量化的浪费，也都有对应的手艺。而在国产硬件上，因为生态成熟度的差距，这些手艺的边际价值被放大了数倍——这既是工程难题，也是这个时代最确定的技术机会之一。
本文的全部素材来源。按"先读什么"排序，每条注明层级与推荐理由——这份清单本身就是一条完整的学习路径。
| 材料 | 层级 | 为什么先读它 |
|---|---|---|
| Making Deep Learning Go Brrrr From First Principles（Horace He） horace.io/brrr_intro.html | 入门 | 本领域最好的一篇入门文，没有第二候选。它给出一套分类学：任何 GPU 操作只属于三种状态——算力受限、带宽受限、开销受限；先判断自己在哪一类，才知道哪些优化有用。作者是 PyTorch 编译器方向的核心开发者。本文第 2 章的思维框架源于此。 |
| GPU Glossary（Modal） modal.com/gpu-glossary | 入门 | 按"设备硬件/设备软件/主机软件"分层的超链接术语表。被 SM、warp、CTA、cluster、SMEM 这堆缩写淹没时，这是解药。 |
| The Ultra-Scale Playbook（HuggingFace / nanotron） huggingface.co/spaces/nanotron/ultrascale-playbook | 入门→进阶 | 当前最好的一站式分布式训练教材，背后是 4,100+ 次实测实验。DP/TP/SP/CP/PP/ZeRO/重计算全覆盖，内嵌显存分解计算器与性能追踪。本文第 4、5 章的主要参照。 |
| How To Scale Your Model（Google DeepMind） jax-ml.github.io/scaling-book | 入门→进阶 | 从 Roofline 第一性原理讲起：什么时候被算力/带宽/通信卡住，如何据此选并行方案。与上一条互补——它教"为什么"，上一条教"怎么做"。其推理章节是第 7 章的教材级参照。 |
| AISystem / AIInfra 开源课程（ZOMI） infrasys-ai.github.io · GitHub · B 站 | 入门→高级 | 中文世界最系统的 AI 系统全栈课程：从 AI 芯片 → 编译器（CUDA 与 CANN 并讲）→ 推理引擎 → 分布式训练与集群通信，文稿、视频、PPT 全部开源，作者兼具昇腾与英伟达双栈背景。本文的章节结构与大量国产卡细节参照了这套课程，强烈建议作为长期精读教材。 |
| 材料 | 层级 | 推荐理由 |
|---|---|---|
| NVIDIA H100 架构白皮书 官方 Datasheet | 进阶 | 132 个 SM、989 TFLOPS BF16、3.35 TB/s HBM3 等规格的唯一权威出处。避坑：官方表里带星号的算力是"带稀疏"数字，稠密要对折——市面上一半的对比文章在拿稀疏比别人的稠密。 |
| AI and Memory Wall（Gholami et al., IEEE Micro） arXiv:2403.14123 | 论文 | 内存墙唯一该引的量化来源：过去 20 年峰值算力每两年 3.0×，而 DRAM 带宽仅 1.6×、互联带宽 1.4×；累计算力涨 60,000×，DRAM 只涨 100×。这解释了 Roofline 拐点为什么一路右移。 |
| Roofline: An Insightful Visual Performance Model（Williams et al., CACM 2009） dl.acm.org | 论文 | 一切性能分析的公共语言。原文里最精髓、二手介绍几乎都漏掉的是 "ceilings"（天花板）那一节：在屋顶下再画若干条线，每条对应一项具体优化，于是 Roofline 从诊断工具升级成优化路线图。 |
| How to Optimize a CUDA Matmul Kernel（Simon Boehm） siboehm.com | 进阶 | 最好的"动手"材料：从只有 cuBLAS 性能 1.3% 的朴素 kernel 出发，逐步做访存合并 → 共享内存分块 → warp tiling → 向量化，最终达到 cuBLAS 的 83.2%。把第 1 章的内存层级理论变成肌肉记忆的最短路径。 |
| Benchmarking and Dissecting the Nvidia Hopper GPU Architecture arXiv:2402.13499 | 论文 | 白皮书不会告诉你的东西：各级存储的实测延迟与带宽（共享内存约 30–40 周期、L2 约 200–300、HBM 约 500–700）。 |
| In-Datacenter Performance Analysis of a TPU（Jouppi et al., ISCA 2017） dl.acm.org | 论文 | 脉动阵列的奠基之作：256×256 = 65,536 个 MAC、92 TOPS、28 MiB 软件管理的片上缓冲、能效比同期 CPU/GPU 高 30–80×。理解 DSA 路线必读。 |
| A New Golden Age for Computer Architecture（Hennessy & Patterson，图灵奖演讲） cacm.acm.org | 论文 | 为什么后摩尔时代的出路是领域专用架构（DSA）——第 1.4 节的理论框架。 |
| Colfax CUTLASS 教程：Hopper WGMMA research.colfax-intl.com | 进阶 | 异步 warpgroup 矩阵乘讲到能动手的程度，是公开材料里离生产级 kernel 最近的一套。 |
| Chips and Cheese: H100 的 L2 有多"funny" chipsandcheese.com | 进阶 | 50MB 的 L2 分成两个 partition 带来的非均匀延迟——官方永远不会写这种事。 |
| 材料 | 层级 | 推荐理由 |
|---|---|---|
| Megatron-LM（张量并行原始定义） arXiv:1909.08053 + PTD-P 3D 并行 arXiv:2104.04473 | 论文 | 第一篇定义了 MLP 列切→行切、注意力按头切的经典方案（每层前反向各一次 all-reduce）；第二篇是 3D 并行组合原则的奠基之作，含 1T 参数 / 3,072 张 A100 / 502 PFLOP/s（峰值 52%）的实证。第 4 章的主要来源。 |
| ZeRO arXiv:1910.02054 | 论文 | 16 字节/参数的显存拆解、三阶段切分、通信量推导（阶段 1/2 通信量不变，阶段 3 才付 1.5× 代价）全在第 5–7 节，教科书级。 |
| Reducing Activation Recomputation in Large Transformer Models arXiv:2205.05198 | 论文 | 序列并行 + 选择性重计算。激活显存的精确公式 s·b·h·(34 + 5as/h) 出自此文；实证：激活显存降 5×、重计算开销降 90%+、530B 模型 MFU 从 42.1% 提到 54.2%。 |
| FlashAttention 三部曲 FA1 → FA2 → FA3 | 论文 | 一条完整的"算法—实现—架构"演进线，也是本文第 5.3 节的核心案例。数字：FA2 在 A100 上达 225 TFLOPS（MFU 72%）；FA3 在 H100 上 FP16 达 740 TFLOPS（75% 利用率）、FP8 接近 1.2 PFLOPS。关键洞察：三代都不减少 FLOPs，只减少访存。 |
| The Llama 3 Herd of Models arXiv:2407.21783 | 论文 | 唯一公开披露万卡级故障统计的前沿模型报告：16K H100、54 天、466 次中断（419 次意外，其中约 78% 归因硬件）、有效训练时间 >90%、4D 并行配置、MFU 38–43%。第 6 章的全部数据来源。 |
| Machine Learning Engineering（Stas Bekman，开源书） github.com/stas00/ml-engineering | 入门→进阶 | 训练工程师的"运维手册"：网络吞吐实测方法、MFU 计算脚本、慢节点定位、loss 尖刺处置、checkpoint 策略。全是能直接复制粘贴的命令，来自 BLOOM-176B 的一线经验。 |
| DeepSeek-V3 技术报告 arXiv:2412.19437 | 论文 | 大规模 FP8 训练的第一份完整工程记录：统一用 E4M3 格式、激活按 1×128 分块 / 权重按 128×128 分块量化、沿 K 维每 128 个元素搬到 FP32 寄存器累加、以及保留高精度的"精度孤岛"清单（embedding、输出头、门控、归一化、注意力）。结果：与 BF16 相比 loss 相对误差 <0.25%。 |
| MegaScale（字节，NSDI'24） arXiv:2402.15627 | 论文 | 12,288 张 GPU 训练 175B 模型做到 MFU 55.2%（比 Megatron-LM 高 1.34×），并逐项拆解每个优化贡献多少——其中"通信与计算重叠"单项就贡献了 +6.2% MFU。工业界全栈调优的标杆样本。 |
| Mixed Precision Training（ICLR'18） arXiv:1710.03740 | 论文 | FP32 主权重 + loss scaling + FP32 累加"三件套"的原始出处，也是理解"为什么 BF16 能免掉 loss scaling"的对照组。 |
| Ring Attention arXiv:2310.01889 · Zero Bubble PP arXiv:2401.10241 | 论文 | 前者是上下文并行的理论基础（序列长度随设备数线性扩展、精确无近似）；后者证明流水线气泡公式并非不可逾越——把反向拆成"对输入求梯度"与"对权重求梯度"两半去填气泡，同显存下比 1F1B 快 23%。 |
| Transformer Math 101（EleutherAI） blog.eleuther.ai | 入门 | 最快建立"参数量↔显存↔算力↔时间"数量级直觉的短文，配套 cookbook 里有现成的计算脚本。 |
| 材料 | 层级 | 推荐理由 |
|---|---|---|
| Transformer Inference Arithmetic（kipply） kipp.ly | 入门 | 推理算术的圣经。每 token 2N FLOPs、KV Cache 公式、算力受限与带宽受限的边界，全靠纸笔推导，无实验无难数学。所有后续论文的记账方式都源于这里。第 7.1 节的方法来源。 |
| LLM inference speed of light（zeux） zeux.io | 入门 | 一篇讲清"速度上限 = 带宽 ÷ 每 token 字节数"，并指出实测通常只有理论值的 50–80%（剩下被读 KV、kernel 启动、采样、通信吃掉）。给单请求性能定基线时最该引的一篇。 |
| Orca（OSDI'22） usenix.org | 论文 | 连续批处理的原始出处：迭代级调度 + 选择性批处理（注意力必须逐请求算、其余算子可合批——这解释了为什么它不是一行代码的事）。GPT-3 175B 上同延迟下吞吐提升 36.9×。 |
| vLLM / PagedAttention（SOSP'23） arXiv:2309.06180 | 论文 | 定义了现代推理引擎的显存管理范式。硬数据：既有系统的 KV 显存利用率只有 20.4%–38.2%（即浪费 60–80%），vLLM 降到 <4%，吞吐提升 2–4×。第 7.3 节的来源。 |
| SGLang / RadixAttention（NeurIPS'24） arXiv:2312.07104 | 论文 | 前缀复用的标准答案：基数树 + LRU 淘汰 + 引用计数 + 缓存感知调度（主动把共享前缀的请求排到一起，而不是被动等命中）。最高 6.4× 吞吐。 |
| Sarathi-Serve（OSDI'24） arXiv:2403.02310 | 论文 | 解决连续批处理引入的新问题——长 prefill 插进来会卡住所有正在解码的请求。方案是分块预填充（chunked prefill），把 prefill 切成等大块与 decode 拼成均匀批次。chunk 大小的选择正好回到 Roofline：512–2048 最合适——大到能让 prefill 算力受限，小到不会卡住 decode。 |
| DistServe（OSDI'24） arXiv:2401.09670 · Mooncake（FAST'25 最佳论文） arXiv:2407.00079 | 论文 | PD 分离的两篇代表作。前者首次把 goodput（同时满足首字与逐字延迟约束下的每秒请求数）立为优化目标；后者是 Kimi 的生产平台，进一步把 KV Cache 本身做成分布式池（"用更多存储换更少计算"），真实部署中多处理 107%–115% 的请求。 |
| Beyond the Buzz（NVIDIA） arXiv:2506.05508 | 论文 | 必读的冷水一杯：扫了几十万个设计点后发现，PD 分离只在 prefill 密集的流量和更大的模型上明显赢；真正决定成败的是两池比例的动态匹配与弹性伸缩。与上一条配着读，避免把架构当银弹。 |
| GQA arXiv:2305.13245 · DeepSeek-V2 MLA arXiv:2405.04434 | 论文 | KV 压缩的两代答案。GQA 的工程贡献是"用原预训练 5% 的算力就能把 MHA 模型转成 GQA"；MLA 用低秩联合压缩把 KV 砍掉 93.3% 且效果不降——一个 671B 的 MoE 模型，每 token 的 KV 比 70B 稠密模型还小数倍。 |
| 量化三件套：GPTQ · AWQ · SmoothQuant | 论文 | 三篇读完，量化谱系的分歧点全清楚：GPTQ 用二阶信息补偿误差；AWQ 发现"重要性要看激活分布而非权重大小"并用等价变换避免混合精度的硬件低效；SmoothQuant 把激活的离群值难度"平滑"迁移到权重上，从而能用 W8A8 整数张量核。 |
| vLLM: FP8 KV Cache 实测（2026-04） vllm.ai/blog | 进阶 | 本文最重要的一记警钟：FP8 KV 让逐字延迟改善 20–29%，但同一份分析里，128K 长文检索任务的准确率从 BF16 的 91% 掉到 13%（累加精度不足）。"短 benchmark 上无损"的配置可能在长上下文任务上崩掉——量化必须带长上下文评测。 |
| 投机解码三代：原始论文 · Medusa · EAGLE-3 | 论文 | 第一篇给出接受率与加速比的解析公式并证明输出分布完全无损；Medusa 去掉独立草稿模型（挂多个解码头，2.2–3.6×）；EAGLE-3 靠特征融合突破 scaling 天花板（温度 0 下 4.1–6.5×），现已是主流引擎的标配选项。 |
| LMSYS：96×H100 上的大规模 EP 部署 lmsys.org/blog | 进阶 | MoE serving 的当前最优实践公开复现：PD 分离 + 大规模专家并行 + 专家负载均衡全套，做到 0.2 美元/百万输出 token，约为官方 API 定价的五分之一。第 7.8 节的来源。 |
| 材料 | 层级 | 推荐理由 |
|---|---|---|
| HybridFlow / veRL（EuroSys'25） arXiv:2409.19256 · GitHub | 论文 | RL 系统设计的枢纽论文：上层数据流用单控制器、下层分布式计算用多控制器/SPMD；3D-HybridEngine 解决训练与生成两种并行布局之间的重分片且零显存冗余。工程红利：改一处资源池映射就能在共置与分离间切换。 |
| AReaL arXiv:2505.24298 | 论文 | 完全异步 RL 的代表：可中断的 rollout（权重更新时打断正在进行的生成）+ 解耦的 PPO 目标（处理来自多个历史策略版本的混合数据），相对同步系统最高约 2.8× 加速。 |
| slime（智谱） GitHub · LMSYS 博客 | 进阶 | 把多轮工具调用与沙箱交互当作"数据生成工作流"接进同一循环——面向 Agent 与长轨迹的设计范本，也是 GLM 系列背后的 RL 框架。 |
| Defeating Nondeterminism in LLM Inference（Thinking Machines） thinkingmachines.ai | 进阶 | 训推一致问题的根因分析：归一化、矩阵乘、注意力这三类算子的数值结果依赖 batch size（不同批量改变归约切分），解法是让 kernel 使用与批量无关的单一归约策略。配 SGLang 确定性推理 看工程落地。第 8.4 节的来源。 |
| Keep the Tokens Flowing（HuggingFace） huggingface.co/blog | 进阶 | 横向比较 16 个开源 RL 库的异步化实现，是 8.3 节三种异步手法的最佳综述。 |
| Kimi k1.5 arXiv:2501.12599 | 论文 | 部分 rollout（给轨迹设 token 预算、未完成的存回缓冲下轮续跑）的经典出处，解决长思维链的资源独占问题。 |
这一节是中文读者的主场。国产卡的一手资料几乎全部只有中文，且质量参差——下面这些是经过筛选的。
| 材料 | 层级 | 推荐理由 |
|---|---|---|
| ArthurChiao GPU 进阶笔记系列（四篇） （一）硬件拓扑与集群组网 · （二）昇腾 910B · （三）华为 NPU/GPU 演进 · （四）GH200 与集群 | 入门→进阶 | 中文里把硬件拓扑 + 集群组网 + 国产 NPU 三件事讲得最系统的一组笔记。第（二）篇是少见的以"对标英伟达视角"梳理昇腾规格与互联的第三方分析。另有《大模型推理的极限》译文，是第 7 章思维模型的中文入口。 |
| 猛猿：图解大模型系列（知乎） 张量并行 TP · Megatron 源码解读 · MoE 并行训练 · PagedAttention 原理 | 入门→高级 | 中文并行训练教学的事实标准，图讲得比论文清楚。从张量并行原理一路到 Megatron 逐行源码、MoE 四维分组策略、vLLM 源码解析，是中文读者绕过英文论文门槛的最短路径。 |
| 苏剑林「科学空间」 从熵不变性看 Attention 的 Scale · 低精度 Attention 的有偏舍入误差 | 高级 | 中文世界最硬核的算法数学博客。第二篇尤其推荐：把"低精度 Transformer 训练为何失败"归因到舍入偏置，是第 5.2 节数值稳定性话题的最佳中文深度阅读。 |
| OneFlow CUDA 优化系列 高效 Softmax kernel · LayerNorm 性能优化 | 进阶 | "分档特化"这一优化范式的教科书案例：按列数分三档策略（warp 级 / block+共享内存 / block 无共享内存）。理解第 3.2 节"为什么归一化类算子是带宽瓶颈"的最佳实操材料。 |
| 深入浅出 GPU 优化系列 reduce 优化 · GEMM 优化 · 配套代码 | 进阶 | 7 版 reduce 迭代到 95% 带宽利用率——"优化是怎么一步步逼近硬件上限"的中文范本，配可编译可跑的代码。进阶可看 LeetCUDA（200+ kernel，HGEMM 打到 cuBLAS 98–100%）。 |
| 昇腾官方文档 Ascend C 硬件基本架构 · CANN 开源仓库（gitcode） · torch_npu · 精度与性能工具 mstt | 进阶 | 达芬奇架构的 Cube/Vector/Scalar 与 L0/L1/UB 缓冲、MTE 搬运引擎的一手中文来源。2026 年重要变化：代码样例已从 gitee 迁往 gitcode，算子库拆成独立仓库开源——大量中文教程仍在引旧路径。分布式训练用 MindSpeed-LLM，不要自己糊。 |
| 昇腾 950 NPU 架构白皮书（华为，2026-06，40 页） 官方 PDF | 进阶 | 本文第 1.5 节的主要来源，强烈建议原文精读。它给出了媒体几乎从未完整报道的东西：逐精度算力表（含各裁剪档位）、完整的内存层级表、HiF8 编码格式的定义（变长前缀码如何实现 38 个阶码且无需外挂缩放因子）、互联规格（72 Lane SerDes / 18 端口 / 2TB/s）、以及内存 RAS 机制。注意口径：正文全程只称"高速片上内存"，不含 HiBL/HiZQ 等发布会用名，也没有功耗与制程数字。 |
| 灵衢（UnifiedBus）2.0 技术规范 官方文档仓库 · 发布会 keynote | 进阶 | 包含《灵衢基础规范 2.0》《固件规范》《操作系统参考设计》《基于灵衢的超节点参考架构白皮书》及八份关键技术分册（内存池化、设备虚拟化、超节点可靠性、编程编译等）。最值得读的是双语义设计：内存语义（Load/Store/Atomic 直达对端内存，无应用层干预）与消息语义（队列 + Doorbell）如何共存，以及集合通信如何硬件卸载。物理层到事务层规范全部公开，是理解"国产超节点路线"的一手材料。 |
| DeepSeek-V3 中文深度解读 Infra & 硬件篇 | 进阶 | FP8 训练、DualPipe 消气泡、无辅助损失负载均衡、免张量并行的显存优化——"用工程换算力"的最佳单一案例，也是国产团队在受限硬件条件下做系统创新的范本。 |
| 微软亚洲研究院 AI-System GitHub | 入门→进阶 | 学术味最正的中文系统教材（已出版《深度学习系统设计》），三段式结构：基础全景 / 前沿科研 / 配套实验。与 A.1 的 ZOMI 课程互补。 |
这一节比它看起来重要。技术讨论里大量的"数据打架"，根源都是口径不一致。
序列长度 ÷ (6 × 隐藏维度)——序列越长越不可忽略（8K 序列、8K 隐藏维度时约 17%）。MoE 模型要用激活参数量而非总参数量。为了让读者能复算，以下推导在正文中都给出了公式与中间步骤，但它们是基于公开规格的计算结果，而非某篇文献的原文数字：Roofline 拐点（989 ÷ 3.35 ≈ 295 FLOPs/Byte）；方阵矩阵乘越过拐点所需边长（约 900）；各类算子的算术强度（逐元素 0.25、朴素注意力约 d/2、FlashAttention 约 S/2）；70B 模型的单请求解码速度上限（约 24 token/s）与 KV Cache 占用（320 KB/token、128K 上下文约 40 GB）；训练时间算例（70B × 15T token、1 万卡、MFU 40% → 约 18 天）。如果你的实测与这些推算差很多，先检查前提假设，而不是怀疑物理定律。
数据配比、去重、清洗、合成数据——对模型效果的影响往往超过算力优化，但属于算法与数据侧，不在本文范围。
供配电（12V→48V→垂直供电）、液冷与风冷、机柜密度、选址与电价、光模块与链路洁净度——万卡集群里这些是真实的工程主战场，值得单独一份文档。
Kubernetes/Slurm 混合调度、GPU 虚拟化与切分、多租户隔离、作业排队与碎片治理——利用率的另一半答案在这里。
线性注意力、状态空间模型、稀疏注意力、混合架构——从算法侧降低算力需求，是与工程优化并行的另一条路。
本文为内部学习材料，基于截至 2026 年 8 月的公开资料编写。技术演进极快，其中的具体数字（尤其芯片规格、框架版本、价格）会迅速过时；但第 2 章的 Roofline 思维、第 4 章的通信量分析、第 5 章的显存账本、第 7 章的推理算术这四套方法论不会过时——硬件换代之后，把新数字代进同样的公式即可。