什麼是 Ripple-65B Preview?擊敗更大競爭對手的 65B 開放模型
Ricursive Intelligence 首款開放權重模型是一個密集型 65B,在代理程式編碼方面超越了更大的美國開放模型——且可在單台機器上運行。

Ricursive Intelligence 於 2026 年 11 月 4 日發布了 Ripple-65B Preview——這是一個擁有 650 億參數的密集型開放權重模型,儘管規模相對較小,卻在美國開放權重模型中取得了最高的自評代理程式編碼分數。它在關鍵測試中擊敗了規模大上許多倍的模型,採用 Apache 2.0 授權發布,且可在單台機器上運行。以下是 Ripple-65B Preview 的實際內容、基準測試表現,以及在相信這些標題數字之前值得了解的注意事項。
什麼是 Ripple-65B Preview?
Ripple-65B Preview 是一個擁有 650 億參數的密集型 Transformer,從頭開始以 12 兆個 token 進行預訓練,支援最多 100 萬個 token 的上下文長度。它以寬鬆的 Apache 2.0 授權發布,你可以下載並自行運行其權重。
這個模型來自 Ricursive Intelligence,一家位於帕羅奧圖(Palo Alto)的新創公司,以 AI 晶片設計聞名,而非前沿大型語言模型。Ripple 是驅動 Ricursive 晶片設計平台之專有模型的通用版本——現以開放權重形式向所有人提供。共同創辦人 Anna Goldie 和 Azalia Mirhoseini 曾參與 Google 的 AlphaChip 研究,主導了這項工作,此次發布也獲得了 Google 的 Jeff Dean 公開祝賀。
「Preview」標籤至關重要。根據 Ricursive 自己的說法,這次發布僅經過相對輕量的後訓練,重點放在代理程式編碼上,因此這是一個早期檢查點,而非完成品。
Ripple-65B Preview 基準測試
核心主張是在 Terminal-Bench 2.1 上取得 80.52 分,這是一個衡量模型在終端機內編寫和執行程式碼能力的基準測試。根據 Ricursive 的模型卡片,該分數在所比較的美國開放權重模型中領先:
| 基準測試 | Ripple-65B(65B) | Reflection Beam(501B) | Muse Spark Open(816B) | Inkling(975B) | Nemotron 3 Ultra(550B) |
|---|---|---|---|---|---|
| Terminal-Bench 2.1(自評) | 80.5 | 80.1 | 76.4 | 63.8 | 56.4 |
| SWE-bench Pro v2.0 Hard | 79.1 | 76.5 | 52.3 | 2.0 | 30.7 |
| SWE-bench Verified | 76.5 | 81.6 | 78.7 | 77.6 | 71.9 |
| DeepSWE 1.1 | 44.3 | 43.3 | 60.0 | 1.8 | 0.2 |
| AIME 2026(數學) | 95.0 | 97.7 | 98.3 | 97.1 | 95.4 |
| MMLU(知識) | 89.6 | 92.4 | 92.6 | 91.3 | 92.0 |
有兩點值得特別注意。首先,表中每個競爭對手都是混合專家(Mixture-of-Experts,MoE)模型,總參數量遠多於 Ripple——Ripple 是密集型且規模小得多,卻在 Terminal-Bench 2.1 和 SWE-bench Pro v2.0 Hard 上略勝一籌。其次,結果並非全面勝出:Reflection Beam 在 SWE-bench Verified 上仍然領先,Muse Spark Open 贏得 DeepSWE 1.1,而更大的模型在通用知識(MMLU)和部分數學測試上略有優勢。
換句話說,Ripple 在其專門調校的領域——代理程式編碼——表現最強,在其他方面則僅具競爭力。
為何小型密集模型能擊敗更大的模型
Ricursive 做出了一個刻意的架構賭注。與大多數實驗室現在採用的 MoE 設計不同,他們訓練了一個現代化密集型 Transformer,以保持訓練和服務基礎設施的簡潔性。該模型採用「細長深層」(thin-and-deep)形狀——在 80 層中使用 5,120 的窄 d_model——以及類似 Gemma-3N 的架構,這是為了在大規模訓練中保持穩定性而選擇的。
效率故事才是真正的亮點。Ricursive 將總研發成本估計為約 3,200 萬美元,並估計這大約是代理程式編碼領域前任開放權重領導者成本的十分之一。它還報告稱,達到其 Terminal-Bench 分數僅使用了 140 萬次強化學習(RL)展開——大約是 Reflection Beam 所用次數的 70 分之一。相對於其自身的 Olmo 3 基準線,Ricursive 報告在程式碼方面實現了 16 倍的計算效率提升,在完整規模下更達到 55 倍。
這些數字來自 Ricursive 本身,而非獨立實驗室,因此在第三方重現之前,應將其視為廠商自評數據。
你能在本地運行 Ripple-65B Preview 嗎?
可以——這正是其重要意義所在。以 650 億總參數而言,Ripple 足夠小,可以在消費級硬體(如 NVIDIA 的 DGX Spark)上運行,Ricursive 也將其定位為本地開發使用。它發布了三個檢查點:一個指令調校的 BF16 模型、一個量化的 NVFP4 版本,以及一個 BF16 基礎模型,另附有一個 Colab 供快速入門。
在資料中心 GPU 上,Ricursive 報告在批次大小為 8 的情況下,2xB200 可達到約每秒 250 個 token,這還是在未進行任何量化或自訂核心的情況下。
你可以從以下管道取得權重和託管存取:
- Hugging Face — ricursiveAI/Ripple-65B-Preview(Apache 2.0 權重)
- API 合作夥伴 — Together AI、GMI Cloud 和 OpenRouter,Fireworks 則列為在發布當天上線
「美國開放權重 SOTA」的主張是否成立
這個主張是真實的,但範圍有限。「美國開放權重模型的最先進水準」排除了閉源模型和非美國開放模型,因此這並非聲稱 Ripple 是整體最佳模型,甚至不是最佳開放模型。獨立報導指出,Ripple 在其他基準測試上落後於一些更大的開放模型。
幾點誠實的注意事項:
- 自評數據。 標題分數是 Ricursive 自己的;Ricursive 本身也指出,代理程式評估分數會因測試框架和設定的不同而有很大差異。
- Preview,非最終版本。 輕量後訓練意味著行為可能在後續版本中改變。
- 範圍有限的主張。 領先聲明僅針對代理程式編碼領域的美國開放權重模型,並非普遍排名。
這些都不能抹殺這項成就——一個 650 億密集型模型在困難編碼任務上匹敵甚至擊敗 5,000 億至 9,750 億參數的競爭對手,是真實的成果。這只是意味著,這些表述值得像對待任何發布當天的基準測試一樣,接受同等程度的審視。
Ripple-65B Preview 與 Reflection Beam 及 Muse Spark Open 的比較
如果你正在近期開放權重編碼模型中做選擇,取捨主要在於規模與廣度之間:
- Ripple-65B Preview — 規模最小、運行成本最低;在 Terminal-Bench 2.1 和 SWE-bench Pro v2.0 Hard 上表現最佳;密集型架構,易於本地部署。
- Reflection Beam(501B) — 在 SWE-bench Verified 上更強;規模大得多的 MoE,託管負擔較重。
- Muse Spark Open(816B) — 贏得 DeepSWE 1.1 和 MCP Atlas;Meta 發布的更大規模模型,覆蓋範圍廣泛。
對於希望部署本地編碼模型且能接受「Preview」成熟度的團隊而言,Ripple 是最值得關注的新選項。若要在編碼評估中追求最大廣度,更大的模型在某些方面仍有優勢。
在你自己的 AI 工作團隊中運行開放模型
Ripple-65B Preview 正是為代理程式整天所做的工作而生:讀取程式碼庫、編寫程式碼,以及在終端機中執行指令。Eigent 是一款開源多代理程式「Cowork」桌面應用程式,可在本地運行這套工作流程——將一組代理程式指向審查 GitHub 拉取請求等任務,並將模型和你的資料保留在自己的機器上。如果你想將本地開放權重模型與本地代理程式執行環境配對,下載 Eigent 並開始建立你自己的 AI 工作團隊。
Recent Posts

Claude 在 Android 上現在可在 Chromebook 和折疊機上像筆電一樣使用
Claude 在 Android 上現在可在 Chromebook、Googlebook 和折疊機上像筆電應用程式一樣運作,具備可調整大小的側邊欄、觸控板、右鍵點擊及桌面快捷鍵。

Eigent v1.0.7 發布說明:並排工作階段、更清楚的任務紀錄與可重用的工作
Eigent v1.0.7 新增工作階段分割檢視與獨立視窗,改善任務紀錄和核准流程,支援將成果轉為技能與自動化,讓日常工作更可靠。

Grok API 的 guidelines 參數是什麼?自訂內容審核機制詳解
了解 Grok API guidelines 參數的功能、支援哪些內容類別、如何設定,以及需要注意的請求限制與錯誤處理。