LLM Serving as Operations Research
在线 Notebook
对应的交互式版本可在 Google Colab 打开，统一使用方式见 第0章说明。
第 8 章主线讨论量化、推理优化、成本控制和生产系统。更深一层看，LLM Serving 可以借用运筹学视角来分析：在有限 GPU、显存、带宽、预算和 SLO 约束下，决定请求如何排队、批处理、路由、缓存和降级。
这一节不把运筹学展开成完整课程，只保留对 LLM 工程有直接帮助的建模视角。
为什么需要运筹学视角
一个线上 LLM 服务通常同时面对这些目标：
- 降低 P95 / P99 延迟
- 提高 GPU 利用率
- 控制 token 成本和峰值预算
- 保证关键业务请求的成功率
- 在流量突增时稳定降级，而不是整体雪崩
这些目标经常互相冲突。比如更大的 batch 可以提高吞吐，但会增加单个请求等待时间；更便宜的小模型可以降低成本，但会提高失败率或人工接管率；更长上下文可以提高回答质量，但会增加 KV cache 显存压力。
因此，第 8 章的工程问题可以写成一句话：
在质量、成本、延迟和可靠性约束下，寻找可上线的资源分配策略。
请求排队：延迟不只来自模型计算
LLM 请求的总延迟通常可以拆成：
总延迟 = 排队等待 + Prefill 计算 + Decode 生成 + 网络与后处理很多系统只关注模型单次推理速度，却忽略排队等待。真实线上服务中，当请求到达率接近服务能力时，排队延迟会快速上升。
工程判断：
- 低流量时，单请求延迟主要由模型和输出长度决定。
- 高流量时，排队等待可能成为主要瓶颈。
- P99 延迟比平均延迟更能反映容量是否不足。
- 如果没有限流和优先级，低价值请求会挤占高价值请求的资源。
批处理调度：吞吐和延迟的交换
批处理的目标是提高 GPU 利用率。它的代价是请求需要等待合批。
| 策略 | 收益 | 代价 |
|---|---|---|
| 固定 batch | 实现简单 | 流量波动时等待时间不稳定 |
| 动态 batch | 提高吞吐 | 调度复杂，延迟更难预测 |
| 连续批处理 | 更适合 token-by-token decode | 对 serving 框架要求更高 |
| 优先级队列 | 保护高价值请求 | 需要明确业务优先级 |
没有一种调度策略总是最好。低延迟交互场景通常要限制最大等待时间；离线批量处理可以接受更大 batch；多租户服务需要优先级和配额，否则容易互相干扰。
路由：把请求分给合适的模型
模型路由是第 8 章成本优化的核心。可以把它看作一个带约束的分配问题：
目标：最小化成本
约束：质量 >= 阈值，延迟 <= SLO，失败率 <= 阈值
决策：请求走小模型、大模型、RAG、Agent，还是转人工常见路由策略：
- 简单问题走小模型，复杂问题走大模型。
- 命中缓存直接返回，不进入模型。
- 高风险请求走更强模型或人工审核。
- 长上下文请求优先压缩、检索或摘要，再决定是否调用大模型。
- 大模型失败时回退到保守回答或人工接管。
路由系统的关键不是“永远用最强模型”，而是把强模型用在最值得的位置。
缓存：用命中率换成本和延迟
缓存可以把重复请求从模型服务中移走。它的价值取决于命中率、缓存过期策略和错误缓存风险。
| 缓存类型 | 适用场景 | 风险 |
|---|---|---|
| Prompt cache | 系统提示词或长上下文重复 | 上下文变化时收益下降 |
| Response cache | FAQ、固定查询、低风险回答 | 可能缓存过期或错误答案 |
| Embedding cache | RAG 文档和查询向量 | 文档更新后需要失效 |
| Tool result cache | 慢 API 或数据库查询 | 实时性要求高时不可用 |
缓存不是单纯的性能技巧。它会改变系统行为：错误答案可能被重复放大，过期知识可能继续被使用，所以必须配合失效、版本和灰度策略。
容量规划：为峰值而不是平均值设计
容量规划需要回答：
- 峰值 QPS 是多少？
- 平均输出长度和长尾输出长度是多少？
- P95 / P99 延迟目标是多少？
- 单卡能承载多少并发序列？
- KV cache 在长上下文场景下是否会成为瓶颈？
- 降级后系统还能保留哪些核心能力？
一个简单但有用的规划方式：
所需副本数 ≈ 峰值请求率 × 单请求平均服务时间 / 目标利用率这只是粗略估算。真实系统还要考虑 batch 效率、上下文长度分布、输出长度分布、冷启动、故障冗余和多租户隔离。
SLO 与成本优化
LLM 系统不能只优化成本，也不能只优化质量。生产系统需要明确 SLO：
- 延迟 SLO：例如 P95 < 2s
- 可用性 SLO：例如成功率 > 99.5%
- 质量 SLO：例如关键任务准确率 > 95%
- 成本 SLO：例如单请求平均成本 < 某个阈值
- 安全 SLO：例如高风险请求必须审核或拒答
当 SLO 冲突时，系统必须有明确优先级。例如支付、医疗、合规类任务通常牺牲速度和成本来换安全；客服 FAQ 可以牺牲部分模型能力来换成本和吞吐。
和第 8 章主线的关系
- 8.1 模型压缩降低单次服务资源需求。
- 8.2 推理优化提高单位硬件吞吐。
- 8.3 成本优化决定请求是否缓存、路由或降级。
- 8.4 评估监控提供约束和反馈信号。
- 8.5 生产系统把调度、限流、回退和审计落到架构中。
运筹学视角的价值是把这些点连成一个系统：不是单点追求最快、最便宜或最强，而是在约束下做可解释、可监控、可回退的取舍。
本节小结
- LLM Serving 可以看作带质量、成本、延迟和可靠性约束的资源分配问题。
- 批处理提高吞吐，但会引入等待和调度复杂度。
- 模型路由的目标是把强模型用在最值得的位置。
- 缓存能降低成本和延迟，但必须管理过期和错误缓存。
- 容量规划要看峰值、长尾和 SLO，而不是只看平均请求。
返回： 第 8 章首页