灵晟超算登顶 TOP500：2 EFLOPS 全国产纯 CPU 架构路线还有希望吗（6/29 更新）

更新：灵晟超算登顶 TOP500：2 EFLOPS 全国产纯 CPU 架构路线还有希望吗

更新说明（2026-06-26）： 本文基于 The Next Platform 深度拆解（Timothy Prickett Morgan, 2026-06-25）和 HACI 2026 演讲幻灯片，对原文做数据确认和补充分析。新增/修正的内容以 「更新」 标注，原文推导和判断全部保留。查看修正详情

更新说明（2026-06-29）： 基于 Chips and Cheese 对 ISC 2026 TOP500 榜单的详细分析（George Cozma, 2026-06-25），补充官方排名数据、HPCG 双冠验证、Top 500 格局变化及周边分析。新增内容以 「更新 6/29」 标注。

2026 年 6 月 23 日，ISC 2026 汉堡，TOP500 新榜：中国「灵晟」（LineShine）2.198 EFLOPS FP64 登顶，全球首台持续性能突破 2 EFLOPS。「更新」实际配置为 40,960 颗 CPU（论文）/ 45,360 颗 CPU（HPL 跑分），13,789,440 核。 LX2 由 NSC 深圳与华为海思联合设计，零 GPU，从处理器到互联网络全栈国产。

与此同时，TOP500 前十里另外四台 Exascale 系统——El Capitan、Frontier、Aurora、JUPITER——全部走 CPU+GPU 异构。上一代纯 CPU 超算冠军富岳（Fugaku），2026 年已跌至第六，且日本已宣布下一代 Fugaku-NEXT 将转向 ARM CPU + NVIDIA GPU 异构。

纯 CPU 路线是走到了终点，还是刚打开一扇新的门？

灵晟提供了一个前所未有的分析样本：它是史上最强的纯 CPU 超算，同时有三篇 arXiv 论文详细记录了真实负载的性能数据。把它拆开看——CPU 微架构、互联网络、端到端软件路径、三篇论文的实证——可以判断这条路线当前的能力边界和未来的扩展空间。

一、LX2 处理器：在已知面积里放 304 个核

1.1 工艺与芯片面积推算

灵晟的核心是 LX2 处理器：304 核、ARMv9 架构、1.55 GHz 基础频率、每 socket 集成 64 GB HBM（8 TB/s），由 2 × 32 GB chiplet 实现，690W TDP。

工艺节点未公开。从可用的公开信息做约束推算：

参照系一：富士通 A64FX。 TSMC 7nm，48 核（含 4 辅助核）+ 4 组 HBM2 控制器，芯片面积 约 480 mm²，集成 87.86 亿晶体管。每核（含分摊的 L2 和控制器）约 10 mm²。

参照系二：ARM Neoverse V2。 在 TSMC 5nm 下的物理实现，单核（含 1MB private L2）约 2-3 mm²。Neoverse N2 在 7nm 下约 3-4 mm²/核。

LX2 的面积约束。 如果用 SMIC 7nm 工艺（国产 HPC 芯片当前最可能的节点），SMIC 7nm 的晶体管密度约 90-100 MTr/mm²（N+1 级别），低于 TSMC N7 的 91 MTr/mm² 和 N5 的 173 MTr/mm²。LX2 的 304 核如果单 die 集成，按 3-4 mm²/核（7nm 级别核心 + 分摊 L2），仅核心区域就需要 900-1200 mm²。加上 8 组 HBM 控制器、灵启 NIC、DDR5 控制器、SDMA 引擎、I/O PHY，总面积会达到 1400-1800 mm²。

「更新」TNP 确认工艺为 SMIC 7nm N+3 改良版。 1.55 GHz 远低于该工艺可达的 ~3 GHz——主动降频来平衡核心速度和内存速度，同时压低功耗曲线。

7nm 光刻的 reticle limit 是 858 mm²。 单 die 放不下。

推论：LX2 几乎确定是 chiplet 设计。 「更新」TNP 从 die shot 确认：2 chiplet，每 chiplet 48 个核心块 × 4 核 = 192 个原始核，每 socket 384 个原始核。实际暴露 304 个核 → 良率 79.2%，与 SMIC 7nm 预期良率一致。（每个 4 集群 × 38 = 152 核，约 600-700 mm²）加 1 个 I/O die（HBM 控制器、DDR5 控制器、NIC、SDMA）。这跟 AMD Zen 系列的 chiplet 架构思路一致——计算 die 用先进工艺，I/O die 可以用更成熟、更便宜的工艺。

chiplet 方案对性能有直接影响：同一 chiplet 内的 4 个集群之间通信延迟低（共享 L2 或 ring），跨 chiplet 的 4 个集群通信要走 I/O die，延迟更高。这形成了一个两级 NUMA：

这个 NUMA 层级直接影响 MPI 进程绑定策略——通信密集的进程对应放在同一 chiplet 上。「更新」幻灯片确认 LX2 具有 8 个 NUMA 域（跨两个 chiplet 组织 DRAM 和 HBM），比原文推测的两级 NUMA 更复杂。

「更新」深入分析：SMIC 7nm N+3 的制造含义。 1.55 GHz vs 3 GHz 的降频不只是散热策略——它直接反映了 SMIC 7nm N+3 的频率-功耗曲线。在国产光刻和工艺限制下，SMIC 的高频段漏电流急剧上升，每增加 100 MHz 功耗增长远超线性。TNP 说的"在核心速度和内存速度之间取得平衡"的深层含义是：HBM 的带宽（8 TB/s）已经固定，再提核心频率只会让 CPU 更快地等内存——增加功耗换不来等比例的性能提升。所以 LX2 选择 1.55 GHz 不是"做不到更快"，而是"再快不划算"。这种"以规模换单点性能、以数量补频率"的策略，跟中国高铁（速度不追求最高但路网密度极高）在逻辑上是同构的。

良率 79.2% 的工艺含义。 384 个原始核、304 个活跃核——在 SMIC 7nm N+3 上做出接近 80% 的核心良率，对 192 核/chiplet 的大 die 而言并不差。作为对比，早期 Intel Sapphire Rapids（Intel 7，约 400 mm² 的复杂 die）在量产初期的良率也是类似水平。这说明 SMIC 在 7nm 级别已经进入了"可以量产但良率需要持续优化"的阶段——不是实验室玩具，但距离 TSMC 的经济量产（良率 >95%）还有一代工艺的差距。每颗 LX2 少掉的 80 个核，保守估计增加了 15-20% 的单颗 CPU 成本。但这恰恰是"国产替代"必须承受的代价。

1.2 微架构：对照 ARM Neoverse V2

LX2 的微架构参数未公开。但 ARMv9 架构规范和 ARM 自研参考核心（Neoverse V2/V3）给出了合理推测基准。Neoverse V2 是 ARM 面向 HPC 和云的旗舰核心，也是目前公开的最接近 LX2 定位的 ARMv9 核心。

LX2 跟 Neoverse V2 最显著的差异在两处：

差异一：L2 架构完全不同。 Neoverse V2 用每核 private L2（1-2 MB），LX2 用每集群 38 核共享 L2（28.5 MB）。共享 L2 的优势是总容量大（8 × 28.5 = 228 MB vs 304 × 1 = 304 MB，差距不大，但共享方式让同集群的核心可以复用彼此加载的数据）。代价是 38 核争同一个 L2 的 bank 和带宽。前文推算过：38 核满负荷 FMA 对 L2 的带宽需求约 7.5 TB/s，而 28.5 MB / 32 bank × 256 GB/s/bank ≈ 8 TB/s——刚好卡住。38 核就是这个 L2 配置下的最大核心数。

差异二：SME 集成。 Neoverse V2 不含 SME（ARM 在 V3 世代才计划集成）。「更新」TNP 确认 SME 为华为定制实现。 LX2 自行集成了 SME——这需要在核心微架构中增加一条独立的矩阵执行流水线、一个 2D 累加器寄存器文件（ZA tile），以及 streaming mode 的状态切换逻辑。这些额外的硬件大约占核心面积的 15-25%。

如果 LX2 基于 V2 衍生，集成 SME 后的单核面积约 3.5-5 mm²（7nm）。如果是从头自研，面积差异取决于设计团队对前端和后端的裁剪——可能会缩减整数 ALU 数量来给 SME 腾面积。

1.3 SME：CPU 上的矩阵加速

SME（Scalable Matrix Extension）是 ARMv9 架构中面向矩阵计算的指令集扩展。它引入了一种新的执行模式——streaming SVE mode，在这个模式下，处理器使用专门的 2D 累加器（ZA tile）执行外积（outer product）运算，一个周期内完成一个矩阵乘法的部分计算。

LX2 的每核 SME 流水线在 BF16 下每周期可以完成一次 512×512 bit 的外积累加。304 核 × 1.55 GHz → 240 TFLOPS BF16。对比 Neoverse V2 在同频率下没有 SME，BF16 算力为零（只能用 SVE 做 BF16 FMA，效率低 4-8 倍）。

SME 的编程模型需要特别注意。进入 streaming mode 使用 smstart 指令，退出使用 smstop。切换代价未公开，但从 ARM 架构规范推断大约 20-100 周期。这意味着在一次 kernel 调用中频繁切换 SVE 和 SME 是不经济的——最好一个 kernel 要么全程 SME（GEMM），要么全程 SVE（逐元素操作）。D2AR 论文中描述的 "asymmetric SME-GEMM" 调度策略印证了这一点：SME 和 SVE 的使用不是对等混合，而是以 SME 为主、SVE 在 SME pipeline 的间隙做辅助。

「更新」SME 软件栈性能实证（HACI 2026 幻灯片）： 另一张幻灯片披露了 LX2 上的 SME/SVE 优化实测数据——SME 矩阵化效率提升 40% 以上（统一映射 stencil multi-row-update、GEMM square-tile、Transformer tall-and-skinny matmul）；SVE+SME 交错调度 IPC 提升最高 1.59×（SVE 在单行更新、边界处理、online softmax 互补）；内存占用减少 3.9 GB + 缓存命中率提升 28%（blocking + packing + prefetching）。对应的三篇论文：HStencil（SC'25） 最高 4.1× over 自动向量化；KirbyMM（DATE'26 Best Paper） 1.11–1.75× over 厂商数学库；SMEAtten（Euro-Par'26） Attention 平均 13.62× over SOTA。这些数据证实了 SME 集成不是"聊胜于无"——配合深度软件优化，可以在特定负载上产生数倍加速比。Attention 13.62× 尤其值得关注，暗示纯 CPU 在 Transformer 推理上可能找到 GPU 之外的竞争力路径。

1.4 内存层级

LX2 的内存子系统有三层物理介质：

L1/L2 缓存。 每核 32 KB L1-I + 32 KB L1-D，每集群 28.5 MB L2 共享。L2 的 228 MB 总量（8 集群合计）处于 HPC CPU 的中等水平——Intel Sapphire Rapids 的 L2 是每核 2 MB（56 核 = 112 MB），AMD Genoa 的 L3 是共享 256-384 MB。LX2 的共享 L2 设计在集群内复用率高，但跨集群的 cache coherence 需要跨 chiplet 通信。

HBM。 64 GB，8 TB/s 总带宽 per socket（2 × 32 GB chiplet）。TNP 推测为 HBM2E 增强版。幻灯片确认 HBM 支持两种可编程模式：Cache 模式（开箱即用带宽优化）和 Flat 模式（深度用户手动调优）。6.3B 模型训练状态约 50 GB，64 GB 足以容纳但仍紧张。如果模型扩到 10-15B，SDMA 调度开销仍将成为瓶颈。

DDR5。 最高 256 GB，带宽约 200-400 GB/s。用作 HBM 的溢出层——通过 SDMA 引擎在 HBM 和 DDR5 之间按需调度数据。

「更新」DRAM 类型修正： 幻灯片和 TNP 确认，实际为 256 GB LPDDR5X per socket（而非普通 DDR5），采用 wafer-to-wafer 3D 堆叠——定制 DRAM die 与逻辑 wafer 堆叠，减少功耗和面积（幻灯片原文："Customized DRAM dies reduce power and area; wafer-to-wafer 3D stacking combines DRAM and logic wafers"）。TNP 推测来自长鑫存储（CXMT）2025 年底展示的 10.7 GHz LPDDR5X。

SDMA（Software-defined DMA）引擎。 位置在 I/O die，负责 HBM ↔ DDR5 之间的数据搬运。D2AR 论文描述了它的使用方式：根据算子类型（compute-bound 还是 memory-bound）和中间结果的生存期，动态决定哪些数据驻留 HBM、哪些 evict 到 DDR5。调度粒度为 page 级（4 KB）。这是一个硬件辅助的分层内存管理机制——不是操作系统做的透明 swap，而是应用通过驱动接口显式控制。

「更新」深入分析：SDMA 的分层内存调度——带宽鸿沟、命中策略与容量匹配。

带宽鸿沟：20-40× 的落差。 SDMA 面对的核心矛盾是 HBM（8 TB/s）和 LPDDR5X（200-400 GB/s）之间的带宽峡谷。每次 HBM miss 触发的 SDMA 搬运，需要从 8 TB/s 的快速通道切换到 200-400 GB/s 的慢速通道——带宽骤降 20-40 倍。 以 D2AR 的 6.3B 训练为例：如果 Adam 优化器状态（37.8 GB）被迫从 HBM evict 到 LPDDR5X，每个 training step 需要先通过 SDMA 搬回 HBM 才能计算。搬 37.8 GB 数据在 8 TB/s HBM 上只需 ~5 ms，在 400 GB/s LPDDR5X 上需要 ~95 ms——多了 90 ms 的纯等待时间。在一个 GPU 上每 step 约 200-500 ms 的训练循环中，90 ms 的 SDMA 搬运相当于 18-45% 的 step 时间被吞掉。

调度策略：compute-bound vs memory-bound 的决策树。 D2AR 论文描述了 SDMA 的调度逻辑：对每个算子，运行时判断它的 arithmetic intensity（FLOP/byte）。

• 如果 intensity 高（GEMM、attention、卷积）→ compute-bound → 算子需要的 tile 优先驻留 HBM，SDMA 提前预取下一层的 tile
• 如果 intensity 低（embedding lookup、layer norm、activation function）→ memory-bound → 算子本身的计算量不足以隐藏 SDMA 搬运延迟 → 这些算子的数据优先被 evict，腾 HBM 给 compute-bound 算子
• 中间结果的生存期分析：short-lived 的 activation（只用一次就丢弃）放在 HBM 但不做 SDMA 写回；long-lived 的 weight 和 optimizer state（每 step 都要更新和读取）优先驻留 HBM，只有 HBM 满时才 evict 到 LPDDR5X

命中与老化策略：page 级 LRU 的硬件实现。 SDMA 在 I/O die 上维护一个 page table（每页 4 KB），记录每个 page 的访问计数和最后访问时间。调度策略接近 LRU（Least Recently Used）但带有 workload hint：应用可以通过驱动接口标注 page 的"预期生存期"和"优先级"，SDMA 在 evict 决策时优先驱逐低优先级、短期生存的 page。这比 OS 透明 swap 的纯 LRU 更精准——因为 OS 不知道训练 step 的边界，而 SDMA 的 hint 机制让应用可以告诉硬件"这一页在下个 step 还会用"或"这一页已经不需要了"。

容量匹配：64 GB HBM vs 256 GB LPDDR5X = 1:4。 这个比例是否合理？

• 对于科学计算（MatRIS-MoE、CAPES）：组态数据以 MB 到几 GB 为单位，64 GB HBM 可以容纳多个独立成员的中间激活 → 1:4 足够，HBM 容量偏充裕
• 对于中等规模 AI 训练（D2AR, 6.3B）：训练状态约 50 GB，64 GB HBM 刚好容纳 → 1:4 匹配得当，但几乎没有裕量
• 对于大规模 AI 训练（>15B 模型）：训练状态 100+ GB，HBM 溢出是常态 → 1:4 偏小，SDMA 吞吐成为新瓶颈

LPDDR5X 的 256 GB 容量选择了"大而慢"的定位——足够存储 2-3 倍 HBM 容量的溢出数据，但从 LPDDR5X 到 HBM 的搬运延迟始终是硬伤。一个可能的改进方向（下一代 LX2 工艺跃迁到 5nm 时）：把 HBM 扩到 128-192 GB，同时把 LPDDR5X 提升到 512 GB——把 1:4 的比例改为 1:3 或 1:2，让常用数据的"溢出概率"降低一半以上。

SDMA 与 GPU Unified Memory 的对比。 GPU 的 Unified Memory（NVIDIA UVM / AMD UM）是 OS 层面的透明 page migration——应用不需要显式管理。LX2 的 SDMA 走的是相反路线：应用层显式控制，硬件执行。两种路线的优劣取决于负载的可预测性：SDMA 的优势在于 HPC 负载的访问模式高度可预测（知道下个 step 需要哪些数据），应用层 hint 比 OS 启发式推理准确得多。劣势是编程复杂度高——每个应用都需要针对 SDMA 做适配，这解释了为什么"400+ 兼容软件"不等于"400+ 高效软件"。

1.5 多精度算力的物理含义

对比 H100：FP64 34 TFLOPS（不含 Tensor Core）、BF16 989 TFLOPS。LX2 在 FP64 上碾压 H100（1.8 倍），在 BF16 上只有 H100 的 24%。

这个对比的物理含义：LX2 的 SVE 向量单元面积大、SME 矩阵单元面积小。这是科学计算优先的芯片面积分配——把更多硅片面积给 FP64 向量运算，把更少给矩阵乘法。跟 GPU 的面积分配完全相反（GPU 把大部分面积给 Tensor Core）。

如果未来 AI 负载继续增长、科学计算负载占比下降，这个面积分配就需要翻转——但翻转后 LX2 就变成了一颗"带 ARM CPU 的 GPU"，失去了纯 CPU 路线的编程简单性。

「更新」深入分析：SME 软件栈的成熟度信号。 HACI 2026 披露的三篇论文（HStencil SC'25、KirbyMM DATE'26 Best Paper、SMEAtten Euro-Par'26）传递了一个比性能数字更重要的信号：NSC 深圳团队已经具备从手写 SME intrinsic 到编译器自动化的全栈优化能力。 三篇论文覆盖了三个不同层次的优化——stencil（不规则计算）、GEMM（密集计算）、Attention（AI 推理）——而且都在顶会发表。这说明 LX2 的软件栈不是"芯片做完了才开始搞软件的被动配套"，而是芯片与软件同步迭代的 co-design。KirbyMM 取得 DATE'26 最佳论文，暗示学术界对 SME 编程模型的研究兴趣正在形成——这对国产芯片生态的长期健康比单次性能数字更重要。

但 KirbyMM 也揭示了一个问题：ARM 上游 ACL（Compute Library）的 GEMM kernel 在 LX2 上只有手写 SME kernel 的 57-90%。 这意味着 LX2 的软件生态目前仍然高度依赖 NSC 深圳团队的内部优化——上游 ARM 生态的通用优化对华为定制的 SME 单元适配不足。如果未来有其他团队想在 LX2 上跑 AI 负载，要么等 ARM 上游改进 ACL，要么自己手写 SME intrinsic——两个选项的门槛都不低。

二、从节点到系统

2.1 计算节点

每个计算节点搭载 2 颗 LX2。两颗 CPU 之间的一致性互联方式未公开，可能是基于 ARM CMN（Coherent Mesh Network）的 mesh 互联，也可能是华为的 UB（Universal Bus）技术——后文分析。

节点上行带宽 1.6 Tb/s。这意味着两颗 LX2 共享一个网络出口——即使 CPU 内部 HBM 带宽充裕，跨节点通信受限于这个 1.6 Tb/s 上行。

「更新」系统层级确认（HACI 2026 幻灯片 + TNP）：

Frame 内部用 PCIe 5.0 交换机互联（TNP 称为"便宜的互联方式"），Frame 之间走灵启网络。

「更新」深入分析：层级化系统架构的制造策略含义。 Node→Blade→Frame→Cabinet 的四层结构不是偶然的——它是一套精准的"制造复杂度分层"策略：

• Blade 内部（8 node，PCIe 5.0）： 最成熟的互联技术，商用 PCIe 交换机成本低、供应链安全
• Frame 内部（16 blade，专用交换机）： 需要定制硬件但规模可控（每 frame 仅 256 CPU），故障域隔离清晰
• Frame 之间（灵启 fat-tree）： 全定制网络，但只用 4 层——L1-3 铜缆降低光模块依赖，只有 L4 跨 frame 用光纤

这个策略跟 GPU 集群的"全 NVLink + 全 InfiniBand"思路形成对比：灵晟的设计哲学是"在成熟的层级用标准技术、在关键的层级用定制技术"，而不是全栈定制。这种"混合成熟度"策略降低了供应链风险——即使 SMIC 产能紧张或光模块禁运，铜缆+PCIe 的绝大部分互联仍可保持运转。

与 Frontier/El Capitan 对比：两台美国 E 级系统的 Cray Slingshot 网络是全定制以太网变体（200 Gb/s 端口，Dragonfly 拓扑），从节点到机柜全线定制。灵启的"铜缆 fat-tree + 仅 L4 光纤"在绝对性能上可能不如 Slingshot，但在供应链韧性上明显更优。

2.2 机柜与物理规模

51 GFLOPS/W 的能效意味着每瓦特电功率产出 51 GFLOPS 的持续 FP64 算力。El Capitan 的 58.9 GFLOPS/W 高出 15%——差距主要来自工艺（TSMC 5nm vs 国产 7nm 级别）和架构（MI300A APU 的 GPU 计算密度更高）。

液冷系统由中国中元设计，集中式 CDU 架构，二次管道总长 3214.7 米，循环水泵 315 kW，单台板换 8700 kW。14 路 20 KV 高压直流配电。

2.3 灵启互联：华为 UB 假说

灵启（LingQi）是灵晟的自研互连网络。双平面多轨胖树拓扑，每节点 1.6 Tb/s，100 万端口组网能力。

公开材料没有描述灵启的协议栈细节。但从已知信息推断，灵启跟华为的 UB（Universal Bus）高速互联技术有较高概率存在技术关联：

「更新」灵启网络完整拓扑（幻灯片 + TNP 确认）：

• 4 层 fat-tree（L1–L4），L1–L3 铜缆，仅 L4 光纤
• 184 个计算 frame + 32 个网络 frame 互联
• L1：每计算 frame 16 交换/计算 blade；L2：每计算 frame 8 交换 blade；L3：每网络 frame 16 交换 blade；L4：每网络 frame 6 交换 blade
• 全系统 22,000+ 节点，200,000 端口，对分带宽 ≥ 3.5 Pbps，单跳延迟 1.07 μs
• 可靠性： 信用制流控（credit-based flow control，无损通信）、双平面 + 多轨通信、链路/芯片/机柜三级冗余、硬件遥测（秒级采集 + 主动推送）
• 片上 NIC 800 Gbps（幻灯片确认），交换机 ASIC 为定制芯片（幻灯片芯片照片）
• TNP 认为 1.07 μs "听起来更像以太网而非 InfiniBand"，但配合 credit-based 流控和无损通信，灵启的设计目标是 HPC/AI 训练的确定性低延迟网络——不是通用以太网

「更新」深入分析：灵启的"以太网—InfiniBand"光谱定位。 灵启同时具备两种网络的特征：以太网侧的——单跳延迟与高端以太网交换机相当（Arista 7800 系列约 0.8-1.2 μs）；InfiniBand 侧的——credit-based 无损流控是 InfiniBand 的核心设计范式。最合理的推断是：灵启的物理层和数据链路层接近增强型以太网（类似 RoCEv2 但做了深度定制），但流控层借用了 InfiniBand 的 credit 机制。 这种"以太网骨架 + InfiniBand 灵魂"的混合方案，在技术上可以避开 InfiniBand 的专利壁垒（Mellanox/NVIDIA 持有大量 IB 专利），同时获得接近 IB 的确定性延迟特性。

幻灯片芯片照片中显示的交换机 ASIC 尺寸偏大——暗示灵启的 L2/L3 交换芯片可能集成了比标准商用交换芯片更复杂的 buffer 管理和 credit 记账逻辑。这进一步支持"华为参与了交换芯片设计"的推断——因为华为在交换机 ASIC（如 Solar 系列）上有深厚积累。

跟 Slingshot 的对比： Cray Slingshot（Frontier/El Capitan 网络）也是以太网变体（200 Gb/s HPE Cray Rosetta 交换芯片），但采用了 Dragonfly 拓扑而非 fat-tree。Dragonfly 在理想条件下可以比 fat-tree 减少一跳，但在拥塞下的表现比 fat-tree 更难预测。灵启选择 fat-tree 而非 Dragonfly，可能是因为 fat-tree 的信用流控和多路径路由在 200K 端口规模下更容易做到确定性和无损——尤其是面对 AI 训练的集合通信爆发模式（AllReduce 瞬时带宽需求极高）。这是一个"放弃绝对性能上限、换取可预测性"的保守选择。

线索一： 灵晟的 LX2 跟华为鲲鹏体系高度相关。发布会提到华为参与，灵晟的生态对接鲲鹏。华为内部有成熟的超节点互联技术——灵衢软件（内核层）+ 硬件互联（包括 UB 物理层）。灵晟的"灵启"和"灵衢"命名甚至跟华为灵衢体系一致。

线索二： 1.6 Tb/s 的每节点带宽跟华为超节点方案的节点级互联带宽量级匹配。华为在昇腾集群中使用的 HCCS（Huawei Cache Coherent System）互联也是类似带宽级别。

线索三： 灵晟从设计到部署的时间线（约 3-4 年）跟华为 UB 技术的成熟期重叠。如果灵启完全从零设计，这个时间不够。

假说： 灵启可能是华为 UB 物理层 + 深圳超算团队自研的上层协议（MPI 适配、集合通信优化）的混合方案。物理层和链路层复用华为技术，网络层和传输层针对超算场景定制。

这个假说对分析的含义： 如果成立，灵启不是"一个团队从零做出的网络"，而是"华为商用互联技术的超算级扩展"。这意味着灵启的可靠性有华为大规模出货的硬件验证背书，但协议层定制部分的成熟度需要看实际运行数据。

「更新」重新审视：多元技术来源假说。 2026 年上半年，国内高速互联领域出现了多个潜在的技术来源：

1. 华为 UB / 灵衢体系（最可能的主力）：命名一致性（灵启/灵衢）、鲲鹏生态深度绑定、华为在交换机 ASIC 上数十年的积累。华为 Solar 系列交换芯片的 buffer 管理和 flow control 经验可以直接复用。LX2 的片上 NIC（800 Gbps）也可能是华为网络 IP 的整合输出。

2. 中科曙光 scaleFabric（2026 年 3 月发布）：国内首款全栈自研 IB 网络，400G 网卡 + 交换芯片，VCT 转发 260ns 延迟，64T 交换容量。但 scaleFabric 的公开时间是 2026 年 3 月——灵启的设计周期应该早于这个时间点 2-3 年。不过，scaleFabric 的底层 SerDes 和交换架构可能在公开前就已迭代了多代，灵启有可能使用了其早期版本的物理层 IP。

3. 众星微 PCIe 交换技术（可能性较低）：众星微专注于企业级 PCIe 交换芯片和 IO 扩展，不是 IB 网络芯片。但灵启在 Frame 内部使用 PCIe 5.0 互联 blade——如果 PCIe 交换部分借用了众星微的技术积累，是合理的。但灵启的 fat-tree 主干网（L2-L4）与 PCIe 无关，众星微不是主干网的候选方案。

4. 混合来源假说（最新推断）：灵启最可能是一个"多层技术栈"的组合——物理层和 link 层基于华为 UB + 华为交换芯片 IP；流控层借鉴 InfiniBand credit 机制（可能参考了中科曙光在 IB 协议栈上的积累）；应用层（MPI 适配、集合通信、software-defined streams）由深圳超算团队自研。 这是一种典型的"系统集成式创新"——每一层都用了国内最成熟的技术来源，整合成一个完整的超算互联方案。

「更新」刷新组网架构设计——为什么是 4 层 fat-tree + 仅 L4 光纤？

Fat-tree 的选型逻辑。 在 200K 端口规模下，超算互联有三种标准拓扑可选：

灵启选择 fat-tree 而非 Dragonfly，最可能的两个原因：

原因一：光模块供应链约束。 中国在高端光模块（800G QSFP-DD）上仍受出口管制影响。Dragonfly 拓扑需要大量全局光链路（每个 group 都要跟所有其他 group 连接），光模块需求是 fat-tree 的 2-3 倍。灵启的 L1-L3 全铜缆策略——配合每 frame 16 blade 的内部交换机——最大化了铜缆的使用范围，把光模块需求压缩到只有 L4（32 个网络 frame × 6 交换 blade × 上联端口）。整个 200K 端口的网络，光模块用量可能只有 Dragonfly 方案的 30-40%。

原因二：AI 训练的集合通信模式。 大模型训练的 AllReduce 和 AllGather 产生周期性的全局同步——每个 training step 结束后，所有 GPU（在这里是 CPU）需要一瞬间的高带宽全局通信。Fat-tree 的对称拓扑和多路径 ECMP（等价多路径）在这个模式下比 Dragonfly 的自适应路由更加确定。"宁可多一跳、不要在拥塞下随机波动"——这对于需要精确控制 training step 时间的 HPC 团队是合理的选择。

L1-L3 铜缆的物理约束。 铜缆 DAC（直连铜缆）在 400 Gb/s 下的有效传输距离约 3-5 米——刚好够 frame 内部和相邻 frame 之间的互联。L1 是 blade 内的 PCIe（~0.5m），L2 是 frame 内 blade 到交换机（~2-3m），L3 是相邻 frame 到网络 frame 交换机（~3-5m）——全在铜缆距离内。只有 L4 需要跨 row 甚至跨机房的光纤——光模块用量被精确控制在了"刚需"层。

与 Slingshot Dragonfly 的对比。 Slingshot 选择 Dragonfly 有前提条件：HPE/Cray 拥有自研的 Rosetta 交换芯片（200 Gb/s）和成熟的光模块供应链。这两个前提在灵启的设计约束下都不成立——交换芯片来自华为/国产设计链条，光模块受到出口管制。所以灵启的拓扑选择不是"Dragonfly vs Fat-tree 的性能对比"决定的，而是"在给定的供应链约束下，哪种拓扑能做到 200K 端口不掉链子"。

这是一种高度务实的架构决策——不是技术最优解，但在当前约束下是最可靠的解。

2.4 存储

67 个存储柜、428 存储节点、650 PB 总容量、10 TB/s 聚合带宽。每个存储节点约 1.5 PB 容量和 23 GB/s 带宽——典型的 Lustre OSS（Object Storage Server）配置。是否部署 burst buffer（NVMe 缓存层）未公开。

「更新」配套异构系统（HACI 2026 总览幻灯片）： 灵晟所在的深超二期并非纯 CPU 集群，而是一个综合性算力设施：

软件生态兼容 400+ 主流超算软件，工具链包含编译器、调试器、性能调优工具。

三、软件：从代码到 SME 指令

3.1 编译器

LX2 的编译器选型未公开。ARM HPC 生态的选项是 LLVM/Clang 或 GCC，两者都支持 SVE 自动向量化。SME 的编译器支持较新——LLVM 主线对 SME intrinsic 和 streaming mode 的完整支持在 2024-2025 年逐步合入。

如果 LX2 的工具链基于较早的 LLVM fork，SME 自动向量化覆盖率会低于最新主线。实际使用中，高性能 kernel 几乎必然需要手写 SME intrinsic——编译器自动生成在复杂 kernel 上可能比手写慢 2-5 倍。

一段典型的 SME 外积矩阵乘法 kernel：

// SME outer product: C += A × B (BF16 → FP32 accumulate)
__arm_new("za")
void sme_gemm(bfloat16_t *A, bfloat16_t *B, float *C, int M, int N, int K) {
    svbool_t pg = svptrue_b16();
    for (int k = 0; k < K; k++) {
        svbfloat16_t va = svld1_hor_bf16(pg, &A[k * M]);
        svbfloat16_t vb = svld1_ver_bf16(pg, &B[k * N]);
        svmopa_za16_bf16_m(pg, ZA0, va, vb);  // 外积累加到 ZA
    }
    svst1_hor_bf16(pg, C, svread_hor_za16_bf16(ZA0));  // 写回
}

svmopa_za16_bf16_m 是核心：一个周期内完成 512×512 bit 的外积累加。ZA 是 SME 专用的 2D 寄存器阵列，跟 SVE 的 1D 向量寄存器 z0-z31 分开管理。进入 streaming mode 后 SVE 的部分 predicate 功能受限。

「更新」深入分析：KirbyMM 与生态成熟度鸿沟。 KirbyMM（DATE'26 Best Paper）揭示了一个比性能数字更深层的问题：手写 SME intrinsic 的 GEMM kernel 比 ARM Compute Library（ACL）上游实现快 1.11-1.75 倍。 这意味着 ARM 官方的数学库在 LX2 的定制 SME 单元上存在显著的性能损失。拆开这个差距的来源：

1. tile 形状适配：ACL 上游假定标准的 SME tile 形状（SVL bits × SVL bits），但 LX2 的华为定制 SME 可能使用了不同的 ZA tile 分块策略——手写 kernel 可以针对 LX2 的具体 tile 尺寸（512 bit SVE 宽度所对应的 matrix tile）做精确匹配，ACL 没有这个优化。

2. streaming mode 切换策略：ACL 保守地在每个 kernel 调用的边界进入/退出 streaming mode（smstart/smstop），切换代价约 20-100 周期。KirbyMM 的手写 kernel 可能把多个连续的 GEMM 操作合并在一次 streaming mode 中，减少了切换次数。

3. prefetch 距离调优：LX2 的 L2 共享架构（38 核争 28.5 MB）的 prefetch 最优距离跟 ARM 参考设计（每核 private L2）完全不同。ACL 的 prefetch 启发式针对的是 ARM 参考核心，在 LX2 上容易出现过早 prefetch（污染 L2）或过晚 prefetch（cache miss）。

这个差距对灵晟的软件生态意味着什么？跟 NVIDIA CUDA 的对比是尖锐的。 CUDA 生态中，NVIDIA 自家 cuBLAS 是性能最优的实现——用户不需要手写 PTX 或 SASS 就能拿到接近峰值的性能。ARM 生态中，ACL 在 LX2 上不是最优实现——这意味着每个想在灵晟上跑 AI 训练的团队，都需要有人能读懂 SME intrinsic、手动调 tile、改 prefetch 距离。这大大缩小了灵晟的"可用开发者池"——从"会写 PyTorch 就行"变成了"需要懂微架构的 HPC 工程师"。

这不是 LX2 的错——这是所有非 GPU 架构在 AI 生态中面临的共同困境。但 KirbyMM 的存在说明 NSC 深圳团队已经意识到了这个问题，并且正在通过发表论文来建立"手写 SME kernel 的最佳实践"知识体系——相当于在 ARM 生态中自建一个精简版的"cuBLAS for LX2"。

3.2 AI 框架调用链

从 PyTorch 到 LX2 硬件的路径：

torch.nn.Linear → PyTorch dispatcher → oneDNN ARM 后端
→ ARM Compute Library (ACL) GEMM kernel → SME intrinsic/汇编
→ ZA 累加器 → L2 → HBM

ARM Compute Library（ACL）是 ARM 官方开源计算库，为 ARM CPU 提供 BLAS、CNN 等 kernel。ACL 上游对 SME 的优化 kernel 在 2024-2025 年才陆续加入。LX2 是否直接使用 upstream ACL 还是 fork 定制未公开——但 D2AR 论文团队自行实现了 SME-GEMM 优化（"reuse-directed asymmetric"调度），暗示 upstream ACL 在 LX2 上的性能不够理想。

PyTorch 在 ARM CPU 上可以运行训练，但分布式训练（DDP/FSDP）在 4 万颗 CPU 上的稳定性是开放问题——PyTorch 的 Gloo 后端对超大集群有已知扩展性瓶颈，MPI 后端更可行但需要定制。

3.3 MPI 与 software-defined streams

灵晟的 MPI 实现大概率是基于 MPICH 或 OpenMPI 的定制版，底层通过 libfabric 或 UCX 适配灵启网络。

在 1380 万 ranks 的规模下，集合通信算法的选择直接影响效率：

• AllReduce： recursive doubling 需要 log₂(13.8M) ≈ 24 步，每步全局同步。ring algorithm 数据旋转传递，对带宽更友好但延迟更高。在灵晟的胖树拓扑下，ring 的物理路径可以优化为最小跳数。

「更新」基于确认拓扑的 MPI 通信刷新。 灵启的 4 层 fat-tree（L1-L4）给了我们精确计算 AllReduce 端到端延迟的信息：

• AllReduce（recursive doubling）： 24 步全局同步。每步的数据走 fat-tree 最少 3 跳（L1→L2→L3→目的 L1），最差 7 跳（跨不同计算 frame 的 L1→…→L4→…→L1）。单跳 1.07 μs，3-7 跳 = 3.2-7.5 μs 纯网络延迟。加上每步的 DMA 和 MPI 层开销（约 5-10 μs），每步 AllReduce 延迟约 10-20 μs。 24 步 × 15 μs（中位数）= 360 μs 的纯 AllReduce 延迟——在 training step 通常 200-500 ms 的尺度下，占比不到 0.2%。延迟不是瓶颈。

• AllReduce 带宽： 瓶颈在带宽而非延迟。ring AllReduce 的每 rank 数据量 = 2 × (N-1)/N × S（S = 消息大小）。以 D2AR 的 6.3B 模型为例，单步梯度约 12.6 GB（BF16 参数），每 rank 约 25.2 GB 数据量。在 1.6 Tb/s 节点带宽下（200 GB/s），理论传输时间约 126 ms——考虑协议开销和网络争用，实际约 150-200 ms。这就是 D2AR 通信占 18-25% 的主要来源——不是 AllReduce 步数多，而是数据量大。

• AlltoAll： MatRIS-MoE 的 AlltoAll 在 4 万 CPU 上产生 O(1.7B) 条消息。灵启的 credit-based 流控在此模式下优势明显——无损网络保证没有丢包重传，每消息延迟只包含纯传输时间。但消息量本身是物理上限——即使每条消息只有 4 KB，总量也达 6.8 TB。在 3.5 Pbps 对分带宽下，理论传输约 15 ms，但消息头部开销和路由表查找会显著拉长时间。

• 通信计算重叠率的拓扑含义： 论文报告的重叠率 >80% 在 fat-tree 拓扑下比 Dragonfly 更容易达到——因为 fat-tree 的多路径 ECMP 让通信流在物理上分散到不同链路，减少了计算 kernel 的内存带宽与通信带宽的争抢。Dragonfly 的自适应路由在某些路径上可能跟计算 kernel 的 HBM 访问争抢网络接口带宽。

• AlltoAll： MoE 路由的核心操作。O(P²) 个消息在 4 万 ranks 下是主要通信瓶颈。MatRIS-MoE 论文中的 "atom-type-aware communication compression" 就是对 AlltoAll 数据量的压缩。

Software-defined streams。 论文中多次提到但未定义。从上下文推断：这是把 MPI 通信操作建模为有向无环图（DAG）的节点，运行时按拓扑序并行执行无依赖的通信，CPU 核心同步执行计算 kernel。效果是通信与计算重叠率超过 80%——原本串行执行的时间中，80% 的通信被异步隐藏。

3.4 OS 与大规模运维

麒麟 Linux 内核。在 304 核/CPU × 4 万颗 CPU 的规模下：

OS noise。 内核线程（kworker、kswapd、时钟中断）的随机调度会产生微秒级延迟尖峰。在全局同步的 MPI 操作中，最慢进程决定全局性能。解决方法是中断亲和性绑定（把所有中断路由到专用核心）和内核线程绑核。

作业启动。 在 1380 万核上启动 MPI 作业，标准 SSH-based 启动需要数分钟。HPC 系统用 PMI（Process Management Interface）分层启动树把延迟控制在秒级。

Checkpoint。 全系统作业的 checkpoint 数据量可能达到 PB 级。以 10 TB/s 存储带宽写 1 PB 需要约 100 秒理论值，实际因并发争抢和元数据操作更长。Checkpoint 频率需要在数据安全和工作效率之间取平衡。

「更新」深入分析：400+ 应用兼容的生态含义。 HACI 2026 幻灯片披露灵晟软件生态兼容"400+ 主流超算软件"，这个数字本身就说明了很多问题。作为对比：富岳（Fugaku）在部署初期兼容约 200 个应用，5 年后增长到 500+。灵晟在初次公开时就能达到 400+，意味着它的生态适配不是在 ISC 2026 登顶后才开始的——软件移植工作很可能在产品原型阶段就已经启动，持续了至少 2-3 年。

400+ 这个数字更深的含义是："ARM 兼容"不等于"生态成熟"。 ARM ISA 兼容性只是入场券——LX2 的 8 NUMA 域、SME streaming mode、SDMA 内存管理、灵启网络的 MPI 适配，每一个都需要应用层做针对性优化。400+ 个应用能运行不等于 400+ 个应用能高效运行。CAPES 论文中 14.6 小时跑完十年回算——这个级别的效率需要针对 LX2 的 NUMA 亲和性、SME GEMM、SDMA 预取做深度调优，不是"recompile and run"能达到的。

「更新」兼容深度分层估算。 按优化深度，这 400+ 个应用可以粗略分为三层：

这个分层的现实含义：L1 层的应用（占多数）在灵晟上能跑但不一定跑得快——跨 NUMA 域的内存访问延迟和灵启的 MPI 通信特性会拉低效率。 L2 层需要 NSC 深圳的应用工程师介入适配——这就是"先导验证系统"（100 台鲲鹏）存在的意义：在实际运行前发现问题。L3 层是少数"旗舰应用"——投入最深的优化资源，换取最好的性能展示，形成论文（SC'25、DATE'26、Euro-Par'26）。

对灵晟的运营而言，关键指标不是 400+ 的总数，而是L2+L3 的应用比例能否从现在的 ~40% 提升到 60-70%。 每提升一个百分点，意味着灵晟从"一台能跑很多软件的机器"向"一台大多数软件在上面跑得很好的机器"进化了一步。

这揭示了中国超算生态的一个深层挑战：硬件迭代越快，软件生态的"优化深度"越跟不上。

这揭示了中国超算生态的一个深层挑战：硬件迭代越快，软件生态的"优化深度"越跟不上。 灵晟之后如果继续迭代 LX2 的后继（5nm 版本），SME 单元可能会更复杂、NUMA 域可能会更多——但应用层的适配积累需要时间。中国超算从 2017 年神威太湖之光后就暂停向 TOP500 提交新系统，这 9 年的沉默期换来了一台登顶的灵晟，但也让软件生态的"代际积累"出现了断裂。400+ 是起点，不是终点。

四、实证：从三个案例推演纯 CPU 集群的能力上限

三个案例不是孤立的论文验证，而是三个探针——分别测试纯 CPU 架构在不同负载形态下的效率边界。把它们放在一起读，可以推出灵晟的能力天花板在哪里。

4.1 MatRIS-MoE：为什么 CPU 在二阶导数训练上赢了 GPU

MatRIS-MoE 是中科院计算所设计的通用机器学习原子间势（uMLIP）模型，用神经网络替代 DFT（密度泛函理论）计算原子间相互作用力。11.5B 参数 MoE 架构，4.73 亿组态，3.6 万亿交互边。

理解 CPU 为什么在这个负载上赢 GPU，需要拆开 uMLIP 训练的三个特殊性：

特殊性一：二阶导数。 LLM 训练只需要一阶梯度（∂L/∂θ），uMLIP 训练需要力的匹配——力是能量对坐标的一阶导数的负值（F = -∂E/∂X）。自动微分框架必须走两次反向传播：第一次从能量到力，第二次从力到参数梯度。第二次反向传播在计算图上是"梯度的梯度"，中间激活的数量和内存占用是一阶训练的两倍以上。

GPU 的 Tensor Core 针对一阶密集矩阵乘法做了深度优化——tile 形状固定（16×16 或 32×32）、数据预取模式可预测、流水线排布高度规整。二阶自动微分的计算图完全不规整：每个原子的力贡献依赖其邻居的坐标和能量，邻居数量和拓扑结构随分子系统变化。这种不规则性让 Tensor Core 的 tile 预取失效，利用率急剧下降。

CPU 的 SVE 向量单元没有 tile 形状约束。二阶梯度的中间激活直接在 HBM 中分配，通过 SDMA 按需调入 L2。编程模型跟一阶训练完全一样——只是多走一遍反向传播。这种灵活性是 CPU 架构的固有优势。

特殊性二：FP32 是硬约束。 量子精度的模拟如果降到 BF16，力预测的误差会累积到分子动力学轨迹发散。所以 uMLIP 训练必须用 FP32。

GPU 的 FP32 算力分两档："普通" FP32（CUDA Core，H100 约 67 TFLOPS）和 Tensor Core FP32（约 330 TFLOPS，但 tile 约束严格）。二阶导数的不规则图只能用"普通" FP32 路径，峰值 67 TFLOPS。

LX2 的 SVE 在 FP32 下原生满速：每核每周期 2 × 512 bit FMA = 16 次 FP32 运算。304 核 × 1.55 GHz = 120.6 TFLOPS，是 H100 "普通" FP32 的 1.8 倍。这个算力差距直接转化为利用率差距。

特殊性三：边就是 token，3.6 万亿条。 GNN（图神经网络）的消息传递沿边进行，边是计算的基本单元。3.6 万亿条边的访存模式完全不规整——邻接表是变长的、距离和角度三元组无法对齐打包。这跟 LLM 的 token（固定维度、连续内存、规整 batch）形成鲜明对比。GPU 的 Tensor Core 需要规整 batch 才能发挥峰值，不规整访存的效率损失严重。CPU 的乱序执行和硬件预取对不规整访存的容忍度更高。

实测数据。 灵晟 12.4M ARMv9 核心，FP32 峰值 1.2 EFLOPS，利用率 35.5%。CNIS GPU 集群（45K GPU 核心），FP32 峰值 1.0 EFLOPS，利用率 25.4%。差 10.1 个百分点。归一化吞吐量 3201 倍于此前 SOTA（UMA，256 H200 训练 21 天）。

能力上限推演。 CPU 的优势在这个案例中是结构性的——只要 uMLIP 训练需要二阶导数 + FP32 + 不规则数据，CPU 架构就跟这个负载天然适配。但这个优势有一个前提：HBM 带宽够用。MatRIS-MoE 的单组态数据量不大（几百原子的局部图），64 GB HBM 足以容纳多个组态的中间激活。如果未来 uMLIP 模型继续扩大——比如从 11.5B 到 50B+——单组态的中间激活可能超出 HBM 容量，SDMA 调度开始成为瓶颈，CPU 的利用率优势会被内存延迟侵蚀。

另一个边界：35.5% 的 FP32 利用率意味着 64.5% 的时间花在了非计算上——通信、内存访问、调度。在 12.4M 核心规模下，通信开销随核心数呈 sub-linear 增长（AllReduce 的 log 步数、AlltoAll 的 O(P²) 消息数）。如果把灵晟规模再扩大 2 倍到 25M 核心，通信占比可能从当前的 ~10% 升到 15-20%，FP32 利用率会降到 30% 以下。灵晟的规模接近纯 CPU uMLIP 训练的甜蜜点——再大，通信开销开始侵蚀效率。

4.2 D2AR：64 GB HBM 下的 AI 训练能力边界

D2AR 是清华/中山大学团队的对地观测生成压缩模型，利用历史遥感档案训练一个生成式压缩器，实现 100× 到 10,000× 的数据压缩。6.3B 参数 Dense Transformer，BF16 精度，全系统 40,960 颗 LX2 训练。

持续性能 1.54 EFLOPS，峰值 2.16 EFLOPS，MFU 15.7%。

D2AR 论文的 Table 1 提供了一个绝佳的横向对比锚点。把它跟 GPU 大规模训练的数据并排看：

灵晟的 1,543 PFLOPS 是 CPU 平台的历史最高纪录。 排第二的富岳是 2.22 PFLOPS。差距 695 倍——但富岳只有 7M 参数、FP64 精度、无矩阵加速。

15.7% MFU 拆解（基于 64 GB HBM）。 D2AR 的 6.3B 训练状态（参数 12.6 GB + Adam 37.8 GB + 激活 ~5 GB ≈ 55 GB）可以完整驻留 HBM——SDMA 调度开销归零。 端到端时间的四块分解：

1. SME 计算（GEMM + attention）：约 55-65%。纯 SME GEMM 受 HBM 带宽约束——8 TB/s 在 240 TFLOPS SME 峰值下，每 byte 数据支撑 ~30 GFLOPS 计算。如果算子的 arithmetic intensity 低于 30 FLOP/byte，SME 就是 memory-bound。attention 层计算密度高，但 embedding 和 norm 层拉低整体。

2. 通信（AllReduce + AlltoAll）：约 18-25%。论文报告重叠率 >80%，剩余串行通信直接拉低 MFU。在 40,960 CPU 上，AllReduce 约 20-25 步（灵启 4 层 fat-tree 的实际跳数），AlltoAll 消息数 O(1.7B)。

3. 数据预处理：约 12-18%。遥感图像解压、裁剪、多光谱对齐——不受 HBM 容量影响。

4. 其他开销：约 5-10%。OS noise、MPI rank 间同步抖动、checkpoint 中断。

归一化后，纯 SME 计算的利用率约 25-30%，端到端 MFU 约 20-22%。非计算时间约 45%——HBM 带宽主要瓶颈。

能力上限推演（基于 64 GB HBM）：

关键判断：64 GB HBM 使纯 CPU 架构在 8-12B 参数规模无痛训练、15-20B 勉强可行、70B+ 仍不可行。 这给了纯 CPU 路线在中等规模 AI 训练（科学模型、垂直领域模型，非通用 LLM）上一代迭代的生存空间。但面对 70B+ LLM 的训练市场，架构劣势没有改变——GPU 的 HBM 容量和算力密度双重优势依旧碾压。

与 ORBIT-2 的横向对位。 ORBIT-2 在 65,536 GPU（MI250X）上跑 10B 气候模型，FP32 精度，MFU ~16%，跟灵晟的 D2AR（MFU ~20%）几乎同级。两类系统在"非 LLM、科学精度、混合负载"这个交叉带上的效率差距不大。这意味着灵晟的竞争位不是通用 AI 训练市场，而是科学 AI 训练市场——在这个 niche 里，CPU 的统一内存、原生 FP64、多精度切换灵活性，构成了 GPU 无法替代的组合优势。

4.3 CAPES：纯 CPU 在多精度混合工作流上的结构性优势

CAPES 是清华/深圳超算的东亚汛期降水预报系统。问题：提前 3-6 个月预测夏季降水，受"春季可预测性屏障"影响，传统数值模式的预报技巧在这个时间尺度上很低。

方法：1,774 成员混合 ensemble——174 个数值模式成员（不同初始条件、不同物理参数化方案）+ 1,600 个 AI 预报成员（初始和物理扰动）。数值模式求解大气/海洋/陆面耦合偏微分方程（FP64），AI 成员做数据驱动的季节预报（BF16）。15 km 分辨率，10 年回算（2016-2025）。

结果：全系统 14.6 小时完成十年回算，预测得分 75.9（ACC），超过 ECMWF 的 71.8。

为什么纯 CPU 在这个场景有结构性优势？

这个工作流的本质特征是：在同一次预报中，FP64 的数值模式和 BF16 的 AI 模型交替执行，且数据流是闭环的。

数值模式跑一步（FP64 PDE 求解）→ 输出中间大气场 → AI 模型读入大气场做一步推理（BF16 矩阵乘法）→ AI 输出修正后的场 → 喂入下一步数值模式 → 循环。

在 GPU 异构系统上，每个循环的数据路径：

CPU 内存（数值模式状态）
  → PCIe/NVLink 搬运 → GPU 显存
    → GPU 计算 AI 步 → GPU 显存（AI 输出）
  → PCIe/NVLink 搬回 → CPU 内存
    → CPU 数值模式下一步

每次搬运的数据量：一个 15 km 分辨率的全球大气场（温度、湿度、风场、气压等变量），约 1-5 GB。1,774 个成员 × 多个时间步 × 多个循环——搬运的总数据量以 PB 计。PCIe Gen5 x16 的双向带宽约 64 GB/s，每次搬运 1 GB 数据约 15 ms。看起来不多，但在千万次循环中累积成可观的开销。

MI300A APU（El Capitan 的处理器）用统一封装内存缓解了这个问题——CPU 和 GPU 共享 128 GB HBM3，不需要 PCIe 搬运。但编程模型仍然是异构的：数值模式在 CPU 核上跑 x86 代码，AI 模型在 GPU 上跑 HIP kernel，两者之间的数据交接需要显式的设备同步。

灵晟的路径要短得多：

LX2 HBM（数值模式状态，FP64）
  → 同一组核心切换到 SME 指令 → AI 计算（BF16）
  → 同一组核心切回 SVE → 数值模式下一步

数据不离开 HBM，精度切换只需要改指令流。没有跨设备 DMA，没有设备同步，没有编程模型的切换。这是纯 CPU 架构在"多精度混合工作流"场景下的结构性优势。

14.6 小时十年回算的含义。 一个气象业务中心每天可以跑一次完整的 1,774 成员 ensemble 回算——这达到了 operational forecasting（业务化预报）的时间窗口要求。论文不再只是学术验证，是可以交付给气象局使用的生产系统。

能力上限推演。 CAPES 的工作流特征（多精度混合 + 大量独立成员）恰好避开了灵晟的两个弱点：

• 避开了 HBM 容量瓶颈：单个 ensemble 成员的模型不大（AI 成员可能是 1-3B 参数），64 GB HBM 够用。1,774 个成员分布在 40,960 颗 CPU 上，每 CPU 跑不到 0.05 个成员，内存压力极低。

• 避开了大规模通信瓶颈：ensemble 成员之间几乎不需要通信——每个成员独立跑完整的预报，最后做一次 AllReduce 统计结果。通信量极小。

所以 CAPES 几乎不触碰灵晟的能力天花板。如果要扩大——比如 ensemble 增到 10,000 成员、分辨率从 15 km 提到 5 km——灵晟还有很大的余量。1 km 分辨率的台风模拟也在论文中验证了可行性。

这个案例说明：纯 CPU 架构在"多精度混合 + embarrassingly parallel"的工作流上，不是差在 GPU 面前，而是结构性更优。

4.4 HPCG：1% 的比值暴露了什么

TOP500 榜单中灵晟的 HPCG 成绩是 22 PFLOPS，HPL 是 2,198 PFLOPS。HPCG/HPL = 1.0%。

HPCG（High Performance Conjugate Gradient）测量稀疏迭代求解，对内存带宽、通信延迟、不规则访存高度敏感。灵晟的 1.0% 是 TOP500 前十中最低的：

「更新 6/29」El Capitan HPCG 数据刷新。 原文 El Capitan HPCG ~38 PFLOPS 来自 2025/11 TOP500 榜单，ISC 2026 官方 HPCG 榜更新为 17.406 PFLOPS。新数据下，TOP500 前四名的 HPCG/HPL 比值都在 1.0-2.9% 范围，Frontier 与 El Capitan 都是 ~1.0%。这说明 HPCG/HPL 比值低不是纯 CPU 架构的特有问题，GPU 异构架构在稀疏负载上同样表现不佳。根源是 HPCG 的稀疏矩阵向量乘法（SpMV）访存模式不规整，对任何架构的预取和 cache 都是噩梦。灵晟 22.004 PFLOPS 的 HPCG 绝对值全球第一，说明纯 CPU 架构在稀疏迭代求解的绝对性能上可与 GPU 异构匹敌；HPCG/HPL 比值低反映的是设计哲学对密集计算的极端偏向，不是稀疏能力的结构性缺失。

这个数据说明： 灵晟的适用域是密集计算（HPL、GEMM、Transformer attention），不是稀疏计算（HPCG、SpMV、图分析）。如果把 HPC 负载按"计算密度"排序——

计算密度高 ←─────────────────────────→ 计算密度低
Dense GEMM · CFD · Transformer · 分子动力学 · 稀疏迭代 · 图分析
   ████████████ ██████████ ██████████ ░░░░░░░░░░ ░░░░░░░░░░
              灵晟高效区                  灵晟低效区

——灵晟的甜蜜区覆盖了大多数科学计算场景（CFD、气象、材料模拟），但不覆盖大数据分析和图计算。

4.5 三个案例交叉对比：能力边界全景

把三个案例的关键数据放在一起，灵晟的能力边界就清晰了：

从这张表推出的结论：

1. 灵晟在 FP32 科学计算训练上的效率结构性优于 GPU（MatRIS-MoE），但这种优势只在二阶导数 + FP32 + 不规则数据的特定条件下成立。标准 BF16 LLM 训练（一阶导数 + 低精度 + 规整 batch）在 GPU 上效率更高。

2. 64 GB HBM 把天花板从 6-7B 推到了 8-12B（刷新）。 确认的 64 GB HBM 容量使 6.3B 模型的训练状态可以完整驻留，SDMA 零开销。模型天板约 8-12B（BF16 + Adam）。更大的模型（15-20B）需要通过 SDMA 辅助训练——MFU 会下降但仍可行。不过 70B+ LLM 训练仍然不可行——需要 200+ GB HBM per socket。

3. 灵晟在"多精度混合 + embarrassingly parallel"工作流上有不可替代的优势。 CAPES 的 1,774 成员 ensemble + 数值/AI 交替在纯 CPU 上天然高效。这个优势不是性能数字上的差距，是编程模型上的简化——没有跨设备同步，没有异构代码管理。

4. HPCG/HPL = 1% 意味着灵晟不应被用于稀疏负载。 它是一台密集计算专用机器。

「更新 6/29」HPCG 双冠：灵晟不只赢 LINPACK。 ISC 2026 正式 HPCG 榜单确认灵晟 22.004 PFLOPS 排名第一，超越 El Capitan（17.406 PFLOPS）。HPCG/HPL = 1.0% 并不是因为 HPCG 弱；灵晟的 HPCG 绝对值是全球最高，根因是 HPL 太强（2,198 PFLOPS）把分母拉大了。Chips and Cheese 的 George Cozma 评价："unlike prior Chinese Supercomputers, this system is not just a 'LINPACK-special'"，灵晟在密集和稀疏两端都做到了极致，但因为设计哲学偏向密集计算，HPL 的领先幅度（21%）远超 HPCG 的领先幅度（约 26%）。HPCG 的 22 PFLOPS 意味着灵晟在 HPCG 所代表的稀疏迭代求解负载上也是全球最强，只是领先幅度不如 LINPACK 显著。

Top 500 前十名零变动。 据 Chips and Cheese 分析，2026 年 6 月 Top 500 前十名与 2025 年 11 月完全一致，该文称此为 Top 500 历史首次。效率并没有停滞，只是旧系统退役推高了整体中位数；头部竞争陷入停滞，暗示当前 GPU 异构架构的效率提升正在逼近工艺节点能提供的上限。灵晟 52.07 GFLOPS/W 距离榜首（73.28）仍有差距，但纯 CPU 路线的能效进步速度（富岳 16 → 灵晟 52，3.3×/6 年）显著快于头部 GPU 异构系统在此期间的进步。如果这个趋势持续，两代之内纯 CPU 和 GPU 异构的能效差距可能大幅收窄。

4.6 DeepSeek 推理实测（新增）

「更新」HACI 2026 系统总览幻灯片披露了一个关键的推理实测数据：单颗 LX2 的 DeepSeek Decode 吞吐量达到 578 TPS。 正在推进 Qwen 等主流及国产大模型的规模化训练和推理部署。

作为参考：一台 NVIDIA H100 在类似 Decode 负载下约 2,000-4,000 TPS（受 batch size 和模型大小影响），功耗约 700W——与 LX2 的 690W 几乎一样。GPU 仍有 3-7 倍优势，但考虑到这是同构 CPU 架构 + 第一代 SME + 无 GPU 软件栈的前提，578 TPS 并不低。

对于 Agentic AI 推理——低延迟、小 batch、长序列、稀疏计算——CPU 的统一内存 + SME + SVE 组合在 TCO（总拥有成本）上有可能找到 GPU 之外的竞争力路径。这个方向值得持续跟踪。

五、HPC 纯 CPU 架构路线是否还有希望

5.1 从数据看路线的当前定位

纯 CPU 路线的当前状态：灵晟是史上最强的纯 CPU 超算，在特定领域（科学计算训练、多精度混合、密集计算）的效率结构性优于 GPU 异构系统。但在主流 AI 训练（LLM）和推理场景上，跟 GPU 的差距在扩大而非缩小。

把灵晟跟两个参照系对比：

vs 富岳（同路线的上一代）：

六年间纯 CPU 路线：FP64 提升 18 倍，BF16 从零到 240 TFLOPS，能效提升 3.3 倍，从外援到全自主。路线还在迭代，没有停滞。

但 HPCG/HPL 从 2.9% 退步到 1.0%。更多核心、更大 L2 共享、更高聚合带宽——这些设计选择优化了密集计算，代价是稀疏负载效率下降。路线越走越偏向"密集计算专用"，通用性在收窄。

vs El Capitan（异构路线的当前标杆）：

HPL 效率灵晟 80.35% vs El Capitan 63.4%——领先 17 个百分点。纯 CPU 没有跨设备同步开销，密集计算效率天然更高。仅次于 Fugaku 82.3% 和 K 的 93% 历史纪录。

BF16 算力密度差距巨大：LX2 的 240 TFLOPS vs MI300A 的约 1300 TFLOPS（GPU 部分）。在 AI 训练的绝对算力需求面前，这个 5.4 倍差距意味着 GPU 集群可以用少得多的计算单元达到同样的训练吞吐。

内存容量差距同样关键：MI300A 的 128 GB HBM3 vs LX2 的 64 GB HBM。El Capitan 可以把 70B 参数的 LLM 训练状态放在单颗 APU 的 HBM 中；灵晟做不到。

5.2 为什么日本转向了异构

日本 Fugaku-NEXT 宣布采用富士通 Monaka ARM CPU + NVIDIA GPU 的异构架构。这个决策的逻辑不在技术本身——富岳在 2020-2021 年是当之无愧的全球第一——而在负载变化。

2020 年富岳设计时，HPC 的主流负载是科学模拟（CFD、气象、地震、材料），FP64 密集计算为主。纯 CPU 架构完美适配。2024-2026 年，AI 训练负载的规模和比重爆炸式增长——LLM 参数从百亿到万亿，训练计算量每年翻几倍。CPU 的 SME 单元无法以同样速度扩展：

• 核心数受 L2 带宽约束：38 核/集群 × 8 = 304，已经是当前 L2 配置的极限
• 主频受工艺约束：1.55 GHz，国产 7nm 级别
• 功耗 700W/CPU，已经接近直接液冷的散热极限
• 加更多 SME 流水线需要更多 die 面积，但 reticle limit 逼着走 chiplet，chiplet 又引入跨 die 延迟

每个维度的扩展空间都到了边际收益急剧递减的拐点。下一代 GPU（NVIDIA Rubin、AMD MI450）的 BF16 将进入 3000-5000 TFLOPS 级别。LX2 的 SME 如果要把 BF16 推到 1000 TFLOPS，需要把 SME 流水线数量翻 4 倍——每核 4 条 SME pipeline，芯片面积增加 40-60%，功耗超 1000W/CPU。在当前封装和散热技术下不现实。

日本转向异构不是因为纯 CPU 路线"失败"，而是因为 AI 负载的成长曲线远超 CPU 矩阵单元的扩展曲线。当两条曲线的差距拉开到 10 倍以上，路线的选择就不由人决定了。

5.3 纯 CPU 路线的能力边界——定量推演

从第四章的三个案例和上面的架构分析，纯 CPU 路线的能力边界可以定量表述：

「更新」模型规模上限（刷新）：约 8-12B 参数（BF16 + Adam）。 由当前 64 GB HBM 容量决定。如果国产 HBM 容量进一步翻倍到 128 GB/堆叠，上限可提高到 20-30B。但 LLM 主流规模（70B+）仍远超这个数字——这是纯 CPU 路线的长期结构性劣势。

「更新」MFU 上限（刷新）：约 30-35%（BF16）。 64 GB HBM 消除了 SDMA 调度开销，MFU 从原来的 15.7% 可提升至 20-22%（D2AR 回推）。理论天花板~30-35%。GPU 同等负载 MFU 约 50-55%，差距从原来的 ~2× 缩到 ~1.5×。突破需要更大 HBM 带宽（>8 TB/s）或激进内存管理。

FP32 训练效率优势区间：二阶导数 + 不规则计算图。 在这个区间内 CPU 的利用率结构性高于 GPU（MatRIS-MoE：35.5% vs 25.4%）。但这个区间在整个 AI 训练市场中的占比很小——大部分训练是一阶 LLM，GPU 在那里效率更高。

多精度混合工作流：不可替代的结构性优势。 数值+AI 混合（CAPES 场景）在纯 CPU 上编程最简单、效率最高。但这类工作流在整个 HPC 市场中也不是主流。

系统规模甜蜜点：20,000-40,000 颗 CPU。 低于这个规模，计算时间太长；高于这个规模，通信开销开始侵蚀效率。灵晟的 40,960 颗 CPU 接近上限。

把这些边界画成一张图：

负载类型              纯 CPU 路线的位置
──────────────────────────────────────────────────────
uMLIP / 科学计算训练    ██████████ CPU 结构性优势
多精度混合 (数值+AI)   ██████████ CPU 不可替代
CFD / 气象模拟         ███████░░░ CPU 高效但 GPU 也可
标准 BF16 AI 训练      ███░░░░░░░ GPU 5× 算力密度优势
LLM 训练 (>20B)        ░░░░░░░░░░ HBM 容量不足
LLM 推理               ░░░░░░░░░░ GPU 压倒性优势
稀疏 / 图计算          ░░░░░░░░░░ HPCG = 1%

5.4 这条路线还有几代

灵晟的 LX2 触碰了纯 CPU 架构的四个物理边界：L2 带宽（38 核/集群极限）、功耗密度（700W/CPU）、HBM 容量（64 GB）、主频（1.55 GHz）。

下一代在同工艺节点上的改善空间有限——核心数加不了（L2 带宽已满）、主频提不了（工艺不变）、功耗已经到顶。唯一的出路是工艺跃迁。

如果国产工艺从 7nm 迁移到 5nm：

• 核心密度提升约 70-80%（5nm vs 7nm 的逻辑密度比）→ 单 die 可以放 ~250 核（当前 7nm ~150 核/die）
• 主频提升 30-50% → 2.0-2.3 GHz
• 同性能下功耗下降 30% → 或同功耗下性能提升 40-50%
• 可以做更大的 SME 单元或更多核心
• 估算：5nm LX2 下一代可达 FP64 ~100 TFLOPS、BF16 ~400 TFLOPS、约 60 核/集群 × 8 = 480 核

如果到 3nm（可能需要 3-5 年）：

• 核心密度翻倍 → ~500-600 核/CPU（需要重新设计 L2 层级，可能 12-16 集群）
• 主频 2.5-3.0 GHz
• FP64 ~200 TFLOPS、BF16 ~800 TFLOPS
• 这个水平接近当前 H100 的 BF16 算力，但仍远低于下一代 GPU（Rubin 预计 3000+ TFLOPS BF16）

纯 CPU 路线还有几代？

在 5nm 工艺下，纯 CPU 路线还有一代有力的迭代——BF16 从 240 提升到 ~400 TFLOPS，FP64 从 60 提升到 ~100 TFLOPS，能效从 51 提升到 ~70 GFLOPS/W。这一代在科学计算训练和多精度混合工作流上仍然保持结构性优势，在标准 AI 训练上的差距从 5.4 倍缩小到 ~3 倍。

到 3nm 工艺一代——如果国产 3nm 能在合理时间内量产——纯 CPU 路线还有最后一代。之后，CPU 和 GPU 的算力密度差距会再次拉开，因为 GPU 的专用性让它可以从每平方毫米硅片榨取更多 FLOPS。

最终判断：纯 CPU 路线在 HPC 集群中还有希望，但窗口在收窄。 它在科学计算训练、多精度混合工作流、密集 FP64 计算这些领域依然是最佳选择——不是次优替代，是结构性最优。但在 AI 训练和推理的主流市场上，GPU 异构路线的算力密度优势在持续扩大。

灵晟之后最可能的演进方向：不是继续纯 CPU，而是走向"ARM CPU + 国产加速器"的异构方案——用 LX2 的后继做通用计算和科学计算的 FP64 部分，用一个国产 AI 加速器（可能基于昇腾架构或全新设计）处理 BF16/FP8 大规模训练。这跟 Fugaku-NEXT 的路线在逻辑上是一样的：保留 ARM CPU 的科学计算优势和编程简洁性，同时引入专用加速器来覆盖 AI 训练的算力缺口。

这不是纯 CPU 路线的失败。是路线的自然演化——从"一种架构打天下"到"科学计算用 CPU、AI 训练用加速器"的分工。灵晟走到了纯 CPU 架构的最高点，也走到了纯 CPU 架构的分岔口。

---

声明： 本文基于公开信息撰写，综合参考了 ISC 2026 TOP500 榜单、arXiv 论文 2604.15821 / 2605.08633 / 2605.24896、Tom's Hardware 报道、国家超级计算深圳中心官方信息、富士通及 AMD 公开技术文档。更新数据来源：Timothy Prickett Morgan / The Next Platform 深度拆解（2026-06-25）、HACI 2026 灵晟演讲幻灯片（Torsten Hoefler / Tadashi Ogawa 公开发布）、NSC 深圳 arXiv 论文（2026-04-17）、芯智讯 / 至顶科技报道。6/29 更新数据来源：Chips and Cheese "TOP500 at ISC'26: We have a New Number 1"（George Cozma, 2026-06-25）。 微架构分析部分基于 ARMv9 架构规范和物理约束的推测，标注"推测"的为合理推断而非确认事实。不构成投资或策略建议。文中数据截至 2026 年 6 月 29 日。封面及机房实拍图来源：科技日报（记者罗云鹏，光明网 2026-06-24 转载），图片由国家超级计算深圳中心提供。