论文链接：PDF；DOI：10.1109/ICCD56317.2022.00103
本文目录 · 17 节
细粒度监控看到了什么
集群级 occupancy 很高时，单个作业仍可能只使用已分配 GPU 的一部分，并在运行期间出现长时间空闲。论文把这种空间和时间上的未使用资源称为“资源泡沫”，并用 R&D 集群的细粒度监控加以测量。
数据集与观测窗口
作者采集了鹏城实验室 CloudBrain-I 的 328 天 trace，表 2 将其概括为 2020 至 2021 年的 10 个月、155K 个 GPU 作业（PDF 第 2 页；PDF 第 4 页，表 2）。集群面向 520 名学生和研究人员，包含 16 个 CPU 节点和 110 个 GPU 节点；论文写作时集群总计约 1,100 张 GPU，而表 2 记为 1,116 张 GPU，差异来自不同统计时点以及部分维护节点。GPU 类型包括 V100-SXM2、V100-SXM3、T4、RTX 2080 和 RTX 2080Ti，最大单作业请求 768 张 GPU（PDF 第 2 至 4 页，表 1 与表 2）。
CloudBrain-I 在 Kubernetes 上运行 OpenI-Octopus，存储使用 Lustre，多卡作业采用 gang scheduling。Prometheus 通过 cAdvisor 与 GPU exporter 记录 CPU、host memory、每张 GPU 的 SM utilization 和 GPU memory，时间间隔为 15 秒，覆盖作业整个生命周期（PDF 第 2 至 3 页，图 1）。和只保留提交、启动、结束时间的 trace 相比，这个数据集的核心价值是能看见“分配量与实际使用量”的差距。
关键统计发现
作业长尾中混入了人为的 8 小时边界。 CloudBrain-I 作业平均时长为 42,672 秒，中位数为 6,182 秒，明显长于 Philly、Helios 和 PAI；CDF 在 28,800 秒处陡增，因为交互调试作业的最长时限被设为 8 小时（PDF 第 4 页，图 2(a) 与表 2）。因此这里的长作业不全是长训练，一部分是用户保持调试容器不退出。
资源申请很宽，但实际使用显著更低。 作业申请量的第 80 百分位为 8 个 CPU、2 张 GPU 和 128GB host memory；单作业最大值分别达到 3,840 个 CPU、768 张 GPU 和 39,552GB host memory（PDF 第 4 页，图 2(b) 至 2(d)）。约 60% 作业只申请一张 GPU，却只消耗约 20% GPU time，多卡作业仍然主导资源量（PDF 第 4 至 5 页，图 3）。
低利用不是少数异常，而是整体分布。 70.57% 作业的平均 GPU utilization 与平均 GPU memory utilization 都低于 50%；54.57% 作业这两个指标都不超过 20%；50.28% 作业的 GPU 与 CPU 平均利用率都低于 20%（PDF 第 4 至 5 页，图 4）。还有约 5% 作业表现出严重的跨资源错配，即一种资源利用率超过 80%，另一种低于 20%。全体作业的平均 GPU utilization、GPU memory utilization、CPU utilization 与 host memory utilization 分别只有 21.24%、25.75%、18.12% 和 33.08%；作业生命周期内“最大 GPU utilization”和“最大 GPU memory usage”的中位数也只有 0.78 和 2.4GB（PDF 第 5 页，图 5）。后两个数应按论文图中指标原样理解，不宜脱离 exporter 定义推成硬件理论占用率。
可共享空间存在，但不能用静态平均值直接 packing。 11.54% 作业在 120 秒窗口内表现出 CPU 或 GPU utilization 的尖锐波动，超过 75% 的采样区间会冲到 90% 以上（PDF 第 6 页，图 6）。若把“stable phase”定义为持续至少 240 秒且空闲显存至少 2GB，则 87.02% GPU time 落在这种稳定阶段；但 38.05% GPU 作业包含多个 stable phase，20.97% 作业的不同阶段显存需求差超过 1GB，8.99% 超过 8GB（PDF 第 6 页，表 3 与图 7）。所以共享机会很大，但分配必须跟着 phase 变化，否则既浪费显存，也可能在利用率尖峰时产生干扰。
时间上的空闲同样严重。 作者把连续至少 60 秒、GPU utilization 和 GPU memory 都为 0 的区间定义为 idle slot。此口径下，idle slot 与从未使用的已分配 GPU 合计浪费全体作业 15.30% GPU time，其中调试作业浪费自身 GPU time 的 77.72%，非调试作业浪费自身 GPU time 的 12.52%（PDF 第 7 页，表 4）。调试作业内部，41.62% GPU time 属于运行中的 idle slot，36.10% 属于从未使用的已分配 GPU。接近 80% 的调试作业在其约 80% 生命周期里实际不用 GPU，40.41% 调试作业接近或超过 8 小时上限，说明忘记退出也是重要原因（PDF 第 7 页，图 8）。
配置错误可以让整张卡从头到尾没被碰过。 在多 GPU 作业中，24.01% 只使用了部分申请 GPU。即使请求 1 张 GPU，仍有 24,370 个作业完全没有使用该卡，占这一请求规模的 26.20%；请求 2、4、8、16 张 GPU 时，至少浪费一张卡的作业比例分别为 23.82%、15.47%、14.23% 和 17.43%（PDF 第 7 至 8 页，表 5）。这不是调度器可以靠更好的初始 placement 自动消除的问题，还需要运行时异常检测和用户反馈。
方法或预测模型
论文没有提出预测模型，也没有实现一个新调度器。它的方法是先从 trace 中区分“申请/占用”与“真实使用”，再用两个可计算定义刻画空间和时间上的浪费。
空间维度使用 CPU、GPU SM、GPU memory、host memory 的 15
秒时间序列，报告每个作业的平均值、最大值和跨资源关系。为寻找可共享区间，作者定义
stable phase：长度大于阈值 t，且空闲 GPU memory 大于阈值
m，并对 t 为 60、120、240、480、960
秒，m 为 1、2、4、8GB 的组合做敏感性统计（PDF 第 6 页，表
3）。时间维度定义 idle slot：至少连续 60 秒完全没有 GPU compute 和 GPU
memory 使用；另行统计“never-used
GPU”，即作业整个生命周期都没碰过的已分配卡（PDF 第 7 页，表 4）。
这种方法的好处是定义清晰，任何包含细粒度监控的 R&D 集群都能复算；它的限制也很直接：阈值是人为选择，指标只能看到资源表象，无法从 trace 恢复完整的训练阶段、Python 调试动作或框架内部因果关系。
实验数字
本文的“实验”主要是 trace
阈值分析而非调度器对照实验。最有用的一组数字来自表 3：当
m=2GB 时，满足 stable phase 的 GPU time 随 t
从 60 秒增加到 960 秒，依次为
88.41%、87.91%、87.02%、85.83%、84.45%；当固定 t=240s、把
m 从 1GB 提高到 8GB 时，该比例从 90.86% 降至 69.51%（PDF 第
6 页，表
3）。这说明“有稳定共享空间”的结论并非只在一个极窄阈值上成立，但可共享容量对显存阈值相当敏感。
表 4 的时间浪费分解也应视为核心实验结果：debugging jobs 的 idle-slot 与 never-used 比例合计 77.72%，但由于这类作业总体 GPU time 较少，它们只贡献全体 GPU time 浪费的 3.31%；non-debugging jobs 自身只浪费 12.52%，却贡献全体浪费的 11.99%（PDF 第 7 页，表 4）。因此，只限制调试作业时长能改善用户行为，却不能消除集群中绝大多数绝对浪费。
测量贡献
这项测量纠正了对 cluster-wide GPU occupancy 的常见理解：它 只说明卡被调度器分出去了，不能说明作业有效使用了卡。对 R&D 集群而言，交互调试、配置错误、多阶段执行和新手用户共同造成大量“已占用、低利用”资源，单看 occupancy 会得出虚假的繁荣。
第二个贡献是把 GPU sharing 的论证从“平均利用率低，所以可以共享”推进了一步。论文同时给出尖峰波动与 stable phase，告诉调度器既有共享空间，也有干扰风险；适合落地的是 phase-aware、可撤回、带运行时监控的动态共享。第三个贡献是补上生产集群 trace 的人群盲区：学生、研究人员和共享账号会形成与成熟生产流水线不同的作业行为。
局限与外推边界
这是单机构、单 R&D 集群的观测，用户构成、8 小时调试上限、OpenI-Octopus 提交方式和 GPU 代际都会影响结果。论文从 job name 与 Docker image 推断模型和框架类型，但没有训练代码、iteration progress、I/O 阶段或人工标注，因此对 idle slot 原因只能提出合理解释，不能做严格因果归因（PDF 第 3 页）。
GPU exporter 的 utilization 与 memory 指标也不是 FLOP、Tensor Core occupancy 或有效训练吞吐；平均利用率低不能自动证明两个任意作业可以无干扰共置。stable phase 和 idle slot 的阈值虽做了敏感性表，但仍是离线定义，在线检测延迟和误判代价没有评估。最重要的是，论文没有实现并比较 phase-aware scheduler，因此七条 implication 是有数据支持的设计要求，不是已经验证过的调度收益。
此外，2020 至 2021 年的 V100/T4/RTX 负载不能直接代表 A100/H100 上的大模型训练。NSDI 2024 的 Acme 结果显示，稠密 LLM 作业的显存和表层 GPU utilization 已很高，ICCD 论文中“普遍适合 GPU sharing”的结论必须按 workload class 重新检查。
与调度器论文的关系
这篇论文直接给调度器提出四类需求：按作业真实使用量而非申请量配资源；识别 debugging job 并使用不同队列或时限；按 stable phase 动态调整 GPU memory allocation；对从未使用的卡做运行时回收和及时告警。它和 Gandiva、AntMan、MIG/MPS 类 GPU sharing 工作关系最紧密，但它同时提醒 sharing scheduler，11.54% 作业有高幅波动，若只按均值 packing 会在尖峰时发生性能干扰。
它也解释了为什么 CSUR 综述把“resource-utilization manner”设为与“scheduling objective”正交的一条分类轴：同样追求低 JCT 或高 fairness，可以用 exclusive allocation、GPU sharing 或 elastic training 达成，而 R&D trace 告诉我们应该何时选择 sharing。与 SC 2021 相比，SC 主要从 scheduler log 推断作业、集群和用户行为，ICCD 加入细粒度 utilization 后，才看见分配后的内部泡沫。
背景与术语：占用、利用和有效进度不是一回事
集群控制面最容易获取的是 allocation：某个作业申请几张 GPU，调度器把这些卡绑定给哪个容器，以及绑定持续多久。用已分配卡时除以全部卡时得到的 occupancy 很适合回答容量是否被预订，却无法回答硬件是否做了有效训练。GPU exporter 报告的 SM utilization 表示采样窗口内 GPU 是否执行 kernel，显存使用表示有多少设备内存被占据；二者仍不等于模型吞吐，因为忙碌 kernel 可能是低效率数据搬运，也可能只是很小的算子。论文所谓 bubble，首先是“已分配资源与监测到的使用之间的空隙”，而不是直接证明某段时间没有任何业务价值。
R&D 集群比成熟训练流水线更容易出现这种空隙。研究者会开交互容器检查环境、在 notebook 中修改代码、等待数据下载、遇到异常后离开终端；初学者可能请求多卡却没有正确启动分布式进程。训练本身又包含数据预处理、评估、checkpoint 和多阶段超参数搜索。一个作业在 Kubernetes 看来始终运行，在 GPU 时间序列上却可能只有若干计算脉冲。CloudBrain-I 的八小时调试上限进一步制造了明显边界：用户不主动结束时，容器会一直占卡到系统强制回收。
因此本文实际上回答三个层次的问题：分配结构上，谁申请了多少资源；空间上，作业运行期间各类资源用到什么程度；时间上，低利用是短暂抖动、长稳定阶段还是完全空闲。只有把三个层次连接起来，才能区分“集群确实满载”“卡被预订但有可共享余量”和“配置错误导致整卡未使用”。这也是论文相对只含提交日志的公开 trace 的主要增量。
从 15 秒采样到作业统计：数据如何聚合
原始监控以每十五秒为一个采样点，粒度是容器、CPU、主机内存和单张 GPU。分析时需要先把容器实例映射回作业，并用调度日志确认作业申请量、开始和结束时刻。对多 GPU 作业，既可以把各卡利用率取平均来描述作业整体，也必须保留每卡序列来发现“只用了部分卡”。若直接把所有卡平均，一项任务使用一张卡达到 100%、另外三张卡为 0% 会显示为 25%，从均值无法区分数据瓶颈与分布式配置错误。
论文报告的平均利用率是生命周期内离散采样的平均，而最大值是这些采样中的最大观测。设作业有 n 个有效采样、每点 GPU 利用率为 u_k，平均值可写成 sum(u_k)/n。这个统计会把初始化、数据等待、训练和结束清理全部纳入分母，恰好适合估计已分配卡时中的浪费，却不适合评价核心训练循环的 kernel 效率。作业长短差异也要小心：按作业求平均时，一个五分钟任务和一个五天任务权重相同；按 GPU time 求平均时，长作业又会主导结果。论文同时报告作业比例与 GPU-time 比例，避免只看其中一种口径。
监控缺失和边界采样会影响短区间判断。一个恰好持续 60 秒的空闲段可能只有四个或五个点，Prometheus 抓取失败会把连续段切开；作业开始前后的容器建连也可能产生零值。复现者应明确缺失值是忽略、前向填充还是当作零，并对持续阈值换算采用一致的闭区间规则。论文重点给出结果而未公开完整清洗代码，所以严格复现应先在人工构造的小序列上验证聚合逻辑。
三个作业案例：相同低均值背后的不同原因
案例一是调试容器。 用户申请一张 GPU，前十分钟运行几次短测试，此后七小时在编辑代码或离开。它的生命周期平均利用率可能低于 1%，存在长 idle slot，显存也可能完全释放。调度层若能确认用户允许回收，可以暂停或终止容器；若只依据低平均值把另一训练任务静态塞进同一卡，用户突然恢复测试时就会发生干扰。调试队列、空闲提醒和可续接会话比永久共置更直接。
案例二是分阶段训练。 作业周期性执行数据准备、GPU 训练、验证和 checkpoint。其全程平均 GPU 利用率可能只有 30%，但训练阶段多次冲到 90%，显存需求也从 3GB 跳到 14GB。论文所定义的 stable phase 用持续时长和空闲显存寻找可共享窗口，正是为了避免把全生命周期均值当作容量承诺。可撤回的低优任务可以利用长稳定余量，而硬保障共置必须为未来峰值留空间。
案例三是错误的多卡配置。 用户申请四张卡，但代码没有调用分布式启动器，所有 kernel 和显存都只出现在第一张卡，另外三张卡从开始到结束始终为零。这类 never-used GPU 与正常阶段性空闲不同：运行时在较短观察窗后就有较高把握回收多余三卡，并向用户指出设备可见性、进程数或 rank 配置问题。论文中 24.01% 多 GPU 作业只使用部分申请卡，说明这不是个别失误。
三个案例都可能得到“平均利用率低”这一表面结论，却对应终止、动态共置和缩容告警三种完全不同动作。任何后续调度器若不先分类，就可能让调试用户丢失环境、让阶段性作业在峰值争抢显存，或继续容忍错误申请。论文的价值正是用时间序列揭示这种不可由单个平均数消除的歧义。
稳定阶段与空闲槽：阈值算法逐步拆解
对每张已分配 GPU，可先由设备显存容量减去观测占用，得到每个采样点的空闲显存 f_k。给定显存阈值 m，把满足 f_k >= m 的连续采样连接成候选区间；再把时长至少为 t 的区间记作 stable phase。随后将所有稳定区间覆盖的 GPU 秒数相加，除以作业总 GPU 秒数，得到表 3 的占比。m 越大或 t 越长，条件越严格，占比应单调不增，这也是检查实现是否正确的简单不变量。
例如一张 16GB GPU 在连续五分钟内分别占用 10、11、11、10、12GB，且每分钟采样一次。若 m=4GB，空闲量为 6、5、5、6、4GB，整段都满足阈值；若 t=240s，它可成为稳定阶段。把 m 提到 6GB 后，中间点不再满足，连续段被切碎，可能没有任何区间达到四分钟。此例用于解释算法，不属于论文 trace。表 3 中固定 240 秒时，阈值从 1GB 升到 8GB，覆盖比例从 90.86% 降到 69.51%，体现的就是这一筛选效应。
idle slot 则同时要求 GPU compute 和显存占用为零，并连续至少 60 秒。显存为零的条件比“利用率为零”更严格，可以过滤等待数据但模型仍驻留显存的训练间隙。never-used GPU 是整个作业生命周期都未出现使用，单独统计以避免一个八小时错误分配被分割成大量 idle slot。两类相加得到时间泡沫，但不能机械认为都可安全抢占：容器可能稍后初始化该卡，设备指标也可能因 exporter 故障为零，所以在线回收还需要确认进程、CUDA context 和用户策略。
从观测到设计：七类可执行含义
- 按真实使用校准配额。 请求量用于初始准入，持续监控用于更新用户或作业画像；长期过量申请者可收到配置建议，而非立刻惩罚一次异常。
- 调试任务单独治理。 交互作业应使用较短租约、空闲通知和可恢复工作区，使用户结束占卡时不必丢失代码与环境。
- 检测从未使用的设备。 多卡作业启动后若只有部分卡建立 CUDA context，应提示分布式启动参数，并在授权后缩减 allocation。
- 按 phase 动态共享。 只有持续余量达到时长与显存门槛才放入低优共置作业，并在原作业需求上升前快速撤回。
- 联合观察多种资源。 GPU 空闲不代表 CPU、主机内存、网络或存储有余量；约 5% 的严重错配说明单一指标 packing 会把瓶颈转移。
- 对波动作业保守处理。 11.54% 作业在短窗口内出现尖峰，预测器需要置信区间和峰值保护，而不是只以全程均值承诺共享容量。
- 反馈要能解释。 告警应指出哪张卡未使用、空闲持续多久、可能的 rank 或设备配置问题，让研究者能修改提交参数。
这些含义有不同证据强度。“存在大量已分配但未使用资源”由 trace 直接支持；“动态共享一定提升吞吐且无干扰”则还需要系统实验。严谨的表达应把 observation、design implication 和 validated mechanism 分开。本文完成前两步，没有完成第三步。
复现实验：如何在另一座集群重做分析
- 导出至少一个月的调度日志和十五秒级设备指标，用匿名作业标识关联；保留请求卡数、设备 ID、队列、作业类型、开始结束时间和硬件型号。
- 先检查数据完整性：设备采样覆盖率、重复点、时钟偏差、容器重启、维护节点和异常长作业。对缺失处理写成明确规则。
- 分别按作业数、作业时和 GPU-time 统计时长、请求规模、平均与最大利用率，避免短小作业数量多或少数长作业资源量大造成口径偏差。
- 实现 stable phase 和 idle slot 扫描，对
t={60,120,240,480,960}秒与m={1,2,4,8}GB 做网格敏感性分析，并验证阈值收紧时覆盖率单调下降。 - 逐卡检查 never-used 状态，按请求规模统计至少浪费一张卡的作业比例；抽样联系用户或读取日志，区分错误配置、预留备用卡和监控丢失。
- 若要验证调度收益，再实现影子调度或受控 A/B：报告吞吐、JCT、抢占次数、性能干扰、OOM、用户恢复时间和误回收率，不能把离线可共享比例直接当作收益。
跨集群比较必须统一分母和 workload class。CloudBrain-I 的学生调试任务、八小时时限和 V100/T4 混合集群会塑造分布；LLM 预训练、稳定生产推理或 H100 集群可能呈现完全不同的显存与利用率。复现时应沿用相同定义，判断本地浪费主要来自调试、阶段变化还是错误配置，而不是追求得到同样的 70.57%。
完整手算例子：四卡作业的泡沫怎样计入分母
设一个作业申请四张 GPU 并运行一小时，所以调度器记录的 allocation 是四 GPU-hours。第一张卡全程训练，平均利用率 80%；第二张卡前半小时训练、后半小时显存清零且利用率为零；第三张卡只有最后十分钟被使用；第四张卡从未创建 CUDA context。若只看 Kubernetes occupancy，四张卡在一小时内都是 100% 占用，集群管理者会认为没有空闲容量。
按论文口径，第四张卡贡献一 GPU-hour 的 never-used 浪费。第二张卡后半小时同时满足计算和显存为零，且远超 60 秒门槛，贡献 0.5 GPU-hour idle slot。第三张卡前五十分钟若也同时为零，贡献约 0.833 GPU-hour idle slot；第一张卡不计。总时间泡沫约为 2.333 GPU-hours，占该作业分配量的 58.3%。若第三张卡前五十分钟已预载模型、显存不为零，即使 SM 利用率为零，也不符合严格 idle-slot 定义，不能计入这一数字。
再看空间共享。假设第二张卡后半小时空闲 12GB，第三张卡预载期间空闲 6GB。设置 m=8GB,t=240s 时，第二张卡有三十分钟 stable phase，第三张卡不满足显存门槛；把 m 降到 4GB 后，两者都可能成为候选。这个例子说明时间泡沫与空间余量不是同一集合：显存仍驻留但 SM 空闲的阶段可能不算 idle，却仍可容纳一个小模型；完全空闲的区间则更适合回收，但仍需检查未来需求。
如果在线系统在作业开始五分钟后发现第四张卡从未使用，它可以先告警，再在用户确认或提交策略允许时缩容。对第二、第三张卡，系统应等待稳定窗口并放入可撤回工作，而不是永久重新分配。手算过程把同一时间序列转成两类不同控制信号，也解释了论文为什么分别定义 stable phase、idle slot 和 never-used GPU。
上线决策矩阵：从指标组合选择动作
第一类信号是“利用率低、显存为零、持续时间长”。若同时没有 CUDA context，可信度最高，可以提示结束调试任务或回收从未使用设备；若仍有进程，则先通知用户并保留宽限期。第二类信号是“利用率低、显存占用稳定且余量大”。这通常是模型驻留或数据等待，更适合放入低优、可抢占、显存有上限的共置作业，不能强制缩容原任务。
第三类信号是“平均值低但频繁冲高”。论文的 11.54% 波动作业属于此类，应按峰值或高分位保护，并降低 packing 密度。第四类是“GPU 忙但 CPU、主机内存或 I/O 饱和”，此时增加 GPU sharing 可能恶化瓶颈；调度器应转向数据管道、CPU 配额或存储诊断。第五类是“只使用部分申请 GPU”，优先检查 world size、local rank、可见设备和分布式进程是否匹配，而不是把它笼统归为模型效率低。
每个动作都需要回退条件。共置后若原作业吞吐下降超过服务阈值，应迁出低优任务；缩容后若用户即将进入多卡阶段，应能重新申请，而非使作业失败；空闲终止应保存 notebook、日志和工作目录。评价系统时要同时报告回收 GPU-hours 与误动作代价，包括额外 JCT、OOM、恢复失败和用户人工干预。没有这些保护，离线统计中看似巨大的余量并不会自动转化成可靠容量。
最后，监控本身也应接受审计：随机抽取若干被判为空闲、稳定和从未使用的区间，与容器日志、进程列表及用户说明交叉核验。只有误判率足够低，阈值结论才适合进入自动控制；否则它们首先应该作为容量分析和用户提示，而不是强制资源回收依据。
结论检查：哪些话可以说，哪些话还不能说
可以确认的是：在所观测的 CloudBrain-I 时间窗口内，分配 occupancy 明显高估了有效资源使用；大量作业平均 GPU 和显存利用率偏低；稳定余量覆盖相当多 GPU-time；调试任务有极高时间空闲；部分多卡申请从未使用全部设备。这些结论均有图表和明确阈值支撑。
不能直接声称的是：所有低利用区间都能无损共置、回收 15.30% GPU-time 就能等比例提升吞吐、某个具体 sharing scheduler 一定有效，或这些比例适用于现代大模型集群。指标没有观察模型进度，trace 也没有执行反事实调度。论文标题中的“tear up”应理解为打破虚高 occupancy 的管理幻觉，而不是已经交付一个消除全部泡沫的系统。
对 inference 系统而言，这篇文章主要提供测量方法。分母、传感器能够观察的量和控制动作需要分开说明。资源被分配、硬件在忙和请求取得有效进展是三个不同信号。调度研究若只优化第一个信号，可能制造论文所说的 bubble boom；若只看第二个信号，也仍需模型吞吐和质量指标证明业务价值。