一家做模型微调的小团队最近遇到一件怪事：代码没改，训练时间却比上个月长了将近一半。排查到最后，原因不在算法，也不在框架，而是同一批卡所在的机房，入驻了更多租户，电力配额被重新分配。工程师花了两天写优化脚本，最后解决问题的是一个电话。
这类事情正在变多。过去谈算力，直觉上等于谈卡：多少张、什么型号、几纳米。现在真正的约束往往在更靠后的位置——机柜能不能上电、变电站有没有余量、冷却系统跟不跟得上。芯片是买得到的，电和空间不一定。
被忽略的那一段：从到货到跑起来
硬件采购完成，只是整条链路的第一环。设备到机房之后，要经过上架、布线、供电测试、网络调通、驱动与框架适配，才能进入稳定产出状态。每一环都可能卡住，而卡住的时间不产生任何训练结果。
更麻烦的是，这些环节之间并不同步。采购周期按季度算，机房扩容按年算，电力报装的时间尺度还要更长。三者的节奏对不齐，就会出现一种尴尬局面：卡已经付了钱，却只能在仓库里等电。
- 机柜功率密度上升，老机房的风冷方案开始吃力；
- 单柜功耗变高后，楼板的承重与配电改造需要重新评估；
- 网络带宽与存储吞吐不匹配，卡再多也会空转。
这些都不是模型层面的问题，却直接决定了模型能不能跑出来。把算力理解成一项系统工程，比理解成一笔采购更难，也更接近现实。
租还是建，取决于波峰的形状
企业面对算力需求时，通常会先问租还是自建。这个问题没有统一答案，关键看需求曲线的形状。
如果负载长期平稳、可预测，自建能让单位成本随使用时间摊薄，也便于做定制化适配。但前提是有人能长期维护机房、处理硬件故障、跟进驱动与安全更新，这是一支常设队伍的活。
如果需求呈现明显的波峰波谷——比如阶段性训练、集中推理、季节性业务高峰——租用更灵活，把闲置风险转移出去。代价是单价更高，且受制于供应方的调度策略。高峰期排队，往往比涨价更让人难受。
实践中还有一种混合做法：常态负载放在自有环境，峰值需求外溢到云端。听起来折中，实际执行时会遇到数据搬运、环境一致性、权限边界等细节问题。这些细节不解决，混合架构就只是两套系统各自为政。
效率这件事，正在被重新计算
当扩张变得不那么容易，注意力自然转向每单位算力能产出多少有效工作。这里有两层含义。
一层是硬件利用率。卡的空转率、通信等待、数据加载瓶颈，都会把名义上的峰值性能打折。很多团队的实际利用率远低于预期，原因常常是数据管道没跟上，而不是芯片不行。优化数据供给的收益，有时比换一代硬件更直接。
另一层是任务层面的效率。同样的业务目标，用不同规模的模型、不同的推理策略、不同的批处理方式，消耗的资源可能相差数倍。把大模型用在只需要小模型的地方，是一种隐性的浪费，而这种浪费在资源宽松时不容易被察觉。
所以算力的成本核算不该只看采购单价，还要看有效产出。一台长期半负荷运行的设备，账面成本可能比租用便宜，实际账不一定这么算。
它正在变成一种需要规划的基础设施
把时间拉长看，算力的角色在变化。早期它是研发部门的一项实验开销，现在越来越多企业把它当成类似水电的生产要素，需要预算、需要容量规划、需要应急预案。
这意味着决策方式也要变。过去是技术团队提需求、采购部门比价格；现在还需要有人判断未来一到两年的需求走向，评估供应方的稳定性，想清楚断电、断网、供应延迟时业务怎么降级运行。这些工作不性感，却决定了系统能不能持续可用。
对多数企业来说，未必需要自建机房，但需要建立对算力的基本认知：它由哪些环节构成，瓶颈可能出现在哪里，哪些依赖掌握在自己手里，哪些交给了外部。想清楚这些，再谈规模，顺序才不会颠倒。
回到开头那个团队，他们后来做了一件很朴素的事：把电力配额、机柜余量、网络带宽和硬件到货时间列进同一张表，按季度对齐。问题没有立刻消失，但至少不再以“训练突然变慢”这种形式出现在凌晨的告警里。