容器、隔离与资源调度原理

所属： 基础设施层。本页边界： 多任务如何共享加速器而不混淆依赖、数据和资源边界。

#核心约束

T_j=T_j^{\mathrm{queue}}+T_j^{\mathrm{run}}+T_j^{\mathrm{restart}}, \qquad \sum_j a_{jd}g_j\leq G_d, \qquad a_{jd}\in\{0,1\}

资源调度既要控制作业的排队与运行时间，也必须满足每个资源域的容量约束；单独最大化设备忙时比例并不等于最小化作业完成时间。

#符号说明

符号	含义	单位/条件
$T_j$	作业 $j$ 的端到端完成时间	s
$T_j^{\mathrm{queue}}$	作业 $j$ 的排队时间	s
$T_j^{\mathrm{run}}$	作业 $j$ 的实际运行时间	s
$T_j^{\mathrm{restart}}$	作业 $j$ 因抢占、故障或迁移产生的重启时间	s
$a_{jd}$	作业与资源域索引分别为 $j,\ d$ 时的放置指示量	0 或 1
$g_j$	作业 $j$ 所需的加速器数量	张卡
$G_d$	资源域 $d$ 可分配的加速器容量	张卡
$U$	后文中的加速器忙时比例	$[0,1]$
$m_j,\ M_d$	作业单卡显存需求、设备可用显存	Byte

实际放置还需加入显存、拓扑、优先级和并行任务成组启动等约束。

#技术要点

容器固定运行时、驱动兼容边界和依赖环境。
隔离包括文件、网络、进程和设备可见性。
调度需要同时考虑 GPU 数量、显存、拓扑和 gang scheduling。
利用率高不等于任务延迟低。
GPU 隔离存在三个层次：时间片轮转（vGPU time-slicing）、多进程服务（MPS）和硬件分区（MIG），隔离强度依次递增。
MIG 将单卡划分为最多 7 个硬件隔离实例，每个实例拥有独立显存、缓存和计算核心。
Volcano 和 Kueue 是当前主流的 GPU 集群调度器，分别以 gang scheduling 和队列管理为核心能力。
资源碎片化不只是显存碎片：拓扑碎片使集群剩余 GPU 总数够用但无法组成一个连续的互联域。

#原理与演进

#从单个设备到同时分配一组设备

训练作业需要一组加速器同时空闲；只给部分设备时，分布式进程可能互相等待，这就是 gang scheduling 的动机。
设备数量之外，还需考虑显存容量、节点内连接、跨节点距离与数据本地性；否则相同 GPU 数量可能对应完全不同的通信耗时。
容器隔离进程、依赖与文件视图；设备隔离还需约束可见设备与显存使用。容器镜像本身不能解决资源争用。

#利用率与完成时间

这正是页首第一项作业完成时间分解，不再使用另一组符号重复列式。

提高设备利用率 $U$ 可能增加排队时间 $T_{\mathrm{queue}}$ ；单个用户关心的完成时间未必改善。
把多个作业塞在同一设备上，也可能因显存竞争和频繁切换降低每个作业吞吐。
调度从“填满设备”演进为“兼顾拓扑、等待、隔离与作业整体完成时间”。

#1. 为什么多 GPU 任务不能逐卡随意分配

设作业 $j$ 同时需要 $g_j$ 张设备，并要求各设备在一次训练 step 中同步。若只给其中一部分，已分配的设备可能空等其他设备。

Gang scheduling（成组调度）要求一组资源同时可用后才启动分布式任务。
数量够不代表拓扑合适：跨节点的张量并行可能使每层通信时间大于计算时间。
多作业共享设备时还需考虑显存容量、带宽与互联争用；只看设备忙时会掩盖单作业变慢。

#2. GPU 虚拟化与隔离的层次

GPU 隔离存在三种主要技术，隔离强度从弱到强依次为：时间片轮转、MPS 多进程服务和 MIG 硬件分区。

#2.1 时间片轮转（Time-Slicing）

时间片轮转是最基础的 GPU 共享方式。GPU 在多个进程或 VM 之间快速切换，每个进程获得一个时间片，在片内独占 GPU 的计算引擎。切换时，GPU 需要保存当前进程的上下文（寄存器状态、显存映射等），加载下一个进程的上下文。

上下文切换开销。 VM 之间的上下文切换引入 50–200 微秒的延迟，对延迟敏感的推理任务影响显著。内存管理开销增加 3–5%（地址转换和隔离执行），调度开销随租户数增加，8 个 VM 共享一张 GPU 时可达 15%。硬件特性（如中断合并）可将虚拟化开销从 18% 降至 7%。

调度策略。 NVIDIA vGPU 支持三种时间片调度策略：

Best Effort（默认） ：不限制任何 vGPU 的 GPU 周期使用量，vGPU 可以使用其他 vGPU 未使用的处理周期。灵活但无性能保证，一个图形密集型应用可能影响其他应用。
Equal Share：物理 GPU 在运行的 vGPU 之间均分。vGPU 增加或减少时，每个 vGPU 的份额相应变化。性能随其他 vGPU 的启停而波动。
Fixed Share：每个 vGPU 获得固定比例的物理 GPU 处理周期，取决于 vGPU 类型。vGPU 的增减不影响已运行 vGPU 的份额，性能稳定可预测。

适用边界。 时间片轮转不提供严格的性能隔离，适合对吞吐量要求不高、能容忍性能波动的场景。在 AI 推理中，它适用于多个低优先级任务共享 GPU 且不需要 SLA 保证的情况。

#2.2 MPS：多进程服务

MPS（Multi-Process Service，多进程服务）是配合 CUDA 应用运行的轻量级服务。应用仍调用原有 CUDA API；MPS 的 control daemon 与 server 负责协调多个 client 进程，使其 kernel 和内存拷贝可以在同一 GPU 上并发执行。它不是 CUDA API 的“二进制兼容替代实现”。

工作原理。 在没有 MPS 的情况下，多个进程共享 GPU 时，各自的 CUDA 上下文会带来调度和上下文切换开销。MPS 引入共享的 server 进程（nvidia-cuda-mps-server），把多个 client 的工作提交给 GPU 并提高并发度，从而减少部分上下文切换和调度开销。Volta 及更新架构上的 MPS client 仍保有各自的 GPU 地址空间与部分独立上下文资源，因此不能把它理解为所有状态都合并成唯一上下文。

MPS 的收益：

允许不同进程的 kernel 和内存拷贝操作在 GPU 上重叠，提高 GPU 利用率。
共享部分调度基础设施，减少进程间切换和资源交换开销。
降低多进程并发时的部分上下文与调度开销；具体共享范围取决于 GPU 架构和 MPS 版本。

MPS 的局限。 MPS 不提供硬件级隔离：多个进程共享 GPU 的显存带宽和计算引擎，一个进程的异常可能影响其他进程。MPS 适合每个进程的工作量不足以饱和 GPU 的场景，如小批量推理或轻量数据处理。

MPS v3 内存分区。 较新的 MPS v3 支持将 GPU 显存按 cgroup 和容器进行分数化分配，需要 Linux cgroup v2、CUDA 13.4+ 和非 MIG 设备。

#2.3 MIG：硬件分区

MIG（Multi-Instance GPU）是 NVIDIA Ampere 架构及以上 GPU 提供的硬件级 GPU 分区技术。它将物理 GPU 划分为最多 7 个完全隔离的 GPU 实例，每个实例拥有独立的高带宽显存、缓存和计算核心。

与时间片轮转的本质区别。 在 MIG 中，不同实例上的工作负载并行运行，而非串行等待时间片。每个实例拥有专用的计算、显存和显存带宽资源，一个实例的工作负载不会影响另一个实例的性能。一个实例上的应用崩溃不会影响其他实例。

可配置的实例大小。 以 NVIDIA GB200 为例，管理员可以创建两个 93 GB 的实例、四个 46 GB 的实例，或七个 23 GB 的实例。MIG 实例还可以动态重新配置：白天用于低吞吐量推理的七个实例可以在夜间重新配置为一个大型训练实例。

性能保证。 MIG 提供确定性的延迟和吞吐量。在没有 MIG 的情况下，一个消耗更大内存带宽的任务会使其他任务“挨饿”，导致多个任务错过延迟目标。MIG 通过为每个实例分配专用的显存带宽来消除这种干扰。

适用场景。 MIG 适合需要保证一致性能的多租户环境，如 MLOps 平台、共享研究集群，以及同时运行训练、推理和视频分析等不同工作负载的场景。

#2.4 三种隔离技术的对比

技术	隔离类型	隔离强度	并行性	适用场景
时间片轮转	时间分割	弱	串行切换	低优先级多任务共享
MPS	进程并发	中	并行（共享调度资源）	轻量多进程，单进程无法饱和 GPU
MIG	硬件分区	强	并行（独立资源）	多租户 SLA、训练/推理混部

#3. 容器、进程、设备隔离的不同层级

层级	能隔离什么	不能单独保证什么
进程与文件命名空间	运行环境与可见文件	GPU 显存和互联无争用
容器镜像	用户态依赖与程序版本	宿主驱动和硬件能力一致
设备分配/虚拟化	可见加速器与资源份额	不同任务具有相同延迟
网络与存储权限	数据路径与访问边界	模型输出本身安全

#3.1 cgroup 的资源隔离边界

cgroup（Control Group）是 Linux 内核提供的基础资源隔离机制，管理 CPU、内存和 I/O 等资源的分配与限制。现代系统使用统一的 cgroup v2。

cgroup 对 GPU 的支持有限。 cgroup v2 的设备控制器没有传统接口文件，而是通过 BPF 实现。它主要控制设备可见性（是否允许访问 /dev/nvidia*），不提供显存配额或 GPU 计算时间片限制。这意味着在 Kubernetes 中，容器级别的 GPU 资源限制主要依赖 device plugin 的数量分配（如分配 1 张 GPU），而非 cgroup 的细粒度配额。

#3.2 容器网络隔离

Kubernetes 通过 NetworkPolicy 实现 Pod 级别的网络隔离。NetworkPolicy 以应用为中心，使用标签选择器选择 Pod 并定义允许的入口和出口流量规则。一旦某个 Pod 被 NetworkPolicy 选中，它将拒绝所有未被明确允许的连接。这为多租户集群中的训练任务提供了网络层面的数据边界。

#3.3 容器运行时的 GPU 集成

容器本身不直接访问 GPU。GPU 访问通过两层机制实现：

NVIDIA Container Toolkit：在容器启动时，将宿主机的 NVIDIA 驱动库、CUDA 库和 GPU 设备节点注入容器。它作为 OCI 运行时（runc/crun）的前置钩子工作。
NVIDIA Device Plugin：Kubernetes DaemonSet，向 kubelet 注册节点上的 GPU 资源（如 nvidia.com/gpu: 8），使调度器可以按数量分配 GPU。

NVIDIA GPU Operator 将上述所有组件（驱动、Container Toolkit、Device Plugin、GPU Feature Discovery、DCGM 监控、MIG Manager）打包为 Kubernetes Operator 统一管理。

容器是可复现依赖和隔离的载体，不是模型加速算法。
设备虚拟化或切分提高资源利用率时，可能让小任务共享卡；但内存带宽、缓存和调度仍可能互相干扰。
训练的随机性还受数据顺序、数值库与并行归约影响；镜像相同并不保证逐 bit 复现。

#4. 调度是带约束的放置问题

令页首的 $a_{jd}\in\{0,1\}$ 表示作业 $j$ 是否占用设备 $d$ ，设备容量为 $M_d$ 、作业需显存 $m_j$ 。一个最基本约束为：

\sum_j a_{jd}m_j\leq M_d,\qquad \sum_d a_{jd}=g_j.

真正系统还需加入设备类型、拓扑邻近、数据本地性、优先级和作业起止时间；上式只是容量层的骨架。

尽量把高频互联的设备放在一起，可减少节点内通信与跨节点通信代价。
将一个多卡作业拆散到多个空闲位置，可能降低等待时间却增加每 step 成本；总完成时间才是目标。

#5. Gang Scheduling 与调度算法

#5.1 Gang Scheduling 的核心机制

Gang scheduling（成组调度）的核心是 “All or Nothing” ：一个 Job 下的所有 Pod 必须同时调度成功，否则全部不调度。如果只启动了部分 worker，其余资源未就绪，已启动的 worker 可能空等，导致死锁。

Volcano 的 Gang 调度实现。 Volcano 是 CNCF 下的 Kubernetes 批处理调度器，通过 PodGroup 资源定义 Job 的最小运行成员数（minMember）。调度器检查 Job 下已调度的 Pod 数量是否满足最小运行数量，满足才实际分配资源。Volcano v1.15 引入了 Gang-Aware Preemption：抢占决策在抢占方和被抢占方两侧都以 Gang 为整体评估。被抢占候选者被区分为冗余副本（超出 minMember 的部分）和关键副本，调度器优先驱逐冗余副本，避免打断任务；在驱逐前先做放置模拟，验证抢占方 Gang 能否整体调度成功。

Kueue 的队列管理。 Kueue 是 Kubernetes 原生作业队列系统，作为调度器之前的准入控制器工作，管理队列和配额而不替换核心 Kubernetes 组件。Kueue 的核心能力包括：多租户全局配额管理、动态容量共享（空闲资源可被其他团队借用）、拓扑感知放置和多集群扩展。

#5.2 Bin-Packing：减少碎片

Gang scheduling 保证了 All-or-Nothing，但不指定具体的放置策略。随机放置会导致 GPU 碎片化——多个节点各被部分占用，无法组成一个完整的 8 卡训练作业所需的连续资源。

Bin-packing 策略。 将部分占用的节点按当前利用率从低到高排序，新工作负载优先放置在空闲资源最少的节点上，确保节点被充分利用后再转移到其他节点。NVIDIA 在 Volcano Scheduler 中集成 bin-packing 后，DGX 云集群的 GPU 占用率达到约 90%，超过 80% 的合同目标。

Bin-packing 与 Gang Scheduling 的集成。 增强型调度器保留了 gang scheduling 的“全有或全无”原则，但增加了智能——根据资源整合优先级安排工作负载放置。在没有 bin-packing 的情况下，一个需要 2 张 GPU 的新工作负载可能被随机放在空闲节点 B 上，使两个节点都被部分占用；集成 bin-packing 后，工作负载被放在已占用 2 张 GPU 的节点 A 上，使其完全用满，节点 B 保持完全空闲，可用于后续需要 4 张 GPU 的作业。

#5.3 抢占与公平性

策略	解决的问题	新代价
FIFO	顺序公平、简单	大任务阻塞后面小任务
Backfilling	利用短期空闲槽	运行时长估计错误会延误预留
抢占	高优先级响应	检查点与恢复成本、低优先级饥饿
拓扑感知放置	降通信成本	可行位置减少、等待变长

#6. 利用率、排队与完成时间

页首的 $T_j$ 已包含排队、运行和重启三部分；此处不再换用 $T_{\mathrm{complete}}$ 重复列式。

高利用率常意味着队列更满；若服务能力接近到达率，排队时间可能快速增加。
抢占可让高优先任务更快开始，但被抢占任务有 Checkpoint 与恢复成本；没有可恢复状态时，抢占会浪费已完成计算。
对推理服务，还须区分系统平均吞吐与用户 P99 延迟；排队策略在服务编排解释。

#7. 资源碎片化的多维分析

#7.1 拓扑碎片

若一个训练任务需要同一强互联域内 $g$ 张 GPU，而集群剩余 GPU 总数虽大于 $g$ ，却分散在多个节点或交换域，任务仍无法有效启动。这叫拓扑/资源碎片化。资源利用率 $U$ 高，不一定表示高价值任务完成得快；小任务填满碎片可能让大型 gang 任务持续排队。

#7.2 显存碎片

即使 GPU 数量充足，每个作业也需要一定的显存。不同作业的显存需求会使设备剩余容量难以被新作业利用。MIG 用固定 profile 将计算与显存资源一起分区，能减少无边界共享造成的资源争用并提高可预测性，但不会从根本上消除碎片：作业需求与 profile 不匹配时仍会产生实例内部碎片或放置碎片。

#7.3 NUMA 亲和性

在多 CPU 插槽服务器中，GPU 通过 PCIe 连接到特定的 CPU 插槽（NUMA 节点）。如果数据处理线程、内存页和目标 GPU 位于不同 NUMA 域，访问可能跨主机互联，延迟和带宽都变差。Kubernetes 的 NUMA 拓扑感知调度将 Pod 的 CPU 和 GPU 放在同一 NUMA 节点上，消除不必要的跨节点流量。当 GPU、网卡、CPU 和内存未能正确对齐在同一 NUMA 节点或 PCIe 根时，性能可能下降 30–50% 甚至更多。

阿里云 ACK 的 NUMA 拓扑感知调度。 通过 Scheduler Framework 机制实现，使用 gputopo-device-plugin 和 ack-koordinator 组件上报节点 CPU、GPU 拓扑结构，支持在工作负载上声明 NUMA 拓扑分配策略。

#8. 发展链与适用边界

单机独占 → 多任务容器化 → 成组分配多卡 → 拓扑感知放置 → 根据负载与故障动态调整。

改进	解决的旧问题	新增代价
容器化	依赖冲突与环境不一致	镜像/驱动边界需管理
MPS	单进程无法饱和 GPU	无硬件隔离，进程间干扰
MIG	多租户性能干扰	分区灵活性降低、大作业无法使用完整 GPU
Gang scheduling	分布式作业部分启动后空等	大作业可能等待更久
Bin-packing	随机放置导致的 GPU 碎片	可能加剧拓扑碎片
拓扑感知	多卡互联差异造成性能波动	放置选择更受限
抢占与动态调度	高优先任务响应慢	恢复、迁移与公平性问题

边界： 本页讨论计算资源如何被分配；模型服务讨论已分配资源上逐请求的 batch 调度。

#9. 隔离的边界

容器化隔离文件系统、进程和依赖版本，但共享 GPU 的显存、带宽、缓存和驱动可能仍互相干扰。设备分区可以增强资源隔离，却可能让大矩阵乘无法使用完整设备。

安全隔离、性能隔离、故障隔离是三个不同目标，需明确需要哪一种：

安全隔离：防止一个租户访问另一个租户的数据。MIG 提供硬件级安全隔离，时间片轮转不提供。
性能隔离：防止一个租户的工作负载影响另一个租户的性能。MIG 通过专用显存带宽保证性能确定性；MPS 和时间片轮转不保证。
故障隔离：防止一个租户的崩溃影响其他租户。MIG 的实例故障不传播到其他实例；MPS 中一个进程的异常可能影响共享调度资源。

当多租户任务共同训练或推理，指标应包含任务级吞吐下降、尾延迟、显存超额、故障传播范围；单任务 benchmark 无法验证隔离效果。

#原始资料

本页由仓库中的 Markdown 生成。具体技术结论请结合正文引用与实验条件理解。