推論ガード：ローカルLLM推論のためのプロキシレベルループ検出

vLLMプロキシの背後でQwen3.6 MoEを実行している開発者が、一般的な信頼性の問題に遭遇しました。それは、モデルが推論ブロック内で自身を繰り返し、トークンを消費し、エージェントを停止させる暴走推論ループです。180トークン/秒で動作する場合、20〜30秒のループでもGPU時間を浪費し、クライアントリクエストをブロックします。彼らはプロキシ層に常駐し、クライアントに到達する前にストリーミング出力に対して決定論的チェックを実施する軽量ガードを構築しました。

アーキテクチャ

クライアント → プロキシ → vLLM → モデル

プロキシは、vLLMから出ていくストリーミング応答を傍受します。モデルの重みを変更したり、2番目のLLMを呼び出したり、埋め込みや意味分析を使用したりしません。すべてのチェックは軽量で決定論的です。

チェック内容

• 推論トークン上限（努力レベルごとに設定可能）
• 繰り返し段落の検出
• スライディングウィンドウn-gram繰り返し
• 繰り返し文のフィンガープリンティング
• あいまいな開始パターン検出（「Actually, I think I’ve found it…」のようなループをキャッチ）
• 切断して続行する回復パス

回復フロー

ガードがトリガーされると、次の処理を行います。

• 上流のストリームを停止
• これまでに生成された推論をキャプチャ
• その推論を事前のアシスタントコンテキストとして組み込んでリクエストを再発行
• 継続部分では思考を無効化
• フェーズ1とフェーズ2の使用統計をマージ

vLLMのプレフィックスキャッシュが既に動作しているため、継続は事実上シームレスです。フェーズ2は通常〜50〜100msのTTFTで再開されるため、クライアントは応答が停止する代わりに、推論がそのまま最終回答に流れ込むのを確認できます。

可観測性

プロキシは各トリガーを以下の情報とともにログに記録します。

• ガードが発動したかどうか
• トリガー理由
• 使用されたトークン上限
• 推論トークン数
• マージされた合計使用量
• ストリーム終了メタデータ

結果

以前は、2000トークン以上の推論ブロックが行き詰まることが散発的に発生していました。導入後は、モデルは依然として必要に応じて推論を行いますが、暴走思考は遮断され、回答にリダイレクトされます。著者はこれを「ローカルLLM推論のためのプロキシレベルのシートベルト」と表現しています。

モデルへの外科的介入も、追加のLLM呼び出しも不要で、単にストリームの傍受、トークンカウント、ループ検出、そしてクリーンな回復パスだけです。このガードは、実際のトレースログに対してライブプロキシを通じてエンドツーエンドで検証されています。