Landscape

One question sorts the field: where do the weights rest?

Batch-1 decode reads every active weight once per token, so decode speed is set by the bandwidth at the weights’ resting place — not by peak arithmetic. Every serious inference architecture is a position on that one constraint. This page places the major machines on that axis, states where Honeycomb agrees with each of them, and is explicit about what is and is not comparable today.

Two ground rules for reading it. First, there is no Honeycomb silicon: Honeycomb’s entries are theorems, generated RTL, golden simulation, and recorded sky130 physical-design runs — the same evidence chain as everywhere else on this site, with the same tags. Second, the figures quoted for other machines are publicly reported and approximate, chosen to characterize each architecture’s shape rather than to benchmark a product. Nothing here is a head-to-head measurement.

The sorting question

A GPU’s peak arithmetic is irrelevant to interactive decode if every token rereads the model through a narrow memory system; a machine with modest arithmetic and wide, close memory can be faster where it counts. The architectures below are usefully read as five different purchases of the same thing — bandwidth at the weights’ resting place — at five different price structures:

The rest of the page walks through each row. The pattern to watch: Honeycomb agrees with almost everyone about something — resident weights with Cerebras and Groq, determinism with Groq, a cheap capacity tier with SambaNova, the tiled-mesh shape with Tenstorrent — and differs from all of them on the same two points: the machine is kept flat, and the construction is proved.

GPUs: batching against the wall

The GPU is the architectural opposite on the sorting question. Weights rest in HBM behind a small number of shared memory controllers, and batch-1 decode rereads every active weight through that funnel each token — which is why decode delivers a small fraction of the chip’s compute-bound rate, and why the standard remedy is batching, a throughput answer to a latency question. The same-node comparison on this site is a narrow, recorded instance of exactly this effect.

Honeycomb inverts the sizing rule: compute is provisioned to match memory bandwidth rather than the other way around, weights stay resident next to the datapath, and decode rides aggregate bandwidth across many small channels instead of a shared hierarchy. The honest converse is stated throughout this site: compute-bound prefill is expected to be comparable at the same node, not better, and raw floating-point density is not the goal. And one GPU advantage is not architectural at all: the software ecosystem is decades deep, and this project does not pretend otherwise — Honeycomb’s compatibility story is a compiler contract on a small proved ISA, not drop-in parity.

Cerebras: bandwidth by wafer-scale integration

Cerebras answers the same question — put the weights next to the compute — with the largest possible unit: one wafer-scale die, on the order of 900,000 cores and tens of gigabytes of on-wafer SRAM with petabytes per second of aggregate bandwidth. The thesis is shared; the economics are mirror images. A wafer is the most expensive possible scaling unit, models larger than on-wafer SRAM spill into external memory appliances or multi-wafer sharding, and the system is coordinated as a hierarchy of specialized parts around the wafer.

Honeycomb buys the same locality with the smallest possible unit instead: one proved cell, repeated, with commodity DRAM at the mesh edge as the capacity tier. Aggregate bandwidth comes from replicating cheap channels rather than integrating a heroic die — and the fabric stays flat, with no coordinating tier above the cells.

Groq: shared determinism, different capacity story

Groq is the closest relative on movement. The LPU is fully compiler-scheduled and deterministic to the cycle — no dynamic arbitration in the steady state, latencies known at compile time. Honeycomb’s transport makes the corresponding claims as theorems: a packet arrives in exactly its Manhattan distance in cycles, dimension-order routing carries a proved acyclic channel-dependency argument, and the flow-controlled fabric’s no-loss and fairness properties are proved on the generated RTL’s own AST. The kinship is real: both architectures treat schedules, not caches, as the source of performance.

The divergence is the capacity tier. The LPU keeps weights in on-die SRAM only — roughly a couple hundred megabytes per chip — so serving a large model means assembling hundreds of chips, an economics that works at datacenter scale and high utilization. Honeycomb keeps SRAM for the hot resident set and treats commodity DRAM at the mesh edge as a first-class region of the same cost-space, so capacity scales with cheap memory rather than with chip count.

SambaNova: the hierarchy, made explicit

SambaNova’s SN40L makes the memory system three explicit tiers — on-die SRAM, HBM, and a large DDR pool per socket — with a reconfigurable dataflow fabric and aggressive operator fusion moving work through them. It is aimed squarely at very large and mixture-of-experts models, where the DDR tier holds the parameters that are not currently active.

Honeycomb agrees about the capacity tier — large, cheap memory close to the machine is the right call for large models — and disagrees about the topology in front of it. A hierarchy places a narrower funnel between each tier and the compute; Honeycomb’s design rule is that decode bandwidth must exist at the resting place, so bulk memory is attached across the mesh edge and reached by the same explicit, capability-gated movement as everything else. There are costs, not tiers: local SRAM is cheap, a neighbour is a hop, DRAM is far — one flat namespace, one movement model.

Tenstorrent: the nearest physical relative

Tenstorrent builds the machine shape closest to Honeycomb’s: a mesh of uniform tiles, each with local SRAM, a matrix engine, and small RISC-V control cores, DRAM at the chip edge, Ethernet for scale-out, and an open-source software stack. Anyone asking “who else builds a flat tiled fabric with local memory and scalar control?” should be pointed there.

The separations are about what sits above and beneath that shape. Tenstorrent’s fabric is driven by a host through a conventional driver stack; Honeycomb is hostless from the mask ROM up — every cell carries the same boot ROM, the array self-boots, and there is no privileged controller to trust. Tenstorrent supports a menu of numeric formats; Honeycomb commits to block floating point as a proved contract, with the integer MAC identity and no-overflow bounds as theorems rather than test suites. And Tenstorrent’s openness is source availability — the RTL can be read; Honeycomb’s claim is machine-checked refinement — the RTL is generated from the same Lean definitions the theorems are about. Readable and proved are different properties, and the verification page is precise about which parts of Honeycomb have which.

The axis no one shares

Every machine above differentiates inside performance per dollar per watt, and each carries a trust story: Groq asserts determinism by construction, Tenstorrent publishes source, GPU vendors sign firmware. Honeycomb’s differentiated axis is that its trust story is the construction method itself: ISA semantics, cell implementations, mesh transport, and capability isolation defined in one Lean artifact, related by machine-checked refinement, with the SystemVerilog generated from the same definitions and no management engine or vendor blob anywhere in the chain. That property cannot be retrofitted to shipped silicon, and none of the machines above is built this way.

This is also why the comparison is stated carefully. On raw density Honeycomb does not claim to beat anyone; on decode latency and energy the claims are model targets pinned to recorded constants until silicon exists; on verifiability the claim is categorical, and the status page enumerates exactly which theorems back it.

What is not comparable today

Honesty about the current evidence, so the rows above are read at the right altitude:

• There is no Honeycomb silicon. The physical anchor is a generated cell routed in sky130 — 29 ns clock, with a streaming kernel datapath at 34.5 MMAC/s and ~59 pJ/MAC, activity-measured on the routed netlist. Those are open-PDK evidence points, not numbers to place beside shipping 4 nm datacenter parts.
• The recorded GPU comparison is deliberately narrow — same node, one model family — so it isolates architecture from process. It does not generalize to H100-class systems until the measurement plan produces the corresponding suites.
• Competitor figures here are publicly reported and approximate, from machines at different nodes, power classes, and maturity. They characterize architectural positions, not products.
• The projection ladder applies. The 16 nm test chip is where measured silicon replaces sky130 estimates; production-node claims are projections from measured 16 nm data, labeled as such, never sooner.

The one comparison that is fair today is the one this page actually makes: five architectures’ answers to where the weights rest and what evidence each machine ships about its own behavior. On the first, Honeycomb’s position is flat and cheap by construction. On the second, it is alone.