很多人第一反应是把“AI工程”理解成“训练一个模型”。我见过太多人学完深度学习课程、能跑通几个开源项目就觉得自己会AI工程了。等到真要做一个能上线、能维护、能迭代的AI系统时全线崩溃。这也是我推崇“ai-engineering-from-scratch”这个思路的原因——只有从零到一完整地走一遍AI工程链路你才会真正理解每个环节存在的必要性而不是停留在调用现成API或者跑通一个demo的层面。这篇内容不是某个框架的使用教程而是我按“从零开始建立AI工程能力”这个目标沉淀下来的完整路径。适合三类人准备入行的AI工程师、从Web或后端转AI的开发者、以及已经在写算法但缺乏工程化经验的算法工程师。它解决的核心问题很现实你怎么把一个能跑通的模型变成一个能长期运转的业务系统。1. 从零起步前先想清楚AI工程要解决什么问题1.1 为什么“from scratch”比直接学框架更重要裸辞转行的时候我也走过弯路。当时市面上最热的是TensorFlow和PyTorch我花了大把时间啃模型结构、训练技巧以为这就是“AI工程”了。直到入职第一周leader让我把一个已经训练好的模型部署成服务我才发现模型训练在整个链路里只是一小段前面有数据获取和清洗后面有服务化、监控、回滚、迭代。这些环节学校不教、教程也少讲但恰恰是工作里最磨人的部分。从零做一次完整流程的意义就在于你会亲手踩遍每一个坑知道训练集分布偏差会让线上效果崩掉、知道模型推理耗时和吞吐怎么平衡、知道线上数据格式换了之后特征管线为什么静默失败。这些经验不是看书能看出来的是真的要自己把自己扔到项目里从零把它跑通一遍才能长在脑子里。我更愿意把AI工程拆成六个环节来理解数据采集与清洗特征工程与样本构建在大模型场景下对应的是数据配比、上下文构建和指令格式设计模型训练与迭代离线评估体系服务化部署上线线上监控与数据回流很多新人只盯着第三项但实际工作中决定项目成败的往往是1、2、5、6。后面我会逐项展开讲。1.2 用开餐厅来理解整条链路如果觉得抽象可以用开餐厅来类比模型是菜谱数据是食材特征工程是切菜备菜训练是后厨试菜评估是品控部署就是前台出菜监控是顾客反馈。菜谱再牛食材不新鲜也做不出好菜后厨试菜做得再开心前台出菜慢、份量不稳定餐厅照样倒闭。我之所以反复强调这个类比是因为很多技术问题本质上是“工程节奏”问题。比如什么时候该训练新模型不是你想训练就训练而是线上指标掉到某个阈值、数据积累到一定量、或者业务规则发生变化时才有可能触发模型更新。这套节奏在你没有完整走一遍链路之前是完全没有体感的。2. 地基数据工程怎么做扎实2.1 数据收集与清洗的基本功很多教程从“加载开源数据集”开始这让我很反感。真实场景里数据是从日志、数据库、第三方接口、甚至人工整理的文件里一个个凑出来的。第一课应该是用shell和Python把零散数据聚合成可用的训练集。我个人的标准操作流程大概是这样的先写脚本做全量扫描统计字段缺失率、重复率、时间范围、值域分布再写清洗逻辑剔除明显错误样本、统一时间戳格式、处理缺失值、过滤敏感信息做一次抽样人工检查随机抽200条看数据质量和标注一致性最后把数据转成统一格式比如JSONL或Parquet分版本存档清洗这一步最容易翻车的是“静默错误”。比如时间戳有的是秒级、有的是毫秒级如果没统一按时间排序的特征就全乱了再比如文本字段里混入了换行符或特殊字符后面切分样本时会出现莫名其妙的空样本。踩过这些坑之后我养成了一个习惯每一步数据操作都打印统计信息处理前记录行数处理后对比行数任何不一致都要找到原因绝不放过。2.2 标注、质检与版本管理没有高质量标注就没有高质量模型。但标注工作看起来简单做起来非常考验管理能力。我见过太多项目的标注规范只有半页纸标到后面每个标注员的标准都不一样。我的建议是写一份详尽的标注规范每个字段都给出正反例疑难case要有仲裁方案小批量试标先让两三个人标同一批数据计算一致性比如Cohen‘s Kappa一致性过低就继续对齐标准正式标注过程按5%~10%的比例抽检抽检不合格就打回重标标注完成的数据和原始数据分开存储关键字段加密脱敏数据版本管理这一点很多人会忽略。但实际项目里训练集改了一版之后模型效果对比就失真了。我强烈建议用DVCData Version Control或者至少用“数据集版本变更说明”的命名规范确保每个模型版本都能找到对应的训练数据版本。不要高估自己的记性也不要高估同事的责任心数据版本混乱是团队协作里最大的隐形杀手。2.3 特征工程与数据管线搭建传统机器学习场景下特征工程决定了效果上限模型只是逼近这个上限。我的经验是先把特征分成几类基础特征用户属性、物品属性、行为特征近7天点击、收藏、交叉特征用户偏好类目×物品类目每一类单独验证有效性不要一开始就堆几百维特征。在大模型场景里特征工程变成了“数据配比”和“上下文工程”。你要考虑训练数据里不同任务的比例是多少每个样本的输入输出怎么组织Instruction要不要加前缀这些决策同样直接影响模型表现本质上和特征工程解决的是同一个问题让模型看到什么、怎么让模型学到规律。数据管线搭建我推荐按这个节奏来先用Python脚本跑通全流程数据量大了之后再用Airflow或Prefect把任务调度起来。不要一上来就搭复杂的分布式数据平台除非你的数据量真的到了那个量级。3. 模型开发别急着上大模型3.1 从baseline开始先把链路跑通每次接新项目我的第一个模型永远是“最土”的。如果是分类任务先上逻辑回归或XGBoost如果是生成任务先用现成的开源小模型加简单prompt如果是大模型应用先直接调现成API验证效果边界。这样做有几个好处快速验证数据管线是否通畅形成一个可靠的效果下限后面所有复杂模型都要以超越这个baseline为及格标准暴露问题比如特征缺失、标签噪声、评估指标不合理这些在简单模型上更容易暴露我见过反着做的团队上来就微调一个大模型跑了两个星期结果发现是数据标签错了白费力气。先跑baseline磨刀不误砍柴工。3.2 把评估体系建在模型训练之前大多数项目挂在评估上。很多人的“评估”就是在测试集上跑几个指标Accuracy高了就宣布成功。但真实业务里离线指标和线上效果经常脱节。我的经验是在训练开始之前先确定评估标准。离线层面除了常规的准确率、召回率、F1还要设计针对业务场景的评估集。比如你做客服问答要单独准备一组“难例”集里面全是用户真正会问但模型容易错的表达你做内容审核要额外关注误杀率因为把正常内容判成违规比漏掉一条违规内容更伤用户体验。人工评估也要提前设计好评分标准最好有详细的评分维度说明多人打分后取平均值或投票。大模型生成类任务我强烈建议用LLM-as-a-Judge辅助评估但Judge模型本身也要测试过稳定性别拿一个不稳定的裁判来评判模型好坏。3.3 调参与迭代的节奏感调参这件事最忌讳靠感觉。我早期就犯过这个错误改了学习率又改了batch size还换了一个优化器三个变量一起变效果变好了也不知道是谁的功劳。后来痛定思痛立了几条规矩每次实验只改一个变量每个实验都有完整的日志记录参数、数据版本、代码commit、训练耗时、指标结果用MLflow或Weights Biases统一管理实验记录再也不靠excel表记参数我的调参习惯是先粗调锁定大致范围再细调围绕最优值做小范围搜索。不要用网格搜索无脑跑除非你预算特别充裕。更实用的做法是随机搜索加上多轮人工判断让领域知识参与进来。大模型的微调我建议先了解清楚全量微调、LoRA、QLoRA之间的区别。大多数场景下LoRA就够用了显存占用小、训练快、效果也不错。除非你有足够多的数据和算力否则不要一上来就全量微调。4. 上线与运维真正拉开差距的部分4.1 模型服务化与API设计训练完模型只是开始。把模型包装成一个稳定、可控的服务才是AI工程和论文实验的分水岭。我常用FastAPI做模型服务原因很简单性能好、自带OpenAPI文档、生态成熟。但框架只是基础真正要设计的是API的边界输入要有完整的request schema字段类型、约束、示例都要定义清楚输出要统一格式包括状态码、业务码、数据、错误信息要设置合理的超时时间做并发限制避免一个慢请求拖垮整个服务要处理模型异常比如输入长度超限、推理结果为空给用户可理解的错误提示而不是直接500还有一点特别容易被忽略模型的吞吐和延迟是矛盾的。延迟是单个请求的响应时间吞吐是单位时间能处理的请求数。你想降低延迟可能要牺牲batch大小你想提高吞吐可能要接受一定的响应延迟。实际项目中必须找到业务能接受的平衡点而不是盲目追求某一个指标。4.2 部署方案选型与推理优化部署选型会直接影响成本和稳定性。我有几条经验先用Docker把模型服务容器化保证本地和线上环境一致如果模型不大优先考虑CPU部署加优化成本低很多如果模型实在太大再考虑GPUGPU推理不要裸上PyTorch建议用vLLM、TensorRT或ONNX Runtime做推理优化吞吐能提升好几倍大模型部署一定要用vLLM它的PagedAttention机制能让显存利用率大幅提升吞吐和延迟都明显优于原生PyTorch推理量化是另一个降本利器。从FP32到FP16能省一半显存再到INT8甚至INT4显存占用和推理速度都会有明显变化但精度会小幅下降。我的建议是先量化到FP16验证效果如果精度能接受再尝试更激进的量化方案。千万不要为了省钱把精度降到用户明显感知到的程度。4.3 监控、回滚与持续迭代线上模型不像离线训练那样“跑完就结束”。你要随时知道它有没有在正常工作。我建议至少做这几层监控接口层QPS、延迟分位数、错误率模型层预测置信度分布、类别分布数据层输入特征分布、关键字段缺失率、词汇覆盖变化数据漂移检测是个经典难题。我常用的方法是定期比如每天对比线上数据的特征分布和训练时数据的分布用PSIPopulation Stability Index或KS检验量化差异。PSI超过0.2就要高度警惕说明线上数据和训练数据已经出现明显分化模型效果大概率在退化。回滚预案一定要提前做。每次新模型上线都要保留上一版本的服务和配置确保新版本出问题能一键切回。我见过太多团队上线新模型之后把旧版本的镜像就地删掉结果新模型崩溃只能紧急重建那种场面太狼狈了。5. 常见问题与排查技巧实录5.1 训练时显存或内存爆了怎么办这是新人问得最多的问题。显存溢出OOM的排查思路是有顺序的先把batch size调到1如果还爆说明模型本身太大考虑换小模型或用LoRA等参数高效微调方法如果batch size1不爆说明是batch太大先减半再逐次减半找到临界值开启梯度累积用很小的batch size模拟大batch的效果使用混合精度训练fp16/bf16显存占用会明显下降检查数据加载是否占用过多内存用DataLoader的num_workers参数平衡CPU和GPU内存溢出常见于数据处理环节通常是全量加载导致的。我习惯用流式读取加分批处理绝对不会把几个G的数据一次性塞进内存。5.2 线上推理延迟高、吞吐上不去延迟高可以按以下顺序排查先看模型推理本身的时间纯模型推理耗时占比高优先优化模型蒸馏、量化、换小模型看预处理和后处理耗时有些项目的文本切分、正则替换、JSON序列化非常耗时容易被忽略看网络传输和IO比如跨机房调用、磁盘读写慢看服务框架层面线程池太小、连接池耗尽都会导致延迟飙升吞吐上不去的常见原因是没用batch推理。GPU是极度适合并行计算的硬件一次处理8个请求和一次处理1个请求的耗时差异远没有8倍那么大。vLLM这类推理框架就是为此优化的。另外如果业务场景允许加一层缓存能挡掉大量重复请求效果立竿见影。5.3 线上效果变差先别急着骂模型线上指标下降很多人第一反应就是“模型不行要重训”。我的排查顺序是先看数据再看特征最后才看模型。第一步用监控面板确认指标下降的时间点往前后追溯同时段有没有发版、数据源变更、业务规则调整。第二步检查线上输入数据和训练数据的分布是否一致PSI指标有没有异常升高。如果特征分布漂移了模型效果下降是必然的重训也没用你要先解决数据问题。第三步确认特征管线正常某个特征是否突然大面积缺失或变成常量。这个问题的隐蔽性极高因为模型不会报错只是默默失效。最后才怀疑模型本身结合人工抽检的badcase判断是泛化能力不足还是遭遇了分布外输入。5.4 个人项目如何低成本起步如果你没有公司算力资源也不用焦虑。我在个人项目里的组合是开源数据集加大模型加云上的少量GPU。具体操作数据优先用开源数据集验证链路比如HuggingFace Datasets上的现成数据模型先用开源权重尽量选择靠LoRA就能微调的模型没有GPU就用Google Colab免费额度或者云平台的竞价实例成本低到可以忽略从很小的数据量开始跑通全链路哪怕只有几千条样本也要完整走一遍“数据→训练→评估→部署→监控”的闭环真正值钱的从来不是“我训了一个什么模型”而是“我有没有把一整条AI工程链路跑通”。从零开始这个事情最重要的不是跑得多快而是把每一步都走扎实。我在实际项目里最大的体会是AI工程中最难的部分不是某一次训练跑出了多高的指标而是你建立的那套系统能不能在真实环境中稳定运转、能不能在出问题时快速定位、能不能在业务变化时平滑迭代。那些每天记录实验日志、为每个接口写清楚错误码、定期检查数据分布的习惯看起来琐碎又不起眼但救场的从来都是这些细节。如果你也想从零建立起自己的AI工程能力我的建议很简单找一个真实的小问题逼自己完整走一遍链路不要跳过任何一个环节。等你走完这一遍再回头看那些框架和工具你会有完全不一样的理解。
从零构建AI工程能力：数据、模型、部署与运维全链路实践
很多人第一反应是把“AI工程”理解成“训练一个模型”。我见过太多人学完深度学习课程、能跑通几个开源项目就觉得自己会AI工程了。等到真要做一个能上线、能维护、能迭代的AI系统时全线崩溃。这也是我推崇“ai-engineering-from-scratch”这个思路的原因——只有从零到一完整地走一遍AI工程链路你才会真正理解每个环节存在的必要性而不是停留在调用现成API或者跑通一个demo的层面。这篇内容不是某个框架的使用教程而是我按“从零开始建立AI工程能力”这个目标沉淀下来的完整路径。适合三类人准备入行的AI工程师、从Web或后端转AI的开发者、以及已经在写算法但缺乏工程化经验的算法工程师。它解决的核心问题很现实你怎么把一个能跑通的模型变成一个能长期运转的业务系统。1. 从零起步前先想清楚AI工程要解决什么问题1.1 为什么“from scratch”比直接学框架更重要裸辞转行的时候我也走过弯路。当时市面上最热的是TensorFlow和PyTorch我花了大把时间啃模型结构、训练技巧以为这就是“AI工程”了。直到入职第一周leader让我把一个已经训练好的模型部署成服务我才发现模型训练在整个链路里只是一小段前面有数据获取和清洗后面有服务化、监控、回滚、迭代。这些环节学校不教、教程也少讲但恰恰是工作里最磨人的部分。从零做一次完整流程的意义就在于你会亲手踩遍每一个坑知道训练集分布偏差会让线上效果崩掉、知道模型推理耗时和吞吐怎么平衡、知道线上数据格式换了之后特征管线为什么静默失败。这些经验不是看书能看出来的是真的要自己把自己扔到项目里从零把它跑通一遍才能长在脑子里。我更愿意把AI工程拆成六个环节来理解数据采集与清洗特征工程与样本构建在大模型场景下对应的是数据配比、上下文构建和指令格式设计模型训练与迭代离线评估体系服务化部署上线线上监控与数据回流很多新人只盯着第三项但实际工作中决定项目成败的往往是1、2、5、6。后面我会逐项展开讲。1.2 用开餐厅来理解整条链路如果觉得抽象可以用开餐厅来类比模型是菜谱数据是食材特征工程是切菜备菜训练是后厨试菜评估是品控部署就是前台出菜监控是顾客反馈。菜谱再牛食材不新鲜也做不出好菜后厨试菜做得再开心前台出菜慢、份量不稳定餐厅照样倒闭。我之所以反复强调这个类比是因为很多技术问题本质上是“工程节奏”问题。比如什么时候该训练新模型不是你想训练就训练而是线上指标掉到某个阈值、数据积累到一定量、或者业务规则发生变化时才有可能触发模型更新。这套节奏在你没有完整走一遍链路之前是完全没有体感的。2. 地基数据工程怎么做扎实2.1 数据收集与清洗的基本功很多教程从“加载开源数据集”开始这让我很反感。真实场景里数据是从日志、数据库、第三方接口、甚至人工整理的文件里一个个凑出来的。第一课应该是用shell和Python把零散数据聚合成可用的训练集。我个人的标准操作流程大概是这样的先写脚本做全量扫描统计字段缺失率、重复率、时间范围、值域分布再写清洗逻辑剔除明显错误样本、统一时间戳格式、处理缺失值、过滤敏感信息做一次抽样人工检查随机抽200条看数据质量和标注一致性最后把数据转成统一格式比如JSONL或Parquet分版本存档清洗这一步最容易翻车的是“静默错误”。比如时间戳有的是秒级、有的是毫秒级如果没统一按时间排序的特征就全乱了再比如文本字段里混入了换行符或特殊字符后面切分样本时会出现莫名其妙的空样本。踩过这些坑之后我养成了一个习惯每一步数据操作都打印统计信息处理前记录行数处理后对比行数任何不一致都要找到原因绝不放过。2.2 标注、质检与版本管理没有高质量标注就没有高质量模型。但标注工作看起来简单做起来非常考验管理能力。我见过太多项目的标注规范只有半页纸标到后面每个标注员的标准都不一样。我的建议是写一份详尽的标注规范每个字段都给出正反例疑难case要有仲裁方案小批量试标先让两三个人标同一批数据计算一致性比如Cohen‘s Kappa一致性过低就继续对齐标准正式标注过程按5%~10%的比例抽检抽检不合格就打回重标标注完成的数据和原始数据分开存储关键字段加密脱敏数据版本管理这一点很多人会忽略。但实际项目里训练集改了一版之后模型效果对比就失真了。我强烈建议用DVCData Version Control或者至少用“数据集版本变更说明”的命名规范确保每个模型版本都能找到对应的训练数据版本。不要高估自己的记性也不要高估同事的责任心数据版本混乱是团队协作里最大的隐形杀手。2.3 特征工程与数据管线搭建传统机器学习场景下特征工程决定了效果上限模型只是逼近这个上限。我的经验是先把特征分成几类基础特征用户属性、物品属性、行为特征近7天点击、收藏、交叉特征用户偏好类目×物品类目每一类单独验证有效性不要一开始就堆几百维特征。在大模型场景里特征工程变成了“数据配比”和“上下文工程”。你要考虑训练数据里不同任务的比例是多少每个样本的输入输出怎么组织Instruction要不要加前缀这些决策同样直接影响模型表现本质上和特征工程解决的是同一个问题让模型看到什么、怎么让模型学到规律。数据管线搭建我推荐按这个节奏来先用Python脚本跑通全流程数据量大了之后再用Airflow或Prefect把任务调度起来。不要一上来就搭复杂的分布式数据平台除非你的数据量真的到了那个量级。3. 模型开发别急着上大模型3.1 从baseline开始先把链路跑通每次接新项目我的第一个模型永远是“最土”的。如果是分类任务先上逻辑回归或XGBoost如果是生成任务先用现成的开源小模型加简单prompt如果是大模型应用先直接调现成API验证效果边界。这样做有几个好处快速验证数据管线是否通畅形成一个可靠的效果下限后面所有复杂模型都要以超越这个baseline为及格标准暴露问题比如特征缺失、标签噪声、评估指标不合理这些在简单模型上更容易暴露我见过反着做的团队上来就微调一个大模型跑了两个星期结果发现是数据标签错了白费力气。先跑baseline磨刀不误砍柴工。3.2 把评估体系建在模型训练之前大多数项目挂在评估上。很多人的“评估”就是在测试集上跑几个指标Accuracy高了就宣布成功。但真实业务里离线指标和线上效果经常脱节。我的经验是在训练开始之前先确定评估标准。离线层面除了常规的准确率、召回率、F1还要设计针对业务场景的评估集。比如你做客服问答要单独准备一组“难例”集里面全是用户真正会问但模型容易错的表达你做内容审核要额外关注误杀率因为把正常内容判成违规比漏掉一条违规内容更伤用户体验。人工评估也要提前设计好评分标准最好有详细的评分维度说明多人打分后取平均值或投票。大模型生成类任务我强烈建议用LLM-as-a-Judge辅助评估但Judge模型本身也要测试过稳定性别拿一个不稳定的裁判来评判模型好坏。3.3 调参与迭代的节奏感调参这件事最忌讳靠感觉。我早期就犯过这个错误改了学习率又改了batch size还换了一个优化器三个变量一起变效果变好了也不知道是谁的功劳。后来痛定思痛立了几条规矩每次实验只改一个变量每个实验都有完整的日志记录参数、数据版本、代码commit、训练耗时、指标结果用MLflow或Weights Biases统一管理实验记录再也不靠excel表记参数我的调参习惯是先粗调锁定大致范围再细调围绕最优值做小范围搜索。不要用网格搜索无脑跑除非你预算特别充裕。更实用的做法是随机搜索加上多轮人工判断让领域知识参与进来。大模型的微调我建议先了解清楚全量微调、LoRA、QLoRA之间的区别。大多数场景下LoRA就够用了显存占用小、训练快、效果也不错。除非你有足够多的数据和算力否则不要一上来就全量微调。4. 上线与运维真正拉开差距的部分4.1 模型服务化与API设计训练完模型只是开始。把模型包装成一个稳定、可控的服务才是AI工程和论文实验的分水岭。我常用FastAPI做模型服务原因很简单性能好、自带OpenAPI文档、生态成熟。但框架只是基础真正要设计的是API的边界输入要有完整的request schema字段类型、约束、示例都要定义清楚输出要统一格式包括状态码、业务码、数据、错误信息要设置合理的超时时间做并发限制避免一个慢请求拖垮整个服务要处理模型异常比如输入长度超限、推理结果为空给用户可理解的错误提示而不是直接500还有一点特别容易被忽略模型的吞吐和延迟是矛盾的。延迟是单个请求的响应时间吞吐是单位时间能处理的请求数。你想降低延迟可能要牺牲batch大小你想提高吞吐可能要接受一定的响应延迟。实际项目中必须找到业务能接受的平衡点而不是盲目追求某一个指标。4.2 部署方案选型与推理优化部署选型会直接影响成本和稳定性。我有几条经验先用Docker把模型服务容器化保证本地和线上环境一致如果模型不大优先考虑CPU部署加优化成本低很多如果模型实在太大再考虑GPUGPU推理不要裸上PyTorch建议用vLLM、TensorRT或ONNX Runtime做推理优化吞吐能提升好几倍大模型部署一定要用vLLM它的PagedAttention机制能让显存利用率大幅提升吞吐和延迟都明显优于原生PyTorch推理量化是另一个降本利器。从FP32到FP16能省一半显存再到INT8甚至INT4显存占用和推理速度都会有明显变化但精度会小幅下降。我的建议是先量化到FP16验证效果如果精度能接受再尝试更激进的量化方案。千万不要为了省钱把精度降到用户明显感知到的程度。4.3 监控、回滚与持续迭代线上模型不像离线训练那样“跑完就结束”。你要随时知道它有没有在正常工作。我建议至少做这几层监控接口层QPS、延迟分位数、错误率模型层预测置信度分布、类别分布数据层输入特征分布、关键字段缺失率、词汇覆盖变化数据漂移检测是个经典难题。我常用的方法是定期比如每天对比线上数据的特征分布和训练时数据的分布用PSIPopulation Stability Index或KS检验量化差异。PSI超过0.2就要高度警惕说明线上数据和训练数据已经出现明显分化模型效果大概率在退化。回滚预案一定要提前做。每次新模型上线都要保留上一版本的服务和配置确保新版本出问题能一键切回。我见过太多团队上线新模型之后把旧版本的镜像就地删掉结果新模型崩溃只能紧急重建那种场面太狼狈了。5. 常见问题与排查技巧实录5.1 训练时显存或内存爆了怎么办这是新人问得最多的问题。显存溢出OOM的排查思路是有顺序的先把batch size调到1如果还爆说明模型本身太大考虑换小模型或用LoRA等参数高效微调方法如果batch size1不爆说明是batch太大先减半再逐次减半找到临界值开启梯度累积用很小的batch size模拟大batch的效果使用混合精度训练fp16/bf16显存占用会明显下降检查数据加载是否占用过多内存用DataLoader的num_workers参数平衡CPU和GPU内存溢出常见于数据处理环节通常是全量加载导致的。我习惯用流式读取加分批处理绝对不会把几个G的数据一次性塞进内存。5.2 线上推理延迟高、吞吐上不去延迟高可以按以下顺序排查先看模型推理本身的时间纯模型推理耗时占比高优先优化模型蒸馏、量化、换小模型看预处理和后处理耗时有些项目的文本切分、正则替换、JSON序列化非常耗时容易被忽略看网络传输和IO比如跨机房调用、磁盘读写慢看服务框架层面线程池太小、连接池耗尽都会导致延迟飙升吞吐上不去的常见原因是没用batch推理。GPU是极度适合并行计算的硬件一次处理8个请求和一次处理1个请求的耗时差异远没有8倍那么大。vLLM这类推理框架就是为此优化的。另外如果业务场景允许加一层缓存能挡掉大量重复请求效果立竿见影。5.3 线上效果变差先别急着骂模型线上指标下降很多人第一反应就是“模型不行要重训”。我的排查顺序是先看数据再看特征最后才看模型。第一步用监控面板确认指标下降的时间点往前后追溯同时段有没有发版、数据源变更、业务规则调整。第二步检查线上输入数据和训练数据的分布是否一致PSI指标有没有异常升高。如果特征分布漂移了模型效果下降是必然的重训也没用你要先解决数据问题。第三步确认特征管线正常某个特征是否突然大面积缺失或变成常量。这个问题的隐蔽性极高因为模型不会报错只是默默失效。最后才怀疑模型本身结合人工抽检的badcase判断是泛化能力不足还是遭遇了分布外输入。5.4 个人项目如何低成本起步如果你没有公司算力资源也不用焦虑。我在个人项目里的组合是开源数据集加大模型加云上的少量GPU。具体操作数据优先用开源数据集验证链路比如HuggingFace Datasets上的现成数据模型先用开源权重尽量选择靠LoRA就能微调的模型没有GPU就用Google Colab免费额度或者云平台的竞价实例成本低到可以忽略从很小的数据量开始跑通全链路哪怕只有几千条样本也要完整走一遍“数据→训练→评估→部署→监控”的闭环真正值钱的从来不是“我训了一个什么模型”而是“我有没有把一整条AI工程链路跑通”。从零开始这个事情最重要的不是跑得多快而是把每一步都走扎实。我在实际项目里最大的体会是AI工程中最难的部分不是某一次训练跑出了多高的指标而是你建立的那套系统能不能在真实环境中稳定运转、能不能在出问题时快速定位、能不能在业务变化时平滑迭代。那些每天记录实验日志、为每个接口写清楚错误码、定期检查数据分布的习惯看起来琐碎又不起眼但救场的从来都是这些细节。如果你也想从零建立起自己的AI工程能力我的建议很简单找一个真实的小问题逼自己完整走一遍链路不要跳过任何一个环节。等你走完这一遍再回头看那些框架和工具你会有完全不一样的理解。
