模型服务规模化：调度、KV Cache 与资源池化的系统之道

SOSP 的 Session 1A 开场就是 Model Serving at Scale这个安排本身就很能说明问题。这几年我和团队一直在做 LLM 推理服务化眼看着这个方向从AI 实验室里的小工具变成了真正意义上的系统软件——调度、缓存、资源池化、故障恢复每一个话题都回到了操作系统研究的老本行。这个 Session 值得逐篇细看不只是因为论文本身而是因为它集中展示了整个行业在规模化部署大模型推理时的真实瓶颈和解决思路。这篇文章我按自己的理解把 Session 1A 的几条主线拆开讲包含对系统设计的分析、对工程落地的思考以及我自己在部署过程中踩过的坑。如果你也在做模型服务化或者正准备上手搭推理平台这些内容应该能帮你省不少时间。1. 为什么 Model Serving at Scale 值得单独开一场先把背景说清楚。SOSP 一直是以操作系统、存储、分布式系统见长的顶会往年这类会议上的工作大多是文件系统、内存管理、一致性协议。现在 Model Serving 能占一个 Session说明学术界已经达成了一个共识大模型推理瓶颈不再是模型精度而是系统效率。1.1 从跑通模型到规模化服务的转折过去一年里行业里能稳定对外提供大模型推理服务的团队基本都遇到了相同的问题。单机单卡跑一个 7B 模型很容易但一旦要支持几百路并发请求、上下文长度动辄几十 k token、还有严格的响应时间要求问题立刻变成资源调度问题。GPU 显存怎么分、请求怎么排队、cache 怎么复用、负载怎么均衡这些都不是 PyTorch 或者 Transformer 库能解决的。Session 1A 里的工作本质上就是在回答一个问题当模型推理变成基础服务操作系统的那套方法论——调度、缓存、隔离、容错——要怎么迁移到 GPU 上。1.2 这个 Session 的三条核心主线我把分场论文归纳成三个方向方便理解。调度与批处理解决怎么让 GPU 一直有事干。连续批处理、chunked prefill、请求级优先级这些都是围绕吞吐和延迟的博弈。状态管理解决KV Cache 放哪里、怎么复用。涉及显存管理、跨请求复用、缓存淘汰策略。资源池化解决多 GPU、多节点如何协同。包括 prefill/decode 分离、异构调度、弹性伸缩。这三条线不是孤立的好的系统设计通常同时处理多个问题。后面我逐个展开。2. 全景拆解Session 1A 的四条技术主线这一节把分场的内容按主题做一个总览。如果你只想要一个速览结论今年的模型服务研究已经从单卡优化全面转向集群协同所有论文都在试图打破单机资源上限。2.1 主线一调度与批处理调度是模型服务系统的心脏。早期推理服务用静态批处理请求来了先凑一批再一起算延迟高、利用率低。vLLM 提出的 PagedAttention 是一次突破但它解决的是显存管理问题真正让吞吐大幅提升的是连续批处理continuous batching——每个 step 动态决定哪些请求进入计算不用等整批结束。今年的论文在连续批处理基础上又往前走了一步。请求级抢占、优先级队列、prefill 分块调度这些都是为了让调度器有更细的控制粒度。我的看法是未来的调度器会越来越像 CPU 调度器只是时间片换成了 token 计算步。2.2 主线二KV Cache 的状态管理KV Cache 是模型服务里最系统的部分。一个 7B 模型生成长度为 4096 的响应KV Cache 占的显存可能比模型权重还大。缓存怎么分配、怎么换出、怎么在请求之间复用直接决定了单卡能并行处理多少请求。这一方向的代表作就是 PagedAttention把 KV Cache 切成固定大小的块用类似虚拟内存的方式管理。后续工作在此基础上做了分层缓存、压缩缓存、跨节点共享。本质上这就是把操作系统的页面置换算法搬到了 GPU 显存上。2.3 主线三Prefill/Decode 分离与池化这是今年最值得关注的方向。推理过程分两个阶段prefill计算密集和 decode访存密集。两个阶段对 GPU 资源的需求完全不同混在一起会导致资源浪费。DistServe 提出的方案是把两者拆到不同的 GPU 池各干各的Mooncake 更进一步把 KV Cache 当作一个可共享的存储层prefill 池算完就把中间结果丢给 decode 池。分离架构的收益很明显但工程复杂度也很高。请求怎么流转、失败怎么恢复、两个池的容量怎么配比都是难题。2.4 主线四性能可观测性与 SLO 治理规模化服务不能只靠感觉。TTFT首 token 延迟、TPOT每 token 生成时间、端到端延迟这些指标要能实时监控并且要能根据 SLO 自动伸缩。相关论文给出的思路是把 SLO 作为调度器的输入参数而不是事后统计。3. 调度细节从连续批处理到请求级控制调度这块看起来简单但真做起来全是细节。我下面拆解几个关键环节。3.1 为什么连续批处理成了标配传统批处理的问题很好理解一批请求里最慢的那个决定了整批的结束时间。如果一批里有 8 个请求其中一个要生成 2000 token其他 7 个只要 50 token那这 7 个快的也得等慢的跑完。GPU 的算力大量浪费在等待上。连续批处理的思路是每个解码步结束后完成的请求立刻离开 batch新请求立刻补进来。这样 GPU 永远在算密度最高的批次。实测下来同样的硬件连续批处理能把吞吐提升 2-3 倍。代价是调度器的复杂度上来了每一步都要检查有哪些请求完成、新请求是否要抢占、KV Cache 是否够分。3.2 Chunked Prefill 与请求优先级连续批处理引入了一个新问题prefill 阶段计算量大一个长请求的 prefill 可能会阻塞后面一排短请求的 decode。于是大家开始做 chunked prefill——把 prefill 的一大段计算切成小块穿插在 decode 步之间。这就像操作系统的抢占式调度长任务不再独占 CPU而是分时执行。实际调优中chunk 大小的选择很讲究太大导致 decode 延迟飙升太小又增加调度开销。我们团队的经验是chunk 大小控制在 512-1024 token 之间比较稳妥同时要给短延迟请求开快车道——可以抢占低优先级请求的算力。提示chunked prefill 不是银弹。如果你的业务首 token 延迟要求极高比如低于 200ms还是要把短请求凑成一个独立优先级队列避免被长 prefill 拖累。3.3 调度器里最难调的参数调度器的核心其实是三个数字的博弈TTFT、TPOT、吞吐量。想提升吞吐就得多塞请求进 batch但每个请求的 TPOT 就会变慢想降低 TTFT 就得让请求快速插队但频繁插队会导致整体吞吐下降。我给团队定的调优策略是先定 SLO 红线然后在这条线下最大化吞吐。具体做法是给请求分三类——交互型要求 TTFT 500ms、生成型要求 TPOT 稳定、批处理型无所谓延迟。这三类请求分别走不同的队列调度器按比例分配 GPU 时间片。4. KV Cache分层、复用与压缩KV Cache 是模型服务的显存大头也是缓存系统的重点研究对象。这一节讲我在读论文和实操中理解到的核心问题。4.1 PagedAttention 之后的世界PagedAttention 的核心贡献是把 KV Cache 切成固定大小的块通过页表映射管理从而消除显存碎片、支持跨请求共享。这个思路对显存利用率提升非常明显。但它的粒度是块一个块通常是 16 个 token 的 KV这在长上下文场景下仍有浪费——最后一块可能只用了几个 token。后续的优化方向是更小的块粒度、动态块大小、以及把 KV 数据压缩到更低位宽。比如 FP8 甚至 INT4 存储 KV Cache配合量化感知的注意力计算。代价是精度损失但实测中大多数场景的生成质量影响很小可以接受。4.2 跨请求共享与语义缓存不同用户问什么是 KV Cache前面几层网络prompt 前缀是完全相同的。如果每次请求都重新算一遍 prefill浪费十分严重。RadixAttentionSGLang 的核心思想把 KV Cache 按公共前缀组织成树结构新请求能直接复用已有缓存跳过重复计算。这在共享前缀命中率高的场景收益极大比如聊天机器人的 system prompt、RAG 的固定检索头。但要注意缓存容量管理——树结构缓存需要配套的淘汰机制LRU 是最基础的更高级的是按未来复用概率做加权淘汰。缓存策略适用场景命中率提升复杂度普通 LRU通用场景一般低Radix Tree 前缀复用固定 system prompt高中语义缓存相似问题聚类高高需要 embedding 匹配分层缓存多 GPU 集群较高高4.3 缓存淘汰的权衡缓存淘汰最大的坑是你没法预知哪个 KV Cache 会被复用。有些请求只是偶尔重复一次占着大量显存有些用户的高频请求却因为容量不够被换出下次又要重算 prefill。我的建议是淘汰策略不要只看访问时间要结合请求频率、前缀长度、是否来自高价值用户来综合打分。另外考虑把冷 KV Cache 下移到 CPU 内存或远端存储而不是直接丢弃。虽然从 CPU 拉回 GPU 有带宽开销但相比重算 prefill通常还是划算的。5. Prefill/Decode 分离与资源池化的实战思考分离式架构是今年讨论热度最高的话题也是实际操作中收益和坑并存的方向。5.1 为什么非拆不可一个 LLM 请求的 prefill 阶段是计算密集的GPU 的算力能跑满但显存带宽需求低decode 阶段则反过来每个 token 只需要做一次小矩阵乘大量时间花在读显存上。把两个阶段混在同一批里GPU 一会儿算到冒烟一会儿又闲得等显存调度效率很低。分离架构把 prefill 和 decode 交给不同的 GPU 池处理。prefill 池用高算力 GPUdecode 池用大显存 GPU各得其所。请求先到 prefill 池算出 KV Cache然后 KV Cache 传到 decode 池继续生成。理论吞吐可以提升数倍。5.2 分离架构的工程代价听起来很美但工程实现远比想象复杂。KV Cache 传输带宽是硬瓶颈。一个 32K 上下文的 KV Cache 大约有几百 MB跨节点传输本身就是延迟大头。请求分配策略难调。prefill 池和 decode 池的比例要根据业务特征动态调整今天聊天请求多明天长文生成请求多比例不对就会一边忙死一边闲着。故障恢复复杂。decode 池里的请求可能依赖 prefill 池传过来的中间结果prefill 池故障意味着要追溯重算。我的建议是如果单集群规模不大比如少于 32 卡不要轻易上分离架构。先把连续批处理和缓存复用做到位通常就能解决 80% 的吞吐问题。分离架构是为了冲更高规模上限的手段不是起点。5.3 池化调度的核心指标一旦决定做资源池化就要盯着几个关键指标看池间队列深度如果 prefill 池的队列深度长期高于 decode 池说明 prefill 能力不足要加卡。KV Cache 传输耗时占比这个占比超过 20%说明网络带宽是瓶颈考虑压缩 KV 或走共享显存。池内空闲率min(池 A 空闲, 池 B 空闲) 越低越好。如果经常出现一边空转一边排队说明池比例没调对。6. 落地实操读完论文后的部署经验论文给的是思路落地全是细节。分享一些我在实践中获得的经验希望能帮你少走弯路。6.1 论文指标和生产指标不是一回事论文里通常报告吞吐量tokens/s、首 token 延迟等指标但它们大多数是在特定数据集上测的前缀缓存命中率可能很高batch 里的请求分布也和你的业务不一样。生产环境要关心的是有效吞吐——满足 SLO 的那些请求的吞吐而不是理论吞吐。我见过不少团队被论文数字吸引上线后实测只有论文数据的 30%。原因几乎都是两类业务请求长度分布跟论文数据集差异大或者高峰期的并发波动把调度器打懵了。所以用你自己的真实流量做压测建立基线指标再找优化点。6.2 架构选型建议根据集群规模和业务场景我给一个简单直接的建议表规模场景推荐架构理由单机 1-4 卡内部工具、小流量vLLM 连续批处理简单可靠够用单机 8 卡中等流量、RAG独立 prefill/decode 分离利用多卡异构优势多机多卡高并发、多租户池化 KV Cache 共享存储弹性伸缩资源效率高混合云流量波动大Serverless 自动伸缩成本最优但要解决冷启动如果流量比较平稳那不一定要上复杂的池化架构如果流量有早晚高峰那就要提前规划弹性扩缩。调度器的自动伸缩触发条件建议用排队长度而不是 GPU 利用率因为 GPU 利用率往往有滞后。6.3 部署监控的最小清单做推理服务下面这些指标缺一不可请求级TTFT、TPOT、尾延迟P99系统级GPU 利用率、显存占用、KV Cache 命中率队列级每类请求的排队长度、平均等待耗时资源级CPU/内存/网络带宽尤其是跨节点 KV Cache 传输带宽我习惯把 TTFT 和排队长度放在同一张图上。只要队一长TTFT 必然跟着涨这时候靠加卡解决不了问题——得看是不是调度策略把长请求和短请求混在一起了。7. 高频问题排查记录把几个我反复遇到、也最适合拿来说明系统原理的问题整理成速查表。现象可能原因排查思路解决建议TTFT 忽高忽低长请求 prefill 阻塞看调度日志检查 chunk 大小拆 prefill 块或启用长请求单独队列GPU 利用率高但吞吐低decode 阶段显存带宽受限看解码步的平均耗时检查 KV Cache 是否压缩降低数据读取量KV Cache 频繁换出缓存容量不足看命中率曲线增加显存份额或引入 CPU 分层缓存多节点时吞吐上不去KV 传输带宽瓶颈看节点间网络占用压缩 KV、减少跨节点请求自动伸缩反复抖动伸缩阈值太敏感看队列长度变化增大冷静周期用加权移动平均7.1 典型场景一TTFT 突然从 300ms 飙到 2 秒排查思路分三步。第一步看有没有大请求进来第二步看调度器是否启用了连续批处理但 prefill 没分块第三步看请求是否都挤进了同一个逻辑队列。我遇到过最隐蔽的问题是缓存命中率突然下降导致 prefill 计算量翻倍缓存没失效但用户请求的 prompt 模板变了前缀全部 miss。7.2 典型场景二加了卡吞吐没变化这通常说明瓶颈不在算力而在别处。可能是 KV Cache 传输网络带宽打满、也可能是调度器单点成了瓶颈。你应该做的第一件事是看吞吐曲线的增长坡度如果是线性走平就需要检查各环节的队列深度。7.3 典型场景三长上下文请求把缓存打爆长上下文的 KV Cache 动辄几个 GB一个并发稍高就填满显存。解法有两类一类是限制单请求最大上下文长度另一类是给长请求设独立的池避免它们挤占普通请求的缓存空间。后一种更推荐因为一刀切限制长度会伤用户体验。8. 写在最后一些个人观察Session 1A 这一整场看下来我最大的感受是模型服务正在快速操作系统化。调度、缓存、隔离、池化、容错——这些词本来就是操作系统教材里的核心章节现在它们在大模型推理场景里重新焕发了生命力。我的第二个观察是论文给出的系统设计越来越复杂但工业界实际部署时越简单的系统越容易成功。你可以先从一个单机版的连续批处理做起把监控和排障体系建好再逐步迭代到池化架构。系统复杂度和团队维护能力要匹配否则论文里漂亮的设计会变成生产事故的来源。如果你正在搭建模型推理服务建议盯着两个指标P99 TTFT 和有效吞吐。把这两个指标排在所有优化工作之前就不会跑偏。至于缓存复用、prefill 分块这些技术细节都属于怎么让这两个指标更好的工具箱按需取用就好。我个人在实操中还有一个习惯每篇相关论文读完不急着改架构先画一张当前系统瓶颈在哪的图把论文方案和我们的瓶颈对照。很多论文确实优秀但它解决的瓶颈你可能还没遇到先确认自己真的卡在哪一层再决定要不要借鉴。这样既能避免过度设计也能在真正遇到瓶颈时知道该从哪个方向找答案。