How Cerebras Runs a 3-Trillion-Parameter Model: 59 Wafers, Weights That Never Move

Cerebras has published a rare look inside how it serves very large models: a roughly 3-trillion-parameter open model, Moonshot's Kimi K3, spread across 59 WSE-3T wafers with every weight held in on-chip memory. The post, written by Sarah Chieng and dated Oct 22, 2026, claims this layout delivers 1,000 to 2,000+ tokens per second for multi-trillion-parameter models. It is a design walkthrough, not a benchmark, so treat the speed as Cerebras's stated target, not an independent measurement. The mechanism, though, is worth understanding because it explains why wafer-scale inference is fast, and what it costs.

Source: How we deploy trillion-parameter frontier models on Cerebras (Cerebras, Oct 22, 2026). Kimi K3 background comes from Moonshot's launch post and our Kimi K3 open-weights coverage.

The short version

Why a trillion-parameter model is a memory problem first

A single WSE-3T wafer has 44 GB of on-chip memory, and Cerebras notes that trillion-parameter frontier models need terabytes just for their weights. That mismatch is the whole story. If the weights cannot fit on one chip, you either shuttle them in from slower memory every token (the GPU approach, where decode speed is limited by memory bandwidth) or you split the model across enough chips that everything stays resident.

Cerebras picks the second route. The only question is how to cut the model so each piece fits and the pieces can talk to each other quickly. If you are new to the vocabulary, our guide to LLM parameters and model sizes and the tokens-per-second explainer cover the basics, and the AI chip architectures guide places Cerebras next to GPUs, TPUs and Groq.

Step 1: how big is each layer?

Cerebras starts with the raw payload. Three trillion parameters at 4 bits each is about 1.5 TB of weights. Divide by Kimi K3's 93 layers and each layer comes to about 16 GB. The 4-bit assumption mirrors the Hugging Face release of the model, per the post.

Image: Cerebras

The diagram above shows the model's repeating pattern: groups of three linear-attention layers followed by a dense-attention layer, 23 groups in total plus a final dense layer. That split matters for the next step, because the two layer types need different amounts of memory beyond their weights.

Step 2: how many wafers?

A 44 GB wafer can hold two 16 GB layers (32 GB) with room to spare, but the room matters:

• Dense (full-attention) layers store keys and values for every token of every active request. Cerebras gives each its own wafer and leaves the remaining SRAM for that KV cache.
• Linear-attention layers keep a small, fixed-size state per request regardless of context length, so no big KV cache is needed. Two of them fit per wafer.

With 69 linear layers at two per wafer you need 35 wafers (rounding up), and 24 dense layers at one per wafer needs 24. The total is 35 + 24 = 59 wafers, or about 2.6 TB of aggregate on-chip memory. This is also why hybrid architectures with linear attention are attractive for this hardware: they shrink the part of the model whose memory grows with context. Our Kimi K3 architecture explainer goes into the model design itself.

Step 3: connecting the wafers

Cerebras runs the model as a pipeline. The compiler assigns layers to wafers, and the runtime sets the path tokens take between them. Because each layer fits entirely inside one wafer's SRAM, the weights never have to move and layers do not need to be split across chips. What crosses the wire is only the activations, sent with RDMA over Ethernet at roughly 2 microseconds per hop.

Image: Cerebras

Think of an assembly line. Wafer 1 runs layers 1-2 and hands its activations to wafer 2, which runs layers 3-4, and so on until the last wafer emits the next token. The weights are the machines bolted to the factory floor; the request's intermediate results are the parts moving down the belt.

Step 4: serving many requests at once

An obvious objection: if a token must walk through 59 wafers in order, is each wafer idle most of the time? Cerebras says no, because the pipeline stays full. While stage 3 works on a token for request A, stage 2 works on request B and stage 1 on request C. Each stage can also process a micro-batch of requests rather than one.

The post is explicit about the trade-off: smaller micro-batches make each individual request faster, while larger micro-batches raise total throughput. It also notes that this example uses one layer per stage for clarity, and that production uses "much finer-grained stages, and many more of them." Requests in flight is roughly the number of stages times the micro-batch size.

Cerebras also draws a contrast with GPU serving: these requests do not wait for one another to finish a batch, they stream through continuously. Note that GPU stacks also use pipeline parallelism and continuous batching, so the contrast is one of degree and design emphasis. The more defensible reading is that the architecture is built around the pipeline from the start, with weights pinned in place.

Step 5: what caps concurrency

The limit is the KV cache on the dense-layer wafers. Every request in flight needs its own cache on each dense wafer, so the SRAM left after the layer's weights sets the ceiling. In the example that is the 44 GB wafer minus about 16 GB of layer weights, leaving roughly 28 GB per dense wafer. Cerebras then divides that by the cache size of one 256k-token request (at an 8-bit KV cache) to get the number of concurrent requests. The post presents the calculation as a formula figure; the extracted text does not state the final request count, so we do not repeat one here.

Cerebras closes by saying that concurrency and batch size alone do not tell you how efficient a system is. The more meaningful metric, it argues, is total token throughput per unit of power, such as tokens per second per megawatt, measured at the same output speed. It does not publish that number for this setup.

What developers are saying

The Hacker News thread was small (about 30 points and 8 comments when we read it) but had one useful piece of arithmetic.

• User eulgro back-of-enveloped the power: at an assumed 20 kW per WSE-3T wafer, 59 wafers is roughly 1.18 MW. Assuming 1,500 tokens per second and 190 concurrent requests, they got about 4.1 joules per token, which they called reasonable for the model size. Both the 20 kW figure and the 190 requests are the commenter's assumptions, not Cerebras numbers.
• User therein argued that extreme speed changes how models feel to use: if long agentic runs finish in a fraction of the time, tool-call latency becomes the bottleneck.
• User xpct asked how the on-chip mesh of processing elements really routes data, and whether the left-to-right flow in the diagrams is a simplification. These are the commenter's open questions, not verified claims.

What this means for what you build or pay

• Latency-sensitive agents are the target. Coding agents and multi-step tool loops are bottlenecked by sequential decode, which is exactly what a pinned-weights pipeline accelerates. See our earlier coverage of GPT-5.6 Sol Ultrafast on Cerebras and the Qwen 3.8 27B 1,500 tok/s endpoint and its rate-limit catch.
• Hardware footprint is large. 59 wafers for one 3T model is a serious deployment, which is why Cerebras sells it as a hosted cloud rather than something you rack yourself. Compare with the single-system claims in our CS-4 wafer-scale piece.
• Check the fine print before planning around it. The post does not give a price, a rate limit, or confirm that Kimi K3 is live on the public API. Cerebras's inference docs list what is actually served today, and its free API tier is at cloud.cerebras.ai.
• Model design and hardware co-evolve. Linear-attention hybrids reduce KV-cache pressure, which this layout directly rewards. Cerebras's CEO has also been outspoken about the company's direction; see Feldman's home AI appliance remarks.

What is claimed vs. what is verified

If you want to check speed claims yourself, run the same long prompt against the endpoint at different times, record time to first token and steady decode rate, and compare with the model's page in the provider's docs. Our Kimi K3 vLLM claimed-vs-verified post shows what that kind of check looks like for a GPU stack.

How this scales beyond 3T parameters

Cerebras's closing argument is simple: calculate the memory for weights and request state, distribute the model across wafers, and connect them into a pipeline. Each added wafer contributes both compute and on-chip memory, so models that exceed any single chip become a matter of wafer count. The unstated catch is that the dense-attention layers set a hard concurrency ceiling through their KV cache, so context length, quantization level and attention design all feed straight back into how many users one deployment can serve.

For readers choosing infrastructure, the takeaway is not to memorize the numbers but to learn the questions: where do the weights live, what has to cross between chips, and what limits concurrent requests. Those three questions apply to any inference system you evaluate.

Specifications and figures are as published by Cerebras on October 22, 2026, and may change. This post will be updated if Cerebras publishes measured Kimi K3 results.

Related reading

• Kimi K3 open weights: the 2.8-trillion-parameter release
• Kimi K3 architecture explained
• AI chip architectures: GPU, TPU, Trainium, Cerebras, Groq
• Cerebras CS-4 wafer-scale accelerator
• GPT-5.6 Sol Ultrafast on Cerebras
• Qwen 3.8 27B at 1,500 tokens per second on Cerebras
• What is TPS? LLM speed explained