容器化环境中的GPU资源调度方案，关键不是简单地在“直通”和“共享”之间二选一，而是确认任务能否容忍资源竞争、是否要求隔离，以及集群能否管理更细粒度的设备。先厘清一个概念：普通容器通常使用宿主机内核和GPU驱动，通过设备插件把GPU设备暴露给容器；这和虚拟机通过VFIO进行PCI设备直通并非一回事。
整卡分配：性能边界清楚，资源颗粒较大
整卡分配时，调度器将一张GPU分配给一个容器或一个工作负载。以Kubernetes为例，集群通常借助厂商设备插件向节点注册可分配资源，再由Pod声明GPU请求。这样做便于限制并发和定位故障，但容器即使只在短时运行任务，也可能占住整张卡。
它适合长时间运行、负载波动较小，或对延迟和吞吐稳定性要求高的任务，例如使用Blender Cycles进行持续渲染、运行单个高负载推理服务，或执行需要完整设备能力的GPU计算。主要优点是争抢较少、性能表现较可预测；缺点是小任务容易造成资源闲置，而且通常不能把单卡按任意比例分给多个容器。
共享切分并非一种模式
硬件切分：MIG提供明确的实例边界
在支持MIG的NVIDIA数据中心GPU上，管理员可将物理GPU划为多个硬件实例，每个实例获得指定的计算与显存资源。NVIDIA H100是支持MIG的产品之一；可用实例组合取决于具体型号和配置。对于多个彼此独立、单个任务不需要整卡资源的推理服务，这种方式能提高设备利用率，并比单纯的软件并发提供更清晰的资源边界。
代价是可分配规格受硬件配置限制，部署前要核对设备插件、驱动和集群调度配置。切分也不等于完全消除干扰：显存、计算单元之外的共享部件和整机资源仍可能影响实际表现。
软件共享：适合轻载并发，性能更受竞争影响
时间片共享会让多个容器轮流使用设备；CUDA MPS则支持多个进程并发提交工作。两者都能让多个轻量任务共用一张卡，但不等同于MIG那样的硬件资源分区。任务同时繁忙时，完成时间可能拉长，且软件共享通常不能保证每个容器获得固定的显存份额。应检查平台的插件与配置能力，并用实际负载验证显存占用、吞吐和尾延迟。
按工作负载做选择
| 判断条件 | 优先考虑 | 需要接受的限制 |
|---|---|---|
| 任务持续繁忙，性能稳定或隔离优先 | 整卡分配 | 细粒度利用率较低 |
| 多个中小任务并行，且设备支持硬件分区 | MIG等硬件切分 | 实例规格和配置需要管理 |
| 任务负载较轻、允许性能波动 | 时间片或MPS共享 | 并发竞争可能增加延迟 |
因此，容器化环境中的GPU资源调度方案应从任务特征出发，而不是只看容器数量。可以按以下步骤落地：
- 记录任务的显存峰值、运行时长、并发数，以及对延迟波动的容忍度；这些指标应来自目标环境的监控或测试。
- 确认GPU型号、驱动、容器运行时和Kubernetes设备插件是否支持计划采用的整卡、MIG或软件共享模式。
- 先选少量节点试运行同一组代表性任务，对比吞吐、排队时间、显存占用和失败情况。
- 根据结果设置资源请求和并发上限；共享模式下应保留监控与降载手段，繁忙任务则考虑迁回独占设备。
常见问题
容器里的GPU直通是不是PCIe直通？
通常不是。容器一般共享宿主机内核，通过设备节点和驱动访问GPU；PCIe直通更多用于虚拟机设备分配。
共享切分一定能降低成本吗？
不一定。它可能减少闲置，但如果竞争导致任务变慢、重试增多或服务延迟超标，整体效率反而会下降。
整卡分配和MIG能混用吗？
是否能在同一集群或节点组合使用，取决于GPU型号、驱动、设备插件和调度配置。上线前应验证资源呈现方式与节点隔离规则。
归根结底，容器化环境中的GPU资源调度方案要在性能可预测性与资源利用率之间取舍：稳定重载优先整卡，硬件条件合适且任务可拆分时考虑MIG，轻载并发再评估软件共享。
