一位做推理服务的工程师最近遇到一件麻烦事：模型上线前，团队按测试环境的请求量估了一笔算力预算，结果正式跑起来，账单比预期高出不少。问题不在模型，也不在代码，而在于测试环境的流量太平滑了——真实用户会在早高峰集中涌入，也会在深夜几乎归零。预算按平均值算，账单按峰值付。
这类落差正在变多。当算力从机房里的一堆机器，变成财务报表上可以逐月核算的一项支出，它带来的问题就不再只是“够不够用”，而是“用得好不好”。
被计量的东西，才会被认真对待
过去很多企业谈算力，语境接近谈水电容量：先买回来，够用就行，闲置的部分不太有人追问。但当资源以小时、以卡时、以调用量的形式被计价，闲置就变成了看得见的成本。一台长期低负载运行的机器，和一台被充分调度的机器，账面差别会非常直观。
这带来一个微妙的变化：采购决策和技术决策开始相互牵扯。以前买设备是IT部门的事，现在预算审批的人会问一句，这些资源打算怎么用、用完怎么回收。问题本身不新，但被认真对待的频率明显提高了。
值得注意的是，计量本身不解决问题。把资源切成更细的计费单位，只是让浪费变得可见；真正的改善仍然取决于业务侧是否愿意配合调整任务的时间分布，以及技术侧有没有能力把零散的负载拼在一起。
因此，一个更实际的判断标准是：企业能否说清楚自己每一份算力在服务哪个业务、承担哪类请求、忙闲曲线长什么样。说不清楚，计量就只是换了一种记账方式。
峰值与均值之间，藏着大部分支出
回到开头那位工程师的困境。多数业务的负载曲线并不平滑，白天高、夜里低，促销日陡增、平日平缓。如果资源按峰值配置，低谷期就会大量闲置；如果按均值配置，高峰又会撑不住。
常见的缓解办法有几类，思路各不相同：
- 错峰调度。把可延迟的训练任务、批处理任务挪到低谷时段，让同一批资源承担两种负载。
- 弹性伸缩。按请求量动态增减实例，前提是扩容速度跟得上流量爬升的节奏。
- 预留与按需搭配。对稳定可预期的部分做长期安排，对波动部分保留临时补充的空间。
这些做法并不新鲜，难点往往在组织而不是技术：谁来决定哪些任务可以等，谁有权在高峰时段临时加资源，成本算在哪个部门的账上。技术方案写得再漂亮，落到这几问上卡住的情况并不少见。
还有一点容易被忽略：弹性本身也有效率损耗。频繁启停、反复迁移、缓存失效，都会让原本节省下来的资源被抵消一部分。把伸缩做得过于激进，账单不一定更好看。
比堆硬件更值得投入的，是调度能力
面对资源紧张，最直接的反应是增加投入。但在很多场景里，同等规模的算力，通过更好的调度能释放出相当可观的余量。任务排队策略、资源切分粒度、不同任务之间的混部比例，这些看不见的工程细节，往往比多买一批设备更能改变实际体验。
调度能力很难被外部直观看到，这也是它常被低估的原因。它不像新硬件那样有明确的交付节点，更多体现为一系列持续的小幅优化：某个队列的优先级调整、某类任务的超时回收、某段链路的瓶颈消除。积累起来，才形成对资源波动的缓冲。
与此同时，也要承认调度的边界。强实时的业务没法随意延后，数据依赖紧密的任务很难拆分，某些合规要求也会限制资源混部的范围。把调度当成万能解药，最后往往会得到一个复杂但收益有限的系统。
一个更务实的态度是：先把资源的使用情况摸清楚，再判断瓶颈究竟在总量还是在结构。如果忙闲曲线本身很平，加调度能带来的空间有限；如果曲线起伏剧烈，那么优化空间通常比想象中大。
一个尚未定型的问题
算力正在经历从“技术资源”到“经营变量”的转变，但围绕它的管理方法还没有稳定下来。计量口径不统一，成本归集方式各异，业务部门与平台部门之间的责任划分也还在磨合。这些空白意味着，现在做出的很多选择，未来可能需要回头修正。
对企业来说，或许不必急于找到一套标准答案。更值得做的，是把自身负载的真实样貌记录下来，把成本变化的来龙去脉讲清楚。等到方法成熟时，这些积累会变成判断的依据，而不是被账单推着走的被动应对。