---
title: 异构算力调度：GPU 不是供品，资源池化才是硬仗
url: https://www.17lubbs.com/yi-gou-suan-li-diao-du-gpu-bu-shi-gong-pin-zi-yuan-chi-hua-cai-shi-ying/
site: 17lubbs
author: 17lubbs 编辑部
published: 2026-10-28T12:39:28+08:00
updated: 2026-10-29T15:02:03+08:00
category: 技术落地
language: zh-CN
license: CC BY 4.0
---

# 异构算力调度：GPU 不是供品，资源池化才是硬仗

> 训练任务排队到天亮，推理服务却只吃掉半张卡，这是调度失效而不是算力不足。8 卡机器按整卡分配时利用率常只有 40%，引入 MIG 与显存切分能接住碎片需求，但必须配合 cgroup 与驱动层隔离，否则…

一台 8 卡机器，训练任务排队到天亮，推理服务却只吃掉半张卡——这是典型的调度失效，不是算力不足。按整卡分配是最简单的策略，也是浪费最严重的策略：单卡利用率常常只有 40%，剩下 60% 被”占着不用”。

## 为什么整卡分配会浪费一半算力？

因为负载的形状和卡的形状不匹配。训练任务通常能吃满整卡，但推理服务、数据预处理、小模型微调这些任务的资源需求是碎片化的：可能只需要 8GB 显存、2 个 CPU 核、偶尔一次前向计算。按整卡分配时，这些任务各占一张卡，卡上其余部分闲置。

结果就是：集群看起来卡都分配出去了，实际算力利用率却很低。监控面板上”GPU 已分配 100%”和”GPU 实际利用 40%”同时成立，这不是矛盾，是分配粒度过粗。

## 切分方案怎么选？

四种常见粒度，适合不同场景，代价各不相同。

| 方案 | 隔离强度 | 适用场景 | 主要代价 |
| --- | --- | --- | --- |
| 整卡独占 | 最强 | 大模型训练、对延迟敏感的推理 | 利用率低 |
| MIG 硬件切分 | 强 | 多租户推理、稳定的小模型服务 | 切分粒度固定，不能动态调整 |
| 显存切分（软件） | 弱 | 开发调试、短任务 | 故障会扩散到同卡其他任务 |
| 时间片轮转 | 中 | 批处理任务 | 上下文切换开销，延迟不稳定 |

实践中常见组合是：训练走整卡或 MIG 大切片，推理走 MIG 小切片，开发环境用软件切分但限制在独立节点上。

## 切分带来的隔离风险有多严重？

比多数人预期的严重。软件层显存切分只是”约定”，不是硬件强制：一个任务显存越界，可能触发整卡重置，同卡其他任务全部中断。这在多租户环境里是不可接受的。

三层隔离要一起做：硬件层用 MIG 做物理切分，边界由硬件保证；系统层用 cgroup 限制 CPU、内存与进程数；驱动层开启错误隔离，让单个进程的异常不扩散。缺任何一层，故障都会穿透到邻居。

## 调度策略应该怎么定？

- **按实测性能分级，不按型号**：同型号卡因散热与功耗墙差异，实测性能可能差 15%。建基准表，按实测值分配。

- **给碎片任务设专用池**：不要让小任务和大训练抢同一批卡，物理隔离比调度算法更可靠。

- **设置抢占与回收**：低优先级任务可被高优先级抢占，但要有检查点机制，避免抢占等于重跑。

- **把利用率作为考核指标**：只看”分配率”会掩盖浪费，必须同时看实际计算利用率与显存占用率。

## 小规模集群（十台以内）需要做这么复杂吗？

不需要全套，但两件事值得做：一是开启 MIG 把推理和训练物理隔开，二是建立任务排队与优先级，避免”谁先提交谁占卡”。十台以内的集群，管理成本主要来自人的协调，而不是技术复杂度。

## 利用率提到多少算合理？

视负载结构而定。以推理为主、切分合理的集群，实际计算利用率做到 60% 到 70% 是可达的；以训练为主则通常低于 50%，因为训练本身存在数据加载与通信等待。低于 30% 说明分配粒度过粗或存在资源囤积，需要排查。

---

## 引用本文

17lubbs：《》，17lubbs，，