一片晶圓只有 44 GB，怎麼跑 3 兆參數
Cerebras 在 2026 年 10 月 22 日發表〈How we deploy Trillion-parameter frontier models on Cerebras〉，作者是 Sarah Chieng。文章開頭就點出一個落差：一片 WSE-3T 晶圓的片上記憶體是 44 GB，而兆級參數的前沿模型光是權重就要好幾 TB。Cerebras 的答案是把模型拆到多片晶圓上，並宣稱這樣能讓多兆參數模型跑到每秒 1,000 到 2,000 以上個 tokens。
這篇在 Hacker News 的討論串，開出約 15 小時就累積 290 points、99 則留言，熱門留言最常問的正是「為什麼一片晶圓只有 44 GB」。如果你在評估推論平台，在意的是速度和成本，這篇文章值得細讀的不是速度數字，而是它攤開了一筆容量帳：權重放在哪、KV cache 還剩多少空間、同時能服務多少請求由什麼決定。這筆帳可以拿計算機驗算，而它沒寫出來的部分，正好是選平台時該追問的地方。
先把帳算一遍
Cerebras 用開源模型 Kimi K3 當例子：約 3 兆（3T）參數，由 69 層 linear-attention 和 24 層 dense 組成，共 93 層。文中設定三個假設：權重以 4-bit 量化、平均請求長度 256k、KV cache 用 8-bit。下面的算式依照這些假設，我們逐步核對過算術。
| 步驟 | 算式 | 結果 |
|---|---|---|
| 權重總量 | 3T 參數 × 4 bit（0.5 byte） | 約 1.5 TB |
| 每層大小 | 1.5 TB ÷ 93 層 | 約 16 GB |
| dense 層 | 24 層，每片晶圓放 1 層 | 24 片 |
| linear-attention 層 | 69 層，每片放 2 層（2 × 16 ＝ 32 GB），69 ÷ 2 ＝ 34.5，進位 | 35 片 |
| 晶圓總數 | 24 ＋ 35 | 59 片 |
| dense 晶圓剩給 KV cache 的空間 | 44 − 16 | 28 GB |
幾個地方可以順手驗證。每層約 16 GB，所以一片 44 GB 的晶圓最多放兩層，放三層就是 48 GB，超過容量。linear 層兩層一片，69 是奇數，最後一片只放一層，因此是 35 片而不是 34.5 片。dense 層明明也只有 16 GB，卻一層就用掉一整片，原因在下一段。
dense 層為什麼一層就占一片晶圓
差別在 attention 怎麼記住前文。dense（full attention）層每產生一個新 token，都要回頭對照這個請求前面所有 token，所以它得為每個進行中的請求，存下每一個 token 的 key 和 value，這就是 KV cache。上下文越長、同時進行的請求越多，KV cache 就越大，而且是隨 token 數一路往上長。
linear-attention 層不這樣存。依 Cerebras 的說明，它對每個請求只保留一份小而固定大小的狀態，不管上下文多長都一樣大，所以不需要另外預留 KV cache 的空間。
這就是 24 層 dense 吃掉 24 片晶圓的原因。Cerebras 讓每片 dense 晶圓只放一層權重，空出的 28 GB 全部留給這一層的 KV cache；linear 層沒有這個需求，才能兩層擠一片。換句話說，59 片晶圓裡有 24 片，大半空間不是拿來放模型權重，而是留給請求的 KV cache。
權重不動，只傳 activations
拆到 59 片之後，晶圓之間怎麼接？Cerebras 說它以流水線（pipeline）執行：每片晶圓像裝配線上的一站，權重留在原地不動，只有 activations 從一片傳到下一片，透過 RDMA over Ethernet，每次跳躍約 2 微秒。因為每層只有約 16 GB，整層都能放進單片晶圓，多數情況下不必把一層拆到兩片上。
這也回答了一個常見疑問：token 要依序穿過每一站，其他站豈不是在空等，等於 batch size 只有 1？Cerebras 的說法是，它用不同請求把整條流水線塞滿。第 3 站處理請求 A 的 token 時，第 2 站處理 B，第 1 站處理 C；每站也可以一次處理一個 micro-batch。同時在線上的請求數，大約是「站數 × micro-batch 大小」。micro-batch 小，每個請求更快；micro-batch 大，總吞吐量更高。文中的例子是一層一站，Cerebras 說實際生產環境切得更細、站數更多。
那同時請求數的上限由什麼決定？答案又回到 KV cache。每個進行中的請求，在每一片 dense 晶圓上都要有自己的 KV cache，所以那 28 GB 能容納多少個 256k 請求的 cache，就是天花板。文章接著說明怎麼先算單一 256k 請求占多少 cache，再用 28 GB 除出同時請求數，但這兩個算式在原文是以圖片呈現，我們讀到的文字版沒有列出結果，所以這裡不替它編數字。
1,000 到 2,000+ tokens/s 該怎麼讀
每秒 1,000 到 2,000 以上個 tokens 是 Cerebras 的宣稱，文中沒有附上這個部署設定的實測資料。
拿獨立第三方的數字當背景：Artificial Analysis 的 Kimi K3 頁面顯示輸出速度 40.6 tokens/s（該頁已標示棄用，建議改看新版），Kimi K3.1 Pro 頁面則是 57.5 tokens/s。這是 Artificial Analysis 頁面列出的量測值，頁面並沒有說它是在 Cerebras 的部署上跑出來的。兩邊看起來差了一到兩個數量級，但模型版本、供應商和負載條件都不同，這些數字不能直接相減，也不能據此推出 Cerebras 比其他供應商快幾倍。
更值得注意的是 Cerebras 自己提的標準。它說，單看同時請求數或 batch size 都不能判斷推論系統的效率，比較有意義的指標是「在相同輸出速度下，每單位功率的總 token 吞吐」，例如每兆瓦每秒多少 tokens。但這篇文章沒有給出這個數字，也沒有功耗、價格，以及最終的同時請求數。HN 上也有使用者表示，實際在 Cerebras 上能用的模型有限；這是單一使用者的說法，未經驗證，但它點出另一個缺口：文中用 Kimi K3 當例子，沒有說明使用者實際能在平台上跑哪些模型。
文中也轉述了 Kimi K3 的成績，例如 Terminal-Bench 2.1 為 88.3%、BrowseComp 為 91.2%，這些是 Cerebras 轉述的模型成績，說的是模型能力，不是部署速度，判斷平台時不必放太重。
向推論供應商追問的幾個問題
以下是我們的建議，不是 Cerebras 提供的清單。這篇文章示範了一種粗估方法：權重總量 ÷ 層數，再看每層要不要 KV cache，就能估出要幾片晶片、每片剩多少空間給請求。有了這個框架，面對任何推論供應商的速度宣稱，可以追問：
- 速度在什麼條件下量的？ 哪個模型、哪個量化精度、平均請求多長、同時有多少請求在跑。
- 同一個速度下，能撐多少同時請求？ 單一請求很快，不代表滿載時還能維持。
- 每兆瓦能產出多少 tokens？ 這是 Cerebras 自己說比較有意義的指標，請供應商在相同輸出速度下給數字。
- 價格怎麼算？ 每百萬 tokens 多少錢，長上下文是否另計。
- 我實際能用哪些模型？ 示範用的模型，不一定是你帳號裡能跑的模型。
回到開頭的問題：44 GB 的晶片跑得動 3 兆參數，靠的是 59 片晶圓分工，其中 24 片各放一層 dense，把剩下的 28 GB 留給 KV cache。這筆帳算得通，也說明了 Cerebras 為什麼能把權重留在片上、只傳 activations。但速度、成本和容量能不能落到你的工作負載上，要等它公開功耗、價格與同時請求數，或有第三方在相同條件下量測之後，才有辦法判斷。
