如何在本地运行 Ripple-65B（Ollama 和原版 llama.cpp 都加载不了它）
现在你已经能在本地跑 Ripple-65B Preview，但没有一条路是开箱即用的。通过社区提供的一套服务端工具包，DGX Spark 在代码任务上大约能跑到 26 tok/s；GGUF 文件需要打过补丁的 llama.cpp，因为 Ollama 和原版构建目前还加载不了；MLX 版本则要加上 --trust-remote-code。
大家盯上它是有原因的：Ricursive 这个 Apache 2.0 模型号称在 Terminal-Bench 2.1 上拿到 80.52 分，比 501B 的 Reflection Beam 高 0.42 分。代价在于 Ripple 是稠密模型（dense）：每生成一个 token 都要读完全部 65B 权重，而 Beam 每次只激活 23B。于是显存反倒成了小事，真正掏钱的是带宽。
我没实际跑过这个模型。分数来自 Ricursive 官方，下面每个速度数字都由对应构建的发布者提供，仓库和 PR 状态截至 2026 年 11 月 5 日，也就是预览版上线后一天。
Ripple-65B 要吃多少显存，各条路线跑多快
BF16 仓库共 129.6 GB，分成 16 个分片。Ricursive 没给出最低显存要求，模型主页也没提到 llama.cpp、Ollama 或 MLX 这几条路。仓库打了 custom_code 标签。服务端 README 讲的是在两张 B200 上跑 SGLang——这显然不是大多数人说的「本地」。
| 路线 | 权重 | 建议内存 | 实测生成速度 |
|---|---|---|---|
| NVFP4 + DFlash2，DGX Spark | ~65 GB | 单块 GB10 | 代码 20–36 tok/s（平均 26.5），普通文本约 9 |
| MLX 4-bit | 37 GB | 64 GB+ Mac | M5 Ultra 256 GB 上 22.0–23.3 tok/s |
| GGUF AD-Q4_K_M | 40.4 GB | 48 GB | 该文件未公布 |
| GGUF 原版 Q4_K_M | 38.8 GB | 未列出 | 单张 GH200 96 GB 上 40.6 tok/s |
| GGUF Q6_K_XL | 52.76 GiB | 96 GB 显卡 | RTX PRO 6000 上短提示词 26.2 tok/s |
| GGUF IQ3_XXS（prometheusAIR） | 25.38 GiB | 32 GB 显卡，按此规格选型但未实测 | 同一张 96 GB 卡上短提示词 46.0 tok/s |
| GGUF AD-IQ2_XXS | 20.0 GB | 24 GB（RTX 3090/4090） | 未公布 |
| 官方 BF16 | 129.6 GB | 2× B200 | batch=8 时 250 tok/s（Ricursive） |
每个社区数字都来自一位发布者、一台机器。Spark 那位作者估计，不用投机解码（speculative decoding）时普通解码只有约 5 tok/s，也就是说 26.5 里的大部分是 DFlash2 挣来的，而它对代码的提升远大于普通文本。官方资料没说 250 tok/s 是不是整个 batch 的总和。如果是总和，那每条流大约 31 tok/s。想做智能体（agent）任务的话，24 GB 那条路线我会直接跳过。
AD-IQ2_XXS 在 AtomicChat 语料库上的最高概率 token 与 BF16 一致率为 80.8%，AD-Q4_K_M 则达到 95.9%。如果要自行量化低比特版本，需要手动设置注意力类型：prometheusAIR 实测发现，llama.cpp 默认的 IQ3_XXS 配方一致率仅 70.7%，而自家配方将注意力设为 IQ4_XS 后达到 88.30%。两家发布方使用的测试语料不同，因此只有同一语料下的数字才具可比性。
如何在 DGX Spark 上运行 Ripple-65B
Ricursive 发布了一个实验性 NVFP4 检查点，其中 MLP 采用 NVFP4，注意力部分保留 BF16，同时附带了 notebook 和离线脚本 spark.py。但该脚本没有 HTTP 服务器，agent 无法与之通信。社区套件为其封装了 OpenAI 兼容 API：
git clone https://huggingface.co/rlaope/Ripple-65B-Spark-Server && cd Ripple-65B-Spark-Server
运行 ./setup.sh，会装好固定版本的虚拟环境，并把约 65 GB 权重下载到 ~/ripple。首次启动 ~/ripple/ripple.sh 大约需要 11 分钟（要编译内核），之后每次约 2 分钟。
接着把客户端指向 http://127.0.0.1:30000/v1，模型名填 ripple。设置 RIPPLE_HOST=0.0.0.0 会把它暴露到局域网且不做鉴权，所以别随手设这个。
如果你打算自己搭一套，这套工具包里的改动值得借鉴。它把草稿 token（draft token）从 32 降到 16（代码吞吐 23.2 → 24.5 tok/s，普通文本 7.4 → 9.0），并启用了 spark.py 里默认关闭的基数缓存（radix cache）。在 5.8K 的提示上，这让下一轮的首 token 时间从 10.2 秒降到 1.0 秒。温度默认设为 0，因为检查点本身没带采样默认值；作者发现温度调到 1.0 时，非英语回答会崩坏。三个并发请求把总吞吐从 23.9 提升到 52.3 tok/s。卡片上还记录了一次智能体运行：Hermes Agent 在 1 分 36 秒内修好了一个小仓库里 4 个失败的测试，用了 14 次工具调用。单次运行不能说明太多，但它比一个 tok/s 数字更接近真实使用。
Ripple-65B GGUF：原版 llama.cpp 和 Ollama 加载不了
AtomicChat 的卡片说，原版 llama.cpp、LM Studio 和 Ollama 目前还加载不了这些文件；mrfakename 的卡片也说需要打过补丁的 llama.cpp。Hugging Face 上两个仓库页面仍显示一行 ollama run 的代码片段，目前先忽略它。相关支持在 PR #31692 里，尚未合并。
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git fetch origin pull/31692/head:ripple && git checkout ripple
cmake -B build -DGGML_CUDA = ON # Mac: omit -DGGML_CUDA=ON
cmake --build build -j --config Release --target llama-server llama-cli
hf download AtomicChat/Ripple-65B-Preview-GGUF Ripple-65B-Preview-AD-Q4_K_M.gguf --local-dir .
./build/bin/llama-server -m Ripple-65B-Preview-AD-Q4_K_M.gguf --jinja -c 32768 -ngl 99
对话模板、工具调用和 <think> 推理逻辑都写在模型文件里。AtomicChat 的模型卡之所以带上 --jinja，就是这个原因——不过在这个分支上，该参数本来就已经默认开启。
我在 Linux 上以纯 CPU 模式编译了 6414d5b0c 这个分支，llama-server 和 llama-cli 都编译通过，没有报错。但这只能说明编译成功：我没有试过 -DGGML_CUDA=ON，也没试过 Metal，更没有实际加载权重。
每个 GGUF 文件都要搭配它模型卡里写明的那份构建来用。AtomicChat 的文件配 PR 分支或它自己的补丁都能跑；mrfakename 和 prometheusAIR 则各自提供了针对 6f1e654 提交的独立补丁。这几种移植并不完全一样：PR 分支新增了一个名为 attn_vres_lambda 的张量，而 prometheusAIR 的补丁里叫 attn_value_res。我没有测试过拿一家的文件去配另一家的构建，也不敢假设这样能跑通。
Vulkan 用户建议去看看 PR 里的讨论：有人用 Strix Halo 试过但失败了，PR 作者怀疑是单个 KV 张量在 1-2M 上下文下有大小上限。
在 Mac 上用 MLX 运行 Ripple-65B
这个非官方的 4-bit 转换版本需要 mlx-lm 0.32.2 或更新版本，并且会运行一个自定义的 ricursive.py（约 280 行）。加参数之前先把这份脚本读一遍：
pip install "mlx-lm>=0.32.2"
mlx_lm.server --model frogggias/Ripple-65B-Preview-MLX-4bit --trust-remote-code
在 M5 Ultra 上，预填充（prefill）速度是 535-565 tok/s，所以处理一段全新的 32K 提示词大约要一分钟。发布者只用了三个提示词来对比 BF16 检查质量。
Ripple-65B 的 1M 上下文能在 96 GB 上跑，速度 6.7 tok/s
Ripple 的 16 层全局注意力会保留整个上下文。按 MLX 模型卡的数据，16-bit 下每个 token 的 KV 缓存占 64 KiB。这个数字和 AtomicChat 模型卡上的层数、头数对得上。prometheusAIR 那边给的是 q8_0 缓存、每 token 34 KiB。
我自己据此算了一笔账：
| 上下文 | 16-bit KV 缓存 | q8_0 KV 缓存 |
|---|---|---|
32,768（上面 -c 32768） |
2 GiB | ~1 GiB |
131,072（spark.py 默认值） |
8 GiB | ~4 GiB |
| 1,048,576 | 64 GiB | ~34 GiB |
在 Spark 上，用 spark.py 的默认设置是撑不下完整 1M 上下文的。
它只接受 BF16 的 KV cache，并固定使用 --mem-fraction-static 0.78。65 GB 权重加上 64 GiB 缓存，在 128 GB 机器上大约要占 134 GB。也就是说，在那台机器上要按 128K 的上下文来规划。1M 默认上下文只存在于官方的双 B200 服务器上。llama.cpp 可以量化 cache，prometheusAIR 正是靠这一点，用自己打的补丁版把完整上下文塞进了一张 96 GB 的 RTX PRO 6000：
llama-server -m Ripple-65B-Preview-Q6_K_XL.gguf -ngl 999 \
--ctx-size 1048576 -ctk q8_0 -ctv q8_0 -fa on -b 2048 -ub 1024 -np 1 --jinja
四个测试问题，在各种深度下它都答对了。这个测试规模很小，但看看速度：
| Prompt tokens | Prefill（整个 prompt） | Decode |
|---|---|---|
| 32,135 | 1,448 tok/s | 23.9 tok/s |
| 131,315 | 982 tok/s | 19.3 tok/s |
| 1,031,887 | 226 tok/s（76 分钟） | 6.7 tok/s |
发布者表示，decode 速度的下降幅度比 KV cache 体积所能解释的更陡，但还没有分析原因。我的建议是：把 1M 当成可以一次性、过夜跑满的东西；日常 agent 任务按 128K 来规划。
Ripple-65B 真的能打赢 501B 模型吗？
在 Terminal-Bench 2.1 上，按 Ricursive 自己给出的数字，能。但“65B vs 501B”只比了总参数量。下面是那张对比表，把激活参数也列了出来：
| 模型 | 总参数 | 激活参数 | TB 2.1（自报） | TB 2.1 Terminus 2 | SWE-bench Verified |
|---|---|---|---|---|---|
| Ripple-65B Preview | 65B | 65B | 80.5 | 80.5 | 76.5 |
| Reflection Beam | 501B | 23B | 80.1 | 70.8 | 81.6 |
| Muse Spark Open | 816B | 42B | 76.4 | 78.7 | 78.7 |
| Inkling | 975B | 41B | 63.8 | 56.2 | 77.6 |
| Nemotron 3 Ultra | 550B | 55B | 56.4 | 55.1 | 71.9 |
Ripple 的总参数最少，激活参数却最多。正因如此，HN 上的 stewartpark 认为它在消费级硬件上会“慢到没法用”。上面 Spark 和 M5 Ultra 的数字，就是对这一观点的第一次检验。目前来看，答案取决于你是在写代码还是在写文章。
测试框架的影响比领先幅度更大。Beam 在两行 Terminal-Bench 数据之间掉了 9.3 分，是 Ripple 0.42 分优势的 20 多倍。竞品的 Terminus 2 分数来自 Ricursive 内部跑的结果，卡片自己也承认 agentic 分数很难复现。其他基准则是喜忧参半。
Ripple 在 SWE-bench Pro v2.0 Hard 上拿下 79.1 分，Beam 是 76.5，DeepSWE 1.1 上则是 44.3 对 43.3；但 Beam 在 SWE-bench Verified 上更强，MCP Atlas 方面 Ripple 为 71.67，Beam 为 80.8，Muse 为 89.2。模型卡还写明所有模型都跑在完整 BF16 精度下，所以 80.52 这个数是 BF16 成绩。页面上列了 16 个量化仓库，但我在其中任何一个都没找到 Terminal-Bench 的测试结果。NVFP4 模型卡只是重复了 80.52，没有给出该检查点的独立得分。“美国开源权重 SOTA”这个头衔范围也很窄。HN 上有评论者提到 Qwen 3.8 Flash Next 拿到 84.3，这个模型并不在 Ricursive 的图表里。我没核实那个数字，但加“美国”这个地理限定词是有原因的。
买硬件之前，先在托管服务上试试 Ripple-65B
先自己跑一个 agent 任务。Ricursive 列出了 Together AI、GMI Cloud、OpenRouter 和 Fireworks。HN 用户 pcwelder 通过 OpenRouter 调用 GMI Cloud 端点时，遇到 131k 上下文限制，8 次工具调用中有 4 次失败。这只是一个数据点，建议你也复现一下。如果你用 SGLang 自托管，并且设置了 tool_choice: "required"，记得检查 schema。Ricursive 的服务器 README 说明，在其 SGLang 版本上，非严格模式的 required 调用会产生多余参数字段，文档要求设置 function.strict=true 和 additionalProperties: false。然后拿一个和你仓库上下文同等大小的 prompt 测一下 prefill 耗时，因为 agent 一天到晚都在反复发送长前缀。
一个 65B 模型能逼近 501B 模型的水平，这让我的采购清单从“内存最大”转向“每美元带宽最高”。但在找不到头条数字的独立复现、也没看到量化版本上跑过 Terminal-Bench 之前，我不会为一个预览版模型买硬件。一个稠密 65B 模型会改变你为本地推理采购的方案吗？还是你仍然会选那种每次推理只激活一小部分权重的 MoE 模型？如果你在自己的机器上跑过量化版，欢迎贴出硬件配置、tok/s 和上下文长度。
资料来源
- Ripple-65B Preview 发布公告
- Ripple-65B Preview 模型卡
- NVFP4 检查点
- DFlash2 草稿模型
- prometheusAIR GGUF 模型卡
- llama.cpp PR #31692
- Hacker News 讨论帖
现在就能在本地跑 Ripple-65B Preview，但不管走哪条路，用的都不是官方原版方案。借助社区提供的服务端工具包，DGX Spark 在代码任务上大约能跑到 26 tok/s；GGUF 文件得用打过补丁的 llama.cpp，因为 Ollama 和官方构建暂时还加载不了；MLX 版本则需要加 --trust-remote-code。大家想要它，是因为 Ricursive 这个 Apache 2.0 模型在 Terminal-Bench 2.1 上声称拿到 80.52 分，比 501B 的 Reflection Beam 高 0.42 分。问题在于 Ripple 是稠密模型：每生成一个 token，都要读一遍全部 65B 权重。