最近在研究开源社区和前沿研究型团队的代码实现时注意到 Sakana AI 发布了一个名为Continuous Thought Machine的项目。标题中“Source-Level Review”这个说法很吸引我——它意味着不是停留在产品介绍层面而是直接进入代码结构、训练过程、模型推理方式层面去审视。这篇文章就围绕这个主题展开我会先讲清楚这个项目试图解决的底层问题然后梳理源代码层面的设计链路再结合一个可运行的简化版实现复盘关键代码最后给出源码审查时容易踩的坑和工程建议。如果你是关注前沿模型架构的算法工程师、想要理解“连续思维”和离散 token 生成差异的研究者或者准备在自己的项目中尝试类似递归状态机制的开发者这篇文章都比较适合。1. 背景与核心概念1.1 Sakana AI 与 Continuous Thought MachineSakana AI 是一家总部位于东京的人工智能研究公司由 David Ha 和 Llion Jones 等人联合创立。它最被关注的方向之一是把一些自然界和经典机器学习中的机制重新引入现代深度学习架构中例如群体智能、自然语言压缩、进化算法辅助模型设计等。而Continuous Thought Machine连续思维机器是其中一种比较有代表性的思路。从项目名称来看它强调的是“continuous thought”也就是把模型的思考过程理解为一个连续的时间状态而不是离散的一次性前向计算。与当前主流大语言模型不同主流 LLM 的工作方式可以概括为输入一段 token 序列。通过 Transformer 层进行一次性并行计算。预测下一个 token 的概率分布。把新 token 拼接回输入继续下一次推理。这种模式在扩展性和并行性上非常优秀但也有一个明显的结构特点模型内部状态是“离散的”每次计算时都依赖注意机制重新读取全部历史信息。Continuous Thought Machine 想要探索的路线则是是否可以让模型内部始终保持一个随时间演化的连续状态向量并让这个状态向量直接参与每一步的推理这里要明确一点“连续”不是指浮点数精度这种层面而是指模型思考状态的建模方式。它更多是在时序维度上做文章让隐藏状态在时间轴上连续变化而不是在每一层之间突然跳跃。1.2 为什么“连续思维”值得关注从传统循环神经网络RNN到 LSTM、GRU再到 Transformer序列建模走过了一条从“逐步递推”到“并行注意力”的路线。RNN 系列模型天然有时间连续性但并行性差难以扩展到超长序列Transformer 系列模型并行性强但注意力计算量随序列长度平方增长且长期记忆能力依赖缓存。连续思维机器试图回到“状态随时间变化”这一经典思想但用现代训练手段来解决之前 RNN 难以大规模训练的问题。这种方向的价值主要体现在以下几方面。第一推理成本更可控。如果模型每一步都只依赖一个固定维度的状态向量而不需要反复读取越来越长的历史 token那么推理开销不会随着上下文长度线性增长理论上可以处理超长上下文。第二更接近“思考”本身的直觉。人在思考一个复杂问题时大脑不是每说一个字就重新翻一遍全部记忆而是维持一个连续变化的思维状态同时根据新信息增量更新。Continuous Thought Machine 这个名字明显是受这种认知过程启发。第三为可解释性提供新的切入点。连续状态向量如果变得足够平滑、有结构那么研究者可以通过分析状态空间轨迹来理解模型在“想什么”这比分析离散注意力权重更直观。1.3 容易混淆的概念在阅读这个项目之前有几个概念需要提前区分。一是Continuous Thought Machine和MoE混合专家。MoE 是通过路由机制选择不同的专家子网络本质仍然是离散选择连续思维机器强调的是状态本身的平滑演化两者关注点不同。二是状态空间模型SSM和连续思维机器。像 Mamba、RWKV 这类模型已经引入了状态空间思想把序列建模变成一个可并行扫描的线性递归过程。Continuous Thought Machine 与之有相似之处但它的重点可能是“思考”这个内部认知过程而不是仅仅追求高效的序列压缩。它可能加入更多非线性、更复杂的门控甚至引入类似元学习的机制。三是连续值输出与连续思维。很多模型输出的是连续值向量但内部状态仍然是对历史 token 的缓存式记忆。连续思维机器强调的是“状态本身就是推理的载体”而不是把历史 token 压缩成 key-value 缓存。2. 源码级审查前需要建立的认知框架2.1 从哪些层次阅读源代码对于一个深度学习项目所谓的“Source-Level Review”不应该只盯着模型文件而是需要拆成多个层次来理解。目录结构层面我们需要知道项目包含哪些模块是训练框架还是推理框架是完整复现还是研究原型。依赖配置层面可以判断项目用了哪些底层库例如 PyTorch、JAX、Triton、CUDA 扩展等。模型定义层面需要理解网络结构、初始化方式、前向传播逻辑。训练循环层面要关注损失函数、优化器、学习率调度、梯度累积、混合精度等。数据管道层面要关注数据格式、采样方式、批处理逻辑。评估与导出层面需要看项目如何验证模型效果以及如何导出权重。每一层都可能隐藏关键问题。比如模型定义很新潮但训练循环里没有梯度裁剪在递归网络中这就是灾难再比如数据管道里隐藏标记了特殊 token导致词表设计和推理代码不一致。2.2 审查 Continuous Thought Machine 时的技术背景要理解 Continuous Thought Machine 的源码最好是先了解三类技术的演进第一类是经典循环网络。LSTM 和 GRU 是理解“门控状态更新”的最佳起点。Continuous Thought Machine 无论实现多复杂核心大概率仍然是一个“旧状态 新输入 - 新状态”的更新函数。第二类是线性注意力与状态空间模型。Mamba 的 select scan 机制、RWKV 的 time-mixing 块都是把一个巨大的注意力矩阵转换成有限维状态的压缩过程。Continuous Thought Machine 如果要在源码中实现“不随序列增长的状态”必然需要类似的状态压缩策略。第三类是 Neural ODE 或连续时间模型。Continuous Thought Machine 的“continuous”如果体现在时间维度上就可能涉及微分方程求解器、自适应步长、欧拉法离散等实现细节。这部分源码阅读起来会比普通 RNN 困难一些。2.3 审查前的环境准备建议在阅读源码前准备一个干净的 Python 环境避免依赖冲突干扰你复现实验。下面是一个基础环境建议版本需要根据代码仓库里的requirements.txt或pyproject.toml调整这里重点演示配置思路。# 建议使用 Python 3.10 或 3.11 python -m venv ~/venvs/ctm-review source ~/venvs/ctm-review/bin/activate # 先安装核心深度学习框架以 PyTorch 为例 pip install torch torchvision torchaudio # 如果仓库涉及 jax 版本则需要单独安装 # pip install jax jaxlib # 安装基础工具库 pip install numpy pandas tqdm tensorboard matplotlib在实际审查时我会先跑通仓库自带的单元测试或最小示例确认代码能正常运行然后再进入逐模块分析而不是一上来就啃最难的文件。3. Continuous Thought Machine 的设计链路拆解由于该项目的具体源码细节可能处于持续迭代中这里我基于公开资料和同类结构的通用经验对源码中最可能出现的设计组件做一个框架性拆解。后续你也可以根据实际仓库代码对照验证。3.1 总体计算链路从外部行为看Continuous Thought Machine 的任务仍然是序列建模所以输入输出层不会太复杂。重点在于内部状态更新模块。一个典型的设计链路如下输入 token 经过嵌入层变成向量x_t。状态向量h_{t-1}从上一个时间步传入。将x_t和h_{t-1}通过一个更新函数得到新的状态h_t。使用h_t计算输出分布预测下一个 token。将h_t作为下一步的初始状态继续循环。这个链路在宏观上与 RNN 一致但内部的更新函数会比经典 RNN 复杂很多。源码中通常对应三个核心模块输入投影模块、状态更新模块、输出投影模块。3.2 状态表示与更新函数状态向量是最关键的设计决策。如果状态维度太小模型容量受限如果状态维度太大推理效率优势又会被抵消。源码中常见的设计是把状态拆成多个通道例如记忆通道、工作通道、门控通道甚至把状态切分成多个并行的 block每个 block 负责不同时间尺度的记忆。更新函数是最值得逐行阅读的部分。它可能包含以下运算# 伪代码用于说明状态更新的通用结构 import torch import torch.nn as nn import torch.nn.functional as F class ContinuousStateCell(nn.Module): 一个简化的连续状态更新单元。 这里仅演示核心设计并非 Sakana AI 官方源码。 def __init__(self, input_dim, hidden_dim, num_blocks4): super().__init__() self.hidden_dim hidden_dim self.num_blocks num_blocks # 输入投影 self.input_proj nn.Linear(input_dim, hidden_dim) # 状态内部的多块混合 self.block_proj nn.ModuleList([ nn.Linear(hidden_dim, hidden_dim, biasFalse) for _ in range(num_blocks) ]) # 门控生成 self.gate_proj nn.Linear(hidden_dim input_dim, hidden_dim * 3) def forward(self, x_t, h_prev): # x_t: [batch, input_dim] # h_prev: [batch, hidden_dim] # 输入注入 x_proj self.input_proj(x_t) # 块级状态交互 block_output 0 for idx, proj in enumerate(self.block_proj): block_output block_output proj(h_prev) # 拼接后生成门控 gate_input torch.cat([block_output, x_proj], dim-1) gates self.gate_proj(gate_input) forget_gate, input_gate, output_gate torch.chunk(gates, 3, dim-1) forget_gate torch.sigmoid(forget_gate) input_gate torch.sigmoid(input_gate) output_gate torch.tanh(output_gate) # 状态更新 h_new forget_gate * h_prev input_gate * torch.tanh(block_output x_proj) h_out output_gate * h_new return h_out, h_new这里需要重点阅读几个地方门控是否使用 sigmoid是否会出现梯度饱和。forget gate 是否存在初始化偏置。经典的 LSTM 会把 forget gate bias 初始化为正数避免初始状态下记忆快速丢失。状态之间是简单加法混合还是通过线性变换混合。简单加法参数少但表达能力受限线性变换参数多但容易过拟合。是否存在 normalization。递归网络中 LayerNorm 的位置非常敏感放到状态更新前还是更新后对训练稳定性影响很大。3.3 训练目标与损失设计在源码审查中训练目标往往能透露项目真正想优化的方向。如果 Continuous Thought Machine 只是做标准语言建模那么损失函数大概率是交叉熵。但如果项目想强调“连续思维”源码中可能出现以下扩展状态平滑正则。让相邻时间步的状态向量差异不要过大从而保证“连续性”。预测多步损失。不仅预测下一个 token还要求状态经过若干步后能预测未来更远的内容。对比学习或重构损失。让状态向量不仅仅是 token 预测的副产品而是真正能编码上下文的语义信息。辅助解码器。在训练时从中间状态重建部分历史信息帮助状态保留更完整的记忆。# 伪代码带连续正则的训练损失 def compute_loss(model, batch, lambda_smooth0.1): x, y batch logits, states model(x, return_statesTrue) ce_loss F.cross_entropy(logits, y) # 连续正则相邻状态差的 L2 范数 smooth_loss 0 for t in range(len(states) - 1): smooth_loss smooth_loss F.mse_loss(states[t], states[t 1]) smooth_loss smooth_loss / (len(states) - 1) total_loss ce_loss lambda_smooth * smooth_loss return total_loss这种设计会让状态变化更平缓但也要注意过强的平滑正则可能导致状态无法及时响应新信息因为模型没有动力去大幅更新状态。源码中如果存在这类正则通常需要配合一个动态权重或自适应机制。3.4 并行化与扫描机制循环结构天然是串行的为了在 GPU 上高效训练源码中很可能引入类似扫描scan的并行化手段。PyTorch 的torch.compile可能对循环进行优化JAX 则有jax.lax.scan来处理这种时序依赖计算。在阅读源码时如果看到while循环或者for循环遍历序列长度要思考它是否真的在时间维度串行。有些实现会采用分块扫描把一个长序列分成多个块块内使用并行注意力块间使用递归状态传递兼顾并行性和长程记忆。这种“块内并行、块间递归”的结构是源码阅读中容易困惑的地方。如果你的本地 GPU 显存有限直接复现时经常会遇到“显存不足”或“训练速度极慢”的问题这不一定是你代码写错了而可能是源码本身的设计就面向特定规模的硬件。3.5 记忆持久化与衰减机制连续思维机器要处理长序列就必须解决状态被新信息覆盖的问题。源码中可能出现以下几种记忆机制一是指数衰减门控。类似 forget gate 的逐步衰减让旧信息随时间自然遗忘。这实现简单但无法处理需要长期保留的精确信息。二是记忆写入与检索分离。状态向量分为长期记忆部分和短期工作记忆部分。长期记忆通过稀疏写入更新短期记忆则反应当前上下文。这种设计类似传统计算机的寄存器与主存配合。三是混合时间尺度。通过多个并行的递归通道每个通道有不同的衰减率。一个通道以 0.99 的 forget 率保留长期信息另一个以 0.5 的 forget 率关注短期输入。这样模型可以通过叠加不同时间尺度的状态来逼近复杂的时间依赖。源码中的num_blocks或num_scales参数往往就是对应这个设计。审查时建议着重看不同 block 之间是否有交互如果完全没有交互那它们本质上只是多个独立的 RNN 并联表达能力会受限如果存在交互则需要关注交互是否会导致训练不稳定。4. 复现一个简化版 Continuous Thought 实验为了更贴近“Source-Level Review”的训练我在这里构建一个简化但可运行的完整示例。它包含一个连续状态模型、一个简单的训练循环和一个验证函数整体代码不多但能帮你理解递归状态网络在语言建模中的核心结构。再次强调这是我根据通用设计思路编写的教学版本不是 Sakana AI 的官方实现。4.1 项目结构ctm_demo/ ├── data.py # 构造一个小型字符数据集 ├── model.py # 连续状态模型定义 ├── train.py # 训练脚本 ├── config.yaml # 配置文件 └── checkpoint/4.2 数据准备# 文件路径ctm_demo/data.py import torch from torch.utils.data import Dataset class CharDataset(Dataset): 一个小型字符级语言建模数据集。 为了让示例更快跑通这里只使用一段简单的英文文本。 def __init__(self, text, seq_len64): chars sorted(list(set(text))) self.chars chars self.vocab_size len(chars) self.char_to_idx {ch: i for i, ch in enumerate(chars)} self.idx_to_char {i: ch for i, ch in enumerate(chars)} self.seq_len seq_len self.tokens [self.char_to_idx[ch] for ch in text] def __len__(self): return max(0, len(self.tokens) - self.seq_len) def __getitem__(self, idx): x self.tokens[idx: idx self.seq_len] y self.tokens[idx 1: idx self.seq_len 1] return torch.tensor(x, dtypetorch.long), torch.tensor(y, dtypetorch.long)4.3 模型实现# 文件路径ctm_demo/model.py import torch import torch.nn as nn import torch.nn.functional as F class ContinuousThoughtLayer(nn.Module): 连续思想层。 它维护一个隐状态并通过门控更新机制完成状态演化。 这个实现比 LSTM 更灵活状态可以拆分为多个 block 每个 block 对输入做不同的非线性变换。 def __init__(self, input_dim, hidden_dim, num_blocks4): super().__init__() self.input_dim input_dim self.hidden_dim hidden_dim self.num_blocks num_blocks self.input_proj nn.Linear(input_dim, hidden_dim) # 每个 block 的投影 self.block_proj nn.ModuleList([ nn.Sequential( nn.Linear(hidden_dim, hidden_dim), nn.LayerNorm(hidden_dim) ) for _ in range(num_blocks) ]) # 门控 self.gate_net nn.Linear(hidden_dim * 2, hidden_dim * 3) # 输出投影 self.out_proj nn.Linear(hidden_dim, input_dim) def forward(self, x_t, h_prev): # x_t: [batch, input_dim] # h_prev: [batch, hidden_dim] x_proj torch.tanh(self.input_proj(x_t)) block_out 0 for proj in self.block_proj: block_out block_out proj(h_prev) gate_input torch.cat([x_proj, block_out], dim-1) f, i, o torch.chunk(self.gate_net(gate_input), 3, dim-1) f torch.sigmoid(f) i torch.sigmoid(i) o torch.tanh(o) candidate torch.tanh(x_proj block_out) h_new f * h_prev i * candidate h_out o * h_new return h_out, h_new class ContinuousThoughtModel(nn.Module): def __init__(self, vocab_size, embed_dim128, hidden_dim128, num_layers2, num_blocks4): super().__init__() self.embedding nn.Embedding(vocab_size, embed_dim) self.layers nn.ModuleList([ ContinuousThoughtLayer(embed_dim, hidden_dim, num_blocks) for _ in range(num_layers) ]) self.head nn.Linear(hidden_dim, vocab_size) def forward(self, input_ids, stateNone): batch_size input_ids.size(0) seq_len input_ids.size(1) if state is None: state [None] * len(self.layers) all_logits [] for t in range(seq_len): x_t self.embedding(input_ids[:, t]) for layer_idx, layer in enumerate(self.layers): if state[layer_idx] is None: h torch.zeros(batch_size, layer.hidden_dim, deviceinput_ids.device) else: h state[layer_idx] x_t, h_new layer(x_t, h) state[layer_idx] h_new logits self.head(x_t) all_logits.append(logits) all_logits torch.stack(all_logits, dim1) return all_logits, state4.4 训练脚本# 文件路径ctm_demo/train.py import torch import torch.nn.functional as F from torch.utils.data import DataLoader from data import CharDataset from model import ContinuousThoughtModel # 示例文本 text ( The continuous thought machine keeps a hidden state that changes over time. Instead of rereading every token, it updates its state step by step. This approach may lead to more efficient long sequence modeling. ) # 超参数 SEQ_LEN 32 BATCH_SIZE 4 EPOCHS 50 LR 1e-3 dataset CharDataset(text, seq_lenSEQ_LEN) loader DataLoader(dataset, batch_sizeBATCH_SIZE, shuffleTrue) model ContinuousThoughtModel( vocab_sizedataset.vocab_size, embed_dim64, hidden_dim64, num_layers2, num_blocks4, ) optimizer torch.optim.AdamW(model.parameters(), lrLR) for epoch in range(EPOCHS): total_loss 0.0 for x, y in loader: optimizer.zero_grad() logits, _ model(x) loss F.cross_entropy( logits.reshape(-1, dataset.vocab_size), y.reshape(-1), ) # 状态连续性正则 # 这里简单起见没有计算状态差因为返回的 state 是最后一个时间步。 # 完整版应该在模型内部收集所有中间状态。 loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() total_loss loss.item() print(fEpoch {epoch 1}/{EPOCHS}, Loss: {total_loss / max(len(loader), 1):.4f}) torch.save(model.state_dict(), checkpoint/ctm_demo.pt)4.5 运行与验证运行命令cd ctm_demo python train.py预期输出大致为Epoch 1/50, Loss: 3.8912 Epoch 2/50, Loss: 3.4720 ... Epoch 50/50, Loss: 1.0510由于是小数据集损失值可能波动但整体应该呈下降趋势。如果损失完全不变优先检查学习率是否过大、门控初始化是否合理、数据是否太短导致模型无法有效学习。4.6 生成验证# 文件路径ctm_demo/generate.py import torch from data import CharDataset from model import ContinuousThoughtModel def generate(model, dataset, prompt, steps100): model.eval() chars [dataset.char_to_idx[ch] for ch in prompt if ch in dataset.char_to_idx] if not chars: chars [dataset.char_to_idx[dataset.chars[0]]] input_ids torch.tensor([chars], dtypetorch.long) state None output list(prompt) with torch.no_grad(): for _ in range(steps): logits, state model(input_ids[:, -1:], state) prob torch.softmax(logits[:, -1, :], dim-1) next_id torch.multinomial(prob, 1).item() output.append(dataset.idx_to_char[next_id]) input_ids torch.tensor([[next_id]], dtypetorch.long) return .join(output) if __name__ __main__: dataset CharDataset(text, seq_len32) model ContinuousThoughtModel( vocab_sizedataset.vocab_size, embed_dim64, hidden_dim64, num_layers2, ) model.load_state_dict(torch.load(checkpoint/ctm_demo.pt)) print(generate(model, dataset, promptThe continuous))这一步能帮你验证状态是否真正记住了上下文。如果生成结果只是重复最后几个字符说明状态记忆能力不足需要增大 hidden_dim 或增加 block 数量。5. 源码审查的关键检查点5.1 数值稳定性递归网络最常见的问题是训练过程中出现 NaN 或梯度爆炸。源码审查时注意检查以下几点是否存在梯度裁剪。状态更新是否存在 tanh 或 sigmoid 饱和区。LayerNorm 的位置是否可能导致梯度不一致。混合精度训练是否需要额外的 loss scaling。是否对初始状态做了特殊处理例如用全零初始化还是可学习初始化。如果源码中没有梯度裁剪在大规模训练时基本无法稳定收敛。经典 LSTM 实践中梯度裁剪几乎是标配。5.2 显存与计算效率连续思维模型在推理时状态维度固定这是它的优势。但训练时如果使用torch.compile或 JAX 的jit需要额外关注编译时间与显存占用。源码中可能出现以下优化使用 checkpoint 技术减少中间激活存储。使用半精度计算。使用 Triton 手写 kernel 加速状态更新。使用分块扫描减少串行依赖。在评估效率时不要只看参数量还要关注有效计算量。两个参数相同的模型一个使用高效扫描一个使用朴素循环推理速度可能相差数倍。5.3 泛化能力与测试方式源码审查不能只看训练集表现。好的代码仓库会包含独立验证集和测试集并且有明确的划分逻辑。对于连续思维模型还需要关注以下几点是否测试了比训练序列更长的序列。是否测试了不同分布的数据。是否检查了状态向量的行为例如是否存在状态崩溃。是否有多步预测的评估脚本。如果代码只提供训练脚本没有评估脚本那么在复现论文结论时需要额外小心因为你无法确认模型是否真的达到了论文效果。5.4 可解释性与可视化连续状态向量的一个重要优势是便于可视化。源码中如果包含以下模块说明作者有意识地把可解释性纳入设计状态向量的 PCA 降维可视化。不同时间步状态向量的相似度矩阵。梯度归因分析。注意力权重的替代分析。这些工具虽然是辅助性的但在研究型项目中往往比模型本身更能反映质量。6. 常见问题与排查思路问题现象常见原因解决思路训练 Loss 不下降学习率设置过大或过小先尝试 1e-3 到 3e-4 之间的学习率配合 warmup状态输出出现 NaN梯度爆炸或状态饱和增加梯度裁剪检查门控激活函数是否饱和模型无法记住长时间信息状态维度太小或遗忘门初始值不合理增大 hidden_dim调整 forget gate 初始化多卡训练时显存溢出状态更新无法并行改用分块扫描或减少 batch size推理速度反而比 Transformer 慢时间维度完全串行检查是否使用了 CUDA 图或 torch.compile 优化状态可视化没有结构状态未被有效约束增加辅助损失或调整状态连续正则权重加载预训练权重后效果差词表、嵌入维度不匹配检查模型超参数是否一致不要只看权重文件大小使用混合精度时 Loss 震荡FP16 精度不足改用 bfloat16或启用 loss scaling排查清单先跑通最小示例确认数据管道没有问题。用较小的模型和较短序列复现排除显存和算力瓶颈。查看训练曲线是 Loss 不降、震荡还是突然变 NaN判断问题方向。单独检查一次前向传播确认输出 shape 和值域是否正确。单独检查一次反向传播确认梯度不为零且没有 NaN。检查状态向量在几个 step 内的变化幅度如果变化过大说明状态不稳定。如果复现失败优先检查依赖版本和硬件兼容性再检查代码本身。7. 最佳实践与工程建议7.1 从经典实现借鉴门控初始化对于递归模型的源码审查建议多对照 LSTM 与 Mamba 的初始化策略。比如 forget gate bias 可以设置为 1 或 2让模型初始状态下更倾向于保留信息而不是快速遗忘。检查源码时如果作者没有写特殊的 bias 初始化可以考虑修改后对比实验。7.2 保留清晰的实验配置管理递归模型对超参数非常敏感建议使用 YAML 或 dataclass 管理所有实验参数包括 hidden_dim、num_blocks、learning rate、batch size、梯度裁剪阈值、混合精度等。每次实验记录完整的配置快照避免复现时只知道“改了某几个参数”。# 文件路径ctm_demo/config.yaml model: vocab_size: 65 embed_dim: 64 hidden_dim: 64 num_layers: 2 num_blocks: 4 train: lr: 0.001 batch_size: 4 seq_len: 32 epochs: 50 grad_clip: 1.0 amp: false7.3 给状态向量建立监控指标连续思维模型的最大风险是状态退化。建议在训练过程中加入以下监控状态向量的平均范数随层和时间的变化。相邻时间步状态向量的余弦相似度。forget gate 的统计值是否长期为 0 或 1。每个 block 输出的方差。这些监控可以帮助你更早发现问题而不是等到生成效果变差才动手排查。7.4 重视长序列评估如果你的目标是用连续状态模型处理超长上下文评估时一定要包含长度外推测试。也就是说用短序列训练再用长序列测试。如果模型在长序列上表现骤降说明状态更新机制没有学会稳定的长期记忆。7.5 对比实验要公平很多研究型项目开源时对比基线不全面。你自己复现时建议统一 tokenizer、统一训练步数、统一硬件环境再和 Transformer 基线做对比。否则你得到的“连续思维模型不如 Transformer”的结论可能只是超参数没调好造成的假象。8. 总结与下一步学习方向这次围绕Continuous Thought Machine的源码级分析我们做完了下面几件事梳理了“连续思维”与“离散 token 生成”之间的差异。拆解了源码审查时应该关注的模块状态表示、更新函数、训练目标、并行扫描、记忆持久化。给出了一个可运行的简化实现演示了连续状态语言建模的基本流程。总结了递归模型训练时的常见问题和排查思路。如果你希望进一步深入建议按下面的路径继续学习先完整跑通本文的简化代码然后逐步增加训练数据量和模型规模观察 Loss 变化。阅读 Mamba 的论文和源码理解 selective scan 是如何取代注意力矩阵的。阅读 RWKV 的 time-mixing 模块对比它与经典 RNN 门控机制的异同。尝试在你的项目中加入状态正则损失设计自己的“连续思维”变体。如果条件允许可以在小规模 TPU 或多卡 GPU 环境上测试分块扫描的效率提升。在实际工程中最需要警惕的风险是连续状态模型虽然推理时很高效但训练时的显存和调试成本并不比 Transformer 低。它更适合的场景是超长上下文、边缘设备推理、在线学习等需要固定推理开销的场合而不是所有场景都能直接替代 Transformer。如果本文对你有帮助可以收藏备用。接下来我也会继续关注 Sakana AI 及相关开源社区的新进展有新的源码实现再和大家一起拆解。