作者：Sarah Chieng，DevX 主管（@MilksAndMatcha）
我們最常被問到的問題之一，就是如何在 Cerebras 晶圓級晶片上部署大型模型。單塊 Cerebras WSE-3T 晶圓擁有 44 GB 的片上記憶體，而萬億參數的前沿模型僅權重就需要 TB 級的空間。
在這篇文章中，我們會解釋如何將一個大型前沿模型拆分到多塊 WSE-3T 晶圓上，從而以每秒 1000–2000+ tokens 的速度運行數萬億參數的模型。
我們將以開源模型 Kimi K3（約 3 萬億參數）作為說明示例。
讀完本文，你將會了解：
- 我們如何將整個模型放入片上記憶體
- 我們如何將模型映射到多塊晶片上
- 我們如何處理大量並發請求
以 Kimi K3 為例拆解分析
Kimi K3 是一個擁有 3T 參數的開源模型，包含 69 個線性注意力層和 24 個密集層。
它在 Terminal-Bench 2.1 上取得了 88.3% 的亮眼成績（GPT-5.6 Sol 為 88.8%），在 BrowseComp 上則達到 91.2%（GPT-5.6 Sol 為 90.4%）。這些結果展現出前沿級別的編程與 Agent 能力，甚至在部分基準測試中超越了領先的專有模型。點擊此處了解更多關於 Kimi K3 的資訊。
在這個示例中，我們假設：
- 平均請求大小為 256k
- 4-bit 權重量化（與 Hugging Face 實現相同）
- 8-bit KV cache
#1：每一層的大小
要計算支持 Kimi K3 所需的 Cerebras WSE-3T 晶圓總數，我們先來算出每個模型層的大小。
Kimi K3 擁有 3 萬億參數。如果全部 3T 參數都以 4 bits 存儲，原始參數數據量為：
將該數據量除以 93 層，得出：
#2：晶圓數量
既然知道每層大約需要 16 GB，我們就能算出每塊 44 GB 的晶圓可以容納多少層。答案取決於層的類型：
- 密集層需要額外空間存放 KV cache，因為每個密集（全注意力）層都要為每個活躍請求中的每個 token 存儲鍵（key）和值（value）。因此，我們在每塊晶圓上只放一個密集層，並將剩餘的 SRAM 留給它的 KV cache。
- 線性注意力層不需要額外的 KV cache 空間。它不會為每個 token 存儲鍵和值，而是為每個請求保留一個小型、固定大小的狀態，且不受上下文長度影響。這樣每塊晶圓就有空間容納兩個線性層（2 × 16 GB = 32 GB）。
因此，根據 Kimi K3 的 69 個線性層和 24 個密集層，我們可以得出：
晶圓總數為 35 + 24 = 59 塊晶圓。
#3：將晶圓連接起來
Cerebras 以流水線方式執行模型。當 Cerebras 編譯器將模型層映射到晶圓的不同區域後，運行時會規劃 token 在各晶圓之間流動的路徑。為了實現超低延遲，晶圓之間只需傳遞激活值（activations），而這可以通過 RDMA over Ethernet 完成，每跳大約只需 2 微秒。
值得強調的是，由於每塊 Cerebras 晶圓都有 44 GB 的片上 SRAM，而每層只有 16 GB，我們通常可以直接將完整的模型層放在晶片上。
這意味着在大多數情況下，模型權重完全不需要移動，各層也不必跨晶圓拆分。只有激活值會從一塊晶圓傳到下一塊。
#4：我們如何處理 1 個請求
現在晶圓已經連接好，模型也已佈局完畢，我們可以把每塊晶圓想象成流水線上的一個工位：每個工位的模型權重保持不動，而請求的中間結果則在各層之間流轉。
例如，晶圓 1 運行第 1–2 層，並將激活值發送給晶圓 2；晶圓 2 運行第 3–4 層，再把結果傳給晶圓 3，如此類推，直到最後一塊晶圓生成下一個 token。
#5：我們如何處理大量請求
這裏有一個常見的誤解。如果 token 必須按順序經過每塊晶圓，那每塊晶圓在等待輪到自己時豈不是處於閒置狀態？這樣一來，系統不就等於以 batch size 為 1 的方式運行嗎？
並非如此！如果我們每次只沿流水線發送一個請求，等它完成才開始下一個，那就是對流水線的浪費。相反，我們會用不同的請求讓整條流水線保持滿載。由於模型已經被拆分成多個流水線階段，每個階段都可以同時處理不同的請求。
當第 3 階段在處理請求 A 的 token 時，第 2 階段正在處理請求 B 的 token，第 1 階段則在處理請求 C 的 token。在我們的例子中，每個階段就是一層。而在生產環境中，Cerebras 使用的階段粒度要細得多，數量也更多。
每個階段還可以處理一個微批次（micro-batch），即一小組請求，而不只是單個請求。因此，正在處理的請求數量大致等於階段數乘以微批次大小。
要理解其中的取捨：較小的微批次能讓單個請求更快完成，而較大的微批次則能提升整體吞吐量。
#6：我們能處理多少個請求？
分配給 KV cache 的片上記憶體容量，決定了最大並發請求數。每個正在處理的請求都需要在每塊密集層晶圓上佔用自己的 KV cache，因此片上記憶體的大小就設定了並發請求的上限。如前所述，我們只需要計算密集層的 KV cache 需求。
對於每塊已放置一個密集層的 44 GB 晶圓，我們可以用以下公式計算 KV cache 的剩餘空間：
晶圓總存儲 - 一個密集層的大小。在本例中：
計算並發請求數
要找出某種特定模型映射方案支持的並發請求數，我們先計算單個 256k 請求會佔用多少 cache：
接着，要計算該配置支持的並發請求總數，我們進行除法運算：
並發請求總數代表在任何時間點同時在流水線中流動的請求數量。與 GPU 的 batch 不同，這些請求不必互相等待完成，而是持續不斷地流經流水線。
當然，無論是並發數還是 batch size，都無法準確反映推理系統的運行效率。在評估推理系統的吞吐量時，更有意義的指標是在相同輸出生成速度下，單位功率的總 token 吞吐量（例如每兆瓦每秒生成的 token 數）。
如何擴展到超過 3T 參數
同樣的方法也適用於更大的模型：計算權重和請求狀態所需的記憶體，將模型分佈到多塊晶圓上，再把它們連成一條流水線。每增加一塊晶圓，就會帶來更多的算力和片上記憶體，讓我們能夠承載超出任何單塊晶片容量的模型。
感謝你的閱讀！有興趣在 Cerebras 上部署模型，或使用我們的推理雲服務進行開發嗎？
- 使用我們的免費 API 開始體驗：cloud.cerebras.ai
- 聯繫我們的銷售團隊：sales@cerebras.ai
- 在 cerebras.ai 閱讀更多文章
- 點擊此處閱讀原文。
設計：@halleychangg。感謝 Atharva Talpade、Zhenwei Gao、Angela Yeung、Jessica Liu、Joyce Er、Emma Call 和 Rohan Gupta 的審閱與反饋。
