【geek-terminalニュース】決定モデル波の最新情報：llama.cpp、Cloudflare Clef、Strands Deciderがエージェントの心臓を置き換え始めた

【事象の全貌と背景】
以前お伝えしたJev/OpenJevやCLM-8B系の続報です。今回の主役は、文章を長々と生成するLLMではなく、選択肢、Yes/No、順序尺度に対して確率を返す「決定モデル」の波です。ポイントは、AIエージェントの中核がチャットモデルの作文能力から、実行してよいか、どの経路へ流すか、次に何を選ぶかを裁く小型の判定器へ移り始めていることです。

確認できる範囲では、llama.cppは2026年10月2日に`/v1/systemone`エンドポイント対応を発表しました。これはstateとしてテキスト、JSON、スクリーンショットなどを渡し、型付き質問を投げると、選択肢ごとの確率を返すAPIです。Jevが導入したSystem One形式に合わせているため、既存クライアントはbase URL変更で利用できると説明されています。ここで重要なのは、出力が自由文ではなく、構造化されたラベル、確率、スコアである点です。つまり「それっぽい説明」ではなく、ルーター、モデレーター、権限ゲート、手順検証器としてLLMを差し込む方向です。

この動きにCloudflareのClef/Clef-flash、AWS Strands LabsのStrands Decider 2Bが重なりました。CloudflareはClef 27BとClef-flash 9BをApache 2.0のオープンウェイト決定モデルとして出し、Workers AIとHugging Faceで提供すると報じられています。Strands Decider 2Bも1.9Bパラメータのオープンソース決定モデルとして、テキスト生成をせず、choice、noul、scoreを返す設計です。Jev式の発想が単発の研究ネタから、ローカルランタイム、エッジ基盤、OSSパッケージへ広がったのが今回の新しさです。

【技術的ディープダイブ】
llama.cpp側で公式に示された対応モデルはJulia-1 144M、Laya 421M、Kev-4B、lev 4B、OpenJev 27Bです。RTX PRO 6000上で1問に答える中央値は、それぞれ3ms、5ms、12ms、36ms、43msとされています。質問型は`choice`、`score`、`noul`の3種類で、顧客メッセージを担当チームへ振り分ける、怒っているかを判定する、緊急度を尺度で返す、といった用途が例示されています。API例ではusageのoutput_tokensが0になっており、ここが象徴的です。文章を吐かないLLM、つまり「生成しない推論器」です。

ただしRuntimeWireの整理では、これは全GGUFモデルが突然typed-decision対応になる話ではありません。Laya、Julia-1、Lev、OpenJev、Kevなど対象モデルごとに変換、メタデータ、サーバ処理が必要で、返された確率が自社業務で校正済みかどうかは別問題です。確率が出ることと、その確率が現実の正答率をきれいに表すことは違います。実運用ではconfidenceと実正答率のキャリブレーション検証が必要になります。

Strands Decider 2Bは、Qwen3.5-2B-Baseを土台に言語モデリングヘッドを外し、約100万パラメータのpointer headを追加する構成と説明されています。``位置のhidden stateと各選択肢末尾トークンのhidden stateを比較し、1回のforward passで結果を出す設計です。公開値ではJevBench v1 public accuracyが0.723、231タスク中167、Brier score 0.342、ECE 0.052、RTX 3090で中央値115ms、p95 299ms、M3 Proでウォーム中央値153msとされています。

CloudflareのClef系は、ClefがQwen3.8-27B、Clef-flashがQwen3.5-9Bをベースにし、backboneのprefill後にjoint schema headが複数質問の情報を合わせて確率を出す構成と報じられています。Cloudflare報告の中央値はClef 209.3ms、Clef-flash 38.8ms、Jev 524.1msです。Workers AI上では1リクエスト最大64質問、最大4画像、64Kコンテキスト、テキスト・JSON・画像・動画対応がうたわれています。ただしMarkTechPostは、これらのベンチ値がvendor-reportedで独立再現はまだないこと、GPQA Diamond、MMLU-Pro、BBHのような知識重視テストではJevがClefを上回る例もあることを明記しています。

【コミュニティの生々しい熱量と議論】
今回、検索結果2のコミュニティ反応欄は空でした。ただし検索結果1に含まれるRedditのLocalLLaMAスレッド由来の整理では、反応はかなりギーク寄りです。まず目立つのは「Jev風モデルが短期間でコモディティ化した」という見方です。数週間前まで新奇に見えたtyped probability routingが、llama.cpp、Cloudflare、AWS周辺まで広がるなら、決定モデルは独自APIというより共通部品になるのではないか、という温度感です。

一方で冷静な反応もあります。これは魔法ではなく、既存の分類、候補スコアリング、reranking、ロジット比較の延長だという見方です。特にHugging Face forumのllama-modesは、専用決定モデルではなく通常のGGUFを1回ロードし、BOOLEAN、CHOICE、SCALEを同じ重みで動かす実験だと説明されています。Jev式の校正済み確率を主張するものではなく、候補スコアリングをllama.cppの再利用可能なruntime primitiveにしたい、という立場です。この温度差が面白いところで、片方は「エージェントの神経系が来た」と見ており、もう片方は「昔からある分類をLLMランタイムに正しく載せただけ」と見ています。

さらに、LLMルーター、ロールプレイ制御、モデレーション、エージェントの次アクション選択への応用可能性も議論されています。たとえば、巨大チャットモデルに毎回「次に何をすべきか説明して」と聞く代わりに、小型判定器へ「このtoolを呼ぶべきか」「人間承認が必要か」「この会話は危険側へ寄っているか」を確率で聞く。ここには、プロンプト芸から実行制御へ、AIエージェント開発の重心が移る匂いがあります。LibLayaXやawesome-jev-use-casesのような周辺リポジトリも観測されており、真偽や成熟度は個別確認が必要ですが、少なくともコミュニティがユースケース集と実装部品を集め始めていることは、この領域の熱量を示しています。

【今後の展望とエコシステムへの影響】
この流れで一番オワコン化しそうなのは、何でも巨大チャットモデルに自由文で判断させる雑なエージェント設計です。もちろん最終的な推論や説明生成には大規模モデルが残ります。しかし、実行可否、ルーティング、権限昇格、人間承認、ツール選択、失敗時の分岐まで全部を同じチャットモデルに背負わせる設計は、コスト、遅延、監査性の面で苦しくなります。

代わりに台頭するのは、チャットモデルを「思考と生成」、決定モデルを「制御と分岐」に分ける構成です。小型のJulia-1やLayaが数msで走り、CloudflareのClef-flashがエッジで確率判定し、Strands Decider 2BがローカルCPUやApple siliconでも動くなら、エージェント基盤は毎ステップに軽量な判定層を挟めるようになります。これはセキュリティにも効きます。プロンプトインジェクション対策を「モデルに気をつけろと言う」だけでなく、実行前に別の判定器でtool call、データ持ち出し、承認要否をスコアリングする方向へ押し下げられるからです。

ただし、決定モデルにも過信は禁物です。確率が返るUIは安心感を与えますが、校正されていない確率はただの見た目の精密さです。Cloudflare系の速度ベンチも現時点ではvendor-reportedで、業務ドメインごとの再現性、キャリブレーション、拒否すべき場面での保守性は別途検証が必要です。それでも、Jev形式のtyped-decision APIがllama.cpp、Strands、Clefへ横断してきた意味は大きい。エージェントの心臓部は、チャット欄で饒舌に語るモデルから、ミリ秒単位で型付き確率を返す小さな判定器へ分岐し始めました。今回の決定モデル波は、AIを「文章屋」から「実行基盤の制御部品」へ変える、地味だがかなり深いパラダイムシフトです。