Huawei Atlas 800I A2 inference server (8x Ascend 310-series)

PER NPU, and stated as an aggregate by the server: the Atlas 300I Pro-class 310-series memory subsystem is 384-bit 4266 Mbit/s LPDDR4X = 204.8 GB/s per processor (cn-huawei-atlas-300i-pro-spec), and the 800I A2 carries 8 of them. The server guide confirms the host-side budget explicitly - 'The total bidirectional interconnection bandwidth between four CPUs and eight NPUs is 512 GB/s', i.e. 64 GB/s of PCIe 4.0 x16 per NPU - which is the only interconnect number Huawei publishes for this box. NO chip-to-chip HCCS FIGURE IS PUBLISHED for this generation, unlike the 910 line.

THE HIERARCHY POINT: the part that matters structurally is not the NPU, it is that the 8 x 64 = 512 GB/s of aggregate PCIe host bandwidth sits ABOVE the 8 x 204.8 = 1638 GB/s of memory bandwidth by a factor of 3.2, i.e. the scale-out path is proportionally healthier than the scale-up path on this box, the inverse of the usual GPU situation and the same pathology as the 910B (HCCS at ~90 GB/s per chip against 1.4 TB/s of HBM). Because 310-series parts have no meaningful chip-to-chip link at all, a model spanning all 8 NPUs shards entirely over PCIe and RoCE. Huawei confirms the scale-out side is a direct-attach 200GE QSFP RoCE fabric. The three NPU variants are 32 GB HCCS, 32 GB PCIe and 64 GB HCCS (PCI ID 0x19E5:0xD802, subsystem IDs 0x3002/0x3004/0x3005) - note that the HCCS and PCIe-binned 32 GB parts are the same capacity with a different scale-up attachment, which is the clearest evidence in the whole Ascend line that HCCS is a binning option rather than a fixed property of the die. Server: 4U, four Kunpeng 920 CPUs (64 cores at 3.0 GHz or 48 at 2.6 GHz), 32 DDR4 slots at up to 3200 Mbit/s, eight hot-swap fans with N+1, ~350 W per NPU module. Video decode equivalent to 480x 1080p. Because every NPU is LPDDR-backed, the server has 256 GB of NPU memory against no HBM anywhere, so this is a capacity-dense, bandwidth-poor configuration - the opposite of a GB200 NVL72 or an H200 node, and the honest characterisation is that it wins on how much model you can hold, not on how fast you can stream it. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). Huawei's own Atlas/Ascend spec pages and the CloudMatrix 384 whitepaper publish capacity, bandwidth and topology but no memory-bus width in bits and no per-pin rate. Not back-computed: the bandwidth figures on this family are already partly derived from secondary sources, and stacking a second inference on a derived aggregate would compound two guesses. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch.