27GBモデルが推論途中でクラッシュするのを見つめながら、6.6GBの代替品がまるで他にやることなんかないかのようにスイスイ動いていた。
そのとき——RTX 5070 Tiの前で、WSL2のセグフォルトエラーを見ていたとき——20年近くこの業界を取材してきた自分の疑問が明確になった。パラメータ数は見栄えの指標に過ぎないということだ。プレスリリースや投資ピッチで引用されるのはこれだ。投資家を気持ちよくさせる。だが、手元で実際に役に立つモデルを作ることとは、ほぼ無関係だ。
Qwen3.5:9Bを18回のテストで5つの競合モデルと比較した。狙いはローカルエージェント作業——実際のツール呼び出し、構造化データの解析、結果がすぐ返ってくるような現実的な用途だ。勝者は明らかだった。
ベンチマークが語らない領域：構造化されたツール呼び出し
実際にローカルエージェントの明暗を分ける決定的な要因があり、Alibabaのエンジニアはそれをほかのほとんどの企業より理解していたようだ。
ほとんどの言語モデルにツールを使うよう指示すると——たとえばディレクトリを列挙するとか、データベースクエリするとか——関数呼び出しを長々とした散文の真ん中に埋め込む。その後は解析ロジック、エラーハンドリング、リトライメカニズムが必要になる。めちゃくちゃだ。モデルによってばらつきがあるが、ほとんどはいい加減な抽出レイヤーを構築する羽目になる。
「ネイティブなtool_calls対応とQ4_K_M量子化だけが本当にスムーズに動く」
Qwen3.5:9BはクリーンでスタンドアロンなJSON形式のtool_callsフィールドを返す。それで終わり。解析なし。正規表現の奇術なし。Pythonの神への祈りなし。Qwen2.5:14BやQwen2.5-coder:14Bのような大型競合は同じ情報をプレーンテキストに埋め込んでしまい、抽出レイヤーを構築して夜11時にデバッグする羽目になる。
5つのモデルでこの特定シナリオをテストした。Qwen3.5:9Bは100%の精度でツール呼び出しを成功させた。Gemma 4 E4B（9.6GB）は、3回のツール呼び出しから14回に増やすのに30分のOllama調整が必要だった。それでも、より小型モデルの一貫性には及ばなかった。27B系列？本番環境へのデプロイは非現実的な不安定性だ。
VRAMがボトルネックになる場所（予告：いつもそこだ）
ぶっちゃけ言うと：コンシューマーGPUのメモリが、ローカルAI作業の実際の制約であって、モデルの洗練さではない。
Qwen3.5:9BはRTX 5070 Tiで6.6GBのVRAMを消費し、KVキャッシュのスペースと長いコンテキスト用に十分な余裕を残す。Q4_K_M量子化の27Bモデル？16GB——カードを完全に満杯にする。そしてクラッシュが始まった。TurboQuantのWSL2セグフォルトバグが状況を悪化させ、単純な推論を悪夢のようなデバッグに変えた。
綿密にメモを取った。実際に起きたことはこうだ：
大型モデル推進派は常に「VRAMを足せばいい」と言う。そりゃ、手元に8000ドルあれば話は別だ。だがコンシューマーGPUでローカルエージェントを実行している人——正直に言って、ほとんどの人だ——VRAMは硬い制約だ。理論的な性能ではなく。ベンチマークスコアではなく。現実的で物理的なメモリだ。
Qwen3.5:9Bはその物理的現実を尊重している。
誰も議論していないトークン効率の仕掛け
ここからが奇妙で、同時に本当の勝利が生まれる場所だ。
Qwen3.5:9Bはthink=falseパラメータに対応しており、内部推論トークンを無効化できる。同じタスク。異なるトークン消費。1024+トークンから131に減る。8～10倍削減だ。これは四捨五入の誤差じゃない——モデルの動作が相転移する。
なぜ重要か。より長いコンテキストウィンドウとより多くのツール結果が同じVRAMフットプリント内に収まるから。VRAM不足に陥らずに複雑なエージェントループを実行できる。創造的なタスクで実際にモデルに考えさせることができて（think=trueで）、それでもハードウェア予算内に収まる。
他のモデルも思考機能を持っているが、粒度の細かい制御は提供しない。我が経験では、粒度の細かい制御——タスク種別に応じてダイアルを上下させる能力——が実際に動くシステムを出荷する方法だ。
「より優れた」モデルが規律あるアーキテクチャに敗れるとき
ここからが皮肉なところで、本気で信じている部分だ。
Gemma 4 E4Bはおそらく、Qwen3.5:9Bより「優れた」モデルだ。パラメータが多く、学術ベンチマークでの生のパフォーマンスが良く、マルチモーダル機能を持つ。なのに、同じエージェントシナリオで実行すると、同じ基本タスクで繰り返し失敗する：信頼できる構造化ツール呼び出しだ。30分のOllama調整後、3回から14回のツール呼び出しに増やせた。Qwen3.5:9Bは最初の試行で一貫して8回だ。
これは何度も目にした現象を反映している：生の性能は信頼性と同等ではない。Gemma 4のアーキテクチャはツール呼び出しをファーストクラスシチズンとして設計されていない。後付けの機能だ。スペックシートに追加されたものだ。Qwen3.5:9Bは、この特定の仕事を上手くやるために一から構築された。
それは「何でもやると主張するナイフ」と「ハンマーとしてこんなに優秀で、すべてにハンマーを使いたくなる」ハンマーの違いだ。
量子化という誰もが間違える問題
量子化——モデルの重みを圧縮してサイズを減らす——こんなに議論になる必要はないのに。
Qwen3.5:9BはQ4_K_M量子化と相性がいい。ファイルサイズと品質の中庸な選択肢だ。競合する大部分の9BモデルはデフォルトでQ2_Kを選ぶが、これはより小さいが細微なニュアンスを失う。その差は、長い会話でツール呼び出しを繰り返すときに複合する。
プレイブックはシンプルだ：ネイティブツール呼び出し対応を最初に確認し、その後Q4_K_M量子化版を使うことを確認する。このステップをスキップするなら、テキスト解析の悪夢（ツール対応がない）か、推論品質の低下（過度に積極的な量子化）のどちらかに対応することになる。
実際に重要なスピード数値
Qwen3.5:9Bはテストハードウェアで秒間106トークンに達した。Gemma 4 E4Bは秒間144トークン。スループット重視の作業負荷にとって注目の差だ。
だが、実際のエージェントシナリオでは、スループットではなく実際の処理時間が重要だ。ブートストラップ段階（並列モデルプリヒート）に527ms。タスク実行（5～8ツール、結果圧縮）は起動から構造化レポートまで約39秒の合計だ。Gemma 4は生のスピードではやや速いが、ツール呼び出しの規律が劣るため同じ結果を達成するために多くの推論サイクルが必要だ。
両モデルで「工場診断」シナリオ（5ツール、ほぼ2000文字出力）と「マルチツール検索」（8ツール、ほぼ5000文字）を時間測定した。Qwen3.5:9Bは両方を完璧に実行。Gemma 4 E4Bは工場診断で0ツール、0文字を返した——機能的に無用だ。
自分が気になるところ
Qwen3.5:9Bの宣伝に給料をもらっていない。オリジナルコンテンツに販売リンクが含まれており、最初から開示している。だが、本当に気になることはこれだ：このようなベンチマーク作業——綿密で、ハードウェア固有で、ベンチマークスコアより現実的なタスク完了に焦点を当てた——AI報道では稀だということだ。
ほとんどの記事はベンチマーク結果を手で振ってすます。「新しい能力」を語る。このテストはより単純な問いを投げかけた：自分の特定ハードウェア、自分の特定ユースケースで、どのモデルが実際に仕事を完了させるか?
その答えはQwen3.5:9Bだった。大きな差でだ。
実際に使う方法
コンシューマーGPUでローカルエージェントを実行しているなら、ここがチェックリストだ：
まず、ネイティブツール呼び出し対応を確認する。モデルにツールを使うよう指示して、レスポンスにtool_callsフィールドが含まれているか確認する簡単なPythonスニペットを書く。これは譲歩不可だ。
次に、選択したモデルのQ4_K_M量子化版を入手する。より小さな量子化で妥協するな。
三番目に、スピード重視タスクでthink=falseパラメータを試す。推論が重要な創造的作業はthink=trueを保つ。
四番目に、複数のツール呼び出しをチェーンしている場合、結果圧縮を検討する。セマンティックコンテンツを失わずにトークンを節約できる。
完全なローカルエージェントエンジンPythonスクリプト（280行、無料リソース）が欲しければ、それは利用可能だ。より深い最適化用のプレイブックも同様に。
