智算中心狂飙之后，利用率这道坎谁也绕不过去

过去两年，智算中心几乎成了各地新基建的标配动作。规划动辄上千P，投资动辄数十亿，机房封顶、首批服务器上架、点亮仪式的照片轮番出现在各种通稿里。但热闹退潮之后，一个更硬的问题浮出水面：这些算力到底被用掉了多少？

坦率地讲，行业里对利用率的真实数字讳莫如深。公开场合谈的多是“算力规模”“峰值性能”，很少有人说“过去三个月平均卡时利用率是多少”。原因不难理解——建的时候按峰值需求规划，用的时候却是波峰波谷交替，中间那道落差，就是利用率上不去的根源。

先看需求侧。大模型训练确实是吃算力的大户，但训练任务有极强的阶段性：一个千亿参数模型的预训练可能集中消耗几千张卡数月，随后进入漫长的微调、评测和推理优化期，对大规模集群的占用骤降。而智算中心的建设逻辑恰恰是按“训练峰值”来配置的，一旦大客户训练任务结束，大量高端加速卡就进入闲置状态。这不是某一家的问题，是供需节奏天然错配。

再看供给侧。智算中心不是把GPU插上电就能跑。高速互联、并行文件系统、调度平台、散热与供电，任何一环拖后腿，整机柜的有效算力就打折扣。很多项目在交付初期，网络拓扑调优没做完，存储带宽跟不上，实际可用的算力远低于标称值。这部分“隐性损耗”在报表上看不见，却实实在在拉低了利用率。

更深一层的问题在于调度。当前多数智算中心的资源分配仍以静态划分为主，按租户、按项目切块，块与块之间很难动态借调。一个团队任务结束释放的卡，另一个团队要走完审批、重新配置环境才能接手，中间空转的时间以天计。而在互联网公司内部，成熟的做法是统一调度、弹性抢占、错峰填谷，把碎片时间也榨出价值。这套能力，恰恰是很多新建智算中心最缺的。

于是出现一个尴尬局面：一边是中小AI团队抱怨拿不到卡、排队等资源，另一边是部分集群的加速卡长期低负载运行。信息不对称加上调度不灵活，让“算力荒”和“算力闲”同时存在。这不是靠再建几个中心能解决的，而是运营能力的问题。

要跨过利用率这道坎，方向其实不复杂，但做起来考验定力。第一，把调度平台当成核心资产来建，支持细粒度切分、弹性伸缩和跨租户共享，让资源流动起来。第二，引入更真实的计量方式，按实际卡时、按有效算力计费，而不是按整机柜包年包月，用价格信号引导错峰使用。第三，重视推理场景。随着生成式应用落地，推理需求会越来越常态化、碎片化，智算中心的配置和调度策略要提前为“长尾推理”留出空间，而不是只盯着训练大单。第四，把运维和调优能力沉淀下来，网络、存储、框架层的持续优化，往往比再买一批卡更能提升有效产出。

智算中心的价值，最终不体现在封顶那天的规模数字上，而体现在一年后机房里风扇转得有多满、任务队列排得有多顺。狂飙阶段拼的是胆量和资源，下半场拼的是精细运营。利用率这道坎，谁也绕不过去，早面对比晚面对好。