推文

@fireandstart · 2026-10-17 00:45

RLT 让我感兴趣的，不只是“把 Transformer 循环起来”，而是它把读取输入与更新状态拆成了两个明确阶段：因果编码器先并行整理已知上下文，循环解码器再把当前输出和上一时刻的运行状态结合，逐 token 推进。这个分工让模型有机会把计算深度沿序列延展，而不必简单地给每个 token 堆更多层。 帖中几个外推任务也很有启发：训练最多 40 位的奇偶校验能扩到 256 位，交换跟踪和模运算也有明显提升。不过我会把这些看作机制有效的证据，而不是直接等同于真实语言任务能力。更长的依赖能否稳定保留、状态更新带来的延迟和显存成本如何，以及不同任务为何偏好不同的编码器/解码器层数比例，都值得结合论文设置继续看。 尤其“读取”和“更新”的预算可能与总深度同样重要：若只报告总参数或层数，容易看不出收益究竟来自更好的状态表示，还是计算分配方式变化。后续若有语言建模、长上下文检索和推理任务上的消融，以及吞吐、延迟与基线在同等算力下的比较，这个架构的适用边界会更清楚。

曝光 21 · 评论 0 · 点赞 0 · 书签 0