如果你也打算从零开始搞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 python=3.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", train=True, transform=transform, download=True ) val_data = datasets.FashionMNIST( root="./data", train=False, transform=transform, download=True ) train_loader = DataLoader(train_data, batch_size=64, shuffle=True) val_loader = DataLoader(val_data, batch_size=64, shuffle=False) print(f"Train 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", type=int, default=10) parser.add_argument("--batch-size", type=int, default=64) parser.add_argument("--lr", type=float, default=1e-3) parser.add_argument("--device", type=str, default="cuda" if torch.cuda.is_available() else "cpu") parser.add_argument("--save-path", type=str, default="checkpoints/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", train=True, transform=transform, download=True) train_loader = DataLoader(train_data, batch_size=args.batch_size, shuffle=True) model = build_model().to(device) criterion = nn.CrossEntropyLoss() optimizer = torch.optim.Adam(model.parameters(), lr=args.lr) for epoch in range(args.epochs): loss, acc = train_one_epoch(model, train_loader, optimizer, criterion, device) print(f"Epoch {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_location="cpu") 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_version=12 )导出之后务必做一步验证：用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, dtype=np.float32).reshape(1, 1, 28, 28) outputs = session.run(None, {"input": arr})[0] pred = int(np.argmax(outputs, axis=1)[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服务做成真正的微服务，注册进服务发现组件。每个方向都有足够深的坑可以踩，但也有足够明显的成长回报。我现在也已经习惯在新建项目时直接初始化为一个模板仓库，目录结构、基础脚本、检查清单全都预置好，真正让“从零开始”变成“从有到优”。这个项目的最后一步，不必停在这里，而是把其中每一个小节，都继续延展成你自己真正的能力版图。
