inference/research
contestedlow · 0.45updated 2026-10-08

Huawei Ascend 910C (dual-910B package)

asic-other da-vinci (dual 910B chiplet) 2025

Fields

id
accelerators/huawei-ascend-910c
Vendor
asic-other
Architecture
da-vinci (dual 910B chiplet)
Release year
2025
Process (nm)
7
Form factors
oammcm
VRAM (GB)
128
Memory type
hbm2e
Memory bandwidth (GB/s)
3,200
Bandwidth basis
PER CHIP, FROM SEMIANALYSIS TEARDOWN AND HUAWEI CONNECT 2025 KEYNOTE. SemiAnalysis teardowns confirm 128 GB of HBM2e across 8 stacks delivering 3.2 TB/s of memory bandwidth (per Huawei Connect 2025 keynote, cited by flopper.io). This is a significant upgrade from the 910B's contested ~1.2-1.6 TB/s. The 3.2 TB/s figure is more authoritative than the 2x-scaled 910B figure because it comes from a teardown and a Huawei keynote rather than arithmetic on a disputed base. Source: cn-huawei-cloudmatrix384 (arXiv:2506.12708v1).
Peak FLOPS
precisionfp16tflops800denseyesvendor_claimnosource_idcn-huawei-cloudmatrix384basisvendor-whitepaperbasis_detailSecond-hand figure, not a first-party spec: the source of record is 'Huawei CloudMatrix 384 (CM384) supernode — system architecture and specifications' (kind: whitepaper). Recorded dense:true as printed.precisionbf16tflops780denseyesvendor_claimnosource_idcn-huawei-cloudmatrix384basisvendor-whitepaperbasis_detailSecond-hand figure, not a first-party spec: the source of record is 'Huawei CloudMatrix 384 (CM384) supernode — system architecture and specifications' (kind: whitepaper). Recorded dense:true as printed.precisionint8tflops1,600denseyesvendor_claimnosource_idcn-huawei-cloudmatrix384basisvendor-whitepaperbasis_detailSecond-hand figure, not a first-party spec: the source of record is 'Huawei CloudMatrix 384 (CM384) supernode — system architecture and specifications' (kind: whitepaper). Recorded dense:true as printed.
TDP (W)
600
Unified memory
no
Consumer part
no
notes
THE HIERARCHY POINT: the 910C is not a new chip, it is two 910B dies in one package, which is the single most important structural fact about it and the reason its numbers must never be quoted without the word 'dual'. FIGURES UPDATED 2026-10-03: The flops and memory figures have been upgraded from the disputed 2x-scaled 910B estimates to SemiAnalysis teardown figures (800 TFLOPS FP16, 780 TFLOPS BF16, 1600 TOPS INT8, 3.2 TB/s HBM2e) and the TDP from the flopper.io estimate of 600 W. These are more authoritative than the previous 2x-scaled figures because they come from a teardown and a Huawei Connect 2025 keynote rather than arithmetic on a disputed base. The 910C supports FP32, HF32, FP16, BF16, and INT8 - but no native FP8 or FP4 (that arrives with the 950 generation). Process is SMIC N+2 (a second-generation 7 nm), against N+1 for the 910B. THE ONE FIGURE THAT IS NOT DERIVED AND IS MORE TRUSTWORTHY THAN ANY SPEC IS THE MEASURED ONE: DeepSeek researchers, who have no commercial interest in flattering Huawei, put 910C inference at roughly 60% of H100 inference performance, and DeepSeek-R1 was trained on H800 and runs inference on 910C. That 60% is a whole-system, real-model, real-workload number and should be weighted far above the 800 TFLOPS. The resulting tension is the real story: theoretical compute on paper is close to H100-class but measured inference efficiency is 60%, and the gap is the scale-up fabric. Huawei's answer to that gap was to stop trying to scale chips and start buying optical bandwidth - CloudMatrix 384 ships 384 910C chips across 16 racks (12 compute, 4 network) using 6912 800G LPO optical transceivers for entirely optical intra- and inter-rack connectivity. The UB interconnect provides 196 GB/s per NPU unidirectional, which is 2.2x the 910B's HCCS but still only 0.061 of the 3.2 TB/s local memory bandwidth. Reported 2025 shipment plans were over 800,000 units of 910B+910C combined. Vendor is 'asic-other' because 'huawei' is not in the schema enum; the real vendor is Huawei HiSilicon. Software stack is CANN/MindSpore (see cn-huawei-cann-mindspore). 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: the 910C is not a new chip, it is two 910B dies in one package, which is the single most important structural fact about it and the reason its numbers must never be quoted without the word 'dual'. FIGURES UPDATED 2026-10-03: The flops and memory figures have been upgraded from the disputed 2x-scaled 910B estimates to SemiAnalysis teardown figures (800 TFLOPS FP16, 780 TFLOPS BF16, 1600 TOPS INT8, 3.2 TB/s HBM2e) and the TDP from the flopper.io estimate of 600 W. These are more authoritative than the previous 2x-scaled figures because they come from a teardown and a Huawei Connect 2025 keynote rather than arithmetic on a disputed base. The 910C supports FP32, HF32, FP16, BF16, and INT8 - but no native FP8 or FP4 (that arrives with the 950 generation). Process is SMIC N+2 (a second-generation 7 nm), against N+1 for the 910B. THE ONE FIGURE THAT IS NOT DERIVED AND IS MORE TRUSTWORTHY THAN ANY SPEC IS THE MEASURED ONE: DeepSeek researchers, who have no commercial interest in flattering Huawei, put 910C inference at roughly 60% of H100 inference performance, and DeepSeek-R1 was trained on H800 and runs inference on 910C. That 60% is a whole-system, real-model, real-workload number and should be weighted far above the 800 TFLOPS. The resulting tension is the real story: theoretical compute on paper is close to H100-class but measured inference efficiency is 60%, and the gap is the scale-up fabric. Huawei's answer to that gap was to stop trying to scale chips and start buying optical bandwidth - CloudMatrix 384 ships 384 910C chips across 16 racks (12 compute, 4 network) using 6912 800G LPO optical transceivers for entirely optical intra- and inter-rack connectivity. The UB interconnect provides 196 GB/s per NPU unidirectional, which is 2.2x the 910B's HCCS but still only 0.061 of the 3.2 TB/s local memory bandwidth. Reported 2025 shipment plans were over 800,000 units of 910B+910C combined. Vendor is 'asic-other' because 'huawei' is not in the schema enum; the real vendor is Huawei HiSilicon. Software stack is CANN/MindSpore (see cn-huawei-cann-mindspore). 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)