Grok4.5“快准狠”的背后，是马斯克的算力利用率困局仍未翻篇

本文来自微信公众号： 火星AI推演 ，作者：火星AI推演

7月9日，SpaceXAI发布Grok 4.5。不拼“最强”，主打“够用且便宜”。而就在此前两个月，马斯克接连将GPU租给了Anthropic和谷歌。

这背后是老马怎样的算盘？Grok4.5的发布与他出租算力之间有什么共通的战术逻辑？

正文

关注马斯克的人，前两天估计都被Grok 4.5刷了屏。

SpaceXAI于7月9日正式发布的Grok 4.5，有三个鲜明特征：

定位变了——不再死磕“最强”。Grok 4.5是SpaceX AI首个重点面向编程、Agent和知识工作场景的模型。马斯克本人也很坦诚：它不如Claude Fable，但大多数日常任务并不需要那么高的性能上限。

成本降了——每百万输入tokens定价2美元，每百万输出tokens定价6美元，比Claude Opus系列和GPT-5.5便宜60%以上。

速度快了——据公开报道，Grok 4.5的推理速度最高可达80 tokens/秒，妥妥的第一梯队。

而就在此前的5月和6月，SpaceX先后与Anthropic和谷歌签下算力租赁大单，马斯克摇身一变成了“算力包租公”。

这两件事看似各说各话，实则根系相连。共同的大背景是：算力规模急剧膨胀，但算力利用率始终上不去。

一个尴尬的数字

今年5月，SpaceX与Anthropic达成协议，将Colossus 1数据中心的全部算力对外出租——涉及超过22万张英伟达GPU，涵盖H100、H200及最新的GB200加速卡。

6月，就在计划上市前一周，SpaceX同谷歌也签下了类似合约：从今年10月起，后者将获得约11万张GPU的算力使用权。

马斯克为何甘当“包租公”？自己用不香吗？——核心答案只有一个：自家模型的算力利用率，实在太低了。

据公开报道，SpaceXAI在Colossus 1上训练Grok时，算力利用率仅有11%。而同行其他玩家普遍能跑到40%左右。

这意味着22万张GPU中，将近20万张处于空转或低效运转状态。

与其让它们白白耗电，不如租出去换点现金流，冲抵一下SpaceX的运营亏损——何况出租算力并不影响Grok自身的训练进度。

而Grok 4.5的发布，正是马斯克基于“算力利用率短期难以改善”这一现实，做出的战术回调：既然利用率暂时上不去，那就先做一个更快、更省token、更便宜的模型。

那么问题来了：算力利用率为什么这么低？

回答这个问题之前，有必要先补充一点理论知识。

一、GPU和算力的基本概念

训练AI使用的芯片，叫图形处理器，也就是GPU。GPU上面有成千上万个计算核心对数据做运算，这种运算数据的能力就称之为算力，它衡量数据的运算速度（单位通常是FLOPS，即每秒浮点运算次数）。需要注意的是，和CPU主要进行串行运算不同，GPU的这种运算是并行运算，即把一个复杂的矩阵运算拆解成成千上万个简单小任务，让众多的计算核心同时处理。因此，在运算海量数据的效率上，GPU是远胜过CPU的。这也是为什么训练AI用的芯片是GPU而非CPU：首先，训练AI需要海量的数据；其次，AI运算数据要求极快的速度。显然，相比串行运算的CPU，并行运算的GPU更具备天然优势。

理论上，GPU堆得越多，意味着可用于并行运算的计算核心总数就越多，单位时间内（如每秒）完成的浮点运算次数就越多。而算力的单位刚好是每秒浮点运算次数。由此可知，GPU堆得越多，按理说算力就越高（本文我们称其为理论算力）。

二、三个重要的工程问题

这里需要关注三个容易混淆且极其重要的工程问题：

第一，单位时间内运算数据的速度越快，并不等同运算数据的数量越多。单张GPU能够实际消化的数据的量，除了看算力，还取决于GPU的显存和带宽。显存类似“数据仓库”，主要负责存储即将运算或者已运算完的数据；带宽则类似“数据传输带”，负责将数据从显存处传输至计算核心。不难理解，如果显存容量不够大，或者带宽速率不够快，即便计算核心能以极快的速度运算完一批数据，可能也经常处于等待新数据传输的闲置状态——业内将这种现象称为“显存饥饿”。

第二，GPU规模扩大会带来显著的通信开销。在多卡并行训练中，每张GPU完成运算后，需要同其他GPU交换信息，这个过程就是通信。GPU数量越多，通信量就越大，且后者随着前者规模的扩大呈非线性飙升。更关键的是，并行运算存在“短板效应”：所有GPU在完成本轮数据运算、交换后要同步进入下一轮运算。即便只有极少数几张卡因发热降频、网络波动等产生微小延迟，都会像多米诺骨牌一样引发连锁反应，拖慢整个集群的训练步调。如果说，带宽决定了数据在单张GPU上的传输效率，那么通信开销反映的则是GPU之间同步所消耗的时间。两者共同决定了多卡并行状态下数据的传输效率。

第三，理论算力≠实际算力。实际算力才是决定模型训练效率的关键参数，两者的关系可以归纳为：

实际算力＝理论算力×算法效率×工程软件转化率

其中，算法是运算数据的方法，可类比为GPU运算数据的“操作手册”；好的算法能让算力事半功倍。这其中一个典型的例子，是2017年谷歌在论文《Attention Is All You Need》中提出的Transformer架构：相较于循环神经网络（RNN）按顺序处理数据的方式，Transformer架构允许模型在处理长序列数据时并行，从而提高了模型高效运算数据的能力。工程软件是将算法翻译为机器指令的“翻译器”和“调度官”，主要包括通信库、编译器和调度器。如果说GPU是钢筋水泥，算法是设计图纸，那么工程软件就是确保图纸高效落地的施工调度系统。其中，通信库和编译器可以优化数据的传输路径，调度器能够降低GPU卡顿、延迟或故障而产生的通信开销。因此，高质量的工程软件既是算法落地的保障，也是降低通信开销、提升实际算力的关键。

综上，算法和工程软件做得越理想，实际算力越接近理论算力。

三、马斯克当前面临的困境

在AI时代，能源、数据和算力正成为新的核心资源。Colossus1从开始建造到落地、投入使用仅用了122天。这充分彰显了“马斯克效率”，巩固了马斯克作为AI基础设施供应商的地位，为其争取到了新的财富创造机制和经济话语权。而他目前面对的棘手问题，正好就出在上文提到的工程软件方面。

首先，调度器做的还不够精。

在拥有22万张卡的Colossus1集群中，由于硬件基数过于庞大，几乎每隔几个小时，就可能有一张卡降频、掉线——卡一坏，模型训练就只有被迫中断。面对这个棘手的问题，谷歌和Meta等科技巨头的调度器，能在毫秒级的时间内自动换卡和断点续训。SpaceXAI作为新玩家，其调度器在如此大规模集群下的响应速度还不够快，导致整个集群常常陷入“一卡故障，万卡等待”的低效泥潭。

其次，编译器也还没完全适配。

编译器负责把程序员写的代码翻译成GPU能执行的机器码。SpaceXAI早期使用的XLA编译器，是谷歌JAX框架下的产物。XLA本身不差，但它翻译出来的是通用的机器码，并不了解任何特定GPU集群的物理布局。直接套用在Colossus1上，调度策略和显存管理都很难发挥出GPU的极限。

这也解释了为什么马斯克决定自研基于C/C++底层框架的编译器——一方面，相比Python、Java等高阶语言，C语言更接近硬件层；另一方面，通过自研，打造出一个熟悉自家GPU集群物理布局的编译器，能够提高软硬协同，进而充分“榨出”GPU的性能。

四、Grok4.5的新亮点

那么针对上述问题，本次发布的Grok 4.5做了什么改进呢？

一个核心亮点，是采用了混合专家架构（MoE）。

在MoE架构下，处理不同类别数据的“专家”被部署在不同的GPU组上：比如GPU 01-10存放“代码专家”，GPU 11-20存放“逻辑专家”，GPU 21-30存放“数学专家”……

当有数据进入时，MoE会根据数据类型只激活对应的专家，调度相应的GPU组（比如处理代码任务就只唤醒01-10），而不需要所有GPU同步参与。这就大幅降低了通信同步的压力，提高了数据运算的效率，一定程度上缓解了算力利用率低下的问题。

可以说，老马为了“驯服”算力也是十八般武艺用尽。但以调度器、编译器等为代表的软件短板，依然是亟待他和团队攻破的工程难关。

结语

把闲置算力租出去，是商业上的止损逻辑；发布一个“够用但便宜”的新模型，是技术上的务实逻辑。

两件事都指向同一个真相：算力规模不等同于算力能力，“驾驭算力”或许远远比“拥有算力”更重要，也更困难。

本内容由作者授权发布，观点仅代表作者本人，不代表虎嗅立场。如对本稿件有异议或投诉，请联系 tougao@huxiu.com。

本文来自虎嗅，原文链接：https://www.huxiu.com/article/4878054.html?f=wyxwapp