きっかけ：「単一GPUに収まるサイズなのに速くならない」謎
前々回のQwen3.8-27B量子化比較記事で、地味に気になっていたことがあった。UD-IQ3_XXS(11GB)は単体のB580(12GB)にほぼ収まるサイズなのに、2枚ともVRAMを使うUD-Q4_K_M(17GB)と生成速度がほぼ同じだったのだ。「VRAMに収まるならGPU1枚で完結して速くなるはず」という予想が外れていた。
これ、実は前提が間違っていた可能性に気づいた。あのテストでは常に2枚のGPUが「見えている」状態で計測していて、実際に1枚だけに制限して比較したわけではなかった。つまり「収まるサイズだから1枚で動いている」と決めつけていただけで、本当に1枚だけで動いていたかは確認していなかった。
というわけで、GGML_VK_VISIBLE_DEVICES環境変数でOllama(Vulkanバックエンド)から見えるGPU数を実際に1枚に制限し、2枚見える状態と比較してみた。
テスト内容
3種類のモデルサイズで、GPU2枚(デフォルト)とGPU1枚に強制制限した状態を比較。
| モデル | サイズ | 位置づけ |
|---|---|---|
| Gemma4-12B-Heretic | 7.4GB | GPU1枚(12GB)に余裕で収まる |
| Qwen3.8-27B UD-IQ3_XXS | 11.9GB | GPU1枚の容量ギリギリ |
| Qwen3.8-27B UD-Q4_K_M | 17GB | GPU1枚には収まらない |
GPU1枚への制限はGGML_VK_VISIBLE_DEVICES=0でOllamaサーバーを起動し直すことで実現。ログで実際に1枚しか認識されていないことを確認した上で計測している。
結果：ギリギリサイズのモデルほど、2枚目のGPUの恩恵が大きい
結果はかなりはっきりしていた。
- Gemma4-12B-Heretic(7.4GB): 33.1 tok/s → 33.1 tok/s。全く変化なし。GPU1枚に余裕で収まるサイズなので、デフォルトでも元々1枚しか使っていなかったということ
- Qwen3.8-27B IQ3_XXS(11.9GB): 12.4 tok/s → 4.8 tok/s。約2.6倍の速度低下
- Qwen3.8-27B Q4_K_M(17GB): 13.2 tok/s → 3.2 tok/s。約4倍の速度低下(GPU1枚には収まらないため、収まらない分がCPU側にオフロードされて動いてはいるが、その分極端に遅くなる)
前々回の記事で「IQ3_XXSは単一GPUサイズなのに速くならなかった」と書いたが、正しくは**「元々一度も単一GPUだけで動いたことがなかった」**が実情だった。デフォルト設定では、たとえVRAMに1枚で収まるサイズであっても、Ollama(Vulkanバックエンド)は複数GPUが利用可能なら層を分割して両方使いにいく挙動をしているらしく、それによって前々回の比較(Q4_K_MとIQ3_XXSがほぼ同速度)は「どちらも2枚使っていたから同じくらいだった」で説明がつく。
GPU1枚に制限すると何が起きているのか
Q4_K_M(17GB)を1枚のGPU(12GB)に制限したケースでは、エラーで止まるかと思いきや、実際には動作した(3.2 tok/s)。収まりきらない分がおそらくCPU側のメモリ・処理にオフロードされて、極端に遅いながらも生成自体は完了する、という挙動のようだ。「VRAM不足=即エラー」ではなく、静かに遅くなるだけなので、意図せずこの状態になっていても気づきにくいという点は注意が必要だと感じた。
結論
- 「VRAMに1枚で収まるサイズだから」だけでは、実際に1枚で動いているとは限らない — デフォルト設定では複数GPUが使える環境なら積極的に分割される
- GPU1枚容量ギリギリのモデルほど、2枚目のGPUの恩恵が大きい(今回は約2.6倍)。単なる「保険」ではなく、明確な速度向上要因になっている
- GPU1枚に収まらないモデルを無理に1枚に制限すると、エラーではなく「静かに遅くなる」(CPUオフロード)。意図しない設定ミスで気づかないまま遅い状態が続くリスクがある
- 小さいモデル(余裕を持って1枚に収まるサイズ)は2枚あっても恩恵なし — GPU2枚構成の価値は「ギリギリ〜収まらないサイズのモデルを速く動かせること」に集約される
前々回の「謎」は、そもそも比較の前提が崩れていたというオチだった。実測して初めて気づけた类の話で、思い込みで結論を出さずに実際に条件を切り分けて検証することの大事さを改めて感じた。