Ripple-65B Preview：0.20ドルのエンドポイント、ネイティブvLLMマージ、そして3つのコンテキスト数値

重みは11月4日02:41 UTCに公開された。19時間後、誰かがそれらをvLLMのメインブランチに入れるプルリクエストを開き、11月5日17:36 UTCにマージされた——27ファイルにわたる1,153行の追加だ。これは大きな注目を集めるモデルリリースの基準から見ても速く、しかも具体的な点を変えた。そのマージまでは、Ripple-65B Preview——Ricursive Intelligenceによる65B dense Apache 2.0チェックポイント——には、文書化されたサービング経路がちょうど1つしかなかった。それは作者がエンジンの外で配布したプラグインだった。これを評価する人にとって、もはや問いは「サービングできるか」ではない。今では公式となったサービング方法のうち、どれが自分のハードウェアに合うのか、そしてそれぞれが密かにあなたに何のコストを課すのか、だ。

その問いの背景には二つの事実があり、しかもそれらは相反する方向に引っ張り合っている。vLLM のネイティブ対応によって、ツリー外の SGLang スクリプトを動かせなかったチームにもセルフホストが現実味を帯びる。一方でホスト型の掲載情報は、実際に得られるコンテキスト量についてモデルカードと依然として食い違っている。あるサービスのページでは仕様サイドバーに 128K と見出しを掲げる一方、同じページのモデルカードのセクションには最大 1,048,576 トークンと記されており、このモデルを搭載した最初の商用エンドポイントは 16,384 を提供していた。100万トークンのコンテキストをうたう 65B モデルが、その前面に立つエンドポイントは 128K だと言うとき、いったいどう振る舞うべきなのかという点は、どちらの事実によっても解決しない。

マージ前に実際に欠けていたものは何だったのか

手がかりはプルリクエスト自体の説明にあり、そこには、この変更以前は「唯一のサービング経路は著者らによるアウトオブツリーのSGLangプラグインだった」と記されています。そのプラグインはモデルカードとともにSGLang 0.5.19のセットアップとして提供されていたため、Ripple-65B Previewをサービングしたい人は誰でも、外部スクリプトを伴う特定のエンジンバージョンを採用するか、カスタムアーキテクチャを宣言するチェックポイントに対して独自のモデル定義を書くかのどちらかが必要でした。

その2点目こそが、静かに導入を潰す要因だ。BF16リポジトリにはcustom_codeタグが付いており、設定ではアーキテクチャがRicursiveForCausalLMと識別されている——1週間前にはどのエンジンも耳にしたことのない名前だ。これを読み込むには--trust-remote-codeが必要で、ほとんどの本番環境では、それは技術的な判断である前にセキュリティレビュアーとの会話を意味する。

このマージはその手順を回避するのではなく、不要にします。PRは組み込みのRicursiveConfigを追加するため、チェックポイントは--trust-remote-codeなしで読み込まれ、アーキテクチャは他のすべての一級ファミリーと並んでモデルレジストリに登録されます。SGLangについても同じことを行う並行作業はまだオープンで未マージのため、現在、このモデルがスクリプトではなく正式にサポートされた一員として扱われる主流エンジンはvLLMだけです。

モデルファイルよりも重要になるマージの部分

413行のモデル実装は、地味な半分にすぎない。興味深い追加要素とは、モデルをそのベンチマーク数値が描写する通りのものとして振る舞わせるためのものだ。

• 推論とツール呼び出し — このマージにより、--reasoning-parser ripple と --tool-call-parser ripple が追加されます。これらはオプションの think ブロックと Hermes 形式の JSON ツール呼び出しを処理し、ストリーミング出力は非ストリーミング形式と一致します。これらがなければ、エージェント型モデルは自分で解析しなければならないテキストを返すことになり、その解析こそがデプロイされたエージェントの失敗する箇所です。

• 検証済みのレシピ — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml、97行、単一のB300上でNVFP4チェックポイントをデフォルトとし、BF16版とパーサーが組み込まれている。これはrecipesリポジトリ自身のvalidate-source.mjsを通過する。これはこのモデルについて存在する、公式の「こうやって実行する」に最も近いものだ。

• ドラフトチェックポイントを用いた投機的デコーディング — リポジトリには4.04Bのドラフターが同梱されており、このマージによりvLLMがno_rope_layersを介してそのNoPEレイヤーレイアウトを読み取れるようになります。GSM8Kでは、このPRは検証ステップあたりの平均受理長が4.98トークンから7.34トークンに増加したと報告しています。

• パーサーテスト158行、さらにトレースビルダー。これは最も目立たないが、最も安心させられる部分だ。推論パーサーの挙動はコメントではなくテストによって固定されている。

なぜ注目すべき指標はトークン毎秒ではなく、アクセプタンス長なのか

Ricursive自身が公表している効率値は、量子化やカスタムカーネルを適用する前の段階で、バッチサイズ8、B200×2構成において毎秒250トークンです。この数値は著者自身によるSGLangビルドで、彼らがテストしたチェックポイントのリビジョン上で測定されたものです。これは上限値としては申し分ありませんが、計画立案の入力としては不適切です。なぜなら、エージェントループが高速に感じられるかどうかを左右するのは、ドラフト1パスあたり何トークンが検証を通過して生き残るかだからです。

ドラフターが役立つのはそこだけだ。位置ごとに32個の候補を伴う16トークンのブロックを提案し、ターゲットの層1、20、39、58、77から中間隠れ状態を読み取る。64.8Bモデルが次に何を言うかを推測することだけを役割とする4.04Bモデルである。自身のカードは条件について慎重で、検証はripple-sglang上で8台のH100を用い、RL-step-500チェックポイントに対して実行されたとし、さらにこのことが「他のターゲットリビジョンやランタイムバージョンに対する互換性や性能を確立するものではない」と明言している。

7.34 に基づいてレイテンシ予算を組む前に、その文を二度読んでください。それは同一リビジョン、同一ランタイムでの測定です。vLLM のマージはランタイムを変えます。マージ後の経路について acceptance-length の数値を公表した人はまだ誰もおらず、それは借り物にせず、自分のトラフィックで最初に測るべきものです。

ダウンロードにかかる費用と、どのハードウェアに適合するか

BF16 instructリポジトリは16シャードで合計129.6 GB、safetensorsメタデータの合計は64,782,689,360パラメータです——密（dense）で、そのすべてが毎トークンで有効になります。活用できるエキスパートルーティングはなく、アクティブパラメータを品質と引き換えにする方法もありません。フル精度モデルが必要なら、それがプロビジョニングすべき数値であり、さらにKVキャッシュも必要です。

• 量子化パス — NVFP4リポジトリには39,616,865,360個のパラメータが格納されており、これはBF16のパラメータ数の約61%に相当します。また、マージ済みレシピでは単一のB300上でこれがデフォルトとなっています。

• ドラフトパス — DFlash2 を有効にすると、4.04B パラメータと2つ目の KV パスが追加されます。このレシピでは、デフォルトではなくオプトインのままになっています。

• 単一ワークステーションでの主張 — Ricursive によると、このモデルは NVIDIA DGX Spark 上で動作し、コミュニティの報告では ROCm 7.2.1 環境下で Radeon AI PRO R9700 カード3枚で動作している。どちらも量子化済みチェックポイントに関しては信頼できるが、サービスレベルとして提示できるようなスループット値はどちらにも示されていない。

• 並列化 — このマージは、テンソル並列、パイプライン並列、torch.compile、CUDA graphsを明示的にうたっており、まさにこれによって65BのdenseモデルのマルチGPUサービングが絵に描いた餅ではなく実用的になる。denseモデルはきれいに分割でき、65Bを4枚の80GBカードに分散させるのは、BF16におけるtensor-parallel-4の快適なレイアウトだ。

コンテキストウィンドウは依然として3つの異なる数値です

これは未解決の項目であり、エンジンの問題ではなくサービング設定の問題であるため、マージを経ても手を加えられずに残っています。

モデルカードは「最大1Mコンテキスト長」をうたっており、設定はそれをはるかに超える位置をサポートしている——長コンテキスト訓練段階では2Mトークン系列が使われた。今週公開された商用リスティングは128Kコンテキストウィンドウを見出しに掲げ、仕様のサイドバーでも128Kを繰り返す一方、同じページのモデルカードセクションには「最大1,048,576トークンのコンテキスト長」と書かれている。ローンチ時、このモデルを搭載した最初のホスト型エンドポイントは16,384を提供していた。

3つの数値、1つのチェックポイント。最もありそうな説明はありふれたものだ。1Mという数値はアーキテクチャと重みが何をできるかを示し、より小さい数値は、特定のサービングデプロイメントが何向けに設定され、検証されているかを示している。それは正常なギャップだ。また、モデルがリポジトリ規模のエージェント作業に使えるかどうかを決めるギャップでもある。16Kウィンドウには大きな差分とそのテスト出力を収められず、128Kウィンドウならおよそそれが1つ分収められるからだ。

Ripple-65B Preview をエージェント型コーディング向けに評価する場合は、コンテキスト数はモデルの属性ではなくエンドポイントの属性として扱い、エンドポイントをテストしてください。vLLM のレシピは、自分で設定できる場所です。

これでルーティングの判断がどうなるか

こうしたことは選択の形を変えるものではなく、その選択に至る実行可能な道筋の数を変えるだけだ。今なら公式レシピを使ってvLLM上でモデルを自分で実行することも、ホスト型エンドポイントを呼び出すこともできる。料金は入力100万トークンあたり約$0.20、出力100万トークンあたり約$0.60で、キャッシュされた入力はそのごく一部の課金となる。これらは同じ重みを持つ別々の製品だ。一方はコンテキストウィンドウと請求を自分で制御できるようにし、もう一方はクレジットカードと他人の待ち行列を渡してくる。

OrcaRouterはRipple-65B Previewを取り扱っていません。カタログには200以上のモデルがありますが、これはその中に含まれていません。曖昧に示唆するのではなく、はっきりと言うべきことです。実務上これが意味するのは、このモデルを検討している理由が「安価でオープンだから」というのであれば、本当に必要な比較対象は、同じキーで利用できる別のモデルだということです。DeepSeek V4 Proは100万トークンあたり$0.66と$1.98、コンテキスト1M、最大出力384Kです。Kimi K3.1 Proは$2.00と$10.00、コンテキスト1M、出力上限943Kです。この2つを単一のエンドポイントで、自動フェイルオーバー付きで運用する部分は、こちらで引き受けられます。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スラッグに対して404を返します。これが外部から見た「未スコア」という状態です。

存在する唯一の独立したシグナルは逆方向を示しており、正確に述べておく価値がある。Cold Iron と呼ばれる157テストのスイートは、このモデルを157中93と採点し、28件中28位に位置づけた——次に低いエントリーより5点下である。著者自身による内訳は順位よりも興味深い。64件の失敗のうち、12件はゼロトークンを返したプロバイダーのタイムアウトで、49件は finish=length だった——モデルは採点可能な回答を生成する前に、4,096トークンの出力予算を使い果たした。内容面の外れはわずか3件だった。タイムアウトを加点すれば105に上がるが、それでも約26位である。

それは能力だけでなく、サービング設定にも関わる結果であり、検証済みレシピを伴うネイティブエンジンサポートが削減するはずの、まさにその種の失敗です。コーディングタスクで4Kの出力上限を使い果たすモデルは、誤った実行をされているモデルであり、必ずしもコーディングできないモデルではありません。

次に見るもの

このモデルに決着をつけるには、これ以上報道を重ねるよりも、3つのことが早いだろう。独立したスコア——Artificial AnalysisかLMArenaが取り上げた時点で、ベンダー比較表は引用されるだけのものではなく検証できるものになる。SGLang側のマージ——これで単一エンジンという状況が終わる。そして名前に「Preview」を含まないチェックポイント——Ricursiveはこのリリースを意図的に軽めにポストトレーニングしたものと説明しており、実際の内部製品はチップ設計用のバリアントだとしたからだ。

それまでは、今週の正直な要約は限定的だが有用だ。サービングの状況は36時間で実質的に改善し、能力面の状況はまったく変わらず、コンテキストウィンドウに関する疑問はモデルカードからあなた自身の設定ファイルへと移った。