本文来自微信公众号： 火星 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 同步参与。这就大幅降低了通信同步的压力，提高了数据运算的效率，一定程度上缓解了算力利用率低下的问题。

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

结语

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

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