本地部署 Ripple-65B 的兼容性与带宽门槛

Ripple-65B Preview 可以在本地跑，但还没到下载权重、交给 Ollama 就能用的阶段。原文梳理了 DGX Spark、GGUF 和 Mac MLX 三条路线，结论很明确：适配、量化和长上下文的成本，都得算进部署预算。

它吸引人的地方，是 Ricursive 宣称一个 65B 模型在 Terminal-Bench 2.1 上超过了 501B 的 Reflection Beam。但作者没有运行模型，只编译过 CPU 分支。下文的速度来自各适配项目，状态截至 2026 年 11 月 5 日，也就是预览版发布后一天。

65B 为什么未必比 501B 更省硬件

Ripple 是稠密模型，每生成一个 token，都要读取全部 65B 权重；Beam 虽有 501B 总参数，每次只激活 23B。参数总量决定存储压力，实际参与计算的参数则影响推理成本。

权重能装下，只解决了本地部署的一半问题。

Ripple 的 BF16 仓库有 16 个分片，共 129.6 GB。官方没有公布最低显存要求，仓库标有 custom_code，服务文档给出的配置是两张 B200 上运行 SGLang。对普通开发者，这个参考起点并不低。

量化可以降低容量要求，但不能直接继承 BF16 成绩。AtomicChat 在自己的语料上测得：AD-IQ2_XXS 与 BF16 选择相同最高概率 token 的比例为 80.8%，AD-Q4_K_M 为 95.9%。这个指标衡量输出分布的接近程度，不等于任务成功率。

prometheusAIR 的另一组测试里，llama.cpp 默认 IQ3_XXS 配方只有 70.7%，把注意力部分设为 IQ4_XS 的自定义配方达到 88.30%。两家测试语料不同，不能跨组排名，但足以提醒你：低比特量化不能只看文件大小。作者因此不建议把 24 GB 路线用于 Agent 工作。

三条运行路线，各自卡在哪里

DGX Spark 路线使用实验性 NVFP4 检查点：MLP 用 NVFP4，注意力保留 BF16。官方提供 notebook 和离线 spark.py，但脚本没有 HTTP 服务，需要社区套件包装成 OpenAI-compatible 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：它会把无认证服务暴露到局域网。

社区发布者报告代码生成约 26.5 tok/s，同时估计不用推测解码时只有约 5 tok/s。DFlash2 的收益对代码明显高于散文。把草稿 token 从 32 改成 16 后，代码从 23.2 提升到 24.5 tok/s，散文从 7.4 提升到 9.0 tok/s。

套件还开启了 spark.py 关闭的 radix cache。它复用已处理的提示词前缀，让 5.8K 提示词的下一轮首 token 等待从 10.2 秒降到 1.0 秒。这对反复携带仓库上下文的 Agent 很有意义。三个并发请求把总吞吐从 23.9 提高到 52.3 tok/s，但不能当成单请求速度。温度默认设为 0，因为检查点没提供采样默认值，发布者在 1.0 下观察到非英语回答失常。

GGUF 路线的障碍是加载支持。AtomicChat 明确说当时的原版 llama.cpp、LM Studio、Ollama 都不能加载，支持仍在开放的 PR #31692 中。Hugging Face 页面自动展示的 ollama run 提示不代表兼容。

下面是原文给出的分支构建与启动方式：

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：省略 -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

关键是获取 PR 分支，并使用它支持的文件。--jinja 用于文件中的聊天模板、工具调用和 <think> 推理格式，该分支已默认开启。

作者只在 Linux CPU 上编译了 6414d5b0c，没有加载权重，也没有验证 CUDA 或 Metal。mrfakename、prometheusAIR 则各自提供基于 6f1e654 的补丁；PR 中的张量叫 attn_vres_lambda，prometheusAIR 中叫 attn_value_res，不能假设文件可以互换。

Mac 的非官方 4-bit MLX 转换要求 mlx-lm>=0.32.2，启动使用 mlx_lm.server --model frogggias/Ripple-65B-Preview-MLX-4bit --trust-remote-code。它会运行约 280 行的自定义 ricursive.py，传参数前应先读代码。发布者仅用三个提示词对照 BF16 检查质量。

1M 上下文能装下，等待时间也得接受

Ripple 有 16 层全局注意力。按 MLX 卡片，16-bit KV cache 每 token 占 64 KiB；prometheusAIR 给出的 q8_0 缓存占用为每 token 34 KiB。KV cache 保存此前上下文的计算结果，长对话会持续扩大这笔开销。

Spark 的 spark.py 只接受 BF16 KV cache，且设置 --mem-fraction-static 0.78。约 65 GB 权重加 64 GiB 缓存，总计约 134 GB，128 GB 机器装不下。作者建议按 128K 规划；官方 1Mi 默认值属于双 B200 服务配置。

prometheusAIR 用自家补丁版 llama.cpp，把完整上下文放进了单张 96 GB RTX PRO 6000。命令采用 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。

代价是解码仅 6.7 tok/s。四个测试问题在各个深度都答对了，但样本很小；速度下降为何比缓存体积所能解释的更明显，发布者也没做性能剖析。

输入同样要等。M5 Ultra 的预填充速度为 535–565 tok/s，一份全新的 32K 提示词约需一分钟。官方列出的 250 tok/s 是否为整批吞吐也没说清；若是，折算每路约 31 tok/s。

领先 0.42 分，能证明什么

Ricursive 给出的 Terminal-Bench 2.1 成绩是 80.52，比 Beam 高 0.42 分。但 Beam 在两种 Terminal-Bench 测试配置之间相差 9.3 分，超过领先幅度的 20 倍。测试框架和执行配置，足以改变排名的解释。

其他项目也有输赢。SWE-bench Pro v2.0 Hard 是 Ripple 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 精度下取得。作者找到 16 个量化仓库，却没有找到任何量化版的 Terminal-Bench 成绩。NVFP4 卡片重复列出 80.52，也没有给出该检查点自己的成绩。

「U.S. open-weight SOTA」还有地域限定。HN 评论提到未进入榜单的 Qwen 3.8 Flash Next 有 84.3 分，但作者没有核实，不能据此下另一轮排名结论。

我的判断

我认可作者把兼容性、首 token 等待和量化质量放到跑分旁边。对编程 Agent，模型能否持续正确调用工具、长前缀能否复用，往往比短输出速度更影响使用体验。

不过，这仍是部署情报整理。Spark 上 Hermes Agent 用 1 分 36 秒、14 次工具调用修复小仓库的 4 个失败测试，距离稳定生产力结论还很远。各平台速度来自不同发布者，也不是统一条件下的横向测试。

BF16 榜单成绩，不能直接作为本地量化版的能力承诺。

和只激活部分权重的 MoE 相比，稠密 65B 确实让内存带宽更值得关注；但「每单位预算买最多带宽」仍是作者的采购判断，没有硬件成本对照。现在就为预览版换机器，证据还不够。

能拿来做什么

• 先通过官方列出的 Together AI、GMI Cloud、OpenRouter 或 Fireworks，运行自己的仓库修复任务。有人报告经 OpenRouter 访问 GMI Cloud 时遇到 131k 上限、8 次工具调用失败 4 次，这只是单个样本，应自行复测。
• 接入 Node 或其他 Agent 客户端时，记录任务完成率、工具参数正确率和真实上下文长度下的预填充时间。若用 SGLang 并设置 tool_choice: "required"，按官方文档检查 function.strict=true 与 additionalProperties: false，对应版本曾出现额外参数字段。
• 本地试用先按 128K 上下文规划，固定 GGUF 发布者和适配分支，再验证自己的任务。等任务质量与等待时间都可接受，再考虑更低比特或 1M 上下文。