单副本（基线方案）
使用场景: 部署首个模型端点的开发者
一个推理服务位于简单反向代理之后
启动时从仓库一次性加载模型
同步请求 → 预测 → 响应
无批处理；一次一个请求
基础健康检查和延迟日志
这样组织的原因: 单副本是最简单的服务配置——图表没有批处理队列或负载均衡，因为一个服务串行处理请求，低流量时没问题，但无法扩展或批处理。
真实案例
自动扩缩集群
使用场景: 服务可变生产流量的团队
负载均衡在 N 个副本间分发
批处理队列把请求分组以提升 GPU 吞吐
自动扩缩器根据队列深度增减副本
共享模型仓库；副本拉取同一版本
监控驱动自动扩缩信号
这样组织的原因: 自动扩缩集群是生产标准的服务模式——图表增加批处理队列和自动扩缩器，因为批处理最大化 GPU 效率，自动扩缩让副本数匹配负载。
多模型服务器
使用场景: 用一套机群服务多个模型的团队
一个服务框架托管多个模型（Triton、TorchServe）
网关按模型名路由到正确的后端
仓库保存所有模型版本；副本按需加载
按模型的批处理和版本管理
跨所有模型的共享监控
这样组织的原因: 多模型服务器把多个模型整合到共享基础设施上——图表在网关增加模型名路由，于是一套机群服务多个模型，而非每个模型一套部署。
LLM 服务
使用场景: 服务大语言模型的团队
连续批处理（in-flight）取代静态批处理
为进行中的生成做 KV-cache 管理
Token 流式返回客户端
大模型的副本跨 GPU 分片
专用服务器（vLLM、TGI）而非通用服务
这样组织的原因: LLM 服务用连续批处理取代静态批处理，并增加 KV-cache 和流式——图表反映生成是逐 token 的，于是服务层必须管理进行中的序列，而非离散的请求-响应对。
使用技巧
- 把批处理队列作为集群内的独立组件画出来——批处理是 GPU 服务高效的关键，在图里很容易遗漏。
- 把模型仓库画成已部署模型的来源，让版本管理和回滚可见。
- 把缓存放在网关路径上、推理之前，让缓存命中完全避开模型这点清晰可见。
- 把监控显式连到集群；延迟和错误信号常驱动自动扩缩和回滚。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=model-serving-architecture
编辑此模型服务模板