模型部署手册

外观

框架与平台怎么选：自建、推理框架还是云托管

本页速览 FastAPI、BentoML、Triton、KServe、SageMaker、火山方舟……部署技术栈怎么选？本文给出按团队规模、延迟要求、模型类型的选型决策框架与推荐矩阵。

部署技术栈选型，是在「自建服务框架、专业推理框架、云托管平台」三层里，按模型类型、延迟要求、团队规模与运维能力找到性价比最优解。 为什么值得认真选？选错层的代价通常是「几个月后重写」：一个小模型团队去啃 KServe 的 K8s Operator，或者一个大流量服务用 FastAPI 裸扛却不用 Triton 的动态批处理，都是把成本花错地方。这篇给出选型决策框架：先回答 5 个问题，再用四张对比表收窄选项，最后落到一张场景→方案的推荐矩阵。部署模式的概念背景见 部署模式，框架底层原理见 模型服务。

选型第一原则

先定问题，再选工具。 技术栈不是越重越好，也不是越轻越好——是「刚好解决你的问题，且团队养得起」。

一、选型前先回答的 5 个问题 ​

答案决定你在哪一层选。五个问题按优先级排：

#问题为什么关键典型答案的指向
1模型类型？CV / 传统 ML / LLMLLM 必须上连续批处理引擎（vLLM），传统模型用 ONNX Runtime 就够LLM → 引擎层；否则 → 服务层
2延迟要求？P99 预算多少个位数 ms 要求走引擎+专用硬件；百 ms 级 FastAPI 就够极致 → Triton/TensorRT；宽松 → 轻框架
3团队规模与技能？有没有专职运维2 人团队养不起 K8s；10 人团队反而需要编排平台小团队 → 平台/轻框架；大团队 → 自建编排
4云环境？自建机房 / 单一云 / 多云云厂商托管平台有锁定，自建有机房限制多云 → 自建/KServe；单一云 → 平台
5运维能力？能 7×24 值班吗无人值守 → 托管平台（SLO 由云厂商兜）无运维 → 托管 SaaS

最常见的选择错误

用团队规模代替全部判断。 大团队 ≠ 该自建，如果模型只有 2 个、流量平稳，KServe 那套 K8s 复杂度就是负资产；小团队 ≠ 该用托管，如果模型是 LLM 且延迟敏感，托管平台反而更贵更难调。五个问题必须一起看。

二、三层架构：自建、框架、平台各是什么 ​

text
┌─────────────────────────────────────────────────────────┐
│ 云托管平台层（SageMaker / Vertex / 火山方舟 / PAI）       │ ← 买服务，SLO 云厂商兜底
├─────────────────────────────────────────────────────────┤
│ 推理框架层（Triton / vLLM / BentoML / Ray Serve / KServe）│ ← 买组件，自己编排
├─────────────────────────────────────────────────────────┤
│ 自建服务层（FastAPI + Docker + 自己的运维）               │ ← 全自己来
└─────────────────────────────────────────────────────────┘
   复杂度/成本 ▲                           控制力/灵活性 ▲
维度自建（FastAPI + Docker）推理框架（Triton/vLLM 等）云平台（SageMaker 等）
上手速度快（1 天出服务）中（1-3 天）最快（向导式）
性能上限低（无批处理/引擎优化）高（动态批处理、算子优化）取决于底层框架
控制力全可控高，但受框架约束低，平台说了算
运维成本最高（全自己扛）中（自己部署与扩容）最低（托管）
灵活性最高（什么都能写）中（多模型/多框架）低（被平台 API 框住）
适合原型、内部工具、小流量生产、高吞吐、多模型无运维团队、快速上线

三、框架横向对比：七个主流选项 ​

框架定位关键特性学习曲线最适合
FastAPIPython Web 框架异步、类型校验、生态广；本身不是推理引擎低单模型、自定义逻辑多、与团队 Web 技能无缝
TorchServePyTorch 官方服务模型管理、批处理、与 torch hub 集成中PyTorch 生态内、要官方支持
BentoML模型打包+服务框架标准化 Bento 打包、多运行时、云原生部署低-中快速交付、一键上云、团队要统一封装
Ray Serve分布式服务层弹性扩缩、多模型、与 Ray 生态结合中-高已有 Ray 集群、复杂 pipeline
TritonNVIDIA 推理服务器多框架后端、动态批处理、并发模型实例、ensemble中GPU 高吞吐、多模型混合、生产级
KServeK8s 上的推理平台Serverless、自动扩缩、灰度、多框架高（需 K8s）已有 K8s、要平台化的团队
Seldon CoreK8s 推理编排灰度、监控、explainability 集成高K8s 团队、要高级发布能力

要点解读：

  • FastAPI 是「地基」不是「对手」：其他框架大多内部也是 HTTP 服务，FastAPI 适合「自建 + 小模型」；一旦追求高吞吐，把模型放进 Triton，FastAPI 退化成前置网关；
  • Triton 的杀手锏是动态批处理（dynamic batching）：把分散请求合并成 batch，GPU 吞吐能翻 2-5 倍——这是 FastAPI 裸服务做不到的；
  • BentoML 的价值在「打包标准化」：模型 + 依赖 + 服务一次打包成 Bento，再导出成各种部署目标，特别适合「团队要快速交付多个模型」；
  • KServe vs Seldon：都基于 K8s；KServe 偏 Serverless + 自动扩缩，Seldon 偏高级发布与可解释性。选哪个看你的 K8s 运维成熟度。

四、云平台对比：四朵云的托管服务 ​

平台特性计费特点上手难度适合场景
AWS SageMaker全链路（训练/部署/监控）、多框架、Endpoint 自动扩缩按端点实例时长计费，闲置成本高中已在 AWS、要全托管
Azure ML与 Azure 生态深度集成、MLOps 工具链按计算/端点计费中已在 Azure、用 Azure DevOps
GCP Vertex AI统一 MLOps、Vertex AI Endpoints、与 BigQuery 集成按使用量计费，免费层较好中已在 GCP、数据在 BigQuery
火山方舟（火山引擎方舟）LLM 推理与微调平台、国内合规按 tokens/资源计费低国内业务、LLM 场景、合规要求
阿里云 PAI训练+推理一体化、EAS 在线服务、国产硬件适配按资源包/按量中国内业务、已在阿里云

平台锁定是真实成本

托管平台的每一项便利背后都是「按平台 API 重构」。上线前评估锁定：模型产物格式（SageMaker 用自家模型包）、扩缩容 API、监控集成。给一个判断标准：如果一年后要迁去另一个云，你的迁移预算是几周人时？ 超过 2 周就要认真考虑平台中立方案（如 KServe）。

五、推荐矩阵：场景 → 方案 ​

把 5 个问题的答案组合成典型场景，直接查表：

场景推荐方案理由备选
快速上线小模型、团队 2-3 人BentoML 或 FastAPI + Docker上手快、够用、无运维负担云平台托管端点
极致性能、多模型共享 GPUTriton动态批处理 + 多框架后端，吞吐上限最高自建 + Triton 后端
LLM 服务vLLM（或托管平台）连续批处理/PagedAttention 是 LLM 吞吐的关键，见 vLLM 案例火山方舟/云端 LLM API
团队无运维、业务在单一云云托管平台（SageMaker/Vertex 等）扩缩容、SLO、监控全托管国内：火山方舟/阿里云 PAI
已有 K8s、要平台化与灰度KServeServerless 扩缩 + 原生灰度Seldon Core
批处理/离线推理云批处理（如 SageMaker Batch / 自建 Pipeline）按需算力、无常驻成本，见 批处理流水线案例自建 Celery/Argo
无状态、突刺型流量Serverless 推理零常驻、冷启动换成本弹性，见 Serverless 推理云平台 Serverless 端点
多模型路由 + A/B 灰度网关 + 框架（如 网关灰度）路由、分流、观测统一在网关层平台内建流量分割

六、迁移成本与锁定问题 ​

选型不只是「当下好用」，要算三年成本。锁定（lock-in）的三个层次：

  1. 框架锁定：代码依赖 Triton 的 Python backend 或 BentoML 的打包格式 → 迁移成本是重写推理类；
  2. 平台锁定：用 SageMaker 的 pipeline API、Vertex 的端点编排 → 迁移是整体重构；
  3. 数据/监控锁定：指标进了平台自己的监控、日志进了云原生存储 → 迁出时历史可观测性丢失。

缓解锁定的通用策略：

  • 让推理类成为唯一依赖点：服务代码只依赖自己封装的 inference.py（见 从零部署一个模型），换引擎换平台只改一个文件；
  • 优先标准格式：模型导出 ONNX（模型格式），ONNX 是跨引擎、跨平台最通用的中间格式；
  • 监控用 Prometheus 系：Prometheus 格式是事实标准，几乎所有平台都支持导出，迁平台不丢指标。

七、决策流程：一棵决策树 ​

text
开始
│
├─ 模型是 LLM？ ──yes──▶ 延迟敏感 & 要自控? ──yes──▶ vLLM + (KServe/自建)
│   │                     │                            └─no──▶ 托管 LLM 平台（方舟/云 API）
│   └─no
│
├─ 延迟要求 P99 < 20ms? ──yes──▶ GPU + 引擎（Triton/TensorRT），见 TensorRT 案例
│
├─ 团队有 K8s 运维能力? ──yes──▶ 多模型/平台化? ──yes──▶ KServe / Seldon
│   │                             └─no──▶ 单模型 → BentoML / TorchServe
│   └─no
│
├─ 有云环境? ──yes──▶ 用该云托管平台（SageMaker/Vertex/PAI/方舟）
│   └─no
│
└─ 自建 → FastAPI + Docker（参考 build-your-own 骨架）

决策树每条路径的「选它」标准，都可以用第 1 节的 5 个问题反推回去，保持决策可追溯。

权衡与取舍 ​

选型永远没有免费午餐，四个必然的取舍：控制力 ↔ 运维成本（自建最灵活但最累）；性能 ↔ 复杂度（Triton 的批处理收益需要用它的 API 换）；上手快 ↔ 上限低（FastAPI 起步快，高吞吐要重学引擎）；托管省事 ↔ 锁定风险。另外别忘了：选型不是一锤子。很多团队的正确路径是「FastAPI 起步 → 流量增长换 Triton → 规模化了上 KServe」，每一层升级都有明确的触发条件（P99 恶化、吞吐封顶、实例数失控）。把升级条件写进监控告警，比一次选到「终极方案」更实际。

检查清单 ​

  • [ ] 5 个问题（模型/延迟/团队/云/运维）逐一写下答案；
  • [ ] 对比表里标出符合你约束的候选（不超过 2 个）；
  • [ ] 用推荐矩阵确认方案，并写下「为什么不是备选」；
  • [ ] 评估过锁定成本（迁移人时数）；
  • [ ] 定了升级触发条件（什么指标恶化时换下一层）；
  • [ ] 模型格式标准（ONNX）与推理类封装已就位，保证可迁移。

延伸阅读 ​

参考资料 ​