五十九片晶圓怎麼裝下三兆參數

這篇文章拆的是 Cerebras 部落格 2026 年 10 月 22 日的一篇技術說明，作者是 Sarah Chieng，題目是怎麼把兆級參數的前沿模型部署到 Cerebras 上。它是廠商自己寫的文章，所以本文分兩層處理。放置的算術與機制，用文章給的數字就能重算，我會一步一步算給你看；每秒 1000 到 2000 個 token 與基準分數，則是廠商的自我陳述，我沒有獨立數據可以驗證，會逐處標明。

44 GB 的預算與三個假設

整件事從一個容量落差開始。文章寫道「A single Cerebras WSE-3T wafer has 44 GB of on-chip memory」，同時說兆級參數的前沿模型光權重就需要 TB 級空間。一片晶圓放不下，問題就變成怎麼把模型切開，又不讓切開的代價吃掉速度。

文章拿 Kimi K3 當範例。它的描述是 3T 參數、69 個線性注意力層與 24 個稠密層，兩種層合計 93 層。接著文章先講好三個假設，後面所有數字都建立在它們上面。一是平均請求長度 256k，二是權重量化到 4 bit，三是 KV cache 用 8 bit。請注意這是三個設計前提，不是實測結果。換掉任何一個，後面的 16 GB、59 片都會跟著動。

三個假設各管一件事。4 bit 決定權重佔多少空間，8 bit 與 256k 決定 KV cache 每個請求要多少空間，而 44 GB 是兩者共用的天花板。權重是固定成本，KV cache 隨請求數成長，整個放置問題就是在這個天花板底下分配這兩種成本。

先做一個文章沒有明說的下界估算，這是我的推算，不是文章的敘述。3T 參數乘以每個參數半個位元組，權重約 1.5 TB；除以單片 44 GB，約 34.1，也就是即使每片都塞到剛好滿，光放權重也至少要 35 片。文章最後用了 59 片，多出來的 24 片從哪裡來，後面兩節會說清楚。

讀這類部署文章時，先分清楚哪些數字是你可以自己調的旋鈕，哪些是模型本身固定的。層數、參數量屬於模型，是 Kimi K3 的既定規格；位元寬度、請求長度、單片容量則屬於部署選擇或硬體規格。文章把前者當輸入，把後者當假設，整篇推導就是從這些輸入算出晶圓數與併發上限。你要把它搬到自己的場景，就得先把這幾個旋鈕換成自己的值，再重跑一遍同樣的算術，而不是直接引用 59 這個結論。

這三個假設還有一層含意：它們彼此牽制。KV cache 用 8 bit，是在說快取的精度比權重的 4 bit 更高，這個選擇讓稠密晶圓的記憶體壓力集中在快取而不是權重。256k 這個長度是「平均」請求長度，文章沒有說明長度分佈的尾端怎麼處理，也沒有說超過平均的請求會不會被拒絕或排隊。這些都是文章沒有交代的操作細節，本文不替它補答案，只提醒你在引用 59 片這個結論時，它綁定的是一組平均值，不是每一個請求。

一層 16 GB 是怎麼算出來的

文章的算法很直接：把總權重除以層數。它寫「Dividing that payload by 93 layers」，接著得到「Now that we know each layer needs about 16 GB」。用文章的假設重算一遍，3T 乘以 4 bit 得到 1.5 TB，除以 93 是 16.13 GB，和「約 16 GB」吻合。這是我用文章的輸入重算的結果，文章原文沒有把 1.5 TB 這個中間值寫出來。

這裡有一個容易漏掉的細節。69 個線性層與 24 個稠密層在文章裡都被當成同樣大小，每層約 16 GB。實際模型裡兩種層的參數量未必相同，文章沒有分開列，我也不能替它補。後面所有算式都沿用文章的簡化：93 層等大。

下面這個滑桿讓你自己改權重位元數。它把文章的放置規則原封不動套到別的精度上：稠密層一片一層，線性層盡量多塞幾層進同一片。4 bit 那一檔會復現文章的 59 片；其他檔位文章沒有算過，是我用同一條規則推出來的，只當作理解規則的工具，不是 Cerebras 的任何部署數字。

拖動權重位元數看晶圓數怎麼變 · 2 到 10 bit · 9 檔

權重位元數

4 bit

拖一下就會看到一個有趣的形狀。從 4 bit 到 5 bit，每層從 16.1 GB 長到 20.2 GB，但一片仍然剛好放兩層，晶圓數不變，只是稠密晶圓留給 KV cache 的空間少了約 4 GB。再往 6 bit 走，每層 24.2 GB，兩層就是 48.4 GB，超過 44 GB，線性層只能一片一層，總數從 59 直接跳到 93。晶圓數是階梯函數，由「一片放得下幾層」決定，不是隨位元數平滑成長。

這也解釋了文章為什麼偏好 4 bit。這是推論，不是文章的原話：在這組假設下，4 bit 剛好落在「兩層一片」的區間裡，再多一個位元也不加晶圓，但多一個位元就吃掉稠密晶圓的 KV 空間；少一個位元則要等到 3 bit 才能每片放三層。文章只說了它的選擇，沒有說明為什麼是這個選擇。

順帶一提這個階梯形狀的實務意義。它說明在這類架構裡，晶圓數對精度的敏感度不是線性的：在某些區間多花一個位元不增加任何硬體，跨過門檻時成本卻會一次跳上去。這是我從滑桿的結果歸納的觀察，只適用於文章的規則與假設；真實部署是否允許不同層用不同精度，文章沒有討論，所以本文不往那個方向推。

稠密層獨占一片，線性層兩片共用

文章對兩種層的處理不同，原因在於 KV cache。它說稠密（full-attention）層需要額外空間，「because each dense (full-attention) layer stores the keys and values」；線性注意力層則「do not require additional room for a KV cache」，文章形容它只保留「a small, fixed-size state per request」。

這個差別的來由可以用注意力機制的一般原理補一句，屬於我的背景說明，不是文章的敘述。全注意力每多處理一個 token，就要多存一份鍵與值，所以快取大小隨序列長度成長，256k 的平均請求長度正是讓它變得昂貴的地方；線性注意力把歷史壓進固定大小的狀態，不隨長度變大。兩種層在 SRAM 上的需求曲線因此完全不同，把它們放進同一種晶圓、套同一條規則，反而會浪費。

需要小心的是，「不需要額外的 KV 空間」不等於「不佔記憶體」。文章自己說線性層對每個請求保留「小而固定」的狀態，也就是每多一個請求，線性晶圓上就多一份狀態，只是這份狀態不隨序列變長。文章沒有給這份狀態的大小，因此線性晶圓剩下的那段空間能同時容納多少個請求，從文章給的數字無法判斷。合理的推測是，這段空間夠用，否則文章不會選兩層一片；但這是我對設計意圖的推測，不是文章的說法。

放置規則因此分成兩條。稠密層：「we place one dense layer per wafer and leave the remaining SRAM for its KV cache」。線性層：「That leaves room for two linear layers per wafer (2 × 16 GB = 32 GB)」。稠密層一片一層，是因為整片剩下的 SRAM 都要留給它的 KV cache；線性層兩片共用，是因為它不需要長大的快取，32 GB 的權重放進 44 GB 之後還有餘裕。

把兩種晶圓的 44 GB 畫出來會比較清楚。稠密晶圓是 16 GB 權重加上其餘空間，我用 44 減 16 算出約 28 GB，這個 28 是我的減法，文章只說「剩下的 SRAM」。線性晶圓是 32 GB 權重，剩約 12 GB，同樣是我的減法；這 12 GB 要裝每個請求的固定狀態，文章沒有給這個狀態的大小。

如果這個規則成立，59 這個數字就可以逐步重算。線性層 69 個，每片兩個，需要 34.5 片，向上取整是 35 片；加上稠密層 24 片，文章寫的是「This gives us a total wafer count of 35 + 24 = 59 wafers」。69 是奇數，所以按我的推算，35 片線性晶圓裡有一片只放一層，不過文章沒有交代這點。

為什麼不是每片三層？三層是 48 GB，大於 44 GB，放不進去。這同樣是我用文章的數字做的檢查，文章沒有解釋「為什麼是兩層」，但它給的 16 GB 與 44 GB 恰好讓兩層成為上限。

只有激活值在晶圓之間走

權重分散在 59 片晶圓上，推論時資料怎麼走，是整個設計能不能成立的關鍵。文章的說法是權重不動：「in most cases, the model weights never have to move, and layers don't need to be split across wafers」，跨晶圓的只有激活值：「Only activations cross from one wafer to the next」。文章用的措辭是「在多數情況下」，這個限定語要保留，我沒有看到文章列出例外是哪些。

權重不動有一個直接的好處，也是這個設計的前提。激活值是一個 token 在某一層算完之後的中間結果，大小遠小於整層權重，所以跨晶圓傳的東西很小；如果反過來要搬權重，每個 token 都得把 16 GB 級的資料搬過鏈路，兩微秒的跳數根本不重要。這是我對量級的判斷，文章沒有給出激活值的實際大小。它能成立，靠的是前面那套放置規則先把每一層固定在某片晶圓上。

連線方式文章寫的是「this can be done via RDMA over Ethernet」，並給了延遲量級：「This is roughly 2 microseconds per hop」。數字是「大約」，也是廠商的自述，沒有附測量條件。

把這兩個數字接在一起，可以做一個粗估，但這是推論。如果 59 片晶圓排成一條線，相鄰晶圓之間有 58 個連接點，一個 token 走完整條鏈要經過 58 跳，58 乘以 2 微秒是 116 微秒。這個估算假設每次解碼一個 token 就要完整穿過一次流水線，也假設每跳都是 2 微秒；文章沒有逐項確認這兩點，真實值可能不同。

為什麼值得算？因為廠商宣稱的目標速度是「to run multi-trillion parameter models at 1000-2000+ tokens per second」。1000 token/s 意味著每個 token 約 1 毫秒，2000 token/s 則是 0.5 毫秒。在我上面的假設下，116 微秒佔其中約 12% 到 23%。下面的滑桿讓你自己拖速度目標看比例。注意它只算出「跳數時間佔多少」，其餘時間花在運算還是別處，文章沒有拆，我也不能拆。

拖動每秒 token 目標看 58 跳佔多少 · 1000 到 2000 · 步進 50

每秒 token 目標

1500 tok/s

流水線本身解決的是另一件事：吞吐。文章說「Cerebras executes models in a pipeline」，並用三個請求說明這個流水線怎麼運作：「While stage 3 processes a token for request A, stage 2 processes one for request B, and stage 1 one for request C」。每一級還可以處理 micro-batch，也就是「a small group of requests, rather than a single request」。一個請求的每個 token 仍然得依序穿過所有級，但各級同時被不同請求佔用，整條鏈不會閒置。單請求延遲與整體吞吐，是流水線兩個不同的量，上面的滑桿只談前者。

micro-batch 與流水線級數的關係，也值得多想一步。如果每一級一次處理一小群請求，這一級的記憶體讀取與運算就可以分攤給這群請求，鏈路上的固定延遲則不會因為群變大而增加。這是我從流水線的一般性質做的推論，文章只說了每級可以處理 micro-batch，沒有說實際的批次大小，也沒有量測批次大小對單請求延遲的影響。換句話說，批次是用單請求的延遲換整體吞吐的旋鈕，文章指出了旋鈕存在，沒有告訴你它設在哪裡。

KV cache 決定同時能服務幾個請求

流水線能同時容納多少請求，文章給了一句定性的限制：「The amount of on-chip memory allocated to KV cache determines the maximum number of concurrent requests」。KV cache 只存在稠密晶圓上，所以上限來自 24 片稠密晶圓各自剩下的那段 SRAM。

要把這句話變成數字，還缺一個值：每個請求在一個稠密層裡要佔多少 KV cache。這取決於注意力頭數、維度，以及 256k 的請求長度與 8 bit 的快取精度。我讀到的文章版本沒有給出這個值，它似乎放在公式裡，而我無法確認，所以我不寫具體的併發數。下面的滑桿只把它當作自由變數：你自己假設每個請求在單一稠密層佔 x GB，上限就是 28 除以 x 取整，其中 28 是前面 44 減 16 的減法。

拖動每請求每稠密層的 KV 大小 · 0.1 到 2.0 GB · 步進 0.1

每請求每稠密層 KV

0.5 GB

這個關係有兩個含意，都屬於推論。第一，上限是由最緊的那片稠密晶圓決定的：每個請求在 24 個稠密層都有自己的 KV，哪一片先滿，整條流水線就不能再收新請求。第二，若每片剩 28 GB，24 片的 KV 總空間粗估約 672 GB（24 乘以 28），但這是容量的上限而不是併發數，因為請求要同時在 24 片上各佔一份。把總容量除以請求數是錯的算法。

文章也沒有說，在 256k 平均長度的假設下，實際上線時的併發數是多少。它只說了決定因素。因此本文能確定的是機制：併發被稠密晶圓的 KV 空間卡住，要提高併發，要不縮 KV（降低精度或長度），要不給稠密層更多空間。

把這一節和上一節接起來看，文章留下了幾個空白。稠密晶圓的剩餘 SRAM 是否全部能拿來放 KV cache，還是要留一部分給激活值與其他暫存，文章只說「剩下的」留給 KV cache。24 片稠密晶圓上的 KV 是否均勻分攤，也沒有交代。這些空白都會直接改變併發上限，所以上面的反比曲線只能表達形狀，不能拿來當容量規劃的依據。

哪些是文章的算術，哪些是廠商的說法

把前面的內容整理成兩類。第一類是用文章自己的數字重算就能核對的，我的結論是它們彼此一致，這個判斷只來自文章給的數字，不是獨立驗證。3T 參數乘 4 bit 約 1.5 TB，除以 93 層約 16 GB，與文章的「約 16 GB」吻合；兩層 32 GB 放得進 44 GB，三層 48 GB 放不進；69 除以 2 向上取整是 35，加 24 是 59，與文章寫的 59 片吻合。

有兩個地方需要保留。其一，93 層這個總數文章只出現在除法的句子裡，沒有單獨列出，我把它當作 69 加 24 的和，這是合理的讀法。其二，「所有層等大」這個簡化會影響 16 GB 的精度：如果線性層與稠密層實際大小不同，兩層一片的結論可能不成立，文章沒有討論。

第二類是廠商自己的說法，我沒有獨立數據可以查證。目標速度是「to run multi-trillion parameter models at 1000-2000+ tokens per second」，這是 Cerebras 的目標與宣稱，文章裡我沒有看到對應的測量條件。模型分數方面，文章寫 Kimi K3 在 Terminal-Bench 2.1 得 88.3%（對照 GPT-5.6 Sol 的 88.8%），在 BrowseComp 得 91.2%（對照 90.4%）。這些分數描述的是模型能力，來自文章，不是 Cerebras 硬體的成果，也不影響晶圓怎麼放；它們在文中的作用是證明這個模型值得部署。同樣因為出自廠商文章，我不把它們當成獨立評測。

效率怎麼比，文章也有立場。它主張「the more meaningful metric is total token throughput per unit of power」，並說以同樣的輸出生成速度來量，例如每秒 token 數除以兆瓦。這是一個合理的比較框架，但框架與數字是兩件事：文章在我讀到的範圍內沒有給出這個指標的具體數值，讀者拿到的是比較方法，不是結論。

如果你要在自己的場景引用這篇文章，建議的做法是把它拆成三張清單。可以直接引用的是放置算術與機制，前提是標明假設是 256k、4 bit、8 bit；可以引用但要掛名的是速度目標與基準分數，要寫成 Cerebras 的說法；不能引用的是任何文章沒有給的數值，例如具體併發數、激活值大小、單跳以外的延遲組成。把這三類混在一起，是這類廠商文章最常被誤讀的地方。

還有一個讀法上的提醒：文章整體是一篇示範性的算例，不是部署報告。它用 Kimi K3 說明一套放置方法，從頭到尾沒有出現某個真實叢集的利用率、故障處理或排程策略。晶圓壞了怎麼辦、一個請求中途換到另一條鏈怎麼辦，這些營運問題不在文章的範圍裡，本文也無從回答。把算例當成算例讀，才不會把「放得下」誤讀成「已經穩定運轉」。

最後是延伸性。文章說同一套方法可以擴到更大的模型：「calculate the memory needed for weights and request state」，再把它們分散到更多晶圓。用本文的算術來看，意思是更大的模型只是更多層、更多晶圓，每片的放置規則不變。晶圓數、鏈路跳數與延遲都會跟著長，上面那條 58 跳的估算，在更大的模型上會變長，文章沒有討論這個代價。

What this enables：在文章的假設下，權重多數情況下不搬家、只傳激活值，讓一個 3T 參數的模型能攤在 59 片晶圓上；真正的取捨在 KV 空間，而不在權重，吞吐與基準數字則需要等獨立測量。