Qwen3.5の27Bが9Bに負けた RTX 4060の逆説
Qwen3.5が出た。9B、27B、MoE構成の35B-A3B。パラメータ数だけ見れば大きいほど賢いで終わる話だが、それを8GB VRAMのGPUに押し込んだらどうなるか。
結論から言うと、スペック表の数字と実用体験の間には、思っていたより遥かに大きな溝があった。VRAM使用量、コンテキスト長、パラメータ数——この3点セットだけで選んだモデルが、実際に使ったら期待と全然違う。そのなぜを解剖する。
検証環境
GPU: NVIDIA GeForce RTX 4060 8GB
CPU: AMD Ryzen 7（詳細は割愛）
RAM: 32GB DDR5
推論: llama.cpp (GGUF Q4_K_M量子化)
ctx: 8192 tokens（全モデル共通）
OS: Windows 11
3モデルとも Q4_K_M 量子化で統一。llama.cppのnglパラメータ（GPUオフロード層数）は各モデルに合わせて設定:
- 9B: ngl=99（全層GPU）
- 27B: ngl=24（58層中24層GPU、残りCPU）
- 35B-A3B: ngl=99（MoEなので全層GPUに収まる）
27Bだけngl=24なのは、Q4_K_Mでも全層をGPUに載せると8GBに収まらないから。ここが後で大きな意味を持つ。
3つのタスク
モデルの性格差を見るために、性質の異なる3タスクを用意した。
- コード生成: 「Pythonでスレッドセーフなシングルトンパターンを実装して」
- 知識要約: 「量子コンピューティングの現状と課題を500文字で説明して」
- 推論・計算: 「12×15+8÷2-3×7の計算過程を示して」
タスク1は構造化された出力（コードブロック）、タスク2は自由記述で知識の広さと文章構成力、タスク3は論理的推論。この3軸でモデルの振る舞いがどう変わるかを見る。
実測結果
| 9B | 27B dense (ngl=24) | 35B-A3B MoE | |
|---|---|---|---|
| タスク1 (コード) | 33.0 t/s | 3.57 t/s | 8.61 t/s |
| タスク2 (知識) | 37.1 t/s ※後述 | ctx枯渇 (58分) | ctx枯渇 (20分) |
| タスク3 (計算) | 33.57 t/s | 3.47 t/s | 8.21 t/s |
| VRAM | 7.1GB | 7.7GB | 7.6GB |
| GPU利用率 | 91% | 60% | 95% |
| システムRAM | 22.6GB | 28.3GB | 30.8GB |
| CPU利用率 | 32% | 74% | 65% |
数字だけ見れば9Bが圧倒的に速いで終わる。だがこのテーブルには、スペック表からは絶対に読み取れない情報が埋まっている。
発見1: 同じ7.5GB VRAMなのに速度が10倍違う
VRAM使用量を見てほしい。7.1GB、7.7GB、7.6GB。ほぼ横並びだ。スペック表的には3モデルとも8GBに収まる、OKで話が終わる。
ところが速度は33 t/s、3.5 t/s、8.6 t/s。最大10倍の差。VRAM使用量からは速度差を予測できない。
差の正体はGPU利用率にある。
- 9B (91%): 全層がGPU上にある。GPUの演算ユニットをほぼフルに使い切っている。
- 27B dense (60%): 58層中24層しかGPUに載っていない。残り34層はCPUで処理。GPUは自分の分を処理し終わってもCPUの処理完了を待っている。GPU利用率60%の意味は、40%の時間GPUが遊んでいるということだ。
- 35B-A3B MoE (95%): MoE（Mixture of Experts）は全35Bのパラメータを持つが、1トークンあたりアクティブになるのは約3B。この3Bは余裕で8GBに収まるため、実質的に3BモデルとしてGPUで処理される。だからGPU利用率が9B（91%）より高い95%。
CPU利用率がこの構造を裏付けている。27BのCPU 74%は、GPUに載りきらなかった34層をCPUが必死に処理している姿だ。9Bの32%と比べれば、何が起きているか一目瞭然。
教訓: VRAMに収まることと速く動くことは全く別の話。 部分オフロード（GPU+CPU分散処理）は「動くが遅い」の典型。以前の記事でQwen2.5-32Bを8GBで動かした実験でも同じ構造が見えていたが、今回3モデルを並べたことで差がさらに鮮明になった。
発見2: MoEのGPU利用率が9Bより高い理由
35B-A3BのGPU 95%は、9Bの91%より高い。直感に反する。35Bのモデルが9Bより効率的にGPUを使っている。
理由はアーキテクチャにある。MoEの35Bはパラメータの総数であって、推論時にアクティブなのは約3B。8GB VRAMに対して3Bのアクティブパラメータは余裕がありすぎるくらいで、GPUの演算パイプラインを効率的に埋められる。
一方9Bは、8GBに対してギリギリのサイズ（7.1GB）。VRAMの空き容量が少ない分、GPUのメモリ帯域にわずかな競合が生じる可能性がある。
ただしシステムRAMは35B-A3Bが最大（30.8GB）。MoEの全エキスパートのパラメータ（35B分）はメモリのどこかに保持する必要があり、GPUに載らない分はシステムRAMにいる。GPUに優しいがシステムメモリに厳しい——これがMoEのトレードオフ。16GB RAMのマシンだったらスワップが発生して、この結論は逆転するかもしれない。
発見3: ctx 8192の実効値はタスクで変わる
タスク1（コード生成）とタスク3（計算）は3モデルとも完走した。ところがタスク2（知識要約: 量子コンピューティングを500文字で）では27Bと35B-A3Bがctx枯渇で全滅。
3モデルともctx 8192は同じ。なのにタスクによって足りる・足りないが変わる。
原因はthinking（推論過程）のトークン消費にある。Qwen3.5はthinking model——回答を出力する前に、内部で考える過程がトークンとして消費される。コード生成や計算は出力構造が決まっているからthinkingが比較的短く済む。しかし500文字で説明してのような知識要約タスクでは、何を書くか・どう構成するか・文字数は足りているかをthinkingで延々と検討し、ctxを食い尽くす。
スペック表のctx 8192は、thinking modelにおいては額面通りの意味を持たない。 実効的なctx長はタスクの種類で変動する。これはctx 8192ありますというスペックシートだけでは読み取れない罠だ。
発見4: 9Bだけ生き残った——知識が浅いからこその逆説
タスク2で面白いことが起きた。27Bと35B-A3Bが全滅する中、9Bだけが回答を出力した。
しかも、9Bは1回目の実行ではctx枯渇で失敗し、2回目の実行で成功した。同じモデル、同じプロンプトで結果が変わる。thinkingの経路が毎回異なるため、ctxの消費量が非決定的になる。成功時のトークン消費は8095/8192。残り97トークンの薄氷だった。
なぜ9Bだけ生き残れたのか。9Bのthinkingログを読むと答えが見える。
9Bのthinking（成功時）は242行。内容のほとんどは下書き→文字数を数える→足りない→増やす→多すぎ→削る→もう1回数えるの繰り返しだった。量子コンピューティングの内容そのものへの検討は冒頭で手短に終わっていて、thinkingの90%以上が文字数調整に費やされている。
一方、27Bと35B-A3Bは量子コンピューティングの知識をthinkingで展開しようとする。知識量が多い分、何を書くべきかの検討が膨らみ、ctxを食い尽くす。
知識が浅いからこそ、書く内容が早く決まり、残りのctxを文字数調整に使えた。 パラメータ数が多いほど賢い——はずなのに、知識の豊富さがctx制約下では逆に足を引っ張る。潤沢なctxがあれば27Bや35B-A3Bの知識量が生きるが、8192という狭い箱の中では浅く速く打ち切れる9Bのほうが結果的に生存できた。
発見5: thinkingの効率はモデルサイズと逆相関する
タスク1（シングルトン）のthinkingを比較すると、モデルサイズとthinking効率の関係が浮かび上がる。
9B: 198行のthinking → 出力は3パターン
thinkingの中身は11ステップのメタ分析。「Wait, lru_cache は本当にthread-safeなのか？」「Self-Correction: いや、__new__のロジックはこうすべきだ」と何度も行きつ戻りつする。能力が足りない分をthinkingの量で補おうとしている。結果として出力は3パターンに絞られているが、各パターンの解説はGILの罠、__init__再実行問題、lru_cacheの注意点まで踏み込む深さがある。
27B: 11行のthinking → 出力は5パターン＋比較表
5つのアプローチをサッと列挙して終了。thinkingが短いのは、少ない推論ステップで要点を掴めるから。出力は5パターン＋比較表＋テストコード＋推奨事項と網羅型。
35B-A3B: 8行のthinking → 出力は4パターン＋並行テスト
3つのアプローチを挙げて即座に出力へ。thinkingが最短。出力にはデコレータパターンで__doc__と__name__を保存するコード、time.sleep(0.001)で初期化遅延をシミュレートする並行テストなど、実際に使うとき必要になる配慮が自然に入っている。
整理すると: 9Bは考えるのが下手で冗長なthinkingが必要。27Bは効率的に考えて広く出力。35B-A3Bは最短のthinkingで実務的な出力。 ただしこの差がctx 8192では命取りになる——thinkingが長いほどctxを食うから。タスク2で9Bだけが生き残ったのは「考えるのが下手だけど、知識も浅いから早く結論に到達した」という二重の偶然だった。
発見6: 遅さは複利で効く
タスク2でctx枯渇した3モデル（9Bの初回失敗を含む）の失敗が判明するまでの時間を比べる。
| モデル | 速度 | 枯渇までの時間 |
|---|---|---|
| 9B | ~33 t/s | ~4分 |
| 35B-A3B | 7.63 t/s | 20分 |
| 27B | 3.21 t/s | 58分 |
全員同じ全滅なのに、失敗の検知に4分 vs 58分かかる。27Bの58分は待っている間ずっともしかしたら出力が始まるかもと期待して、結局ゼロ。遅いモデルのctx枯渇は、速度の遅さが二重にペナルティとして効く。 失敗するのは同じでも、それに気づくまでの時間コストが速度に反比例する。
もう一つ。35B-A3Bのタスク2速度は7.63 t/sで、タスク1の8.61 t/sより低い。27Bも3.57→3.21 t/sに落ちている。ctxが埋まるにつれてattention計算が重くなり、スループットが劣化する。ctx末期は生成速度が落ちる——これもスペック表には載っていない現実。
制約が差異を増幅する——この実験の本質
A100 80GBにctx 128Kなら、3モデルとも快適に動いて差は見えない。8GB VRAMとctx 8192という狭い箱に押し込むことで、モデルアーキテクチャの設計思想の違いが拡大されて見える。
- dense 27Bは全パラメータが毎トークン活性化するから、8GBに収まりきらずCPUに溢れて速度が死ぬ
- MoE 35B-A3Bは1トークンあたり3Bしか活性化しないから、35Bの知識を持ちながらGPUを95%使い切れる
- 9Bは小さいからGPUに余裕で収まるが、thinking効率が悪く、ctxを冗長な推論で浪費する
これは限界試験だ。壊れるかどうかではなく、壊れ方の違いからモデルの内部構造を逆推定する試験。壊れ方がそのまま設計思想のX線写真になっている。
99%の人は9Bでいい
8GBでとにかく速く → 9B（33 t/s）。インタラクティブ用途、コード補完、チャットなど速度が正義のユースケース全般。VRAM 7.1GBで収まりがよく、GPU 91%で無駄がない。
8GBでもう少し賢い出力が欲しい → 35B-A3B MoE（8.6 t/s）。9Bでは知識が足りない専門領域のタスク、出力の網羅性や実務的な配慮が欲しい場面。ただしシステムRAM 30.8GBを食うので、16GB RAMのマシンでは厳しい。
8GBでdense 27Bを選ぶ理由はない。 3.5 t/sは対話的に使うには遅すぎる。品質が35B-A3Bを明確に上回るわけでもない。ngl=24の部分オフロードはGPU 60%/CPU 74%という非効率な状態を生み出し、MoEの同じVRAMでより賢くに完敗する。
そして、これが一番伝えたいことだが——自分のタスクとハードウェアの組み合わせで試さないと、正解はわからない。VRAM使用量・ctx長・パラメータ数のスペック3点セットだけでは、実用上の体験を予測できない。GPU利用率、CPU負荷、thinking効率、ctxの実効長——これらはスペックシートに載っていないが、体験を決定的に左右する。
この記事の3モデル比較が、その証拠だ。
参考
- RTX 4060 8GBでQwen2.5-32Bが動く — M4超えの10.8 t/sを叩き出した最適化全手順 — llama.cppでの8GB VRAM運用の基礎
- RTX 4060 8GBで論文RAGを完全ローカル化した — BGE-M3 + Qwen2.5-32B + ChromaDB構築記 — VRAM制約下でのRAGパイプライン構築
- 半導体FABにLLMを持ち込んだら何が起きるか — ArXiv論文5本を現場目線でぶった斬る — ローカルLLMが製造業の前提条件になる話