Huawei Ascend 910D

THE HIERARCHY POINT: THIS RECORD IS DELIBERATELY ALMOST EMPTY, and that is the honest finding rather than a gap in the research. 910D is a part I can substantiate EXISTENCE for but not SHIPPING, and the distinction matters: the only traceable public reporting is a WSJ story carried in cn-hisilicon-wikipedia stating that in late April 2025 Huawei approached several China-based companies to begin TESTING 910D, with first samples expected in May 2025. Sampling to a handful of integrators is not volume shipment. No specification of any kind has been published by Huawei, no compute figure, no memory figure, no die size, no process node, and no independent teardown exists - unlike the 910B, which at least drew SemiAnalysis and TechInsights attention. Every field above is None because every field is unknown, and inventing a plausible number here would be the exact failure mode this record exists to prevent. What can be said with evidence: 910D occupies the slot immediately after 910C and before the announced Ascend 920 (SMIC 6 nm, HBM3 at 4 TB/s, 900 TFLOPs per card, announced April 2025 for late-2025 production - and note even the 920's figures are announcement claims with no shipped product behind them as of the access date). If 910D is sampling and the 920 is announced, the plausible read is that 910D is a 7 nm N+2-family refinement sold into 2025 while the 920 is the 6 nm jump. Treat this record as an open question, revisit if Huawei publishes or a teardown appears. 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.