和一个做模型训练的朋友聊天，他说最近最常做的事是盯着任务队列。不是模型不收敛，也不是数据有问题，而是排队。前面还有几十个任务，预计等待时间不断往后跳。他形容这种感觉像在机场等一架不知道什么时候起飞的航班。
这大概是当下很多团队共同的处境。算力这个词被提得太多，反而容易让人忽略它具体意味着什么——它不是一个抽象的数字，而是从供电、散热、机架、调度到框架适配的一整条链路。任何一个环节卡住，等待都会落在具体的工程师身上。
卡不够，还是用的方式不对
讨论算力紧张时，最常见的说法是“卡不够”。这个判断不能算错，但过于简化。实际走访和公开交流中能听到另一种声音：有些集群的利用率并不高，任务排队长，但资源空转的现象同样存在。
原因往往出在调度上。训练任务对显存、互联带宽、存储吞吐的要求差别很大，如果按统一规格分配，很容易出现大任务占不满、小任务排不进的情况。碎片化的空闲资源拼不起来，看上去总量不少，能用的却很有限。
另一层原因是任务本身的形态在变。早期以训练为主，任务周期长、可预期；现在推理需求上来，请求波动大，白天高峰和夜间低谷差别明显。按训练的思路去准备资源，遇到推理就会显得笨重。弹性这件事说起来简单，真正做起来要动调度、动存储、动网络配置。
- 资源规格与任务需求不匹配，导致分配后利用率偏低
- 训练与推理的负载特征不同，统一池化难以兼顾
- 排队信息不透明，团队难以规划迭代节奏
被忽略的配套环节
还有一个容易被低估的问题：电和热。高密度机柜对供电和散热的要求，直接决定了同样面积的机房能放下多少设备。很多地方的瓶颈不在采购，而在配电容量和制冷能力。设备到了，装不进去，这种情况并不罕见。
这也解释了为什么一些团队开始重新考虑地域选择。靠近电力资源、气候条件适宜的地方，长期看可能更划算。代价是网络时延和运维便利性，需要在具体业务里权衡。没有统一答案，只有取舍。
软件层面同样有空间。算子优化、混合精度、并行策略的调整，往往能在不改硬件的前提下换回一部分效率。这部分工作不显眼，却直接影响单位算力的产出。有团队把同样的模型在同样的硬件上做出明显更短的训练时间，靠的就是这些细活。
等待的成本怎么算
排队带来的损失不容易量化。表面上是时间，实际上是节奏：实验做不完，方案验证慢，团队在反复等待中失去对进度的掌控。对初创团队来说，这种不确定性有时比资源价格更难受。
所以现在能看到一些变化。有的团队把任务分级，重要的训练任务优先，探索性的实验放到低峰时段；有的开始把部分推理迁到成本更敏感的路径上，训练和推理分开管理。做法各不相同，共同点是承认算力不是无限资源，得当成需要经营的东西来对待。
我个人更倾向于把这件事看成系统工程问题，而不是单纯的采购问题。增加设备能缓解一时，但如果不解决调度、配套和任务组织方式，等待还会以别的形式出现。反过来，把现有资源用得更细，也能释放出不小的空间。
回到开头那位朋友。他后来做的一件事是把排队数据做成看板，让团队知道什么时候该提交什么任务。听起来是个小改动，但等待从盲目变成了可预期。算力的紧张短期内不会消失，能做的或许就是让每一次等待都有明确的原因。