Groq LPU 是什麼？與英偉達 GPU 差異、200 億美元合作解析

重點摘要

• Groq 創辦人兼 CEO Jonathan Ross 於 2026 年 6 月 12 日公開說明推理鏈分工：預填充（prefill）交給 GPU，解碼（decode）依成本與速度需求混搭 GPU 或 LPU（語言處理單元）。
• LPU 批次大小約 10 即可達到經濟運作點，GPU 需要數百量級才能攤薄 DRAM 讀取成本，LPU 因此在混合專家（MoE）模型的解碼段具有結構性優勢。
• Ross 援引傑文斯悖論（Jevons Paradox）指出，算力單位成本下降會催生更多需求而非壓縮市場，智能體架構中「AI 呼叫 AI」的多層嵌套使算力消耗指數擴張，GPU 與 LPU 市場本質上共同成長。

Groq 創辦人兼 CEO Jonathan Ross 在 2026 年 6 月 12 日的公開訪談中，系統性地說明了 Groq 與英偉達（NVIDIA）200 億美元合作協議的工程邏輯：兩家公司的晶片在大型語言模型（LLM）推理鏈中承擔不同任務，協同部署的效益高於任何一方單獨使用。Ross 把 GPU 比作「18 輪重型卡車」，LPU 比作「最後一公里配送貨車」，核心主張是一條可操作的工程分工線。這份架構觀點來自 Groq 創辦人本人的陳述，目前缺乏獨立第三方 benchmark 佐證，讀者宜將其定性為路線觀察。

推理鏈為什麼可以切成兩段？

LLM 推理在技術上分成兩個性質截然不同的階段。預填充階段負責讀取輸入文字，高度可並行化，對單一 Token 的延遲不敏感，GPU 的大量平行運算核心是主場。Ross 明確建議這段完全跑在 GPU 上。解碼階段則是逐 Token 生成輸出，批次小、延遲要求高，GPU 的記憶體頻寬在這裡開始成為瓶頸。

正因為兩段計算特性差異如此大，Ross 描述的配置梯度才有意義：成本敏感型場景全程 GPU 解碼；付費專業使用者採 GPU 加 LPU 混合；極端低延遲場景考慮純 LPU 解碼。這個分法把「選哪顆晶片」的問題，轉換成「每個工作負載的延遲預算是多少，然後找對應的組合」。部署工程師拿這個框架比廠商規格表更實用：先量工作負載特性，再選架構。

LPU 在 MoE 模型上的結構性優勢從哪裡來？

Groq LPU 的兩項核心設計，讓它在解碼段走出不同路線。

第一是全片上 SRAM（on-chip SRAM）。GPU 從外部 DRAM 讀取權重時，需要數百量級的批次大小才能攤薄記憶體頻寬成本。LPU 的權重存在晶片上的 SRAM，批次大小約 10 就能達到經濟運作點，差距接近兩個數量級。混合專家模型（Mixture of Experts，MoE）每個 Token 只激活少數幾個「專家」子網路，天然是小批次場景，GPU 在 DRAM 讀取效率上天然吃虧。Ross 進一步指出，LPU「幾乎是為專家模型量身定制的」，而 MoE 目前正是主流大型模型的架構選擇。

第二是靜態調度（static scheduling）。Groq 的運算順序在編譯期就確定，不在執行期動態分配，讓每段計算能迅速完成並及時釋放硬體資源。Ross 把這比作短會必須精確預約，因為延誤會卡住下一場，推理場景的計算正是這種「多個短會」的性質。這裡有個常見誤解值得澄清：靜態調度並不代表 LPU 無法處理 MoE 的動態路由。Ross 說明，LPU 的時間段是固定的，但「激活哪個專家」可以透過散射聚集（scatter-gather）機制在運行時決定，時間槽固定、路由可變，兩者並不衝突。

為什麼 GPU 與 LPU 的市場是共同擴張而非競爭？

更長期的問題是：如果 LPU 讓推理更便宜，它是否會蠶食 GPU 市場？Ross 援引傑文斯悖論（Jevons Paradox）給出反直覺的答案。

傑文斯悖論最初來自 19 世紀一本關於煤炭的論著：蒸汽機效率每提升一次，整體煤炭消耗不減反增，因為使用成本降低後，原本不划算的場景開始可行，催生全新需求。Ross 的判斷是，AI 算力遵循同一邏輯：單位成本下降後，更多原本跑不起來的應用開始跑，市場邊界因此擴大。

智能體（Agentic AI）架構進一步放大這個效應。任務拆解成並行子任務、多個 Agent 同時推進、AI 呼叫 AI 再呼叫 AI 的多層嵌套，算力消耗因此從線性變成指數擴張。Ross 用「成功災難」（success disaster）描述這個結果：Groq 和英偉達提供的算力越多，市場想要的越多，供給本身在創造需求。這個框架也給 200 億美元合作一個更清晰的解釋，兩家公司在帕累托曲線（Pareto frontier）上各佔一個效率角，合用才能在任意目標速度下最小化每 Token 成本。

混合部署對推理基礎設施設計有什麼含義？

對正在規劃推理基礎設施的工程師，Ross 的框架帶來幾個可以立即對照的工作假設。

MoE 解碼段是否值得評估 LPU 方案，關鍵在批次大小分布。若線上服務的請求天然是小批次（即時聊天、低延遲 API），LPU 的 SRAM 優勢理論上可以直接轉換成成本或速度收益；若是大批次離線推理，Ross 自己也說全 GPU 是最低每 Token 成本的選項。先量自己的 batch size 分布，比換晶片更重要。

靜態調度限制了動態工作負載的彈性。Groq 的模型需要在編譯期固定計算圖，對需要熱切換 LoRA、動態調整上下文長度等實驗性場景的適配程度，訪談中並未提供具體數據，是評估前需要獨立驗證的項目。

容量規劃上，Agentic 工作負載會讓消耗從線性變指數，按目前請求量做的規劃在 Agent 流量起量後可能很快失效，預留的緩衝倍數需要遠大於線性外推的直覺值。

GPU 加 LPU 的帕累托邊界論，目前是 Ross 本人的路線觀察，缺乏 Groq 以外的獨立數據支撐。但它提供的思考工具比「誰更快」的規格比拼更實用：推理鏈的兩段計算特性本就不同，混合部署的成本最佳解值得認真評估，別等廠商把答案包好再端上來。