Ripple 65B 开放权重，主打终端任务能力

Ripple-65B Preview 想证明：开放权重的编程模型，不一定要把总参数堆到数千亿，才能做好终端里的复杂任务。这个从零预训练的 65B 稠密模型，在 Terminal-Bench 2.1 上拿到 80.52 分，超过了原文列出的多个大型 MoE 对手。

但它还不能被概括成「小模型全面逆袭」。这些成绩均为厂商自报，科学编程和其他软件工程测试也暴露了短板。对程序员更有价值的，是分清它擅长什么，以及部署门槛到底降到了哪里。

65B 为什么能赢，总参数又说明不了什么

Ripple-65B Preview 来自 Ricursive Intelligence，是其专有 AI 芯片设计模型的通用版本，重点面向智能体编程：模型需要在工具环境中执行操作、检查结果，再继续推进任务。

它采用稠密 Transformer，65B 参数全部参与计算。相比之下，MoE，也就是混合专家模型，每次只激活部分参数。原文中的 Beam、Muse Spark Open、Inkling 总参数分别为 501B、816B、975B，激活参数却只有 23B、42B、41B。Nemotron 3 Ultra 则采用 Hybrid Mamba-2 LatentMoE，总参数 550B，激活 55B。

总参数更少，不等于每次推理参与计算的参数也更少。

稠密架构的吸引力在于基础设施更简单。作者转述，Ricursive 使用简单分片，没有定制计算内核，也没有量化训练，维持了 40% MFU，即模型算力利用率。

具体结构是 80 层、d_model 为 5120，走「窄而深」的路线。团队从 Olmo 3 的类 Llama 布局，转向类似 Gemma 3N 的设计，通过更多注意力头、更多滑动窗口层和更小窗口平衡推理能力与开销，并加入门控注意力、全局 NoPE、value residuals，以及 gpt-oss 也使用的 FFN 激活裁剪。

这些选择来自逐级放大实验。比如，2-stream mHC 没能在 4B 规模保持收益，就被舍弃。技术材料声称，4B 阶段的代码计算效率提升了 16 倍；这是局部实验结果，不能直接当作最终模型的整体加速倍数。

80.5 分很强，但换个考场就有差距

Terminal-Bench 2.1 的结果最抢眼：Ripple 为 80.5，Beam 为 80.1，Muse Spark Open 为 76.4，Inkling 为 63.8，Nemotron 3 Ultra 为 56.4。原文据此称它是美国开放权重模型中自报成绩最高的模型，精确值为 80.52。

其他测试没有呈现同样整齐的优势。Ripple 在 SWE-bench Pro v2.0 Hard 上取得 79.1，是 Ricursive 表内最高分；但 SWE-bench Verified 为 76.5，低于 Beam 的 80.9 和 Inkling 的 77.6，高于 Nemotron 的 70.7。Meta 未披露该项成绩。

数学成绩也很突出：AIME 2025 为 98.3，HMMT Feb 2026 为 90.5。不过，SciCode 只有 39.4，在自家五模型对照表里垫底；DeepSWE 1.1 为 44.3，MCP Atlas 为 71.67。GPQA Diamond 为 85.2，也低于 Muse Spark Open 的 89.0、Inkling 的 87.2 和 Nemotron 的 87.0。

测试方式同样影响排序。Ricursive 使用 OpenCode 补跑缺失评测，在 SWE-bench Pro v2.0 Hard 和 DeepSWE 1.1 中使用 Terminus 2。另一次测试采用官方 Terminus 2 测试框架、将上下文设为 128K：Beam 降到 70.8，Muse Spark Open 升到 78.7，仍低于 Ripple 的 80.5。

这说明运行框架和上下文配置必须一起看。补跑部分测试提高了可比性，但全部成绩仍是厂商自报，不能视作独立第三方完成的统一评测。

训练更省，部署却还不是普通电脑的事

Ripple 使用 12T tokens 预训练，语料只有文本，以英文和代码为主，预训练序列长度为 8K。后训练依次包含中期训练、长上下文训练、SFT、长上下文 SFT 和混合 RL；长上下文阶段使用 2M 序列长度，最终标注支持最高 1M 上下文。两者分别是训练配置和对外能力规格，不能混用。

团队称没有购买后训练数据，而是自建合成数据流水线。RL 结合截断重要性采样、分数中心化和线性长度惩罚，以 1.4M 次 rollouts 达到 Terminal-Bench 2.1 的 80.5 分。相对 Beam 披露的超过 100M 次，Ricursive 给出的说法是约少 70 倍。

完整研发成本为 3200 万美元，包含梯度规模实验、数据混合、评测、合成数据及最终训练。所谓「前一位开放权重智能体编程领先者的十分之一」，也是团队估算，原文没有给出可审计的统一成本口径。

发布物包括指令微调 BF16、NVFP4 和 BF16 基座三个检查点，均采用 Apache 2.0。BF16 在 2 张 B200、batch 8 时达到 250 tok/s；这个吞吐数字不能直接理解成单用户生成速度。

实验性 NVFP4 版本量化 MLP 层，注意力仍保留 BF16，目标设备包括 NVIDIA DGX Spark，另列有 DFlash2 变体。因此，「支持本地」仍有明确的硬件前提。

权重已放在 Hugging Face。原文列出的上线渠道包括 Together AI、GMI Cloud、OpenRouter，Fireworks 将随后支持，但同时注明 Together AI 页面仍显示 coming soon。接入名单与已经可用，需要分开确认。

我的判断

我认可这次发布提供的一个方向：围绕智能体任务打磨数据、训练配方和执行环境，可能比单纯增加总参数更有效。对准备自托管的团队，稠密架构带来的基础设施简化也有实际吸引力。

但「全面替代更大的模型」缺乏支持。科学编程、软件工程和知识测试里的差距已经说明，它的强项有边界。与 MoE 相比，也应同时比较激活参数、显存占用和实际吞吐，不能只拿总参数做效率结论。

80.5 分足以让它进入候选名单，还不足以让团队跳过自己的任务评测。

研发成本和 rollout 数量也不能直接换算成能力效率。原文没有交代任务分布、单次执行长度及失败重试等完整口径，这部分应当作为团队披露的经验结果看待。

能拿来做什么

• 如果日常 AI 编程涉及终端操作，可以拿真实仓库中的安装依赖、执行构建、定位报错和修改代码任务做小规模对照，检查它能否完成整个流程。
• 比较模型时，固定工具权限、执行框架、上下文预算和重试规则，避免把环境差异误算成模型能力差异。
• 计划自托管时，先根据 BF16 与实验性 NVFP4 的硬件要求评估资源，再测单任务延迟；不要用 batch 8 的 250 tok/s 估算个人交互体验。
• 如果工作涉及科学计算或专业知识代码，单独设置验收任务，别让 Terminal-Bench 2.1 的领先成绩代替领域验证。