Ripple-65B 預覽：Apache 2.0 權重、100 萬 Token 的宣稱，以及 16K API

Ripple-65B Preview由 Ricursive Intelligence 於 2026 年 11 月 4 日發布，取決於你如何存取它，它會是兩種不同的產品。下載內容是 129.6 GB 的 Apache 2.0 權重，其模型卡宣稱上下文「最高可達 1M」個 token。第一個搭載相同檢查點的商業端點則宣稱 16,384。這兩個數字描述的是同一個模型，而它們之間的差距，是開發者在為此投入一天時間之前，關於這次發布所能知道最有用的一件事。

這間實驗室的標題，比發布貼文所暗示的來得狹窄，卻也比迄今的報導所注意到的更有意思。Ricursive 聲稱在代理式編碼（agentic coding）上達到美國開放權重（open-weight）的最先進水準——在 Terminal-Bench 2.1 上取得 80.52 分——而這個成績來自一個 65B 的稠密模型，據報導訓練成本為 3,200 萬美元。這是關於一項真實產物的真實宣稱：權重可下載、無需申請審核，且無須另行協商協議即可取得商業使用授權。然而，截至 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 個權杖的區塊。

這套架構是刻意的復古設計。在這個規模上，其他每一間實驗室都已轉向混合專家模型，Ricursive 卻打造了一個稠密 Transformer，窄而深：d_model 5120、80 層、80 個注意力頭共享 8 個鍵值頭、100,352 個 token 的詞彙表，以及套用於混合層模式的 1,024 個 token 滑動視窗。FFN 激活裁剪、閘控注意力、全域 NoPE 與值殘差，完善了團隊從 Olmo 3 基準逐步擴展時所採用的修改。

這套訓練技術堆疊的公開細節，比大多數模型卡所願意揭露的還多：預訓練使用 12T tokens、序列長度 8K；中期訓練使用 200B tokens、64K；長上下文擴充使用 6.5B tokens、2M；SFT 使用 183B tokens、128K；以及 128K 下的 700 步 RL。開發期間團隊從一人增加到五人，並回報在沒有自訂 kernel 的情況下達到 40% MFU。

一個命名上的提醒，因為搜尋結果已經把它們搞混了：Ricursive Intelligence是那家晶片設計實驗室，其發布文章描述了硬體、軟體與模型的協同最佳化。它不是 Recursive，那家打造 Flint 的自我改進 AI 新創公司。這兩家公司彼此無關，將它們混為一談的報導是錯誤的。

基準主張，以及它能傳播多遠

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 在 128K、啟用摘要功能的官方 Terminus 2 測試框架下重新執行比較，並回報幾乎所有分數都出現變動，唯獨它自己的沒變：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 以及所有其他非美國實驗室，所以這是在主張美國境內訓練出的最佳開放權重模型，而不是最佳開放權重模型。

基礎模型是更誠實的文件。

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+。代理式程式設計的優勢幾乎全都來自後訓練堆疊：中期訓練的資料混合、長上下文擴展，以及 700 步 RL——Ricursive 稱其在 140 萬次 rollout 中達到 80.5，所需 rollout 數約比 Reflection Beam 少 70 倍。這比基準測試表更有意思，也更脆弱——在合成的長時程環境上進行大量 RL 爬坡，正是那種會不均勻遷移到實驗室未針對訓練的任務上的配方。

為什麼上下文編號是兩個數字

模型卡上寫的是 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，且每一層都進行全域注意力，那麼在 130 GB 的權重之上，還會有約 344 GB 的快取。

這就是滑動視窗的用途。Ripple 大多數層只在 1,024 個權杖的視窗內進行注意力計算；少數層進行全域注意力，而只有這些層會隨上下文成長。如果 80 層中有 16 層是全域層，一百萬個權杖的快取成本約為 69 GB，而不是 344 GB——雖然很大，但可在多 GPU 節點上提供服務。確切的分割方式由 config.json 中的混合層模式設定，而這是你使用任何 serving stack 時首先要檢查的事，因為決定你記憶體帳單的是那個分割方式，而不是表面上的標題數字。

所以，請把這兩個數字當成兩項事實。一百萬個 token 是存在於權重中的架構能力，需要相當規格的節點才能提供服務。一萬六千個 token 則是首個商業端點提供的數量——對多數 agent 迴圈來說足夠，但不足以進行儲存庫規模的推理或長文件作業。如果你嘗試 Ripple-65B Preview 的原因是 1M 上下文，託管途徑目前不會提供給你，而自架是唯一能提供它的方式。

本機是指 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，且尚未計入量化與自訂 kernel。在 Spark 上，你是在用吞吐量換取這台機器就放在你桌上的事實。這兩個數字都沒有錯；它們只是屬於不同的機器，而地端情境只有在採用量化檢查點時才成立。

通話費用是多少

第一個託管端點標價為每百萬輸入 token $0.20、每百萬輸出 token $0.60，快取輸入讀取則為 $0.05。以一次真實的代理呼叫來計算——在完整視窗下使用 16,000 token 的提示，回傳 2,000 token——輸入為 $0.0032、輸出為 $0.0012，合計約 $0.0044。若每天以 80/20 的輸入輸出比例處理 1,000 萬 token，費用就會達到 $2.80。

快取是值得拉動的槓桿。一段重複出現的 16,000 token 系統提示，以快取費率計價只要 $0.0008，而非 $0.0032，等於輸入端成本削減為四分之一——對於每一輪都重新送出相同工具定義的代理程式而言，這就佔了帳單的大部分。

OrcaRouter 的定位：我們目前並未提供 Ripple-65B Preview，因此沒有加價幅度可供比較，也沒有理由假裝不是如此。這個預覽真正改變的是：當你評估一個未經證實的模型時，讓它遠離正式生產環境的理由。把你流量已經依賴的現行模型透過單一金鑰路由——超過 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 已明確表示這裡的後訓練很輕量，而其晶片設計平台背後的內部變體才是它真正在打造的產品。在那之前，新聞標題是一項主張，而下載檔案是真的——而兩者之間的落差，正是接下來一個月評估將發生之處。