Ripple-65B 預覽：一個 $0.20 端點、一次原生 vLLM 合併，以及三個上下文數字

權重於 11 月 4 日 02:41 UTC 上線。十九小時後，有人開了一個 pull request，要把它們放進 vLLM 的主分支，並於 11 月 5 日 17:36 UTC 合併——27 個檔案共新增 1,153 行。即使以一個備受關注的模型發布標準來看，這也很快，而且它改變了一件具體的事：在那次合併之前，Ripple-65B Preview——來自 Ricursive Intelligence 的 65B 稠密 Apache 2.0 checkpoint——只有一條有文件記載的 serving 路徑：作者在引擎之外隨附的外掛。對任何評估它的人來說，問題不再是它能不能被 serving，而是如今這些官方 serving 方式中，哪一種適合你的硬體，以及每一種會默默讓你付出什麼成本。

有兩個事實支撐著這個問題，而它們指向相反的方向。原生 vLLM 支援讓那些始終沒能讓樹外 SGLang 腳本運作起來的團隊，也能合理自行託管。與此同時，託管服務的清單仍與模型卡在實際可獲得多少上下文上不一致——某個服務頁面在規格側欄以 128K 為標題，而同頁的模型卡區段卻說最高可達 1,048,576 個 token，而第一個搭載該模型的商業端點則提供 16,384。這兩項事實都無法釐清：一個宣稱具備百萬 token 上下文的 65B 模型，在作為其前端的端點只說 128K 時，究竟該怎麼做。

合併前實際上缺少了什麼

線索就在這個 pull request 本身的描述裡，它指出在此之前，「唯一的服務路徑是作者們的樹外 SGLang 外掛」。該外掛隨模型卡以 SGLang 0.5.19 設定形式發布，這意味著任何想服務 Ripple-65B Preview 的人，都必須採用搭配外部腳本的特定引擎版本，或者針對一個宣告自訂架構的檢查點自行撰寫模型定義。

第二點才是悄悄扼殺採用率的那一點。BF16 儲存庫帶有 custom_code 標籤，而設定檔將架構識別為 RicursiveForCausalLM——一個一週前沒有任何引擎聽過的名字。載入它就意味著要使用 --trust-remote-code，而在大多數生產環境中，這在成為技術決策之前，先得跟安全審查人員談一談。

合併移除了那個步驟，而不是繞過它。這個 PR 加入了內建的 RicursiveConfig，因此檢查點無需 --trust-remote-code 就能載入，並且它在模型登錄檔中註冊了該架構，與其他所有一線模型家族並列。為 SGLang 進行相同工作的平行努力仍處於開放且尚未合併的狀態，因此 vLLM 目前是唯一將此模型視為受支援成員而非腳本的 mainstream 引擎。

合併中比模型檔案更重要的部分

413 行的模型實作是較不起眼的那一半。真正有趣的新增內容，是那些讓模型表現得像其基準測試數據所描述之物的改動。

• 推理與工具呼叫 — 此次合併新增了 --reasoning-parser ripple 與 --tool-call-parser ripple，可處理選用的 think 區塊與 Hermes 風格的 JSON 工具呼叫，且串流輸出與非串流形式一致。少了這些，代理式模型回傳的文字就得自行解析，而部署後的代理往往正是在解析這一步出錯。

• 一份經過驗證的 recipe——recipes/models/ricursiveAI/Ripple-65B-Preview.yaml，共 97 行，預設在單張 B300 上使用 NVFP4 checkpoint，並附有 BF16 變體，且已接好解析器。它通過了 recipes 儲存庫自身的 validate-source.mjs。對這個模型來說，這是現有最接近官方「照這樣跑」的東西。

• 透過草稿檢查點進行推測性解碼——該儲存庫附帶一個 4.04B 的草稿模型，而這次合併讓 vLLM 能透過 no_rope_layers 讀取其 NoPE 層配置。在 GSM8K 上，該 PR 回報平均接受長度從每個驗證步驟 4.98 個 token 提升至 7.34 個 token。

• 158 行解析器測試，外加一個追蹤建構器，這是最不顯眼卻最令人安心的一部分：推理剖析器的行為是由測試固定住的，而非靠一句註解。

為什麼該關注的是接受長度，而不是每秒 token 數

Ricursive 自身公布的效率數字，是在兩張 B200 上、批次大小為 8 時，每秒 250 個 token，這還是在量化或自訂核心之前。那個數字是用作者自己的 SGLang 建置版本、在他們測試的檢查點修訂版上測得的。它是個不錯的上限，卻是個糟糕的規劃依據，因為決定代理迴圈感覺快不快的關鍵，是每次草擬輪次後有多少 token 能通過驗證。

草稿模型只在那裡提供協助，也僅限於那裡。它會提出以 16 個 token 為單位的區塊，每個位置有 32 個候選，並從目標模型第 1、20、39、58、77 層讀取中間隱藏狀態——這是一個 4.04B 模型，其全部工作就是猜測 64.8B 模型接下來會說什麼。它自己的模型卡對相關條件相當謹慎：驗證是在八張 H100 上、於 ripple-sglang 下、針對 RL-step-500 檢查點執行，而模型卡明確指出，這「並不代表對其他目標修訂版或執行階段版本具有相容性或效能」。

在把 7.34 當作延遲預算的依據之前，先把那句話讀兩遍。這是在同一版本、同一執行環境下測得的數據。vLLM 的合併會改變執行環境。目前還沒有人公布合併後路徑的 acceptance-length 數據，而這正是我會先用自己的流量實測、而不是直接借用別人數據的第一件事。

下載會讓你付出多少成本，以及它能裝在哪些硬體上

BF16 instruct 儲存庫總計 129.6 GB，分成 16 個分片；safetensors 中繼資料顯示總參數量為 64,782,689,360，屬於稠密模型，每個 token 都會啟用全部參數。沒有專家路由可利用，也無法以啟用參數量換取品質。若要完整精度的模型，這就是你需要配置的數量，另外還要加上 KV cache。

• 量化路徑 — NVFP4 儲存庫儲存了 39,616,865,360 個參數，約為 BF16 數量的 61%，而合併配方在單一 B300 上預設採用它。

• 草稿路徑 — 若啟用 DFlash2，會增加 4.04B 個參數與第二條 KV 路徑；此配方將其保留為選用而非預設。

• 單一工作站宣稱——Ricursive 表示該模型可裝在 NVIDIA DGX Spark 上，而有一份社群報告指出它能在三張 Radeon AI PRO R9700 顯卡上、於 ROCm 7.2.1 環境下運行。這兩者對量化檢查點而言都可信，但兩者都沒有附上我會當作服務等級引用的吞吐量數字。

• {{1}}平行化{{/1}} — 這次合併明確宣稱支援張量平行、管線平行、torch.compile 與 CUDA graphs，這正是讓 65B 稠密模型的多 GPU 服務從理想變為可行的原因。稠密模型能乾淨地切分，而將 65B 模型分布在四張 80GB 顯卡上，是 BF16 下舒適的 tensor-parallel-4 配置。

上下文視窗仍然還是三個不同的數字

這是尚未解決的項目，而它在合併過程中未受改動地保留下來，因為這是服務組態的問題，而非引擎的問題。

模型卡標榜「上下文長度最高可達 1M」，而設定檔支援的位置遠遠超出此範圍——長上下文訓練階段使用了 200 萬 token 的序列。本週發布的商業頁面在主標題主打 128K 上下文視窗，並在規格側欄重複標示 128K，但同一頁面的模型卡區段卻寫著「上下文長度最高可達 1,048,576 個 token」。推出時，第一個搭載該模型的託管端點提供 16,384。

三個數字，一個檢查點。最可能的解釋平淡無奇：1M 這個數字描述的是架構與權重能做到什麼，而較小的數字描述的則是某個特定服務部署被設定與驗證到什麼程度。這是正常的落差。這也是決定該模型能否用於儲存庫規模的代理工作的落差，因為 16K 視窗裝不下大型 diff 加上其測試輸出，而 128K 視窗大約能裝下一個。

如果你正在為代理式編碼評估 Ripple-65B Preview，請把上下文數字視為端點的屬性，而不是模型的屬性，並測試該端點。vLLM recipe 正是你可以自行設定上下文數字的地方。

這讓路由決策處於什麼位置

這一切都不會改變選擇的形狀，只會改變通往它的可行路徑數量。你現在可以用官方配方在 vLLM 上自行執行模型，或以每百萬輸入 token 約 $0.20、每百萬輸出 token 約 $0.60 的價格呼叫託管端點，而快取輸入的計費僅為其中一小部分。這些是權重相同但產品不同的選項：一個讓你掌控上下文視窗與帳單，另一個則給你一張信用卡和別人的佇列。

OrcaRouter 並未上架 Ripple-65B Preview——其型錄有 200 多個模型，而這款並不在其中；這一點值得明說，而不是暗示相反。實際上的意思是：如果你看中這個模型的原因是它便宜且開放，那你真正需要比較的，是你能用同一把金鑰存取的東西。DeepSeek V4 Pro的價格為每百萬 token $0.66 與 $1.98，具備 1M 上下文與 384K 最大輸出；Kimi K3.1 Pro的價格為每百萬 token $2.00 與 $10.00，具備 1M 上下文與 943K 輸出上限。讓這兩個模型透過單一端點執行並具備自動容錯移轉，是我們能替你從技術堆疊中接手的部分。Ripple 那一半則由你自行託管或購買。

哪些仍是廠商自行通報的，以及外部人士發現了什麼

附在此模型上的每一個能力數字都來自 Ricursive。Terminal-Bench 2.1 的 80.52 是最受矚目的亮點，而模型卡上也載有 Terminus 2 的 80.5、SWE-bench Verified 的 76.5、SWE-bench Pro v1.0 的 61.42、SWE-bench Pro v2.0 Hard 的 79.1、DeepSWE 1.1 的 44.3、SciCode 的 39.4，以及 MCP Atlas 的 71.67。這些全都沒有被獨立實驗室重現過，而且 Artificial Analysis 沒有該模型的條目——它的模型目錄對於我試過的每一個 Ripple slug 都回傳 404，這就是「未評分」從外部看起來的樣子。

唯一存在的獨立訊號指向相反方向，值得精確說明。一套名為 Cold Iron 的 157 項測試套件給該模型評分為 157 分中的 93 分，將其排在 28 名中的第 28 名，落後次低者五分。作者自己的細分比排名更有意思：在 64 次失敗中，12 次是供應商逾時並回傳零個 token，49 次是 finish=length——模型在產出可評分的答案之前就用完了 4,096 個 token 的輸出預算。只有三次是內容失誤。若把逾時計入，分數會升至 105，仍約排第 26 名。

這既是關於服務組態的結果，也同樣是關於能力的結果；而這正是原生引擎支援搭配經驗證的設定方案，理應能減少的那類失敗。一個在程式設計任務上耗盡 4K 輸出上限的模型，是被錯誤地執行，而不一定是無法寫程式的模型。

接下來要看什麼

有三件事會比任何進一步的報導更快讓這個模型塵埃落定。一份獨立評分——一旦 Artificial Analysis 或 LMArena 收錄它，供應商表格就變得可查證，而不只是可引用。SGLang 那邊的一次合併，這將終結單一引擎的局面。以及一個名稱中沒有「Preview」的檢查點，因為 Ricursive 將這次發布描述為刻意只做了輕度後訓練，而真正的內部產品是晶片設計變體。

在那之前，對這週的誠實總結範圍有限但有用：服務層面的情況在 36 小時內有實質改善，能力層面的情況則完全沒變，而上下文視窗的問題已從模型卡轉移到你自己的設定檔。