SOSP 2026 第一天的 Session 1A 排在了早上九点主题是 Model Serving at Scale。我提前十分钟进场发现前排已经坐满了后排有人在翻论文 PDF有人在笔记本上提前写好问题。这几年只要议题里带 Model Serving会场就不会冷清——从训练卷到推理之后系统研究者终于找到了又一个能持续产出问题的舞台。这个 Session 的标题里有一个关键词Scale。它不代表模型参数上了多少亿而是三个尺度同时被拉大并发请求规模、KV Cache 的存储规模、集群跨地域的调度规模。看完这半天报告我的整体感受是serving 领域正在从“把 GPU 用满”走向“把资源当操作系统来管”。这篇文章是我的现场评述不打算复述摘要只聊聊哪些设计值得抄回去、哪些结论要谨慎对待以及实验数据里藏着什么坑。写给正在做推理平台、自建模型服务、或者准备投系统方向论文的读者。1. 我看 Serving 论文的判卷标准四个题眼1.1 为什么 Model Serving 能在系统顶会里独占一个 Session早几年系统顶会的主角是训练分布式并行、容错、梯度压缩、参数服务器一整套围绕“离线批量作业”展开的问题域。训练系统的优化目标很单一——在尽可能多的 GPU 上把端到端吞吐拉满收敛时间缩短失败能自动恢复。这是个经典的大规模分布式计算问题调度器做着批量作业调度通信库负责张量搬运一切都相对可控。推理服务在过去被普遍视为“训练的前向过程加个缓存”工程师在工程侧手搓几层负载均衡和批处理就行很难撑起一篇系统论文的核心贡献。真正把它变成研究问题的是 LLM 的在线性和交互性。查一个 token 的生成服务器并不知道整个序列什么时候结束用户随时可能停止流式输出让每一步都处在动态变化中。请求到达是突发性的平均长度是幂律分布的SLA 不以“跑得多快”衡量而以“首 token 多久、后续 token 多稳”衡量。更现实的是成本一个 7B 模型跑在 A100 上GPU 闲置时间的浪费是肉眼可见的账单损失。于是 Session 1A 的几场报告看起来像一次小型操作系统会议调度器、缓存、换页、内存池、资源抢占只是操作对象从进程换成了 token。这本身就是一个信号——serving 已经从“工程优化”升格为“系统研究”而且是顶会愿意留出黄金时段的方向。1.2 四个判卷维度问题真实性、设计区分度、实验强度、可落地性评述论文前我习惯先给自己立一个判卷标准不然容易被 PPT 带跑。这场我主要盯四个题眼判卷维度我会问的问题问题真实性这是数万台 GPU 跑出来的痛点还是 demo 机上编出来的场景设计区分度相对 vLLM、TGI、TensorRT-LLM 这些基线是改参数还是换了机制实验强度有没有真实 trace 支撑指标是否覆盖延迟与成本两侧可落地性我团队花三个月复刻值不值举个具体例子KV cache 分层这个方向我在真实线上环境确实见过显存被超长上下文吃穿的情况所以这类论文的问题真实性天然加分。而有些论文从合成负载生成器起步问题定义看起来漂亮但往生产上一放就露馅——因为它没回答“真实流量长什么样”这个前提问题。设计区分度是我最警惕的一项。现在 serving 领域有个趋势任何系统都往“调度器 KV cache 优化 投机解码”这三件套上靠。如果你做的事情只是把其中某个环节的默认参数改一改那算不上新系统。本场有两篇论文在机制层面有真正的差异化我会在下一节细说。剩下几篇更多是工程组合优化不是不好但不是 SOSP 级别贡献的核心。实验强度和可落地性在论文里常常互相打架。有的论文实验做得非常漂亮用掉了几个知名 benchmark但作者在 QA 环节被问到真实负载时明显底气不足。这类论文读起来要打个折扣。2. 从请求级调度到页级缓存两篇最有“操作系统味”的工作2.1 ProgressServe首 token 之后才是调度真正开始的地方第一篇让我印象最深的工作临时叫它 ProgressServe 吧核心命题是:现有 continuous batching 有一个被大多数实现忽略的长尾问题。continuous batching 本身的价值不用多说它让 GPU 不必等一个 batch 全部跑完就能插入新请求把空闲时间压缩到极小。但请求一旦开始输出后续 token 的产生速度基本由模型大小和显存带宽决定长流式输出会长时间占住 KV cache 和计算资源。大部分在线服务的真实情况是少数请求特别长多数请求很短。短请求对新到达请求的 TTFT 非常敏感用户等 2 秒没反应就会刷新页面而已经在输出的长请求用户已经看到了前几个 token耐心阈值反而高不少。ProgressServe 的思路是进度感知抢占把已经输出足够多 token、用户预期已经建立的请求从“不可中断”降级为“可换出”状态把宝贵的显存和算力让给还没开始输出、或者刚开头的请求。这有点像调度器里的 aging 反着用——传统调度器防止长任务饿死这里的逻辑是长流式请求有更高的被抢占容忍度所以故意给它们一点“委屈”。我认可这个设计的地方在于它把产品体验量化成了一个可调度的参数以 TTFT 优先的延迟目标动态决定换出阈值。这比拍脑袋调 batch size 科学得多。我不太放心的地方是换出的具体代价换出要保存哪些 KV 块恢复路径是否真能在几十毫秒内完成报告里说它们用了一层可旁路的本地 offload但我看换出时机的阈值还是靠参数调的不同 workload 下的稳定性存疑。现场有评委追问“换出粒度到底是层还是 token 序列”作者回答是块级但恢复时是否重新计算注意力前缀这个细节被一句带过了。2.2 TierKV把 KV Cache 当成页缓存来管理第二篇我临时叫它 TierKV讲的是 KV cache 的分层存储方向完全不让人意外但设计密度够高。先算一笔账以 8B 模型、32 层、GQA 头为例每个 token 的 KV cache 大约是 128KB跑到 1M token 上下文就是 120GB 以上远超模型权重。这直接改变了一个基本假设KV cache 不再是“够用就行的一点缓冲”而是整个 serving 系统里最大的显存消耗者。既然它大就必须像内存一样管起来。TierKV 把 KV cache 分成三层HBM、统一内存池、NVMe。块粒度和 PagedAttention 的页表兼容冷热判断用了“访问时间 注意力分数”的组合比如某一块 KV 很久没被访问、或者注意力权重一直很低就把它换到 NVMe等后续请求触发时再换回 HBM。我看到这里第一反应是——这就是把 KV cache 当 page cache 管把 GPU 当内存把 NVMe 当磁盘教科书级的内存管理迁移。我的批评集中在换页的带宽成本没有讲透。PCIe 4.0 带宽约 32GB/sNVMe 再快也就是 7-14GB/s 的量级。如果流量突发导致 cache miss 风暴大量请求同时触发换入换出TTFT 会直接劣化。论文评测里应该给出 miss 率不断上升时的尾部延迟曲线而不是只报平均。但方向上我完全赞成长上下文成为标配之后KV cache 管理就是 serving 的“内存瓶颈”谁先把这里做得像操作系统一样稳谁就掌握了下一阶段的成本优势。2.3 合起来看serving 正在内核化把这两篇放一起看一个清晰的技术趋势浮出水面维度传统 serving 视角这两篇的视角调度单元请求进度阶段、KV 页内存模型整块 KV buffer分页、分层、换出优化目标最大化 batch 吞吐TTFT/SLO 约束下的资源复用类比批处理虚拟内存管理这就是我前面说的“serving 内核化”请求像进程、KV 页像页框、调度器像 OS scheduler我们以前在操作系统课里学的那套资源管理方法论正在 LLM 推理这个新场景里重新长一遍。但我也提醒自己别过度类比。OS 的页换入换出有硬件 MMU 支持地址转换和异常处理都是微秒级KV cache 换页完全由软件驱动涉及 GPU 与 CPU 之间的 PCIe 搬运成本高一个数量级。TierKV 能做到的更多是“减少换页次数”而不是“让换页很便宜”。这个区别决定了这类系统的适用范围只有长上下文请求占比高、且具备阶段性显存波动的业务分层缓存才真正划算。3. 跨出单机prefill/decode 分离与投机路由的账本3.1 GeoSplit把 prefill 和 decode 拆到不同的地方Session 1A 的第三个主题是跨节点的部署形态其中一篇我临时叫它 GeoSplit核心思想是 prefill 和 decode 分离部署甚至放到不同地理位置。这个设计的出发点在推理系统的算术特性里。我整理了一张对比表特性PrefillDecode计算密度高低瓶颈算力显存带宽延迟敏感指标TTFTTPOT最优部署倾向集中式大算力节点靠近用户、低时延节点prefill 阶段要处理整段 prompt注意力矩阵随序列长度增长是标准的计算密集型任务decode 阶段每个 step 只生成一个 token主要时间花在读权重和 KV cache 上是显存带宽受限。两者的资源画像完全不同硬放在同一台 GPU 上必然造成浪费prefill 高峰时算力吃紧decode 高峰时带宽吃紧。GeoSplit 的做法是把 prefill 放在成本更低的大算力节点decode 放在靠近用户的节点两者之间传输的是已经算好的 KV cache而不是重新算一遍 prompt。这个想法本身不新鲜但难在工程细节KV cache 的体积随序列长度线性增长跨节点传输的带宽占用和延迟预算必须算清楚。比如同城多机房专线延迟在几毫秒量级跨 region 的专线延迟可能到几十毫秒decode 每一步本身才几十毫秒传输开销稍大就会吃掉收益。我的判断是这类系统最适合同城多机房或者云厂商同一个 region 内的部署跨 region 做 token 级搬运网络成本会把算力成本的优势抵消掉。除非业务对 TPOT 极度敏感、且专线带宽白送否则别轻易抄。3.2 SpecRoute路由与投机执行联动第四篇的视角又不一样它把“路由”和“投机解码”绑在一起我临时叫它 SpecRoute。投机解码的基本逻辑是先用一个小模型快速生成草稿 token再让大模型一次性验证。草稿接受率高加速明显接受率低验证成本白花。SpecRoute 在这个基础上加了一层路由决策请求先经过小模型打草稿同时路由控制器根据请求的 embedding 相似度预测这条请求适合哪个模型、大致会生成多长甚至在相似请求之间共享已经校验过的 token 块减少重复计算。它的漂亮点在于把“去哪台机器跑”和“怎么跑得更快”这两个问题统一到了一个控制平面上。对于同一个会话反复查询相似内容的热门负载草稿缓存命中率会很高收益非常可观。我的担忧也很具体公共服务里绝大多数请求是长尾的相似度聚类在热门请求上命中率高长尾请求的收益会明显回落。论文给的是平均收益掩盖了分布的方差。而且引入一个全局路由状态同步组件本身可能成为新的瓶颈——中央式状态存储的延迟和本地缓存的命中率之间需要精细平衡这部分报告里讲得不够。对多数团队我的建议是先不要像 SpecRoute 这样把路由和投机耦合着做。先把两者的收益分别量化如果你的业务连简单的 content-based 路由都还没跑明白叠加投机只会让排查问题变得困难。3.3 QA 最犀利的问题流量计费模型这半场最让我印象深刻的细节不是某个技术答案而是评委席上一位老师直接问 GeoSplit 的作者“你把 KV cache 从 A 地搬到 B 地按云厂商的流量计费来算到底省了钱还是多花了钱”作者回答得比较委婉说要看时延敏感度和算力成本差。这个问题的本质是论文优化的是资源利用率但真实账单里网络也是成本。我在写生产环境方案时经常遇到这种情况——纸面上算 GPU 利用率提升了不少把流量费、带宽占用费、跨区专线费一填进去结论就翻转了。所以读到这一类跨节点方案我的习惯是先把自家的价格模型做成一个小表把网络项填进去再决定是否跟进。4. 实验与评估这半场论文最让我不放心的地方4.1 trace 稀缺与负载形状的威力说句得罪人的话serving 论文的实验部分是所有系统方向里最不好做的也是最容易藏问题的。同一个系统面对平均 200 token 的短对话和平均 2000 token 的长文总结结果可能差出好几倍。prefill 与 decode 的资源占比完全不同调度策略的优劣也完全不同。本场有一篇论文在官方 benchmark 上非常漂亮但讨论环节承认换了会话型负载后吞吐掉了近一半原因是热加载的 KV 块被意外淘汰。这就是负载形状的威力——一个看似中性的调度策略在某种负载形态下会突然暴露弱点。我读 serving 论文的经验是先看实验部分的三个信息负载是从哪来的、平均长度和长尾长度是多少、有没有构造突发流量。三样都不给的话这篇论文的实验结果参考价值直接减半。4.2 指标清单不要只看吞吐很多团队评估 serving 系统只看吞吐这是个大坑。吞吐高可能意味着 batch 很大、 KV cache 占用很高但单请求延迟可能已经恶化到用户无法接受。本场论文里指标差异也很大我整理了一个对照指标回答的问题适用场景TTFT首个 token 多快聊天、交互型应用TPOT后续 token 稳不稳流式输出、长文本生成吞吐token/s单位 GPU 产出成本核算P99 排队时延抗突发能力生产 SLA这里我特别想强调看 TTFT 一定要把 P50 和 P95 一起看。只给平均值的论文我一律在心里打折。因为 serving 系统的 tail 行为往往决定了用户真实感受尤其是长尾请求被换出导致的 TTFT 劣化平均值根本看不出来。4.3 开源不等于可复现顶会现在都要求开源但源码能跑通不代表结论可复现。GPU 型号、CUDA 版本、网络拓扑甚至 NVMe 固件版本都会影响换页类系统的表现。我们团队之前在内部复现过一个和 TierKV 类似的方案单机实验一切正常但上到 8 卡之后卡在 host buffer 和 NVMe 之间的传输路径上性能和论文差了近四成。后来发现是 PCIe switch 拓扑和论文中的环境差异导致的。所以我现在的习惯是先跑两个针对性小实验一个验证单机稳定性一个故意构造能触发换页的负载确认这两个都过再决定深入复现。这也算是对自己时间成本的一种保护。5. 散场后的判断哪些结论值得抄哪些先放一放5.1 我会带回团队立刻试的三件事第一把 prefill 和 decode 的并发控制从“尽力而为”改成显式阈值。不用做到 ProgressServe 那种完整的进度感知抢占先做一条简单规则当 TTFT 超过某个阈值时强制让部分长流式连接暂停输出、释放 KV 资源给新请求。这个改动在工程上工作量不大但能显著改善短请求的体验。第二在长上下文占比高、显存阶段性紧张的线上业务尝试 KV cache 分层。先只做两层HBM CPU 内存不急着上 NVMe。两层模式没有 PCIe 之外的额外存储层次实现简单很多大多数业务场景的收益已经很可观。第三把评估指标表里加上 P95 TTFT 和成本/token每双周复盘一次。不是为了发论文而是为了让技术决策有数据支撑而不是靠直觉争论。5.2 我不打算复刻的设计跨地域 token 级 prefill/decode 分离我暂时不碰。原因就是前面说的网络成本模型不划算除非团队已经有同城多机房和稳定专线。路由与投机联动也不打算立刻做因为叠加了两套系统的复杂度出了问题排查成本太高。我更愿意把精力花在单集群内部的资源管理优化上。在多数场景里单集群的显存利用率做到 90% 比跨集群搬运 KV cache 省下的钱多得多也稳定得多。5.3 下一届 Session 我想看到的东西走出会场时我最大的感受不是“serving 又来了多少篇”而是这个领域终于开始把操作系统的方法论搬进一个每天都在烧钱的生产系统里。论文里的换页、抢占、路由我大概率不会全部照抄但它们逼我重新思考了一个问题我们在生产环境里默认的调度策略真的比论文里的更合理吗答案不一定是 No但这个疑问本身就很有价值。如果下一届还有 Model Serving 的 Session我最想看到的也许是这三个方向统一资源账本——把 GPU 算力、HBM、KV cache、网络带宽放进同一个优化框架serving 与训练混布——训练低谷期让推理占用换页策略如何利用训练任务的节奏以及一个学术界和工业界都能用的在线负载生成器让论文实验在复现时不至于因为负载定义模糊而各说各话。到那时候这个领域才真正成熟了。 
长河君 · 2026/10/26 8:03:30 · 阅读 1.2k SOSP 2026现场评述：Model Serving的系统化演进与KV Cache管理
SOSP 2026 第一天的 Session 1A 排在了早上九点主题是 Model Serving at Scale。我提前十分钟进场发现前排已经坐满了后排有人在翻论文 PDF有人在笔记本上提前写好问题。这几年只要议题里带 Model Serving会场就不会冷清——从训练卷到推理之后系统研究者终于找到了又一个能持续产出问题的舞台。这个 Session 的标题里有一个关键词Scale。它不代表模型参数上了多少亿而是三个尺度同时被拉大并发请求规模、KV Cache 的存储规模、集群跨地域的调度规模。看完这半天报告我的整体感受是serving 领域正在从“把 GPU 用满”走向“把资源当操作系统来管”。这篇文章是我的现场评述不打算复述摘要只聊聊哪些设计值得抄回去、哪些结论要谨慎对待以及实验数据里藏着什么坑。写给正在做推理平台、自建模型服务、或者准备投系统方向论文的读者。1. 我看 Serving 论文的判卷标准四个题眼1.1 为什么 Model Serving 能在系统顶会里独占一个 Session早几年系统顶会的主角是训练分布式并行、容错、梯度压缩、参数服务器一整套围绕“离线批量作业”展开的问题域。训练系统的优化目标很单一——在尽可能多的 GPU 上把端到端吞吐拉满收敛时间缩短失败能自动恢复。这是个经典的大规模分布式计算问题调度器做着批量作业调度通信库负责张量搬运一切都相对可控。推理服务在过去被普遍视为“训练的前向过程加个缓存”工程师在工程侧手搓几层负载均衡和批处理就行很难撑起一篇系统论文的核心贡献。真正把它变成研究问题的是 LLM 的在线性和交互性。查一个 token 的生成服务器并不知道整个序列什么时候结束用户随时可能停止流式输出让每一步都处在动态变化中。请求到达是突发性的平均长度是幂律分布的SLA 不以“跑得多快”衡量而以“首 token 多久、后续 token 多稳”衡量。更现实的是成本一个 7B 模型跑在 A100 上GPU 闲置时间的浪费是肉眼可见的账单损失。于是 Session 1A 的几场报告看起来像一次小型操作系统会议调度器、缓存、换页、内存池、资源抢占只是操作对象从进程换成了 token。这本身就是一个信号——serving 已经从“工程优化”升格为“系统研究”而且是顶会愿意留出黄金时段的方向。1.2 四个判卷维度问题真实性、设计区分度、实验强度、可落地性评述论文前我习惯先给自己立一个判卷标准不然容易被 PPT 带跑。这场我主要盯四个题眼判卷维度我会问的问题问题真实性这是数万台 GPU 跑出来的痛点还是 demo 机上编出来的场景设计区分度相对 vLLM、TGI、TensorRT-LLM 这些基线是改参数还是换了机制实验强度有没有真实 trace 支撑指标是否覆盖延迟与成本两侧可落地性我团队花三个月复刻值不值举个具体例子KV cache 分层这个方向我在真实线上环境确实见过显存被超长上下文吃穿的情况所以这类论文的问题真实性天然加分。而有些论文从合成负载生成器起步问题定义看起来漂亮但往生产上一放就露馅——因为它没回答“真实流量长什么样”这个前提问题。设计区分度是我最警惕的一项。现在 serving 领域有个趋势任何系统都往“调度器 KV cache 优化 投机解码”这三件套上靠。如果你做的事情只是把其中某个环节的默认参数改一改那算不上新系统。本场有两篇论文在机制层面有真正的差异化我会在下一节细说。剩下几篇更多是工程组合优化不是不好但不是 SOSP 级别贡献的核心。实验强度和可落地性在论文里常常互相打架。有的论文实验做得非常漂亮用掉了几个知名 benchmark但作者在 QA 环节被问到真实负载时明显底气不足。这类论文读起来要打个折扣。2. 从请求级调度到页级缓存两篇最有“操作系统味”的工作2.1 ProgressServe首 token 之后才是调度真正开始的地方第一篇让我印象最深的工作临时叫它 ProgressServe 吧核心命题是:现有 continuous batching 有一个被大多数实现忽略的长尾问题。continuous batching 本身的价值不用多说它让 GPU 不必等一个 batch 全部跑完就能插入新请求把空闲时间压缩到极小。但请求一旦开始输出后续 token 的产生速度基本由模型大小和显存带宽决定长流式输出会长时间占住 KV cache 和计算资源。大部分在线服务的真实情况是少数请求特别长多数请求很短。短请求对新到达请求的 TTFT 非常敏感用户等 2 秒没反应就会刷新页面而已经在输出的长请求用户已经看到了前几个 token耐心阈值反而高不少。ProgressServe 的思路是进度感知抢占把已经输出足够多 token、用户预期已经建立的请求从“不可中断”降级为“可换出”状态把宝贵的显存和算力让给还没开始输出、或者刚开头的请求。这有点像调度器里的 aging 反着用——传统调度器防止长任务饿死这里的逻辑是长流式请求有更高的被抢占容忍度所以故意给它们一点“委屈”。我认可这个设计的地方在于它把产品体验量化成了一个可调度的参数以 TTFT 优先的延迟目标动态决定换出阈值。这比拍脑袋调 batch size 科学得多。我不太放心的地方是换出的具体代价换出要保存哪些 KV 块恢复路径是否真能在几十毫秒内完成报告里说它们用了一层可旁路的本地 offload但我看换出时机的阈值还是靠参数调的不同 workload 下的稳定性存疑。现场有评委追问“换出粒度到底是层还是 token 序列”作者回答是块级但恢复时是否重新计算注意力前缀这个细节被一句带过了。2.2 TierKV把 KV Cache 当成页缓存来管理第二篇我临时叫它 TierKV讲的是 KV cache 的分层存储方向完全不让人意外但设计密度够高。先算一笔账以 8B 模型、32 层、GQA 头为例每个 token 的 KV cache 大约是 128KB跑到 1M token 上下文就是 120GB 以上远超模型权重。这直接改变了一个基本假设KV cache 不再是“够用就行的一点缓冲”而是整个 serving 系统里最大的显存消耗者。既然它大就必须像内存一样管起来。TierKV 把 KV cache 分成三层HBM、统一内存池、NVMe。块粒度和 PagedAttention 的页表兼容冷热判断用了“访问时间 注意力分数”的组合比如某一块 KV 很久没被访问、或者注意力权重一直很低就把它换到 NVMe等后续请求触发时再换回 HBM。我看到这里第一反应是——这就是把 KV cache 当 page cache 管把 GPU 当内存把 NVMe 当磁盘教科书级的内存管理迁移。我的批评集中在换页的带宽成本没有讲透。PCIe 4.0 带宽约 32GB/sNVMe 再快也就是 7-14GB/s 的量级。如果流量突发导致 cache miss 风暴大量请求同时触发换入换出TTFT 会直接劣化。论文评测里应该给出 miss 率不断上升时的尾部延迟曲线而不是只报平均。但方向上我完全赞成长上下文成为标配之后KV cache 管理就是 serving 的“内存瓶颈”谁先把这里做得像操作系统一样稳谁就掌握了下一阶段的成本优势。2.3 合起来看serving 正在内核化把这两篇放一起看一个清晰的技术趋势浮出水面维度传统 serving 视角这两篇的视角调度单元请求进度阶段、KV 页内存模型整块 KV buffer分页、分层、换出优化目标最大化 batch 吞吐TTFT/SLO 约束下的资源复用类比批处理虚拟内存管理这就是我前面说的“serving 内核化”请求像进程、KV 页像页框、调度器像 OS scheduler我们以前在操作系统课里学的那套资源管理方法论正在 LLM 推理这个新场景里重新长一遍。但我也提醒自己别过度类比。OS 的页换入换出有硬件 MMU 支持地址转换和异常处理都是微秒级KV cache 换页完全由软件驱动涉及 GPU 与 CPU 之间的 PCIe 搬运成本高一个数量级。TierKV 能做到的更多是“减少换页次数”而不是“让换页很便宜”。这个区别决定了这类系统的适用范围只有长上下文请求占比高、且具备阶段性显存波动的业务分层缓存才真正划算。3. 跨出单机prefill/decode 分离与投机路由的账本3.1 GeoSplit把 prefill 和 decode 拆到不同的地方Session 1A 的第三个主题是跨节点的部署形态其中一篇我临时叫它 GeoSplit核心思想是 prefill 和 decode 分离部署甚至放到不同地理位置。这个设计的出发点在推理系统的算术特性里。我整理了一张对比表特性PrefillDecode计算密度高低瓶颈算力显存带宽延迟敏感指标TTFTTPOT最优部署倾向集中式大算力节点靠近用户、低时延节点prefill 阶段要处理整段 prompt注意力矩阵随序列长度增长是标准的计算密集型任务decode 阶段每个 step 只生成一个 token主要时间花在读权重和 KV cache 上是显存带宽受限。两者的资源画像完全不同硬放在同一台 GPU 上必然造成浪费prefill 高峰时算力吃紧decode 高峰时带宽吃紧。GeoSplit 的做法是把 prefill 放在成本更低的大算力节点decode 放在靠近用户的节点两者之间传输的是已经算好的 KV cache而不是重新算一遍 prompt。这个想法本身不新鲜但难在工程细节KV cache 的体积随序列长度线性增长跨节点传输的带宽占用和延迟预算必须算清楚。比如同城多机房专线延迟在几毫秒量级跨 region 的专线延迟可能到几十毫秒decode 每一步本身才几十毫秒传输开销稍大就会吃掉收益。我的判断是这类系统最适合同城多机房或者云厂商同一个 region 内的部署跨 region 做 token 级搬运网络成本会把算力成本的优势抵消掉。除非业务对 TPOT 极度敏感、且专线带宽白送否则别轻易抄。3.2 SpecRoute路由与投机执行联动第四篇的视角又不一样它把“路由”和“投机解码”绑在一起我临时叫它 SpecRoute。投机解码的基本逻辑是先用一个小模型快速生成草稿 token再让大模型一次性验证。草稿接受率高加速明显接受率低验证成本白花。SpecRoute 在这个基础上加了一层路由决策请求先经过小模型打草稿同时路由控制器根据请求的 embedding 相似度预测这条请求适合哪个模型、大致会生成多长甚至在相似请求之间共享已经校验过的 token 块减少重复计算。它的漂亮点在于把“去哪台机器跑”和“怎么跑得更快”这两个问题统一到了一个控制平面上。对于同一个会话反复查询相似内容的热门负载草稿缓存命中率会很高收益非常可观。我的担忧也很具体公共服务里绝大多数请求是长尾的相似度聚类在热门请求上命中率高长尾请求的收益会明显回落。论文给的是平均收益掩盖了分布的方差。而且引入一个全局路由状态同步组件本身可能成为新的瓶颈——中央式状态存储的延迟和本地缓存的命中率之间需要精细平衡这部分报告里讲得不够。对多数团队我的建议是先不要像 SpecRoute 这样把路由和投机耦合着做。先把两者的收益分别量化如果你的业务连简单的 content-based 路由都还没跑明白叠加投机只会让排查问题变得困难。3.3 QA 最犀利的问题流量计费模型这半场最让我印象深刻的细节不是某个技术答案而是评委席上一位老师直接问 GeoSplit 的作者“你把 KV cache 从 A 地搬到 B 地按云厂商的流量计费来算到底省了钱还是多花了钱”作者回答得比较委婉说要看时延敏感度和算力成本差。这个问题的本质是论文优化的是资源利用率但真实账单里网络也是成本。我在写生产环境方案时经常遇到这种情况——纸面上算 GPU 利用率提升了不少把流量费、带宽占用费、跨区专线费一填进去结论就翻转了。所以读到这一类跨节点方案我的习惯是先把自家的价格模型做成一个小表把网络项填进去再决定是否跟进。4. 实验与评估这半场论文最让我不放心的地方4.1 trace 稀缺与负载形状的威力说句得罪人的话serving 论文的实验部分是所有系统方向里最不好做的也是最容易藏问题的。同一个系统面对平均 200 token 的短对话和平均 2000 token 的长文总结结果可能差出好几倍。prefill 与 decode 的资源占比完全不同调度策略的优劣也完全不同。本场有一篇论文在官方 benchmark 上非常漂亮但讨论环节承认换了会话型负载后吞吐掉了近一半原因是热加载的 KV 块被意外淘汰。这就是负载形状的威力——一个看似中性的调度策略在某种负载形态下会突然暴露弱点。我读 serving 论文的经验是先看实验部分的三个信息负载是从哪来的、平均长度和长尾长度是多少、有没有构造突发流量。三样都不给的话这篇论文的实验结果参考价值直接减半。4.2 指标清单不要只看吞吐很多团队评估 serving 系统只看吞吐这是个大坑。吞吐高可能意味着 batch 很大、 KV cache 占用很高但单请求延迟可能已经恶化到用户无法接受。本场论文里指标差异也很大我整理了一个对照指标回答的问题适用场景TTFT首个 token 多快聊天、交互型应用TPOT后续 token 稳不稳流式输出、长文本生成吞吐token/s单位 GPU 产出成本核算P99 排队时延抗突发能力生产 SLA这里我特别想强调看 TTFT 一定要把 P50 和 P95 一起看。只给平均值的论文我一律在心里打折。因为 serving 系统的 tail 行为往往决定了用户真实感受尤其是长尾请求被换出导致的 TTFT 劣化平均值根本看不出来。4.3 开源不等于可复现顶会现在都要求开源但源码能跑通不代表结论可复现。GPU 型号、CUDA 版本、网络拓扑甚至 NVMe 固件版本都会影响换页类系统的表现。我们团队之前在内部复现过一个和 TierKV 类似的方案单机实验一切正常但上到 8 卡之后卡在 host buffer 和 NVMe 之间的传输路径上性能和论文差了近四成。后来发现是 PCIe switch 拓扑和论文中的环境差异导致的。所以我现在的习惯是先跑两个针对性小实验一个验证单机稳定性一个故意构造能触发换页的负载确认这两个都过再决定深入复现。这也算是对自己时间成本的一种保护。5. 散场后的判断哪些结论值得抄哪些先放一放5.1 我会带回团队立刻试的三件事第一把 prefill 和 decode 的并发控制从“尽力而为”改成显式阈值。不用做到 ProgressServe 那种完整的进度感知抢占先做一条简单规则当 TTFT 超过某个阈值时强制让部分长流式连接暂停输出、释放 KV 资源给新请求。这个改动在工程上工作量不大但能显著改善短请求的体验。第二在长上下文占比高、显存阶段性紧张的线上业务尝试 KV cache 分层。先只做两层HBM CPU 内存不急着上 NVMe。两层模式没有 PCIe 之外的额外存储层次实现简单很多大多数业务场景的收益已经很可观。第三把评估指标表里加上 P95 TTFT 和成本/token每双周复盘一次。不是为了发论文而是为了让技术决策有数据支撑而不是靠直觉争论。5.2 我不打算复刻的设计跨地域 token 级 prefill/decode 分离我暂时不碰。原因就是前面说的网络成本模型不划算除非团队已经有同城多机房和稳定专线。路由与投机联动也不打算立刻做因为叠加了两套系统的复杂度出了问题排查成本太高。我更愿意把精力花在单集群内部的资源管理优化上。在多数场景里单集群的显存利用率做到 90% 比跨集群搬运 KV cache 省下的钱多得多也稳定得多。5.3 下一届 Session 我想看到的东西走出会场时我最大的感受不是“serving 又来了多少篇”而是这个领域终于开始把操作系统的方法论搬进一个每天都在烧钱的生产系统里。论文里的换页、抢占、路由我大概率不会全部照抄但它们逼我重新思考了一个问题我们在生产环境里默认的调度策略真的比论文里的更合理吗答案不一定是 No但这个疑问本身就很有价值。如果下一届还有 Model Serving 的 Session我最想看到的也许是这三个方向统一资源账本——把 GPU 算力、HBM、KV cache、网络带宽放进同一个优化框架serving 与训练混布——训练低谷期让推理占用换页策略如何利用训练任务的节奏以及一个学术界和工业界都能用的在线负载生成器让论文实验在复现时不至于因为负载定义模糊而各说各话。到那时候这个领域才真正成熟了。