AI 集群正在把传统计算机体系推向极限：处理器数量持续增加，但通信、同步、内存访问和故障处理的成本不会同步消失。华为发布的 Peerium 计算架构试图改变系统的组织方式，通过嵌套并行、统一内存寻址和平等互联，让百万级处理器在编程和资源管理层面表现为一台计算机。
这里的重点不只是“连接更多芯片”，而是让应用不必直接面对海量独立节点。根据已公布的摘要，Peerium 引入 Nested BSP，并将其描述为对传统图灵范式与冯·诺依曼单机架构的突破。不过，这些表述仍需要结合后续技术论文、编程接口和实测数据来判断其具体边界。
百万处理器成为一台计算机，难点在哪里
把大量处理器装进一个数据中心并不困难，困难的是让它们像一个系统那样协同工作。
传统分布式程序通常需要开发者显式处理节点、网络、数据分片和失败重试。规模增长到百万级处理器后，几个问题会迅速放大：
- 全局同步成本：如果每一步计算都等待所有处理器，最慢的节点会拖住整个任务。
- 数据移动成本：AI 训练中的梯度、参数和激活值可能比计算本身更昂贵。
- 寻址模型割裂：本地内存、远端内存和设备内存往往使用不同接口，增加运行时与开发复杂度。
- 互联层级复杂：同机、同机架、跨机架和跨数据中心的带宽与延迟差异巨大。
- 故障成为常态：节点数量足够大时，单个器件或链路失效不再是偶发事件。
因此，“一台计算机”更适合被理解为统一的编程、寻址、调度和资源视图，而不是所有处理器之间具有完全相同的物理延迟。
Nested BSP：用嵌套层级控制同步范围
BSP，即 Bulk Synchronous Parallel，通常把并行程序划分为重复执行的超级步：
- 各处理单元执行本地计算；
- 处理单元交换数据；
- 所有参与者到达同步点，然后进入下一轮。
经典 BSP 模型清晰，但在超大规模系统中，全局屏障可能非常昂贵。Peerium 提出的 Nested BSP，可以从名称和摘要所述能力理解为：把并行组织成多层嵌套结构，在较小范围内频繁同步，在更大范围内降低同步频率。
例如，一次 AI 训练可以形成这样的层次：
- 加速器内部完成张量分块计算；
- 节点内多个加速器合并局部结果；
- 机架内完成一次聚合；
- 多个机架在更粗粒度的超级步上交换结果。
这种结构的价值在于让算法结构贴合硬件拓扑。局部通信留在低延迟范围内，昂贵的全局通信只在必要时发生。不过，“平等互联”不应简单理解为物理链路不存在距离差异；工程上仍需关注拓扑感知调度、拥塞控制和跨层通信成本。
统一寻址不等于所有内存同样快
统一内存寻址可以减少应用对数据位置的显式管理。理想情况下，程序操作的是统一地址空间，由编译器、运行时和硬件决定数据位于本地内存、远端内存还是其他设备上。
但统一地址空间并不会消除性能层级。开发者仍需要知道：
- 远端访问是否具备缓存一致性；
- 数据迁移由硬件还是运行时触发；
- 页错误或远端缺页的成本是多少；
- 热点地址是否会造成链路拥塞；
- 一致性范围是节点内、机架内还是全系统。
因此，判断 Peerium 的统一寻址能力时，不能只看“地址是否统一”，还要看一致性协议、内存语义、故障隔离和性能可预测性。
用本地 Python 模拟嵌套式 BSP
目前摘要没有给出 Peerium 的公开 SDK 或编程接口。下面的例子不是 Peerium API，而是一个可以直接运行的概念模拟：先由多个进程计算分片结果，再在组内聚合，最后执行全局聚合。ProcessPoolExecutor 一轮任务完成，相当于一个简化的同步屏障。
将以下内容保存为 nested_bsp_demo.py：
from concurrent.futures import ProcessPoolExecutor
from collections import defaultdict
import os
def shard_sum(task):
group_id, shard_id, start, stop = task
subtotal = sum(range(start + 1, stop + 1))
return group_id, shard_id, subtotal
def main():
n = 1_000_000
workers = min(8, os.cpu_count() or 1)
shards = workers * 4
shards_per_group = 4
tasks = []
for shard_id in range(shards):
start = n * shard_id // shards
stop = n * (shard_id + 1) // shards
group_id = shard_id // shards_per_group
tasks.append((group_id, shard_id, start, stop))
# 第一层超级步：各分片并行计算，任务全部完成后形成同步点。
with ProcessPoolExecutor(max_workers=workers) as executor:
shard_results = list(executor.map(shard_sum, tasks))
# 第二层超级步：在组内聚合。
group_totals = defaultdict(int)
for group_id, _, subtotal in shard_results:
group_totals[group_id] += subtotal
# 最外层超级步：聚合所有组的结果。
global_total = sum(group_totals.values())
expected = n * (n + 1) // 2
print(f"workers={workers}, shards={shards}, groups={len(group_totals)}")
print(f"result={global_total}")
print(f"expected={expected}")
assert global_total == expected
if __name__ == "__main__":
main()
运行：
python nested_bsp_demo.py
这个示例没有模拟统一内存、真实网络或容错，但展示了 Nested BSP 的核心工程思路：不要让所有工作单元在每个阶段都参与全局同步，而是先完成局部计算和局部归并，再进入更高层级。
如果要进一步改造，可以把组内聚合替换成共享内存，把组间聚合替换成 MPI、RDMA 或集合通信库，并分别记录各层的计算时间、通信字节数和屏障等待时间。
评估 Peerium 时应关注什么
Peerium 描绘的是一种强扩展方向，但“百万级处理器”是规模目标，不等同于所有工作负载都能获得线性加速。真正决定架构价值的，是软件与硬件能否共同压低通信和管理成本。
在考虑采用类似架构时，可以重点检查以下问题：
- 是否提供稳定的编程模型、编译器和调试工具；
- Nested BSP 如何映射现有的数据并行、张量并行和流水线并行；
- 统一寻址采用什么一致性与隔离语义；
- 平等互联如何处理物理拓扑、热点和拥塞；
- 节点或链路失败后，超级步能否局部恢复；
- 扩展效率是否包含网络、存储和检查点开销；
- 能否运行现有 AI 框架，迁移成本有多高。
Peerium 最值得关注的地方，是把“集群中的许多计算机”重新抽象为“具有层级结构的一台计算机”。这一方向能否落地，则要等待更完整的架构说明、开发工具、兼容性信息，以及从单节点扩展到百万级处理器的公开测试结果。