Ripple-65B Preview 解讀：80.52 分之外，開放權重與本機部署要看什麼？（2026）

2026 年 11 月 4 日，Ricursive Intelligence 在 Hugging Face 公開了 〈Ripple-65B Preview〉模型卡與權重；提交紀錄顯示，這份指令模型的初始檢查點於當日上傳。Ripple-65B Preview 是約 650 億參數的稠密模型，開發者自報 Terminal-Bench 2.1 得分 80.52。值得追問的是：這張成績單，能替你的電腦與程式工作保證多少？

先說判斷：可下載的檢查點，讓外部評估有了具體對象；開發者自報的名次，仍須連同測試框架、數值精度與執行預算一起看。下面先整理原文的技術選擇，再拆開評測與容量，最後回到什麼情況值得試用。本文查閱的是 2026 年 11 月 5 日取得的公開資料，未在本機執行這份模型或重跑基準測試。

一、Ripple-65B Preview 的訴求：把模型與硬體一起設計

原文想展示的，並非單純把參數做小。Ricursive 在發布文章說明，它為晶片設計平台訓練模型，這次釋出的是其中的通用變體，希望讓模型設計與底層硬體互相改善。這是公司的研發方向；一份程式評測成績，尚不足以證明整個自我改進循環已經成立。

模型卡描述一條偏向簡化基礎設施的路線：選擇稠密 Transformer，再調整深度、注意力與訓練配方。公開的 config.json可核對到 80 層、hidden size 5120，以及混合局部與完整注意力的配置。白話說，它不是每次都從一大群專家中挑幾個，而是把主要參數集中在每次運算都會使用的模型裡。

訓練資料量與效果則屬開發者說明：模型以約 12 兆個、以英文與程式碼為主的 token 預訓練，後續經過長上下文訓練、監督式微調與強化學習，Preview 的後訓練偏重 agentic coding，也就是讓模型透過工具完成程式工作。這些描述支持「值得放進程式 Agent 候選名單」，還不能直接推出它特別適合繁中寫作或所有專業領域。

二、80.52 分怎麼讀？先把開發者成績與獨立驗證分開

模型卡把 Terminal-Bench 2.1 的 80.52 與幾個美國開放權重模型並列，摘要表四捨五入為 80.5。這些數字來自 Ricursive 彙整的各家自報與內部測試。本文保留的是「Ricursive 報告這個結果」；不把它改寫成已由外部統一認證的程式能力冠軍。截至本次查閱，本文取得的材料不足以獨立確認這個領先主張。

Therefore, our results represent a best-effort attempt at a fair comparison.

中文：因此，這些結果代表團隊盡力做出公平比較的嘗試。

Ricursive Intelligence，Ripple-65B Preview 模型卡

這句話前面有一個重要限定：作者發現，改用 Terminus 2、128K 長度與摘要設定時，多個比較模型的分數會改變。這不是枝微末節。測試框架會安排工具、處理長對話、決定何時重試；換了框架，模型面對的工作條件也變了。若你還不熟悉這層，可以先讀 AI Agent Harness 的說明。

外部可核對的是考試本身：Terminal-Bench 2.1 官方儲存庫描述的是容器環境中的複雜終端任務；2.1 也修改過 2.0 的部分任務、逾時或資源條件。因此，報告應綁定資料集版本＋模型版本＋Agent 框架＋預算。把 2.0、2.1 或其他版本的單一分數排在一起，容易把考題變動誤認成模型進步。

同一張 Ricursive 比較表也保留了它在其他程式與代理任務上落後的結果。這反而是有用的訊號：一項終端評測的優勢，不能替另一種程式維護、科學運算或工具協作背書。對使用者而言，最重要的問題是它能否完成自己的工作，而非某個國別範圍內的名次。

三、65B 對 501B：小的是整個模型，還是每次運算？

這裡最容易被標題帶走。Reflection 對 Beam 的官方介紹明確區分：Beam 是總參數 501B、每個 token 啟用約 23B 的 MoE。Ripple 則是 65B 稠密模型。總參數較少，和每次生成使用較少參數，是兩種比較。

可以把 MoE 想成一間有許多專家的公司，每件工作只叫部分專家上場；稠密模型則像固定班底共同處理。前者的完整名冊影響權重儲存，當次上場的人數影響部分運算量，但實際速度還受記憶體頻寬、資料搬移、批次大小與軟體實作影響。這個比喻用來區分兩本帳，不能拿人頭比例直接換算推論成本。

Ripple 的完整權重更集中，可能讓單機部署與維護更容易安排；但要說它每次回答一定比某個 MoE 便宜或快，仍要提供同硬體、同長度、同品質門檻下的量測。原文在資料中心 GPU 上報告的吞吐，也不應直接當成桌上型設備單人對話的速度。

四、Ripple-65B Preview 的本機門檻：NVFP4 權重約 57.2 GB

權重確實已放出。除了 BF16 指令模型，也有 NVFP4 檢查點，其頁首明確標為 Experimental。兩者提供不同的容量選擇；NVFP4 這個名稱，不表示整份模型的每個張量都是 4 位元。

using NVFP4 for the MLP layers while keeping attention in BF16.

中文：MLP 層使用 NVFP4，而注意力部分保留 BF16。

Ricursive Intelligence，NVFP4 模型卡（原句節錄）

這個混合精度細節，能由下載前就看得到的檔案索引交叉核對。BF16 的 索引 metadata.total_size為 129,565,378,720 bytes；NVFP4 的 同欄位為 57,213,636,640 bytes。換成十進位 GB，約為 129.6 GB 與 57.2 GB；換成二進位 GiB，約為 120.7 GiB 與 53.3 GiB。這是索引記載的張量大小，不是完整執行時記憶體需求。

所以，直接用「65B × 4 bits ÷ 8＝32.5 GB」替這個檢查點估容量會低估。執行時還要容納推論引擎、暫存與對話的 KV cache；上下文越長，容量問題越值得另外量測。NVIDIA 的 DGX Spark 硬體文件列出一款 128 GB 統一記憶體配置，但這個規格本身不保證某種精度、上下文與併發組合一定順跑。

模型卡宣稱支援最高 1M token 上下文；這應視為需要按設定驗證的能力範圍，不能與「在單台設備上下載、載入、維持可接受速度」合併成一個承諾。長度能接收多少、遠處資訊能找回多少，以及跑完要等多久，值得分開填成績。

五、開放權重帶來什麼？可以檢查，不等於所有研發都已重現

儲存庫的 LICENSE採 Apache 2.0。這讓使用、修改與再分發有明確的授權依據；實際散布仍要遵守授權文本中的條件。對模型評估更直接的意義是：別人可以固定同一份 checkpoint，重問同一批問題，檢查量化與工具呼叫是否改變結果。

發布文章還提出兩組效率主張：公司自報完整研發與訓練成本為 3,200 萬美元，並將其與估算的競爭者成本相比；另外，訓練配方在特定程式資料上的 compute efficiency 改善，來自它自己的模型階梯實驗。這些是值得追蹤的研究線索，並非同口徑成本審計，也不能把某一訓練指標的改善倍數當成使用者工作效率的倍數。

我會把這兩個問題分開：公開檢查點，讓「這個模型現在能做什麼」更容易被外部驗證；要證明「哪個訓練選擇造成進步、花了多少完整成本」，還需要可比的資料、實驗與成本邊界。權重開放提高了前一件事的可測試性，沒有自動替後一件事完成查核。

六、AlphaLab 的判讀：值得試，但要換一張自己的考卷

我同意：可下載的中型模型，是值得測試的工程選項

對能自行部署的團隊，模型版本、軟體與資料流向都可以納入自己的控制範圍。Ripple 提供了可檢查的權重、設定與推論程式，這比只讀一張發布榜單更有用。它的價值可以從一個小而完整的程式任務開始驗收：修改、執行測試、留下 diff，再檢查是否造成回歸。

我存疑：名次與參數比例，足以替實際成本做決定嗎？

還不夠。若同一工作要多試幾次、產生更長的推理或耗費更多人工修補，模型檔較小也可能抵銷不了這些成本；反過來，能穩定完成任務的較小部署，也可能比追求榜單名次更合用。我的選擇規則是：比較每個驗收成功任務所付出的時間、資源與人工，而不只比較每個 token 或總參數。

別把 BF16 成績直接貼到 NVFP4 部署上

模型卡的評測敘述以 BF16 為條件，NVFP4 則是另一次數值表示的改變。即使權重來自同一個模型，也值得把程式正確率、工具呼叫完整性與長對話表現再驗一次。這不是預設量化會失敗，而是避免拿另一個設定下的結果替它擔保。

七、下一步：留下五個欄位，再決定是否採用

如果你已有合適設備，先選三類可以獨立判定的工作：修一個有測試的 bug、替小型專案補測試、完成一次多步工具操作。使用專案副本與假資料，先限制可存取的檔案和網路；模型回覆成功之後，由既有測試與人工檢查共同驗收。把 AI 評測當成工作驗收，會比照抄發布成績更接近你的問題。

每次至少記五個欄位：模型 revision 與精度、框架與提示、上下文與重試預算、資源及耗時、驗收與人工修補結果。硬體還沒準備好，也可以先寫好考題與標準，不必為了驗證一張榜單就購買設備。最值得等待的新證據，是同一套條件下的公開執行紀錄，以及 BF16、NVFP4 與現有方案的可比結果。

Ripple-65B Preview 讓我們多了一份可以拿到手、固定版本去問問題的模型。接下來真正有用的進展，是它在你能驗收的工作上，能否持續交出更好的答案。