RAMオフロードとは、VRAMに収まらないモデル層をCPUのメインメモリへ逃がして動かす手法。
1兆パラメータ級のモデルが、コンシューマ向けGPUのどのVRAMにも載らない。海外のRedditコミュニティ（r/LocalLLaMA）では、Ring-2.6-1Tという1兆パラメータ級の推論モデルが発表され、自宅環境でこの種の巨大モデルをどう回すかという話題が続いている。投稿への反応を見ると、Kimi K2.6やMiMo V2.5 Pro、DeepSeek V4 Proといった大型モデルを手元のマシンで試そうとするユーザーが少なくない。ただ、16GBクラスのVRAMには70Bクラスですら丸ごとは載らない。そこで現実的な選択肢になるのが、モデルの一部をCPU側のRAMへ逃がす「レイヤーオフロード（-ngl分割）」という運用。
- VRAMに収まらないモデルでも、層をCPU側RAMへ分割すれば起動自体は可能。万能ではない
- GPUに載せる層数（-ngl）を増やすほど速いが、VRAM容量が上限。CPU側に残した層の演算とGPU/CPU間の受け渡しが速度を落とす
- 当サイトの検証環境（RTX 5080単体・VRAM 16GB）では、VRAMが埋まりきると生成速度が大きく落ちる挙動を確認
VRAMに収まらない大型LLMという壁 — なぜ手元で動かすのか
大型LLMをローカルで動かそうとして最初にぶつかるのが、VRAMの壁。モデルの重み（パラメータ）は、量子化してもサイズに比例した容量を要求する。1兆パラメータ級ともなれば、量子化を効かせても数百GB規模になり、家庭用GPUの単体VRAMで受け止められる量ではない。70Bクラスでも、4bit量子化（Q4_K_M等）で30GB以上を要し、16GBや24GBのGPUには丸ごとは載らない。
ではなぜ、わざわざ手元で動かすのか。クラウドのAPIを叩けばGPUは不要になる。それでもローカル実行にこだわる理由として、データを自分の管理下に置けるという運用上の動機がある。Computex 2026でSynologyが、AI機能を活用しつつデータをユーザー側で管理できる「ローカル実行」を前面に出した方針を発表したのも、同じ流れの一例。機密性の高い社内文書やコードを外部の推論APIへ送りたくない場面では、多少遅くても手元で完結させたいという需要が残る。
Reddit上の議論を見ても、巨大モデルを「とりあえず自分のマシンで動かしてみたい」という関心は根強い。Ring-2.6-1Tの発表スレッドでも、複数の大型モデルをダウンロードして試すコメントが並んでいた。動かせるかどうかと、実用速度で動くかどうかは別問題。ここを切り分けて考える必要がある。
70Bクラス・1兆パラメータ級が16GB VRAMに載らない理由
モデルが要求するVRAMは、ざっくり「パラメータ数 × 1パラメータあたりのバイト数」で決まる。FP16なら1パラメータ2バイト、4bit量子化なら約0.5バイト。70Bモデルを4bitに落としても35GB前後の重みが残り、これにKVキャッシュ（コンテキスト保持用のメモリ）が積み増される。RTX 5080のVRAMは16GB、中古で人気のRTX 3090でも24GB。どちらも70Bクラスの重みを丸ごとは抱えられない。
Ring-2.6-1Tのような1兆パラメータ級は、さらに桁が違う。開発元の説明によれば、このモデルはエージェント実行や長時間タスクを想定した推論特化型とされる。
Ring-2.6-1Tの目標は、単にパラメータ規模を追うことではなく、エージェントのワークフロー、エンジニアリング開発、科学研究、複雑な業務システムといった、大型モデルが実際に投入される本番環境に対応すること。（Ring-2.6-1Tの開発元による説明）
こうした規模のモデルは、複数の業務用GPUを束ねるか、データセンター級の構成が前提になる。家庭環境で「載せきる」のは現実的でない。本記事では、この上限側の例として言及するに留め、実機では走らせていない。
RAMオフロード（-ngl分割）の仕組み
VRAMに載りきらないモデルを動かす一つのレバーが、レイヤー単位の分割。LLMはTransformerの層が積み重なった構造で、llama.cppやOllamaは「何層までをGPUに載せるか」を起動時に指定できる。この指定が-ngl（n-gpu-layers）。GPUに載った層はVRAM上で高速に処理され、溢れた層はCPUが担当し、その重みはメインメモリ（RAM）に置かれる。
具体的な指定はこのような形になる。
# llama.cpp: GPUに載せる層数を指定（残りはCPU+RAMが担当）
./llama-server -m model-Q4_K_M.gguf -ngl 40 -c 4096
ollama run qwen3.5:35b-a3b
# 対話中に層数を変える場合
# /set parameter num_gpu 40 なお、Ollamaは通常VRAMに収まる範囲でGPUオフロードを自動推定する。num_gpuで明示的に制御する場合は、扱いや指定方法がバージョンによって変わることがあるため、ollama psやサーバーログでGPU/CPUの分割状況を確認しておくと確実。
-nglの値を大きくするほど多くの層がGPUに載り、速くなる。ただしVRAM容量が天井。Ollamaのように収まる範囲を自動推定する実装もあるが、llama.cppで-nglを手動指定する場合は、VRAMを超える値を指定するとOOMや起動失敗につながることがある。CPU側に残した層はメインメモリ上で処理されるため、そこからが速度低下の入口になる。量子化やデュアルGPUとは別の独立したレバーで、「1枚のGPUで足りない分をCPUとRAMに肩代わりさせる」という発想。
GPU/CPU分割比とボトルネックの出どころ
速度が落ちる原因は、層の転送と演算速度の差にある。GPUのVRAMは広帯域で、CPUが使うシステムRAMより桁違いに速い。GPUに載った層はその速度で処理されるが、CPU側に逃がした層は、RAMからの読み出しとCPU演算という遅い経路を通る。生成の各ステップで、CPU側の層を通過するたびに待ちが発生する。GPUに載る割合が下がるほど、この待ちが支配的になっていく。
同じ現象は画像・動画生成でも起きる。r/comfyuiでは、VRAMを大きく超えるチェックポイントを16GBのGPUへ載せようとしたケースが報告されている。重みがVRAMに収まらず、CPU RAMからGPUへ常時ストリーミングする状態になり、生成1本に長時間かかったという。ワークロードは言語生成と動画生成で違っても、「VRAMを超えた分をCPU側に逃がすと、転送がボトルネックになる」という構造は同じ。レバーは共通している。
当サイトの検証環境と計測条件
速度の話を数値で示すため、当サイトの検証環境での計測条件を先に明記しておく。使用したGPUはRTX 5080単体（VRAM 16GB）、システムRAMは96GB。推論エンジンはOllama 0.30.7、量子化はQ4_K_M、コンテキスト長はnum_ctx=4096で揃えた。NVIDIAドライバは610.47、OSはWindows。計測日は2026-06-12。tokens/secは複数回の計測から代表値を採り、thinking対応モデルは思考モードの条件を揃えている。
VRAM使用量として示す値は、nvidia-smiのmemory.used由来の「GPU全体の使用量」。デスクトップ表示などのベースラインを含んだ数値で、単位はMiB（GiB換算を併記）。モデル単体の増分とは別物として扱う。CPUや電源を含むフル構成は専用の検証環境ページに集約済みのため、本文では繰り返さない。計測に使ったGPUと設定だけを、数値の意味を保つために添える。
16GB VRAMで見たLLM推論の壁 — 12B〜35Bの実測
16GBという容量が、どのあたりで壁になるのか。当サイトの検証環境（RTX 5080単体・VRAM 16GB・num_ctx=4096・Q4_K_M）で、パラメータ規模を上げながら計測した結果が以下。VRAM占有が16GBに近づくほど、tokens/secが落ちていく傾向がはっきり出ている。
| モデル | 規模 | tokens/sec | GPU全体VRAM使用量 |
|---|---|---|---|
| Gemma 4 12B（Ollama: gemma4:12b） | 12B | 73.7 | 11042MiB（10.78GiB） |
| Phi-4 14B（Ollama: phi4:14b） | 14B | 76.0 | 12171MiB（11.89GiB） |
| Codestral 22B（Ollama: codestral:22b） | 22B | 30.2 | 15380MiB（15.02GiB） |
| Gemma 4 26B（Ollama: gemma4:26b） | 26B | 36.7 | 15612MiB（15.25GiB） |
| Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）（MoE） | 35B（A3B） | 19.0 | 15755MiB（15.39GiB） |
| Qwen3 32B（Ollama: qwen3:32b）（dense） | 32B | 計測不可（単体16GBで起動せず） | — |
12B〜14Bクラスは70tok/s台で快適に動き、VRAM占有も12GiB前後に収まる。ところが20B台に入ると様子が変わる。codestral:22bは15.02GiBまで埋め、tokens/secは30.2まで落ちた。gemma4:26bは15.25GiBで36.7。そして35BのMoEであるqwen3.5:35b-a3bは15.39GiBとほぼ上限に張り付き、19.0tok/sまで沈んだ。一方でqwen3:32bのような32Bのdenseモデルは、単体16GBでは起動せず当サイト環境では計測できなかった。これが16GB単体の壁。
-ngl分割比ごとのtok/sとVRAM占有
注目したいのが、Qwen3.5 35B-A3B（Ollama: qwen3.5:35b-a3b）の19.0tok/sという数値。これは3Bだけが活性化するMoEで、本来ならもっと速く出てもおかしくない。VRAM使用量は15.39GiBと16GBには収まっているのに速度が伸びないのは、上限近くまで埋まった状態で一部の層がCPU側に回り、その負荷がGPU全体の使用量には表れにくい形でボトルネックになっている可能性がある。ここはCPUオフロード量を測っていないため推測の域を出ない。確実なのは、-nglを下げてCPUへ逃がす層を意図的に増やせば、起動はできても速度はさらに落ちる方向に向かうという点まで。
GPUに載せる層を増やせば速く、減らせばVRAMに余裕が出る代わりに遅くなる。-ngl分割は、この二つを天秤にかける調整。VRAMに収まる最大層数の手前で止めるのが速度面では有利。VRAM上限に近づくと、KVキャッシュや一部処理のCPU側への移動、メモリ帯域、MoEの実装差といった要因が重なり、表の22B〜35Bで見たような速度低下が出やすくなる。
逃がし先で速度は変わる — 2枚目GPUとCPU+RAMの違い
では、単体16GBに載りきらない帯はどうなるのか。当サイトでは、同じqwen3.5:35b-a3bを2枚目のGPUへ一部を逃がす構成にした場合、125.3tok/sまで回復することを計測している（GPU全体で13653MiB／13.33GiB、2026-06-12）。単体での19.0tok/sと比べて大きな差。逃がし先がもう一枚のGPUであれば帯域が確保され、速度が戻るという結果。デュアルGPU構成での自動分散については別記事で詳しく扱っている。
ただし、逃がし先がCPU+RAMの場合はこうはいかない。RAMの帯域はVRAMより遅く、CPU演算も加わるため、同じ「逃がす」でも速度の戻り方は鈍い。70B級をQ4で単体16GBから-ngl分割してCPU+RAMへ逃がす運用は、起動自体は96GBのRAMがあれば成立する見込みだが、その際のtokens/secは当サイトでは未計測。ここを断定はしない。確認できているのは「16GBを超えてCPU側へ逃げ始めると速度が大きく落ちる」という一点まで。
速度低下の実用境界 — どこまで遅くなると割に合わないか
動くことと、使えることは違う。どこまで遅くなると実用を割るのか。これは用途で線が動く。対話用途では、生成が読む速度に追いつかないと待ち時間が気になり始める。Reddit上でも「この速度を割ると常用しづらい」という声は出ているが、許容できる速度は用途と個人差が大きく、特定の数字を一律の目安として置くのは無理がある。要約やコード補完のように即応性が要る場面と、夜間にバッチで長文を処理する場面とでは、許せる遅さがまるで違う。
傾向としては、CPUへ逃がす層を増やすほど転送待ちが積み上がり、tokens/secは下がる一方になる。当サイトの検証で確認できたのは、VRAMが上限に達した22B〜35B帯で速度が30tok/s前後から19tok/sまで落ちたところまで。それ以上CPUへ深く逃がした領域は未検証で、上限としての断定はしない。実用ラインを自分で引くなら、まず手元のモデルとGPUで-nglを段階的に下げ、生成速度が我慢できる範囲に収まる分割比を探るのが現実的。
別ワークロードとの対比と上限側の証拠
RAMオフロードという同じレバーが、言語生成以外でどう効くか。境界の両側を見ておくと、判断の精度が上がる。
画像/動画生成でのオフロード劣化との違い
画像・動画生成でも、VRAMを超えたモデルをCPU側へ逃がす場面は珍しくない。r/comfyuiでは、VRAMを大きく超えるチェックポイントを16GBのGPUへ載せようとした結果、重みがほぼGPUに載らず、CPU RAMからの常時ストリーミングで生成が大幅に遅くなったという報告がある。投稿者は既存の最適化を一通り適用済みで、それでも速度が戻らず、モデル形式そのものを軽い量子化版に変えるしかないと指摘していた。
LLMの-ngl分割と構造は同じ。違いは、画像/動画生成では1枚を生成し終える時間で体感し、LLMでは1秒あたりのトークン数で体感する点。どちらも「VRAMを超えた分を逃がすと転送がボトルネックになる」という同型の現象で、オフロードが万能ではないことの傍証になる。逃がせば動くが、逃がすほど遅くなる。この原則はワークロードをまたいで共通している。
1兆パラメータ級=実用限界の外側
境界の上限側にあるのが、冒頭のRing-2.6-1Tのような1兆パラメータ級。r/LocalLLaMAのコメントでは、このモデルに対して「Kimi K2.6のほうが扱いやすく、結局そちらを常用する」といった反応も見られた。1兆という規模が必ずしも家庭環境での実用に直結しないという見方の表れかもしれない。MiMo V2.5 ProやDeepSeek V4 Proを試すユーザーもいたが、これらも本格的に回すには相応のVRAMかRAMが要る。DeepSeek V4の安定化や最適化については、推論エンジン側の対応も進んでいる。
1兆パラメータ級は、家庭用GPU単体はもちろん、RAMへ逃がしても実用速度で回すのは難しい上限の外側にある。境界の下側に16GB級で快適に動く12B〜14B帯があり、その上にRAMオフロードで「動くが遅くなる」70B級帯があり、さらに外側に実用を超えた1兆パラメータ級が控える。この三層の地図を持っておくと、手元の構成で何を狙うかの見当がつけやすい。ローカルLLMをこれから始める読者には、姉妹サイトのローカルLLM入門記事も土台固めになる。
ご自身の環境なら、どこに線を引くだろうか。16GBに収まる軽いモデルで速度を取るか、RAMへ逃がしてでも大きいモデルを試すか。用途が対話中心かバッチ中心かで、最適解は変わってくる。手元のGPUとRAMで-nglを少しずつ動かしながら、我慢できる速度の分割比を探ってみてほしい。
まとめ
VRAMに収まらない大型LLMは、-ngl分割でCPU側のRAMへ層を逃がせば起動自体は可能。ただし逃がした層は遅い経路を通るため、CPUへ回す割合が増えるほどtokens/secは落ちる。まずVRAMに快適に収まるモデルサイズを把握し、次にどうしても大きいモデルを動かしたい場合だけ-nglを下げて分割する、という順序が実用的。
当サイトの検証環境（RTX 5080単体・VRAM 16GB）では、12B〜14Bが70tok/s前後で快適、22B〜35Bで15GiB台までVRAMが埋まり19〜36tok/sへ低下、32B denseは単体では起動せず、という壁が確認できた。70B級や1兆パラメータ級はこの外側で、前者はRAMオフロード前提、後者は家庭環境の実用範囲を超える。速度が実用を割る境界は用途で動くため、手元の構成で-nglを段階調整し、許せる速度に収まる分割比を見つけるのが現実解になる。
| 主役レバー | -ngl（n-gpu-layers）分割によるRAMオフロード |
|---|---|
| 検証GPU | RTX 5080（VRAM 16GB） |
| システムRAM | 96GB |
| 計測条件 | Ollama 0.30.7 / Q4_K_M / num_ctx=4096 |
| 16GBで快適な上限 | 12B〜14Bクラス（約70tok/s） |
| VRAM飽和帯 | 22B〜35B（15GiB台・19〜36tok/s） |
よくある質問
Q. 70Bクラスは16GB VRAMで動きますか？
4bit量子化（Q4_K_M等）でも70Bクラスの重みは30GB以上あり、RTX 5080の16GB VRAMには丸ごとは載りません。-ngl分割でCPU側のRAMへ層を逃がせば起動自体は可能ですが、CPU経由の層が増える分、tokens/secは大きく落ちます。当サイトでは70B級のCPUオフロード速度は未計測のため、断定はしません。
Q. -nglはいくつを目安にすればいいですか？
固定の正解はありません。VRAMに収まる最大の層数まで載せるのが速度面では有利です。起動時にVRAM使用量を見ながら-nglを段階的に上げ、容量に収まる手前で止めるのが基本。溢れてCPUへ逃げ始めると速度が落ちるため、モデルとGPUの組み合わせごとに探る必要があります。
Q. RAMは何GB必要ですか？
CPU側へ逃がす層の重みはシステムRAMに置かれるため、モデルが大きいほどRAMを要します。当サイトの検証環境は96GBで、これだけあれば大型モデルを逃がす余地は広く取れます。RAMが不足するとスワップが発生しPC全体が重くなるので、大型モデルを狙うなら容量に余裕を持たせるのが安全です。
Q. 遅すぎて使えないと感じる境界はどこですか？
用途で変わります。対話用途は即応性が要るため遅さが目立ちやすく、バッチ処理なら多少遅くても許容できます。当サイトの検証で確認できたのはVRAM飽和帯で19〜36tok/sまで落ちたところまでで、それ以上CPUへ深く逃がした領域は未検証です。手元の用途で許せる速度に収まる分割比を、実際に試して見極めるのが確実です。
Q. 大きいモデルを速く動かす別の手段はありますか？
2枚目のGPUへ逃がす構成は有効で、当サイトでは35BのMoEが単体19.0tok/sから125.3tok/sへ回復しました。RAMへ逃がすより速度が戻りやすい一方、GPU増設のコストと電源・スペースが要ります。用途を満たす範囲でモデルを一段軽くする選択も、結果的には快適な場合が多いです。
参考資料
- llama.cpp 公式リポジトリ（-ngl / n-gpu-layers の実装と説明）
- Ollama 公式リポジトリ（num_gpu パラメータとモデル実行）
- Reddit r/LocalLLaMA（大型ローカルLLMの実運用コミュニティ）
- NVIDIA GeForce RTX 50シリーズ 公式（VRAM・仕様）
- Hugging Face（量子化済みモデルの配布とサイズ確認）
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
