Groq LPU chip-to-chip network

NULL - deliberately, and this is a sourcing limitation rather than a judgement about the part. Groq's own architecture page states the LPU's four design principles, one of which is 'Deterministic compute and networking', and confirms the on-chip SRAM bandwidth of upwards of 80 TB/s - but it publishes NO chip-to-chip link rate, no port count and no per-direction figure. Groq publishes no LPU datasheet, so there is no primary document from which a fabric rate could be taken. Rather than import a number from a GroqCloud marketing claim about system-level scale-out or infer one from the SRAM bandwidth, every quantitative field that would require such a figure is left null.

Not published. What IS published is the determinism property: because Groq statically schedules all data movement at compile time, the multi-chip topology is fixed at tapeout rather than dynamically routed, so there are no dynamic scheduling stalls and no cache misses across chips. That architectural property is the load-bearing claim here and it is qualitative - the vendor asserts it, but no link rate, latency or topology diagram is given.

None published.

The multi-chip link for the LPU, and the record that documents a KNOWN GAP rather than filling it. SOURCING LIMITATION, stated up front: Groq publishes no per-chip compute figure, no memory capacity figure and no interconnect figure on groq.com. The 230 MB SRAM, 188 TFLOPS FP16 and 750 TOPS INT8 on the accelerator record all come from press coverage of the Hot Chips 2021 presentation and are flagged vendor_claim false for that reason; the 80 TB/s SRAM bandwidth IS on groq.com. This interconnect record inherits the same limitation, so it is draft at low confidence and every rate field is null. WHAT IS SAFE TO SAY, from Groq's own words: the architecture's fourth principle is 'Deterministic compute and networking', and the compiler statically schedules all data movement, producing what Groq calls a programmable assembly line. For a reader choosing a fabric this is the relevant distinction - the claim is about predictability, not about bandwidth. INFERENCE RELEVANCE, and it cuts against the usual grain: with on-chip SRAM only and no off-package memory tier, weight streaming is impossible, so a model larger than 230 MB must be tiled across chips. Because that tiling is fixed at compile time rather than scheduled dynamically, the partitioning is a compile-time decision that cannot adapt to a changing batch size or a KV cache that grows during a long context - which is a real constraint on serving behaviour that has nothing to do with link bandwidth. A reader optimising Groq deployments should therefore think about placement and tiling at compile time, not about fabric tuning, because there is no fabric tuning surface exposed. TO RESOLVE: find a Groq LPU datasheet or a GroqCloud architecture publication stating chip-to-chip bandwidth, port count and topology, then fill bandwidth_gbps with the direction convention stated and link_count. Until then do not quote a Groq fabric rate from a system-level throughput claim - system throughput is a model-and-batch quantity and is not a link rate. KIND: filed as 'other' because the Groq chip-to-chip network has no entry in the schema's interconnect enum and no analogue in the named families. 2026-10-10: set null_bandwidth=sourcing. The record's own basis/notes already establish the reason; the field only names the case the schema now distinguishes. No number changed.