

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