inference/research
verifiedhigh · 0.85updated 2026-10-05

Huawei UB Link 2.0 (Ascend 950DT scale-up / unified addressing)

392.0 GB/s

Fields

id
interconnect/huawei-ub-link
Kind
other
Version
UB Link 2.0, Ascend 950DT generation (Atlas 650E 8-NPU, Atlas 950 SuperPoD 64-NPU, 1024-NPU pod)
Bandwidth (GB/s, per link, unidirectional)
392
Bandwidth basis
PER NPU, PER DIRECTION, INTRA-SERVER (8-NPU Atlas 650E) - the larger figure in topology is the 16-NPU full-mesh case. DIRECTION IS STATED BY HUAWEI, which is what makes this record usable and is the reason it is filed at confidence 0.8 rather than contested. The Atlas 650E page (cn-huawei-atlas-650e-spec) gives UB Link as '8 x 784 GB/s BIDIRECTIONAL intra-server' and '2 x 8 x 1.68 TB/s (bidirectional)' for the 16-NPU full-mesh, so the recorded value is 784 / 2 = 392 GB/s per direction per NPU for the 8-NPU configuration. === THE PER-LINK / PER-NPU / PER-SYSTEM SEPARATION, WHICH IS THE POINT OF THIS RECORD (audited 2026-10-05) === HUAWEI PUBLISHES NO PER-LINK FIGURE AT ALL. Not for UB Link 2.0, not for UB, not for HCCS. Every Huawei UB number on every product page is a SUM - either per NPU or per system - and the single most common error in reading these pages is to treat one as a per-link rate. The three levels that must be kept apart: (1) PER LINK: NOT PUBLISHED. No lane count, no signalling rate, no per-port figure exists in any Huawei source. Any per-link number quoted for UB Link is this repo's invention or a third party's. bandwidth_gbps here is therefore NOT a per-link figure despite the schema's field description ('per link, unidirectional'), and the *_basis field is the only place that override can live. (2) PER NPU: what Huawei actually publishes. Two rates, both labelled bidirectional. Intra-server 8-NPU Atlas 650E: '8 x 784 GB/s', i.e. 784 GB/s per NPU bidirectional = 392 GB/s per direction (the recorded value). 16-NPU full-mesh: 1.68 TB/s per NPU bidirectional = 840 GB/s per direction. Note the rate roughly DOUBLES from 8 to 16 NPUs, so 'the per-NPU UB Link bandwidth' is not a single number even within one product generation. (3) PER SYSTEM: '8 x 784 GB/s' = 6.272 TB/s bidirectional intra-server (8 x 784 / 1000). '2 x 8 x 1.68 TB/s' = 26.88 TB/s bidirectional for the 16-NPU full-mesh, and the SuperPoD's 64-NPU cabinet is '64 x 1.68 TB/s' = 107.52 TB/s bidirectional. === HUAWEI'S OWN BULLET PROVES THE DIRECTION, AND THIS IS THE STRONGEST EVIDENCE IN THE RECORD === The Atlas 650E page carries a prose bullet that the spec table does not: 'Provide 13.4 TB/s UB Link bandwidth per server (16-NPU FM)'. Compare it with the table's '2 x 8 x 1.68 TB/s (bidirectional)' = 26.88 TB/s. 26.88 / 2 = 13.44, which rounds to the 13.4 TB/s Huawei prints. HUAWEI'S OWN PROSE FIGURE IS THEREFORE THE UNIDIRECTIONAL SUM OF ITS OWN BIDIRECTIONAL TABLE FIGURE. That is a vendor-internal reconciliation of the direction convention and it is stronger than any inference this repo could make: 'bidirectional' on the Atlas 650E means what it says, and the 392 GB/s per direction recorded here is half of a table figure Huawei itself halves in prose. Anyone who halves the 784 again, or who treats 13.4 TB/s as bidirectional, is wrong in opposite directions. === THE 1.72 PB/s POD FIGURE, AND WHY IT IS FLAT RATHER THAN GROWING === The SuperPoD page states both '1024 NPUs with 1.72 PB/s UB Link bandwidth' and, for the 64-NPU cabinet, '64 x 1.68 TB/s (bidirectional)'. Dividing the pod figure by the NPU count: 1.72 PB/s / 1024 = 1.6797 TB/s per NPU, which is 1.68 TB/s to three significant figures. THAT IS EXACTLY THE 16-NPU FULL-MESH PER-NPU RATE. So Huawei holds the per-NPU rate FLAT at 1.68 TB/s bidirectional (840 GB/s per direction) from the 16-NPU full-mesh through the 64-NPU cabinet to the 1024-NPU pod, and the pod total grows purely by adding NPUs: 1.72 PB/s is 1024 x 1.68 TB/s and nothing else. The earlier reading of this field rounded 1.72 PB/s / 1024 to '1.72 TB/s per NPU' and concluded the rate was 'essentially flat' - the conclusion was right but the arithmetic was not, and the corrected division is what shows the flatness exactly rather than approximately. A pod-level aggregate divided by NPU count is safe HERE ONLY because the per-NPU figure is independently published for the 64-NPU and 16-NPU cases; for a fabric that added tiers, that division would be an invention. THE SCALE-OUT FIGURE IS SEPARATE AND PER-DIRECTION ALREADY, so it must NOT be halved: UBoE (Huawei's Ultra Backbone Ethernet) and RoCE at '400 Gbps per NPU UNIDIRECTIONAL' = 50 GB/s per direction. The same two pages use 'bidirectional' for UB Link and 'unidirectional' for UBoE/RoCE, so the vendor is not sloppy about this and mixing the two is purely the reader's error.
Link count
8
Topology
Three scale-up domains, and the per-NPU rate is NOT constant across them, which is the property that makes Huawei's figures easy to misread. (1) INTRA-SERVER, 8 NPUs - Atlas 650E (14U air-cooled, ~14.5 kW, 2 x 950 CPUs, 8 x 96 GB on-chip memory = 768 GB, 4.0 TB/s peak memory bandwidth per server). 784 GB/s per NPU bidirectional = 392 GB/s per direction per NPU. (2) FULL-MESH, 16 NPUs across 2 servers. Huawei publishes the rate roughly DOUBLING to 1.68 TB/s per NPU bidirectional = 840 GB/s per direction, as '2 x 8 x 1.68 TB/s (bidirectional)'. Note the topology is a full MESH - a wider domain than the 8-way that both AMD's Infinity Fabric and NVIDIA's NVSwitch top out at. (3) SUPER-POD, 64-NPU cabinet and 1024-NPU pod. The 44OU Atlas 950 SuperPoD cabinet holds 64 NPUs at ~100 kW liquid-cooled and scales to 1024 NPUs, quoted as '1.72 PB/s UB Link bandwidth' pod-wide. The per-NPU rate there is 1.72 PB/s / 1024 = 1.68 TB/s to three significant figures, i.e. IDENTICAL to the 16-NPU full-mesh rate - so from 16 NPUs upward Huawei holds per-NPU bandwidth flat at 840 GB/s per direction and grows the pod purely by adding NPUs. The earlier version of this field computed 1.72 PB/s / 1024 as '1.72 TB/s' and read the rate as merely 'essentially flat'; the corrected division shows it is exactly flat, and the flatness is the finding. It also means '1.72 PB/s' and '1.68 TB/s per NPU' are the same fact at two scales, so a reader who treats the 1.72 PB/s headline as a distinct, larger capability is double-counting. WHAT THE FABRIC DOES NOT PUBLISH: no per-link rate at any level, no lane count, no switch SKU for the 16-NPU, 64-NPU or 1024-NPU domains, and no topology description beyond the counts. Huawei describes these as fabric configurations and separately advertises '256 TB unified global memory addressing & memory semantics' across the 1024-NPU pod, which is a memory-model property rather than a fabric property.
Scale-up
yes
Scale-out
yes
Switching
No switch part is named in the retrieved sources; the 16-NPU full-mesh and 64-NPU/1024-NPU domains are described as fabric configurations without a switch SKU. Scale-out is a different mechanism entirely: UBoE (Huawei's Ultra Backbone Ethernet) and RoCE at 400 Gbps per NPU unidirectional.
notes
UPDATED 2026-10-05 (w7f pass): the direction convention is now VENDOR-PROVEN rather than inferred - see w7f-huawei-650e-prose-bullet-13-4tbs-proves-ublink-direction, where Huawei's own prose '13.4 TB/s per server' is exactly half of its own '2 x 8 x 1.68 TB/s (bidirectional)' table figure (26.88 / 2 = 13.44). The per-link / per-NPU / per-system separation is now stated explicitly in bandwidth_basis, and two arithmetic errors in earlier versions of this record are corrected there: the garbled 'the 840 = 2 x 392 x ... no:' self-correction, and the rounding of 1.72 PB/s / 1024 to '1.72 TB/s' when it is 1.6797 TB/s, i.e. exactly the 16-NPU full-mesh rate. Huawei publishes NO per-link figure for UB Link at any level. Confidence raised 0.8 -> 0.85 on the strength of the vendor-internal direction reconciliation. Added 2026-10-03 to resolve a DANGLING REFERENCE: huawei-ascend-950dt listed 'huawei-ub-link' in its interconnect array and no such record existed, so a validator pass reading that array had nothing to resolve. The figures were already on the accelerator record; this is the interconnect view of them, with the direction conventions made explicit. FIRST-PARTY PUBLISHED (Atlas 650E / Atlas 950 pages): 8 x 96 GB on-chip memory, 4.0 TB/s peak memory bandwidth, 12.48 PFLOPS mxFP4 / 6.43 PFLOPS mxFP8-FP8-HiF8 / 3.40 PFLOPS FP16-BF16 per 8-NPU server; UB Link 8 x 784 GB/s bidirectional intra-server and 2 x 8 x 1.68 TB/s for 16-NPU full-mesh; UBoE and RoCE 400 Gbps per NPU unidirectional; PCIe 5 x16; SuperPoD 64x 950DT at 64 x 1.68 TB/s, scaling to 1024 NPUs at 1.72 PB/s with '256 TB unified global memory addressing'. THE UNIFIED-ADDRESSING CLAIM IS THE HEADLINE AND IT IS AN INFERENCE RESULT, not a fabric result: a KV cache addressable as one flat space across 1024 NPUs, rather than replicated per rank, changes the memory model in a way no NVLink generation does, and it is why this part is worth a record even though its bandwidth is not exceptional. THE BANDWIDTH IS ACTUALLY EXCEPTIONAL IN THE DIRECTION THAT MATTERS: 392 GB/s per direction per NPU against 500 GB/s of local memory bandwidth is a ratio of 0.78, versus H100's 450/3350 = 0.13 and even MI355X's 537.6/8000 = 0.067. That is the inverse of the Ascend 910B problem recorded on huawei-hccs, where ~90 GB/s of chip-to-chip bandwidth against ~1.2-1.6 TB/s of contested memory bandwidth made wide TP expensive. On the 950DT the fabric is within the same order as local memory, so TP is essentially free on bandwidth grounds - and the B* crossover in docs/11-interconnect-decision.md lands in the tens of thousands, far beyond any serving batch. THAT IS THE HEADLINE FINDING OF THIS SLICE'S AUDIT: the part with the worst-known scale-up fabric (910B, HCCS, no primary source) has been superseded by a generation whose scale-up fabric is the best ratio in this repo, and the improvement is entirely in the ratio rather than in absolute per-link bandwidth. CONTRAST WITH THE PREDECESSOR, explicitly, since it is not apples to apples: the 910C used SMIC 7 nm and HBM2e, the 950DT uses on-chip memory, and Huawei publishes no process node for the 950DT - so the fabric improvement cannot be cleanly separated from the memory-substrate change. CAVEAT: all figures are VENDOR THEORETICAL and Huawei's own page carries the disclaimer 'Theoretical computing power may have a <1% error in actual testing' - these are clock-derived peaks, not measurements, and no third-party measurement of UB Link bandwidth is held in this repo. KIND: filed as 'other' because UB Link has no entry in the schema's interconnect enum and is not a member of any named family; note the easy confusion with 'UBoE', Huawei's Ultra Backbone ETHERNET scale-out interface, which is a different thing at a different rate and direction - see the bandwidth_basis above.
way
each

Notes

UPDATED 2026-10-05 (w7f pass): the direction convention is now VENDOR-PROVEN rather than inferred - see w7f-huawei-650e-prose-bullet-13-4tbs-proves-ublink-direction, where Huawei's own prose '13.4 TB/s per server' is exactly half of its own '2 x 8 x 1.68 TB/s (bidirectional)' table figure (26.88 / 2 = 13.44). The per-link / per-NPU / per-system separation is now stated explicitly in bandwidth_basis, and two arithmetic errors in earlier versions of this record are corrected there: the garbled 'the 840 = 2 x 392 x ... no:' self-correction, and the rounding of 1.72 PB/s / 1024 to '1.72 TB/s' when it is 1.6797 TB/s, i.e. exactly the 16-NPU full-mesh rate. Huawei publishes NO per-link figure for UB Link at any level. Confidence raised 0.8 -> 0.85 on the strength of the vendor-internal direction reconciliation. Added 2026-10-03 to resolve a DANGLING REFERENCE: huawei-ascend-950dt listed 'huawei-ub-link' in its interconnect array and no such record existed, so a validator pass reading that array had nothing to resolve. The figures were already on the accelerator record; this is the interconnect view of them, with the direction conventions made explicit. FIRST-PARTY PUBLISHED (Atlas 650E / Atlas 950 pages): 8 x 96 GB on-chip memory, 4.0 TB/s peak memory bandwidth, 12.48 PFLOPS mxFP4 / 6.43 PFLOPS mxFP8-FP8-HiF8 / 3.40 PFLOPS FP16-BF16 per 8-NPU server; UB Link 8 x 784 GB/s bidirectional intra-server and 2 x 8 x 1.68 TB/s for 16-NPU full-mesh; UBoE and RoCE 400 Gbps per NPU unidirectional; PCIe 5 x16; SuperPoD 64x 950DT at 64 x 1.68 TB/s, scaling to 1024 NPUs at 1.72 PB/s with '256 TB unified global memory addressing'. THE UNIFIED-ADDRESSING CLAIM IS THE HEADLINE AND IT IS AN INFERENCE RESULT, not a fabric result: a KV cache addressable as one flat space across 1024 NPUs, rather than replicated per rank, changes the memory model in a way no NVLink generation does, and it is why this part is worth a record even though its bandwidth is not exceptional. THE BANDWIDTH IS ACTUALLY EXCEPTIONAL IN THE DIRECTION THAT MATTERS: 392 GB/s per direction per NPU against 500 GB/s of local memory bandwidth is a ratio of 0.78, versus H100's 450/3350 = 0.13 and even MI355X's 537.6/8000 = 0.067. That is the inverse of the Ascend 910B problem recorded on huawei-hccs, where ~90 GB/s of chip-to-chip bandwidth against ~1.2-1.6 TB/s of contested memory bandwidth made wide TP expensive. On the 950DT the fabric is within the same order as local memory, so TP is essentially free on bandwidth grounds - and the B* crossover in docs/11-interconnect-decision.md lands in the tens of thousands, far beyond any serving batch. THAT IS THE HEADLINE FINDING OF THIS SLICE'S AUDIT: the part with the worst-known scale-up fabric (910B, HCCS, no primary source) has been superseded by a generation whose scale-up fabric is the best ratio in this repo, and the improvement is entirely in the ratio rather than in absolute per-link bandwidth. CONTRAST WITH THE PREDECESSOR, explicitly, since it is not apples to apples: the 910C used SMIC 7 nm and HBM2e, the 950DT uses on-chip memory, and Huawei publishes no process node for the 950DT - so the fabric improvement cannot be cleanly separated from the memory-substrate change. CAVEAT: all figures are VENDOR THEORETICAL and Huawei's own page carries the disclaimer 'Theoretical computing power may have a <1% error in actual testing' - these are clock-derived peaks, not measurements, and no third-party measurement of UB Link bandwidth is held in this repo. KIND: filed as 'other' because UB Link has no entry in the schema's interconnect enum and is not a member of any named family; note the easy confusion with 'UBoE', Huawei's Ultra Backbone ETHERNET scale-out interface, which is a different thing at a different rate and direction - see the bandwidth_basis above.

Cross-references

This record references no other records — it is a leaf. It is cited by 2.