深夜的机房里，风扇声比白天更响。屏幕上任务队列还挂着几十条，监控面板上的加速卡利用率却在三成上下浮动。采购单上的数字明明涨了，等待时间却没见短多少。这个场景在不少做模型的团队里反复出现，问题往往不在“有没有”，而在“用不用得上”。
标称的数字，和真正跑起来的时间
设备说明书上的算力指的是峰值：在理想条件下，一定精度、一定批量、连续不断地计算。真实任务很少这么听话。数据要从存储搬进显存，梯度要在卡与卡之间同步，一批算完还要等下一批准备好。任何一环慢下来，计算单元就只能空转。
批量小的时候尤其明显。为了压低延迟，推理服务常常一次只处理很少的请求，矩阵乘法的并行度上不去，峰值性能发挥不出一半。训练侧则是另一种浪费：模型切分到多卡之后，通信开销随卡数上升，参数同步的等待时间有可能超过计算本身。
碎片化的闲置，比总量不足更常见
把视角从单机拉到整个集群，浪费的形态会变。常见的情况大致有几类：
- 粒度不匹配。有的任务单卡放不下，要占满一整台机器；有的任务只用得上一张卡的一小部分，却同样申请了整卡。
- 排队方式粗糙。先来先服务看着公平，实际会让一个长任务堵住后面一串短任务，队列越长，空转越多。
- 环境不一致。镜像、驱动、依赖版本各自为政，任务迁到别的节点就跑不起来，资源只能按团队切块。
- 时间上的空档。夜间、周末、项目间隙，机器开着，没人提交。
这些问题的共同点是：它们都不靠添设备解决。
先测，再决定要不要扩
在讨论扩容之前，有几个指标值得先看清楚：按小时统计的真实占用率，采集自监控系统而不是采购台账；任务从提交到开始的等待时长分布，看长尾而不只看均值；失败重试的比例；以及数据加载在整个任务耗时里占的比重。这几项摆在一起，大致能判断瓶颈压在哪一层。
如果占用率长期低位、等待主要来自调度和环境，那么先做工程侧的整理，收益通常来得更快，也更便宜。反过来，如果占用率长时间贴着上限、排队时长稳定增长、任务类型又确实吃并行计算，那才是扩容的理由。
也有些任务，不该往大集群上放
把算力当成万能解法，容易忽略任务本身的差异。轻量的分类、抽取、小模型推理，放在通用处理器上跑，成本可能更低，运维也更简单。延迟敏感的业务，把模型压小、放到离用户近的地方，效果往往比在远端堆设备更直接。反过来，一些看起来不起眼的预处理环节，如果反复读写、频繁搬运数据，反而会吃掉大量时间，值得单独优化。
换句话说，需要判断的是“这类任务在这个规模下，值不值得占用这块资源”，而不是笼统地问要不要更多机器。
把账算清楚
算力是必要条件，不是解决方案。它像仓储：面积大不等于周转快，货架怎么摆、出入库怎么排，决定了同样的空间能撑起多少业务。对多数团队来说，先花两周把监控补齐、把调度规则理一遍、把镜像统一，比急着签下一张采购合同更有用。等到利用率曲线真的贴顶了，再谈加机器，那时花的每一笔钱也都说得清。