lyramakesmusic/neuron-explorer

如果你已经在小型开放权重模型上做激活引导研究，并且有可用的 GPU 时间，可以试；把它当研究工具，而非成品。

解决什么问题

你想知道单个 MLP 神经元到底做什么，而不只是 layer 22 上某个整体方向的作用。常见做法很零散：写个脚本改一个神经元，跑几条 prompt，扫一眼生成结果，换下一个神经元时脚本就丢了。由于每个神经元、每个剂量的结果都没有归档，两天后你没法把 3501 号神经元的三条 prompt 和 12000 号神经元的六条 prompt 放在一起比较，也没有基线来判断哪些效果只是噪声。

这个项目把流程改成一轮批量 sweep 加一个浏览器。选定层里每个 MLP 神经元都被同样几条 prompt 分别推高和压低，每条 rollout 连同文本、token id、logprob 和 top-k 落盘，探索器再把这些结果铺在模型各层的 3D 视图上。你得到的是可持久保存、可视觉导航的结果，而不是一次性的 prompt 实验。

有什么不同

机制的关键在于把全量 sweep、随机对照组和下游 lens 放在一起。sweep/rank.py 用独特词和 cluster mass 给神经元打分，并与 256 个随机方向对照；sweep/steer_lens.py 记录每个神经元在 ±0.8 推动下 next-token logprob 的变化和 KL。对照比较才是真正有用的部分：它让你能区分有可重复效果的神经元和只是碰巧生成了一句有趣文本的神经元，而不用手工读三万条输出。

剂量以离开该层时残差范数的中位数比例表示，而不是原始激活差值，因此 +0.8 是相对该层自身尺度的量。README 描述了固定的 prompt/剂量网格，例如 {who, snake, orange} 在 −0.7 和 +0.5/+0.8 下，外加每条 prompt 一个未引导基线。代价是这批 sweep 很重：每个神经元乘以若干 prompt 再乘以若干剂量，而且需要 vLLM 的 steering fork。探索器的实时聊天会本地加载 Qwen3.5-4B，用于引导、lens 和消融。

投入前需要明白一点：sweep、stats 和 cache 文件是探索器的输入。仓库自带的 cache 只覆盖作者生成过的内容；你自己的层需要自己把 sweep 结果放进 runs/ 和 stats/。另外有一个 Claude 面板，通过 MCP server 调用 claude CLI，能读取神经元、运行实时模型、移动地图，并在你的 home 目录里使用文件工具和 shell。这是研究时的便利，不是浏览已有 run 的必要条件。

谁值得试

适合已经有 CUDA pod、熟悉 vLLM 和 Hugging Face 内部机制、并且专门想在 Qwen3.5-4B 上跑神经元级密集引导实验的机制可解释性研究者或好奇的工程师。如果你只想交互式查看某个感兴趣的神经元，三列引导聊天和逐神经元 rollout 能省掉你自己搭框架的功夫。

不适合想要一个适用于任意模型的通用可解释性工具、或者不打算跑 sweep 就想看效果的人。探索器围绕 Qwen3.5-4B 和这些脚本产出的数据构建；README 没有提供与模型无关的路径，也没有托管版本。

使用条件与边界

sweep 路径明确要求 CUDA 13 GPU pod、RhizoNymph/vllm 的 steering fork，并由 setup_pod.sh 写出环境文件。探索器可以在 MPS、CUDA 或 CPU 上加载模型，但重头在 sweep。仓库未声明 license，在基于它继续开发前需要确认使用条款是否合适。

Claude 面板有单独的准备工作：必须安装并登录 claude CLI，且服务端说明它只响应本机上的页面和工具。这个 agent 拥有你 home 目录里的文件工具和 shell，应把它当作能访问本地文件的可执行环境，而不是隔离沙箱。日常维护更多是研究工作流问题：增加层时保持 runs、stats 和 cache 目录一致，README 只通过 merge_runs.py 和 depth report 给了粗略说明。

HotRepo 点评

HotRepo 从 2026-10-24 开始追踪这个仓库，2026-10-26 在 NEW-REPOSITORY 榜（python，并非总榜）上观察到它以 673 总 stars 排到 #22。这只是四天新仓库的一个带日期快照，不是每日增长序列，因此还无法判断热度能否持续。投入 GPU 时间前，先确认决定适配性的那一点：sweep 脚本能否接受你自己数据所需的层和 stats 布局。

项目源码与说明