Ripple-65B Preview 必要スペック
BF16 約130GB / NVFP4 約57GB・RTX PRO 6000〜DGX Spark【65B dense・2026年版】
Ripple-65B Previewの必要スペックを実ファイルサイズで整理。65B denseの重みはBF16が129.57GB、公式NVFP4が57.21GB。DGX Sparkや96GB GPUの構成、1MコンテキストのKV推定、GGUF/MLXの実サイズ、起動手順を解説。2026年11月更新。
Ripple-65B Preview は、Ricursive Intelligence が 2026年11月4日に公開したオープンウェイトの言語モデルで、総パラメータ約65B（Hugging Face 表示 64.78B）の dense（密）Transformer、Apache 2.0 ライセンス、最大1M（1,048,576）トークンのコンテキストに対応する。エージェント型コーディング向けに調整されており、公式は「DGX Spark のような手元の機材に載る」と説明している。実ファイルの合計サイズは、BF16 の公式版が 129.57GB、公式 NVFP4 版が 57.21GBで、NVFP4 なら 96GB 級の GPU 1枚や DGX Spark（128GB）に収まる。
本記事の重みサイズは、Hugging Face 上の各リポジトリの safetensors / GGUF の実ファイルサイズ（2026年11月9日確認）である。一方、KV キャッシュ量、GPU・Mac での収まり方、速度の目安は config.json の値や一般的な計算式からの推定で、その旨を明記する。Terminal-Bench 2.1 の 80.5 などのベンチマークは Ricursive の自社計測であり、第三者の再現ではない。
必要スペック早見表
| 形式 | 重みの実ファイルサイズ | 構成の目安（推定） | 備考 |
|---|---|---|---|
| BF16（公式） | 129.57GB（120.67GiB） | H100 80GB×2、RTX PRO 6000 96GB×2、B200×2（公式サーバーの既定構成） | H200 141GB 1枚は重みだけで約9割を占め、長いコンテキストは厳しい |
| FP8（コミュニティ版） | 約65.8GB | 80GB 級 GPU 1枚（KV に使える余白は約13GiB）、96GB 級なら余裕 | primitive-ai/Ripple-65B-Preview-FP8。公式配布ではない |
| NVFP4（公式） | 57.21GB（53.28GiB） | RTX PRO 6000 96GB 1枚、DGX Spark 128GB | MLP は NVFP4、アテンションは BF16 のまま。Blackwell 世代向け |
| NVFP4（Red Hat AI 版） | 約37.9GB | 48GB 級、RTX 5090 32GB には載らない | 活性値も FP4 の別実装。vLLM 向け |
| Q8_0（GGUF） | 68.84GB | 96GB 級 GPU、128GB の Mac・DGX Spark | BF16 とほぼ差がない品質（KLD 0.0010、AtomicChat 計測） |
| Q6_K（GGUF） | 53.15GB | 64GB 以上のメモリ、80GB GPU | 長いコンテキストなら余裕が欲しい |
| Q5_K_M（GGUF） | 45.76GB | 64GB の Mac、2×24GB GPU（短いコンテキスト） | |
| Q4_K_M（GGUF） | 38.80GB | 2×24GB GPU、48GB の Mac | 標準的な落としどころ |
| Q3 級（GGUF） | IQ3_XXS 27.25GB〜Q3_K_M 31.02GB | RTX 5090 32GB（短いコンテキスト） | 品質低下が目立ち始める |
| Q2 級（GGUF） | 20.01〜23.75GB | RTX 4090 / 3090 24GB（短いコンテキスト） | 実用品質は要確認。素の Q2_K は壊れる報告あり |
手元のGPU・Macで動くかをすぐ確かめたい場合は、モデル・量子化・コンテキスト長を選ぶだけで必要VRAMを試算できるVRAM計算ツール（無料・登録不要）も用意している。Ripple-65B Preview もモデル一覧から選択できる。
表のサイズは重みだけである。HF の「GB」は10の9乗バイト、GPU 搭載メモリの「GB」は実質 GiB（2の30乗）で表記されるため、32GB の GPU に載るのは約34.4GB（10の9乗基準）までの計算になる。さらに KV キャッシュ、CUDA コンテキスト、アクティベーションが加わるので、重みサイズに1〜3GB以上の余裕を見たい（推定）。
Ripple-65B Preview のモデル概要
| 項目 | 内容 |
|---|---|
| 開発元 | Ricursive Intelligence（AI チップ設計向けの自社モデルの汎用版として公開） |
| 公開日 | 2026年11月4日（Hugging Face 上のリポジトリ作成日時も同日） |
| 種別 | dense Transformer。MoE ではなく、毎トークン 65B すべてが計算に使われる |
| パラメータ数 | 64,782,689,360（BF16）。公式表記は 65B |
| 層数・隠れ次元 | 80層・d_model 5,120・FFN 中間 40,960 |
| アテンション | 80ヘッド（Q）・8 KV ヘッド（GQA）・head_dim 128。5層に1層が全注意（NoPE）、残り4層は窓1,024トークンのスライディング窓 |
| そのほかの設計 | ゲート付きアテンション、FFN 活性化のクリップ、value residual、Gemma 3n 風の構成（Olmo 3 ベースから改良） |
| 学習 | 12T トークンを 8K 系列長で事前学習。midtrain → 長コンテキスト → SFT → 長コンテキスト SFT → RL。事前学習データはテキストのみ・英語とコードが中心 |
| コンテキスト長 | 1M（1,048,576）トークン。config の max_position_embeddings は 2,097,152 |
| 語彙 | 100,352 |
| ライセンス | Apache 2.0 |
| 提供形態 | BF16・NVFP4・Base（BF16）・DFlash2（投機的デコード用ドラフト）。Together AI・GMI Cloud・OpenRouter・Fireworks でも提供 |
出典は Hugging Face のモデルカード（https://huggingface.co/ricursiveAI/Ripple-65B-Preview）と、Ricursive の公式ブログ（https://www.ricursive.com/ripple）である。ブログは開発・学習費用を約3,200万ドルと述べているが、これは同社の自己申告で、必要スペックには関係しない。
リポジトリごとの実サイズ
| リポジトリ | 内容 | safetensors 合計 |
|---|---|---|
| ricursiveAI/Ripple-65B-Preview | 指示調整済み BF16（16ファイル） | 129.57GB（64.78B パラメータ） |
| ricursiveAI/Ripple-65B-Preview-NVFP4 | NVFP4 MLP＋BF16 アテンション（6ファイル、「Experimental」表記） | 57.21GB |
| ricursiveAI/Ripple-65B-Base-Preview | 事前学習のみの BF16 Base（17ファイル） | 129.57GB |
| ricursiveAI/Ripple-65B-Preview-DFlash2 | 投機的デコード用ドラフト（4.04B パラメータ） | 8.08GB |
NVFP4 版が BF16 の約4分の1にならず約44%（57.21GB）なのは、MLP だけを NVFP4 にして、アテンション・埋め込み・出力ヘッドを BF16 のまま残す「保守的な量子化」だからである（公式説明）。DFlash2 のドラフトは別に約8.1GB を使うため、Spark で投機的デコードまで使うと重みは合計約65.3GB になる（計算）。
dense モデルの注意点 — 速度は 65B 級、MoE と違い全重みが毎トークン動く
MoE は総パラメータが大きくても、1トークンで動くのは一部のエキスパートだけなので、メモリは重くても速度は軽い。Ripple-65B は逆で、65B の全重みが毎トークン読まれる。デコード速度の上限はおおよそ「メモリ帯域 ÷ 重みサイズ」で決まるため、重みを読む量が速度に直結する（一般的な近似で、推定）。
- 帯域1TB/s の GPU で Q4_K_M（38.8GB）なら、理論上限は約26トークン/秒（1,000÷38.8、推定）。実際は下回る
- 量子化は容量だけでなく速度にも効く。BF16（129.57GB）より NVFP4（57.21GB）のほうが読む量は少ない
- 同規模の MoE（総パラメータが数百B）と比べて、メモリ総量は小さい一方、トークン当たりの計算量は大きい
- 公式ブログは、DGX Spark を「演算性能は高いがメモリ帯域がデータセンター向け GPU より低い」機材と位置づけ、公式の Spark 用ノートブックは DFlash2 の投機的デコードを組み合わせている
数値で確認できる公式・準公式の速度は2つだけである。公式カードは、BF16・量子化やカスタムカーネルなしで B200 2枚・バッチ8のとき 250トークン/秒と述べている。コミュニティの AtomicChat は、素の Q4_K_M を GH200 96GB の llama-cli で動かし、プロンプト処理309トークン/秒・生成40.6トークン/秒だったと1回の計測値を公開している。DGX Spark での公式な生成速度は、確認した範囲では公表されていない。
MoE との違いを実感したい場合は、2026年11月5日公開の 280B MoE である ERNIE 5.5 Flash Base の必要スペック と並べるとよい。もっと軽い dense が目的なら、Qwen3.8-27B や Nanbeige4.3-33B が候補になる。
1M コンテキストと KV キャッシュ（config からの推定）
KV キャッシュは config.json の値から計算できる。層数80、KV ヘッド8、head_dim 128、BF16 だと、1トークン・1層あたり K と V で 2×8×128×2バイト＝4KiB である。ここで効くのが層構成で、80層のうち全注意の層は16層（5層に1層）、残り64層は窓1,024トークンのスライディング窓なので、窓を超えた古いトークンの KV を持たなくてよい（推定。実装がそう動く場合）。
| コンテキスト長 | 全注意16層の KV（BF16、推定） | 窓付き64層の KV（固定、推定） | 合計の目安 |
|---|---|---|---|
| 32,768 | 約2GiB | 約0.25GiB | 約2.3GiB |
| 131,072 | 約8GiB | 約0.25GiB | 約8.3GiB |
| 262,144 | 約16GiB | 約0.25GiB | 約16.3GiB |
| 1,048,576（1M） | 約64GiB | 約0.25GiB | 約64.3GiB |
計算は「16層×4KiB＝64KiB/トークン」と「64層×1,024トークン×4KiB＝256MiB」である。窓付き層も全トークン分の KV を持つ実装だと、1トークン当たり320KiBになり、131,072トークンで約40GiB、1Mで約320GiBまで膨らむ（推定）。また、これは1リクエスト分で、同時リクエストが増えれば比例して増える。公式サーバーが BF16 の KV で 1Mi トークンを前提に B200 2枚を使っているのは、この規模の確保が理由と考えられる（推定）。
実用面では、重み（NVFP4 の57.21GB）に 128K の KV（約8.3GiB）を足しても Spark の 128GB に十分収まる。一方、1M を 1 リクエスト通すと、KV だけで約64GiB になり、DGX Spark や 96GB 級 GPU 1枚では重みと合わせて厳しくなる。公式の Spark 用サンプルが既定で 131,072 トークンに絞っているのもこのためだろう。
GPU 構成別の目安
| 構成 | 合計メモリ | 推奨する形式（推定） | コメント |
|---|---|---|---|
| RTX 4090 / 3090（24GB） | 24GB | Q2 級（20〜24GB） | 短いコンテキストのみ。品質低下が大きい。Q4 以上は RAM オフロードが必要で、dense なので遅くなる |
| RTX 5090（32GB） | 32GB | Q3 級（IQ3_XXS 27GB 前後） | コンテキストは数万トークンが現実的 |
| 24GB×2 / 5090 ×2 | 48〜64GB | Q4_K_M〜Q5_K_M | 2枚分割は llama.cpp の複数 GPU で可能 |
| RTX PRO 6000（96GB） | 96GB | NVFP4（公式）または Q8_0 | 1枚で重み＋100K 級のコンテキストが収まる |
| H100 80GB | 80GB | FP8（コミュニティ）、Q6_K | NVFP4 のネイティブ演算は Blackwell 世代向けで、H100 での動作は未確認 |
| H100 80GB×2 / H200 141GB | 160GB / 141GB | BF16 | ×2 ならコンテキストに約28GiBの余白（推定）。H200 は余白が約10GiBで短めのみ |
| DGX Spark（128GB 統合メモリ） | 128GB | NVFP4（公式）＋ DFlash2 | 公式が動作を想定した機材。重み合計約65.3GB |
| B200 ×2 | 2枚 | BF16（公式サーバー） | 1M コンテキストが既定。TP=2 |
NVFP4 のネイティブ演算は Blackwell 世代（B200、RTX 5090、RTX PRO 6000、DGX Spark の GB10）が前提で、公式の NVFP4 向けローカル実装も Spark 用に書かれている。Hopper（H100/H200）や Ada（RTX 4090）では、NVFP4 の速度上の利点は得にくいと考えられる（推定）。それらでは GGUF や FP8 を選ぶほうが素直である。
Apple Silicon での動作
Apple Silicon はユニファイドメモリなので、GPU 専用メモリの枠を気にせず大きなモデルを載せられるが、全量を GPU に使えるわけではない（推定）。Ripple には llama.cpp 用の GGUF のほか、コミュニティの MLX 版もある。frogggias の MLX 4bit は safetensors 合計で約36.4GB、8bit は約68.8GBである。
- 36〜48GB の Mac: MLX 4bit（約36.4GB）や Q4_K_M（38.8GB）は載るが、コンテキストと OS 分の余白が足りず、48GB 機でもかなり短いコンテキストに限られる
- 64GB の Mac: Q5_K_M（45.76GB）が現実的。Q6_K（53.15GB）は短めのコンテキストならなんとか
- 96GB の Mac: Q8_0（68.84GB）が載り、数十K トークンのコンテキストに余裕が出る
- 128GB の Mac: Q8_0 と長めのコンテキスト。BF16（129.57GB）は載らない
- 速度: dense で毎トークン全重みを読むため、メモリ帯域が高い Max・Ultra 系が有利で、無印 M シリーズは遅い（推定）
Mac で複数のモデルを比べる前に、DGX Spark で機密コードをローカル LLM に任せる運用 の記事で、手元機材とクラウドの使い分けの考え方を押さえておくとよい。
起動手順 — 公式の SGLang、vLLM、llama.cpp
モデルカードには起動コマンドの説明がなく、手順は同リポジトリの inference フォルダに置かれている。標準の SGLang にはまだ Ripple 対応が入っておらず（2026年11月9日時点で対応 PR #48636 は未マージ）、公式は専用の起動スクリプトを配っている。
BF16 を B200 2枚で動かす公式サーバー手順は、SGLang 0.5.19、CUDA Toolkit 13、C++ コンパイラ、uv が前提である。inference/server フォルダで次のように起動し、既定は TP=2・BF16 の重みと KV・1Mi トークンのコンテキスト・DFlash2 の16トークン投機で、127.0.0.1:30000 で待ち受ける。
export CUDA_HOME=/usr/local/cuda-13.0
export PATH="$CUDA_HOME/bin:$PATH"
CUDA_VISIBLE_DEVICES=0,1 uv run --script serve.py \
--model-path /path/to/target \
--speculative-draft-model-path /path/to/draftDGX Spark 向けは、NVFP4 版と DFlash2 を組み合わせるノートブック（inference/local/ripple.ipynb）が公式で用意されている。Python 3.12 の Jupyter カーネル、CUDA Toolkit 13、sglang==0.5.19、torch==2.13.0+cu130、transformers==5.12.1 などの固定バージョンを入れ、from spark import Spark で Spark("ricursiveAI/Ripple-65B-Preview-NVFP4", "ricursiveAI/Ripple-65B-Preview-DFlash2") を作る。HTTP サーバーではなくオフライン実行で、同時に1リクエストだけが対象になる。同梱の spark.py は既定のコンテキストを131,072トークンにしている。
vLLM は、Ripple 対応の PR #65745 が 2026年11月5日にマージされた。ただし、確認時点で公開済みの最新タグは v0.33.0rc3（11月2日）で、マージより前のため、どのリリースに入るかは未確認である。Red Hat AI の NVFP4 版（RedHatAI/Ripple-65B-Preview-NVFP4）のカードには、次の起動例が載っている。
vllm serve RedHatAI/Ripple-65B-Preview-NVFP4 \
--tensor-parallel-size 1 \
--reasoning-parser ripple \
--enable-auto-tool-choice \
--tool-call-parser ripplellama.cpp は、Ripple 対応の PR #31692 が 2026年11月5日にマージされ、リリース b12167（11月6日）以降で素の llama.cpp が動く。b12167 より古い版を同梱するアプリ（AtomicChat の説明では LM Studio や Ollama を含む）は、更新されるまで GGUF を読み込めない。CUDA 版は次のようにビルドして --jinja 付きで使う（Mac は -DGGML_CUDA=ON を外す）。
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build -j --config Release --target llama-server llama-cli
./build/bin/llama-server -m Ripple-65B-Preview-AD-Q4_K_M.gguf --jinja -c 32768 -ngl 99チャットテンプレートはツール呼び出しと <think> による推論出力を含む。公式サーバーは reasoning_content と tool_calls を分けて返すパーサー（ripple）を持つ。一方でテンプレートには、思考のオン・オフや推論の強さを切り替える機能は実装されていない（公式 README）。
コミュニティ GGUF の実ファイルサイズ
| 量子化 | 実ファイルサイズ | 出所と備考 |
|---|---|---|
| BF16 | 129.57GB | 公式の safetensors と同サイズ |
| Q8_0 | 68.84GB | mrfakename、prometheusAIR ほか。KLD 0.0010（AtomicChat 計測） |
| Q6_K | 53.15GB | prometheusAIR。AtomicChat の AD-Q6_K は57.7GB |
| Q5_K_M | 45.76GB | mrfakename、DevQuasar。AD-Q5_K_M は47.93GB |
| Q4_K_M | 38.80GB | 複数。AD-IQ4_XS は38.72GB、AD-Q4_K_M は40.43GB |
| Q3_K_M | 31.02GB | mrfakename ほか。IQ3_S は29.61GB |
| IQ3_XXS | 27.25GB | prometheusAIR。AtomicChat 版は27.96GB |
| Q2_K | 23.75GB | DevQuasar。mrfakename は PPL が約50.7で Q3_K_M の5倍超となり公開を見送った |
| AD-IQ2_XXS | 20.01GB | AtomicChat。一致率80.8%、24GB GPU 向けの研究的な位置づけ |
AtomicChat は、BF16 との次トークン一致率も公開している。同社の独自レイアウトで、AD-Q4_K_M が95.9%、AD-IQ3_XXS が91.2%、AD-IQ2_XXS が80.8%、素の Q4_K_M が93.0%である。つまり同じ容量なら、重要度行列（imatrix）を使った量子化のほうが素の Q4_K_M より品質が高い。これらは第三者が公開した計測値で、公式のものではない。
公式ベンチマークと他モデルとの比較（自社計測）
以下は公式モデルカードの数値である。Ricursive はモデルカードで、各社が公表している数値は公式値を使い、欠けている項目だけ自社の評価環境で計測したと説明しており、†が付いた競合の値は Ricursive が自社で測ったものである。Terminal-Bench 2.1 については、公式の Terminus 2 ハーネスで128K・要約ありに揃えるとほぼ全モデルのスコアが下がったとも書かれている。すべて自己申告であり、第三者の検証ではない。
| ベンチマーク | Ripple-65B Preview | Nemotron 3 Ultra 550B | Inkling 975B | Muse Spark Open 816B | Reflection Beam 501B |
|---|---|---|---|---|---|
| アーキテクチャ | dense | MoE | MoE | MoE | MoE |
| 総パラメータ / 活性 | 65B / 65B | 550B / 55B | 975B / 41B | 816B / 42B | 501B / 23B |
| Terminal-Bench 2.1（各社公表値） | 80.5 | 56.4 | 63.8 | 76.4 | 80.1 |
| Terminal-Bench 2.1（Terminus 2） | 80.5 | 55.1† | 56.2† | 78.7† | 70.8† |
| SWE-bench Verified | 76.5 | 71.9 | 77.6 | 78.7† | 81.6 |
| SWE-bench Pro v1.0 | 61.42 | 46.9† | 54.3 | 58.2† | 66.1 |
| SWE-bench Pro v2.0 Hard | 79.1 | 30.7† | 39.6† | 72.4† | 76.5 |
| DeepSWE 1.1 | 44.3 | 0.2† | 1.8† | 60.0 | 43.3 |
| MCP Atlas | 71.67 | 62.2† | 76.0 | 89.2 | 80.8 |
| GPQA Diamond | 85.2 | 87.0 | 87.2 | 89.0 | 90.6 |
| MMLU-Pro | 84.2 | 86.8 | 87.3† | 87.9† | 76.5† |
見どころは、総パラメータが7〜15倍のモデルと並ぶ、あるいは上回る端末操作系（Terminal-Bench 2.1、SWE-bench Pro v2.0 Hard）のスコアである。反対に、SWE-bench Verified、DeepSWE 1.1、MCP Atlas、GPQA Diamond では、Reflection Beam 501B や Muse Spark Open 816B に届いていない。点数の高さは「端末で動くエージェント」のタスクに偏っており、知識や汎用推論での優位ではない。エージェント向けのタスクで自分のリポジトリを使って試してから判断したい。
なお、事前学習データはテキストのみで英語とコードが中心と明記されており、日本語の性能や画像入力への対応は公表されていない。日本語の業務文書に使う場合は、手元で確認する必要がある。
ライセンス
ライセンスは Apache 2.0（リポジトリの LICENSE は Apache License Version 2.0 の全文）で、商用利用・改変・再配布の条件が緩い。BF16、NVFP4、Base、DFlash2 の各リポジトリが Apache 2.0 を表示している。コミュニティ版の量子化や派生モデル（abliterated など）は、それぞれのリポジトリの表示を個別に確認したい。
Base 版（Ripple-65B-Base-Preview）は、midtraining・合成QAデータを含まない事前学習のみのチェックポイントで、チャット用途にそのまま向くものではない。ファインチューニングの素材としては、BF16 で129.57GBの重みに加え、勾配とオプティマイザの状態が必要になる点に注意したい（一般的な傾向で、実際の量は手法による）。
トラブルシューティング
- 起動時に CUDA out of memory: 重みが載っていない。形式を NVFP4 や GGUF の小さい量子化に変えるか、GPU を増やす
- 起動後に OOM: KV キャッシュが足りない。コンテキスト長（-c や --context-length）を下げる、同時リクエスト数を減らす。1M を既定にする公式サーバーは特に大きい
- llama.cpp で「unknown model architecture: ricursive」: 対応は b12167 以降。LM Studio や Ollama など、古い llama.cpp を同梱するアプリは更新を待つ
- 標準の SGLang で読み込めない: 対応 PR #48636 は未マージ。公式の serve.py（inference/server）か Spark 用の spark.py を使う
- DFlash2 が動かない・効果が出ない: ドラフトは対応する Ripple 実装（ripple-sglang 相当）とセットでのみ検証されている。公式 README も、他のターゲット版やランタイム版での互換性は保証しないと書いている
- 生成が遅い（Spark、Mac）: dense でメモリ帯域が律速になる。NVFP4 や小さい量子化にする、Spark では DFlash2 を併用する
- Q2_K で出力が壊れる: 素の Q2_K は品質が極端に悪い（mrfakename の PPL 計測）。IQ2 系や imatrix 付きの量子化を選ぶ
- ツール呼び出しで余計な引数が付く: 公式 README によると、tool_choice: "required" では strict=true と additionalProperties=false を指定する
Ripple-65B Preview の必要メモリはどれくらいですか？
重みだけで、公式の BF16 版が129.57GB、公式 NVFP4 版が57.21GBです（Hugging Face の実ファイルサイズ）。GGUF の Q4_K_M は38.80GB、Q8_0 は68.84GBです。これに KV キャッシュ（128K で約8GiB、推定）と実行時の余裕を加える必要があります。
DGX Spark で動きますか？
公式は動作を想定しており、NVFP4 版と DFlash2 ドラフトを組み合わせるノートブックを用意しています。重みは合計で約65.3GB（57.21GB＋8.08GB）で、128GB の統合メモリに収まります。同時に1リクエストのみが対象で、サンプルの既定コンテキストは131,072トークンです。Spark での公式な生成速度は確認できていません。
RTX 4090 や RTX 5090 で動かせますか？
動かせますが、ほぼ量子化が前提です。32GB の RTX 5090 ならIQ3_XXS（27.25GB）前後で短めのコンテキスト、24GB の RTX 4090 なら Q2 級（20〜24GB）まで落とす必要があり、品質は下がります（推定）。48GB 以上を確保できる2枚構成なら Q4_K_M が現実的です。
65B の dense は MoE と比べて重いのですか？
メモリ総量は数百B級の MoE より小さい一方、毎トークン65B すべての重みが読まれるため、同じメモリ帯域ならデコード速度は活性パラメータの少ない MoE に劣ります（一般的な傾向）。量子化で読む量を減らすことが速度にも効きます。
1M コンテキストは実際に使えますか？
モデルとしては1,048,576トークンに対応します。ただし KV キャッシュは config からの推定で約64GiB（1リクエスト、BF16）となり、重みと合わせると大きな GPU が必要です。公式の Spark サンプルは131,072トークンが既定です。実際に長いコンテキストで精度が保たれるかは、自分の用途で確認してください。
Terminal-Bench 2.1 の 80.5 は信頼できますか？
公式モデルカードに載る自社計測値で、第三者による再現ではありません。同じカードでも、競合の一部は Ricursive が自社の評価環境で測っており、設定次第でスコアが変わると断り書きがあります。SWE-bench Verified や MCP Atlas では競合が上回る項目もあります。自分のリポジトリでの検証を勧めます。
商用利用はできますか？
ライセンスは Apache 2.0 で、公式の各リポジトリがそう表示しています。コミュニティ版の量子化や派生モデルは、各リポジトリのライセンス表示を個別に確認してください。
この記事に関連する無料ツール（登録不要・その場で結果）
お気軽にご相談ください
お問い合わせ