HC 2026 Panorama: The Unit of Competition Shifts from Chip to System

Huawei Connect 2026 (HC 2026) ran in Shanghai from September 17 to 19. The headlines belonged to the Ascend 960E supernode and the million-card cluster; the tone-setter was Rotating Chairman Wang Tao, whose keynote was titled “Ignite a New Future, Build the Silicon Black Soil of the Intelligent World.”

Read the three days together, and the headlines cover only part of the story. Huawei moved six components forward in parallel: intelligent-computing supernodes (Ascend 960E), general-purpose computing supernodes (TaiShan 950), memory storage (M900), interconnect networking (Stellar and the OCS800), cloud services (Huawei Cloud and Stack), and industry portfolios.

All six share one interconnect protocol — UnifiedBus (Lingqu), a unified memory-semantics specification spanning NPUs, CPUs, memory, and storage — and one delivery calendar. Released the day before the conference, the Intelligent World 2035 report supplies a ten-year demand slope: by 2035 the world will hold about 900 billion AI agents, and agents will account for more than 90% of network traffic.

This site already holds three pieces of the puzzle: the single-machine teardown (Same Node, Double the Compute), the five network planes returned to their places (Huawei’s One Network: The HC 2026 Networking Panorama), and the protocol layering of UnifiedBus (Deep Analysis of the Lingqu Protocol). This piece fills in the remaining components and reads the whole launch as one system: supernodes raise the efficiency of close collaboration, clusters expand compute supply, general-purpose compute and memory carry agent execution, and cloud plus industry solutions turn these capabilities into business systems that keep running. The unit of competition is shifting from single products to whole systems.

1. The Status Line: What Is Commercial, What Is Calendar

The table’s states fall into four layers: purchasable, deploying, announced-but-awaiting-validation, and roadmap. The industrial deployments that can honestly be discussed right now are the 950 and the installed platforms, cloud services, and industry solutions; the 960E must be discussed on two tracks at once: architectural value and engineering-validation progress, and neither can claim the other’s credit. The parts that can be bought map to procurement judgments, and every remaining item carries a trackable date or validation checkpoint. Unless stated otherwise, figures throughout are Huawei-disclosed and not independent third-party test results.

2. Compute: Two Legs, and a New Architecture

Start with cadence. Wang Tao’s wording was one generation a year: the 960DT arrives three quarters ahead of plan, ready in Q1 2027; the 960PR lands one quarter early, ready in Q3 2027; the 970 and 980 follow in 2028 and 2029, following the “compute doubling” cadence (the τ-law), with memory bandwidth, memory capacity, and interconnect bandwidth rising in step. The chip line built around UnifiedBus covers compute, interconnect, storage, and management, a scope beyond a single NPU.

For the 960E generation, the three capabilities to watch are still whether they grow in step: compute throughput, data supply, and cross-chip collaboration. Once single-chip matrix compute rises, whether model performance rises with it depends on whether HBM access, non-matrix operators, and communication and synchronization can keep up. The full-production microarchitecture, per-card TDP, final HBM mix, and pricing remain undisclosed; a confirmed procurement spec sheet cannot be assembled yet; this stays a validation item rather than something to fill in from the roadmap. Nor can total system compute be divided by card count to infer process node, power, yield, or cost.

The other product line running alongside the 960E gained obvious weight this time: the TaiShan 950 general-purpose computing supernode. It uses an all-optical UnifiedBus fabric, supporting up to 4,096 general-compute nodes and a 256TB unified memory pool, aimed at agent sandboxes, startup efficiency, and vector retrieval (4,096 is the general-compute node count, not 4,096 NPUs).

Its significance is generalizing the supernode from large-model accelerator interconnect to CPU resource organization. Reason forward from the agent workflow: model generation is only one segment; code execution, tool calls, browser operation, retrieval parsing, and task orchestration are all general-compute workloads, with occupancy patterns unlike model compute that sits on accelerators for long stretches.

So its goal is not to make CPUs look like GPUs, but to let large numbers of short-lived execution environments in varying states start fast, share resources, isolate faults, and work efficiently with model inference. Infrastructure provisioning changes with it: from static configuration by “how many NPUs per how many CPU servers” to allocation that follows the actual needs of model execution, tool execution, retrieval, and data processing. The boundaries also need stating: a unified memory pool does not equal uniform access performance, and decoupled resources do not mean access location stops mattering. More important than the maximum node count are four engineering checks: sandbox concurrency density, startup tail latency, cross-node access cost, and fault isolation.

Off the main agenda, Huawei’s official LinkedIn account disclosed the Peerium computing architecture (pending confirmation in a formal press release). The keywords: nested BSP (Bulk Synchronous Parallel — compute advances in rounds, with one global synchronization at each round’s end), unified memory addressing, and peer interconnection, with UnifiedBus underneath connecting CPUs, NPUs, memory, SSDs, NICs, and switches. The point is not “a million cards like one machine”; it is nested parallelism: mapping the different communication levels of nodes, supernodes, and clusters into one parallel execution model, so that synchronization which can complete locally does not extend to the global level, and communication-heavy tasks stay inside tightly interconnected domains.

What this touches is not only the network but also compilers, runtimes, collective communication, memory allocation, and task placement. There is one validation question: can it make the hardware hierarchy easier for applications to exploit and cut unnecessary cross-level synchronization? Unified addressing does not automatically deliver uniform access performance, nor should it be read as proof that a new computing paradigm now holds.

The software ecosystem is shifting gears too. CANN has entered routine open-source community operation: external developers reached 61% for the first time, monthly active developers passed 5,200, more than 40 models have been trained natively on Ascend plus CANN, coverage spans 90-plus communities including PyTorch, Triton, vLLM, and veRL, and CANN has become a technology route officially supported by PyTorch (all figures per Huawei). Framework counts by themselves say nothing.

What matters is whether one combination — target models, precision, parallelism schemes, communication libraries, software versions — can be maintained over time and recover correctly after faults. For post-training infrastructure in particular, validate weight synchronization between training and rollout, trajectory transfer, version consistency, and recovery paths. Getting a framework to start is only the starting point; sustained iteration and correct recovery after failures are what make it a system product.

3. Clusters: Four Numbers and One Validation Chain

Start with the flagship. The Ascend 960E’s technical parameters now reach into the system’s physical implementation: 4,096 NPUs per system, peaking at 8 EFLOPS in FP8 and 16 EFLOPS in FP4; an orthogonal architecture with full liquid cooling, and Hi-ONE near-package optical engines rated at 7.2 Tb/s each. Where the earlier round offered only a roadmap, this set of details moves the story from “what to do” toward “how it gets built.”

But specs are not maturity. Evaluating the 960E splits into two questions: whether the architecture is sound, judged on interconnect distance, bandwidth organization, resource access, and software coordination; and whether the engineering is mature, judged on assembly, optical connections, cooling, repair, spare parts, fault recovery, and batch consistency. The first can be analyzed from the design; the second can only wait on full-system validation. The NPO optical engine being ready for volume production does not mean a 4,096-card system has completed at-scale delivery validation.

Four scale numbers in public information often get spliced into one story; take them apart: 4,096 is the NPU count of one 960E system; 256K is the Atlas 950 supernode cluster now being deployed (per official LinkedIn wording); 512K is the scaling number for a two-tier CLOS four-plane fabric; 1M is the expansion target with multi-rail topology layered on top. The four numbers belong to single system, cluster under construction, network tier, and topology target; they do not assemble into “the million-card cluster has landed.”

Every level up raises the validation bar: connectable, manageable, able to run jobs, scaling effectively per job, stable over the long run, economically viable. The most-quoted figure from the launches, a 2.75× MFU improvement (a 100,000-card cluster of 4K supernodes versus 100,000 cards of eight-card servers), is labeled as output of Huawei’s Markov Lab simulation, not a public live comparison test on 100,000 real cards. It supports architecture research; it is not selection evidence. Real selection still needs tests under target models, topology, parallel configuration, and fault conditions. The credibility of a vendor narrative depends on how much evidence it offers that can be checked against dates; this site’s teardown of GLM’s inference infrastructure (The Model Optimizes the System, the System Runs the Model) applies the same standard.

4. Storage: From a PB-Scale KV Pool to Concrete Architecture and Media

The M900 is one of the most technically substantial releases of this round: it turns “PB-scale KV cache” from a direction into architecture and media design. Public materials give the numbers in three tiers: 7PB of capacity and 10TB/s of bandwidth per cabinet; 64PB of capacity and 40TB/s of aggregate access bandwidth per cluster (1.5× industry, per Huawei); access latency down from milliseconds to 60μs. The three figures belong to three different scopes: the cabinet, the cluster, and the access path; different configurations cannot be extrapolated linearly by cabinet count. The 60μs figure also comes without message size, concurrency, or tail-latency conditions, so it cannot be equated with application first-token latency. Usable KV cache per NPU rises from GB scale to TB scale; in a typical AI coding scenario, token throughput doubles and first-token latency halves.

More important than capacity is architecture and media. An industry first: CPU, network, and disk-controller three-chips-in-one, with native KV semantics and NPUs reaching SSDs in one hop, eliminating protocol conversion and CPU forwarding. This is not just making SSDs bigger; it is shortening the data path between the inference engine and the cache media. One hop does not mean the CPU control plane is no longer needed at all, and it does not mean SSDs have become memory equivalent to HBM. On the media side, KV-Aware adaptive storage arranges multiple media types by the value and lifecycle of KV data, with endurance up to 24 DWPD (drive writes per day, an SSD endurance metric), SSD lifetime raised 16×, supporting three years of stable operation. Peak endurance also needs reading together with media mode, usable capacity, retention conditions, and warranty terms.

The real change: KV cache no longer fully inherits the media-management logic of long-term persistent data; it is designed around retention time, reuse value, and write intensity.

The returns rest on one condition: retrieving those states after a cache hit must cost less than recomputing them. With low hit rates, short reuse distances, or retrieval traffic crowding out inference communication, an even larger cache pool cannot deliver the expected returns.

“AI memory” spans at least three layers and cannot be lumped under one term. The execution-state layer is the M900 and the cloud-side CMS (per Huawei: PB-scale memory space, capacity doubled against industry peers, TB-scale read performance up 50%), the latter being a cloud-side service form that should not be assumed fully identical to the M900 without confirmation; the semantic-knowledge layer is the OceanStor A800 in the finance solution; the enterprise-data-asset layer is AI DataLake and DataArts. Each has its emphasis: execution state highlights model versions and reusability; semantic knowledge highlights retrieval, provenance, and permissions; enterprise data assets highlight governance and lifecycle. The three layers can share part of the infrastructure, but interface definitions, versions, and responsibility boundaries must each stay clear rather than merge into one vague set of interfaces.

5. Optics and Networking: Three Layers of Division of Labor, Each With Its Own Segment

Networking is the other main line of this round; this site has already taken it apart in a dedicated piece (Huawei’s One Network: The HC 2026 Networking Panorama). Put back into the whole system picture, it answers questions at four levels. Inside a supernode: how accelerators, memory, and storage collaborate closely. At the cluster level: how supernodes compose into a larger compute system. At the WAN level: how distant compute and data work together. And at the opto-electronic engineering level: how high-speed signals get from the chip onto the link. At the product level, three pieces each own one segment: CloudEngine SF9300 owns “how communication works,” XH9300-EN’s near-package optics own “how high-speed signals leave the chip,” and OptiXtrans OCS800 owns “which optical ports connect to each other.” The three can be combined; they cannot substitute for one another.

The first piece is the SF9300. Huawei defines it as a 100T UBG + RoCE dual-mode switch, and the value is headroom for migration: customers do not have to replace an entire network at once, and the product can serve both the UnifiedBus compute system and existing RoCE environments. But three capabilities must be kept apart: a device supporting two modes, the two modes running at the same time, and transparent interworking between the two protocols are three different things. Dual mode alone does not prove that any RoCE NIC can gain all UnifiedBus capabilities, that the two terminal types need no extra adaptation, or that existing applications can use unified memory semantics without modification. The questions to ask: does mode switching happen at the chassis, board, or port level? Where are the function and performance boundaries of mixed networking? That determines whether this is an ecosystem product or a component inside one vendor’s package.

The announced key designs: a two-tier multi-plane architecture, network build cost down 30%, end-to-end latency from 20μs to 11μs, and link-layer retransmission (LLR) against link flaps. Removing one switching tier can save switches, some optical modules, and forwarding hops, while multiple planes carry parallel bandwidth and redundancy. But once the core layer is gone, everything else cannot stay unchanged. At least four things need rebalancing: switch port counts, server-side NIC counts, traffic distribution across planes, and post-failure residual capacity. Multiple planes meeting the target together under normal conditions does not mean one plane dropping out still meets business latency.

So the question is not “is two-tier better than three-tier,” but: under the same compute scale, the same non-blocking requirement, and the same failure redundancy, how much total cost does the two-tier multi-plane design actually remove? And a latency gain does not convert directly into throughput. Take a simplified calculation: assume communication that compute cannot hide takes 30% of total time; even cutting that portion’s time by 45% reduces total time by only 13.5%, or about 15.6% more throughput (idealized; ignores other bottleneck shifts). Real workloads also depend on message size, concurrency, endpoint processing, and congestion.

What the SF9300 should demonstrate is not an isolated latency figure but how much key-path communication time it removes in MoE expert communication, collective communication, and PD-disaggregated serving. LLR’s value is confining some transport anomalies to local repair, so not every problem escalates into an end-to-end timeout. Evaluations should test four classes separately: how transient anomalies are retransmitted, how sustained congestion is controlled, how permanent link breaks are rerouted, and how job state is recovered, along with retransmission buffer size, retry window, and tail latency.

The second piece is NPO. The XH9300-EN uses a self-developed 3.2T optical engine; that figure is the optical engine’s rate and must not be mixed with the switch’s 100T capacity. The analysis of NPO is not “optics replacing electronics” but: how far high-speed electrical signals travel on the board, through which components, and where the conversion to light happens. Moving optical conversion next to the switch chip shortens part of the high-speed electrical path and creates room to cut loss and raise interface density. The final payoff depends on the electrical interface, optical engine, packaging, and cooling; an NPO label does not prove that power and latency necessarily beat every pluggable solution. Power and latency figures also need their denominators stated: interconnect power from 1,000W to 600W, and per-node latency improved 26%; these cover the interconnect portion and the node; they cannot be applied to the entire switch, much less the entire data center. On an illustrative basis, 1,000 devices each saving 400W continuously adds up to about 3.5 million kWh a year: an order-of-magnitude reference, not a commitment.

The more underrated issue is maintenance: higher optical integration can widen the repair boundary, turning what used to be a module swap into a board swap. “Field-replaceable” is only a starting point; further questions: does replacement require taking a board down, how many ports are affected, is the light source shared, is recalibration needed, what do spares cost? Field-replaceable, hot-swappable, and non-disruptive are three different grades. Evaluating the NPO route should rest on total system cost and maintainability, not on its generational rank on an optical technology roadmap.

The third piece is the OCS800, this round’s key addition at the optical layer. The OCS800X256 uses MEMS for all-optical cross-connects, with 256 main optical ports and millisecond-scale path reconfiguration; its essence is optical-path cross-connection rather than packet-by-packet parsing before forwarding. Tasks that keep relatively fixed communication relationships for long periods may get more direct connections by reconfiguring light paths; the OCS may also adjust bandwidth connections between different task phases. Two boundaries here: millisecond reconfiguration describes the time to change one optical path, not the latency of a packet crossing a switch. And a connected light path does not mean the application continues seamlessly; congestion control, reliable transport, endpoint state, and task scheduling still sit on the packet side.

What to validate: whether reconfiguration requires link retraining, whether communication groups must be rebuilt, whether the switching window affects live traffic, and whether the control software truly knows the workload’s communication needs. Seen this way, the OCS’s potential differentiation lies not in the optical switch box but in joint scheduling of path control, task placement, and network state.

On the WAN side, the change is closer to “network and model runtime designed together.” The compute-network convergence appliance runs the model’s initial and final parts locally and the middle part remotely, in essence slicing the model by layer across domains. That is far more complex than a plain API call: intermediate-state formats, layer-split placement, model version sync, remote queuing, and fault recovery all have to be solved.

Three accounting reminders: fewer local cards does not mean total cost falls in proportion. Only if the center offsets remote-network and coordination costs through multi-branch sharing, batching, and higher utilization does the economics improve. Communication-compute overlap can hide waiting time, but it does not automatically reduce the number of bytes that must be transferred. The “95% remote compute efficiency over 1,000 km” claim also needs its definition first (overall throughput, device utilization, or single-request latency). Take a simplified assumption: light in fiber travels at about 200,000 km/s; 1,000 km of fiber costs roughly 5 ms one way and 10 ms round trip, the order of magnitude of propagation alone, before detours, device processing, queuing, and retransmission. Cross-domain throughput can be fought for with concurrency and pipelining, but single-request latency can hardly approach local. One more privacy boundary: layer-splitting avoids handing raw inputs to the remote side, but intermediate activations still carry input information, so “no raw data sent” does not prove privacy. On the campus side, Huawei also highlighted 100-millisecond telemetry, DCP, and iFlow 2.0 for observability, analysis, and verification, moving from alert aggregation toward controlled repair. Supporting such autonomy: permission limits, change auditing, and rollback mechanisms.

6. Cloud and M&E: From Built Clusters to an Operable Compute Service

The 950 intelligent-computing cluster cloud service is the nearest delivery on the calendar (commercial in China on September 30, overseas on November 30). Its added value is in recovery and operations capability, not in a newer card model: full-link observability, a five-level fast-recovery mechanism, 40 days of stable cloud training, fault recovery within 10 minutes, and token throughput up 20%. That is closer to how the system actually runs than peak-compute numbers alone, but interpret it correctly: 40 days of stable operation does not mean 40 days with no component failures, and recovery time must be split across the device, process, and training-job layers. From an operations view, effectiveness breaks into three items: how much compute progress a fault destroys, how much extra resource recovery consumes, and whether results are correct after recovery. Only the three together make up long-term effective output.

Huawei Cloud Stack’s upgrade centers on an agent-oriented Next architecture: converged AI-and-general-computing infrastructure, an AI capability hub, an agent platform, and full-lifecycle operations. On concrete technical points, mainly NPU pooling and memory snapshots (adapted to the A5 supernode), with Huawei’s disclosed utilization figure rising from 30% to 70%. Allocation rate, device-busy ratio, compute-unit activity rate, and model FLOPs utilization are four different metrics; 70% utilization does not automatically equal 70% MFU. Whether pooling and snapshots are worth it comes down to four things: model startup and switching overhead, fragmentation rate, performance interference under sharing, and post-recovery state consistency. For multi-model, multi-tenant inference, these may matter more than a small increase in peak compute.

On the Agentic Cloud side, what gets delivered is expanding from virtual machines, containers, and accelerator cards to model services, agent runtime environments, and industry assets: AgentArts already serves more than 100 enterprises, commercial overseas on December 30. The openJiuwen community has passed 50,000 stars and 3.29 million downloads; the industry AI dream factory has accumulated thousands of industry assets and over 1,000 delivered projects, with government-intelligence and AI-hardware zones added this round. But that does not mean infrastructure should carry all business semantics; the sensible division: infrastructure guarantees resources and runtime state, the model platform manages execution and versions, and industry applications carry business rules and authorization.

Mechanical and electrical support (source-grid-load-storage AIDC) belongs in the system view, but not all of it counts as hardware launched at this event: the FusionPower9000 prefabricated power unit and the FusionCol600-L450MA thermal management unit (redundancy, modular maintenance, continuous cooling). AI cluster energy and cooling design should ultimately deliver not just PUE but effective compute capability under power limits and partial failures. Acceptance ties directly to job behavior: whether frequency drops on power switchover, how large a resource domain a cooling anomaly affects, and whether servicing one loop stops an entire task group.

7. Industries: Not Every Project Has to Start from 4,096 Cards

Not all industry AI projects need to start from the 960E and 4,096-card supernodes. The overseas solution Fintelligent AI explicitly names an agent factory, a token factory, and a data-and-knowledge factory, and introduces TokeNexus and Financial Agentic Data. Its on-premises combination is a trio: Atlas 850E carries model inference, TaiShan 950 carries sandbox execution, and OceanStor A800 carries long-term memory, landing on three resource positions: inference, general-purpose compute, and data. Huawei discloses more than 7,100 financial customers served, with 54 of the Top 100 banks adopting.

The domestic “Financial Qiyuan” solution is built around openJiuwen, adding FAB 2.0, engineering enhancements, a smart-finance zone, and token full-lifecycle operations for financial services; delivery spans platform, agents, assets, knowledge, security governance, and compute. Read together, the point is engineering assets and operating mechanisms: how tasks execute reliably, how knowledge updates, how calls get metered, and how permissions and audit run through the process. What industry scenarios need is the right mix of inference, general-purpose compute, data, and runtime platform: high-end large clusters solve the scale problem, and industry combinations solve “how to use it and keep it running.”

Healthcare is the HAIC (Healthcare AI Copilot) joint solution and the Nanfang Hospital global showcase: the HAIP platform organizes compute, data, and models, supporting the four domains of care, education, research, and management. Distinguish three layers here: the carrying platform, the industry application, and the showcase release; they should not be lumped together. The value is putting hospital data, permissions, models, and business processes into one operational environment; acceptance should center on data traceability, verifiable outputs, permission isolation, and human review, and general Q&A scores say nothing about real-world usability.

Manufacturing runs along three lines: smart drug R&D (drug discovery, clinical research materials and report generation, knowledge organization, and process traceability), R&D tool chains (the full span from product definition, systems, mechanics, software, and circuits to simulation), and the production digital platform (production, quality, equipment, energy, and other managed objects). The event’s official index also lists “seven major solutions and two initiatives” for manufacturing and large enterprises; the three directions above are the ones with concrete compositions verifiable from public materials, and not all of their underlying products are first launched at this event. The smart drug R&D portfolio includes Atlas, DCS, and storage, and does not have to be built on next-generation ultra-large supernodes. The hard part is whether the model can enter existing engineering tool chains and production processes while preserving version, approval, quality, and traceability constraints. That brings infrastructure demands quite different from large-model training: graphics and simulation workloads, CPU compute, time-series data, document and knowledge retrieval, edge inference, and long-term stable system integration.

The six global power showcases (Brazil CEMIG, Guangzhou Baiyun distribution-microgrid coordination, Hunan Shaoshan distribution grid, Jiangxi power supply and use, Zhejiang Shaoxing digital converter station, Liaoning power communication network) are validation assets across different businesses and deployment environments, not six new hardware pieces. For solution replication, separate what can be standardized (data access, diagnostics, communication management, digital operations) from what still depends on on-site engineering and existing systems; parts involving real-time control need independent safety and determinism boundaries and should not simply be handed to general-purpose agents.

For the scaled industry market, Huawei also released the enterprise compute engine and DCS AI alongside the SCALE partner system; for broad customers, this direction may affect procurement more directly than the flagship supernodes. The essential task is to deliver together: configurations for clearly defined scenarios, validated software combinations, performance baselines, upgrade-and-rollback paths, fault responsibility, and service boundaries; without these, the same hardware still gets re-integrated across projects, and a solution cannot become a repeatable product.

8. Judgments

The unit of competition shifts from chip to system. Compute systems are expanding from fixed servers into collaboration among multiple resource classes: the combination of Ascend supernodes, Kunpeng general-purpose computing supernodes, the M900, and cloud platforms shows Huawei handling model compute, tool execution, and state storage at once, not just adding more accelerators. The important object of optimization going forward is the resource mix and placement of the full task chain: NPUs, CPUs, cache, and persistent data can all become bottlenecks, and optimizing one link is not enough. The system route’s constraint is equally clear: all six components are indispensable, and any lagging link drags down the whole.

Storage and network are entering the model execution process. The M900 provides native KV access, the OCS provides reconfigurable optical paths, and the compute-network convergence appliance lets the WAN join tiered model deployment. The deeper they reach into execution, the clearer the interfaces, versions, and responsibility divisions must be. Infrastructure cannot, on the strength of “joint optimization,” bind business and equipment deeply together without providing upgrade, replacement, and fault-recovery mechanisms.

Industry competition is turning toward repeatable delivery. Beyond the platform, vendors must supply engineering assets, reference architectures, validation environments, and service mechanisms. Differentiation does not show up in the options list; it shows up in whether the same business can be delivered with less integration work, more controllable performance, and clearer fault responsibility.

For the capabilities this round touches, acceptance should work the same way: verify the result of a complete task under specified models, data, concurrency, latency, and fault conditions, rather than accepting each product’s best-case metric separately. KV storage: not just bandwidth, but how much recomputation it removes. OCS: not just switching time, but whether reconfiguration improves task output. NPU pooling: not just allocation rate, but performance and isolation after sharing. Industry solutions: not just demos, but whether upgrades keep reproducing results.

If we pick the new technical points most worth continued deep study from this round, this site picks four: the Kunpeng general-purpose computing supernode, Peerium nested parallelism, OCS optical-path reconfiguration, and the M900’s native KV and endurance design. For near-term industrial landing points worth tracking, again four: the 950 cloud service going commercial in China on September 30, Stack’s pooling and recovery capabilities, the compute–sandbox–memory combination in finance, and the standardized delivery of the enterprise compute engine and DCS AI. Public launches have shown a fairly complete direction, but maximum card counts, peak compute, simulated gains, deployment progress, and commercial results must always be kept apart; whether this route holds will ultimately be proven by real workloads.

---

Sources

• Full text of Wang Tao’s keynote, “Ignite a New Future, Build the Silicon Black Soil of the Intelligent World” (Huawei official site, 2026-09-17, huawei.com/cn/news/2026/9/hc-wang-keynote): 1,000+ 910C sets; 950 commercial at scale; the 960DT/960PR and 970/980 cadence; 2.75× from Markov Lab simulation; CANN ecosystem numbers; Kunpeng’s 4.16 million developers
• Ascend 960E supernode launch release (Huawei official site, 2026-09-17, huawei.com/cn/news/2026/9/hc-ascend960-supernode): 4,096 cards; 8/16 EFLOPS; orthogonal architecture, full liquid cooling; Hi-ONE 7.2T; two-tier CLOS, four planes, 512K cards; multi-rail 1M cards; Kunpeng supernode 4,096 nodes / 256TB
• Huawei Connect 2026 official event page (huawei.com/cn/events/huaweiconnect): TaiShan 950; OCS800X256; FusionPower9000; FusionCol600-L450MA; 7PB / 10TB·s per cabinet (event-page disclosure layer)
• Huawei Stellar AI network upgrade (Huawei Enterprise official site, 2026-09-17, e.huawei.com/cn/news/2026/solutions/enterprise-network/xinghe-intelligent-network-upgrade): tokens growing 260× per year; SF9300; XH9300-EN; compute-network convergence appliance and remote compute efficiency; three-tier security fencing (network parts covered in this site’s networking piece)
• OptiXtrans OCS800 product page (Huawei Enterprise official site, checked 2026-09-19, e.huawei.com/cn/products/optical-transmission/optixtrans-ocs800): MEMS optical cross-connect / 256 main optical ports / millisecond-scale / DCI scenarios
• OceanStor M900 launch release (Huawei Enterprise official site, 2026-09-17, e.huawei.com/cn/news/2026/solutions/storage/hc-context-memory-storage): 64PB / 40TB·s / 60μs / three-chips-in-one / 24 DWPD / 16× lifetime
• Huawei Cloud, “Building Agentic Cloud Together” (Huawei Cloud official site, 2026-09-18, huaweicloud.com/news/2026/20260918105927245.html): the 950 cloud service timetable and recovery numbers; CMS; AgentArts; openJiuwen; the industry AI dream factory
• Huawei Cloud Stack, “All for AI” (Huawei Cloud official site, 2026-09-17, huaweicloud.com/news/2026/20260917212419917.html): the Next architecture; NPU pooling; memory snapshots; utilization from 30% to 70%
• Fintelligent AI overseas launch (Huawei Enterprise official site, 2026-09-18, e.huawei.com/cn/news/2026/industries/finance/fintelligent-ai-solution-globally): three factories; TokeNexus; the Atlas 850E / TaiShan 950 / OceanStor A800 trio; 7,100 financial customers
• Financial Qiyuan Agentic AI solution (Huawei Enterprise official site, 2026-09): solution name and the openJiuwen carrier
• Nanfang Hospital smart-medicine global showcase site and the HAIC joint solution (Huawei official site, 2026-09-18, huawei.com/cn/news/2026/9/hc-intelligent-healthcare)
• Six global power showcase sites (Huawei Enterprise official site, 2026-09-18, e.huawei.com/cn/news/2026/industries/grid/six-global-showcases-grid-projects)
• SCALE partner support system, enterprise compute engine, and DCS AI (Huawei official site, 2026-09-18, huawei.com/cn/news/2026/9/hc-scale-industrial-intelligence): the five-dimension system; 100+ scenario solutions across 8 industries; 48 reference architectures
• Manufacturing three-line solution pages (Huawei Enterprise official site, checked 2026-09): smart drug R&D / R&D tool chains / production digital platform
• Relay sources (not carried in official press releases; flagged in the body): the 256K-card Atlas 950 cluster being deployed, and the Peerium computing architecture, both from Huawei’s official LinkedIn channel
• Intelligent World 2035 (Huawei, released 2026-09-16): about 900 billion AI agents; agent traffic share above 90% (same official source as the networking piece)
• Earlier pieces on this site: Same Node, Double the Compute: How Ascend 960 Rebuilds the Chip, the Supernode, and the Cluster; Huawei’s One Network: The HC 2026 Networking Panorama; Deep Analysis of the Lingqu Protocol; The Model Optimizes the System, the System Runs the Model: Building GLM’s Frontier Inference on 100,000 Domestic Accelerators