部署架构模式

一句话定义：部署架构模式是"在什么时机、以什么方式、在什么位置运行模型推理"的五种基本形态——在线、批处理、流式、边缘、Serverless，各有各的延迟、成本与运维特征。

行业洞察：选错部署模式是部署工程里最贵的错误，且难以事后弥补。把日活百万的推荐流量做成批处理，用户画像滞后一天，业务直接崩；把每天只跑一次的日报打分挂成常驻 GPU 服务，一年烧掉一台 A100 的钱。业界经验是：先用一句话描述你的流量模式与延迟要求，再对号入座选模式——模式定对了，后面所有优化都是在正确的骨架上加固。

一、五种模式一览

模式	触发方式	延迟	吞吐	成本形态	典型场景	代表工具
在线推理	请求实时	毫秒级	高（并发）	常驻资源	推荐、搜索、对话、风控	FastAPI、Triton、vLLM
批处理	定时/手动	小时级	极高	按量结算	画像、日报、离线评估	Airflow + Spark/PyTorch
流式推理	事件驱动	秒级	持续	常驻（可伸缩）	实时风控、实时个性化	Kafka + Flink
边缘部署	端侧触发	本地毫秒	低	一次性硬件	离线可用、隐私敏感	TensorRT、TFLite
Serverless	请求实时	冷启动秒级	弹性	按调用计费	低频、突发、内部工具	KServe、AWS Lambda

二、逐一展开

1. 在线推理：实时 API

特征：请求-响应同步、毫秒级延迟预算、常驻服务保并发。适合延迟敏感、流量稳定且量大的场景（推荐、风控、对话）。

客户端 ──► 网关 ──► 推理服务(常驻多副本) ──► GPU/CPU
                        ▲ 动态 batching / 结果缓存

成本特征：即使夜里流量趋零，副本也常驻（除非配弹性伸缩）。优化重点是 性能优化与容量规划 与 服务化与推理 API。

2. 批处理：定时离线打分

特征：定时任务、全量数据、小时级容忍、不占在线资源。适合画像、日报、实验离线评估。

Airflow 定时触发 ──► Spark/DataFrame 读取千万级样本
                       ──► 模型批量前向（大 batch，GPU 打满）
                       ──► 结果写回数仓/特征表

关键点：大 batch 是批处理性能的核心——GPU 利用率轻松到 90%+，是五种模式里单位成本最低的。批处理与在线共用一个模型时，注意"特征口径一致"，详见 批处理推理管道。

3. 流式推理：事件驱动

特征：事件流逐条处理、秒级延迟、处理不完不阻塞（背压与 checkpoint）。适合实时风控、实时个性化、IoT 告警。

Kafka 事件流 ──► Flink 算子（含模型推理 UDF）
                  ──► 决策/告警 ──► 结果写回 Kafka/DB

与在线推理的区别：流式是数据来找你（push），延迟要求宽松（秒级而非毫秒），但要求状态一致性与精确一次（exactly-once）语义。模型推理在 Flink 里做成 UDF，通常配合小模型（避免单条延迟过高）。

4. 边缘部署：端侧推理

特征：模型跑在用户设备或现场设备上，无网也能用、数据不出端。适合离线工具、隐私敏感、车载/工业现场。代表做法见 TensorRT 与边缘部署。

手机/车载/工控机
 ├─ TFLite / Core ML / TensorRT / 边缘 NPU
 └─ 本地推理 → 本地结果；可选回传匿名样本做联邦学习

代价：硬件碎片化（每款设备都要验证算子兼容）、无法热更新模型（只能随 App/固件发版）、算力有限（必须小模型+量化）。换来的是零网络延迟与强隐私。

5. Serverless：按调用计费

特征：平台自动伸缩、按调用次数/时长计费、冷启动代价。适合低频、突发、内部工具、实验性服务。实战见 Serverless 推理。

请求 ──► KServe/网关 ──► 从 0 扩到 1（冷启动：拉镜像+加载模型，秒~十秒级）
                       ──► 空闲后缩回 0

冷启动是 Serverless 的头号敌人

模型加载 30 秒的 7B 模型放 Serverless，首请求可能等 40 秒。缓解：预热实例（最小实例数=1）、模型放共享缓存盘、或者干脆不用 Serverless。"Serverless 只适合可秒级加载的小模型"是经验法则。

三、选型决策树

先问：延迟要求是什么？
 ├─ 毫秒级、用户可感知（推荐/对话/风控）        → 在线推理
 ├─ 秒级、事件驱动                             → 流式推理
 ├─ 分钟~小时级、全量数据                      → 批处理
 └─ 无网环境 / 强隐私 / 设备端                   → 边缘部署

再问：流量模式是什么？
 ├─ 稳定且量大 → 常驻在线 + 弹性伸缩
 ├─ 低频 / 突发 / 不稳定 → Serverless（模型小）或 Serverless + 预热
 └─ 白天在线 + 夜间全量 → 混合部署（见下）

再问：数据在哪里？
 ├─ 数据在数据中心 → 云上推理
 ├─ 数据在用户设备（隐私） → 边缘推理
 └─ 数据在流式管道 → 流式推理

决策权重排序

延迟要求 > 流量模式 > 成本约束 > 数据位置

延迟要求先于一切：能忍受小时级，永远别考虑在线服务；必须毫秒级，就老老实实掏常驻 GPU 的钱。

四、混合部署：在线 + 批处理组合

真实系统几乎都是混合的。经典组合：

白天：在线推理（低 batch、低延迟）为实时业务服务
夜间：同一批 GPU 切换成批处理任务（画像、模型重估、离线实验）
              或者：在线服务弹性缩容，批处理扩容

收益：一套 GPU 资源 24 小时不闲置——白天给在线、夜里给批处理，综合利用率翻倍。工程前提：

1. 在线与批处理用同一套部署单元（K8s + 伸缩策略切换）；
2. 模型文件、特征口径统一（见 MLOps 部署流水线）；
3. 批处理任务优先级低于在线，突发时可抢占。

五、成本模型对比

模式	固定成本	可变成本	闲置浪费风险
在线推理	高（常驻 GPU/CPU）	低	高（夜间空闲）
批处理	低	按运行时长	低（用完即释放）
流式推理	中（常驻流处理集群）	中	中
边缘部署	一次性硬件	维护	低
Serverless	低	按调用	极低（空闲归零）

一个直观算例：每天 1 万次调用、单次推理 50ms、模型可塞进 T4（约 1 元/时按需）：

• 在线常驻：24×1 ≈ 24 元/天，利用率实际 <2%；
• Serverless（按调用）：1 万 × 50ms ≈ 500 秒 ≈ 0.14 元/天，差 170 倍。

但若调用涨到每天 1000 万次，Serverless 的按调用费用会超过常驻包月——这就是"模式随规模迁移"的现实。

权衡与取舍

决策点	选项	怎么选
实时性	在线/流式 vs 批处理	延迟要求说了算
成本	常驻 vs Serverless	低频突发 Serverless；稳定大流量常驻
数据位置	云 vs 端	隐私与离线需求优先
运维复杂度	常驻 vs Serverless vs 批处理	越托管越省心，但可定制性越差
资源利用	单一模式 vs 混合	利用率优先选混合

一句话总结：模式是部署的第一决策——先按延迟、流量、成本、数据位置四步对号入座，再把多模式组合起来把资源用满。

延伸阅读

• 服务化与推理 API —— 在线模式的服务工程基础
• 批处理推理管道 —— 批处理落地的完整案例
• Serverless 推理 —— 冷启动与弹性伸缩实战
• TensorRT 与边缘部署 —— 边缘模式的编译与部署
• 性能优化与容量规划 —— 在线模式的压测与容量核算

参考资料

• Kubernetes 官方文档：Deployment 与伸缩
• Apache Airflow 官方文档
• Apache Flink 官方文档
• KServe：Kubernetes 上的 Serverless 推理
• AWS Lambda 文档（Serverless 参考）