Jalapeño 跑分炸場，GPU 推理路線開始分裂？

Token 成本成為大模型硬件競爭的新座標。作者丨鄭佳美 編輯丨岑 峰 今天，OpenAI 的自研推理芯片 Jalapeño，終於從規格表走到了跑分臺。這次公開的數據很接地氣：Token 吞吐、生成延遲、單位功耗下能跑多少推理。因為大模型上線以後，芯片面對的早就不只是一次訓練任務。ChatGPT 要一直回消息，Reasoning 模型要持續生成長鏈路內容，Agent 還會一輪接一輪調用模型。算力再高，Token 吐得慢、延遲壓不下來、功耗又高，數據中心照樣難受。成績一出來，Reddit 很快就把 Jalapeño 和 NVIDIA Rubin 擺到了一起。

有人認為它已經進入 Rubin 的效率區間，也有人認為測試條件、軟件優化和整個平臺形態沒有對齊，現在還沒法直接分高下。爭論暫時停在這裡，沒有統一答案。更巧的是，Jalapeño 並不是孤例。NVIDIA 正在把 Groq 3 LPU 拉進推理系統，專門處理 Token 生成；Google 也把 TPU 8 拆成偏訓練和偏推理的兩條路線。幾家公司幾乎在同一時間開始重新拆芯片的工作，背後那套硬件邏輯難道真的已經變了嗎？01Jalapeño 在看 Token 怎麼跑OpenAI 公佈的數據裡，Jalapeño 在 GPT-OSS 120B、DeepSeek R1 670B 和 Kimi K2.

5 1T 上，峰值吞吐位置每瓦完成的 AI 工作提高約 1.5～1.9 倍，端到端延遲降低約 1.7～3.6 倍；在交互速度要求較高的區間，性能提升達到約 2.1～4.1 倍。芯片額定功耗是 700W，這批負載中的持續功耗沒有超過 550W。這些數字為什麼圍繞 Token 展開，需要先看一次大模型推理內部發生了什麼。輸入 Prompt 時，模型進入 Prefill。假設一次輸入 8K Token，這些 Token 可以大規模並行計算，模型權重從 HBM 取出來之後，會被很多 Token 重複使用。此時矩陣比較大，計算密度高，矩陣計算單元很容易忙起來。開始生成答案後，模型進入 Decode。

它需要一個 Token 接一個 Token 往外生成，新 Token 又依賴前面的狀態。並行度下降了，模型權重卻依然要讀，Attention 還要不斷訪問此前保存下來的 KV Cache。所以兩段推理看起來使用相同的 Transformer，芯片看到的負載卻差別很大：Prefill 更容易受到計算能力限制，Decode 更容易卡在內存帶寬和數據移動上。OpenAI 在 Jalapeño 的架構說明裡也明確把兩者做了這一區分。用 Roofline 模型可以把這個問題看得更清楚。

芯片能發揮多少性能，大致取決於兩個上限：可達性能 ≈ min（峰值計算能力，內存帶寬 × 算術強度）算術強度說的是，搬運一份數據以後，能拿它做多少計算。訓練和 Prefill 的矩陣足夠大，一次讀取權重能夠服務大量 Token，所以算術強度很高。低 Batch Decode 裡，情況會反過來。假設 Dense 模型有 P 個參數，每個參數平均佔 b Byte，生成一個 Token 涉及約 2P FLOPs 量級的矩陣運算，而讀取一遍權重需要約 P × b Byte，只考慮權重部分，算術強度粗略只有：2 / b FLOPs/Byte。參數量 P 在這個比例裡直接被約掉了。

換句話說，模型從幾百億參數變成幾千億參數，Decode 依然要面對同一類問題：計算陣列可以做得很強，但 HBM 如果沒有及時把權重送過來，新增計算單元就會等數據。Jalapeño 因此沒有隻在矩陣乘上堆資源。OpenAI 強調的是讓模型狀態和 KV Cache 顯式放在合適的位置，儘量保持數據局部性，再通過芯片內部的計算、內存和網絡協同完成不同推理階段。它還刻意維持一種相對均衡的架構，讓同一種加速器既能處理 Prefill，也能處理 Decode，而不需要提前把機器固定分成兩套資源池。這也解釋了 Reddit 上為什麼很難靠一個數字結束 Jalapeño 和 Rubin 的爭論。

一部分討論引用 SemiAnalysis 的比較，認為 Jalapeño 在部分單位成本 Token 指標上已經進入 Rubin 的區間，而且 Jalapeño 這批結果沒有依賴 speculative decoding。另一部分討論則認為，當前公開測試主要是相對規則的負載，Rubin 的軟件優化方式不同，Jalapeño 還處在生產資格驗證和規模部署之前，更復雜的 Agent 型長上下文負載也缺少足夠公開數據。還有人直接把 NVIDIA 的比較對象擴大到了 Rubin GPU 加 Groq 3 LPX，而不再只看 Rubin GPU。現有討論可以搬出來看，但還不足以給兩套系統下一個簡單排名。

02最合適做推理芯片的時代專用推理硬件其實早就存在，變化在於大模型的運行方式。訓練一輪模型雖然昂貴，但它畢竟是一段集中發生的計算過程。模型上線之後，ChatGPT、Claude、代碼助手以及各種 Agent 會持續運行，每次聊天、代碼生成、搜索和工具調用背後，服務器還在不斷生成 Token。推理因此從訓練之後的配套工作，變成了長期佔用電力、服務器和機房容量的負載。Agent 又把這個問題放大了一次。普通聊天裡，幾十毫秒的差異可能只體現為文字快一點出現。Agent 的任務經常是串行的：模型先判斷一步，調用工具，拿到結果後繼續判斷，再進入下一步。單次推理增加的延遲，會一路傳到後面的步驟。

此時 GPU 有一個經典矛盾。想把 GPU 用得更滿，可以增加 Batch。模型權重從 HBM 讀一次，同時給幾十個請求使用，權重複用率提高，矩陣也更大，總 Token 吞吐自然會上升。但在線請求不能無限等著湊 Batch。Batch 越小，單用戶響應越快，權重複用率卻會下降；Batch 越大，整臺機器的吞吐更漂亮，單用戶的 Token 延遲又可能上升。OpenAI、NVIDIA 和 Google 現在展示性能時越來越喜歡畫 Tokens/s/user 與 Tokens/s/watt 之間的 Pareto 曲線，背後就是這組交換關係。長上下文還增加了另一筆成本：KV Cache。

Transformer 在生成新 Token 時，會把此前 Attention 的 Key 和 Value 保存起來，避免每次重新計算全部歷史。上下文越來越長，KV Cache 也跟著增長。Agent 又會不斷積累系統 Prompt、工具返回、網頁、代碼和歷史步驟，這些狀態可能跟著一個 Session 存在很久。於是調度器不能只看“哪顆芯片現在空閒”，還得考慮“這個請求的數據現在在哪”。如果 Prefill 在一組機器完成，Decode 被遷到另一組機器，KV Cache 也可能跟著跨網絡移動。對於長上下文模型，這次搬運本身就會消耗帶寬和時間。到了這裡，推理芯片的價值已經不只來自減少幾次計算。

它開始圍繞一整條數據路徑做優化：權重從哪裡來、KV Cache 留在哪裡、一次 Token 生成需要訪問幾次 HBM、數據需不需要跨芯片，以及計算單元有多少時間處在等待狀態。而 NVIDIA 選擇的辦法，比 Jalapeño 更激進一些——它直接把推理內部拆開了。03GPU 不再包下整段推理Hot Chips 2026 上，NVIDIA 展示了 Groq 3 LPU 在 Vera Rubin 系統裡的位置。邏輯非常清楚：GPU 很適合 Prefill，大矩陣、高並行、較高的權重複用率正好發揮 GPU 的能力；到了低延遲 Decode，NVIDIA 開始讓 Groq 3 LPU 接手大量工作。

ServeTheHome 在現場報道中直接把 LPU 的作用概括為填補 Vera Rubin 在低延遲 Decode 區域的短板。Groq 的芯片設計也幾乎圍繞這件事展開。一套 LPX 機架有 256 顆 LPU，加起來只有 128 GB SRAM，容量和 GPU 機架裡的 HBM 沒法放在一個尺度上比較，但聚合 SRAM 帶寬可以達到 40 PB/s。這個設計看重的就是“近”。HBM 能裝很多模型狀態，卻離計算單元更遠；SRAM 很貴、容量難做大，但數據就在芯片內部，能夠提供極高帶寬和很低的訪問延遲。

Decode 每一步做的計算有限，又頻繁取數據，把數據放得更靠近 ALU，收益會非常直接地反映在下一個 Token 的等待時間上。Groq 還進一步減少了動態硬件控制。LPU 是確定性執行架構，指令調度主要由軟件提前完成。每顆芯片同時充當處理器和路由器，編譯器會一起安排計算資源和網絡資源，甚至省掉了傳統硬件流控和虛擬通道這類機制。代價也很明顯：這種架構沒有 GPU 那麼通用，片上 SRAM 又裝不下完整的大模型狀態。所以 NVIDIA 沒有讓 Groq 3 獨立運行整個模型，而是做了一套更復雜的異構系統。

Prefill 在 GPU 上進行，大部分 Decode 放到 LPU；Decode 裡的 Attention 又可以回到 GPU。GPU 和 LPU 分別維護自己的 KV Cache，兩邊主要交換 draft Tokens，同時通過 micro-batch 把計算和通信重疊起來。由於 LPU 是同步域，而 GPU 和外部 KV Cache 屬於異步系統，NVIDIA 甚至加入 FPGA 作為兩邊的異步橋接。這套結構很能說明 AI 芯片分工已經走到了什麼程度。它拆的已經不只是“訓練芯片”和“推理芯片”，連一次 Decode 裡面的不同部分也可以放到不同架構執行。

不過 NVIDIA 展示的數據也給出了這條路線的邊界：當業務只追求總體吞吐，並且能夠接受較高延遲時，Rubin GPU 依然很有效率；隨著對單用戶 Token 速度要求提高，LPX 才逐漸發揮優勢，而使用更多 LPU 之後，總體吞吐效率也會下降。所以 Groq 3 的出現並不意味著 GPU 被推理淘汰了。它說明另一件事：同一顆 GPU 很難同時佔住高吞吐和極低延遲兩端，讓兩種硬件分別跑自己更擅長的區間，系統反而更容易把性能曲線拉開。Google 則把這道切口放在了更上層。

04訓練和推理，用兩套芯片配方Google 在 TPU 8 這一代同時做了 TPU 8t 和 TPU 8i，t 面向訓練，i 面向推理。這種分法背後的邏輯，直接寫在芯片的內存配置上。Hot Chips 現場展示中，TPU 8t 使用 6 組 HBM，TPU 8i 反而用了 8 組。Google 給出的解釋是，推理每單位計算需要更多 HBM，同時還需要更高比例的 SRAM，因此 8i 把更多資源給了 SRAM、內存容量和帶寬。這個差異很值得琢磨。如果 AI 芯片只是在比矩陣算力，推理版沒有理由把這麼多芯片面積和封裝資源花在內存上。

TPU 8i 這樣設計，說明 Google 看到的瓶頸已經移到了數據供應。訓練時，大 Batch 能夠把權重讀取成本攤到很多 Token 上；Decode 中每次生成的 Token 很少，權重和 KV Cache 卻仍然頻繁訪問。於是每單位 FLOPS 需要配多少 HBM 帶寬，兩類任務的答案並不一樣。Google 甚至把這種差異做到了網絡拓撲。過去 TPU 常用的 3D Torus 更適合訓練，強調的是大規模集群裡的整體吞吐。TPU 8i 支持 BoardFly，網絡路徑更短：BoardFly 的路徑上限為 7 hops，3D Torus 則達到 16 hops。

對訓練來說，幾次額外網絡跳轉之後通常還有很大一塊矩陣計算，通信時間可以被攤薄。Decode 每一步的計算窗口短，幾跳網絡延遲更容易直接落進 Token 間隔裡。MoE 又讓這個問題變得更明顯。MoE 可以讓一個 Token 只激活一部分 Expert，從計算量上看很划算，但 Router 會把 Token 發往不同 Expert。一旦這些 Expert 分佈在不同芯片上，計算減少的同時，All-to-All 通信會增加。因此 TPU 8i 還加入了 Collective Acceleration Engine，把部分 collective 操作放在靠近網絡接口的 I/O Die 上處理。

數據無需先搬進 Compute Die，再經過 HBM 完成操作，可以直接省掉一部分芯片內部數據移動。訓練版 TPU 8t 的資源分配則明顯朝另一邊傾斜。訓練需要大量 FLOPS，也需要巨大的 Scale-Up 域去同步參數和梯度。TPU 8t 的 Superpod 可以擴展到 9600 顆芯片，擁有約 2 PB 共享 HBM 和 121 EFLOPS FP4 聚合計算能力，Google 還為它引入 Virgo 網絡，把更大範圍的訓練連接做成專門體系。Google 在現場還提到了一個很實際的芯片設計問題：dark silicon。芯片面積和功耗預算有限。

如果同一顆芯片同時塞入訓練需要的大量矩陣計算資源，又塞進推理需要的更多 SRAM、HBM 和低延遲網絡，在某一種 workload 運行時，總會有一部分電路長期閒置。既然兩種任務已經需要不同的資源比例，直接做兩顆芯片反而更乾淨。05從 FLOPS 到 Token 經濟學把三條路線放在一起，差異其實很清楚。OpenAI 做 Jalapeño，把芯片專用化到 LLM 推理這一層，但保留 Prefill 和 Decode 在同構硬件上的靈活調度；NVIDIA 往下繼續拆，讓 GPU 和 Groq LPU 分擔一次推理裡的不同階段；Google 往上切，把訓練和推理直接做成兩顆 TPU。

這幾條路線背後並沒有神秘的新計算原理，改變的是資源比例。訓練希望把更多晶體管投入矩陣計算和大規模互聯，因為高 Batch 能把數據搬運成本攤開；低延遲推理需要更高的 HBM 帶寬、更大的 SRAM、更好的 KV Cache 局部性和更短的網絡路徑，因為很多時間花在等待數據上。當兩類負載需要的“芯片配方”越拉越開，用一顆通用芯片同時照顧它們，效率損失自然會越來越明顯。這也是為什麼這輪硬件競爭裡的核心數字正在變化。FLOPS 依然重要，但旁邊開始出現 Tokens/s/user、TBT、TTFT、Tokens/kW、HBM 帶寬以及網絡延遲。

它們描述的其實是同一件事：算力已經放在那裡了，系統能不能持續把數據喂進去，並把生成的 Token 儘快送出來。OpenAI、NVIDIA 和 Google 現在選擇的分界線還不一樣，後面真正會繼續變化的，很可能也是這條線應該畫在哪裡。訓練和推理可以拆，Prefill 和 Decode 可以拆，Decode 內部的 Attention 與其他計算也可以繼續拆。拆得越細，單項效率越容易提高，但資源調度、KV Cache 搬運和跨硬件通信也會變得更復雜。因此下一階段 AI 芯片競爭的難題，或許已經不只是造出一顆更強的芯片。

更難的是決定：哪些任務值得專門做一顆芯片，哪些任務繼續放在同一套硬件裡，整套系統的 Token 成本才更低。參考鏈接：https://openai.com/index/jalapeno-first-results/上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。