GPU 集群调度架构解析


大家好,我是 子玥酱,一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案,
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向:前端 / 跨端 / 小程序 / 移动端工程化
内容平台:掘金、知乎、CSDN、简书
创作特点:实战导向、源码拆解、少空谈多落地
文章状态:长期稳定更新,大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”,而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍,希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端,或准备长期走前端这条路
📚 关注我,第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源(工程化 / 框架 / 跨端 / 面试 / 架构)
💡 一起把技术学“明白”,也用“到位”
持续写作,持续进阶。
愿我们都能在代码和生活里,走得更稳一点 🌱
文章目录
引言
过去几年,大模型行业有一个非常有趣的现象。
大家讨论最多的是:
GPT
DeepSeek
Llama
Qwen
Claude
讨论第二多的是:
训练框架
推理框架
MoE
RLHF
Agent
但真正决定一家 AI 公司成本和效率的,往往不是这些。
而是:
GPU 集群调度系统
很多团队购买了几百张 GPU 后才发现:
GPU 不够贵,闲置才最贵。
例如:
GPU 利用率仅30%
任务长期排队
训练任务互相抢资源
推理服务频繁扩缩容
最终导致:
算力很多
效率很低
因此对于 AI 基础设施团队来说:
GPU Scheduler 才是真正的“大脑”。
甚至可以说:
GPU = CPU
GPU Scheduler = Kubernetes
如果没有调度系统:
1000张GPU
≈
100张GPU
因为大部分资源都会被浪费。
一、为什么 GPU 调度如此困难
很多人第一次接触 GPU 集群时会觉得:
CPU调度都解决了
GPU调度有什么难的?
实际上完全不同,CPU 调度:
任务粒度小
资源弹性高
切换成本低
GPU 调度:
任务巨大
资源昂贵
切换成本高
例如,一个 Web 服务:
2 Core
4 GB RAM
随时可以迁移,但一个大模型训练任务:
64 GPU
512 CPU
2TB Memory
一旦启动:
不能轻易迁移
否则代价极高。
二、GPU 集群核心架构
典型架构如下:
User
│
▼
┌─────────────────┐
│ Submit Job │
└────────┬────────┘
▼
┌─────────────────┐
│ Scheduler │
└────────┬────────┘
▼
┌─────────────────────────────┐
│ Resource Manager │
└───────────┬─────────────────┘
▼
┌────────────────────┐
│ GPU Cluster │
└────────────────────┘
核心组件包括:
Job Queue
Scheduler
Resource Manager
Node Manager
Monitor
三、任务提交流程
训练任务启动时:
python train.py
实际上背后发生了很多事情。用户提交:
gpu: 8
cpu: 64
memory: 512G
进入:
Job Queue
任务状态:
Pending
Running
Completed
Failed
Scheduler 开始寻找资源。例如:
Node-A GPU不足
Node-B GPU不足
Node-C 满足条件
最终:
任务分配到 Node-C
开始训练。
四、GPU Scheduler 核心职责
调度器主要解决四个问题:
放哪里
什么时候放
放多少资源
如何保证公平
即:
Placement
Allocation
Priority
Fairness
五、资源发现机制
Scheduler 首先要知道:
集群有哪些资源
例如:
GPU型号
GPU数量
CPU数量
内存大小
网络带宽
节点定期上报:
{
"node":"gpu-001",
"gpu":8,
"gpuType":"H100",
"cpu":128
}
Scheduler 构建:
Cluster View
集群视图。
六、资源匹配算法
假设用户申请:
8 × H100
集群情况:
NodeA 4 H100
NodeB 8 H100
NodeC 16 A100
调度器需要选择:
NodeB
因为:
满足需求
碎片最少
这就是:
Best Fit
策略。
常见策略
1.First Fit
找到就放
优点:
速度快
缺点:
碎片严重
2.Best Fit
选择最接近需求的节点
优点:
资源利用率高
缺点:
调度开销大
3.Bin Packing
目标:
尽可能塞满节点
例如:
8GPU节点
任务A 2GPU
任务B 2GPU
任务C 4GPU
放一起,这样:
空闲节点更多
方便后续大任务调度。
七、大模型训练中的 Gang Scheduling
这是 GPU 调度最核心的技术之一,训练任务经常要求:
8 GPU
16 GPU
64 GPU
128 GPU
问题来了,如果:
只找到63张GPU
怎么办?答案:
不能启动
因为:
分布式训练要求同时启动
这就是:
Gang Scheduling
原理
普通任务:
找到资源就运行
Gang Task:
全部资源到位
↓
同时启动
例如:
8 GPU Training
必须:
GPU1
GPU2
GPU3
GPU4
GPU5
GPU6
GPU7
GPU8
全部 Ready,否则:
继续等待
八、GPU 碎片化问题
这是所有 AI 公司都会遇到的问题。例如:
NodeA 剩余 1 GPU
NodeB 剩余 2 GPU
NodeC 剩余 1 GPU
总共:
4 GPU
看起来资源很多,但用户需要:
4 GPU 连续资源
实际上无法调度。这就是:
GPU Fragmentation
为什么越来越严重
因为:
训练任务结束时间不同
导致:
GPU空洞
越来越多,最终:
资源利用率下降
九、GPU 共享技术
为了提升利用率,行业开始使用:
MIG
vGPU
Time Slicing
NVIDIA MIG
把一张 GPU 切成多个实例。例如:
1 H100
↓
7 个小GPU
适用于:
推理任务
小模型训练
这样:
资源利用率更高
十、推理调度架构
训练与推理完全不同,训练:
长任务
推理:
短任务
例如:
请求到达
↓
模型推理
↓
返回结果
只有几百毫秒,因此调度目标变成:
低延迟
高吞吐
推理调度流程
Request
│
▼
Load Balancer
│
▼
Model Router
│
▼
GPU Worker
其中:
Model Router
最关键,负责:
路由到哪个模型
路由到哪个GPU
十一、多租户调度
企业 GPU 集群通常不是一个团队使用,例如:
推荐团队
搜索团队
大模型团队
数据团队
都在抢 GPU,因此需要:
Quota
配额系统。例如:
teamA: 40%
teamB: 30%
teamC: 30%
避免:
一个团队占满所有GPU
十二、抢占式调度(Preemption)
当重要任务到来时。怎么办?例如:
CEO要求训练紧急模型
但:
GPU已经满了
此时 Scheduler 可以:
暂停低优先级任务
释放 GPU。这就是:
Preemption
工作流程
高优任务到达
↓
发现资源不足
↓
选择低优任务
↓
保存Checkpoint
↓
回收GPU
↓
启动高优任务
十三、GPU 集群监控系统
没有监控:
等于盲飞
通常需要监控:
GPU利用率
显存占用
训练吞吐量
网络流量
故障率
典型指标:
GPU Utilization
Memory Usage
Tokens/sec
Samples/sec
十四、AI时代的新调度挑战
过去:
单模型训练
现在:
MoE
RLHF
Agent
多模型协同
出现新的问题:
GPU拓扑感知
RDMA调度
跨机房训练
异构GPU调度
Scheduler 不再只是:
资源分配器
而是:
AI Infrastructure Brain
十五、未来趋势:AI Native Scheduler
未来 GPU Scheduler 会越来越智能。
传统模式:
规则驱动
未来:
AI驱动
例如:
预测任务完成时间
预测GPU需求
自动扩容
自动迁移
形成:
Self-Driving Cluster
自治算力集群。
总结
很多人认为大模型时代最重要的是:
模型
算法
数据
实际上当规模达到:
100 GPU
1000 GPU
10000 GPU
以后,真正决定效率的往往是:
GPU 调度系统
因为:
模型决定能力上限
Scheduler决定资源利用率
从某种意义上说:
AI 时代的 Kubernetes,不是 Kubernetes 本身,而是面向 GPU 的新一代调度系统。
而未来所有 AI 基础设施的竞争,最终都会回到一个核心问题:
如何让每一张 GPU 都创造最大价值。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)