显卡看起来“没怎么忙”，不一定代表资源可以回收：任务可能已经占住整张卡，只是暂时等待数据；也可能只用了少量显存，却因调度方式无法让其他任务共享。做好显卡算力资源闲置率优化与自动伸缩策略，第一步不是设定扩容阈值，而是弄清闲置率的口径、采样周期和可用容量边界。
先把三种“空闲”分开
资源统计至少要区分未分配、已分配但低负载，以及暂时没有任务运行。集群调度器显示一张卡已分配，并不等于它一直在计算；反过来，短时间 GPU 利用率低，也可能是任务在读数据或等待同步。只看瞬时利用率容易把这两种情况混为一谈。
- 分配率：已分配给任务的 GPU 数量占可调度 GPU 数量的比例，适合判断调度池是否将满。
- GPU 利用率：观察设备在采样周期内参与计算的程度。应查看时间序列，而非仅看某一刻的读数。
- 显存占用率：用于发现显存被长期占用、但计算活动很少的任务；高显存占用本身不能证明任务无用。
例如 Slurm 可通过 GRES 为作业分配 GPU。作业即使处于运行状态，仍可能因输入准备而有一段低负载期；若调度器不支持安全的 GPU 共享或抢占，就不能仅凭低利用率把卡重新分配。实际的闲置率定义应先写清：统计的是未分配卡时，还是已分配卡上的未使用算力时间。
用一段稳定窗口算闲置，不追逐瞬时波动
一种可复核的口径是：在统计窗口内，将所有可调度 GPU 的“总可用设备时间”作为分母，将设备忙碌时间从中扣除，再计算占比。假设一个池有 8 张可用卡，观察 60 分钟，总可用设备时间为 480 卡分钟；若监控汇总的忙碌时间为 240 卡分钟，则按该口径，算力闲置率约为 50%。这是计算示例，不代表所有设备或工作负载都会得到相同结果。
开始阶段可同时保留 5 分钟级采样用于观察突发负载，并用 15 至 60 分钟窗口判断伸缩趋势；再对照一周左右的业务周期，确认是否存在每日高峰或集中提交作业。具体窗口取决于任务时长和监控系统的采样能力。显卡算力资源闲置率优化与自动伸缩策略的关键，是让指标能对应真实等待和可回收资源，而不是追求某个孤立的低数值。
按任务类型设触发条件和扩容边界
在线服务：优先守住等待时间
对需要持续响应的在线任务，GPU 利用率高且请求队列持续增长时，扩容通常比单看利用率更有依据。设定最小副本或最小 GPU 数量，避免低谷期全部缩到零后，流量到来才开始启动。新卡从分配到模型或程序可用还需要时间，因此触发阈值要给启动过程留出余量。
批处理：让队列和期限共同决定扩容
对可排队的训练、推理或数据处理作业，可依据待处理任务量、最老任务等待时长和可用 GPU 数扩容。没有明确时限的任务通常可以接受较长等待，扩容上限应结合预算、配额和物理库存设置；有截止时间的任务则应按预计处理能力预留余量，而非等到所有卡都满载才扩。
一套可执行的配置顺序
- 盘点可调度 GPU 数、预留容量、维护中的设备及云平台或集群配额，确定硬上限和最低保留量。
- 连续记录分配率、GPU 利用率、显存占用率、队列等待时间与任务成功率；把采样时间和统计窗口一并记录。
- 选一个主触发信号，再用第二个信号确认。例如，队列增长并且可用卡不足时扩容，避免只因短暂利用率上升就频繁加卡。
- 设定扩容步长、最大容量和冷却窗口。冷却时间应覆盖设备加入及任务启动所需时间；按实际启动时长调整，不要照搬固定值。
- 先在非高峰或可控负载下验证：观察扩容是否及时、缩容是否打断任务，以及达到配额或库存上限时是否有明确告警。
缩容尤其要防止误回收。可要求低负载持续多个采样周期、队列为空或任务已完成后再减卡；对不能中断的作业，设置保护或等待其自然结束。不同平台的抢占、共享与任务排空能力不同，规则应以实际调度机制为准。
常见问题
闲置率高，就应该立刻缩容吗？
不一定。先确认低负载是否持续、资源是否被任务占用，以及近期是否有确定的负载高峰；短暂空档不适合作为缩容依据。
扩容只看 GPU 利用率可以吗？
不建议。利用率无法单独说明是否有任务在等待，也不显示资源是否已分配。结合队列等待、可用卡数和显存情况，判断会更可靠。
如何确定最大扩容数量？
以可调度库存、平台配额、预算和任务并行能力中最严格的限制为边界，并保留故障或维护所需容量。容量变化后应重新核对。
归根结底，显卡算力资源闲置率优化与自动伸缩策略不是把利用率推到最高，而是让资源分配、任务等待和回收风险彼此匹配。先统一闲置口径，再用真实运行窗口校准触发条件与扩容边界，才适合逐步自动化。
