一张生成的标题卡,标题为“Ripple-65B Preview”,副标题为“Ricursive Intelligence——一个 65B 稠密模型,开放权重,但有一个关键问题”,日期为 2026年11月4日,卡片下方有四张统计卡片:65B 稠密 Transformer,80 层;129.6 GB 的 Apache 2.0 权重,分为 16 个分片;Terminal-Bench 2.1 上得分 80.5,标注为厂商报告;首个托管 API 提供 16,384 个 token 的上下文。
Guides & Insights

Ripple-65B Preview:Apache 2.0 权重、100 万 Token 宣称与 16K API

作者

Elias Hawthorne

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

Ripple-65B Preview,由 Ricursive Intelligence 于 2026 年 11 月 4 日发布;取决于你通过何种方式接触它,它其实是两个不同的产品。下载内容是 129.6 GB 的 Apache 2.0 权重,其模型卡宣称上下文“最高 1M”个 token。首个搭载同一检查点的商业端点宣称 16,384。这两个数字描述的是同一个模型,而它们之间的差距,是开发者在为这个发布投入一天时间之前最值得知道的事情。

该实验室的头条结论比发布博文所听起来的范围更窄,也比迄今为止的报道所注意到的更有意思。Ricursive 声称,在一个 65B 的稠密模型上取得了美国开放权重模型在智能体编程方面的最先进水平——在 Terminal-Bench 2.1 上得分 80.52——据报道其训练成本为 3200 万美元。这是一项关于真实产物的真实声明:权重可下载、无需审批,且无需协商协议即可获得商业使用许可。但截至 11 月 5 日,这也完全是由厂商报告的。Artificial Analysis 尚未收录该模型。

实际登陆 Hugging Face 的到底是什么?

四个代码仓库于11月4日上线,这些区别很重要,因为它们会改变你所需的硬件:

• Ripple-65B Preview — BF16 指令微调检查点,16 个 safetensors 分片,总计 129.57 GB,Apache 2.0,无需门控。

• Ripple-65B Preview NVFP4—— 一个实验性的 4 位构建,大小为 57.22 GB,分为 6 个分片,对 MLP 层进行量化,同时注意力部分保持 BF16。

• Ripple-65B Base Preview——仅预训练检查点,无中期训练,无合成问答数据,同样为 129.57 GB。

• Ripple-65B Preview DFlash2 — 一个用于投机解码的 8.08 GB 草稿模型,具有 4.04B 参数,针对目标模型按 16 个 token 为块进行起草。

The Hugging Face Files and versions listing for ricursiveAI/Ripple-65B-Preview, showing a 130 GB repository size, the Apache-2.0 licence tag and the custom_code tag, and sixteen safetensors shards named model-00001-of-00016 through model-00016-of-00016 with individual sizes between 8.3 GB and 8.42 GB.

这套架构是一次刻意的复古。在这个规模上,其他所有实验室都已转向专家混合(mixture-of-experts),而 Ricursive 却构建了一个稠密 Transformer,又薄又深:d_model 5120、80 层、80 个注意力头共享 8 个键值头、100,352 个 token 的词表,以及在混合层模式中应用的 1,024 token 滑动窗口。FFN 激活裁剪、门控注意力、全局 NoPE 和价值残差,则补齐了团队从 Olmo 3 基线逐级攀升过程中所采纳的种种改动。

训练技术栈公布的细节比大多数模型卡都要多:8K 序列长度下 12T token 的预训练、64K 下 200B token 的中期训练、2M 下 6.5B token 的长上下文扩展、128K 下 183B token 的 SFT,以及 128K 下 700 步 RL。开发期间团队从 1 人增加到 5 人,并报告称在未使用自定义内核的情况下达到 40% MFU。

有一点命名上的提醒,因为搜索结果已经把它搞混了:Ricursive Intelligence 是一家芯片设计实验室,其发布文章描述了硬件、软件和模型的协同优化。它不是 Flint 背后的自我改进型 AI 初创公司 Recursive。这两家公司互不相关,将它们混为一谈的报道是错误的。

基准测试主张,以及它能传播多远

Terminal-Bench 2.1 是决定这次发布成败的关键,而分数是 80.52。Ricursive 让它领先于 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——这些模型的总参数量都比它大七到十五倍。

让那张表比寻常厂商表格更有价值的是第二列。Ricursive 在官方 Terminus 2 测试框架下,于 128K 上下文并启用摘要的情况下重新进行了比较,并报告称分数几乎在所有模型上都发生了变化,唯独它自己的没有:Ripple 保持在 80.5,Muse Spark 升至 78.7,Reflection Beam 从 80.1 降至 70.8,Inkling 从 63.8 降至 56.2,Nemotron 从 56.4 降至 55.1。一家实验室发布了一个测试框架,而自家得分持平、竞争对手得分大幅下滑,这做了大多数发布文章都会回避的事。这仍然是一家在给自己的作业打分的实验室——那张表里的每个数字都由 Ricursive 的评估流程产生——但变化的方向是对的。

一旦离开终端,这一说法就不再成立。在 DeepSWE 1.1 上,Ripple 得分为 44.3,而 Muse Spark 为 60.0。在 MCP Atlas 上,Ripple 为 71.67,落后于 Muse Spark 的 89.2 和 Inkling 的 76.0。在 SciCode 上,Ripple 以 39.4 在五者中垫底,落后于 Beam 的 49.2 和 Muse Spark 的 58.5。模式是一致的:Ripple 在长周期终端任务和多步骤软件任务上很强,在科学代码生成和工具协议广度方面表现平平。如果你的工作负载是一个在 shell 中逐项操作的智能体,那么这个说法就是针对你的。如果它是一个重度依赖 MCP 的助手,那就不是。

而这种表述方式在悄悄地发挥作用。“美国开放权重的最先进水平”是一个限定语,而不是可以略过不看的前缀。它把 DeepSeek、Qwen 以及其他所有非美国实验室排除在外,因此它所指的只是在美国境内训练出的最佳开放权重模型,而不是最佳开放权重模型。

A generated single-model scoreboard titled 'Ripple-65B Preview — the scoreboard' with six rows: Terminal-Bench 2.1 at 80.5 marked vendor, SWE-bench Pro v2.0 Hard at 79.1 marked vendor, DeepSWE 1.1 at 44.3 marked vendor, licence and size Apache 2.0 and 129.6 GB BF16, context 1M claimed against 16,384 served, and price $0.20 in and $0.60 out per million tokens, with a footer reading that Ricursive's figures are unaudited and there are no independent scores yet.

基础模型是更诚实的文档

Base Preview 卡片中包含一句发布帖并未首先提及的话:预训练检查点“在推理、数学和代码方面与 DeepSeek V3.1 和 V4 Flash 相当”,而 Nemotron 3 Ultra “在传统预训练评测中占据主导”。数字印证了这种低调。Base MMLU-Pro 为 61.5,而 DeepSeek V4 Flash 284B 为 68.3,Nemotron 3 Ultra 550B 为 79.1。Base GPQA Diamond 为 38.4,远低于 V4 Flash 的 44.4。

把这两张表放在一起看,故事就更清晰了。Ripple 的预训练先验说得过去,但在一个 12T token 的训练中只算中游——这是它自己对比组里最小的预训练预算,而 Nemotron 是 20T,V4 Flash 是 32T 以上。几乎全部 agentic 编程优势都来自后训练栈:中训练数据配比、长上下文扩展,以及 Ricursive 称在 140 万次 rollout 中达到 80.5 的 700 步 RL,所需 rollout 大约比 Reflection Beam 少 70 倍。这个结果比基准表更有意思,也更脆弱——在合成长期环境中进行大规模 RL 爬坡,恰恰是那种会不均匀迁移到实验室未针对训练的任务上的配方。

A cropped view of Ricursive's launch post showing the reinforcement-learning section, headlined 'Steep Ascent Reinforcement Learning', with a Terminal-Bench 2.1 Pass@1 chart where Ripple-65B Preview's four points sit between 72 and 80.5 at under 2M RL rollouts while the Reflection Beam curve climbs from about 53 at 2M to about 78 at 80M.

为什么上下文编号是两个数字

模型卡上写的是 1M。配置里写的是 max_position_embeddings 2,097,152。托管端点写的是 16,384,外加 14,745 个 token 的输出上限。没有人说谎;这是三件不同的事,而算一算就能明白第一个托管方为什么选了它选的那个数字。

KV 缓存是长上下文需要付出代价的地方。在 80 层、8 个 KV 头、头维度为 128 且使用 BF16 存储的情况下,每层每个 token 的缓存开销为 4,096 字节——其中键占 2,048,值占 2,048。跨全部 80 层,每个 token 大约为 0.33 MB。在该端点的 16,384 个 token 下,大约是 5.4 GB。在一百万 token、每一层都执行全局注意力的情况下,大约会有 344 GB 的缓存叠加在 130 GB 的权重之上。

这就是滑动窗口的用途。Ripple 的大多数层在 1,024 个 token 的窗口内进行注意力计算;少数层进行全局注意力,并且只有这些层会随上下文增长。如果 80 层中有 16 层是全局层,那么一百万个 token 的缓存开销约为 69 GB,而不是 344 GB——虽然很大,但可以在多 GPU 节点上提供服务。精确的划分由 config.json 中的混合层模式设定,无论你使用哪种服务栈,这都是首先要检查的事情,因为决定你内存开销的是这个划分,而不是宣传中的数字。

因此,请把这两个数字当作两个事实。100 万 token 是一种存在于权重中的架构能力,需要相当强的节点才能提供服务。1.6 万是首个商业端点所提供的能力——足以应对大多数智能体循环,但不足以进行仓库级推理或长文档工作。如果你尝试 Ripple-65B Preview 的原因是 100 万上下文,那么托管路线今天并不能为你提供它,自托管是唯一能做到的路径。

Local 指的是 57 GB,而不是 130

发布帖称,该模型“能装进 NVIDIA DGX Spark 这类消费级硬件”,而媒体报道将其固化成“能在 MacBook 上运行”。下载体积能说明每条说法对应的是哪个产物。

• BF16 instruct 检查点为 129.57 GB。仅其本身,在尚未计入任何 KV 缓存或运行时开销之前,就需要一台 192 GB 级别的加速器,或采用多 GPU 拆分。

• NVFP4 构建版本为 57.22 GB。这能装进一台 128 GB 统一内存的机器,并为工作上下文留出空间——而且它被标记为实验性,注意力仍保留在 BF16。

• DFlash2 草稿模型增加 8.08 GB,换来的是推测解码,而非质量提升。

250 tok/s 这个数字是数据中心的数据:2×B200、batch 8,且尚未采用量化和自定义内核。在 Spark 上,你是在用吞吐量换取这台机器就在你桌面上这一事实。两个数字都没错;它们只是属于不同的机器,而本地方案只有在使用量化检查点时才成立。

通话费用是多少

第一个托管端点标价为每百万输入 token 0.20 美元、每百万输出 token 0.60 美元,缓存输入读取为 0.05 美元。按一次真实的 agent 调用计算——16,000 token 的提示词对满窗口,返回 2,000 token——输入为 0.0032 美元,输出为 0.0012 美元,合计约 0.0044 美元。如果每天通过它处理 1000 万 token,按 80/20 的输入输出拆分,就是 2.80 美元。

缓存是最值得动用的杠杆。一段重复出现的 16,000 token 系统提示,按缓存价格计费只需 $0.0008,而不是 $0.0032,输入侧成本直降 4 倍——对于一个每轮都要重复发送同一批工具定义的智能体来说,这几乎就是账单的大头。

{{1}}OrcaRouter 的定位:我们目前不提供 Ripple-65B Preview,因此没有可比较的加价,也没有理由假装不是这样。{{/1}} 预览版真正改变的是:在你评估一个未经证实的模型时,有理由让它远离生产路径。通过一个密钥路由你的流量已经依赖的现有模型——200+ 模型、供应商列表价按 0% 加价透传、供应商不稳定时自动故障转移——并将 Ripple 与之并列放在离线评估中,而不是放在用户面前。如果数据站得住脚,路由 DSL 无需二次集成就能转移一部分流量;如果不成立,回退方案从来都不是问题。

谁应该尝试它,以及什么会改变局面

现在就可以试试:如果你正在构建终端或 shell 智能体,你会想要一个无需律师介入就能微调的 Apache 2.0 检查点,而且 16K 窗口对你的循环来说已经足够。稠密架构对任何在普通硬件上提供服务的人来说都是真正的优势——没有专家路由,没有全对全通信,延迟可预测——而一个 65B 稠密模型在 Terminal-Bench 上达到 80.5,这个结果值得在你自己的任务上复现,而不是争论。

如果ſ你需要从托管端点获取长上下文,如果你的工作大量涉及 MCP 或科学代码,或者如果你需要任何并非由训练该模型的实验室产出的数字,那就再等等。目前还没有独立评测:Artificial Analysis 上没有收录条目,也没有第三方复现 80.52 这一结果。对于一个才发布一天的 Preview 版本来说,这属于正常现象,而非可疑之处——但这也意味着,本文中每一个来自 Ricursive 的数字都被标注为其自报数据,是有原因的。

有三件事能定论。第二套由未参与模型训练的人运行的评测框架。一个能服务超过 16,384 个 token 的宿主,这会告诉我们 1M 上下文的主张在与调度器接触后是否仍成立。还有一个非预览版检查点,因为 Ricursive 已明确表示,这里的后训练很轻量,而其芯片设计平台背后的内部变体才是它真正在打造的产品。在此之前,头条仍然只是一个主张,下载是真实的——而两者之间的差距,正是接下来一个月评估将展开的地方。

本文中的对比1

根据本文内容识别 · 基准测试:Artificial Analysis · 每日更新