有一次在机房外等人，隔着玻璃看运维人员推着工具车进去。那扇门开合的几秒钟里，冷风往外涌，里面一排排机柜亮着灯。外面的人只关心一个结果：任务什么时候跑完。可对里面的人来说，答案不在一颗芯片上，而在电、在冷、在网络上，也在任务怎么排。
这大概是理解算力最容易被忽略的一面。我们习惯把它当成一个可以购买的数值，像一个容量更大的硬盘，买来就多一块。但实际使用中，真正影响体验的往往是等待：提交任务之后要排多久，模型跑到一半会不会被挤下去，闲下来的资源能不能及时回收。
排队本身，也是一种成本
把算力想成一片停车场，车位数是固定的，但入口只有一个。车多的时候，不是没有空位，而是进不去。任务调度也有类似处境：某些资源被长期占用，另一些资源却处在空隙里，调度系统需要判断谁能先走、谁该等一等。
问题在于，这种等待不容易被看见。采购时看的是规模，使用中感受到的却是延迟。对做推理服务的团队来说，一次请求慢了几百毫秒，用户未必说得出原因，但会慢慢减少使用。于是“算力够不够”这个问题，常常要换成“在需要的时候，能不能马上用上”。
被拖慢的地方，往往不在芯片上
围绕算力的讨论容易集中在芯片型号和数量上，但实际运行中，拖慢速度的环节很多：
- 供电容量和配电改造的周期，决定了一个机房能装多少设备；
- 散热方式影响设备能不能持续跑在高负载状态；
- 网络带宽和存储读写速度，会让多台设备协同的效率打折；
- 调度策略是否合理，决定了空闲资源会不会被浪费。
这些环节里，任何一个跟不上，整体感受就会变差。芯片是算力的核心之一，但它不是全部。把资源集中起来之后，如何让它们不互相等，才是更日常的难题。
这也解释了一个现象：有些团队明明增加了设备，任务完成时间却没有明显缩短。不是新设备没用，而是任务和数据搬运的路径没有同步调整。算力被“堵”在了半路上。
弹性听起来很美，边界要说清楚
云服务常提弹性，意思是需要时扩、不用时缩。这个思路对波动明显的业务很有吸引力，但它有边界。扩容需要时间，数据迁移需要成本，跨区域调度还受网络延迟影响。对延迟敏感的任务来说，临近的资源比遥远的富余资源更有价值。
另一个边界是成本的可预测性。按量付费灵活，但如果任务长时间高负载运行，费用曲线未必比自建平稳。团队需要根据自己的任务形态做取舍，而不是默认某一种方式更先进。算力的使用效率，最终要落在一段时间内的总账上，而不是单次跑分。
先把问题问对
如果一定要给正在规划资源的人一句建议，那就是先别急着问“需要多少算力”，而是问“哪些任务最怕等”。把任务按延迟敏感程度、运行时长、数据位置分一分，很多选择会自然清晰起来。
算力终究是一种要被使用的资源。它的价值不体现在参数表上，而体现在任务顺利跑完、用户没有察觉等待的那一刻。机房的灯一直亮着，真正值得关心的，是灯下那些机器有没有在做该做的事。