云平台调度GPU算力的本质,是把物理显卡拆成多个逻辑算力单元,再通过调度器按需分配给不同训练任务,让一张A100能同时服务好几个小模型训练,或者把多张卡组合成一个算力池供大模型独占使用。
云平台GPU算力调度怎么做:先拆卡再排队
云平台不像你桌上的工作站,插上显卡就能直接跑,它背后是成百上千张加速卡,任务来自不同团队、不同项目,有的训练大语言模型要8卡,有的跑个小分类器半张卡就够了,调度系统要回答两个问题:这张卡此刻能不能分出去?分给谁最划算?
先看拆卡,物理GPU在云平台眼里不是最小粒度,逻辑算力单元才是,拆卡方式决定了并行效率的上限。
GPU虚拟化切分技术对比:三种主流路线
目前行业里拆卡主要有三条路,各有各的脾气。
- PCIe直通:整卡分配给一个虚拟机或容器,性能损耗接近零,但颗粒度太粗,小任务吃不饱,属于"一卡一住"的独栋模式。
- MIG切分:NVIDIA从Ampere架构开始提供的硬隔离方案,把一张A100切成7个独立实例,每个实例有自己的显存和计算通道,互不干扰,训练任务对显存带宽和算力稳定性敏感,生产环境中MIG的使用比例在逐年上升。
- API拦截型vGPU:在驱动层做虚拟化,把物理卡包装成多个虚拟卡,兼容性好但性能损耗相对明显,适合图形渲染和轻量推理场景。
业内专家指出,选择哪种虚拟化路线,本质上是在隔离强度、性能损耗、调度灵活性三者之间做取舍,训练场景优先考虑MIG和整卡独占,推理场景可以放开用vGPU和时间片方案。
Kubernetes调度GPU训练任务的基本流程
现在多数云平台的GPU调度建立在Kubernetes之上,流程可以拆成四步。
- 节点上报:每台GPU服务器上的device-plugin向K8s汇报可用GPU型号、数量、显存大小。
- 任务声明

:用户提交的YAML里写清楚需要几张卡、什么型号、多少显存。
- 过滤打分:调度器先过滤掉资源不够的节点,再按剩余资源量、网络拓扑、当前负载打分。
- 绑定运行:任务被绑定到具体节点,device-plugin把对应的GPU设备挂载进容器。
这里的核心是扩展资源名称,标准K8s只认识CPU和内存,GPU通过nvidia.com/gpu这类扩展资源名被识别,用户申请nvidia.com/gpu: 2,调度器就去找还有两张空闲卡的节点。
多任务并行调度的关键机制
拆完卡,任务排着队等资源,调度系统要保证高优先级任务不被饿死、低优先级任务不浪费空闲算力、紧急任务能插队。
队列与优先级抢占
云平台通常设置多级队列,训练任务提交后进入对应队列,调度器按优先级轮询,当高优先级任务资源不够时,会触发抢占机制把低优先级任务驱逐出节点,腾出GPU给它。
抢占不是无代价的,被驱逐的任务要重新排队,已经算了几小时的进度可能白费,所以多数平台要求训练任务定期保存checkpoint,被抢占后从最近存档继续,而不是从头再来。
拓扑感知调度
多卡训练对GPU之间的通信速度极其敏感,两张卡如果不在同一台服务器上,数据要通过网络传输,训练速度可能慢好几倍,调度器需要做拓扑感知:
- 优先把同一任务的多张卡分配到同一台物理机。
- 如果跨机不可避免,选择NVLink直连或InfiniBand网络互通的节点。
- 记录GPU的PCIe拓扑,把通信频繁的卡分配在相邻PCIe交换机下。
动态伸缩与弹性任务
有些平台的调度器支持弹性训练:当集群出现空闲GPU时,运行中的训练任务可以临时扩容,多拉几张卡加速;当高优先级任务需要资源时,再缩回去,这对调度器的实时监控能力要求很高,但对提升整体利用率效果明显。

实操:提交一个并行训练任务的完整配置
假设你要在云平台上跑一个PyTorch分布式训练,申请4张卡,YAML配置大致是这样:
apiVersion: batch/v1
kind: Job
metadata:
name: gpu-training-job
spec:
parallelism: 4
template:
spec:
containers:
- name: trainer
image: pytorch/pytorch:latest
resources:
limits:
nvidia.com/gpu: 1
env:
- name: MASTER_ADDR
value: "gpu-training-job-0"
- name: WORLD_SIZE
value: "4"
command: ["torchrun", "--nproc_per_node=1", "--nnodes=4", "train.py"]
restartPolicy: Never
这里面几个关键点值得展开:
nvidia.com/gpu: 1:每个Pod申请1张卡,4个Pod并行,调度器会尽量把它们分散到有空间的节点上。- 环境变量:
MASTER_ADDR和WORLD_SIZE是分布式训练的通信基础,K8s的Job控制器会自动注入。 - 节点亲和:如果希望4个Pod尽可能在同一台机器,可以加
nodeAffinity或使用拓扑调度约束。
提交后,调度器找节点、挂载GPU、拉镜像、启动容器,全程不需要人工干预。
性能与成本:并行调度的现实考量
共享调度对比独占调度的性能损失
这是很多用户关心的问题,把一张卡切给多个任务,性能是否线性下降?
答案取决于切分方式和任务类型,MIG切分的显存和算力是硬隔离的,各实例之间的干扰很小,接近理论值,时间片方案则存在切换开销,当任务数量多、时间片短时,有效吞吐会明显低于整卡,PCIe直通没有切分损耗,但一张卡同一时间只能服务一个任务。
行业共识认为,对于显存敏感的模型训练,MIG的性价比最高;对于算力密集但显存需求小的推理任务,时间片方案能榨出更多利用率。
云GPU服务器租用价格的关键影响因素

云GPU服务器租用价格不是只看显卡型号,以下几个因素对价格影响很大:
- 切分粒度:整卡独占最贵,MIG实例按比例计价,时间片按小时计费最便宜。
- 地域节点:不同地域的GPU资源池成本有差异,一线城市核心机房的租用价格通常高于边缘节点。
- 网络与存储:多卡训练如果跨节点,高速网络(如InfiniBand)的带宽费用会加在账单里。
- 使用时长:包年包月比按量付费便宜不少,但灵活性差,不少平台提供竞价实例,价格可能只有按量的一半,但随时可能被回收。
选型时别只看单价,要算每训练一个epoch的实际成本,一张便宜的卡如果网络差、通信慢,总训练时间拉长,总花费反而更高。
常见问题
云平台GPU算力调度怎么做才能避免资源浪费?
关键在分时复用和动态调整,把训练任务按优先级分层,高优先级用整卡或MIG独占,低优先级用时间片填充碎片时段,同时开启弹性伸缩,让空闲卡自动并入运行中的任务,定期分析集群利用率报表,调整队列配额。
多卡训练和单卡训练在云平台上有什么区别?
单卡任务调度简单,找到一张空闲卡就能跑,多卡训练要求调度器同时找到多张满足条件的卡,还要考虑卡间通信拓扑,调度难度成倍增加,这也是为什么多卡任务在高峰期排队时间更长的原因不是总卡数不够,而是连续可用的卡组不够。
GPU虚拟化和直接调用物理GPU性能差多少?
PCIe直通方案性能损耗通常在5%以内,几乎可忽略,MIG切分后的单实例性能与切分比例基本成正比,额外开销很小,vGPU和时间片方案的性能波动较大,取决于同时运行的任务数量和工作负载类型,训练任务建议优先考虑PCIe直通或MIG,推理任务可以接受vGPU的微小损耗换取更高的资源利用率。