1.5亿参数拿下29.5% ARC-AGI，潜空间循环或颠覆Transformer

在尝试复现 Pathway 团队的逻辑推理实验时，我发现，面对 ARC-AGI-1 这类强逻辑任务，传统 Transformer 架构单纯依赖扩大参数量，也就是 Scaling Laws，已经出现边际效应递减的趋势。

我研究了 Pathway 团队 150M 参数量模型的实现方式，发现它的关键并不是继续堆叠参数，而是将预测方式从 Token 空间的概率预测，转向循环潜空间推理（Recurrent Latent Reasoning）。

在实际部署中，这个模型的单次任务推理成本仅为 0.0007 美元。这也意味着，逻辑推理能力的提升不再需要依赖参数规模的线性增长，计算时间的迭代同样可以发挥作用。下面记录这次实操中的几个关键点。

为什么传统 Chain-of-Thought 无法替代潜空间迭代？

对比测试显示，传统 LLM 即使开启 CoT，本质上仍然是在 Token 空间中进行单向预测。

处理复杂空间推理时，这种方式容易产生“幻觉”。每个 Token 的生成都受概率分布限制，只要中间步骤出现错误，后续推理就可能迅速崩塌。

循环潜空间推理采用另一种机制：模型不会直接预测下一个词，而是在输出答案前，于潜空间（Latent Space）中循环更新内部状态。这个过程不是继续生成 Token，而是在内部状态中反复精炼推理路径。

这样一来，模型无需增加参数量，只要增加迭代次数，就可以获得更深的推理能力。

如何构建循环潜空间推理机制？

要实现这种架构，需要打破 Attention(Q, K, V) 的单向流向。实现逻辑可以分为三个部分。

状态定义：定义一个潜空间向量 $z$，每轮迭代都更新这个向量，而不是让状态在 Token 序列中传递。

循环更新函数：构建更新函数 $z_{t+1} = f(z_t, x)$，其中 $x$ 表示输入任务。模型需要在潜空间中多次执行循环函数 $f$，不断深化对问题的理解。

循环更新函数的实现机制是什么？

解耦输出：当达到预设迭代次数，或者触发停止信号后，再将最终潜状态 $z_{final}$ 映射回 Token 空间，输出任务结果。

在端侧设备部署时会遇到哪些问题？

尝试把这类 150M 小规模模型迁移到嵌入式芯片或端侧设备时，我遇到了几个问题，也整理了对应的处理方式。

1. 显存碎片化导致的 OOM 报错

循环迭代过程中，如果中间状态没有得到正确清理，就可能触发：

RuntimeError: CUDA out of memory

在迭代循环中使用 with torch.no_grad():，并显式调用 torch.cuda.empty_cache()，可以避免这类显存问题。

1. 迭代次数与精度失衡

迭代次数并不是越多越好。

当迭代次数超过某个临界点后，潜空间状态可能发生数值不稳定，最终导致输出结果随机化。可以通过设置可学习的停止门控（Gating Mechanism），让模型动态决定何时结束迭代。

1. 版本依赖问题

如何通过图编译优化循环推理函数？

建议使用 PyTorch 2.0+ 版本，并用 torch.compile() 对循环推理函数进行图编译。

如果不做图编译，Python 层循环带来的开销，可能抵消 150M 小模型原本具备的推理速度优势。

实操结论与性能分析

潜空间计算机制优化对开发者的指导意义是什么？

这次分析得到的结论是：对于开发者来说，优化方向应该从增加参数规模，转向优化潜空间计算机制。

| 指标 | 传统 Transformer（大参数） | 循环潜空间模型（150M） |
|---|---|---|
| 推理成本 | 高，依赖高算力 GPU | 极低，0.0007 美元/次 |
| 逻辑处理方式 | Token 概率预测 | 潜空间状态迭代 |
| 端侧可行性 | 需量化或剪枝后勉强运行 | 原生支持低功耗芯片 |

如果这种机制能够扩展到 1B-3B 参数规模，端侧 AI 就有可能处理更复杂的空间推理和逻辑陷阱，而不再仅仅是一个能够流畅对话的模型。