The Pulse
Cerebras Maps 3-Trillion-Parameter Kimi K3 Across 59 Wafer Chips
Cerebras describes an illustrative deployment that maps Kimi K3 across 59 WSE-3T wafers, keeping model weights on-chip while requests move through a pipeline. The guide explains its memory and serving approach, but does not report a like-fo
AI.info Team · Written with AI · fact-checked ·
“This means that in most cases, the model weights never have to move, and layers don’t need to be split across wafers.”
Sarah Chieng, writing for Cerebras
Cerebras’ October 22 deployment guide describes how it maps the roughly 3-trillion-parameter Kimi K3 model across 59 WSE-3T wafers, keeping model weights on-chip while requests move through a pipeline. The company presents the design as an example of serving models larger than any one wafer’s memory, not as an independently measured benchmark report.
Why Kimi K3 takes 59 wafers
A WSE-3T wafer has 44 GB of on-chip memory, while Kimi K3’s weights alone require terabytes at ordinary precision. Cerebras works through an illustrative configuration using 4-bit weight quantization, an 8-bit key-value cache and an assumed average request length of 256,000 tokens. Under those assumptions, the company estimates each of the model’s 93 layers at about 16 GB.
The layer mix determines how Cerebras distributes the model. Kimi K3 has 69 linear-attention layers and 24 dense, or full-attention, layers. Cerebras assigns two linear layers to a wafer, using 32 GB of its 44 GB, but reserves one wafer for each dense layer because dense attention stores keys and values for tokens in active requests.
That arithmetic yields 35 wafers for the linear layers and 24 for the dense layers: 59 altogether. The remaining memory on dense-layer wafers holds KV cache. The estimate depends on the stated quantization and request-length assumptions; it is not a universal wafer count for every model or serving configuration.
Weights stay put as activations move
Cerebras describes execution as a pipeline. Its compiler maps layers to wafer regions, then the runtime routes tokens between stages. The post says activations—the intermediate results passed between layers—travel over RDMA over Ethernet, with roughly two microseconds per hop. The model weights generally remain where they are placed, avoiding the need to move them between wafers for each request.
In the guide’s simplified example, one wafer runs layers 1 and 2, then sends its activations to a second wafer running layers 3 and 4. Production deployments use finer-grained stages, the company says. That distinction matters: the two-layer illustration explains the principle, but does not specify the exact stage layout of a production Kimi K3 deployment.
Requests share the pipeline, not a waiting line
Cerebras says its system keeps multiple requests in flight at once. While one stage processes a token for request A, other stages can work on requests B and C. Each stage can also process a micro-batch, a small group of requests; the company says smaller micro-batches favor individual request speed, while larger ones raise total throughput.
The speed claim needs a measurement context
Cerebras frames the approach as a way to run multi-trillion-parameter models at 1,000 to 2,000-plus tokens per second. The guide does not attach that range to a reported test of Kimi K3 under a specified serving workload. It also cautions that request concurrency and batch size alone do not show how efficiently a system performs.
For comparisons, Cerebras says the more useful measure is total token throughput per unit of power, such as tokens per second per megawatt, with systems measured at the same output-generation speed. The post supplies a deployment calculation and an architectural explanation; it does not provide that like-for-like power comparison for the Kimi K3 example.