在 21.3 节中，我们讨论了如何定位和优化训练中的通信、计算与存储瓶颈。但即便单次训练任务已经极致调优，集群维度上仍然可能存在大量算力浪费：GPU 长时间空闲等待、任务排布稀疏导致资源割裂、预留过量资源形成黑洞。本节聚焦三种已经被大厂和中小团队验证有效的策略——任务打包、资源超配、空闲资源回收——它们分别解决“怎么把活塞得更满”“怎么一分钱当两分花”“怎么把摸鱼的 GPU 揪出来”的问题。
一、为什么算力利用率如此重要？
先明确衡量指标。算力利用率通常用 GPU 活跃时间占比 和 GPU 计算单元实际利用率（SM Usage / Tensor Core Usage） 来刻画。但作为集群管理员，更有实用价值的是：
有效算力利用率 = （实际完成的有效计算量） / （集群理论峰值算力 × 占用时间）一个万卡集群如果整体有效利用率只有 30%，相当于有 7000 张卡在付费空转——这在大模型团队中并不罕见。提升利用率直接等同于降低单位 Token 的训练/推理成本。在云厂商收费按卡时计费、自建机房按电费+折旧计算的现实下，这是运维团队最直接的价值输出。
二、任务打包（Job Packing）：让“零碎活”挤上同一张卡
2.1 问题场景
集群中常见碎片化资源：2 张卡闲着 16GB 显存，3 张卡闲着 8 核 CPU，但它们无法组成一台完整的 8 卡训练节点。同时，大量小规模任务（如 1 卡微调 LoRA、数据预处理、模型转换、小批量验证推理）各自独占整张卡，却只用到了三成算力，显存刚刚过线但 GPU 计算单元大量空闲。如果按传统调度逻辑，一张卡上一个任务，就会导致大量“算力泡沫”。
2.2 核心思路
任务打包就是将多个显存或计算消耗低的任务，同时调度到同一张 GPU 上，让它们共享 GPU 的计算单元和显存带宽，从而榨干单卡余量。
2.3 具体落地方案
方案一：基于 MPS（Multi-Process Service）的 CUDA 多进程共享
NVIDIA MPS 允许多个 CUDA 进程同时使用同一 GPU，它在 Volta 之后的架构上尤其成熟。原理是 MPS Server 将多个 Client 的 CUDA Kernel 提交合并到一个上下文，减少上下文切换开销。适合的场景是推理服务、小实验训练等对延迟不苛刻的任务。
- 开启 MPS 后，在同一 GPU 上同时跑 2~3 个小模型推理实例，GPU 计算利用率可从 30% 提升至 70% 以上。
- 注意：MPS 对显存没有保护隔离，一个进程的显存越界可能导致同卡其他进程崩溃，所以要求任务不完全野蛮，最好配合容器环境做显存限制（如
nvidia-container-runtime的--gpus选项限制显存）。
方案二：基于时间片（Time-Slicing）的 GPU 切分
利用 NVIDIA 的 GPU Operator 或推理框架（如 Triton Inference Server 的 instance group），可以将一张物理 GPU 切分为多个时间片，轮转分配给不同容器。这种方式显存隔离更好，但引入了上下文切换延迟。适用于低负载推理任务或模型转换与预处理等批处理作业。
- K8s 下可通过配置
nvidia.com/gpu资源为nvidia.com/gpu.shared实现时间片复用。 - 将数据预处理、小模型转换任务打包到训练卡上，和主训练任务在时间上错峰使用同一张卡，实现“白天训练、晚上预处理”。
方案三：自动打包调度器
修改集群调度系统（如 Slurm 或 K8s 调度器）的调度策略：
- 给任务标注“弹性”标签：标记哪些小任务允许被打包（packable），并设置 GPU 显存最小需求（如
--gres=gpu:2g表示只需 2GB 显存）。 - 调度器在分配时优先将多个“弹性”小任务塞到一张卡上，直到卡的总显存利用率达到设定阈值（如 90%）。
- 为训练等大任务保留整卡独占标记，避免打包导致性能降级。
实用建议：打包策略优先用于推理、数据清洗、转换和验证任务，微调任务需谨慎测试。MPS 和打包不适合延迟敏感的实时在线推理，因为突发 Kernel 同步可能导致 P99 延迟抖动。
三、资源超配（Resource Overcommit）：一份物理资源，多份逻辑承诺
3.1 问题场景
所有用户提交任务时，几乎都会高估需求：要 4 卡，其实只用 2 卡；要 200GB 内存，实际峰值 120GB；要 8 核 CPU，数据加载只占 2 核。但传统调度系统按“申报量”死板锁定资源，导致物理节点明明有余力，逻辑上却显示满负载，后续任务被无意义阻塞。
3.2 核心思路
资源超配就是让调度器分配的虚拟资源总量大于物理资源总量，基于实际使用量而非申请量进行调度。 类似云主机的 CPU 超卖，但在 GPU 环境下风险更高，需要配套监控和压制机制。
3.3 落地策略
超配显存
很多训练任务的显存申请是“峰值预留”，但实际运行中平均显存占用远低于申请值。通过监控历史数据，可以找到安全超配比例。例如，某个微调任务申请 80GB，实际平均使用 50GB，就可考虑在同一节点上超配 20%~30% 的显存，塞入额外的小推理任务。
- 使用 GPU 显存动态分配技术（如 K8s 下的
kube-arbitrator和 Volcano 的资源超卖插件）。 - 配合压力驱逐机制：如果超配后的实际显存使用超过物理上限，驱逐低优先级任务。
超配 CPU 与内存
数据加载、日志、监控 etcd 等辅助组件，CPU 和内存占用波动大。通过容器 request 较小、limit 较大的设置（K8s），或通过 Linux cgroup 允许 soft limit 突破，实现超配。
- 训练节点上通常 CPU 核数远超 GPU 核心密集任务的需求，可高频超配 CPU（如物理 256 核，卖出去 400 核虚配），但需要在内存上保守，避免因 OOM Killer 杀掉关键训练进程。
- 设置内存优先级：当系统内存紧张时，优先回收缓存和低优进程，保护训练主进程。
实用建议：GPU 显存超配是高风险操作，务必配合自动化驱逐和告警。建议先在推理集群中试验，训练集群需在与业务方充分对齐的前提下逐步放量。
四、空闲资源回收：别让 GPU 空转等待
4.1 浪费来源
- 排队等待的“预备卡”：分布式训练需要等齐所有需要的卡，有时因网络或节点状态，部分 GPU 已经分配完毕但训练尚未发起，卡处于占用无工作状态。
- Checkpoint 写盘、数据加载停顿：训练任务在写 Checkpoint 或从低速存储读取下一批数据时，GPU 计算单元完全闲置，甚至整个训练步停滞。
- 人工占用忘记释放：开发者开交互式 Jupyter，跑完代码后忘了释放资源，GPU 空烧数小时。
- 推理服务波谷期：在线推理服务在凌晨流量低谷时，GPU 空闲却长期占用。
4.2 回收策略
自动回收机制
- 设置 GPU 空闲超时策略：监控 GPU 的
compute utilization和显存带宽使用率。若 GPU 持续 10 分钟计算利用率低于阈值（如 5%）且进程未被标记为“持久保持”，则自动向用户发送告警，15 分钟后强制杀掉进程并释放资源。 - 针对交互式开发环境，使用 JupyterHub 的
cull_idle_servers自动终止超时 Kernel。
Gang Scheduling 与预算式抢占
- 高优先级训练任务采用 Gang Scheduling，要求所有需要的卡同时满足时才启动，避免部分卡提前占用但等待。
- 低优先级任务设置为可抢占（preemptible）。当高优任务需要资源时，调度器优雅中止低优任务（保存 snapshot），事后恢复。
推理集群自动伸缩
- 利用 K8s HPA 或 KEDA，根据 pending 请求队列长度自动调整推理 Pod 数量。波谷期自动缩减至最小副本，波峰快速扩容。
- 在推理服务中接入性采纳滚动更新与缩容信号，确保缩容时无损当前请求。
动态任务填充（Spot-filling）
- 将低优先级、可中断的任务（如数据预处理、模型评估、超参搜索实验）作为 Spot 任务，当有空闲 GPU 出现时自动填充，一旦有高优训练任务需求就立即腾出资源。
- 例如，可以在凌晨 2 点到 6 点自动跑自动回归测试和定期基准评估，利用原本闲置的算力。
实用建议：自动回收机制必须配有完善的用户通知策略，避免造成研发同事的数据丢失和投诉。空闲回收的目标是提升集群全局吞吐，但不应以牺牲开发体验为代价。
五、组合打法与效果预期
将三种策略整合实施后，集群有效利用率通常可从 30%~40% 提升至 60%~80%，具体取决于负载多样性和调度策略精细度。典型的实施路径是：
- 先从离线训练集群的碎片化任务打包开始——风险低，见效快；
- 再在推理集群引入超配和自动伸缩——直接降低线上服务成本；
- 最后在全集群推行空闲资源回收与抢占式调度——需要组织配套规范和自动化看守。
一个真实案例：某中型 AI 公司拥有 200 张 A100 的集群，实施任务打包和空闲回收后，GPU 日利用率从 38% 升至 67%，等效于在不采购新硬件的情况下多支撑了两个 13B 模型的并行训练任务。