DeepSeek V4.1 Flashのツール呼び出しがvLLMに登場：空白入りタグが壊したもの

DeepSeek V4.1 Flashは2026年9月10日から一般提供されており、その誕生から最初の12日間、このモデルには誰も書かなかったギャップがありました。推論でき、画像を見ることができ、100万トークンのコンテキストを保持できましたが、最も広く使われているオープンなサービングスタックを通じてツールを確実に呼び出すことはできませんでした。そのギャップは今、vLLMで解消されました — 設定フラグによってではなく、パーサーの書き換えによってです。2つのプルリクエストがその作業を担っており、それらが必要とされた理由こそが興味深い部分です。

要約すると、DeepSeek V4.1 Flash はツール呼び出しを、既存の DeepSeek V4 検出器が認識しないタグ形式で出力します。そのため、標準の vLLM デプロイでは、ツール呼び出しのマークアップが構造化出力ではなく通常のテキストとして届きます。エラーは出ません。モデルが単に関数の呼び出しを拒否しただけのように見えます。自己ホスト型の DeepSeek V4.1 Flash に対してエージェントループをテストしていて、モデルはツールが苦手だと結論づけていたなら、おそらくこれが目にしていたものだと思われます。

サービングスタックで実際に何が変わったのか

DeepSeekモデル向けのvLLMのツール呼び出し解析は、しばらくの間、Pythonフロントエンドと、より新しいRustフロントエンドという2つの場所に存在しており、文法レベルの作業はXGrammarプロジェクトに委譲されていました。V4.1 Flashサポートを導入することは、XGrammar内のC++deepseek_xml変換をRustビルダーへ移植し、その後、モデル独自のエンコーディングをvLLMのトークナイザーディレクトリに組み込むことを意味していました。

• Rustフロントエンドの作業はPR #56235で、XGrammar C++のdeepseek_xml変換をRustビルダーに移植するものです。V4.1専用の新規テストを18件追加しており、既存の全スイート — vllm-parserの472件とvllm-chatの326件 — もグリーンのままです。

• Pythonフロントエンドの作業はPR #56408で、まだドラフトの状態です。これは上流のXGrammarの変更（mlc-ai/xgrammar#885）が先に取り込まれることに依存しており、その依存関係を適用した状態で110件のテストが成功したと報告されています。

• 新しいエンコーディングモジュールはvllm/tokenizers/deepseek_v41_encoding.pyです — V4エンコーディング内の分岐ではなく独立したファイルになっており、このことはタグ文法が単に拡張されたのではなく、本当に異なっていることを示しています。

• 呼び出しは明示的に行います：--tool-parser deepseek_v41。黙って正しいことをしてくれる自動検出のフォールバックはありません。

間隔を空けたタグがすべてを物語っている

新しいパーサーが、拡張された正規表現ではなく存在する理由は、空白文字にあります。DeepSeek V4.1 Flash は、DSML ツールタグをトークン間にスペースを入れて書き出します。V4 検出器のパターンはスペースなしの形式を想定しているため、マッチに失敗します。そして、ツール呼び出しパーサーにおけるマッチの失敗は設計上サイレントです——例外を送出するのではなく、テキストはコンテンツとしてそのまま渡されます。

その失敗モードは、最もコストがかかる種類だからこそ、じっくり考える価値がある。例外を投げるパーサーなら、午後には修正される。呼び出し側が一切求めていないマークアップを含む、整形式の文字列を返すパーサーは、モデル品質の問題のように見える。そしてチームは、モデル品質の問題に反応するのと同じように反応する。別のプロンプトを試し、例を追加し、モデルを切り替えるのだ。12日あれば、そうしたことが非公開でかなり行われていてもおかしくない。

また、それは修正が調整用のつまみではないことも意味する。モデルの出力形式に合わない検出器から、プロンプトで抜け出すことはできない。また、クライアント側で後処理して修正することもできない。テキストがクライアントに届く頃には、構造はすでに失われているからだ。それはサービングスタックで行われる必要があり、まさに今、そこにある。

これがV4の場合よりもV4.1 Flashにとって重要である理由

ツール呼び出しは、この特定のモデルにとっては「あると嬉しい」程度のものではありません。DeepSeek V4.1 Flashは、5520億パラメータのMixture-of-Expertsモデルであり、入力時に80億パラメータ、出力時に160億パラメータがアクティブで、コンテキストウィンドウは100万トークン、最大出力は38万4千トークンです。このアクティブパラメータの分割が証拠です。このモデルは、大きな入力（リポジトリ、ドキュメントセット、長いツールトレースなど）を受け取り、長い構造化された応答を出力するように作られています。これはエージェントの形であり、チャットの形ではありません。

ローンチ仕様の残りの部分も同じ方向を指し示している。MITライセンスの重み、トークンあたり890バイトのKVキャッシュ、45兆の事前学習トークン、ネイティブビジョン。100万コンテキストにおいて運用上重要なのはKVキャッシュの数値であり、長いエージェントのトランスクリプトを常駐させておくのを手頃なコストにするのはこれだ。そして、より高価なモデルが監督するループにおいて、このモデルが安価なワーカーとして現実的である理由もそこにある。

このことが、12日間のツール呼び出しギャップを脚注ではなく実際のコストにしている。エージェントパイプラインで大量実行を担うことを経済的根拠とするモデルは、パイプラインがそこから構造化された呼び出しを引き出せなければ、ほとんど価値がない。

何がまだ未解決ですか

2026年9月22日時点での、正直な現状：

• Rustフロントエンドのパス（PR #56235）は、新しいV4.1のケースと既存のテストスイートの両方で完全なテストカバレッジを備えているものです。それを含むvLLMビルドをお使いであれば、そのパーサーは今日から利用できます。

• Pythonフロントエンドの経路（PR #56408）はドラフトであり、外部依存関係があります。XGrammarの変更以前のビルドに固定されている場合、PythonフロントエンドではまだV4.1のツールパースを利用できません。

• 呼び出しが明示的に行われるため、vLLM をアップグレードしても起動フラグを変更しないデプロイメントでは、以前の動作がそのまま維持されます。パーサーが存在することと、そのパーサーが実際に使用されることは別物です。

• 新しいパーサーを導入したV4.1 Flashに対して、独立したツール呼び出しベンチマークを実行したという公開証拠はまだない。分かっているのは、配管が機能し、テストが通っているということだ。モデルのツール呼び出し品質が良いかどうかは、マージが答えない別の問題である。

その最後の点こそ、肝に銘じるべき点だ。パーサーの修正は、モデルを「評価できない」状態から「評価できる」状態へと移す。それは判定の前提条件であり、判定そのものではない。

サービングスタックを自分で実行したくない場合は

もっと短い道があります。DeepSeek V4.1 Flash は OrcaRouter の専用エンドポイントから利用できるため、ツール呼び出しの挙動はビルド上の問題ではなく、通常の API 呼び出しとして得られます。XGrammar のバージョンを合わせる必要も、フロントエンドを選ぶ必要も、起動フラグを覚えておく必要もありません。これがここで特に重要なのは、修正が成熟度の異なる2か所に投入されており、ホスト型エンドポイントならその選択が不要になるからです。

同じキーは、比較対象となる残りのモデルにも届きます。これは、「このパーサーは正しいか」ではなく「このモデルは自分のループにとって十分に良いか」という問いを立てるときに役立つ特性です。DeepSeek V4.1 Flash を安価な実行者としてルーティングルールの背後に置き、呼び出しが失敗したときには、2つ目の契約や2つ目の SDK を用意することなく、より強力なモデルへフェイルオーバーさせることができます。ツール呼び出しへの対応がわずか2週間前のモデルを試すことこそ、自動フェイルオーバーが存在するまさにその状況です。

次に見るもの

3つのことがあれば、これは配管の話から評決へと変わる：

• ドラフトから出る PR #56408 は、Python フロントエンドの道筋を現実のものとし、二層サポートの状況に終止符を打つことになります。

• 固定されたサービングスタック上で V4.1 Flash に対して実行された、独立したエージェントまたはツール呼び出しの評価。このモデルはリリースされてから12日しか経っておらず、パーサーが使用可能になってからはそれ未満なので、今このモデルについて引用されているツール呼び出しスコアを見かけたら、その前提を尋ねる価値がある — セットアップはモデルと同じくらい重要だ。

• 他のサービングスタックが追随するかどうか。公開された PR があるのは vLLM だけだが、スペース入りタグの問題は vLLM 固有のものではない。したがって、V4.1 の出力から再導出することなく V4 検出器を採用したスタックは、どこも同じサイレント障害を抱えていることになる。

それらの最初のものが実現するまでは、正確な要約は限定的であり、率直に述べておく価値がある。DeepSeek V4.1 Flash は MIT ウェイトを備えた GA モデルで、1M コンテキストと 384K の出力上限を持ち、そのツール呼び出しは現在、明示的なパーサー フラグを使って vLLM の Rust パスで動作する。それは確かな一歩であり、まだ結果ではない。