輝達,築起新高牆

日前,輝達一下子解密了六顆晶片,引起了全球轟動。但其實早在去年年底,就有一則重磅消息在AI晶片圈炸響:推理晶片初創公司 Groq 宣佈,已與輝達達成一項“非獨家許可協議”。公告只有寥寥數語,但隨之而來的資訊卻迅速改變了這筆交易的份量——Groq 創始人兼 CEO Jonathan Ross、總裁 Sunny Madra 以及多名核心成員,將一併加入輝達,參與授權技術的推進與規模化。

如果只看形式,這並不是一次收購;如果只看結果,它卻幾乎具備了收購的全部要素。技術被許可,團隊被吸納,關鍵人物離場,Groq 雖然名義上繼續營運,但其最具決定性的資產——技術路線與靈魂人物——已然轉移。這是一種典型的“收購式招聘”,也是輝達近年來愈發嫻熟的一種操作方式:在不觸碰監管紅線的前提下,把潛在威脅納入自己的體系之中。

更重要的是,這一步發生在一個極其敏感的時間點。AI 晶片的競爭,正在從“訓練為王”轉向“推理決勝”。輝達的 GPU 依舊牢牢統治著訓練市場,但在推理端,AMD、定製 ASIC、雲廠商自研晶片正在快速逼近,成本與供應鏈多元化成為大客戶最現實的訴求。Groq 的 LPU 正是為推理而生,主打極致低延遲和性能確定性,其創始人 Jonathan Ross 更被視為Google TPU 背後的關鍵推手——這不是一家可以被忽視的公司。

因此,與其說輝達“買”下了 Groq,不如說它在競爭真正白熱化之前,提前拆掉了一段可能威脅自身根基的城梯。回看歷史,從 Mellanox 到未遂的 Arm,再到今天的 Groq,輝達並非只是在擴張版圖,而是在一磚一瓦地加高自己的防禦體系。輝達在乎的,似乎已不再是某一筆交易的得失,而是如何在訓練、推理、網路、軟體與生態的多條戰線上,同時構築起一道幾乎無法繞開的“城牆”。

算力,並不是焦慮根源

輝達與 Groq 達成交易,這件事本身的重要性,並不在於它是否會推出一款“非 GPU 的 AI 晶片”,而在於它暴露了輝達真正的焦慮來源。今天的輝達,幾乎已經在訓練算力層面取得了事實上的統治地位,但 AI 產業的重心正在悄然移動——從“誰能堆更多 FLOPS”,轉向“誰能更高效、更確定性地交付推理結果”。

Groq 的價值並不在算力規模,而在系統哲學。它強調確定性延遲、強調編譯器對執行路徑的絕對控制、強調“推理不是硬體問題,而是系統問題”。這套思路,與 GPU 世界中長期存在的動態調度、非確定性執行形成鮮明對比。

Groq 的創始人 Jonathan Ross 是 Google 第一代 TPU 的首席架構師。他在 2016 年離開 Google 後,試圖打造一個比 TPU 更快、更可控的“通用 AI 處理器”。Groq 的核心技術是自研的 LPU(Language Processing Unit)架構,這種架構拋棄了傳統的亂序執行和動態調度機制,採用靜態調度、資料路徑固定、執行流程可預測的“確定性設計”(deterministic design)。晶片內部採用 SRAM 技術,而非輝達 GPU 依賴的片外 HBM 視訊記憶體,這讓 Groq 在某些場景下實現了極致的低延遲。

Groq 最初也曾試圖進入訓練市場,但很快發現這是一條死路:訓練市場的競爭邏輯是“大生態+大資本+大客戶”。Groq 的架構對主流 AI 框架(如 PyTorch、TensorFlow)的相容性有限,也缺乏成熟的編譯工具鏈,使得訓練任務的遷移成本極高。

從 2023 年下半年開始,Groq 明確轉向推理即服務(Inference-as-a-Service)方向。2024 年,Groq 展示了其系統運行 Llama 2-70B 模型時,實現每秒超過 300 個 Token 的生成速度,遠超主流 GPU 系統。這一優勢讓 Groq 迅速吸引到一批對延遲敏感的垂直行業使用者,如金融交易系統、軍事資訊處理、語音/視訊同步字幕生成。Groq 將產品定位從“AI 晶片”擴展為“AI 處理平台”,通過 GroqCloud 平台向開發者提供 API 存取權,與 LangChain、LlamaIndex 等生態整合。

正是這種“異類”,恰恰點中了輝達的軟肋。隨著大模型進入規模化落地階段,越來越多客戶開始關心延遲、能效、TCO 和系統複雜度,而不再只是顯示卡型號。推理正在走向碎片化:雲廠商自研 ASIC(AWS 的 Trainium 和 Inferentia、Google TPU、Microsoft Maia)、CPU+加速器混合部署、邊緣側異構系統層出不窮。如果輝達只停留在“賣最強 GPU”,它在推理端的話語權,遲早會被系統層慢慢侵蝕。

對於輝達和黃仁勳而言,Groq 的意義並不是“補一塊晶片”,而是補一塊輝達尚未完全掌控的系統能力:對執行路徑的強約束、對延遲的可預測性、以及編譯器主導的算力使用方式。換句話說,如果說 GPU 是輝達的地基,那麼 Groq 代表的,是它試圖插入系統頂層的一根“控制梁”。

對“叢集控制權”的長期執念

而在與Groq達成交易之前,輝達其實早已悄然埋下了一條新的主線。

很多人習慣從作業系統的角度理解算力生態,認為誰控制了 Linux 發行版、誰控制了核心,誰就掌握了計算世界的話語權。但在 AI 時代,這種邏輯已經開始失效。輝達對此看得非常清楚:真正重要的,不是節點上的作業系統,而是節點之上的叢集控制方式。

這正是輝達在 2022 年 1 月收購 Bright Computing 的根本原因。當時這筆交易的金額未公開,但 Bright Computing 已完成兩輪融資,共籌集 1650 萬美元,其叢集管理工具 BCM 在全球擁有超過 700 家使用者。Bright Cluster Manager 並不是一個時髦的新工具,它誕生於傳統 HPC 世界,最初用於管理高度複雜、對穩定性和可預測性要求極高的超級計算系統。正因為如此,它並不追逐某一種特定技術潮流,而是長期圍繞“如何在大規模叢集中統一部署、監控、修復和調度”這個核心問題演進。

BCM 最初是為管理傳統高性能計算(HPC)系統而設計的,但多年來,為了將其打造成為一款通用叢集控製器,BCM 也進行了適配,以支援 Hadoop、Spark、OpenStack、Kubernetes 和 VMware ESX 等對控制要求極高的分佈式系統。

在被輝達收購併更名為 Base Command Manager 之後,這套工具被完整納入 AI Enterprise 軟體堆疊,成為輝達 AI 系統的“底層控制平面”。通過許可證模式,輝達不再只是交付硬體,而是開始按 GPU、按年份出售“系統能力”——AI Enterprise 許可證包含輝達捆綁並支援在其 GPU 加速系統上的庫、框架和其他工具,每個 GPU 每年的費用為 4500 美元。

這一步的意義極其關鍵:它意味著輝達正式把“叢集管理”變成了自己的商業資產,而不是留給客戶或第三方去解決。

輝達還設定了一個精妙的商業策略:對於每個節點包含 8 個 GPU 以內的叢集,提供免費的 BCM 許可證,但不提供任何技術支援,且“隨時可能被撤銷”。這意味著企業如果想要穩定的生產環境,就必須購買 AI Enterprise 許可證。免費版本不是慷慨,而是一種“試用即繫結”的策略。

更重要的是,Base Command Manager 並不是孤立存在的。在其之上,輝達疊加了 Mission Control,用於自動部署所謂的“AI 工廠”:框架、工具、模型、容器運行環境、健康檢查和功耗最佳化一體化。Mission Control 包含 Run:ai 實現的 Kubernetes,用於編排容器;還包含 Docker,用於在容器內運行計算;此外,它還可以虛擬化 GPU,以提供更精細的計算粒度。Mission Control 會對系統進行健康檢查,並根據系統上運行的工作負載最佳化功耗。

這套體系的目標並不是讓客戶擁有更多選擇,而是讓客戶在默認情況下就運行在輝達定義的最優路徑上。

當然,這裡繞不開輝達在2024年對Run.ai的收購,Run.ai的核心價值不是又一個Kubernetes外掛,而是實現了GPU資源的抽象化管理:多租戶、彈性調度、優先順序控制、GPU虛擬化。在Run.ai的系統中,一個物理GPU可以被切分成多個虛擬實例,讓不同使用者、不同任務按需使用,同時保證隔離性和性能。

為什麼輝達提前拿下了 Run:ai?因為調度權如果不在自己手裡,CUDA 生態的優勢就會被“平台化”稀釋。雲廠商可以通過調度層,讓客戶感知不到底層是誰的 GPU,甚至可以在調度中插入自研晶片作為替代選項。

但就高性能計算(HPC)和人工智慧(AI)工作負載的裸機工作負載管理而言,輝達仍然需要一款工具。事實證明,BCM 正是執行這些健康檢查的工具,而解決問題的操作則通過 Slurm 工作負載管理器完成。

輝達並沒有強行要求所有客戶拋棄既有體系,而是非常務實地接受了一個現實:在大量從 HPC 演進而來的 AI 叢集中,Slurm 依然是事實標準。許多高性能計算和人工智慧機構不想學習新東西——比如 Run:ai——而是想繼續使用 Slurm。對於那些最初以高性能計算中心起家的混合型人工智慧/高性能計算中心來說,這種情況可能尤為突出。

這就為下一步的關鍵收購埋下了伏筆。

開源不是放棄控制

2025 年 12 月,輝達補上了這道牆的最後一塊磚:收購了 SchedMD,獲得了 Slurm 工作負載管理器背後的核心團隊和技術支援權。

Slurm 項目始於 2001 年,由勞倫斯·利弗莫爾國家實驗室、Linux Network(已被 SGI 收購)、惠普以及 Groupe Bull(已被 Atos 收購併成立 Eviden)合作開發。據稱,Slurm 的設計靈感來源於超級電腦互連裝置製造商 Quadrics 開發的 RMS 叢集檔案總管。2010 年,該項目的兩位創始人 Morris Jette 和 Danny Auble 創立了 SchedMD,旨在為 Slurm 提供技術支援,從而為工作負載管理器的進一步開發提供資金。

Slurm 最重要的優勢在於,過去十年中,在 Top500 超級電腦排行榜上出現的電腦中,約有 60% 使用 Slurm 作為其工作負載管理器,而不是 IBM/Platform Computing 的負載共享工具(LSF)、Altair 的可攜式批處理系統(PBS)、Adaptive Computing 的 Maui 和 Moab 以及 Sun/Univa Grid Engine。所有這些工作負載管理器/作業調度器都會將一組具有特定計算能力需求的工作負載進行“俄羅斯方塊”式的調度,最終使它們按照既定的優先順序順序高效運行。

Slurm 過去十多年裡成為超級計算領域的事實標準,並不是因為它最激進,而是因為它足夠穩定、足夠中立,也足夠適配不斷變化的硬體環境。SchedMD 已向全球數百家 HPC 中心、雲建構商、超大規模資料中心和企業銷售了 Slurm 工作負載管理器的支援服務。過去十年,輝達和 SchedMD 一直在合作開發 Slurm。

在輝達收購 Bright Computing 之前,BCM 支援不同的工作負載管理器,但隨著 Slurm 逐漸成為高性能計算中心乃至人工智慧領域工作負載管理的實際標準,它被選為 Bright Cluster Manager 的默認工作負載管理器,並在過去幾年中一直是輝達 Base Command Manager 的默認工作負載管理器。

對輝達而言,真正危險的並不是 Slurm 開源,而是如果 Slurm 的演進方向、支援能力和企業級整合權掌握在自己控制之外,那麼整個 Base Command Manager 和 Mission Control 體系,都會留下一個無法掌控的“底座”。

通過收購 SchedMD,輝達並沒有否定 Slurm 的開源屬性,反而在公開表態中反覆強調其“廠商中立性”。輝達表示,它將“繼續開發和分發 Slurm,使其成為開源、廠商中立的軟體,使其在各種硬體和軟體環境下都能被更廣泛的 HPC 和 AI 社區廣泛使用和支援”。

但需要看清的是:開源並不等於沒有權力結構。誰來維護主幹程式碼、誰來提供企業級支援、誰來決定新特性的優先順序,這些問題,比許可證本身重要得多。

輝達已同意為 SchedMD 的現有客戶提供支援,據推測,他們將通過聘用 SchedMD 的員工來實現這一點。但即便 Slurm 開源,也不意味著輝達會為開源版本的程式碼提供支援,或者將 Slurm 的所有未來功能都開源。輝達擁有大量專有驅動程式、框架和演算法,這個模式很可能會延續到 Slurm 身上。

輝達顯然希望做到兩點:一方面,保持 Slurm 在 CPU、非輝達加速器等環境中的廣泛適用性,避免引發社區反彈;另一方面,把 Slurm 的商業支援、系統整合和 AI 方向演進,與自己的 AI Enterprise 體系深度繫結。這是一種極其典型的“高階控制”:不通過封閉程式碼來壟斷,而通過系統複雜度和服務整合來設立門檻。

目前尚不清楚的是,Run:ai 和 Slurm 的功能將如何與 Base Command Manager 整合,從而為高性能計算(HPC)和人工智慧(AI)叢集提供一個自上而下的叢集和工作負載管理工具——而且不僅限於 AI 叢集,還要考慮到許多叢集中可能存在一些僅使用 CPU 的機器以及非輝達加速器。

如果輝達試圖以任何方式限制它,其他人可以獲取 Slurm 程式碼(該程式碼以 GNU GPL v2.0 許可證提供),進行 fork 並繼續開發。但現實是,fork 程式碼容易,建立支援能力難。當所有人都在用同一套開源工具,但只有輝達能提供最優的整合方案時,開源本身就成了輝達生態的擴展。

2024 年 10 月,輝達停止單獨銷售 Bright Cluster Manager,而僅將其作為 AI Enterprise Stack 的一部分提供。目前尚不清楚 AI Enterprise 的價格是高於還是低於之前單獨購買 Bright Cluster Manager 的許可,也不清楚有多少客戶曾在純 CPU 系統或其他類型的加速器上使用過這款早期工具。但這個動作的訊號意義很明確:輝達正在把所有系統元件打包成一個不可分割的整體。

也正是在這裡,Run:ai、Slurm 和 Base Command Manager 的關係變得微妙而關鍵。前者代表雲原生和容器化世界,後者代表 HPC 傳統,而輝達的目標,是讓這兩套體系在自己的框架內完成融合,而不是彼此競爭。

新的城牆,已經成型

把Groq、Bright Computing、Run:ai 和 SchedMD 放在同一條時間線上看,輝達近幾年的收購邏輯就變得異常清晰:它正在系統性地收回 AI 計算體系中的“非硬體控制權”。

GPU 仍然是輝達最鋒利的武器,但已經不再是唯一的壁壘。真正的新城牆,建立在三個層面之上:

第一層:對叢集資源的調度權。從 Mellanox 的網路互聯技術,到 Bright Computing 的叢集管理,再到 SchedMD 的工作負載調度,輝達控制了算力如何連接、如何分配、如何排隊執行的完整鏈條。這不是簡單的硬體整合,而是把網路從“外設”變成了“AI 系統的一部分”。

第二層:對工作負載執行路徑的定義權。Run:ai 提供的 GPU 虛擬化和資源抽象,Mission Control 提供的自動化部署和健康檢查,Slurm 提供的作業調度——這些工具共同定義了“任務應該怎麼跑、跑在那裡、用多少資源”。當執行路徑被輝達定義時,即使客戶理論上可以使用其他硬體,在實踐中也會發現遷移成本高得難以承受。

第三層:對企業級支援與系統複雜度的掌控權。輝達通過 AI Enterprise 許可證模式,把所有這些工具打包成一個商業服務。客戶購買的不是單個元件,而是一整套“系統整合能力”。開放原始碼可以 fork,但企業級支援、最佳化經驗、最佳實踐,都掌握在輝達手中。

一旦這三層疊加完成,客戶即便理論上“可以選擇別的硬體”,在實踐中也會發現遷移成本高得難以承受。

從賣晶片到賣生態,輝達的商業模式已經發生質變。過去的輝達,GPU 是產品,賣出去就完成了交易。現在的輝達,GPU 是生態入口,是使用者進入輝達系統的第一步。收購的真實邏輯不是規模併購,而是精準補洞:在 AI 計算的完整鏈條中,那一環還沒有被控制?

這也是為什麼說,輝達正在建構的已經不是傳統意義上的護城河,而是一座生態城牆。它不靠封鎖入口,而是通過系統整合,讓離開變得不再理性。在 AI 進入基礎設施階段之後,這種能力,或許比任何一代 GPU,都更加持久。

從 Groq 到 SchedMD,從推理架構到工作負載管理,從硬體到系統,輝達用幾年時間完成了一次商業史上罕見的“生態圍城”。這座城牆的高度,已經不是用技術指標可以衡量的,而是用遷移成本、學習曲線、生態粘性來定義的。

當所有人還在討論“誰能挑戰輝達的 GPU”時,輝達已經在思考:如何讓“挑戰”這件事本身變得不再可能。 (半導體行業觀察)