AI模型部署实战：从训练产物到线上推理服务的完整链路

模型训练完，不等于项目做完。真正让模型产生价值的，是把训练好的权重文件变成线上能跑的推理服务，让业务系统、Web应用甚至边缘设备能实时调用它。这篇“AI训练师图解”系列的第十篇，我就把AI模型部署这条链路完整梳理一遍：从训练产物盘点、模型格式转换、推理服务封装，到容器化部署、上线后的版本管理与问题排查，全流程拆开讲清楚。适合刚跑通训练流程、准备把模型产品化的朋友，也适合小团队自己动手做本地部署和API服务。

我见过太多人卡在这个环节：训练时模型跑得挺好，一提到“部署”就发怵，不知道权重文件该怎么处理，更不清楚API服务、Docker容器这些东西和模型之间是什么关系。其实部署没那么玄乎，核心就是解决三件事：模型怎么加载、推理怎么跑得快、服务怎么对外提供。把这三件事串起来，剩下的就是工程细节。

1. 部署前先想清楚：你要部署的是什么，部署到哪去

很多人拿到一个训练好的模型就急着写接口，结果写到一半发现缺东少西，还得回头补。部署前把准备工作做扎实，后面能省一大半麻烦。

1.1 盘点训练产物，别只盯着权重文件

训练完成后，你手上通常不止一个文件。以最典型的PyTorch训练流程为例，完整产物包括模型权重（.pt或.bin）、配置文件（config.json）、分词器文件（tokenizer.json或vocab.txt）、训练时记录的类别标签或归一化参数，还有训练日志和评估指标。如果你用的是LoRA这类微调方式，还得额外保留适配器权重（比如adapter_model.safetensors和adapter_config.json），部署时要和基础模型一起加载。

这里有个容易踩坑的地方：很多人只把best.pt拷走，以为就万事大吉。结果到了部署环境，模型加载报错，一查才发现缺了config.json——模型类定义里的参数和实际权重对不上。所以部署前一定要建一个清单，把权重、配置、分词器、标签文件全部列出来，逐项确认。我用YOLO训练目标检测模型时，还会额外保存一份data.yaml，里面记录了类别名和类别数，推理结果映射和可视化都靠它，少了它后端接口返回的类别就是一堆数字ID。

1.2 训练和推理是两码事，别用训练思维做部署

搞清楚训练和推理的区别，是部署入门的第一个门槛。训练是“学习”过程，模型要前向传播算损失、反向传播更新梯度，每轮迭代要同时保存中间激活值，所以显存开销大；推理是“预测”过程，模型只做前向计算，不需要保存梯度，显存开销小得多，这也是为什么一张消费级显卡能跑得动7B模型推理，但训练同尺寸模型需要多卡集群。

两者在精度需求上也不一样。训练时通常用FP16或BF16混合精度，既省显存又不损失收敛效果；推理阶段则可以更进一步，用INT8甚至INT4量化。量化后的模型体积能缩小到原来的四分之一，推理速度翻倍，代价只是轻微精度损失。很多部署工具链（比如ONNX Runtime、TensorRT、vLLM）都对低精度推理做了深度优化，效果非常明显。

1.3 部署形态怎么选，由应用场景决定

部署形态没有绝对的“最好”，只有“适不适合”。我在实际项目中常用四种形态：第一种是内嵌式部署，直接把模型库打进应用进程，比如桌面端软件内调用EasyOCR或PaddleOCR做文字识别，零网络开销、延迟最低；第二种是本地服务式部署，用FastAPI或Flask包一层HTTP接口，供内部系统调用，这是最通用、最推荐的形式；第三种是容器化部署，用Docker把模型和运行环境一起打包，团队协作和上线回滚都方便；第四种是边缘设备部署，模型转成TensorRT或OpenVINO格式部署到Jetson、树莓派、工业相机上，要求是极致的轻量和低延迟。

选择依据很简单：你的模型要被谁调用。如果只是自己写脚本测试，内嵌式就够了；如果要做成Web应用或小程序后端，那本地服务和容器化是标配；如果要跑在设备端做实时检测，就必须考虑边缘部署。别一上来就追求分布式集群——单机都还没跑明白，上集群纯粹是给自己添乱。

2. 模型从训练产物到可服务状态，中间隔着格式转换

训练产物不能直接被推理服务用，这是部署中最容易忽略的一步。PyTorch的.pt文件依赖PyTorch框架，加载慢、占用高，而且部署环境不一定装了完整的训练库。所以部署前要做格式转换和验证，这是整个链路里的重点，也是难点。

2.1 格式转换链路：PyTorch到ONNX再到TensorRT

最常见的转换链路是“PyTorc