GPU按日历小时计成本，按计算小时创收。每一小时空闲都在侵蚀ROI，而这个问题正在从"采购问题"变成"管理问题"。利用率正在取代参数规模，成为企业AI真正的胜负手。
航空业很早就明白一个道理：飞机按日历小时计成本，按飞行小时创收。融资、折旧、保险、定期维护、机组合同——这些成本在每个日历小时都在累积，无论飞机是在天上还是在地上。而收入只来自飞行小时。每一小时"停在地面"都在侵蚀利润。
利用率是航空业最核心的指标，因为它下游关联着几乎所有运营决策：周转纪律、航线设计、维护计划、机组排班、备件库存。一家航空公司可以拥有庞大的机队，但如果利用率低，经济性就会输给机队更小但利用率更高的对手。
企业AI正在经历同样的结构，只是硬件从飞机换成了GPU。
成本按日历小时计（融资、折旧、保险、维护）
产出按飞行小时计
核心指标：飞机利用率
成本按日历小时计（融资、折旧、电力、冷却）
产出按计算小时计
核心指标：GPU利用率
但有一个关键区别：一架空闲的737可以灵活调度到任何航线，而一个空闲的GPU只能吸收与其内存、延迟、持续时间匹配的工作负载。这使得GPU编排比航班调度更复杂。
企业AI的第一波竞争围绕模型质量展开：更大的参数量、更多的训练算力、更高的基准分数。但这种能力绑定了一个依赖——生产级AI运行在专用硬件上，而GPU正在成为战略约束。
2020年，微软为OpenAI建造了一台专用超算：超过10,000颗GPU和285,000颗CPU核心，当时被认为是全球最大的系统之一。到2026年，即使是资金最充裕的实验室也在同时应对多个硬件平台的算力约束。
注：2020年微软超算规模报道为当年全球最大系统之一；2026年Anthropic同时在Amazon、Google、Microsoft、AMD四个平台运行多GW级 commitments。Meta亦签署了同等规模的算力交易。
六年之间，能力不再是瓶颈，硬件利用效率成了新的天花板。采购GPU只是开始，让它们持续运转才是真正的挑战。
企业通过API调用模型时，成本随token使用量线性增长。一个每月处理几千次请求的概念验证看起来可以承受，但同样的工作负载进入生产后，成本线会持续攀升，永不到顶。
另一种选择正在获得关注：企业自购GPU，本地运行模型——将可变的线性成本转化为固定的资本支出。
注：柱形仅示意成本结构差异，非精确比例。自建GPU的盈亏平衡点取决于利用率，利用率越高，单次计算成本越低。
但自建并没有解决所有问题。它只是把问题从"能不能买到GPU"换成了"能不能让GPU一直忙"。第一个问题有采购团队负责，第二个问题却常常无人真正担责。
一个集群报告高平均利用率，并不代表它在做正确的事。GPU全天候运行，但需求并非均匀分布。基础设施必须按峰值配置——训练、批处理、实时流量同时到达——这导致峰值之外有相当一部分容量被闲置。
更深层的问题在于：不同工作负载对GPU的需求截然不同。
每种工作负载对GPU的内存、延迟、持续时长要求都不同。一个为推理优化的调度器，在训练任务面前几乎无效。
调度器如果为其中一种工作负载优化，其他三种几乎必然被错配。一个集群可以报告"高占用率"，同时多个排队任务在等待恰好被其他任务占用的GPU类型。"忙"不等于"有效"。
最大化GPU ROI需要的不只是一次性配置决策，而是持续、主动的基础设施管理，每时每刻都在运行，而非只在采购时介入。
一个新兴的工程领域正在成形：GPU管理——位于工作负载、模型与硬件之间的编排层。它的职责是持续决定：哪个工作负载运行、何时运行、如何运行、在集群中的哪颗GPU上运行。
专业化与编排解决同一问题的不同一半。小型专用模型可以用更少的资源完成特定任务，释放出原本被大模型占用的容量——但释放出的容量如果无人重新分配，只会变成另一种形式的空闲。
没有编排的专业化，释放了容量但无人回收。没有专业化的编排，则没有多少容量值得回收。两者缺一不可。
GPU管理正在从"运维问题"升级为"战略问题"。企业AI的下一个分水岭，不在于谁拥有最多的GPU，而在于谁能把已有的GPU用到最有效率。
评估你的GPU集群利用率，从"采购思维"转向"管理思维"。
建立持续编排机制，让每一颗GPU都在创造价值，而非仅仅是"在运行"。