1. AI工程不是调包是从零开始建立一整套工程思路起这个项目名的时候我脑子里想到的是另一件事AI工程这个词这几年出现的频率越来越高但真正能说清楚“AI工程到底在干什么”的人其实不多。你问一个刚入门的朋友他可能会告诉你AI工程就是训练模型、跑推理、搭服务你要是问一个做后端的老开发他可能觉得AI工程就是把模型包装成API接口剩下的全是K8s的活儿。这两种说法都对一半但都离“工程”的核心差得很远。我个人的理解是AI工程是把模型从“实验室里能跑通的demo”变成“线上稳定运行、可维护、可迭代、可回滚的正式系统”的全套方法论和实践。它横跨数据、训练、评估、部署、监控、迭代这六个环节任何一个环节掉链子整个系统都会出问题。很多团队在模型效果上投入了大量精力却在部署和监控上翻了车最后模型再强也上不了线或者上了线就天天报警。这不是个别现象而是AI工程刚起步时最常见的坑。“from-scratch”这个后缀我更喜欢把它理解成一种心态不是让你从零手写神经网络框架而是让你从零开始把工程化的思维建立起来。调包是常态但调包之前你得知道包为什么存在、底层发生了什么、瓶颈可能在哪。这套认知体系才是“从零开始学AI工程”和“随便跑跑模型”之间的本质区别。这篇文章我打算按照我自己从零搭一套AI工程体系的真实路径来写。谁适合看一类是想进入AI工程方向但不知道从哪里下手的开发者另一类是已经在做AI但总觉得“工程化差一口气”的算法工程师。我会把环境搭建、数据准备、模型训练到部署监控的完整链路串起来讲每一段都会说清楚“为什么这么做”而不是只丢给你一堆命令。2. 环境与工具链搭建GPU、容器、依赖管理的一次性到位2.1 先搞清楚CPU和GPU各干哪些活再决定要不要上显卡很多刚接触AI工程的人会陷入一个装备焦虑是不是没有A100就没法干活了其实工程环境搭建的第一件事不是盯着显卡流口水而是把CPU和GPU的分工想清楚。你的数据处理、文本清洗、数据增强、评估脚本跑批量推理这些活儿百分之九十是CPU就能搞定的瓶颈通常不在算力而在I/O和代码效率。CPU能做的事情就交给CPUGPU只留给真正吃不消的部分模型训练、大规模微调、高吞吐在线推理。一台带GPU的开发机和一台高内存多核的CPU工作站在AI工程里的角色完全不同没必要一上来就堆硬件。我自己搭环境的时候踩过最大的坑是“环境漂移”问题。今天在本地环境跑通的训练脚本下周换台机器或者过两个月再跑依赖冲突、CUDA版本不匹配、Python小版本不一致各种玄学问题全冒出来了。所以从第一天起我就强制自己用conda管理Python环境每个项目单独一个环境目录再配合requirements.txt把依赖锁死。刚开始觉得麻烦后来真切体会到什么叫“省下来的时间都是自己的”。2.2 容器化为什么说你不需要逼自己从零写Dockerfile然后是容器化。很多教程会带你从零写一份细致的Dockerfile官方镜像、换源、装系统依赖、设环境变量、写启动脚本一套下来几个小时就没了。我个人的建议是第一次接触直接用官方镜像越少改动越好。比如做PyTorch相关的项目直接拉官方PyTorch镜像Python版本、CUDA版本、驱动版本都匹配好了你只要把自己的代码挂载进去就能跑。等这套流程跑顺了你自然会知道哪些依赖需要额外装、哪些基础镜像太大需要换一个体积更小的变体、哪些阶段可以合并来减少层数。到那时候再回头写自己的Dockerfile思路是完全不一样的——不是照抄而是在理解每一层作用之后动手。GPU容器还有一个专门的坑就是nvidia-container-toolkit。镜像拉下来了代码也挂载好了结果一跑就报CUDA error折腾半天发现宿主机的Docker根本不知道有GPU这回事。这个toolkit装好之后记得重启Docker服务再用nvidia-smi验证一下容器里能看到GPU这一步能帮你避开一周的奇怪问题。2.3 从30B模型显存焦虑到资金规划显存这个东西我见过太多人被分享帖里面的模型参数量吓住拿笔一算觉得自己这辈子都跑不动。实际上没必要。我们有几笔账可以算清楚。一笔账是训练和推理分开算。拿7B模型来说FP16权重大概是14GB显存这是量化之后单卡推理的基本盘。但如果你要做全参数微调账就不是这么算了。AdamW优化器要额外保存一份模型参数的副本、momentum和variance这三份加起来大约是权重三倍的内存开销全参数微调7B模型一张A100 80GB都捉襟见肘。所以现在主流做法是用LoRA这类参数高效微调把可训练参数压缩到总参数量的1%甚至更低24GB的消费级显卡也能跑得很开心。另一笔账是“我到底需不需要训练”。很多业务场景根本轮不到微调直接套一个大模型API或者开源模型做few-shot就能搞定效果还不差。训练是工具不是目的。你为了练手当然可以去微调一个模型但为了业务上线请先冷静评估现有模型加提示工程解决不了吗数据量够不够支撑一次有价值的微调微调之后带来的提升值不值得后续一长串部署和运维成本这些账算清楚之后硬件的钱反而是小事。我见过太多团队在算力上舍得花钱在数据清洗和评估体系建设上却舍不得投入人力最后模型训练一百遍还是没有可靠的办法知道它到底比上一个版本好在哪里。这才是AI工程里真正烧钱的地方。3. 数据是AI工程的地基清洗、标注、配比里的门道3.1 你的模型上限其实在数据阶段就已经定了做AI工程的时间越长我越认同一句话模型的上限是数据决定的训练只是把这个上限逼近。很多项目训练效果不如预期第一反应是调参、换结构、堆算力但其实问题在源头——数据质量不够、分布不对、噪声太多。文本类项目里最常见的三个问题我列一下这么多年反复遇到的一是重复数据。网上抓来的语料同一篇文章可能被转载了上百次你不做去重的话模型会在这些重复样本上过拟合看着训练集loss在掉一跑验证集就露馅。去重算法不用多复杂MinHash或者SimHash跑一遍就能筛掉绝大多数重复文本值得做。二是噪声标签。如果数据是业务系统里积累的标签往往带着历史包袱规则改过、标准变过、标注人员换过这些问题不筛出来模型学到的全是矛盾信息。清洗阶段一定要有专门的时间做标签一致性检查抽样本人工复核再决定是改标签还是丢样本。三是分布失衡。某些类别的样本特别多某些类别几乎没有模型学出来就是个偏科生。分类任务上最少类别和最多类别的样本量差十倍我都见过这个时候你先别急着上各种采样技巧先去想想能不能补充数据。数据实在补不到的话再考虑过采样、欠采样、或者把问题建模方式换一换。3.2 标注规范和评估集设计的实务操作标注这件事很多小团队觉得“不就是找几个人标一下吗”真正做起来才知道水深。我建议最迟在项目启动的第二周就要写一版标注规范。这份文档不需要长但要把边界情况说清楚。比如做情感分类“这个商品质量不错但物流太慢”到底是正向还是负向标注规范里如果没定义好十个人能标出五种结果。标注规范写好后还要有一个试标环节。挑几十条典型样本让每个标注人员先标一轮然后逐条对齐讨论。这个过程既是在校准标注标准也是在测试标注规范本身有没有写清楚。等试标结果的一致性上来了再进入正式标注阶段返工率会低非常多。评估集的搭建更需要提前规划。评估集不能只从训练数据里随便切一块出来要专门留出一段时间的数据、或者换个来源的数据做评估保证模型面对的是真正没见过的新样本。评估集里每个类别至少要有一定的数量不然算出来的准确率、召回率全是噪声根本没法做判断。3.3 数据版本管理工程化的一小步团队协作的一大步还有一件容易被当成“工具洁癖”的事情数据版本管理。很多算法工程师手里有一套“最终版”、“最终版2”、“真的最终版”数据文件在本地散落谁也不知道自己用的到底是哪份数据。等模型效果出了问题想复现根本找不到当时的训练集长什么样。我现在的做法是每个数据集都有明确的版本号训练集、验证集、测试集一起打包管理对应的清洗脚本、标注规范和生成时间都记录清楚。模型效果不佳或者想要复现历史实验的时候先定位到数据集版本再对齐代码版本问题排查的效率会高出一个量级。这个习惯前期会觉得繁琐但每个做过AI工程的人都会告诉你这是你迟早要补的课早补早受益。4. 从训练到评估把实验过程变得可复现、可比较4.1 第一次训练请从小模型开始正式进入训练环节我对新人的建议永远是第一次跑通用最小的模型。别一上来就微调几十亿参数的模型训练时间长、调试成本高、一次失败半天白等。你完全可以从几千万参数的小模型开始跑通数据加载、训练循环、评估脚本、日志记录这一整套流程确认链路都没问题了再切到目标规模的模型上。这套流程看起来简单里面藏着AI工程里最重要的一课可复现性。训练脚本拿到另一台机器上能跑出一样的结果吗随机种子设了没有数据加载顺序稳定吗框架版本变了影响大吗这些问题你第一次训练的时候不解决后面全都会加倍找上门。我见过一个团队同一个训练脚本两次跑出来的指标差了两个点排查了三天才发现是数据加载的shuffle没有固定种子——这种坑真的不希望你再踩一次。4.2 读懂训练日志loss值下降不是唯一的标准训练过程中的日志很多教程只告诉你“看loss有没有降”。实际上loss只是一个宏观信号它降了不代表模型在变好它不降也不一定代表训练失败。要结合更多维度一起看。过拟合的判断最常用的就是训练集loss和验证集loss的剪刀差训练loss持续下降而验证loss开始回升这个拐点之前就是最佳早停时机。学习率设高了loss会在一个平台期反复震荡就是不降数据有异常loss曲线可能出现突然的尖峰然后迅速回升。学会读这些曲线比盲目调参有价值得多。另外就是评估指标的选型。很多人上来就用准确率但准确率在类别不平衡的时候极具误导性。九成样本是A类一成是B类模型无脑全预测A类就有90%的准确率看起来很强实则屁用没有。你要根据任务类型去选指标分类任务上Precision、Recall、F1排序任务上用NDCG、MRR生成任务就要结合文本本身的评估维度。写代码之前先想清楚“好”到底怎么定义这是评估体系设计的起点。4.3 微调方案选择题LoRA还是全量微调关于微调方案现在LoRA几乎是默认选项了但也要明白它和全量微调各自适合什么场景。LoRA训练参数量少、显存占用低、训练速度快而且可以在基座模型之上同时挂多个LoRA适配器按需切换这在很多业务场景下极其方便。缺点是模型容量上限受限如果任务难度高、数据量大LoRA可能达不到预期效果。全量微调效果上限更高但对显存、训练时间、数据量的要求全维度拉满而且微调完的模型就“定形”了再想适配其他任务只能重新训练非常不灵活。我的经验是起步阶段先跑LoRA效果好就继续深入数据量大到LoRA明显不够用的时候再考虑全量微调。这个顺序能帮你省下大量试错成本。5. 部署与上线让模型从“能跑”变成“好用”5.1 三个核心问题延迟、吞吐、成本模型训练完了评估也通过了接下来是让模型真正见客。部署方案的设计本质上是在延迟、吞吐和成本之间做取舍。我举个例子。你在Web服务里在线调用模型每来一个请求就同步推理一次这叫在线推理。它的优点是简单直接、响应快但GPU利用率通常不高——大部分时间GPU都在等你网络请求的数据送过来。如果业务是几百个用户同时问问题一次性把请求攒一批再统一交给GPU并行计算这就是批处理推理。延迟会稍微升高但吞吐量翻倍都是正常的GPU利用率也好看很多。还有一条路是异步处理。请求先进消息队列后台Worker一批一批消费前端的交互可以变成“提交任务、轮询结果、完成后取走”。适合那些不需要实时响应的场景比如每天下班后跑批量分析任务。这三种模式没有绝对优劣只有适不适合你的业务场景。5.2 精度和速度的权衡量化到底行不行模型压缩是部署绕不开的话题其中量化带来的争议一直不少。FP16转INT8模型体积减半、推理速度提升但精度会有一定损耗。对于生成类模型量化后可能不是每句话都变差但会在某些边缘case上出现质量回退。所以我不建议上来就无脑开INT8。我的路径是先跑FP16的基线记录好各项指标和延迟数据再做INT8的量化推理跑同一套评估集两者对比如果指标下降在可接受范围之内就上INT8否则退回FP16或者尝试混合精度方案。量化的收益是实打实的但前提是你能用评估证据说服自己“不会出事”。工程上没有证据的优化都是赌博。部署环节我强烈建议了解vLLM这类推理框架它对连续批处理做了深度优化可以把GPU利用率撑得很高。同样是跑一个开源模型vLLM和直接用原始框架的吞吐差距可以达到好几倍。省下来的GPU卡就是实实在在的预算。5.3 上线前必须做好的压测和监控体系很多团队第一次部署模型的时候想的都是“让它跑起来”很少有人认真想一个问题跑起来了然后呢线上的模型什么时候开始悄悄变差了哪个请求触发了超长推理时长GPU显存是不是快要爆了这些如果没有监控你就是闭着眼睛在运营一个AI系统。我上线前一定会做的三件事一是压测把线上的预期流量放大几倍去测看延迟和错误率什么时候开始失控拿到一个真实的容量上限二是日志结构化请求参数、推理耗时、token用量、返回结果都打点记录这是后续排查问题的弹药库三是建立指标面板QPS、P99延迟、错误率、GPU利用率每天开门先看这几个数字心里有底再开始干活。监控体系搭好之后还要有一个简单的告警闭环延迟超过阈值了谁负责看、错误率飙升时是直接回滚还是先摘流量这些都应该提前商量好而不是等事故发生了才开始开会吵架。5.4 灰度发布和回滚把试错成本控制在最小范围新模型上线最忌讳的是“全网一刀切”。哪怕离线评估指标再漂亮线上真实流量跑起来也总有你想不到的情况某种输入触发了罕见bug、某种写法导致了异常长的输出、某种语言风格让质量急剧下降。灰度发布就是解决这个问题的。先切5%的流量到新模型观察一阵子指标跟旧模型做对比发现没问题再提到20%、50%最后全量。每一步都留足观察时间每一步都有明确的回滚预案。这个过程看起来慢但恰恰是慢工出细活——AI系统上线后的重大事故绝大多数都是因为跳过了灰度直接全量惹出来的。6. 常见问题与排查技巧实录做AI工程这两年多遇到过的坑实在太多我整理几个高频问题出来对应的排查思路也都是自己走晕过几轮之后总结出来的。GPU显存不足这是个报错不是个问题描述。显存不足的背后可能是单条数据太长导致batch内动态padding过长、可能是评估时也在开梯度、可能是多进程DataLoader的共享内存占用、也可能是推理框架的缓存设置不合理。我一般先关掉梯度推理再把batch size减半试试同时看一眼是不是有残留进程占着显存。一套排查下来大多数情况都能找到真正的瓶颈。训练一个晚上醒来发现loss变成NaN了这个我经历得太多久病成医。先查学习率是不是太大再把数据样本里有问题的部分找出来——某个样本某个字段是非法值喂进去直接让梯度爆了。还有一个隐藏很深的坑某些模型加了梯度裁剪和权重衰减之后特定初始化条件下训练中期仍可能出现数值溢出。我的建议是训练脚本一上来就启用梯度裁剪不要等出问题再补。推理延迟很高但GPU利用率也很高这听起来像是利用率高就该心里踏实其实背后可能藏着更严重的问题——不是算力不够而是并发处理得不够聪明。我遇到过的情况是每一路请求都独占一个CUDA stream导致资源互相挤兑。换用连续批处理之后同样的负载下P99延迟降了差不多一半。再补一个小场景模型明明量化了速度反而变慢。这个我实测过某些模型在INT8时如果算子没有对应的kernel优化落地反而会走一个慢速回退路径看起来量化了实际上更慢了。这种情况只能逐层profile看看算子级别的耗时分布或者干脆换一个对INT8支持更成熟的推理框架。7. 最后分享一下我个人的一些体会我把这个项目命名为“from-scratch”其实还有一个很私人的原因我自己就是从零开始走过来的。最早接触AI工程的时候什么都不会光是把依赖环境折腾明白就花了一周。训练脚本一跑就崩GPU买了等你半天跑出个效果还说不清楚为什么好。踩过这些坑之后我最大的体会是AI工程的能力不是靠看教程看出来的是一点点调试调出来的。你亲手把一个报错从“看不懂”修到“一眼就知道是什么问题”把一套训练流程从“碰运气能跑通”稳定成“换台机器照样复现”把模型从“跑起来了”带到“上线后稳定可回滚”——这种实打实的过程才是“从零开始”这四个字真正的分量所在。如果你也正走在这条路上我的建议就是一句话别贪大先跑通。用最小的模型、最少的数据、最简单的架构把一个完整的AI工程链路走通一遍。过程中遇到的所有问题都是你后面最值钱的经验。祝你少踩几个我踩过的坑。