Qwopus3.6-27B-v2 から Qwen3.6-27B へ：安定稼働への回帰

【プロローグ】 より優秀な「エージェントの脳」を求めて

GB10環境上の Qwen3.6-27B-FP8 が MTP（複数トークン並列予測）により安定した高速推論を実現し、システムは安定期に入っていた。 しかし、MCSM-Agent の Operator（実行役）として自律ループを回す上で、「より論理推論とコーディングに特化した、賢いモデルはないか」と探求を続けるのはエンジニアの性である。

そこで目を付けたのが、推論能力（Reasoning）とツール呼び出し（Tool-use）に特化してファインチューニングされた派生モデル群だった。最初は Qwopus3.6-27B-Coder を試したが、汎用の Operator としては少し厳しかった。続けてリサーチを行い、評判の良かった Qwopus3.6-27B-v2 の検証を開始した。

【第一部】 Qwopus3.6-27B-v2-FP8 の導入と熱狂

Qwopus3.6 を vLLM 0.23.0 で動かそうとしたが、ファインチューニングの Qwopus3.6 は、 ｖLLM 0.23.0 にある、MTP（Multi-Token Prediction / 推測デコード）と tool_choice（ツール呼び出し・構造化出力）を同時に有効化すると、正常に動作しなくなるという、重大なバグの影響をもろに受けた。

仕方がないので、vLLM のツールパーサーに関する課題解決にも取り組んだ。モデルのツール呼び出しを安定させるため、vLLM のパーサーを使わずに tool_choice="none" とし、プロンプトで <tool_call> タグを強制的に出力させる「自前パース方式（Healer）」を採用し動作を確立。「速くて賢い完璧なエージェント基盤が完成した」とその時は喜び、様々なタスクを実行させていました。

【第二部】 現実の壁：巨大コンテキストと 2 種類の XML 崩壊

単発のテストでは完璧に動作し、コーディング等も優秀な Qwopus だったが、実際に MCSM-Agent の Operator として組み込み、Web Researcher 等のタスクで大量のコンテキストを整理・処理させようとした途端、脆くも崩れ去った。

ここには、大きく分けて2つの異なるトークン閾値による限界（崩壊）が存在していた。

限界1：出力トークン上限によるストリーム切断

モデルが research_notes.md などの巨大なファイルを一度にテキストとして出力しようとした際、1回の生成出力が 8192 トークンの上限に到達。その結果、ストリームが強制切断されて <tool_call> の閉じタグが出力されず、「長文を出力してはパースエラーになる」という無限ループに陥った。クライアント側でのパース強化やフォールバックプロンプトの動的注入で一時的な回避を試みたものの、再試行ロジックの限界が浮き彫りになった。ただここは、再試行ロジックの調整などで解消できた。

限界2：入力コンテキスト長超過によるモデル推論の崩壊

限界1を乗り越えた後も、様々なタスクを処理していくと入力コンテキスト（過去の会話や検索結果の履歴）が 約 19,000 トークン を超えた時点で、Qwopus モデル自身の推論能力（アテンション）が限界を迎えた。

• ハルシネーションの爆発: 突如として「814年まで hacía de la 580円」「味噌を下 марина 担々麺を nghiên cứu 作る」といったように、存在しない言語（アラビア語、スペイン語、ロシア語などの断片）が混ざる壊滅的な状態に陥った。
• タグの出力忘れ: 推論崩壊により、そもそも <tool_call> の開始・終了タグを正しく出力できなくなり、タスクが進行不能となって停止した。

検証段階で「Qwopus の Long-Context SFT 学習の限界は 32K であり、最も安定するスイートスポットは 16K である」という仕様を把握してはいた。限定的なコンテキスト（短〜中規模）であれば Qwopus は極めて優秀だが、エージェントが過去の履歴を保持したまま大量のデータを処理する MCSM の要件においては、この特性が致命傷となった。

【第三部】 ゴーストツールの発見と最終防御

大量データの取りまとめは MCSM-Agent において Operator（Local LLM）に担ってもらい、API 費用を抑えることがアーキテクチャの要である。この事実を突きつけられた時、「巨大なトークンを安定して処理するには、ベースモデルである Qwen3.6-27B に戻すことが正解である」 と結論づけた。そして、Qwen3.6-27B に戻すことで、vLLM ネイティブパーサー（--tool-call-parser qwen3_xml）も問題なく戻して動作するようになった。

しかし、Qwen3.6 に戻し、vLLM ネイティブパーサーを利用する中で、新たな課題である 「ゴーストツール（Ghost Tools）」 が発見された。

• 事象: vLLM のパーサーが、並行ツールコールの合間にある改行などを誤認し、「名前（name）も引数（arguments）も空の無効なツール」を約 29% の割合でストリームに混入させてしまうバグが存在した。
• 影響: エージェントが unknown ツールを実行しようとして "Tool not found" エラーとなり、無駄なコンテキストとターンを消費していた。
• ストリームレベルの防波堤（解決策）: この vLLM 側のバグを無害化するため、MCSM（agent-runner.ts）側の SSE チャンク受信部に「初めて出現したのに名前が空のツールコールを即座に破棄する」強力なフィルターを実装した。これにより、下流の SDK には完全にクリーンなツールコールのみが届くようになった。

【結論】 劇的な改善と安定動作の実現 (Golden Path の開通)

Qwopus への挑戦を経て、最終的に Qwen3.6-27B-FP8 へのモデル回帰、およびアーキテクチャの最適化を行ったことで、MCSM の自律エージェントは**極めて安定した Golden Path（リサーチからファイル生成までの完全自律実行）**を達成した。

最大の比較結果として、過去のテスト（Qwopus使用時）では、30分かけて情報を集めたものの 19K トークンを超えた時点で XML が崩壊し、ファイルを1つも書き出せずに停止 していた。 しかし、同等以上の負荷をかけた最終テスト（Qwen3.6使用時）では、約 50,000 トークン の巨大なコンテキストを保持したまま、一切のハルシネーションや破綻なく 3 つの高品質なファイルを生成し、見事にタスクを完遂したのだ。

現在のアーキテクチャは、以下の 3 層構造により非常に堅牢な基盤を確立している。

1. コンテキスト限界の突破: Qwen3.6 と 131K 枠（128GB RAM搭載のGB10の特性をフル活用）によるハルシネーションの撲滅。
2. フォーマットの保証: vLLM ネイティブパーサー（--tool-call-parser qwen3_xml）による XML 崩壊の吸収。
3. ゴーストの無害化: MCSM クライアントフィルターによる不正なチャンクの破棄。

LLM エージェントが途中でエラー停止することなく、「情報の徹底したリサーチ → 品質を担保するための自己レビューとリトライ → 最終成果物のファイル出力」という本来あるべき理想的な実行フローを歩めるようになった。

限定的なタスクには Qwopus も光るが、巨大なコンテキストを捌く大黒柱としては、やはりベースモデルの強さが際立った。 GB10 が 一台しかないので、汎用的な LLM に頼るしかないと思いながら、機能を絞って Qwopus3.6-27B-v2 を活用するなど、様々なパターンでの適用基準があると思った。