Cerebrasが1兆パラメータのAIモデルを展開：59ウェーハのパイプラインが3Tパラメータモデルを実行する方法

Cerebrasは、複数のWSE-3Tウェーハスケールチップにわたって1兆パラメータのフロンティアモデルを展開する方法を段階的に説明した記事を公開しました。その具体例として、約3兆パラメータのオープンソースモデルであるKimi K3を使用しています。この展開レシピにより、すべてのモデル重みをオンチップSRAMに常駐させた59ウェーハのパイプラインが生成され、Cerebrasによると、複数兆パラメータのモデルを毎秒1000〜2000+トークンで実行できます。

この投稿に関するHacker Newsの議論（292ポイント、100コメント）は、パイプラインの仕組みよりも、Cerebrasが定量化しなかったトレードオフに焦点を当てていました。量子化とベンチマークの同等性、トークンあたりの電力、59ウェーハパイプラインの障害ドメイン、そしてプリフィルトラフィックがデコードと同じ相互接続をどのように通過するかなどです。

核心的な制約：1兆パラメータのモデルにはテラバイトが必要、1ウェーハは44 GB

単一のCerebras WSE-3Tウェーハは、44 GBのオンチップメモリを提供します。1兆パラメータのフロンティアモデルは、重みだけでもテラバイトのストレージを必要とするため、単一のウェーハでは保持できません。Cerebrasの答えは、モデルを複数のウェーハに分割し、それらをパイプラインに接続することです。これにより、各ウェーハはオフチップメモリから重みをストリーミングするのではなく、モデルのスライスをオンチップSRAMに永続的に保持します。

具体例：Kimi K3、3兆パラメータ、93層

Kimi K3は、約3兆パラメータのオープンソースモデルで、69の線形アテンション層と24の高密度（フルアテンション）層で構成され、合計93層です。Cerebrasの例示的な構成は、次の3つのことを前提としています。

• 平均リクエストサイズは256kトークン。
• 4ビットの重み量子化。これは、モデルのHugging Face実装で参照されているスキームと一致します。
• 8ビットのKVキャッシュ。

ステップ1：各モデル層は4ビット重みで約16 GB

3兆パラメータを4ビットで保存すると、生の重みペイロードは約1.5 TBになります。このペイロードを93層に分割すると、層あたり約16 GBになります。

この層あたりの数値が、設計の他のすべてを決定する数値です。なぜなら、それはウェーハの44 GBのSRAMに収まる必要があるからです。

ステップ2：モデルは59ウェーハにマッピングされる

1つのウェーハに収まる層の数は、層のタイプによって異なります。その理由はKVキャッシュです。

• 高密度（フルアテンション）層は、KVキャッシュ用に追加のスペースが必要です。各高密度層は、アクティブな各リクエストのすべてのトークンに対するキーと値を保存するためです。したがって、Cerebrasはウェーハあたり1つの高密度層を配置し、残りのSRAMをその層のKVキャッシュ用に残します。
• 線形アテンション層は、KVキャッシュ用に追加のスペースを必要としません。線形アテンション層は、すべてのトークンのキーと値を保存する代わりに、コンテキスト長に関係なく、リクエストごとに小さな固定サイズの状態を保持します。これにより、ウェーハあたり2つの線形層（2 x 16 GB = 32 GB）のスペースが残ります。

このパッキングルールをKimi K3の構成に適用すると、次のようになります。

• 69の線形アテンション層をウェーハあたり2層で割ると、35ウェーハ（34.5から切り上げ）。
• 24の高密度層をウェーハあたり1層で割ると、24ウェーハ。
• 合計 = 59ウェーハ。

ステップ3：ウェーハはイーサネット上のRDMAで約2マイクロ秒/ホップで接続される

Cerebrasはモデルをパイプラインとして実行します。Cerebrasコンパイラはモデルの層をウェーハの領域にマッピングし、ランタイムはトークンがウェーハ間を流れるパスをマッピングします。低レイテンシのために、アクティベーションのみがウェーハ間で渡され、転送はイーサネット上のRDMAを介して約2マイクロ秒/ホップで行われます。

これを安価にする設計特性は、各ウェーハが44 GBのオンチップSRAMを持ち、各層が約16 GBしか必要としないことです。Cerebrasは、したがって層全体がチップに直接収まるため、モデルの重みを移動する必要がなく、層をウェーハ間で分割する必要もないと述べています。アクティベーションのみがウェーハから次のウェーハへと渡されます。

ステップ4：単一リクエストの処理は組立ラインのように見える

モデルが接続されたウェーハ全体に配置されると、各ウェーハは組立ラインの1つのステージとして機能します。ステージの重みはその場に留まり、リクエストの中間結果がステージを移動します。

具体的な例では、ウェーハ1はモデル層1〜2を実行し、そのアクティベーションをウェーハ2に送信します。ウェーハ2は層3〜4を実行し、その結果をウェーハ3に渡します。最後のウェーハが次のトークンを生成するまで続きます。Cerebrasは、本番環境では、1層1ステージの図が示すよりもはるかに細かい粒度のステージを多数使用していると述べています。

ステップ5：多数の同時リクエストがパイプラインを満杯に保つため、バッチサイズ1ではない

Cerebrasは一般的な誤解に明示的に対処しています。トークンが各ウェーハを順番に通過する必要がある場合、各ウェーハは自分の番を待ってアイドル状態になり、実質的にバッチサイズ1で実行されるのでしょうか？答えはノーです。一度に1つのリクエストだけをラインに送信すると、パイプラインは非効率的に使用されます。代わりに、Cerebrasは異なるリクエストでパイプライン全体を満杯に保ちます。モデルはすでにパイプラインステージに分割されているため、各ステージは異なるリクエストを同時に処理できます。

ステージ3がリクエストAのトークンを処理している間に、ステージ2はリクエストBのトークンを、ステージ1はリクエストCのトークンを処理できます。各ステージは、単一のリクエストではなく、マイクロバッチ（小さなリクエストグループ）を処理することもできます。処理中のリクエスト数は、おおよそステージ数にマイクロバッチサイズを掛けたものです。

トレードオフは直接的に続きます。マイクロバッチが小さいほど個々のリクエストは高速になり、マイクロバッチが大きいほど総スループットが向上します。

ステップ6：同時リクエストは高密度層ウェーハのKVキャッシュメモリによって制限される

処理中の各リクエストは、各高密度層ウェーハに独自のKVキャッシュを必要とするため、オンチップメモリが同時リクエスト数の上限を設定します。線形アテンション層はリクエストごとに固定サイズの状態のみを保持するため、この計算では高密度層のみが重要です。

すでに1つの高密度層を保持している各44 GBウェーハについて、KVキャッシュ用の残りのスペースは、ウェーハの総ストレージから1つの高密度層のサイズを引いたものです。

44 GB - 16 GB = 28 GB

Cerebrasは、単一の256kトークンリクエストが8ビット精度で消費するKVキャッシュの量を計算し、28 GBの空きSRAMをそのリクエストあたりのフットプリントで割って、このマッピングでの最大同時リクエスト数を導き出します。Hacker Newsのスレッドでは、あるコメンターがその導出された数値を190の同時リクエストと読んでいます。

Cerebrasはまた、同時実行性とバッチサイズが決定的な効率指標ではないと警告しています。同社は、推論スループットのより意味のある尺度は、同じ出力生成速度で測定された、電力単位あたりの総トークンスループット（メガワットあたりのトークン/秒など）であると主張しています。

3兆パラメータを超えるスケーリングも同じレシピを使用

このアプローチはより大きなモデルにも拡張できます。重みとリクエスト状態に必要なメモリを計算し、モデルをウェーハ全体に分散し、ウェーハをパイプラインに接続します。各追加ウェーハは、計算とオンチップメモリの両方に貢献します。これが、単一チップの容量を超えるモデルに対応する方法です。

Cerebras展開説明からの主要な数値

数量	値
WSE-3TウェーハあたりのオンチップSRAM	44 GB
例示モデル	Kimi K3、約3兆パラメータ、オープンソース
層構成	69の線形アテンション層、24の高密度層（合計93）
4ビット量子化での生の重みペイロード	約1.5 TB
層あたりの重みメモリ	約16 GB
線形アテンション層用ウェーハ	35（ウェーハあたり2層）
高密度層用ウェーハ	24（ウェーハあたり1層）
総ウェーハ数	59
各高密度層ウェーハのKVキャッシュ用SRAM	28 GB
ウェーハ間レイテンシ/ホップ	約2マイクロ秒、イーサネット上のRDMA
主張される生成速度	複数兆パラメータモデルで毎秒1000〜2000+トークン

Hacker NewsがCerebrasの投稿で問題視した点

フル精度ベンチマークと4ビット量子化

展開例は4ビットの重み量子化に基づいており、コメンターは量子化された展開と見出しのモデル品質との間のギャップを指摘しました。

フル精度のベンチマークを引用して、その後4ビット量子化で進める

あるコメンターは、Cerebrasが実際に公開しているモデルでの自身の経験を次のように説明しました。「Cerebrasは紙の上では良いが、私が合理的にアクセスできるのは『GPT OSS 120b、Qwen 3.8 27B』だけで、私の用途にはあまり良くない。Openrouterのnitroでそこに到達できる。TPSは5倍少ないが。CerebrasでGPT OSS 120bを試したが、速い。しかし、ほとんど間違っている。」同じスレッドには、同社のポジショニングと開発者関係についてより率直な評価もあり、別のコメンターは「笑、これらの人たちは以前に言及した別の愚かな量子化スキームを持っている。少なくとも彼らのゲートウェイからは、ほとんどのモデルはより愚かだ」と述べました。

「GPUバッチとは異なる」という主張は説明されなかった

Cerebrasは、ストリーミングリクエストをGPUバッチと対比し、パイプライン内のリクエストは「互いの完了を待たず」、「パイプラインを継続的にストリーミングする」と述べています。あるコメンターはこのフレーミングに疑問を呈しました。

「GPUバッチとは異なる」とはどういう意味ですか？それはGPUのハードウェア制限ではないですよね？ソフトウェアでこれを行うための足場がまだ利用できないだけですよね

この投稿は、その違いがハードウェアの特性なのか、ソフトウェアとスケジューリングの違いなのかを解決していません。

障害ドメイン：59ウェーハのパイプラインには劣化する明白な方法がない

スレッドで最も実質的なエンジニアリング上の異議は、可用性に関するものです。GPUでは、多くのノードにまたがるモデルはノードを失って劣化できます。Cerebrasでは、モデルは事実上ラックです。

知りたいのは、59ウェーハのパイプラインが障害ドメインで何をコストするかです。GPU展開はノードを失って劣化できます。ここでは、モデルがラックであるため、1つの不良ウェーハが全体を停止させ、エンドツーエンドでライブである必要があるパイプラインはローリングアップグレードを受けられません。どのようにドレインしますか？

Cerebrasの投稿は、冗長性、ウェーハ交換、またはライブのマルチウェーハパイプラインのバージョンアップグレードに対処していません。

同じ相互接続上のプリフィルトラフィックはカバーされなかった

2マイクロ秒のRDMAホップ数値は、アクティベーションのウェーハ間コストとして提示されています。あるコメンターは、この投稿がデコードのみを暗黙的にカバーしていると指摘しました。

デコードについては信じますが、記事はその相互接続ストーリーでプリフィルを高速にする方法について何も述べていません :/

KVキャッシュはより安価なオフチップDRAMに置けるか？

あるコメンターは、KVキャッシュをDRAMなどのより安価なオフチップストレージに押し出すことを提案し、推論エンジンが別のユーザーのデコードを開始する前に1人のユーザーのデコードを完了させる場合、DRAMからSRAMへのKVキャッシュのフェッチが制限されると主張しました。別のコメンターは運用上の帰結を提起しました。各新しいリクエストのKVキャッシュは、サポートストレージサーバーからロードする必要があり、そのサーバー自体が多くのリクエストのアクティブなキャッシュを保持するために大量のRAMを必要とするでしょう。

トークンあたりのエネルギー、コメンターによる推定

投稿の59ウェーハ構成を使用して、あるコメンターは電力推定値を生成しました。

WSE-3Tウェーハあたりの平均消費電力20 kWで、システム全体で約1.18 MWになります。毎秒1500トークンと190の同時リクエストを仮定すると、トークンあたり4.1 Jになります。モデルのサイズを考えると、それは良いと思いますか？

これらの数値を文字通り読むと、59ウェーハ×20 kW = 1.18 MW、1.18 MWを約285,000の総トークン/秒（190の同時リクエストがそれぞれ毎秒1500トークンを生成）で割ると、約4.1ジュール/トークンになります。これらはコメンターの仮定であり、Cerebrasが公開した数値ではありません。投稿自体は、同じ出力生成速度で測定されたメガワットあたりのトークン/秒が比較の公正な基準であると述べているだけです。

ウェーハあたり44 GBは一部の読者には低く見える

ウェーハはかなり大きく見えます。利用可能なメモリが44 GBしかないのは驚きです。それは少し...低くないですか？私はハードウェアの専門家ではありませんが、ウェーハにはもっと多くのメモリが収まると思っていました。

Cerebrasの投稿は、44 GBの数値の背後にあるSRAM密度のトレードオフを説明していません。

チップトポロジとコアが正方形にタイル状に配置される理由

ウェーハスケールアーキテクチャは、データがチップの2次元メッシュの処理要素（コア）を実際にどのように流れるか、そしてなぜ正方形のタイルが支配的であるかについて、より長いハードウェアの質問を促しました。

彼らは層が左から右にPEによってストリーミングされることを示していますが、それが実際にどの程度真実であるか疑問に思います。おそらく、通信は対角線や、データフローに適したトポロジを持つ他の形状を介してストリーミングする方が簡単かもしれません。[...] そして、Cerebrasのようなストリーミングアーキテクチャでは、六角形グリッドのような他のタイプのタイルが考慮されないのはなぜですか？

この投稿は、ウェーハの物理的なレイアウト、ルーティングジオメトリ、またはクロッキング制約について議論していないため、この質問はスレッド内で未回答のままです。

アクセスは依然として見出しの能力に遅れをとっている

サービスを試した支払いユーザーを含む数人のコメンターは、毎秒1000〜2000+トークンの主張と実際に実行できるものとの間のギャップを報告しました。

今週、プロジェクトでCerebrasを試しました。彼らの27bモデルが2000tksで私のプロジェクトに完璧でしょう。残念ながら、それは私が探している毎秒2kトークンを達成していません。

他の人々は、投稿が提供しないものを求めました。ベンチマーク数値ではなく、人間的な品質の比較です。「私は投資しています。なぜなら、このハードウェアは本質的に...素晴らしいと思うからです。しかし、誰かがもう少し...人間的な（純粋にベンチマークベースではない）比較をしましたか？chatgptとanthropic subを選ぶ理由があります。すべてが絶対的な能力ではありません。」あるコメンターは、同社の立場を一言で要約しました。「CerebrasはAIウェーブのTransmetaだ。」

需要側：人々は能力だけでなくレイテンシを望んでいる

スレッドの繰り返しのテーマは、多くのワークフローにとってモデル能力がもはやボトルネックではないということです。「Opus 5.5は今や十分に賢い。速度が私たちに必要なものだ」とあるコメンターは書き、エージェントワークフローがハードウェアの速度では修正できないテストと構築にも時間を費やすことを指摘しました。別のコメンターは、極端な推論速度を質的に異なるものとして捉えました。「彼らが10%の時間で100倍の努力をするか、ツール呼び出しにかかる時間がボトルネックになる1%を想像してみてください。それは実際には特別な種類の『超知能』のように感じられるでしょう。」

結論

Cerebrasの展開方法は、静的で重み固定のパイプラインです。4ビットの重みが各モデル層をオンチップSRAMに固定し、59ウェーハが3兆パラメータのモデルを保持し、アクティベーションのみが約2マイクロ秒/ホップのRDMAイーサネットを介してウェーハ間を通過し、同時実行性は各高密度層ウェーハに残された28 GBのSRAM（KVキャッシュ用）によって制限されます。公開された説明は、サイジングとマッピングのウォークスルーであり、ベンチマークレポートではありません。Hacker Newsのスレッドで未解決の質問は、投稿が定量化していないものです。量子化品質、ウェーハ間相互接続上のプリフィル動作、トークンあたりの電力、そして1つのウェーハが故障したときに59ウェーハのパイプラインがどうなるかです。