llama.cppに「出力トークンゼロ」の分類特化モデルが登場 — ルーティングや感情判定を3msで処理、テキスト生成なしで分類に特化

10月2日、Hugging Face傘下のggml-orgが「New in llama.cpp: Decision Models」と題した記事を公開した。llama.cppサーバーに新たに追加された「Decision Models（決定モデル）」のAPIと対応モデル群について詳しく紹介している。

Decision Modelとは何か

通常のチャットモデルはトークンを1つずつ生成するため、出力のパースも必要になる。Decision Modelはその逆の発想で、選択肢を渡すと1回のフォワードパスで各オプションの確率を返す。テキスト生成をしないため、出力トークン数はゼロだ。

典型的な用途として記事が挙げているのは以下の4つである：

リクエストのルーティング
コンテンツモデレーション
エージェントのステップ検証
エージェントの次のアクション選択

テキスト生成モデルと比べて応答が極めて速く、後述するように小型モデルでは3〜5msという応答時間を実現している。

`/v1/systemone` エンドポイント

PR #29818で実装されたこの機能は、TypeSafeのJevモデルで導入されたSystem Oneフォーマットに準拠している。既存クライアントはベースURLを変えるだけで利用可能だ。

質問には3つのタイプがある：

タイプ	送るもの	返るもの
choice	選択肢（説明付き可）	最上位の選択肢＋各確率
score	2〜10段階のレベル（低い順）	期待値（2段階の間になることもある）
noul	Yes/Noの質問	Yesの確率

実際のリクエスト例を見ると、1回のAPIコールで複数の質問を同時に投げられる：

curl http://localhost:8080/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Customer message: I was charged twice for my order last week and nobody has replied.",
    "questions": {
      "route": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "payments, charges, refunds, invoices",
          "shipping": "delivery, tracking, lost or late parcels",
          "technical": "bugs, errors, login problems"
        }
      },
      "angry": {
        "type": "noul",
        "instructions": "Is the customer angry?"
      },
      "urgency": {
        "type": "score",
        "instructions": "How urgent is this?",
        "criteria": ["can wait", "this week", "today", "right now"]
      }
    }
  }'

レスポンスはこうなる：

{
  "model": "ggml-org/Kev-4B-GGUF",
  "answers": {
    "route": {
      "type": "choice",
      "choice": "billing",
      "probabilities": {"billing": 0.9049, "shipping": 0.0275, "technical": 0.0676},
      "confidence": 0.8574
    },
    "angry": {
      "type": "noul",
      "noul": 0.8208
    },
    "urgency": {
      "type": "score",
      "score": 2.2821,
      "legend": {"0": "can wait", "1": "this week", "2": "today", "3": "right now"},
      "probabilities": {"0": 0.036, "1": 0.1937, "2": 0.2225, "3": 0.5478},
      "confidence": 0.2821
    }
  },
  "usage": {"input_tokens": 130, "output_tokens": 0}
}

output_tokens: 0 が象徴的だ。ルーティング・感情判定・緊急度スコアリングを、テキスト生成なしで1回のリクエストに束ねられる。

対応モデルと速度

現時点で以下の5モデルが利用可能だ。計測環境はNVIDIA RTX PRO 6000。

モデル	サイズ	ベース	言語	画像	応答時間
Julia-1	144M	mmBERT-small	50言語以上	なし	3ms
Laya	421M	ModernBERT-large	英語	なし	5ms
Kev-4B	4B	Qwen3.5-4B-Base	英語	なし	12ms
lev	4B	Qwen3.5-4B	英語	なし	36ms
OpenJev	27B	Qwen3.8-27B	英・独・仏・ヒンディー・中・日	あり	43ms

※ベースモデル欄の「Qwen3.5-4B-Base」「Qwen3.8-27B」は元記事に記載されているモデル名をそのまま使用している。一般に流通しているQwenのバージョン体系（2.5、3など）とは異なる表記だが、元記事の記述に従った。

画像入力に対応しているのは現時点でOpenJevのみだ。ドキュメントのスクリーンショットを渡して分類するといった使い方ができる。なお、ビジョン用プロジェクターは自動でダウンロードされる。

モデルの比較はDecision Indexでも確認できる。

実用上のTips

記事が明示しているポイントをいくつか抜粋する。

選択肢には説明を付ける。Julia-1でラベルだけ渡した場合、「二重請求」のメッセージがshippingにルーティングされたが、各選択肢に説明を付けるとbilling（確率0.99）に正しく振り分けられた。説明の有無が精度に直結するため、criteriaフィールドの活用は基本的な作法となる。

信頼度のカットオフはモデルごとに調整する。「Hi, quick question about my account」という曖昧なチケットはJulia-1では信頼度0.25だったが、Kev-4Bでは0.80になった。モデルによって出力の分布が異なるため、自分のデータで検証してからカットオフを決めるべきである。

複数の質問はまとめて送る。Kev-4B、lev、OpenJevはstateを一度だけ処理するため、質問を分けてリクエストを送るより効率が良い。