Arbor模拟中可通过rank检查实现spike记录吗？两种记录方案有何差异

单rank全量记录方案的可行性 #

你给出的仅在rank 0调用sim.record(arbor.spike_recording.all)的方案是完全可行的。Arbor底层的分布式通信逻辑已经封装了跨MPI节点的spike收集能力，arbor.spike_recording.all模式会自动汇总所有节点产生的spike数据，不管在哪个rank调用该记录接口，只要调用就会触发全局收集，仅在rank 0调用的话，最终全量spike只会存储在rank 0的进程内存中，不会占用其他rank的内存，逻辑完全合法可用。

两种方案的优劣对比 #

单rank全量记录方案 #

• 优势：
  • 内存占用低：仅单节点存储全量spike，其余节点无额外spike存储开销，整体内存占用远低于多节点本地记录方案
  • 代码逻辑简洁：不需要自己实现跨节点spike聚合、广播逻辑，Arbor底层已经完成了所有分布式收集工作
  • 后续处理成本低：全量spike已经在单节点汇总完成，不需要做多节点数据合并，可直接在rank 0做分析、存盘等操作
• 劣势：
  • 存在单节点内存瓶颈：如果模拟规模极大、spike总产出量超过单节点内存上限，会触发OOM导致程序崩溃
  • 写盘性能受限：所有spike都只能通过单节点写入存储，无法利用分布式存储的并行带宽，spike量高时会拖慢整个模拟的收尾速度
  • 容错性差：负责存储spike的节点一旦崩溃，全量spike数据会直接丢失，无冗余备份
• 适用场景：中小规模神经网络模拟，spike总数据量不超过单节点内存上限，且仅需单节点处理spike结果的场景。

多节点本地记录后聚合方案 #

• 优势：
  • 无单节点内存瓶颈：每个节点仅存储自身负责的细胞产生的spike，存储压力分散到所有MPI节点，可支持超大规模、高放电频率的模拟场景
  • 写入性能更高：支持多节点并行写spike到分布式存储，可充分利用集群存储的并行带宽，避免单节点写盘瓶颈
  • 容错性更好：单个节点崩溃只会丢失该节点负责的spike数据，不会导致全量数据丢失
• 劣势：
  • 开发成本高：如果需要全局spike数据，需要自己实现MPI_Gather聚合逻辑，或者后续手动合并多节点输出的spike文件，代码复杂度更高
  • 整体内存开销更高：所有节点都需要存储自身产生的spike，集群整体内存占用比单节点记录方案更高
  • 后续处理流程长：要做全局spike分析必须先合并多节点数据，增加了后续数据处理的步骤
• 适用场景：超大规模神经网络模拟，spike总产出量超过单节点内存上限，或者对写盘吞吐量有极高要求的场景。

示例代码说明 #

import arbor, mpi4py.MPI

# 基于网络构建规则、域分解方案、运行时上下文初始化Arbor仿真实例
sim = arbor.simulation(recipe, decomp, context)
# 仅在MPI的0号进程上开启全量spike记录
if not mpi4py.MPI.COMM_WORLD.Get_rank():
  sim.record(arbor.spike_recording.all)

内容的提问来源于stack exchange，提问作者Robin De Schepper