vLLMのQwen3+ streaming parser、local agent運用の痛点へ

local LLMでは、parserの小さな修正がbenchmark以上に効くことがある。r/LocalLLaMAの投稿は、vLLM nightlyに入ったQwen3+ streaming parserを取り上げた。Qwen3.6-27Bが途中で止まる問題や、streaming tool callがchunk boundaryで壊れる問題を直す狙いだという。

これはモデル能力そのものとは別の層の問題だ。Qwen系モデルをvLLMでserveし、OpenAI互換APIとしてagent harnessへ流す場合、出力はstreaming chunkとして届く。reasoning text、XML風のtool call markup、function callの断片がparserの想定とずれると、モデルが正しい意図を出していてもagent loopは止まる。

コメント欄の反応は実務寄りだった。あるユーザーは、Qwen3.6-27BをvLLM上のagent loopで動かすたびにchunk boundary由来のtool call failureに当たり、client-side bufferingを入れるかstreamingを切るしかなかったと説明した。別のユーザーは、手動監視が減る修正として歓迎した。llama.cppやIDE連携でも似た症状があるのか、という質問も出ている。

nightly buildなので、まだ安定版の保証ではない。model variant、chat template、serve option、client harnessによって挙動は変わる。とはいえ、local coding agentを長時間走らせる人にとってparser reliabilityは周辺機能ではない。tool callが一度壊れるだけで、作業は止まり、人間が戻って状態を直す必要がある。

今回の反応は、local modelの進歩がweightsだけで決まらないことを示す。vLLM、reasoning parser、tool-call parser、streaming transport、agent harnessがすべて噛み合って初めて長い作業が続く。Qwen3+ parserへの関心は、より大きなモデルよりも、今あるモデルを途中で落とさず動かす基盤が欲しいという需要の表れだ。