模型生产部署

问题背景

训练好的模型若仍停留在 notebook 或单机脚本里，很难稳定承接线上流量：预处理与推理代码容易分叉、依赖版本漂移、缺少健康检查与可观测性，一次「能跑」的 demo 往往撑不住生产扩缩与版本迭代。

技能如何工作

本技能让 Agent 按可复现的部署链路，把模型产物变成可运维的推理服务：

1. 序列化与打包：将模型导出为 ONNX、TorchScript、SavedModel 或 joblib 等格式，并与预处理流水线、配置文件一并捆绑，保证推理路径自包含。
2. 构建 REST API：用 FastAPI 或 Flask 在启动时加载模型，暴露预测端点；配合 Pydantic 做输入校验、结构化日志、健康检查与明确的 HTTP 错误码。
3. 容器与编排：编写多阶段 Dockerfile 缩小镜像；在 Kubernetes 上配置 Deployment/Service、资源限制、就绪/存活探针，以及基于 CPU、内存或延迟的 HPA。
4. 上线与监控：推送镜像并做冒烟测试；对接 Prometheus/Grafana 等，跟踪延迟、错误率、吞吐与预测分布漂移，必要时用蓝绿或金丝雀发布新版本。

也覆盖 TorchServe、Triton、Cloud Run、Lambda 等路径，以及 MLflow 等模型注册表的使用场景。

适用边界与注意点

• 超大模型（>1 GB）不宜打进镜像，宜启动时从对象存储拉取或挂卷，并考虑懒加载与就绪探针超时。
• 训练期预处理必须与线上一致，优先序列化整条 Pipeline，勿在推理侧重写一遍。
• GPU 训练、CPU 部署时需显式 map_location 并在目标硬件上实测；无服务器冷启动大模型要预留并发或最小实例。