Grok-4-fast最近在降本增效上的表現堪稱一騎絕塵，連有「路由器」傍身的GPT5都給干趴下了。

面對如此驚艷的推理效率，很多人第一反應就是：堆卡式的算力scaling又一次大顯神威了。

實際上，Grok的背后確實有英偉達的影子。

但這次立功的，或許不是老黃的顯卡，而是算法。

沒錯，Grok-4-fast的秘密武器，被和一篇英偉達的算法論文關聯在了一起。

讓LLM快53倍的火箭發動機

正如Grok-4-fast所表現出來的一樣，這篇論文解決了困擾行業已久的推理成本問題。

一味的硬件Scaling只會讓模型廠商賬單上的數字越來越長，用戶耐心也在漫長的推理時間中逐漸被消耗殆盡。

為此，英偉達研究團隊推出了一種全新「混合結構」模型——Jet-Nemotron。

經過一系列全面的基準測試，發現Jet-Nemotron-2B的表現與Qwen3、Qwen2.5、Gemma3和Llama3.2等頂尖開源模型不相上下，還能實現約53倍的速度提升。

例如在MMLU-Pro上，Jet-Nemotron-2B不僅準確率比Qwen3-1.7B-Base更高，就連生成速度也要快上47倍。

此外，Jet-Nemotron-2B即便遇上參數更大的模型也絲毫不虛，它在MMLU和MMLU-Pro上的準確率甚至可以超過DeepSeek-V3-Small和Moonlight（總參數量15B，激活參數量2.2B）。

改變這一切的關鍵，在于一個叫PortNAS的新框架。

不同于以往的方法，PostNAS不是從零開始訓練，而是以一個預訓練的全注意力模型為起點，并凍結其MLP權重，只探索注意力機制的改進。

這樣一來，不僅能讓訓練成本直接降低幾個數量級，還能有更多精力用于全面探索模型結構。

其流程包括四個核心部分：全注意力層放置、選擇最優的線性注意力模塊、設計更優的線性注意力模塊、硬件感知架構搜索。

全注意力層放置

大多數團隊會在模型的所有層里統一使用全注意力，但這會浪費算力資源。

因此，英偉達團隊希望保留少量關鍵的全注意力層，以維持復雜任務的準確性，同時剔除冗余層以提升效率。

PostNAS的做法是：先構建一個同時包含兩種注意力機制的超級網絡，再通過特征蒸餾來訓練子網絡，最后用beam search找到最優的注意力層放置方案。

事實證明，的確并非所有注意力層都重要，不同任務依賴不同層，少量關鍵層即可覆蓋大部分任務需求。

實驗結果顯示，PostNAS優于均勻放置策略——在只使用2層全注意力的情況下，PostNAS的準確率約49%，而均勻放置的準確率約40%。

選擇最優的線性注意力模塊

在確定了全注意力層后，英偉達團隊開始進行注意力模塊搜索，旨在找到目前最優的線性注意力模塊。

論文評估了六種當前最先進的線性注意力模塊，包括RWKV7、RetNet、Mamba2、GLA、DeltaNet和Gated DeltaNet。

這六個之中，Gated DeltaNet的準確率最高，這主要歸功于兩個因素：

1、數據依賴門控機制（Data-Dependent Gating Mechanism）：可以理解成一個路由器。模型會根據輸入的內容，決定是更重視新信息，還是之前的歷史狀態，從而在不同任務里找到平衡。

2、Delta規則（Delta Rule）：不是每次都把記憶里的東西全部覆蓋，而是只更新新變化的部分。這樣能減少不必要的重復存儲，節省內存，同時保持信息的連續性。

更優解：JetBlock

不過，英偉達并不打算止步于Gated DeltaNet，而是設計了一款比它更強的線性注意力模塊——JetBlock。

卷積對線性注意力模塊的準確率至關重要，然而，以往方法大多使用的是靜態卷積核，它們無法根據輸入自動調整特征提取方式。

相比之下，JetBlock使用動態卷積，通過在線性注意力中引入一個卷積核生成器模塊，JetBlock能根據輸入特征動態地產生卷積核。

結果顯示，JetBlock在數學推理和檢索任務上的準確率優于Gated DeltaNet，而且仍然保持了不錯的生成效率。

要是跟表現最差的Mamba2比起來，JetBlock的優勢就更明顯了。

硬件感知架構搜索

在確定了宏觀架構以及選擇了線性注意力模塊之后，英偉達團隊進一步進行了硬件感知架構搜索，用于優化核心超參數（key/value的維度、注意力頭的數量…）。

過去，參數規模通常被作為衡量模型效率的主要指標，用來指導架構設計。

但英偉達團隊認為這種方法并不理想，因為參數量并不能直接反映真實硬件上的效率。

對此，他們改進的方法是：以生成吞吐量作為直接目標來選擇超參數。

英偉達團隊發現，相比起參數量，KV緩存大小才是影響長上下文和長文本生成吞吐量的最關鍵因素。而當KV緩存大小固定時，不同參數規模的模型，其生成吞吐量表現相似。

基于此，英偉達團隊選擇保持KV緩存大小與原始設計一致，然后在key維度、value維度和注意力頭數上進行小規模網格搜索。

實驗證明，優化后的版本在保持吞吐量不變的情況下，參數量增加（1.84億 vs 1.7億），同時數學準確率得到提升（34.8% vs 32.8%）（藍色行代表實驗組，灰色行代表對照組。）

綜上，PortNAS有望為目前的AI行業帶來三點影響。

1、推理階段GPU使用時長減少47倍，這讓LLM能夠以更快的速度完成高質量任務。

2、更小的內存需求，這使得更廉價的硬件部署成為可能。

3、更高吞吐量，意味著模型廠商可在現有基礎設施規模下服務更多用戶。

而且，PostNAS提供低成本、高效率的架構探索方式，適用于任何預訓練Transformer。

所以基本上，任何廠商都可以在不重新訓練模型的情況下嵌入PortNAS，模型的成本可以大幅降低，同時準確率幾乎不會受到影響。

此外，Jet-Nemotron居然還是開源的。

通訊作者Han Cai在Github上表示Jet-Nemotron的代碼和預訓練模型將在法律審查完成后發布。

感興趣的朋友可以查看文末的鏈接～

Grok-4-fast的背后是英偉達？

同時看到Grok-4-fast和Jet-Nemotron二者同樣驚艷且高度相似的表現，很難不讓人懷疑老馬和老黃這一次是不是聯手了。

在Reddit上，有網友推測Grok-4-Fast應該就是基于Jet-Nemotron創造的。

Jet-Nemotron可以在不犧牲模型性能的情況下，大幅減少推理所需的計算量，這與Grok-4-fast所展現出來的能力高度相似。

這一觀點能從數據上得到支撐——從Grok-4-fast的定價來看，其價格下降水平與NVIDIA對這種架構模型的預測相符（論文預計會便宜20倍到50倍）。

更重要的是，如果Jet-Nemotron能夠應用于Grok，那它同樣能被OpenAI、Anthropic、Google等公司部署。

也有網友不同意這種說法，認為Grok此次的降價也許只是一種營銷手段，并不能從中推斷出xAI是否采用了什么新技術。

他們可能只是在燒錢獲取市場份額，我不認為你可以從中推斷出是采用了某種特定架構。

但是，即便Grok-4-fast沒有采用英偉達的技術，這篇論文也是極有價值的，因為Jet-Nemotron同樣可以被用來進一步降低成本。而且，xAI也不太可能在這么短時間研究出來了另一種和Jet-Nemotron一樣效果顯著的技術。

當然，也可能是其他算法上的突破。如果真是這樣，那仍然是極具突破性的，因為Jet-Nemotron也可以被用來進一步降低成本。但說實話，XAI真的又發現了一個能讓價格再下降20倍以上的算法改進的可能性有多大呢？

不過，上述觀點都只是猜測，目前這些說法都未得到xAI驗證…

華人學者的又一力作

Grok-4-fast是否真的采用了這項技術我們不得而知，可以明確的是，在這項突破性研究成果背后，是華人學者的又一次集中發力——論文作者全部為華人。

論文的一作是顧煜賢，他是清華大學計算機科學與技術系交互式人工智能（CoAI）課題組的四年級博士生，師從黃民烈教授。

圖片

顧煜賢致力于提升LLM在整個生命周期中各個環節的效率，包括預訓練、下游適配以及推理階段。

近期，他的工作重點放在LLM的數據策劃策略研究、高效模型架構設計，以及運用知識蒸餾技術(knowledge distillation)進行語言模型壓縮。

此前，他曾在微軟亞洲研究院實習，由董力博士指導。他還曾作為訪問學生赴麻省理工學院HAN實驗室，導師為韓松教授。

論文的通訊作者是Han Cai，他目前是NVIDIA Research的一名研究科學家

圖片

在加入NVIDIA之前，Han Cai麻省理工學院EECS獲得了博士學位，他的本科和碩士均就讀于上海交通大學。

Han Cai的研究重心在于高效的基礎模型（擴散模型、LLM等）、EdgeAI和AutoML，除了Jet-Nemotron，他還參與了不少英偉達的重要項目，包括ProxylessNAS、Once-for-all…

目前，他的論文在Google Scholar上累計被引用超1萬次。

論文：https://arxiv.org/pdf/2508.15884v1
Github：https://github.com/NVlabs/Jet-Nemotron

參考鏈接：
[1]https://pub.towardsai.net/jet-nemotron-nvidias-new-ai-architecture-achieves-53x-speed-improvement-71a5cf2baeeb
[2]https://www.reddit.com/r/singularity/comments/1nmzqj5/there_is_a_very_real_possibility_that_google/
[3]https://t1101675.github.io/
[4]https://han-cai.github.io/