推理服务的多模型混部：显存与算力的共享调度

为什么要把多个模型塞进一张卡

MIG、vGPU、时分复用这些技术本身的原理，「GPU 虚拟化与切片」一篇已经拆过；本篇站在推理服务的视角回答一个更贴近日常的问题：什么时候、用什么方式，把多个模型塞进同一张卡。这不是炫技，是被成本逼出来的现实诉求——GPU 是推理平台最贵的资产，而现实中大量卡处于「一个模型占着卡、利用率却不高」的状态。

诉求典型来自三种形态。其一是「大带小」：一张大显存卡跑一个十几 B 的主模型，显存只用了一半，旁边审核、分类、向量化这些小模型又各自占一张卡，整体利用率都不高。其二是多租户平台：几十个业务方各自带个小模型，按独占卡分配根本分不起。其三是显存碎片：各服务按峰值预留显存，谁也借不出闲时显存，整机的真实利用率被锁死在低位。混部的本质，是把「按峰值独占」改成「按统计复用」，用共享换密度。

利用率的现实图景可以给个数感：独占卡的服务在非高峰时段，利用率常常只有个位数到两三成（常识口径），夜谷更接近空转——混部的理论空间就藏在这些闲时里。还要点破一层调度现实：容器调度器只看显存申请值，显存给多少它管得住，但算力是整卡共享的，资源限制配额管不住算力——「每人占一块显存、算力大家抢」是共享卡上的默认物理规律，后面讲干扰时会回到这一点。

路线一：多实例共享与权重热切换

多实例同卡：最朴素的混部

主流推理引擎（vLLM 是代表）的基本形态是一个实例服务一个模型，单实例内多模型共池在工程上还不算成熟选项；所以最朴素的混部就是同卡起多个推理实例，每个实例配置显存占比，由调度器保证总占用不超卡。这个方案门槛最低、行为最可预期，但隔离是软的：显存上划了界，算力上没有——所有实例的计算任务混在同一个硬件队列里排队，谁的任务重谁多吃，互相干扰不可避免。它适合对延迟不太敏感、或各模型流量都很平缓的场景。

显存占比的配置要留安全边距：每个实例的份额按「权重加 KV Cache 峰值预算」估算，再留一成多的余量防碎片——预留太少，高峰期某个实例显存溢出会拖垮整卡；预留太多，混部就白混了。实践中常见的是按压力测试出的峰值水位定份额，而不是按配置上限定，两者可能差出一倍。

实例间的故障隔离也要想清楚：A 实例的进程崩溃通常不连累 B，但 GPU 层面的故障（驱动崩溃、显存错误风暴）会把同卡实例一起拖下水——混部不但没有缩小故障域，反而把多个服务的命运拴在了一张卡上。这是 SLA 严格的服务不该混部的底层原因之一：你接受的不是性能毛刺，还有邻居硬件故障的连带停服。

LoRA 热加载：共享底座的最划算形态

如果多个「模型」本来就是同一底座的微调版，答案根本不是混部，而是 LoRA 适配器热加载：底座权重在显存里只放一份，各业务的适配器（几十 MB 到几百 MB 的小文件）动态挂载、卸载，切换几乎零成本，主流引擎对此已有成熟支持，一个服务实例就能轮着服务几十个微调版。这是「多模型」问题里性价比最高的解，优先级应该排在一切真混部之前——先问一句「这些模型真的不同底座吗」，能合并的先合并。

多适配器服务在接入层的形态是网关聚合：业务方看到统一的服务入口，网关按请求特征（业务标识、模型名）路由到对应适配器挂载的实例（接入层机制可参考「大模型 API 网关」篇）。适配器一多，管理问题跟着来：哪些适配器常驻显存、哪些按需加载、加载排队怎么排，都是小型调度问题——好在适配器小，调度的代价低，试错也便宜。适配器的显存开销虽小，几十个一起常驻也要记账——按访问频率分级（热门常驻、冷门按需加载）是这个小调度问题的常见解。

权重热切换：低频换装的兜底

真正的不同底座模型之间，还有权重热切换一途：同一实例按需把权重文件换成另一个模型。代价是切换窗口——几 GB 到几十 GB 权重从存储载入显存，秒级到分钟级的服务中断或降级，切换期间该卡上的请求要么排队要么拒绝。它只适合低频场景：白天跑模型 A，夜里批量任务换模型 B 这种「错峰换装」。把它当在线能力用，等于把中断做成日常，不可取。

切换的工程实现也有讲究：先把新权重从存储预载到 CPU 内存甚至预拷到本地盘，再把显存里的旧权重换出——把慢的存储环节挪到切换窗口之外，窗口本身只留显存拷贝的秒级动作。切换期间到达的请求明确排队或明确拒绝，重试语义写清楚，别让客户端在半新半旧的状态里收到奇怪的结果。另外它与「灰度与模型热更新」篇讲的在线热更新是两回事：那边换的是同模型的版本灰度，这边换的是整个模型，复杂度与风险都高一级。

路线二：硬件切分与时分复用

软件层隔离不够时，往下找硬件层。MIG 把一张卡物理切成若干独立实例，显存与算力单元硬隔离，互不干扰，代价是切分粒度固定、容量不能弹性共享——切出去的份额就算闲置，也借不回来。vGPU 走虚拟化路线，粒度更灵活，但依赖虚拟化层、有性能开销。时分复用则是时间维度上的共享：多个进程轮流整卡使用，你用一段我用一段，隔离靠时间片，代价是毛刺——轮到你时若是刚好没接上，延迟直接翘头。另有进程级的算力共享机制（MPS 一类），让多个进程的计算任务真正并发跑，比纯时分利用率高，但故障域耦合：一个进程崩了可能带崩共享上下文。选型口诀可以概括成一句：要强隔离选 MIG，要灵活选 vGPU 与时分，要利用率且能接受耦合选 MPS，能合并底座先选 LoRA。

落到容量换算，硬件切分的账很朴素：按小模型的实际需求选切分规格——它的权重加峰值 KV Cache 只需要二三十 GB 显存，就切出对应的份额，不必给它半张卡；切得太细，单实例的算力份额不够峰值用，又得回头重新规划。时分复用的时间片大小也有讲究：片太短，进程切换开销占比高；片太长，排队等待的延迟毛刺大——按各服务的单步延迟预算反推时间片上限。

硬件方案的运维成本也别忽略：MIG 的切分要随模型组合变化重新规划，而切分变更通常要等卡空闲（卸载全部实例）才能做；时分复用的进程调度器、算力共享机制的配额管理，都是新增的运维面。选型时把「模型组合的调整频率」估进去——模型天天换的平台，硬切分会被调整成本拖垮，这时软隔离加好的调度反而更实用。

干扰与隔离的权衡

混部绕不开的账是干扰。共享卡上，一家的长文本 prefill 风暴可以在几十毫秒内吃掉大半算力，同卡的另一家立刻表现为首 token 延迟毛刺；时分复用下毛刺更规律——排队的等待时间直接叠加在每次请求上。延迟毛刺是混部的固有税，问题只是税率高低。降低税率的手段有几层：调度层给在线服务设优先级，离线任务让路；容量层把每家的显存占比设死，防止一家膨胀挤垮全卡；观测层对比混部前后的 P99 与毛刺频率，用数据说话而不是凭感觉。监控在这里不是可选项——没有每实例的延迟分位与显存水位监控，混部就是盲飞，出了问题连是谁干扰了谁都说不清（监控指标与告警怎么搭，本系列「一篇读懂 GPU 监控」一篇专门展开）。

干扰的定位方法可以实操化：对比混部前后的分位指标确认存在劣化；把毛刺时间点与各邻居的流量高峰做时间相关性，锁定嫌疑对象；必要时做对照实验——临时把嫌疑邻居限流半小时，看毛刺是否消失。给个数感（演示口径）：同卡两服务，一家高峰期可能把另一家的尾延迟从几百毫秒拖到两秒以上，这种量级的劣化足以击穿多数业务的延迟预算。共享队列还有两种组织形态：在线与离线分优先级（离线可被抢占，工程复杂但体验可控）、完全对等共享（简单但毛刺大），选哪种同样是毛刺预算的函数。

从容量视角再算一笔干扰账：混部提升的是平均利用率，但 SLA 要按最坏情况供给——两家高峰完全重叠时，共享卡的有效容量不是两者相加而是打折。所以混部的容量规划要用「重叠高峰」做保守假设，而不是拿平均利用率的提升自我安慰；这也是「GPU 集群的容量规划」篇的三张表里，混部收益那一栏要写保守值的原因。

什么场景值得混部

混部是收益与风险的交换，值不值得换，看三个条件。第一看毛刺预算：业务能接受 P99 劣化百分之多少？内部工具、离线批处理、闲时任务通常预算宽裕，适合混；SLA 严格的线上主链路预算紧张，不该混——主服务独占卡看起来奢侈，其实是买确定性，不该省的这个钱就是隔离的钱。第二看流量形状：各模型流量错峰明显（一个白天忙、一个夜里忙）混部收益大；同时高峰叠加则共享只会制造排队。第三看运维复杂度承受力：混部的故障排查天然更难——性能问题要先排除邻居干扰，容量问题要算总账，这对平台的监控与排障能力有真实要求。三条件过两条以上再混，一条都不占就老老实实独占。

混部还应走渐进路线，风险逐级上台阶：第一步先拿离线任务填闲时（错了只是离线任务慢，无人在意）；第二步小模型多实例同卡（影响面可控）；最后才考虑在线大模型共享卡（收益大、风险也大）。一步到位直接把主服务混上去的团队，通常会在第一次大促流量时学乖。

混部上线后的验收也要数据化：设两周的对照观察期，记录每个服务的分位延迟、错误率与吞吐变化，达标才转正；转正后把「混部基线」（各服务的份额、优先级、观测指标）记录归档，下一次评估新业务上卡时有据可依，而不是凭印象拍脑袋。混部省下的卡也别忘了回填容量账：密度提升两成，等于容量规划里凭空多出两成供给，「GPU 集群的容量规划」篇的三张表应该把这份收益记进去。

小结

多模型混部是在「利用率」与「确定性」之间做交换：诉求来自大带小、多租户与显存碎片，路线从软到硬依次是多实例同卡、LoRA 热加载、权重热切换、MIG 硬切分、时分复用与算力共享，隔离强度与灵活性各有取舍。决策的优先级很清晰：能共享底座的先 LoRA 合并，这几乎是无代价的；真要混部的，按毛刺预算、流量错峰、运维能力三条件评估；SLA 严格的在线主服务独占卡，买的是确定性，这笔钱不该省。

混部不是省钱的银弹，而是一类需要专门工程能力（软隔离配置、优先级调度、干扰观测）的运营模式。做对了，同样的卡多扛几成的服务；做错了，所有服务一起变毛。判断标准永远回到数据：混部前后每个模型的延迟分位、显存水位、故障率——有这些数字，混部是精细运营；没有这些数字，混部是赌博。