Ml-Infra

起因 # 上一篇搞清楚了 Pipeline Parallelism 的调度机制：GPipe 先 Forward 后 Backward，1F1B 通过交替调度降低 Activation 暂存压力，但理想条件下 Bubble Time 相同。

起因 # 上一篇把 ZeRO 的三个 Stage 走了一遍之后，我以为关于参数分片这件事已经想得差不多了——ZeRO-3 / FSDP 把参数、梯度和 Optimizer States 全部分片存储到多张 GPU 上，单卡 Model States 从 112 GB 降到约 28 GB，问题解决。

起因 # 上一篇 Tensor Parallelism 写完之后，我对 TP 的基本原理有了底：把单个算子内部的矩阵乘法拆到多张 GPU 上执行，每张卡只算部分输出，最后通过 AllReduce 聚合。TP 分片的是计算本身。

起因 # 上一篇搞清楚了 AllReduce、ReduceScatter 和 AllGather 三种通信原语，末尾提到 DDP 和 ZeRO Stage 2 选择了不同的通信原语组合，根本原因是参数更新的责任分配不同。

起因 # 之前几篇文章从模型显存组成一路算到 7B 模型的训练账本，结论很直接：BF16 mixed precision + AdamW 的 Model States 就有 112 GB，一张 80 GB A100 连放都放不下。Checkpointing + Offloading 两个一起用可以勉强塞进去，但训练速度要被 PCIe 传输和额外重计算拖累。

起因 # 上一篇讨论完 Checkpointing 和 Offloading 之后，结尾留了一句：单卡优化的代价已经不可接受时，下一步自然是考虑让多张 GPU 分担训练状态。 于是我开始看 DDP（DistributedDataParallel）。一开始觉得 DDP 的核心思想很直白——每张卡各算各的梯度，然后 All-Reduce 同步一下，用平均梯度更新参数。看起来最朴素的做法就是把所有梯度打包成一个大 tensor 做一次 All-Reduce，简单干净。

起因 # 上一篇算完了 7B 模型的训练显存账本。结论很直接：BF16 mixed precision + AdamW 的 Model States 就有 112 GB，加上 30 GB 的 Activations，单卡至少需要 145 GB——一张 80 GB 的 A100 连 Model States 都放不下。

起因 # 之前分别写了推理和训练的显存心智模型和混合精度训练中的显存组成，反复出现一个粗估：BF16 mixed precision + AdamW 大约 16 bytes/parameter。但这个数字每次都只是"1B × 16 = 16 GB"的单位换算，没有真正对着一个具体的 Transformer 架构把账从头到尾算一遍。

最近在看 MIT 6.S191 Lecture 9 的时候，反复听到一句话：Data Movement Matters。 之前写过 Arithmetic Intensity 和 Compute/Memory Bound，也刚写完 FlashAttention 的分块和 Online Softmax。这些文章里"HBM"和"片上存储"出现了很多次，但我发现自己其实一直没有认真想过一个问题：HBM 到底是什么？它全称叫 High Bandwidth Memory——高带宽内存——既然带宽已经很高了，为什么还要费这么大劲减少对它的访问？

之前的几篇把 Self-Attention 的公式拆得比较清楚了，从 QKV 的计算含义到 Multi-Head 的分工。另一条线是 GPU 性能——Arithmetic Intensity、memory bound、HBM 带宽这些概念也已经聊过。关于 HBM 和片上存储的物理区别，可以参考GPU 存储层级那篇。

起因 # 过去几篇笔记一直在 Lecture 6 的范围里打转。Distribution Shift 那篇让我意识到离线测试集的 98% 准确率没法平移到生产环境，Algorithmic Bias 那篇又告诉我总体准确率可以掩盖群体间的巨大差异，对抗攻击那篇则让我看到泛化好的模型仍然可以被微小扰动骗过。

起因 # 之前在量化团队做 ML Infra 相关工作时，我曾参与过期货预测模型的特征重要度评估与特征筛选系统。 在那套系统里，Permutation Importance（置换重要度）是最核心的算子之一。当时我们面临的工作负载非常庞大：针对上千维的输入特征，要在多个交易日的数据上反复进行特征随机置换、模型前向推理以及评价指标的计算。在很长一段时间里，我的注意力几乎完全被系统层面的工程瓶颈吸引——如何降低内存拷贝、如何把推理批次打满、如何避免在不同特征扰动之间重复扫描数据。计算耗时被压下来之后，整套流水线跑得很顺，我也就习惯性地把这套指标当作特征评价的标准答案。

起因 # 上一篇聊分布偏移与外推的时候，我把关注点放在了训练数据与生产环境之间的不一致上：模型在离线测试集上哪怕拿到了 98% 的高分，一旦现实环境发生 Covariate Shift 或者流形外推，线上的预测能力依然可能迅速滑坡。

起因 # 上一篇聊随机标签实验的时候，我把注意力放在了模型容量和假设空间上：一个参数量巨大、完全有能力死记硬背随机噪声的神经网络，为什么在面对真实规律的数据时，依然能找到泛化良好的解。

一个部署工程师的困惑 # 几年前我在做计算机视觉模型的部署，用的是 TensorRT 4 和 5。每次把训练好的模型转成 TensorRT engine，都绕不开一个参数：maxBatchSize。

在 2022 年的年终总结里，我提过当时做的一个“动态算力”项目。那一年，我和另一位同事一起推进了这套系统，陆续接入腾讯新闻、QQ 音乐、全民 K 歌等业务，部分场景节省了约 30% 的成本。

起因 # 三年前我参与维护过一个多人共享的训练集群。集群上跑着各业务线的训练任务，用户通过一个队列系统提交，每个用户有自己的资源 Quota。

起因 # 在上一篇《从进程视角重新理解 Docker》中，我总结了 Docker 最核心的价值：它通过 namespace 和 cgroup 给进程构造了独立的视图和资源限制，并把这套运行环境固化成了可以直接分发的 artifact。

起因 # 最近在团队内部重新整理 Python 项目的打包、发布和依赖管理规范，逐渐把各个工程统一收敛到： 1pyproject.toml 2uv 3uv.lock 4wheel 5src layout 6internal package registry 在这个过程中，大家交流最多的往往是一些具体的工具用法：私有源怎么配、build backend 选哪一个、uv 的命令参数怎么写。但我越梳理越发现，这些工程细节很容易盖住一个更基础的问题：

起因 # 写训练代码的时候，经常从这里开始： 1dataset = load_dataset(...) 2model = build_model(...) 3train(model, dataset) dataset 像是一个天然存在的东西。打开一个 benchmark，下载一个压缩包，解压，加载，开始训练。ML 课程、论文、demo 大多也是从这一步开始。