65B 稠密模型 TerminalBench 拿 80.52 分，压过一票 500B 级对手

摘要：Ricursive Intelligence 发布首个模型 Ripple-65B Preview：65B 参数稠密 Transformer、12 万亿 token 预训练、百万 token 上下文，Agent 编码基准得分超过多个 500B~900B 级开源权重模型，Apache 2.0 协议。

在开源模型普遍转向 MoE 的当下，一家叫 Ricursive Intelligence 的小团队反着来：他们从零预训练了一个 65B 参数的稠密 Transformer——Ripple-65B Preview，然后在 Agent 编码基准 TerminalBench 2.1 上拿了 80.52 分。这个分数超过了 Reflection Beam 501B（80.1）、Meta Muse Spark Open 816B（76.4）、Thinking Machines Inkling 975B（63.8）和 NVIDIA Nemotron 3 Ultra 550B（56.4）——清一色参数量是它 8 到 15 倍的对手。

规格上，Ripple-65B 在 12 万亿 token 的语料（以英文和代码为主）上预训练，上下文最长支持 1Mi（1,048,576）token。团队从 Olmo 3 基线出发逐项改进训练配方：代码上的算力效率（CE）相对 Olmo 3 训练阶梯提升 16 倍，完整 hero run 达到 55 倍。本次 Preview 释出包含指令微调版（BF16 与 NVFP4 两种精度）和 BF16 基座模型，发布仓库是 BF16 指令版，协议为 Apache 2.0。

选稠密而不是 MoE 是一个明确的工程决策。团队的目标是降低预训练和后训练的基础设施复杂度，同时保住推理与 agentic 性能——结果是开发团队从 1 人扩到 5 人就完成了从零预训练，整个过程保持 40% 的 MFU，用简单分片、没有自定义 kernel、也没有做量化（纯 BF16）。对比之下，MoE 路线虽然能靠稀疏激活摊薄推理成本，但要额外处理专家路由、负载均衡和跨卡通信，对小团队来说每一步都是隐性成本。

架构走”瘦而深”路线：d_model 只有 5120，但堆了 80 层。注意力方案从 Olmo 3 的 llama-like 换成 Gemma 3N 风格以改善大规模训练稳定性；为了推理性能，他们过量配置注意力头的数量，同时提高 SWA 与全局注意力层的比例、缩小 SWA 窗口来对冲成本。此外还用上了 FFN 激活裁剪、gated attention、全局 NoPE 和 value residuals 这几项改进。这些都不是新发明，难的是把它们在同一套配方里调到不互相拖后腿——从结果看，16 倍到 55 倍的算力效率提升就是这份调参的回报。

对个人用户最实际的信息是部署成本：65B 的稠密模型塞得进 NVIDIA DGX Spark 这类消费级设备，官方还准备了 NVFP4 checkpoint 和 Colab 方便本地起步；放到数据中心卡上，2 张 B200、batch=8 的配置下能跑到 250 tok/s——这还是没有任何量化或自定义 kernel 优化的裸速。

“更少的参数、更窄的路、更简单的基建”，Ripple-65B 给出的是一个反规模叙事的样本：当对手们用 10 倍参数堆能力时，把训练配方和架构每一项都磨到位，65B 也能在 Agent 编码上正面赢。它同时抛出一个值得讨论的问题：在 Agent 这类”动作正确率比知识广度更关键”的任务上，参数规模的天花板究竟在哪里。

模型地址：https://huggingface.co/ricursiveAI/Ripple-65B-Preview