第 15 章 模型服务基础

学习目标

• 厘清 Serving、Inference、Scoring 的概念边界；
• 掌握同步、异步、流式、批处理四种服务模式；
• 理解 REST、gRPC、WebSocket、消息队列的选型；
• 理解在线、离线、近线推理的定位；
• 理解多模型服务、多版本服务与模型路由。

---

15.1 Serving、Inference、Scoring 是什么

三个词经常混用，工程上要分清：

• Inference（推理）：模型计算本身——输入到输出的计算过程（第 14 章优化的是它）；
• Scoring（打分）：特指输出数值分数（概率、相似度）的推理——传统 ML 风控/推荐常用词；
• Serving（服务）：把模型推理包装成可被其他系统调用的服务——含网络协议、并发、生命周期、可观测性。Serving 是「模型 + 推理 + 工程外壳」的统称。

模型推理（算得快）→ 模型服务（对外稳定可用）→ 模型平台（多模型/多租户/治理）

第 14 章解决了「算得快」，本章到第 17 章解决「对外稳定可用」。

15.2 四种服务模式

模式	请求-响应	适用	特点
同步（在线）	立即返回	对话、搜索、交互	延迟敏感
异步	提交后轮询/回调	批量打标、长任务	吞吐优先、可排队
流式（Streaming）	边生成边返回	LLM 对话、字幕	首 token 快、体验好
批处理（Batch）	成批处理	离线评估、数据标注	成本最低

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart TD
    A[请求] --> B{模式选择}
    B -->|交互式| C[同步在线
低延迟]
    B -->|生成式| D[流式
SSE/WS]
    B -->|量大不实时| E[异步队列
任务+回调]
    B -->|离线批量| F[批处理
吞吐最大化]

流式是 LLM 服务的默认形态：用户看到 token 一个个蹦出来，首 token 延迟低（几百 ms）让体验接近「即时」，总输出再长也不焦虑。SSE（Server-Sent Events）是流式的最简实现（单向文本流），WebSocket 用于双向交互。

15.3 传输协议：REST、gRPC、WebSocket、消息队列

协议	模式	优势	劣势	场景
REST/HTTP	同步、SSE 流式	通用、调试易、生态最广	开销大、无强类型	对外 API 默认
gRPC	同步/流式	高性能、强类型、双向流	生态偏服务端	内部服务间默认
WebSocket	双向长连接	实时交互	状态管理、运维复杂	实时对话/Agent
消息队列	异步	削峰、解耦、可重试	端到端延迟	离线/异步任务

工程共识：对外统一 REST（兼容性第一），对内 gRPC（性能与类型安全），实时交互补 WebSocket，离线批量走消息队列。REST 与 gRPC 混用的网关层（第 16 章）是常见架构。

15.4 在线、离线、近线推理

第 2 章按部署形态讲过在线/离线/流式/端侧，这里从服务架构角度补充「近线（Nearline）」：

类型	延迟	触发	典型架构	例子
在线	ms-秒	用户请求	网关 → 推理集群	对话、搜索
近线	秒-分钟	事件/周期触发	队列 + 处理集群	推荐预计算、异步审核
离线	分钟-小时	批量调度	批处理集群	数据标注、评测、全量打标

近线是「吞吐与时效的折中」：比在线便宜（可排队、可批量）、比离线及时（分钟级可见）。LLM 应用里典型如：内容审核（先在线粗筛、近线精审）、推荐重排（近线预热候选）。

15.5 多模型服务、多版本服务、模型路由

生产平台几乎不会只服务一个模型，于是有：

• 多模型（Multi-Model）：不同任务用不同模型（意图分类小模型 + 生成大模型 + 检索模型）。挑战：异构负载共享资源、模型间隔离（第 17 章多租户）。
• 多版本（Multi-Version）：同一模型的新旧版本并存，供灰度与回滚（第 16 章）。
• 模型路由（Model Routing）：请求按规则/能力路由到合适的模型——这是 LLM 应用的关键架构件：

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[请求] --> B[路由层]
    B -->|简单任务| C[小模型
快/便宜]
    B -->|复杂任务| D[大模型
强/贵]
    B -->|特定领域| E[领域微调模型]
    B -->|兜底| F[旗舰模型]

路由的价值：用「把简单任务发给便宜模型」换成本大幅下降（第 17 章的 Token 成本优化）。路由策略从静态规则（关键词、长度）到动态（基于模型不确定度、基于成本预算）演进。

---

本章要点回顾

1. Serving = 推理 + 工程外壳；Scoring 特指输出分数的推理。
2. 四种模式按延迟/吞吐权衡选：同步、流式、异步、批处理；LLM 默认流式。
3. 协议选型：对外 REST、对内 gRPC、实时 WebSocket、离线消息队列。
4. 在线/近线/离线三档，近线是吞吐与时效的折中。
5. 多模型、多版本、模型路由是平台级服务的基本结构；路由用「简单任务走便宜模型」省成本。

习题

1. 你的 LLM 服务要支持流式输出，选 SSE 还是 WebSocket？列出判断依据。
2. 内容审核场景，设计在线粗筛 + 近线精审 + 离线回扫的三级架构，各用什么模式与协议。
3. 模型路由的「简单任务」怎么判定？给出三种可落地的路由特征。
4. gRPC 与 REST 在什么情况下该混用？画出网关层的混用架构。

延伸阅读

• Triton Inference Server 官方文档
• KServe 官方文档
• vLLM 的 OpenAI 兼容 API 文档
• Nginx/gRPC/WebSocket 协议对比资料

下一章预告

第 16 章服务架构：模型服务器（Triton/TorchServe/KServe/Ray Serve/Seldon）、API 网关、负载均衡、限流鉴权、自动扩缩容（HPA/KEDA）、灰度蓝绿金丝雀与 A/B 测试。