Ripple 65B自称美国开源编码最强，独立测试仅93分

一个模型宣称自己在美国开源权重模型里编码能力最强，第三方实测却只拿到157分里的93分。Ripple 65B Preview的发布，把开源编码模型的老问题又摆上了台面：榜单分数和真实开发工作流之间，到底隔着多少东西？

Ricursive Intelligence在发布公告中把Ripple 65B Preview定位为前沿开源权重系统，并声称它在Terminal-Bench 2.1和SWE-bench Pro v2.0 Hard两项评测上，取得了美国开源权重模型中最强的编码表现。这两个榜单测的不是聊天窗口里解释代码，而是模型在计算机环境中调用工具的能力，以及智能体能否处理代码仓库里的真实软件问题。

换句话说，成绩好看，只能说明模型"可能"能在开发流程里干活，不能直接等同于好用。接下来要追问的是可重复性、执行条件，以及拿到这个成绩付出了多少成本。

按Ricursive的公告，Ripple 65B是一个650亿参数的模型，采用Apache 2.0许可证发布。许可证在这里有战略意义：开发者可以检查、修改和部署模型，不必完全依赖某家公司的专有API。Hugging Face上的官方模型卡提供了权重，确认了许可证，并给出架构、训练信息、推理流程和部署指引，还附上了两项评测的成绩表。

但650亿参数的体量意味着实打实的显存和带宽需求。模型卡里有硬件指引，指引不等于保证每个开发者都能经济地跑起来。对一家公司来说，要算的不只是模型能不能装进内存，还有每小时能处理多少任务、延迟够不够低。一个要试好几次才给出正确补丁的模型，可能还不如一个稍弱但稳定快速的系统。

第一份外部证据是批评性的。在Nemo为SMF Works所做的一次独立测试中，测试者报告得分为93/157，并称许多失败与推理服务商超时和上下文长度上限有关。Nemo据此认为，这次测试没有复现Ricursive宣称的智能体编码领先地位。

这构成一个值得重视的质疑，但单凭它也不能证明Ricursive的榜单成绩是错的。请求被服务商截断，或者模型留不住足够的仓库上下文，失败可能反映的是部署环境，而不只是编码能力。反过来，这些限制也不能一句"无关"带过——开发者在真实部署里天天遇到它们。一个只有在上下文格外充裕、推理格外稳定时才表现良好的模型，优势会比标题数字窄得多。

另一路批评来自被标注为首席技术官的Dominic Plouffe。他在对Ripple本地硬件与成本要求的评估中认为，Ripple的稠密架构会让本地推理变慢，并指出那个亮眼的Terminal-Bench成绩目前仍是厂商说法，没有独立复现。

这里的逻辑很直接：大模型不只需要装下参数的内存，还需要足够的内存带宽把参数快速送过每一步生成。带宽不够，模型技术上能跑，但慢到没法用于交互式编码。于是"能拿到"和"能用好"之间出现分界——模型可以开源可下载，实际使用却集中在有专门硬件的资金充裕的团队手里。云服务商能降低门槛，代价是持续推理费用、服务商限额和可用性变化。

Apache 2.0许可证的价值仍然真实：组织可以避免被单一托管服务锁死，也能按自己的需求优化部署。但开放不消除基础设施经济学，它只是把更多责任转移给用户。

所以更有信息量的比较，应该看完成一个仓库任务的总成本，而不是每生成一个token的成本。便宜模型反复重试，可能比一次通过的贵模型更贵；快模型产出不可靠的补丁，可能比慢模型更耗工程师时间。

严肃的对比还应该把Ripple和领先开源模型放在相同条件下：同样的仓库、工具定义、上下文上限、时间预算和推理设置。工具使用要单独看，有的系统擅长判断何时查文件、跑测试、搜仓库，有的能写出像样的代码却收集不到做安全修改所需的信息。任务通过与否之外，还要记录失败类型——是误解了问题，改错了文件，耗尽了上下文，工具调用失败，还是没验证就停了。延迟要从用户视角记录，包括首次响应时间、工具调用间隔和拿到完整补丁的总时间。最后要测失败恢复：编码智能体很少一次成功，能自己发现测试失败、调整思路继续干的系统，才是更强的那个。

目前可用的证据是混合的。Ricursive的原始材料给出了强劲的编码与智能体评测成绩，并把模型开放给外部测试；两份独立说法则对可复现性、超时、上下文上限、速度和榜单说法本身提出了实际异议。在现有来源中，没有找到有利的独立评估，外部证据目前偏向批评一侧。

这不能给Ripple的前景下结论，它只定义了还需要做的工作。榜单领先只有在受控复现中活下来、并且在开发者面对普通约束时继续成立，才算数。若成立，Ripple可能成为市场上一个可信的宽松许可替代品；若不成立，这次发布也说明了一件事：开放权重扩大了获取渠道，但真实世界的编码领先，取决于整个部署系统，而不是一个分数。