技能介绍

模型上线前的真实痛点

一个在 Notebook 里表现不错的模型，离稳定对外服务还有很长一段路。常见的具体问题包括：

模型权重和预处理逻辑散落在多个脚本里，换台机器就无法复现推理
要手写 FastAPI/Flask 服务，加上输入校验、健康检查、错误处理，工程代码往往比模型本身更繁琐
Dockerfile 把训练依赖也打进镜像，镜像体积膨胀，拉取和启动变慢
上线后缺乏监控，推理变慢、输入分布漂移、静默失败都无从察觉

这个技能做了什么

@user_fccf428b/model-deployment-decision 将部署拆解为六个可执行步骤：

序列化与打包模型：导出为 ONNX、TorchScript、SavedModel 或 joblib pickle 等格式，并与预处理流水线、配置文件捆绑，保证推理自包含
构建服务 API：用 FastAPI 或 Flask 暴露预测端点，含健康检查、Pydantic 请求校验、结构化日志与合理的 HTTP 状态码
容器化：编写 Dockerfile，固定 requirements.txt 依赖版本，用多阶段构建剔除仅训练依赖
编排与扩缩容：定义 Kubernetes Deployment/Service 清单，配置资源限额、readiness/liveness 探针和基于 CPU、内存或自定义指标的 HPA
部署与验证：推送镜像、应用清单，对线上端点跑冒烟测试，验证已知输入的输出符合预期
监控与迭代：接入 Prometheus + Grafana 跟踪延迟、错误率、吞吐与预测分布漂移，用蓝绿或金丝雀策略发布新版本

支持的技术栈覆盖 FastAPI、Flask、TorchServe、Triton Inference Server 等服务框架，Docker/Podman 容器化，Kubernetes、AWS ECS、Cloud Run 编排，以及 AWS Lambda、Cloud Functions 等 Serverless 平台。

适用边界与注意事项

安全边界：技能不会自动安装依赖、修改系统权限或创建持久化任务；涉及实际部署等外部写入时，会先展示目标与影响，取得明确确认后才执行
大模型（> 1 GB）：不要打进镜像，应在启动时从 S3/GCS 拉取或挂载持久卷
Serverless 冷启动：大模型加载可能耗时 10–30 秒，需 provisioned concurrency 或 ONNX Runtime 优化
预处理一致性：训练与推理的预处理必须完全一致，推荐整体序列化 scikit-learn Pipeline，而非重新实现转换逻辑
GPU/CPU 差异：GPU 训练的模型部署到纯 CPU 环境时需显式 map_location="cpu"，并在目标硬件上先行验证