四个值得学习的开源工作#

1. OpenLM Research 2B（清华）：提供了一套全流程的模型训练 recipe，包括数据处理、使用的数据集等均已开源。

2. Megatron（NVIDIA）：已成为行业标准的训练框架。NVIDIA 的核心目的是展示”按这个方式训练能收敛”，从而推动硬件销售。虽然 Megatron 并不以训出最优模型为目标，但在强大算力和数据的加持下表现依然不错，且其数据集资源非常充足。

3. OLMo（AI2）：一篇超强的消融实验论文。在四个训练阶段中训练了超过 140 个 1B 和 4B 参数规模的模型，并开源了所有 take-away。

4. Playbook：长达数百页的完整训练指南（推荐阅读时长 2-4 天）。其最大价值在于不仅介绍了成功的设计决策，更记录了失败的探索——大多数论文只展示”我的 design 是什么样的”，而这份 Playbook 解释了”为什么要做这些 design”。

不要直接照搬 Take-away#

一个关键提醒：上述工作的 take-away 不能直接拿来用。不同工作的数据量、数据类型、不同领域的数据配比、混合数据的配方、训练超参数等背景差距巨大。例如 OLMo 发现 80-160 倍的数据做 Pre-train 就已经”学的差不多了”，再多不会带来显著提升——但实际上各大厂商的训练数据量远超这个范围，且确实训出了更好的模型。

Benchmark 的矛盾#

Evaluation 和 Benchmark 存在一个”矛与盾”的问题：只要给出一个 benchmark，就有办法刷榜刷到它失去意义。但在持续训练模型的过程中，又确实需要某些指标来 indicate 训练过程和效果是否良好。这是一个尚未解决的行业难题。

Infrastructure 是训练效率的重要部分，但数据工程和训练 recipe 的实践经验同样是训练成功的关键。各家模型厂商的高质量数据和 Data Engineering 方案是各自的核心竞争力，通常不会完全开源。

Transformer 的两大基石#

这篇论文提出了两个至关重要的概念：

1. Encoder-Decoder 结构：输入端为 Encoder，输出端为 Decoder，两者是完全独立的结构。后续的探索将其分化为 Encoder-only（如 BERT）和 Decoder-only（如 GPT）两大路线。

2. Attention 机制：经典的 QKV 注意力公式：

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

论文中的实现方式是 Multi-Head Attention（MHA），虽然这是一个相对原始的实现（后续会被迭代优化），但它奠定了整个领域的计算范式。

GPT vs BERT：路线之争#

从 2017 年到 2020 年，模型结构路线经历了一段有趣的竞争历史——OpenAI 的 GPT 系列与 Google 的 BERT 之间几乎每隔四个月就交替发布新版本。

在 GPT-2 之前，GPT 的表现并没有比 BERT 好上很多，且 BERT 的资源需求更少，因此学术界和工业界更倾向于使用 BERT。

转折点出现在 2020 年 5 月的 GPT-3。论文 “Language Models are Few-Shot Learners” 使用了 175B 参数和大约 100 倍于前代的数据，以”大力出奇迹”的方式彻底杀死了这场竞赛。自 2020 年起，业界掀起了疯狂堆叠参数量和数据量以追求涌现效果的浪潮。

Scaling 的代价#

大力出奇迹带来了三重 scaling 的复杂度：

• 模型参数量越来越大
• 训练数据量越来越大
• 上下文长度（Context Length）也越来越长——从 4K 到 32K、128K 再到 1M

这三者是乘法关系，对算力和资源的需求呈相乘式增长。因此，要在可控的时间里将大模型训到收敛，不可避免地需要做软硬件的 Co-design：既需要拥抱更强更新的硬件，又需要对训练框架做细致的优化——后者能直接帮助省钱省电费，因此各方动力十足。

GPipe 的思想#

GPipe 的思想极其简单：将模型按层切开，放在不同的 GPU（Device）上，算出来的中间结果通过通信传到下一个 Device。这个思想非常类似 CPU 从单周期执行到流水线执行的演进。

但肉眼可见的巨大问题是 气泡（Bubble）——同一时刻只有一个 Device 在工作，其他 Device 都在等待。PP 最大的两个问题是：

1. Bubble 带来的性能损耗如何降低（挤气泡）
2. Forward 完成后、Backward 之前的 Activation 如何管理

Micro-Batch 与气泡优化#

通过引入 Micro-Batch 可以降低 Bubble 的占比——将一个大 batch 切成多个小 micro-batch，让不同 Device 交错处理不同的 micro-batch。经典的同期工作 PipeDream（1F1B 策略）进一步将 Forward 和 Backward 交织在一起执行，在降低气泡的同时还减少了峰值显存占用（见图2右下角）。

后续还有 DeepSeek 的 DuoPipe，将 Expert Parallel 中的 All-to-All 通信与流水线调度做重叠（overlapping），实现更细粒度的挤气泡。其思想可以概括为”三板斧”：切更细的 micro-batch、交错 forward/backward、与通信做 overlap。

Activation Recomputation#

当显存紧张时，Forward 阶段计算出的 Activation 不能一直保留到 Backward，否则容易 OOM。最简单的做法是全部丢弃、全部重算（Full Recomputation）——等 Backward 传回来时，重做一次 Forward 拿到当时的 Activation。但这需要付出额外的计算代价。

因此，如何精细地选择最少的 Recomputation 比例来达到最好的显存/计算平衡，是一个重要的优化问题。2022 年的一项工作专门研究了 Sequence Parallel 维度下的精细重计算策略——全部扔掉意味着最大计算代价，全部保留意味着最大显存代价，而最优解在两者之间。

Tensor Parallelism（TP）#

Megatron-LM 论文中最初称之为 Model Parallelism，但后来被统一称为 Tensor Parallel（TP）。其核心思想是对 Transformer 中的 MLP 层和 Self-Attention 层做 tensor 维度的并行。

理解 TP 的关键在于两个算子 $f$ 和 $g$：

• $f$：Forward 时是 Identity（什么都不做），Backward 时做 AllReduce
• $g$：Forward 时做 AllReduce，Backward 时是 Identity

这是一个非常自然的设计。因为正向和反向传播时需要 transpose，到底是做 concatenate 还是做求和，取决于矩阵是横着切还是竖着切。

MLP 层的切分策略：对权重矩阵 A 采用按列切割，对权重矩阵 B 采用按行切割。为什么不对 A 用按行切？因为中间的 GELU 是非线性函数，$\text{GELU}(A_1 + A_2) \neq \text{GELU}(A_1) + \text{GELU}(A_2)$——它不满足分配律。如果按行切 A，就必须在进 GELU 之前多做一次 AllReduce 来聚合结果，这会引入额外的通信开销。而按列切 A 时，各个分片可以独立过 GELU，之后在 B 层用 AllReduce 合并即可。

Attention 层：天生契合 Multi-Head Attention 的设计——对 Q、K、V 三个参数矩阵按列切割，每个 head 放到一块 GPU 上做并行计算。切割方式与 MLP 层基本一致。实际应用中，并不一定是一个 head 占一块 GPU，也可以多个 head 占一块 GPU，但需要保证 head 总数能被 GPU 数量整除（通常直接用 assert 做特判）。

Sequence Parallelism（SP）#

SP 可以理解为 TP 的免费午餐。在只开 TP 的情况下，所有 GPU 都要各自做一遍相同的 LayerNorm、Dropout、残差加法等操作——这些是每个 GPU 独立重复做的”串行部分”。一个自然的想法是：能不能每个 GPU 只做一部分，需要的时候再聚合？答案是可以的，这就是 Sequence Parallelism。

SP 将原先 TP 后的 AllReduce 拆解为 Reduce-Scatter + AllGather：

• $g$ 在 Forward 时变成 AllGather，Backward 时变成 Reduce-Scatter

这样把原来的串行部分也并行化了，最大的好处是可以减少 Activation 的显存占用。

SP vs CP 的区分#

一个经常让初学者困惑的点：Sequence Parallel（SP） 和 Context Parallel（CP） 是不同的概念。这是 Megatron 团队刻意做的区分——SP 是和 TP 搭配使用的，它们一起开启；而 CP（Context Parallel）才是处理超长上下文（如 128K、1M token）时的并行方式。虽然大家日常说 Sequence Length 或 Context Length 时不做区分，但对应的并行策略是不同的。

本次讲座刻意略去了 CP 的详细介绍，但值得强调的是：在 Agent 时代和 Reasoning 时代，长上下文的需求越来越大，CP 是一个非常值得深入学习的方向。

从矩阵运算的角度看，TP 的本质就是高维矩阵乘的分块计算：如果分块之间需要求和，就做 AllReduce；如果分块之间可以直接 concatenate，就做 AllGather。

为什么需要 ZeRO#

在做模型训练时，有三个非常大的显存占用项：

1. Optimizer States（最大）：以 Adam/AdamW 为例，需要存储 FP32 的一阶动量（Momentum）、二阶动量（Variance）和 FP32 的 Parameters 副本。仅 Optimizer 状态就占了总显存的大头。（值得关注的是，最近特别火的 Moon 优化器也在这一领域做了探索，但在 Moon 之前，Adam/AdamW 仍是主流选择。）

2. Gradients：反向传播过程中产生的梯度。

3. Parameters（模型权重）

一个容易混淆的点是：实际上存在两份 Parameters——Optimizer 内部保存一份 FP32 的 Parameters（用于精确更新），最终使用的 FP16 Parameters 是从 FP32 版本 cast 过去的。这解释了为什么用了更低精度的 Parameters 做计算，显存占用反而更大——因为需要额外维护 FP32 版本。

对于 Non-distributed 的 Adam 优化器，需要存储的数据量约为模型参数的 12 倍（FP32 Parameters × 4 bytes + FP32 Momentum × 4 bytes + FP32 Variance × 4 bytes = 12Ψ bytes，其中 Ψ 为参数量）。

ZeRO 的三个阶段#

ZeRO（Zero Redundancy Optimizer）将上述三项进行分布式切分：

• ZeRO-1（$P_{os}$）：分布式 Optimizer States——每个 GPU 只保存自己负责的那部分 Optimizer 状态
• ZeRO-2（$P_{os+g}$）：在 ZeRO-1 基础上，进一步分布式 Gradients
• ZeRO-3（$P_{os+g+p}$）：在 ZeRO-2 基础上，进一步分布式 Parameters（即 FSDP）

原理很直观：每个 GPU 的 Optimizer 只产生自己负责的那部分 Gradient，用这部分 Gradient 更新自己负责的那部分 Weight，等到需要全部 Weight 的时候，用 AllGather 把所有人的 Weight 聚合到一起。

从图5可以看出效果：以 K=12（Adam）、Ψ=7.5B、$N_d$=64 为例，Baseline 需要 120GB 显存，ZeRO-1 降到 31.4GB，ZeRO-2 降到 16.6GB，ZeRO-3 降到 1.9GB。

通信换显存的本质#

这就是”通信换显存”的核心思想——通过在需要全量数据时做 AllGather 通信来获取，降低了峰值显存占用。对于会 OOM 的场景，这是一个非常必要的优化；如果不 OOM，则需要权衡通信代价是否值得。

ZeRO 系列还有 ZeRO-Offloading（将 Optimizer 状态卸载到 CPU 内存）和 ZeRO-Infinity（进一步卸载到 NVMe SSD）等扩展。DeepSpeed 的这些工作后来也被集成到了 Megatron 框架中。

从整体来看，DeepSpeed ZeRO 最出圈的贡献就是这套数据并行的思想——它让原本因显存不足而无法训练的大模型变得可训练。

为什么需要 MoE#

2020 年 GPT-3 之后，各大公司开始疯狂堆叠稠密模型的参数量。但随着 scaling 推进到 2022-2023 年，暴露了两个巨大的问题：

1. 训不动：FFN 层特别大，需要巨大的计算量做 GEMM，但投入的算力却没有带来预期的表现提升。
2. 推不动：一个 405B 参数量（如 Llama 3.1）的稠密模型，推理性能非常差。

Sparse FFN 的核心思想#

Mixture of Experts（MoE）本质上是将稠密的 FFN（Fully Connected Layer）替换为 Sparse FFN。以四个 Expert 的场景为例，对于每个 token，只激活其中一个或几个 Expert，未被激活的 Expert 不参与计算——这意味着计算量可以降低到原来的 1/k（k 为 Expert 总数与激活数的比值）。

MoE Layer 由两部分组成：

• Router：一个线性层加 Softmax，输出每个 Expert 的得分，然后做 Top-K 选出要激活的 Expert
• 多个 Expert：每个 Expert 本质上就是一个独立的 FFN

有人认为把 MoE Layer 叫做 Sparse FFN 更有助于理解——这确实更直觉：原来是一个全连接的 FFN，现在变成了稀疏激活的 FFN。

训练的挑战#

MoE 的思想虽然简单（Top-K 选完就结束了），但挑战才刚刚开始。据传 Llama 3.1 也训过 MoE 结构的模型，但没有训收敛，最终 release 的还是稠密模型。直到 2024 年底 DeepSeek 成功训出了 MoE 模型且表现出色——用较低的训练成本获得了性能 OK 的模型，且推理成本降低了一到两个数量级——才让 MoE 真正火爆出圈。

训练中的核心挑战包括：

• Load Balancing：如果某些 Expert 一直不被激活，就一直得不到训练。需要通过设计辅助损失（Auxiliary Loss）、设置 Expert 负载上限、引入 Random Routing 强制激活部分 Expert 等手段来解决。
• 结构探索：包括 Shared Expert（无论如何都要过的公共 Expert）、DeepSeek-V3 提出的 Latent MoE 结构等，探索仍在不断推进。

Expert Parallelism#

Expert Parallel（EP）的思想更加 trivial：不同的 Expert 放在不同的 GPU 上，token 来了需要 route 到哪个 Expert，就把 token 发过去，算完再发回来。从整体流程来看，这变成了一个负载不太均衡的类 All-to-All 通信原语。

但传统的集合通信库（如 NCCL）面对的场景与 EP 所需的场景并不完全一致——All-to-All 要求规整的通信模式，而 EP 的通信量是动态不均衡的。为此，DeepSeek 开源了 DeepGEMM 和 DeepEP 两个工作来优化这个场景。DeepEP 绑定了 H800 集群和 Mellanox（ConnectX）网卡，通过牺牲通用性换取极致性能——在高性能场景下这是完全合理的。

各种 Parallel 的统一目标#

所有 Parallel 策略（PP、TP、SP、DP、EP）的宗旨只有一条：分布式执行后的表现，至少在算法层面上要和在单机上执行是一样的。 作为 infra 工程师，改了算法本身是不被允许的——必须保证算法不变，只做计算和通信的拆分与优化。

其中关于精度有一个微妙的问题：浮点数的加法没有结合律，改变 Reduce 的顺序可能真的会对收敛性和最终表现造成影响。虽然这个问题过于工程细节，但需要意识到：即使没有改动算法，分布式后仍可能出现精度问题。

关于通信实现，RDMA 和 NVLink 分别对应节点间和节点内的通信路径，追求 High Throughput 还是 Low Latency 会有两套不同的实现方式——不同场景下的操作完全不同，不存在”一次实现到处跑且性能都好”的方案。

Flash Attention：充分利用 Memory Hierarchy#

Flash Attention 的核心思路是：不做任何算法上的近似，只充分利用 GPU 的 memory hierarchy 来加速 Attention 计算。

好处在于理论上对精度没有任何影响。坏处在于它是跟着硬件走的——硬件更新时实现也要更新一版，但在当前这版硬件上，目标是达到接近极限的性能。

超长上下文的四条路线#

对于超长上下文（Context Length 从 4K → 32K → 128K → 1M），标准 Attention 的计算复杂度是 $O(n^2)$。当 $n$ 足够大时，Attention 的开销会远超 FFN（FFN 是线性的），成为明显的 bottleneck。

优化 Attention 的四条路线：

路线一：量化（Quantization）

利用低精度计算单元做 Attention。代表工作是 SageAttention 系列，通过 FP8/INT8 等低精度的矩阵乘来加速 Attention 计算。

路线二：压缩（Compact）

核心思想是利用子空间或隐空间降低计算量。有两条经典路径：

• GQA（Grouped Query Attention）/ 矩阵吸收：将 KV 的 head 数量减少，多个 Query head 共享同一组 KV
• Latent Attention：映射到一个隐空间做计算，完成后再映射回去。DeepSeek-V2 提出的 MLA（Multi-head Latent Attention）是这条路径的代表

虽然术语不同，但思想上都是”先映射到一个更小的空间做事，做完再映射回来”，从而降低过程中的计算量。

路线三：Sparse Attention

不计算完整的 $n \times n$ Attention 矩阵，只计算其中重要的部分。DeepSeek 开源的 NSA（Native Sparse Attention） 是一个值得学习的工作——如果想学写算子，它的核心就是 Top-K 操作。这类工作需要同时满足精度可控、性能优越、并具备创新性。

路线四：Linear Attention

从根本上改变 Attention 的计算复杂度，从 $O(n^2)$ 降到 $O(n)$。代表工作包括：

• DeltaNet / KDA（KIMI/月之暗面开源）
• Mamba 系列和 RWKV 系列（RNN 时代就有的工作）

Linear Attention 的目标是在保持模型表达能力的同时，将 Attention 的计算开销从平方级降到线性级。

Attention 结构的组合探索#

各种 Attention 结构的工作实在太多，甚至可以做 Attention 块的排列组合——比如 NVIDIA 的 Nemotron 系列中，将 Linear Attention Block、Standard Attention Block、以及不同的 FFN Block 像搭积木一样组合，从算法上完全可行，只是探索空间指数级爆炸。听涛写了一个不错的 survey，涵盖了分布式 Attention 和各种 Attention 算子的设计。

为什么追求低精度#

使用低精度的 GEMM 运算可以获得理论上数倍的峰值算力提升。这种提升是非常诱人的——只要能掩盖住精度调整的开销，设计好混合精度的 recipe，准备好数据，就可以享受到 2-3 倍级别的算力升级。

但低精度训练并非”免费午餐”。它涉及到大量底层硬件实现细节，并且需要精心设计精度转换（Quantize / Dequantize）的 recipe 来保证收敛性。

低精度的两大挑战#

挑战一：硬件支持与精度转换开销

低精度操作（如 FP8 的 Quantize 和 Dequantize）引入的精度转换有时会成为性能瓶颈。而且收敛性需要经过 scaling 验证，recipe 的设计需要精心考量（例如缩放因子的选择）。某些精度操作甚至是和硬件指令绑定的——如果硬件没有做到芯片上（比如 FP4 的某些操作），就需要用软件模拟，性能就上不去。

挑战二：低精度的收敛性

即使有了硬件支持，用低精度训练能否收敛到和高精度相同的效果，仍然是一个需要大量实验验证的问题。

FP8 混合精度训练#

图7展示了 Hopper 和 Blackwell 架构上的 FP8 混合精度训练方案：

• Forward：使用 FP8 GEMM（BF16 输入 → Row-wise/Col-wise FP8 量化 → FP8 GEMM → BF16 输出）
• Backward：Input Gradient 和 Weight Gradient 同样使用 FP8 GEMM
• Optimizer：仍然维护 FP32 的 Master Weights、Momentum 和 Variance

整个流程对训练 pipeline 的复杂度会增加不少。小米的一个技术报告中提到了 DeepSeek First Attention（DFSA）等相关实践。

低精度算力的趋势#

以 B300 为例，不同精度的 Tensor Core 理论峰值差异巨大：

• FP32 → FP16/BF16 → FP8 → FP4，每降一级精度，算力大约翻倍
• 从 BF16 的 ~36 PFLOPS 到 FP8 的 ~72 PFLOPS 到 FP4 的 ~108 PFLOPS

NVIDIA 在 B300 中专门加强了稠密 FP4 的算力，但同时 INT8 Tensor Core 和 FP64 被大幅削减。这说明即使是 NVIDIA，对低精度的设计也在不断调整和演进。B200 的设计在某种程度上被认为不够成功（FP4 的稀疏/稠密设计比例），可以参考相关 blog 了解。

低精度训练不是简单地”把精度调低”，而是需要从硬件指令、精度转换开销、收敛性验证、混合精度 recipe 设计等多个维度综合考量的系统工程。

第一类：端侧推理（资源极度受限）#

核心问题是 GPU 和 CPU 如何做协同推理（Offloading）——哪些计算在 CPU 上做，哪些在 GPU 上做。

手机端：手机上的 NPU 算力有限，目前 Ollama 和 llama.cpp 确实可以让模型在手机上跑起来，但体验很差（容易卡死）。端侧推理的真实需求来自隐私场景——用户可能不希望某些数据被云端大模型读取，因此需要一个本地的轻量级小模型（通常 <10B，超低比特量化 + 剪枝）。MIT 韩松团队在模型轻量化方向有深入研究。

此外，具身智能场景（如机器人搭载 NVIDIA Jetson）的端侧算力会更强，端云协同是一个正在探索的方向。

消费级显卡/单卡：2025 年初有一波热潮。代表项目 KTransformers 的成名之战是用 24GB 显存满血推理 DeepSeek-R1，核心就是做好 Offloading——让 CPU 和 GPU 协同完成一次推理，包括利用 Intel AMX 做 CPU 端的计算加速。

第二类：小规模推理（Collocated Serving）#

Prefill 和 Decode 不做分离（PD 不分离），使用传统的 3D 并行在单节点或少量节点上做推理。两个成熟的框架是 vLLM 和 SGLang。

vLLM 的核心卖点是 PagedAttention——借鉴操作系统的分页机制，以 page 为单位管理 KV Cache 的显存，将碎片控制在一个 page size 以内。

SGLang 的核心卖点是 RadixTree——通过前缀树做 KV Cache 的复用。

两个框架发展速度极快，互相借鉴对方的设计并实现，目前各自的独家卖点需要持续关注。推荐的学习材料包括 SwiftInfer（晟余写的两三千行的推理代码）、NanoVLLM 和 MiniSGLang 等小型项目，适合用来理解推理系统的核心设计。

Prefill vs Decode 的特征差异#

理解推理优化的前提是理解 Prefill 和 Decode 阶段的本质区别：

• Prefill：输入 token 全部已知，可以通过 mask 一次性计算完毕，KV Cache 在这个阶段被建立。它是 Compute-Bound 的。
• Decode：自回归生成，一次只吐一个 token。由于每次计算量很小但需要大量读取 KV Cache，它是 Memory-Bound 的。

对这两个阶段分别有不同的性能指标要求：

• TTFT（Time To First Token）：衡量 Prefill 的速度
• TPOT（Time Per Output Token）：衡量 Decode 的速度

协调多个 request 的 TTFT 和 TPOT 是一个经典的调度优化问题——如果把大量资源给 Prefill，Decode 的用户体验就会变差。

关键优化技术#

• Continuous Batching + Chunked Prefill：不会因为一个超长 Prefill 请求占满所有 Decode 资源，以 continuous 的形式组 batching，更好地打满硬件资源
• Speculative Decoding / MTP：引入一个或多个小模型同步做推理，让大模型来验证并选择结果，从而一次性输出多个 token，打破自回归的逐 token 限制

第三类：全模态与 Agent 场景#

文本、图片、声音、视频等多模态输入的预处理和资源安排，以及 Agent 场景下各种工具调用和 Agent 之间的交互——这是推理场景下新兴的方向，目前尚无定论，但核心问题是如何协作和做资源管理来适应全模态和 Agent 的需求。

CUDA Graph 与 Mega Kernel#

GPU kernel 的 launch 流程类似于”把大象放进冰箱”的三步：把数据拷到 GPU、launch kernel 让 GPU 计算、算完把结果传回 CPU。当 GPU 算力极强时，如果提交了过多的小 kernel，launch 的开销与 kernel 执行时间甚至差不多，就会形成 CPU 端的提交瓶颈。

两种解决方式：

1. CUDA Graph：以 graph 的形式一次性提交多个 kernel 的执行计划，减少 launch 开销
2. Mega Kernel / Kernel Fusion：将多个小 kernel fuse 成一个大 kernel，只需一次 launch 就完成所有操作。Stanford 的 NoBubble 工作做到极致——写一个 kernel launch 完就完成了一次完整推理。字节的 Flux 和 CoMeT 则在做 fine-grained 的 computation-communication overlapping

归根结底就是两件事：充分利用硬件资源 和 在模型/调度策略上做 design 以满足用户需求。

量化推理#

推理场景中低精度量化是一个被大量研究的方向——不同的量化比特数、不同的量化技巧、不同硬件上的适配方案、不同的数据类型组合。目标是在精度损失有限的前提下获得尽可能强的推理性能。2025 年这个方向的工作日新月异，因为推理的上手门槛相对较低（有一台服务器、一张卡就可以做），叠加模型推理的热点，产出极其丰富。

大规模分布式推理：PD 分离#

大规模推理是完全不同的场景。既然 Prefill 和 Decode 有不同的计算特征和优化目标，那就把它们分开部署——这就是 Disaggregated Serving（PD 分离） 的思想。

引领性工作 DistServe 提出了 Goodput 的概念，并提出了 PD 分离的思想。核心架构如图8所示，以 KV Cache 为中心构建整套系统：

• Prefill Instance：专注于计算密集的 Prefill 阶段，优化目标是 max Cache Reuse，约束是 TTFT SLO 和 MFU Lower Bound
• Decode Instance：专注于访存密集的 Decode 阶段，优化目标是 max Throughput，约束是 TBT SLO 和 KVCache < VRAM
• KVCache Transfer Engine：在 Prefill 和 Decode Instance 之间传输 KV Cache

KV Cache 的存储系统涉及多级存储：GPU 显存、CPU 内存、磁盘（SSD）、甚至其他节点的存储。KIMI 的 MoonCake 就是一个 KV Cache Centric 的架构，以 KV Cache 为中心构建了整套推理系统。

类似的工作还有 FlexKV、HiCache 等，思想都是做存储池化，然后低延迟、高吞吐地传输用户需要的 KV Cache 数据。不同场景下可以针对性地设计 caching 策略——观察到某种访问模式后，设计新的 caching 策略来优化。

当 Expert Parallel 加上 Disaggregated Serving 时，核心优化目标变为两个：KV Cache 的存储管理 和 通信效率。

“工程地狱”#

思想虽然 trivial，但工程实现远比想象中困难。看架构图觉得简单，实际上每一步都是挑战：

• PD 的比例如何分配才最合理
• Instance 出错时如何做容错处理
• 如何针对自己的推理集群做针对性调优
• 从上到下这么多组件，如何挑选合适的版本并全部 set up 好

衡量标准只有两条：性能好 + 没 bug。

CPU Centric vs GPU Centric#

高性能通信可以分为两大阵营：

CPU Centric：代表库是 NCCL 和 NIXL。通信由 CPU 上的 proxy thread 管理——CPU 启动 CUDA kernel 生成数据 → 写入 host memory 的 proxy buffer → CPU 读取 doorbell → CPU 通过 NIC 发起 RDMA → 对端 NIC 完成 → 对端 CPU 轮询 completion queue → 通知 GPU。整个链路中 CPU 介入了多个步骤（约 4 个可优化步骤），增加了 latency。

GPU Centric：代表是 NVSHMEM 和 IBGDA。核心改进是移除 CPU 的介入——GPU 的 SM 直接管理通信，不需要 proxy buffer、不需要 CPU 读 completion queue。SM 自己写 doorbell、自己做 work descriptor 提交、网络操作完成后直接在 GPU memory 可见。这就是 GPU-Direct In-Kernel Initiated 的概念，对标 CPU/Proxy Initiated 的方式，latency 大幅降低。

DeepEP 正是基于 NVSHMEM + IBGDA 重写了 All-to-All 的实现，在 H800 + ConnectX 网卡上达到了极致性能，从而带火了整个 GPU Centric 方向。

NCCL 的超强进化#

不能以静态的眼光看待 NCCL。很多对 NCCL 的”攻击”其实已经过时——NCCL 在 2.28 和 2.29 版本中做了大量进化：

• SHARP：将 Reduce 操作 offload 到网络交换机（in-network computing），SM 使用量从 16+ 降到 6，同时 AllReduce 带宽提升约 30%（从 360 GB/s 到 480-490 GB/s）
• ncclCommShrink + ncclCommGrow：支持动态缩减和扩展 communicator，解决了”建链后无法动态调整”的问题
• GPU Initiated Network：NCCL 2.28 开始支持 GPU Initiated，无需 CPU 干预，kernel 直接管理网络——这让 NCCL 同时具备了 CPU Centric 和 GPU Centric 两种模式
• Copy Engine：对于纯数据移动操作，自动使用 Copy Engine 而非 SM，减少 SM 资源占用
• NCCL4Py：Python 绑定，方便开发

其他高性能通信生态#

• AWS 生态：EFA 网卡 + 陈乐群等人的高性能网络工作；UCCL 项目（洋哥）对标 NCCL 的三个 branch（UCCL-Collective、UCCL-P2P、UCCL-EP），目标是支持不同硬件
• 华为：HCCL 和 HIXL（对标 NCCL 和 NIXL）
• 超节点协议：华为的 Unified Bus（UB）、NVIDIA 的 NVLink（NVL72 等）、UALink 联盟（多家公司联合的互联标准）

NVLink 带宽优势#

NVLink 相比 PCIe 的带宽优势是数量级级别的：Hopper 上 NVLink 理论双向 900 GB/s，实际 360+ GB/s；而 PCIe 总带宽仅 ~63 GB/s。如果通信是瓶颈且使用的是 PCIe 服务器，需要做大量针对性优化来减少通信 bottleneck。

NVSwitch 超节点#

超节点的思想是用 NVSwitch 连接 NVSwitch——节点 A 的 GPU 通过 NVSwitch 出去，经过节点间 NVSwitch 互联，到达节点 B 的 NVSwitch，再到目标 GPU。虽然通信要经过三个 NVSwitch（节点内 → 节点间 → 节点内），但理论带宽仍然保持一致（每个 chip 有 18 条 link）。在带宽层面上等效于一个”超节点”，但代价是更高的 latency 和更多的硬件成本。

架构演进趋势#

从 A100（Ampere）到 H100（Hopper）到 B200/B300（Blackwell）再到即将发布的 Rubin，一个非常明显的趋势是：低精度计算单元越来越强——Tensor Core 的理论峰值性能不断攀升，但同时对编程的要求也越来越高，因为需要准备好数据让计算单元充分打满峰值。

Memory Hierarchy 是性能的重中之重。Tensor Core 本身是”随时待命”的——只要数据就位，就可以以频率上限做计算。但数据准备才是真正的瓶颈。因此充分利用 memory hierarchy（寄存器 → Shared Memory → L2 → HBM）来准备数据，是写出高性能算子的核心。

Hopper（H100）的关键进化#

相较于 A100，H100 引入了几个重要特性：

1. Thread Block Cluster：在 Grid → Block → Thread 之间新增了一个抽象层次。多个 Block 组成一个 Cluster，Cluster 内的 Block 可以更高效地协作，并共享 Distributed Shared Memory。

2. TMA（Tensor Memory Accelerator）：异步数据加载单元。TMA 可以在后台自动完成数据从 Global Memory 到 Shared Memory 的搬运，而 SM 的计算线程可以同时执行计算——实现了数据预取和计算的 overlap。这对 pipeline 的设计至关重要。

3. FP8 Tensor Core：原生支持 FP8 的矩阵乘，使得 FP8 混合精度训练成为可能。

Blackwell（B200/B300）的低精度算力#

以 B300 为例，Tensor Core 在不同精度下的理论峰值性能差异极大：

B300 相比 B200 的变化：稠密 FP4 算力被专门加强，但 INT8 Tensor Core 和 FP64 被大幅削减。这说明 NVIDIA 对 FP4 的设计仍在调整——B200 的 FP4 设计被认为是一个失败（可以参考相关 blog 了解细节），B300 对此做了修正。

NVLink C-to-C：CPU 与 GPU 的 Co-design#

一个容易被忽略的特性是 Hopper 引入的 NVLink C-to-C（Chip-to-Chip）——GPU 通过 NVLink 访问 CPU 的带宽与访问另一个 GPU 相同（都是 900 GB/s 理论带宽）。而 CPU 侧的 LPDDR5X 内存带宽仅 ≤500 GB/s，形成了一个有趣的对比。这个特性对于需要 CPU-GPU 协同的场景（如 Offloading、KV Cache 管理）有重要意义。

2:4 Sparsity 的争议#

2:4 Structured Sparsity 是 NVIDIA 从 Ampere 架构开始引入的硬件特性：每 4 个元素中恰好有 2 个为零，可以获得 2 倍的 Tensor Core 加速。但使用条件苛刻：

1. 矩阵至少需要 50% 的 sparsity
2. sparsity 的分布必须严格满足 2:4 模式

如果原始矩阵不满足 2:4 模式，需要先做 transform（旋转/重排），计算完再 inverse transform。transform 的开销如果太大，就拿不到性能收益。在大模型时代，自然产生的稀疏性通常不会这么规则，因此 2:4 Sparsity 在实际中的适用场景有限。但如果能用上，可以发高质量的 SC 论文。

DSL 与算子生态#

编写高性能 GPU 算子有一个”不可能三角”：开发速度快、写算子门槛低、算子性能好——三者很难同时满足。为此涌现了大量 DSL（Domain Specific Language）：

• CuTeDSL（NVIDIA 推荐）：CUTLASS 团队推出
• cuTile：NVIDIA 的 tile-based 编程模型
• TileLang（字节 / 郑思泽团队）：国内常见的算子 DSL
• Triton Distributed：基于 Triton 的分布式扩展
• ROCm/Iris/TritonBlas（AMD）：AMD 生态的算子工具
• CUTLASS 和 Triton：最经典的两个算子库

如果追求极致性能，直接写 CUDA C 和 PTX 仍是最佳选择。但如果愿意接受 80-90% 的性能、用 50% 的开发 effort，上述 DSL 是更务实的选择。

AI Kernel Generation#

2025 年 AI 写 kernel 做调优展现出了不小的潜力——基于强化学习或 Agent 工作流，在 DSL 或 CUDA C/PTX 层面让 AI 帮写算子。虽然目前在泛化性和性能上还有差距（尚未达到”能让程序员相信它可以解决 80% 工作负担”的程度），但值得持续关注。

存储系统越来越重要#

存储系统在训练和推理中的重要性正在不断提升，但训练和推理对存储的需求有本质区别：

训练场景：访问 pattern 是高度可预测的——每个 epoch 读取固定的数据集、checkpointing 按固定间隔写入。这种可预测性让存储优化相对容易。需要关注的问题包括：

• 训练持续时间特别长（数周到数月），checkpoint 的存储和恢复效率直接影响训练成本
• 硬件故障时的快速恢复能力
• 大规模数据集的高效加载

推理场景：访问 pattern 不如训练那么可预测——用户请求的 pattern 是动态的，KV Cache 的访问和淘汰策略需要根据实际场景设计。正如前文提到的 MoonCake 架构，推理场景下的多级存储系统（GPU 显存 → CPU 内存 → SSD → 分布式存储）需要精心设计 caching 策略。

训练中存储不成为瓶颈的原因：训练的 epoch 轮次很长，当前 epoch 在计算的同时，下一个 epoch 的数据可以提前 prefetch，磁盘 IO 被完全 overlap 掉（除了第一轮的冷启动）。

存储系统的优化空间很大，包括但不限于：硬件 Co-design、硬件优化、以及在存储系统层面做”以存代算”（用存储换计算）。DeepSeek 的 Engram 对存储系统有明确要求——其核心机制是将 embedding tables offload 到 CPU 内存乃至磁盘的多级存储中，推理时需要在前面几层计算时做 prefetch，如果存储性能（offloading 和预取速度）达不到要求，Engram 带来的创新性能增益就无法兑现。

整体设计哲学#

以整体的视角看待系统设计——不单单是各个硬件组件之间的协同，还包括硬件和软件之间的 co-design。

一个核心观点：如果你能指导硬件设计，将某些软件层面的操作（如精度调整、特定的通信模式）做到硬件里，就可以从根本上改变性能特征。例如 FP8 的精度调整如果做到硬件指令中，软件层面的开销就大幅降低。

这种整体视角要求工程师不仅理解软件栈（框架、算子、通信库），还要理解硬件栈（GPU 架构、网络拓扑、存储层次），才能从全局最优的角度去榨干整个系统的性能。

关键 Insight#

几条值得铭记的认知：

1. 设计不是科学发现：很多硬件设计本身是可以 argue 的——它不是物理定律，而是工程权衡。不同的设计在不同场景下有不同的合理性。

2. 没有银弹：不存在”一次优化到处跑且性能都好”的方案。不同场景（High Throughput vs Low Latency、节点内 vs 节点间、训练 vs 推理）需要完全不同的优化策略。

3. 思想往往 trivial，工程才是地狱：无论是 PD 分离、EP、还是各种并行策略，思想上都不复杂。但工程实现中的容错、调优、版本兼容、性能回归等问题，远比想象中困难。

4. 持续学习是唯一出路：这个领域的迭代速度极快，任何”take-away”都有时效性。保持开放心态，多交流、多实践。

30 分钟的思考省 3 小时的调试。上手很容易，但听声（理解深层原理）很困难——打开影子之后，持续学习和多多交流才是长期发展的关键。