Ripple-65B 开源：Apache 2.0 的 65B 稠密模型
AI 芯片公司 Ricursive 开源 Ripple-65B Preview：65B 稠密 Transformer、12 万亿 token、Apache 2.0，官方称 TerminalBench 2.1 得 80.52 分。
2026-11-08 · Hugging Face 模型仓库 API（一手，2026-11-08 核对） / The Decoder（2026-11-06，二手汇总）
发布 2026-11-08核实 2026-11-08要点
- AI 芯片设计公司 Ricursive Intelligence 放出
Ripple-65B-Preview，权重在 Hugging Face 上，许可证apache-2.0、gated: false、31 个文件（2026-11-08 实读 API）。 - 架构反潮流：65B 稠密（dense）Transformer，不是 MoE。官方称预训练语料 12 万亿 token，并针对 Nvidia 硬件优化。
- 官方自述 TerminalBench 2.1 得 80.52，称是「开源美系模型最高分」；harness 为 Terminus 2 与 OpenCode 混用。
- 同表另三项落后同期开源的 Inkling 2 Small：SWE-Bench Pro v2.0 Hard 79.1% vs 86.3%、DeepSWE v1.1 44.3% vs 72.1%、MCP Atlas 71.67% vs 85.4 / 85.0。
- 成本口径：Ricursive 称开发与训练总支出 3200 万美元（含全部研发），属公司自述。
- 仓库周边：同组织另有
Ripple-65B-Base-Preview（2026-10-14 建）、Ripple-65B-Preview-NVFP4、Ripple-65B-Preview-DFlash2（均 11-04 建），说明发布前已备好量化与推理加速分支。 - 仓库热度（2026-11-08 实读）：3,803 次下载 / 365 likes，创建于
2026-11-04T02:41:21Z，最后更新2026-11-06T19:26:32Z。
一个反潮流的架构选择
2026 年的开源模型主流是 MoE——用总参数量换激活参数量，把「大模型」塞进「小显存」。Ricursive 反过来做：65B 稠密，全部参数每次推理都要算。
这个选择的代价与收益都很直接：
| MoE（主流） | 稠密 65B（Ripple） | |
|---|---|---|
| 显存需求 | 看总参数，可 offload | 看全量 65B，量化后才现实 |
| 单请求算力 | 只激活一部分 | 每次全量前向 |
| 部署复杂度 | 专家路由、并行策略更复杂 | 结构简单，单机多卡即可 |
| 微调 | 专家分布敏感 | 全参数微调路径清楚 |
官方的说法是「更容易部署到用户自有硬件」。这在「一台 8 卡机器」的规模上成立，在「一张消费卡」的规模上不成立——65B 稠密就算 NVFP4 量化，也不是单卡能舒服跑的量级。同组织提前备了 NVFP4 分支，恰好说明他们自己也知道纯 BF16 的部署门槛有多高。
基准数字要连同 harness 一起读
官方给的 TerminalBench 2.1 = 80.52，是这次传播中最容易被单独拎出来的数字。读它需要三个限定：
- 版本是 2.1，不是 4.0。 本站 Terminal-Bench 百科 里记录的是 4.0 世代的口径，两者不可横比。
- harness 混用：部分任务用 Terminus 2，部分用 OpenCode。harness 直接决定 Agent 能在终端里做多少事，同一模型换 harness 差十几个点是常态。
- 同一张表里它并不是全面领先：SWE-Bench Pro v2.0 Hard 落后 7.2 点、DeepSWE v1.1 落后 27.8 点、MCP Atlas 落后约 14 点。「开源美系最高分」限定在 TerminalBench 2.1 这一项上。
对比对象 Inkling 2 Small 的权重仓库，本站用三种常见命名（thinkingmachines/Inkling-2-Small、Inkling2-Small、Inkling-2-Small-Preview）打 detail 端点均为 404。因此本文不把 Inkling 2 Small 当作「已开源可下载」陈述，只记录 Ricursive 表格里的对比数字。
3200 万美元这个数字怎么读
Ricursive 称「总开发与训练成本 3200 万美元，覆盖全部研发支出」。这是公司自述，且口径模糊——「全部研发」是否含人力、数据采购、失败实验，没有拆解。把它当「训练一个 65B 稠密模型的最低门槛」会严重低估：真正可比的是「一次成功预训练的边际成本」，而失败重跑通常才是大头。
值得记录的是趋势：2026 年出现了一批「几千万美元训练出接近前沿的开源模型」的案例，这削弱了「只有大厂能做前沿模型」的叙事，但没有削弱「只有大厂能反复做前沿模型」——一次成功和持续迭代是两件事。
对使用者的实际影响
- 想在自己的机器上跑 Agent 的团队：Apache 2.0 + 稠密架构，是少见的「许可干净、结构简单」组合。先看 NVFP4 分支的实际显存占用，再决定要不要上。
- 做 coding agent 的：TerminalBench 2.1 的分数说明它在终端任务上有竞争力，但 DeepSWE v1.1 的 44.3% 说明跨文件、多步重构这类活它明显弱。别用单一基准决定替换。
- 国内部署：
hf-mirror.com可读元数据，权重下载是否通畅本轮未实测——这条留作待核实。
AI 之家 观点
一、这次最值得记的不是 80.52，是「一家做芯片设计的公司训了个模型」。 Ricursive 的主业是 AI 芯片设计，训模型对它更像是验证自家硬件客户的真实负载——顺带把成果开源。当「训一个 65B 模型」变成某个行业公司的副产物，说明训练能力的稀缺性正在快速下降。 这对做应用层的团队是好消息：模型会越来越像水电，不是护城河。
二、稠密 65B 是个诚实但不讨巧的选择。 MoE 的流行有一半原因是营销——「总参数 600B」听起来比「稠密 65B」强。Ricursive 选了更难讲故事、但工程上更可控的路径。对自托管团队来说，「结构简单」的价值远高于「参数好看」：一个不需要专家并行、不需要特殊路由的模型，运维成本差一个量级。
三、基准表要按「同一张表内部」读，不要按「最高分」读。 这张表最有信息量的地方不是 80.52，而是它在 TerminalBench 上赢、在 DeepSWE 上输近 28 个点。这说明它是「终端操作型」选手，不是「大型重构型」选手。选模型时先问自己的任务像哪一类，比看总分有用得多。
四、给评估者的三条动作：① 先读 custom_code 里的推理代码再决定是否上生产（Apache 2.0 不等于代码无风险）；② 用自家任务集跑一遍，不要拿 TerminalBench 2.1 的数字代替；③ NVFP4 分支与 BF16 的分数差异要单独测——量化对 Agent 任务的伤害通常比对话任务大。
待核实
config.json的实际层数 / 隐藏维度，以及 65B 是否含 embedding 的精确口径——本文未读配置文件。- 12 万亿 token 的语料构成与截止日期，官方未列。
- TerminalBench 2.1 上 80.52 的复现配置（Terminus 2 与 OpenCode 各自承担哪些任务）。
- 3200 万美元的成本拆解口径（是否含人力与失败重跑）。
- Inkling 2 Small 的权重是否另行发布（本轮三种命名 detail 端点均 404，不等于不存在）。
- 国内镜像下载完整权重的可用性。
相关阅读
来源
常见问题
Ripple-65B Preview 能商用吗？
权重仓库的许可证字段是 apache-2.0（Hugging Face API 实读），没有 gated 限制，31 个文件可直接拉取。Apache 2.0 意味着可商用、可改、可再分发，但要注意仓库里有 custom_code 标签，即推理需要加载自定义代码，部署前需自行审查这段代码。
TerminalBench 2.1 的 80.52 和本站百科里 TB4.0 的数字能比吗？
不能。这是两个不同版本的基准，而且这次官方说明了 harness 是 Terminus 2 与 OpenCode 混用。版本、harness、快照三处任一不同，数字就不可横比。
为什么说它是「开源美系最高分」要打折？
这是厂商自述（Ricursive 自己的口径），本站只核到权重仓库存在、许可与文件数，未复现基准。同一张对比表里它在 SWE-Bench Pro v2.0 Hard 上落后 Inkling 2 Small 7.2 个点、DeepSWE v1.1 上落后 27.8 个点。