inference/research
verifiedmedium · 0.75updated 2026-10-08

Huawei CloudMatrix 384 (CM384) supernode — 384x Ascend 910C

asic-other da-vinci (dual 910B chiplet per NPU, 384 NPUs) 2025

Fields

id
accelerators/huawei-ascend-910c-cloudmatrix-384
Vendor
asic-other
Architecture
da-vinci (dual 910B chiplet per NPU, 384 NPUs)
Release year
2025
Process (nm)
7
Form factors
rack-scale
VRAM (GB)
49,152
Memory type
hbm2e
Memory bandwidth (GB/s)
1,228,800
Bandwidth basis
AGGREGATE SYSTEM FIGURE. 384 x 128 GB = 49,152 GB (48 TB) total HBM; 384 x 3.2 TB/s = 1,228.8 TB/s aggregate memory bandwidth. Per-NPU: 128 GB at 3.2 TB/s. Source: Huawei CloudMatrix384 engineering paper arXiv:2506.12708v1 (cited by flopper.io) and China Research Collective analysis.
Peak FLOPS
precisionbf16tflops307,200denseyesvendor_claimyessource_idcn-huawei-cloudmatrix384basisderivedbasis_detailSYSTEM figure from arXiv:2506.12708v1 (~300 PFLOPS BF16 dense for 384 NPUs = 781 TFLOPS/NPU), recorded at system scale, not per chip. Read as an aggregate; dividing by 384 gives ~780 per NPU. The China Research Collective analysis gives ~289 PFLOPS for the same system - the two are kept rather than resolved.precisionfp16tflops307,200denseyesvendor_claimyessource_idcn-huawei-cloudmatrix384basisderivedbasis_detailSYSTEM figure from arXiv:2506.12708v1 (~300 PFLOPS BF16 dense for 384 NPUs = 781 TFLOPS/NPU), recorded at system scale, not per chip. Read as an aggregate; dividing by 384 gives ~780 per NPU. The China Research Collective analysis gives ~289 PFLOPS for the same system - the two are kept rather than resolved.precisionint8tflops614,400denseyesvendor_claimyessource_idcn-huawei-cloudmatrix384basisderivedbasis_detailSYSTEM figure from arXiv:2506.12708v1 (~300 PFLOPS BF16 dense for 384 NPUs = 781 TFLOPS/NPU), recorded at system scale, not per chip. Read as an aggregate; dividing by 384 gives ~780 per NPU. The China Research Collective analysis gives ~289 PFLOPS for the same system - the two are kept rather than resolved.
TDP (W)
559,000
Unified memory
yes
Consumer part
no
notes
THE HIERARCHY POINT: CloudMatrix 384 is not a chip but a rack-scale system — 384 Ascend 910C NPUs across 16 racks (12 compute, 4 network) with 192 Kunpeng CPUs, connected via Huawei's Unified Bus (UB) for fully non-blocking all-to-all interconnect. This is Huawei's answer to the Ascend 910B's HCCS scale-up problem: instead of making the chip-to-chip fabric faster, they bought optical bandwidth at the system level. SYSTEM FIGURES (vendor-published, arXiv:2506.12708v1): ~300 PFLOPS BF16 dense, 48 TB HBM, 559 kW system power. The China Research Collective analysis (June 2026) gives slightly different figures: ~289 PFLOPS BF16, 48 TB HBM, 350-500 kW. The discrepancy is likely measurement vs. theoretical peak. UB INTERCONNECT: 196 GB/s unidirectional per NPU (7 x 224 Gbps transceivers per NPU), with L1 on-board switching (7 UB Switch chips per node) and L2 rack-level switching (112 L2 UB switch chips across 4 communication racks). Scale-out is 200 Gbps RoCE RDMA per NPU (76.8 Tbps total). The system uses 6,912 800G LPO optical transceivers for entirely optical intra- and inter-rack connectivity. DEEPSEEK V4 PRO INFERENCE: 6,688 tokens/s/NPU prefill, 1,943 tokens/s/NPU decode — reportedly exceeding H100/H800 under the same conditions. At TPOT < 50 ms, CM384 maintains 538 tokens/s/NPU while H100/H800 drop to 30-40% of peak. The 128 GB HBM per NPU (60% more than H100/H800's 80 GB) allows larger models or longer context. Vendor is 'asic-other' because 'huawei' is not in the schema enum; the real vendor is Huawei HiSilicon. 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.

Notes

THE HIERARCHY POINT: CloudMatrix 384 is not a chip but a rack-scale system — 384 Ascend 910C NPUs across 16 racks (12 compute, 4 network) with 192 Kunpeng CPUs, connected via Huawei's Unified Bus (UB) for fully non-blocking all-to-all interconnect. This is Huawei's answer to the Ascend 910B's HCCS scale-up problem: instead of making the chip-to-chip fabric faster, they bought optical bandwidth at the system level. SYSTEM FIGURES (vendor-published, arXiv:2506.12708v1): ~300 PFLOPS BF16 dense, 48 TB HBM, 559 kW system power. The China Research Collective analysis (June 2026) gives slightly different figures: ~289 PFLOPS BF16, 48 TB HBM, 350-500 kW. The discrepancy is likely measurement vs. theoretical peak. UB INTERCONNECT: 196 GB/s unidirectional per NPU (7 x 224 Gbps transceivers per NPU), with L1 on-board switching (7 UB Switch chips per node) and L2 rack-level switching (112 L2 UB switch chips across 4 communication racks). Scale-out is 200 Gbps RoCE RDMA per NPU (76.8 Tbps total). The system uses 6,912 800G LPO optical transceivers for entirely optical intra- and inter-rack connectivity. DEEPSEEK V4 PRO INFERENCE: 6,688 tokens/s/NPU prefill, 1,943 tokens/s/NPU decode — reportedly exceeding H100/H800 under the same conditions. At TPOT < 50 ms, CM384 maintains 538 tokens/s/NPU while H100/H800 drop to 30-40% of peak. The 128 GB HBM per NPU (60% more than H100/H800's 80 GB) allows larger models or longer context. Vendor is 'asic-other' because 'huawei' is not in the schema enum; the real vendor is Huawei HiSilicon. 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.

Cross-references

Interconnect (2)