为什么要做“从零开始造AI工程”我先说个场景。简历上写着“熟悉TensorFlow/PyTorch”GitHub上挂着几个notebook面试的时候能聊两句Transformer但一到真实业务里老板让把一个模型做成线上接口服务要能扛住流量、要能监控、要能回滚、要能版本迭代很多人当场就卡住了。我见过太多这样的人也包括几年前的我。所以当我看到ai-engineering-from-scratch这个项目标题时第一反应就是这玩意儿踩中了绝大多数AI从业者的命门——从“会跑模型”到“会做系统”之间那条巨大的鸿沟。它不是一个教你调参的教程不是又一个Transformer原理精讲它是在告诉你如果让你一个人、一台机器、从裸机开始把一个AI应用完整地造出来、跑起来、维护下去你到底需要掌握哪些能力按什么顺序学每一阶段要做到什么程度才算过关。这类项目解决的核心痛点就是“学了一堆碎片化知识但无法组装成一套能用的系统”。适合的人群也很明确已经能跑通简单模型、但没正经做过工程化项目的学生刚入职做算法落地不久的新人以及想从纯算法岗转向AI工程岗的开发者。这篇内容我就把它当作一次完整的拆解和一个“过来人”的经验记录把这套能力地图给你摊开顺带附上实战代码、选型分析和踩坑记录。1. 先拆解ai-engineering 到底在学什么1.1 AI 工程师不是调包侠能力栈全景很多人对AI工程的误解是只要会写模型结构、会训练剩下的交给后端工程师就行。真做一次端到端的项目就会发现工程化的“脏活累活”多到超出想象。一个完整的AI工程能力栈至少覆盖这么几层数据处理层是地基。真实环境里的数据远没有Kaggle比赛那么干净缺失值怎么处理、异常值怎么识别、类别特征怎么编码、时间序列怎么对齐、多源数据怎么join每一项都直接影响模型上限。这层的能力要求是“数据敏感度”——拿到一批数据你能在半小时内找到明显的问题而不是把脏数据直接喂进模型。更进阶的还包括数据版本管理、数据管道编排、特征存储。训练与实验层是核心。这层不仅包括模型架构设计和调参还包括实验追踪、结果对比、超参数搜索、分布式训练策略。“可复现性”在这里是被反复强调的——今天跑出来的结果是不是改了两行代码之后还能复现依赖版本有没有锁死随机种子有没有固定很多新手吃过大亏上周实验结果好这周怎么跑都复现不了最后发现是某个库悄悄升级了。服务化与推理层是落地关键。模型训练好只是开始真正的工程挑战在于把模型封装成接口、合理管理算力资源、降低推理延迟、提升吞吐量。这个层面要求你懂模型量化、Batch推理、缓存策略、请求排队还要能判断该用同步接口还是异步任务。再加上模型的AB测试、灰度发布和监控告警就又是一整套方法论。基础设施与运维层是长跑保障。模型上线后不是万事大吉数据分布会漂移模型效果会衰减线上反馈需要回流再训练。这一层要求你理解容器化部署、CI/CD流程、日志收集、指标监控、告警规则以及最核心的——整套流程能不能自动化。如果一个环节还需要人工手动操作那它就是不稳定的来源。说白了AI工程是“算法系统数据”的交叉学科每一项都需要刻意练习。1.2 为什么选择“从零开始”的方式我在带新人的时候发现一个规律直接丢给他一个现成项目让他在上面加需求上手很快但一旦出了奇怪的问题他根本不知道从哪里排查。因为他对整个系统的“因果链”没有建立起来——他不知道哪里出了问题应该往哪一层去查。而“从零开始”的方式看起来慢实则快。你得自己装环境、自己建数据管线、自己写训练脚本、自己设计接口、自己部署服务。每一个环节都亲手敲过一遍之后你对系统的理解是从底层长出来的不是从上层覆盖下来的。就好比学做饭跟着菜谱炒出一个菜容易不打火、不备菜光是理解“为什么要热锅凉油”、“为什么先下葱姜蒜”就得自己动手烧过几回厨房才能明白。这个项目的路线本质上就是在强制你“由下往上”构建知识体系。不给你现成的模板工程去抄而是让你搞清楚每个模块存在的理由、它解决的问题、不做的后果。这叫“慢就是快”。2. 从零到上线一条完整的 AI 工程路线图2.1 基础层数学、Python 与数据操作别急着上深度学习框架。我见过太多人PyTorch写得飞起结果一个简单的梯度推导写不出来一个pandas的groupby操作要想半天。工程化落地需要的基础其实比很多人想象中窄但更深数学基础不需要学到数学系的程度但线性代数中的矩阵乘法、特征分解、奇异值分解概率论中的常见分布、条件概率、最大似然估计微积分中的偏导数和链式法则这三块是硬底线。它们不一定每天直接出现在代码里但当你读论文、调loss、改网络结构时它们是理解一切的基础语言。做AI工程还要额外补一点数值计算的内容比如浮点精度的坑、梯度消失爆炸的成因这些都属于“数学照进现实”的部分。Python工程能力才是真正的分水岭。写脚本和写工程是两码事。合格的AI工程师至少要熟练Python的面向对象设计、类型注解、装饰器和上下文管理器虚拟环境管理venv、conda、poetry包管理配置以及基本的单元测试和日志规范。不要小看这些“不性感”的内容它们是团队协作和项目可维护性的命根子。数据操作部分SQL pandas是你吃饭的家伙。很多面试官喜欢考一个真实的取数场景给你三张表要统计某个维度的转化率并要求考虑去重、空值、时间窗口等问题。这背后的本质是考察你是否能精准地理解业务指标和数据形态。数据操作过关之后再去学更系统的数据管道工具Airflow、Prefect也不会太吃力。2.2 训练层框架、实验管理与模型开发框架选型上现在是PyTorch的天下这没什么悬念。TensorFlow在部分生产场景还有存量但新项目绝大多数是PyTorch。关键不是记住API而是理解一个训练脚本的结构化套路。我习惯把训练脚本分为几块数据加载器Dataset/DataLoader、模型定义、损失函数和优化器配置、训练循环、验证循环、检查点保存和日志记录。每一块各司其职改起来互不干扰。实验管理方面至少要会用一款工具追踪每次实验的配置、指标和产物。MLflow是比较轻的选择支持记录params、metrics、artifacts一行代码就可以接入。WB体验更好但要联网团队内部用起来要考虑成本。重点不在工具本身而在于建立一种习惯每次实验必留记录每条记录必带可复现信息——代码版本、数据版本、配置、随机种子、环境依赖缺一不可。调参这块最容易掉进去的是“手动乱试”。遇到效果不好就调一下学习率、换一换网络层数漫无目的地瞎试既浪费时间又得不到可迁移的经验。比较推荐的做法是先跑一个小规模基线确定loss能下降、指标有意义再使用Optuna这类工具做结构化超参搜索。别一上来就上贝叶斯优化先用随机搜索和网格搜索找感觉再逐步精细。2.3 服务层模型打包、推理优化与 API 化训练完成 ≠ 工作完成。模型要变成产品必须过一道“工程转换”的工序。模型导出是第一步。PyTorch训练好的.pt权重文件通常不能直接被线上服务加载。常规操作是先把模型转成TorchScript或者进一步导出为ONNX格式。ONNX的好处是中间表示层之后可以接不同的推理引擎ONNX Runtime、TensorRT还能顺便做图优化和算子融合。生产环境里我一般直接上ONNX跨框架的兼容性好优化也省心。推理优化涉及的手段很多半精度推理FP16能把显存占用和延迟同时降低接近一半Batch推理就是把多个请求拼在一起过一遍模型通常能成倍提升吞吐自带缓存的重复请求处理也能有效降低压力最终手段才是模型量化——把权重从FP32压到INT8精度往往还能控制在可接受范围内但速度提升非常可观。量化这块要多留一个心眼不是所有模型都能直接量化不掉点必须拿自己的数据做充分验证。API化最常用的组合是 FastAPI Uvicorn不用我说你也能在网上找到大量示例后续我会给出一个完整示例。FastAPI的优势在于自动生成OpenAPI文档、类型校验完善、并发性能不错而且生态成熟和Pydantic配合做请求/响应的校验几乎是天然的。把模型加载放到全局变量推理函数封装成异步接口一个能用的服务也就一百多行代码。2.4 运维层监控、版本管理与持续集成很多从零开始的教程讲到这里就停了那其实还不是完整工程。真正线上跑着的东西必须有监控和迭代闭环。监控方面除了常规的CPU、内存、GPU、QPS、延迟这些基础设施指标更值得关注的是模型效果指标——比如线上预测分布的均值漂移、特征缺失率变化、用户反馈的负面率上升。这些信号意味着数据分布变了模型可能需要更新了。用Prometheus Grafana做基础设施监控用自定义埋点上报业务指标基本能覆盖绝大多数需求。版本管理比很多人以为的更复杂。模型文件本身要版本化训练用的数据要版本化特征计算逻辑要版本化甚至连prompt模板如果是LLM应用都要版本化。DVC可以做数据和模型版本管理和Git配合良好MLflow的Model Registry也能管模型版本和stage流转。核心思路就一条任何影响线上预测结果的东西都必须能回滚到历史上的某个精确状态。CI/CD对于AI工程来说也别具一格。除了常规的代码测试和构建还要加入“数据验证”和“模型评估”两道关卡——数据schema变了触发告警模型在验证集上指标低于阈值就跑不过Pipeline。把质量控制前置比靠人盯靠谱得多。3. 实操实录把一套模型端到端跑起来3.1 项目结构与数据管线理论说完看一个最小可行的端到端结构。假设我们要做一个“影评情感分类”服务数据是IMDB评论这个规模适中能在一台普通开发机上跑通是很好的练习素材。我推荐的项目结构是这样ml-project/ ├── configs/ # 配置文件yaml ├── data/ │ ├── raw/ # 原始数据 │ └── processed/ # 清洗后数据 ├── src/ │ ├── data/ # 数据加载与预处理 │ ├── models/ # 模型定义 │ ├── train.py # 训练入口 │ └── predict.py # 推理封装 ├── services/ │ └── api.py # FastAPI 服务 ├── tests/ # 单元测试 ├── scripts/ # 运维脚本 ├── requirements.txt └── README.md不复杂但分层清晰。数据进raw之后不要动所有清洗逻辑写到src/data/里输出到processed/。这样别人接手时能清楚地看到“原始数据长什么样、哪里改过、改成了什么样”。数据处理这一块最容易忽视的是文本标准化的一致性。训练时你做了小写化、去停用词、词形还原那推理时也必须走完全一样的流程。我见过线上服务忘了调小写函数导致模型输入分布和训练完全不匹配精度直接崩掉。解决办法很简单把预处理逻辑封装成一个类或者一个函数训练和推理共用同一个模块不允许两套逻辑各自实现。另外数据划分也用得上几行严谨代码——训练/验证/测试的比例控制在8:1:1并且要按标签分层抽样保证类别比例在三个集合里一致。用sklearn的train_test_split加stratify参数就能搞定这是很多人会忽略的细节。3.2 训练脚本里容易忽视的三件事训练脚本的核心逻辑大多数人都能写出来无非就是forward、loss、backward、step。我见过太多跑得起来的脚本但能进生产的脚本还得补三样东西第一固定随机种子。保证在同样的数据、同样的代码版本下多次训练结果一致。做法是在入口统一设置def set_seed(seed: int 42): import random import numpy as np import torch 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有人觉得这样会拖慢训练确实会但换来的是实验可复现性。跑实验阶段可以关掉正式训练或者出报告时一定要打开。第二Early Stopping 模型检查点。很多人训练用固定epoch数但其实更稳的是在验证集上监控loss连续N轮没有改善就提前停止并且只保留验证指标最好的那次权重。写成代码就是best_val_loss float(inf) patience 0 for epoch in range(max_epochs): train_loss train_one_epoch(model, train_loader) val_loss evaluate(model, val_loader) if val_loss best_val_loss: best_val_loss val_loss torch.save(model.state_dict(), best_model.pt) patience 0 else: patience 1 if patience early_stop_epochs: break不要只把最后一个epoch的权重存下来那不是最好的模型。第三训练日志要能被人看懂。用标准库的logging或者第三方库都行关键是每轮记录loss、学习率、当前epoch、耗时还要能方便地导出成结构化数据比如json lines这样后续画loss曲线时直接读取而不用去抠终端输出。这里有一个经验数字如果训练脚本启动后前几个batch的loss没有明显下降趋势大概率是学习率设置有问题或者数据/标签对不上。别傻等先停下来排查。3.3 模型导出与推理服务化训练完成后把PyTorch模型导出为ONNX。以我们简单的LSTM分类模型为例import torch from models import build_model model build_model(vocab_size50000, embed_dim128, hidden_dim256, num_classes2) model.load_state_dict(torch.load(best_model.pt, map_locationcpu)) model.eval() dummy_input torch.randint(0, 50000, (1, 128)) # (batch, seq_len) torch.onnx.export( model, dummy_input, model.onnx, export_paramsTrue, opset_version13, input_names[input_ids], output_names[logits], dynamic_axes{input_ids: {0: batch_size, 1: sequence_length}} )dynamic_axes这里务必设置成动态轴否则模型只能接受固定形状的输入线上遇到不同长度的句子就傻了。ONNX模型配合FastAPI做服务整体架构干净利落。注意一个关键细节模型是全局加载一次不要每次请求都重新加载。from fastapi import FastAPI from pydantic import BaseModel import onnxruntime as ort import numpy as np from src.data.preprocess import preprocess_text app FastAPI() sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): probability: float label: str app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): input_ids preprocess_text(req.text) # 返回 np.array shape(seq_len,) logits sess.run(None, {input_ids: input_ids.astype(np.int64)})[0] prob float(1 / (1 np.exp(-logits[0]))) label positive if prob 0.5 else negative return PredictResponse(probabilityprob, labellabel)还要注意ONNX Runtime有个providers参数。机器上有NVIDIA GPU的话可以试试CUDAExecutionProvider没有就老老实实CPUExecutionProvider。选择provider的顺序会影响生效优先级一般把CUDA放前面。启动服务用一行命令uvicorn services.api:app --host 0.0.0.0 --port 8000 --workers 2这里workers的个数不是越多越好。如果你的服务是CPU密集型推理worker数一般不超过CPU核心数如果是IO密集型可以适当多开。而且每个worker都会复制一份模型到内存里内存不够时多开反而拖垮整体性能。3.4 上线前必须做的压测与稳定性检查模型一旦准备上线我先做三件事都不复杂但能避免大量线上事故。第一件写个简单的压测脚本模拟连续发N个请求看延迟和成功率。不用上复杂工具直接用locust或者自己用asyncio写个并发脚本就够了。我通常会设置一个并发梯度10并发、50并发、100并发逐步往上加同时观察P50和P99延迟的变化。如果P99比P50高出五六倍大概率存在某个资源瓶颈常见的就是Python GIL限制让模型推理排队了或者数据预处理和推理争抢CPU。第二件检查最大输入长度的边界情况。文本类接口用户不会按照你训练时的长度来。如果输入的padding后超过模型支持的最长长度可能直接报错或者截断后信息丢失。一定要在代码里显式处理超长输入逻辑比如截断、告警、或者丢弃。第三件冷启动和内存占用检查。模型服务启动后观察一下常驻内存和首次请求的耗时。你会发现第一个请求特别慢——因为懒加载的库、模型初始化都堆积在第一次调用上。如果线上有这个情况建议在服务启动时做一次“预热请求”让所有资源在接收真实流量之前就位。压测下来如果发现延迟超标个人建议先不要急着加机器先确认是不是模型太大、预处理里存在低效代码、或者没用上batch推理。我在实际项目里遇到过很多次代码层面一个小小的优化效果比多加一台机器都明显。4. 从零搭建中的典型问题与排查手册这部分全是实际踩过的坑每一个都让我印象深刻。4.1 训练环境和生产环境不一致经典中的经典。开发机上用的是Python 3.10 PyTorch 2.1线上容器里是Python 3.8 PyTorch 1.13结果模型加载直接报错或者推理结果微妙地不一致。解决这个问题只有一条路把环境作为项目的一部分管起来。用requirements.txt锁死顶层依赖不算够生产环境建议直接把整个依赖树锁死pip freeze requirements_lock.txt更好的方式是使用容器镜像把CUDA、Python版本、系统库、Python依赖全部固化在镜像里。每次训练和部署都用同一个镜像从根上消除环境漂移问题。这一点我在很多从零教程里都没看到但它其实是工程化最核心的习惯。4.2 数据泄漏与评估失真数据泄漏在NLP任务里比较隐蔽。一个常见的坑做文本分类时你用整个数据集做了词表vocabulary构建然后才切分训练/验证/测试集。这样测试集里出现的词已经在词表中“见过”了模型实际上从词表中获取了本不该接触的信息。在机器学习中这叫“预处理泄漏”会让验证指标虚高上线后崩盘。正确做法是先切分数据集然后用“训练集”部分单独拟合词表或者统计特征验证集和测试集只做变换不做拟合。这一步踩过之后我写任何数据处理代码都会先问自己这个统计量是“全局统计”还是“训练集统计”如果是前者线上怎么办4.3 显存溢出与批量策略训练时显存溢出OOM几乎是每个人都会遇到的。常规解法是减小batch size但这会拖慢训练。我一般先做三件事检查输入tensor的dtype确保是FP32或FP16而不是默认双精度Double双精度的显存占用是两倍检查是不是有变量在计算图中被全程持有导致无法释放显存用torch.cuda.empty_cache()在合适时机清理缓存但这不是根治方案。如果以上都做了还是OOM可以考虑梯度累积——用多个小batch的梯度累加后再更新参数效果等效于大batch但显存占用平稳许多。4.4 模型不可复现与乱糟糟的Prompt模型不可复现的最大元凶就是不固定随机种子和依赖版本升级。如果做LLM应用还发现同样的Prompt和参数输出结果每次都变化那是因为温度系数temperature没设为0模型天然有随机性。这种随机性在开发调试时会让你疯掉“这行代码明明没改怎么效果不一样了”。排查思路是逐层隔离先锁模型推理的随机性设置do_sampleFalse或temperature0再锁数据加载的随机性固定shuffle的seed最后锁训练初始化的随机性。从外层往里一层层排查总能定位到问题所在。4.5 问题速查表现象可能原因排查方向训练loss不降学习率太大/太小数据标签错位输出前几个batch的prediction与label对比验证集指标远低于训练集过拟合/数据泄漏检查预处理是否用全局统计增加正则线上延迟偏高模型过大、预处理低效、无batch压测定位瓶颈考虑量化或加缓存模型加载失败序列化格式不匹配、依赖版本不一致对比训练与加载环境torch/torchvision版本首个请求特别慢懒加载启动时做预热请求复现失败随机种子未固定、依赖变更锁定随机种子依赖全量冻结5. 工具选型我的取舍与理由5.1 框架选择为什么是 PyTorch 生态PyTorch在研究和生产两个维度上同时占优这不是偶然。它的动态图机制让调试变得非常直观你可以在执行到任意一行时打印中间结果这对于开发效率太关键了。配套生态也最丰富Hugging Face Transformers天然优先支持PyTorchtorch.compile又能把训练加速一截。TensorFlow的优势曾经在于生产部署闭环完整TF Serving、TF Lite但这两年PyTorch这边也有了TorchServe和ONNX Runtime差距在逐渐抹平。从招聘市场看纯PyTorch的岗位需求明显更多我身边的新项目也几乎都是PyTorch一家独大。对于从零开始的你选PyTorch不会错。5.2 服务化方案FastAPIONNX Runtime 对比 Triton模型上线时大部分场景用不到重型推理引擎。FastAPI ONNX Runtime的组合是我最常用的默认方案原因很简单代码直观、调试方便、依赖轻、部署灵活。它适合QPS要求中等几十到几百、模型不算复杂、团队规模不大的情况。但如果流量大、模型多、需要动态Batch、需要同时服务多个模型版本NVIDIA Triton Inference Server会是更专业的选择。它内置动态Batch和并发推理优化性能远好于自己手写。代价是运维复杂度明显上升配置和理解成本都不低。我的建议是先把FastAPI方案跑通、压测到接近瓶颈再评估是否有必要上Triton。不要一上来就用重武器那是给需要扛大流量的人准备的。5.3 实验与数据版本管理MLflow、DVC 的实际体验MLflow 我用了三年多整体体验是“轻量但够用”。实验追踪这块每次训练自动记录参数和指标UI里对比结果非常直观。Model Registry管理线上模型版本做得也不错配合阿里云OSS或S3存模型文件基本能满足小型团队的需求。DVC 的数据版本管理理念我很认同不复制数据本身而是用Git记录数据文件的哈希和版本关系。数据文件存在共享存储里需要时通过DVC pull拉取。这样可以随时切换回“某次实验用的那一版数据”。虽然初期配置有点繁琐但一旦团队需要协作、复现历史结果这套体系的价值立刻显现。工具没有绝对的好坏关键是匹配团队规模、业务需求和你自己的维护能力。选型的基本逻辑永远是先用最简单的方案跑通流程再根据痛点渐进式引入更复杂的工具。最后分享一点个人体会从零开始造AI工程最磨人的不是某个具体技术点难到学不会而是“你不知道自己不知道什么”——你以为提交了模型就是完成结果被线上召回、数据漂移、可复现性这些问题轮番教做人。这个项目之所以有价值就是因为它逼着你把整条链路走一遍让你在坏事发生之前先知道坏事可能长什么样。如果你正在走这条路我的建议是别贪多先做透一个最小闭环。数据、训练、导出、上线、监控哪怕是一个玩具模型也要把它生产化。然后再在这个闭环上一点点添加复杂度。做得深比看得广重要得多因为工程能力的本质不是知识量而是应对不确定性的经验积累。