GPU Overprovisioning 怎么做：从超卖、共享到隔离的解决方案

只要认真看过一段时间 GPU 集群的监控，你几乎都会遇到同一种尴尬：很多任务申请了一整张卡，实际利用率却并不高；显存像是被占满了，算力却长时间跑不满；某些训练任务只有少数阶段真正紧张，但整段生命周期都把资源锁住；推理服务为了防峰值把 requests 开得很保守，结果绝大多数时间都在空转。GPU overprovisioning 会反复被拿出来讨论，说到底就是因为越来越多的团队不愿意继续接受“整卡独占但利用率很差”这件事。

不过这件事一上来就得先把边界画清楚。GPU overprovisioning 不是“反正 GPU 贵，能塞多少塞多少”，也不是简单粗暴地超卖资源。它本质上是一套提升利用率的工程策略，前提是你知道自己的负载长什么样，也知道风险会从哪里冒出来。没有观测、没有分层、没有止损，所谓 overprovisioning 很容易从“优化利用率”一路滑向“制造事故”。

一、这件事到底在解决什么

如果用一句话概括，GPU overprovisioning 就是在已知很多业务不会长期把一整张卡吃满的前提下，通过调度、共享、虚拟化、硬件分区或业务编排等手段，让同一批物理 GPU 承载比“整卡独占”更多的有效工作负载。它不是一种单独的技术，而是一组策略的组合：有的发生在调度层，有的发生在运行时层，有的依赖硬件能力，有的则依赖任务队列和业务优先级。

业内经常会出现一种很有意思的错位：大家都在聊 overprovisioning，但说的常常不是同一件事。有人说的是调度超配，有人说的是时间切片，有人说的是显存控制，有人说的是 MIG，有人说的是 Serverless 外溢。它们都属于提高 GPU 有效利用率的手段，但解决的问题、风险模型和适用场景差别很大，混在一起谈，结论往往会跑偏。

GPU 之所以特别容易出现“表面占满、实际没吃满”，原因通常有三类。第一类是资源申请天然偏保守。业务方宁可多申请一些，也不愿意因为申请不足把任务跑挂；在缺少历史数据和画像分析的情况下，保守申请几乎总会变成默认行为。于是调度器看到的是“这张卡已经满了”，硬件层面看到的却可能是“还有不少空闲”。第二类是 GPU 使用有明显的阶段性波动。训练里的数据预处理阶段更偏 CPU 和 I/O，模型加载阶段显存高但算力并不高，推理服务在低峰期的吞吐又远低于峰值，如果始终按峰值去锁一整张卡，利用率自然不会好看。第三类是 GPU 原生隔离能力并不像 CPU 那样细粒度、成熟。共享 GPU 不难，真正难的是共享之后仍然可控，这也是为什么 GPU overprovisioning 的重点从来不是“多塞几个任务”，而是在可控前提下提高密度。

二、别被名词带着跑，先把常见路线放在一张图里看

下面这个表可以先把主要路径摆在一起：

如果非要从这张表里提炼出一条最值得记住的规律，那就是：隔离性越强，通常越稳定，但灵活性越低；灵活性越高，通常越依赖治理和观测。没有一种方案能同时把密度、隔离、灵活性和实现成本都做到最好，平台要做的始终是权衡，而不是幻想有一条银弹路径。

三、很多时候，最先见效的并不是共享，而是把调度和编排做对

很多团队一提 GPU overprovisioning，第一反应就是“能不能让一张卡跑多个任务”。但从平台治理角度看，最先值得做的通常不是共享，而是把调度和编排做得更聪明。只要已经有比较稳定的历史监控数据，就可以先统计不同任务类型的真实 GPU 利用率和显存峰值，把长期明显过保守的 requests 收缩掉，对低风险任务允许更紧凑的装箱。这个阶段本质上是在做一件很朴素的事：先把虚胖的申请瘦下来，再去谈后面的共享和超配。很多团队其实还没走到 GPU 虚拟化那一步，只是把资源申请从“拍脑袋”改成“基于观测”，利用率就已经上去了。

训练集群里常见的 backfill 也是同一类思路。大任务在排队，小任务先填进去；节点上有零碎空闲时，让低优先级任务先跑起来；把短任务和可中断任务拿来吃碎片时间。它的价值不在于把同一时刻的同一张卡“超卖”到极限，而在于减少等待、减少空转、提高整个平台的有效吞吐。对很多组织来说，这其实比一上来就做激进共享更稳，也更容易和现有作业队列体系对接。

当然，调度层 overprovisioning 也不是没有风险。样本不准时，requests 可能压得过低；模型版本一变，资源画像可能就失真；任务执行时间波动很大时，回填策略也可能扰乱主队列。所以这一层最重要的不是“更激进”，而是“更有证据”。你得先知道自己在浪费什么，才能知道该收哪里，而不是因为 GPU 很贵就一股脑往上压密度。

四、共享、隔离和业务编排，本质上在解决不同的问题

时间切片和软共享是大家最容易联想到的路线。对于轻量推理、开发测试、内部实验这类任务，整卡独占往往太浪费，让多个容器或任务共享同一张物理 GPU，看起来很自然，也确实经常有效。它的优点很直接：提升密度快，对轻载业务友好，不一定需要特殊硬件，对“很多小推理服务”这种场景往往能立刻见到收益。

但软共享最大的问题也同样直接：noisy neighbor。一个任务突然把显存吃满，另一个任务的尾延迟就可能开始抖；共享环境里一旦出现线上问题，平台很难第一时间判断这是业务逻辑问题、模型问题，还是资源争抢导致的问题。所以软共享更适合那些对性能抖动容忍度较高、可以接受失败重试、主要目标是提高资源密度的场景。对于低延迟、强 SLA 的生产推理，如果没有配套的控制和止损，直接上激进软共享通常风险不小。

很多团队最终会继续往更深一层走：显存限制、运行时拦截、vGPU 抽象、自定义 device plugin、把 compute 和 memory 拆成两个资源维度，用 runtime 去做真正的配额控制和观测。像 tke gpu-manager、HAMi Core、TensorFusion 这一类方案，核心都不只是“让多个工作负载共享 GPU”，而是希望把 GPU 的申请和使用纳入一个更细粒度、可治理的控制面。只有到了这一层，你才开始接近“可控共享”，而不是纯靠调度器内部做逻辑分账。

但这条路的代价也必须说清楚。实现复杂度会上升，驱动、CUDA 版本、容器运行时兼容性都会变得更敏感，升级、回归、排障成本会明显增加；平台团队要更深地掌握 GPU 软件栈，业务方的资源申请和使用习惯也常常要跟着调整。如果观测和治理能力还没跟上，这类方案甚至可能在短期内放大风险，而不是降低风险。更适合它的，是那些真正想把 GPU 共享做成平台能力的团队，而不是只想临时把利用率抬一抬的团队。

当问题从“能不能多塞几个任务”变成“我怎么确保别人不把我挤爆”时，讨论重点就会自然转向硬隔离。MIG 是最典型的例子：它把一张物理卡切成多个硬隔离实例，实例之间的隔离性更强，性能确定性通常也好于软共享，所以很适合稳定的生产推理和多租户环境。很多团队喜欢 MIG，根本原因不是它听起来更高级，而是它回答了生产系统里最现实的那个问题：我不仅想提高利用率，我还想知道共享不会把核心业务拖垮。

当然，MIG 也不是答案终点。不是所有 GPU 都支持它，切分规格有限，灵活性不如软共享，而且切分本身会带来碎片化，对大训练任务也未必友好。所以更准确地说，MIG 不是“最先进的方案”，而是“在隔离优先时经常更对路的方案”。同理，vGPU 和其他虚拟化路线也该放在同样的语境里理解：它们不是单纯为了做一个更酷的资源抽象，而是为了在共享和隔离之间找到一个更可控的折中点。

还有一个经常被忽略、但其实非常实用的方向，是业务层的编排。很多平台并不是靠把一张卡切得更碎来提高利用率，而是靠优先级、抢占、离峰调度、批处理整形和 Serverless 外溢来提升整个平台的有效吞吐。在线推理高优先级，训练中优先级，实验和回归任务低优先级；低优先级任务利用空闲时间跑，高优先级业务一来自动让位。或者夜里集中跑 embedding、生成和批处理，把白天的突发请求吸进队列，再把峰值外溢到 Serverless GPU。严格说，这也是 overprovisioning，只不过优化的是整个资源供给结构，而不是单卡并发数。

五、最后拼的还是治理能力，不是技术名词

GPU overprovisioning 最终能不能落地，决定因素往往不是技术是不是先进，而是治理是不是扎实。至少有三件事不能少。第一是观测能力。你必须能稳定地看到 GPU 利用率、显存占用和峰值、Pod/容器/任务维度的资源使用、队列时延、失败率、延迟分位数，以及节点层异常和业务层异常的关联。如果观测只停留在节点总览层面，平台几乎不可能安全推进任何激进策略。

第二是准入分层。不是所有任务都应该进入同一个资源池，也不是所有任务都适合同一套共享策略。延迟敏感的在线服务、吞吐优先的批任务、可中断的实验任务、高价值训练任务，理应有不同的资源边界和调度策略。如果这件事不做，最后很容易把“平台通用能力”做成“一刀切超卖”，看起来省资源，实际上是把风险均匀撒给了所有业务。

第三是止损和回收能力。共享出了问题时，平台要能自动驱逐低优先级任务，熔断新的共享调度，降低单卡并发密度，把异常 workload 临时迁回独占池，或者回退到更保守的配置。没有这些兜底，任何一次共享冲突都有可能把组织内部对 overprovisioning 的信心彻底打掉。

更实际的落地顺序通常是分阶段推进：先做资源画像、回填和 requests 收缩；再对低风险任务引入软共享、优先级和抢占；之后才考虑显存限制、vGPU、runtime 拦截；关键业务则始终保留 MIG 或其他硬隔离手段，再配合 Serverless 外溢去承接波峰。很多团队的问题不是方向错了，而是跳得太快，还没把“资源申请做准”和“空闲时间利用起来”这两件最基础的事做好，就直接想靠复杂共享把利用率拉满，最后复杂度先上去了，收益却不明显。

常见问题

GPU overprovisioning 就是 GPU 超卖吗？ 不能简单等同。超卖只是其中一种更激进的实现方式，而 overprovisioning 的范围更广，队列回填、优先级调度、时间切片、Serverless 外溢都属于提高 GPU 有效利用率的路径。

训练集群适合做 overprovisioning 吗？ 适合，但通常更建议先从回填、优先级和离峰调度入手。长训练任务更看重性能确定性，失败代价也更高，直接做激进共享常常不划算。

生产推理能不能做 overprovisioning？ 能，但要分层。核心低延迟服务通常更适合硬隔离或更保守的策略；边缘业务、低优先级模型、内部服务更适合先尝试软共享或弹性外溢。

MIG 是最终答案吗？ 不是。它很好地解决了强隔离和稳定性问题，但灵活性有限，也可能带来碎片化。它是适合某类场景的答案，不是所有场景的终点。

结语

GPU overprovisioning 的目标，从来不是把每张卡都压到极限，而是把 GPU 资源从粗放独占，慢慢推进成一种可度量、可分层、可治理的高利用率供给体系。对平台团队来说，最值得坚持的思路通常很朴素：先把资源画像做准，再把低风险空闲利用起来，然后才逐步把共享和超配做深，同时始终为关键业务保留更强的隔离和回退能力。

如果你现在正准备推进 GPU overprovisioning，不妨先问团队三个问题：我们真的知道 GPU 是怎么被浪费的吗；我们能不能按业务重要性做资源分层；一旦共享出了问题，我们有没有清晰的止损方案。只有这三个问题能答得比较踏实，overprovisioning 才更像一项工程能力，而不是一次靠运气的密度实验。