南门居士-杜锦刚把模型训练完只是第一步，真正让它产生价值的是把它交到别人手里。你写好一段推理脚本，在自己的Jupyter Notebook里跑得飞快，精度也不错，但产品同事、前端同学、甚至是另一个服务想调用它时，总不能用截图或者把你电脑上的脚本拷贝过去跑。这时候最通用、最低侵入的方案就是：把模型包装成一个Web API，让任何人通过HTTP请求就能拿到预测结果。这也是我在多个项目里经历过从“本地能跑”到“稳定上线”之后，最想分享的一段经验。
这篇文章不聊高深理论，只讲实战。我会带你走一遍一个典型的机器学习模型部署流程：从模型序列化、接口设计，到用FastAPI封装、性能调优、Docker容器化，最后总结我在实际部署中踩过的坑。适合那些已经会用sklearn或PyTorch训练模型，但还不清楚怎么把它变成线上服务的同学。如果你只是听说过“模型部署”但没动过手，这篇可以直接照着操作。
1. 部署形态与选型：为什么Web API是必经之路
1.1 从Notebook到生产：脚本调用和API的差别
很多初学者会觉得，模型部署不就是写个predict函数，然后在服务器上跑起来吗？其实中间的坑比想象中多得多。最原始的方式是把模型文件和一个Python脚本放在服务器上，通过命令行或定时任务调用。这种方式看起来简单，但有几个硬伤：第一，调用方没法跨语言，别人用Java、Go写的服务要调你的模型，总不能强制他装Python环境；第二，无法处理并发请求，脚本是进程级的，来一个请求就要起一个Python进程，GPU资源根本吃不住；第三，没有统一的错误处理和数据校验机制，输入一个坏数据可能直接让进程崩溃。
Web API之所以成为事实标准，是因为它把“模型能力”抽象成了一个HTTP端点。调用方只需要发送JSON格式的输入，收到JSON格式的输出，完全不用关心背后是sklearn、TensorFlow还是某个自研的推理引擎。这种解耦方式让模型服务可以独立部署、独立扩容，也能很自然地接入微服务体系里。我在实际项目里最直观的感受是：当后端把这个预测接口暴露给前端和第三方之后，后续的模型迭代只需要替换服务内部的文件，接口地址和数据结构不用变，省了无穷无尽的沟通成本。
1.2 主流框架对比与我的选择
就算决定用Web API，也还有框架选型的问题。我在几个框架里都写过不同的部署服务，简单说下我的主观体验：
| 框架 | 适合场景 | 我的体验 |
|---|---|---|
| Flask | 简单快速出活 | 同步阻塞，性能一般，写小demo没问题，生产环境要自己封装很多东西 |
| FastAPI | 现代异步API、高并发、自动文档 | 基于Pydantic做数据校验很爽，自带OpenAPI文档，性能也不错，我最推荐 |
| Django REST Framework | 需要自带后台管理、ORM | 重量级，适合有数据库交互的大系统，普通模型服务杀鸡用牛刀 |
| .NET Core Web API | 企业级C#技术栈 | 配合ML.NET或ONNX Runtime能跑，但生态相对封闭，团队要都是Python就绕开 |
FastAPI用起来最顺手。它原生支持异步，不用自己折腾线程池；请求体用Pydantic校验，输入格式不对能直接返回400错误，省得在函数里写一堆if not isinstance。另外它自动生成的/docs接口文档可以直接拿给前端同学联调，这是Flask没有的待遇。如果你的团队对JVM更熟，也可以用Spring Boot，但后面我所有的例子都会用FastAPI，因为它在大部分模型部署场景里最不费脑子。
模型格式上，如果只是sklearn或XGBoost这类传统模型，直接joblib.dump或者pickle.dump就够了；如果是深度学习模型，建议导出成ONNX，这样能跨框架、用CPU也很快，后面会专门讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模型落地前必须想清楚的几件事：序列化与数据对齐
2.1 模型持久化格式：pkl、joblib、onnx该怎么选
很多人直接把model.save("model.h5")或pickle.dump(model)就完事了，直到部署时才踩坑。不同框架有不同的序列化方式，我们得先处理好“模型文件”这一步。
对于传统机器学习模型，比如sklearn里的LogisticRegression、RandomForest，我推荐用joblib.dump，因为它对numpy数组做了优化，加载速度比原生pickle快不少。示例：
python复制import joblib
from sklearn.linear_model import LogisticRegression
model = LogisticRegression()
model.fit(X_train, y_train)
joblib.dump(model, "model.joblib")
对于PyTorch模型，不要在项目里到处用torch.save(model.state_dict())，因为部署时需要先定义出相同的模型类，很容易因为代码路径不一致而出错。更稳妥的做法是导出为torch.jit.script或ONNX。我特别推荐ONNX，因为它不仅让推理可以用ONNX Runtime这个轻量级引擎，还能直接兼容CPU、GPU，做量化也方便。