外观
模型服务化与编排
把一个能跑通的模型，变成一个能扛流量、可观测、可回滚的线上服务，中间隔着整套工程。这就是模型服务化（model serving）——本站什么是推理加速讲"怎么让模型跑得快"，本文讲"怎么让模型稳稳地对外提供"。它是批处理与请求调度（怎么把请求塞进 batch）的上层、部署设计原则的落地、Triton 推理服务与vLLM这些引擎案例的"外壳"。
本文定位
本文不是某个具体框架的使用教程，而是建立"推理服务长什么样"的心智模型。读完你能回答：服务分几层、各层管什么、选什么框架、怎么监控、怎么伸缩。具体框架实操见对应案例研究，落地原则见部署设计原则。
概念定义：模型服务化的五个诉求
一个生产级推理服务要同时满足五件事，缺一不可：
| 诉求 | 含义 | 不做会怎样 |
|---|---|---|
| 可用性 | 服务不挂、挂了能快速恢复 | 单点故障，一次 OOM 全站宕机 |
| 可伸缩 | 流量涨能加卡、流量落能省钱 | 白天扛不住、晚上烧钱 |
| 可观测 | 知道延迟、吞吐、错误率、GPU 利用率 | 黑盒运营，出问题靠猜 |
| 可演进 | 模型能热更新、灰度发布、回滚 | 发版停服、回滚靠重启 |
| 成本可控 | 单 token 成本可量化、可优化 | GPU 利用率 < 30%、账单失控 |
这五件事是服务化与"裸跑模型脚本"的根本区别。裸脚本能验证"模型行不行"，服务化验证"系统能不能上线"。详见部署设计原则。
一、推理服务的架构分层
一个成熟的推理服务通常分五层，从外到内：
text
┌──────────────────────────────────────────────────┐
│ ① API Gateway / 接入层 │ ← 鉴权、限流、路由
├──────────────────────────────────────────────────┤
│ ② Load Balancer / 调度层 │ ← 请求分发、负载均衡
├──────────────────────────────────────────────────┤
│ ③ Inference Engine / 推理引擎层 │ ← vLLM、TensorRT-LLM、TGI
├──────────────────────────────────────────────────┤
│ ④ Model Repository / 模型仓库层 │ ← 版本化、热加载
├──────────────────────────────────────────────────┤
│ ⑤ Hardware / 硬件层 │ ← GPU/CPU/NPU + 监控
└──────────────────────────────────────────────────┘① API Gateway（接入层）
对外暴露 HTTP/gRPC 接口，负责鉴权（API key / OAuth）、限流（令牌桶 / 漏桶）、路由（按模型名 / 租户分流）。LLM 场景还要处理流式响应（SSE / WebSocket）与长连接超时——生成 2000 token 可能要几十秒，传统网关默认 30s 超时会截断。
② Load Balancer（调度层）
把请求分发到后端推理实例。常见策略：
| 策略 | 做法 | 适用 |
|---|---|---|
| 轮询 | 依次分发 | 实例同质、请求同质 |
| 最少连接 | 发给当前并发最低的 | LLM 场景默认（请求耗时不一） |
| 一致性哈希 | 相同 prompt 路由到同一实例 | 配合prefix caching |
| 按模型路由 | 不同模型到不同实例池 | 多模型服务 |
LLM 推理的负载均衡难点：请求耗时长且差异大（短 prompt 0.5s、长 prompt 10s），简单轮询会让某实例堆积长请求。最少连接 + 健康检查是事实标准。
③ Inference Engine（推理引擎层）
真正跑模型的一层，本站的核心。主流引擎见推理引擎选型对比：
- vLLM：开源社区最大，PagedAttention + continuous batching；
- TensorRT-LLM：NVIDIA 官方，FP8 + in-flight batching；
- TGI：HuggingFace 出品，与 Transformers 生态贴近；
- Triton Inference Server：NVIDIA 多后端服务框架，统一管理多种引擎。
引擎层内部的批处理与调度详见批处理与请求调度，性能指标定义详见延迟、吞吐与并发。
④ Model Repository（模型仓库层）
管理模型文件的版本化、存储与热加载。要求：
- 版本化：每次发版有唯一版本号，可回滚；
- 热加载：不停服加载新模型（Triton 的
--model-control=explicit+ poll）； - A/B 与灰度：同时跑两个版本按比例分流；
- 存储格式：LLM 常用 SafeTensors / GGUF / TensorRT Plan，详见vLLM与llama.cpp。
工具上，MLflow Model Registry 是开源事实标准，配合对象存储（S3/OSS）做模型仓库。
⑤ Hardware（硬件层）
GPU/CPU/NPU，及配套的驱动、CUDA、NCCL。硬件选型见硬件基础速查，硬件上的实测数据见基准数据与工具档案。这层的监控（GPU 利用率、显存、温度）是上层调度决策的依据。
二、部署形态
推理服务有四种典型部署形态，适用场景与成本结构完全不同。
单机单卡
最简单：一个进程 + 一张卡 + 一个模型。适合原型验证与小流量内部服务。瓶颈是单卡显存与算力——70B 模型 FP16 放不下，必须量化或升级硬件。
单机多卡（TP）
一张机器多张卡，张量并行把单层权重切到多卡。要求 NVLink 互联（详见硬件基础速查），适合 70B+ 模型单机推理。8×H100 SXM 是常见配置。
多机多卡（PP / DP）
- 流水线并行（PP）：模型按层切到多机，通信少但有气泡，适合超大模型（405B）；
- 数据并行（DP）：多机各跑完整模型副本，前加负载均衡，适合扩吞吐（流量大时加副本）。
详见分布式推理（TP/PP）。
Serverless / 边缘
- Serverless：按请求冷启动实例，适合突发流量或低频调用。LLM 冷启动慢（模型加载几分钟），需配合预热与模型缓存；
- 边缘部署：手机/车机/IoT，必须 INT4 量化 + 小模型，详见移动端部署与llama.cpp。
LLM 不适合裸 Serverless
LLM 模型动辄几十 GB，冷启动加载到显存要几十秒到几分钟，远超传统服务的毫秒级。常见折中：常驻实例 + 自动伸缩（保底几实例不关，流量涨时扩），而非纯按请求冷启动。详见部署设计原则。
三、主流服务框架对比
不同框架定位不同，不是"谁取代谁"。
| 框架 | 定位 | 强项 | 适合 |
|---|---|---|---|
| Triton Inference Server | 多后端服务框架 | 统一管理 TensorRT/PyTorch/ONNX 多模型，动态 batching | 多模型/多引擎统一服务 |
| vLLM server | LLM 专用引擎+服务 | PagedAttention、continuous batching、OpenAI 兼容 API | 单一 LLM 高吞吐服务 |
| TGI | HF 官方 LLM 服务 | 与 Transformers/Hub 深度集成 | HF 生态用户 |
| SGLang | 结构化生成框架 | RadixAttention 前缀缓存、JSON/工具调用 | 结构化输出、多轮对话 |
| Ray Serve | 通用 ML 服务框架 | 弹性伸缩、多模型流水线、Python 原生 | 复杂编排、多模型 pipeline |
| BentoML | ML 模型打包部署 | 模型打包成可移植 image | 跨环境部署 |
选框架的三条经验
- 单一 LLM 服务：直接 vLLM 或 TensorRT-LLM，自带 HTTP 服务与 continuous batching；
- 多模型/多引擎统一：上 Triton，把 vLLM/TensorRT 作为 backend 接入；
- 复杂编排（多模型 pipeline、RAG）：Ray Serve 或 BentoML 做上层编排，下层调 vLLM/Triton。 不要一上来就上 Ray Serve——简单 LLM 服务用 vLLM 一行命令即可。详见推理引擎选型对比。
四、多模型路由与流量管理
线上服务常同时部署多个模型（不同规模、不同任务、不同版本），路由层决定"请求到哪个模型"。
路由策略
| 策略 | 做法 | 场景 |
|---|---|---|
| 按模型名 | 请求带 model=llama-3-70b 路由 | 多模型并存（OpenAI 兼容 API） |
| 按任务 | 分类→小模型，生成→大模型 | 任务异构 |
| 按租户 | VIP 客户走大模型，免费走小模型 | 多租户 SLA |
| 按成本 | 简单请求走小模型，复杂走大模型 | 成本优化 |
| A/B 灰度 | 5% 流量到新版本 | 模型发版 |
| 级联 | 小模型先答，不确定再升级大模型 | 级联推理降本 |
级联推理（cascade inference）
成本优化的高级玩法：先用小模型（8B）生成，用置信度判断；不确定的请求升级到大模型（70B）重答。整体成本可降到原来的 20–30%，质量接近全用大模型。详见调参与性能调优。
五、弹性伸缩与容量规划
弹性伸缩的核心是"按负载增减推理实例"。LLM 服务的伸缩比传统服务难——单个实例加载模型慢、显存大、启动后还需预热。
伸缩指标
| 指标 | 含义 | 伸缩触发 |
|---|---|---|
| QPS | 每秒请求数 | 超阈值扩容 |
| 并发数 | 当前在途请求 | 超单实例上限扩容 |
| GPU 利用率 | 算力使用比例 | > 80% 扩，< 30% 缩 |
| P99 延迟 | 尾部延迟 | 超过 SLA 扩容 |
| KV cache 占用 | 显存压力 | 接近上限扩容 |
容量规划：从 Little's Law 推导
根据Little's Law（并发 = 吞吐 × 延迟），给定业务目标即可反推硬件需求：
text
目标：1000 QPS，P99 延迟 < 2s
→ 最大并发 = 1000 × 2 = 2000
→ 单 H100 能撑 ~200 并发（Llama-3-70B INT4）
→ 需要 2000 / 200 = 10 张 H100
→ 加 30% 冗余 = 13 张单卡并发数要通过基准测试实测，不能拍脑袋。详见延迟、吞吐与并发与基准数据与工具档案。
LLM 伸缩的三个坑
- 冷启动慢：实例拉起到能服务要几十秒到几分钟（模型加载+预热），不能像 web 服务那样秒级伸缩——要提前伸缩（基于 QPS 趋势预测）；
- 缩容别太激进：在途请求要等完，直接 kill 会丢请求——设 grace period；
- 显存碎片：长期运行后 KV cache 碎片化，吞吐下降——定期重启实例（如每 24h）。 详见常见陷阱与反模式。
六、监控指标与可观测性
"没有监控的服务等于黑盒"——LLM 推理服务的监控比传统服务更复杂，因为要同时看业务、引擎、硬件三层。
三层监控
| 层级 | 指标 | 工具 |
|---|---|---|
| 业务 | QPS、P50/P95/P99 延迟、错误率、token 吞吐 | Prometheus + Grafana |
| 引擎 | batch 大小、KV cache 命中率、queue 长度、prefix cache 命中 | vLLM metrics / Triton metrics |
| 硬件 | GPU 利用率、显存占用、温度、功耗 | DCGM Exporter |
关键指标详解
- P50/P95/P99 延迟：必须分 TTFT 与 TPOT 看——TTFT 反映 prefill，TPOT 反映 decode，瓶颈完全不同。只看平均会被长尾掩盖。详见延迟、吞吐与并发。
- GPU 利用率：注意区分"SM 利用率"与"Tensor Core 利用率"——前者高不代表后者高，可能在做访存。配合 Nsight Systems 看时间线。
- KV cache 命中率：prefix caching 的命中率，直接决定多租户场景的 TTFT。低于 20% 说明 prompt 没复用价值或缓存策略有问题。
- queue 长度：请求在引擎内排队数——持续 > 0 说明已饱和，该扩容了。
监控的黄金信号
四个信号必看：延迟（latency）、流量（traffic）、错误（errors）、饱和度（saturation）——Google SRE 的"四个黄金信号"在 LLM 推理上同样适用。任一信号异常都该触发告警，详见部署设计原则。
七、MLOps 闭环：从部署到再训练
模型服务化不是终点，而是闭环的一环。完整的 MLOps 循环：
text
训练 → 评估 → 部署 → 监控 → 收集线上数据 → 再训练
↑ │
└─────────────────────────┘线上推理阶段要为闭环贡献两件事：
- 数据飞轮：记录用户真实输入与模型输出（脱敏后），筛高价值样本回流训练集，详见部署设计原则；
- 漂移检测：监控输入分布（prompt 长度、话题）与输出分布（token 数、拒绝率）的变化，触发再训练。术语见术语表。
LLM 场景的漂移更隐蔽——用户提问风格随时间变化（新话题、新指令），模型不会"报错"只会"答得不好"。需要定期用基准测试在固定评测集上回归。
八、权衡与取舍
- 延迟 vs 成本：小 batch 低延迟但 GPU 利用率低、成本高；大 batch 高吞吐但延迟高——交互式重延迟，批处理重吞吐；
- 单机 vs 分布式：单机简单但上限低；分布式能扩但要 NVLink 与调度开销，详见分布式推理；
- 自建 vs 托管：自建灵活但运维重；托管（各云厂商 LLM 推理服务）省心但贵且锁定，详见部署设计原则；
- 精度 vs 容量：FP8/INT4 量化腾出显存可多放并发，但精度损失要监控质量回归。
延伸阅读
- 批处理与请求调度——引擎层怎么把请求塞进 batch
- 延迟、吞吐与并发——服务化要监控的核心指标
- 显存层次与带宽墙——容量规划的硬约束
- Triton 推理服务——多后端服务框架案例
- vLLM 与 PagedAttention——LLM 引擎内置服务
- 分布式推理（TP/PP）——多机多卡部署
- 部署设计原则——服务化的设计原则
- 推理引擎选型对比——框架选型
- 推理基准测试实践——容量规划靠实测
- 常见陷阱与反模式——服务化的常见翻车
- 硬件基础速查——硬件层参数
- 基准数据与工具档案——实测容量数据
- 术语表——本文术语定义
参考资料
- Triton Inference Server 官方文档——多后端推理服务框架
- vLLM 官方文档——LLM 推理引擎与服务
- Ray Serve 文档——通用 ML 服务编排框架
- Google SRE Book——四个黄金信号——监控的黄金信号方法论
- MLflow Model Registry——模型版本化与注册中心