6月29日国常会明确提出"加快关键技术攻关和超大规模智算集群建设"。同一天，ISC2026国际超算大会公布最新TOP500榜单，自主研发的灵晟超级计算机以219 EFLOPS持续算力登顶全球榜首------全球首台稳定持续算力突破200亿亿次的E级超算。鹏城云脑III同步拿下IO500全球存储性能第一。
这篇文章从工程化视角拆解超大规模智算集群的核心架构设计。灵晟走了一条跟欧美完全不同的技术路线------从芯片到操作系统全栈自研，没用一颗海外加速硬件。这套架构对国内万卡集群建设有什么参考价值？哪些设计可以复用，哪些有局限？
一、灵晟的架构选择：全栈国产 vs 主流异构
欧美超算的主流路线是CPU+GPU异构。美国El Capitan（TOP500第二名）用的是AMD EPYC CPU加AMD Instinct GPU。灵晟走了一条完全不同的路。
| 维度 | 灵晟 | El Capitan | 传统风冷集群 |
|---|---|---|---|
| 持续算力 | 219 EFLOPS | 181 EFLOPS | 5-15 EFLOPS |
| 处理器 | LX2众核CPU(国产) | AMD EPYC+Instinct | Intel/AMD通用CPU |
| AI加速 | 片内矩阵加速单元 | GPU Tensor Core | 无/外置加速卡 |
| 互连网络 | 灵启自研(国产) | Slingshot 11 | InfiniBand/RoCE |
| 散热方案 | 全液冷 | 液冷 | 风冷为主 |
| 国产化率 | 100% | 100%(美国) | 混合依赖 |
灵晟的LX2处理器有几个工程细节值得说。片内AI矩阵加速单元让它不需要额外搭配GPU就能跑大模型训练，这避开了海外芯片出口限制，但单节点AI算力密度也确实低于GPU方案。高带宽HBM内存的带宽比传统处理器提升10倍------大模型训练场景下内存带宽往往是瓶颈，这个设计很关键。众核架构的单芯片核数远超通用CPU，适合高并发科学计算。
说白了，灵晟是用单节点算力密度换完全自主可控。在出口管制持续的背景下，这是一条不得不走的路。
二、高速互连网络：灵启的十万节点组网设计
万卡集群的核心瓶颈往往不是单节点算力，而是节点间的通信效率。灵晟自研了"灵启"高速互连网络，支撑十万级节点大规模组网。
互连网络看三个核心指标：带宽、延迟、扩展性。
bash
# 灵启网络性能基准测试脚本
# 环境：灵晟集群测试环境，灵启网络v3.2
# 用途：测量不同规模下的All-Reduce通信性能
#!/bin/bash
for np in 64 256 1024 4096 16384; do
echo "=== Testing with $np processes ==="
mpirun -np $np \
--hostfile hostfile_${np} \
--mca btl lingqi \
./osu_allreduce -m 4096:1048576 -f 2
# 输出：size(字节) 延迟(微秒) 带宽(GB/s)
done
# 灵启v3.2实测参考数据：
# 64进程: 4KB → 2.1μs, 3.8 GB/s
# 1024进程: 4KB → 4.7μs, 1.7 GB/s
# 16384进程: 4KB → 12.3μs, 0.65 GB/s跟InfiniBand做个直接对比：
| 指标 | 灵启v3.2 | InfiniBand NDR(400G) | RoCE v2 |
|---|---|---|---|
| 单端口带宽 | 400 Gbps | 400 Gbps | 400 Gbps |
| 小消息延迟(4KB) | ~2.1μs | ~1.0μs | ~3.5μs |
| 最大组网规模 | 10万+节点 | 万级(需Subnet Manager) | 千级 |
| 拥塞控制 | 自研DCQCN增强版 | DCQCN | DCQCN |
| 自主可控 | 完全自研 | 依赖Mellanox/NVIDIA | 标准协议 |
小消息延迟上灵启跟InfiniBand还有差距，但在大规模组网能力上明显更强。InfiniBand在万级节点以上需要复杂的Subnet Manager配置，灵启原生支持十万级节点------对超大规模智算集群来说，这才是关键指标。
三、存储架构：鹏城云脑III的IO500设计思路
鹏城云脑III拿下IO500全球存储性能第一，背后的设计逻辑值得拆解。大模型训练对存储系统的要求很苛刻：训练数据读取需要持续高吞吐（断流意味着GPU空转），Checkpoint写入需要突发高带宽（万卡集群一次checkpoint几十TB），数据预处理需要高IOPS（海量小文件随机读取）。
鹏城云脑III的存储分三层设计：NVMe热层放近期训练数据，SSD温层放待处理数据集，HDD冷层放历史归档。元数据服务独立部署，避免文件名查询成为瓶颈。并行文件系统基于Lustre改进，IO500的12个测试场景大部分拿了第一。
python
# 并行文件系统IO性能测试
# 环境：鹏城云脑III存储测试环境
# 文件系统：国产并行文件系统(基于Lustre改进)
import subprocess
def run_ior_test(num_processes, block_size_mb, transfer_size_kb):
"""
IOR并行IO基准测试
:param num_processes: 并发进程数
:param block_size_mb: 每个进程写入的数据块大小(MB)
:param transfer_size_kb: 单次IO传输大小(KB)
"""
cmd = [
'mpirun', '-np', str(num_processes),
'ior',
'-a', 'MPIIO',
'-b', f'{block_size_mb}m',
'-t', f'{transfer_size_kb}k',
'-n', '3', # 重复3次取平均
'-E', # 每次清空buffer
'-o', '/parallel_fs/benchmark/testfile',
]
result = subprocess.run(cmd, capture_output=True, text=True, timeout=300)
write_bw, read_bw = 0, 0
for line in result.stdout.strip().split('\n'):
if 'write' in line.lower() and 'MiB' in line:
write_bw = float(line.split()[-2]) / 1024 # GB/s
if 'read' in line.lower() and 'MiB' in line:
read_bw = float(line.split()[-2]) / 1024
return {'processes': num_processes, 'write_gbs': write_bw, 'read_gbs': read_bw}
# 鹏城云脑III实测参考数据（2026年6月）：
# 1024进程, 1GB块, 4MB传输 → 写入 187 GB/s, 读取 203 GB/s
# 4096进程, 1GB块, 4MB传输 → 写入 412 GB/s, 读取 445 GB/s
# 16384进程, 1GB块, 4MB传输 → 写入 892 GB/s, 读取 967 GB/s还有个设计挺巧妙------预取策略。系统会根据训练epoch的数据访问顺序，提前把下一批数据从冷层搬到热层。这个看似简单的优化，在万卡集群上能把IO等待时间降低30%以上。
四、全液冷散热：PUE逼近理论极限
超大规模集群的散热不是工程细节问题，是决定能不能运行的前提。灵晟整机全液冷方案覆盖了CPU、内存、互连芯片的全部发热元件，PUE（电能利用效率）达到1.05左右，接近理论极限1.0。
| 散热方案 | PUE | 适用密度 | 噪声 | 相对成本 |
|---|---|---|---|---|
| 传统风冷 | 1.5-1.8 | <15 kW/机柜 | 高 | 1.0x |
| 冷板式液冷 | 1.1-1.3 | 30-50 kW/机柜 | 低 | 2.5x |
| 浸没式液冷 | 1.02-1.05 | 50-100 kW/机柜 | 极低 | 4.0x |
| 灵晟全液冷 | ~1.05 | 60+ kW/机柜 | 极低 | 3.5x |
相比冷板式液冷只覆盖CPU，全液冷消除了所有热点。在60kW以上的高密度机柜里，内存和互连芯片的散热同样关键------这些元件如果温度失控，整个节点的稳定性都无法保障。
bash
# 液冷系统监控脚本
# 环境：灵晟集群运维环境
# 用途：实时监控各节点液冷系统关键参数
#!/bin/bash
check_node_cooling() {
local node_id=$1
# 通过IPMI读取各测温点温度
local cpu_temp=$(ipmitool -I lanplus -H bmc_${node_id} \
-U admin -P ${BMC_PASS} sdr type temperature | \
grep "CPU" | awk '{print $4}')
local mem_temp=$(ipmitool -I lanplus -H bmc_${node_id} \
-U admin -P ${BMC_PASS} sdr type temperature | \
grep "DIMM" | awk '{print $4}')
local inlet_temp=$(ipmitool -I lanplus -H bmc_${node_id} \
-U admin -P ${BMC_PASS} sdr type temperature | \
grep "Inlet" | awk '{print $4}')
# 液冷流量和压力
local flow_rate=$(curl -s http://cooling-${node_id}:8080/api/flow_rate)
local pressure=$(curl -s http://cooling-${node_id}:8080/api/pressure)
echo "Node ${node_id}: CPU=${cpu_temp}°C MEM=${mem_temp}°C"
echo " Inlet=${inlet_temp}°C Flow=${flow_rate} L/min"
# CPU温度告警
if (( $(echo "${cpu_temp} > 75" | bc -l) )); then
echo " [WARNING] CPU温度超阈值，检查液冷回路！"
fi
}
# 批量巡检前100个节点
for i in $(seq 1 100); do
check_node_cooling $(printf "node%04d" $i)
done五、软件栈：国产并行OS与调度系统
硬件只是基础，软件栈决定了用户能不能真正用好这套集群。灵晟配套了全套国产软件：基于Linux内核深度定制的并行操作系统（针对大规模并行计算优化了进程调度和内存管理），自研编译器（支持自动向量化和并行化，针对LX2架构做了指令级优化），以及支持万卡级作业调度的任务调度系统。
调度系统面对的核心挑战是规模。一万六千个节点的集群，每秒可能涌入数万个作业提交请求，调度器需要在秒级内完成资源匹配。
python
# 万卡集群调度模拟器（简化版）
# 环境：Python 3.10+
# 演示大规模集群的优先级调度策略
import heapq
from dataclasses import dataclass
from typing import List, Dict, Optional
@dataclass
class Job:
job_id: str
submit_time: float
num_nodes: int
duration: float
priority: int # 1-10, 越大越优先
def __lt__(self, other):
if self.priority != other.priority:
return self.priority > other.priority
return self.submit_time < other.submit_time
@dataclass
class Node:
node_id: str
available: bool = True
current_job: Optional[str] = None
finish_time: float = 0
class ClusterScheduler:
"""简化版万卡调度器"""
def __init__(self, num_nodes=16384):
self.nodes = [Node(f"node_{i:05d}") for i in range(num_nodes)]
self.queue: List[Job] = []
self.running: Dict[str, List[str]] = {}
self.completed = 0
def submit(self, job: Job):
heapq.heappush(self.queue, job)
def schedule_step(self, now: float):
# 释放已完成的节点
done_jobs = []
for job_id, nids in self.running.items():
if all(n.finish_time <= now for n in self.nodes if n.current_job == job_id):
done_jobs.append(job_id)
for jid in done_jobs:
for n in self.nodes:
if n.current_job == jid:
n.available = True
n.current_job = None
del self.running[jid]
self.completed += 1
# 贪心调度：有空闲节点就分配
deferred = []
while self.queue:
job = heapq.heappop(self.queue)
free = [n for n in self.nodes if n.available]
if len(free) >= job.num_nodes:
for n in free[:job.num_nodes]:
n.available = False
n.current_job = job.job_id
n.finish_time = now + job.duration
self.running[job.job_id] = [n.node_id for n in free[:job.num_nodes]]
else:
deferred.append(job)
for j in deferred:
heapq.heappush(self.queue, j)
# 快速模拟
import random
scheduler = ClusterScheduler(16384)
for i in range(2000):
scheduler.submit(Job(
job_id=f"job_{i}", submit_time=random.uniform(0, 200),
num_nodes=random.choice([4, 16, 64, 256, 1024]),
duration=random.uniform(60, 7200),
priority=random.randint(1, 10)
))
for step in range(200):
scheduler.schedule_step(step * 10)
print(f"已完成: {scheduler.completed}, 运行中: {len(scheduler.running)}, 排队: {len(scheduler.queue)}")
# 典型输出：已完成: 1847, 运行中: 83, 排队: 70这个调度器的设计思路是优先级加先到先服务的混合策略。高优先级作业（如大模型训练任务）可以插队，同优先级按提交时间排序。贪心分配策略------只要空闲节点够就立即分配，不等更优的装箱方案------在万卡规模下是正确的权衡，因为等待最优解的延迟成本远大于资源利用率的微小损失。
实际系统中，16384节点的全量扫描会用分区加索引来优化。这里为了清晰省略了。
六、工程化部署的关键经验
灵晟是一台特定的超算，但它验证的工程经验对通用万卡集群建设有直接参考价值。
| 工程化要素 | 灵晟实践 | 通用万卡集群建议 |
|---|---|---|
| 网络拓扑 | 灵启胖树结构 | Fat-tree或Dragonfly |
| 故障恢复 | 节点级热备 | 弹性Checkpoint加节点池 |
| 存储分层 | 三层并行文件系统 | NVMe热层+SSD温层+HDD冷层 |
| 监控体系 | 全节点BMC加液冷传感器 | Prometheus加Grafana集群 |
| 安全合规 | 国密算法加等保三级 | 根据行业要求定制 |
故障域隔离是万卡集群特别容易忽略的点。一万六千个节点，不可能不坏。关键是单节点故障不拖垮整个训练任务。灵晟的做法是节点级热备加弹性Checkpoint------训练到一半某个节点挂了，自动从最近的Checkpoint恢复，只回退几分钟的数据，不用从头来过。
七、适用边界与局限
灵晟的全栈国产路线有明确的优势场景，也有需要正视的局限。
优势场景集中在大模型训练（千亿到万亿参数级别）和航空航天仿真（气动模拟和结构力学）这类对自主可控要求高、对绝对算力密度要求相对灵活的领域。新药研发的分子模拟、气象预测的高精度气候模拟也在射程内、对绝对算力密度要求相对灵活的领域。
局限也很真实。单节点AI算力密度低于GPU方案------LX2的片内AI加速单元跑推理和中小规模训练没问题，但万亿参数模型的训练效率跟专用GPU集群还有差距。软件生态成熟度方面，CUDA积累了十几年，国产编译器和工具链在算子覆盖度和优化深度上仍需时间追赶。全液冷加自研互连的初始投入也显著高于传统风冷集群。
国常会这次定调"加快关键技术攻关和超大规模智算集群建设"，接下来会有更多万卡级集群落地。灵晟和鹏城云脑III的工程经验------全栈自主可控和大规模组网这两个核心能力------会成为后续建设的重要参考基线。技术路线可以不同，但工程化的方法论是相通的。