5.6 先在仿真器里跑通：Brian2 与 Lava 实战

5.6 先在仿真器里跑通：Brian2 与 Lava 实战

本节摘要：仿真器是工具链的第一站，两条主线各司其职：Brian2 用"方程即代码"的方式服务模型探索，几行 Python 就能定义自定义神经元；Lava 用统一接口跨 CPU、GPU 与 Loihi 后端，服务部署前的迁移验证。本节各给一个完整可跑的最小项目，并交代两者的分工与迁移要领。

5.5 节画了全链路地图，本节走进第一段和第四段的入口：仿真器。选择仿真器像选自行车还是选货车——Brian2 适合把一个动力学问题想透，Lava 适合把一个网络搬到目标后端。多数项目两个都会用到，先后有别。

Brian2：把方程写进代码

Brian2 的核心声明式 API 让你直接写微分方程，框架负责离散化与编译。下面这个最小项目演示 2.1 节的 LIF 在恒流输入下的频率-电流关系，十几行跑完全程：

from brian2 import *

# 单位系统是 Brian2 的灵魂：ms、mV、pA 全部显式
defaultclock.dt = 0.1 * ms

n = NeuronGroup(
    4,
    """dv/dt = (-(v - v_rest) + R * I) / tau : volt
       I : amp""",
    threshold="v > v_th",
    reset="v = v_reset",
    method="exact",
)
n.v_rest = -70 * mV
n.v_th = -55 * mV
n.v_reset = -70 * mV
n.tau = 20 * ms
n.R = 100 * Mohm
n.I = [120, 150, 180, 210] * pA          # 四档注入电流
n.v = -70 * mV

mon = SpikeMonitor(n)
run(500 * ms)

for idx in range(4):
    rate = mon.count[idx] / (500 * ms) / Hz
    print(f"电流档 {idx}: 发放率约 {rate:.0f} Hz")
# 预期：发放率随电流单调上升——2.1 节的电流-频率特性在真实仿真器里复现
​

这段代码里值得学的不是 LIF（你已经会了），而是工程习惯：单位显式声明让量纲错误在编译期就暴露；method="exact" 对线性方程用精确积分，避免步长误差污染发放时序；SpikeMonitor 与 StateMonitor 分离，让"看脉冲"和"看波形"解耦。Brian2 的甜点区是单神经元动力学、小网络现象（同步、波传播）、STDP 规则原型的快速验证——凡是"探索"性质的活，它最快。

Lava：面向后端的中间表示

Intel 开源的 Lava 的设计目标是"一次建模、多后端运行"：同一份网络描述，可以在 CPU 仿真、GPU 仿真与 Loihi 2 硬件之间切换后端，切换成本只是一个参数。它的抽象层级比 Brian2 高：神经元是进程（Process）单元，脉冲经通道（Port）传递，时间步由统一的 Runtime 驱动。下面是它的固定输入到 LIF 层的最小骨架：

from lava.lib.dl.slayer import neuron as slayer_neuron   # 训练侧接口（LOIHI 神经元参数化）
import lava.magma.core.run_conditions as rc
import torch

# Lava 的训练侧（slayer）与部署侧共享同一套神经元参数口径：
# 每步衰减 1 - 1/tau，电流单位按 Loihi 的整数权重标定
lif = slayer_neuron.Leaky(
    current_decay=1 - 1/20.0,     # tau = 20 步，与芯片时间步口径一致
    voltage_decay=1 - 1/20.0,
    v_threshold=1.0,
)
x = torch.rand(8, 1, 10) * (torch.rand(8, 1, 10) > 0.9)   # 稀疏脉冲输入
out, _ = lif(x)
print("发放数:", int(out.sum()), "/ 输入脉冲:", int(x.sum()))
# 关键习惯：从第一天就用目标硬件的时间步与整数权重口径做实验，
# 迁移时的语义差异（5.5 节断点二）就会消失大半
​

注意这段代码透露的部署心法：用目标后端的口径做仿真。Loihi 的权重是整数（1 至 255 区间的脉冲电流增量），膜电位按时间步整数衰减——训练时就按这个口径约束参数，编译映射时的量化误差就少一层。很多"仿真器上很美、芯片上翻车"的案例，根子都在训练时用了浮点口径。

两者怎么分工与交接

我的使用次序是：现象验证用 Brian2（单位系统对动力学直觉极友好，调 tau、看波形、试规则都是几分钟的事）；网络定型后用 snntorch 或 slayer 系（含 Lava 训练侧）在 GPU 上以目标口径重训；最后用 Lava 的 CPU/GPU 后端做"预演"，确认映射后的行为与训练侧一致，才碰真芯片。交接时有两张对账单必须核：时间常数对照表（仿真单位换算到芯片时间步）与权重对照表（浮点值量化到整数刻度后的误差统计）。

⚠️ Brian2 有一个高频踩坑点值得点名：把 tau 或阈值设成跨数量级混合单位（毫秒对秒、毫伏对伏特），不报错但行为诡异——它的单位系统只在量纲上检查，不管数值合理性。Lava 的对应坑是后端差异：CPU 仿真与 Loihi 硬件在脉冲到达的同时间步仲裁上语义略有差异，对时序敏感的网络要做多后端行为对比。

两个工具各自的"能力边界"也要说清，避免用错场合。Brian2 不适合的：大规模网络的吞吐仿真（纯 Python 前端加数值积分，百万神经元级会比专业引擎慢一个量级以上，它官方也建议大规模转 NEST 或 CoreNEST 后端）；面向具体芯片的部署仿真（它没有芯片资源模型的概念）。Lava 不适合的：自定义神经元动力学的快速探索（写一个新模型要走进程模型与端口协议的完整流程，探索成本远高于 Brian2 的一行方程）；以及教育演示（抽象层级高，反而遮住了动力学细节）。一句话分工：Brian2 是"动力学实验室"，Lava 是"部署转运站"。

版本生态方面提醒一句：这类工具都处于活跃演进期，接口年年在动。务实做法是把你的实验代码冻结在明确的版本号上（连同环境文件一起存档），升级前先跑回归——尤其是 Lava，跟着它的示例版本走能少踩一半的坑。

仿真器的意义不是"替代芯片"，而是在你付出真硬件的约束成本之前，把算法错误全部清理干净。Brian2 负责想明白，Lava 负责搬过去——先后不能乱。

下一节看工具链的最后一站：真芯片上的开发环境到底长什么样。