和几位做模型部署的工程师聊天，有个细节反复出现：预算批下来之前，大家先做的不是买机器，而是翻监控面板。看哪块卡在空转，哪段流水线在等数据，哪个任务排队三小时、实跑四分钟。等这些数字摆出来，很多“算力不够”的结论会自己松动一半。
这不是说硬件不紧张。训练和推理对资源的需求确实在涨，采购周期也不短。但把问题全部归到“卡少”，往往会掩盖更麻烦的部分：已有的算力没有被有效使用。
空转的卡与排队的人
集群里常见的浪费有几类。一类是占而不用：任务申请了整机，实际只跑单卡负载，剩余资源被锁住到任务结束。一类是等：等存储读取、等上游数据清洗、等别的服务释放显存。还有一类是重复：同一份特征被反复计算，同一个模型被不同团队各部署一份。
这些问题不新鲜，但当单位成本上升，它们就从“工程细节”变成了账面上的数字。有团队做过粗算，把调度策略从整机分配改成按卡与显存细粒度切分后，同样规模的任务在原有资源上完成了更多批次。这里没有新硬件，只有分配方式的调整。
所以评估算力缺口时，先问三个问题会更实在：利用率曲线在夜间是什么形状？排队时长和实际运行时长差多少？闲置资源能不能被别的任务接手？答不上来，扩容只是把同样的低效放大一遍。
延迟不只看芯片
推理场景里，用户感受到的慢，经常和计算本身关系不大。请求在网关排队、在预处理阶段等待、在结果拼装时卡住，都会计入响应时间。把模型换成更快的版本，端到端指标可能只动了一点。
一个常见的做法是把链路拆开测：纯计算耗时、数据传输耗时、框架调度耗时各占多少。拆开之后，优化对象就清楚了。有的系统瓶颈在网络，有的在批处理策略，有的在缓存命中。算力只有在真正成为那一段最短的木板时，加资源才划算。
这也解释了一种反差：有的团队机器不多，但响应稳定；有的机器成排，高峰期仍然拥堵。差别通常不在硬件型号，而在有没有把链路当整体看。
该买还是该改
判断顺序可以很简单。先看利用率与排队数据，确认现有资源是否已经跑满且跑得合理；再看任务结构，哪些必须实时、哪些可以错峰；最后才看缺口规模。前两步做完，采购需求往往会变得更具体：不是“再来一批卡”，而是“在某个时段补多少、支持哪类切分方式”。
需要承认的是，这种方法有边界。业务增长快、模型规模大、任务本身已经优化到一定程度时，扩容就是唯一解。调度改造也有成本，团队要投入人力，系统复杂度会上升。对规模很小的团队，把资源集中在一处、简化管理，可能比精细切分更省心。
算力这个词这两年从技术词汇变成了预算词汇，讨论也容易滑向数字比拼。但对多数企业来说，真正要回答的不是“有多少”，而是“用在哪儿、等多久、能不能换一种用法”。前一个问题靠采购，后两个问题靠工程。
如果下周要做一次内部汇报，与其只报新增了多少资源，不如顺手附上一张利用率图。那张图通常比任何结论都更能说明，下一笔钱该花在哪里。