★ FEATURED ARTICLE 拿到Day 1的议程时我第一个圈出来的就是Session 1AModel Serving at Scale。上午第一场座位照例最难抢题目看着克制但懂行的人知道这几个词背后是过去三年系统领域最卷的方向——把GPU上的算力变成token再把token变成账单上的成本。这个session里的每一篇论文本质上都是在回答同一个问题当模型的推理请求像潮水一样涌过来时系统到底怎么才能既扛得住规模又守得住延迟还压得下成本。这篇评述我不打算按议程顺序机械复述每篇论文的摘要而是想从一名推理系统从业者的视角拆一拆这个session里呈现出的共性技术路线、论文之间的隐性对话以及哪些结论值得我们带回自己的工程体系里。对于只做应用层开发、没有深挖过推理系统的朋友这篇文章也能帮你理解为什么SOSP这种老牌系统会议会连续几年把最黄金的session时段留给大模型服务。1. 开场一小时Session 1A 的论文画像1.1 从投稿分布看研究热点进入会场落座之后我习惯性翻了一遍这个session的论文清单。一个很直观的感受是纯训练相关的论文几乎绝迹所有工作都贴着推理服务展开。这其实是个强烈的信号训练阶段的研究已经沉淀进基础设施工具链里了真正让系统研究者睡不着觉的是推理阶段的成本、延迟和利用率这三座大山。从论文分布来看热点集中在几个方向KV Cache的优化与管理、预填充和解码阶段的拆分执行、MoE模型在分布式集群上的调度以及面向SLOService Level Objective服务等级目标的请求调度策略。各个工作切入角度不同但底层逻辑高度一致——大家都在跟GPU的“空闲时间”和“无效占用”较劲。1.2 三篇报告带来的一条主线Session开场后前面三篇报告给我留下特别深的印象倒不是因为它们各自的技术细节多惊艳而是它们串成了一条完整的主线第一类工作解决的是单卡推理的效率问题核心动作是让显存和计算单元在解码阶段尽量不闲着第二类工作解决的是跨卡推理的扩展问题核心动作是让模型参数和KV Cache在集群里被更合理地切分和搬运第三类工作解决的是系统整体的调度问题核心动作是让成百上千个请求在有限的GPU资源里排队、抢占、让路。这三层叠加起来恰好对应了一个生产级推理系统从底层到上层的完整架构。以前我们做系统的人常说“单机优化是基础集群调度是上层建筑”这个session用论文的形式把这个分层逻辑重新讲了一遍——只是底座从CPU换成了GPU从内存换成了显存从磁盘IO换成了HBM带宽。2. 大模型推理的服务化困局为什么SOSP盯上了serving2.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个并发请求的GPUKV 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把模型按层切开适合跨机部署但对延迟更敏感数据并行则在多个卡上各放一份完整模型来处理不同请求吞吐最高但显存开销最大。真正有意思的是MoEMixture 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 TokenTTFT。对于聊天机器人、智能助手这类交互式应用用户等第一个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的老本行。我对接下来的几个会议充满期待也建议做推理系统相关工作的朋友把论文里的调度和缓存思路彻底撸一遍。真正的机会往往就藏在这些看似枯燥的系统机制里。
阅读完成 · 觉得有帮助？
