Cerebras 兆參數部署解析：59 片晶圓裝得下，為何還要算並行快取？（2026）

2026 年 10 月 22 日，Sarah Chieng 在 Cerebras 官網發布了〈How we deploy Trillion-parameter frontier models on Cerebras〉，解釋 Cerebras 兆參數部署如何跨越單片晶圓 44 GB 片上記憶體的限制。最值得讀的地方，是它把「模型放得下」與「同時服務多少請求」放進同一份容量帳。

下面先看原文的分層、流水線與快取算式，再對照模型開發者及 GPU 軟體文件，最後判斷這套設計真正解決了什麼。59 片晶圓是原文的示例配置，約 190 個並行請求是指定假設下的容量估算；兩者都不能直接當成已驗收的生產服務規格。

Cerebras 兆參數部署：先把模型拆成留在原地的工站

想像一條組裝線：每個工站保留自己的設備，半成品往下一站移動。對應到推論，設備是模型權重，半成品是當前計算的中間結果，也就是 activation。這個比喻能解釋原文最核心的一句話：

Only activations cross from one wafer to the next.

中文：只有中間計算結果，會從一片晶圓傳到下一片。

Sarah Chieng／Cerebras

這句話描述的是原文所設想、能把完整層放進晶圓的映射。它要減少解碼時反覆搬移權重的代價，不代表整套服務完全沒有其他資料傳輸。輸入處理、請求狀態、排程和主機通訊，仍應在完整系統測試中列帳。

原文進一步說明，多個請求可以同時占用不同工站；工站也能處理一小組請求，稱為 micro-batch。小組較小偏向降低單一請求的等待，小組較大則可能提高整體吞吐。作者最後主張，在相同輸出速度下比較每單位功耗的總吞吐，比單看批次或並行數更有意義。這是它希望讀者帶走的評估方向。

59 片怎麼算？先看清楚示例的假設

Cerebras 用約 3 兆參數的 Kimi K3 示範，設定權重 4-bit、KV cache 8-bit，平均每個請求 256,000 token。KV cache 可以想成每位客人的工作筆記：生成下一個 token 時，保留先前計算過、還會用到的資訊，避免從頭重算。

以下按原文的十進位容量重算。這是算式核對，本文未在 Cerebras 硬體上執行模型。

原文示例	算式或配置	應保留的邊界
純權重資料量	3 × 10¹² × 4 ÷ 8＝1.5 TB	未把所有執行時資料都算進去
平均每層	1,500 GB ÷ 93 ≈ 16.1 GB	平均值不等於每一層的實際大小
線性注意力部分	69 層，每片安排兩層，向上取整為 35 片	仍需要保存每個請求的固定大小狀態
完整注意力部分	24 層，每片一層，預留快取空間	請求愈長或愈多，快取愈大
合計	35＋24＝59 片	示意映射，並非逐層編譯後的採購清單

這裡有個名詞陷阱。Moonshot 的 Kimi K3 模型卡列的是 2.8T 總參數、104B 活躍參數、93 層，以及 69 KDA＋24 Gated MLA；它另列的稠密前饋層數是 1。原文的 24 個「dense」是在說完整注意力，不是宣稱有 24 個稠密前饋層。模型卡的 2.8T 與文中取整的約 3T，也應分開標示。

MoE 每個 token 只啟用部分專家，可以減少當次運算；但若採用把全部權重常駐記憶體的策略，仍要為全部專家留位置。把 104B 活躍參數拿來估全模型權重容量，會把「這次算多少」與「總共要存多少」混在一起。

約 190 個請求，為什麼不是再乘上 24？

在原文簡化帳裡，一片完整注意力晶圓先放約 16 GB 權重，44−16 後剩約 28 GB。它再用每 token 每層儲存 576 bytes，估算一份 256,000-token 請求占 147,456,000 bytes，也就是約 147 MB；28 GB 除下去，得到約 190 份。

這個 576 並非適用所有模型的常數。Kimi K3 的公開設定檔列有 512 的 KV 潛在維度與 64 的 RoPE 維度；在原文每元素 1 byte、以壓縮 MLA 表示儲存的假設下，512＋64 對應到 576。不同的快取表示、精度與配置，應重新計算。

同一份請求會在每個完整注意力層保留自己的狀態，因此這裡約 190 是整條映射可同時承載的請求量級，不能再乘 24。它也不是保證每秒完成 190 件工作；請求可能還要生成很多 token。約數四捨五入、執行緩衝區、量化尺度和其他狀態，都會影響可實際配置的整數席位。

做一個能看出機制的敏感度推演：如果把每份請求由 256,000 拉到四倍的 1,024,000 token，維持相同快取格式與 28 GB 預算，完整注意力部分的每份快取也會變成四倍，可容納量級就由約 190 降至約 47。這不是另一個實測結果，也不是 Cerebras API 上限，而是同一容量模型的條件推算。

線性注意力的優勢在於以固定大小的遞迴狀態取代逐 token 成長的完整歷史快取，但狀態仍隨請求數增加。Moonshot 的 Kimi Linear 論文也討論固定狀態與精確歷史檢索的取捨。混合 KDA／MLA 的意義，就在保留不同機制的長處；不能由部分層節省狀態，推導整個模型的長上下文記憶體成本消失。

外部文件提供的校正：流水線與動態排程也存在於 GPU

原文把連續流動的請求拿來對比「GPU batch」，容易讓人讀成 GPU 必須整批做完才接下一批。這樣比較太窄。NVIDIA TensorRT-LLM 的平行策略文件明確列出 pipeline parallelism：不同 GPU 負責不同層，裝置間傳遞 activation。這支持的是一般機制，不是替 Cerebras 的速度背書。

NVIDIA 的 執行時排程文件也說明 in-flight batching 可在迭代中安排請求，並公開快取容量、利用率與暫停請求之間的取捨。因此，公平問題應是：在相同模型、品質與延遲目標下，哪一套記憶體和排程實作更有效率？不是把其中一方設定成只能使用固定批次的簡化對手。

同樣地，不能把「4-bit」直接寫成品質一定下降。Moonshot 模型卡說明 K3 從 SFT 階段起就使用 MXFP4 權重與 MXFP8 activation 的量化感知訓練。真正應核對的是該部署如何保留模型品質、如何存放敏感層與狀態，以及同一版本在相同任務的結果，而不是僅憑位元數下判決。

AlphaLab 的判讀：有說服力的容量帳，仍需要四個補件

一、平均每層 16 GB，還不是可執行的映射

把總權重除以 93，適合教學，也適合估量級；要形成可重現的部署，還需要逐層大小、實際排列、工作區、量化中繼資料及最吃緊工站的配置。假設某層比平均值大，它的擺法就可能影響其他層與請求狀態。這不是否定 59 的加法，而是指出從算得通到編譯可執行，中間還有一張配置表。

二、晶圓間兩微秒，不是整份回答兩微秒

原文標示跨晶圓每跳約 2 微秒，屬 Cerebras 的鏈路說明。一次回答還包含各層計算、多次 token 迭代與服務端等待；長輸入更要處理 prefill。Artificial Analysis 的量測方法把首 token 時間、收到首 token 後的輸出速度、完整回應時間分開。這個拆法比單拿最快的鏈路數字更接近使用者感受。

三、能排進流水線，不代表每個席位都達到同一速度

記憶體告訴你最多能留下多少份工作狀態，運算與排程則決定每份工作多久前進一步。要把原文開場每秒 1,000–2,000 以上 token 的供應商敘述，與這份 K3 示意配置接在一起，還需要同一模型映射、輸入長度、並行數、精度及延遲分布的測試。本文不把該速度當成這 59 片配置已被獨立驗證的成績。

四、每瓦吞吐有價值，但品質與系統邊界要一起固定

在相同輸出速度下比較每單位功耗總吞吐，是合理方向；還應固定輸出品質、輸入長度與尾端延遲，並說清楚功耗包含哪些主機、網路與冷卻設備。服務的價值終究要回到合格工作：如果只是更快產生需要重做的答案，token 數本身不會替你完成任務。

我同意：原文用權重常駐、分層映射及每請求狀態，把片上 SRAM 的優勢與容量代價連在一起，值得認真看。我存疑：把平均層大小與理想快取除法，延伸成具體服務在長輸入、滿載與固定品質下的速度或經濟性保證。Cerebras 兆參數部署最有價值的啟發，是讓我們追問瓶頸搬到了哪裡。

下一步：向供應商要一張容量與延遲能對帳的表

若你在評估推論服務，可先提供一小批已知合格標準的真實任務，要求短輸入與長輸入、低負載與高負載分開報告。每一格記下模型版本、量化與快取格式、輸入／輸出 token、並行數、p50／p95 首 token 時間、輸出速度、失敗與重試，以及每件合格成果的總時間與費用。評估硬體時，再加上可重跑的配置及完整功耗邊界。

也要把文章中的示例，與自己能取得的產品分開。Cerebras 的 Shared Inference 模型目錄與 Dedicated Inference 是不同入口；這篇工程解說不能單獨證明你的帳號已能呼叫同一個 K3 配置。先確認可用模型與容量，再討論遷移。若想了解這條硬體路線的背景，可接著看 Cerebras CS-4 的機櫃與速度宣稱解析；本篇則把焦點留在跨晶圓的容量帳。