1. 这个项目到底在解决什么问题第一次看到 ai-engineering-from-scratch 这个标题我脑子里蹦出来的第一个念头是又是一个教人调包的教程仓库但仔细琢磨了一下 from scratch 这几个字我意识到它想做的事情可能完全不一样。市面上讲 AI 工程的内容绝大多数都是从pip install开始然后调几个 API跑通一个 demo 就结束了。但真正在生产环境里摸爬滚打过的人都知道从能跑到能用之间隔着一整个太平洋。这个项目的核心定位我理解下来是这样的它试图把 AI 工程这件事从最底层的原理开始一层一层地搭起来让你不光知道怎么用工具更知道这些工具背后在干什么、为什么要这么设计、出了问题该从哪里下手排查。它面向的不是只想跑个 demo 的人而是那些真正想把 AI 能力落地到产品里、需要自己搭管线、做优化、处理各种边界情况的工程师。说白了这个项目解决的是知其然不知其所以然的问题。你可能已经会用某个框架训练模型了但如果让你从零实现一个 attention 机制或者手写一个反向传播你可能就卡住了。而恰恰是这些底层的理解决定了你在遇到性能瓶颈、调试诡异 bug、做架构选型的时候能不能做出正确的判断。我见过太多团队模型训练脚本写得飞起但一到部署就抓瞎——推理延迟高得离谱显存占用莫名其妙batch size 调来调去就是找不到最优解。这些问题的根源往往不是框架用得不够熟而是对底层的计算逻辑、内存管理、并行策略缺乏基本的认知。这个项目想做的就是帮你补上这一课。适合谁来参考呢我觉得有三类人特别值得花时间研究第一类是有一定编程基础、想转行做 AI 工程的开发者你需要一个系统性的路径来建立完整的知识体系第二类是在做 AI 相关项目但总觉得根基不稳的工程师你需要回头把那些被跳过的基础补起来第三类是对 AI 系统内部机制好奇、想自己动手实现一遍的技术爱好者你需要一个从零开始的实操指南。2. 整体设计思路与知识体系拆解2.1 为什么选择从零实现这条路线从零实现听起来很硬核但它的价值不在于让你以后真的手写每一个算子——实际工作中你肯定还是用 PyTorch 或 TensorFlow。它的价值在于建立直觉。就像学开车你不需要会造发动机但如果你知道发动机的工作原理你在听到异常声音的时候就能判断大概是哪里出了问题。这个项目的设计逻辑我推测是这样的先让你用最原始的方式实现一遍核心组件感受一下计算是怎么流动的、梯度是怎么传的、内存是怎么分配的。等你对这些有了体感之后再引入成熟的框架和工具你就能理解框架帮你做了什么、在哪些地方做了取舍、什么时候需要绕过框架自己动手。这种路线的好处是你学到的知识不会随着框架版本的更新而过时。框架的 API 可能一年换一次但底层的数学原理和工程逻辑十年都不会变。你花时间在底层上投资回报周期是最长的。2.2 知识体系的层次划分我把这个项目涉及的内容大致分成四个层次从下往上依次是第一层数学与算法基础。这一层包括线性代数、概率论、微积分在 AI 中的具体应用以及反向传播、梯度下降、注意力机制等核心算法的推导和实现。很多人觉得这层太理论、太枯燥但恰恰是这层决定了你的天花板。我见过不少工程师调参全靠试就是因为对损失函数的曲面形状、学习率的几何意义没有直观理解。第二层计算与内存管理。这一层涉及张量操作、计算图、自动微分、内存分配策略、GPU 并行计算等内容。这是从数学公式到能跑的代码之间的桥梁。很多性能问题都出在这一层——比如为什么你的模型显存占用比理论值大那么多为什么 batch size 翻倍后速度没有翻倍这些都需要你对计算和内存有深入的理解。第三层工程架构与系统设计。这一层包括训练管线设计、数据加载与预处理、分布式训练、模型部署、推理优化等内容。这是从能训练到能上线的关键。很多团队在这一层踩坑最多因为涉及的东西最杂——既要懂算法又要懂系统还要懂业务。第四层工具链与最佳实践。这一层包括框架选型、实验管理、版本控制、监控告警、CI/CD 等内容。这层看起来最软但实际影响很大。一个好的实验管理工具能让你少走很多弯路一个合理的版本控制策略能让你在出问题的时候快速回滚。2.3 与其他学习资源的差异化市面上讲 AI 工程的资源不少但大多数要么偏理论只讲数学推导不涉及工程实现要么偏应用只讲怎么调 API不涉及底层原理。这个项目的差异化在于它试图在理论和应用之间架一座桥——用工程的方式讲理论用理论的高度指导工程。举个例子讲反向传播的时候很多教程会直接给你公式然后让你用框架的autograd完事。但这个项目可能会让你先用 NumPy 手写一个简单的反向传播感受一下链式法则在实际计算中是怎么体现的然后再引入计算图的概念解释框架是怎么自动完成这些计算的最后再讨论在真实的大模型中反向传播会遇到哪些工程挑战比如梯度消失、梯度爆炸、混合精度训练中的数值稳定性问题。这种三步走的方式让你不仅知道是什么还知道为什么和怎么办。3. 核心模块的实操要点与避坑指南3.1 从零实现一个简单的神经网络如果让我来设计这个项目的第一课我会从实现一个最简单的全连接网络开始。不是用框架而是用 NumPy。为什么因为这是让你建立计算直觉最快的方式。具体怎么做呢首先定义网络结构输入层、一个隐藏层、输出层。然后手动初始化权重——这里就有第一个坑权重初始化不能全零。如果你把所有权重初始化为零那么所有神经元的输出都一样反向传播时梯度也一样网络永远学不到东西。正确的做法是用随机初始化比如 Xavier 初始化或 He 初始化具体用哪个取决于激活函数。接下来是前向传播。这一步相对直观就是矩阵乘法加激活函数。但这里有个细节激活函数的选择会影响梯度传播。Sigmoid 函数在输入很大或很小时梯度接近零会导致梯度消失ReLU 在正区间梯度恒为 1能缓解这个问题但在负区间梯度为零可能导致神经元死亡。实际中常用 Leaky ReLU 或 GELU 来平衡。然后是损失函数。分类问题常用交叉熵回归问题常用均方误差。这里有个容易忽略的点交叉熵损失配合 Softmax 使用时数值稳定性很重要。如果你直接先算 Softmax 再算交叉熵当 logits 很大时可能会溢出。正确的做法是用 log-sum-exp 技巧来合并计算。最后是反向传播和参数更新。反向传播的核心是链式法则但手动推导和实现的时候很容易搞错矩阵的维度。我的经验是先在小批量数据上验证梯度计算的正确性用数值梯度有限差分来对比解析梯度确保实现无误后再上大规模数据。注意手动实现反向传播时矩阵转置和求和维度是最容易出错的地方。建议每写一行代码都打印一下张量的形状确认维度匹配。3.2 计算图与自动微分的实现逻辑理解了手动反向传播之后下一步就是理解框架是怎么自动完成这件事的。核心概念是计算图——把所有的计算操作表示成图中的节点数据流动表示成边。前向传播时按拓扑顺序计算每个节点的值反向传播时按逆拓扑顺序计算梯度。实现一个简易的自动微分系统关键设计决策有几个第一节点怎么表示。每个节点需要存储前向计算的值、反向传播的梯度、产生该节点的操作、以及该操作的输入节点。这样在反向传播时每个节点可以根据自己的操作类型把梯度传给输入节点。第二梯度怎么累积。如果一个节点被多个下游节点使用它的梯度需要累加。这就是为什么框架里每次反向传播前都要zero_grad()——不清零的话梯度会一直累加。第三内存怎么管理。计算图在前向传播时需要保存中间结果用于反向传播这会占用大量内存。框架通常提供一些优化手段比如 checkpointing只保存部分中间结果反向传播时重新计算、in-place 操作原地修改节省内存但可能影响梯度计算等。我实测下来自己实现一个简易的自动微分系统哪怕只支持加法和乘法对理解框架的行为都有巨大帮助。你会突然明白为什么有些操作不支持原地修改、为什么某些情况下需要detach()、为什么retain_graphTrue有时候是必要的。3.3 训练管线的工程化设计从能训练到训练得好中间隔着大量的工程细节。这个项目如果涉及训练管线我觉得以下几个点必须覆盖数据加载与预处理。这是最容易被低估的环节。很多人模型训练慢不是模型本身慢而是数据加载成了瓶颈。解决方案包括使用多进程数据加载、预取数据、把数据预处理成适合快速读取的格式如 WebDataset、LMDB、在 GPU 上做数据增强等。我踩过的坑是数据加载的 worker 数量不是越多越好太多会导致 CPU 争抢和内存暴涨通常设置为 CPU 核心数的 2-4 倍比较合适。混合精度训练。用 FP16 或 BF16 代替 FP32 可以显著减少显存占用、加速计算但需要处理数值稳定性问题。关键是损失缩放——因为 FP16 的动态范围小梯度容易下溢需要把损失放大一定倍数反向传播后再缩回来。框架通常提供自动损失缩放但你需要知道它在干什么以及什么时候需要手动干预。梯度累积。当显存不够大、无法使用大 batch size 时可以通过多次前向传播累积梯度再一次性更新参数模拟大 batch 的效果。这里有个细节Batch Normalization 在梯度累积时行为会变化因为 BN 依赖当前 batch 的统计量。如果累积了多个小 batchBN 看到的是每个小 batch 的统计量而不是合并后的大 batch。解决方案是用 SyncBatchNorm 或者改用 LayerNorm/GroupNorm。检查点与恢复。训练大模型动辄几天几周中间可能因为各种原因中断。一个健壮的检查点机制需要保存模型参数、优化器状态、学习率调度器状态、当前的 epoch 和 step、随机数生成器状态保证可复现。我见过太多人只保存模型参数结果恢复训练后 loss 曲线对不上就是因为优化器的动量状态丢了。3.4 推理优化与部署的关键考量模型训练完只是第一步怎么高效地跑推理才是真正见功夫的地方。这个项目如果涉及部署以下几个方向值得深入模型量化。把 FP32 的权重和激活值转换成 INT8可以大幅减少模型大小和推理延迟。但量化会带来精度损失需要在精度和速度之间做权衡。常见的做法是训练后量化PTQ和量化感知训练QAT。PTQ 简单但精度损失可能较大QAT 在训练时就模拟量化误差精度更好但需要重新训练。算子融合。把多个连续的小算子合并成一个大的算子减少 kernel launch 的开销和内存访问。比如 Conv BatchNorm ReLU 可以融合成一个算子。框架和推理引擎通常会自动做这些优化但你需要知道哪些模式容易被融合、哪些不容易以便在模型设计时就有意识地往容易优化的方向靠。动态批处理。在线推理时请求是逐个到达的。如果每个请求都单独跑一次推理GPU 利用率会很低。动态批处理把短时间内到达的多个请求合并成一个 batch 一起推理显著提升吞吐。但这里有个权衡等待时间越长batch 越大吞吐越高但延迟也越大。需要根据业务对延迟的容忍度来调整等待窗口。缓存策略。对于某些场景比如对话系统很多请求的前缀是相同的比如 system prompt。可以把这些公共前缀的 KV Cache 缓存起来避免重复计算。这个优化在大语言模型推理中效果非常明显能显著降低首 token 延迟。4. 常见问题与排查技巧实录4.1 训练不收敛的排查思路训练不收敛是 AI 工程中最常见也最让人头疼的问题。我总结了一个排查顺序从简单到复杂第一步检查数据。这是最容易被忽略的。把数据可视化出来看看标签对不对、分布有没有问题、有没有脏数据。我遇到过好几次折腾了半天模型最后发现是数据加载的时候把标签搞错了。第二步检查损失函数。损失函数和任务是否匹配分类任务用交叉熵回归任务用 MSE多标签分类用 BCE。另外检查一下 reduction 方式——是求和还是求平均这会影响梯度的尺度。第三步检查学习率。学习率太大导致震荡太小导致收敛慢。可以做一个学习率扫描从很小的值开始逐渐增大观察 loss 的变化。通常能找到一个大致的合理范围。第四步检查初始化。权重初始化是否合理有没有全零初始化有没有用适合当前激活函数的初始化方法第五步检查梯度。打印梯度范数看看有没有梯度消失或爆炸。如果梯度范数在训练过程中持续增大可能需要梯度裁剪如果一直很小可能需要调整网络结构或初始化。第六步过拟合一个小数据集。取几十个样本让模型去拟合如果 loss 降不到接近零说明模型本身有问题不是数据或训练策略的问题。4.2 显存不足的优化手段显存不足是另一个高频问题。以下是我常用的优化手段按性价比排序优化手段显存节省对速度的影响实现难度减小 batch size线性节省可能降低 GPU 利用率低梯度累积线性节省几乎无影响低混合精度训练约 40-50%通常加速中梯度检查点约 60-70%减慢 20-30%中模型并行取决于切分方式通信开销增加高ZeRO 优化可训练超大模型通信开销增加高我的经验是先试混合精度和梯度累积这两个组合能解决大部分显存问题。如果还不够再上梯度检查点。模型并行和 ZeRO 是最后的手段因为实现复杂度高调试困难。注意使用梯度检查点时需要确保模型的前向传播是确定性的否则重新计算的结果可能和第一次不一致导致梯度错误。4.3 推理延迟高的排查路径推理延迟高可能的原因很多需要系统性地排查首先区分是计算瓶颈还是内存瓶颈。用 profiling 工具如 PyTorch Profiler、Nsight Systems看一下时间花在哪里。如果 GPU 利用率很低说明是内存瓶颈或 CPU 瓶颈如果 GPU 利用率很高但延迟还是大说明是计算量本身太大。如果是内存瓶颈检查是否有频繁的 CPU-GPU 数据传输、是否有不必要的内存拷贝、是否可以用更高效的内存布局。如果是计算瓶颈考虑量化、算子融合、使用更高效的推理引擎如 TensorRT、ONNX Runtime。如果是 CPU 瓶颈检查数据预处理是否太慢、是否有 Python GIL 的限制、是否可以用多线程或多进程加速。我踩过的一个坑是模型在 GPU 上推理但输入数据在 CPU 上做预处理每次推理都要等 CPU 处理完再传到 GPU。后来把预处理也放到 GPU 上用 DALI 或 TorchVision 的 GPU 版本延迟直接降了一半。4.4 分布式训练的常见故障分布式训练涉及多机多卡通信出问题的概率比单卡高得多。以下是我遇到过的典型问题NCCL 通信超时。通常是因为某张卡上的计算太慢其他卡等它等到超时。排查方法是看各卡的利用率找到拖后腿的那张。可能的原因包括数据加载不均衡、某张卡温度过高降频、网络带宽不足。Loss 不一致。分布式训练时如果各卡的 loss 差异很大说明数据划分或梯度同步有问题。检查 DataLoader 的 sampler 是否正确设置了分布式采样检查梯度是否在所有卡上正确同步。检查点保存冲突。多卡同时往同一个文件写检查点会冲突。通常的做法是只在 rank 0 上保存其他卡等待。随机种子不一致。分布式训练时如果各卡的随机种子不同数据增强的结果会不同可能导致训练不稳定。需要确保所有卡的随机种子一致或者使用按 rank 区分的种子但保证可复现。5. 从项目中学到的工程思维5.1 抽象与分层的艺术做 AI 工程很重要的一点是知道什么时候该抽象、什么时候该具体。抽象得太早你会被各种接口和间接层搞得晕头转向抽象得太晚代码会变成一团乱麻改一处动全身。我的经验是先写具体实现等模式重复出现三次以上再抽象。比如你写第一个模型的时候训练循环直接写在脚本里就行写第二个模型的时候把重复的部分提取成函数写第三个模型的时候再考虑设计一个通用的训练框架。这样抽象出来的东西才是真正有用的而不是拍脑袋想出来的通用架构。这个项目如果涉及代码组织我觉得应该体现这种渐进式抽象的思路。不要一上来就设计一个庞大的框架而是从最简单的脚本开始随着需求的增加逐步重构。5.2 可复现性的工程保障AI 工程和传统软件工程最大的区别之一就是结果的不确定性。同样的代码换个随机种子、换个硬件、换个框架版本结果可能就不一样。这给调试和协作带来了巨大挑战。保障可复现性需要从多个层面入手代码层面固定所有随机种子Python、NumPy、框架、CUDA记录所有依赖的版本号避免使用不确定性的操作如某些 GPU 上的原子操作。数据层面记录数据的版本和预处理流程确保每次训练用的是同一份数据。环境层面使用容器化技术固定运行环境记录硬件配置和驱动版本。实验层面使用实验管理工具记录每次实验的配置、指标、产物方便对比和回溯。我见过太多团队因为没有做好可复现性导致一个好不容易调出来的好结果过了一个月就复现不出来了只能从头再来。这个时间成本是巨大的。5.3 性能优化的取舍之道性能优化不是越极致越好而是要在多个目标之间找到平衡点。延迟、吞吐、成本、精度、开发效率这些目标往往是相互冲突的。比如为了降低延迟你可以用量化但精度会下降为了提高吞吐你可以增大 batch size但延迟会上升为了节省成本你可以用更小的模型但效果可能变差。我的建议是先明确你的核心指标是什么。如果是离线批处理吞吐最重要延迟可以放宽如果是实时交互延迟最重要吞吐可以牺牲如果是成本敏感的场景那就要在精度和成本之间找平衡。另外不要过早优化。先把功能跑通测量出真正的瓶颈在哪里再针对性地优化。我见过太多人花大量时间优化一个只占 5% 时间的模块而真正的瓶颈在别的地方。5.4 持续学习与知识更新AI 工程是一个快速变化的领域新的模型架构、新的训练技巧、新的工具链层出不穷。保持学习能力比掌握任何具体技术都重要。我的学习方法是以问题为导向而不是以技术为导向。不要因为出了一个新框架就去学它而是当你遇到一个具体问题、发现现有工具解决不了的时候再去寻找新的方案。这样学到的知识是带着问题场景的记忆更深刻也更容易迁移。另外多读源码少读教程。教程往往简化了很多细节而源码是真实的、完整的。读源码能让你看到真实工程中的取舍和权衡这是教程里学不到的。这个项目如果能在每个模块的最后给出一些延伸阅读的方向和思考题我觉得会非常有价值。因为 from scratch 的最终目的不是让你停留在 scratch而是让你在理解了底层之后能更好地使用和创造上层的东西。