---
title: LineShine Exascale Supercomputer
url: https://www.emergentmind.com/topics/lineshine-exascale-supercomputer
type: topic
---

# LineShine Exascale Supercomputer

Searching arXiv for the cited LineShine-related papers to ground the article in the latest available preprints.
Looking up LineShine and the specific arXiv identifiers for corroborating metadata and scope.
LineShine is an exascale Armv9-based supercomputer at the National Supercomputing Center in Shenzhen and is described in current arXiv literature as an exascale HPC-AI converged system built around Armv9 LX2 processors and the LingQi high-speed network (LQLink) with 1.6 Tb/s per node. Published accounts characterize it less as an isolated hardware artifact than as an enabling platform for full-system workflows: operational flood-season forecasting through the CAPES fused numerical-AI ensemble system, and exascale training of historical-prior generative compression models for Earth observation [2605.24896] [2605.08633].

## 1. System identity and architectural profile

In the available literature, LineShine is presented as a **CPU-based Armv9 HPC-AI supercomputer** rather than a GPU cluster. Its compute substrate is the **Armv9 LX2 processor**, and its node-level design combines hierarchical HBM/DDR memory, high per-node network bandwidth, and Armv9 vector and matrix acceleration. This positioning is central to how the system is used in both numerical Earth-system simulation and large-scale AI training [2605.08633].

| Component | Reported specification |
|---|---|
| System type | CPU-based Armv9 HPC-AI supercomputer |
| Site | National Supercomputing Center in Shenzhen |
| Processor | Armv9 LX2 |
| Node composition | 2 LX2 processors per node |
| Cores per processor | 304 CPU cores |
| Clustering | 8 CPU clusters, 38 cores per cluster |
| On-package memory | 32 GB HBM per processor |
| Peak HBM bandwidth | 4 TB/s peak aggregate bandwidth per processor |
| Off-package memory | 256 GB DDR |
| NUMA organization | 16 NUMA domains per processor |
| Interconnect | LingQi high-speed network (LQLink), 1.6 Tb/s per node |
| Vector/matrix support | Armv9 SVE and Armv9 SME |

Each processor contains **2 compute dies**; each core has **32 KB L1 instruction cache** and **32 KB L1 data cache**; each cluster has **28.5 MB shared L2 cache**. The hierarchical memory design is explicit: one **HBM domain** and one **DDR domain** per cluster, with a dedicated **SDMA engine** for DDR↔HBM movement. A single LX2 processor is reported to have theoretical peak throughput of **60.3 TFLOP/s FP64**, **240 TFLOP/s BFloat16/FP16**, and **960 TOP/s INT8** [2605.08633].

This hardware profile matters because the two major published LineShine workloads stress different aspects of the machine. CAPES emphasizes coupled modeling, ensemble concurrency, and operational throughput, whereas Earth-observation generative compression emphasizes dense-transformer training, memory pressure, and communication-intensive runtime behavior. A plausible implication is that LineShine is being positioned as a general exascale platform for workflows in which simulation and AI are both first-class computational modes.

## 2. Platform for hybrid numerical-AI seasonal forecasting

The most explicit system-level application paper describes LineShine as the platform on which **CAPES**, the **CRESM-AI Seasonal Prediction Ensemble System**, becomes operationally feasible at decadal-hindcast scale and, in a separate configuration, at kilometer-scale resolution. CAPES combines a **physics-based coupled regional numerical model** and a **data-driven AI seasonal forecasting model** within a fused workflow for East Asia [2605.24896].

The numerical track is **CRESM**, a coupled regional Earth system model built from **CWRF** as the regional atmosphere component, **CoLM** as the land surface component, and **UOM** as the simplified upper-ocean component, all tied together with the **CPL7-MCT coupling framework**. This track serves as the physically grounded backbone for seasonal prediction and is used for both **15-km seasonal flood-season forecasting** and **1-km high-resolution extreme-weather simulation**.

The AI track is designed to generate large ensemble membership at low marginal cost. It ingests multi-source reanalysis data from **ERA5**, **ORAS5**, and **ERA5-Land**, and combines information from the past **14 days**, past **3 months**, and past **2 years** to represent weather evolution, seasonal background circulation, and climate memory. The AI ensemble uses a **dual-perturbation strategy**: **40 initial-condition perturbations** produced by a **multi-stream VAE + Diffusion Transformer (DiT)**, and for each of those, **40 latent forecast perturbations** injected during inference, yielding
$$
40 \times 40 = 1600
$$
AI ensemble members per year [2605.24896].

The fused forecast merges numerical and AI members through an adaptive fusion/post-processing stage. The fusion module scores each member using **sign consistency** relative to the ensemble-median anomaly and **anomaly magnitude** relative to climatology; these are normalized and combined into a unified contribution score so that the final product better captures both dominant signals and extreme anomalies. This suggests that LineShine is not being used merely to accelerate two separate models, but to sustain a single operational pipeline in which coupled simulation, AI inference, and fusion are jointly executed.

## 3. Ensemble composition, concurrency, and operational throughput

The key 15-km operational hindcast configuration on LineShine comprises **174 numerical members**, **1,600 AI members**, and **1,774 total hybrid members**. The numerical ensemble is assembled in two stages: **27 members** from **3 start dates × 9 physics-scheme combinations**, and **147 members** from the same 3 start dates plus a **\(7 \times 7\)** sweep over two sensitive physical parameters, so that
$$
27 + 147 = 174,
$$
and with the AI component
$$
174 + 1600 = 1774.
$$
The paper also reports the concurrency model: each **numerical member uses 8 nodes**, every **two AI members share 1 node**, and a full 15-km ensemble occupies **2,192 nodes** [2605.24896].

This concurrency structure is tied directly to LineShine’s role as an exascale system. For the **ten annual hindcasts from 2016 to 2025**, the full CAPES workflow completes in **14.6 hours** for the **10-year, 1,774-member hindcast campaign**. The paper explicitly states that this allows the model to “validate and iterate forecasting methods over a decadal sample within one day.” In the authors’ framing, the significance is not simply a shorter wall-clock time; it is the conversion of full-system exascale resources into operational flood-season forecasting throughput [2605.24896].

The paper also states that LineShine makes it possible to relax the traditional trade-off among **physical fidelity**, **ensemble size**, and **operational cost** by providing **massive core count**, **HBM bandwidth**, **high-bandwidth interconnect**, and **matrix/vector acceleration for AI**. A plausible implication is that the system’s distinguishing feature, in this context, is balanced throughput across heterogeneous workload types rather than peak kernel performance in isolation.

## 4. Forecast evaluation and kilometer-scale capability

Forecast skill in the CAPES study is evaluated primarily with the **PS Score**, an operational metric used by the China Meteorological Administration for seasonal precipitation forecasting. The anomaly categories are **normal**, **first-level anomaly** \(N1\), defined as precipitation anomaly percentage in the range \(20\%\sim50\%\) or \(-50\%\sim-20\%\), and **second-level anomaly** \(N2\), defined as \(>50\%\) or \(<-50\%\). A penalty term \(M\) is added when the observed precipitation is extreme (\(>100\%\) or \(<-100\%\)) but the forecast fails to reach \(\pm 50\%\). Let \(N_0\) be the number of samples with the correct anomaly sign. The score is
$$
PS = \frac{2\times N_0 + 2\times N_1 + 4\times N_2}{(N-N_0) + 2\times N_0 + 2\times N_1 + 4\times N_2 + M}\times 100.
$$
Using this metric, the paper reports that CAPES improves the **mean prediction score** from ECMWF’s **71.8** to **75.9** over the 2016–2025 hindcast period [2605.24896].

The same study reports ensemble-scaling behavior at a fixed **CRESM:AI ratio of 1:10**: PS rises from **72.1** at **22 members** to **75.9** at the full **1,774-member** ensemble. Supporting metrics such as **ACC** and **RMSE** are also reported for the ViT-based AI component, but PS is the main operational score for the hindcast comparison. This suggests that LineShine’s contribution is closely tied to enabling ensemble enlargement at a scale that produces measurable forecast-skill gains.

The paper distinguishes two LineShine execution modes. The **15-km configuration** is the production seasonal forecasting mode used for the 10-year hindcasts, operational flood-season forecasting, large-ensemble generation, and the reported **14.6-hour** full hindcast runtime. The **1-km configuration** is the high-resolution capability mode. Its explicit demonstration case is **Super Typhoon Saola**, initialized at **0000 UTC 31 August 2023** and integrated for **72 hours**. The 1-km CRESM simulation reproduces the **compact vortex core**, **spiral rainbands**, **intense eyewall precipitation**, and the typhoon track close to **IBTrACS**. The paper further states that full-machine use enables a **six-month operational flood-season forecast in 158.8 hours**, that is, about **one week**, and uses this to argue for the feasibility of kilometer-scale fused forecasting on a one-week timescale [2605.24896].

## 5. Exascale training of Earth-observation generative compression

A separate LineShine paper presents the system as the enabling platform for exascale training of a large **historical-prior generative compression** model for Earth observation. The scientific premise is that Earth observation repeatedly measures the same evolving planet, making historical-prior learning feasible for extreme compression, and the system result is that this paradigm can be trained at exascale on a CPU supercomputer when the full stack is co-designed [2605.08633].

The model family includes **D2AR-rec-3B, 6B, and 8B** variants, with the key large-scale training result reported for the **6B** model. The paper’s implementation sustains **1.54 EFLOP/s** and peaks at **2.16 EFLOP/s** in end-to-end training. In the reported weak-scaling result, the 6B model scales to **20,480 nodes**, sustains **1.54 EFLOP/s**, and achieves **76.0%** weak scaling efficiency; the same paper reports the **3B model** at **4,096 nodes** with **275 PFLOP/s** and **80.4%** efficiency, and the **8B model** at **4,096 nodes** with **295 PFLOP/s** and **70.4%** efficiency [2605.08633].

The paper defines the sustained number as the whole training application, including communication and I/O, and contrasts it with the compute-only peak. Training is measured over **20 iterations**, with the **average per-iteration time over the last 10 iterations** reported; the **Megatron-LM FLOP formulation** is used; sustained BFloat16 FLOP/s is computed as analytical model FLOPs divided by measured iteration time; and **MFU** is defined as sustained FLOP/s divided by the theoretical BFloat16 peak of the participating nodes. It is also noted that **1 LX2 node** has vendor-advertised peak of **480 TFLOP/s BFloat16**, and the performance table reports the D2AR baseline at **6.3B parameters**, **252M batch size**, **Armv9 LX2 CPU**, **40,960 CPUs**, **15.7% MFU**, and **1543 PFLOP/s** sustained, equivalent to **1.543 EFLOP/s** [2605.08633].

The scientific significance claimed in that paper is that full-scale training changes the learning regime: a large-batch full-machine setting reaches a target loss in **50 steps**, whereas a **4-node** configuration still has not reached that level after **5000+ steps**. This suggests that LineShine is being used not only to shorten time to solution, but to make a broader-coverage historical-prior learning regime operationally realizable.

## 6. Co-design, memory hierarchy, and diagnostics relevance

The Earth-observation training paper attributes LineShine’s performance to **co-optimization across model design, kernels, memory hierarchy, runtime, and parallelism**. At the model level, it uses **task decoupling**, a **single-stream diffusion transformer** inspired by **Z-Image**, lightweight **EQ-VAE** adapters, and the injection of **geographic priors** from global historical archives into the Flow Matching process. At the kernel level, it implements a custom **SME-GEMM** strategy with complementary micro-kernels for \(64\times K\) by \(K\times16\) and \(16\times K\) by \(K\times64\), analytical determination of `magic_k` from **L2 cache capacity**, reuse-aligned thread partitioning, near-uniform tiling, and a **K-aware accumulation policy** [2605.08633].

Memory placement is treated as a constrained global allocation problem because parameters, activations, gradients, and optimizer states do not fit in local HBM. The paper reports locality-sensitive bandwidth values of **450 GB/s** for local HBM, **230 GB/s** for same-die remote HBM, **170 GB/s** for cross-die HBM, and **45 GB/s** for cross-CPU HBM; for DDR it reports **125 GB/s** local, **110 GB/s** cross-die, and **45 GB/s** cross-CPU. Its placement strategy keeps only **attention output activations** in HBM during the forward pass, places gradients and intermediates in HBM during the backward pass, and offloads persistent parameter gradients to DDR during SP communication. The runtime paper also reports that default PyTorch imposed about **24.2% overhead**, while an asynchronous runtime reduced this to **1.9%** by overlapping operator dispatch, memory allocation, tensor view operations, kernel execution, and communication scheduling [2605.08633].

The distributed strategy is topology-aligned. The paper specifies **one MPI process per CPU cluster**; each cluster has **38 cores**, with **37 available**; each process has access to **32 GB DDR** and **4 GB HBM**; and within a die, four processes can communicate via **shared memory**. **Sequence Parallelism (SP)** is applied across the **four intra-die processes** using **ring attention**, and **Hybrid Shared Data Parallelism (HSDP)** shares and shards optimizer states across processes within **four nodes**. Forward-pass communication exchanges \(K\) and \(V\), whereas backward-pass communication exchanges \(Q\) and \(\mathrm{grad\_out}\), reducing backward communication volume by about **50%** compared with a symmetric exchange strategy [2605.08633].

A separate exascale diagnostics paper does **not** discuss LineShine by name and is **not** a system paper for LineShine, but it is directly relevant to LineShine-style operations because it addresses **exascale telemetry volume**, **performance bottleneck analysis**, **heterogeneous CPU/GPU systems**, **MPI rank scaling to 100,000**, **topology-aware network diagnostics**, and **trace reconstruction and iteration-aware modeling**. Its accelerated infrastructure for the **hpcanalysis** framework includes a C++ Read API, OpenMP parsing, GPU backends, and **pybind11** exposure to Python; on Aurora it ingested a **100,000-rank** dataset in **9.6878 seconds**, and its topology-aware workflow localized network congestion across **22 distinct racks**. It also introduced a tri-dimensional model over **event**, **trace index**, and **iteration index**, and used it to estimate a **32.28% potential speedup** for a GAMESS workload on Frontier [2605.03561].

Taken together, these publications portray LineShine as an exascale platform whose defining role is operational enablement. In flood-season forecasting, it supports a **1,774-member hybrid ensemble**, **ten annual hindcasts (2016–2025) in 14.6 hours**, and a reported PS improvement from **71.8** to **75.9**. In Earth-observation AI, it supports multi-billion-parameter training at **1.54 EFLOP/s sustained** on **20,480 nodes**. The surrounding diagnostics literature suggests that machines in this class require equally scalable methods for ingestion, topology-aware diagnosis, and iteration-level performance reconstruction, even when those methods are documented on systems other than LineShine [2605.24896] [2605.08633] [2605.03561].

Source: https://www.emergentmind.com/topics/lineshine-exascale-supercomputer