← 返回 PaperDaily 大模型与智能体

微软研究院新作：LLM扩缩容告别“整模型复制”，GPU最高省36.3%

大模型推理集群的GPU浪费有多严重？这篇来自微软研究院、莱斯大学的系统论文，把扩缩容的“最小颗粒度”从整个模型打碎到单个算子，用毫秒级弹性换回最高36.3%的GPU节省，在A100和GB200集群上都验证了效果。做LLM infra的读者值得细读。

龙哥读论文发布于 2026-08-17 00:20:13 阅读 4 查看原文

#大语言模型 #模型架构 #AI应用

原论文信息如下：

论文标题:
OPSCALE: Operator-level Provisioning and Autoscaling for LLM Serving

发表日期:
2026年08月发表单位:
莱斯大学（Rice University）、微软研究院（Microsoft Research）、微软Azure Research 原文链接:
https://arxiv.org/pdf/2608.13499v1.pdf 开源代码链接:
https://github.com/GeeeekExplorer/nano-vllm（项目基于Nano-vLLM构建，该仓库已开源）

在开始今天的内容之前，先聊一个让所有做大模型基础设施的人都头疼的问题：GPU集群的利用率，为什么总是上不去？

引言：大模型服务的算力焦虑与SLO困境

模型级与算子级LLM服务对比

在线大模型推理如今是云基础设施中最吃算力的负载。服务商需要在“满足用户对首个令牌时延（TTFT）和令牌间时延（TBT）的严格SLO”和“尽量少买GPU、少耗电”之间反复横跳。这个矛盾有多尖锐？论文里引用了来自全球云厂商的数据：如果按P95峰值需求静态预留GPU池，纯文本负载的GPU利用率只有50%，多模态负载更是低到39%。换句话说，为了扛住偶尔的流量尖峰，你将近一半的GPU在闲逛。

业界的主流解法是SLO感知的自动扩缩容，比如DynamoLLM、AIBrix和vLLM Production Stack。这些系统的做法很统一：以整个模型为最小单位，在流量上来时复制一份完整模型到新GPU上，流量下去时再缩回去。听起来没啥毛病，但细想全是问题。

生产LLM推理流量的突发性。即便在10秒级别的扩缩容窗口内，聊天服务和代码服务的峰值/谷值流量比平均仍分别超过2倍和5倍

第一个问题是慢。加载一个完整的70B模型到新GPU上，哪怕用上业界最先进的手段，平均也要超过10秒。可LLM流量尖峰的出现是以秒甚至毫秒计的。等你把模型副本拉起来，流量早就变了形状，结果要么是SLO违约（用户等得不耐烦），要么是GPU继续空转（扩了白扩）。

第二个问题是粗。一个LLM推理过程本质上是一张又深又宽的数据流图，里面有注意力算子、线性变换算子、归一化算子等等。不同算子的计算特性和资源口味完全不一样，强行把它们捆在一起按同一个节奏扩缩容，结果就是：真正卡脖子的算子没吃饱，不卡脖子的算子反而撑着。

图3：扩缩容延迟越大，错过生产环境中短时流量波动的比例越高

从模型级到算子级：LLM服务扩缩容的新范式

既然整模型扩缩容又慢又粗，那如果把缩放的单位从“整个模型”细化为“单个算子”呢？这正是OPSCALE的核心思路。打个比方：以前为了给厨房加个烤箱，你把整个房子都重新盖了一遍；现在你只需要在厨房里加个烤箱就行了，卧室客厅该干嘛干嘛。

把缩放单位从模型降到算子，能同时解开两个死结：一是资源分配可以精准到瓶颈算子，不再为所有算子平均加菜；二是弹性时延可以做到亚秒级，因为只加载单个算子的权重和配置，比加载整个模型快一到两个数量级。

但想法很美，落地很痛。算子级扩缩容面临两个核心系统挑战。第一，到底该扩哪个算子？瓶颈是动态变化的：短序列时线性算子（比如各种投影、MLP）是计算主力，长上下文时注意力算子的O(L²)复杂度会让它瞬间变成头号瓶颈；而且不同算子对扩缩容动作的反应也不一样，给归一化算子加副本基本是浪费内存。第二，扩出来的算子副本放在哪？单独占一张卡会浪费资源还增加跨设备通信，跟别人挤在同一张卡上又可能因为争抢SM、显存和互联带宽而互相干扰。这需要一套能感知互连拓扑、能建模细粒度争抢的放置算法。

算子异质性：揭开LLM推理的资源效率之谜

为什么模型级扩缩容浪费严重？因为LLM推理本质是一张算子数据流图。一个标准的Transformer解码层里，有做矩阵乘法的线性算子（Linear）、有算注意力分数的Attention算子、有做归一化的RMS Norm算子，还有各种激活函数算子。它们在一次前向推理中各自扮演不同角色，对计算量、显存占用、通信开销的“口味”差异极大。

图4：不同模型架构中各算子对序列长度的计算与内存敏感性。横轴为内存增长，纵轴为计算时间增长，左到右分别测量序列长度128到64K，y=x虚线表示随序列长度线性增长

这张图透露了很多关键信息。首先，Attention（注意力）算子的计算时间随序列长度呈二次方增长，远超那条y=x的线性参考线；而MLP、线性投影等算子基本贴着线性增长线走。这意味在长上下文场景下，Attention会成为绝对的计算瓶颈，而其他算子的计算压力增长相对温和。如果此时对整个模型做扩容，相当于为了照顾Attention一个人的胃口，给全公司人都加了一碗饭。

再看内存维度，Attention的内存增长同样恐怖，几乎贴着二次方曲线走（虽然论文里用的是FlashAttention，避免了显式的O(L²)注意力矩阵，让内存增长近似线性，但依然比别的算子陡峭得多）。而像reshape_and_cache这类算子，内存占用很平稳，几乎不随序列长度变化。图5进一步展示了各算子对batch size的计算敏感性。

图5：不同模型架构下各算子对批大小的计算敏感性。每条线代表一个不同的算子

从这张图能明显看到，不同模型架构的算子敏感性曲线分散程度差异很大。Qwen2-7B和Llama3-8B这类稠密模型的曲线比较集中，而Qwen2-57B-A14B和Mixtral-8x7B这类MoE（Mixture-of-Experts，混合专家）模型的曲线则分散得多。算子敏感性越分散，算子级扩缩容的收益空间就越大——因为你能更精准地对瓶颈算子单独下手。

论文还做了一组很有意思的跨维度分析，把每个算子的计算敏感性和内存敏感性放在同一个坐标系里观察，如图6所示。

图6：Qwen2-7B中不同序列长度下各算子的平均计算-内存敏感性对比

从图中可以看到几个有趣的聚类：Attention算子是计算敏感和内存敏感的双料冠军；RMS Norm算子则是内存敏感但计算极轻；还有一些算子两边都不敏感，属于“路人甲”型。这种二维异质性意味着，在做扩缩容决策时，必须同时考虑算子在计算和内存两个维度上的不同特点，单纯看某一个维度都会做出次优决策。

此外，论文还研究了算子对SM（Streaming Multiprocessor，流式多处理器）核心分配的敏感性，这直接关系到算子能否高效地共享GPU资源。对于长序列（例如2K tokens的prefill阶段），减少SM分配会显著增加算子延迟；但在短序列decode阶段（1个token），几乎所有算子的SM利用率都不高，减少SM分配的影响很小。这个发现为GPU空间共享提供了有力支撑——短序列场景下，多个算子完全可以在同一张卡上和谐共处。

算子级扩缩容的收益有多大？先从理论算一笔账

光说“算子级更好”还不够，得用理论模型量化出收益，OPSCALE才站得住脚。论文把一个LLM推理过程建模成算子DAG（Directed Acyclic Graph，有向无环图），每个请求都要经过多轮迭代：第一轮是prefill（预填充），处理完整输入序列；后面每一轮decode（解码）生成一个输出token。用户的TTFT（Time-to-First-Token，首令牌时延）和TBT（Time-Between-Tokens，令牌间时延）SLO，分别对应prefill和decode阶段单次迭代的延迟上限。

那么问题来了：给定流量特征（到达率、序列长度分布等），如何为每个算子配置合适的副本数、张量并行度、batch size和放置位置，使得总GPU资源占用最小且满足端到端SLO？论文把这个算子级扩缩容的优化问题形式化为一个多目标整数非线性规划问题。核心的目标函数是让所有逻辑分片副本的总需求最小化：

其中Pν表示算子ν的张量并行分片数，Rν表示副本数，遍历模型内所有算子。这个式子的含义很直白：算子级扩缩容的目标就是精确满足每个算子的资源需求，不多给、不少给。

但要真正求出可行解，还得考虑SLO约束。单次迭代延迟必须小于SLO阈值：

其中Tν是算子的计算时间，Cν是向下游算子通信的时间，Wν是在该算子上的排队等待时间。这个式子把一次推理的延迟拆成了三个可量化的组成部分：算得多久、传得多久、等得多久。单算子排队等待时间可以通过M/M/Rν队列模型来估计：

其中λ是请求到达率，μν是算子的服务速率（等于1/Tν），C(Rν,ρν)是Erlang-C公式（爱尔兰C公式），用于计算排队论中所有服务器繁忙的概率。这个模型让OPSCALE能够在流量变化时快速预估当前配置是否还能满足SLO，以及需要调整哪些算子。

基于这套理论模型，论文做了系统的收益分析。用生产环境流量trace驱动性能模型，对比模型级配置和算子级最优配置，结果如图8和图9所示。

图8：不同序列长度下算子级扩缩容的收益对比；图9：不同QPS下算子级扩缩容的收益对比

图8与图9：不同序列长度与QPS下，算子级相比模型级扩缩容的收益对比（蓝色为GPU设备节省、绿色为能耗节省、橙色为内存节省）

先看图8（不同序列长度下的收益）：GPU数量节省在序列长度4K附近达到峰值——稠密模型约30%，MoE模型约40%。序列长度超过8K后，计算负载增长开始饱和SM核心，共享机会减少，GPU节省有所回落，但内存节省反而一路走高，在32K序列长度时超过60%。为什么？因为Attention算子的内存随序列长度增长最快，算子级扩缩容可以只给Attention加资源，而不用动其他算子。

再看图9（不同QPS下的收益）：GPU节省在QPS=40附近达到约30%的峰值；能耗节省在高QPS下最高可达25%；内存节省随QPS持续增长，在100 QPS时超过50%。理论分析还显示，模型越大、算子越多样化，算子级扩缩容的收益越高。Qwen2-72B这种大模型的能耗和内存节省都能达到50%左右。

OPSCALE系统设计：如何把算子级弹性变成现实

理论收益让人心动，但把理论搬进现实需要解决两大工程难题：空间爆炸和组合爆炸。

先说空间爆炸：要精确刻画每个算子的行为，理想情况下得在batch size、序列长度、SM分配比例的三维空间里做穷举式剖析。以batch size范围1到256、序列长度1到64K、SM比例1%到100%为例，每个算子要测约10⁷种配置。即使每次微基准测试只要100毫秒，剖析一个有11种不同算子的0.5B参数模型也需要数周GPU时间，这显然不现实。

再说组合爆炸：找最优算子配置是个NP难的整数非线性规划问题，搜索空间随算子数量和各配置维度组合式增长。暴力求解器哪怕对0.5B的小模型都要跑几分钟，而生产流量要求秒级决策。

OPSCALE用三个关键手段在保证决策精度的同时化解了这两个爆炸问题。整个系统架构如图11所示。

图11：OPSCALE系统架构总览。系统分为控制平面与执行平面，控制平面由算子剖析器（Operator Profiler）、算子供给器（Operator Provisioning）和算子放置器（Operator Placement）三个模块组成；执行平面由副本管理器（Replica Manager）统一调度

稀疏采样剖析：大幅压缩剖析空间

论文观察到一个重要规律：虽然不同算子的敏感性曲线形状各异，但大部分曲线在batch size和序列长度维度上都是单调的。既然如此，就没必要穷举所有点，只需在(B, L)空间里随机采样少量点，再用分段插值法补齐未采样点的行为即可。插值法是非参数的，不需要训练，实现简单且计算开销小。

更妙的是，Transformer架构具有结构等价性：Attention、MLP这些算子在模型的不同层甚至不同模型之间是完全相同的结构。这意味着一个模型上剖析得到的算子画像，可以直接复用到其他同架构模型上。论文表示，配合并行采样，数十亿参数规模的模型在一小时内就能完成剖析。

两阶段供给：避开组合爆炸的最优解逼近

面对NP难的最优配置问题，OPSCALE采用一个两阶段贪心算法。第一阶段初始化：沿用模型部署策略的初始并行度配置，为每个算子扫描可行batch size，找出满足当前到达率所需的最小副本数，得到一个局部最优的baseline。第二阶段迭代优化：计算每个算子在当前配置下的“SLO贡献度”或“性能缺口”，优先对缺口最大的算子增加资源，直到所有算子都满足SLO。

论文通过理论分析证明，这个毫秒级的贪心启发式算法得到的资源成本，与离线最优oracle的差距在8%以内。换句话说，用不到最优解1%的计算时间，换来了92%以上的最优性，这买卖非常划算。

争抢感知的放置：算子共享GPU的艺术

最后是放置问题。把扩出来的算子副本放在哪张GPU上？放在独立GPU上会浪费资源并增加通信开销，与别的算子共享GPU又可能引起SM、显存、互联带宽的争抢。OPSCALE的设计思路是“能共享则共享，共享不了就分开”。它根据算子的SM敏感性、显存占用和通信拓扑，把多个算子副本编排到同一张GPU上，同时用争抢模型预估对彼此性能的影响。论文还利用了CUDA Green Contexts这样的GPU空间共享技术，可以为不同算子流分配不同数量的SM核心，实现硬件层面的隔离。

图12：OPSCALE控制平面由算子供给与算子放置两个核心模块组成

执行层面，OPSCALE采用集中式的副本管理器（Replica Manager），统一维护算子副本的生命周期，同时充当请求分发器。与模型级路由（把请求分配给某个完整的模型副本）不同，OPSCALE的请求会依次流经多个算子副本池：每个阶段从本阶段的副本池中汇总输出，然后把激活值转发给下一阶段的算子。路由采用带权最短队列策略，会考虑SM分配和共置争抢等因素，避免把请求都怼到某个繁忙的副本上。

关于实现，OPSCALE的工程基座是Nano-vLLM——一个仅用约1200行Python代码实现的轻量级vLLM框架，已在GitHub上开源（拿到15K star）。Nano-vLLM集成了前缀缓存、张量并行、Torch编译和CUDA图等优化技术，代码简洁易懂，非常适合二次开发。OPSCALE正是基于这个轻量级框架做的系统扩展，才能够在工程上快速实现算子级的剖析、供给和放置逻辑。对想深入理解或复现这篇论文的读者来说，Nano-vLLM的代码确实是绝佳的切入点。

实验验证：GPU节省36.3%，功耗降低28%

理论模型再漂亮，最终还得看硬核实验。OPSCALE在最高40张NVIDIA A100和24张GB200的集群上做了系统评估，对比对象包括DynamoLLM、AIBrix和vLLM Production Stack这三个当前主流的模型级推理扩缩容平台。测试覆盖了文本、视觉、稠密和MoE等多种模型架构，用生产环境trace驱动（处理了92.9万条请求和15亿个token）。

表3：论文特性研究与评估中使用的模型列表，涵盖稠密LLM（Qwen2-7B、Llama3-8B、Qwen2.5-VL-32B）与MoE模型（Qwen2-57B-A14B、Mixtral-8x7B）

先看最直观的对比实验。以Qwen2-7B为例，在相同的流量驱动下，同时记录模型级扩缩容与算子级扩缩容两种方案的请求性能（P99 TTFT）、GPU用量与集群功耗随时间的变化，结果如图13所示。

图13：Qwen2-7B自动扩缩容过程中请求性能（P99 TTFT）、GPU用量与集群功耗对比。可以看到在保持P99 TTFT均满足SLO的前提下，OPSCALE（蓝色曲线）的GPU用量和集群功耗明显低于模型级方案

在模型级方案还在慢吞吞地加载整个模型副本时，OPSCALE已经完成了对瓶颈算子的精准扩容；在流量回落后，又迅速释放那些非瓶颈算子的闲置资源。这种精细化的调度节奏，让OPSCALE在保证SLO达标率的同时，大幅压低了GPU占用和功耗。

图14：集群级功耗对比。在各类模型与负载场景下，OPSCALE的集群功耗均显著低于基线方案

图15则展示了不同SLO达标率要求下所需GPU数量与能耗的权衡曲线。OPSCALE的曲线整体位于左下方，意味着在同样的SLO达标率要求下，所需GPU更少、功耗更低；或者在同样的资源预算下，SLO达标率更高。

图15：成本与SLO达标率之间的权衡对比

再看对MoE模型（Qwen2-57B-A14B）的自动扩缩容实验。图27展示了类似的结果：在自动扩缩容过程中，OPSCALE的GPU用量和功耗显著低于DynamoLLM基线，同时P99 TTFT保持平稳达标。MoE模型由于算子敏感性分布更分散，算子级扩缩容的优势体现得更充分。

图27：Qwen2-57B-A14B（MoE）自动扩缩容过程中GPU用量、请求性能与总功耗对比

图27：Qwen2-57B-A14B（MoE模型）自动扩缩容过程中GPU用量、P99 TTFT与总功耗对比

更细致的量化结果见图16。在不同QPS条件下，OPSCALE所需GPU数量（图16a）和平均总功耗（图16b）均全面低于三个基线系统。在QPS=40附近，GPU节省达到论文报告的最大值36.3%，同时功耗降低28%。

图16：不同QPS下服务成本对比。(a) 所需GPU数量；(b) 平均总功耗

在固定资源预算下，OPSCALE还能换来更高的吞吐。图17展示了在相同GPU数量配置下能达到的最大吞吐量，OPSCALE比模型级方案提升了最多44%。这对那些被SLO绑住手脚、不敢把负载跑满的团队来说，是个非常实在的利好。

图17：固定资源配置下达到的最大吞吐量对比

论文还单独比较了静态配置场景（无自动扩缩容，固定分配资源）下不同粒度的最优静态配置，结果如图18所示。即使在不做动态扩缩容、只做一次性资源规划的静态场景，算子级粒度依然全面胜出。在A100和GB200两种硬件配置下，OPSCALE静态配置所需GPU数量均低于模型级方案。

图18：不同服务粒度与硬件配置下的静态配置对比

最后，论文还测试了关键超参数对系统的影响。图19左侧展示了扩缩容决策间隔对SLO达标率的影响，右侧展示了SLO目标值的影响。可以看到OPSCALE在较长的扩缩容间隔下依然能保持较高的SLO达标率，说明系统对控制平面的决策频率不敏感，有较好的鲁棒性。

图19：（左）扩缩容间隔对SLO达标率的影响；（右）SLO目标值对系统的影响（基于Qwen2-7B）

总结一下实验结论：在自动扩缩容场景下，OPSCALE比最先进的模型级方案少用最多36.3%的GPU、降低28%的功耗；在固定资源预算下吞吐提升最多44%；在静态配置场景和GB200集群（NVL域互联更快）上收益还会放大。这些数字不是某个单一场景的偶然结果，而是在多种模型、多种流量模式、多种硬件配置下的一致趋势。

实验结果分析：为什么算子级能省这么多？

实验结果本身已经足够亮眼，但更值得琢磨的是：OPSCALE到底靠什么机制省下这些GPU和功耗？龙哥分析下来，核心机制是三个“精准”。

第一个是扩容对象的精准。模型级扩容是“眉毛胡子一把抓”，所有算子一起复制；OPSCALE只扩真正吃紧的瓶颈算子，比如长上下文场景下的Attention。这就避免了为缓解一个算子的瓶颈而复制全部算子的浪费。

第二个是弹性速度的精准。加载单个算子的权重显著快于加载整个模型。论文的Table 1对比了Qwen2-7B上的扩缩容时延，算子级的scale-up时延远低于模型级。更快的弹性让OPSCALE能贴合秒级的流量波动节奏，减少“扩了白扩”和“该缩不缩”的时间窗口。

表1：Qwen2-7B上模型级与算子级的扩展时延对比

第三个是资源形态的精准。GPU上的资源不只是算力，还有显存和SM核心。OPSCALE能根据算子的计算-内存敏感性差异，把“算力型”算子和“内存型”算子巧妙地共置在同一张GPU上，让显存和算力都被充分利用。这种跨维度互补的资源共享，是模型级方案根本做不到的。

实验设计方面，论文设置了自动扩缩容、静态配置、固定预算吞吐量、超参数敏感性等多组实验，覆盖了模型架构（稠密vs MoE）、硬件平台（A100 vs GB200）、流量模式（文本vs多模态）等多个维度，对比对象也都是业内最先进的系统。这样多维度的实验设计，使得结论具有较强的说服力。

有一点需要说明：收益峰值并非在所有负载条件下都能实现。论文的收益分析明确指出，在低QPS（<20）场景，收益几乎为零——此时单个模型实例已经能轻松扛住流量，没必要做精细扩缩容；在超长序列（>8K）场景，GPU数量节省会回落，因为计算负载饱和了SM核心，限制了资源共享的机会。所以OPSCALE的收益是在中等序列长度和中等偏高QPS条件下最明显，这恰好是生产环境中最常见的工作负载区间。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？大模型服务扩缩容粒度太粗，导致GPU浪费与SLO超标。微软研究院等提出OPSCALE，将扩缩容单位从整个模型降到算子级，最高节省36.3% GPU、降低28%功耗，或固定预算下提升44%吞吐。

这篇工作最值得看的点是什么？OPSCALE在满足SLO的前提下，相比模型级扩缩容方法可减少最多36.3%的GPU使用和28%的功耗；在固定成本预算下可提升44%的吞吐量。

这篇工作的边界或风险在哪里？优点：1）提出算子级扩缩容的新范式，突破了模型级扩缩容的粒度限制；2）系统设计完整，包含性能剖析、配置优化、放置和执行四个平面；3）理论分析与实验验证结合，论证充分。缺点：1）系统复杂度较高，实际部署需要大量工程投入；2）对超低延迟场景（如megakernel融合）不适用；3）目前仅支持单模型服务，多租户场景需要进一步扩展。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

提出一种以算子为基本弹性单元的大语言模型服务编排框架，通过算子的细粒度配置、放置和动态扩缩容，实现资源的高效利用和SLO的满足。

实验合理度：★★★★☆

SLO达成率、GPU使用数量、功耗、吞吐量（TPS）、扩缩容延迟

学术研究价值：★★★★☆

提出一种以算子为基本弹性单元的大语言模型服务编排框架，通过算子的细粒度配置、放置和动态扩缩容，实现资源的高效利用和SLO的满足；更关键的是问题定义是否可复用到同类任务。

稳定性：★★★☆☆

现有材料未提供充分的极端条件、重复运行或扰动测试，稳定性暂按中性评价。

适应性以及泛化能力：★★★☆☆

现有材料未完整展示跨数据集、跨场景或分布外实验，泛化能力仍需进一步验证。

硬件需求及成本：★★★☆☆

不适用（本文是系统设计，不涉及深度学习模型训练）

复现难度：★★★☆☆

https://github.com/GeeeekExplorer/nano-vllm

产品化成熟度：★★★☆☆

论文验证以研究实验为主，真实部署中的时延、成本、维护和异常场景仍需补充验证。

可能的问题：1）系统复杂度较高，实际部署需要大量工程投入；2）对超低延迟场景（如megakernel融合）不适用；3）目前仅支持单模型服务，多租户场景需要进一步扩展。

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！