第十二章模型服务系统¶

导读¶

把一个能跑的推理引擎变成"生产可用"的服务系统，要解决：负载均衡、模型路由、弹性伸缩、A/B 灰度、监控告警、多租户隔离、计费配额等。本章从工程师视角讲这些"模型之外"的工程问题。

12.1 服务架构全景¶

LLM生产服务架构

一个典型 LLM 生产服务架构：

客户端 SDK
   ↓
API Gateway（鉴权 / 限流 / 计费 / 日志）
   ↓
Model Router（按模型 / SLA / 成本分流）
   ↓
Worker Pool A: Llama-3-8B (4 GPU, vLLM)
Worker Pool B: Llama-3-70B (8 GPU, vLLM)
Worker Pool C: GPT-4 API fallback
   ↓
缓存层：KV Cache / Prompt Cache
监控层：Prometheus / Grafana
伸缩层：KEDA / K8s HPA

12.2 API Gateway 层¶

承担**所有跨模型通用**的功能：

鉴权：API key、JWT、OAuth；
限流：rate limit（QPS / tokens per minute）；
配额：日 / 月 token 限额；
计费：按 input + output token 分别计；
日志：请求 / 响应（注意隐私脱敏）；
追踪：OpenTelemetry trace；
多协议：REST / gRPC / WebSocket / SSE。

技术选型：

Kong / APISIX：通用 API gateway；
Envoy + Istio：service mesh 路线；
LiteLLM：LLM 专用 proxy，支持多模型 + 成本路由；
OpenAI 兼容 API：vLLM、SGLang 都内置，对上层零改动。

12.3 Model Router¶

按规则分流请求到不同 worker pool：

def route(request):
    if request.model == "llama-3-70b":
        return worker_pool_B
    elif request.sla == "low_latency":
        return worker_pool_A   # 8B 更快
    elif request.cost_priority:
        return worker_pool_A   # 更便宜
    elif request.feature == "long_context":
        return worker_pool_B   # 70B 长上下文好
    else:
        return worker_pool_C   # GPT-4 fallback

路由维度：

模型 ID；
SLA（延迟 / 吞吐）；
成本；
上下文长度；
多租户；
流式 / 非流式；
功能（function call、JSON 输出）。

路由策略：

静态规则：简单、可预测；
加权随机：A/B 测试；
延迟感知：路由到当前最快的 pool；
成本感知：在 SLA 范围内选最便宜的。

12.4 Worker Pool 与负载均衡¶

每个 worker pool 内部多个 replica，需负载均衡：

算法	说明
Round robin	简单轮询
Least connections	选当前最闲的
Least response time	选历史最快
Hash by session	同会话保持同卡（用 KV Cache）
Power-of-2-choices	随机选 2 个再选较闲的，比 least-conn 更鲁棒

LLM 特殊考量：

会话亲和（session affinity）：同会话尽量路由到同卡，复用 KV Cache；
请求长度感知：长请求不要全堆一起，避免拖累短请求；
冷启动：权重加载秒级，避免打到刚启动的 worker。

12.5 弹性伸缩¶

LLM 服务伸缩难，因为：

GPU 资源稀缺：不能像 CPU 那样随时扩；
权重加载慢：70B 模型加载 1-2 分钟；
多 GPU 一致性：TP 切分时所有卡要一起就绪；
冷启动影响 SLA：扩容期间 P99 暴涨。

KEDA（Kubernetes Event-Driven Autoscaling）配合 K8s：

按队列长度（待处理请求）伸缩，而非 CPU；
预设 min/max replica；
cooldown 避免抖动。

预扩容策略：

业务高峰前主动扩（如工作时间开始前）；
大促 / 新功能上线前预留 buffer；
多区域部署，单区域故障转移。

12.6 多租户与隔离¶

LLM 服务的多租户挑战：

维度	隔离方式
数据	每租户独立 vector DB、独立 RAG 索引
模型	共享 base + LoRA per tenant（动态切换）
性能	配额 + 限流，避免单租户拖垮
安全	prompt 注入防护、输出审核
计费	按 token 精确计费

LoRA 多租户：base 模型加载一次，每租户 LoRA 权重小（<100MB），可在 worker 内动态切换：

vllm serve base-model --enable-lora --lora-modules \
    tenant-a=/lora/tenant-a \
    tenant-b=/lora/tenant-b

12.7 A/B 与灰度¶

发布新模型 / 新 prompt 时：

方式	用途
A/B test	5% 流量到新模型，比较留存 / 满意度
Canary	1% → 10% → 50% → 100% 渐进
Shadow	100% 流量复制到新模型，不影响用户
Champion/Challenger	当前冠军 vs 挑战者持续对比

评测指标：

业务 KPI（满意度、点击、转化）；
模型质量（人工评分 / 自动评分）；
系统指标（latency、error rate、cost）。

12.8 监控与告警¶

指标分层：

层	指标
业务	QPS、用户满意度、转化率、错误率
模型	输出质量、幻觉率、拒答率、token cost
服务	TTFT、TPOT、P50/P99、batch size、KV Cache 利用率
系统	GPU 利用率、显存利用率、网络带宽、温度
集群	节点健康、副本数、扩缩容事件

技术栈：

Prometheus + Grafana：标准指标；
OpenTelemetry：分布式 trace；
Loki / ELK：日志；
Lunary / Langfuse / Helicone：LLM 专用观测。

告警原则：

P99 latency > SLO 持续 5 分钟；
错误率 > 1%；
GPU 利用率 < 30% 持续 10 分钟（说明负载过低或故障）；
显存碎片 > 20%；
单租户配额耗尽前预警。

12.9 故障与容灾¶

故障	处理
GPU 损坏	自动剔除节点、转移流量
权重加载失败	回滚到上一版本
KV Cache OOM	减 batch、降 max_num_seqs
上游 API 限流	退避 + 重试 + fallback 模型
网络抖动	重试 + 超时
模型质量退化	shadow 模式提前发现

多区域部署：主-备或 active-active，单区域故障切换。

12.10 成本管理¶

LLM 服务成本结构：

GPU 租赁 / 折旧：占大头（60-80%）；
存储：权重 + KV Cache（5-10%）；
网络：跨区流量（5-10%）；
人力：运维 + 模型迭代（10-20%）。

降本手段：

手段	收益
量化（INT4/FP8）	2-4×
Speculative Decoding	1.5-3×
Prefix Cache	system prompt 场景 5-20×
高效 batching	2-3×
Spot instance	3-5×（但可能被回收）
多模型路由（小模型优先）	30-50%
LoRA 多租户共享 base	多租户场景 5-10×

12.11 部署形态¶

形态	适合
本地 GPU 集群	大规模、长期
云 GPU（按需）	中等规模、突发
Spot instance	容错任务、训练
专用 AI 云（CoreWeave、Lambda）	大规模、成本敏感
API 转售	早期、规模小

工程实战要点¶

API gateway 与推理引擎分离：可独立演进；
session affinity 大幅降本：复用 KV Cache；
冷启动是大敌：扩容期 P99 暴涨，需预热；
LoRA 多租户是性价比路线：单 base + 多 LoRA；
监控分层：业务 / 模型 / 服务 / 系统 / 集群；
shadow 模式发现质量退化：100% 复制，不影响用户；
Spot instance 用于训练：推理慎用（被回收影响 SLA）；
成本是工程问题：每个杠杆都值得量化。

小结¶

LLM 服务架构 = gateway + router + worker pool + cache + 监控 + 伸缩；
API gateway 承担通用功能（鉴权 / 限流 / 计费）；
Model router 按模型 / SLA / 成本分流；
Worker pool 内负载均衡要考虑会话亲和（KV Cache 复用）；
弹性伸缩难：GPU 稀缺 + 权重加载慢；
LoRA 多租户：单 base + 多 LoRA 动态切换；
A/B / canary / shadow 是模型发布标准做法；
监控分 5 层：业务 / 模型 / 服务 / 系统 / 集群；
成本杠杆多：量化 / speculative / prefix cache / 路由 / LoRA 多租户。

练习题¶

API gateway 与 model router 各承担什么职责？
为什么 LLM 服务推荐使用 session affinity？
一个 70B 模型部署在 K8s，弹性伸缩面临哪些挑战？
LoRA 多租户方案如何降本？
shadow 模式相对 A/B test 的优势是什么？
列出 LLM 服务监控的 5 个层次及代表指标。
一个 LLM 服务 P99 突然飙到 5s，可能原因是什么？怎么定位？
列出至少 4 种 LLM 服务降本手段并量化收益。

下一章：第十三章 Agent与工具调用

第十二章 模型服务系统¶

导读¶