Huawei Ascend 910B

NOT VENDOR-PUBLISHED. Huawei has never released an Ascend 910B datasheet. This is the midpoint of the ~1.2-1.6 TB/s range reported by analysts and teardowns (aiwiki aggregation of SemiAnalysis, TechInsights and CSET). The 910B4 variant is a cut-down part with 32 GB and, per community kernel notes, ~800 GB/s - a factor of two against the main 910B. NOTE: the flops array now carries BOTH 320 and 600 alongside the central 376, because the two ends of that range come from different reporting chains and keeping only 376 would hide a real disagreement. These double as the basis for the 910C figures, which are 2x whatever is chosen here.

STATUS CONTESTED and low confidence because there is no primary source at all - every figure here is analyst estimate, teardown or supply-chain reporting. DISAGREEMENTS KEPT RATHER THAN RESOLVED: (1) BF16/FP16 compute is reported as ~320 TFLOPS, ~376 TFLOPS (SemiAnalysis), up to ~400, and up to ~600 in some supply-chain reporting; 376 is recorded as the central estimate and all four endpoints are retained in the flops array (320 and 600 tagged to cn-hisilicon-wikipedia, which is the aggregator naming those figures in-line with its WSJ and Tom's Hardware citations). (2) Memory is reported as 64 GB HBM2e on 910B1-910B3 but 32 GB on the 910B4 cut-down. (3) Bandwidth is given as a ~1.2-1.6 TB/s range with no agreed figure. (4) TDP is quoted as 310-400 W; 400 W recorded as the upper end. (5) PROCESS NODE, NOW BETTER EVIDENCED THAN THE NUMBERS: SMIC N+1 7 nm, against TSMC N7 on a comparable NVIDIA part - this rests on Huawei's own 2021 statements about dual-sourcing and on Tom's Hardware reporting, so it is firmer than any throughput figure here. Vendor is set to asic-other because 'huawei' is not in the schema enum; the real vendor is Huawei HiSilicon. THE HIERARCHY POINT: the memory story is what makes 910B interesting rather than the compute. 64 GB HBM2e at ~1.2-1.6 TB/s gives a BF16 intensity around 270-310 FLOP/byte, and its scale-up link HCCS is three ports at only 30 GB/s each - roughly 90 GB/s per chip of chip-to-chip bandwidth against H100's 450 GB/s of NVLink. That HCCS number is the real constraint: tensor parallelism across many chips is expensive, which is precisely why Huawei's systems scale out with many chips and why CloudMatrix-style rack designs emerged. For inference this part is bandwidth-bound at batch 1 with a weak scale-up path, and the software story is the binding constraint: CANN/MindIE rather than CUDA, with vLLM and torch_npu ports of varying maturity. Widely deployed in Chinese clusters under NVIDIA supply restrictions (Baidu, ByteDance, iFlytek) and used to train DeepSeek-family models. SUPPLY SCALE, WELL SOURCED: reported 2025 plans were over 800,000 units of 910B+910C combined, which makes this by far the highest-volume non-NVIDIA datacenter accelerator in the world - the volume contradicts any suggestion that it is a rounding error in the NVIDIA line, even though the per-part numbers are weak. 910C pairs two 910B dies in one package (see huawei-ascend-910c), and the successor generation is the 950DT (see huawei-ascend-950dt), which replaces HBM2e with Huawei-developed on-chip memory and is the first Ascend part with a genuinely competitive scale-up link. Note that the successor's interconnect is the fix for the defect identified above, which is the clearest available evidence that the HCCS bottleneck was real and not an artifact of analyst estimate. 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.