VRAMが足りないとき、メモリを増やせば解決する？ローカルLLMのオフロードで実際に移すもの（2026）

VRAMとメモリの間には何がある？

PCIeバスと十数倍の帯域幅の差があります。VRAMは900～1800 GB/s、デュアルチャネルDDR5は約70 GB/s、PCIe 4.0 x16は約32 GB/sです。 トークンを1つ生成するたびに、計算に使う重みをすべて読みます。そのバイト列をどこから、どの経路で読むかが速度を決めます。

GPU帯域幅は各機種の仕様ページに基づき、メモリとPCIeは一般的なデスクトップの実際の値を使っています。DDR5-5600のデュアルチャネルは理論値89.6 GB/sで、実際にはその7～8割です。PCIe 4.0 x16の片方向理論値は31.5 GB/sで、PCIe 5.0では倍の63 GB/sになります（PCI Expressの世代別帯域幅、DDR5の仕様）。当サイトの速度式ではシステムメモリを70 GB/sに効率0.7を掛けて計算します。算定基準は方法の説明を参照してください。

つまり「16GB VRAM＋64GBメモリ」は80GB VRAMではありません。メモリに置いた重みはトークンごとに十数倍遅い経路を通り、速い側は待つしかありません。オフロードの要点は、遅い経路を通るバイト数をできるだけ少なくすることです。

オフロードでは実際に何を移している？

3種類のオフロードでは移すものが違います。密モデルのレイヤーオフロードは毎トークン必要な重み、MoEエキスパートオフロードは毎トークン一部しか使わないエキスパート、拡散モデルのブロックオフロードは各ステップで必要だが1ステップに1度しか使わない重みを移します。 名前は同じoffloadでも、代償は1桁違います。

1. 密モデルのレイヤーオフロード。llama.cppは-nglでGPUに置くレイヤー数を指定し、残りはCPUで計算します。密モデルは各トークンがすべてのレイヤーを通るため、CPU側のレイヤーはメモリ帯域幅に従って動きます。最も一般的で、最も割に合わないオフロードです。
2. MoEエキスパートオフロード。MoEモデルの各レイヤーには数十～数百のエキスパートがありますが、1トークンで有効になるのは数個だけです。llama.cppの--n-cpu-moeはエキスパート重みをすべてメモリに置き、Attentionレイヤー、共有エキスパート、KVキャッシュはGPUに残します。トークンごとにメモリから読むのは有効な数個のエキスパートだけで、遅い経路を通るバイト数は全重みの数十分の一です。gpt-oss 120Bは総パラメータ数117Bに対し、各トークンで読むエキスパートは3.6Bだけなので、16GB GPUでも動くのです。
3. 拡散モデルのブロックオフロード。ComfyUIとDiffusersはUNetやDiTの重みをブロックごとにメモリに置き、推論の各ステップで順番にGPUへ移して計算し、次のブロックと入れ替えます。各ステップでモデル全体をPCIe経由で移しますが、拡散モデルは1ステップの計算量が多く、総ステップ数も固定なので、追加の転送時間は画像1枚あたり通常数秒～数十秒です。Diffusersのドキュメントにあるmodel offloadとsequential offloadが、この2種類の粒度です（Diffusersのメモリ最適化）。

この3つのうち、「メモリ増設」をまともな解決策にできるのは2番目だけです。以下で別々に計算します。

密モデルのレイヤーオフロード：移すレイヤー数と速度低下の関係は？

1割を移すと速度は半分、3割を移すと4分の1になります。 当サイトの式でRTX 3090上のQwen3 32B 4-bitのデコード速度を計算し、GPUに残す重みの割合を100%から下げると、次のようになります。

これほど急に落ちるのは、1トークンの所要時間が2つの部分の合計だからです。GPU側は900 GB/s、メモリ側は49 GB/sで読みます。1.8 GBをメモリに置くと、その読み取りだけで毎トークン37ミリ秒かかり、GPUが残り16.5 GBを読む26ミリ秒より長くなります。メモリ側の処理が生じた瞬間にボトルネックとなり、GPUがどれほど速くても待つしかありません。

実際のGPU選びに当てはめると、16GBのRTX 5070 TiでQwen3 32B 4-bitを動かす場合、重み18.3 GBにKVキャッシュ2 GBが加わり、GPUには66%しか残せず、推定7 tokens/sです。同じモデルを24GBのRTX 3090のVRAMに丸ごと置けば、推定32 tokens/sです。Gemma 4 31Bはさらに厳しく、大きなKVキャッシュのため16GBには重みの37%しか入らず、推定4 tokens/sとなります。

結論は明快です。密モデルがVRAMを超えると、メモリ増設で得られるのは「動くが使いものにならない」状態です。使えるようにするには、まずコンテキストを下げ、次に3-bitへ下げ、最後に24GB GPUへ交換します。16GBで動くモデルの対処順序を参照してください。たまに70Bモデルを1回動かすなら2 tokens/sでも我慢できますが、毎日は無理です。

MoEエキスパートオフロード：メモリ増設が本当に役立つ場面

MoEのエキスパートをメモリに置くと、必要VRAMは4～7 GBだけになり、速度はメモリ帯域幅で決まり、16GB以上のGPUならほぼ同じです。 下表はモデルデータベースからリアルタイムに計算しています。「オフロード」欄はVRAMとメモリの2つの数値です。

3つの規模では見方が異なります。

• 30B級MoE（Qwen3.6 35B A3B、Gemma 4 26B A4B、GLM 4.7 Flash）：4-bitの全体に必要なVRAMは17～22 GBで、24GB GPUなら直接VRAMに置けて推定110～145 tokens/sです。16GB GPUでオフロードするとVRAM 4～6 GB、メモリ13～19 GBで、推定38～54 tokens/sです。32GBメモリで足り、日常のチャットやコード作成にも十分な速度です。
• 100B級MoE（gpt-oss 120B、GLM 4.5 Air）：全体には62～67 GBのVRAMが必要で、1枚で収まる民生用GPUはありません。オフロード後はVRAM 4～7 GB、メモリ56～65 GBで、推定12～21 tokens/sです。最もメモリ増設の価値がある場面で、16GB GPUと96GBメモリがあれば、本来はRTX PRO 6000でなければ全体を載せられないモデルを動かせます。
• 300B級MoE（DeepSeek V4 Flash）：メモリは155 GB以上必要で、推定12 tokens/sです。動きますが、搭載メモリ自体が192GBからになります。DeepSeekのGPU選びにあるフルモデルの評価を参照してください。

オフロード時はGPUの機種が速度にほぼ影響しないことが、最も直感に反する点です。

アスタリスク付きはオフロード時の速度です。gpt-oss 120BはRTX 5070 Ti、RTX 3090、RTX 5090のいずれでも21 tokens/sです。各トークンで有効な3.6Bのエキスパートをメモリから読む40ミリ秒余りが時間の大半を占め、GPU側は1～2ミリ秒しかかからないためです。同じモデル全体を96GBのRTX PRO 6000に置けば153 tokens/s、Mac Studio M4 Max 128GBのユニファイドメモリなら68 tokens/sです。100B級MoEを速くするには、モデル全体をVRAMに収めるか、Macのユニファイドメモリを使います。Macユニファイドメモリの比較を参照してください。オフロードのために高価なGPUを買うのはお金の無駄です。

メモリ増設前に何を確認する？

注文する前に、メモリ帯域幅、容量、llama.cppの引数を確認してください。 次の3点を順に確認します。

1. チャネル数が帯域幅を決める。上表の速度はデュアルチャネルDDR5の約70 GB/sで計算しています。ノートPCやミニPCはシングルチャネルや直付けメモリだけの場合が多く、帯域幅が半分ならオフロード速度も半分です。クアッドチャネルのワークステーションなら倍になります。メモリはペアで取り付けてください。スロットを間違えてシングルチャネルになるのが、最もよくある無駄です。
2. 容量はエキスパート重みに2割を加える。OS自体、KVキャッシュ以外の実行時バッファ、ブラウザーもメモリを使います。gpt-oss 120Bのエキスパート重み65 GBには96GB、GLM 4.5 Airの56 GBには64GBではぎりぎりで96GBなら安心、Qwen3.6 35B A3Bの19 GBには32GBで十分です。メモリ不足になるとOSがディスクへスワップし、速度は1 tokens/s未満に落ち、動かさないほうがましなほどです。
3. 引数を正しく指定する。llama.cppの起動時に--n-cpu-moe Nを加えます。NはエキスパートをCPUに置くレイヤー数で、モデルのレイヤー数から下げて調整します。VRAMに余裕があれば小さくし、より多くのレイヤーをGPUに残します。-ngl 99でAttentionレイヤーをすべてGPUに置きます。LM Studioのモデル読み込み設定にはエキスパート重みをCPUに置くスイッチがあり、ほかのフロントエンドは各バージョンのドキュメントに従います（llama.cppリポジトリ）。

Windowsユーザーにはもう1つ落とし穴があります。NVIDIAドライバーは既定でシステムメモリへのフォールバックが有効で、VRAMが埋まるとデータを自動でメモリへあふれさせます。エラーは出ず、速度だけが一桁に落ちます。これは意図したオフロードではなく、ドライバーが最悪のオフロードを代わりに行っている状態です。NVIDIAコントロールパネルの「3D設定の管理」で「CUDA - システムメモリーフォールバックポリシー」を「システムメモリーへのフォールバックなしを優先」にすると、VRAM不足がきちんとエラーになり、実際に収まるか分かります。

メモリ増設ではなくGPUを交換すべきなのはいつ？

普段使うモデルが密モデルでVRAMを2割以上超えるならGPU交換、MoEならメモリ増設です。 費用は同程度でも、効果は10倍違います。

Qwen3 32Bのような密モデルで計算すると、16GBのRTX 5070 Tiと64GBメモリではオフロード後7 tokens/s、24GBのRTX 3090のVRAMに全体を置けば32 tokens/sです。中古3090は5070 Tiより安く、増えるVRAMは増えるシステムメモリよりはるかに価値があります。3090と5070 Tiの比較を参照してください。

逆にgpt-oss 120Bでは、RTX 5090のオフロード後は21 tokens/s、RTX 5070 Tiも21 tokens/sです。2枚の価格差は約1万元ですが、このモデルを動かす限りまったく違いません。そのお金を96GBメモリに回しても、半分以上が残ります。

判断ルールは3つだけです。

• 普段のモデルが密モデルで、VRAM不足が2割以内なら量子化ビット数やコンテキストを先に下げる。2割を超えるならGPUを交換する。
• 普段のモデルがMoEなら、エキスパート重みの1.2倍までメモリを増やす。GPUは16GBあればよい。
• たまにしか動かさない大きなモデルなら、オフロードで我慢し、そのためだけに何も買わない。

画像・動画生成のオフロードは何が違う？

拡散モデルのオフロードの代償は、各ステップに数秒の転送時間が加わることです。毎トークンの速度が10分の1になるわけではないため、より我慢しやすい一方、VRAMのピークはVAEデコードで生じることが多く、その段階ではオフロードは役立ちません。 LLMのデコードは「トークンごとに重みを1回読む」、拡散モデルは「ステップごとに重みを1回読み、それを数十ステップ行う」ため、計算が違います。

ComfyUIはVRAMが足りないと、重みを自動でメモリに置いてブロック単位で読み込みます。画像1枚あたり数秒～数十秒余計に待つ程度なら、多くの人は許容できます。公式Wan 2.2ドキュメントの「8GB VRAMで5Bモデルが動く」という説明も、このネイティブオフロードに基づいています（ComfyUI Wan 2.2チュートリアル）。これは5B版とオフロードの組み合わせの話で、A14B版はその条件に含まれません。両者のVRAM数値を混同してはいけません。

動画生成を本当に止めるのは、重みではなくVAEデコードであることがよくあります。数十フレームの潜在変数を一度に画素へデコードすると、VRAMピークが生成段階を上回る可能性があります。この段階は重みが小さく、中間テンソルが大きいため、重みをオフロードしても意味がありません。「最後のステップでVRAM不足になる」場合は、メモリ増設ではなく、タイル分割デコード、解像度の削減、フレーム数の削減が必要です。

画像・動画ユーザーへの判断も単純です。メモリ増設は動かなかったワークフローを動かせますが、画像1枚ごとの待ち時間が増えます。待ち時間を削るにはやはりVRAMが必要で、動画生成のVRAM要求の上限はLLMよりはるかに高くなります。16GB VRAMで動くモデルにある容量帯別の説明を参照してください。