1. 从零手搓AI工程为什么我不建议你直接调包很多人一听到“AI工程”这四个字第一反应就是打开某个云平台拖几个组件调几个API然后跑通一个Demo就觉得自己已经掌握了。我刚开始接触这个方向的时候也是这么想的直到有一次线上推理服务在高峰期直接雪崩日志里全是显存溢出和请求超时我才意识到——只会调包的人根本不知道模型在底层到底经历了什么。ai-engineering-from-scratch这个项目标题核心不在“AI”而在“from scratch”。它要解决的不是“怎么用现成框架跑一个模型”而是“当框架不给你兜底的时候你能不能自己把整条链路搭起来”。这包括数据管道的搭建、模型结构的定义、训练循环的编写、推理服务的部署以及最容易被忽略的——资源调度和性能观测。这篇文章适合三类人看第一类是有一定Python基础但从来没自己写过完整训练循环的开发者第二类是用惯了高级封装库想搞清楚底层到底发生了什么的中级工程师第三类是准备面试AI工程岗位需要把“调包经验”转化为“工程能力”的求职者。我会把整个从零搭建的过程拆成可复现的步骤同时把每个环节背后的“为什么”讲清楚让你不只是照抄而是真正理解。需要提前说明的是我不会涉及任何具体的商业平台或敏感工具所有内容都基于公开的、通用的技术方案。你不需要有GPU集群一台带独立显卡的普通开发机就能跟着做。2. 环境准备别急着装CUDA先把依赖关系理清楚2.1 为什么环境配置是第一个大坑我见过太多人卡在环境配置这一步不是因为他们不会敲命令而是因为他们不理解各个组件之间的依赖关系。Python版本、CUDA驱动版本、深度学习框架版本、编译器版本这四者之间有一个非常严格的兼容矩阵。你随便升级其中一个整条链路就可能直接崩掉。举个真实的例子我曾经在一台开发机上装了最新的Python 3.12然后直接pip install了一个深度学习框架结果框架的预编译包只支持到Python 3.10pip自动去编译源码编译了四十分钟后报了一个C标准不匹配的错误。这就是典型的“不看依赖矩阵就动手”的后果。我的建议是在动手之前先做三件事第一确认你的显卡驱动版本用nvidia-smi命令查看第二根据驱动版本确定支持的CUDA版本范围第三根据CUDA版本选择对应的框架版本。这三步做完再去创建虚拟环境。2.2 虚拟环境的选择与隔离策略虚拟环境不是可选项是必选项。我推荐用conda而不是venv原因很简单conda不仅能管理Python包还能管理非Python的二进制依赖比如CUDA运行时库和cuDNN。用venv的话这些底层库你得手动装版本冲突的概率会高很多。创建环境的命令如下conda create -n ai-scratch python3.10 conda activate ai-scratch这里选Python 3.10而不是更新的版本是因为目前主流深度学习框架对3.10的支持最稳定。不要盲目追新稳定比新特性重要得多。装框架的时候一定要去官方文档查对应的安装命令不要直接pip install。以PyTorch为例官方会给你一个带CUDA版本号的安装命令类似pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118这个cu118就是CUDA 11.8的标识。如果你装错了版本框架虽然能装上但运行时找不到GPU会静默回退到CPU模式训练速度直接慢几十倍。注意装完之后一定要验证GPU是否可用。运行python -c import torch; print(torch.cuda.is_available())输出必须是True。如果是False不要继续往下走先解决这个问题。2.3 目录结构的设计逻辑从零做项目目录结构决定了你后期维护的痛苦程度。我见过有人把所有代码都堆在一个文件里写到后面自己都找不到哪个函数在哪里定义。我的习惯是按功能模块划分同时把配置和代码分离。一个可用的目录结构大概长这样ai-engineering-from-scratch/ ├── configs/ # 配置文件 ├── data/ # 数据存放 ├── src/ │ ├── data/ # 数据加载与预处理 │ ├── models/ # 模型定义 │ ├── train/ # 训练循环 │ ├── inference/ # 推理服务 │ └── utils/ # 工具函数 ├── experiments/ # 实验记录 └── requirements.txt这样分的好处是当你想换一个模型结构时只需要改models/目录下的文件训练和推理的代码完全不用动。配置分离则让你可以在不修改代码的情况下切换超参数这对做实验来说非常关键。3. 数据管道模型效果的上限由数据决定3.1 从原始数据到可训练张量的完整链路很多人把数据加载想得太简单觉得无非就是读文件、转张量、喂给模型。但实际工程中数据管道要处理的问题远不止这些数据格式不统一、缺失值、异常值、类别不平衡、内存放不下需要流式加载、多进程读取时的竞争条件……每一个问题都可能导致训练崩溃或者效果极差。我的一般做法是把数据管道拆成三层第一层是原始数据读取负责把各种格式的文件读成统一的Python对象第二层是预处理和增强负责把Python对象转成模型需要的张量格式第三层是批处理和加载负责把张量组织成批次并高效地送入模型。以图像数据为例第一层可能是读取JPEG文件第二层是缩放、归一化、随机裁剪第三层是用DataLoader组织成批次。每一层的职责要清晰不要混在一起写。3.2 Dataset和DataLoader的自定义实现PyTorch提供了Dataset和DataLoader两个抽象但很多人只是机械地继承并不理解它们的设计意图。Dataset的核心是定义“如何获取一个样本”DataLoader的核心是定义“如何组织一批样本”。这两个职责分离之后你才能灵活地控制批大小、打乱顺序、多进程加载等行为。自定义Dataset的最小实现from torch.utils.data import Dataset class MyDataset(Dataset): def __init__(self, file_list, transformNone): self.file_list file_list self.transform transform def __len__(self): return len(self.file_list) def __getitem__(self, idx): # 读取单个样本 data load_file(self.file_list[idx]) if self.transform: data self.transform(data) return data这里的关键是__getitem__方法它只负责返回一个样本不要在里面做批处理。批处理交给DataLoader。DataLoader的配置有几个参数需要特别注意from torch.utils.data import DataLoader loader DataLoader( dataset, batch_size32, shuffleTrue, num_workers4, pin_memoryTrue, drop_lastTrue )num_workers控制并行加载的进程数设置得太小会导致GPU等数据设置得太大反而会因为进程切换开销降低效率。我的经验是设置为CPU核心数的一半左右。pin_memoryTrue会把数据锁在内存中加速CPU到GPU的传输这个在GPU训练时几乎必开。drop_lastTrue会丢弃最后一个不完整的批次避免批归一化层在批次大小为1时出错。3.3 数据增强的度什么时候该停手数据增强是提升模型泛化能力的有效手段但增强过度会引入噪声反而降低效果。我见过有人在图像分类任务上同时用了随机裁剪、随机旋转、颜色抖动、高斯噪声、随机擦除五种增强结果模型在训练集上都收敛不了。判断增强是否过度的标准很简单增强后的样本人眼还能不能正确识别出它的类别。如果一张猫的图片经过增强后你自己都看不出是猫了那这个增强就是过度的。另一个原则是增强的强度要和数据量匹配。数据量少的时候可以适当加大增强力度数据量充足的时候增强应该更保守。因为数据量本身已经提供了足够的多样性过度增强反而会破坏原始分布。提示在训练初期建议先用较弱的增强跑一遍确认模型能正常收敛再逐步加大增强力度。不要一上来就把所有增强都打开。4. 模型定义从线性层到完整网络的手动搭建4.1 为什么手写模型结构比调包更有价值用高级API定义一个模型可能只需要一行代码。但手写模型结构的过程会让你真正理解每一层的输入输出维度、参数量、计算量以及这些因素如何影响训练速度和显存占用。当你遇到显存溢出的时候只有知道每一层占了多少显存才能有针对性地优化。我建议从最简单的线性模型开始逐步增加复杂度。先写一个单层全连接网络跑通训练流程然后再加隐藏层、加激活函数、加批归一化、加Dropout。每加一个组件观察训练曲线和显存占用的变化。这个过程比直接用一个复杂模型跑通更有收获。4.2 层、激活函数、损失函数的组合逻辑一个神经网络本质上就是“线性变换 非线性激活”的堆叠。线性层负责特征提取激活函数负责引入非线性损失函数负责衡量输出和目标的差距。以分类任务为例一个典型的结构是import torch.nn as nn class SimpleClassifier(nn.Module): def __init__(self, input_dim, hidden_dim, num_classes): super().__init__() self.fc1 nn.Linear(input_dim, hidden_dim) self.bn1 nn.BatchNorm1d(hidden_dim) self.relu nn.ReLU() self.dropout nn.Dropout(0.3) self.fc2 nn.Linear(hidden_dim, num_classes) def forward(self, x): x self.fc1(x) x self.bn1(x) x self.relu(x) x self.dropout(x) x self.fc2(x) return x这里有几个设计决策需要解释。批归一化放在线性层之后、激活函数之前是因为它需要在线性变换的输出上做归一化让激活函数的输入分布更稳定。Dropout放在激活函数之后是因为它要随机丢弃已经激活的神经元防止过拟合。这些顺序不是随便定的背后都有实验依据。损失函数的选择取决于任务类型。分类任务用交叉熵损失回归任务用均方误差损失。交叉熵损失内部已经包含了Softmax操作所以模型输出层不需要再加Softmax否则会导致数值不稳定。4.3 参数量与显存占用的估算方法在训练之前你应该能估算出模型大概需要多少显存。这个能力在实际工程中非常重要因为它决定了你能用多大的批大小、需不需要做梯度累积、要不要上混合精度。估算公式大致是显存占用 参数量 × 4字节float32× 4参数、梯度、优化器状态、激活值。其中激活值的大小取决于批大小和网络深度比较难精确计算但可以用一个经验值批大小每增加一倍激活值显存增加一倍。举个例子一个参数量为1000万的模型参数本身占40MB加上梯度和优化器状态大约占160MB。如果批大小是32激活值可能占几百MB到几GB不等。这就是为什么大模型训练需要大显存。如果你发现显存不够有几个优化方向减小批大小、使用梯度累积模拟大批大小、使用混合精度训练、使用梯度检查点。这些方法各有取舍后面会详细讲。5. 训练循环手动实现反向传播与参数更新5.1 训练循环的五个核心步骤训练循环看起来复杂但拆开来看就是五个步骤的重复前向传播、计算损失、反向传播、参数更新、梯度清零。很多人用高级API习惯了反而忘了这五步的顺序和原理。手动实现的训练循环model.train() optimizer torch.optim.Adam(model.parameters(), lr1e-3) criterion nn.CrossEntropyLoss() for epoch in range(num_epochs): for batch_idx, (data, target) in enumerate(train_loader): data, target data.cuda(), target.cuda() # 1. 前向传播 output model(data) # 2. 计算损失 loss criterion(output, target) # 3. 反向传播 loss.backward() # 4. 参数更新 optimizer.step() # 5. 梯度清零 optimizer.zero_grad()这五步的顺序不能乱。梯度清零必须放在参数更新之后否则会把刚更新的梯度清掉。反向传播必须在损失计算之后因为它是从损失开始往回推导的。5.2 学习率调度与梯度裁剪的实战配置学习率是训练中最重要的超参数没有之一。设置得太小收敛慢设置得太大损失震荡甚至发散。我的经验是先用一个中等偏小的学习率跑几个epoch观察损失曲线再决定是调大还是调小。学习率调度器可以让学习率在训练过程中动态变化。常用的策略有阶梯下降、余弦退火、预热加余弦退火。对于Transformer类模型预热加余弦退火几乎是标配。对于CNN类模型阶梯下降就够用了。from torch.optim.lr_scheduler import CosineAnnealingLR scheduler CosineAnnealingLR(optimizer, T_maxnum_epochs)在每个epoch结束后调用scheduler.step()即可。梯度裁剪是防止梯度爆炸的常用手段尤其在RNN和Transformer中几乎是必须的torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)这个操作要在反向传播之后、参数更新之前执行。max_norm的值需要根据具体情况调整1.0是一个比较安全的默认值。5.3 训练过程中的监控指标与日志记录训练过程中需要监控的指标不只是损失。我通常会记录以下几项训练损失、验证损失、学习率、梯度范数、每个epoch的耗时、GPU显存占用。梯度范数特别值得关注。如果梯度范数突然变得很大说明可能出现了梯度爆炸如果一直很小说明可能出现了梯度消失。这两种情况都需要调整模型结构或训练策略。日志记录建议用TensorBoard或者WandB不要用print。print的日志在训练结束后很难分析而可视化工具可以让你直观地看到曲线变化。from torch.utils.tensorboard import SummaryWriter writer SummaryWriter(experiments/logs) writer.add_scalar(Loss/train, loss.item(), global_step) writer.add_scalar(LR, scheduler.get_last_lr()[0], global_step)注意日志目录要按实验分开不要所有实验都写到同一个目录。否则你后期根本分不清哪条曲线对应哪次实验。6. 推理部署从训练好的权重到可用的服务6.1 模型导出与格式转换的注意事项训练好的模型不能直接用于生产环境需要先导出成适合推理的格式。PyTorch提供了两种主要方式保存整个模型和只保存状态字典。我强烈建议只保存状态字典因为保存整个模型会把模型类的定义也序列化进去换一个代码环境就可能加载失败。# 保存 torch.save(model.state_dict(), model.pth) # 加载 model SimpleClassifier(input_dim, hidden_dim, num_classes) model.load_state_dict(torch.load(model.pth)) model.eval()注意加载之后要调用model.eval()这会把Dropout和批归一化层切换到推理模式。如果不调用推理结果会不稳定。如果需要更高的推理性能可以把模型导出为ONNX格式dummy_input torch.randn(1, input_dim).cuda() torch.onnx.export(model, dummy_input, model.onnx)ONNX格式的好处是跨框架、跨平台可以用ONNX Runtime加速推理。但导出过程中可能会遇到算子不支持的问题需要根据具体模型调整。6.2 批处理与动态批大小的权衡推理服务和训练最大的区别是推理的请求是动态到来的批大小不固定。如果每个请求都单独推理GPU利用率会很低如果攒一批再推理延迟又会增加。我的做法是设置一个时间窗口比如10毫秒在这个窗口内到达的请求攒成一个批次一起推理。如果窗口结束时批次还没满也直接推理。这样在延迟和吞吐之间取一个平衡。动态批大小的实现需要一个请求队列和一个调度器。调度器负责从队列中取请求、组批、调用模型、返回结果。这个逻辑用Python的异步编程可以实现但要注意GPU操作是同步的需要用线程池或者单独的推理进程来避免阻塞。6.3 推理性能的度量与优化方向推理性能的核心指标有两个延迟和吞吐。延迟是单个请求从发出到收到结果的时间吞吐是单位时间内能处理的请求数。这两个指标通常是矛盾的增大批大小可以提高吞吐但会增加延迟。优化的方向有几个第一使用混合精度推理把float32换成float16速度可以提升一倍左右精度损失很小第二使用算子融合把多个连续的操作合并成一个减少内存访问第三使用量化把float16换成int8速度更快但精度损失更大需要根据任务容忍度决定。我的一般流程是先用float32跑通测出基线延迟和吞吐然后开混合精度看提升多少如果还不够再考虑量化和算子融合。不要一上来就上最激进的优化否则出了问题很难定位。7. 踩坑实录那些文档里不会写的教训7.1 显存溢出但批大小已经调到1了怎么办这是我遇到过最棘手的问题之一。批大小已经调到1显存还是不够。这时候问题通常不在批大小而在模型本身或者数据本身。排查思路是这样的第一检查输入数据的尺寸是不是符合预期有时候数据预处理出错输入了一张超大图显存直接爆掉第二检查模型中间层的输出尺寸某一层如果维度爆炸也会导致显存溢出第三检查是不是在训练循环里累积了计算图比如没有调用zero_grad()或者把损失累加了但没有detach。我遇到过一次是因为在验证阶段没有用torch.no_grad()导致验证集的计算图一直累积几个epoch之后显存就满了。加上torch.no_grad()之后问题解决。7.2 损失不下降的六种可能原因损失不下降是新手最常遇到的问题。根据我的经验可能的原因有六种学习率太大或太小、数据没有归一化、标签格式不对、模型初始化有问题、损失函数选错了、梯度没有回传。排查顺序建议从简单到复杂先检查数据和标签用几个样本手动算一下损失看是否合理再检查学习率试着调大或调小一个数量级然后检查梯度打印几个参数的梯度值看是不是全零或者超大最后检查模型结构确认每一层的输入输出维度匹配。我印象最深的一次是因为标签没有转成long类型交叉熵损失内部报错但被吞掉了损失一直不变。把标签转成long之后立刻正常。7.3 多卡训练时的常见同步问题多卡训练可以加速但也会引入同步问题。最常见的是批归一化层的统计量在多卡之间不同步导致训练不稳定。解决办法是用SyncBatchNorm替换普通的BatchNorm。另一个问题是随机种子。多卡训练时每张卡上的数据增强如果用了不同的随机种子会导致每个epoch的数据分布不一致。解决办法是在DataLoader的worker_init_fn里设置种子确保可复现。还有一个坑是保存模型时只保存了主卡的参数其他卡的参数没有同步。如果用DistributedDataParallel保存的时候要用model.module.state_dict()而不是model.state_dict()。8. 从能跑到跑好工程化收尾的几件事8.1 配置管理别再硬编码超参数了硬编码超参数是项目从实验走向工程的最大障碍。我见过太多项目学习率、批大小、模型维度全部写在代码里想换一个配置就得改代码、重新提交、重新跑。正确的做法是用配置文件管理所有超参数。我习惯用YAML格式因为可读性好支持嵌套结构model: input_dim: 784 hidden_dim: 256 num_classes: 10 train: batch_size: 32 lr: 0.001 epochs: 50然后在代码里用argparse或者omegaconf加载配置。这样切换实验只需要换一个配置文件代码完全不用动。8.2 实验复现种子、版本、日志三件套实验复现是工程能力的重要体现。要做到复现需要控制三个东西随机种子、依赖版本、完整日志。随机种子要覆盖Python、NumPy、PyTorch三个层面import random import numpy as np import torch def set_seed(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)依赖版本要记录在requirements.txt里最好精确到小版本号。日志要记录每次实验的配置、开始时间、结束时间、最终指标。这样当你想复现三个月前的一次实验时才能找到完整的上下文。8.3 代码审查清单上线前必须检查的项在把代码交给别人或者部署到生产之前我会过一遍这个清单检查项说明随机种子是否设置了全局种子设备管理是否显式指定了cuda或cpu异常处理数据加载失败时是否有兜底日志级别生产环境是否关闭了debug日志模型保存是否只保存了state_dict推理模式推理前是否调用了eval()梯度关闭推理时是否用了no_grad()输入校验是否检查了输入维度这个清单看起来简单但每一条我都见过有人踩坑。尤其是最后一条输入维度不匹配是线上服务最常见的故障原因之一。8.4 后续可以扩展的方向这套从零搭建的框架跑通之后你可以往几个方向继续深入。第一个方向是分布式训练把单卡扩展到多卡甚至多机这需要理解数据并行和模型并行的区别。第二个方向是模型压缩包括剪枝、量化、知识蒸馏让模型能在边缘设备上运行。第三个方向是自动化调参用贝叶斯优化或者进化算法自动搜索最优超参数。我个人在实际操作中的体会是从零搭建的过程虽然慢但每一步都踩实了后面遇到问题排查起来会快很多。那些直接调包的人遇到报错往往只能搜索或者问人而你知道每一行代码在做什么定位问题的速度完全不是一个量级。