1. 从零搭建AI工程能力为什么大多数人卡在“环境”这一步“ai-engineering-from-scratch”这个标题我第一次看到的时候脑子里蹦出来的不是某个具体框架而是一连串被环境问题折磨的深夜。你可能也有类似经历兴致勃勃想跑一个开源模型结果卡在CUDA版本不匹配好不容易装好了PyTorch发现numpy又冲突了换了一台机器之前跑通的代码直接报错。这些事听起来琐碎但它们恰恰是AI工程从零开始时最真实的门槛。所谓“from scratch”不是让你从汇编语言开始写矩阵乘法而是说你要有能力从一台干净的机器出发把一套能训练、能推理、能部署的AI工程链路完整搭起来。这件事的价值在于当你理解了每一层依赖为什么存在、每个组件解决什么问题后面无论换什么模型、换什么硬件你都能快速迁移。适合读这篇内容的人是那些已经会写Python、跑过几个notebook但一到“把东西放到真实环境里跑”就心里没底的朋友。我见过太多人把AI工程等同于调包和调参。调包当然重要但真正的工程能力体现在你知道什么时候该用conda而不是pip知道为什么Docker镜像要分层构建知道推理服务为什么要做动态批处理。这些判断力不是看几篇教程就能获得的它来自你亲手搭过、踩过、修过的完整过程。接下来的内容我会按照一个真实的从零搭建路径来展开每一步都告诉你为什么这么做以及我实际踩过的坑。2. 硬件与系统层别急着装框架先把地基看清楚2.1 显卡选型不是越贵越好要看你的任务形态很多人一上来就问“买什么显卡”这个问题其实没有标准答案因为AI工程的任务形态差异太大了。如果你主要做的是小规模微调或者推理一张显存24GB的消费级卡就够用如果你要训练大语言模型那显存带宽和卡间互联才是关键。我自己的经验是先明确你的任务属于哪一类推理为主显存容量优先计算精度支持FP16/INT8即可不需要太在意卡间互联。小规模微调显存容量和带宽都要看至少24GB起步否则连7B模型的全量微调都跑不起来。大规模训练这时候单卡已经不够了要考虑多卡互联方案NVLink的有无会直接决定训练效率。这里有个容易被忽略的点显卡的驱动版本和CUDA版本是绑定的。你装了最新的驱动可能反而导致某些旧版框架无法使用。我的做法是先确定你要用的框架版本再反推需要的CUDA版本最后选择满足这个CUDA版本的最低驱动版本。这样做的原因是驱动越新兼容性反而可能越差尤其是当你需要复现一些较老的实验时。2.2 操作系统的选择Ubuntu LTS是省心之选在操作系统层面我强烈建议用Ubuntu的LTS版本。原因很实际绝大多数AI框架的官方文档和社区讨论都是基于Ubuntu的你遇到问题时搜索到的解决方案大概率能直接套用。Windows虽然也能跑但WSL2的性能损耗和路径问题会让你在调试时多花很多时间。macOS的M系列芯片在推理上表现不错但训练生态还是不如NVIDIA CUDA成熟。安装系统时有一个细节值得注意分区的时候给/home留足够空间。AI工程中数据集和模型权重动辄几十上百GB如果/home分区太小后面迁移数据会很麻烦。我一般建议/home至少留500GB如果做计算机视觉1TB也不嫌多。2.3 驱动安装用官方runfile还是系统包管理驱动安装有两种主流方式用系统包管理器如apt安装或者用NVIDIA官方提供的runfile安装。我的经验是如果你不打算频繁切换驱动版本用apt最省事如果你需要特定版本的驱动来匹配某个CUDA版本runfile更灵活。用apt安装的命令大致是这样的sudo apt update sudo apt install nvidia-driver-535安装完成后用nvidia-smi验证。这里有个坑如果你之前装过runfile版本的驱动直接再用apt装会冲突。正确的做法是先彻底卸载旧驱动重启后再装新的。卸载命令是sudo apt purge nvidia-* sudo apt autoremove重启后确认nvidia-smi已经找不到命令再安装新驱动。这个顺序不能反否则会出现驱动加载失败但系统又认为驱动已安装的尴尬状态。3. Python环境管理conda、venv还是Docker3.1 为什么我最终选择了conda加pip的混合方案Python环境管理是AI工程里最容易让人抓狂的部分。venv轻量但处理不了非Python依赖conda能管理CUDA、cuDNN这些二进制依赖但有时候又和pip装的包冲突Docker最干净但学习曲线陡峭而且GPU透传需要额外配置。我自己的选择是用conda创建基础环境用pip安装AI框架。具体来说conda负责管理Python版本和CUDA相关的底层库pip负责安装PyTorch、Transformers这些上层框架。这样做的原因是conda的CUDA包经过测试兼容性有保障而pip上的AI框架更新更快版本选择更丰富。创建环境的命令conda create -n aieng python3.10 conda activate aieng然后安装PyTorch时去官网找到对应CUDA版本的pip安装命令直接复制执行。不要用conda install pytorch因为conda源的PyTorch版本往往滞后而且和pip混装时容易出问题。3.2 依赖冲突的排查思路从报错信息反推依赖冲突是家常便饭。最常见的报错是ImportError: cannot import name xxx from yyy这通常意味着你装的yyy版本太老或太新。我的排查步骤是这样的先看报错涉及的包名和版本号。用pip show 包名查看当前版本。去这个包的官方文档或GitHub release页面确认你用的框架版本需要哪个范围的依赖版本。用pip install 包名版本号锁定版本。这里有个技巧如果你不确定该用哪个版本可以先用pip install 包名装最新版然后看报错是否消失。如果消失说明是版本太老的问题如果报错变了再根据新报错继续排查。这个过程可能需要几轮但比盲目搜索快得多。3.3 环境导出与复现requirements.txt不够用的时候pip freeze requirements.txt是常规操作但它有个问题它会把所有间接依赖都写进去导致在不同平台上复现时出现平台相关的包冲突。更好的做法是只导出你直接依赖的包用pipreqs这个工具可以做到pip install pipreqs pipreqs . --force它会扫描你的代码只导出实际import的包。但即便如此AI工程的环境复现仍然很难做到100%一致因为CUDA版本、驱动版本、甚至CPU指令集都可能影响结果。所以我现在更倾向于用Docker来固化环境后面会详细说。4. 框架选型PyTorch、TensorFlow还是JAX4.1 从社区生态和调试体验做决定2024年这个时间点如果你问我推荐哪个框架我会说除非你有明确的理由用TensorFlow或JAX否则选PyTorch。原因不是PyTorch在技术上全面领先而是它的社区生态和调试体验对从零开始的人最友好。PyTorch的动态图机制让你可以在代码里直接print张量、用pdb打断点这对理解模型内部发生了什么至关重要。TensorFlow的静态图虽然在大规模部署上有优势但调试起来需要额外的心智负担。JAX在科研领域很流行函数式编程的风格很优雅但它的生态还不如PyTorch成熟遇到问题时可参考的案例少。4.2 安装PyTorch时最容易搞错的三个参数安装PyTorch时官网会给你一个命令里面有三个关键参数torch版本、CUDA版本、Python版本。这三个必须和你的环境匹配否则装上了也跑不起来。torch版本不要盲目追新选一个稳定版即可。比如2.1.0就是一个经过充分测试的版本。CUDA版本用nvcc --version或nvidia-smi查看你的CUDA版本。注意nvidia-smi显示的是驱动支持的最高CUDA版本不是你实际安装的CUDA版本。实际安装的版本用nvcc --version看。Python版本PyTorch对Python版本有要求比如2.1.0支持Python 3.8到3.11。用太新的Python可能没有预编译的wheel。一个常见的错误是nvidia-smi显示CUDA 12.2你就去装CUDA 12.2的PyTorch但你的nvcc其实是11.8。这种情况下PyTorch会找不到CUDA。正确的做法是以nvcc --version为准。4.3 验证安装是否真正可用不只是import装完PyTorch后很多人只跑一句import torch就以为成功了。这不够。你还需要验证CUDA是否可用import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))如果is_available()返回False说明CUDA没配好。这时候先检查nvcc和PyTorch的CUDA版本是否一致再检查驱动版本是否满足要求。还有一个容易被忽略的点如果你在Docker里跑需要确保容器启动时加了--gpus all参数否则容器内看不到GPU。5. 数据管道从原始文件到训练可用的张量5.1 数据集加载的性能瓶颈在哪里AI工程中数据加载往往是第一个性能瓶颈。很多人模型训练慢第一反应是模型太大但实际上可能是数据管道拖了后腿。一个典型场景是你用PIL逐张读取图片然后在Python里做增强最后转成张量。这个过程是单线程的GPU大部分时间在等数据。解决思路是用多进程预取。PyTorch的DataLoader提供了num_workers参数设置成CPU核心数的一半到一倍之间通常比较合适。但num_workers不是越大越好因为每个worker都会复制一份数据集对象内存开销会线性增长。我的经验是先用num_workers4试如果GPU利用率还是上不去再逐步增加。5.2 数据增强该放在CPU还是GPU数据增强的位置选择会影响整体吞吐。放在CPU端在Dataset的__getitem__里做的好处是灵活可以用各种Python库放在GPU端在模型forward之前做的好处是快因为GPU并行能力强。我的建议是简单增强如归一化、缩放放在GPU端用torchvision.transforms的GPU版本或kornia库。复杂增强如随机裁剪、颜色抖动放在CPU端用albumentations库它比torchvision快不少。这里有个细节如果你用albumentations记得在__getitem__里把numpy数组转成张量之前做增强因为albumentations处理numpy数组比处理张量快。5.3 数据版本管理别再用文件名区分了“数据最终版”、“数据最终版2”、“数据真的最终版”——这种命名方式在AI工程里是灾难。你永远不知道哪个版本对应哪次实验。我的做法是用DVCData Version Control来管理数据集。它和Git类似但专门为大文件设计。基本用法dvc init dvc add data/train git add data/train.dvc .gitignore git commit -m add training data这样数据文件本身不进入Git但它的哈希值和版本信息被记录在.dvc文件里。切换分支时用dvc checkout就能拿到对应版本的数据。这个习惯一旦养成实验复现会轻松很多。6. 训练循环从能跑到跑得好之间隔着什么6.1 混合精度训练省显存也省时间混合精度训练AMP是我强烈建议从第一天就开启的功能。它让模型在FP16和FP32之间自动切换显存占用能减少30%到50%训练速度也能提升。PyTorch里的用法很简单from torch.cuda.amp import autocast, GradScaler scaler GradScaler() for data, target in dataloader: optimizer.zero_grad() with autocast(): output model(data) loss loss_fn(output, target) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()这里的关键是GradScaler它负责在反向传播时放大梯度防止FP16下梯度下溢。如果你忘了用scalerloss可能会变成NaN。6.2 梯度累积小显存跑大batch的实用技巧显存不够但你想用大batch size怎么办梯度累积可以解决。它的思路是多次前向传播累积梯度然后再更新一次参数。这样等效于大batch但显存占用不变。代码上就是在loss.backward()之前不zero_grad()累积N次后再更新accumulation_steps 4 for i, (data, target) in enumerate(dataloader): output model(data) loss loss_fn(output, target) / accumulation_steps loss.backward() if (i 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()注意loss要除以accumulation_steps否则梯度会放大N倍。这个技巧在微调大模型时特别有用。6.3 检查点保存不只是保存模型权重保存检查点时只存model.state_dict()是不够的。你还需要保存优化器状态、学习率调度器状态、当前epoch数。否则恢复训练时优化器的动量信息丢失训练曲线会出现抖动。完整的保存逻辑checkpoint { epoch: epoch, model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: scheduler.state_dict(), loss: loss, } torch.save(checkpoint, fcheckpoint_epoch_{epoch}.pt)恢复时对应加载。这个习惯能帮你省下大量重训时间。7. 推理部署模型跑通只是开始7.1 推理框架选型ONNX、TensorRT还是原生PyTorch模型训练完下一步是部署。这时候你会面临选择用原生PyTorch直接推理还是转成ONNX或TensorRT我的经验是原生PyTorch适合快速验证和低并发场景部署最简单但性能一般。ONNX跨平台好支持多种推理引擎适合需要灵活部署的场景。TensorRTNVIDIA平台上的性能王者但转换过程可能遇到不支持的算子。选择依据是你的延迟要求和硬件环境。如果只是内部工具原生PyTorch就够了如果是对外服务TensorRT能带来数倍的吞吐提升。7.2 动态批处理提升GPU利用率的关键推理服务中请求是逐个到达的。如果每个请求都单独推理GPU利用率会很低。动态批处理Dynamic Batching的思路是把短时间内到达的多个请求合并成一个batch一起推理。这样GPU的并行能力被充分利用吞吐量能提升几倍甚至十几倍。实现动态批处理可以用Triton Inference Server它内置了这个功能。你只需要配置一个模型仓库Triton会自动处理请求的合并和分发。配置文件中关键的一项是max_batch_size它决定了单个batch最多合并多少请求。设置太小吞吐上不去设置太大延迟会增加。需要根据你的延迟要求做权衡。7.3 模型量化INT8到底损失了多少精度量化是另一个提升推理速度的手段。把FP32的权重和激活值转成INT8模型大小减少75%推理速度提升2到4倍。但精度损失是不可避免的。我的做法是先用FP32跑一遍验证集记录基线精度。用PyTorch的torch.quantization做动态量化再跑验证集。对比精度下降是否在可接受范围内通常1%以内可以接受。如果下降太多尝试量化感知训练QAT在训练时模拟量化误差。这里有个坑不是所有层都适合量化。比如LayerNorm和Softmax对精度敏感通常保持FP32。PyTorch的量化API允许你指定哪些层不量化需要根据模型结构做调整。8. 工程化收尾日志、监控与持续迭代8.1 实验跟踪别再用Excel记结果了AI工程中实验数量很容易失控。今天调了学习率明天换了数据增强后天改了模型结构。如果没有系统的跟踪工具你很快就会忘记哪个配置对应哪个结果。我用的是Weights Biaseswandb它能在训练过程中自动记录loss曲线、超参数、甚至模型梯度的分布。集成方式很简单import wandb wandb.init(projectmy-ai-project, config{ learning_rate: 1e-4, batch_size: 32, architecture: ResNet50 }) for epoch in range(epochs): # training loop wandb.log({loss: loss, accuracy: acc})这样每次实验都有记录对比不同配置的效果时一目了然。如果不想用在线服务TensorBoard是本地替代方案但功能相对基础。8.2 日志分级DEBUG、INFO、WARNING该怎么用日志是排查线上问题的生命线。但很多人要么不打日志要么把所有信息都打成INFO导致日志文件爆炸。我的分级原则是DEBUG详细的中间变量只在开发阶段开启。INFO关键流程节点如“开始训练”、“模型保存完成”。WARNING不影响运行但需要注意的情况如“学习率过低”。ERROR导致流程中断的问题如“CUDA out of memory”。用Python的logging模块配置import logging logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(training.log), logging.StreamHandler() ] )这样日志同时输出到文件和控制台方便调试和回溯。8.3 模型版本管理从v1到v2之间发生了什么模型上线后迭代是必然的。但如果没有版本管理你很快会搞不清线上跑的是哪个模型。我的做法是给每个模型打上版本号并记录训练数据版本、超参数、评估指标。可以用MLflow来管理mlflow models serve -m runs:/run_id/model -p 5000这样每个模型都有唯一的run_id对应完整的训练记录。回滚时只需要切换到之前的run_id即可。这个习惯在模型效果突然下降时特别有用你能快速定位是数据问题还是模型问题。9. 我踩过的三个印象最深的坑第一个坑是CUDA版本和PyTorch版本不匹配。当时nvidia-smi显示CUDA 11.7我就装了对应版本的PyTorch但nvcc其实是11.3。结果torch.cuda.is_available()一直返回False。排查了半天才发现是nvcc和nvidia-smi显示的版本不一致。教训是以nvcc --version为准不是nvidia-smi。第二个坑是DataLoader的num_workers设置过大。我一开始设成16结果内存直接爆了。原因是每个worker都会复制一份数据集对象我的数据集加载了全部图片路径到内存16个worker就是16倍内存。后来改成4问题解决。教训是num_workers不是越大越好要结合数据集大小和内存容量来定。第三个坑是模型保存时只存了state_dict。有一次训练到一半机器断电恢复时发现优化器状态丢了训练曲线剧烈抖动花了很久才恢复。后来我养成了保存完整checkpoint的习惯包括优化器、调度器、epoch数。这个习惯帮我省下了至少两次重训的时间。10. 从零到一之后下一步往哪走当你把上面这些环节都跑通一遍你其实已经具备了AI工程的核心能力。但“from scratch”不是一个终点而是一个起点。接下来你可以往几个方向深入一是性能优化研究如何用TensorRT、CUDA Graph把推理延迟压到极致二是分布式训练学习DDP、FSDP这些并行策略把训练扩展到多卡多机三是MLOps把实验跟踪、模型部署、监控告警串成自动化流水线。我自己的体会是AI工程最迷人的地方在于它要求你同时具备软件工程的严谨和机器学习的直觉。你既要写出可维护的代码又要理解模型为什么有效。这两者的结合点就是“from scratch”真正要培养的能力。别急着追求最新最炫的模型先把这套基础链路搭稳后面无论技术怎么变你都有能力快速跟上。
