从零构建AI工程：数据、训练、部署与监控的完整实践指南

1. 先搞清楚AI工程到底在解决什么问题在开始写代码之前我想先把一个概念掰开揉碎讲清楚——AI工程指的到底是什么很多朋友一听说ai-engineering from scratch第一反应是我要从零学会训练神经网络。这个理解对了一半。AI工程的重点不在AI而在工程。它要解决的从来不是怎么把模型精度从92%提到93%而是怎么让一个AI系统稳定、高效、可持续地跑在生产环境里。从零开始不是从神经网络的反向传播开始学而是从怎么把一个模型想法变成一条可靠的生产链路开始学。我自己见过太多这样的例子算法工程师在Notebook里跑通了模型精度漂亮demo惊艳但一提到上线就卡壳——数据管道没人维护、模型文件不知道放哪、线上环境的依赖跟开发环境不一致、推理延迟超标。这些都是AI工程要回答的问题。那这个内容适合谁三类人。第一类是想转行做AI工程/MLOps的开发者需要一张完整的地图第二类是算法工程师想补上工程一侧的手艺不再写能跑就行的脚本第三类是技术负责人想从零搭一套AI交付体系但不确定从哪下手。这三类人读这篇文章应该都能找到对应的切入点。1.1 从能跑的代码到能用的系统我经常打一个比方在Notebook里训练模型相当于在厨房里炒一盘菜搭建AI工程相当于开一家餐厅。炒菜只需要关心火候和味道开餐厅要操心的事情就多了——供应链、排风系统、员工排班、食品安全、客户的等待时间、菜单迭代节奏……对应到AI工程上就是这五件事数据层训练数据从哪里来、如何校验、如何版本化、如何应对线上分布的漂移。实验层模型训练过程如何复现参数、代码、数据、环境如何一一对应锁定。模型层训练好的模型如何评估、如何打包、如何做版本管理。服务层模型怎么部署成接口吞吐量、延迟、成本怎么权衡。运维层上线后怎么监控、怎么告警、模型效果衰减了怎么迭代。这五层合起来才叫AI工程。任何一个环节脱节整个系统就会像一条拧起来的链条总有地方卡住。从零开始的价值就在这里——每一层你都亲手搭过、踩过坑你才知道系统真正脆弱的地方在哪里。1.2 为什么至少要从零完整走一遍我见过不少朋友先学MLflow再学Kubeflowdocker、kubernetes、prometheus挨个啃学了大半年还是觉得AI工程是个模糊的概念。原因很简单——工具是分散的每一件单独学都懂但串不起来。所以我强烈建议至少要从零完整走一个最小闭环用一个真实的小数据集从原始数据清洗开始到特征工程、训练、评估、打包成镜像、部署成接口、写监控、做自动告警一个环节都不跳。这个过程走完你再看MLflow的文档理解就完全不一样了。因为你知道它解决的是哪一环的什么问题。这就好比学开车。光看仪表盘说明、背交通法规永远学不会。必须上车从启动、换挡、踩刹车开始磕磕绊绊走几趟你才真正理解每个部件是做什么的。AI工程也是一样从零走一遍的笨功夫是后面提速的基础。2. 从零搭AI工程需要掌握的四层基本功既然要from scratch就得先说清楚基本功的范围线。我的建议是不用贪多把下面四层打扎实AI工程的主干就有了。每层我都附上最低限度的学习重点和判断标准。2.1 语言与代码基本功首先是代码能力这是所有工程能力的根。AI工程的主要语言还是Python这不完全因为Python写模型方便更因为它的生态足够厚——数据处理、Web服务、运维脚本一行Python都能找到成熟方案。需要重点过关的包括类型标注type hints和Pydantic之类的数据校验工具这部分是代码可维护性的基础。装饰器、上下文管理器、生成器这几个Python高级特性写数据处理管道的时候会频繁用到。单元测试pytest基础至少能在重构的时候兜底。我还建议掌握一点Go或Rust的基础不为了写业务而是为了将来需要压榨性能时知道性能瓶颈在哪里、怎么跟底层工具协作。这个不强求属于加分项。我见过很多从算法转工程的朋友最大的绊脚石就是代码组织能力。模型代码几百行全挤在一个脚本里全局变量满天飞连参数都写死在文件里。这样的代码模型精度再高到了工程阶段都要推倒重来。所以我的建议是开始学AI工程之前先老老实实把一个Python项目用清晰的结构重写一遍模块拆分、依赖注入、异常处理这些基础不牢后面所有环节都会很痛苦。2.2 数据工程基本功AI工程里绕不开数据。一个残酷的事实是大部分AI项目的时间消耗不在模型调试而在数据准备。我自己的比例大概是七成时间在处理数据三成时间在训练和调优。所以数据工程的基本功不能少SQL是基本功中的基本功。别觉得简单窗口函数、复杂Join、子查询的优化这些必须在不看文档的时候也能熟练写出来。Pandas/Polars的数据操作。Polars这几年发展很快处理大数据集内存效率更高我建议两个都掌握。数据质量校验。写数据管道的人必须有一种怀疑一切的心态——空值、重复值、脏数据、类型错乱每个环节都要校验。这一块后面实操部分我会详细展开。这里有个容易被忽视但很重要的点数据版本管理。Git管理代码DVCData Version Control这类工具管理数据。没有数据版本管理你就无法回溯这个模型是用哪份数据训出来的这在排查线上问题时是致命的。2.3 机器学习与深度学习基础AI工程毕竟还是围着模型转机器学习基础不能缺。最低限度包括监督学习的核心概念过拟合、欠拟合、偏差方差权衡、交叉验证、正则化。常用模型的原理与适用范围线性模型、树模型、深度神经网络。不用会手推反向传播但要知道每种模型的先验假设和适用场景。评估指标的选择分类问题看AUC还是F1回归问题看RMSE还是MAE排序问题看NDCG还是MAP指标选错整个项目方向就错了。深度学习的工程细节学习率调度、Batch Size的影响、Dropout/BN的作用、损失函数的设计。这一层的核心目标不是让你发明新模型而是让你能读懂模型的行为、判断模型的输出是否合理。在工程链路里你更多是模型的使用者和Debugger而不是模型的发明者。2.4 工程化基本功DevOps与系统设计这是从懂机器学习到能构建AI工程最关键的一层跳跃。很多算法背景的同学对这一层最陌生但恰恰是AI工程最核心的竞争力。要掌握的东西包括Linux操作与Shell脚本这是线上环境的基础。Docker容器化。必须能把训练环境、推理环境打包成镜像让开发、测试、生产环境保持一致。CI/CD概念与实操用好GitHub Actions或GitLab CI这类工具实现代码改动到自动测试、自动构建、自动部署的流水线。Kubernetes基础。知道Pod、Service、Deployment这些概念就够了初期不建议深挖但要知道它能解决什么。监控体系基础。日志、指标、告警是三个支柱。比如Prometheus采集指标、Grafana做可视化这是AI工程里监控模型效果的底座。我在带团队时经常发现一个现象纯算法背景的同事对CI/CD这件事天然有抗拒感觉得训练脚本为什么要自动化测试、自动部署。但恰恰是这些看似跟AI无关的工程设施决定了整个系统的交付质量和效率。没有自动化流水线每次模型更新都是一次手工搬运模型文件、手工改配置的危险操作迟早出事故。2.5 一个实用主义的工具选型建议工具选型很容易陷入什么火用什么的误区。我个人的原则是选那些社区活跃、文档清晰、不绑定特定云计算厂商的工具。给你一套我自己用下来比较顺手也推荐给初学者的组合环节推荐工具推荐理由代码仓库GitHub / GitLab生态完善GitHub Actions内置CI数据版本管理DVC开源、与Git搭配自然实验追踪MLflow开源主流追踪参数/指标/模型一条龙编排管道Airflow / Prefect做数据管道和训练管道的调度容器化Docker事实标准没有悬念编排平台Docker Compose起步 Kubernetes后期循序渐进模型服务FastAPI MLflow模型服务 或 Triton先FastAPI起手性能瓶颈再上Triton监控Prometheus Grafana观测届的经典组合这套组合的最大优点是全部开源、社区案例多、遇到问题Google一下基本都有答案。初期不要追求大而全的MLOps平台从轻量组合开始理解每一环的原理之后再逐步引入更重的组件。3. 核心环节拆解数据、训练、部署、监控这一节是正文的正文。我用一个完整项目的口吻带你看AI工程里每个核心环节我实际是怎么做的每一步后面的为什么是什么。3.1 数据工程AI项目的地基工程数据环节的坏消息是它不够性感好消息是只要你把这块做扎实项目就成功了一半。我在项目中落地数据工程时会严格走这四步。第一步数据探查EDA拿到数据后我通常不会急着写清洗代码。先把数据往DataFrame里一载快速过一遍以下几项维度行数、列数、各列数据类型空值比例、缺省值分布数值列的分布均值、分位数、标准差、最大最小值类别列的取值频次目标变量的分布是否需要做样本均衡时间字段的范围与粒度这一步看起来很基础但它的价值在于尽早暴露问题。有一次我在做一个用户行为预测的项目EDA时发现某个关键字段的统计口径在不同月份发生了变化如果不发现后面训练的模型会学到假规律。这就是EDA的意义——花一天的时间省掉后面一个月返工的代价。第二步数据清洗清洗这一步我给自己定了几条规矩空值处理必须基于业务理解来定策略不能一刀切。用户年龄为空可能是用户未填写也可能是系统没采集到两种情况的处理方式完全不同。前者可以填充默认值后者可能需要从别的表关联补齐。异常值处理要谨慎。3倍标准差之外的异常值不一定是要剔除的脏数据有可能代表着非常典型的业务场景比如大客户的超大订单。剔除前必须问一句这个值有没有可能是真实业务产生的。清洗策略必须可复现、可审计。所有的清洗逻辑应该写成函数而不是在Notebook里手改单元格。否则训练数据和生产数据可能因为清洗逻辑不同而出现分布偏差这在业界叫数据偏差问题。我建议把清洗逻辑做成一个独立的Python包每个清洗函数有对应的单测。这不是小题大做想想看如果你的清洗逻辑改了线上推理时用的是旧逻辑还是新逻辑如果没管好模型训练时的输入分布和线上推理时的输入分布不一致性能会莫名其妙地劣化排查起来特别痛苦。第三步特征工程特征工程是持续迭代的过程。我的习惯是先做一套能跑通端到端链路的瘦身版特征让模型和部署流程先转起来后续再迭代特征。这样做的好处很明显你能在早期就发现整条链路的瓶颈在哪里而不是在特征工程堆了几天后发现部署环节根本不支持这些特征。特征工程里有一个工程侧的坑特征的线上逻辑和离线逻辑必须保持一致。比如用户最近7天下单总金额这个特征离线看是5块线上用同一个公式跑出来却是3块这种训练/推理特征不一致是AI工程里最隐蔽也最致命的问题之一。解决办法是把特征计算逻辑封装成唯一一份代码离线在线共用而不是各写一套。第四步数据与管道验证最后一个环节是经常被忽略的验证。在数据管道构建完成后我会设置一套数据质量门禁每天/每次管道运行后自动检查关键字段的空值率、分布漂移指标比如PSI。一旦超过阈值立刻告警而不是等模型上线后效果变差了才回头查数据。在模型中记录并持续追踪训练数据分布 vs 线上数据分布的差距。不要以为这些都是大厂才需要的。哪怕你的项目很小长期维护一个AI系统的过程无非就是处理各种数据分布的变化数据质量门禁是刚需。3.2 训练管线让实验可复现、可追溯很多人理解的训练就是跑个脚本但这个环节一旦上升到工程层面核心目标就变成三个词可复现、可比较、可恢复。可复现意味着任何一次实验结果都应该能回溯到用了哪份数据版本、哪些代码Git提交、哪些超参数配置、什么环境镜像。缺少任何一项实验结果都无法追溯。为了让可复现真正落地我通常这么做把超参数写进配置文件YAML而不是写死在代码里。用MLflow记录每次运行的参数、代码版本、数据版本、指标、模型产物。把运行环境固化成Docker镜像镜像tag对应到代码版本。可比较意味着每一次实验都记录统一的评估指标算分。同一个任务不同模型、不同超参数组产生的结果要能在同一个维度上对比。我自己的习惯是在MLflow里设一套统一的评估组件对每个模型运行同一套逻辑产出同一组指标。这样表格拉出来哪个模型更好一目了然。这比在微信上发来发去Excel文件高效一百倍。可恢复指的是训练失败时能从断点继续而不是从头再来。深度学习训练动辄几小时到几天中途断了从头跑非常浪费时间。PyTorch的torch.save/torch.load加一个断点恢复机制或者直接用PyTorch Lightning的ModelCheckpoint都是成熟的做法。关于训练本身我再说几个实操细节随机种子要固定。模型初始化的随机性、数据随机打乱的随机性都要设置种子否则同一份代码跑两遍结果不一样你都不知道该信哪个。混合精度训练AMP是标配。现代GPU都有Tensor Core用FP16训练速度翻倍显存占用减半。只要不是对精度极度敏感的场景建议无脑开。梯度累积是模拟更大Batch Size的小技巧。显存不够用的时候把多个Batch的梯度攒够一起更新效果接近大Batch训练。早停法Early Stopping别让训练无止境地跑。监控验证集指标连续若干epoch没有提升就停掉。我看到不少团队只训练个模型就把训练脚本扔在那边训练过程完全没有记录。这等于在黑暗里走夜路模型效果好了都不知道怎么好的模型效果差了也不知道差在哪里。这一点如果你记不住其他内容也请一定把这一条记住。3.3 模型部署从模型文件到稳定服务模型训练完只是万里长征走了一半。真正的挑战在于怎么让这个模型稳定地对外提供预测服务。部署方式的选择。初期我建议先用最直接的方式用FastAPI把模型包一层HTTP服务。这个方案简单、直观、代码量少适合业务量不大、延迟要求不苛刻的场景。之后如果并发量上来了可以切换到Triton Inference Server它支持动态批处理Dynamic Batching、多模型管理、GPU显存优化性能提升显著。模型打包的两种形态要分清楚训练态PyTorch的.pt文件、TensorFlow的.pb文件等只适合在训练环境里加载。服务态标准化的、自包含的、带有输入输出Schema的模型格式比如ONNX、TorchScript。服务态模型的好处是不依赖训练框架的版本、优化了推理性能、可以在线做模型版本切换。我见过太多线上事故都是因为生产环境重新装了个训练框架版本跟训练时不匹配模型加载直接报错。所以我的建议是从第一天起就规划模型导出。部署场景的输入输出要设计好。我见过一个很典型的错误模型输入是图片训练时用的是预处理后的张量部署时直接传原始图片字节结果报错半天找不到原因。这里的关键是——输入输出Schema必须在模型打包时锁定。我建议用Protobuf或JSON Schema定义好请求和响应的结构同时把预处理逻辑也包含在模型服务里或者至少提供与训练时完全一致的预处理代码版本。训练和推理环境对输入数据的处理方式不一致这是部署环节最大的坑没有之一。模型服务上线前压测必须做。很多团队部署完模型小流量跑通了就宣告上线。但线上真实流量一上来各种问题就都暴露了内存泄漏、GPU显存溢出、超时重试风暴。我通常的压测流程是先确定SLO比如P99延迟小于100ms成功率99.9%以上然后用Locust或WRK做压测观察延迟、吞吐量、内存、显存四项指标找到系统的真实容量上限再据此配置自动扩缩容。3.4 监控与迭代模型上线只是开始上线之后AI工程的工作还有一半。模型不是说训完就一劳永逸了真实世界的数据分布永远在变。我经常说的是模型效果衰减不是意外是常态。所以监控体系必须从第一天就搭建。我一般分两个层面做监控系统层监控服务器资源、容器状态、API延迟、错误率。这层用Prometheus加Grafana就能解决任何一个做后端工程的人都熟悉这套。关键是告警要配置好——不是所有指标都要告警盯住P99延迟、错误率、GPU利用率这几个核心指标即可。模型层监控这个层面更有AI工程特色。核心包括三个指标输入分布漂移线上请求的输入特征分布跟训练集分布做对比用PSI或KL散度衡量。分布漂移大了说明线上环境变了模型可能要重新训练。预测分布漂移模型预测结果的分布是否发生偏移。比如一个风控模型线上预测的风险评分整体上抬这可能意味着客群变了或者出现了新的风险模式。反馈延迟问题Label Feedback很多模型的真实标签需要等一段时间才能拿到比如用户是否下单要等几天才知道。这个反馈链路的时间窗口决定了模型迭代的节奏。做模型监控时有一个很扎心的点很多情况下你并没有真实标签来直接判断模型是不是变差了你只能靠代理指标Proxy Metric来间接观测。比如内容推荐模型你没有即时反馈告诉你这个推荐是不是真的好只能通过用户的次留、点击率等代理指标来推断。所以设计监控指标时必须想清楚这个指标到底在反映什么它在什么情况下可能会误导你。关于迭代我遵循一个简单原则先定位问题源头再动手改模型。模型效果下降先去看是数据分布变了还是上游数据处理逻辑变了还是某个特征源挂了。很多时候问题根本不在模型本身。把排查顺序定下来能节省大量无效训练的时间。4. 实操从零构建一个完整的AI工程示例这一节我拿一个非常落地的场景完整走一遍链路。场景电商平台商品评论的情感倾向分类。数据用公开的评论数据集比如IMDB电影评论或者直接自己爬点商品评论模型用一个轻量的预训练语言模型做微调。目标不是做出最好的模型而是带你走完一整条AI工程闭环。4.1 项目初始化与数据准备我建议所有AI工程都先建立好目录结构。下面是一份我常用的结构参照它来组织你的项目. ├── configs/ # 配置文件YAML模型参数、数据配置 ├── data/ # 数据文件用DVC管理不进Git │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗后的数据 │ └── features/ # 特征数据 ├── src/ # 源代码包 │ ├── data/ # 数据加载、清洗、特征工程 │ ├── models/ # 模型定义、训练逻辑 │ ├── evaluate/ # 评估指标与评估流程 │ └── serve/ # 推理服务代码 ├── tests/ # 单元测试与集成测试 ├── scripts/ # 一次性脚本与工具脚本 ├── Dockerfile # 镜像构建定义 ├── docker-compose.yml # 本地一键起服务 └── README.md目录不用照抄但思路值得借鉴代码按职责分离配置与代码分离数据与代码分离。这套结构的好处是无论项目规模怎么增长新人都能在十分钟内找到自己要改的文件。数据准备环节我做三件事把原始数据放到data/raw/用DVC做版本管理。写清洗脚本把评论文本去重、去空白、统一大小写、按需要做简单分词。清洗脚本的每个函数都配单测。做一次快速EDA检查标签分布、文本长度分布把结果存成报告。如果标签非常不均衡比如好评占90%要提前决定是不是要做采样或者修改评估方式。4.2 训练实验与模型追踪这个项目的模型我用一个轻量级的预训练模型比如distilbert在消费级显卡上也能微调。训练代码的结构建议是配置文件configs/train.yamlmodel: name: distilbert-base-uncased max_length: 512 data: batch_size: 16 train_file: data/processed/train.csv valid_file: data/processed/valid.csv training: epochs: 5 learning_rate: 2e-5 seed: 42 mixed_precision: true gradient_accumulation_steps: 4所有超参数都进配置文件不写死在代码里。MLflow追踪在训练脚本里我就这么接入import mlflow with mlflow.start_run(): # 记录参数 mlflow.log_params(config[training]) # 训练逻辑 ... # 记录指标 mlflow.log_metric(val_accuracy, val_acc) mlflow.log_metric(val_f1, val_f1) # 保存模型 mlflow.pytorch.log_model(model, distilbert_sentiment)评估。情感分类这种二分类任务我至少看准确率、F1、AUC三个指标。如果标签不均衡F1是主要参考。每次实验跑完MLflow会自动把所有实验结果汇总在同一个UI里方便横向比较。这里我想强调一个细节训练之前先跑一个过拟合小实验。取几十条训练样本把模型训几个epoch看能不能做到接近满分。这一步是验证代码链路通不通的最快方式。如果这么点数据都过拟合成不了那一定是训练逻辑、数据加载、模型定义中哪个环节有bug。先排除bug再上全量数据能省下大量无效等待时间。4.3 模型服务化与Docker部署训练好的模型我通常导出为ONNX格式这样最终的推理过程可以脱离PyTorch训练框架部署更轻量速度也更快。import torch from transformers import AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained(distilbert_sentiment) dummy_input torch.randint(0, 30522, (1, 512)) # token ids 模拟输入 torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids, attention_mask], dynamic_axes{input_ids: {0: batch_size}, attention_mask: {0: batch_size}}, )导出之后推理服务我用FastAPI来写。简化起见核心就是这样一个结构from fastapi import FastAPI import onnxruntime as ort app FastAPI() ort_session ort.InferenceSession(model.onnx, providers[CUDAExecutionProvider]) app.post(/predict) def predict(text: str): inputs tokenize(text) logits ort_session.run(None, inputs)[0] label positive if logits[0][1] logits[0][0] else negative return {label: label, confidence: float(...)}写完之后最重要的就是Docker化保证所有环境依赖与训练阶段一致。Dockerfile大致是这个样子FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]然后docker build -t sentiment-service . docker run -p 8000:8000 sentiment-service服务起来后用一行curl验证curl -X POST http://localhost:8000/predict -H Content-Type: application/json -d {text: This product is amazing!}接着我强烈建议补上一个健康检查端点/healthzKubernetes或Docker Compose的健康检查都靠它来判定服务是否正常运行。返回的不仅是一个纯状态200我还会顺带把模型是否加载成功、显存剩余情况一起返回这样排障时能少打好几个命令。4.4 CI/CD与自动化流水线到这步一个能跑的AI服务已经有了。但我们要的是能长期维护、可自动交付的AI工程所以要上CI/CD。我用GitHub Actions做自动化的三件事代码检查与单元测试每次push代码自动跑pytest。构建镜像与推送打上Git commit hash作为镜像tag推送到容器仓库。部署如果commit打上了特定tag自动把新镜像部署到测试环境测试环境验证通过后再手动触发部署到生产。流水线文件大致长这样name: ci on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv4 - run: pip install -r requirements.txt - run: pytest build: needs: test runs-on: ubuntu-latest steps: - ... - run: docker build -t my-registry/sentiment:${{ github.sha }} - run: docker push my-registry/sentiment:${{ github.sha }}盖上流水线以后模型更新的发布流程从手工复制模型文件、手工改服务器配置变成了合并代码、打tag、自动部署。有一次线上模型效果衰减我们要紧急回滚到旧版本因为有这个流水线一条命令就完成了镜像回滚。这种时刻才真正体会到工程化的价值。4.5 灰度发布与模型监控落地生产环境我从来不做模型的全量一刀切替换。标准做法是灰度发布新模型先接5%的流量观察一段时间对比新旧两版模型的业务指标与系统指标。没问题再逐步加大流量直到全量。在代码层面我通常在推理服务里加一个简单的流量路由逻辑按照请求ID的hash值决定命中哪个模型版本。初期可以做得简朴一点不用引入复杂的Feature Store或在线推理架构。关键是养成永不全量直接切的习惯。监控方面我在这个项目里落地了三个组件Prometheus负责采集指标请求量、P99延迟、错误率。Grafana做可视化面板API延迟曲线、模型预测结果分布。自研的分布漂移检测每天定时把当天请求的输入特征做一次统计与训练集分布做对比计算PSI。PSI一旦超过0.2就触发告警。这一套监控体系让我在一个小项目上也能做到模型效果变差之前先发现异常信号。有一次我们监测到某个商品的评论长度分布突然异常一查发现是上游文本采集接口改了参数导致空文本比例增加。如果不做这些监控这种问题可能要等几个星期后用户投诉才暴露。5. 常见问题与排查技巧实录最后这部分我把自己亲手踩过的坑和帮别人排过的雷整理成一份速查表按场景分类。这些问题的共性是初次搭建AI工程时极其常见但官方文档通常不会写。5.1 环境依赖的坑现象根因解法本地能跑容器里加载模型失败镜像里的依赖版本与训练环境不一致用pip freeze锁定全量版本并写入requirements.txt或基于训练环境导出的镜像做推理镜像CUDA/GPU不可用但明明装了NVIDIA驱动Docker镜像缺少cuda运行时或没有配置--gpus all在Dockerfile里基于nvidia/cuda基础镜像构建运行时加--gpus all或用NVIDIA Container ToolkitPython原生依赖冲突装这个包坏了那个包环境被污染坚决使用虚拟环境venv/conda锁版本每换环境就重新pip install -r依赖问题是AI工程里最大的隐形杀手没有之一。最容易踩的是window上能跑Linux上跑不了这种环境差异。我特别建议大家尽早放弃Windows当生产环境开发机可以用Windows但Docker容器和训练服务器统一Linux能少掉一半莫名奇妙的bug。5.2 模型复现性的坑现象根因解法同一份代码两次训练指标不一样随机种子没固定或GPU运算不确定性设置torch/numpy/random的种子固定DataLoader的worker种子接受GPU微小非确定性但保证最佳结果可复现MLflow里看不到之前的实验记录实验追踪服务没启动或模型日志目录不一致统一MLflow的tracking_uri养成每次训练前明确experiment_name的习惯训练完的模型换台机器推理效果明显变差预处理逻辑没有跟着模型一起打包预处理代码和tokenizer配置一并冻结进服务镜像或使用ONNX这类自带Input Schema的格式复现性问题的排查思路其实很简单——逐层锁定变量。数据是变量吗代码是变量吗环境是变量吗把三个变量逐步固定下来复现一定可以做到。怕的是每次都稀里糊涂地改好几个变量一起跑那出了问题根本无法定位。5.3 部署性能的坑现象根因解法接口P99延迟很高但CPU利用率不高没有开启批处理或预处理环节太慢用Triton等支持Dynamic Batching的框架预处理逻辑里把Tokenizer批量化不要一条条做GPU显存OOM服务直接崩溃并发请求过多或单个请求输入过长做长度截断在模型服务外加队列与限流设置显存预留上限并在OOM前返回错误而非崩溃服务莫名超时但日志没有异常线程/协程阻塞或依赖的存储超时导致整个请求链路卡死给所有外部调用设置超时时间用异步方式组织I/O在网关层设置请求超时兜底模型明明效果好线上表现差得离谱线上输入分布与训练时分布不一致加分布监控在预处理处做输入合法性校验如果是漂移优先做定向数据采集与补充训练我印象最深的一次线上事故是模型服务在高峰期P99延迟从100ms飙升到5秒。查了半天发现不是模型推理变慢了而是服务里一个负责加载停用词表的模块每次都去读远程文件系统远程盘抖动直接拖垮了整个链路。最后把词表加载到本地缓存问题秒解。这个案例想说明的是AI工程里的性能问题很多时候出在那些看起来跟AI毫无关系的工程细节上。6. 最后一个建议从小闭环开始写到这里该说的主干都已经说透了。从数据工程、训练追踪、模型部署、CI/CD到监控告警每一步单独拿出来都能写一篇长文但把一个最小闭环完整走通比把某一个环节钻研得特别深更重要。我个人体会最深的一点是AI工程的能力不是学出来的是趟出来的。你亲手把一个模型放到容器里、亲手配置Prometheus告警、亲手回滚一次糟糕的发布这些经验的价值远超过读十篇架构文档。从零开始的含义就是别绕过那些看似麻烦的步骤——恰恰是那些步骤让你真正理解系统。最后分享一个小技巧给自己设定最小目标——两周内把一个你自己选的小模型走通完整的工程链路哪怕数据只有几千条、服务只用Docker Compose在本机跑。这两周里你会遇到各种报错但每一个报错都是你从零搭建AI工程能力的一块砖。这条路走完你再看任何MLOps平台、AI工程框架思路都会完全打开。