Dharma-AI最近在Hugging Face发了一篇文章,说企业AI的瓶颈正在换挡:以前愁"抢不到GPU",现在愁"GPU转起来了却出不来活"。这家公司同时在卖专用模型和算力调度产品,判断听着像行业观察,骨子里也是自家生意的推销词。
2020年微软给OpenAI搭的那台专属超级计算机,用了超过一万颗GPU、28.5万个CPU核心,当时号称全球最大系统之一。六年过去,这个数字听着更像起点。资金最充裕的几家实验室这两年仍在为"能不能拿到足够算力"发愁,向多家云厂商和芯片供应商同时压单。
瓶颈往哪挪:从抢模型到喂饱GPU
对大多数企业来说,稀缺换了一副面孔。调用大模型API,账单随token线性涨,做demo阶段便宜,上了生产规模就压不住。
不少公司转向自建GPU集群,把变动成本换成固定资产。这笔账过了盈亏平衡点确实划算——但"盈亏平衡点"取决于负载稳不稳定、规模够不够大、有没有人长期运维,不是所有企业算完账都该建机房。
自建那天起,问题从"能不能采购到"变成"能不能让它一直有活干"。这个问题历史上从来没有一个团队专门负责——采购团队管到货为止,运维团队管到不宕机为止,中间那段"利用率"的责任,常年悬空。
忙不等于赚:异构任务的错配
GPU按日历小时计提折旧、电费和散热成本,不管此刻有没有干活。只有真正跑起有效计算,才算产出。
企业的活儿五花八门:训练、微调、量化、实时推理、批处理、模型评测,常常混在同一个集群里。它们对显存、延迟、运行时长的要求完全不同。
Dharma-AI借用飞机类比:飞机停着不飞,成本照算,收入归零,航空公司靠"飞行时数"就能看出运营水平。这个类比能说清闲置成本,边界也很清楚——芝加哥的飞机可以临时改飞丹佛,代价很小;闲置的GPU却做不到,它只能接住显存、延迟、时长都对得上的任务。这也是GPU调度比机队调度更难的地方。
企业该看的不是"GPU忙不忙",而是几个更具体的信号:
| 观察维度 | 忙碌但低效的信号 | 该检查什么 |
|---|---|---|
| 显存占用 | 长期占满,但完成的任务数没涨 | 是否被少数大模型占满,能否换成专用小模型 |
| 排队时长 | 实时推理频繁超时 | 调度器是否把资源让给了训练或批处理 |
| 任务分布 | 训练/批处理挤占推理窗口 | 需要分池、分优先级,而不是共享一个队列 |
| 单位产出 | GPU小时成本 vs 完成的有效请求数 | 这才是最终该看的数字,不是占用率本身 |
接下来该盯的,是这几条曲线各自的走势,而不是综合占用率的绝对值。
谁该现在做什么
| 角色 | 现在该做的事 |
|---|---|
| 基础设施/平台负责人 | 把综合利用率拆成训练、推理、批处理分开看,先揪出谁在挤占谁 |
| 模型部署与算力采购决策者 | 拿真实负载测试专用模型能不能替代大模型,再决定要不要买调度产品 |
Dharma-AI的解法有两条腿:专用小模型负责腾资源,动态编排负责把腾出来的资源实时分给排队任务。少了哪一环,另一环都打折扣——模型再小,没人接盘,腾出来的空间还是闲置;编排再聪明,模型依旧笨重,能腾挪的空间也有限。
这套逻辑站得住,但这篇文章出自一家同时卖专用模型和GPU编排产品的公司,判断天然带着推销自己方案的立场,不代表整个行业已经达成共识。
GPU利用率是真实、容易被忽视的成本项,但不是企业AI唯一的胜负手——模型质量、数据管线、网络通信、电力和组织执行力,哪个掉链子照样出问题。
劳而无功,古人早有此说——GPU转得再欢,账算不对,照样打水漂。