企业官网建设流程全解析

SOSP 2026第一天早上的第一场，会场几乎坐满。如果你想判断一个系统方向是不是真的处在大周期里，不用去看投稿数据，只看顶会第一个session的上座率就够了。今年这个位置留给了Model Serving at Scale，这个信号本身已经说明很多事情：大规模模型服务早已不只是MLSys的专属话题，它正在成为操作系统和分布式系统社区的核心战场。这篇文章是我根据现场笔记快速整理的评述，覆盖Session 1A里我印象最深的几类工作、背后的核心技术取舍，以及QA环节值得细品的几轮争论。如果你在做LLM推理部署、GPU集群调度或者AI基础设施相关的工作，这篇应该能帮你省掉不少回放时间。

1. 为什么Model Serving at Scale能扛住SOSP开场？

1.1 系统顶会的变化：从文件系统到AI推理

早年SOSP的经典配方是什么？分布式文件系统、共识协议、内核机制、内存管理、虚拟化隔离。那时候AI相关的paper偶尔出现，但更多是训练系统的分布式优化，比如梯度同步、参数服务器这类话题，且多半是被放在偏后场次的session。今年直接把Model Serving放在Day 1 Session 1A，等于官方挑明了一个判断：推理规模化已经激活了操作系统社区最擅长处理的一整类问题。调度、显存管理、容错、性能隔离、带宽分配，这些OS领域的看家本领在一个新工作负载上重新变得重要。

这不是说MLSys社区过去几年做的事情没有价值，而是说整个问题的重心在迁移。单卡推理引擎层面的优化，比如连续批处理、算子融合、量化推理、投机解码，已经发展得相当成熟。可到了集群规模、多租户、生产级SLO的时候，大家发现瓶颈并不在于某个kernel写得不够好，而在于跨节点、跨请求、跨租户的资源协调。这种"从局部优化到全局系统设计"的转变，恰好是SOSP这类会议最擅长评价的内容。

1.2 规模化带来的系统问题，而不是模型问题

Session开始前主持人给了一个数字我印象很深，具体数值不便透露，但大意是：生产环境一个中等规模的推理集群，一天内要处理的请求量级让KV cache的总占用达到了PB级别。PB级别的中间状态需要被调度、被换入换出、被去重，这已经完全不是"显存够不够装"的问题了。

一旦请求规模上千QPS、集群规模到几百甚至几千张卡、多个业务方共享同一批GPU，问题性质就变了。单卡时代我们关心的是怎么让一个batch跑得更快，集群时代关心的是怎么在保证每个租户SLO的前提下，尽量把GPU利用率和吞吐拉上去。这两者经常是冲突的。你越是做全局分批、做抢占、做动态迁移，对延迟特征的把控就越难。整个Session 1A给我的整体感觉是，这个领域正在从"延续MLSys的优化思路"演变成"回归操作系统的经典问题"，只不过物理资源从CPU内存换成了GPU显存和NVLink带宽。

1.3 Session 1A的论文画像总览

如果给这届Session 1A的论文做个粗糙分类，大概是这样的结构：

这个分布挺有意思。连续两三年大家卷的是单引擎内部机制，到这一届明显开始往集群侧填坑。推理引擎内部的优化空间正在收窄，而集群调度、资源隔离、上游故障恢复这些"系统味"更重的东西，成了新的增量来源。下面的评述我按这四类分别展开。

2. 逐篇评述：Session 1A里让我印象最深的几类工作

2.1 KV Cache管理：从单机页式缓存到分层分布式缓存

这一part我听得最认真。自从vLLM那套PagedAttention把KV cache按block管理之后，大家默认碎片问题在单机维度上算是解决得不错。但这次session里面的工作明显往前跨了一步：KV cache不再只是一个进程内的块分配器，而是被当成一个与内存、存储、网络协同的分层缓存体系来设计。

具体来说，有工作把KV cache按访问热度分成了几层：热数据留在HBM显存里，温数据下沉到CXL内存或者本地DRAM，冷数据放到远端存储。这么做背后的动机很直白，就是单卡显存装不下整个工作集的KV cache。既然装不下，就必须有换入换出，也就必须有admission、eviction、prefetch这三件事。坦白讲，这个思路和十年前的页面置换算法几乎同构，但难点在于新的约束条件：KV cache不是均匀大小的页面，它天然和请求的Attention计算耦合，换出去的代价不是一次缺页中断，而是可能需要重新执行一遍Prefill。

这里有个细节值得琢磨：跨请求共享。不同请求如果共享了相同的前缀，比如同一个System Prompt，那它们的KV cache在物理上就应该复用。session里有篇工作专门做这件事，在block粒度上做引用计数和去重，据说在真实负载下命中率提升相当明显。这种思路本质上跟操作系统里的page sharing是一样的道理，但在GPU内存管理里落地需要解决Lazy copy、失效同步等问题，工程量不小。还有一个争论点在于offload的阈值怎么设：如果是一个TTFT很敏感的交互式请求，KV cache被换出去一次，用户感知到的延迟可能直接从几十毫秒飙到几百毫秒。可如果是一个长文档总结、离线批处理任务，换出去完全无所谓。所以好的缓存策略必须跟请求的SLO分类绑定，而不是单纯按全局命中率做贪心。

2.2 集群调度器：在线推理与离线训练同池共舞

Session 1A里有几篇工作关注的是GPU集群调度。这里的核心场景很现实：你一个大集群里面，白天跑着大量在线推理服务，晚上会穿插训练任务和数据预处理任务；不同业务方之间的请求潮汐还不一样，有的是上班高峰，有的是活动大促。如果在线和离线完全分开部署，GPU利用率上不去；如果混在一起，又很难控制在线请求的延迟抖动。

这些论文的解法大多是"分层调度"的思路。上层有一个中央调度器根据集群状态做资源切分，比如给在线推理预留多少个GPU、离线训练用剩下的多少份额。下层每个推理服务实例内部再用分布式调度把请求分配到具体worker，不同worker之间的负载通过队列长度动态感知。这类设计其实很像OS里CFS和带宽控制给容器做资源限额，只不过现在额度单位不是CPU时间片，而是GPU显存和算力。

比较有意思的是一个关于抢占的设计。在线请求一旦超过SLO预算，调度器可以在毫秒级别把低优先级的离线步骤暂停，把资源让出来。但GPU不像CPU那样可以干净地保存上下文，训练任务被抢占之后的恢复成本很高，所以需要谨慎设计。这篇工作的思路是让离线任务每隔一段时间主动做一个checkpoint，然后调度器利用checkpoint作为抢占点。这个思路应是当前工程上最可行的折中方案，但也意味着离线任务的框架层要做配合改造。

2.3 多租户性能隔离与潮汐流量治理

多租户隔离的论文基本都在讨论同一个问题：一个租户的流量暴涨为什么会把其他租户的P99打穿。原因不难理解，即使是同一个GPU实例，不同请求共享的SM、显存带宽、NVLink带宽都是有限的，一个租户的大batch会迅速撑爆内存，另一个租户的短请求就得排队等资源。这和传统云计算里的邻居噪音问题高度相似，但GPU推理场景下更敏感，因为单batch的延迟不像CPU上下文切换那样有明确的毫秒级预算。

session里有篇工作直接引入了"性能预算"的概念。每个租户不是一个垂直绑定的固定资源池，而是拿到一个SLO延迟预算，调度器动态判断当前价格范围内允许它使用多少资源份额。预算超了的租户，调度器会主动把它的一些请求迁移到其他有空余的节点，或者限制它的并发上限。这种边界的制定过程其实挺复杂的，因为"公平"在这种场景下没有标准答案——是按请求数公平，按token数公平，还是按GPU时间公平。现场有个提问非常尖锐：如果按token数公平，短请求多的租户天然吃亏；如果按请求数公平，长上下文任务又会被故意拖慢。不同定义的公平会直接影响业务方的计费模型和体验，这不是纯技术能拍板的。

另外我看到一个细节，他们的隔离手段不只是调度，还包括内核级和网络级的配合。比如对特定租户的kernel执行时间做限制，或者通过优先队列让低优先级租户的请求走慢车道。这已经是很典型的OS带宽控制思路了，只不过落地在CUDA driver层而已。量产想落地得好，必须得有配套的监控，能按租户维度看到SM占用、显存占用、排队时长这些细分指标，否则完全无法解释隔离策略为什么生效或者失效。

2.4 PD分离与"推理即分布式系统"

这次Session 1A里的一个高光部分是关于PD分离的讨论。所谓PD分离，就是把Prefill请求处理和Decode请求处理放到不同的GPU节点上。之所以值得单独评述，是因为它彻底改变了推理系统的部署形态。

从算力画像上看，Prefill阶段要处理很长的输入序列，计算密集，GPU利用率高；Decode阶段是逐token生成的，每一步都很大程度受显存带宽限制，算力反而不饱和。如果两者放在同一个卡上，混合执行时的潮汐现象会让系统很难做到每一类操作都吃满硬件。拆开之后，Prefill集群可以用高算力卡，Decode集群可以用高带宽、大内存的卡，两类资源弹性伸缩互不干扰。有paper给出的综合收益可以达到量级化降低成本，当然具体数字取决于负载模型。

PD分离真正复杂的地方在做分布式系统的那些事：当一个请求来到网关，网关需要决定把Prefill调度到哪台机器；Prefill完成后生成的KV cache怎么传给Decode节点；如果目标Decode节点正忙，能不能改路由到另一个节点，代价如何。这听起来像负载均衡，但牵扯的是大块KV cache的迁移，动不动就是几百MB到GB级别的数据。session里有篇工作专门优化这个传输过程，把KV cache做压缩和分片之后走RDMA直通，实测下来的传输时延已经可以被纳入调度决策了。还有个让现场很兴奋的点是，PD分离之后可以把同一批请求的共享显存位置设计得更灵活，比如把热门前缀的KV cache直接放在一个专门的前缀缓存池里，Prefill节点只负责冷请求，热请求直接去缓存池加载。这个设计和前面KV cache分层的思路正好合上了。

3. 从Session 1A读出的几条技术主线

3.1 内存墙取代算力墙

把这一个session的所有报告串起来看，最明显的主线是"内存"取代"算力"成了第一公民。几乎所有论文的核心约束都是KV cache和模型权重在多层存储之间的移动成本。Token生成过程是内存带宽密集型的，这在推理优化圈早就是常识，但这一次它终于真正反映到系统架构设计里：从单卡内的block分配器，到跨卡、跨节点的缓存层级，再到考虑存储介质的价格与延迟，整个系统的资源抽象开始围绕"KV cache在哪里、怎么更快搬过去"来组织。

这种转变的影响是比较深的。以前做系统优化，我们习惯的是"计算往数据靠"，比如算子融合，让数据在寄存器里多待一会儿。现在则是"数据往计算靠"——模型权重放显存里是固定的，但KV cache是可变的、动态的，它应该被放在离计算最近的地方，放不下的时候怎么降级、怎么淘汰、怎么预热，这些才是真正决定用户体验的部分。如果你还在用单一GPU利用率来评估自己的推理系统，这个session会给你一个很强的信号：带宽利用率、缓存命中率、迁移开销，往往是更重要的指标。

3.2 SLO从口号变成硬约束

第二个很明显的主线是SLO开始进入系统设计的约束条件里。过去聊推理性能，大家习惯于说Throughput多高、QPS多少，但现在论文里大量出现TTFT和TPOT的P99约束。TTFT是首token延迟，用户发出请求到看到第一个token的时间；TPOT是每个token生成的间隔时间，直接决定输出速度的感知。在多租户、混合负载场景下，调度器除了做资源分配，还必须在约束求解的框架下决定请求优先级、抢占对象与缓存预留。

有一个报告我特别关注：调度器并不追求笼统的最优吞吐，而是按照每个请求的"延迟预算"动态调整batch。比如某个客户愿意接受较长TTFT，那调度器就把他塞进大batch，用高吞吐的模式服务；另一个客户要求首token在多少毫秒内返回，调度器就减少它的batch尺寸，甚至直接预留一小块显存区域。这种做法看起来会增加系统调度的复杂度，但它带来的收益是明确的可预期性。我自己的经验是，没有SLO约束的调度器，在面对突发流量时很容易沦为纯直觉驱动的管理工具，有了SLO维度，你会迫不得已把工作负载的分位数特征摸清楚，后面做容量规划也顺手很多。

3.3 可观测性成为基础设施

session里出现了一个高频词汇：profiling。这不是说大家不会做性能分析，而是说推理系统的可观测性维度在变化。以前我们看GPU util、显存使用、每秒请求数这些粗粒度指标就够了，现在被反复强调的反而是更细的维度：KV cache命中率、PD节点队列长度、Prefill与Decode资源的配比水位、每token生成时间在不同batch大小下的变化曲线。

有一篇论文甚至提出了一个"token级延迟剖析"的框架，把一次请求从进入网关到返回最后一个token的全链路延迟拆解成十几个阶段，每个阶段对应一块可优化的系统组件。这种做法切中了工程上的一个真实痛点：很多系统性能问题并不是某个单点慢，而是分布式交互过程中的等待时间被隐藏了。没有准确的阶段级剖析，你根本不知道调度延迟和传输延迟各占多少，也就没法做针对性优化。它和过去分布式追踪的思路一脉相承，但把"延迟"的单位从"请求"细化到了"token"。

3.4 模型层与系统层的协同优化

Session里模型与系统结合的论文数量在增加，最典型的是投机解码和大模型批处理调度的协作。以往投机解码是模型侧的技术，做法是大模型前面挂一个小模型，小模型先草拟多个token，大模型一起验证。问题在于，小模型草拟的token是串行的，放在集群调度里看，它把一个batch内的请求拆成了两个不同性质的子任务——一个低精度快速生成、一个高精度批量验证。如何让这两种任务在GPU集群上合理共享资源，成了一个系统问题。

还有论文在讨论early exit与SLO的结合：某些请求对质量要求不高，可以提前退出并返回结果。这个思路过去被认为是模型侧的投机行为，但在这届session里，早期退出被当作调度器的策略选项来设计——调度器根据当前队列负载决定哪些请求可以降级到低模型层数。这种跨层优化的趋势，会改变我们对系统边界的理解。系统层不再只是被动地调度一个黑盒模型，而是开始理解模型的内部结构，利用它来创造调度上的自由度。

4. QA环节的几个硬核争论

4.1 远端KV Cache到底值不值？

这是QA环节最激烈的一轮讨论。反对者认为，KV cache访问路径上多一跳，延迟就多几十微秒，对于交互式场景是致命的。尤其当走RDMA访问远端节点时，虽然带宽够，但往返延迟累积起来很难看。支持者的反驳是：命中率高的热数据根本不需要从远端拿，通常只在cache miss时才触发远端访问，此时多出来的几十微秒远小于重新跑Prefill的几百毫秒。

现场给的折中方案是"分级缓存"——GPU本地放最热的KV cache，第二热放本地DRAM或CXL内存，最冷的才放远端。关键是每一层之间的延迟差要覆盖迁移成本。坦率讲，这个动态分层在实现上确实复杂，但它的方向是对的。我个人的判断是，随着CXL内存池化走入数据中心，这种分层会成为推理系统的标准配置。如果你的服务主要是短会话、热前缀、交互式为主，本地容量够用，远端的好处不大；但如果是长上下文、批处理、冷启动流量高的场景，远端缓存的意义会非常明显。

4.2 PD分离后的容错与故障恢复

PD分离被现场很多人看好，但有个问题被反复追问：Prefill节点宕机怎么办。它不像单机推理那样重启进程就行，一旦Prefill节点挂了，所有正在等待这个节点生成KV cache的在线请求都会受影响。如果你已经把它生成的KV cache发给了Decode节点，对方那块的上下文数据也要处理。恢复的时间很大程度上决定SLO能不能守住。

有论文提出了一套基于日志和检查点的方案，让Prefill节点定期把中间状态落盘，故障后按请求优先级重建缓存。现场讨论的结论是：重建顺序不应该按FIFO，而应该按剩余SLO预算排序，先恢复那些即将超时的请求。这其实是在提醒大家，PD分离在带来资源弹性的同时，也引入了更大的故障面，部署前必须把故障恢复流程当作一等公民来设计，而不是上线后出了事故再补。

4.3 评测方法论：你的负载模型可信吗？

QA环节里另一个反复出现的争论是评测基准。大量系统的优化效果是在公开负载上测的，但真实生产负载的请求长度分布往往是重尾的：大多数请求短，但大量算力和KV cache被少数长请求吃掉。这种分布对调度策略极其敏感，你在合成均匀负载上测出来的平均延迟，放到生产环境里可能完全不准。

现场有人提议建立一个统一的推理集群基准，既要包含标准化的合成负载，也要允许把真实trace脱敏后跑进来。我对这个方向的期待很高，因为AI Infra领域现在最缺的就是"可对标的、可复现的"评测环境。大家各自报数字，彼此无法验证，这对整个行业的技术沉淀是不利的。如果SOSP能推动一个公开的推理评测集出来，价值不会低于会议本身。

5. 这些讨论对一线工程团队的直接启示

5.1 四个能立刻动手的改进

作为一个常年做AI Infra的人，session结束后我把笔记里的内容对照自己的项目过了一遍，发现有四件事不需要等会议论文的原型系统落地，现在就能动手做：

• 把KV cache管理统一打到block粒度，告别连续大块分配，这能从根本上解决碎片导致的有效显存缩水。
• 对常用System Prompt做前缀缓存的共享和引用计数，命中率往往高得惊人，工程回报比想象中大。
• 给线上推理服务加上TTFT和TPOT的P99监控，先把SLO量化出来，再谈调度优化。
• 把在线推理和离线任务放到同一个调度框架下管理，哪怕先做并行队列，不强制混部，也能为后续的潮汐调度积累数据。

这四件事启动成本都不高，但每一步都是朝着session里讨论的大方向前移动。最忌讳的就是听完觉得很牛，回去继续只盯单卡优化。反过来讲，如果集群规模还没到一定量级，也不用盲目套PD分离和分层调度，先把数据量级跑起来再演进，基础设施的改造永远要等真实负载来验证。

5.2 出现频率最高的系统取舍

Session里被反复拿出来对比的取舍，其实可以整理成一张决策对照表，供不同业务阶段的人参考：

没有绝对正确的答案，核心思路是：先识别自己最痛的那个指标，再去选对应的方案。很多团队的问题是每次都想着上最全的架构，结果复杂度把团队拖垮了，收益完全没兑现。

5.3 我预判的下一届热点

Session结束后我跟几位同行聊了聊，大家比较一致的预判是，下一届会冒出三个新热点。第一个是Agent工作负载的调度。Agent会频繁做工具调用和多轮交互，请求的长度和上下文模式与传统对话差异很大，系统需要为"计划-执行-观察"这样的循环行为设计新的缓存和调度策略。第二个是更细粒度的异构内存调度。包括HBM、DRAM、CXL、SSD在内的多级存储会成为推理系统必须面对的现实，怎么把它们组织成一个对上层透明的资源池，会催生很多新的系统设计。第三个是更多网络侧的卸载，比如用DPU和可编程交换机做负载均衡和KV cache转发，把CPU从数据通路里解放出来。这些方向在这个session里都有人点到，只是还没有完全铺开。

写在最后

这次Session 1A给我最大的启发不是某个系统夺冠，而是"推理系统正在重新变成操作系统"这个话题成了全场共识。无论是缓存分层、多租户隔离还是故障恢复，本质上都是OS领域吃过一遍的苦，只是这次迎来了一个新的工作负载和一套新的物理约束。我后面给团队的建议都很直白：别急着上最炫的架构，先回去把显存分配的账算清楚，把SLO监控补齐，再把负载的长尾特征摸透。基础工作做扎实了，论文里那些高阶方案才有落地的基础。

最后再分享一个现场听到的观点，session快结束时一位讲者说了一句话："Your cache is your destiny."（你的缓存决定了你的命运）。当时全场都笑了，但冷静想想，这句话可能是整场session里最实在的总结。如果你只能从这篇文章带走一个判断，那就是：把KV cache当作和你应用一样重要的一等公民来看待，所有的调度、隔离、容错设计都围绕它展开。未来的推理系统，决胜点大概率就在这里。