Groq LPU (Language Processing Unit, Tensor Streaming Processor)

NULL, AND HERE IS WHAT WAS LOOKED FOR (2026-10-05, non-GPU classification audit). groq.com/lpu-inference-engine publishes 'upwards of 80 terabytes/second' of on-chip SRAM bandwidth, and this field used to hold it. NULL FOR TWO INDEPENDENT REASONS, either of which is sufficient. (1) WRONG QUANTITY: it is SRAM bandwidth on a part Groq itself states has no off-chip HBM, so there is no memory-tier bandwidth for this field to hold. (2) NOT EXPRESSIBLE: 'upwards of' is a lower bound, and this field can hold neither a qualifier nor a bound. The sentence survives verbatim in sources vb-groq-lpu-80tbs-14nm and w4h-groq-lpu-inference-engine-80tbs-no-perchip-figure. NO FIGURE WAS BACK-COMPUTED. Note that Groq prints the 80 TB/s in the SAME SENTENCE as an 'about eight terabytes/second' GPU HBM figure - that adjacency is what makes this number look GPU-shaped, and reading it as GPU-shaped is the error being corrected.

AUDIT: status downgraded verified -> contested. Both sources are vendor/marketing blog posts (asic-groq-lpu-technology, asic-groq-nvidia-3lpx), no datasheet or independent benchmark, so the numeric claims are vendor-claim only. PARTIAL SPEC, and the reason for low confidence: Groq's own architecture page publishes no per-chip compute or memory-capacity figure at all. The 230 MB SRAM capacity, 188 TFLOPS FP16 and 750 TOPS INT8 recorded here come from press coverage of the original GroqChip (widely attributed to Groq's Hot Chips 2021 presentation) and are NOT confirmed on groq.com, which is why they are flagged vendor_claim false. Groq confirms only: on-chip SRAM, no off-chip HBM, 14 nm, and 80 TB/s SRAM bandwidth. GROQ HAS PUBLISHED SYSTEM-LEVEL THROUGHPUT FIGURES: Groq's own blog cites Artificial Analysis benchmarks showing 241 tokens per second and 0.8 seconds total response time for 100 output tokens. These are system-level inference throughput figures measured on Groq's cloud service, NOT per-chip compute specifications. They demonstrate that the SRAM-only architecture delivers competitive inference throughput despite the lack of published per-chip TFLOPS. THE ARCHITECTURAL POINT, which is what matters for inference: SRAM-only with no DRAM tier means there is no weight-streaming path. A model larger than 230 MB must be tiled across many chips and the tapeout is fixed at compile time, so the compiler statically schedules all data movement and the result is a deterministic assembly line with no dynamic scheduling, no cache misses and no variance. That is why Groq's headline latency figures hold under load, and also why a single-chip spec sheet is misleading: reported 70B-class configurations have needed on the order of hundreds of chips. Do not compare this record's flops against a GPU's flops as if capacity were comparable. On generation naming: Groq's own silicon is still the LPU line; 'Groq 3 LPX' is NVIDIA-branded silicon produced under the December 2025 non-exclusive licensing agreement with NVIDIA, so records for the two must not be conflated. Since that deal, NVIDIA has become a consumer of Groq IP and Groq an NVIDIA Cloud Partner, but Groq states its own roadmap and architecture remain Groq-led. === FIELDS CORRECTED 2026-10-05 (non-GPU classification audit, w7-nonxpu-computers). SAME DEFECT AS cerebras-wse-3, AND IT IS WORSE HERE BECAUSE OF WHERE THE 0.23 COMES FROM. === The existing notes already said 'The 230 MB SRAM capacity ... come[s] from press coverage of the original GroqChip ... and [is] NOT confirmed on groq.com' and that the 80 TB/s is 'SRAM bandwidth, not memory capacity bandwidth'. Both facts were correctly stated in prose while BOTH FIELDS kept the numbers. Three separate defects were stacked in those two fields: vram_gb: 0.23 -> null. 0.23 GB is on-chip SRAM, and the LPU has no DRAM tier, so it is not VRAM or HBM and does not belong in a field whose definition is 'HBM or VRAM per device/package'. It is ALSO unverified: source w4h-groq-lpu-inference-engine-80tbs-no-perchip-figure states in terms that 'the stored vram_gb 0.23 is NOT stated on this page anywhere. Groq publishes no SRAM capacity figure here. That value therefore has no vendor source and should be treated as unverified for the same reason the compute rows are.' So the field was both the wrong quantity AND unsourced. Two reasons to null it, either of which suffices. memory_bandwidth_gbps: 80000 -> null. This one needs the precision the source record itself supplies, because a bare number hides it: Groq's sentence is 'Groq on-chip SRAM has memory bandwidth upwards of 80 terabytes/second, while GPU off-chip HBM clocks in at about eight terabytes/second.' The value is a LOWER BOUND ('upwards of'), so the number cannot be represented faithfully in a field that can hold neither '>=' nor a qualifier. But that is the lesser problem. The greater problem is that it is SRAM bandwidth on a part with no off-chip memory at all, printed by Groq in the same sentence as a GPU HBM comparison - which is precisely the framing that makes it look like a drop-in GPU field. It is not. Groq is arguing that an LPU has no memory wall because it has no memory tier; storing 80000 next to a GPU's 3350 makes that argument read as 'this part has 24x an H100's bandwidth', which is a category error and a commercially misleading one. memory_bus_bit: already null, structurally - no DRAM tier means no memory bus. Stays null. tdp_w: already null. Groq publishes no per-chip TDP. Correct as null. THE GENERAL RULE THIS ESTABLISHES FOR THE WHOLE NON-GPU SET, stated because three records in this corpus hit it independently (this one, cerebras-wse-3, and d-matrix-corsair): on a part whose only memory is on-chip SRAM, vram_gb and memory_bandwidth_gbps are BOTH structurally inapplicable, and the honest value for both is null with the reason. The capacity now lives in onchip_cache.sram_mb below. Prose in notes does not achieve this, because notes are invisible to every numeric query, join and sort in the repo. WHY THE COMPUTE ROWS WERE LEFT ALONE, because it would be easy to 'fix' them by deleting and that would be wrong: the fp16 188 and int8 750 rows are already correctly marked basis 'unverified', vendor_claim false and source_id null, and the sources that establish they are unsourced (vb-groq-lpu-no-perchip-figures, w4h-groq-lpu-inference-engine-80tbs-no-perchip-figure) are already in the corpus. They are honest nulls-in-disguise: a value with a documented absence behind it. Deleting them would lose the record of WHAT WAS LOOKED FOR. They stay. WHAT REPLACES THE ROOFLINE READING, and it is the reason null beats a wrong number here: on an SRAM-only part there is no weight-streaming path, so 'bandwidth-bound decode' - the phrase this repo applies to almost every GPU - has no referent for an LPU. What limits an LPU is that a model larger than one chip's SRAM must be tiled across many chips with the schedule fixed at compile time, which is why Groq's reported 70B-class configurations have needed hundreds of chips and why its latency figures hold under load. That is a capacity-and-scheduling statement, not a roofline position, and no arithmetic-intensity number expresses it. === onchip_cache IS NULL ON THIS RECORD, AND THAT IS THE SCHEMA'S OWN RULE, NOT AN OMISSION (2026-10-05). === The 230 MB figure was moved here during this pass and then removed again, and the round trip is worth recording because the schema's field description is unusually explicit about it. schemas/accelerator.schema.json says of onchip_cache: 'DO NOT FILL A FIELD YOU DID NOT VERIFY against a first-party spec sheet, architecture whitepaper or vendor docs page: a null here is the correct value for a part whose on-chip hierarchy nobody publishes.' The enum enforces the same rule from the other side - onchip_cache.basis accepts only vendor-spec-sheet, vendor-whitepaper or vendor-docs, and there is deliberately no 'unverified' member, because a value with no first-party provenance is not admissible in this field at all. Groq publishes no SRAM capacity figure anywhere (established first-party-negative by source w4h-groq-lpu-inference-engine-80tbs-no-perchip-figure), so 230 MB cannot go here. WHERE THE 230 MB THEREFORE LIVES, and why that is not a loss: in these notes, at the same place it always was, with its provenance stated - press coverage of the original GroqChip, widely attributed to Groq's Hot Chips 2021 presentation, NOT confirmed on groq.com. It is now stated in a field that says what it is and in prose that says how confident it is, which is strictly better than the state this record was in before the audit, when 0.23 sat in vram_gb looking exactly like every GPU's VRAM. A reader who needs the number gets 230 MB and the words 'press-attributed, not vendor-published' in the same place; a reader who filters on vram_gb gets null, which is the truth about a part with no DRAM tier. BY CONTRAST, cerebras-wse-3 AND d-matrix-corsair DID GET onchip_cache ROWS in this pass, because for both of those the capacity IS first-party - 44 GB is printed on the CS-3 system page and the CS-3 datasheet, and 2 GB at 150 TB/s is printed in the d-Matrix white paper. Same audit, same field, different answers, and the difference is entirely whether a vendor published the number. That is the test. === vram_gb / memory_bandwidth_gbps NULLS RE-VERIFIED 2026-10-08 (w8-reverify) — BOTH HOLD. === Re-read the Groq LPU page live (https://www.groq.com/lpu-inference-engine/). The page carries exactly two hardware numbers and it was checked whether either licenses a memory field. (1) 'Groq on-chip SRAM has memory bandwidth upwards of 80 terabytes/second, while GPU off-chip HBM clocks in at about eight terabytes/second.' The 80 TB/s is SRAM bandwidth by Groq's own label, and the same page's design-principle 4 is the negative: 'LPUs include both memory and compute on-chip ... GPUs utilize separate high-bandwidth memory chips'. There is no off-chip HBM on this part, so there is no memory-tier bandwidth to put in memory_bandwidth_gbps. (2) 'Our current chip set is built on a 14 nanometer process.' Neither number is a DRAM or VRAM figure. (2a) The page publishes NO SRAM CAPACITY figure at all, which corroborates the repo's decision to leave onchip_cache NULL rather than fill it with the press-attributed 230 MB: the schema says a null there means 'not verified first-party', never zero, and this is exactly that case. CONCLUSION: groq-lpu is the clean case of the three. Unlike d-matrix-corsair, where the vendor publishes a real off-chip tier, Groq publishes none, so both nulls are correct and both stay. The pre-existing memory_type 'sram (on-chip only, no DRAM tier; capacity recorded in onchip_cache, not vram_gb)' reads slightly wrong given onchip_cache is in fact null - the capacity is NOT in onchip_cache on this record - and that wording is corrected here to say so, because a reader following it would look for a figure that is not there.