LineShine Armv9 CPU Supercomputer
- LineShine is an Armv9 CPU-only supercomputer using 40,960 CPUs to achieve exascale BF16 training for extreme data compression in Earth observation.
- It features many-core LX2 processors with SME and SVE optimizations, coupled with a hierarchical HBM/DDR memory system for efficient data locality.
- The system attains 1.54 EFLOP/s sustained performance through co-designed kernels, topology-aware execution, and an asynchronous runtime that minimizes communication overhead.
Searching arXiv for the cited papers to verify metadata and support the article. The LineShine supercomputer is the system designation used for an Armv9 CPU–only, exascale HPC–AI converged platform at the National Supercomputing Center in Shenzhen (NSCC-SZ), deployed in reported work to exascale-train a historical-prior generative compression model for Earth observation. In that role, it is presented not as a generic storage-oriented platform, but as a machine for end-to-end BF16 training of a Dual-Decoupled Asymmetric Compression and Reconstruction workload that targets on-demand 100× to 10,000× data reduction across downstream tasks while sustaining 1.54 EFLOP/s and peaking at 2.16 EFLOP/s in training (Zhang et al., 9 May 2026).
1. System identity and operational role
LineShine is described as an Armv9 CPU–only system with no GPUs or NPUs. In the reported full-machine configuration, the work uses 40,960 CPUs, corresponding to 20,480 nodes. Its role in the cited study is tightly coupled to exascale training of a historical-prior generative compression model for Earth observation, rather than to a broad benchmark suite or a conventional storage-and-transmission compression pipeline (Zhang et al., 9 May 2026).
This operational role is central to how the platform is characterized. The training target is a generative compression framework that learns from historical Earth observation archives and supports on-demand 100× to 10,000× data reduction across downstream tasks. The paper argues that Earth observation repeatedly measures the same evolving planet, making historical-prior learning feasible for extreme compression. In that framing, LineShine functions as an enabling infrastructure for a workload whose objective is scientific reuse of Earth observation data rather than only archival compaction.
A common misconception would be to interpret the reported exascale result as an accelerator result. The description explicitly emphasizes a CPU-only Armv9 platform. Another misconception would be to assume that “exascale” here refers only to theoretical hardware peak. The reported sustained value is an end-to-end training throughput, while the higher 2.16 EFLOP/s figure is compute-only peak for forward and backward compute excluding communication and I/O.
2. Node architecture, core organization, and hierarchical memory
Each LineShine node contains 2 LX2 Armv9 processors. Each processor has 304 CPU cores organized as 8 clusters with 38 cores per cluster. Per-core caches are 32 KB L1-I and 32 KB L1-D, and each cluster has a 28.5 MB shared L2. Each processor integrates two compute dies; each die has 4 cluster-local HBM domains and 4 DDR domains, for a total of 16 NUMA domains per processor and 32 NUMA domains per node. Each cluster is associated with one HBM domain and one DDR domain (Zhang et al., 9 May 2026).
The memory system is split between on-package HBM and off-package DDR. Per processor, the system provides 32 GB HBM with 4 TB/s peak aggregate bandwidth and 256 GB DDR. Per node, that becomes 64 GB HBM with up to 8 TB/s peak aggregate processor-local bandwidth and 512 GB DDR. The measured locality effects reported in the paper are pronounced: local HBM is about 450 GB/s, same-die remote HBM about 230 GB/s, across dies about 170 GB/s, and across CPUs about 45 GB/s; local DDR is about 125 GB/s, across dies about 110 GB/s, and across CPUs about 45 GB/s. These measurements explain why the software stack adopts cluster-level binding and operator-specific placement rather than uniform memory allocation (Zhang et al., 9 May 2026).
Armv9 execution support includes SVE and SME. SME uses ZA tile registers and outer-product instructions, and the paper states that custom kernels exploit SVE and SME. The paper does not state SVE or SVE2 vector width, nor whether vector-length-agnostic programming was used. Peak compute per processor is reported as 60.3 TFLOP/s FP64, 240 TFLOP/s BF16/FP16, and 960 TOP/s INT8. The per-node theoretical BF16 peak is 480 TFLOP/s, which is the normalization basis used for MFU.
| Component | Per processor | Per node |
|---|---|---|
| Processors | 1 LX2 Armv9 | 2 LX2 Armv9 |
| CPU cores | 304 | 608 |
| HBM | 32 GB | 64 GB |
| DDR | 256 GB | 512 GB |
| Theoretical BF16 peak | 240 TFLOP/s | 480 TFLOP/s |
The architectural significance of this layout is not only core count. The platform combines many-core Armv9 CPUs, SME/SVE execution, and a hierarchical memory system with fine-grained NUMA partitioning. This suggests that LineShine’s effective performance depends on whether compute kernels, memory placement, and parallel decomposition are aligned with cluster-local HBM and DDR domains.
3. Interconnect, process placement, and execution model
The system uses the LingQi high-speed network, LQLink, at 1.6 Tb/s per node. The topology is not specified. Inter-process communication uses MPI, and the execution model binds one MPI process to one CPU cluster. In that arrangement, each process receives 38 cores, with 37 usable by the application, together with that cluster’s 4 GB HBM and 32 GB DDR. Within a die, four processes communicate through shared memory (Zhang et al., 9 May 2026).
The topology-aligned strategy extends beyond process binding. Intra-die sequence parallelism is implemented across four processes using ring attention, and shared memory is used both for K/V and Q/grad_out exchanges and for gradient all-reduce within sequence-parallel groups. The communication schedule is asymmetric: ring attention exchanges K/V in the forward pass and Q/grad_out in the backward pass, reducing backward communication volume by about 50% relative to a symmetric design.
The system software is PyTorch-based, but the reported implementation does not rely on the default framework runtime in its original form. Profiling shows default PyTorch runtime overhead of about 24.2%. A custom asynchronous runtime with a dedicated launch thread reduces framework overhead to 1.9% and overlaps operator dispatch, allocation, and tensor-view operations with kernel execution. Communication is also overlapped with compute, with dedicated cores assigned to communication tasks to minimize interference (Zhang et al., 9 May 2026).
The resulting execution model is explicitly CPU-centric. The paper notes that existing communication libraries were not well tuned for CPU BF16 and topology-aware collectives, so the implementation introduces hook-based scheduling, explicit synchronization, dedicated communication threads or cores, and overlap with compute. The significance is that system throughput is treated as a property of the full runtime stack, not only of dense linear algebra kernels.
4. Kernel design, memory placement, and topology-aware optimization
Dense compute is organized around a reuse-directed asymmetric SME-GEMM design. Two complementary SME micro-kernels are used: and . At runtime, the implementation selects between M-major and N-major reuse in order to maximize per-thread data reuse. A parameter called magic_k, derived from L2 capacity rather than from empirical tuning, guides K-tiling and determines whether partial sums should remain resident (Zhang et al., 9 May 2026).
The memory strategy is similarly asymmetric. One operand is streamed through a large HBM-packed buffer to exploit high bandwidth, while the other operand is kept thread-private in small local buffers. Output handling is K-aware: when , the result is written directly; otherwise FP32 partial sums are accumulated in HBM. Bias addition and output scaling are fused into compute and write-back, reducing memory traffic.
Hierarchical-memory placement is operator- and lifetime-aware. In the forward pass, only attention outputs are placed in HBM, because they are identified as the most bandwidth-sensitive allocations. Those outputs are immediately cast from FP32 to FP16 and the HBM allocation is released. In the backward pass, most gradients and intermediates are short-lived and placed in HBM, while parameter gradients are offloaded to DDR during sequence-parallel communication phases in order to free HBM space. Placement is therefore driven by both operator sensitivity and tensor lifetime.
Parallelization is matched to the hardware topology. Sequence parallelism is kept within a die, and Hybrid Shared Data Parallelism shards and partially shares optimizer states within four nodes, reducing memory footprint and redundant optimizer compute compared with full replication. The paper reports sensitivity studies over sequence-parallel and HSDP group sizes before selecting final configurations.
At the single-node level, the cumulative effect of these optimizations is explicit. For the 6B model, the step time is reduced from 51.31 s at the vendor-BLAS baseline to 26.32 s with HBM-aware placement, to 7.68 s with SVE/SME kernels, to 6.12 s with communication optimization, and to 4.98 s with the asynchronous runtime, for an overall 10.3× speedup. For the 3B model, step time decreases from 21.56 s to 2.54 s with the full stack. For the 8B model, the baseline is out of memory, and the workload becomes feasible only after the memory optimizations are introduced (Zhang et al., 9 May 2026).
5. Performance methodology and exascale training results
The performance methodology is defined in the paper rather than inferred from generic HPC practice. Sustained BF16 FLOP/s is computed as analytical model FLOPs divided by measured end-to-end iteration time, with analytical model FLOPs following Megatron-LM’s formulation. MFU is defined as measured sustained BF16 FLOP/s of the whole system divided by the theoretical BF16 peak of the participating nodes. The per-node BF16 peak used for normalization is 480 TFLOP/s. The paper also gives the general definitions
and
It emphasizes weak scaling rather than strong scaling (Zhang et al., 9 May 2026).
At full scale, the reported sustained performance is 1.54 EFLOP/s BF16 end-to-end on 20,480 nodes and 40,960 CPUs, with weak-scaling efficiency of 76.0% for the 6B model. The compute-only peak for forward and backward compute, excluding communication and I/O, is 2.16 EFLOP/s on the same configuration. The state-of-the-art table reports an MFU of 15.7% for D2AR on 40,960 CPUs with a 6.3B model and a global batch of 252 M.
Additional large-scale cases are also reported. The 3B and 8B models scale to 4,096 nodes, reaching 275 PFLOP/s and 295 PFLOP/s sustained, with weak-scaling efficiencies of 80.4% and 70.4%, respectively. End-to-end reporting includes I/O, and each configuration is measured over twenty iterations with the average of the last ten iterations reported to avoid warmup effects.
The training dynamics are notable. From the same checkpoint, full-machine large-batch training reaches a target intermediate loss in about 50 steps, whereas a 4-node setup does not reach that level even after more than 5,000 steps, and the large-batch trajectory is described as smoother. This is a training-behavior observation rather than a pure throughput metric, but it is relevant because it links scale to optimization dynamics in the reported workload.
In comparative context, the paper notes that this work sustains 1.543 EFLOP/s on 40,960 CPUs at 15.7% MFU on a CPU-only platform. It contrasts this with large GPU-scale jobs reporting 379.7 to 4,110 PFLOP/s sustained on thousands to tens of thousands of GPUs, often with MFU in the 16% to 55% range, and with prior Arm CPU-only AI training on A64FX 16,384 nodes for 3D-CNN at about 2.22 PFLOP/s sustained with about 2% MFU. The significance of that comparison is narrow and specific: it supports the claim that exascale ML throughput is achievable on a CPU-only Armv9 system when kernels, runtime, memory hierarchy, and parallel decomposition are co-optimized.
6. Workload characteristics: D2AR and Earth observation generative compression
The workload used to characterize LineShine is the Dual-Decoupled Asymmetric Compression and Reconstruction framework, abbreviated D2AR. In the on-orbit stage, arbitrary compressors and a lightweight feature mapper produce control tokens. In the ground stage, D2AR-rec, a Flow-Matching generative model guided by control tokens and global geographic priors, reconstructs high-fidelity outputs from ultra-low-entropy inputs. The D2AR-rec backbone is a single-stream diffusion transformer, described as Z-Image style, operating in the EQ-VAE latent space before decoding to physical sensor space. Prior injection is implemented through global spatiotemporal geographic embeddings used as control to recover spectra and structures lost under extreme compression (Zhang et al., 9 May 2026).
The reported model configurations used for performance are D2AR-rec-3B with 17 layers, hidden size 3840, and 30 heads; D2AR-rec-6B with 36 layers, hidden size 3840, and 30 heads; and D2AR-rec-8B with 46 layers, hidden size 4096, and 32 heads. Training uses BF16 precision. This workload stresses the platform in ways that directly motivate the system design choices: dense transformer-like computation, bandwidth-sensitive attention, substantial activation and gradient traffic, and a need for memory placement that distinguishes short-lived from long-lived tensors.
Application-level validation is reported on Sentinel-2 multispectral data over the global top-1,000 cities across eight years. Three case studies are listed in the reconstruction table. At 6,104× compression using HL-CompNet, the baseline has PSNR 13.2252, LPIPS 0.6497, MS-SSIM 0.5922, and NDVI error 0.0982; with D2AR-rec, the values are PSNR 14.9484, LPIPS 0.1074, MS-SSIM 0.9238, and NDVI 0.0915. At 6,295× compression using LIC-TCM, the baseline has PSNR 15.3820, LPIPS 0.4504, MS-SSIM 0.9087, and NDVI 0.0776; with D2AR-rec, the values are PSNR 16.5998, LPIPS 0.1218, MS-SSIM 0.9537, and NDVI 0.0818. At 17,777× compression using MLIC++, the baseline has PSNR 13.1023, LPIPS 0.6189, MS-SSIM 0.8416, and NDVI 0.0978; with D2AR-rec, the values are PSNR 14.1299, LPIPS 0.1193, MS-SSIM 0.9018, and NDVI 0.0893.
A global-prior coverage ablation compares training on 1,000 cities with training on 900 cities, using the same six-year span and evaluating on a held-out set of 100 cities over the next two years. Adding 100 cities improves PSNR from 12.1516 to 12.4708, lowers LPIPS from 0.3273 to 0.2990, raises MS-SSIM from 0.8474 to 0.8586, and lowers NDVI error from 0.0934 to 0.0906. This directly supports the stated role of historical and geographic prior information in the framework.
The downstream task evaluation uses land-cover scene classification on DynamicEarthNet. Using reconstructed data, Macro F1 remains essentially unchanged, with examples including 0.7540 versus 0.7540 and a minor +0.0007 in one case, while mAP remains close to original, with examples 0.8535 to 0.8465, 0.8761 to 0.8372, and 0.8535 to 0.8312. Exact accuracy differences are small, such as 0.5000 to 0.4792. Figure-based qualitative results are described as showing high-fidelity textures at 100× and structurally consistent semantics and spectral curves at 10,000× even when micro-textures are smoothed. In system terms, these results explain why the platform was evaluated on this workload: it is both computationally demanding and scientifically constrained.
7. Related software portability context, limitations, and open questions
A related but distinct line of work is the CUDA-to-CPU transpilation framework based on Polygeist and MLIR, which translates CUDA programs into CPU-threaded code while preserving analyzable high-level parallel constructs. That work reports a 76% geometric mean speedup over handwritten OpenMP code on Rodinia and shows that CUDA kernels from PyTorch can run efficiently on the CPU-only supercomputer Fugaku, with a PyTorch compatibility layer outperforming the PyTorch CPU native backend by 2.7× (Moses et al., 2022).
Its relevance to LineShine is contextual rather than documentary. The paper explicitly states that, for a hypothetical Armv9-based supercomputer “LineShine,” the same approach applies directly: GPU parallel semantics are preserved, barrier-aware transformations remain available, and the resulting code can be compiled for Armv9 with SVE or SVE2 vectorization and NUMA-tuned threaded execution. This suggests a plausible software-portability path for CUDA-origin workloads on Armv9 CPU systems, but it should not be conflated with the actual software stack reported for the LineShine exascale generative compression result.
Several limitations and unspecified items are explicit in the LineShine report. CPU clock frequencies are not provided. The paper does not state the SVE vector width, whether SVE2 is used, or whether vector-length-agnostic programming was employed. It does not provide OS distribution or version, specific MPI or BLAS library names, interconnect topology, storage system type, storage bandwidth, time-to-train complete models or datasets, or power and energy-efficiency data (Zhang et al., 9 May 2026).
These omissions matter for reproducibility and comparison. They do not invalidate the reported results, but they constrain cross-system interpretation, especially for energy efficiency, storage sensitivity, and portability of the Armv9-specific kernel and placement strategies. The paper itself notes that many gains rely on SME, SVE, and the LX2 HBM/DDR/NUMA layout, and that CPU communication libraries and BF16 collectives required extra work. A plausible implication is that future tuned libraries could further increase MFU, but the reported article does not quantify that effect.
Taken together, the record presented for LineShine is technically specific. It describes a CPU-only Armv9 supercomputer whose exascale machine-learning performance emerges from the conjunction of many-core LX2 processors, SME/SVE-oriented kernels, explicit hierarchical-memory placement, cluster-aligned NUMA binding, intra-die shared-memory sequence parallelism, HSDP for optimizer-state management, and an asynchronous runtime that reduces framework overhead. Within the scope reported, the system demonstrates that exascale BF16 training of a modern large generative model can be realized on an Armv9 CPU platform when the architecture, kernels, runtime, and workload are co-designed.