1. 从零构建AI工程能力为什么“手搓一遍”比调包更值钱这两年AI应用开发的门槛肉眼可见地降低了。一个刚入行的开发者借助现成的框架和API半天就能搭出一个能跑通的对话机器人。但如果你真的在团队里带过人或者自己经历过从“能跑”到“能扛住线上流量”的完整过程就会发现一个很尴尬的事实大部分所谓的AI工程能力其实是框架能力不是你的能力。我见过太多这样的情况——模型效果不好第一反应是换个更大的模型推理速度慢第一反应是加机器显存爆了第一反应是减小batch size然后祈祷。这些操作本身没错但如果你不知道背后的显存是怎么算出来的、推理延迟到底卡在哪一环、量化到底损失了什么那你永远只能停留在“调参侠”的层面。ai-engineering-from-scratch这个方向之所以值得认真对待是因为它逼着你去面对那些被框架封装掉的细节。从张量的内存布局到注意力机制的计算复杂度再到推理引擎的调度策略这些东西你亲手实现一遍和只看文档是完全不同的体验。就像学开车你可以直接上路但如果你连离合和变速箱的原理都不清楚遇到陡坡起步就会慌。这篇文章适合两类人一类是有一定Python和深度学习基础但一直停留在“调包”层面想真正理解AI系统底层运作机制的开发者另一类是在实际项目中遇到了性能瓶颈发现光靠调API解决不了问题需要从工程角度重新审视整个链路的工程师。我会从最基础的环境搭建讲起一路走到推理优化和部署把每个环节的“为什么”和“怎么做”都掰开揉碎。提示这篇文章不会教你如何调用某个具体框架的API而是聚焦于那些跨框架通用的底层原理和工程实践。你学到的知识换一个框架依然能用。2. 环境搭建别急着装CUDA先把这几个概念理清楚2.1 为什么你的环境总是配不对新手配深度学习环境十有八九会卡在版本兼容性上。CUDA版本、cuDNN版本、PyTorch版本、Python版本这四个东西之间的依赖关系像一张蜘蛛网。我见过有人为了跑一个demo重装了三次系统。问题的根源在于很多人是“照着教程一步步敲命令”而不是理解每个组件到底在干什么。CUDA是NVIDIA的并行计算平台它让你的代码能跑在GPU上cuDNN是专门为深度学习优化的加速库卷积、池化这些操作都靠它PyTorch是上层框架它调用CUDA和cuDNN来完成计算。三者是层层依赖的关系。我的建议是先确定PyTorch版本然后反推CUDA和cuDNN版本。比如你要用PyTorch 2.1它官方支持CUDA 11.8和12.1那你就去NVIDIA官网下载对应的CUDA Toolkit再下载匹配的cuDNN。不要反过来先装一个最新的CUDA 12.4然后发现PyTorch还不支持又折腾着降级。# 查看当前CUDA版本 nvcc --version # 查看GPU信息 nvidia-smi # 查看PyTorch是否能用GPU python -c import torch; print(torch.cuda.is_available())还有一个容易被忽略的点Python环境隔离。我强烈建议用conda或者venv给每个项目建独立环境。原因很简单不同项目依赖的库版本可能冲突全局安装迟早会出问题。conda的好处是它能帮你管理CUDA Toolkit的版本不需要在系统层面装一堆东西。2.2 显存到底被谁吃了环境配好之后第一个让人困惑的问题往往是为什么我的模型一跑就OOMOut of Memory明明参数量看起来不大。这里需要建立一个基本的显存账本。模型训练时的显存占用主要来自四部分模型参数、梯度、优化器状态、中间激活值。前三个是固定的中间激活值则和batch size、序列长度直接相关。举个例子一个7B参数的模型用FP16精度存储光参数就要占14GB。训练时梯度也是FP16再加14GB。如果用Adam优化器它需要保存一阶矩和二阶矩通常是FP32精度那就是7B × 4字节 × 2 56GB。加起来已经84GB了还没算激活值。所以7B模型全量微调没有几张A100是搞不定的。这也是为什么现在流行LoRA、QLoRA这些参数高效微调方法——它们只训练一小部分参数优化器状态大幅减少显存需求直接降一个数量级。理解了这个账本你就知道该往哪个方向优化了。注意torch.cuda.memory_allocated()和torch.cuda.max_memory_allocated()是你排查显存问题的好帮手前者看当前占用后者看峰值占用。2.3 一个最小可用的工程目录结构很多人写AI项目所有代码堆在一个文件里跑通了就不管了。等到要复现或者迁移的时候自己都看不懂。从工程角度我建议从一开始就养成好习惯project/ ├── configs/ # 配置文件 ├── data/ # 数据相关 │ ├── raw/ │ └── processed/ ├── src/ │ ├── data/ # 数据加载和预处理 │ ├── models/ # 模型定义 │ ├── training/ # 训练循环 │ ├── inference/ # 推理逻辑 │ └── utils/ # 工具函数 ├── experiments/ # 实验记录 ├── notebooks/ # 探索性分析 └── requirements.txt这个结构的好处是职责清晰。模型定义归模型定义训练逻辑归训练逻辑推理部署归推理部署。当你需要把训练好的模型部署到生产环境时只需要拿走models和inference两个目录不用在一堆训练代码里大海捞针。3. 张量与自动求导亲手实现一遍才算真正理解3.1 张量不只是多维数组PyTorch的Tensor和NumPy的ndarray看起来很像但有一个本质区别Tensor可以跑在GPU上并且支持自动求导。这两个能力是深度学习框架的基石。从工程角度看你需要理解张量的几个关键属性shape形状、dtype数据类型、device设备、requires_grad是否需要梯度。这四个属性决定了这个张量能做什么运算、占用多少显存、在哪个设备上计算。我建议你亲手写一段代码创建一个张量然后做各种操作观察它的属性变化。比如import torch # 创建一个需要梯度的张量 x torch.tensor([1.0, 2.0, 3.0], requires_gradTrue) print(x.shape, x.dtype, x.device, x.requires_grad) # 做一次运算 y x ** 2 z y.sum() # 反向传播 z.backward() print(x.grad) # 输出 dz/dx 2x这段代码虽然简单但它展示了自动求导的核心流程前向计算构建计算图反向传播沿计算图求梯度。理解了这个流程你才能明白为什么有时候需要detach()为什么有时候需要with torch.no_grad()。3.2 计算图是怎么构建和释放的PyTorch采用动态计算图每次前向传播都会重新构建计算图。这带来了灵活性但也意味着如果你不小心保留了中间变量计算图就不会释放显存会持续增长。一个典型的坑是在训练循环里把loss累加到列表里# 错误做法 losses [] for batch in dataloader: loss model(batch) losses.append(loss) # loss还带着计算图显存不会释放 loss.backward() optimizer.step()正确的做法是只记录数值# 正确做法 losses [] for batch in dataloader: loss model(batch) losses.append(loss.item()) # 只取数值断开计算图 loss.backward() optimizer.step()这个细节在训练小模型时可能感觉不到但训练大模型时几轮下来显存就爆了。我当初踩这个坑的时候排查了半天才发现是日志记录的问题。3.3 从零实现一个线性回归要真正理解自动求导最好的方式是手动实现一个简单的线性回归不用nn.Linear而是自己定义参数和计算过程。import torch # 生成数据 X torch.randn(100, 1) true_w torch.tensor([[2.0]]) true_b torch.tensor([1.0]) y X true_w true_b torch.randn(100, 1) * 0.1 # 手动初始化参数 w torch.randn(1, 1, requires_gradTrue) b torch.zeros(1, requires_gradTrue) # 训练循环 lr 0.01 for epoch in range(100): # 前向 y_pred X w b loss ((y_pred - y) ** 2).mean() # 反向 loss.backward() # 更新参数注意要暂停梯度追踪 with torch.no_grad(): w - lr * w.grad b - lr * b.grad w.grad.zero_() b.grad.zero_() if epoch % 20 0: print(fEpoch {epoch}, Loss: {loss.item():.4f})这段代码虽然简单但它包含了训练的所有核心要素前向计算、损失计算、反向传播、参数更新、梯度清零。你亲手写一遍比看十遍文档都管用。4. 模型训练的核心工程问题不只是调参4.1 数据加载为什么成了瓶颈很多人优化模型性能时只盯着GPU利用率却忽略了数据加载这个隐形杀手。我见过一个案例模型本身计算只需要50毫秒但数据加载花了200毫秒GPU大部分时间在等数据。PyTorch的DataLoader有几个关键参数num_workers、pin_memory、prefetch_factor。num_workers决定了用几个进程加载数据设置得太小会来不及设置得太大反而会因为进程切换开销降低效率。经验值是设置为CPU核心数的一半左右但具体要看数据预处理的复杂度。pin_memoryTrue会把数据加载到锁页内存这样从CPU传到GPU会更快。这个参数在GPU训练时几乎总是应该开启。还有一个容易被忽略的点数据预处理的位置。如果你在__getitem__里做复杂的图像增强那每个worker都在重复计算。更好的做法是离线预处理一次或者用GPU做增强。4.2 混合精度训练省显存还能提速混合精度训练的核心思想是前向和反向用FP16计算参数更新用FP32。这样既能利用FP16的计算速度又能保持FP32的数值稳定性。PyTorch提供了torch.cuda.amp来自动管理这个过程from torch.cuda.amp import autocast, GradScaler scaler GradScaler() for batch in dataloader: optimizer.zero_grad() with autocast(): output model(batch) loss criterion(output, target) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()GradScaler的作用是放大loss防止FP16下梯度下溢。这个机制很巧妙但如果你不理解它的原理遇到NaN loss的时候就会一头雾水。实测下来混合精度训练通常能省30%-50%的显存速度提升20%-30%。但要注意不是所有操作都适合FP16比如softmax、layer norm这些对数值范围敏感的操作通常需要保持FP32。4.3 梯度累积小显存跑大batch当你只有一张消费级显卡但需要大batch size来稳定训练时梯度累积是一个实用的技巧。它的原理很简单多次前向反向累积梯度然后一次性更新参数。accumulation_steps 4 for i, batch in enumerate(dataloader): output model(batch) loss criterion(output, target) / accumulation_steps loss.backward() if (i 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()注意loss要除以累积步数这样梯度的量级才和真实大batch一致。这个技巧在微调大模型时特别有用我经常用它在单卡上模拟多卡的大batch效果。4.4 学习率调度什么时候该降降多少学习率是最重要的超参数没有之一。但很多人设了一个固定值就不管了。实际上好的学习率调度能让训练效果提升一个档次。常见的调度策略有StepLR每隔固定步数降一次、CosineAnnealingLR余弦退火、OneCycleLR先升后降。我个人的经验是微调任务用CosineAnnealing比较稳从零训练用OneCycle收敛更快。还有一个实用技巧是warmup在训练初期用很小的学习率逐渐升到设定值。这是因为模型初始参数是随机的直接大学习率容易训崩。warmup通常占总步数的5%-10%。from torch.optim.lr_scheduler import CosineAnnealingLR, LinearLR, SequentialLR warmup LinearLR(optimizer, start_factor0.1, total_iters100) cosine CosineAnnealingLR(optimizer, T_max900) scheduler SequentialLR(optimizer, [warmup, cosine], milestones[100])5. 推理优化从能跑到跑得快5.1 推理和训练到底有什么不同训练时我们关心的是梯度能不能算对、loss能不能降下去推理时我们关心的是延迟、吞吐、显存占用。这两个场景的优化目标完全不同。推理时不需要计算梯度所以可以关掉自动求导用torch.no_grad()或者torch.inference_mode()。后者比前者更彻底它连版本计数都不记录速度更快。另一个关键区别是batch size。训练时batch size影响梯度质量推理时batch size影响吞吐和延迟。在线服务通常batch size1追求低延迟离线批处理可以大batch追求高吞吐。这两种场景的优化策略完全不同。5.2 模型量化用精度换速度量化是把模型的权重和激活值从FP32/FP16降到INT8甚至INT4从而减少显存占用和计算量。常见的量化方法有量化方式精度显存节省适用场景FP16高50%通用推理INT8中75%对精度要求不极端的场景INT4低87.5%大模型边缘部署量化的核心挑战是精度损失。训练后量化PTQ简单但精度损失大量化感知训练QAT精度好但需要重新训练。实践中INT8量化通常能保持99%以上的精度INT4则需要更精细的处理。我实测过一个7B模型FP16推理需要14GB显存INT8量化后只要7GBINT4只要3.5GB。速度方面INT8在支持INT8指令的GPU上能快1.5-2倍。5.3 KV Cache自回归生成的加速利器自回归生成时每生成一个token都要重新计算之前所有token的注意力。这导致计算量随序列长度平方增长。KV Cache的思路是把之前计算过的Key和Value缓存起来生成新token时只计算当前token的Query然后和缓存的KV做注意力。这个优化能把生成复杂度从O(n²)降到O(n)。但KV Cache也占显存序列越长占用越大。对于长文本生成KV Cache可能比模型本身还占显存。# 简化的KV Cache逻辑 class AttentionWithKVCache: def __init__(self): self.cache_k None self.cache_v None def forward(self, x, use_cacheTrue): q, k, v self.compute_qkv(x) if use_cache and self.cache_k is not None: k torch.cat([self.cache_k, k], dim1) v torch.cat([self.cache_v, v], dim1) if use_cache: self.cache_k k self.cache_v v return self.attention(q, k, v)5.4 批处理与动态填充在线服务中请求是陆续到达的。如果每个请求单独处理GPU利用率很低。批处理是把多个请求攒在一起同时推理提高吞吐。但不同请求的输入长度不同直接padding到最大长度会浪费计算。动态填充dynamic padding是按batch内最长序列填充而不是全局最大长度。更进一步的优化是连续批处理continuous batching它允许新请求随时加入正在处理的batch不用等当前batch全部完成。这些优化在vLLM、TensorRT-LLM这些推理引擎里都有实现。理解它们的原理你才能根据实际场景选择合适的方案。6. 部署与监控模型上线只是开始6.1 从checkpoint到服务的完整链路训练好的模型要变成可用的服务中间还有不少工作。首先是模型导出把PyTorch的checkpoint转成推理引擎能识别的格式比如ONNX、TensorRT。然后是服务封装用FastAPI或者gRPC暴露接口。最后是容器化用Docker打包环境Kubernetes做编排。这个链路里每一步都有坑。比如ONNX导出时动态轴设置不对会导致变长输入失败TensorRT构建引擎时优化级别选太高可能导致精度下降Docker镜像里CUDA版本和宿主机不匹配会直接跑不起来。我的建议是先在本地把整个链路跑通再上生产环境。本地跑通意味着你能控制所有变量出了问题好排查。直接上生产环境出了问题你连日志都看不全。6.2 监控什么指标怎么告警模型服务上线后你需要监控三类指标系统指标GPU利用率、显存占用、CPU负载、服务指标QPS、延迟P50/P99、错误率、业务指标生成质量、用户反馈。系统指标帮你判断资源是否够用服务指标帮你发现性能瓶颈业务指标帮你评估模型效果。这三类指标缺一不可。告警策略上我建议对P99延迟和错误率设硬阈值超过就告警。GPU利用率可以设软阈值持续高于90%就考虑扩容。业务指标通常需要人工审核不适合自动告警。提示延迟指标一定要看P99而不是平均值。平均值会掩盖长尾请求而用户体验往往由最慢的那1%决定。6.3 版本管理与回滚模型更新比代码更新更复杂因为模型文件大、加载慢、效果评估周期长。我见过团队直接覆盖线上模型文件结果新模型效果不好想回滚发现旧文件已经被删了。正确的做法是每次模型更新都保留完整版本用版本号区分。上线新版本时先小流量灰度观察指标正常后再全量。如果出问题一键切回旧版本。模型版本管理可以用MLflow、DVC这些工具也可以简单地用文件系统加命名规范。关键是要有记录这个版本是什么时候训练的、用了什么数据、评估指标是多少、谁批准的。7. 那些只有踩过才知道的坑7.1 随机种子不是万能的设置随机种子能让实验可复现但很多人不知道的是即使设置了种子不同GPU型号、不同CUDA版本、不同框架版本的结果也可能不同。这是因为某些CUDA操作的实现细节会随版本变化导致浮点运算顺序不同最终结果有微小差异。所以如果你要严格复现一个实验除了设置种子还要固定硬件和软件环境。如果只是对比不同模型结构那点微小差异通常不影响结论。import torch import numpy as np import random def set_seed(seed42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark False注意deterministicTrue会降低性能因为cuDNN不能用一些非确定性的快速算法。所以只在需要严格复现时开启日常训练可以关掉。7.2 数据泄漏比你想的更常见数据泄漏是指训练数据里包含了测试数据的信息导致评估指标虚高。常见的泄漏场景包括预处理时用了全量数据的统计量、时间序列数据随机划分、同一用户的数据同时出现在训练集和测试集。我见过一个案例团队做文本分类预处理时用全量数据计算了词表的IDF权重然后划分训练测试集。结果测试集的指标比实际高了10个点上线后效果大打折扣。避免数据泄漏的原则是任何用到数据的操作都要在训练集上拟合然后应用到测试集。标准化、归一化、词表构建、特征选择统统如此。7.3 显存碎片化为什么重启能解决问题有时候你会遇到这种情况明明显存还有剩余但就是分配不出来报OOM。这通常是显存碎片化导致的。PyTorch的显存分配器会缓存已释放的显存块以便快速重用。但如果请求的显存块大小和缓存的不匹配就会产生碎片。长时间运行的服务容易出现这个问题。解决方案有几个设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True让分配器更灵活定期重启服务或者用torch.cuda.empty_cache()手动清理缓存但注意这会影响性能。7.4 模型保存的坑state_dict还是整个模型PyTorch保存模型有两种方式保存整个模型对象或者只保存state_dict。我强烈建议只保存state_dict。原因是保存整个模型会把模型类的定义也序列化进去。如果之后你修改了模型类的代码加载旧模型就会失败。而state_dict只包含参数张量和模型类解耦只要模型结构不变代码怎么改都能加载。# 推荐只保存state_dict torch.save(model.state_dict(), model.pt) # 加载时先实例化模型再加载参数 model MyModel() model.load_state_dict(torch.load(model.pt))如果需要保存优化器状态、epoch数这些训练信息可以一起打包成一个字典checkpoint { model: model.state_dict(), optimizer: optimizer.state_dict(), epoch: epoch, loss: best_loss, } torch.save(checkpoint, checkpoint.pt)8. 从项目到能力怎么把学到的东西变成自己的8.1 建立自己的代码模板库每次做新项目都从零开始写训练循环、数据加载、日志记录效率太低了。我的做法是维护一套自己的代码模板新项目直接复制粘贴然后改改就能用。模板里应该包含标准的训练循环、常用的学习率调度、混合精度训练、梯度累积、日志记录、模型保存和加载、指标计算。这些东西在每个项目里都差不多没必要重复造轮子。但要注意模板是起点不是终点。每个项目都有特殊需求该改的地方还是要改。模板的价值在于让你跳过那些重复劳动把精力放在真正有挑战的地方。8.2 读源码从使用者到贡献者用框架遇到问题时很多人第一反应是搜教程、问别人。但最有效的方式其实是直接读源码。PyTorch的源码写得相当清晰torch/nn/modules/transformer.py、torch/optim/adam.py这些文件读一遍你对Transformer和Adam的理解会上一个台阶。读源码的另一个好处是你能看到框架作者是怎么处理边界情况的。比如Adam里的偏差校正、LayerNorm里的数值稳定性处理这些细节在论文里可能一笔带过但在工程实现里至关重要。8.3 参与开源从issue到PR如果你想把AI工程能力提升到更高层次参与开源项目是一个很好的途径。从提issue开始到修复文档错误再到提交代码PR这个过程能让你接触到真实项目的工程标准。我自己的经验是第一次提PR的时候被reviewer指出了很多问题代码风格不一致、缺少测试、边界情况没处理。虽然当时有点受挫但正是这些反馈让我意识到工业级代码和实验代码的差距有多大。8.4 保持对底层的好奇心AI领域变化很快新模型、新框架、新工具层出不穷。但底层的东西变化很慢矩阵乘法、梯度下降、注意力机制这些核心原理十年没变过。我的建议是花70%的时间在底层原理上30%的时间在最新工具上。底层原理让你有判断力知道什么工具值得学、什么只是昙花一现。最新工具让你保持手感不至于和实际脱节。回到ai-engineering-from-scratch这个主题它的价值不在于让你重新发明轮子而在于让你理解轮子是怎么转的。当你理解了这些再用框架的时候你就不是盲目地调API而是知道每一步在做什么、为什么这么做、出了问题该往哪个方向排查。这种能力才是真正属于你自己的。