所谓 ai-engineering就是从零开始把模型从 idea 推到线上并且保证它在真实流量下稳定运行。我见过太多同学把大量时间花在调参和模型结构上却忽略了数据版本、环境依赖、部署监控这些真正决定项目能否落地的环节。如果你正准备动手做一个 ai-engineering 项目或者已经在路上了下面这些经验应该能帮你少踩几个坑。有人觉得从零开始就是装一个深度学习框架跑通一个开源模型就算入门了。实际上一旦进入真实业务你会发现数据是脏的、环境是乱的、模型是回不去版本的、线上是没法监控的。这篇内容没有高深数学只有我从环境搭建、数据处理、训练追踪到部署监控整个链路中踩过的坑和整理出来的方法适合刚入门的同学也适合已经在业务里摸爬滚打想补上工程短板的工程师。1. 先搞清楚ai-engineering 到底在解决什么问题1.1 从 Notebook 到生产环境的鸿沟很多人的第一个模型都是在 Jupyter Notebook 里跑通的读一个 CSV跑一个简单的网络看到 loss 下降就觉得自己会了。但真实业务里几乎没有这种温柔场景。你面对的是几个 TB 的日志文件是每天凌晨才落地的增量数据是突然断掉的上游任务是训练到一半被运维 kill 掉的实例以及下次跑同一个实验时完全不一样的指标。Notebook 的核心问题是状态不可控单元格可以乱序执行全局变量可能被悄悄覆盖依赖包升级后旧结果再也不复现。生产环境需要的是确定性同样的代码、同样的数据、同样的配置必须得到同样的结果。ai-engineering 的价值就是把这些不确定性一个个摁住让模型开发像软件工程一样有版本、有测试、有监控、有回滚。我见过一个团队模型效果明明在实验里很好上线之后却一塌糊涂。排查到最后发现他们的线上服务用的是另一份“手工抽出来的特征”和训练时用的特征口径差了整整一个字段。这已经不是模型问题是工程问题。如果不解决这类问题再好的算法也落不了地。1.2 从零起步需要建立的四种能力从零开始搭 ai-engineering我不建议一上来就追新框架而是先建立四种底层能力它们几乎决定了项目后续能不能稳定运转。环境可复现能力代码、依赖、系统版本、GPU 驱动都要能被固定和恢复不能依赖“某个人的电脑”。数据可追溯能力数据从哪来、经过什么清洗逻辑、对应哪个时间版本都要能随时回放不能只留下一个data_final_v2.csv。实验可比较能力每次实验的超参、指标、模型产物、代码提交号都有记录方便横向对比而不是靠记忆强行“我觉得这个模型更好”。服务可观测能力线上推理延迟、吞吐、输入特征分布、预测结果都要可监控出了问题能在几分钟内定位而不是等用户投诉。这四种能力有点像盖房子的地基。算法模型是地板以上的部分大家都看得见但住得稳不稳取决于地基浇得实不实。后面几章我就按这个思路逐步拆解从零搭建的完整过程。2. 从零搭建开发环境把“在我机器上能跑”变成“在任何机器上能跑”2.1 操作系统与硬件规划环境搭建是第一道门槛。做 ai-engineering建议直接选 Linux 作为开发和生产环境发行版用 Ubuntu Server LTS 比较省心。原因很实际NVIDIA 驱动、CUDA 工具链、Docker 容器、PyTorch 预编译包对 Ubuntu 的支持最完善。如果你用的是 macOS日常调试没问题但最终部署大概率还是 Linux早一点统一环境能少很多麻烦。硬件规划上我建议先列需求再花钱。训练阶段需要 GPU显存决定了你能跑的 batch size 和模型规模。如果你主要是微调开源模型或者做中小规模数据实验一张 24GB 显存的消费级卡比如 RTX 4090足够起步。如果涉及大模型预训练那就要考虑多卡集群网络带宽同样重要。内存和 CPU 也千万别省尤其数据预处理和特征工程阶段CPU 核心数和内存大小往往比 GPU 更容易成为瓶颈。一个我常用的起步配置CPU 32 核、内存 128GB、系统盘 500GB SSD、数据盘 4TB SSD、GPU 1 到 2 张。这个配置对大多数 CV/NLP 实验项目都够用。另外一个容易忽略的点数据盘和系统盘分离日志、模型权重、数据集都放数据盘避免系统盘被日志塞满导致服务器宕机。2.2 Python 环境与依赖管理Python 环境管理是 ai-engineering 里最容易翻车的地方。我见过太多人直接pip install到系统环境结果过两周一个包升级项目就全废了。标准做法是使用虚拟环境推荐 conda 或者 pyenv virtualenv。我自己常用 conda因为它还能顺手管一些非 Python 的底层库。创建一个新环境并固定 Python 版本conda create -n ai-engineering python3.10 -y conda activate ai-engineering然后安装项目依赖。这里有一个关键习惯不要写成pip install requests就完事而是把精确版本写进requirements.txt。更稳妥的方式是直接用pip freeze生成当前环境的完整版本快照pip freeze requirements-lock.txt这样别人拿到项目后直接根据锁文件恢复环境基本能复现 90% 的运行结果。如果团队里有多个人协作可以考虑更专业的工具比如 Poetry 或 PDM它们能同时管理依赖树和打包。但无论用哪种工具核心原则就一条所有依赖必须版本化不允许任何人手动往环境里塞包。2.3 训练框架与GPU运行时深度学习框架我默认选择 PyTorch它对工程生态的支持比较成熟社区也活跃。安装 PyTorch 时最坑的是 CUDA 版本匹配。nvidia-smi显示的 CUDA Version 是驱动支持的最高版本不代表你要安装的 PyTorch 就一定要对应它。正确做法是先查 PyTorch 官方支持矩阵再选择配套的 CUDA 运行时。安装完成后第一件事是验证python -c import torch; print(torch.__version__, torch.cuda.is_available())如果输出True说明环境基本就绪。如果False大概率是 PyTorch 装成了 CPU 版本或者 CUDA 库缺失。我的建议是先卸载再用官方命令重新安装 GPU 版本pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124对于常见组合可以参考下面的对应关系以我近期实践为准显卡驱动支持 CUDAPyTorch 版本常用 CUDA 运行时11.8 及以上2.0 - 2.1CUDA 11.812.1 及以上2.2 - 2.4CUDA 12.1 / 12.4这里想特别提醒不要盲目追求最新 CUDA训练框架支持什么就装什么。我见过有同事把驱动升级后旧项目的预编译算子全部失效被迫回滚驱动整整浪费了一天。环境稳定比版本新重要得多。3. 数据管道与特征工程AI工程的地基3.1 数据采集和清洗的工程化数据是 AI 工程最容易“看起来没问题实际全是坑”的部分。很多项目初期数据科学家手动下载一份 CSV做清洗后另存为final_v2.csv模型训练时直接读这个文件。等到需要复现实验、增量更新、排查线上问题的时候根本没人说得清这个文件是怎么来的、里面做了哪些处理。正确的做法是把数据采集和清洗写成一个独立模块通过脚本执行并且保证幂等性同一个任务跑多少次结果都一样。对于需要从数据库或对象存储拉取的源数据记录源路径和拉取时间清洗过程中每做一步处理就输出一份带版本标记的中间数据而不是只保留最终结果。例如用 DVC 对数据目录做版本管理dvc init dvc add data/raw git add data/raw.dvcDVC 会记录数据的哈希值和文件路径和 git 提交记录关联起来。将来想恢复某次实验对应的数据直接通过 DVC 签出即可不需要从同事的网盘里翻找“最终版”。清洗逻辑也要注意不要满屏幕if判断和 magic number。把缺失值处理、类型转换、异常值过滤都封装成函数并且加上必要的日志。比如“删除发货日期大于签收日期”的订单这个规则背后为什么这样定义最好写进注释。否则三个月后你自己看代码都会一脸茫然。3.2 特征工程与数据版本管理特征工程是决定模型上限的关键也是最容易和训练代码耦合的地方。我建议把特征计算从训练脚本中抽离出来做成独立的特征库。每个特征都有确定的名称、类型、计算逻辑、依赖的表或字段。这样训练和线上推理才能共用同一套特征函数避免“训练用了 A线上用了 AB”这种悲剧。在实践中我会把特征分为离线特征和实时特征。离线特征可以提前批量计算并存储适合 T1 的模型更新实时特征需要在线实时拼接适合风控、推荐召回等场景。无论哪种特征数据同样要做版本管理。特征目录加入 DVC 后我们可以轻松回答“当前模型是用哪一批特征训练的”这个问题。特征版本和数据版本一样重要。我曾经遇到过一个模型指标突然大幅下降查了半天最后发现是上游团队把“用户活跃度”字段的计算规则改了旧特征名还在但含义已经变了。特征版本管理配合监控告警可以在这种变更发生后的第一时间发现异常而不是等模型效果崩了才开始回溯。3.3 数据质量监控的落地做法很多团队等模型上线后才开始做监控却发现不知道监控什么。我的经验是提前定义数据质量指标在训练前和训练后都要跑。数据质量监控的核心指标一般包括字段缺失率缺失率突然升高说明上游表格可能没更新或者解析逻辑出错。字段取值范围年龄出现 999、金额出现负数这类异常值基本就是数据 bug。数据分布漂移比较实时数据分布与训练数据分布是否显著不同常用 PSI 或 KL 散度分数超过阈值就告警。唯一键重复率主键重复会导致训练时样本泄漏上线时打分重复。实现层面可以用whylogs或great-expectations这类开源库生成数据 profile再写一个定时任务每天对最新批数据计算指标和历史基线比较。超过阈值就发告警到企业微信或钉钉群。我曾经靠着这个机制在上游数据接入错误后的半小时内就收到告警避免了模型带着脏数据跑一整天。这种监控看起来不起眼但长期价值极大。4. 模型训练与实验管理让每次实验都说得清楚4.1 训练脚本的工程化改造刚开始写训练代码时我也习惯一个文件干到底读数据、定义模型、写训练循环、算指标全部塞在同一个脚本里。结果就是改一个 batch size 要翻好几个地方换模型结构要复制整个文件程序跑崩了都不知道是数据问题还是模型问题。后来我把训练代码拆分成标准目录configs/ # 存放所有实验配置通常是 yaml 文件 data/ # 数据加载和特征处理相关代码 models/ # 模型结构定义 trainer/ # 训练和验证逻辑 utils/ # 通用工具函数 main.py # 入口负责读取配置并组装各模块入口脚本只做三件事加载配置文件、准备数据、启动训练。所有超参数从文件里读不硬编码在代码里。配置文件示例model: name: resnet18 pretrained: true train: batch_size: 64 epochs: 50 learning_rate: 0.001 weight_decay: 0.0001 data: train_path: data/features/train.parquet val_path: data/features/val.parquet seed: 42这样的结构有很多好处新实验就是新增一个 yaml 文件不用改代码回看实验记录时看一眼配置就知道当时跑的是什么。还有一个容易忽略的习惯在入口处固定随机种子包括 Python、NumPy、PyTorch 的随机种子确保实验可复现。4.2 实验追踪与超参管理模型训练跑完之后如果你只留下一个model.pth文件那和没跑这个实验基本没什么区别。因为过程中涉及的数据版本、代码版本、超参数、评估指标全都丢了。要追踪这些信息我推荐使用 MLflow它功能足够轻量又方便自托管。在训练代码里加几行import mlflow with mlflow.start_run(): mlflow.log_params(cfg[model]) mlflow.log_params(cfg[train]) mlflow.log_metric(val_acc, val_acc) mlflow.log_artifact(model.pth)同时把 git commit hash 和 DVC 数据版本也记进 run。这样每次实验都有完整的血缘关系代码、数据、超参、指标、产物全部绑定。之后对比不同实验直接在 MLflow UI 里看曲线或者用脚本拉取所有 run 的指标做一个排序表效率远高于每个人口头发“我这边 acc 很高”。这里有个操作细节每次跑实验之前先 commit 代码。我吃过亏跑了一组实验效果不错想复盘代码结果发现代码没提交只能靠模糊记忆去恢复。现在我的习惯是如果代码有改动先 commit 再跑实验这样才能保证实验记录和代码版本对得上。4.3 模型评估与基线对比评估环节最忌讳“只看一个总指标”。比如分类问题只看 accuracy在样本不均衡时会产生严重误判。正确的做法是同时看多个维度业务相关指标准确率、召回率、F1、AUC、性能指标推理延迟、吞吐量、稳定性指标线上指标方差。其中业务指标的选取最好和业务方对齐而不是纯算法团队自己拍脑袋。建立基线也很重要。不要一上来就上深度模型先用逻辑回归、XGBoost 这类简单模型跑一个基础分数。这个分数是后续所有复杂模型的“地板”如果加了深度模型之后提升很小就要重新评估投入产出比。我见过有的项目深度学习比 XGBoost 只提升 0.1% 的 AUC但工程复杂度翻了几倍最后实际业务收益几乎为 0这种就是没有做好基线对比的代价。评估脚本要保持统一不能每个模型一套评估逻辑。把所有模型的预测结果、真实标签、评估指标统一存成一个评估报告并且和 MLflow 里的 run 关联。这样线上决策时可以直接追溯某某某个模型在哪个数据集上 AUC 是多少训练代码和特征版本分别是什么。逻辑越清楚后续迭代越省心。5. 模型部署与服务化从离线模型到在线服务5.1 部署形态选择模型训练之后先别急着上 API 服务想清楚业务需要的是离线预测还是在线推理。这两种形态差别很大。离线批量预测每天定时跑一次处理全量或增量数据结果写入数据库或对象存储。适合场景用户画像、商品召回、日报级风险评分。在线实时推理请求进来时毫秒级返回结果。适合场景搜索排序、实时反欺诈、推荐位实时打分。还有一个介于两者之间的方案先离线计算结果在线直接查表。比如把召回结果提前算好存到 Redis线上推荐时只做查表和排序。这种设计很多时候比强行上实时推理更划算。部署形态稳定后再考虑并发、延迟、成本问题。如果一天只跑一次离线任务就没必要上 K8s。5.2 模型 serving 框架与接口封装在线推理服务我用过几种方案最简单可靠的是用 FastAPI 封装模型。FastAPI 自带请求校验、接口文档、并发能力足够覆盖中小规模业务。关键点是避免每次请求都加载模型模型文件要初始化一次放在全局。一个最简示例from fastapi import FastAPI import torch app FastAPI() model None app.on_event(startup) def load_model(): global model model torch.load(model.pth, map_locationcpu) model.eval() app.post(/predict) def predict(payload: dict): features payload[features] with torch.no_grad(): tensor torch.tensor(features).unsqueeze(0) output model(tensor) return {score: output.item()}这里有几个细节model.eval()一定要调用它会影响 dropout 和 batchnorm 的行为推理时用torch.no_grad()关闭梯度计算节省内存和计算量如果同一时间请求很多需要考虑 batch 化推理把多个请求拼成一个 batch 一次过模型吞吐能提升数倍。无论用什么框架都要把模型输入输出的版本化纳入设计。线上接口升级时旧模型和新模型可能并存需要支持灰度切换。数据格式的任何改动都要走版本兼容而不是直接把请求字段改掉否则上游调用方很容易挂。5.3 容器化与弹性伸缩模型服务化之后下一步是容器化。Docker 是目前最通用的打包方案它能把代码、模型、依赖库、运行环境打包成一个镜像保证开发环境和生产环境完全一致。一个相对规范的 Dockerfile 长这样FROM python:3.10-slim WORKDIR /app COPY requirements-lock.txt . RUN pip install --no-cache-dir -r requirements-lock.txt COPY model.pth /app/model.pth COPY app /app/app EXPOSE 8000 CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]使用多阶段构建先在基础镜像中编译依赖再把编译产物复制到运行镜像可以显著减小镜像体积。我习惯把模型文件拆出来单独构建避免每次代码变更都重新拷贝一个几百 MB 的模型文件。部署时如果项目还在早期用 docker-compose 启动服务就够没必要直接上 K8s。等到需要多实例、自动扩容、滚动更新时再迁移到 K8s。在 K8s 里使用 GPU 资源要声明资源类型nvidia.com/gpu同时配好健康检查接口让容器就绪后才知道它可以接收流量。我踩过最深的坑是容器启动时加载模型耗时超过健康检查默认周期导致启动就被 kill后来把就绪探针的初始延迟调大才解决。6. 常见问题与排查技巧实录6.1 环境不一致导致的“在我电脑上好好的”这是我收到最多的求救信息。典型场景是本地跑得好好的推到服务器上就报错No module named xxx或者CUDA error: no kernel image is available for execution on the device。第一种情况往往是依赖没有完整同步第二种情况是 PyTorch、CUDA 和显卡驱动三者版本不匹配。解决办法很简单不要靠手动安装依赖而是把整个环境固化成 Docker 镜像或者用 conda 环境导出完整清单conda env export environment.yml换一台机器后直接用conda env create -f environment.yml重建能解决绝大多数环境问题。如果还是不行优先检查 CUDA 驱动与 PyTorch 版本的兼容性用nvidia-smi看驱动跑torch.version.cuda看 PyTorch 编译时用的 CUDA 版本两者对不上就重装 PyTorch。6.2 GPU 显存溢出与数据加载瓶颈训练时CUDA out of memory是最常见的崩溃信息。很多人第一反应是调小 batch size但更规范的做法是先搞清楚显存都去哪了。模型参数、梯度、优化器状态、中间激活值都会占显存尤其是激活值会随着 batch size 和序列长度成倍增长。如果 batch size 受显存限制可以用梯度累积来模拟更大的 batchaccumulation_steps 4 for step, (x, y) in enumerate(loader): loss model(x, y) / accumulation_steps loss.backward() if (step 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()同时可以开启自动混合精度scaler torch.cuda.amp.GradScaler() with torch.cuda.amp.autocast(): loss model(x, y) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()数据加载慢也会让 GPU 长时间摸鱼。常用优化包括DataLoader设置num_workers 0和pin_memoryTrue尽量使用内存映射格式如 parquet避免每次读取都做大量解析。这些小改动经常能把训练速度提升 30% 以上。6.3 模型漂移与线上反馈闭环模型上线后效果下滑不一定是模型本身的问题。先检查线上输入数据的分布是否发生了漂移再检查业务规则是否有变化最后才是重训。很多团队一看到指标跌就急着用最新数据重训结果重训完指标更差原因就是没搞清根因。我建议在模型服务里加预测日志记录请求时间、输入特征快照、预测结果、实际业务结果如果回流。这部分日志是后续做漂移分析和模型重训的重要原材料。定期把线上最近一段时间的样本拿出来和训练集的特征分布做对比生成季度报告。一旦发现漂移再触发重训流程。整个过程要自动化不要等人去跑脚本。6.4 一个完整的排查案例我印象很深的一次线上事故推荐服务 p99 延迟从 50ms 涨到 300ms直接拖垮了页面加载。一开始以为是模型变大或者 GPU 不够看了监控发现 CPU 使用率也居高不下。通过 profiling 发现耗时不是模型推理而是特征拼接部分写了一个双层循环在用户多、商品多时计算量爆炸。那次排查花了两小时真正的原因非常简单某个新来的同学把一些特征的笛卡尔积直接用了双重 for 循环实现在训练数据量小的时候没问题上线后被真实流量一放大就出问题。最后改成向量化操作延迟瞬间回到 50ms 附近。这个案例让我养成了一个习惯线上服务的任何代码路径都要做最坏情况下的复杂度评估不能只拿小批量数据测一测就上线。最后说一个我自己的习惯每次跑实验前先把 seed 固定、把 config 存成 yaml、把 git commit hash 记录到实验跟踪系统。就这三步能让你少掉一半的“怎么复现”问题。ai-engineering 的难点从来不是数学而是如何在各种不确定性中建立一个相对确定的流水线。希望这篇从零开始的记录能让你一开始就把路走稳。