RTX 5080 VRAM不足エラーとは、公称16GBの割り当てから約1.1GBをOSとKVキャッシュが先取りし、実効14.8GBに収まらないモデルが起動拒否される状態のこと。
Ollamaでqwen3:32bを起動しようとしたら、モデルのロードが始まる前に「SKIPPED_VRAM」で止まった。RTX 5080は16GB搭載しているはずなのに、なぜ32Bクラスだけ起動できないのでしょうか。答えは公称容量と実使用可能枠の差にあります。
- 最大の原因はVRAM実効上限14.8GBを超えるモデル要求で、Ollamaが事前チェックで起動を拒否する
- 最初に試すべきは量子化レベルを下げる（Q4_K_M→Q3_K_M）か、MoEアーキテクチャのモデルに切り替える
- 解決しない場合はCPUオフロード、Oculink経由のデュアルGPU、APIへの切り替えが代替手段
このエラーの症状と確認すべき環境情報
Ollamaやllama.cppでモデルをロードしようとした瞬間、以下のようなログや挙動が出ていれば本記事の対象です。
よくある症状:
- Ollamaのログに「SKIPPED_VRAM」または「not enough VRAM available」
- モデルのダウンロードは完了しているのに推論が始まらない
- ollama run qwen3:32bを実行してもプロンプト入力画面に入らず終了
- CUDA error: out of memory がモデルロード中に発生
- ロードは通るが最初のトークン生成後にクラッシュ
これはGPUが壊れているわけでも、ドライバが異常なわけでもありません。RTX 5080の16GB VRAMに対して、モデルの要求量が上回っているのが原因。対処前に自分の環境を次のように確認してください。
対処前に確認してほしい環境情報:
- OS: Windows 11 / Windows 10 / Linux（本記事の検証環境はWindows 11 25H2・build 26200）
- GPU: RTX 5080 16GB（nvidia-smiで確認）
- ドライババージョン: nvidia-smiコマンドで確認（本記事は595.97で検証）。NVIDIA System Management Interface 公式ドキュメントに出力項目の意味が記載されている
- Ollamaバージョン: ollama
--versionで確認（本記事は0.20.7） - 空きVRAM: nvidia-smiの「Memory-Usage」列でアイドル時の使用量を確認
アイドル時にVRAMを1GB以上消費している場合、ブラウザやウィンドウマネージャが先取りしています。ここが実効上限を決めるポイント。
SKIPPED_VRAMで起動拒否される｜実効14.8GBの壁が原因
RTX 5080は公称16GB VRAMですが、実機で確認できる容量は15.9GB。ここからWindowsのデスクトップコンポジション、NVIDIAドライバ本体、そしてモデルロード時に確保されるKVキャッシュが引かれます。当サイトの検証環境（RTX 5080 / i7-14700F / 96GB RAM / Ollama 0.20.7 / ドライバ595.97）では、実際にモデル推論に使える枠は約14.8GBでした。
Ollamaはモデルをロードする前に「このモデルを動かすのに何GB必要か」を見積もり、空きVRAMと照合します。足りないと判断したら起動自体を止める。これがSKIPPED_VRAMの正体。out of memoryでクラッシュさせる前に自衛しているだけで、エラーそのものは正常動作の一部です。Ollama公式FAQ「Why is Ollama using my GPU?」に、GPUメモリ判定の挙動と環境変数による上書き方法が整理されている。
対処手順:
- nvidia-smiでアイドル時のVRAM使用量を確認する。Windowsのデスクトップ効果やブラウザが使っている分を把握
- 不要なブラウザタブ・Discord・ハードウェアアクセラレーションが有効なアプリを終了する。空きVRAMを14.8GB以上確保するのが目標
- OllamaのOLLAMA_KEEP_ALIVEを短くする。前回ロードしたモデルが常駐してVRAMを占領しているケースあり
- 起動したいモデルの「VRAM目安」を確認する。14.8GBを超える値なら物理的に動かない
ステップ2でVRAM使用量が1GB未満まで減らない場合、GPUハードウェアアクセラレーションを使っているバックグラウンドアプリが残っている可能性があります。タスクマネージャの「GPU」タブで使用プロセスを一覧表示できます。
32BクラスDenseモデルが全滅する理由｜MoEとの違い
検証環境で実際に起動拒否された3モデルがこちら。
| モデル | アーキテクチャ | 状態 | 備考 |
|---|---|---|---|
| qwen3:32b | Dense | SKIPPED_VRAM | 32B全パラメータが常時アクティブ |
| gemma4:31b | Dense | SKIPPED_VRAM | 31Bクラスも同様 |
| qwen3.5:27b | Dense | SKIPPED_VRAM | 27BでもQ4換算で16GB超え |
| codestral:22b | Dense | OK（14.2GB） | 22Bは14.8GB枠に収まる |
| gemma4:26b | MoE | OK（14.8GB） | 総26Bでも活性パラメータ小 |
| qwen3.5:35b-a3b | MoE | OK（14.8GB） | 総35B・活性3B |
27B以上のDenseモデルは全滅。一方で総パラメータが26B・35BあるMoEモデルは動いています。この差がアーキテクチャによる挙動の違いを示す実例。
DenseとMoEでVRAM消費が違う仕組み
Denseモデルは推論時に全パラメータをGPU上に展開する必要があります。32BをQ4_K_M量子化しても実サイズは約19〜20GB前後（willitrunai.comやapxml.comの参照値ではqwen3:32b Q4_K_Mで約19.8GB）となり、14.8GBの枠には収まりません。これが32Bクラス全滅の理由。Hugging Face Qwen3-32B モデルカードに総パラメータ数と推奨ハードウェア要件が掲載されている。
MoE（Mixture of Experts）は総パラメータが大きくても、推論時に使う「活性パラメータ」だけを計算します。qwen3.5:35b-a3bは総35Bですが活性は3B。モデル自体のロードは総量ぶん必要ですが、Q4量子化で14.8GBに圧縮できる構造ならVRAM枠にぎりぎり収まります。総パラメータと活性パラメータを分離する設計はMixtral of Experts (Jiang et al., 2024)で広く知られるようになり、推論時メモリ要求とモデル容量のトレードオフを整理する出発点になっている。
対処手順:
- ollama listで現在ダウンロードしているモデル一覧を確認
- 起動拒否されたモデルを削除する（ollama rm qwen3:32b）。14GB以上のファイルが空きストレージを圧迫
- 同じ系列のMoE版か、より小さいサイズに切り替える。qwen3:32b → qwen3.5:35b-a3b（MoE）または qwen3:14b
- ロード時にnvidia-smi -l 1で1秒ごとのVRAM推移を観察。14.8GB前後で停止すればOK
ステップ3でMoEモデルに切り替えた場合、速度は落ちる点に注意してください。当サイト検証ではgemma4:26b（MoE）が36.7 tokens/sec、qwen3.5:35b-a3bが18.5 tokens/sec。通常のDense 14Bモデル（qwen3:14bで79.1 tokens/sec）と比べると体感は遅めです。
量子化レベル別のVRAM消費目安
同じモデルでも量子化レベルを変えるとVRAM要求は大きく変わる。llama.cppが提供する代表的な量子化フォーマットの違いをllama.cpp公式 quantize READMEから整理すると以下の通り。32B Denseモデルを基準にした目安値を当サイト検証環境で確認した範囲で並べた。
| 量子化フォーマット | ビット数 | 32Bモデルの目安サイズ | RTX 5080での挙動 | 品質低下の度合い |
|---|---|---|---|---|
| Q8_0 | 8bit | 約32-34GB | 起動不可 | ほぼ無し |
| Q6_K | 6bit | 約26-28GB | 起動不可 | 軽微 |
| Q5_K_M | 5bit | 約22-24GB | 起動不可 | 軽微 |
| Q4_K_M | 4bit | 約19-20GB | 起動不可 | 体感小 |
| Q3_K_M | 3bit | 約15-16GB | 境界線（CPUオフロード併用が現実的） | 明確に低下 |
| Q2_K | 2bit | 約12-13GB | 起動可（劣化大） | 顕著に低下 |
Q3_K_Mまで落とせば32B Denseでも14.8GB枠に滑り込む可能性が出てくる。ただしコード生成・数値推論・長文要約では精度低下が体感できるレベルになり、用途を選ぶ必要がある。Q2_Kは緊急回避用と考えたほうがいい。14B〜22Bクラスを高品質量子化（Q5_K_M / Q6_K）で運用するほうが、32B Denseを極端な低ビット量子化で動かすより安定した出力を得やすい。
Codestral 22Bが遅い・TTFTが不安定な場合の対処
22Bクラスは起動できるものの「他サイトが報告する速度に届かない」「TTFT（最初のトークン生成までの時間）が不安定」というケースがあります。当サイトの検証環境ではcodestral:22bで33.3 tokens/sec・VRAM 14.2GB・TTFT 2771msを記録。willitrunai.comが公開しているRTX 5080 16GB環境の報告では51.5 tokens/sec・TTFT 3759msとされており、トークン速度で下回りTTFTでは上回る結果。
この差は量子化設定・Ollamaバージョン・バックエンド（CUDA/cuBLAS）の違いで発生します。測定条件が合わないと単純比較できない点は押さえておきたいところ。
対処手順:
- 起動できている場合はnvidia-smiで消費電力を確認する。フルGPU推論時はTDP（360W）の5〜8割程度に張り付くのが目安。100Wを切っているとCPUへの処理退避が混ざっている可能性
- OLLAMA_NUM_GPUを最大値に固定する。自動判定に任せると一部の処理ブロックがCPUに逃げることがある
- Ollamaのバージョンを確認する。本記事の検証は0.20.7。古いバージョンでは同じモデルでも速度が落ちる報告が複数ある
- プロンプト長を短くしてTTFTを測り直す。長文プロンプトはTTFTを大きく押し上げる要因
ステップ2を実行した後、ollama psで「100% GPU」と表示されていれば完全にVRAMに乗っています。「87% GPU / 13% CPU」のような表示が出ていれば、一部がCPUに退避している証拠。この状態だと速度は数分の1まで落ちます。
VRAM消費を継続監視する手段
長時間運用でVRAMリークや常駐モデルの占有を見抜くには定常監視が要る。標準的な選択肢を整理する。
- nvidia-smi -l 1: 1秒ごとのVRAM・温度・電力をCLIで確認。スクリプトでgrepしてログ化しやすく、長時間ベンチマークの記録にも向く
- nvtop: Linux向けTUI監視ツール。GPUプロセス一覧と帯域・温度を一画面で把握できる
- ollama ps: ロード済みモデルとSIZE・PROCESSOR分担（GPU/CPU比率）を表示。SKIPPED_VRAMが起きる前段の挙動把握に有効
- タスクマネージャ GPU タブ: Windowsで各プロセスのVRAM割当を可視化。「Dedicated GPU memory」が実効上限の指標になる
Ollamaサーバを常駐させる構成ではOLLAMA_KEEP_ALIVEを短めに設定するとVRAM占有時間が縮む。デフォルトの5分でも長いと感じるケースでは0を指定して即時アンロードする運用もある。Ollama公式FAQ「How do I keep a model loaded in memory」に環境変数の挙動が明記されている。OLLAMA_KEEP_ALIVE=0で都度アンロード、OLLAMA_KEEP_ALIVE=-1で無期限常駐、という両極端の指定も可能。
それでも解決しない場合の代替手段
SKIPPED_VRAMがどうしても消えない、または32Bクラスを動かしたい場合、次の4つの選択肢があります。それぞれの特性を理解した上で選んでください。
選択肢1: 量子化レベルを下げる
Q4_K_MをQ3_K_MやQ2_Kに落とすと、同じモデルでもVRAM要求が2〜4GB減ります。27BクラスのDenseモデルなら14.8GB枠に収まる可能性あり。ただし品質は明確に低下します。コード生成や長文推論では回答精度が目に見えて落ちるため、用途次第。軽い会話用途なら許容範囲の場合もあります。
選択肢2: CPUオフロード
Ollamaやllama.cppは一部の処理ブロックをCPUメモリに退避する機能を持ちます。32Bクラスでも起動自体はできますが、速度は劇的に落ちる。目安としてフルGPU推論時の10〜20%程度まで落ちるのが一般的。また、CPUオフロード時はRAM消費も跳ね上がります。大型モデルのCPUオフロード運用では十数GB〜数十GBのシステムRAMを消費するケースが珍しくないため、AI用途では最低32GB、できれば64GB以上のシステムRAMを用意したいところ。
選択肢3: セカンドGPU追加・Oculink接続
RTX 5080にRTX 5060 Ti 16GBなどを追加してデュアルGPU構成にすると、合計32GB VRAMが使えます。Oculink経由の外付けGPUも選択肢。llama.cppやOllamaは複数GPUへの自動分散に対応しています。32Bクラスを快適に動かしたい場合の本命の解決策。llama.cpp公式ビルドドキュメントにマルチGPU環境でのCUDAビルド手順と分散設定が記載されている。
選択肢4: クラウドAPIへの切り替え
Claude APIやGemini APIなら32Bを超えるモデルも即時利用可能。ローカルGPU不要でノートPCからでも使えます。GPU購入費用と比較してコストが見合う場合は有力な選択肢です。
まとめ
RTX 5080でVRAM不足エラー（SKIPPED_VRAM、out of memory）が出る最大の原因は、公称16GBと実効14.8GBの差を見落としていること。対処の優先順位は次の通り。
まず空きVRAMをnvidia-smiで確認し、14.8GB以上を確保する。これで9割のケースは起動できるようになります。それでもダメな場合、モデルを14B以下のDenseかMoE版に切り替えるのが次の一手。32Bクラスを諦められない場合のみ、量子化レベルの降格・CPUオフロード・デュアルGPU化を検討する順序になります。
| RTX 5080 VRAM（公称） | 16GB GDDR7 |
|---|---|
| 実機認識容量 | 15.9GB |
| 推論実効上限 | 約14.8GB（OS・KVキャッシュ差引後） |
| 動作上限モデル（Dense） | codestral:22b（14.2GB / 33.3 tokens/sec） |
| 動作上限モデル（MoE） | qwen3.5:35b-a3b（14.8GB / 18.5 tokens/sec） |
| 起動拒否モデル | qwen3:32b・gemma4:31b・qwen3.5:27b |
| TDP | 360W |
| 参考価格 | 200,000円〜（2026年4月時点） |
よくある質問
Q. 16GB VRAMでQwen3 32Bを動かす方法はありますか？
Denseの32BをQ4_K_Mで動かすのは不可能です。代替策は3つ。同じQwen系列のMoE版qwen3.5:35b-a3b（14.8GBで動作）に切り替える、量子化をQ2_Kまで下げてCPUオフロードと併用する、RTX 5060 Tiなどを追加してデュアルGPU化する、のいずれか。実用速度を求めるならMoE切り替えが最も無難です。
Q. MoEモデルならなぜ総35Bでも16GBに収まるのですか？
MoEは推論時に全パラメータを使わず、活性パラメータ（Active Parameters）だけを計算します。qwen3.5:35b-a3bは総35Bですが活性は3B。Q4量子化後のモデルサイズが14.8GBの実効枠に収まれば動作します。ただし速度はDense 14Bより遅く、当サイト実測では18.5 tokens/secでした。
Q. RTX 5080とRTX 5090の差は何GBで効きますか？
RTX 5090は32GB VRAMで、RTX 5080の2倍。差が明確に効くのは27B以上のDenseモデル（qwen3:32b・gemma4:31b・qwen3.5:27bなど）を動かしたい場合。22B以下しか使わないならRTX 5080で十分で、価格差（約35万円）に見合いません。70Bクラスや4K動画生成の並列処理が必要ならRTX 5090が本命。
Q. CPUオフロードで32Bモデルは実用速度で動きますか？
実用範囲とは言い難いのが正直なところ。RAMへの一部退避が発生すると、速度はフルGPU時の10〜20%まで落ちるのが一般的です。対話用途なら待てる範囲、コード生成や自動処理では実用に厳しい水準。RAMは最低64GB、できれば96GB以上を用意したいところ。当サイトの検証環境も96GB RAM構成です。
Q. ドライバを更新すればVRAM不足エラーは消えますか？
消えません。SKIPPED_VRAMはドライバの問題ではなく物理的なVRAM容量不足。ドライバ更新で改善するのは起動速度や推論速度の微調整程度。16GBの枠を超えるモデルを動かしたい場合は、モデルサイズを変えるかGPUを変えるしかありません。
Q. RTX 5080とRTX 5060 Ti 16GBのデュアルGPU構成で32Bは動かせますか？
合計32GB VRAMが取れるため、qwen3:32b Q4_K_M（約19-20GB）はモデル分割で動作させやすくなる。ただしllama.cppの自動分散はテンソル並列ではなく層分割（layer split）が中心で、推論速度は単一GPU換算より落ちる。当サイトの検証ではOculink経由のRTX 5060 Tiを追加した構成で、32Bクラスを起動して対話できる水準は確保できた。極端な高速化目的より「容量の壁を越える」目的に向く構成。Oculink帯域がPCIe x4相当に制限されるため、外付け側に大量のレイヤーを乗せると帯域がボトルネックになりやすい。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
