vLLMの制約付きデコーディングにより、KimiとDeepSeekのツール呼び出し精度が100%に向上

要点

vLLM 0.31で導入された制約付きデコーディングフラグを有効にすることで、Kimi K2.6とDeepSeek V4 Flashのツール呼び出しスキーマ準拠率が100%保証され、以前は精度が92%に低下していた不正な呼び出しが排除されました。

ツール呼び出しスキーマ精度が重要な理由

  • ツール呼び出しは、モデルに提示されたJSONスキーマに従う必要があります。逸脱すると呼び出しが失敗し、コンテキストウィンドウを汚染します。
  • マルチターンのエージェントワークロードでは、1回の不正な呼び出しがリトライを強制し、レイテンシを増加させ、モデル全体の品質を低下させます。
  • Moonshot AIのK2VV ToolCallベンチマークは、2つの主要な指標を測定します。
    • トリガー類似度 – サービスが参照実装と比較してツールを呼び出す頻度。
    • スキーマ精度 – 生成された呼び出しのうち、宣言されたスキーマに準拠する割合。スキーマ精度が50%の場合、全呼び出しの半分が使用不可になります。
  • UbicloudがvLLM 0.28でKimi K2.6を提供したとき、スキーマ精度はわずか92%（25回の呼び出し中2回失敗）であり、本番エージェントには許容できませんでした。

制約付きデコーディング：仕組み

  • 標準デコーディングでは、モデルが確率に基づいて任意のトークンをサンプリングできるため、構文的に無効なJSONが生成される可能性があります。
  • 制約付きデコーディングでは、各生成ステップで、ツールのJSONスキーマに従って出力を有効に保つトークンのみにトークンセットを制限します。
  • vLLMはこれをXGrammar構造タグを使用して実装しています。文法は決定的なシーケンスを定義します。
    1. <|tool_call_begin|>{function.name}:{index}
    2. <|tool_call_argument_begin|>
    3. JSONSchemaFormat – 提供されたスキーマに準拠するJSONを生成します。
    4. <|tool_call_end|>
  • 無効なトークンはオンザフライでマスクされ、マスクは各フェーズで事前計算されるため、GPUは無視できるオーバーヘッドで適用できます。

「これにより、スキーマ精度はベストエフォート方式から実行時保証に変わります。モデルは依然としてどのトークンを生成するかを決定しますが、現在はトークンが制限された構文的に正しいセットから選択されます。」 – Ubicloudブログ

vLLM 0.31で変更された点

  • 制約付きデコーディングは、vLLM 0.31でサーバーサイドフラグ（--tool-strict-level）として追加されました。
  • 0.31より前では、この機能は以前のリリース（例：0.25）に存在しましたが、期待されるツール呼び出し形式に従わないモデルでのリグレッションを回避するため、ほとんどのモデルでデフォルトで無効でした。
  • KimiとDeepSeekでフラグを有効にすると、エンジンがXGrammarマスクを適用し、K2VVベンチマークでスキーマ精度が**100%**に向上しました。

デフォルトが無効だった理由

  • vLLMは多種多様なモデルを提供しています。一部のモデル（例：gpt-oss-20b、Qwen 3.6、GLM 5.1）は期待される形式から逸脱するツール呼び出しを生成し、制約付きデコーディングが過剰にトークンを拒否してパフォーマンスを低下させる可能性があります。
  • 3つのカテゴリの問題が特定されました。
    1. 一般的なモデルの問題 – モデルが制約なしで期待されるスキーマから逸脱する。
    2. 文法変換のバグ – モデルのツールスキーマをXGrammarタグに変換する際のエラー。
    3. 機能相互作用のバグ – 例：制約付きデコーディングと投機的デコーディングの競合により、有効なトークンが誤ってマスクされる。
  • これらのリグレッションのため、vLLMのメンテナはモデルに依存しないデフォルトとして制約付きデコーディングを無効にすることを選択し、厳格な強制が必要なユーザー向けに明示的な--tool-strict-levelフラグを導入しました。

コミュニティの洞察

「制約付きデコーディングはvLLMに長い間存在し、制約付きツール呼び出しデコーディングもvLLMにしばらく存在しています。ブログ投稿はかなり紛らわしいです。全体の状況を理解するまで、vLLMを修正した（タイトルが示唆するように）ように見えますが、実際には正しく設定する必要があっただけです。」 – @Aurornis（HNコメント）

  • 議論は、実際の修正は設定であり、コード変更ではないことを強調し、リグレッションを検出したベンチマークを維持したUbicloudを評価しています。
  • 他のコメンテーターは、制約付きデコーディングが他のランタイム（例：llama.cpp、HuggingFace transformers.js）で一般的になりつつあり、100%のツール呼び出し精度が本番エージェントのベースライン期待であると指摘しています。

デプロイメントのための実践的ガイダンス

  1. フラグを有効にする 安定したツール呼び出し形式を持つモデル（例：Kimi K2.6、DeepSeek V4 Flash）を提供する場合：
    vllm serve model_path --tool-strict-level=2   # またはvLLMドキュメントに従って適切なレベル
  2. ベンチマークで検証する Moonshot AIのK2VV ToolCallなどのベンチマークを使用して、エンジンアップグレード後もスキーマ精度が100%に維持されることを確認します。
  3. モデル固有のリグレッションを監視する 制約付きデコーディングでモデルのパフォーマンスが低下する場合は、そのモデルにのみフラグを無効にすることを検討します。
  4. XGrammar定義を最新に保つ ツールを追加または名前変更するときは、文法がモデルが使用する正確なJSONスキーマを反映している必要があります。

結論

ツール呼び出しスキーマ精度は、エージェント型LLMの品質を決定する重要な要素です。vLLM 0.31の制約付きデコーディングを有効にすることで、Ubicloudは不正なツール呼び出しを排除し、KimiおよびDeepSeekモデルのベンチマーク精度を92%から**100%**に向上させました。これは、推論エンジンの設定が、信頼性の高い高品質なAIサービスを提供するためにモデル選択と同じくらい重要であることを示しています。

Sources