Cerebrasが、自社の wafer-scale chip 上で超巨大なAIモデルをどう動かしているのかを説明した記事を公開した。焦点は、1枚のチップに収まりきらない trillion-parameter 級モデルを、どう分割し、どうつなぎ、どう多数のリクエストをさばくかだ。単なる技術自慢ではなく、推論基盤としてどこにボトルネックがあるのかをかなり具体的に見せている。大規模モデルの「重みをどう置くか」が、そのまま性能の話になる局面が見えてくる。
元記事はまず、CerebrasのWSE-3T wafer 1枚には 44 GB の on-chip memory がある一方で、trillion-parameter frontier model は重みだけでも terabytes 級の容量を要すると説明する。そこで例として挙げるのが、オープンソースの Kimi K3 だ。約 3 trillion parameters を持ち、69の linear-attention layers と24の dense layers で構成される。記事では、このモデルを使って、実際にどう multiple WSE-3T wafers にまたがって配置するのかを順を追って示している。
前提条件として、平均リクエストサイズを 256k と仮定し、重みは 4-bit quantization、KV cache は 8-bit としている。まず3Tパラメータを4bitで持つと、総量は約 1.5 TB になる。これを93層で割ると、1層あたり約16 GB になる。Cerebrasの考え方では、1層が 16 GB なら、44 GBある wafer にはそのまま複数の層を載せられるが、層の種類によって載せ方が変わる。dense layer は各アクティブなリクエストの keys と values を保持する必要があるため、1 wafer に1層だけ置き、残りの領域を KV cache に残す。一方 linear-attention layer は、コンテキスト長に依存して巨大化する cache を持たず、各リクエストにつき固定サイズの state で済むので、1 wafer に2層置ける。こうして見積もると、69の linear-attention layers に35 wafers、24の dense layers に24 wafers が必要になり、合計59 wafers という計算になる。
配置が決まったら、Cerebrasの compiler が model layers を wafer の各領域へ割り当て、runtime が token の流れ道を決める。ここで重要なのは、各 wafer 間で運ぶのは主に activations だけで、重みそのものは動かさない点だ。wafer 間の通信は Ethernet 上の RDMA で行い、1 hop あたりおよそ 2 microseconds としている。つまり、巨大モデルでも「重みを遠くへ運ぶ」のでなく、「小さな中間結果を次へ送る」構造にしているわけだ。
1件のリクエストを処理する流れは、組み立てラインに近い。ある wafer が最初の数層を処理し、次の wafer がその続きの層を担当する。最後の wafer が次の token を出力するまで、順番に activations を渡していく。さらに記事は、これだと1件ずつ待つ batch size 1 になるのでは、という疑問にも答える。実際には pipeline を常に満たし、別々のリクエストを別々の stage で同時に処理する。Cerebrasの例では1 stage が1 layerだが、実運用ではもっと細かい stage を使うという。
同時にどれだけのリクエストをさばけるかは、dense layer に割り当てた KV cache の容量が上限を決める。各 active request は dense-layer wafer ごとに自分専用の cache を必要とするからだ。記事では、1リクエストが消費する cache 量を見積もり、それを各 wafer の残り容量で割って concurrent requests の数を出す。Cerebrasは、こうして pipeline を流し続けながら、1,000〜2,000+ tokens per second の推論性能を狙う、と説明している。最後に、この方法は3Tを超えるモデルにも同じように拡張でき、必要なのは重みと state の容量を見積もり、wafer を増やして pipeline 化することだとしている。
この記事で面白いのは、巨大モデルの推論を「速いか遅いか」の話にせず、まず物理的な置き場の設計に戻しているところだと思う。GPUベースの議論だと、どうしても batch や throughput の数字が先に来る。でもCerebrasの説明では、1層が 16 GB 前後なら wafer 1枚に載る、dense layer なら1層、linear-attention なら2層、というように、モデル構造そのものが配線図になっている。抽象的なAI基盤の話というより、かなり露骨に「この層はここ」と決める話だ。
これは強みでもあり、制約でもある。強みは、重みを頻繁に動かさずに済むので、巨大モデルでも安定して流せること。制約は、モデルの構造がそのままハードウェアの都合に縛られることだ。特に dense layer の存在が効いていて、linear-attention と違って KV cache を食うので、同じ16 GBの層でも扱いが変わる。つまり「3Tモデルを動かす」ことは、単に演算能力の話ではなく、attention の種類をまたいだメモリ配分の話になる。ここにCerebrasの思想がよく出ていると思う。
RDMA over Ethernet で wafer 間をつなぎ、1 hop あたり約 2 microseconds と聞くと、かなり速い。だがこの記事が本当に言いたいのは、通信を速くした、という単純な話ではないはずだ。むしろ「通信するのは activations だけ」「重みは動かさない」という前提を徹底したからこそ、その 2 microseconds が意味を持つ。巨大な重みを毎回外へ取りに行く構成なら、いくら hop が速くても話にならない。
この設計は、クラウドで大規模推論を回すときの見えにくいコストにもつながる。モデルが大きくなるほど、1リクエストの応答速度だけでなく、同時に何件流せるか、KV cache をどれだけ積めるかが効いてくる。記事が concurrent requests をかなり丁寧に扱っているのはそのためだろう。推論基盤の実力は、単発のレイテンシーではなく、長い列を切らさず流せるかで決まる。Cerebrasはそこを「pipeline を満たし続ける」構造で押し切ろうとしているように見える。
記事では平均リクエストサイズを 256k と置いている。これは長文入力やエージェント的な使い方をかなり意識した前提だと思う。最近のフロンティアモデルは、単発の短い質問応答より、長い履歴を持った推論やコード作業、ブラウジングのような用途に寄っている。だから KV cache の見積もりが支配的になるのは自然だし、dense layer ごとの cache 容量が同時接続数を決めるという説明にも説得力がある。
ただ、ここで面白いのは、Cerebrasが「大きいコンテキストを扱うなら cache の扱いが重要」と言うだけでなく、それを wafer 上の残り容量にまで落としていることだ。一般論としては分かりやすいが、実装上はかなり厳しい制約でもある。1リクエストあたりの cache が増えれば、同時接続数はすぐ削られる。逆に小さい micro-batch にすれば各リクエストは速くなるが、総スループットは落ちる。ここは、単に「速い推論装置」では済まず、ワークロード設計まで含めて最適化しないといけない世界だと感じる。
元記事には、Kimi K3 が Terminal-Bench 2.1 で 88.3%、BrowseComp で 91.2% を出し、GPT-5.6 Sol の値と比較しているくだりもある。つまりモデル自体が frontier 級で、しかもオープンソースでもある、という文脈はある。ただ、この記事全体の本丸はベンチマーク勝負ではなく、そのモデルをどう載せるかの設計図だ。競合比較は入口にすぎず、Cerebrasが本当に見せたいのは「巨大モデルでも、配列のように並べれば動く」という発想だと思う。
この見せ方はうまい。AI業界では、モデルサイズが大きくなるたびに「GPUでどこまでいけるか」が話題になるが、Cerebrasはその土俵を少しずらしている。必要なのは、より大きなGPU群ではなく、重みを内蔵しながら pipeline と cache を制御できるハードウェアだ、という主張に見える。もちろん、実運用で本当に 1,000〜2,000+ tokens per second をどの条件で出せるのかは、ワークロード依存だろうし、他社との比較は慎重に読むべきだ。でも、少なくとも「3兆パラメータをどう扱うか」を、かなり具体的に説明してみせた点は価値がある。推論インフラの議論は、これからますますモデル性能そのものと分離しにくくなるのではないかと思う。
