拿到Day 1的议程时，我第一个圈出来的就是Session 1A：Model Serving at Scale。上午第一场，座位照例最难抢，题目看着克制，但懂行的人知道，这几个词背后是过去三年系统领域最卷的方向——把GPU上的算力变成token，再把token变成账单上的成本。这个session里的每一篇论文，本质上都是在回答同一个问题：当模型的推理请求像潮水一样涌过来时，系统到底怎么才能既扛得住规模，又守得住延迟，还压得下成本。
这篇评述我不打算按议程顺序机械复述每篇论文的摘要，而是想从一名推理系统从业者的视角，拆一拆这个session里呈现出的共性技术路线、论文之间的隐性对话，以及哪些结论值得我们带回自己的工程体系里。对于只做应用层开发、没有深挖过推理系统的朋友，这篇文章也能帮你理解：为什么SOSP这种老牌系统会议，会连续几年把最黄金的session时段留给大模型服务。
1. 开场一小时：Session 1A 的论文画像
1.1 从投稿分布看研究热点
进入会场落座之后，我习惯性翻了一遍这个session的论文清单。一个很直观的感受是：纯训练相关的论文几乎绝迹，所有工作都贴着推理服务展开。这其实是个强烈的信号，训练阶段的研究已经沉淀进基础设施工具链里了，真正让系统研究者睡不着觉的，是推理阶段的成本、延迟和利用率这三座大山。
从论文分布来看，热点集中在几个方向：KV Cache的优化与管理、预填充和解码阶段的拆分执行、MoE模型在分布式集群上的调度，以及面向SLO（Service Level Objective，服务等级目标）的请求调度策略。各个工作切入角度不同，但底层逻辑高度一致——大家都在跟GPU的“空闲时间”和“无效占用”较劲。
1.2 三篇报告带来的一条主线
Session开场后，前面三篇报告给我留下特别深的印象，倒不是因为它们各自的技术细节多惊艳，而是它们串成了一条完整的主线：
- 第一类工作解决的是单卡推理的效率问题，核心动作是让显存和计算单元在解码阶段尽量不闲着；
- 第二类工作解决的是跨卡推理的扩展问题，核心动作是让模型参数和KV Cache在集群里被更合理地切分和搬运；
- 第三类工作解决的是系统整体的调度问题，核心动作是让成百上千个请求在有限的GPU资源里排队、抢占、让路。
这三层叠加起来，恰好对应了一个生产级推理系统从底层到上层的完整架构。以前我们做系统的人常说“单机优化是基础，集群调度是上层建筑”，这个session用论文的形式把这个分层逻辑重新讲了一遍——只是底座从CPU换成了GPU，从内存换成了显存，从磁盘IO换成了HBM带宽。
2. 大模型推理的服务化困局：为什么SOSP盯上了serving
2.1 从“能跑”到“能规模化收费”的跨越
SOSP历史上审稿标准一贯苛刻，它关注的从来不只是“这个系统能不能跑通”，而是“这个系统的设计思想能不能支撑规模化的部署”。用这个标准去看Model Serving，核心矛盾就浮出来了：模型能跑，和模型能规模化地服务，是两件完全不同的事。
跑通一个推理程序，只需要一张GPU、一个模型权重、一份推理代码，然后对着一条Prompt输出结果。但规模化服务意味着什么？意味着同一个GPU卡上要同时塞进几十个不同长度的请求，意味着用户请求的到达时间是随机的、长度是任意的，意味着系统必须保证P99延迟不超线，同时又把GPU利用率压到接近极限。这两者在传统系统里是天然对立的——你很难一边追求低延迟一边追求高吞吐。
这个session里的论文，几乎每一篇都在试图打破这种对立。它们不再把GPU看作一个简单的“计算盒子”，而是把它拆解成显存、带宽、计算单元三份独立资源，然后分别针对瓶颈做文章。这个视角的转变，是推理系统研究走向成熟的标志。
2.2 KV Cache 与解码阶段的“黄金窗口”
几篇论文里反复出现一个词：KV Cache。这词对很多做上层应用的人来说可能比较陌生，但它是理解整个推理系统优化的钥匙。
简单解释一下：Transformer模型在生成回复时，每个token都要跟前面所有token做注意力计算。如果每次都重新计算前面token的Key和Value，计算量会爆炸。所以主流推理框架会把历史token的K、V缓存下来，这个缓存就叫KV Cache。KV Cache的特点是：越大，模型能处理的上下文越长；但越大的KV Cache，占显存也越多，而且它的增长速度是按请求来的。一个服务着32个并发请求的GPU，KV Cache可能轻松吃掉几十GB显存。
session里有论文专门讨论KV Cache的“动态管理”——不是简单地给它分配固定显存，而是根据每个请求的实时长度、未来可能生成的token数，动态调整保留和淘汰策略。这个思路让我想起内存管理里经典的页面置换问题，只不过现在换页的单位变成了“注意力张量”，而且换页的代价要昂贵得多——一次错误淘汰可能导致整个请求重新计算。论文的实验结果显示，做得好的动态KV管理，能在不损失精度的前提下把服务吞吐提升20%以上，这个收益在规模效应下非常可观。
2.3 预填充/解码分离背后的系统学考量
Session里另一条被反复讨论的技术线，是预填充（Prefill）和解码（Decode）阶段的分离。要理解为什么这值得SOSP级别的论文专门研究，得先看懂两个阶段的计算特征有多不同。
预填充阶段是“高并发、高计算密度”的——你要一次性处理用户输入的一整段Prompt，把它的KV Cache建出来，这时候GPU的计算单元是满载的，但显存占用还不算高。解码阶段则完全反过来：每一轮只生成一个token，计算量小，但需要频繁读取KV Cache，显存带宽成为瓶颈，而且这个阶段要持续很长时间。
把这两个阶段混在一起调度，GPU要么在预填充阶段浪费显存，要么在解码阶段浪费算力。所以现在的做法是，把两个阶段拆开，甚至让它们跑在不同的GPU卡上。Session里不止一篇论文在做这件事，有的专注怎么为分离后的两个阶段分别设计调度器，有的专注怎么解决分离后KV Cache传输的额外开销。这个方向已经不只是学术界的想象，生产框架里已经开始出现类似架构的雏形，但距离一个通用的系统解决方案还有距离，这正是论文工作发挥价值的地方。
3. 分布式执行与弹性调度：规模化服务的硬骨头
3.1 单卡放不下之后：并行策略的组合拳
Session进行到中段，话题从单卡优化滑向了多卡分布式执行。这个转变很自然——今天的开源模型动辄几百B参数，即使量化后单卡也装不下，更别说还要留显存给KV Cache。
论文里讨论的并行策略不外乎那几种，但组合方式上有新意。张量并行（Tensor Parallelism）把一层网络切开分到多卡上，适合卡间通信带宽高的场景；流水线并行（Pipeline Parallelism）把模型按层切开，适合跨机部署但对延迟更敏感；数据并行则在多个卡上各放一份完整模型来处理不同请求，吞吐最高但显存开销最大。
真正有意思的是MoE（Mixture of Experts，混合专家）模型的并行。MoE的特点是每层里有多个“专家”子网络，每个token只激活其中一小部分专家，所以它的计算图是动态的，不是固定切几份就能搞定。有一篇论文直接聚焦MoE推理的专家调度问题，核心思想是：根据当前各专家被token访问的热度，动态决定专家副本在集群里的摆放位置和数量。有点像是给图书馆的书做动态编目——热门书多放几本在离读者近的地方，冷门书存到远处的库房里。这个比喻背后的系统开销可不小，因为专家权重动辄几个GB，迁移一次要考虑通信成本和缓存一致性的问题。
3.2 MoE 模型的调度新挑战
MoE模型给调度带来的麻烦，比论文里轻描淡写的几句要深刻得多。Session里有一张实验图我盯了很久：它展示了不同请求到达模式对MoE专家热度的影响。结果很直观——请求分布稍微偏一点，某些专家的访问次数就是其他专家的几十倍，形成明显的热点。
传统稠密模型不存在这个问题，因为每个token对每层计算的参与权重都一样，负载天然均衡。MoE则把“不均衡”焊死在了模型结构里，调度器的职责就变成了：识别热点专家，提前把它们的副本放到离计算最近的卡上，同时避免让几张卡因为热点专家而成为新的瓶颈。
这其实是一个在线决策问题，而且决策窗口非常短——一个请求在某个专家上可能只停留几毫秒，调度器必须在这么短的时间里决定副本放哪里、迁不迁、迁移过程中请求怎么暂存。有几篇论文的思路是用启发式策略逼近最优解，也有论文试图用强化学习离线训练一个策略网络，再在线推理。以我的经验来看，纯RL方案在真实流量下容易过拟合，反倒是那些结合了真实负载特征分析的启发式方案，工程落地可能性大得多。
3.3 调度器与执行引擎的协同矛盾
Session讨论里，主持人抛出一个让我印象很深的问题：调度器的决策和执行引擎的执行之间，天然存在信息差，怎么办？
这个问题的实质是这样的——调度器希望知道每个GPU卡上正在跑什么、显存还剩多少、KV Cache利用率多高，然后才能做全局最优的请求分配。但执行引擎本身是高度动态的，一个请求在解码过程中会不断消耗显存、改变算力需求，调度器拿到的状态信息大概率已经过时了。信息越精确，调度越优；信息越实时，系统开销越大。这个矛盾跟传统分布式系统的监控-调度循环很像，但在推理场景下被放大了，因为一次调度决策从生效到失效可能只有几百毫秒。
论文里给的解法各有侧重：有的走“分层调度”路线，全局调度只做粗粒度决策，细粒度调整交给每台机器上的本地调度器；有的走“同步屏障”路线，在特定阶段强制所有卡对齐状态，换取决策的一致性。我个人更看好分层调度，因为它在决策质量和响应速度之间的平衡更可控，而且和现有生产框架的架构兼容性更好。
4. 从论文实验看工程判断：吞吐、时延与SLO的博弈
4.1 实验基准和指标里的“小心思”
作为常年被各类论文实验数据“教做人”的人，我对Session里的实验部分看得比系统设计还仔细。论文的实验设计，往往比摘要更能反映作者对真实场景的理解程度。
这次Session里一个值得肯定的共同点是，大家不再只拿吞吐量（Throughput）说事，而是普遍采用“在满足某条SLO约束下的吞吐量”作为主要指标。这个变化很关键。举个例子，一个系统把吞吐做到每秒1000 token，但P99延迟到了10秒，这在搜索引擎里就是个不可用的系统；反过来，SLO给了P99 500毫秒，系统在保证这条线的前提下跑去吞吐最大化，这样的数字才有参考价值。
此外还有论文专门讨论了一个容易被低估的指标——“首次token延迟”（Time to First Token，TTFT）。对于聊天机器人、智能助手这类交互式应用，用户等第一个token的时间就是把控体验的生命线。部分论文的优化策略宁可牺牲一点整体吞吐，也要把TTFT压下来，我认为这个取舍在真实商业场景里是完全正确的。
4.2 生产环境中的多租户与资源碎片化问题
Session里关于多租户隔离的报告，让我确认了一件事：学术界的模型服务研究，正在从“单用户假设”切换到“多租户现实”。
真实的生产环境没有那么多独享集群，往往是多个部门、多个应用共享同一批GPU资源。一个在线助手应用和一个离线批处理任务混在同一个集群里，资源需求完全不同，SLO要求也完全不同。论文里提出了带优先级和配额控制的协作调度机制，让在线任务可以抢占离线任务的闲置资源，但又不至于把离线任务饿死。
这个课题的难度在于资源碎片化——GPU显存的分配粒度不是一个平滑的连续区间，一张80GB的卡，两个40GB的请求塞进去刚好，但如果一个请求要45GB，剩下的35GB就彻底浪费了。Session里有论文尝试用“KV Cache压缩+请求排布优化”来缓解这个问题，把碎片空间重新利用起来。虽然目前的效果还依赖于请求长度分布，但方向是对的，值得做增量研究的团队关注。
4.3 值得带回公司参考的三件事
如果在Session结束后只能带走三件事，我会挑下面这些，它们对任何跑过推理服务的团队都会有直接帮助：
一、有意识地拆分预填充和解码的混合部署策略。不用一步到位实现完全分离，可以先在调度器层面区分两种阶段的计算特征，把预填充请求集中调度到算力强的卡上、解码请求调度到带宽高的卡上，就能获得不小的收益。
二、把“在SLO约束下度量吞吐”作为标准的Benchmark口径。内部压测不要只看QPS和平均延迟，要盯P99、P999，并明确写出SLO的约束条件。没有约束的吞吐数字，CTO不看还好，一看就得出错误决策。
三、关注KV Cache的动态配额管理。很多团队还在用静态方式给KV Cache划分显存，预留多了浪费、预留少了OOM。学一学论文里的动态KV管理思路，哪怕先实现一个最简单的按请求长度调整配额的版本，稳定性也会上一个台阶。
5. 散场后的思考：下一步值得追踪的方向
5.1 从学术原型到工业级系统的距离
Session结束后跟同行交流，大家都有一个共识：这届论文的理论完整度普遍不低，但离落到大规模生产系统，中间还隔着工程化的最后一公里。
比如论文里那些效果惊艳的调度算法，很多是建立在“负载模式已知”“请求长度可预估”的假设之上的。生产环境的流量模式完全不是这样，高峰期和低峰期的负载差异可能超过一个数量级，请求长度更是充满随机性。论文里的离线场景实验做得再漂亮，上了生产还是要做大量的兜底策略，比如排队超时、请求合并、降级方案。我甚至觉得，学术界下一步真正稀缺的工作，不是提出更精巧的算法，而是沉淀一套公开的、能模拟真实流量特征的Benchmark标准。没有这个基础，论文之间的横向比较很难有说服力。
5.2 可观测性、冷启动与长尾效应的沉默成本
Session里很少被直接谈起、但在交流环节被反复提及的，是可观测性问题。论文里的模拟器可以精确知道每一毫秒GPU里发生了什么，但生产环境做不到。我们花了大量精力优化系统的行为，却往往连“系统当前为什么会慢”都很难讲清楚。推理系统的可观测性，特别是KV Cache利用率、显存碎片率、卡间通信等待时间这些细粒度指标的采集和呈现，我认为是被严重低估的研究方向。
冷启动是另一个绕不开的话题。模型服务不像微服务那样轻量启动，一个大模型权重加载到GPU上可能需要几十秒甚至几分钟。为了应对突发流量，就需要常驻“热备副本”，但热备也意味着持续的显存占用。论文里提到的方案偏向于按量调整副本数，但副本扩缩容的时机和速率怎么定，还会持续折磨系统工程师。
5.3 我的参会建议与判断
最后说一点私人化的参会感受。SOSP这种级别的会议，论文本身的含金量当然高，但对我来说更大的收获，是在session间隙跟同行的交流中获得的“系统直觉”。学术论文给的是“最优解”，而工程现实往往只需要“最稳解”——带着论文里的思路回公司，先做小规模验证，再逐步扩大范围，远比一上来就要复现整套paper系统要靠谱。
Model Serving at Scale这个方向，未来两三年一定会继续是系统领域的主战场。这一方面是因为模型能力还在涨，服务压力只会越来越大；另一方面，这个方向完美地踩在计算机系统研究的传统强项上——资源管理、调度策略、并行计算、容错设计，全都是SOSP的老本行。我对接下来的几个会议充满期待，也建议做推理系统相关工作的朋友，把论文里的调度和缓存思路彻底撸一遍。真正的机会，往往就藏在这些看似枯燥的系统机制里。
