夜里十点，机房的空调声比白天更清楚。监控面板上，几张加速卡的利用率曲线并不好看：一会儿冲到高位，一会儿又掉下来，像有人在反复踩刹车。值班的工程师没有盯着峰值看，他打开了另一个面板，那里显示的是数据加载队列和网络等待时间。那一刻你会意识到，算力并不是买回来就自动变成结果的。
峰值数字之外的等待
讨论算力时，人们习惯说规模、卡数、峰值性能。这些数字当然有意义，但它们描述的是“能做多快”，不是“实际做了多少”。一个训练任务从存储读到内存，再从内存搬到显存，中间要经过多次排队。只要有一环跟不上，加速卡就会空转。空转不产生结果，却照样耗电、占机位。
所以，评估一套系统时，我会先问三个问题：数据能不能持续喂饱计算单元？任务之间的切换是否足够轻？失败重试会不会把队列拖长？这些问题不如峰值数字醒目，却更接近日常体验。
调度不是排队，而是匹配
机房里的任务并不整齐。有的任务很长，有的只是短时推理；有的吃显存，有的吃网络。如果调度只按提交顺序排队，短任务很容易被长任务堵住，资源池看起来满载，实际产出却被打折。更合理的做法，是把任务按资源特征分组，再决定谁先进入哪一类资源。
这件事听起来像运维细节，但它决定了算力的“可兑现程度”。同样的硬件，调度策略不同，等待时间会差出很多。这里没有放之四海皆准的方案，只有对业务节奏的理解：哪些任务可以等，哪些任务不能等，哪些任务其实可以合并。
电和热，是绕不开的物理约束
很多人把算力想象成软件问题，实际上它首先受电和热限制。机柜的供电上限、制冷能力、楼层承重，都会约束单柜能放多少设备。功率密度上去以后，风冷未必够用，液冷又要改管路和机房结构。这些改造不便宜，也不快。
因此，扩容不是简单地加设备。它更像一次系统工程：电力容量、散热方案、网络布线和运维流程要一起变。只盯着计算芯片，容易忽略背后的配套成本。真正影响长期运行的，往往是那些不常出现在发布会上的部分。
不是所有问题都值得堆算力
还有一种浪费更隐蔽：用大资源解决一个本来没定义清楚的问题。数据标注混乱、评价标准模糊、业务流程没有梳理，这时候增加算力，只会让错误结果来得更快。我的判断是，先把问题缩小、把数据清理干净、把评估口径定下来，再决定要不要扩资源。很多场景里，一个更小的模型加上人工复核，反而更可控。
算力是基础设施，不是成绩单。它应该服务于具体目标：缩短一次迭代的时间，支撑更多的并发请求，或者让原本跑不动的实验变得可行。如果目标说不清，资源越多，协调成本越高。