Atlas 950 SuperPoD lit up

Chinese outlets reported on October 15 that Huawei powered on its first 1024-card Ascend Atlas 950 SuperPoD, a liquid-cooled supernode, and that Ascend shipped same-day 0Day support for StepFun’s Step 5 Preview. The Atlas 950 SuperPoD is Huawei’s supernode built on its Lingqu (UnifiedBus) interconnect, and the configuration the Chinese coverage describes delivers 1 EFLOPS FP8, 2 EFLOPS FP4, 256TB of globally unified memory addressing and 3µs end-to-end latency. The single first-hand deployment document in the same batch of material was tested on 2 nodes of 8 NPUs, and states plainly that it is “not recommended for direct use in production environments.”

Key points

IT之家, 快科技 and two other Chinese outlets reported on 2026-10-15 that the first 1024-card Atlas 950 SuperPoD went live in step with Step 5 Preview’s release. All four relay the same specification set; “lit up” here means the cluster was powered on and put into operation for the first time.
Huawei’s keynote at HC2025 on 2025-09-18 describes the full Atlas 950 SuperPoD configuration as up to 8,192 Ascend 950DT chips, 8 EFLOPS FP8, 16 EFLOPS FP4, 1,152TB of memory and 2.1µs interconnect latency, shipping in Q4 2026. The 1,024-card build is one sub-configuration of that family.
The official vLLM Ascend Step-5-Preview deployment guide documents an 8-NPU test run across 2 nodes, reports only two accuracy figures (GPQA Diamond 93.8, MMMU-Pro 76.24), and says performance optimization and reliability validation are still in progress.

Background

The public starting point for the Atlas 950 SuperPoD was Huawei’s keynote at Huawei Connect 2025 on September 18, 2025. Eric Xu described the full configuration as 8,192 Ascend 950DT chips in 160 cabinets — 128 compute and 32 communications — inside roughly 1,000 square meters of floor space, connected entirely with optical interconnect, available in Q4 2026. The interconnect protocol behind it is UnifiedBus, Chinese name Lingqu, whose 2.0 generation lays the groundwork for the Atlas 950 SuperPoD. Huawei claims 2.1µs interconnect latency and 16 PB/s of interconnect bandwidth, with optical interconnect 100 times more reliable than the previous generation and reach beyond 200 meters. The same speech notes that existing technology, at its best, offers an inter-cabinet inter-NPU latency of “about 3 microseconds” — close to the 3µs figure the Chinese coverage attaches to the 1,024-card build, though the two may measure different layers. Above that sits the Atlas 950 SuperCluster: 64 Atlas 950 SuperPoDs tied into 524 EFLOPS FP8. The Atlas 960 SuperPoD, planned for Q4 2027, is specified at up to 15,488 Ascend 960 chips and 30 EFLOPS FP8.

The software groundwork came earlier. DeepSeek open-sourced six Ascend component repositories on September 30, 2026, porting the operator layer of its V4-series models to Ascend (our coverage). Step 5 Preview’s 0Day adaptation is the second landing on that path, and a rare complete deployment record at the 600B scale on Ascend hardware.

The facts

Two specification sets circulate for the Atlas 950 SuperPoD, and mixing them produces nonsense. The 1,024-card figure from Chinese coverage is one sub-configuration; Huawei’s keynote sells the 8,192-card build.

Item	1,024-card build (Chinese coverage)	Full 8,192-card build (Huawei HC2025)
Chips	1,024 Ascend NPUs	Up to 8,192 Ascend 950DT
FP8 compute	1 EFLOPS	8 EFLOPS
FP4 compute	2 EFLOPS	16 EFLOPS
Memory	256TB globally unified addressing	1,152TB
Latency	3µs end-to-end	2.1µs interconnect
Cabinets	16 compute + 4 switch (LightCounting)	160 (128 compute + 32 comms)
Availability	not stated	Q4 2026

The latency figures measure different things. The 2.1µs in Huawei’s keynote is SuperPoD interconnect latency; the 3µs attached to the 1,024-card build by Chinese coverage is written as end-to-end. The keynote’s “about 3 microseconds” figure for existing technology lands close to the Chinese number, but nothing in either source explains the gap. Power draw, per-rack power and pricing have no source in this material.

Further checkable facts from primary material:

The Hugging Face model card for Step 5 Preview: a sparse MoE with 600B total parameters, 27B activated per token, a 1M-token context window that covers input and output combined, and text, image and video input. FP8 is the default weight format; BF16 requires a separate Step-5-Preview-BF16 checkpoint. The card warns that setting --dtype bfloat16 on the FP8 checkpoint does not convert its quantized weights to BF16.
The license is StepFun Model License 1.0, described on Hugging Face as “an Apache-2.0-Style license, with additional attribution and commercial-license conditions.” Recommended inference settings are temperature=1.0, top_p=0.95, top_k=0.
The deployment stack in the vLLM Ascend guide: HDK 25.5.0, CANN 9.2.0, torch_npu 2.10.0.post4, vLLM and vLLM-Ascend v0.27.0, container image quay.io/ascend/vllm-ascend:step5-a5-openeuler. Installing from source is explicitly unsupported.
The code: PR #18774, “[Doc] Add Step 5 Preview deployment guide,” merged into vllm-project/vllm-ascend at 2026-10-15T08:20:02Z. It touches 4 files, adds 275 lines, and is documentation only.

The Ascend software stack

The Chinese press release framing is “inference performance on par with leading overseas compute.” The first-hand document says something narrower. The vLLM Ascend guide limits support to 950DT products and states that “other Ascend hardware (e.g., Atlas A3 Products) is not supported.” Its tested configuration is a 2-node deployment using --tensor-parallel-size 4, --data-parallel-size 4 and --data-parallel-size-local 2, for 8 NPUs in total; the same document explains that 1M context is reached by this DP=4 deployment across 2 nodes.

The guide reports two accuracy figures and nothing else: GPQA Diamond 93.8 and MMMU-Pro 76.24, both from the vllm-api-general-chat gen mode. There are no throughput or latency numbers. It carries three caveats — the current version is for early experience only, service reliability has not been fully validated, and direct production use is not recommended — and lists LoRA, Pipeline Parallel and Prefill-Decode Disaggregation as untested. First weight load “usually takes about 10 minutes.”

The three-layer optimization list in Chinese tech media lines up with the guide’s own flags: Ascend C and Triton fused operators correspond to the W8A8 MXFP8 weights (Step-5-Preview-w8a8-mxfp8), FullMesh+CLOS covers the bandwidth-maximizing Allreduce, Allgather and ReduceScatter primitives, and MTP speculative decoding maps to --speculative-config with num_speculative_tokens 3 and method mtp. 新智元’s own footnote reads: the performance ratios come from targeted tests on individual operators or partial paths, and actual gains vary with hardware configuration and workload.

What others say

IT之家 (2026-10-15, 22:07) relays Huawei’s account, writing that the first 1024-card supernode went live in step with the release of Step 5 Preview, with performance “on par with leading overseas compute,” attributed with “according to Huawei.” The same piece records Day 0 adaptation claims from MetaX, Biren and Moore Threads, with MetaX saying it has adapted 43 flagship models since December 2025. 快科技 (2026-10-15) repeats the same specification set, adds the “on par with leading overseas compute” framing, and notes an all-liquid-cooled design spanning compute and interconnect cabinets.

LightCounting analyst Carol Cao took the system apart from a cost angle in a research note dated July 21, 2026: the 1,024-NPU cluster is 16 compute racks plus 4 central UB switch racks, each compute rack holding 8 NPU trays of 8 NPUs, with 4,096 800G optical transceivers across the system. Per-NPU optics moved from 8×400G to 2×800G, and it is the first supernode design to adopt LPO (linear-drive pluggable optics), resting on Huawei’s 100G VCSEL technology. The note is paywalled beyond its abstract, which publishes no TDP, per-rack power or price. It describes the system shown at WAIC 2026 in July; whether that is the same build lit up on October 15 is not stated in any of the material.

The act of “lighting up” a 1,024-card cluster has no first-hand source today. Huawei’s newsroom carries no matching announcement, and StepFun’s own site carries no such release; the four Chinese outlets relay the same press-release framing.

How to try it

Reproducing the guide’s 8-card run needs two 950DT nodes (8 NPUs each), the container image, the Step-5-Preview-w8a8-mxfp8 weights from ModelScope, and the serve command below, adapted from the vLLM Ascend guide:

vllm serve Step-5-Preview-w8a8-mxfp8 \
  --served-model-name step \
  --tensor-parallel-size 4 \
  --data-parallel-size 4 \
  --data-parallel-size-local 2 \
  --max-model-len 1048576 \
  --enable-expert-parallel \
  --speculative-config '{"num_speculative_tokens": 3,"method": "mtp"}'

Without eight Ascend cards to spare, read the model card and the deployment guide: the first covers the model’s capabilities and license boundaries, the second spells out how 1M context is reached on Ascend hardware, flag by flag. The same week’s Microsoft Maia 300 inference chip lays out a different route to owning your inference silicon, and the two are worth reading side by side.

Our take

For anyone making inference hardware decisions, one honest sentence: the 1,024-card build currently exists only as a vendor claim. All four Chinese outlets trace their numbers back to Huawei’s own framing, with no primary announcement and no third-party test. Treat 1 EFLOPS, 256TB and “on par with leading overseas compute” as unverified until the full 8,192-card build ships in Q4 2026.

For developers inside the Ascend ecosystem, what is genuinely reusable here is the software. The vLLM Ascend guide turns “how do I run 1M context on Ascend” into a command with flags, from data parallelism across nodes to MTP speculative decoding, and then draws the boundary itself: 950DT only, 8 cards validated, not for production. That candor is worth more than the press release’s performance slogans. Between DeepSeek’s operator layer and vLLM Ascend’s deployment notes, “can domestic chips run frontier models” is turning into an engineering question with an answer — and the work vLLM’s own alumni are doing on inference kernels suggests the bottleneck is shifting from whether it runs to what it costs to run.