Cerebras has published an engineering walkthrough of how it fits trillion-parameter models onto its wafer-scale chips, using the open-source Kimi K3 model — roughly 3 trillion parameters — as the worked example. The company says the resulting configuration runs at 1000-2000+ tokens per second, and the post is notable less for the throughput number than for showing the arithmetic a team would need to replicate the sizing exercise on its own workload.
The constraint Cerebras starts from is memory, not compute. A single Cerebras WSE-3T wafer carries 44 GB of on-chip SRAM, and Kimi K3's 3 trillion parameters, even quantized to 4 bits, do not fit on one chip. Cerebras's post walks through the layer math directly: at 4-bit weight quantization, the raw parameter payload divided across the model's 93 layers works out to roughly 16 GB per layer. Kimi K3 itself is described in the post as having 69 linear-attention layers and 24 dense layers.
Because dense layers need on-chip room for a KV cache per active request while linear-attention layers carry only a small fixed-size state regardless of context length, Cerebras places just one dense layer per wafer but packs two linear layers per wafer (2 × 16 GB = 32 GB). That layout produces 24 wafers for the dense layers and 35 for the linear layers — 59 wafers total to hold one copy of Kimi K3, according to Cerebras's own accounting. The company frames this as a general method, not a Kimi-specific hack: "calculate the memory needed for weights and request state, distribute the model across wafers, and connect them into a pipeline."
Wafers are chained as pipeline stages, and the blog post's operational claim is that, because the model is usually mapped so entire layers fit on-chip, weights themselves never move during inference — only activations cross wafer boundaries, over RDMA over Ethernet, at what Cerebras states is roughly 2 microseconds per hop. The engineering account also addresses a question the company says it fields often: whether a strict wafer-to-wafer pipeline forces an effective batch size of one. Cerebras's answer is that it keeps every pipeline stage busy with different requests simultaneously — while one wafer processes a token for one request, the next wafer up the chain handles a different request — and that each stage can additionally process a micro-batch rather than a single request, trading per-request latency against total throughput.
The limiting resource for concurrency, per the post, is KV cache space on the dense-layer wafers, since every in-flight request needs its own cache there; Cerebras's worked example assumes a 256k average request size and an 8-bit KV cache to derive how many simultaneous requests a given wafer allocation supports. The company is explicit that neither concurrency count nor batch size is a sufficient efficiency metric on its own, writing that "the more meaningful metric is total token throughput per unit of power (e.g. tokens per second per megawatt), when measured at the same output generation speed" — a metric the post references conceptually but does not report a figure for in this account.
What the piece does not supply is a direct cost or power comparison against GPU clusters serving the same model, nor a published tokens-per-second-per-megawatt number to back its own stated efficiency framing — so the 1000-2000+ tokens-per-second figure stands without a cost-per-token or hardware-utilization baseline to weigh it against. The post also cites Kimi K3 benchmark scores, 88.3% on Terminal-Bench 2.1 and 91.2% on BrowseComp, comparing them against what it calls "GPT-5.6 Sol," but those are model-quality figures rather than deployment metrics and say nothing about Cerebras's own serving overhead.
For teams sizing wafer-scale inference against a GPU cluster, the operationally useful part of this account is the layer-by-layer budgeting method itself — parameter count, quantization bit-width, and KV cache footprint per request translate directly into a wafer count and a concurrency ceiling, and that arithmetic can be rerun against any target model before committing to either stack.