SOSP 2026 第一天的上午场，会议还没正式开始，过道里已经站了不少人。Session 1A 的标题是 "Model Serving at Scale"，这几年系统界的重磅话题几乎都绕不开它。我选了第一排靠里的位置，想先把五篇论文都过一遍，再决定哪些值得回来之后精读。整场听完，我的第一感觉是：这已经不是"我们怎么把推理部署得快一点"那个时代了，而是"如何把模型服务当成像数据库一样的基础设施来运营"的时代。
先给不熟悉 SOSP 的朋友交代一下背景：SOSP 是操作系统原理领域的顶级学术会议，论文的实用主义和工程含量都相当高，即便你是做纯业务的工程师，也能从中看到一些系统架构的判断。所谓"Model Serving at Scale"，通俗讲就是当大模型广泛部署、请求规模暴涨时，怎么调度 GPU、怎么管理 KV Cache、怎么保证延迟稳定、怎么评估真实的系统表现。过去这类问题大多散落在工程博客里，今年高密度的专用 Session 说明整个社区已经把它当作一个严肃的系统研究子领域了。
1. 这一场 Session 为什么值得从头听到尾
1.1 从 Session 安排看议题走向：Model Serving 不再是 LLM Serving 的附庸
第一观察是名字本身。往届关于 serving 的论文常常被塞进"分布式系统""机器学习系统"等大类的夹缝里，题目也多围绕单一模块。而这场 Session 直接以"Model Serving at Scale"立题，且排在第一天的黄金时间段。这说明该方向已经从"热点问题"变成了"成熟研究线"。现场几篇论文覆盖了调度、存储、解码机制、批处理和评估方法论，像是一个小型的研究生态拼图。
这个转变对听众意味着什么呢？如果你还停留在"跑通了部署脚本就算 serving"的阶段，那么这场 Session 会给一个非常现实的提醒：在规模化场景里，请求的到达模式、GPU 资源池的共享干扰、KV Cache 的内存敏感性、甚至评估用的负载是否真实，都会决定一个系统的最终表现。单独调某一层参数已经很难解决整体服务质量的问题。
1.2 五篇论文的分布，以及我准备怎么看
- 多租户 GPU 池化调度器：核心是利用率、隔离性和 SLA 的三角权衡。
- KV Cache 分层持久化系统：把缓存当成有状态资源来管理。
- 长上下文解码的密集计算解耦：减少非必要的重复计算。
- 批处理感知的模型放置：把通信开销和批处理窗口放一起优化。
- 服务评估方法论与基准设计：解决"我们到底如何比较系统"的问题。
这五篇的关系并不是孤立的。调度篇依赖对负载特征的准确观测，而观测依赖评估方法；缓存篇的效果又直接影响调度的资源账。我认为最合理的读法是先接收每一篇的独立贡献，再横向寻找它们的共同假设，最后把这套假设带回去对照自己的业务场景。
1.3 适合哪些人仔细读这一场
给不同背景的读者一个定位：如果你是刚接触模型服务的工程师，重点看第一篇和第五篇，前者能让你理解资源池的复杂性，后者能让你建立正确的评估直觉；如果你已经在维护推理集群，第二篇和第四篇更贴近你每天面对的缓存管理和多模型混部问题；如果你属于研究导向，第三篇的解耦思路很值得跟着推演一遍。总的来说，整场的难度并不算低，信息密度也比大部分工程分享高很多。
2. 第一篇论文：多租户 GPU 池化调度器如何重新定义"公平"
2.1 问题定位：利用率、隔离性和 SLA 的三角平衡
这篇论文解决的问题，用一句话说就是：在多租户共用一个 GPU 资源池时，调度器如何同时保证资源利用率、租户间的隔离性，以及每个推理请求的 SLA。
大多数做过 GPU 池化尝试的人都体验过那种矛盾：为了利用率把任务混排在一起，结果某个租户的流量突发把另一个租户的 P99 延迟顶了上去；为了保证隔离又只能用大块资源做硬隔离，于是闲置了很多碎片。论文作者把这三点建模成一个多目标优化问题，这一点本身并不新鲜，新鲜的是他们的系统同时引入了两层调度和基于在线观测的优先级反转机制。
2.2 两个让我印象很深的设计选择
第一层调度负责粗粒度的节点级分配，第二层负责节点内部细粒度的时隙与抢占，这个两层的切分可以借鉴传统操作系统的 CPU 调度经验，好处是把跨机决策和机内资源仲裁解耦开，避免调度器成为一个中心瓶颈。第二个选择是"干扰感知的配额管理"：它不只看当前 GPU 利用率，还会通过性能计数器估算共享带来的缓存污染和访存竞争，据此在配额里预留一段"安全边际"。这一点和云厂商里常见的"超卖但保 P99"思路很像，只是他们把安全边际做成了可动态调节的参数。
2.3 实验结论与我的审视
实验部分用了 8 机 GPU 集群和一个专门构造的混合负载：有短请求、长请求、周期性突发，还有明显的请求数量起伏。结果表明在接近 90% 的平均利用率下，租户间的 P99 隔离相较于常见静态分区方案提升了约 40% 左右。这个结果很好，但我后来私下复盘时觉得需要小心一点：调度器自身的决策延迟和重启成本没有完全展开，如果负载本身就是高频小请求，决策开销会吃掉一部分收益。即便如此，把 SLA 和隔离放进调度器内核这个方向是明确的。
2.4 现场讨论里被问得最多的问题
这部分大约三分之一的提问时间花在"安全边际到底谁说了算"上。作者承认安全边际的初始值来自静态配置，依赖一批历史 profiling 数据，一旦请求形态和 profile 差距太远，调度器需要几分钟时间重新估算。另一个质疑集中在抢占逻辑上：被抢占的低优先级请求是否会造成慢启动，作者说他们在同一节点保留了热备份进程，这其实就是拿内存换延迟。它有自己的适用边界，但在真实运维里算是一个可落地的权衡。
3. 第二篇论文：把 KV Cache 变成分层持久化系统，而非内存垃圾
3.1 为什么 KV Cache 会被单拎出来做成系统
如果你接触过推理框架，应该对 KV Cache 不陌生：它随着解码的不断增长持续占着显卡显存，而且释放时机非常影响吞吐。多租户共享一个推理节点时，如果只按请求的到达顺序分配内存，很容易出现显存碎片与暴力抢占，进而造成整个节点的时延抖动。
这篇论文的要点是把 KV Cache 当作有状态块的集合来管理，而不是把它当作一段临时内存。他们的做法是 KV Cache 分层化：热度高的片段留在高带宽显存，低热度片段可以下沉到 DRAM 甚至 NVMe；操作上类似内存分页和缓存替换，但是专门的语义感知版本。这一点在工程上挺关键，因为当前不少部署把 KV Cache 的显存预留当作固定开销，比例经常占到 20% 到 30%，浪费相当可观。
3.2 分层存储与迁移策略的具体做法
系统里维护了块粒度的访问热度表，作者特别提到他们不按 token 也不按整个请求做粒度，而是按"前缀共享的块"——不同请求共享相同系统提示词的部分会合并成一个块。这样设计的好处是热度统计更稳定，而且迁移时不会让正在解码的请求中断。跨层迁移采用异步机制：先把块拷贝到目的层，完成目录项切换，再释放原层空间；这和现代文件系统的迁移没什么两样，但它被封装成了推理框架可以直接调用的库接口。作者团队给 vLLM 和同类 Triton 服务套了一层替换层，整体改动量比我预想的小，可见他们确实考虑了兼容性。
3.3 实验结论里最吸引我的一组数字
他们在长对话机器人负载下，把原本需要固定 20GB 左右的 KV Cache 显存压缩到了约 8GB，同时回源延迟只增加了不到 10%。最大的收益不是省了多少显存，而是节点调度议价的空间变大了：原先一个新请求可能因为显存不足排队几十秒，现在可以把低活度块沉到 NVMe，从排队欠账里腾出位置来。对做线上运维的人来说，这等于多了一类非常灵活的背压手段。
3.4 讨论里的两个异议，我是否认同
第一个异议是 NVMe 寿命与带宽问题，作者回应他们的负载写放大其实很低，因为迁移只发生在块活跃度发生明显变化时，而这种情况占比不大。我个人基本认同这个回应，但也要看业务是否满吞吐长时间浸泡。第二个异议是关于一致性：如果节点崩溃，KV Cache 的持久化层会不会变成恢复障碍？作者的答案是它本来就是重建成本极高的内容，持久化反而能加速恢复。这个回答在现场听到时不算特别完美，但在讨论时间有限的情况下已经足够。
4. 第三篇论文：长上下文解码的密集计算解耦，画面感比指标更值钱
4.1 长上下文场景下的计算浪费
长上下文是现代大模型服务里最大的痛点之一。上下文越长，每个新 token 的解码都要访问并重新处理完整的 KV Cache，计算量和显存带宽都随着序列长度线性增长，很多时候生成一个小小答复却要付出几十万 token 的计算成本。
这篇论文的切入角度很有意思：他们不把 KV Cache 当作一个必须被完整扫描的稠密张量，而是将它视为一个数据源，解码时可以实时决定哪些上下文是真正与当前生成相关的。这样做的画面感很像"把一本书的全文都背下来了，但翻开时只查需要的章节"。他们提出一种双路径解码机制：一条路径做快速的稀疏上下文选择，另一条路径做传统的稠密注意力校准；当稀疏路径被判定为可信时，稠密路径可以跳过大部分计算。
4.2 稀疏路径与稠密路径的合作机制
关键的技术难度在于如何既保证速度又不怕选错。作者的方案是维护一个低秩的上下文索引，解码时先生成一个候选集，再让稠密路径只对候选集做细粒度评估，并根据评估结果判断是否截断后续计算。论文里报告了在超长文档问答和代码理解两类任务上的结果：P99 延迟比基线下降了约 35%，而答案质量在自动评估里几乎没有退化。
4.3 好结果背后的边界条件
我自己比较关心的一个问题是：这种近似方法在"需要精确引用原文细节"的任务上，比如法律条文审查，偏差会不会被放大？作者在实验里加了一组用难点问题搭建的压力集，结果显示质量确实下降了几个百分点。他们在结论里也老老实实地把适用范围限定在流程图解、摘要、对话等对精确度容忍度较高的场景。这点让我对论文加分，因为比许多只报平均收益的工作要诚实。
4.4 现场追问：这种技术是否已经进入生产
有听众直接问作者"你们的系统跑过真实生产流量没有"，作者的回答是：他们在内部试点服务上运行了数千小时，主要放在知识密集型对话场景，确认了计算节省是可重复的，但还没有公开的 A/B 数据。这个回答给我触动挺大，因为它说明一个系统即使再漂亮，距离成为通用基础设施仍然有一段较长的工程距离。不过这并不妨碍我们借鉴它的解耦思路去优化自己的长上下文链路。
5. 第四篇论文：批处理感知的模型放置，先聊成本账再聊算法
5.1 一个成本数字引发的思考
这篇论文的开场给出了一个很有意思的数字：在混合模型部署场景里，仅仅因为模型放置不在意批处理匹配，GPU 资源浪费可以达到 30%，这主要来自请求到达不均衡导致的批处理窗口碎片化。我第一次看到这个结论时的反应是：强调 placement 的论文很多，但把批处理窗口和放置同时建模的比较少。
传统的模型放置算法大多是装箱问题：把模型当作一堆大小各异的矩形，找最少机器装进去。问题在于它忽略了推理批处理的时间维度：两个模型就算显存刚好互补，如果它们的请求峰谷完全错开，那就会在某个时段抢占批处理容量；反过来，两个请求模式互补的模型放在一起，即使显存不那么贴合，整体吞吐反而更高。
5.2 算法设计：从"放哪里"到"什么时候一起跑"
论文提出的算法用一个带时间维度的二维装箱变体来刻画。他们把一天的负载曲线切成时间窗口，每个窗口内的请求到达速率决定可形成的批处理容量；再用一个收益函数计算两个模型放在同一机器时窗口级吞吐的收益与通信损耗之差。求解采用的是在线启发式加定期重规划，频率大概几分钟一次，避免直接被流量突变打穿。
这个收益函数现场没有太多细节，但从结果看，他们在多组混合工作负载下将平均 GPU 利用率提高了约 18%，同时牺牲了不到 5% 的尾部延迟。可能有人觉得 5% 无所谓，但如果你对 SLA 很敏感，这就需要在批处理收益和延迟之间设一条硬性红线，而不是当作软约束。
5.3 跨机通信与批处理窗口的取舍
将模型放在同一机器有利于减少跨机通信，但放在不同机器则可能在批处理能力上更有利，这个取舍需要量化。作者为此假设了一个可估计的通信成本模型：同一批内的跨机调用会插入额外的等待时间，但他们观察到推理框架通常会把多个小通信合并成一个大通信，所以真正损失的是管道气泡，而不是单纯带宽。这个判断和我实际调过的多节点推理经验一致，值得在调试期间专门测量一次。
5.4 我觉得这篇论文最值得抄作业的部分
不是最后的启发式算法，而是他们把"放置"从一个一次性决策改造成了一个持续观测与重规划的闭环。这一点可以直接迁移到任何 GPU 集群管理工具里。模型不是静态的，负载曲线也不是，撇开在线观测谈 placement 算法，最终只会得到一个漂亮的离线实验结果。我在自己团队的集群里，曾经就吃过离线模型的亏。
6. 第五篇论文：评估基准做的是"可复现性"，而不是制造新榜单
6.1 现有评估指标为何越来越不够用
做 serving 系统的人其实都清楚：很多系统论文里的延迟优化数字，换个负载或换个硬件就完全站不住脚。这篇论文的作者把评估本身当作研究对象，他们指出当前大多数评估基准有三大问题：负载不真实、指标不给分位信息、成本指标没有跟服务质量绑定。
他们不是第一个指出这些问题的，但是第一个把这些批评封装成一套标准实验室流程的尝试：包括负载回放工具、P50/P95/P99 的强制报告、GPU 千瓦时计量、以及 SLA 达标率统计。我个人非常喜欢"千瓦时计量"这一点，因为很多性能优化本质上是拿资源换延迟，不算能耗或不算算力成本，很容易得出对生产环境没有意义的结论。
6.2 量化方式的分层：从请求级到集群级
论文把评估拆成请求级、节点级、集群级三层。请求级看完成时间和调度公平性，节点级看批处理利用率和显存生命周期，集群级则看整体吞吐、能耗和故障恢复时间。分层之后最大的好处是可以定位问题到底发生在哪一层：如果请求级差但节点级高，可能是调度问题；如果节点级差但集群级不错，可能只是模型恰好适配了某些机器。
这套分层评估框架听起来没有算法那么性感，但我认为它的价值是长期的，尤其当越来越多的团队开始横向对比不同推理框架时，缺乏统一评估方法让很多结论变成了"实验室里的玄学"。
6.3 可复现性工作对社区的直接好处
他们给出的开源工具箱内置了若干公开数据集，并且在两个推理框架上预先导出了配置文件，保证论文里的实验可以在中等规模集群上直接复现。这点看起来不起眼，实际意义却很大，因为推理系统的实验结果复现难度高，一直劝退了很多想进入这个方向的人。如果明年 SOSP 的 serving 论文都能附带这样的环境，那么整个社区的共同基线会干净很多。
6.4 评审里最尖锐的问题
现场有一位研究者提问说：评估基准一旦被主流团队"采纳"，就很容易变成大家只优化榜单指标的军备竞赛，这和毫无评估又有什么区别。作者的回应要点是：他们把指标定义得足够多，包括能耗和 SLA 达标率，游戏化一个多维指标的空间会被压缩，否则模型换来换去总有一个指标倒挂。这个回答在现场引起不少点头，但也有人私下觉得，只要论文结果是委员会审核的，多维指标依旧可以通过选择性报告来"保平安"。我比较同意后者的谨慎。
7. 五篇论文连成一条线之后，落地顺序我这么排
7.1 把握"Scale"这个词的真实含义
Session 标题里的"Scale"不是指模型参数有多大，而是指集群规模、请求数量、租户数量都大到单机经验失效的那个临界点。五篇论文从不同方向逼近同一个目标：让模型服务在规模化下既高效又可预期。
这里我特别想给刚入系统方向的同学一个提醒：不要以为论文里的洞见都只属于大厂。多租户调度、KV Cache 分层、批处理放置、评估框架，这些思想哪怕用在一个几十卡的中型集群里都能见效。论文的实现和部署量固然有门槛，但内核思想剥离出来都不复杂。
7.2 我认为最稳妥的落地顺序
如果回到自己的团队，我会这样安排优先级：先做评估基础设施，把延迟分层指标和负载回放建立起来；再参照第二篇的思路做 KV Cache 的分层管理，因为它对显存利用率和尾部延迟的改善最直接；之后才是调度器的改造和 placement 算法的迭代。这个顺序的核心是先解决可观测性，再动存储，最后动调度，因为你越早动调度，越难说清楚它是否真的有效。
7.3 我对下一篇同类论文的期待
五个方向里最让我期待的是多节点推理与 KV Cache 全局共享的交汇点。目前大多数工作仍以节点内的优化为主，但长上下文和混合模型都天然驱动跨节点的协同。比如多个节点能否共享某个公共上下文块，翻译成数据库的话就是一种"云缓存"。如果下一届还能看到把这两条线合起来的系统工作，我会毫不犹豫地花一个早上连续读完。
这篇评述并不算会议的全景记录，现场还有不少海报和 Q&A 我没有展开。如果你想跟进，最好的做法是精读自己关心的那篇论文，然后跑一下他们的复现实验，尤其是评估那篇的框架。毕竟系统论文最大的价值往往不在最后的数字，而在你复现过程中踩到的那一串坑。
