GPU闲置成本治理：从资源浪费看基础设施

利用率，而非智能，才是 AI 面临的下一个真正约束。

航空业曾以惨痛代价认识到这一点。在这个行业的大部分历史中，最能预测一家航空公司能否生存下来的指标，是每架飞机每天有多少时间停在地面上。

原因在于其结构。飞机的成本按自然时间不断累积：融资、折旧、机身保险、定期维护、机组合同。它的收入却只在飞行时间内产生。飞机每在地面上多停留一小时，等式中的产出端就会进一步缩水，而成本端仍像往常一样持续运转。利用率也是航空公司几乎所有其他运营活动的下游结果。过站周转纪律、航线网络设计、维护规划、机组排班和备件供应，最终都会体现在这一个数字上，因为无论其他方面做得多好，底层运营一旦失灵，飞机就只能停在地面。

更庞大的机队当然仍有帮助。更多飞机意味着更多可用运力，事实就是这么简单。但两家拥有相近规模机队、运营相似航线的航空公司，最终的经营效益可能截然不同，而其中的大部分差距都可以追溯到一个指标，而非机队规模。

企业 AI 正在另一种硬件上遭遇同样的结构性问题。GPU 的成本同样按自然时间累积，无论它此刻是否在执行有用的工作，融资、折旧、电力和冷却成本都会持续产生。它的产出却只在实际计算时产生。增加 GPU 的作用，大致相当于航空公司扩充机队：它能带来真实的容量和切实的优势，但依然无法保证获得真正决定胜负的结果。拥有相近 GPU 预算的两家公司，差距越来越取决于任意时刻有多少硬件正在做有用的事情，而不是其中任何一家拥有多少硬件。这个数字与航空公司的利用率一样，位于企业几乎所有其他基础设施决策的下游。智能推动这个行业走到了今天，而利用率正在成为下一个真正的约束。

瓶颈已从模型转向算力

随着 AI 规模扩大，稀缺性并没有消失。它只是沿着链条向上移动，最终落在了一种完全不同的资源上。

企业 AI 的第一波竞争，胜负取决于模型质量。更大的模型、更多的训练算力、更严格的 benchmark：参数量和排行榜名次主导着整个行业的讨论。这场竞赛确实催生了足以承载真实企业工作负载的模型。但这种能力也捆绑着一项依赖：生产环境中的 AI 必须运行在专用硬件上，而今天，这种硬件几乎完全就是 GPU。

GPU 价格昂贵、供应受限，其需求远远超出可用数量——即使在市场最顶端也是如此。2020 年，Microsoft 为 OpenAI 建造了一台专用超级计算机：超过 10,000 块 GPU 和 285,000 个 CPU 核心。据当时报道，它是全球五大系统之一，用于训练后来成为 GPT-3 的模型。那时，这似乎是一个几乎难以想象的硬件集群，其规模让人觉得，只要能够获得这种资源，算力问题就已经解决了。

六年后，这个数字看起来更像起点，而不是上限。到 2026 年，即使是全球资本最雄厚的实验室，也仍将算力获取视为一个现实存在的战略约束，而非已经解决的问题。仅 Anthropic 一家公司，就同时在 Amazon、Google、Microsoft 和 AMD 四个独立硬件平台上部署了数吉瓦级的资源承诺，而且这些承诺是在短短几个月内层层叠加的。与此同时，Meta 也签署了规模相近的数吉瓦级协议。当一个买家实际上拥有近乎无限的资本，却仍无法从任何单一来源获得足够算力，以至于必须同时向四家供应商分散采购承诺时，这就是算力稀缺最真实的样子。

相隔六年的这两件事，都代表了一个实验室仅仅为了保持竞争力所需要达到的前沿水平。这期间发生的变化，与 AI 能力变得更强关系不大，却与能力本身不再是决定性约束密切相关。

同样的模式也以另一种形式出现在实验室的下游。通过 API 使用这些模型的企业，遇到的更多是定价问题，而不是硬件问题。成本会随着 token 使用量线性增长，而仅仅这一事实，就几乎彻底区分了概念验证与生产环境的经济模型。一个每月处理几千次请求的 PoC 看起来负担得起；同样的工作负载一旦扩展到生产规模，就可能变成一项始终无法消除的成本。另一种越来越流行的方案非常直接：企业购买自己的 GPU，在本地运行模型，用固定的资本支出替代随用量线性增长的可变成本。

API 成本随使用量增长，而自有基础设施的成本则基本保持固定。一旦越过盈亏平衡点，这笔账就会反转。

这种转变让 GPU 从一个费用项目变成了基础设施。它需要为增长预留容量，也需要为需求峰值预留容量，因此配置规模必然高于任何一个具体星期的实际需求。这意味着完成采购并没有解决问题，反而开启了一个新问题。集群上线当天，问题就不再是“我们能否获得加速器”，而变成了“我们能否让它们始终保持忙碌”。但只有第一个问题配备了专门的采购团队。签下硬件合同的工作有明确截止日期，也有明确负责人；让硬件不再“停在地面上”的工作，却在不声不响中决定了这笔交易是否值得签署。

这些交易描述的是容量承诺，而非效率。如何充分利用这些容量，是另一个独立的问题，由不同的人负责，衡量方式远没有那么严谨，距离真正解决也还要远得多。

为什么繁忙的集群仍在浪费容量

一个装满繁忙 GPU 的集群，仍然可能浪费掉大部分潜力，而原因几乎总是相同的：GPU 全天候持续运行，但施加在它们身上的需求并非如此。基础设施必须按照峰值进行配置，也就是训练任务、批处理任务和实时流量同时到来的时刻。这必然导致峰值以外的大量容量已经配置，却没有得到使用。如果每块 GPU 都能同样有效地承接各种工作，那么更准确的预测本身就足以解决这个问题。但很少有 GPU 能做到这一点，而这恰恰是问题更难解决的另一半。

这种错配还要从更深一层说起。

在第一代企业 AI 中，GPU 的任务基本只有一个：运行 inference。如今，同一套硬件要支持训练、fine-tuning、量化、实时 inference、批量 inference、embedding 生成和模型评估。这些工作往往服务于同一个组织，有时甚至针对同一个模型，并运行在同一个集群上。每种工作负载对硬件的要求都不相同，而且差异十分深刻。

实时 inference 几乎把低延迟置于其他一切需求之上，因为响应太慢就等同于响应失败。批处理工作关心吞吐量，可以容忍延迟，有时甚至可以等待数小时。训练任务可能连续占用一块 GPU 数小时乃至数天。量化需要大量容量，但只会短暂占用。针对其中一种工作负载调优的 scheduler，几乎必然会错误分配另外几种工作负载。这种失败也不一定会出现在利用率 dashboard 上。集群可能报告很高的平均占用率，但多个排队中的任务仍在等待符合自身规格的 GPU，而这种 GPU 恰好正忙于运行完全不同的工作。

具体的工作负载组合因组织而异，但问题的形态不会改变。飞机的类比也正是在这里触及了边界，而这个边界并不只是对类比加以限定，它还揭示了新的问题。闲置的飞机通常可以被重新部署到机队中的任何航线上：一架停在芝加哥的 737，可以改飞丹佛而不是达拉斯，几乎不会产生多少额外代价。闲置 GPU 却只能承接其显存、延迟和持续时间特征真正能够满足的工作负载。

这种差异让编排比机队调度更加困难，也让问题从“GPU 是否被占用”转变成：“哪种工作负载应该在什么时间、以什么优先级，运行在哪块 GPU 上？”再购买一整机架的 GPU，只会增加容量和成本，并不能解决错配问题。新增容量也可能像已经安装的容量一样，在错误的时刻以错误的资源形态闲置在那里。

智能开始进入基础设施

要最大化 GPU ROI，仅靠一次性的资源配置决策远远不够。它要求持续、主动地管理基础设施本身：这种管理需要每小时都在运行，而不是只在采购时发生。为此，一个独立的领域正在形成——GPU Management。它是位于工作负载、模型和硬件之间的编排层，负责持续决定哪个工作负载要运行、何时运行、如何运行，以及运行在集群中的哪一块具体 GPU 上。这些概念本身并不神秘。它更接近于优秀运维团队凭直觉已经在做的事情，只不过如今这些工作被正式化并持续运行，不再依赖某个人发现问题。

智能并不会停在模型的边界。编排层正在实时做出分配决策，而模型本身对此毫无感知。

过去，智能几乎完全存在于模型中：规模更大、训练更充分、能力更强，这就是竞争的主要内容。如今，智能还必须存在于基础设施中，存在于这样一个层级：它需要时时刻刻决定，在多个相互竞争的工作负载中，哪个应该获得刚刚空闲出来的 GPU，以及相对于队列中等待的其他工作，它应该具有怎样的优先级。

仅仅让 GPU 保持忙碌已经不能作为目标，因为只要运行一些本可以等待的低优先级任务，就很容易制造“繁忙”的假象。真正的目标，是最大化每块已安装 GPU 所产生的回报，而这远比此前的资源配置问题更加持续和动态。

优秀的资源配置并不会消除这个问题，只会改变它的形态。资源配置决策只在采购时做一次；资源分配决策却需要持续不断地做：每当一个任务结束、每当一个新请求到达、每当面向客户的服务与内部训练任务之间的优先级发生变化，都要重新决策。

这种高频率解释了为什么决策过程已经从人工逐项处理，转变为必须自动运行。凌晨三点不会有工程师盯着 dashboard，决定刚完成训练任务的 GPU 应该交给队列中的批处理任务，还是应该保留给即将到来的客户流量峰值。必须有其他系统持续做出这种判断，而且其正确率必须足够高，以至于不需要任何人反复检查。

这个领域还很新，相关工具和惯例仍在形成之中。对于成熟的 GPU Management 实践究竟应该是什么样子，目前还没有形成统一的 playbook。但至少有一件事已经明确：约束转移到了哪里。

专用化释放容量，编排使用容量

专用化与编排解决的是同一个问题的不同部分。

专用化的小型模型，可以用大型通用模型完成同一任务所需资源的一小部分来执行特定任务，同时不牺牲任务所需的质量。这会直接影响利用率。过去需要一个大型模型、并在整个任务期间占据集群大部分容量的工作负载，现在可以改由体量更小、针对特定任务的模型运行，只占用原来一小部分资源。曾经被完全占满的容量，就这样突然释放了出来。

专用化具体能够释放多少容量，取决于工作负载和模型。但释放出来的容量仍然必须有去处，否则它只会闲置在那里。只有当某个系统主动决定如何使用这些释放出来的空间，将其重新分配给另一个工作负载、另一个模型或后方排队的另一个队列时，更小的专用模型才能真正转化为 GPU ROI。

如果缺乏管理，释放出来的容量只会变成另一种形式的闲置，而不是收益。它与明显未被使用的 GPU 相比，只是以另一种方式变得不可见，生产力却并没有更高。

没有编排的专用化，释放的是无人回收的容量。没有专用化的编排，则没有多少值得回收的容量。任何一个杠杆都无法独自完成全部工作。

没有编排的专用化，会释放无人回收的容量。没有专用化的编排，一开始就没有多少值得回收的容量，因为模型仍然很大，它们留下的可用空间很少。任何一个杠杆都无法独自完成全部工作；每个杠杆都会抬高另一个杠杆所能达到的上限。如果目标是真正缩小已安装容量与有效产出之间的差距，而不只是改变浪费所处的位置，那么二者缺一不可。

这就是为什么模型架构与 GPU Management，是从两个不同方向解决同一个问题的两种方式，而且最终彼此依赖。一方缩减每个工作负载所需要的资源；另一方持续决定由此产生的资源差额应该流向哪里。

更庞大的机队始终是一项真实优势，本文并不否认这一点。但在机队规模相近的航空公司之间——有时甚至是在规模更小的公司与更大的对手之间——胜者通常是那个能够更充分地利用现有飞机的公司，而这个结果承载着航空公司在底层运营中所做对的一切。

企业 AI 正从另一个方向走向同样的经营纪律。GPU 已经安装、已经开始折旧、相关投入也已经承诺。专用模型与 GPU Management 是两条并行的解决路径，或者说是一种二元策略。专用化缩减每个工作负载所需的资源，管理则最大化基础设施的回报。能够同时掌握二者的企业，将在未来十年的 AI 竞争中确立节奏。

更新的模型，同样的优势——尽管采用了更新的架构，DharmaOCR 仍通过领域专用化和针对性训练，在巴西葡萄牙语任务上击败了 Mistral OCR4 和 Unlimited-OCR。本文展示了这一优势背后的证据与机制。

为什么专用化不可避免——专用化论点的结构性与理论性基础。优化理论、进化生物学、竞争市场和机器学习都指向同一个预测：在资源有限且存在选择压力的情况下，适配性胜过广度。

专用化胜过规模：大多数 AI 采购决策忽视的战略变量——对本文的实证与战略补充。No Free Lunch theorem 解释了为什么专用化在结构上是可预测的，而本文则考察了专用化在实践中表现更优的证据，以及为什么它在大多数 AI 采购决策中的权重仍然不足。

文本退化：大多数 benchmark 都不会追踪的生产故障模式——一种已有记录的故障模式，会在语言模型超出其有效领域边界运行时出现。

超越 Chatbot 的 Direct Preference Optimization——偏好优化技术如何扩展到对话式 AI 之外的专用领域；这是本文所论证的、在结构上必然出现的领域聚焦策略的一种具体实现。

在 Hugging Face 上探索 Dharma AI，体验我们的交互式 demo、下载开源模型，并了解专用 AI 系统如何在真实企业应用中超越通用模型。

本文提及的模型 1

本文提及的 Spaces 1

该作者的更多内容

更新的模型，同样的优势

为什么专用化不可避免

下一个前沿是管理一整支 Agent 舰队，而且没有任何东西能够阻止它。

· 注册或登录后发表评论

本文提及的模型 1

本文提及的 Spaces 1