4. 训练规模与"本地部署"的诚实测算
#数字
| 参照 | 参数量 | 换算成"神经元" |
|---|---|---|
| 我们当前胜出配置 | 1,874 | 16 |
| GPT-2 large（能写通顺文本，不会对话） | 749M | — |
| 日常对话下限（LLaMA-7B 量级） | 6.57B | ≈ 900 万 |
| Mamba-3B（液态/SSM 路线已做到的） | 5.12B | ≈ 700 万 |
差距：从 1,874 参数到 6.57B 是约 350 万倍。 通用对话在现有资源下不可达。
#但本地部署不是问题，训练才是
| 参数量 | 权重显存 | 本机 8GB | GPU 生成速度 |
|---|---|---|---|
| 100M | 0.19 GB | ✅ | ~800 tok/s |
| 3B | 5.59 GB | ✅ | ~35 tok/s |
| 7B | 13.04 GB | ❌（需量化） | ~12 tok/s |
能跑，不能造：1B 参数在 8GB 显存上无法从零预训练。
#真正的硬约束是数据，不是算力
Chinchilla 经验律：参数量 × 20 tokens 是下限。
| 规模 | 至少需要的 tokens |
|---|---|
| 我们当前（3.7M 参数） | 73M |
| units=2048（69M 参数） | 1.39B |
| 对话下限（6.57B） | 1.4 万亿 |
这不是租服务器能解决的（租机器买不到数据）。
#★ 由此推出的架构决策：解耦"内心"与"嘴巴"
| 部分 | 谁提供 | 我们做什么 |
|---|---|---|
| 语言生成 | 本机跑量化后的小 LLM（1–3B） | 只当"发声器官" |
| 内心（情感 / 记忆 / 主动性 / 自我模型） | 我们自己造 | 项目的核心 |
| 接口 | — | 内心状态 → 调制语言行为与语气 |
为什么这样对：
- 立刻可做，不需要万亿 tokens
- 与"给 LLM 写 prompt 说你是 Atri"有本质区别 —— LLM 没有真正的持久状态、没有自身动力学、没有内驱力。所有"活着的部分"都在我们这边
- 保住了科学内核（四需求仍是主线）
- 结果可以被真正体验，而不是停留在准确率数字
#参数为什么在语言任务里不是主导变量
一旦接上语言输出，参数量主导项立刻从"神经元"变成词表嵌入：
| units | 液态层参数 | +词表 50k | 总参数 |
|---|---|---|---|
| 48 | 37.2K | 2.4M | 5.7M |
| 512 | 395K | 25.6M | 29.3M |
词表嵌入占 65 倍以上，且随 units 线性增长；神经元间连接才是二次的。 → 所以"训练多少个神经元"在语言任务里不是主导变量。
#神经元能否后期添加
| 组件 | 能否后期加 | 原因 |
|---|---|---|
| 液态循环核 | ❌ 不能无缝 | 稠密循环权重 + 非线性门控；Net2Net 式的"复制+减半"在线性层上精确（实测差异 5.96e-08），在 CfC 上只近似（因 backbone 里的 tanh 破坏恒等） |
| 专家池 | ✅ 可以，且无缝 | 加一个专家不影响任何已有专家（Progressive Nets 已验证不遗忘） |
| 词表嵌入 / 读出层 | ✅ 可以 | 线性层，Net2Net 精确适用 |
结论：液态核不能"先小后大"，但专家池可以"先少后多"。 所以正确路线是：把核做小做稳做好路由，把容量放在可增删的专家池里。
这也让用户早先提出的"LNN 路由 + 稀疏专家池"从"一个可选架构"变成 "唯一能支持逐步长大的架构"。
#★ 4x. 实测：本机能跑多大的 LNN，以及时间刻模拟速度
此前所有关于"规模"的判断都是估算。第 0 阶段做了实测
（experiments/diag_lnn_capacity.py，RTX 5060 8 GB）。
| units | backbone | 参数量 | 推理显存 | 模拟速度 | 每刻 | 训练显存 | 训练速度 |
|---|---|---|---|---|---|---|---|
| 16 | 16 | 3,042 | 0.03 G | 1,558/s | 0.64 ms | 0.07 G | 24,623/s |
| 64 | 64 | 30,018 | 0.06 G | 1,722/s | 0.58 ms | 0.07 G | 24,402/s |
| 256 | 256 | 414,402 | 0.06 G | 1,647/s | 0.61 ms | 0.11 G | 26,668/s |
| 1024 | 1024 | 6,375,618 | 0.09 G | 1,850/s | 0.54 ms | 0.32 G | 21,435/s |
| 2048 | 2048 | 25,333,954 | 0.16 G | 2,084/s | 0.48 ms | 0.79 G | 17,281/s |
| 4096 | 4096 | 100,999,362 | 0.44 G | 719/s | 1.39 ms | 2.39 G | 5,276/s |
| 8192 | 8192 | 403,325,122 | 1.57 G | 192/s | 5.22 ms | 8.22 G ✗ OOM | — |
三条结论：
① 模拟速度对模型大小几乎不敏感 —— 直到 2500 万参数。 参数量从 3 千做到 2500 万（8300 倍），时间刻速度 1,558 → 2,084 刻/秒（不降反升）。 拐点在 2500 万 ～ 1 亿参数之间（那里单次 kernel 的计算量终于追上启动开销）。 原因见 §6.19c 与 §11：时间是 kernel 启动次数主导的，而次数固定 （T 步串行 × 每步约 10 个 kernel）。模型变大只让每次 kernel 变大，而算力占用率是 0.072%。
② "流畅"不是约束，显存才是。 人类对话需要 10–100 刻/秒（60 刻/秒 = 每刻 16.7 ms）。 即使 4 亿参数的模型也有 192 刻/秒 —— 是需求的 2–19 倍。
③ 本机实际上限
| 用途 | 上限 | 配置 | 依据 |
|---|---|---|---|
| 模拟 / 常驻（智能体在跑） | ≥4 亿参数 | units=8192 | 1.57 G，192 刻/秒，仍有余量 |
| 从零训练 | ≈1.5–2 亿参数 | units=4096 稳；8192 OOM | 101 M → 2.39 G ✓；403 M → 8.22 G ✗ |
★ 由此推出的选型建议
| 场景 | units/backbone | 参数量 | 显存 | 速度 |
|---|---|---|---|---|
| 从零训练（推荐） | 1024 / 1024 | 640 万 | 0.32 G | 1,850 刻/秒 |
| 训练得更强 | 2048 / 2048 | 2500 万 | 0.79 G | 2,084 刻/秒 |
| 模拟 / 守夜常驻 | 4096 / 4096 | 1 亿 | 0.44 G | 719 刻/秒 |
在实测之前，我们一直在用
units=16–128（3 千 ～ 10 万参数）—— 比硬件能力小用了 3–4 个数量级，而放大它几乎免费 （实测：1,874 → 100,994 参数，每次迭代 154.3 → 151.7 ms，完全不变）。
★ 这也让"租云服务器提速"的答案变得清楚： 瓶颈是 kernel 启动次数与 Python 开销，不是算力。 更强的 GPU 对这些实验一秒都不会快；云端唯一的价值是并行跑很多个（吞吐）， 不是单步速度。详见 §11.20。