d-Matrix Corsair

NULL, AND HERE IS WHAT WAS LOOKED FOR (2026-10-05, non-GPU classification audit). The d-Matrix white paper (source w7z-dmatrix-whitepaper-full) publishes TWO distinct bandwidths for this card and this field used to hold the wrong one. (1) '2 GB on-chip integrated Performance Memory at 150 TB/s memory bandwidth' - the ON-CHIP tier. (2) The 8-card reference server table: 'Performance Memory 16 GB, 1200 TB/s' and 'Capacity Memory Up to 2 TB, 3.2 TB/s' - so the off-chip LPDDR5 Capacity Memory tier runs at about 3.2/8 = 400 GB/s PER CARD. NULL because a two-tier part has no single value for a field that every GPU record uses to mean off-package memory bandwidth: the 150 TB/s is an order of magnitude off the quantity that bounds weight streaming and would make this card appear to have 25x an H100's bandwidth. The on-chip figure is preserved in onchip_cache.sram_mb's source_note and in the two source records; the Capacity Memory tier is LPDDR5 per the white paper ('The off-chip LPDDR5 Capacity Memory enables GenAI workloads in offline batched inference use cases'). NO FIGURE WAS BACK-COMPUTED for a per-card Capacity Memory bandwidth: the vendor publishes only the 8-card aggregate, so 400 is named here as an aggregate division and NOT stored as this field's value. RESTORED VRAM_GB = 256 (2026-10-08, wave 8 re-verification, PR #33). An earlier pass nulled this field on the theory that the Corsair has no DRAM tier. That was wrong and is now corrected: the vendor DOES publish off-chip capacity. The white paper's opening paragraph states 'up to 256 GB off-chip Capacity Memory' per card, confirmed independently from the same document's 8-card row 'Capacity Memory Up to 2 TB' divided by 8. Null left this card looking like it holds 2 GB - a 128x understatement of capacity, implying a part whose entire use case is holding a large model cannot hold one. The 2 GB on-chip Performance Memory stays in onchip_cache.sram_mb and is NOT summed into this field: vram_gb is the off-chip Capacity Memory tier, the tier that actually holds model weights. memory_bandwidth_gbps stays null (see above), so a reader cannot mistake a terrabyte-scale figure for this part's streaming bound.

REAL VENDOR: d-Matrix (d-matrix.ai). Set to 'asic-other' because the schema enum does not include 'd-matrix'. d-Matrix Corsair is a digital in-memory compute inference accelerator that entered full production in June 2026, with volume shipping to priority customers. The architecture uses chiplet design with 256 MB SRAM per die, 2,048 MAC arrays, and digital in-memory computing to eliminate the memory wall. The key innovation is the two-tier memory system: 2 GB of on-chip integrated Performance Memory at 150 TB/s (an order of magnitude above HBM) plus up to 256 GB of off-chip Capacity Memory. The card is a full-height full-length PCIe 5.0 x16 card with CXL 2.0 support. The compute is block-scaled integer (MXINT8/MXINT4), not floating-point — this is deliberately aimed at weight-only quantization for LLM inference. The white paper states peak dense compute of 2,400 TFLOPS for MXINT8 and 9,600 TFLOPS for MXINT4 equivalent. TDP is not published at the card level; the white paper mentions <5W per die but the card contains multiple dies. The product brief mentions 1 pJ/MAC-class efficiency. Corsair is aimed at datacenter inference for LLMs and is NOT a training chip. The company was founded by Sudeep Bhoja and Sid Sheth, both former Wave Computing executives. Process node is 7nm. The chiplet approach allows scaling to larger systems via die-to-die interconnects. RESOLVED (2026-10-04 cross-reference repair): interconnect value 'cxl' -> cxl-2-0, on this record's own statement that the card is 'a full-height full-length PCIe 5.0 x16 card with CXL 2.0 support'. The repo holds cxl-2-0, cxl-3-x and cxl-4-0 as separate records and the version is named here, so the choice is forced by context. === FIELDS CORRECTED 2026-10-05 (non-GPU classification audit, w7-nonxpu-computers). A THIRD INSTANCE OF THE cerebras/groq FALSE FRIEND, AND IT HAD NOT BEEN CAUGHT BY EITHER EARLIER PASS. === The repo's own notes on this record said 'The key innovation is the two-tier memory system: 2 GB of on-chip integrated Performance Memory at 150 TB/s ... plus up to 256 GB of off-chip Capacity Memory' - which is the diagnosis - and then left vram_gb at 2 and memory_bandwidth_gbps at 150000 anyway. Both fields were wrong in opposite directions from the same cause. vram_gb: 2 -> null. 2 GB is the on-chip Performance Memory tier ONLY. The white paper's own 8-card server table prints 'Performance Memory 16 GB, 1200 TB/s' and 'Capacity Memory Up to 2 TB, 3.2 TB/s' as two separate rows (source w7z-dmatrix-whitepaper-full). So this card has a capacity tier of up to 256 GB of off-chip LPDDR5 that the record's own memory_type string mentions and that vram_gb cannot express, and it stored the 2 GB tier in a field defined as 'HBM or VRAM per device/package'. A reader asking 'how much memory fits on this card' got 2, which is off by a factor of up to 128. memory_bandwidth_gbps: 150000 -> null. 150 TB/s is the on-chip Performance Memory tier's bandwidth. The card's actual off-chip Capacity Memory bandwidth is about 400 GB/s per card (3.2 TB/s / 8 cards in the vendor's own server table). Filing 150000 GB/s makes this card look 25x an H100's memory bandwidth, which is exactly the reading the vendor's architecture is designed to make defensible for the ON-CHIP TIER and that is meaningless for the part as a serving device. 150000 is not a small correction to 400; it is a different memory system. What is NOT lost: 2 GB / 150 TB/s is now in onchip_cache below, where the field name states what it is. The Capacity Memory tier's per-card capacity and bandwidth are recorded in memory_bandwidth_basis and notes, with the vendor's own 'up to 256 GB' qualifier intact. WHY THIS RECORD IS THE MOST INTERESTING CASE IN THE AUDIT, and why it needed the white paper rather than the product brief: unlike cerebras and groq, d-Matrix is NOT an SRAM-only part - it has a genuine two-tier hierarchy with a real off-chip DRAM tier, and a first-party per-tier bandwidth for each. That makes it the only record in this corpus where a reader could compute a defensible roofline position, and it is the record where filing the fast tier in the field meant for the slow tier did the most damage. The rule that generalises: on ANY part with an on-chip tier in front of (or alongside) an off-package tier, memory_bandwidth_gbps must hold the OFF-PACKAGE tier's bandwidth, because that is the quantity every GPU field of that name means and the only one that bounds weight streaming. This is the same rule that keeps AMD's Infinity Cache (kind 'llc-in-front-of-hbm') out of a bandwidth comparison in the repo's own onchip_cache schema description, applied here to a part the schema description does not mention. WHAT IS ADDED, from the white paper's numerics table, which the record was missing: an int16 row at 600 TFLOPS for MXINT16. The vendor prints all three of MXINT16 600, MXINT8 2400, MXINT4 9600 and the record held only the last two. The vendor's own footnote matters for all three: '*Both weights and activations in same format. TOPS can be higher with mixed precision. For example, MXINT4 weights and MXINT8 activations can provide 4800 TOPS.' So 9600 is a same-format figure and must not be halved or doubled for a mixed-precision deployment. STILL NULL, and why, named so a future pass does not re-derive them: memory_bus_bit (no bus width published for either tier; not back-computed from the 3.2 TB/s server figure), tdp_w (the white paper gives no card-level TDP), and the per-card Capacity Memory bandwidth (the vendor publishes only the 8-card aggregate). The 'up to 256 GB' capacity is a ceiling, not a firm figure, and is stored as a qualifier rather than as vram_gb. === SOURCE DECLARED 2026-10-08 (w8-reverify). === flops[].source_id cited 'w7z-dmatrix-whitepaper-full' on 1 row(s), and that source file exists and was read — but it was never added to this record's sources[], so the figure carried per-row provenance that the record-level source list did not back. AGENTS.md rule 2 requires every cited source to be resolvable, and it was, but the reverse held too: a source a record actually cites is a source the record must declare. Added now. No number changed. validate.py has never caught this class of defect — it checks that sources[] entries resolve, never that a cited source_id appears in sources[] — which is why 121/121 tests passed over it. === vram_gb RESTORED 2026-10-08 (w8-reverify) — THE 2026-10-05 CORRECTION OVER-NULLED THIS FIELD. === THE 2026-10-05 NON-GPU AUDIT set vram_gb 2 -> null on the theory that a two-tier part has no single value for a field every GPU record uses to mean off-package memory. The classification argument is right for the BANDWIDTH field and it is stated correctly there and was left standing. It is WRONG for the CAPACITY field, and the reason is that the vendor does publish a single off-chip capacity for this part: the white paper's opening paragraph, verbatim and re-read live 2026-10-08, says Corsair packs '2 GB on-chip integrated Performance Memory at 150 TB/s memory bandwidth, and up to 256 GB off-chip Capacity Memory'. The architecture section confirms the technology: 'The off-chip LPDDR5 Capacity Memory enables GenAI workloads in offline batched inference use cases' and 'Each chiplet has ... two LPDDR interfaces'. So this is NOT an SRAM-only part like cerebras-wse-3 or groq-lpu, where the null is correct because no off-chip tier exists at all - the audit's own note recorded the distinction ('This is not an SRAM-only part - it has a real off-chip LPDDR5 Capacity Memory tier') and then nulled both fields anyway. VERIFIED TWO WAYS FROM ONE DOCUMENT: (a) the per-card prose says 'up to 256 GB off-chip Capacity Memory'; (b) Table 2, the 8-card reference server, says 'Capacity Memory Up to 2 TB', and 2048 / 8 = 256 GB per card. Both land on 256. NO FIGURE WAS BACK-COMPUTED from any other quantity - this is the vendor's own per-card capacity. WHAT RESTORING IT DOES AND DOES NOT CHANGE. The null left this card looking like it held 2 GB, which understates its capacity by 128x - a reader would have concluded a card that holds up to 256 GB could not serve a 70B model, which is false and is the card's entire use case. It does NOT make 150 TB/s a bandwidth figure again: the on-chip Performance Memory tier is 2 GB at 150 TB/s and the off-chip Capacity Memory tier is 256 GB at a much lower, UNPUBLISHED rate (the white paper gives only the 8-card aggregate 'Capacity Memory Up to 2 TB, 3.2 TB/s'), so memory_bandwidth_gbps STAYS NULL and its basis is unchanged. vram_gb is now the off-chip tier; onchip_cache.sram_mb is still the on-chip tier at 2.0. The two fields now answer the two different questions they are named for, which is the state the 2026-10-05 pass was trying to reach and did not reach. THE 'up to' IS A VENDOR CEILING AND IS RECORDED AS ONE: d-Matrix does not publish a firm per-card number, so 256 is the ceiling, not a guaranteed configuration. The same convention this repo already uses for nvidia-b300's 'up to' framing. Do not treat this as a floor.