1. 项目概述为什么会有从零开始做AI工程这件事ai-engineering-from-scratch这个项目说白了就是一套完整的、从零起步的AI工程实战笔记和代码仓库。市面上讲AI的教程多如牛毛但绝大多数要么落在调库跑模型的入门层要么直接跳到分布式训练的进阶层中间这块工程化的真空地带几乎没人认真填。这个项目要解决的就是这个断层当数据、模型、训练、部署、监控这些环节必须连成一条完整的链路时中间到底发生了什么每一步又该怎么选型、怎么落地。我自己做这个项目的原因很直接。带过不少新人也面试过不少候选人发现很多人能聊透Transformer的注意力机制能背出各种Loss函数的公式但一问他模型训练完了怎么上线QPS涨了十倍怎么办数据分布漂移了如何发现就沉默了。这不是基础不扎实而是缺少一套完整的工程视野。所以我把过去几年在AI工程方向踩过的坑、沉淀下来的套路整理成了这个从零开始的实战路线。这个项目适合谁如果你正在从算法岗转向工程岗或者刚入行想做AI平台的开发又或者你是独立开发者想把自己的模型快速产品化那这套东西应该能帮你省不少弯路。内容覆盖了从需求分析、数据管道、模型训练、性能优化到部署监控的完整闭环并且每个环节都配了可运行的代码和具体参数不是那种只讲概念的PPT式教程。2. 整体设计与路线拆解先想清楚再动手少走一半弯路2.1 工程思维和算法思维的区别在哪里我在项目开篇就强调了一个核心观点AI工程师和算法研究员的工作方式有本质区别。研究员追求的是模型指标的极限哪怕为了一个点的提升跑一百组实验也值工程师追求的则是系统的稳定、可维护和可复现模型指标只是整个系统的一个环节。这个定位决定了整个项目的设计思路。我不会手把手教你怎么从零实现一个BERT或者Diffusion模型——那是深度学习课程的事。我关注的是假设你现在手上已经有一个效果还不错的模型你怎么把它变成一套能长期稳定运行的服务。这里面的学问远比想象中大特征怎么管理、实验怎么追踪、模型怎么版本化、推理延迟怎么压、资源怎么调度、线上效果怎么监测每一个环节展开都是一整篇文章。所以这个项目在结构上分成了几个独立的模块工程基础设施、数据管道、模型训练管理、推理优化、部署与监控。每个模块之间保持松耦合你可以按顺序学习也可以直接跳到当前最需要的部分。我在设计时就刻意避免必须从头读到尾的线式结构毕竟每个人遇到的实际问题不一样。2.2 技术栈选型背后的逻辑技术选型方面整个项目基于Python生态主要使用了PyTorch、MLflow、Airflow、FastAPI、Docker和Prometheus这套组合。选它们的理由不是最新最潮而是最成熟最稳。用PyTorch做模型训练和推理是因为它的动态图机制在工程调试时实在太方便了而且TorchServe和TorchScript这些配套工具让从训练到部署的衔接顺畅很多。实验追踪用MLflow它虽然在UI和多租户支持上不如商业化的Weights Biases但胜在开源、可自托管、API简单对中小团队来说性价比很高。数据管道用Airflow调度虽然被很多人吐槽太重了但它胜在生态成熟、可视化好依赖管理和失败重试机制也比Cron脚本靠谱得多。服务化用FastAPI异步支持好、性能不错、自动生成OpenAPI文档调试起来特别顺手。监控这块选了Prometheus加Grafana的组合这基本是云原生时代的标配指标采集和可视化都非常成熟。这套选型覆盖了从数据到上线的大多数场景而且全部是开源方案。我给项目设定的原则是能自托管的不用云厂商绑定的服务能用标准工具的不用自己造的轮子。这样读者在复现项目时不会被云服务商的差异卡住拿来就能在自己机器上跑通。3. 核心模块实战数据、训练、推理三条主线的关键细节3.1 数据管道的设计别再让训练脚本直接读数据库了很多人一开始做AI项目时的习惯是训练脚本里直接连数据库查数据或者从本地CSV读入然后开始跑模型。这种思路在小规模实验阶段没问题但一旦到了需要定期更新模型、多团队协作的时候就会变成灾难。我在项目里设计了一套标准的数据管道流程核心思路是数据即产物。原始数据从业务库同步到数据湖经过清洗和特征工程变成特征数据集然后再进一步加工成训练集和测试集每一层产物都有明确的格式规范和版本记录。这样做的好处是特征计算逻辑可以被训练和推理两套流程复用保证离线训练和在线推理用的是同一套特征逻辑不会出现训练时用A逻辑、上线时用B逻辑这种经典翻车事故。数据版本管理是很多人忽略的重点。模型效果变差了你想回溯到三个月前的训练数据重跑一遍实验如果数据没有版本化这件事根本做不了。我在项目里用DVC管理数据集版本把元数据存在Git里实际数据文件放在对象存储或NAS上这样既享受了Git的版本管理能力又不需要把大文件直接塞进仓库。整个流程大概长这样# 1. 初始化DVC dvc init # 2. 添加远程存储本地目录模拟 dvc remote add -d myremote /mnt/data/dvcstore # 3. 添加数据目录并生成.dvc文件 dvc add data/raw git add data/raw.dvc .dvc/config git commit -m add raw dataset # 4. 数据变更后推送新版本 dvc push在使用DVC时有一个特别容易踩的坑.dvc文件里记录的是文件哈希值如果有人改了数据内容但没执行dvc add那么版本记录和数据实际内容就不一致了。所以建议把dvc add和git commit写成一个固定的发布流程最好在CI里做校验确保每次数据发布都有完整的版本记录。关于Airflow调度很多初学者一上来就想着实现复杂的DAG依赖但我在实际项目中更倾向于Keep It Simple的原则。数据管道最重要的是稳定性和可观测性而不是花哨的依赖关系。我的建议是DAG数量控制在十个以内每个DAG的task数也尽量精简调度频率定在业务需要的水平就行没必要为了实时而实时。每天跑一次的批任务比一个看起来实时但经常挂的流任务可靠得多。3.2 模型训练的工程化管理从能跑到可复现训练环节是整个项目里代码最多的部分。我设计了一个标准化的训练流程框架把训练过程拆成配置管理、模型管理、实验追踪三个子模块。配置管理方面我用YAML文件承载所有的超参数和训练配置而不是把参数散落在代码里或者通过命令行传几十个参数。每一条实验记录都对应一个配置文件的快照这样实验的可复现性就有了基本保障。配置文件大致长这样model: name: text_classifier backbone: bert-base-chinese hidden_size: 768 num_labels: 10 data: train_path: data/processed/train.parquet eval_path: data/processed/eval.parquet batch_size: 32 max_seq_len: 128 train: optimizer: adamw learning_rate: 2e-5 weight_decay: 0.01 num_epochs: 5 warmup_ratio: 0.1 seed: 42 output: run_dir: runs/experiment_001 save_model_metric: f1_macro在训练代码里我会强制要求先加载配置再初始化所有组件模型结构、数据加载器、优化器、日志器都是从配置对象里读取参数。这样整个训练过程就变得非常声明式想跑一组新实验只需要复制一份配置改几个关键参数不必动代码。模型管理这块我养成了两个习惯。第一个是每轮训练结束都保存checkpoint但只保留最近几轮和历史上效果最好的那个避免磁盘被一轮轮的模型填满。第二个是模型产出一律通过MLflow登记注册模型的路径、指标、依赖的Python环境、训练配置全部记录在MLflow的model registry里。这样等到部署的时候直接在registry里挑一个版本授权发布就行不需要到处找模型文件。实验追踪可能是很多人觉得不就是一个日志功能吗的部分但真正做深了才知道它的价值。我一般会记录这几类信息系统资源占用GPU显存、CPU、内存、训练指标loss、准确率、F1、数据相关指标样本数、标签分布、模型结构摘要和参数量。有了这四类信息当你训练效果异常的时候才可能快速定位是数据问题、模型问题还是资源问题。训练过程中还有几个细节值得单独说一下一是随机种子管理。我固定了Python、NumPy、PyTorch和CUDA的随机种子但需要明确一点固定种子只能减少随机性在GPU上训练仍然不可能做到100%可复现。所以训练代码里我还会把环境变量和依赖版本也记录到实验日志里至少做到问题和环境能对上号。二是混合精度训练。现在的主流显卡基本都支持FP16或者BF16开启之后训练速度能提升30%到50%显存占用也能降低不少。但新手用AMP时容易出问题比如Loss出现NaN或者模型不收敛。我的经验是在开AMP的时候一定要同时做梯度裁剪并且密切关注Loss曲线的走势一旦发现异常就先关掉AMP排查不要硬着头皮跑完。三是早停策略。我实现了一个简单的EarlyStopping回调监控验证集上的目标指标连续N个epoch没有提升就终止训练然后回滚到历史最优模型。这个机制看着简单但能节省大量的无效训练时间特别是做超参搜索的时候价值非常明显。3.3 推理优化怎么把延迟从200ms压到50ms模型训练完成之后真正的硬仗在推理这一步。我见过太多模型在离线评测时指标漂亮一上线就超时的情况。原因很简单离线评测用的是一个都没人抢的批量GPU线上是几十个并发请求挤一个推理服务资源竞争完全不是一个量级。推理服务我有一个通用框架用FastAPI封装TorchScript模型配合异步请求处理和动态批处理。框架的伪代码大致如下import asyncio from fastapi import FastAPI from transformers import BertTokenizer import torch app FastAPI() model torch.jit.load(models/text_classifier_v3.pt, map_locationcpu) model.eval() tokenizer BertTokenizer.from_pretrained(bert-base-chinese) # 信号量控制最大并发防止GPU显存溢出 sem asyncio.Semaphore(16) app.post(/predict) async def predict(request: dict): async with sem: text request[text] inputs tokenizer(text, max_length128, truncationTrue, paddingTrue, return_tensorspt) with torch.no_grad(): logits model(**inputs) pred logits.argmax(dim-1).item() return {label: pred}这个版本只是基准实现真正的优化动作在后面。我梳理了一套推理优化的优先级清单第一优先级是模型端优化。能从模型结构上降延迟收益最大。量化是性价比最高的一招把FP32模型转成INT8推理延迟通常能下降一半以上模型体积缩小到原来的四分之一在NLP任务上精度损失一般能控制在1%以内。TensorRT或者ONNX Runtime的图优化也是这个环节的武器ONNX Runtime加Dynamic Quantization在CPU上就能跑出不错的效果不需要上GPU。第二优先级是服务端优化。动态批处理非常有效把一小段时间内的多个请求攒在一起拼成一个batch送到GPU上充分利用显存并行计算能力。这个逻辑实现起来不复杂就是维护一个请求队列每隔几十毫秒或者攒够N个请求就触发一次批量推理。我实测过在并发100的场景下动态批处理能把吞吐量拉高两倍以上。但需要注意动态批处理会增加单个请求的最坏延迟所以上线前一定要压测找到延迟和吞吐量之间的平衡点。第三优先级是缓存策略。对于业务场景来说很多查询是有重复的。我在服务层面加了一个简单的LRU缓存key是文本哈希值value是推理结果。热门请求的命中率上来了之后整体QPS压力小了很多用户体验也更稳定。部署环节我推荐用Docker镜像加Kubernetes的方式。镜像里只打包模型文件和推理服务代码模型文件可以从MLflow registry拉取这样镜像本身做到和版本完全对应。K8s的HPAHorizontal Pod Autoscaler可以基于自定义指标做自动扩缩容配合Prometheus的QPS和延迟指标服务在大促或者流量高峰时能自适应地扩出副本高峰过去了又能自动回收省了不少钱。4. 部署与监控把服务跑起来只是开始不掉线才算本事4.1 Docker镜像和启动脚本的避坑提示部署环节的坑和训练环节完全不同。训练环境挂了最多就是重跑一次实验线上服务挂了那就是事故。我在这个模块里专门整理了一套经过反复验证的镜像构建方案。基础镜像方面我强烈建议用PyTorch官方提供的GPU镜像作为底座不要自己从零装CUDA和cuDNN。官方镜像是经过充分测试的各库之间的版本兼容性有保障。版本选型也有一点讲究不要追求最新版本选一个社区使用量大、已知问题少的稳定版本即可。我自己的镜像tag通常会固定到小版本比如pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime而不是用latest这样构建出的镜像才是可复现的。一个很容易被忽视的问题是镜像体积。一个装了CUDA的PyTorch镜像动辄几个GB部署和拉取都很痛苦。优化方案是分阶段构建在构建阶段用完整的开发镜像装依赖、编译扩展最终运行阶段换成slim镜像只拷贝运行所需的Python包和模型文件。我最好的记录是把一个4.7GB的镜像降到了1.2GB部署速度提升了接近四倍。启动脚本里我加了一个耗时几分钟的冷启动问题。加大模型加载到GPU确实需要时间如果每次扩容都要等模型重新加载流量高峰根本接不住。我自己的解法是借助K8s的pre-stop钩子和readinessProbe做优雅上下线新Pod加载完成后才接收流量旧的Pod等存量请求处理完了再退出这样滚动更新时服务基本不会断。另外如果你的模型比较大考虑准备一些常驻的热Pod流量高峰时直接顶上。4.2 线上监控的三类指标和告警配置监控是我认为整个项目里最工程化的环节也是最容易被初学者忽略的。我自己总结了一套线上模型服务必须盯的三类监控指标第一类是系统指标包括CPU使用率、内存使用率、GPU显存占用、GPU利用率、网络带宽和磁盘I/O。这些指标反映的是服务的身体状态。GPU利用率长期很低但显存占满大概率是你的推理代码有显存泄漏或者批处理设置不合理。第二类是服务指标包括QPS、P50/P95/P99延迟、错误率、超时率、熔断次数。这些指标反映的是服务的工作表现。其中P99延迟比平均延迟重要得多平均延迟低但P99很高意味着有大量请求被拖得很慢用户体感依然很差。如果P99和P50差距过大往往说明有慢请求在排队需要检查动态批处理的队列大小和超时设置。第三类是业务指标包括预测结果的标签分布、置信度分布、空结果率。这些指标反映的是模型在线上真实环境的表现。标签分布和训练集分布差异太大基本可以断定数据漂移了模型已经开始失真需要尽快采集新样本做重训。告警配置上我建议抓住少而精准的原则。告警项设得太多天天半夜被吵醒最后大家都会选择忽略。真正需要告警的其实就几个场景P99延迟超过阈值持续五分钟、错误率超过1%且请求量大于某个绝对值、GPU显存占用接近上限、模型输出空结果率异常升高。每个告警都要配置好恢复条件避免告警风暴之后一堆永不恢复的僵尸告警。关于日志的处理我强烈建议结构化日志。Python里用logging库加上JSON格式化器把每条日志输出为JSON格式包含时间戳、请求ID、业务字段、日志级别等。这样日志能直接接入ELK或者Loki做检索排查问题的时候按请求ID串联全链路的日志定位时间从半小时起步缩短到三分钟内。5. 常见问题与排查技巧这些坑我替你踩过了5.1 训练阶段的典型问题和解决思路训练阶段最常见的问题我列一个速查表都是我在实际项目里反复遇到的现象可能原因解决思路Loss不下降学习率过大或过小先把学习率调到1e-4左右跑几十步看趋势再做范围搜索Loss变成NaN梯度爆炸或混合精度溢出开梯度裁剪调低学习率检查数据里是否有异常值GPU显存不足batch size过大或模型太大减小batch size检查是否有显存泄漏开启梯度检查点验证集效果远低于训练集过拟合加正则化、减小模型容量、增大数据增强、提前早停训练速度突然变慢数据加载成为瓶颈检查DataLoader的num_workers和prefetch_factor设置多卡训练Loss抖动梯度同步或batch norm问题确认DistributedSampler使用正确BatchNorm换成SyncBatchNorm数据加载变成瓶颈的现象特别常见。很多时候GPU利用率只有30%你以为模型太复杂算不动其实问题出在CPU来不及把数据喂到GPU。在PyTorch里num_workers设置为CPU核心数的一半或三分之二prefetch_factor默认2这些参数看起来不起眼调对了训练速度能提升不少。我自己的经验是在NVIDIA Nsight Systems里一眼就能看出GPU的空闲气泡如果DataLoader的时间占比特别高那就该优化数据管道了。还有一个很隐蔽的坑训练里用了BatchNorm但在推理阶段忘了切换成eval模式。BatchNorm在训练时会用当前batch的均值和方差做归一化在推理时要用全局统计量。如果代码里没有调用model.eval()推理结果会和训练时有很大的分布差异尤其在小batch场景下会特别明显。5.2 服务上线后的翻车记录服务上线后的坑往往更致命因为它直接影响用户。我分享一个我自己印象特别深刻的案例一次对NLP分类服务做压测离线单请求延迟只有30ms但100并发压测时P99直接飙到了800ms而且随着压测时间延长延迟还在持续增大。一开始我以为是模型推理太慢后来用cProfile分析才发现问题根本不在推理而在请求处理逻辑里。我为了做特征工程在每次请求时都要从数据库读取一份用户画像数据数据库的连接池太小并发一高就全堵在等数据库响应上了。把连接池调大并加上缓存之后P99降到了120ms以内。这个案例给我的经验是线上服务性能排查永远先从系统画像开始而不是直接猜模型慢。用py-spy或者cProfile拿到CPU火焰图看时间到底花在哪里用top或者nvidia-smi看CPU和GPU有没有忙起来。数据说话别凭感觉猜。另一个高频问题是内存泄漏。TorchScript模型如果推理的输入长度一直变化导致图里的张量反复重新分配就可能出现内存碎片化导致RSS持续上涨。解决的办法是固定输入长度不足的部分padding超过的部分截断。我当时排查的时候发现内存以每小时100MB的速度在涨就是因为输入长度不固定导致的。固定到128之后内存曲线变成了平稳的锯齿形。混合精度推理也是一个大坑。如果模型用FP16推理但输入的特征分布和训练时差异很大输出的数值范围可能溢出导致预测结果退化。这种情况下量化模型上线前一定要用线上的真实流量做离线比对测试对比指标至少包括准确率、置信度分布和误差样本分析。只有这些比对通过量化模型才适合上线。6. 性能压测与容量预估线上不崩的底线操作6.1 压测的正确姿势从脚本到工具都别太随意很多人以为压测就是拿ab命令跑一下看看QPS有多少其实这样得到的数据参考价值很低。我自己总结了一套相对完整的压测方案供大家参考。压测工具我推荐wrk或者Locust。wrk适合做纯HTTP的短连接压测性能极高单机就能压出很大的压力。Locust是Python写的可以写自定义的请求逻辑模拟更真实的用户行为。我自己习惯先用wrk做一轮粗暴压测确定服务的性能上限再用Locust做带业务逻辑的混合场景压测模拟更真实的高峰流量。压测脚本里有两件事一定要做对。第一是逐步加压而不是直接打满。我从100并发开始逐步增加到200、500、1000观察每个并发水平下的延迟和错误率变化曲线。这样可以看出服务的瓶颈在哪一个环节。第二是压测时长不要低于十分钟。头几分钟很多内存泄漏和连接池耗尽的问题还没暴露出来压够时间才有说服力。6.2 容量预估的一个实用公式容量预估这件事我总结出一个非常实用的小公式单机QPS 1000 / P95延迟(ms) x 并发数 x 服务可用性系数。服务可用性系数一般取0.7到0.8给系统留出余量防止高峰时段的毛刺直接拖垮服务。假设你的推理服务P95延迟为100ms单机能开16个并发跑推理那么单机理论QPS约为1000 / 100 x 16 160。考虑到CPU抢占、GC停顿和网络开销乘0.75的系数单机真实QPS大概在120左右。如果峰值流量是1000 QPS那么至少需要1000 / 120约9个实例再预留35%的峰值冗余配置12个副本相对稳妥。这个估算公式不一定精确但至少能让你心里有数。比感觉应该够了吧靠谱得多。而且算清楚之后K8s的HPA最大副本数、NodeGroup的机器数都能推算出来预算也好做。7. 项目复盘与个人经验总结7.1 三个月实践下来最大的收获整个ai-engineering-from-scratch项目从构思到落地我大概花了两三个月时间中间经历了无数次的推翻重来。最深的体会是AI工程本质上是一门约束下的妥协艺术。模型效果、推理速度、资源成本、部署复杂度、团队协作效率这五个维度很难同时做到最优真正成熟的做法是明确业务目标后有取舍地做优化。比如如果业务对延迟特别敏感那就可以接受1%到2%的精度损失上量化和TensorRT优化。如果业务对精度要求极高那就要预留够多的GPU资源并做好缓存和批处理来支撑延迟要求。这些取舍没有绝对的对错关键是决策过程要让整个团队都参与并达成共识避免上线之后因为技术分歧来回折腾。另外我越来越觉得可观测性是AI工程最值得投资的部分。很多团队花大力气打磨模型精度却连一套像样的监控面板都没有。模型上线之后效果变差只能等用户来投诉才知道。我在这次项目里把监控体系搭到了能看清每一个环节的程度从数据管道的任务耗时到训练过程的Loss曲线到推理服务的P99延迟再到线上预测结果的分布漂移每一个环节都有对应的指标看板。这笔投入的回报率非常高几乎每次线上疑难杂症都能通过指标快速定位方向。7.2 后续学习的扩展方向这个项目目前覆盖的是单机到小规模集群的范畴还可以往几个方向继续扩展。一个是大规模分布式训练比如用DeepSpeed或者Megatron-LM跑千亿级参数模型涉及张量并行、流水线并行、ZeRO优化器等更底层的技术工程复杂度完全不一样。另一个是更完善的特征平台建设比如让特征在离线训练和在线推理中通过统一的Feature Store服务来管理解决特征一致性问题。如果你想把这套东西进一步完善我建议可以给项目增加一个完整的CI/CD流水线让代码提交后能自动触发训练、自动跑评估、自动生成部署镜像真正做到代码到上线全链路自动化。相比我目前手动操作的半自动流程自动化之后团队的交付效率还会有明显的提升。最后分享一个我个人的习惯每次项目结束后我会把所有的操作记录、遇到的问题和解决方案整理成一篇类似复盘笔记的文档放在仓库的docs目录下。这个习惯坚持了几年积累下来就是一笔非常宝贵的个人知识库。遇到相似问题的时候翻一翻自己写的笔记往往比搜索引擎好用得多。AI工程这条路特别长体系化的知识积累比偶然的灵光一现可靠得多。