7 月 9 日，SpaceXAI 發(fā)布 Grok 4.5。不拼 " 最強 "，主打 " 夠用且便宜 "。而就在此前兩個月，馬斯克接連將 GPU 租給了 Anthropic 和谷歌。
這背后是老馬怎樣的算盤？Grok4.5 的發(fā)布與他出租算力之間有什么共通的戰(zhàn)術邏輯？
正文
關注馬斯克的人，前兩天估計都被 Grok 4.5 刷了屏。
SpaceXAI 于 7 月 9 日正式發(fā)布的 Grok 4.5，有三個鮮明特征：
定位變了——不再死磕 " 最強 "。Grok 4.5 是 SpaceX AI 首個重點面向編程、Agent 和知識工作場景的模型。馬斯克本人也很坦誠：它不如 Claude Fable，但大多數(shù)日常任務并不需要那么高的性能上限。
成本降了——每百萬輸入 tokens 定價 2 美元，每百萬輸出 tokens 定價 6 美元，比 Claude Opus 系列和 GPT-5.5 便宜 60% 以上。
速度快了——據(jù)公開報道，Grok 4.5 的推理速度最高可達 80 tokens/ 秒，妥妥的第一梯隊。
而就在此前的 5 月和 6 月，SpaceX 先后與 Anthropic 和谷歌簽下算力租賃大單，馬斯克搖身一變成了 " 算力包租公 "。
這兩件事看似各說各話，實則根系相連。共同的大背景是：算力規(guī)模急劇膨脹，但算力利用率始終上不去。
一個尷尬的數(shù)字
今年 5 月，SpaceX 與 Anthropic 達成協(xié)議，將 Colossus 1 數(shù)據(jù)中心的全部算力對外出租——涉及超過 22 萬張英偉達 GPU，涵蓋 H100、H200 及最新的 GB200 加速卡。
6 月，就在計劃上市前一周，SpaceX 同谷歌也簽下了類似合約：從今年 10 月起，后者將獲得約 11 萬張 GPU 的算力使用權。
馬斯克為何甘當 " 包租公 "？自己用不香嗎？——核心答案只有一個：自家模型的算力利用率，實在太低了。
據(jù)公開報道，SpaceXAI 在 Colossus 1 上訓練 Grok 時，算力利用率僅有 11%。而同行其他玩家普遍能跑到 40% 左右。
這意味著 22 萬張 GPU 中，將近 20 萬張?zhí)幱诳辙D(zhuǎn)或低效運轉(zhuǎn)狀態(tài)。
與其讓它們白白耗電，不如租出去換點現(xiàn)金流，沖抵一下 SpaceX 的運營虧損——何況出租算力并不影響 Grok 自身的訓練進度。
而 Grok 4.5 的發(fā)布，正是馬斯克基于 " 算力利用率短期難以改善 " 這一現(xiàn)實，做出的戰(zhàn)術回調(diào)：既然利用率暫時上不去，那就先做一個更快、更省 token、更便宜的模型。
那么問題來了：算力利用率為什么這么低？
回答這個問題之前，有必要先補充一點理論知識。
一、GPU 和算力的基本概念
訓練 AI 使用的芯片，叫圖形處理器，也就是 GPU。GPU 上面有成千上萬個計算核心對數(shù)據(jù)做運算，這種運算數(shù)據(jù)的能力就稱之為算力，它衡量數(shù)據(jù)的運算速度（單位通常是 FLOPS，即每秒浮點運算次數(shù)）。需要注意的是，和 CPU 主要進行串行運算不同，GPU 的這種運算是并行運算，即把一個復雜的矩陣運算拆解成成千上萬個簡單小任務，讓眾多的計算核心同時處理。因此，在運算海量數(shù)據(jù)的效率上，GPU 是遠勝過 CPU 的。這也是為什么訓練 AI 用的芯片是 GPU 而非 CPU：首先，訓練 AI 需要海量的數(shù)據(jù)；其次，AI 運算數(shù)據(jù)要求極快的速度。顯然，相比串行運算的 CPU，并行運算的 GPU 更具備天然優(yōu)勢。
理論上，GPU 堆得越多，意味著可用于并行運算的計算核心總數(shù)就越多，單位時間內(nèi)（如每秒）完成的浮點運算次數(shù)就越多。而算力的單位剛好是每秒浮點運算次數(shù)。由此可知，GPU 堆得越多，按理說算力就越高（本文我們稱其為理論算力）。
二、三個重要的工程問題
這里需要關注三個容易混淆且極其重要的工程問題：
第一，單位時間內(nèi)運算數(shù)據(jù)的速度越快，并不等同運算數(shù)據(jù)的數(shù)量越多。單張 GPU 能夠?qū)嶋H消化的數(shù)據(jù)的量，除了看算力，還取決于 GPU 的顯存和帶寬。顯存類似 " 數(shù)據(jù)倉庫 "，主要負責存儲即將運算或者已運算完的數(shù)據(jù)；帶寬則類似 " 數(shù)據(jù)傳輸帶 "，負責將數(shù)據(jù)從顯存處傳輸至計算核心。不難理解，如果顯存容量不夠大，或者帶寬速率不夠快，即便計算核心能以極快的速度運算完一批數(shù)據(jù)，可能也經(jīng)常處于等待新數(shù)據(jù)傳輸?shù)拈e置狀態(tài)——業(yè)內(nèi)將這種現(xiàn)象稱為 " 顯存饑餓 "。
第二，GPU 規(guī)模擴大會帶來顯著的通信開銷。在多卡并行訓練中，每張 GPU 完成運算后，需要同其他 GPU 交換信息，這個過程就是通信。GPU 數(shù)量越多，通信量就越大，且后者隨著前者規(guī)模的擴大呈非線性飆升。更關鍵的是，并行運算存在 " 短板效應 "：所有 GPU 在完成本輪數(shù)據(jù)運算、交換后要同步進入下一輪運算。即便只有極少數(shù)幾張卡因發(fā)熱降頻、網(wǎng)絡波動等產(chǎn)生微小延遲，都會像多米諾骨牌一樣引發(fā)連鎖反應，拖慢整個集群的訓練步調(diào)。如果說，帶寬決定了數(shù)據(jù)在單張 GPU 上的傳輸效率，那么通信開銷反映的則是 GPU 之間同步所消耗的時間。兩者共同決定了多卡并行狀態(tài)下數(shù)據(jù)的傳輸效率。
第三，理論算力≠實際算力。實際算力才是決定模型訓練效率的關鍵參數(shù)，兩者的關系可以歸納為：
實際算力＝理論算力 × 算法效率 × 工程軟件轉(zhuǎn)化率
其中，算法是運算數(shù)據(jù)的方法，可類比為 GPU 運算數(shù)據(jù)的 " 操作手冊 "；好的算法能讓算力事半功倍。這其中一個典型的例子，是 2017 年谷歌在論文《Attention Is All You Need》中提出的 Transformer 架構(gòu)：相較于循環(huán)神經(jīng)網(wǎng)絡（RNN）按順序處理數(shù)據(jù)的方式，Transformer 架構(gòu)允許模型在處理長序列數(shù)據(jù)時并行，從而提高了模型高效運算數(shù)據(jù)的能力。工程軟件是將算法翻譯為機器指令的 " 翻譯器 " 和 " 調(diào)度官 "，主要包括通信庫、編譯器和調(diào)度器。如果說 GPU 是鋼筋水泥，算法是設計圖紙，那么工程軟件就是確保圖紙高效落地的施工調(diào)度系統(tǒng)。其中，通信庫和編譯器可以優(yōu)化數(shù)據(jù)的傳輸路徑，調(diào)度器能夠降低 GPU 卡頓、延遲或故障而產(chǎn)生的通信開銷。因此，高質(zhì)量的工程軟件既是算法落地的保障，也是降低通信開銷、提升實際算力的關鍵。
綜上，算法和工程軟件做得越理想，實際算力越接近理論算力。
三、馬斯克當前面臨的困境
在 AI 時代，能源、數(shù)據(jù)和算力正成為新的核心資源。Colossus1 從開始建造到落地、投入使用僅用了 122 天。這充分彰顯了 " 馬斯克效率 "，鞏固了馬斯克作為 AI 基礎設施供應商的地位，為其爭取到了新的財富創(chuàng)造機制和經(jīng)濟話語權。而他目前面對的棘手問題，正好就出在上文提到的工程軟件方面。
首先，調(diào)度器做的還不夠精。
在擁有 22 萬張卡的 Colossus1 集群中，由于硬件基數(shù)過于龐大，幾乎每隔幾個小時，就可能有一張卡降頻、掉線——卡一壞，模型訓練就只有被迫中斷。面對這個棘手的問題，谷歌和 Meta 等科技巨頭的調(diào)度器，能在毫秒級的時間內(nèi)自動換卡和斷點續(xù)訓。SpaceXAI 作為新玩家，其調(diào)度器在如此大規(guī)模集群下的響應速度還不夠快，導致整個集群常常陷入 " 一卡故障，萬卡等待 " 的低效泥潭。
其次，編譯器也還沒完全適配。
編譯器負責把程序員寫的代碼翻譯成 GPU 能執(zhí)行的機器碼。SpaceXAI 早期使用的 XLA 編譯器，是谷歌 JAX 框架下的產(chǎn)物。XLA 本身不差，但它翻譯出來的是通用的機器碼，并不了解任何特定 GPU 集群的物理布局。直接套用在 Colossus1 上，調(diào)度策略和顯存管理都很難發(fā)揮出 GPU 的極限。
這也解釋了為什么馬斯克決定自研基于 C/C++ 底層框架的編譯器——一方面，相比 Python、Java 等高階語言，C 語言更接近硬件層；另一方面，通過自研，打造出一個熟悉自家 GPU 集群物理布局的編譯器，能夠提高軟硬協(xié)同，進而充分 " 榨出 "GPU 的性能。
四、Grok4.5 的新亮點
那么針對上述問題，本次發(fā)布的 Grok 4.5 做了什么改進呢？
一個核心亮點，是采用了混合專家架構(gòu)（MoE）。
在 MoE 架構(gòu)下，處理不同類別數(shù)據(jù)的 " 專家 " 被部署在不同的 GPU 組上：比如 GPU 01-10 存放 " 代碼專家 "，GPU 11-20 存放 " 邏輯專家 "，GPU 21-30 存放 " 數(shù)學專家 " ……
當有數(shù)據(jù)進入時，MoE 會根據(jù)數(shù)據(jù)類型只激活對應的專家，調(diào)度相應的 GPU 組（比如處理代碼任務就只喚醒 01-10），而不需要所有 GPU 同步參與。這就大幅降低了通信同步的壓力，提高了數(shù)據(jù)運算的效率，一定程度上緩解了算力利用率低下的問題。
可以說，老馬為了 " 馴服 " 算力也是十八般武藝用盡。但以調(diào)度器、編譯器等為代表的軟件短板，依然是亟待他和團隊攻破的工程難關。
結(jié)語
把閑置算力租出去，是商業(yè)上的止損邏輯；發(fā)布一個 " 夠用但便宜 " 的新模型，是技術上的務實邏輯。
兩件事都指向同一個真相：算力規(guī)模不等同于算力能力，" 駕馭算力 " 或許遠遠比 " 擁有算力 " 更重要，也更困難。
