權重放哪裡，決定 AI 晶片擅長什麼

你把一個 700 億參數（70B）的模型放上一張 NVIDIA B200，只有你一個人在用，回答一個字一個字冒出來。本站推算，這張卡每秒最多約 55 個 token：FP16 的權重 140 GB，每吐一個 token 讀一遍，沒計入 KV cache（模型記住前文的暫存）。在這個條件下，卡住速度的是記憶體頻寬。GPU、TPU、Cerebras、Groq 給了四種答案。

快速回答 四種晶片的差別，主要在權重放在哪：GPU 與 TPU 放在晶片外的 HBM（高頻寬記憶體），Cerebras 放在整片晶圓上的 SRAM（靜態記憶體），Groq 放在每顆晶片內的 SRAM；以第一代 Groq LPU 部署 70B FP16 模型為例，約需 576 顆。單人逐字生成時，每個 token 都要把 140 GB（70B、FP16）的權重讀一遍，所以權重所在記憶體的頻寬決定速度上限；同時服務很多人時，HBM 的大容量與批次處理更划算。產品賣點是單人互動速度時，才值得為 SRAM 的速度付出容量與搬遷成本；批次離線工作仍以 HBM 的容量與成熟軟體較省事。

四條結論的依據，依序在後面各節。

四種晶片放進同一張表：權重放哪裡、擅長什麼、代價是什麼

GPU 與 TPU 放晶片外的 HBM，Cerebras 與 Groq 放晶片上的 SRAM。

「擅長」與「代價」兩欄是本站依後面各節的來源歸納的。Jacob Peake 是在個人網站 jacobpeake.com 發表長文《AI Chip Architectures》的作者，頁面沒有附簡介，也沒有標發表日；內文提到 GTC 2026，本文於 2026 年 10 月 23 日查閱。

解碼為什麼先卡在記憶體頻寬？

解碼（decode，一個 token 接一個 token 產生的階段）通常卡在記憶體頻寬，因為每個 token 都要把全部權重讀過一遍，而每讀 1 byte 能做的運算很少。

NVIDIA 的《GPU Performance Background User's Guide》把這個比值叫算術強度（arithmetic intensity，演算法的運算數除以讀寫的 byte 數）。晶片也有自己的比值，叫 ops:byte ratio，是它的算力除以記憶體頻寬。演算法的算術強度高於晶片的比值，就是算力受限；低於，就是記憶體受限。文件以 V100 為例：晶片每提供 1 byte 的記憶體頻寬，約對應 40 到 139 次運算（ops:byte）。同一個 FP16 線性層有 4096 個輸出、1024 個輸入：批次 512 時，每讀寫 1 byte 約做 315 次運算（315 FLOPS/B），通常受算力限制；批次 1 時約做 1 次，通常受記憶體限制。這是 V100 的例子，文件沒有給 B200 的對應數字。

Jacob Peake 的文章從歷史講起：以圖靈獎研究聞名的 John Hennessy 與 David Patterson 指出，單執行緒 CPU 效能在 1980 年代每年成長 52%，到 2018 年只剩約 3%；Google 的第一代 TPU 在神經網路推論上，吞吐量是 CPU 的 29 倍、能源效率是 80 倍。他對解碼的描述更直接：解碼時算術強度比預填（prefill，一次處理整段輸入）低了好幾個數量級（"orders of magnitude"）。四種晶片的設計，都在回答同一件事：怎麼讓權重離計算單元近一點，或讓讀進來的權重多用幾次。

GPU：用批次把頻寬用滿

GPU 靠同時服務很多使用者，把一批 token 合成一次矩陣乘法，讓每次讀進來的權重用上很多次。

Peake 寫的是 GPU 的賭注：延遲不可預測、依資料而變，所以用大量執行緒同時駐留來藏延遲，一個等資料時換另一個上場；SM（串流多處理器）是 GPU 裡執行運算的單元，每個 SM 最多可容納 64 組一起執行指令的執行緒，稱為 warp，由排程器每個週期挑一組準備好的。B200 共有 148 個 SM。對解碼的問題，他寫道："Inference systems recover some of that intensity by batching tokens to promote those GEMVs back to GEMMs."（推論系統靠批次湊回一部分強度，把矩陣乘向量變回矩陣乘矩陣。）他列的手法有連續批次（continuous batching）、推測解碼（speculative decoding）與多 token 預測。

B200 的數字有兩個版本。Peake 寫每顆 192 GB、8 TB/s；NVIDIA 的 HGX B200 資料表寫八顆 B200 各有 180 GB 的 HBM3E，整板記憶體最高 1.4 TB、總頻寬最高 62 TB/s。兩者差異的原因，文件沒有說明。本文表格與試算用 NVIDIA 的版本，每顆平均約 7.75 TB/s（本站把 62 TB/s 除以 8）。

規模上，Peake 記錄 NVL72 機櫃有 72 顆 GPU、13.5 TB 的 HBM，顆與顆之間約 130 TB/s 的全互連頻寬。他也指出批次有邊界：每個使用者的請求仍要讀自己的 KV cache，上下文很長時，解碼會從受權重頻寬限制，變成受 KV 頻寬限制。

工程上的意思。 在 GPU 上，同一張卡的單人速度與整體吞吐是兩個數字，服務端靠批次拉高後者，單人速度的上限仍由 HBM 頻寬決定。

TPU：編譯器排程，權重留在陣列裡

TPU 用編譯器取代硬體排程器，並把權重預載進脈動陣列（systolic array，資料在規則排列的運算單元間流動的矩陣乘法電路），讓每個權重在陣列裡重複使用。

Peake 說 TPU 沒有 warp 排程器、快取、亂序執行引擎與分支預測器，省下的面積拿去放更多乘加單元（MAC）；他的一句話是 "the compiler is the scheduler"（編譯器就是排程器）。這種做法叫 weight-stationary，也就是讓權重固定留在陣列裡：矩陣 B 的值先載入陣列，每格放一個權重；處理中的資料（激活值）流過陣列，計算的中間結果（部分和）再送進累加佇列繼續相加。這樣避開反覆讀寫記憶體的能量成本。代價也寫得明白：128×128 的矩陣乘法放上 256×256 的陣列，會浪費 75% 的矽面積，所以 XLA 編譯器要做填補與切塊。

Google Cloud 的 TPU7x（Ironwood）文件列出每顆 192 GiB HBM、7,380 GBps 頻寬、FP8 峰值 4,614 TFLOPs，每個 pod 9,216 顆；該頁面標示最後更新於 2026-10-22。Google 在 2026 年 4 月的 Cloud Next 發表第八代 TPU：推論用的 TPU 8i 每顆 288 GB HBM，加上 384 MB 的片上 SRAM，為前一代的三倍。Google 說這個 SRAM 的容量依推理模型在正式環境的 KV cache 大小設計，希望讓模型當下運算會用到的資料留在晶片上。第八代有訓練用的 TPU 8t 與推論用的 TPU 8i 兩款，Google 表示預計 2026 年稍後正式提供（Google 自己的說法，未經第三方驗證）。換句話說，主打 HBM 的 TPU，也在往片上 SRAM 加碼。

Cerebras：整個模型放進晶圓上的 SRAM

權重放在整片晶圓的 SRAM，不用 HBM。

Peake 記錄 WSE-3 有 900,000 個核心、46,225 mm² 的面積、44 GB 的晶圓上 SRAM，分成每核心 48 kB 的小塊，晶圓上沒有別的記憶體；整體 SRAM 頻寬約 21 PB/s。他的結論是這片晶圓從頭到尾是一台頻寬機器（"The wafer was never a FLOPs machine."）。他引用 Artificial Analysis 在產品發表時的實測：Llama 3.1 8B 為 1,850 tokens/s，70B 為 446，405B 為 969。他也指出，Cerebras 從未公布任何一次執行的算力使用率，批次大小也沒有公開。

容量是這條路的邊界。70B 的 FP16 權重放不進 44 GB，Peake 估計最少要四台 CS-3；他也寫到，規格表上最多可接 2,048 台 CS-3，公開過的最大叢集是 64 台。2026 年 10 月 22 日，Cerebras 在自家部落格說明怎麼部署約 3 兆參數的 Kimi K3，文中稱這代晶圓為 WSE-3T，每片同樣是 44 GB SRAM：權重 4-bit、KV cache 8-bit、平均請求 256k；每層權重約 16 GB；稠密層要存每個請求的 KV cache，一層占一片晶圓，剩下的 SRAM 留給 KV cache；線性注意力層每個請求只留小而固定的狀態，不必另留 KV 空間，兩層（2 × 16 GB）共用一片。24 個稠密層用 24 片，69 個線性層兩層一片、進位成 35 片，共 59 片晶圓。晶圓之間只傳激活值，走 RDMA over Ethernet，每一跳約 2 微秒。Cerebras 宣稱這樣能讓多兆參數模型達到每秒 1000 到 2000 多個 token（廠商自己的數字）。

工程上的意思。 容量規劃改用「幾片晶圓」計算：Peake 寫每多一片，就多 44 GB 的權重加 KV cache 空間。

Groq LPU：連時間表都由編譯器排好

執行時間在編譯時算定，代價是模型要切到數百顆晶片。

Peake 寫 LPU 去掉快取、分支預測器、仲裁器與重排序緩衝，編譯器把每一道指令與每一個 byte 排到精確的時脈週期。每顆晶片約 230 MB SRAM、分成 88 個切片，總頻寬約 80 TB/s，沒有 HBM 也沒有 DRAM；圖 2 右側的矩陣單元，就是這些 SRAM 旁邊負責乘加的運算區塊。Llama-2 70B 的 FP16 權重約 140 GB，所以部署時用了約 576 顆 LPU。一個節點是 8 顆全連接的 LPU，一個機櫃 9 個節點共 72 顆，第 9 個節點（8 顆）是備援，實際運作 64 顆，規格上可擴到 10,440 顆，晶片之間的網路由編譯器排程，沒有路由，也沒有網卡與交換器晶片。Groq 自己報告，BERT-Large 跑 24,240 次，落在約 75 微秒的區間內，編譯器預測的延遲與實測相差在 2% 以內（Groq 的數字，經 Peake 轉述）。

軟體上，Peake 寫 Groq 沒有核心程式，由編譯器處理，不到十人的團隊四天就讓 LLaMA 跑起來，但那是一個小而封閉的堆疊。邊界也在他的整理裡：LPU 只做推論；放不進 SRAM 的大模型、大批次吞吐的工作、動態控制流，都不適合；他引的分析認為，批次化之後，每美元吞吐輸給 GPU。2025 年 12 月，NVIDIA 取得 LPU 技術的非獨家授權，並聘用 Groq 創辦人 Jonathan Ross（Peake 寫他當年在 Google 以 20% 專案起頭做 TPU）與團隊的大部分成員；Peake 轉述 NVIDIA 的 10-K：沒有轉移產品、客戶合約或股權。GroqCloud 仍在原本 14 nm 的晶片上提供服務，Peake 寫第二代 LPU 從未量產。GTC 2026 上，這項技術以 NVIDIA Groq 3 LPU 出現；Peake 表列 LP30 為 500 MB SRAM、150 TB/s。

NVIDIA 2026 年 9 月 15 日的開發者部落格講了 Groq 3 LPX 機櫃：256 顆 LPU，編譯器事先決定整櫃 256 顆晶片每一刻的資料搬運與運算，晶片之間直連。NVIDIA 宣稱，搭配 Vera Rubin NVL72，跑 2 兆以上參數、長上下文、高互動性的模型時，每兆瓦吞吐最高為 GB200 NVL72 的 35 倍（廠商的數字，預計 2026 下半年提供）。Peake 描述的分工是 GPU 跑注意力（attention），LPU 跑負責轉換資料的前饋層，以及由多個專家子網路分工的 MoE（混合專家）層。

70B 模型在四種晶片上，單人速度上限各是多少？

B200 單人上限約每秒 55 個 token，Cerebras 約十幾萬，Groq 約三十多萬，都是只計權重讀取的理想值。

前提：70B、FP16、批次 1，不計 KV cache、通訊與運算；頻寬取 B200 為 62 TB/s ÷ 8、Ironwood 為 7,380 GBps、Cerebras 為 21 PB/s、Groq 為 80 TB/s。Peake 寫 Cerebras 的 70B 實際部署是跨 Ethernet 的管線平行，批次 1 時一個 token 依序經過 4 片晶圓，每片只讀自己那四分之一的權重，所以有效頻寬等於 1 片的 21 PB/s，程式裡晶片數記 1。Groq 假設 576 顆平均分攤權重、同時讀取；Peake 沒有寫切法，這是本站的假設，所以 Groq 數字是最樂觀的上限。

WEIGHT_GB = 70e9 * 2 / 1e9  # 70B 參數 x 2 bytes = 140 GB

# 名稱: (每顆或每片的權重頻寬 GB/s, 分攤權重的晶片數)
chips = {
    "B200 (HBM)": (62_000 / 8, 1),
    "Ironwood (HBM)": (7_380, 1),
    "Cerebras WSE-3 (SRAM)": (21e6, 1),  # 管線平行、批次 1：4 片依序讀，有效頻寬為 1 片
    "Groq LPU (SRAM)": (80e3, 576),
}

for name, (bw, n) in chips.items():
    seconds = WEIGHT_GB / (bw * n)  # 讀完全部權重一遍
    print(f"{name:24s} {seconds * 1000:10.4f} ms -> {1 / seconds:>10,.0f} tok/s 上限")

B200 (HBM)                  18.0645 ms ->         55 tok/s 上限
Ironwood (HBM)              18.9702 ms ->         53 tok/s 上限
Cerebras WSE-3 (SRAM)        0.0067 ms ->    150,000 tok/s 上限
Groq LPU (SRAM)              0.0030 ms ->    329,143 tok/s 上限

結果：兩種 HBM 晶片的上限是 55 與 53（用 Peake 的 8 TB/s 算，約 17.5 毫秒、57 個 token，同一量級）；Cerebras 約 15 萬、Groq 約 33 萬 token/s；Artificial Analysis 的 446 tokens/s（Peake 轉述）遠低於 Cerebras 的上限。Peake 指出 Cerebras 沒有公布使用率與批次大小，差距無法拆解，本文也不猜原因。

邊界：HBM 也能切開，晶片也開始混搭

OpenAI 在 Hot Chips 2026 的演講提出另一條路：把 HBM 切成每個核心各自一份。

Hot Chips 2026 在 2026 年 8 月 23 日到 25 日舉行，會議第二天（8 月 25 日，23 日為教學場）下午，節目表上有四場跟本文相關的演講：Cerebras 的 Jean-Philippe（J.P.）Fricker 講〈The Cerebras Rack-Scale Architecture for Wafer Scale Engine〉，NVIDIA 的 Igor Arsovski 與 Santosh Raghavan 講〈Think Fast: LPU Accelerator for Heterogeneous Compute〉，Google 的 Norman Jouppi 與 Sridhar Lakshmanamurthy 講〈The Eighth Generation TPU Family〉，OpenAI 的 Richard Ho、Ravi Narayanaswami 與 Chris Leary 講〈You Can Just Build Things … Chips〉。投影片需要與會者登入才能下載，本文沒有讀到，只用公開的節目表，以及電子報《Key Context by Tae Kim》作者 Tae Kim 在 2026 年 9 月 1 日發表的 OpenAI 演講筆記。Tae Kim 自述引言是他手選的。

依他的筆記，演講談的是 OpenAI 的 Jalapeño 推論晶片。OpenAI 技術人員 Ravi Narayanaswami 在「OSS performance」一節說，每位使用者「幾乎 1500 tokens per second」，這「過去是 SRAM 加速器的領域」，接著說："Well, HBM is not the bottleneck."（HBM 不是瓶頸。）他還說交出了「今天最高的吞吐，延遲低 4 倍」。同一場的 Chris Leary（OpenAI 技術人員）描述這是「記憶體切片」架構，每個核心看到的是自己那一片 HBM，所以全域記憶體子系統沒有爭用；他也補了一句，要想清楚工作負載怎麼對應到這台機器上。筆記沒有載明「延遲低 4 倍」的比較對象，也沒有規格表，本文只採用上面的原話，不引用二手報導裡的規格與效能數字。

混搭是另一個方向：Peake 寫 GPU 與 LPU 分工（見 Groq 一節），NVIDIA 的節目標題直接寫「Heterogeneous Compute」（異質運算）。工程上的意思是部署要先決定哪一層跑在哪種晶片。軟體端，Peake 把 CUDA 的護城河定義成二十年累積的第三方核心程式（kernel）、函式庫與工具。

回到那個每秒 55 個 token

開頭的 55，是 B200 讀取 140 GB 權重、批次 1 時的頻寬上限。要提高它，可以減少要讀的權重量，或增加可用頻寬；改變權重住的地方是其中一條路。

我的判斷是，選型前先用前面的頻寬試算，算出只計權重讀取時的單人速度上限，再看值不值得為 SRAM 的速度付出容量與搬遷的代價。條件：產品賣點是單人互動速度（語音、即時 Agent），才值得認真比較 Cerebras 與 Groq 這一類；批次離線的工作，HBM 的大容量與成熟軟體仍是較省事的選擇。若是我，既有 CUDA 程式的離線批次工作選 B200，已在 Google Cloud 的訓練與批次推論選 Ironwood，語音與即時 Agent 先試 Cerebras 或 Groq 的雲端服務、算過延遲再決定要不要搬。選之前問三題：

1. 模型放不放得進 SRAM？放不進，要算幾片晶圓或幾百顆晶片。
2. 要的是一個人的速度，還是整體吞吐？前者看權重所在記憶體的頻寬，後者靠批次。
3. 軟體搬不搬得動？依 Peake：GPU 有二十年的第三方核心程式生態；TPU 的唯一介面是編譯器；Groq 沒有核心程式，由編譯器處理；Cerebras 的第三方核心程式沒有地方可以接上。

我沒有親自實測這些晶片；本文的速度，是來源的數字或上面的算術。

先問權重住在哪，再問晶片多快。

常見問題

解碼和預填差在哪裡？

預填一次處理整段輸入；解碼逐一產生 token。依 Jacob Peake 的整理，解碼每讀取一份資料能做的運算少了好幾個數量級，通常較容易受記憶體頻寬限制。批次 1 時，每個 token 都要把全部權重讀一遍；上下文很長時，還可能改受前文暫存資料（KV cache）的頻寬限制。

批次開大，單人速度會變快嗎？

不一定。NVIDIA 以 V100 的同一個線性層為例，批次從 1 增至 512，每讀寫 1 byte 的運算次數從約 1 次增至 315 次，整體吞吐會上升。每位使用者仍須讀取自己的 KV cache；依 Peake 的整理，上下文很長時，這部分的頻寬也會限制速度。

NVIDIA 授權 Groq 技術後，Groq 還在做晶片嗎？

依 Peake 的整理，2025 年 12 月的交易是非獨家授權，NVIDIA 另聘用 Groq 創辦人 Jonathan Ross 與團隊的大部分成員；GroqCloud 仍在原本 14 nm 的晶片上提供服務，第二代 LPU 從未量產。Groq 之後是否推出新晶片，Peake 的文章沒有說明。

Cerebras 為什麼要把大模型切到好幾片晶圓上？

單片晶圓上的 SRAM 只有 44 GB，權重與前文暫存資料超過容量就需要多片。Cerebras 2026 年 10 月 22 日的部落格以 Kimi K3 為例，依各層的記憶體需求分配到共 59 片晶圓，晶圓之間只傳運算中的中間資料（激活值）。

延伸閱讀

• 個人能設計晶片到哪一步？從 tiny-gpu 看開源工具鏈
• Win98 跑起 LLM，離產品可用還有多遠？

參考資料

• Jacob Peake, AI Chip Architectures（頁面未標發表日；內文已寫到 GTC 2026；2026-10-23 查閱） https://www.jacobpeake.com/ai-chip-architectures
• NVIDIA, GPU Performance Background User's Guide（算術強度、ops:byte、V100 例子；頁面未標日期，2026-10-23 查閱） https://docs.nvidia.com/deeplearning/performance/dl-performance-gpu-background/index.html
• NVIDIA, Product Carbon Footprint (PCF) Summary for NVIDIA HGX B200（資料表內的 HBM3E 容量與總頻寬；未標日期，2026-10-23 查閱） https://images.nvidia.com/aem-dam/Solutions/documents/HGX-B200-PCF-Summary.pdf
• Seth Weidman, Aravind Vellora Vayalapra, Santosh Raghavan, How NVIDIA Groq 3 LPX Deterministic Execution Drives Power-Efficient High-Interactivity Inference on NVIDIA Vera Rubin, NVIDIA Technical Blog, 2026-09-15。 https://developer.nvidia.com/blog/how-nvidia-groq-3-lpx-deterministic-execution-drives-power-efficient-high-interactivity-inference-on-nvidia-vera-rubin/
• Google Cloud, TPU7x (Ironwood)（頁面標示最後更新 2026-10-22） https://docs.cloud.google.com/tpu/docs/tpu7x
• Google, Our eighth generation TPUs: two chips for the agentic era（Cloud Next，2026 年 4 月；頁面未顯示日期） https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/eighth-generation-tpu-agentic-era/
• Cerebras, How We Deploy Trillion-Parameter Frontier Models on Cerebras, 2026-10-22。 https://cerebras.ai/blog/how-we-deploy-trillion-parameter-frontier-models-on-cerebras
• Hot Chips 2026 Program（2026-08-23 至 08-25） https://hc2026.hotchips.org/
• Tae Kim, Hot Chips: OpenAI Jalapeño presentation, Key Context by Tae Kim, 2026-09-01（演講日 2026-08-25）。 https://taekim.substack.com/p/hot-chips-openai-jalapeno-presentation