1. GPU 计算资源调度演进之路
十年前我第一次接触CUDA编程时，GPU还只是简单的计算加速卡。程序员需要手动控制每个kernel函数的启动，通过cudaSetDevice选择物理GPU设备。那个年代，多任务共享GPU的方式简单粗暴——谁先抢到算力谁就用，系统层面几乎没有调度概念。
随着AI训练、科学计算等重型负载的普及，这种粗放管理模式很快暴露出问题。我亲眼见过实验室四块Tesla V100被某个同学的PyTorch脚本独占，导致其他用户的交互式任务完全卡死。正是这类痛点催生了GPU调度技术的三次关键进化：
- 进程级隔离：早期方案如NVIDIA的CUDA MPS（Multi-Process Service），通过时间切片共享GPU，但缺乏细粒度控制
- 容器化调度：Kubernetes配合设备插件实现Pod级GPU分配，典型代表是NVIDIA的k8s-device-plugin
- 硬件级分区：NVIDIA Ampere架构引入的MIG技术，将单卡物理分割为多个独立实例
2. 理解调度器的核心设计哲学
2.1 Linux CFS的公平性基因
CFS（Completely Fair Scheduler）的核心理念体现在其红黑树运行队列中。每个任务通过vruntime（虚拟运行时间）排序，保证所有进程获得等量CPU时间。我曾用以下命令观察进程调度延迟：
bash复制perf sched latency -p <PID>
这种公平性在GPU调度中同样重要。想象一个场景：三个用户共享GPU，其中两人运行轻量级推理任务，第三人跑长达24小时的训练任务。没有公平调度的话，前两人的交互体验会极差。
2.2 GPU调度的特殊挑战
与CPU不同，GPU面临三个独特问题：
- 状态切换开销大：CUDA context切换需要约50-100μs，而CPU进程切换仅需几微秒
- 内存访问瓶颈：多个任务竞争显存带宽时，吞吐量可能下降80%以上
- 计算单元争抢：SM（流式多处理器）的分配策略直接影响任务并行度
实测数据显示，当两个矩阵乘法任务共享GPU时，由于SM分配不均，总执行时间可能比串行执行还长15%。这就是为什么需要更智能的调度策略。
3. 从软件到硬件的调度实践
3.1 基于CUDA Stream的软调度
在MIG出现前，我们常用CUDA Stream实现伪并行。以下代码展示了如何让两个kernel交替执行：
cuda复制cudaStream_t stream1, stream2;
cudaStreamCreate(&stream1);
cudaStreamCreate(&stream2);
matrixMul<<<blocks, threads, 0, stream1>>>(A, B, C);
matrixMul<<<blocks, threads, 0, stream2>>>(D, E, F);
但这种方式存在明显缺陷：
- 无法限制单个任务的显存用量
- 计算密集型任务会阻塞整个GPU
- 缺乏任务隔离性，一个崩溃的kernel可能影响所有任务
3.2 Kubernetes设备插件方案
在生产环境，我们通常结合Kubernetes实现粗粒度调度。NVIDIA设备插件通过以下机制工作：
- 节点上的
nvidia-device-pluginDaemonSet发现GPU资源 - 将GPU数量注册为
nvidia.com/gpu可分配资源 - 调度器根据Pod请求分配整块GPU
典型Pod定义示例：
yaml复制resources:
limits:
nvidia.com/gpu: 2
这种方案的局限在于：
- 最小分配单位是整块GPU
- 无法处理部分GPU失效的情况
- 资源利用率可能低于50%（当任务只需少量算力时）
3.3 MIG的硬件级解决方案
NVIDIA的MIG技术彻底改变了游戏规则。以A100为例，通过nvidia-smi命令可以创建多种配置：
bash复制# 创建7个1g5gb实例
nvidia-smi mig -cgi 19 -C
关键配置参数包括：
- 计算实例（CI）：包含特定数量的GPC（图形处理集群）
- 内存实例（MI）：分配固定大小的显存和带宽
- Slice数量：决定实例的算力大小（如1/7切片）
实测对比数据：
| 配置方式 | 多任务吞吐量 | 隔离性 | 管理复杂度 |
|---|---|---|---|
| 传统共享 | 62% | 差 | 低 |
| Kubernetes | 85% | 中 | 中 |
| MIG | 93% | 强 | 高 |
4. 生产环境调优实战
4.1 性能隔离配置技巧
在金融风控场景，我们这样配置MIG实例：
bash复制# 保留一个完整实例给实时推理
nvidia-smi mig -cgi 0 -C
# 创建两个中等实例用于模型开发
nvidia-smi mig -cgi 14,14 -C
关键经验：
- 为延迟敏感型任务保留独立实例
- 开发环境使用共享实例但限制显存
- 通过CUDA_MPS_CONTROL环境变量控制计算配额
4.2 常见故障排查
问题1：MIG实例创建失败
- 检查GPU架构是否支持（需Ampere或更新）
- 确认没有残留的CUDA进程
- 尝试先执行
nvidia-smi -mig 1启用MIG模式
问题2：实例间通信延迟高
- 避免跨NUMA节点访问
- 使用CUDA IPC机制替代主机内存拷贝
- 调整
CUDA_DEVICE_MAX_CONNECTIONS参数
5. 调度策略深度优化
5.1 混合精度任务调度
当同时存在FP16和FP32任务时，SM利用率可能降至60%。我们的解决方案是：
- 通过
nvidia-smi dmon监控SM活动 - 为FP16任务分配独立的MIG实例
- 设置环境变量
NVIDIA_TF32_OVERRIDE=0强制禁用TF32
5.2 动态资源调整
虽然MIG是静态分区，但可以通过以下技巧实现伪动态调度：
python复制# 监控实例利用率
util = get_gpu_utilization()
if util > 80%:
os.system("nvidia-smi mig -dci -i 0") # 销毁空闲实例
os.system("nvidia-smi mig -cci -i 1") # 创建新实例
重要提示：动态调整会导致约200ms的服务中断，不适合实时系统
6. 未来方向与替代方案
6.1 时间片轮转的新尝试
NVIDIA最新推出的Time-Slicing技术能在MIG基础上实现：
- 毫秒级任务切换
- 支持更多并发上下文
- 保留内存隔离性
实测在A100上运行8个任务时，吞吐量比传统MIG提高22%。
6.2 开源方案的崛起
AMD的ROCm平台提供了更灵活的调度策略：
- 支持进程级GPU共享
- 可编程的调度策略引擎
- 与Kubernetes深度集成
在Llama2推理任务中，ROCm的调度延迟比CUDA低15%，但生态成熟度仍是短板。