VRAM 16GB：RTX 5080 VRAM不足でLLMが起動しないエラーの解決法｜原因と対処法を徹底解説

RTX 5080 VRAM不足エラーとは、公称16GBのVRAMのうち実際にモデルへ回せる枠に要求量が収まらず、ロードが通らない・あるいは通っても一部（場合によっては全部）がCPU側に置かれて極端に遅くなる状態のこと。

Ollamaで32Bクラスのモデルをロードしようとして生成が始まる前に止まる、あるいは起動はしたものの極端に遅い。RTX 5080は16GBを搭載しているのに、なぜ32Bクラスでつまずくのでしょうか。答えは公称容量と、実際にモデルへ回せる枠の差にあります。

このエラーの症状と確認すべき環境情報

Ollamaやllama.cppでモデルをロードしようとした瞬間、以下のようなログや挙動が出ていれば本記事の対象です。

よくある症状:

• Ollamaのログに insufficient VRAM to load any model layers のような、GPUへオフロードできるレイヤーがないことを示すデバッグログが出る
• モデルのダウンロードは完了しているのに推論が始まらない
• モデル名を指定してollama runを実行しても、プロンプト入力画面に入らないまま終了する
• CUDA error: out of memory がモデルロード中に発生
• ロードは通るが最初のトークン生成後にクラッシュ
• 起動はするが極端に遅く、ollama psのPROCESSOR列にCPUの割合が表示される

これらの症状では、まずVRAM不足またはCPU側へのオフロードを疑います。ただし、ドライバやOllamaの不具合でも似た症状が出るため、ollama ps、nvidia-smi、サーバーログを合わせて切り分けます。対処前に押さえておきたいのは、GPUの搭載VRAM容量、NVIDIAドライバとOllamaのバージョン、そしてアイドル時の空きVRAMの4点です。

アイドル時に他のプロセスが使っている分は、そのままモデルへ回せる枠を削ります。ブラウザやウィンドウマネージャがGPUメモリを先取りしていれば、その分は空けられる余地。ただし常駐アプリの構成は環境ごとに違うため、「何GiB以下なら正常」という一律のしきい値はありません。本記事の計測条件（ドライバ・Ollamaのバージョン等）は記事末尾の一覧にまとめています。

16GBがそのまま使えるわけではない｜VRAM不足でロードが止まる仕組み

RTX 5080は公称16GBのVRAMを積みますが、nvidia-smiが表示する総容量は約15.9GiB。ここからWindowsのデスクトップ表示やNVIDIAドライバ本体が使う分が引かれ、さらにモデル本体に加えてKVキャッシュとコンテキスト用のバッファが必要になります。当サイトの環境（RTX 5080）で2026年7月24日に計測した範囲では、単体で動かせたモデルのGPU全体使用量（nvidia-smiのmemory.used＝他プロセス込みのベースラインを含む値）は最大で約15.6GiBでした。これは本検証で観測した最大値であって、ハードウェアの上限を示す値ではありません。

Ollamaはモデルをロードする前に必要なメモリ量を見積もり、GPUに載る分だけレイヤーを割り当てます。載り切らない分はCPU側のメモリに置かれます。1レイヤーもGPUへ載せられない場合、デバッグログに insufficient VRAM to load any model layers と記録され、100% CPU配置での実行へ切り替わることがあります。これは「GPUへオフロードできるレイヤーがない」ことを示すログで、モデルのロードそのものが失敗したという意味ではありません。システムRAMも不足する場合や、メモリの割り当てに失敗した場合はロード自体が止まります。つまり「起動はするが一部（あるいは全部）がCPUに置かれて遅い」ケースと「そもそも推論が始まらない」ケースは地続きで、どちらもVRAM枠の不足が背景にある。Ollama公式ドキュメント（Hardware support）とOllama公式FAQに、対応GPUの条件とメモリ関連の環境変数が整理されている。

対処手順:

1. nvidia-smiでアイドル時のVRAM使用量を確認する。Windowsのデスクトップ効果やブラウザが使っている分を把握
2. 不要なブラウザタブ・Discord・ハードウェアアクセラレーションが有効なアプリを終了する。当サイトの計測では単体で動かせたモデルでもGPU全体で15GiB台まで使う場面があったため、空きVRAMは多いほど余裕が出る
3. 直前に使ったモデルがメモリに残っているなら降ろす。既定ではモデルが約5分間メモリに保持されるため、その間は次のモデルに回せる分が減る。個別に降ろすならollama stop <モデル名>、保持時間そのものを変えるならOLLAMA_KEEP_ALIVE、APIから即時に降ろすならkeep_aliveに0を指定する（Ollama公式 CLIリファレンス）
4. 起動したいモデルのファイルサイズとコンテキスト長を確認する。16GBに対して余裕のない値なら、全レイヤーがGPUに載らない前提で考える

ステップ2でVRAM使用量が思ったほど減らない場合、GPUハードウェアアクセラレーションを使っているバックグラウンドアプリが残っている可能性があります。タスクマネージャの「GPU」タブで使用プロセスを一覧表示できます。

「載った」ように見えても一部はCPUに置かれている

ロードが通ったかどうかだけでは、モデル全体がVRAMに乗っているかは分かりません。Ollama公式FAQは、正常にロードされた配置として「100% GPU」「100% CPU」「CPUとGPUの混在」を区別しています。この記事では、これにロード失敗を加えた次の4つに分けて扱います。

• 100% GPU配置: モデル全体がGPU側にロードされている状態
• CPU・GPU混在: モデルがGPUとシステムメモリに分割して置かれている状態
• 100% CPU配置: GPUへレイヤーを載せず、システムメモリ上で実行している状態
• ロード失敗: システムRAM不足・メモリ割り当ての失敗・互換性の問題などにより、推論自体が始まらない状態

「単体で動作した」は上3つのいずれでも成立するため、動いたかどうかだけでは配置は判別できません。判別にはOllamaが表示する情報を使います。ollama psのPROCESSOR列にCPUとGPUの配分が表示され、APIが返すsize_vram（VRAMに載ったモデル量）とsize（モデル総量）の比も参考になります。当サイトの今回の計測では、size_vram÷sizeとollama psのPROCESSOR表示はほぼ一致しました。配置の判定はollama psで行い、API値は補助確認として扱っています。MoEの2本は同じ通称でもタグによって必要量が変わるため、実測に使ったタグとdigestを先に固定しておきます。使用したのはgemma4:26b-a4b-it-q4_K_M（digest 5571076f3d70、Ollamaでの表示サイズ18GB）とqwen3.5:35b-a3b-q4_K_M（digest 3460ffeede54、公式モデルライブラリでの表示サイズ24GB）の2つで、以降は短縮名のgemma4:26b・qwen3.5:35b-a3bと書きます。計測結果は次のとおりです。

※size_vram÷sizeとPROCESSOR列は、gemma4:26bとqwen3.5:35b-a3bのみ2026年7月25日にコンテキスト長8192で追加取得した値。それ以外の行と、GPU全体使用量はいずれも2026年7月24日の計測値です。

この表で見落としやすいのが、GPU全体使用量とsize_vramのずれ。gemma4:26bとqwen3.5:35b-a3bはどちらもnvidia-smi上で約15.2GiBを使っており、数字だけ見れば16GBをほぼ使い切っています。それでもモデル本体がVRAMに載った割合は72.7%と58.3%どまり。GPU全体使用量にはKVキャッシュ・演算用バッファ・他プロセスの使用分が含まれるため、「VRAMが埋まっている＝モデルが全部載っている」ではありません。

qwen3-coder:30bをロードしたときのollama psの出力がこちら。

▼ ollama ps の実出力（表示された値のまま）

PROCESSOR列の「26%/74% CPU/GPU」と、APIのsize_vram÷size＝約74.1%は一致していました。このときシステムRAMの使用量も約5.5GB増えました。RAMの増分にはランタイムやKVキャッシュの確保も含まれるため内訳までは切り分けていませんが、CPU側への配置が発生したというPROCESSOR表示とは整合しました。当サイトの計測範囲では、PROCESSOR列に「100% GPU」と表示されたモデルはsize_vram÷sizeもほぼ100%になっています。

同じ確認を、総パラメータの大きいMoEモデル2本にも行いました。2本を同時に載せると条件が変わるため、それぞれ別セッションで1本ずつロードし、そのときの出力を1つの表にまとめます。

▼ ollama ps の実出力（別セッションで1本ずつロードした2回分を並べたもの・表示された値のまま）

SIZE列では、ロード済みモデルのメモリ規模がそれぞれ18GB、23GBと表示されています。PROCESSOR列は「起動はしたが、それぞれ27%・42%はCPU側にある」という状態を示していて、100% GPU配置ではありません。なおollama psのSIZE列は、表示単位や集計方法により、モデルライブラリのファイルサイズと差が出る場合があります。ここで要点になるのは端数ではなく、どちらの見方でも16GBを超えているという事実のほうです。

この記事の主題に直結するのは、ロードが止まらなくても部分的なCPU配置は起きるという点。「起動したから問題ない」ではなく、PROCESSOR列とsize_vramで実際の配置まで確認したほうが、速度が出ない原因の切り分けが早くなります。

32BクラスのDenseモデルがVRAMに収まらない理由｜MoEとの違い

当サイトの計測結果を、さきほどの4分類（100% GPU配置／CPU・GPU混在／100% CPU配置／ロード失敗）で並べ直します。

※tokens/secは共通の日本語長文生成タスクでの生成速度（中央値）で、2026年7月24日の計測値。コード生成速度や出力品質は計測していません。PROCESSOR列とsize_vram÷sizeのうち、gemma4:26bとqwen3.5:35b-a3bの値は2026年7月25日に追加取得しました。

とくに注意したいのがMoEの2本です。総パラメータが26B・35BあるMoEモデルは単体のRTX 5080でも起動しましたが、起動したことと16GBに収まったことは別。Ollama公式モデルライブラリが示す配布サイズはgemma4:26b-a4b-it-q4_K_Mが18GB、qwen3.5:35b-a3bのQ4_K_Mが24GBで、どちらも16GBへ全量を配置できません。実測でもgemma4:26bは27%、qwen3.5:35b-a3bは42%がCPU側に置かれた状態で動いていました。

当サイトが今回100% GPU配置を確認したのは、phi4:14b、qwen3:14b、deepseek-coder-v2:16b-lite の3本でした。ただしこれはパラメータ数で線が引けるという意味ではありません。同じモデルでもタグ（量子化）とコンテキスト長で必要量は変わるため、判断材料になるのはパラメータ数ではなく、実際に使うタグの配布サイズと動かすコンテキスト長です。モデル別に16GBへ収まるか・あふれるかを一覧で見比べたい場合は、VRAM 16GBで動かすローカルLLMのモデル別早見表に整理しています。

活性パラメータと保存メモリは別物｜DenseとMoEの違い

Denseモデルは、原則として全パラメータが各トークンの計算に関与します。VRAMに収まらない場合でも一部をCPU側に配置して実行はできますが、その割合が大きいほど速度は落ち、条件によっては大幅に低下します。32BをQ4_K_M量子化しても実サイズは約19〜20GB前後（willitrunai.comやapxml.comの算出値ではqwen3:32b Q4_K_Mで約19.8GB）となり、16GBのVRAMには全量を置けません。これが32Bクラスで100% GPU配置にならない理由。なお、この種の一覧サイトが載せているのはハードウェア仕様から算出した推定値で、実機の計測値ではない点は割り引いて見る必要がある。Hugging Face Qwen3-32B モデルカードに総パラメータ数と推奨ハードウェア要件が掲載されている。

MoE（Mixture of Experts）は総パラメータが大きくても、推論時に使う「活性パラメータ」だけを計算します。qwen3.5:35b-a3bは総35Bで活性は3B。ここで混同しやすいのが、活性パラメータが効くのは1トークンあたりの演算量であって、モデルを保持するために必要なメモリではないという点です。どのエキスパートが呼ばれるかは入力ごとに変わるため、全ての重みをGPUのVRAMかシステムRAMのどこかに置いておく必要があります。活性が3Bでも、配布サイズが16GBを超えれば全量はVRAMに載りません。実測でqwen3.5:35b-a3bの42%、gemma4:26bの27%がCPU側に置かれていたのはこのためです。総パラメータと活性パラメータを分離する設計はMixtral of Experts (Jiang et al., 2024)で広く知られるようになり、推論時の演算量とモデル容量のトレードオフを整理する出発点になっている。

対処手順:

1. ollama listで現在ダウンロードしているモデルとそのサイズを確認
2. 使わないモデルを削除してストレージを空ける（ollama rm qwen3:32b）。ここで削除されるのはディスク上のモデルファイルで、VRAMの解放とは別の操作。メモリに載ったままのモデルを降ろしたいときはollama stop <モデル名>かAPIのkeep_aliveに0を使う
3. モデルの配布サイズが空きVRAMを十分に下回り、KVキャッシュや実行バッファを含めた総要求量が収まる構成へ切り替える。qwen3:32b → qwen3:14b のようにサイズを落とすのが基本で、MoE版に替えても配布サイズが16GBを超えていれば一部はCPU側に置かれる。最終的な配置はollama psで確認する
4. ロード時にnvidia-smi -l 1で1秒ごとのVRAM推移を観察する。使用量が伸び切って頭打ちになり、ollama psのPROCESSOR列にCPUが出ていなければ全レイヤーがGPU側にある

ステップ3で総サイズの大きいMoEを選ぶと、速度が下がる場合があります。2026年7月24日に共通の日本語長文生成タスクで計測した中央値は、gemma4:26b（MoE）が59.46 tokens/sec、qwen3.5:35b-a3bが53.81 tokens/sec。100% GPU配置だったDense 14Bのqwen3:14b（73.14 tokens/sec）と比べると2〜3割低い水準でした。ただしこれはMoEという構造そのものの優劣ではなく、今回比較したモデル・量子化・CPU側への配置割合の組み合わせで出た結果。配置が変われば同じモデルでも数字は変わります。

量子化レベル別のVRAM消費目安

同じモデルでも量子化レベルを変えるとVRAM要求は大きく変わる。llama.cppで使われる代表的な量子化フォーマットについて、Qwen3 32Bの代表的なGGUF配布ファイルを基準にした目安サイズと、RTX 5080単体（16GB）へ全量を載せられるかの見通しを並べた。なおQ4_K_MのようなK量子化は、テンソルごとに複数の形式を組み合わせる方式で、名称に含まれる数字が全テンソル一律のビット幅を表しているわけではない。llama.cpp公式 quantize READMEは各フォーマットの実効bits/weightを併記しており、名称上の区分と実際のビット数は分けて見る必要がある。

※目安サイズはQwen3 32Bの代表的なGGUF配布ファイルを基準にした概算で、モデル本体のみの値。同じ区分名でも配布元やモデルによってファイルサイズは前後します。実際にはこれに加えてKVキャッシュとコンテキスト用のバッファがVRAMを使うため、モデルサイズが16GBを下回っていれば必ず載る、とは言えません。コンテキスト長を伸ばしたときにKVキャッシュがどこまで膨らむかは、VRAM 16GBでコンテキスト長はどこまで伸ばせるか（KVキャッシュ量子化の実測）で扱っています。

Q3_K_Mまで落とせば32B Denseでも16GBの枠に滑り込む可能性が出てくる。一般に低ビット化するほど品質低下のリスクは高まるが、影響の出方はモデルとタスクで異なり、本記事では出力品質を計測していない。当サイトの運用上の選び方としては、配布サイズが16GBの枠に対して余裕を持って収まるモデルを高品質量子化（Q5_K_M / Q6_K）で動かす構成を先に試し、32B Denseの極端な低ビット量子化は最後の手段として扱っている。なお22Bクラスは当サイトの計測でQ4_K_Mの時点でGPU全体15.6GiBまで使っており、そこから量子化を上げる余地はほとんど残っていません。

Codestral 22Bの生成速度が伸びない場合の対処

22Bクラスは単体のRTX 5080でも動きます（当サイトの計測ではCPU・GPU混在）が、「他サイトに載っている数値に届かない」というケースがあります。最初に疑うべきは量子化の違い。codestral:22bの既定タグはQ4_0で、Q4_K_M版はcodestral:22b-v0.1-q4_K_Mという別タグです。2026年7月24日に共通の日本語長文生成タスクで計測したところ、既定のQ4_0版が35.38 tokens/sec（GPU全体15,454MiB＝約15.1GiB）、Q4_K_M版が21.94 tokens/sec（GPU全体約15.6GiB）でした。同じ「codestral:22b」と呼んでいても、タグが違えば速度もVRAM使用量も変わります。

Q4_K_M版で記録した108.1msという値についても、測定状態を確認しておきます。これはモデルがメモリに常駐した状態でAPIが返したload_durationとprompt_eval_durationの合計で、モデルの読み込みから測ったコールドロード時間ではありません。最初のトークンが出るまでの時間（TTFT）を厳密に測った値でもないため、他サイトのTTFTと並べて比較できる数値ではない点に注意してください。

他サイトの数値と比べるときも同じ注意が要ります。willitrunai.comのRTX 5080欄には約25.6 tokens/secという値が載っていますが、これは実機を計測した値ではなくハードウェア仕様から算出された推定値で、当サイトの実測と直接比較できるものではありません。量子化・Ollamaのバージョン・プロンプト・計測方法が揃っていない数値同士を並べても、差の原因は特定できない。

対処手順:

1. ollama psでPROCESSOR列を確認する。CPUの割合が出ていれば一部がCPU側に置かれており、生成速度が落ちる要因になる
2. GPUに載せるレイヤー数はOllamaが自動で決めるが、APIのoptions.num_gpuで明示することもできる。Modelfileでの指定は扱いがバージョンによって変わる可能性があるため、使用中のバージョンで有効かどうかを確認してから使う。指定したあとはollama psで実際の配分を見る
3. nvidia-smiのボード電力は補助情報にとどめる。電力の出方はモデルの構造・バッチサイズ・生成フェーズ・メモリ帯域のボトルネックでも変わるため、値の高低からCPU・GPU混在かどうかは判定できない。配置の判定はステップ1のollama psか、APIが返すsize_vramで行う
4. Ollamaのバージョンを確認する。バージョンによってメモリ見積もりやスケジューリングの挙動が変わるため、他の環境の数値と比べるときは前提を揃える
5. プロンプト長を短くして測り直す。長いプロンプトはプロンプト評価時間（APIのprompt_eval_duration）を押し上げ、生成が始まるまでの待ち時間を伸ばす

ollama psが「100% GPU」と表示していれば全レイヤーがVRAMに乗っています。「26%/74% CPU/GPU」のように割合が出ていれば一部はCPU側。当サイトの計測では、qwen3-coder:30bを単体のRTX 5080で動かすと68.95 tokens/sec、OCuLink接続のRTX 5060 Tiを足した2GPU構成では154.72 tokens/secと約2.2倍の差が出ました（共通の日本語長文生成タスク）。ただし2GPU構成では演算資源とメモリ帯域も増えるため、CPU配置が減ったことだけが差の要因とは切り分けられません。

VRAM消費を継続監視する手段

長時間運用でVRAMリークや常駐モデルの占有を見抜くには定常監視が要る。標準的な選択肢を整理する。

• nvidia-smi -l 1: 1秒ごとのVRAM・温度・電力をCLIで確認。スクリプトでgrepしてログ化しやすく、長時間ベンチマークの記録にも向く
• nvtop: Linux向けTUI監視ツール。GPUプロセス一覧と帯域・温度を一画面で把握できる
• ollama ps: ロード済みモデルとSIZE・PROCESSOR（GPUとCPUの配分）を表示。VRAMに載り切っているかの確認に直結する
• タスクマネージャ GPU タブ: Windowsで各プロセスのVRAM割当を可視化。「専用GPUメモリ」の使用量で、どこまで埋まっているかが分かる

Ollamaサーバを常駐させる構成ではOLLAMA_KEEP_ALIVEを短めに設定するとメモリの占有時間が縮む。既定ではモデルは約5分間メモリに保持される。Ollama公式FAQ「How do I keep a model loaded in memory or make it unload immediately?」に指定方法が記載されており、0で即時アンロード、時間指定、-1で保持し続ける、の3通り。ただし-1を指定してもメモリが足りなくなれば退避は起こるため、常駐を保証するものではない。保持中はVRAMを占有するが、新しいモデルのロード時には、必要に応じてアイドル状態のモデルのアンロードや待機が発生する。確実に先に解放しておきたい場合はollama stopを使う。

それでも解決しない場合の代替手段

VRAM不足がどうしても解消しない、または32Bクラスを動かしたい場合、次の4つの選択肢があります。それぞれの特性を理解した上で選んでください。

選択肢1: 量子化レベルを下げる

量子化を下げると、モデルファイルを数GB小さくでき、その分だけVRAM要求も下がります。Q4_K_Mでは全量を置けなかったクラスでも、枠に収まる余地が出てくるということ。ただし収まるかどうかはタグの実サイズとコンテキスト長しだいで、パラメータ数だけでは決まりません。一般に低ビット化するほど品質低下のリスクは高まりますが、影響の大きさはモデルとタスクで異なり、本記事では出力品質を計測していません。量子化レベルごとのVRAM消費と生成速度の実測値は、Q4_K_M・Q8_0・FP16のVRAMと速度を実測比較した記事にまとめています。

選択肢2: CPUオフロード

Ollamaやllama.cppは、GPUに載り切らないレイヤーをCPU側のメモリに置いて実行します。VRAMに全量が入らないモデルでも動かせる余地があるのはこのため。ただしCPUに置かれる割合が大きいほど生成速度は落ちます。落ち幅はオフロード比率とCPU・メモリの性能で変わるため一律には言えません。また、CPUオフロード時はRAM消費も跳ね上がります。当サイトの計測でも、単体GPUではVRAMに載った割合が74.1%だったqwen3-coder:30bをロードした際、システムRAMの使用量が約5.5GB増えました（増分にはランタイムやKVキャッシュの確保も含まれます）。必要なRAM量はモデルサイズとCPU側へ回る割合で変わるため一律には言えませんが、当サイトの運用では64GB以上を推奨しています（検証機は96GB構成）。

選択肢3: セカンドGPU追加・OCuLink接続

RTX 5080にRTX 5060 Ti 16GBなどを追加してデュアルGPU構成にすると、合計32GB VRAMが使えます。OCuLink経由の外付けGPUも選択肢。llama.cppやOllamaは複数GPUへの自動分散に対応しています。当サイトの2026年7月24日の計測では、この2GPU構成でqwen3.5:27bが29.95 tokens/sec、gemma4:31bが25.72 tokens/secでした（いずれも単体では計測せず、2GPU構成のみで計測。共通の日本語長文生成タスク）。32Bクラスを単体GPUで諦めたくない場合の有力な選択肢になります。llama.cpp公式ビルドドキュメントにマルチGPU環境でのCUDAビルド手順と分散設定が記載されている。

選択肢4: クラウドAPIへの切り替え

Claude APIやGemini APIなどのクラウドサービスへ切り替えれば、ローカルPCのVRAM容量に制約されずモデルを利用できます。ローカルGPU不要でノートPCからでも使えます。GPU購入費用と比較してコストが見合う場合は有力な選択肢です。

まとめ

RTX 5080でVRAM不足を示すログやout of memoryエラーが出る主な理由の一つは、公称16GBという数字と、実際にモデルへ割り当てられる量の差を見落としていること。ドライバやランタイム側の不具合という別筋もありますが、この記事で扱う典型的な原因はこの差のほうです。対処の優先順位は次の通り。

まずnvidia-smiで空きVRAMを確認し、他のプロセスが先取りしている分を減らす。これだけで枠が空いて動き出すこともあります。次にollama psのPROCESSOR列を見て、ロードできていても一部がCPU側に置かれていないかを確認する。それでも足りない場合は、配布サイズが空きVRAMを十分に下回り、KVキャッシュや実行バッファを含めた総要求量が収まるモデルへ切り替えるのが次の一手で、切り替えた後の配置はollama psで確認する（当サイトの計測で100% GPU配置を確認できたのはphi4:14b・qwen3:14b・deepseek-coder-v2:16b-lite）。MoEに替えても総サイズが16GBを超えていれば一部はCPU側に残るため、「MoEだから収まる」という判断は成り立ちません。32Bクラスを諦められない場合のみ、量子化レベルの降格・CPUオフロード・デュアルGPU化を検討する順序になります。

※tokens/secは共通の日本語長文生成タスクでの生成速度（中央値）。コード生成速度や出力品質は計測していません。

よくある質問

Q. 16GB VRAMでQwen3 32Bを動かす方法はありますか？

Denseの32BをQ4_K_Mのまま単体のRTX 5080のVRAMへ全量配置することはできません（配布サイズが約19〜20GB）。取りうる選択肢は3つ。量子化を下げてCPU側への配置を前提に動かす、配布サイズが空きVRAMを十分に下回るモデルへ替える、RTX 5060 Tiなどを追加してデュアルGPU化する、のいずれかです。2つ目で同系列のMoE版qwen3.5:35b-a3bを選ぶ手もありますが、こちらも配布サイズは24GBで全量は載りません（当サイトの計測では42%がCPU側に置かれた状態で53.81 tokens/sec）。100% GPU配置にこだわる場合、当サイトの計測範囲でそれを確認できたのはphi4:14b・qwen3:14b・deepseek-coder-v2:16b-liteでした。

Q. 35BのMoEモデルが16GB GPUでも起動することがあるのはなぜですか？

モデル全体がVRAMに収まったからではなく、載り切らない分がCPU側に置かれているためです。MoEは推論時に全パラメータを使わず、活性パラメータ（Active Parameters）だけを計算します。ただし活性パラメータが効くのは1トークンあたりの演算量であって、モデルを保持するために必要なメモリではありません。どのエキスパートが呼ばれるかは入力ごとに変わるため、全ての重みをVRAMかシステムRAMのどこかに置いておく必要があります。qwen3.5:35b-a3b（活性3B）も2026年7月25日の計測でollama psが「42%/58% CPU/GPU」を表示しました。もっとも、CPU・GPU混在でも活性パラメータが少ないぶん、Denseモデルとは速度の出方が変わることがあります。日本語長文生成タスクで計測した中央値は53.81 tokens/secで、100% GPU配置だったqwen3:14bの73.14 tokens/secと比べて2〜3割低い水準。今回のモデル・量子化・配置の組み合わせでの結果です。

Q. RTX 5080とRTX 5090の差は何GBで効きますか？

RTX 5090は公称32GB VRAMで、RTX 5080の2倍。差が効くのは、Q4_K_Mで20GB前後になる27B〜32Bクラス（qwen3:32b・gemma4:31b・qwen3.5:27bなど）を1枚で動かしたい場合です。逆に、使うモデルの配布サイズとコンテキスト長が16GBの枠に余裕を持って収まるならRTX 5080でも100% GPU配置を狙えるため、価格差を払う必然性は薄いところ（実売価格は変動が大きいため購入時点で確認）。ただし同じパラメータ数でも量子化を上げたり長いコンテキストを使えば16GBでは足りなくなるため、判断はパラメータ数ではなく実際に使うタグとコンテキスト長で。32Bクラスを常用したい、あるいは動画生成のように大きなVRAMを要求する用途なら、RTX 5090が候補になります。

Q. CPUオフロードで32Bモデルは実用速度で動きますか？

CPU側に置かれる割合が大きいほど生成速度は落ちます。落ち幅はオフロード比率とCPU・メモリの性能に左右されるため一律には言えませんが、対話用途で待てる範囲に収まっても、コード生成や自動処理では厳しくなりやすい水準。RAMの必要量もモデルサイズとCPU側へ回る割合で変わるため一律には言えませんが、当サイトの運用では64GB以上を推奨しています（検証機は96GB構成）。

Q. ドライバを更新すればVRAM不足エラーは消えますか？

ドライバを更新してもVRAMの物理容量は増えないため、モデルの要求量が16GBの枠を超えているケースでは解消しません。一方で、ドライバやランタイム側の不具合でメモリが正しく確保できていないケースなら、更新で改善する可能性はあります。まずollama psのPROCESSOR列とnvidia-smiの使用量を見て、容量が足りていないのか挙動がおかしいのかを切り分けてください。容量不足だった場合は、モデルのサイズを変えるかGPUを変えることになります。

Q. RTX 5080とRTX 5060 Ti 16GBのデュアルGPU構成で32Bは動かせますか？

合計32GB VRAMが取れるため、qwen3:32b Q4_K_M（約19-20GB）のように単体のVRAMへ全量を置けないクラスも、モデル分割で動かせるようになる。2026年7月24日の計測では、OCuLink経由でRTX 5060 Tiを追加した構成でqwen3.5:27bが29.95 tokens/sec、gemma4:31bが25.72 tokens/sec（共通の日本語長文生成タスク）。単体では一部がCPU側に置かれていたqwen3-coder:30bは、68.95から154.72 tokens/secへ約2.2倍になりました。ただし2枚分の演算資源とメモリ帯域が加わった影響も含まれるため、CPU配置が減ったことだけが要因とは切り分けられません。今回使用したMINISFORUM DEG1のホスト接続はPCIe 4.0 x4で、GPU側の物理スロットがx16でもホストとのリンク帯域はx4になる点は、構成を決めるときの前提になります。なお複数GPUへの分散方式はランタイムと設定によって異なり、今回のOllama構成で各GPUへどの単位で分割されたかまでは検証していません。

参考資料

• NVIDIA 公式: System Management Interface (nvidia-smi) ドキュメント
• Ollama 公式ドキュメント: Hardware support
• Ollama 公式ドキュメント: FAQ
• Ollama 公式ドキュメント: CLI リファレンス
• Ollama 公式モデルライブラリ: qwen3 タグ一覧（Qwen3 32B の配布サイズ）
• Ollama 公式モデルライブラリ: qwen3.5 タグ一覧
• Ollama 公式モデルライブラリ: gemma4 タグ一覧
• Ollama 公式モデルライブラリ: codestral タグ一覧
• Google 公式: Gemma 4 model overview（モデル構成と Dense / MoE の内訳）
• llama.cpp 公式: quantize README（量子化フォーマットと実効 bits/weight）

本記事は AIハードウェア図鑑 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。