Ml-Infra

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

起因 # 之前在量化团队做 ML Infra 相关工作时，我曾参与过期货预测模型的特征重要度评估与特征筛选系统。

起因 # 上一篇聊分布偏移与外推的时候，我把关注点放在了训练数据与生产环境之间的不一致上：模型在离线测试集上哪怕拿到了 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 大多也是从这一步开始。

起因 # 最近偶然看到一篇文章，里面提到一个 Linux 和 Windows 的差异：在 Linux 下，即使机器实际上没有足够的物理内存，一个很大的 malloc 仍然可能成功返回。而 Windows 对 committed memory 的管理要严格得多，类似的 allocation 更容易被直接拒绝。

起因 # 最近在继续 CS336 和 MIT 6.S191。 之前那篇写了 BPE tokenizer——从训练到编解码，关注的是 raw text 怎么变成 token，token 怎么映射成 token ID。做完之后，对这条链路的前半段算是搞清楚了：

起因 # CS336 的 training loop 里，loss.backward() 和 optimizer.step() 挨在一起。前者计算 gradient，后者更新 parameter；但 gradient 存在哪里、什么时候清零、optimizer 还维护什么状态，需要分开看。于是结合 MIT 6.S191 的 Lecture 1，把一次训练迭代重新过了一遍。

推理任务能放下，为什么训练任务放不下 # 上一篇讨论了模型调度中的 Capacity Constraint：一组模型到底能不能同时放进一张 GPU。

起因 # 这是 CS336 系列的又一篇。 之前那篇讨论了 FLOPs 到 Latency 之间的鸿沟：FLOPs 相同的两个 GEMM，latency 可能差几倍甚至十几倍。那篇文章的核心结论是 FLOPs 是 workload metric，不是 performance metric，并且引入了 Arithmetic Intensity 和 Roofline Model 作为分析工具。

起因 # 最近在做 CS336（Language Modeling from Scratch）的 Transformer 实现，代码里反复出现这种写法：

起因 # 我们的线上推理系统中存在大量模型——MLP、GNN、MoE，以及它们的各种组合。这个 workload 有几个重要特点：

起因：一个来自运维同事的问题 # 前阵子运维同事找到我，大意是： “我们现在训练特征大部分还是 NumPy / Parquet。最近看到 Lance，说是一个更适合 AI 训练、推理的数据格式。我们为什么没有用 Lance？”

起因：GPU 没吃满，但不是算力问题 # 最近组里有同学训练模型时，最直接的感受是：GPU utilization 上不去，step time 里总有一段在等数据。

起因 # 以前在商汤做 CV 的时候，有一段时间在做目标检测模型的 INT8 量化。目标很直接：降低 inference latency，减少 model memory 和 bandwidth，同时利用 INT8 hardware throughput。