NVIDIA Groq 3 LPX 量產：3,431 tokens/s 離公開雲端有多遠？（2026）

2026 年 8 月 24 日，NVIDIA 在 Company Blog 發布〈With Groq 3 LPX in Full Production, NVIDIA Extends Vera Rubin Inference for Agents〉，宣布 NVIDIA Groq 3 LPX 機櫃級推論系統進入全面量產，並把 Gemma 4 31B 在 100K 輸入 Context 下的 3,431 output tokens/s 推到聚光燈下。這是一個很快、也很窄的結果：它證明 LPX 在特定單請求測試中能高速 decode，還不能直接證明公開雲端的多人吞吐、每次任務成本或 Agent 端到端速度。

以下先把「量產」與「可用」拆開，再回到 Artificial Analysis 的測試條件，最後解釋這種速度可能從哪裡來。最重要的判讀是：3,431 是一個值得重視的單請求效能訊號，不是一張已完成的雲端產品成績單。

NVIDIA Groq 3 LPX 量產：先把新聞主詞說準

Announced today, the NVIDIA Vera Rubin rack-scale system NVIDIA Groq 3 LPX is in full production.

中文：NVIDIA 當天宣布，Vera Rubin 機櫃級系統 NVIDIA Groq 3 LPX 已進入全面量產。

NVIDIA Company Blog

這句話的主詞不是一顆「Groq 3 晶片」，而是 LPX rack-scale system。依 NVIDIA 的架構說明，一套 LPX 機櫃可放入 256 顆 LP30 LPU；技術文章列出的合計 on-chip SRAM 是 128GB。用詞看似細微，卻會改變你怎麼理解「量產」：NVIDIA 宣布的是包含加速器、機櫃內互連與軟體排程的完整系統狀態，不只是某顆 silicon tape-out。

但 full production 仍是 NVIDIA 的供應商宣告。它沒有在同一批公開資料中附上 LPX 出貨量、良率、公開雲端 GA 日或可購買的標準 SKU。NVIDIA 在 2026 年 3 月已表示 Vera Rubin 平台的七顆晶片進入全面量產，並預告 Rubin-based products 將於 2026 年下半年由合作夥伴提供；8 月這次消息更精確地把 LPX 機櫃與長 Context 測試搬到前台。兩者不是互相衝突，而是晶片／平台進度、合作夥伴產品窗口與特定 LPX 雲端服務里程碑的不同層級。

Nebius 的第一方文章也支持「採用已宣布、服務仍在前方」這個讀法：它稱自己是第一家採用 NVIDIA Groq 3 LPX 的 AI cloud，卻用 will run 描述 LPX 將在 Token Factory 上運作。合理寫法是「Nebius 計畫導入」，不是「Nebius 已向客戶提供 3,431 tokens/s」。發布、量產、雲端部署與一般可用，是四個不同 gate。

3,431 tokens/s 到底量到什麼？

Median speed across samples with 100K input context length was 3,431 tokens/second.

中文：在 100K 輸入 Context 的樣本中，中位速度為每秒 3,431 tokens。

NVIDIA Developer Technical Blog

這個數字不是 NVIDIA 自己按一下碼表得出。Artificial Analysis（AA）執行了它的 100K Context workload；但受測 endpoint 是 NVIDIA 在自家資料中心架起、經 Google Cloud Private Service Connect 存取的 private pre-release deployment。圖表註腳顯示，LPX 結果取自 50 個依序送出的 client requests、concurrency 1，模型標為 Gemma 4 31B（Reasoning）。

圖中最快的公開比較 endpoint 是 870 output tokens/s，所以 3,431 ÷ 870 = 3.94 倍，NVIDIA 寫成約 4 倍沒有算術問題。問題在比較設計：其他九條是未具名的 shared production serverless endpoints，以 14 日測試的中位數呈現；LPX 則是為測試提供的私有預發布系統。AA 是第三方測試執行者，這增加了測量獨立性，卻沒有把兩邊變成同樣的產品、負載與資源隔離條件。

這次結果可以支持	這次結果還不能支持
Gemma 4 31B 在約 100K 輸入下，50 個依序請求（concurrency 1）的 decode 中位速度達 3,431 output tokens/s	大量使用者同時請求時，仍能為每位使用者維持相同速度
在這張 AA 比較圖中，LPX 是最快公開比較值的約 3.94 倍	LPX 對所有模型、精度、batch、Context 與 provider 都快約 4 倍
NVIDIA 提供的 LPX 預發布系統確實能跑完 AA 的長 Context workload	Nebius 已經上線，或一般開發者現在就能取得相同 endpoint
長 Context 沒有把這次 decode 速度壓到一般 public endpoint 的區間	TTFT、排隊、網路、工具執行、答案品質與完整 Agent 任務也快 4 倍

還有三個很容易漏掉的口徑。第一，AA 的 output speed 是第一個 token 出現後的生成速度；它不包含 time to first token（TTFT），因此不能單獨代表使用者從送出問題到收到完整答案的時間。第二，圖表統一用 o200k_base tokenizer 計數，這方便跨 provider 比較，卻不必然等於 Gemma native 或帳單 token。第三，AA 的 100K workload 約有 100K 輸入，並要求至少 2,000 個 answer tokens；它不是 Gemma 4 31B 的最大 Context 測試。Google 的官方 model card列出 30.7B dense parameters 與最高 256K Context，而這次公開資料沒有完整披露 checkpoint、量化、解碼優化或所有服務參數。

NVIDIA 技術文章另報告同一系統在 10K Context 的 AA 中位速度為 3,382 output tokens/s，與 100K 的 3,431 相近。這是 LPX 長 Context 路線最有意思的訊號：至少在同一系統的 10K／100K AA 量測中，decode speed 沒有隨輸入長度明顯下滑。不過 NVIDIA 自行執行的 SPEED-Bench 4,767 中位數與 P80 5,520 output tokens/s 屬於另一個 workload、另一種證據層級；不能和 AA 的第三方執行結果混成同一個「獨立紀錄」。

為什麼長 Context 還能這麼快？關鍵在可預排的資料流

一般 tensor parallelism 把矩陣計算切到多顆晶片，算完還要把小 tensor 交換、合併。當目標是低 batch、單一使用者超高 interactivity，計算本身已經很短，固定的協調與通訊時間就可能吃掉平行化收益。NVIDIA Groq 3 LPX 的解法不是只堆更多算力，而是把運算單元、SRAM 與機櫃內 C2C link 的動作交給 compiler 事先排到 clock-cycle 級別。

更具體地說，LPX compiler 能以 320-byte vector 為粒度重疊 computation 與 communication：一小片 dot-product 結果準備好便沿 C2C link 送出，不必等整個 matrix operation 完成。這對小 tensor、低 batch 特別重要，因為最後一段等待資料傳完的 communication tail 會變短。圖中的機制是合理的工程解釋，但「因此在所有 production workload 都有相同比例加速」仍需要外部重跑與負載測試才能成立。

LPX 與 Vera Rubin 的分工也不只有一種。NVIDIA 列出三種可能配置：Rubin 做 prefill、交 KV cache 給 LPX 完成 decode；Rubin 保留 attention／KV cache、LPX 執行 FFN；或由 LPX 跑較小 drafter、Rubin 驗證 speculative tokens。發布文為了白話，寫成「Rubin 處理大規模 Context、LPX 加速 decode」；技術上應理解為多種可組合 topology。公開 benchmark 資料沒有說明 3,431 測試是否搭配 Rubin，若有，又採用哪一種 topology。

這會讓多步驟 Agent 快 4 倍嗎？

不一定。若一個工作回合真的要在 100K Context 後連續產生 5,000 tokens，3,431 output tokens/s 對 decode 階段的影響非常大；單純相除約 1.46 秒。可是一個 coding Agent 的 wall time 還包含 prefill／TTFT、排隊、檢索、shell 或 browser 工具、檔案讀寫、模型停下等待 tool result，以及失敗後的重試。當 decode 原本是主要瓶頸，LPX 會帶來巨大體感差；當工具與外部服務佔大頭，tokens/s 再高也會受到 Amdahl’s law 限制。

另一個常被忽略的變數是品質。速度測試回答「同一輸出計數口徑下生成多快」，沒有回答模型是否選對工具、改對程式、通過測試，或為了修正錯誤多繞了幾個 turn。NVIDIA 與 AA 表示測試沒有觀察到 precision／quality loss，但公開資料不足以讓外部讀者重建 exact model artifact、服務設定與逐筆答案。對 Agent 買家來說，真正的分母應該是每個正確完成任務的總時間與總成本。

下一輪應公開的資料	它回答的採購問題
一般可用 endpoint、價格、SLA 與模型清單	開發者何時能買到？每百萬 tokens 與每個完成任務多少錢？
concurrency 1／8／32／更高的 per-user tok/s、TTFT 與 aggregate throughput	單人極速能否轉成多人 production economics？
固定模型、checkpoint、精度、batch、Context 與 endpoint class 的配對測試	4 倍來自硬體，還是服務隔離與設定差異？
帶檢索、工具、重試與品質 gate 的完整 Agent traces	decode 加速最後替真實任務省下多少 wall time？
長時間 soak、尾延遲、錯誤率與功耗	「量產」系統能否穩定支撐商用負載與 TCO？

AlphaLab 判讀：真突破，但還不是雲端產品勝利

我同意 NVIDIA 的核心方向：Agent 會把推論系統推向長 Context、低 batch、低 decode latency，單靠擴大 GPU batch 追求 aggregate throughput，未必能提供互動式體驗。LPX 用 deterministic scheduling、機櫃級 SRAM 與細粒度 C2C overlap 解這個問題，3,431 output tokens/s 也不是投影片上的預估，而是 AA 在 NVIDIA-hosted system 上實際跑出的 scoped result。這足以讓專用 LPU＋GPU 異質推論成為 2026 年最值得追蹤的 infra 路線之一。

我不同意把它直接翻譯成「世界最快公開雲端」或「Agent 快 4 倍」。比較組與 LPX 的 endpoint class 不同，測試是 concurrency 1，output speed 又排除了 TTFT；Nebius 的措辭仍是未來式。更精確的結論是：NVIDIA 已展示一套宣稱進入量產的 LPX 系統，在 100K 長 Context 的單請求 decode 測試中創造了非常高的第三方量測值；市場接下來要驗證的是 availability、負載下的服務曲線，以及 cost per correct task。

如果你是模型服務商，現在可以先做三件事：要求供應商提供與你流量形狀相同的 concurrency curve；用自己的 prompt 長度、輸出長度與品質 gate 做配對測試；把 TTFT、tool time、error retry、功耗與價格放進同一份 TCO。若 LPX 在這些條件下仍保住大部分速度優勢，它就不只是漂亮的 benchmark，而會真正改變即時 coding、多 Agent 協作與長文件推理的產品邊界。