企业官网建设流程全解析

把"跑通一个AI服务"和"工程化落地一个AI服务"彻底分开来看，是我做这套从零整理时最强烈的感受。标题里的ai-engineering-from-scratch，说白了就是希望给那些已经会调模型、会跑notebook，但还没亲手把一个模型变成稳定线上服务的人，一条完整的、能照着走的路。我在这条路上踩过不少坑，也摸索出了一些很实用的套路，这篇就把我的完整思路和实操经历摊开来讲，希望能帮你省掉几个月的摸索期。

1. 先说清楚AI工程到底难在哪：从一次"代码能跑"的假象说起

我最早带团队的时候经常遇到一个诡异的现象：算法工程师在本地Jupyter Notebook里把模型调得漂漂亮亮，离线指标也很能打，代码交到工程手里，部署上线之后效果却一路下滑，甚至直接报错。两边互相看不懂，算法说工程没按我的版本来，工程说算法代码里全是隐藏的状态依赖。这种撕裂感，就是AI工程要解决的问题。

1.1 本地能跑和线上能扛，差距不在模型而在系统

你在notebook里做的推理，是数据一次性加载到内存里，模型直接调用，输出打印在屏幕上。线上服务呢？请求是并发进来的，数据是会变的，模型显存是要被多路复用的，进程是会崩溃的，数据分布是会漂移的。哪怕你的模型精度再高，只要这几层没处理好，线上效果照样稀烂。

我见过有的团队上线一个文本分类模型，在测试集上F1高达0.93，上线后业务方反馈一堆错误案例。排查到最后发现，线上接口收到的文本是经过脱敏和截断的，和训练时用的原始文本根本不是同一种分布。模型本身没错，错的是数据链路的断裂。

这类问题的本质，就是数据和模型之间没有任何形式的一致性约束。训练时一套处理逻辑，推理时又写了一套，两边各改各的，不出问题才是运气好。

1.2 从零开始到底是在开始什么

这个标题里的"from scratch"，我的理解不是要你不利用任何预训练模型、从反向传播手写一个神经网络，而是指你要从一张白纸开始，搭建一套能持续迭代的AI工程系统。它包含至少五条线：

这五条线，每一条单独拎出来都能写一本书。但如果你从零开始，我强烈建议先完整串联一遍，再逐个深入。先把一个最小的端到端链路跑通，哪怕模型用的是现成的开源模型，也要让这条链路具备"可以上线"的基本素质。

2. 从零起步的第1公里：环境、数据与算力三个地基

很多人学AI工程是从训练开始的，这其实是本末倒置。我自己的经验是，前面三件事不打牢，后边你会在各种奇怪的问题上反复躺枪。

2.1 开发环境：把"在我机器上能跑"这句话彻底消灭掉

环境不一致是AI工程里最让人头秃的坑。算法同事用Python 3.9，你用3.11，他装的是CPU版PyTorch，你用GPU版，模型推断出来的数值都能对不上。解决这个问题的唯一办法，就是用工具把环境锁死。

我的标准配置是这样的：

• 用pyenv管理Python版本，项目根目录放一个.python-version，内容就是3.11.9，谁进来都切到这个版本；
• 用uv（或者pip-tools）管理依赖，生成uv.lock文件，所有传递依赖的版本都锁死；
• 整个开发环境做成Docker镜像，Dockerfile里固定python:3.11-slim基础镜像，把CUDA、cuDNN版本写死在镜像里，而不是依赖宿主机装了什么；
• 训练和推理共用同一个镜像，从根上避免"训练有这依赖，推理缺那依赖"。

有个非常反直觉的细节，Docker镜像的体积比你想的更影响开发效率。本地构建模型服务镜像时，如果你用基础镜像手动装一堆系统库，镜像体积很容易超过3GB，传到镜像仓库就能把人急死。我后来改用多阶段构建，把编译阶段和运行阶段拆开，生产镜像能压到800MB以内，拉取时间大幅缩短。

2.2 数据规格化：先定Schema再谈训练

数据是AI最容易被忽视的地基。我见过太多团队，数据文件直接用CSV来回传，字段类型靠猜，日期格式各写各的，跑着跑着字段加了几个，下游模型训练代码就崩了。

更好的做法是：

• 统一存储格式：能上Parquet就别用CSV，自带列式存储和压缩，大数据量读写性能差距是数量级的；
• 写Schema校验：用Great Expectations或者pandera定义每一列的类型、取值范围、非空约束，数据进管线之前先过一道校验，不满足直接报警；
• 数据版本化：每次训练用的数据集，记录下哈希值，哪怕只是改了一个字段，版本号也要变。DVC是这方面最常用的工具，它不存全量数据，只存数据文件的哈希指针，配合Git正好用。

这一步很多初学者嫌麻烦，觉得我数据量小不需要这些。但我可以告诉你一个大概率会发生的事故：你某一天手工修改了一份CSV，给一个新字段补了值，不知不觉间改变了整体分布，重新训练后的模型效果忽好忽坏，而你完全不知道为什么。这时候再回头想Schema校验和版本管理，代价已经高了很多。

2.3 算力意识：别让GPU账单变成你的天价学费

算力这个东西，训练之前不规划，训练完就后悔。我自己在这上面吃过亏，所以现在给自己定了两条硬规矩：

第一，大规模训练之前先小规模试跑。比如打算用100万条数据微调，先用1万条跑一个批次，确认数据格式没问题、Loss在下降、日志输出正常，再放开全量。这个小时级的试跑，能避免你浪费几百块的GPU时长的同时，还收获一堆报错日志。

第二，给训练任务设预算上限。主流云厂商都有预算告警机制，设置好上限，一旦快触顶就自动发通知。别觉得这没必要，分布式训练里的"野路子"代码是什么开销水平，账单一出你就清楚了。印象非常深刻的一次，我忘了关一个测试用GPU实例，连着跑了三天，那一个月的成本直接顶平时三个月。从那天起，"关资源"和"写代码"并列成为我的日常必做事项。

3. 训练与微调不是点个开始就行：可复现才是准入门槛

训练环节，很多人的误区是追求指标好看，忽略了可复现性。可复现这个东西，枯燥，不性感，但它是工程化训练和实验室训练的分水岭。

3.1 实验追踪：你的训练记录不是聊天记录

早期我做训练实验，用的方式是本地新建一个文件夹，然后起名model_v2_final、model_v2_final_real、model_v2_final_real_v3。这种命名方式的后遗症，用不了几个月你就会彻底想不起来哪个版本用了哪份数据、哪个超参组合。

真正工程化的做法，是用MLflow这类实验追踪工具。每次训练前把关键信息全部记录进去：

import mlflow with mlflow.start_run(run_name="bert-finetune-batch32-lr2e5"): # 记录参数 mlflow.log_param("learning_rate", 2e-5) mlflow.log_param("batch_size", 32) mlflow.log_param("dataset_version", "2025-06-01_v3") mlflow.log_param("base_model", "bert-base-chinese") # 训练代码... # 记录指标 mlflow.log_metric("val_f1", 0.923) mlflow.log_metric("val_loss", 0.18) # 记录模型 mlflow.pytorch.log_model(model, "model")

这么做短期看似乎多写了几行代码，但长期带来的好处是：你能回答"这个模型是怎么来的"这个问题。线上模型出问题时，第一步不是看代码，而是查实验记录，搞清楚这个模型用了什么数据、什么基座、什么超参，然后再定位问题。这套追溯能力，生产环境必备。

3.2 大模型微调：能不动全量参数就别动

针对微调开源大模型，我最避讳的做法就是一上来全量微调。全量微调的成本高、训练不稳定、而且一个团队如果微调了很多个垂直模型，部署时的显存开销会让人崩溃。现在做微调，基本都是参数高效微调的路数，其中LoRA和QLoRA是最常见的两个选择。

LoRA的原理，通俗讲就是不改变原来的模型权重，只在你关心的线性层旁边加两条低秩矩阵，只训练这两条小矩阵，原来的权重冻结不动。这样显存占用小很多，训练速度也快，而且微调完你得到的其实是一个很小的增量权重文件，几MB到几十MB，部署时可以动态加载合并，也可以单独走一条推理分支。

QLoRA更进一步，把基座模型的权重先4bit量化，在量化后的基座上做LoRA训练，效果在大多数指令微调场景下和全量微调的差距已经很小。

我在一个法律文书分类项目里验证过：全量微调一个7B模型，需要4块A100，训练时间超过6小时；改用QLoRA之后，单卡A10G就能跑，时间缩到45分钟，分类F1只掉了0.8个百分点。这种性价比，工程化落地场景下几乎不用犹豫直接选QLoRA。

3.3 随机与确定：把实验误差从源头掐灭

训练可复现最容易被忽略的是随机性。数据加载顺序、数据增强、Dropout、甚至CUDA的某些操作都有随机性。想让一次实验结果能被精确复现，至少要固定这几个东西：

• 全局随机种子：random.seed(42)、numpy.random.seed(42)、torch.manual_seed(42)；
• torch.backends.cudnn.deterministic = True，把cuDNN切到确定性算法；
• torch.backends.cudnn.benchmark = False，关闭自动寻找最优算法的逻辑；
• DataLoader用worker_init_fn保证每个子进程的随机种子也固定。

顺带说一个不坑你不舒服的细节，全量复现要连同硬件一起考虑。A100上跑出来的PyTorch结果和V100上不一定完全一样，浮点运算的微小差异是硬件层面的物理事实，无法做到逐位一致。所以工程上对复现的定义，通常是指指标在合理误差范围内可以再次得到，而不是每小数点后六位都一模一样。

4. 把模型交到线上用户手里：部署链路上的最后一公里问题

模型训练好了，只相当于你做好了菜，端到用户桌上还得过一条繁忙的走廊。这条走廊上的问题，才是AI工程最实战的部分。

4.1 模型转换：不要用训练格式直接上线

PyTorch训练出来的.bin或.safetensors格式，直接塞进生产服务是不太合适的。一方面它体积大、加载慢；另一方面它对部署环境里的Python和PyTorch版本极其敏感，稍有不匹配就加载失败。

我常用的做法是转成ONNX格式。ONNX就像一个中间语言，把模型的计算图固化下来，部署时不再需要完整PyTorch框架，只要有一个ONNX Runtime的轻量运行时就能跑。实测下来，ONNX版本在CPU上的推理速度通常比PyTorch原版快20%-50%，显存占用还能降一些。

import torch import onnxruntime as ort from transformers import BertForSequenceClassification # 训练好的PyTorch模型 model = BertForSequenceClassification.from_pretrained("my_finetuned_bert") # 转出ONNX dummy_input = {"input_ids": torch.ones(1, 128, dtype=torch.long), "attention_mask": torch.ones(1, 128, dtype=torch.long)} torch.onnx.export(model, (dummy_input["input_ids"], dummy_input["attention_mask"]), "model.onnx", opset_version=14, input_names=["input_ids", "attention_mask"], output_names=["logits"])

大型语言模型做生成式推理时，用vLLM这类专门的推理引擎更合适。它用PagedAttention机制管理显存，吞吐量比普通Hugging Face管线提升好几倍。我第一次把7B模型从Transformers管线切到vLLM时，在面对相同请求吞吐量的情况下，GPU卡数直接砍掉了三分之二，效果相当直观。

4.2 服务框架：FastAPI只是入口，稳定靠设计

模型部署的服务框架，现在基本是FastAPI标准打法，异步接口、自带OpenAPI文档、性能也不错。但真正决定稳不稳定，不是框架本身，而是你这层API的设计：

• 超时设置：模型推理有波动，请求排队多了，单次推理可能从50ms升到500ms。如果API不设超时，网关等不起就会重复发起请求，反而把系统压垮；
• 批量推理：高并发场景下，单条请求循环推理是非常浪费的。更好的方式是把请求攒一小批，凑够batch_size或者到时间阈值再统一进模型推理；
• 背压机制：模型服务处理不过来时，要有主动拒绝的逻辑，而不是无限接收请求把内存打爆。

我见过一个上线事故，因为接口没做批量推理，又把模型服务的并发上限设成了和网关一样的值，结果流量稍大，GPU利用率只有个位数，延迟却在不停飙升。优化成动态batching以后，GPU利用率上到80%，相同资源下吞吐翻了几倍，延迟反而降了。

4.3 版本共存：线上模型不是只有一个

模型版本管理这件事，比代码版本管理要复杂得多。因为模型不是单纯靠Git就能管理的，还要管理它的数据版本、训练配置、评估结果。用MLflow的Model Registry，可以给每个模型版本打上状态标记：Staging、Production、Archived。调用方明确指定版本号，而不是每次都用latest。

线上同时运行多个模型版本，这个场景在工作里非常常见。比如新模型上线，总得先切5%流量跑几天看看在线指标，没问题再逐步放量，有问题立刻切回旧模型。这个机制说起来简单，但真踩过坑才知道，没有多版本共存能力的模型平台，回滚就是一次噩梦。曾经有一次新模型放量后线上投诉率升高，我们想把流量切回旧模型，结果发现旧模型已经在代码仓库里找不到对应文件了。所以我现在要求所有模型服务，必须保留最近两个生产版本的推理接口，随时可以秒级切换。

5. 上线只是开始：监控、回归与AI效果衰减的持久战

模型上线后的工作，往往比开发期还重。因为模型的输出不是确定性的，数据分布会变，用户行为会变，效果会衰减。这个"上线即终点"的思维，是AI工程里最危险的一种错觉。

5.1 数据漂移：你的模型正在悄悄变笨

数据漂移是模型效果衰减的最大隐形杀手。它分两种，一种是特征漂移：训练数据的特征分布和线上实时数据的特征分布慢慢拉开差距；一种是概念漂移：同样一个特征值，它对应的业务含义变了，比如"点击"这个动作在界面上改了入口之后，行为模式完全不同。

检测特征漂移，我常用两个指标：

• PSI（Population Stability Index），用来衡量某个特征在两个时间段上的分布差异。一般认为PSI小于0.1是稳定，0.1到0.25需要关注，超过0.25就是明显漂移；
• KL散度或JS散度，适合衡量更精细的概率分布变化。

监控到漂移之后怎么办？不是立刻重训，那是成本最高的选项。第一步先定位漂移源：是上游数据源改了？还是数据预处理逻辑变了？第二步看业务侧有没有发生什么变动，比如活动流量、推荐策略调整。确认是真实环境变化后，再决定是否需要增量更新或重新收集数据训练。

5.2 线上指标：离线评估的指标好看不等于线上好用

离线评估用的是F1、AUC、准确率这些标准指标，但线上业务关心的是转化率、留存率、客诉率、处理时长。两者之间存在很大gap。

我在文本审核模型项目里的体会非常深：离线AUC高达0.98，觉得已经无敌了。上线后业务方反馈，漏过的违规内容比拦截掉的还多。后来一查，离线测试集里违规和正常的比例是1:9，但线上实际比例可能只有1:49。类别先验分布不同，AUC这种阈值无关指标依然很漂亮，但业务查的是漏报率，一算下来完全不能看。

所以线上监控至少要有两套口径：

• 运维口径：请求量、p95/p99延迟、错误率、GPU利用率、内存占用；
• 业务口径：按业务逻辑定义的"预测正确率"、拦截率、误杀率、用户投诉率、空结果率。

比如做智能客服FAQ推荐，用户没点击任何推荐答案的比例就是"空结果率"。模型效果如果衰减，这个数字会上涨，比看Loss更直接。

5.3 告警不是越响越好，要有一套不打扰人的告警规则

很多人一上来就把所有监控指标都加了告警，结果半夜三点被一条"内存使用率78%"的短信吵醒，告警疲劳之后，真正的严重事故反而没人理了。

我现在的告警设置原则是：只有需要人立刻介入的问题才告警。具体来说，就是三层：

• 危险告警：例如5分钟内错误率连续超过5%，或者服务整体不可用。直接钉钉或短信打到人；
• 预警告警：例如p95延迟连续15分钟超过200ms，或者PSI超过0.2但还没到0.25。群消息通知，工作日处理；
• 记录型告警：一些噪音信号，比如某个冷门接口错误率偶尔毛刺，直接进日志和看板，不打搅人。

这套分层，既能早发现问题，又不把人逼疯。真正到线上你才会意识到，稳定运行的系统不需要信息轰炸，它需要的是关键时刻有人判断。

6. 给自己一条可复制的从零路线图和避坑清单

最后这部分，我想给准备从零开始的你，一份可以直接照着走的路线图。不要贪多，不要跳步，按这个顺序走完，你就具备独立工程化一个小模型服务的能力了。

6.1 三阶段实践路线

阶段一：跑通最小闭环。选一个简单任务，比如文本分类或小规模FAQ匹配，用你熟悉的预训练模型微调，然后完成这些环节：数据清洗、格式标准化、实验记录、模型保存、FastAPI封装、Docker部署、本地或云端跑通接口。不要一上来就上Kubernetes和自动扩缩容，先把链路跑起来。

阶段二：加上工程底座。给这套链路配上数据版本管理、模型注册、监控看板、CI/CD流水线。哪怕你的项目只有一个人开发，也走完这套流程。这一阶段最重要的不是你用了哪些工具，而是你形成了"每次改动都能追溯、每次上线都能回滚"的肌肉记忆。

阶段三：做一次压测与优化。对你的服务做一轮并发压力测试，找到瓶颈是卡在模型推理、数据处理还是机器资源，然后针对性优化。这一步的价值是让你对"系统的弹性"有真实的感觉，知道它什么时候会撑不住，怎么扩展能撑住。

6.2 高频踩坑清单

我把自己在多个项目里反复出现的问题，整理成一张清单，每一条后面都是真实教训：

6.3 最后说一点我的真实体会

从零开始做AI工程，最反直觉的地方在于，它真正的瓶颈往往不是模型能力，而是系统思维。模型不好，换一个、微调一下，成本是可控的；系统不稳定，数据链路断裂、模型无法复现、上线不能回滚，每一个问题都能让你堵上大半周。

我见过不少技术很强的算法工程师，模型训练一手好牌，但工程化一到手就翻车，就是因为此前没有完整地把一个系统跑上线的经验。反过来，当你把数据、训练、部署、监控这条完整链路亲手走通之后，再回到模型本身做优化，你的判断维度就已经完全不一样了——你不光知道怎么能提升指标，你还会衡量这个提升在工程上值不值得做，部署成本能不能cover住，线上监控能不能及时发现衰减。

这条路的入门门槛确实不低，但它远没有传说中那么玄乎。把上面每个环节都亲手过一遍，你就拥有了真正的"从零到一"的AI工程能力，而不是停留在调包跑通一个Demo的阶段。希望我的这些经验，能让你少走一些我当年走过的弯路。