共享LLM服务跨模型自动扩缩容：从资源池视角优化GPU利用率

1. 先看这篇论文在解决什么问题1.1 共享LLM服务的现实场景这两年做LLM推理平台的人应该都有同一种体会模型越来越多但GPU资源永远是紧的。团队里可能同时有7B、13B、70B这几个量级的模型还有不同的量化版本、不同的任务类型。如果每个模型各自部署一套独立服务资源利用率会很惨尤其是长尾模型可能一天里只有几个小时有流量但GPU得一直占着。论文题目里提到的“共享LLM服务”指的就是把多个模型放进同一个服务池里统一管理、统一调度。这和我们常见的“模型网关”有点像但区别在于网关通常只做路由转发并不负责底层副本数量的调整。真正要做到资源高效必须让服务池能够根据实时负载自动伸缩而且是在多个模型之间动态分配资源。这里的核心痛点不是“单模型扩缩容”——那个领域已经有不少成熟方案而是“跨模型”的。比如某个小模型突然来了波流量而旁边的大模型正在闲置系统能不能自动把资源从大模型那边匀给小模型更极端的情况是流量峰值是错开的模型A上午忙模型B下午忙如果它们共享一个池子理论上只需要准备“峰值中的最大值”而不是“所有模型峰值之和”。这篇论文就是围绕这种共享池的扩缩容问题展开的。它研究的不是某个特定推理引擎的优化而是当一个服务池承载多个不同规模的LLM时怎么让副本数量的调整更智能、更及时、成本更低。1.2 为什么LLM服务的扩缩容这么难我自己踩过不少坑先说一个最简单的普通无状态Web服务扩缩容加副本、删副本对已有流量影响不大。但LLM服务不是这样。LLM推理有个很要命的特性就是显存占用是“预分配”的。加载一个7B模型量化之后可能也要占用好几GB到十几GB的显存70B模型更是动辄上百GB。你扩容一个新副本不是启动一个进程那么简单而是要先把权重加载到显存里这个过程可能持续几十秒甚至几分钟。在这个窗口期负载已经打过来了但副本还没就绪。另外LLM请求的耗时波动非常大。同一个模型的输入长度、输出长度对推理时间影响极大。一个请求可能只要0.1秒另一个可能要10秒。这意味着单纯看QPS根本没法定容得看“实际正在处理的请求占用的计算资源”。再叠加“多模型共享”这个条件问题就更复杂了。不同模型的大小不一样7B和70B的推理吞吐差异可能是数量级的。一个服务池里的总显存是固定的如果给7B模型配了太多副本70B模型可能卡在显存不够连启动都启动不了。反过来如果为了迁就大模型留太多冗余小模型的弹性又不够。这就是论文要解决的核心矛盾在共享资源池里如何自动决定每个模型该有多少副本既不能让请求排队太久又不能浪费算力。1.3 已有方案为什么不够用业内常见的做法大概有三类。第一类是“固定分配”管理员手动给每个模型设置最小和最大副本数再配合简单的CPU/内存指标做HPA。第二类是“独占集群”每个模型单独占一批GPU资源互不共享弹性只在自己那组机器上玩。第三类是“排队控制”不管多少副本都靠请求队列来削峰填谷队列太长就拒绝或降级。这三类各有问题。固定分配的问题在于阈值很难定不同模型的负载模式完全不一样手动配出来的效果很差。独占集群的做法最省心但成本最高而且违背了“共享池”的初衷。排队控制只能缓解不能解决资源分配的根本问题——队列可以把压力暂存但当大量请求积压时如果副本数不跟上延迟照样飙升。论文里提的“跨模型自动扩缩容”本质上是在补上这些方案的短板既保留共享池的资源池化优势又用一套自动决策机制替代人工配置同时还能感知每个模型的实时负载和延迟表现。2. 核心思路把扩缩容从“单模型视角”拉回“服务池视角”2.1 整体设计想让你重新理解“负载”我最早接触这类系统时脑子里有个根深蒂固的想法每个模型的流量是独立的我只需要分别看每个模型的QPS然后决定它自己要不要加副本。这篇论文给我最大的启发是它把问题重新定义为服务池的总负载是共享的每个模型只是池子里的一个“租户”扩缩容决策应该站在池子的全局视角来做。这是什么意思举个例子。假设池子里有2台GPU服务器每台能装下1个70B模型或2个7B模型。现在7B模型流量涨了70B模型流量跌了。站在单模型的视角7B模型应该扩容70B模型可能需要缩容。但问题是你的机器上限是固定的如果7B模型的副本已经占满了机器你要扩容就得把70B模型的副本踢掉。这个“踢掉谁”的决策不能只靠看单个模型的数据必须全局算。论文里的核心思路是引入一个“跨模型容量协调器”之类的角色定期采集每个模型的请求速率、排队情况、每个副本的吞吐和延迟然后统一算出最优的副本分配。它不是对每个模型单独做HPA而是把整个池子当成一个“资源背包”每个模型都在争抢有限的GPU容量。2.2 决策的核心变量吞吐需求 vs 资源占用要自动扩缩容最关键的环节是建立“需要多少容量”和“分配到多少副本”之间的数学关系。论文里大概率会用到“请求到达率”和“单副本吞吐能力”这两个基础指标。一个模型需要的副本数粗略等于请求到达率除以单副本可承受的吞吐量。但这个计算对LLM来说必须细化因为吞吐量不是一个固定值它取决于输入输出长度、批大小、模型大小、量化方式。实际工程里我更愿意把“单副本吞吐能力”拆成多个维度来观测模型加载后的显存占用、最大可并行batch数、在给定batch大小下的decode吞吐。论文里的扩缩容算法应该也是类似思路只不过它把“容量”统一成“GPU显存或计算单元”这样的抽象资源然后算出每个模型在特定副本数下能提供的服务水平。更有意思的是跨模型共享意味着不同模型必须可以被“比较”。7B模型和70B模型的容量没法直接比较论文可能需要定义一种标准化的“容量单位”比如“一张A100可提供的推理算力”作为基数。每个模型根据自身的显存需求和典型吞吐折算成对应的容量消耗。这样整个池子的资源分配就变成一个线性规划或启发式优化问题。2.3 一个直观的例子假设池子里有4张A100。模型A是7B每张卡能放2个副本共可以跑2个7B副本一个副本每秒大约能处理5个典型请求。模型B是70B每张卡只能放1个副本一个副本每秒大约能处理2个典型请求。当前时刻模型A有4个副本模型B有2个副本。突然模型A的流量从10 QPS涨到18 QPS现有4个副本最多扛20 QPS虽然还有余量但很悬模型B的流量从4 QPS降到1 QPS它的2个副本显然太多了。传统HPA可能只会为模型A加副本但池子已经满了加不动。论文里的跨模型控制器会看到模型A只需要多1个副本就能稳定而模型B可以砍1个副本于是自动把模型B的一个副本缩掉腾出的卡扩容给模型A。整个过程不需要人工干预。这个例子看起来简单但实际做起来难点在于容量评估要实时、精确切换模型副本不等于删进程再起进程还涉及权重加载、缓存清空、流量切换每一步都容易出错。3. 系统的关键模块与大概实现路径3.1 容量评估给每个模型建立“性能画像”论文要实现自动扩缩容第一步肯定得有一个相对可靠的容量评估模块。简单说就是回答一个问题给这个模型分配N个副本它能在什么延迟下处理多少并发请求。我的做法是分三层来画像第一层是静态参数比如模型参数量、量化位数、最大上下文长度、KV Cache的显存开销第二层是从实验或历史数据里总结出来的吞吐-延迟曲线第三层是运行时动态指标包括当前批大小、队列深度、GPU利用率。论文里提到“跨模型”这个维度时“标准化”是一个绕不开的坑。不同模型的性能曲线不在同一个坐标系里。为了协调它们论文很可能引入了一种“虚拟容量”概念比如以“每秒可处理的同等复杂度请求数”或者“单个GPU实例的利用率”作为统一刻度。我见过一些商业平台的做法是把每种模型在参考硬件上的benchmark吞吐量存下来然后按比例折算虽然粗糙但在生产环境里够用。容量评估模块不能做一次就完事它需要持续更新。因为模型的输入长度分布会变、同batch下的实际吞吐会变、GPU的拓扑和功耗也会影响性能。论文里的方案应该也是滚动窗口式的在线更新保留一段时间的性能观测来做回归而不是总拿一个旧表格出来拍脑袋。3.2 负载预测别等高峰来了才反应自动扩缩容最怕的就是“追着流量跑”。如果扩缩容决策只看当前QPS等副本启动完成时可能流量已经回落了白白浪费一组资源。所以论文里大概率包含负载预测模块。负载预测的输入通常是每个模型的历史请求序列。这个序列有明显的周期性比如白天工作时段高、凌晨低也有突发特征比如某个模型被新版应用带起来后流量陡增。传统的时间序列模型比如ARIMA、指数平滑也能用但LLM服务的流量变化往往跟业务发版、外部事件强相关纯时序模型很难捕捉。我自己的经验是预测不能只看总体QPS要按请求类型或输入长度分布拆开。长文本请求和短文本请求对资源的需求完全不一样。就算预测出总QPS没变但如果这个小时内长文本比例升高了其实也需要扩容。论文里的跨模型调度应该会把“预测容量需求”而不是“预测QPS”作为扩缩容的依据这样才能真正反映负载。3.3 决策引擎如何分配稀缺的GPU资源有了容量画像和负载预测接下来的核心就是决策引擎。它是整个系统的“大脑”输入是每个模型的需求和池子的总容量输出是一组扩缩容动作。这个决策问题可以建模成一个约束优化问题在总GPU容量受限、每个模型的最小副本数和最大副本数受限、期望延迟SLO的约束下最大化吞吐或最小化成本。论文里可能不会用全精确求解器因为生产环境需要实时决策通常会用贪心算法或者启发式规则。一个比较实用的思路是按优先级排先保证高优先级、延迟敏感模型的SLO再把剩余容量分配给低优先级、可容忍排队的大模型。论文里花了很大篇幅描述的部分很可能就是“如何在多个模型之间公平且高效地争夺容量”。这里难点在于公平的定义——是按请求量公平还是按业务价值公平还是按资源占用比公平不同平台的做法差异很大。决策引擎触发的频率也很关键。LLM模型冷启动时间长所以决策不能太频繁否则模型副本反复启停系统稳定性会崩。但如果太慢又会对突发流量不敏感。我看到的多数系统是分两层一个慢周期比如每几分钟做一次容量重分配一个快周期比如每几秒只调整请求路由不启停副本。论文里的自动扩缩容很可能也是这个逻辑。3.4 动作执行副本启动、迁移与下线决策引擎输出“模型A加1个副本模型B减1个副本”之后执行这一层才是真正容易翻车的地方。给模型A扩容意味着要选一台满足显存要求的机器然后开始加载权重。这里有个细节LLM权重加载不同于普通Docker镜像要先把模型参数从磁盘或远端缓存读到内存再写入GPU显存最后可能还要预热一下模型的结果缓存。整个过程里新副本是不能立即接流量的。论文里必须考虑“预热完成后再接收请求”这个状态管理。给模型B缩容要更小心因为直接杀掉副本会导致正在处理的请求全部失败。生产环境里缩容前应该先停止接收新请求等存量请求跑完再把副本回收。论文里可能会用一个“优雅下线”的机制来解决先把目标副本标记为“排空”由路由层判断哪些请求不再发给它等队列清空后再释放资源。跨模型的动作还会带来一个额外难题不同模型之间的资源释放和创建是有依赖关系的。比如我要扩容模型A但池子里没有空闲机器必须先把模型B的副本缩掉。那么是先缩B再扩A还是先扩A等它安装好再缩B如果缩了B但A启动失败池子容量就白白浪费了。所以执行顺序需要设计成带补偿逻辑的事务失败时能回滚。4. 论文里的实验方法和效果验证4.1 实验场景怎么看才不吃亏解读一篇系统论文最重要的不是背结论而是理解它的实验设计为什么能支撑结论。最早的实验一般会包含两类场景一类是合成工作负载用来做压力测试和对照实验另一类是真实或接近真实的trace用来验证在实际情况中的表现。合成工作负载的优势是可控。比如可以让模型A的流量在某个时间段内突然翻倍模型B的流量同时下降用来观察跨模型调度器能否快速完成资源转移。这比真实trace干净能比较容易地看出问题。论文里的效果通常会在这种“可复现的尖峰场景”里做多组对比。真实trace的优势则是“长尾效应”。真实流量里有很多细碎的波动比如每隔几分钟就有一个小峰或者某个请求因为超时被重试导致放大。这些现象在合成数据里很难构造出来所以真实trace能检验系统在“不完美”场景下的稳健性。解读时要特别关注论文有没有交代trace来源、请求分布、模型大小配比否则效果指标很难横向比较。4.2 基准对比跟谁比很关键自动扩缩容论文的对比基准一般有几种固定副本数、单模型HPA、全局浪费最小化但不预测的启发式以及论文提出的跨模型方法。解读时不能只盯着“我们的方法最好”这个结论要思考“它比基线好在哪里”以及“它是靠什么机制胜出的”。固定副本数的基线最容易打败因为它完全不弹性。单模型HPA比固定副本强一些但在共享池里会因为“看不到其他模型的容量需求”而卡住所以它恰恰能反衬出论文里“跨模型协同”的贡献。如果论文里还对比了一个“上帝视角最优解”那可以去看跨模型方法到底离最优有多远这个差距反映了在线决策的代价。我个人的习惯是先看模型数量和GPU规模的配置。如果实验只用了2个模型和4张卡那结论的普适性就要打折扣。论文如果做了更大规模比如8个模型、64张卡可信度会高很多。还要看负载强度的设置最高QPS有没有达到池子的真实瓶颈。如果始终没有压力那扩缩容机制根本没有被真正考验过。4.3 效果指标延迟、SLO违规率与资源节省论文里最值得关注的三个指标通常是P99/P95延迟、SLO违规率、GPU平均利用率或总使用量。延迟是用户能直接感知的指标但它不能单独看。因为很多系统会通过限流来保护延迟限流造成的拒绝或排队并不体现在延迟曲线里所以还要看成功率和SLO违规率。如果跨模型扩缩容把P99从100ms压到80ms但代价是5%的请求被拒绝那就没有说服力。资源节省通常用“相对于固定分配的GPU时间”来衡量。比如同样是满足99%请求延迟达标固定方案需要10张卡跨模型自动扩缩容只用7张卡这样就能折算成本节省。论文实验里如果能把成本曲线和性能曲线放在一起看而不是只突出一个维度就更有参考价值。我尤其会注意论文对“冷启动开销”的处理。如果跨模型自动扩缩容每次都通过牺牲3分钟的冷启动时间来节省资源那么对延迟敏感的业务来说不太可取。好的效果展示应该区分“在线决策生效时间”和“资源腾挪时间”分别说明系统在多少秒内能完成路由调整、在多少秒内能真正启动新副本。5. 落地实践中的启发与值得注意的细节5.1 从论文到生产环境的距离论文里的系统再怎么完整到了自己的业务环境里还是会有落差。第一个现实问题就是“模型数量”和“GPU异构性”。论文里可能假设所有GPU是同一型号但生产环境往往是A100、H100、4090混在一起甚至一张卡上还通过MIG切成了多个小实例。跨模型容量调度在异构环境里会更复杂因为“容量单位”不再是统一的。第二个问题是“路由策略”。论文里的跨模型扩缩容必须依赖一个“请求路由器”它知道每个模型有哪些副本、各自负载如何。但生产环境里往往还叠加着多租户隔离、不同业务的接入方式HTTP/gRPC/流式、不同版本模型灰度等诉求。这些都会降低调度器的控制力让你不能像论文里那样对每个请求做精细调度。第三个问题是“业务优先级”。论文里的优化目标可能是“最小化整体SLO违规率”但业务方真正想要的是“核心链路绝对不能出错离线任务有空就跑”。这种多级QoS的需求论文里不一定覆盖需要你在工程上额外实现。5.2 我踩过的几个坑第一个坑模型副本数不是连续的。7B模型在一张卡上可能放得下两个但跨模型收缩后只剩“0.5张卡”时你并不能把它切半使用。所以决策引擎的输出要考虑“离散资源块”否则算出来的分配方案是扭曲的。第二个坑KV Cache给容量评估带来的不确定性。同一个模型、同一个batch大小如果输入长度分布完全不一样其显存消耗可以差异非常大。论文里的容量画像如果只用平均长度容易在长文本高峰时低估容量需求。我在实践里会把输入长度分成“短、中、长”三档分别统计吞吐再按加权预测比单一平均值可靠得多。第三个坑缩容时“排空”很容易拖时间。一个模型副本如果正在处理一个很长的生成请求可能要等几分钟才结束。如果这时候又来了新流量需要资源就会出现“资源明明在池子里但没法立刻腾出来”的尴尬。论文里的优雅下线做法需要设置一个最长等待时间超时后强制中断请求。第四个坑手动干预和自动扩缩容的冲突。业务方有时候会手动给某个模型固定副本数。如果你的自动系统之后又去调整它会导致业务方感觉失控。要解决这个问题必须在系统设计时设置“最小副本数锁”或“策略优先级”让自动决策只在业务方允许的范围内执行。5.3 什么场景适合直接采用什么场景需要改造如果你的平台模型数量少、GPU规格统一、流量以内部调用为主那么论文里的思路可以直接落地。把模型注册进共享池配好容量画像启用跨模型调度器基本就能看到资源利用率的提升。如果你的平台是面向外部客户的“模型托管服务”每个客户有不同的SLA那么你要在论文思路之上增加一层“租户级配额”。比如某些VIP用户希望自己的模型副本数始终大于等于2这个约束必须在决策引擎里当成硬条件来对待。否则模型被自动缩容后客户的QoS出现波动投诉会让人头疼。如果你的模型很大比如超过单机显存的多卡并行模型跨模型扩缩容还要考虑“并行维度”。一个副本可能横跨多张GPU扩容时需要求和同一时间能腾出N张连续逻辑卡。这种场景下资源调度已经从“装箱问题”升级成了“多维装箱问题”论文里的启发式算法可能需要大幅改造才能用。6. 我对这篇论文的几点思考6.1 论文真正的贡献是什么我个人觉得这篇论文不一定发明了什么奇迹算法但它的价值在于提出了一个很清晰的系统视角把多个LLM服务当成一个整体的“容量资源池”然后用预测和优化模型来自动分配资源。这个视角解决了一个实际工程里很普遍但常常被绕开的问题——不同模型的流量高峰错开时怎么把闲置资源利用起来。相比那些“让LLM推理速度提升5倍”的论文这篇更偏工程架构。它不一定直接告诉你某个算子的优化技巧但能让你在搭建推理平台时少走弯路。很多团队花了很多时间去分析“单模型为什么变慢”却没有意识到资源已经空转很久了。从基础设施的角度看跨模型扩缩容是务实的选择。模型多了以后不可能永远靠人工配置来调度资源必须把“该给谁多少资源”这个判断交给系统里的策略引擎。论文给出的正是这样一个系统的可行模板。6.2 后续值得扩展的方向我觉得这篇论文之后有一些问题特别值得继续深挖。一个是“多副本之间是否要感知亲和性”比如同一个模型在物理上放得越近通信开销越小但资源碎片会多一些两者如何权衡。另一个是“扩缩容决策能否和推理引擎内部的动态batch协同”。现在很多引擎支持实时调整最大batch大小如果调度器能跨层地调节“单副本的并发能力”而不是只调副本数弹性可以更细粒度。还有一个方向是“在线更新容量画像”。模型在运行中可能会因为PagedAttention的内存碎片、量化误差等原因出现性能波动如果能实时学到当前的吞吐上限扩缩容的预测会更准。这本质上是一个在线学习问题和论文里的自动扩缩容天然契合。我在实际观察中发现共享池类的系统最大的阻力不是算法反而是组织层面的不同模型由不同团队维护时他们愿不愿意把资源控制权交出来。论文里如果有办法在“全局最优”和“本地控制”之间找到平衡那才是真正可以改变行业的方向。以及在落地上我始终建议先从一个小的模型子集开始验证。挑两个负载有明显错峰效应的模型跑一段时间记录资源利用率变化并和之前固定部署模式下的成本对比。如果数据符合预期再逐步扩大范围。这门学科里从来不缺漂亮的论文缺的是从一个稳定的小系统里亲自踩出来的经验。