采购会上，常见的一句话是：“先把算力备足。”听起来稳妥，实际把很多问题往后推。机器进来只是开始，电费、散热、机位、运维、闲置和迁移，会在接下来几个月慢慢显形。它不像一箱打印纸，用完再买；更像一条持续运行的产线，开动有成本，停下也有成本。
预算表里看不见的那部分
询价单通常只写加速卡型号、内存和节点数量。真正决定支出的，往往是这些数字之外的东西：机房能不能承载功率密度，冷却方式要不要改，网络带宽够不够，存储会不会拖后腿，值班人员能不能处理故障。单独买卡便宜，不代表整体便宜。把设备放进不合适的环境，性能会打折，电费却不会打折。
所以讨论这套资源时，我倾向于先问三个问题：业务峰值出现在什么时候？平均利用率大概多少？如果任务推迟，损失是什么？这些问题没有标准答案，但它们能把“买多少”变成“为什么买”。
利用率是一个诚实的指标
不少团队会盯着峰值性能，日常却跑不满。训练任务有排队期，推理任务有波峰波谷，开发和测试又占用一部分资源。机器空转时，折旧、电力和运维仍在发生。于是出现一种尴尬：账面资源增加了，交付速度却没有同步变化。
原因不一定在硬件。数据管道堵住、任务调度粗放、框架版本不匹配、团队缺少调优经验，都会让设备停在“可用”状态。与其继续加机器，不如先做一次资源盘点：哪些任务长期占卡但利用率低，哪些任务可以错峰，哪些任务根本不需要加速卡。把这些看清楚，新增采购才有依据。
- 记录每类任务的等待时间和实际占用时间；
- 区分长期常驻任务和临时任务，给临时任务设置回收时间；
- 把网络、存储和计算放在同一张表里看，避免只优化一环。
把算力当成服务来管，而不是当成资产来堆
资产思维关注“拥有多少”，服务思维关注“何时可用、成本多少、谁在使用”。两者并不矛盾，但后者接近日常经营。比如，把不同任务分到不同资源池，给临时任务设置回收时间，记录每次作业的资源消耗，这些动作不炫技，却能减少浪费。机器的价值不在于躺在机柜里，而在于被合适的工作负载持续使用。
另一个常被忽略的边界是数据移动。计算再快，如果数据要反复搬运，等待时间仍会吃掉收益。网络、存储和计算需要一起看，单独优化一环，效果有限。企业不一定需要过于复杂的方案，但需要知道自己卡在哪一环。
先算账，再扩容
回到那张电费单。它提醒管理者，算力不是一次性采购，而是一段持续运营。我的判断是：在预算有限时，优先把钱花在可观测性和调度能力上，往往能减少盲目扩容。知道资源去了哪里，才有资格谈扩容；知道业务为什么需要，才不会把机器变成昂贵的背景板。
这不是反对投入，而是反对把投入当成答案。算力可以买来，效率买不来。先把账算清，再决定买多少，可能慢一点，但更接近真正的解法。