LineShine Exascale Supercomputer
- LineShine Exascale Supercomputer is a CPU-based Armv9 HPC-AI system designed for high-performance numerical simulations and large-scale AI training.
- It features a sophisticated memory hierarchy, high per-node bandwidth, and optimized interconnects enabling hybrid workflows for flood forecasting and Earth observation.
- The platform integrates coupled numerical and AI ensembles, supporting a 1,774-member hybrid workflow to deliver significant forecast accuracy improvements.
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 (Chen et al., 24 May 2026, Zhang et al., 9 May 2026).
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 (Zhang et al., 9 May 2026).
| 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 (Zhang et al., 9 May 2026).
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 (Chen et al., 24 May 2026).
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
AI ensemble members per year (Chen et al., 24 May 2026).
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 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 (Chen et al., 24 May 2026).
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 (Chen et al., 24 May 2026).
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 , defined as precipitation anomaly percentage in the range or , and second-level anomaly , defined as or . A penalty term 0 is added when the observed precipitation is extreme (1 or 2) but the forecast fails to reach 3. Let 4 be the number of samples with the correct anomaly sign. The score is
5
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 (Chen et al., 24 May 2026).
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 (Chen et al., 24 May 2026).
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 (Zhang et al., 9 May 2026).
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 (Zhang et al., 9 May 2026).
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 (Zhang et al., 9 May 2026).
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 6 by 7 and 8 by 9, analytical determination of magic_k from L2 cache capacity, reuse-aligned thread partitioning, near-uniform tiling, and a K-aware accumulation policy (Zhang et al., 9 May 2026).
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 (Zhang et al., 9 May 2026).
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 $27 + 147 = 174,$0 and $27 + 147 = 174,$1, whereas backward-pass communication exchanges $27 + 147 = 174,$2 and $27 + 147 = 174,$3, reducing backward communication volume by about 50% compared with a symmetric exchange strategy (Zhang et al., 9 May 2026).
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 (Grbic, 5 May 2026).
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 (Chen et al., 24 May 2026, Zhang et al., 9 May 2026, Grbic, 5 May 2026).