如果你也打算从零开始搞AI工程我先劝你想清楚一件事AI工程和你平时看的算法教程、Kaggle比赛完全是两码事。比赛只要一个精度数字工程要的是稳定、可复现、能维护、能上线的一套体系。我把自己从只写过几个玩具模型到能正经跑通一条数据管线、一个训练任务、一个推理服务的完整经历整理成这篇“ai-engineering-from-scratch”路线。适合想真正入行AI工程、但被各种工具链和概念绕晕的人。我会直接告诉你先学什么、后学什么、哪些坑必须绕开以及一个可以照抄的最小工程案例。1. 项目到底在解决什么问题拆掉AI工程的黑盒1.1 算法和工程的距离差点让我放弃我最早接触AI的时候以为“AI工程师”就是把神经网络跑起来。结果第一次被丢到一个真实项目里要我把一个实验用的图像分类模型部署到Linux服务器上事情彻底变味了。模型训练完了精度挺漂亮但导出时发现格式不对服务器上CUDA版本不匹配推理接口一压测就超时数据预处理逻辑在训练和推理两端不一致导致线上效果稀烂。那一刻我才意识到AI工程不只是一堆深度学习的API调用而是一条从原始数据到线上稳定服务的完整流水线。这个流水线里算法能力只是其中一段。更吃功夫的是数据版本管理、环境一致性、训练任务的自动调度、模型格式转换、服务化部署、性能压测、监控告警、回滚策略。每一项单独拎出来都不是新东西但组合在一起就特别考验工程素养。做过一遍之后再看那些“几分钟跑一个模型”的Demo我会本能地追问你的数据和权重有没有版本记录换一台机器能不能复现模型每日推理量波动时会不会崩这些追问才是AI工程真正的日常。1.2 为什么“从零开始”特别值得讲市面上的课程大多教你怎么调网络结构、怎么调超参数很少讲“从零”搭一套工程体系。所谓从零不是从0写神经网络而是从一台裸机、一个空目录、一堆原始文件起步一步步构建出可交付的系统。这个过程包含大量不起眼却决定成败的细节Python解释器版本是3.9还是3.11、CUDA和cuDNN的版本组合、依赖锁定的文件是不是每次安装都一致、模型输出张量和后处理代码之间的格式匹配。任何一个环节不一致都会在线上爆发出来且极难排查。我梳理下来AI工程从零开始至少需要四层能力第一层是数据层包括数据采集、清洗、增强、版本管理第二层是训练层包括实验跟踪、超参数管理、GPU资源调度第三层是部署层包括模型格式转换、推理服务编写、镜像构建第四层是运维层包括日志、监控、指标告警、模型回滚。这四个层次相互独立又彼此咬合每一个都是完整的工程领域。这篇博文就是按这个分层把我的实操过程和踩坑经验挨个拆给你看。2. 从零开始的路线图先搭技能树再选工具2.1 真正的优先级不是模型而是环境与数据很多新手犯的最大错误是把80%的精力花在模型结构上。真正支撑模型效能的其实是环境可复现性和数据质量。我自己的顺序是这样的先把Python开发环境搞稳定用Conda或virtualenv创建专门的项目环境把Python版本固定在项目文档里然后用Pip或Poetry管理依赖并保存锁定文件确保换一台机器能还原出一模一样的环境再然后才谈装PyTorch或TensorFlow。数据层面先做版本化给每个数据集打标签、记录来源、记录处理脚本再开始清洗。顺序倒过来做未来一定是灾难。工具选型我建议坚持几个原则主流程避免追求新潮框架能稳定的就尽量稳定能标准化的就标准化比如模型导出用ONNX或TorchScript能自动化的就自动化比如训练脚本用命令行参数接收所有超参数而不是改代码。我实操下来最顺手的一套组合是Python 3.10 Conda PyTorch 2.x MLflow Docker FastAPI Prometheus/Grafana。这套工具链全部开源免费社区成熟遇到问题随便一搜就有答案踩坑成本低很多。2.2 给新手的技能清单与避坑提示我整理了一份按优先级排序的技能清单照着这张表走基本不会跑偏优先级技能核心工具解决什么问题P0环境隔离与依赖管理Conda、Pip、Poetry避免“在我机器上明明能跑”P0数据清洗与版本管理Pandas、DVC、Git LFS保证数据变更可追踪P0训练脚本工程化argparse、配置文件把超参数从代码里抽离P1实验跟踪与对比MLflow、TensorBoard搞清哪次实验用了什么参数P1容器化打包Docker让运行环境随模型一起交付P1模型导出与推理优化ONNX、TensorRT提升线上推理效率P2服务化部署FastAPI、Flask对外提供标准HTTP接口P2监控与告警Prometheus、Grafana实时掌握模型线上表现这条清单里的每一项我当初都至少填进去一个星期的实操时间。P0级别的技能不绕开后期会加倍偿还。以Docker为例很多人以为只是“把代码塞进容器”这么简单。真正做起来你要处理基础镜像选择、依赖层缓存、非root用户权限、时区设置、健康检查、日志输出方式这些细节。把它想简单的人第一次上线就会吃亏。2.3 环境搭建的真实操作记录我拿最常见的技术栈举个例子。假设你在一个GPU服务器上从零开始搭环境命令大概是这样# 安装 Conda以 Linux 为例 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh # 创建项目专属环境 conda create -n ai_eng python3.10 -y conda activate ai_eng # 安装 CUDA 相关的 PyTorch 包 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # 将当前环境的依赖锁定 pip freeze requirements.txt这里有个特别关键的点:基于conda和pip的版本细节。我用CUDA 12.1配PyTorch 2.1是当时实测比较稳定的组合。装完以后建议立刻跑一个最小矩阵乘法确认GPU可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出是False不要急着写模型先回到驱动层面排查。我遇到过一次服务器上装了两块GPU但驱动版本旧和PyTorch新版本的CUDA不兼容。那次的教训是先查nvidia-smi再查PyTorch要求的CUDA版本两个对照好了再往下走。这一步看似基础但如果跳过后面训练时突然报错排查成本会高出好几倍。3. 实操主战场一个最小可用的图像分类工程3.1 数据准备先让数据流动起来理论讲再多不如跑通一个真实项目来得踏实。我选的任务是经典的Fashion-MNIST图像分类原因很实际数据集小、任务明确、处理逻辑简单可以完全聚焦在工程链路上而不需要纠结模型结构。先把数据准备的脚本跑起来# data_download.py from torch.utils.data import DataLoader from torchvision import datasets, transforms transform transforms.Compose([ transforms.ToTensor(), transforms.Normalize((0.5,), (0.5,)) ]) train_data datasets.FashionMNIST( root./data, trainTrue, transformtransform, downloadTrue ) val_data datasets.FashionMNIST( root./data, trainFalse, transformtransform, downloadTrue ) train_loader DataLoader(train_data, batch_size64, shuffleTrue) val_loader DataLoader(val_data, batch_size64, shuffleFalse) print(fTrain samples: {len(train_data)}, Val samples: {len(val_data)})这里要注意我把下载好的数据固定相关路径并且用相对路径写在每个脚本里保证别人按同样的命令执行时不会遇到路径不一致。数据管线里最容易出问题的是数据形状和类型。Fashion-MNIST的原始数据是PIL图像ToTensor会把[H, W]转成[1, H, W]Normalize才能正确作用于通道维。新手写代码时一定要随手打印一个batch的shape和dtype确认是4维浮点张量否则模型输入层必然会报错。数据版本化这块我在项目里用的是最简单的方案在目录里存放一份CHANGELOG文件记录每次数据处理的改动。比如“2024-05-20 新增归一化系数0.5”“2024-05-21 修复train/val切分的随机种子”。虽然不如DVC那么完备但在早期阶段能保证你三个星期后回头还能搞清楚自己当时做了什么。等数据规模大到用网盘和手动备份管不过来时再迁移到DVC不迟。3.2 训练脚本的关键设计理念把超参数完全抽离训练脚本是AI工程里最不能写成一坨的东西。我从第一次写脚本就坚持一个原则所有可变的数值一律通过命令行参数传入绝对不进代码。批大小、学习率、轮数、优化器名称、模型保存路径全部用argparse或配置文件驱动。这样做的好处是换参数时不用改代码每次实验的参数组合会自动记录在命令行里配合日志也能完整复现实验。# train.py import argparse import torch import torch.nn as nn from torch.utils.data import DataLoader from torchvision import datasets, transforms def build_model(): return nn.Sequential( nn.Flatten(), nn.Linear(28 * 28, 256), nn.ReLU(), nn.Linear(256, 10) ) def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss, correct, total 0, 0, 0 for images, labels in loader: images, labels images.to(device), labels.to(device) optimizer.zero_grad() outputs model(images) loss criterion(outputs, labels) loss.backward() optimizer.step() total_loss loss.item() * images.size(0) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() return total_loss / total, correct / total if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--epochs, typeint, default10) parser.add_argument(--batch-size, typeint, default64) parser.add_argument(--lr, typefloat, default1e-3) parser.add_argument(--device, typestr, defaultcuda if torch.cuda.is_available() else cpu) parser.add_argument(--save-path, typestr, defaultcheckpoints/model.pt) args parser.parse_args() device torch.device(args.device) transform transforms.Compose([ transforms.ToTensor(), transforms.Normalize((0.5,), (0.5,)) ]) train_data datasets.FashionMNIST(root./data, trainTrue, transformtransform, downloadTrue) train_loader DataLoader(train_data, batch_sizeargs.batch_size, shuffleTrue) model build_model().to(device) criterion nn.CrossEntropyLoss() optimizer torch.optim.Adam(model.parameters(), lrargs.lr) for epoch in range(args.epochs): loss, acc train_one_epoch(model, train_loader, optimizer, criterion, device) print(fEpoch {epoch 1}/{args.epochs} - loss: {loss:.4f}, acc: {acc:.4f}) torch.save({model_state_dict: model.state_dict()}, args.save_path)这个脚本看起来很简单但已经把工程化该有的要素都搭起来了入口统一、参数可控、训练逻辑和超参数分离、状态字典保存。我个人的建议是每个项目的训练脚本保持这样的纯粹性不负责数据清洗、不画图、不推送消息只负责训练和保存模型。其他功能统统拆到独立脚本里。3.3 模型导出和服务化把产物变成可交付的东西训练完的模型还只是一个状态字典不能直接拿出来做线上服务。我通常的下一步是把PyTorch模型转成ONNX格式让推理可以脱离PyTorch依赖。这里的收益是实打实的服务镜像体积更小、CPU推理更稳、切换其他推理后端也更容易。# export_onnx.py import torch from train import build_model model build_model() checkpoint torch.load(checkpoints/model.pt, map_locationcpu) model.load_state_dict(checkpoint[model_state_dict]) model.eval() dummy_input torch.randn(1, 1, 28, 28) torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}}, opset_version12 )导出之后务必做一步验证用ONNX Runtime跑一遍推理输出和原始PyTorch模型做比对误差超过小数点后四位就要警惕。我遇到过一个问题模型里有算子ONNX不支持导出时没报错但运行结果完全错误。解决办法是逐层检查等价性或者换算子重写网络。这种坑不在实际部署中是根本不会暴露的。服务化的部分我推荐FastAPI因为它自带异步能力和自动生成的API文档写起来非常顺手# serve.py import numpy as np import onnxruntime as ort from fastapi import FastAPI from pydantic import BaseModel app FastAPI() session ort.InferenceSession(model.onnx) class Payload(BaseModel): image: list app.post(/predict) def predict(payload: Payload): arr np.array(payload.image, dtypenp.float32).reshape(1, 1, 28, 28) outputs session.run(None, {input: arr})[0] pred int(np.argmax(outputs, axis1)[0]) return {prediction: pred}这里面有个非常容易踩的坑请求体里数值的shape和dtype。前端传过来的往往是Python列表直接丢给ONNX会因类型或尺寸不匹配报错。所以每一层都要做显式转换并且写一个单元测试来验证整个接口的输入输出结构。我坚持给每个服务写冒烟测试哪怕只是调用一次predict接口确认返回200这比什么都管用。4. 工程化里的那些坑实测复现和排查思路4.1 环境不一致的千里之堤我做这个项目时最离谱的一次经历是训练时用的PyTorch和部署时用的ONNX Runtime对同一个算子的数值处理有细微差异导致线上推理结果在边缘类别上有偏差。其实两个库都符合各自规范但就是不完全等价。那一次排查花掉我整整一个下午最后发现online预处理里少了一个归一化转换。这类问题几乎是AI工程里最普遍、最隐蔽的数据预处理逻辑在训练和推理两端出现不一致表现就是线下Accuracy高、线上效果飘。排查这类问题我沉淀了一套固定方法首先确认训练和推理走的是同一份预处理代码不要图省事在测试环境里手写一份其次在进入模型前把输入Tensor保存下来用fp32精度逐元素比对训练端和推理端的差异最后排除模型权重加载错误。这三个步骤都做一遍问题的定位时间通常能缩短一大半。要用csv记录比如输入样本ID、预处理相似度、模型输出差异、判定结果。靠经验猜只会让问题更乱。4.2 常见问题速查表我整理了这个基础项目中会遇到的高频问题每条都附上原因和对应解法现象常见原因排查方向训练loss始终不降学习率过大/过小、数据标签错乱先用小样本过拟合单batch训练正常但验证集崩严重过拟合/分布不一致检查数据切分随机种子和预处理推理速度慢得离谱未开启batch推理、CPU上跑大模型用ONNX Runtime半精度或装TensorRT同一个模型线上结果不稳定请求输入padding不一致在服务端统一预处理接口容器启动后无法访问模型CUDA驱动和镜像版本不对在Docker里直接执行nvidia-smi多线程请求时经常报错ONNX会话被并发调用加锁或使用实例级会话管理这些内容看起来琐碎但每一个都是我在真实项目里撞过墙才总结出来的。最典型的还有那个“一切正常但线上精度差”——最后发现是请求图像的通道顺序ONNX Runtime默认NCHW而客户端传来的是HWC差出了一个transpose。自那以后我在服务内统一要求输入为NCHW并将其写进接口文档第一行。4.3 性能压测与监控告警的落地配置基础功能跑通了还只是第一步线上稳定需要监控来做保障。我部署推理服务时会搭配一套极轻量的监控方案FastAPI做Prometheus指标暴露Grafana做可视化仪表盘Alertmanager做钉钉或Webhook告警。核心指标很简单请求量、推理延迟P99、错误率、显存占用率。不要一开始就想做复杂的模型质量监控先把基础设施监控做好等流量多了再慢慢加数据漂移检测。先解决“服务挂了没人知道”再解决“模型变笨了没人发现”。监控配置里我特别建议记录模型的版本信息。每一次部署一个新的模型版本就在指标里带上版本标签。这样线上模型出问题时可以立刻通过Grafana比对不同版本同一时间窗口的表现迅速定位是模型退化还是基础设施故障。我从实际经历里学到的经验是越是自动化程度高的地方越需要留下完整的版本时间线。否则模型回滚操作会变成一场灾难。5. 后续还能怎么扩展更上层的东西都在你手里到这里最小可行的AI工程已经完整落地。可以尝试的扩展方向不止一条比如把Conda环境换成Docker镜像统一构建流程把训练链路的超参数接入MLflow做自动记录把模型格式换成TensorRT做推理加速又或者把这里的FastAPI服务做成真正的微服务注册进服务发现组件。每个方向都有足够深的坑可以踩但也有足够明显的成长回报。我现在也已经习惯在新建项目时直接初始化为一个模板仓库目录结构、基础脚本、检查清单全都预置好真正让“从零开始”变成“从有到优”。这个项目的最后一步不必停在这里而是把其中每一个小节都继续延展成你自己真正的能力版图。