CLM-8Bとは？アクションをキャッシュする判断モデルを解説

CLM-8Bの要点

CLM-8Bは、System One Modelと呼ばれる高速な判断専用モデルの一種です。質問への長い回答を生成するのではなく、「現在の状態」と「選べるアクション」を共通のベクトル空間へ変換し、最も近い組み合わせを選びます。選択肢が閉じているため、ツール選択、ルーティング、分類、best-of-Nの候補順位付けに向きます。

最大の特徴は、状態とアクションを別々のエンコーダーで処理することです。同じツール群を繰り返し使うエージェントなら、ツール説明の埋め込みを一度計算してキャッシュし、新しい状態だけを処理できます。一般的な生成LLMやJevのように、状態と候補をリクエストごとにまとめて評価する方式との差が、候補数の多い反復処理で表れます。

コードと重みはApache 2.0で公開されています。公式の従量課金APIはなく、Qwen3-8Bの埋め込みサーバーとCLMの小さな投影ヘッドを自社環境で動かします。ライセンス料やAPI単価がゼロでも、GPU、運用、監視、障害対応の費用は発生します。

この節の一次情報：CLM公式GitHub（2026年9月29日確認） ／ CLM-v0.1-8B公式モデルカード

開発元と公開背景

公開された引用情報にはJacky Kwok、Hangoo Kang、Tarun Suresh、Jon Saad-Falcon、Marco Pavone、Christopher Ré、Azalia Mirhoseiniの7名が記載されています。VentureBeatはStanfordとNVIDIAの研究者によるプロジェクトとして報じました。現時点の一次資料は公式ブログ、GitHub、モデルカードで、査読済み論文としての公開は確認できません。

CLM-8Bは、60M件のNemotron Q&Aペアで事前学習し、30M件の合成ハードネガティブで中間学習、1M件のエージェント軌跡で事後学習したと説明されています。これは公開チームによる学習レシピです。データ全体の品質、重複、再現に必要な計算量を第三者が独立に監査した結果ではありません。

Jevが広めたSystem One Modelというカテゴリに対し、CLMは対照学習と分離キャッシュを持ち込みました。新しい巨大モデルというより、生成を必要としない判断だけを、埋め込み検索に近い計算へ置き換えるための推論方式と見るのが正確です。

この節の一次情報：公式GitHub｜Citation・ライセンス ／ VentureBeat｜Stanford・NVIDIAのCLM-8B

技術的な仕組み：状態とアクションを別々に埋め込む

学習時は、正しい状態とアクションの組を近づけ、誤った組を遠ざける双方向InfoNCEを使います。推論時は状態エンコーダーが現在の文脈を、アクションエンコーダーが候補の説明をベクトルへ変換し、内積で類似度を計算します。最後に候補間のsoftmaxを取り、Choice、Noul、Scoreなどの型付き結果を返します。

各エンコーダーは凍結したLLMバックボーンと約20Mパラメータの学習可能な投影ヘッドで構成されます。新しいテキストには埋め込み計算が必要ですが、既にキャッシュした候補は内積だけで再利用できます。例えば100種類の社内ツールが毎回同じなら、100個のツール説明を各リクエストで再計算する必要がありません。

この構造はCLIPや密ベクトル検索に近い考え方です。ただし検索文書ではなく、エージェントの状態と実行可能なアクションの対応を学びます。候補集合が安定し、同じアクションが多くの状態で再利用されるほど、キャッシュの効果が大きくなります。反対に毎回候補が変わる処理では、両側の埋め込み計算が必要になり、優位性は小さくなります。

この節の一次情報：公式GitHub｜How it works ／ Sanity｜CLMの仕組みと制約

Jev・生成LLMとの違い

生成LLMは、分類だけが必要でもプロンプトを読み、答えのトークンを生成します。Jevは文章生成を避けて型付きの判断を返しますが、状態と候補を共同で評価するクローズドAPIです。CLMはさらに状態側とアクション側を分離し、候補の埋め込みを事前計算できる点が異なります。

CLMが常にJevを置き換えるわけではありません。公開チームのゼロショット評価では、BFCL v4のツール呼び出しでCLMが95.2%、Jevが99.2%、WikiRacingはCLMが26/30、Jevが30/30でした。長文もJevが最大64Kトークンを扱うのに対し、CLMの参照ヘッドは2K〜8Kでの利用が中心です。

CLMの確率は、渡した候補集合の中での相対値です。候補を追加・削除するとsoftmaxの分母が変わるため、0.9という値を異なる候補集合の間でそのまま比較できません。絶対的なリスク判定や候補外の異常検知には、しきい値校正、Noul、別の検証器が必要です。

この節の一次情報：VentureBeat｜CLMとJevの比較 ／ LocalLLaMA｜実装議論と制約

速度・精度：最大9倍をどう読むか

公式は、コンピューター操作、ゲーム、ツール呼び出しでJevと同等水準、最大9倍低遅延としています。海外の技術解説が公式グラフを精査した結果では、T-RexでCLMが16.5ms、Jevが149.8msでした。一方、他の条件ではおおむね1.6〜4倍で、「9倍」は全タスクの平均ではありません。

候補約1,000件を使うモデルカードの測定では最大13倍という主張もあります。候補数が増えるほど、候補埋め込みを使い回す設計が効くためです。逆に、毎回まったく新しい状態と候補を計算する処理ではキャッシュの恩恵が限定されます。公式GitHubのRTX 4090測定でも、状態を再訪するループは約2.8倍高速でしたが、新しい状態だけのループでは差が小さくなりました。

微調整した検証器ではTerminal-Bench 2.1で87.6%、DeepSWEで81.6%と報告されています。ただし評価対象はそれぞれ30件と38件で、公開チーム自身の測定です。独立した再現実験はまだ不足しており、最高性能の一般モデルと断定できません。速度はハードウェア、候補数、キャッシュ命中率、バッチ、ネットワークを揃えて測る必要があります。

この節の一次情報：公式GitHub｜ベンチマークとキャッシュ測定 ／ ExplainX｜ベンチマーク条件の検証

API仕様・料金・導入方法

公式パッケージはTypeSafe互換のPOST /v1/systemone、GET /v1/models、GET /healthを提供します。PythonクライアントではChoiceで候補選択、Noulで候補なしを含む判断、Scoreで数値評価を扱えます。候補列を渡して順位付けする用途にも使えます。

標準構成は、GPU上のvLLMでQwen3-8Bを埋め込みサーバーとして動かし、CPU側のclm-serveが状態・アクション用ヘッドとキャッシュを管理します。投影ヘッドのチェックポイントは約75MBですが、バックボーンのQwen3-8BとGPUメモリは別に必要です。既定では2,048トークンを超える状態を切り詰め、メモリに余裕があれば8,192へ上げられます。

公式ホストAPIと従量料金は2026年9月29日時点でありません。したがって『API料金ゼロ』ではなく、セルフホスト費用へ置き換わります。比較時はGPU時間、アイドル率、冗長化、キャッシュメモリ、監視、更新、人件費を合算してください。既存のGPU基盤と安定した大量トラフィックがある場合は有利ですが、小規模・断続利用では従量APIの方が総額を抑えやすい可能性があります。

• Python 3.10以降とNVIDIA GPUを用意する
• Qwen3-8Bをlast-token poolingの埋め込みサーバーとして起動する
• CLMヘッドを取得しclm-serveを起動する
• Choice／Noul／Scoreと候補順位付けを既存処理へ接続する
• 自社タスクで精度、p95遅延、キャッシュ命中率、GPU原価を測る

この節の一次情報：公式GitHub｜Installation・API Reference ／ 公式モデルカード｜利用例

利用例と日本で広がる可能性

現実的な用途は、AIエージェントが多数のツールから次の1つを選ぶ場面、問い合わせを専門モデルへ振り分けるルーティング、複数の生成候補から最良案を選ぶ検証器、検索候補の絞り込み、ゲームやロボットの離散行動選択です。いずれも候補を明示でき、同じ候補集合を何度も使う点が共通します。

日本で後から検索需要が生まれる可能性がある理由は、AIエージェントの実装が「何を生成するか」から「どのツールを選ぶか」「どの候補を採用するか」へ広がっているためです。生成トークンを削るだけでなく、候補側の推論をキャッシュするCLMは、トークン課金では説明しにくいエージェント原価を扱う新しい設計パターンになります。

海外では公開から数日でGitHubが2,300スター・200フォークに到達し、Hugging Faceのモデルにも約500件の反応がありました。VentureBeatの報道に加え、ExplainXとSanityが仕組みや限界を解説し、LocalLLaMAでは量子化モデルをllama.cppで動かす手順まで議論されています。公式発表の転載だけでなく、実装へ進む独立シグナルが複数あります。

この節の一次情報：GitHub｜CLMリポジトリ ／ VentureBeat｜独立報道 ／ Sanity｜CLM解説

導入に向くケース・向かないケース

向くのは、候補集合が閉じていて安定し、同じツールやアクションを大量の状態で再利用する処理です。大量のツールを持つ社内エージェント、低遅延が必要なゲーム・操作エージェント、候補を何度も採点する検証器では、分離キャッシュが原価と待ち時間の両方に効く可能性があります。

自由文の生成、説明、複雑な多段推論が必要な仕事には向きません。候補が毎回変わる、候補外の答えが多い、64K級の長文が必要、GPU運用体制がない場合も優位性が薄れます。誤選択の損失が大きい処理では、CLMだけで実行せず、しきい値、Noul、人手承認、強い生成モデルによる再判定を残します。

導入判断では、Jevや軽量生成モデルと同じタスクセットで比較します。候補数、キャッシュ命中率、入力長を本番に合わせ、正解率だけでなくp50・p95遅延、GPU稼働率、1判断当たり総原価、候補外回答の検出率を測ります。公開ベンチマークの最大値だけで採用しないことが重要です。

• 向く：候補が固定されたツール選択・モデルルーティング
• 向く：同じ候補を大量に再評価するbest-of-N検証
• 向く：GPU基盤を持ち、セルフホスト要件がある組織
• 向かない：自由文生成や複雑な説明が主目的
• 向かない：候補集合が毎回変わりキャッシュできない処理
• 向かない：長文・広いゼロショット知識・絶対確率が必須

制約・未検証事項

CLM-v0.1-8Bは公開直後です。査読済み論文、第三者による大規模な再現評価、日本語タスクの精度、混雑時の長期安定性、実運用のGPU総原価は確認できません。公式の最大9倍、最大13倍、検証器スコアは公開チームの条件に依存します。

参照ヘッドは2K〜8Kの文脈が中心で、長文をそのまま入れる設計ではありません。候補確率は集合内の相対値で、候補を変えると値も変わります。また、オープンウェイトでも学習データやバックボーンの利用条件、入力データの保護、脆弱性対応、ライセンス適合性を導入側で確認する必要があります。

アクションキャッシュは候補説明を更新したときに無効化が必要です。古いツール仕様の埋め込みを残すと誤選択につながります。候補のバージョン、埋め込みモデル、ヘッド、キャッシュキーを一緒に管理し、更新時に再計算する運用設計が必要です。

FAQ

Q. CLM-8BはLLMですか？　A. Qwen3-8Bを凍結バックボーンとして使いますが、目的は文章生成ではなく、状態と候補アクションを埋め込んで選択・順位付けすることです。

Q. Jevより常に9倍速いですか？　A. いいえ。9倍はT-Rexなど特定条件の開発元測定です。他の条件は1.6〜4倍程度で、候補再利用が少ない処理では差が小さくなります。

Q. API料金はいくらですか？　A. 公式のホストAPIはなく、コードと重みをApache 2.0で利用します。従量料金はありませんが、Qwen3-8Bを動かすGPU、監視、冗長化、人件費がかかります。

Q. 日本語で使えますか？　A. 多言語バックボーンを使うため日本語入力は可能と考えられますが、2026年9月29日時点で日本語の独立評価は確認できません。自社の候補説明と状態で検証が必要です。

Q. どんなAPIを使えますか？　A. TypeSafe互換の/v1/systemoneと、Choice、Noul、Score、候補順位付けを提供します。既存のJev検証環境を比較に流用しやすい設計です。

Q. 微調整はできますか？　A. 可能です。凍結したバックボーン全体ではなく小さな投影ヘッドを学習するため、フルファインチューニングより軽量です。ただしデータ設計と評価は必要です。

Q. 生成LLMを完全に置き換えられますか？　A. 置き換えられません。候補選択や検証をCLMへ分け、自由文生成と複雑推論は生成LLMへ残す構成が現実的です。