单卡共享与推理混部-MIG时间片与抢占的取舍

摘要训练任务通常吃满整张卡推理任务则常常吃不满——尤其是小模型、低并发的场景。这意味着大量算力被独占但闲置的方式浪费掉。共享一张卡的方案主要有三类硬件分区、时间片轮转、以及抢占式调度它们在隔离强度与性能代价上差异明显。本文对比三者的适用场景指出常见的误用并给出混部落地前必须确认的检查项。2026 奇点智能技术大会11 月 20-21 日 · 北京万达文华酒店将讨论 AI 基础设施与算力效率。一、为什么共享是推理场景的必答题三个现实推动了共享需求其一单卡能力增长快于单请求需求。新一代加速卡的显存与算力远超一个中小型模型的需要跑一个 7B 模型的推理服务可能只用掉一小部分资源。其二流量有峰谷。为峰值独占一张卡意味着低谷期大部分时间闲置。其三多模型并存。一个业务往往需要同时部署主模型、嵌入模型、重排模型等各自独占会造成碎片。独占模式的浪费 卡数 × (1 − 单服务平均利用率) 共享的目标 把多个低利用率负载叠到同一张卡上二、三类共享方式对比方式隔离强度性能代价显存隔离适用场景硬件分区强硬件级低算力按比例切分是稳定负载、需要保障时间片轮转弱上下文切换中切换开销否交互式、容忍抖动抢占调度中依赖优先级高被抢占者需恢复部分开发任务填充空闲硬件分区的优点是确定性强每个分区有固定的算力与显存配额互不干扰。代价是粒度受限分区规格固定且切分后无法动态调配。时间片轮转的灵活度最高但上下文切换有真实开销且延迟特性会变差——对延迟敏感的服务时间片往往不可接受。抢占调度适合把低优先级任务塞进空闲缝隙代价是被抢占任务需要保存与恢复状态实现复杂度高。三、显存才是共享的第一约束讨论共享时注意力常集中在算力上但真正的约束通常是显存。权重常驻。每个模型加载后都要占用固定的权重显存这部分无法共享。一张卡能同时放几个模型取决于权重总量。KV Cache 波动。活跃请求的 KV Cache 随并发与长度变化可能突然膨胀。共享场景下一个租户的突发流量可能挤占另一个租户的空间。defcan_colocate(models,total_mem,safe_ratio0.85):能否共置先算权重占用再检查剩余空间是否够峰值 KV Cache。weightssum(m.weight_mbforminmodels)need_kvsum(m.peak_kv_mbforminmodels)returnweightsneed_kvtotal_mem*safe_ratio注意这里用peak_kv_mb而不是平均值按平均值规划会在峰值时触发显存不足表现为服务整体崩溃而不是轻微变慢。四、三个常见误用误用一把延迟敏感服务与批处理任务混在一起。批处理会长时间占用算力导致前者的尾延迟急剧恶化。混部的前提是负载特征互补而不是简单地把空闲填满。误用二共享后不做隔离验证。光看平均吞吐没意义必须验证单租户在邻居满载时的性能衰减幅度。如果衰减超过可接受范围共享就不成立。误用三忽略故障域扩大。一张卡上跑五个服务卡故障影响的就是五个服务。共享提升了利用率也放大了单点影响。关键服务应保留独占资源。五、混部落地的检查项上线前建议逐项确认峰值显存是否够按峰值而非平均计算邻居干扰是否可接受在满载邻居存在的情况下测延迟算力配额是否可配置能否为不同服务设置不同权重故障影响范围是否明确一张卡挂掉影响哪些服务是否有快速迁出能力某个服务异常时能否迁到其他卡检查优先级显存 干扰 配额 故障域 迁移 ↑ 前两项不过后面都不用谈六、与调度层的配合共享不只是单机问题还需要调度层配合。三个配合点其一调度器要感知卡的共享状态。否则会把新任务调度到已经拥挤的卡上。其二优先级要贯穿两层。单机内的算力分配与集群级的调度优先级要一致否则会出现上层高优、下层被压制的情况。其三监控要按租户拆分。共享后如果只看卡的总体利用率就无法判断哪个租户受影响。按租户统计延迟与吞吐是共享场景的必需监控项。七、三类负载的共置组合建议混部不是随意搭配负载特征互补才能既提利用率又不互相伤害。以下组合值得参考。组合特征效果注意事项在线推理 离线批处理延迟敏感度差异大好批处理需可抢占小模型 大模型显存与算力占用互补好大模型需保底配额嵌入/重排 生成计算形态不同较好注意显存峰值两个在线延迟敏感服务特征相同差尾延迟互相恶化训练 推理故障域与调度冲突差通常不建议共卡最后一行值得强调训练与推理共卡在纸面上很诱人但实际会互相干扰——训练的显存峰值不可预测推理的延迟要求又很硬。除非有强隔离机制否则不建议这样做。八、读者问答问硬件分区的规格限制如何应对分区规格通常是固定的几种组合无法任意切分。应对方式是按最接近的规格分组部署把不同规格的卡归类管理而不是要求每张卡都精确匹配需求。问共享后性能衰减多少算可接受建议以内部分位数为准在邻居满载的情况下P95 延迟上升不超过 20% 通常可以接受。超过这个值共享的收益已经被体验损失抵消。问时间片轮转会不会导致输出质量变化不会直接影响质量但会影响延迟稳定性。如果服务对首字延迟敏感时间片往往不是好选择。问共享是否影响故障排查会。一张卡上多个服务时性能问题需要按租户拆分数据才能定位。按租户统计是共享场景的必需监控项而不是可选项。九、共享场景下的监控设计共享之后传统的卡级指标会失真。需要新增三类监控。第一类按租户的资源占用。每个租户的显存占用、算力占用、请求队列长度。只有按租户看才能判断谁在影响谁。第二类干扰指标。在邻居满载与空载两种情况下同一租户的延迟差异。这个差值直接反映隔离是否有效。第三类显存水位与碎片。共享场景下显存是硬约束水位告警应当留出足够余量而不是等到接近满载才告警。definterference_metric(idle_latency,busy_latency):干扰度邻居满载时的延迟相对空载的上升幅度。ifidle_latency0:return0.0return(busy_latency-idle_latency)/idle_latency建议把这个指标纳入共享准入判断干扰度超过阈值的组合就不该共置。这比事后排查高效得多。十、读者问答问共享是否会增加运维复杂度会主要包括配额管理、干扰排查与故障域扩大。判断是否值得要看利用率提升带来的成本节约能否覆盖这份复杂度。问小团队需要共享吗如果卡少且负载稳定独占反而更简单。共享的收益随规模增长——卡越多、负载越杂共享的价值越大。问共享能否动态开关可以但不建议频繁切换。共置关系变化会影响性能基线频繁调整会让监控数据失去可比性。问如何评估共享是否成功三个指标整体利用率提升幅度、单租户延迟劣化幅度、以及故障影响范围是否可控。三者同时满足才算成功。十一、最后几个问题问共享之后如何做容量规划按租户的峰值之和而非平均值规划并留出显存余量。按平均规划会在多个租户同时达到峰值时出问题。问共享是否需要特殊的调度器支持需要。调度器要理解卡上已有租户的资源占用与干扰容忍度否则容易把冲突负载放在一起。问混部后如何做压测在邻居满载的条件下压测目标服务而不是在空载环境测。空载压测结果在共享场景下没有参考价值。问共享对成本的影响如何量化对比共享前后完成相同工作量所需的卡时数同时扣除因干扰导致的性能损失得到净收益。问什么情况下应该停止共享当干扰度持续超标、或者故障影响范围超出可接受程度时。共享是手段利用率才是目标手段伤害了目标就该停止。十二、衔接大会专题问共享后如何做容量演练模拟单个租户流量翻倍观察其他租户的延迟变化与显存水位。这个演练能提前发现多数共置不合理的问题。问共享方案是否需要硬件支持硬件分区需要硬件特性支持时间片与抢占主要依赖软件调度。没有硬件分区能力时后两者仍可实现只是隔离强度较弱。问共享是否会增加故障排查时间初期会。建立按租户的监控后排查时间会回落。建议在共享上线时就同步建设这类监控而不是等出问题再补。11 月 20-21 日北京万达文华酒店2026 奇点智能技术大会将讨论 AI 基础设施、算力调度与集群效率C 及系统软件技术大会则从资源隔离、并发与运行时角度给出底层视角。带着我们的卡平均利用率是多少、能不能共置这两个数字去参会会比讨论硬件规格更有收获。大会信息2026 奇点智能技术大会 C 及系统软件技术大会时间2026 年 11 月 20-21 日地点中国·北京万达文华酒店大会报名点击报名领取大会PPT资料立即报名锁定 Lukasz Kaiser Keynote 与 70 场演讲完整资料