聊到AI工程很多人的第一反应是“深度学习很火我来学个PyTorch”。可真入了门才发现模型训练只是整条链路里的一小块。ai-engineering-from-scratch这个标题听起来像一门课本质上其实是一套能力体系——从原始数据到模型训练再到部署上线、监控迭代每一环都得能动手解决。我见过太多人花三个月调一个模型调到SOTA结果一问“怎么把它变成接口给用户用”就卡住了。这就是典型的“算法思维”和“工程思维”之间的断层。这篇文章想聊的就是我从零开始补齐AI工程能力的那条路线。它适合谁适合刚入门机器学习、想往工程方向走的开发者和学生也适合已经在做算法、但总觉得“交付很痛苦”的从业者。它能帮你解决的问题很明确**怎么把一份CSV变成API、把训练脚本变成可交付的服务以及在踩坑时能快速定位是数据问题、训练问题还是环境问题。**整篇都是顺着我实际摸索过的路径来的没有八股全是能落地的做法。1. 重新理解AI工程先把自己从“调参选手”变成“系统负责人”1.1 AI工程到底在解决什么问题如果只追热点你看到的AI工程是K8s、GPU集群、大模型推理引擎这些词儿。但回到本质上它解决的是一个很朴素的问题让模型从“实验室里的实验品”变成“生产环境里的稳定服务”。我经常用开餐厅来打比方。训练模型就像研发一道菜——你有菜谱模型结构、食材数据、灶台训练环境炒出一盘让评委点头的菜离线指标达标。但AI工程是把这道菜变成一家能每天营业的餐厅要设计后厨动线数据处理Pipeline要定标准菜谱模型版本管理要培训传菜员推理服务要处理顾客投诉Bad Case监控还得控制成本推理资源估算。光会炒菜开不了餐厅。这个视角很重要因为它决定了你学习的优先级。很多人一上来就啃Transformer论文、刷LeetCode但真正做AI工程时卡住你的往往不是模型结构而是下面这类问题数据里为什么有那么多缺失值和重复样本训练脚本在本机能跑换台机器就崩怎么用Docker固定环境模型精度不错但推理延迟20毫秒线上扛不住每秒1000个请求怎么办三个月前跑出来的结果现在复现不了了怎么管实验记录和随机种子这些问题没有一个是“算法调参”能解决的但它们恰恰是AI工程的核心。所以文章后面所有的内容都会围绕这条“从数据到服务”的链路展开而不是单讲模型结构。1.2 AI工程师、算法工程师、后端工程师三种角色三条能力线刚入行的时候我分不清“算法工程师”和“AI工程师”的区别觉得自己做了算法就是在做AI。后来项目一多才发现这是两条能力线交集有限。角色核心关注点典型产出日常工具算法工程师模型效果提升论文复现SOTA指标实验报告、模型权重PyTorch、Jupyter、WandBAI工程师模型生命周期管理稳定交付与运维可部署的服务、监控面板、Pipeline脚本Docker、MLflow、FastAPI、K8s后端工程师业务逻辑、高并发架构、数据库设计业务系统、微服务接口Java/Go、MySQL、Redis、消息队列AI工程师的位置正好卡在算法和后端中间。你需要懂一点模型训练不是为了刷指标而是为了能判断“这个模型上线后大概什么吞吐、什么显存开销”你也需要懂一点后端不是为了写复杂的业务系统而是为了把模型包成一个稳定、可观测、能扛流的服务。这条能力线恰恰是很多培训课程和教育机构最不擅长教的。网上的教程大多止步于“模型训练完成”至于之后的事情全要靠自己在项目里摔打。这也是为什么我坚持认为从零学AI工程不能用“学算法”的逻辑来学得用“做系统”的逻辑来学。2. 从零开始的学习路线图五阶段我实际走下来的经验2.1 阶段一Python、SQL、Git是逃不掉的地基很多教程会先让你死磕数学我的建议反着来先动手写代码数学在用到时再补。Python这门语言不需要学成源码级大师但有几样东西必须熟练列表推导、字典操作、类和对象的基本写法、装饰器能看懂、生成器知道怎么用、会写函数式风格的map/filter。别小看这些做数据处理和写Pipeline时天天用。SQL是很多人忽略的一环。真实场景里数据不会像竞赛题那样打包好给你它躺在数仓里你得自己取数、理解字段含义、处理脏数据。至少要做到会写JOIN、GROUP BY、WHERE知道窗口函数的基本用法能用SQL做数据质量检查。我见过不止一个算法基础不差的人卡在“不知道去哪取数据”这一步。Git属于那种“不学就永远不知道哪里疼”的技能。不用懂太深但分支创建与合并、代码回滚、把大文件加进.gitignore、用tag标记版本这几件事必须形成肌肉记忆。没有Git管理代码后面的实验复现和多人协作会彻底失控。这个阶段每天2小时的话三到四周就能过完。别恋战重点是“能跑起来”不是“学得很深”。2.2 阶段二机器学习不是去背八股而是跑通最小闭环到了机器学习阶段最大的坑是陷入“算法八股”——今天看SVM推导明天看XGBoost论文一个公式看不懂就卡一整天。说实话AI工程里90%的场景用不到你手推SVM的KKT条件。你需要的是建立“最小学习闭环”给定一份数据你能完成特征处理、训练一个基础模型、评价它的效果、保存并加载模型。我当时就是用scikit-learn把这条链路跑通的。流程很简单用pandas读入一份结构化数据比如Kaggle的Titanic或UCI的Adult数据集。处理缺失值、做类别编码、特征缩放。用train_test_split划分训练集和测试集。分别跑逻辑回归、随机森林、XGBoost。用accuracy_score、f1_score做评估画出混淆矩阵。用joblib.dump保存模型写一个加载脚本做推理。这件事看着简单价值在于它让你第一次体会到“机器学习是一个可复用的流程”而不是一段一次性脚本。要刻意去理解几个概念过拟合与欠拟合、训练集/验证集/测试集为什么必须分开、交叉验证在干什么、分类问题为什么别只看准确率。这些概念后面会反复用到所以值得多花点时间。2.3 阶段三深度学习与大模型的基础功搞定了传统机器学习就可以进入深度学习。今天的AI工程深度学习是绕不开的但我的建议是不要一上来就追大模型而是先用PyTorch把基础功打牢。你需要依次搞懂这些环节张量的基本操作、自动求导机制、Dataset与DataLoader的作用、模型定义与训练循环的写法、优化器和学习率的作用、GPU训练时数据怎么搬到显存里。这些不是理论是你每天都要写的代码。我当时是拿MNIST手写数字识别当入门项目从零手写一个MLP分类器然后改进成CNN体会“加了卷积之后效果为什么会变好”。有了基础再看大模型就顺了。Transformer的核心机制——注意力机制、多头自注意力、位置编码——吃透原理之后去跑一个Hugging Face的BERT模型用现成库做文本分类。再到后面如果你有兴趣可以自己训练一个迷你的GPT模型几十MB那种不为实用就为了理解“预训练”到底在干嘛。这一层打通了后面接触LLM相关的工程你会比别人快很多。这个阶段建议投入六到八周算是整个路线里最耗时、也最值得的部分。2.4 阶段四工程化能力把模型从Notebook搬到服务里这是从“学过AI”到“能做AI工程”的分水岭。哪怕你模型训得一般只要这一步做得扎实在职场上就已经比一大堆调参选手有竞争力。核心要掌握三件事容器化、服务化、流程化。容器化就是学会Docker。不用懂太深的底层原理但要看得懂Dockerfile会构建基础镜像知道怎么把训练好的模型和依赖环境一起打包。它能解决一个特别现实的痛点你本地跑得好好的代码同事拉下来就是一串报错“在我机器上是好的啊”这句话从此可以不说了。服务化核心是你能把一个训练好的模型封装成HTTP接口。选FastAPI就对了。它天然支持异步自带接口文档用起来比Flask更现代。你至少要做到写一个/predict接口接收JSON入参调用模型推理返回结果然后把它跑在uvicorn或gunicorn上用curl或Postman验证请求成功。流程化则是把“训练、评估、预测”都写成可复用的脚本能做到一键训练、一键评估、一键部署。Notebook可以留着做分析和实验但到了交付环节一定要变成结构清晰的项目文件和脚本。这一步的核心不是工具本身而是“工程习惯”。2.5 阶段五全链路项目给自己造一个“迷你AI产品”零散的技能学完必须用一个全链路项目把它们串起来。项目不要贪大关键是“麻雀虽小五脏俱全”。我自己最推荐的一个练手项目是做一个中文文本情感分类服务大致步骤是收集或下载一份中文情感数据集比如酒店评论、电商评论。用BERT或者简化一点的模型做微调得到分类模型。用MLflow记录训练参数和指标把模型导出为ONNX格式。基于FastAPI写一个推理服务支持单条预测和批量预测。用Docker把服务打包本地起容器测试。用locust或ab做一次简单的压力测试看看并发20、50的时候延迟和成功率。写一个README记录部署方式、接口说明和已知问题。这个项目做完你的简历上就不仅仅写着“我会TensorFlow/PyTorch”而是“我能独立把一个模型从数据变成高可用服务”。这两句话在面试官眼里的分量完全不同。3. 核心链路实操从一份原始CSV到一套推理服务3.1 数据处理特征工程、数据集划分与“防泄漏”的基本功真实项目里最花时间的永远是数据处理。我第一次拿到一份几十万行的用户行为数据时差点被数据质量折磨到崩溃时间字段有时间戳也有文本、性别字段有“男/女/M/F/未知/空值”五种取值、同一用户在一小时内出现了几十条重复行为。这段经历让我后来养成了一个习惯——任何机器学习项目开始之前先花30%的时间做数据探索和数据清洗。特征工程先不做太复杂的把基本功练好缺失值处理删除、均值填充、模型预测填充、类别特征编码LabelEncoder、OneHotEncoder、数值特征标准化StandardScaler、MinMaxScaler。这些操作只需要记住一个原则标准化和编码的拟合只允许在训练集上进行然后用训练集学到的参数去转换验证集和测试集。数据集划分也不能随便。纯随机划分适合大部分分类问题但遇到时间序列数据一刀切随机切就造成了数据泄漏——比如你用未来数据训练去预测过去结果是“用答案去猜题目”。正确的做法是按时间顺序切分保证训练集时间早于测试集。另外分类任务强烈建议stratify参数它能让划分出的训练集和测试集保持相同的类别比例避免“测试集里全是负样本”这种乌龙。3.2 模型训练训练时不只看Loss还要盯住这5件事训练环节新手最容易只看Loss往下掉就以为万事大吉其实远远不够。我给自己列了一个“训练检查清单”每次训练都从头到尾过一遍Loss曲线训练集的Loss是否在持续下降如果震荡剧烈学习率可能太高如果下降缓慢学习率可能太低。验证集的Loss是否在下降一阵后开始反弹反弹就是过拟合的信号。训练/验证差距训练Loss降得很低、验证Loss却很高这是典型的过拟合。应对手段依次是增加数据、加Dropout、加正则化、做数据增强、用早停。指标选择的合理性二分类不要只看准确率样本不均衡时准确率会骗人改用F1、AUC、召回率、精确率配合着看。多分类可以看宏平均F1。随机种子固定这是老生常谈但真的很多人会忘。训练脚本开头把torch.manual_seed(42)、np.random.seed(42)、random.seed(42)全设好否则明天重跑可能结果就变了后面排查到怀疑人生。梯度异常Loss突然变成NaN大概率是梯度爆炸。排查顺序是检查学习率、检查输入数据是否包含了NaN、检查模型是否用了不稳定的激活函数。另外再分享一个小习惯**记录每一项训练超参包括batch size、学习率、优化器参数、数据划分的随机种子。**不用专门买工具写在一个固定的config.yaml里或者训练日志的第一行就行。等出了Bad Case再想回头排查你会发现这些记录救你命。3.3 模型部署把模型变成一台能伺候人的API服务服务部署最常见的问题是“拿训练环境当推理环境”。训练时你用的是PyTorch动态图、GPU、一堆实验代码推理时最好用更轻量的运行时。我是先学PyTorch直接部署上线被并发压垮过才去补ONNX Runtime的课。以FastAPI为例一个最基础的推理接口长得像这样from fastapi import FastAPI from pydantic import BaseModel import onnxruntime as ort import numpy as np app FastAPI() sess ort.InferenceSession(model.onnx) class Input(BaseModel): text: str app.post(/predict) def predict(data: Input): inputs preprocess(data.text) outputs sess.run(None, {input_ids: inputs[input_ids], attention_mask: inputs[attention_mask]}) label np.argmax(outputs[0], axis1).item() return {label: label}这个代码本身不难难的是后面的事。你怎么估算这个服务该开多少个Worker模型加载进内存后每个Worker都会复制一份模型开多了显存OOM开少了又扛不住并发。一般来说gunicorn的Worker数可以参考2 * CPU核心数 1但用了GPU推理时往往一个GPU进程就是极限再开就爆显存。部署期间还必需面对推理延迟和显存占用的问题。粗算公式很简单模型显存占用 ≈ 参数量 × 参数精度字节数。一个70亿参数的模型FP32全精度推理要占28GB显存INT8量化后降到7GB左右INT4更可以压到3.5GB左右。计算延迟时也要考虑batch size的影响——批量推理理论上摊薄单条成本但也要看服务端能不能一次性吃下这么多请求。3.4 用一次情感分类项目串起全流程学完上面的环节一定要自己完整地跑一遍别只看不练。我自己带新人最常用的例子就是中文评论情感分类它的好处在于数据好找模型复杂度可控业务逻辑直观而且能覆盖整条链路。整条流水线可以拆成这样数据准备收集约1万条带情感标签的评论按7:2:1划分训练、验证、测试集。数据处理清洗文本去重、去URL、去掉无意义符号使用分词器转换为模型输入格式。模型训练加载预训练BERT在训练集上微调2~3个epoch每500步观察一次验证集F1。模型评估保存测试集上的混淆矩阵观察哪些负面评论被误判为正面把它们单独拎出来当Bad Case。模型导出把PyTorch模型导出成ONNX格式用ONNX Runtime验证推理结果与PyTorch是否一致。服务化用FastAPI封装接口加入超时控制和错误处理启动uvicorn提供服务。压力测试先用ab -n 1000 -c 20跑一次看平均响应时间和成功率然后决定要不要加Worker数或上量化。等这一整套做下来你对AI工程的理解就不再是名词层面的了。你会很自然地想明白一件事为什么模型效果不错不等于系统稳定。数据慢、推理慢、并发高、内存溢这些都是系统问题必须用工程手段解决。4. 工具链选型我反复对比后留下的固定组合4.1 训练框架PyTorch为主TensorFlow为辅训练框架二选一我百分百推荐PyTorch。不是TensorFlow不好而是对于做AI工程的人来说PyTorch有三个不可替代的优势动态图机制调试时能随时print中间结果和写普通Python代码一样自然。TensorFlow 2.x也默认了动态图但生态里的历史包袱还在。社区生态Hugging Face、PyTorch Lightning、Kornia这些主流库全部扎根PyTorch。你在网上搜到的大部分最新模型代码默认就是PyTorch写的。部署链路的灵活性PyTorch模型可以导出ONNX也可以直接走TorchServe更可以自己用纯Python做推理服务。TensorFlow也不是完全退出我的工具箱。如果项目需要部署到移动端、嵌入式设备TensorFlow Lite依然有它的优势。但从学习效率出发先把一个框架吃透远比两个框架都会个皮毛要强得多。4.2 实验、数据与模型版本管理MLflow DVC Git以前做实验我的目录长这样model_v2_final_真的最终版.pth、model_v3_最终版2.pth……后来自己都分不清哪个对应哪份数据、哪个跑出了哪个指标。直到被逼着用了MLflow才治好了这个病。MLflow主要解决的是“实验追踪”问题你在mlflow.start_run()之后把参数、指标、模型文件统统记进去每次实验自动生成一条记录。过两个月回来看哪一条Run用了什么参数、跑出什么指标、模型存在哪一目了然。数据版本管理我配的是DVCData Version Control。DVC的思路是数据文件不进Git但数据的版本信息进Git。你把一份原始数据用dvc add加进仓库的时候它会生成一个元数据文件记录版本、路径和哈希值。之后想回到某个实验依赖的数据状态一个dvc checkout就搞定。Git负责代码DVC负责数据MLflow负责实验记录和模型。三者各管一摊组合起来就是一套个人版的MLOps。有人可能说“我一个人搞项目用这些是不是杀鸡用牛刀”我的回答是当你需要翻三天前的实验记录却找不到或因为数据被覆盖而重跑一遍训练的时候就会后悔没早用。4.3 服务化链路FastAPI、ONNX Runtime与容器化部署链路我现在的标配是FastAPI ONNX Runtime Docker。FastAPI适合AI服务有几个原因对异步请求支持好、用Pydantic做请求体校验省了很多脏活、自动生成Swagger文档方便联调。写接口的时候你只管定义模型输入输出的数据结构剩下的事情框架帮你搞定。ONNX Runtime是我导出模型后的首选推理引擎。它在CPU上就能跑得不错对GPU的利用效率也很高而且模型格式是开放标准不用担心锁定在某个训练框架里。PyTorch模型可以用一句torch.onnx.export导出成.onnx然后用onnxruntime.InferenceSession加载推理。这个转换过程能砍掉一些推理时的框架开销对低延迟场景帮助很大。Docker不必多说它是AI服务交付的一等公民。你只需把Dockerfile写清楚基础镜像、拷贝依赖、安装Python包、暴露端口、启动命令。然后docker build、docker run一份可复现的环境就这样诞生了。到了多人协同时这套流程能省掉大量“帮你看看环境”的沟通成本。5. 高频问题与排查经验速查表实操向5.1 训练阶段Loss不降、显存不足、过拟合怎么办训练中出现问题最忌讳的就是瞎试。我每次都是按下面的排查顺序来效率高很多。Loss不降最常见的五个原因数据预处理出错、标签错了、学习率不合适、模型没收敛、梯度异常。排查时先打印一批输入样本和标签人工检查再去调学习率试试降低10倍看Loss有没有变化最后再看模型结构和归一化层有没有问题。很多所谓“玄学”问题最后都查出来是数据问题。显存不足CUDA OOM是最容易解决的“难问题”。优先调小batch size还是不够就开梯度累积模拟更大batch的效果再不行就用混合精度训练torch.cuda.amp显存能省一半以上速度还能提不少。实在不行就要换小模型或者减序列长度了但这属于最后一招。过拟合的判断我在前面提过核心是“训练集表现好、验证集表现差”。应对优先级加数据 数据增强 Dropout 正则化 早停。别一上来就换模型先看看数据层面能不能缓解。5.2 部署阶段延迟高、并发上不去、内存暴涨怎么办部署阶段的问题往往比训练阶段更隐蔽。这里列几个我亲身踩过的坑。推理延迟高先看是不是模型太大。一个BERT-base模型在CPU上跑单条样本可能要几十毫秒如果业务要求每秒上千QPSCPU肯定顶不住。应对策略很明确要么换GPU要么做INT8量化要么换更轻量的蒸馏模型。先量化通常能把延迟砍掉30%-50%代价是精度略有损失。并发上不去优先检查Worker数和线程数。用gunicorn部署时Worker开太多会导致内存翻倍、上下文切换频繁开太少则CPU利用不充分。我习惯的做法是先用默认公式压测后看CPU和内存指标再调整。另外preload参数建议打开让模型在Worker分叉前就加载好否则每个Worker自己加载一遍模型启动时间会拖得巨长。内存暴涨多半是因为模型被复制多份。PyTorch默认的fork方式会有这个坑改用gunicorn --worker-class uvicorn.workers.UvicornWorker同时考虑用spawn方式启动。另外推理服务里不要缓存太多用户请求数据内存迟早被吃光。5.3 数据与实验管理复现不了、环境冲突怎么破复现不了几乎每个做过实验的人都会遇到。原因无非三类代码版本变了、随机种子变了、依赖版本变了。Git管住代码MLflow管住随机种子和超参requirements.txt管住依赖版本三条都做到复现问题基本消失。注意requirements.txt最好锁定到具体版本别写1.0这种。环境冲突是Python老问题了。今天这个包依赖A版本1.0明天另一个包要A版本2.0一套环境根本伺候不过来。我的标准是每个项目一个conda虚拟环境或者venv环境文件提交进Git仓库。脏活累活一开始做足后面省出的时间不是一星半点。5.4 我的十条防坑清单与习惯把经验浓缩成十条每一条都是真金白银换来的。动手之前先写个README.md把目标和方案写清楚项目跑偏的时候拉回来。数据文件不提交Git但数据来源和处理脚本要提交。训练脚本里所有随机种子统一设置写在最前面。任何操作先在小数据上试通再上全量。省时间也省算力。训练和推理准备两套依赖清单别让推理服务背上训练库。模型服务必须有超时设置否则一个慢请求挂死整个进程。日志是排查的第一现场。打印入参、出参、耗时、报错堆栈宁可多不可少。部署别一上来就上K8s先用Docker Compose把单机搞定。任何优化前先压测拿到基线再动手不要“感觉变快了”就收工。每次实验结束花十分钟整理记录这是整个项目最值的十分钟。6. 关于学习节奏与个人经验的一些话有人问我从零开始到底要多久如果每天能投入2小时左右我的经验是基础阶段三到四周机器学习四到五周深度学习六到八周工程化四到五周最后全链路项目再花三到四周持续打磨。前后加起来差不多四到五个月能到“独立做完整项目”的水平。关于学习节奏我自己最重要的体会是**一定要项目驱动不要章节驱动。**每一阶段学完都留下一个看得见摸得着的作品。Python学完写一个数据处理脚本机器学习学完跑通一个sklearn流程深度学习学完训出一个分类器工程化学完部署一个接口。这样回头看你看到的不是“我学了几个月”而是“我做了一串东西”简历、面试素材、信心全都从这里来。还有一点想特别说给刚起步的人听不要被“AI大牛都很厉害”这种幻觉吓住。你只需要比昨天的自己强一点把一条极小的链路端到端跑通就已经比绝大多数只停留在看视频、收藏教程的人强了。拿到一个项目先从“把菜做出来”开始再慢慢想怎么开餐厅。最后分享一个我现在的习惯每隔一段时间我会把自己的学习路径、踩坑记录和常用命令整理到一份个人文档里。不是为了发表而是为了让我自己快速回忆。AI工程这个领域变化太快今天ChatGPT热明天RAG热后天又出了个Agent框架什么都追一定追不动。真正扎实的永远是底层能力数据处理、模型训练、服务部署、监控调优、工程习惯。把这几样练到肌肉记忆任何新框架、新模型出来你都能在几天之内跟上它。这就是我从ai-engineering-from-scratch这一路走过来最想分享给你的东西。 
长河君 · 2026/10/4 22:14:30 · 阅读 1.2k AI工程从零开始：从CSV到API服务的完整路线
聊到AI工程很多人的第一反应是“深度学习很火我来学个PyTorch”。可真入了门才发现模型训练只是整条链路里的一小块。ai-engineering-from-scratch这个标题听起来像一门课本质上其实是一套能力体系——从原始数据到模型训练再到部署上线、监控迭代每一环都得能动手解决。我见过太多人花三个月调一个模型调到SOTA结果一问“怎么把它变成接口给用户用”就卡住了。这就是典型的“算法思维”和“工程思维”之间的断层。这篇文章想聊的就是我从零开始补齐AI工程能力的那条路线。它适合谁适合刚入门机器学习、想往工程方向走的开发者和学生也适合已经在做算法、但总觉得“交付很痛苦”的从业者。它能帮你解决的问题很明确**怎么把一份CSV变成API、把训练脚本变成可交付的服务以及在踩坑时能快速定位是数据问题、训练问题还是环境问题。**整篇都是顺着我实际摸索过的路径来的没有八股全是能落地的做法。1. 重新理解AI工程先把自己从“调参选手”变成“系统负责人”1.1 AI工程到底在解决什么问题如果只追热点你看到的AI工程是K8s、GPU集群、大模型推理引擎这些词儿。但回到本质上它解决的是一个很朴素的问题让模型从“实验室里的实验品”变成“生产环境里的稳定服务”。我经常用开餐厅来打比方。训练模型就像研发一道菜——你有菜谱模型结构、食材数据、灶台训练环境炒出一盘让评委点头的菜离线指标达标。但AI工程是把这道菜变成一家能每天营业的餐厅要设计后厨动线数据处理Pipeline要定标准菜谱模型版本管理要培训传菜员推理服务要处理顾客投诉Bad Case监控还得控制成本推理资源估算。光会炒菜开不了餐厅。这个视角很重要因为它决定了你学习的优先级。很多人一上来就啃Transformer论文、刷LeetCode但真正做AI工程时卡住你的往往不是模型结构而是下面这类问题数据里为什么有那么多缺失值和重复样本训练脚本在本机能跑换台机器就崩怎么用Docker固定环境模型精度不错但推理延迟20毫秒线上扛不住每秒1000个请求怎么办三个月前跑出来的结果现在复现不了了怎么管实验记录和随机种子这些问题没有一个是“算法调参”能解决的但它们恰恰是AI工程的核心。所以文章后面所有的内容都会围绕这条“从数据到服务”的链路展开而不是单讲模型结构。1.2 AI工程师、算法工程师、后端工程师三种角色三条能力线刚入行的时候我分不清“算法工程师”和“AI工程师”的区别觉得自己做了算法就是在做AI。后来项目一多才发现这是两条能力线交集有限。角色核心关注点典型产出日常工具算法工程师模型效果提升论文复现SOTA指标实验报告、模型权重PyTorch、Jupyter、WandBAI工程师模型生命周期管理稳定交付与运维可部署的服务、监控面板、Pipeline脚本Docker、MLflow、FastAPI、K8s后端工程师业务逻辑、高并发架构、数据库设计业务系统、微服务接口Java/Go、MySQL、Redis、消息队列AI工程师的位置正好卡在算法和后端中间。你需要懂一点模型训练不是为了刷指标而是为了能判断“这个模型上线后大概什么吞吐、什么显存开销”你也需要懂一点后端不是为了写复杂的业务系统而是为了把模型包成一个稳定、可观测、能扛流的服务。这条能力线恰恰是很多培训课程和教育机构最不擅长教的。网上的教程大多止步于“模型训练完成”至于之后的事情全要靠自己在项目里摔打。这也是为什么我坚持认为从零学AI工程不能用“学算法”的逻辑来学得用“做系统”的逻辑来学。2. 从零开始的学习路线图五阶段我实际走下来的经验2.1 阶段一Python、SQL、Git是逃不掉的地基很多教程会先让你死磕数学我的建议反着来先动手写代码数学在用到时再补。Python这门语言不需要学成源码级大师但有几样东西必须熟练列表推导、字典操作、类和对象的基本写法、装饰器能看懂、生成器知道怎么用、会写函数式风格的map/filter。别小看这些做数据处理和写Pipeline时天天用。SQL是很多人忽略的一环。真实场景里数据不会像竞赛题那样打包好给你它躺在数仓里你得自己取数、理解字段含义、处理脏数据。至少要做到会写JOIN、GROUP BY、WHERE知道窗口函数的基本用法能用SQL做数据质量检查。我见过不止一个算法基础不差的人卡在“不知道去哪取数据”这一步。Git属于那种“不学就永远不知道哪里疼”的技能。不用懂太深但分支创建与合并、代码回滚、把大文件加进.gitignore、用tag标记版本这几件事必须形成肌肉记忆。没有Git管理代码后面的实验复现和多人协作会彻底失控。这个阶段每天2小时的话三到四周就能过完。别恋战重点是“能跑起来”不是“学得很深”。2.2 阶段二机器学习不是去背八股而是跑通最小闭环到了机器学习阶段最大的坑是陷入“算法八股”——今天看SVM推导明天看XGBoost论文一个公式看不懂就卡一整天。说实话AI工程里90%的场景用不到你手推SVM的KKT条件。你需要的是建立“最小学习闭环”给定一份数据你能完成特征处理、训练一个基础模型、评价它的效果、保存并加载模型。我当时就是用scikit-learn把这条链路跑通的。流程很简单用pandas读入一份结构化数据比如Kaggle的Titanic或UCI的Adult数据集。处理缺失值、做类别编码、特征缩放。用train_test_split划分训练集和测试集。分别跑逻辑回归、随机森林、XGBoost。用accuracy_score、f1_score做评估画出混淆矩阵。用joblib.dump保存模型写一个加载脚本做推理。这件事看着简单价值在于它让你第一次体会到“机器学习是一个可复用的流程”而不是一段一次性脚本。要刻意去理解几个概念过拟合与欠拟合、训练集/验证集/测试集为什么必须分开、交叉验证在干什么、分类问题为什么别只看准确率。这些概念后面会反复用到所以值得多花点时间。2.3 阶段三深度学习与大模型的基础功搞定了传统机器学习就可以进入深度学习。今天的AI工程深度学习是绕不开的但我的建议是不要一上来就追大模型而是先用PyTorch把基础功打牢。你需要依次搞懂这些环节张量的基本操作、自动求导机制、Dataset与DataLoader的作用、模型定义与训练循环的写法、优化器和学习率的作用、GPU训练时数据怎么搬到显存里。这些不是理论是你每天都要写的代码。我当时是拿MNIST手写数字识别当入门项目从零手写一个MLP分类器然后改进成CNN体会“加了卷积之后效果为什么会变好”。有了基础再看大模型就顺了。Transformer的核心机制——注意力机制、多头自注意力、位置编码——吃透原理之后去跑一个Hugging Face的BERT模型用现成库做文本分类。再到后面如果你有兴趣可以自己训练一个迷你的GPT模型几十MB那种不为实用就为了理解“预训练”到底在干嘛。这一层打通了后面接触LLM相关的工程你会比别人快很多。这个阶段建议投入六到八周算是整个路线里最耗时、也最值得的部分。2.4 阶段四工程化能力把模型从Notebook搬到服务里这是从“学过AI”到“能做AI工程”的分水岭。哪怕你模型训得一般只要这一步做得扎实在职场上就已经比一大堆调参选手有竞争力。核心要掌握三件事容器化、服务化、流程化。容器化就是学会Docker。不用懂太深的底层原理但要看得懂Dockerfile会构建基础镜像知道怎么把训练好的模型和依赖环境一起打包。它能解决一个特别现实的痛点你本地跑得好好的代码同事拉下来就是一串报错“在我机器上是好的啊”这句话从此可以不说了。服务化核心是你能把一个训练好的模型封装成HTTP接口。选FastAPI就对了。它天然支持异步自带接口文档用起来比Flask更现代。你至少要做到写一个/predict接口接收JSON入参调用模型推理返回结果然后把它跑在uvicorn或gunicorn上用curl或Postman验证请求成功。流程化则是把“训练、评估、预测”都写成可复用的脚本能做到一键训练、一键评估、一键部署。Notebook可以留着做分析和实验但到了交付环节一定要变成结构清晰的项目文件和脚本。这一步的核心不是工具本身而是“工程习惯”。2.5 阶段五全链路项目给自己造一个“迷你AI产品”零散的技能学完必须用一个全链路项目把它们串起来。项目不要贪大关键是“麻雀虽小五脏俱全”。我自己最推荐的一个练手项目是做一个中文文本情感分类服务大致步骤是收集或下载一份中文情感数据集比如酒店评论、电商评论。用BERT或者简化一点的模型做微调得到分类模型。用MLflow记录训练参数和指标把模型导出为ONNX格式。基于FastAPI写一个推理服务支持单条预测和批量预测。用Docker把服务打包本地起容器测试。用locust或ab做一次简单的压力测试看看并发20、50的时候延迟和成功率。写一个README记录部署方式、接口说明和已知问题。这个项目做完你的简历上就不仅仅写着“我会TensorFlow/PyTorch”而是“我能独立把一个模型从数据变成高可用服务”。这两句话在面试官眼里的分量完全不同。3. 核心链路实操从一份原始CSV到一套推理服务3.1 数据处理特征工程、数据集划分与“防泄漏”的基本功真实项目里最花时间的永远是数据处理。我第一次拿到一份几十万行的用户行为数据时差点被数据质量折磨到崩溃时间字段有时间戳也有文本、性别字段有“男/女/M/F/未知/空值”五种取值、同一用户在一小时内出现了几十条重复行为。这段经历让我后来养成了一个习惯——任何机器学习项目开始之前先花30%的时间做数据探索和数据清洗。特征工程先不做太复杂的把基本功练好缺失值处理删除、均值填充、模型预测填充、类别特征编码LabelEncoder、OneHotEncoder、数值特征标准化StandardScaler、MinMaxScaler。这些操作只需要记住一个原则标准化和编码的拟合只允许在训练集上进行然后用训练集学到的参数去转换验证集和测试集。数据集划分也不能随便。纯随机划分适合大部分分类问题但遇到时间序列数据一刀切随机切就造成了数据泄漏——比如你用未来数据训练去预测过去结果是“用答案去猜题目”。正确的做法是按时间顺序切分保证训练集时间早于测试集。另外分类任务强烈建议stratify参数它能让划分出的训练集和测试集保持相同的类别比例避免“测试集里全是负样本”这种乌龙。3.2 模型训练训练时不只看Loss还要盯住这5件事训练环节新手最容易只看Loss往下掉就以为万事大吉其实远远不够。我给自己列了一个“训练检查清单”每次训练都从头到尾过一遍Loss曲线训练集的Loss是否在持续下降如果震荡剧烈学习率可能太高如果下降缓慢学习率可能太低。验证集的Loss是否在下降一阵后开始反弹反弹就是过拟合的信号。训练/验证差距训练Loss降得很低、验证Loss却很高这是典型的过拟合。应对手段依次是增加数据、加Dropout、加正则化、做数据增强、用早停。指标选择的合理性二分类不要只看准确率样本不均衡时准确率会骗人改用F1、AUC、召回率、精确率配合着看。多分类可以看宏平均F1。随机种子固定这是老生常谈但真的很多人会忘。训练脚本开头把torch.manual_seed(42)、np.random.seed(42)、random.seed(42)全设好否则明天重跑可能结果就变了后面排查到怀疑人生。梯度异常Loss突然变成NaN大概率是梯度爆炸。排查顺序是检查学习率、检查输入数据是否包含了NaN、检查模型是否用了不稳定的激活函数。另外再分享一个小习惯**记录每一项训练超参包括batch size、学习率、优化器参数、数据划分的随机种子。**不用专门买工具写在一个固定的config.yaml里或者训练日志的第一行就行。等出了Bad Case再想回头排查你会发现这些记录救你命。3.3 模型部署把模型变成一台能伺候人的API服务服务部署最常见的问题是“拿训练环境当推理环境”。训练时你用的是PyTorch动态图、GPU、一堆实验代码推理时最好用更轻量的运行时。我是先学PyTorch直接部署上线被并发压垮过才去补ONNX Runtime的课。以FastAPI为例一个最基础的推理接口长得像这样from fastapi import FastAPI from pydantic import BaseModel import onnxruntime as ort import numpy as np app FastAPI() sess ort.InferenceSession(model.onnx) class Input(BaseModel): text: str app.post(/predict) def predict(data: Input): inputs preprocess(data.text) outputs sess.run(None, {input_ids: inputs[input_ids], attention_mask: inputs[attention_mask]}) label np.argmax(outputs[0], axis1).item() return {label: label}这个代码本身不难难的是后面的事。你怎么估算这个服务该开多少个Worker模型加载进内存后每个Worker都会复制一份模型开多了显存OOM开少了又扛不住并发。一般来说gunicorn的Worker数可以参考2 * CPU核心数 1但用了GPU推理时往往一个GPU进程就是极限再开就爆显存。部署期间还必需面对推理延迟和显存占用的问题。粗算公式很简单模型显存占用 ≈ 参数量 × 参数精度字节数。一个70亿参数的模型FP32全精度推理要占28GB显存INT8量化后降到7GB左右INT4更可以压到3.5GB左右。计算延迟时也要考虑batch size的影响——批量推理理论上摊薄单条成本但也要看服务端能不能一次性吃下这么多请求。3.4 用一次情感分类项目串起全流程学完上面的环节一定要自己完整地跑一遍别只看不练。我自己带新人最常用的例子就是中文评论情感分类它的好处在于数据好找模型复杂度可控业务逻辑直观而且能覆盖整条链路。整条流水线可以拆成这样数据准备收集约1万条带情感标签的评论按7:2:1划分训练、验证、测试集。数据处理清洗文本去重、去URL、去掉无意义符号使用分词器转换为模型输入格式。模型训练加载预训练BERT在训练集上微调2~3个epoch每500步观察一次验证集F1。模型评估保存测试集上的混淆矩阵观察哪些负面评论被误判为正面把它们单独拎出来当Bad Case。模型导出把PyTorch模型导出成ONNX格式用ONNX Runtime验证推理结果与PyTorch是否一致。服务化用FastAPI封装接口加入超时控制和错误处理启动uvicorn提供服务。压力测试先用ab -n 1000 -c 20跑一次看平均响应时间和成功率然后决定要不要加Worker数或上量化。等这一整套做下来你对AI工程的理解就不再是名词层面的了。你会很自然地想明白一件事为什么模型效果不错不等于系统稳定。数据慢、推理慢、并发高、内存溢这些都是系统问题必须用工程手段解决。4. 工具链选型我反复对比后留下的固定组合4.1 训练框架PyTorch为主TensorFlow为辅训练框架二选一我百分百推荐PyTorch。不是TensorFlow不好而是对于做AI工程的人来说PyTorch有三个不可替代的优势动态图机制调试时能随时print中间结果和写普通Python代码一样自然。TensorFlow 2.x也默认了动态图但生态里的历史包袱还在。社区生态Hugging Face、PyTorch Lightning、Kornia这些主流库全部扎根PyTorch。你在网上搜到的大部分最新模型代码默认就是PyTorch写的。部署链路的灵活性PyTorch模型可以导出ONNX也可以直接走TorchServe更可以自己用纯Python做推理服务。TensorFlow也不是完全退出我的工具箱。如果项目需要部署到移动端、嵌入式设备TensorFlow Lite依然有它的优势。但从学习效率出发先把一个框架吃透远比两个框架都会个皮毛要强得多。4.2 实验、数据与模型版本管理MLflow DVC Git以前做实验我的目录长这样model_v2_final_真的最终版.pth、model_v3_最终版2.pth……后来自己都分不清哪个对应哪份数据、哪个跑出了哪个指标。直到被逼着用了MLflow才治好了这个病。MLflow主要解决的是“实验追踪”问题你在mlflow.start_run()之后把参数、指标、模型文件统统记进去每次实验自动生成一条记录。过两个月回来看哪一条Run用了什么参数、跑出什么指标、模型存在哪一目了然。数据版本管理我配的是DVCData Version Control。DVC的思路是数据文件不进Git但数据的版本信息进Git。你把一份原始数据用dvc add加进仓库的时候它会生成一个元数据文件记录版本、路径和哈希值。之后想回到某个实验依赖的数据状态一个dvc checkout就搞定。Git负责代码DVC负责数据MLflow负责实验记录和模型。三者各管一摊组合起来就是一套个人版的MLOps。有人可能说“我一个人搞项目用这些是不是杀鸡用牛刀”我的回答是当你需要翻三天前的实验记录却找不到或因为数据被覆盖而重跑一遍训练的时候就会后悔没早用。4.3 服务化链路FastAPI、ONNX Runtime与容器化部署链路我现在的标配是FastAPI ONNX Runtime Docker。FastAPI适合AI服务有几个原因对异步请求支持好、用Pydantic做请求体校验省了很多脏活、自动生成Swagger文档方便联调。写接口的时候你只管定义模型输入输出的数据结构剩下的事情框架帮你搞定。ONNX Runtime是我导出模型后的首选推理引擎。它在CPU上就能跑得不错对GPU的利用效率也很高而且模型格式是开放标准不用担心锁定在某个训练框架里。PyTorch模型可以用一句torch.onnx.export导出成.onnx然后用onnxruntime.InferenceSession加载推理。这个转换过程能砍掉一些推理时的框架开销对低延迟场景帮助很大。Docker不必多说它是AI服务交付的一等公民。你只需把Dockerfile写清楚基础镜像、拷贝依赖、安装Python包、暴露端口、启动命令。然后docker build、docker run一份可复现的环境就这样诞生了。到了多人协同时这套流程能省掉大量“帮你看看环境”的沟通成本。5. 高频问题与排查经验速查表实操向5.1 训练阶段Loss不降、显存不足、过拟合怎么办训练中出现问题最忌讳的就是瞎试。我每次都是按下面的排查顺序来效率高很多。Loss不降最常见的五个原因数据预处理出错、标签错了、学习率不合适、模型没收敛、梯度异常。排查时先打印一批输入样本和标签人工检查再去调学习率试试降低10倍看Loss有没有变化最后再看模型结构和归一化层有没有问题。很多所谓“玄学”问题最后都查出来是数据问题。显存不足CUDA OOM是最容易解决的“难问题”。优先调小batch size还是不够就开梯度累积模拟更大batch的效果再不行就用混合精度训练torch.cuda.amp显存能省一半以上速度还能提不少。实在不行就要换小模型或者减序列长度了但这属于最后一招。过拟合的判断我在前面提过核心是“训练集表现好、验证集表现差”。应对优先级加数据 数据增强 Dropout 正则化 早停。别一上来就换模型先看看数据层面能不能缓解。5.2 部署阶段延迟高、并发上不去、内存暴涨怎么办部署阶段的问题往往比训练阶段更隐蔽。这里列几个我亲身踩过的坑。推理延迟高先看是不是模型太大。一个BERT-base模型在CPU上跑单条样本可能要几十毫秒如果业务要求每秒上千QPSCPU肯定顶不住。应对策略很明确要么换GPU要么做INT8量化要么换更轻量的蒸馏模型。先量化通常能把延迟砍掉30%-50%代价是精度略有损失。并发上不去优先检查Worker数和线程数。用gunicorn部署时Worker开太多会导致内存翻倍、上下文切换频繁开太少则CPU利用不充分。我习惯的做法是先用默认公式压测后看CPU和内存指标再调整。另外preload参数建议打开让模型在Worker分叉前就加载好否则每个Worker自己加载一遍模型启动时间会拖得巨长。内存暴涨多半是因为模型被复制多份。PyTorch默认的fork方式会有这个坑改用gunicorn --worker-class uvicorn.workers.UvicornWorker同时考虑用spawn方式启动。另外推理服务里不要缓存太多用户请求数据内存迟早被吃光。5.3 数据与实验管理复现不了、环境冲突怎么破复现不了几乎每个做过实验的人都会遇到。原因无非三类代码版本变了、随机种子变了、依赖版本变了。Git管住代码MLflow管住随机种子和超参requirements.txt管住依赖版本三条都做到复现问题基本消失。注意requirements.txt最好锁定到具体版本别写1.0这种。环境冲突是Python老问题了。今天这个包依赖A版本1.0明天另一个包要A版本2.0一套环境根本伺候不过来。我的标准是每个项目一个conda虚拟环境或者venv环境文件提交进Git仓库。脏活累活一开始做足后面省出的时间不是一星半点。5.4 我的十条防坑清单与习惯把经验浓缩成十条每一条都是真金白银换来的。动手之前先写个README.md把目标和方案写清楚项目跑偏的时候拉回来。数据文件不提交Git但数据来源和处理脚本要提交。训练脚本里所有随机种子统一设置写在最前面。任何操作先在小数据上试通再上全量。省时间也省算力。训练和推理准备两套依赖清单别让推理服务背上训练库。模型服务必须有超时设置否则一个慢请求挂死整个进程。日志是排查的第一现场。打印入参、出参、耗时、报错堆栈宁可多不可少。部署别一上来就上K8s先用Docker Compose把单机搞定。任何优化前先压测拿到基线再动手不要“感觉变快了”就收工。每次实验结束花十分钟整理记录这是整个项目最值的十分钟。6. 关于学习节奏与个人经验的一些话有人问我从零开始到底要多久如果每天能投入2小时左右我的经验是基础阶段三到四周机器学习四到五周深度学习六到八周工程化四到五周最后全链路项目再花三到四周持续打磨。前后加起来差不多四到五个月能到“独立做完整项目”的水平。关于学习节奏我自己最重要的体会是**一定要项目驱动不要章节驱动。**每一阶段学完都留下一个看得见摸得着的作品。Python学完写一个数据处理脚本机器学习学完跑通一个sklearn流程深度学习学完训出一个分类器工程化学完部署一个接口。这样回头看你看到的不是“我学了几个月”而是“我做了一串东西”简历、面试素材、信心全都从这里来。还有一点想特别说给刚起步的人听不要被“AI大牛都很厉害”这种幻觉吓住。你只需要比昨天的自己强一点把一条极小的链路端到端跑通就已经比绝大多数只停留在看视频、收藏教程的人强了。拿到一个项目先从“把菜做出来”开始再慢慢想怎么开餐厅。最后分享一个我现在的习惯每隔一段时间我会把自己的学习路径、踩坑记录和常用命令整理到一份个人文档里。不是为了发表而是为了让我自己快速回忆。AI工程这个领域变化太快今天ChatGPT热明天RAG热后天又出了个Agent框架什么都追一定追不动。真正扎实的永远是底层能力数据处理、模型训练、服务部署、监控调优、工程习惯。把这几样练到肌肉记忆任何新框架、新模型出来你都能在几天之内跟上它。这就是我从ai-engineering-from-scratch这一路走过来最想分享给你的东西。