ローカルLLM常駐時のVRAM配分｜他のAI作業と同時に回すと重みとKVキャッシュで詰まる

ローカルLLMのVRAM配分とは、重み・KVキャッシュ・一時確保の3枠に容量を割り振る設計。

モデルは載った。起動も速い。それなのに、常駐させたまま画像生成を回した瞬間に生成が始まらなくなる。この症状の原因は「VRAMが足りない」ではなく「配分を決めていない」ことにあります。VRAMの基礎占有は重みで決まり、そのうえで常駐運用時に調整可能な主要因になるのが、設定したコンテキスト長と並列数から決まるKVキャッシュ枠です。長いコンテキストや複数並列を設定すると、ロードした時点で他の処理に使える余白が減ります。

この記事の要点

VRAMを食うのは重み・KVキャッシュ・実行スタックの3枠。重みの基準値は量子化タグごとの実配布ファイルサイズから第一近似する（Qwen3.6-27BはQ4_K_Mが16.8GB、Q6_Kが22.5GB）。MoEは活性ではなく総パラメータ側で場所を取る（35B-A3BのUD-Q4_K_Mは22.1GB）
Ollamaの必要メモリはOLLAMA_NUM_PARALLELとOLLAMA_CONTEXT_LENGTHの積に比例し、その枠はロード時に確保される（割り当てられたコンテキスト長はollama psのCONTEXT列、CPU/GPUの配置はPROCESSOR列で確認できる）。keep_alive=-1 は「自動では解放しない」宣言であって、他プロセスへの優先権ではない
Ollama内で別モデルをロードする空きVRAMが足りない場合、必ずしも即座にエラーにならず、キュー待ちとアイドルモデルのアンロードで表面化することがある。当サイトのRTX 5080（16GB）実測では26B級のGPU全体使用量が15GiB台に達し（この計測はGPU常駐73%で一部CPU側）、同居させるなら常駐モデルを小さくするかGPUを分けるかの判断が先に要る

VRAMを主に食う3つの枠
1. 「メモリ不足でエラー」より先に起きること
常駐させる重みのサイズは実配布ファイルで確認する
1. Q4_K_Mが開始点として選ばれやすい理由
2. 同じ「27B」でも量子化タグでサイズが変わる
MoEは総パラメータで場所を取る｜活性パラメータで見積もらない
1. 「活性3Bだから載る」が成立しない理由
KVキャッシュの枠はコンテキスト長×並列数でロード時に決まる
1. num_ctxを上げた分だけ他の作業の取り分が減る
2. 並列スロットを増やすと何が増えるか
Ollamaは足りないとき「待たせる」か「落とす」｜常駐の実際の挙動
keep_aliveの3択と、それでも解放されるケース
1. 同時ロード数の上限は「常駐させる設定」ではない
常駐したまま画像生成を回すと先に破綻するのはどちらか
同時に回さない運用という選択肢
容量帯別の割り振り方｜16GB級と24GB級で何が変わるか
1. 残しておく余白をどれだけ見るか
詰まったときの切り分け｜nvidia-smiとollama psで見る
1. CPUへ逃げていないかを最初に見る
まとめ
よくある質問
参考資料

VRAMを主に食う3つの枠

推論中にVRAMを消費する主な枠は、モデルの重み、KVキャッシュ、実行スタックが確保するオーバーヘッドの3つです。実務ではこのほかにCUDAコンテキスト、アロケータの予約、映像出力、モデルによってはvision encoderやMTP用の領域、同じGPUを使う別プロセスの分も乗ります。配分を考えるうえでの整理として3枠に分けます。この3枠の配分が決まって初めて「載るか載らないか」が決まる、という順番。逆に言えば、配分を考えるうえで押さえるべきはこの3つです。

重みは常駐させた瞬間に確保される分です。総量は配布物と量子化タグを選んだ時点でほぼ固定されますが、そのうち何割をGPUへ置くかは空きVRAMやコンテキスト設定によって変わります。KVキャッシュは、設定したコンテキスト長と並列スロット数から必要量が決まる分。Ollamaが基盤に使うllama.cpp系では、その上限に見合った領域をモデル初期化時に確保します。生成が進むとキャッシュ内の使用領域は埋まっていきますが、確保済みのVRAM量が入力トークンごとに後から増えていくわけではありません。3つめが実行スタックのオーバーヘッドで、推論エンジンが計算のために掴む作業領域。

重みが基礎占有を決めたあと、設定によって大きく変動する主要な枠がKVキャッシュです。重みは総量が読めるので予算が組める。ところがKVキャッシュ側は大きく設定するとロード時点から他の処理の取り分を圧迫し、しかも「気づいたら他の作業の取り分が無くなっていた」という形で表面化します。

「メモリ不足でエラー」より先に起きること

Ollama内で別のモデルを新たにロードしようとして空きVRAMが不足した場合、必ずしも即座にエラーになるわけではありません。Ollamaは新しいモデルをロードする空きメモリが無い場合、新規リクエストをキューに入れて待たせ、アイドルになった既存モデルを1つ以上アンロードして場所を空けます。これが公式ドキュメントに記載された挙動です。

つまりこのケースで体感上の「詰まった」の正体は、エラー画面ではありません。生成がいつまでも始まらない待ち状態か、さっきまで載っていたモデルが勝手に落ちて再ロードが走っている状態。エラーログを探しても何も出てこないのは、そもそも異常終了していないからです。

「落ちない代わりに待たされる」という設計を知らないと、原因追跡が空振りする。生成が始まらないときはエラーログではなく、まず現在のVRAM使用量とロード済みモデルの一覧を見るのが先。

常駐させる重みのサイズは実配布ファイルで確認する

重みが何GBになるかは、パラメータ数から係数で暗算するより、量子化タグごとの実配布ファイルサイズを直接見るほうが確実です。「4bit量子化なら1パラメータあたり約0.6バイト」といった係数は配布物によってずれます。実配布サイズから逆算すると概算で0.62〜0.63バイト/パラメータ前後になりますが、これはあくまで結果から求めた目安であって、先に係数を置いて予算を組む根拠にはなりません。

Qwen3.6-27Bを例に取ります。Qwen公式のモデルカードによれば、dense構成の27Bで、層数は64、ネイティブのコンテキスト長は262,144トークン、拡張時の上限は1,010,000トークン。Unsloth配布のGGUFでは、量子化タグごとのファイルサイズが次のようになっています。

量子化タグ	Qwen3.6-27B（dense 27B）	Qwen3.6-35B-A3B（MoE 総35B）
Q4_K_M	16.8GB	22.1GB（UD-Q4_K_M）
Q5_K_M	19.5GB	26.5GB（UD-Q5_K_M）
Q6_K	22.5GB	29.3GB（UD-Q6_K）
Q8_0	28.6GB	36.9GB（Q8_0）

出典はUnsloth 配布の Qwen3.6-27B-GGUF / Qwen3.6-35B-A3B-GGUF（Hugging Face）。同じ「Q4_K_M」でも配布元によってタグ名に接頭辞が付くことがあり、35B-A3B 側は UD- 付きのタグが該当します。サイズの近い別タグ（UD-Q4_K_S 20.9GB / UD-Q4_K_XL 22.4GB）と取り違えないよう、pull する前に配布ページのファイル名を確認してください。ここに並ぶのは重みのファイルサイズだけで、KVキャッシュもランタイム分も含まれていません。ここで単位に注意が要ります。Hugging Faceの表示は10進のGBで、GPUツールが表示するGiBとは基準が違う。Q6_Kの22.5GBは約21.0GiBなので、24GB級（24GiB）のカードでは単純計算で約3GiBが残る勘定です。ただしここからKVキャッシュと計算バッファを確保するため、長いコンテキストや同居ワークロードに回せる余白は限られます。

Q4_K_Mが開始点として選ばれやすい理由

Q4_K_Mから始める例が多いのは、品質とメモリ占有のバランス点として扱われているからです。Q5_K_MやQ6_Kに上げれば品質側に振れますが、その分だけ他の枠を圧迫する。27BのQ4_K_MとQ6_Kは、配布ファイル表示上で5.7GBの差があります。この差の分だけ、コンテキスト長と同居ワークロードに回せる枠が減ります。

常駐前提なら、まず量子化を1段下げて枠を作るほうが運用は安定します。品質差が用途に対して許容できるかどうかは、実際に自分のタスクで比べてから決めてください。タグごとの精度とサイズの関係はQ4_K_MからQ8・QATまでを16GBで見極めた比較で実測しています。

同じ「27B」でも量子化タグでサイズが変わる

同じモデル名でも、Q4_K_Mの16.8GBとQ8_0の28.6GBでは、載るカードがまるで違います。「27Bだから24GBに載る」という言い方は成立しません。載るのは特定の量子化タグのファイルであって、モデル名ではないからです。

配分を組むときの手順はシンプルです。配布ページで量子化タグごとのファイルサイズを見る。カードの公称容量から実配布サイズを引き、ランタイムやKVキャッシュ用の追加余白を見込む。残りを同居ワークロードの取り分として分ける。この順番を守れば、係数からの暗算で外すことはなくなります。

MoEは総パラメータで場所を取る｜活性パラメータで見積もらない

MoEモデルは、トークンごとに一部のエキスパートしか計算に使いませんが、全エキスパート分の重みを保持する必要があります。全量をGPUに常駐させるなら、その重みはVRAM側に載ります。収まらない場合は一部をシステムRAMへオフロードできるものの、必要な総メモリ量はアクティブパラメータ数ではなく総パラメータ数を基準に見積もる。これが最も間違えやすい箇所です。

Qwen公式のモデルカードによれば、Qwen3.6-35B-A3Bは総35B、トークンあたりのアクティブパラメータが3B、エキスパート総数256（トークンごとにルーティング8＋共有1が活性化）、層数40という構成。「アクティブ3B」という数字だけを見ると軽量モデルに見えます。ところが実配布のUD-Q4_K_Mは22.1GB。dense 27BのQ4_K_M（16.8GB）より5.3GB大きい。ファイルサイズは総35Bに見合った大きさになっています。

「活性3Bだから載る」が成立しない理由

容量は総パラメータ側で決まる一方、速度は総パラメータ数には比例しない。この非対称がMoEの特徴です。当サイトの検証環境（RTX 5080単体）で qwen3.6:35b-a3b を計測したときのGPU全体使用量は 15799MiB（15.43GiB）、生成速度は 67.7 tokens/sec でした。ただしこの計測では ollama ps の size_vram/size 比が 62% で、Ollamaがモデルの一部をCPU側へ配置した状態です。16GBに全量を載せた状態の値ではないため、全量GPU常駐のモデルと速度を横並びで比較することはできません。同系列のMoEが16GBでどれだけあふれるかは、gemma4:26b・qwen3.5:35b-a3bを載りきらない状態で計測した記事でも扱っています。Ollama公式配布の qwen3.6:35b-a3b（Q4_K_M）は配布サイズが24GB級で、16GBのGPUに全量を載せる前提がそもそも成り立たない点にも注意が必要です。同じ環境の Qwen3 14B（Ollama: qwen3:14b）が 76.4 tokens/sec で 11623MiB（11.35GiB）。今回は35B-A3B側が部分的にCPUへオフロードされているため、この2つの数値からMoE固有の速度特性を評価することはできません。ここで確認できるのは、活性パラメータ数が小さくても重みの保持に必要な総容量は小さくならない、という点だけです（think=false・各3回のIQR外れ値除外後の中央値・Ollama 0.30.7 / NVIDIA driver 610.47。qwen3.6:35b-a3b は2026年6月18日、qwen3:14b は2026年7月22日の計測）。

なお、この値は nvidia-smi の memory.used によるGPU全体の使用量で、デスクトップ表示などのベースラインを含みます。モデル単体のロード増分ではない点に注意してください。

本記事の「GPU常駐率」は、Ollama API の /api/ps が返す size_vram ÷ size から算出したモデル配置の比率です。nvidia-smi の VRAM 使用率や GPU 使用率ではありません。100% 未満なら、Ollamaがモデルの一部をCPU側へ配置している状態を指します。

MoEを「活性パラメータが小さいから軽い」と扱って常駐計画を立てると、確保段階で破綻する。速度の指標と容量の指標を混ぜないこと。

KVキャッシュの枠はコンテキスト長×並列数でロード時に決まる

常駐運用で実際に効いてくるのがここです。Ollamaが必要とするメモリは、OLLAMA_NUM_PARALLEL と OLLAMA_CONTEXT_LENGTH の積に比例してスケールする、と公式FAQに明記されています。並列リクエスト処理は、そのモデルのコンテキストサイズを並列数の分だけ増やす扱いになり、追加のメモリ確保を伴う仕組み。

公式が挙げている例が分かりやすい。2Kコンテキストで4並列を受けると、実効8Kコンテキスト相当のメモリを確保することになります。並列数を増やしたつもりが、コンテキストを4倍に伸ばしたのと同じ負荷をVRAMにかけている。

既定値は把握しておいてください。並列リクエスト数は1件、キュー上限は512件。コンテキスト長の初期値は環境によって異なり、Ollamaの専用ドキュメントではVRAM 24GiB未満で4K、24〜48GiBで32K、48GiB以上で256Kとされる一方、FAQには4096との記載も残っています。16GB級では4Kで合いますが、上位帯では前提が変わるため、割り当てられたコンテキスト長はollama psのCONTEXT列で確認してください（CPU/GPUの配置はPROCESSOR列です）。この既定のままなら消費は控えめですが、num_ctx を上げた瞬間に前提が変わります。

num_ctxを上げた分だけ他の作業の取り分が減る

コンテキスト長は環境変数 OLLAMA_CONTEXT_LENGTH、対話中の /set parameter num_ctx、API の num_ctx で変更できます。8Kに広げる設定は次の形。

OLLAMA_CONTEXT_LENGTH=8192
OLLAMA_NUM_PARALLEL=1

この2つはOllamaサーバ側の環境変数で、サーバ起動時にしか読まれません。クライアント側のコマンドプロンプトで set しても常駐中のサーバには反映されないため、OSごとの手順で登録してから起動し直します。Windowsはタスクバーの Ollama を終了し、設定アプリの「環境変数を編集」でユーザー環境変数として登録してから、スタートメニューで起動。macOSは launchctl setenv、Linux（systemd）は systemctl edit ollama.service の Environment 行で指定します。OLLAMA_ で始まる設定はいずれも同じ扱いです。

長いコンテキストは能力にも効きます。Qwen公式のモデルカードは、OOMが出たらコンテキストウィンドウを減らすよう案内する一方で、思考能力を保つには128Kトークン以上のコンテキストを維持するよう推奨しています。

OOM が発生する場合はコンテキストウィンドウを減らすことを検討する。一方で、思考能力を保つには 128K トークン以上のコンテキスト長を維持することを推奨する。（Qwen 公式 Hugging Face モデルカード（Qwen3.6-27B / Qwen3.6-35B-A3B）の記述を訳出）

容量と能力のトレードオフが公式ドキュメント上で明示されている、という点が押さえどころ。実際に16GBでコンテキスト長をどこまで伸ばせるかは、KVキャッシュの量子化を変えながら別途実測しています。「とりあえず最大まで伸ばす」でも「既定のまま」でもなく、同居させたい作業から逆算して天井を決める運用になります。

KVキャッシュのデータ型を落とす手もあります。既定は f16 で、OLLAMA_KV_CACHE_TYPE を q8_0 にすると f16 のおよそ半分、q4_0 ならおよそ4分の1のメモリで済む、というのが公式FAQの記載。Flash Attention は、対応するバックエンドとデバイスでは自動的に使われます。明示的に強制する場合はサーバ起動時に OLLAMA_FLASH_ATTENTION=1、無効化する場合は 0 を指定します。

OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_FLASH_ATTENTION=1

並列スロットを増やすと何が増えるか

llama.cpp の llama-server を直接使う場合も考え方は同じです。並列スロット数 -np/--parallel の既定は -1（auto）、コンテキスト長 -c/--ctx-size の既定は 0（モデル定義から読み込み）。スロットを増やせば、その分だけコンテキスト用の確保が積み上がります。KVキャッシュのデータ型は K 側・V 側それぞれ -ctk / -ctv で指定でき、既定は f16、q8_0 や q4_0 も選べる仕様。--no-kv-offload で KV キャッシュのオフロード（既定は有効）を切ることもできます。エンジンごとに設定の粒度と既定値が違うため、Ollama・llama.cpp・LM Studio・vLLMの比較もあわせて確認すると選びやすくなります。

増えた分の内訳を「全部KVキャッシュ」と断定はできません。スロットごとに確保されるのはKVキャッシュなどの作業領域であり、実行スタック側のバッファも含まれます。見るべきは内訳の名前ではなく、スロットを1つ増やしたときにGPU全体の使用量が実際にいくら増えたか。

16GB級での目安は、当サイトの検証環境（RTX 5080単体）の値が参考になります。Gemma 4 26B（Ollama: gemma4:26b）が 15730MiB（15.36GiB・GPU常駐73%で一部CPU側）、Codestral 22B（Ollama: codestral:22b）が 15021MiB（14.67GiB・GPU常駐100%）、Gemma 4 12B（Ollama: gemma4:12b）が 9740MiB（9.51GiB）でした（同上の計測条件、GPU全体の使用量）。26B級を常駐させた時点で16GBはほぼ埋まり、追加のCPUオフロードや速度低下を許容しない限り、並列スロットを増やしたりコンテキストを伸ばしたりするVRAM余地はほぼ残っていません。12B級まで落として6GiB前後を空けておくか、そもそも同居させないか。この二択を先に決めておくのが、詰まらせない配分の出発点になります。どのモデルが16GBに収まるかの早見表はVRAM 16GBで動かすローカルLLMの境界を実測した記事にまとめてあります。

Ollamaは足りないとき「待たせる」か「落とす」｜常駐の実際の挙動

ここまでは、常駐させる側のサイズをどう決めるかという話。次は、決めた配分が崩れたときにOllamaが実際に何をするかを見ていきます。

Ollamaが新しいモデルをロードしようとして空きVRAMが足りない場合の挙動は、公式FAQに明示されています。新しいモデルをロードする空きメモリが無い場合、Ollamaは新規リクエストをキューに入れて待たせ、アイドルになった既存モデルを1つ以上アンロードして場所を空ける。この2つが同時に起きるため、体感としては「送ったのに何も返ってこない」「さっきまで即答だったのに数十秒待たされる」という形で表面化します。

キューには上限があります。OLLAMA_MAX_QUEUE の既定値は512件で、キューには最大この件数まで入り、上限を超えた追加リクエストは拒否されます。エラーが出ないからこそ、原因の特定が遅れがちです。

もう一つ押さえておきたいのが、モデルが単一GPUに丸ごと収まるかどうかで配置の挙動が変わる点。収まる場合はそのGPUにロードされ、収まらない場合は利用可能な全GPUにまたがって分散されます。2枚差しの環境で「1枚に載せるつもりだったのに両方使われている」という状態は、収まらなかったことのサインです。使うGPUを絞りたければCUDA_VISIBLE_DEVICESで指定します。数値IDは順序が変わりうるため、UUIDで指定するほうが確実です。これもOllamaサーバ側の環境変数なので、前述のOSごとの手順で登録してから Ollama を起動し直します。UUIDは次のコマンドで調べられ、出力される GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 形式の文字列をそのまま値に使います。

nvidia-smi -L

Ollama公式のGPUドキュメントによれば、スケジューラはGPUライブラリが報告する利用可能VRAMを根拠に配置を決めています。その情報が取れない環境では、モデルの概算サイズによるベストエフォート判断に落ちる仕様。つまり配置の精度は環境依存であり、常に最適な判断が保証されるわけではありません。

keep_aliveの3択と、それでも解放されるケース

keep_aliveの選択肢は3つです。0を指定すれば応答後に即座に解放、時間を指定すればその時間だけ保持（既定は5分）、そして負の値（-1）を指定すれば無期限に載せたままになります。「常駐させる」という運用は、この3つ目を選ぶことを指します。

keep_alive=-1 を指定してもVRAMがロックされるわけではありません。公式FAQがアンロードの契機として挙げているのは、Ollama 自身が別のモデルをロードしようとして空きが足りない場合です。画像生成のような別プロセスの確保要求に対して Ollama が譲るかどうかは公式に記載がなく、-1 は「Ollama が自動では解放しない」という宣言であって、他プロセスから VRAM を守る予約ではありません。keep_alive=-1 を指定しても、外部プロセスとの競合時にどのような結果になるかは保証されません。Ollamaが自動アンロードするとは限らず、外部プロセス側がメモリ確保に失敗する可能性もあります。

ここが常駐運用でつまずきやすい箇所。-1は「解放しない意思表示」であって、「他のプロセスより優先される保証」ではありません。Ollama公式が説明しているアンロードの契機は、Ollama自身が別のモデルをロードしようとして空きが足りない場合です。ComfyUIのような別プロセスがVRAMを要求したときにOllamaが自動で譲るとは記載がなく、逆に外部プロセス側が確保に失敗することもあり得ます。いずれにせよ -1 はVRAMの予約でも外部プロセスに対する優先権でもないため、実際の挙動は環境ごとに確認してください。

再ロードが発生したときの体感コストは、Ollama APIのレスポンスに含まれるload_durationで確認できます。この値が大きいときは、載せ直しに時間がかかったことを示します。公式の定義は「モデルのロードに要した時間」で、初回ロードや手動停止後のロード、別モデルへの切り替えでも大きくなるため、直前の自動アンロードを証明するものではありません（再ロードが起きた可能性を確認する指標として使います）。物理的な内訳（ディスクから読んだのか、OSのページキャッシュから戻したのか）まではこの値だけでは判別できないため、そこは断定せず「載せ直しに時間がかかった」という事実だけを見ます。

同時ロード数の上限は「常駐させる設定」ではない

OLLAMA_MAX_LOADED_MODELSをめぐる誤解は多い。この値は「同時にロードできるモデル数の上限」であって、モデルを常駐させる設定ではありません。既定値はGPU数の3倍（CPU推論時は3）。1枚構成なら3モデルまで同時に載る余地が最初から開いている計算になります。

この既定値が意味するのは、意図せず複数モデルがVRAMに居座る余地があるということ。コーディング用と要約用で別モデルを呼び分けていると、両方がVRAMに残ったまま画像生成を起動する、といった状況が起きます。常駐させたいモデルを1本に絞る運用なら、この値を1に下げておくほうが配分は読みやすくなります。

並列リクエスト数のOLLAMA_NUM_PARALLELは既定が1件。公式FAQには、2Kコンテキスト×並列4リクエストで実効8Kコンテキスト相当のメモリを確保する、という例が挙げられています。必要メモリはOLLAMA_NUM_PARALLELとOLLAMA_CONTEXT_LENGTHの積に比例してスケールする仕様なので、並列数を上げるならコンテキスト長を下げる、という引き算が要ります。

常駐したまま画像生成を回すと先に破綻するのはどちらか

同じGPUにローカルLLMを常駐させたまま、ComfyUIで静止画を生成する。この組み合わせでどちらが先に音を上げるかは、起動順・モデル・ワークフロー・アロケータ・DynamicVRAMの設定によって変わります。当サイトでは同時実行時にどちら側が先に失敗するかまでは実測していないため、ここでは一般化しません。傾向として押さえておきたいのは、次のような差があることです。

理由は確保のパターンにあります。LLM推論は既にロード済みの重みを使い、設定されたKVキャッシュ枠の中にトークン情報を保持していく動き。対して画像生成は、モデルのロードと中間テンソルの確保でまとまった量を一度に掴みにいきます。ただし、どちらが先に失敗するかは起動順・モデル・ワークフロー・アロケータ・DynamicVRAM設定によって変わります。本記事では同時実行時の失敗側を実測していないため、ここでは一般化しません。

ComfyUI側にも制御手段は用意されています。既定では使用後にモデルをCPUメモリへ退避する設計で、--highvramを付けるとGPUメモリに保持し続ける挙動に変わる。常駐LLMと同居させるなら、この既定の退避挙動が効いている状態を維持するほうが安全です。OSや他ソフト用に確保しておくVRAM量をGB単位で指定する--reserve-vramもあり、既定でもOSに応じて一定量が確保されます。同居前提なら、この値を明示的に積み増しておく判断もあります。

python main.py --reserve-vram 2 --cuda-device 0

--cuda-deviceで使用するCUDAデバイスIDをカンマ区切りで指定できるため、GPUが2枚あるなら役割分担そのものを実装できます。LLMをCUDA_VISIBLE_DEVICESで1枚に固定し、ComfyUIを--cuda-deviceでもう1枚に寄せる。この分離が、同居問題に対する有力な解決策になります。2枚目を足してCPUオフロードを解消したときに速度がどれだけ戻るかは、Oculink接続の2枚構成で実測した記事にあります。

なお--lowvramは、ダイナミックVRAMが有効な環境では何もしません。無効な場合にテキストエンコーダをCPUで動かす挙動になります。--novramはlowvramでも足りない場合の選択肢という位置。VRAM不足に効くオプションとして機械的に--lowvramを付ける運用は、環境によっては空振りします。重みの非同期オフロードを制御する--async-offload / --disable-async-offload、DynamicVRAMの余白量をGB指定する--vram-headroomもあり、細かい調整の余地は残されています。

同時に回さない運用という選択肢

GPUが1枚しかない場合、最も壊れにくいのは「同時に回さない」という運用です。画像生成を回す前にkeep_alive=0でLLMを解放し、生成が終わってから載せ直す。載せ直しのコストはload_durationで測れるので、それが許容範囲なら同時実行に固執する理由はありません。

同時実行が必要なのか、それとも「常に即応してほしい」だけなのかを分けて考えてください。後者なら、GPUを分けるかkeep_aliveを短めの時間指定にして自動で入れ替わる形にするほうが、VRAMを削り合うより安定します。

ローカルLLMを実作業で使う具体像は姉妹サイトでも扱っています。コーディング支援としてOllamaを常時呼び出す構成はCline でローカル LLM を動かして無料・オフラインで AI コーディングする（Ollama 連携）が参考になります。常時呼び出す前提なら、画像生成との同居は最初から避ける設計が現実的です。

容量帯別の割り振り方｜16GB級と24GB級で何が変わるか

NVIDIA公式の仕様では、GeForce RTX 50シリーズのデスクトップ向けVRAMはRTX 5090が32GB、RTX 5080・RTX 5070 Ti・RTX 5060 Ti（16GB版）が16GB、RTX 5070が12GB、RTX 5060とRTX 5060 Tiの8GB版が8GB、RTX 5050が8GB（5050はGDDR6、ほかはGDDR7）。RTX 4090は24GB（GDDR6X）です。

この容量差が常駐運用で何を変えるか。配分の枠組みで整理すると次のようになります。

項目	12GB級（RTX 5070）	16GB級（RTX 5080 / 5070 Ti / 5060 Ti 16GB）	24GB級（RTX 4090・前世代）	32GB級（RTX 5090）
公称VRAM	12GB	16GB	24GB	32GB
常駐させる重みの上限目安	8B〜12B級の量子化版	12B〜22B級を中心に検討（26B級は量子化や配布物によって一部CPUオフロードになる可能性が高い）	Qwen3.6-27B Q4_K_M（16.8GB）が収まる	Qwen3.6-35B-A3B Q4_K_M（22.1GB）まで届く
コンテキスト用に残せる分	ごく僅か	12B級なら6GiB前後	27B Q4_K_Mで単純差8GiB強	35B-A3B Q4_K_Mでも余白あり
同居ワークロード用の残し分	実質確保できない	常駐モデルを小さくして初めて確保できる	量子化を1段下げれば確保可能	同居を前提にした余白を確保しやすい
AI用途の目安	単発のLLM推論に専念	LLM常駐か画像生成のどちらか一方	27B級常駐＋短めコンテキスト	常駐＋同居を検討しやすい

表の「常駐させる重みの上限目安」は、Unsloth配布のGGUFファイルサイズを基準にしています。ファイルサイズはVRAM常駐量の第一近似であって確定値ではなく、CPUオフロード・GPU上でのrepack・計算バッファ・projector などで実際の占有は変わります。Qwen3.6-27BはQ4_K_Mが16.8GB、Q5_K_Mが19.5GB、Q6_Kが22.5GB。24GB級（24GiB）ならQ4_K_Mは収まりますが、Q5_K_M（19.5GB＝約18.2GiB）まで上げると単純差で6GiB弱。ここからランタイムとKVキャッシュ分が引かれるため、コンテキストと同居ワークロードの取り分はかなり細くなります。同じ24GBでも量子化タグ次第で運用の性格が変わる、というのがこの表の読みどころ。

24GB級・32GB級については、当サイトに実測がありません。ここに書いた数値は公称容量と実配布ファイルサイズからの割り振り方針であって、実測値ではない点を明記しておきます。16GB級の実測は当サイトの検証環境（RTX 5080単体・think=false統一・IQR外れ値除外後の中央値・Ollama 0.30.7 / NVIDIA driver 610.47。計測日はモデルにより2026年6月18日または7月22日）で取得したもので、Qwen3 14B（Ollama: qwen3:14b）が 11623MiB（11.35GiB・GPU常駐100%）というGPU全体の使用量でした。35B-A3B 側は前述のとおりGPU常駐62%の計測なので、16GBに収まった例としては扱えません。

24GB級には現行のRTX 50シリーズに該当する構成がありません（5080・5070 Tiが16GB、5090が32GB）。この帯は前世代のRTX 4090か、中古の24GBカード（RTX 3090など）を探すことになります。いずれも新品の安定供給を前提にできないため、これから買い足すなら16GB級か32GB級を軸に配分を考えるほうが現実的です。以下の表で24GB級を併記しているのは、すでに手元にある場合の目安としてです。

残しておく余白をどれだけ見るか

余白の決め方は、同居させたい作業から逆算するのが確実です。画像生成を同じGPUで回すなら、そのワークフローが単体で必要とする分をまず測っておく。測った値に対して余白が足りなければ、常駐モデルの量子化を1段下げるか、コンテキスト上限を絞るか、GPUを分けるか。この3択のどれかを選ぶことになります。

Qwen公式は、OOMが出たらコンテキストウィンドウを減らすよう案内する一方で、思考能力を保つには128Kトークン以上のコンテキストを維持するよう推奨しています。Qwen3.6-27B / 35B-A3Bのネイティブコンテキスト長は262,144トークン、拡張時の上限は1,010,000トークン。つまりコンテキストを削る調整には品質側の代償があり、公式ドキュメント上でもトレードオフとして明示されています。無制限に絞れるレバーではありません。

詰まったときの切り分け｜nvidia-smiとollama psで見る

症状が出たとき、最初にやることは決まっています。GPU全体の使用量と、モデルが実際にどこに載っているかの2点を見る。

nvidia-smi --query-gpu=index,name,memory.used,memory.total --format=csv
ollama ps

nvidia-smiのmemory.usedはGPU全体の使用量です。デスクトップ描画や他のアプリケーション、別に立ち上がっている推論プロセスの使用分も含まれます。モデル単体の増分を知りたければ、ロード前後の差分を取るしかありません。数値を読むときは、どちらの値を見ているのかを常に区別してください。

ollama psではPROCESSOR列を確認します。ここにCPUの表示が混じっていれば、モデルの一部がGPUに載りきらずCPU側で処理されている状態。この状態では速度の意味が変わるため、tok/sの比較も成立しません。

症状ごとの見方を整理すると次のようになります。生成が始まらない場合は、キュー待ちかロード中の可能性が高い。ollama psでモデルが載っているか、nvidia-smiで空きがあるかを見ます。途中から急に遅くなった場合は、CPUへのフォールバックか、他プロセスがVRAMを掴んだ可能性。気づくとモデルが落ちている場合は、keep_aliveの設定と、同時ロード数の上限に対して何本載っていたかを確認します。

CPUへ逃げていないかを最初に見る

速度が想定より遅いとき、真っ先に疑うのはCPUへのフォールバックです。GPUに全層載っているつもりでも、大きなnum_ctxを設定していれば、その分の枠を含めて載りきらず一部がCPU側に回ることがあります。ollama psのPROCESSOR表示が「100% GPU」でなければ、まずそこを疑うべき箇所。

意図的にCPU実行へ寄せる場合は、CUDA_VISIBLE_DEVICESに無効なIDとして-1を指定する方法があります。切り分けの過程で「CPUだとどれくらい遅いのか」を測っておくと、フォールバックしていたときの速度低下を判断しやすくなります。

複数のOllama serveや推論プロセスが同時に動いている場合、他プロセスのVRAM使用分が測定値に混入します。切り分けの前に、余計なプロセスが立っていないかを確認しておくほうが確実。GPUが2枚以上ある構成では、nvidia-smiの値が合算なのか片側なのかも明示して読む必要があります。

まとめ

配分は決める順番で難易度が変わります。動かない枠から固定するのが早い。

最初に重みを量子化タグ単位まで下ろして基準値を置く。「27B」ではなく「27BのQ4_K_M（16.8GB）」まで下ろして初めて予算になります。MoEは総パラメータ側で見る。次にOLLAMA_CONTEXT_LENGTHとOLLAMA_NUM_PARALLELに天井を置き、KVキャッシュの最大枠を固定する。ここまでで2枠が固定され、残りが同居ワークロードの取り分になります。

次の一歩は測ることです。同居させたい画像生成ワークフローを単体で回し、nvidia-smiでロード前後の差分を取る。その値が残り枠に収まらなければ、選べるのは3つ。常駐モデルの量子化を1段下げる、コンテキスト上限を絞る、GPUを分けるか順番に回す。GPUが1枚なら、生成前にkeep_alive=0で解放して終わってから載せ直す運用が最も壊れにくく、そのコストはload_durationで測れます。

コンテキストを絞る調整には代償があります。Qwen公式はOOM時にコンテキストを減らすよう案内する一方、思考能力の維持には128Kトークン以上を推奨している。無制限に削れるレバーではありません。同様にkeep_alive=-1も「自動で解放しない」宣言であって、他プロセスへの優先権ではない。

本記事の実測は16GB級（RTX 5080）のみで、24GB級・32GB級は公称容量と実配布ファイルサイズからの割り振り方針です。速度と占有容量は測っていますが、出力品質や用途別の適性は評価していません。そこはご自身のタスクで確かめてください。

よくある質問

Q. 量子化を1段下げれば同居できますか？

枠は作れます。Qwen3.6-27BのQ4_K_M（16.8GB）とQ6_K（22.5GB）は、配布ファイル表示上で5.7GBの差があります（Hugging Faceの表示は10進のGBで、GPUツールが表示するGiBとは単位が異なります）。その差の分だけコンテキストと同居ワークロードに回せます。ただし品質がどう変わるかは本記事では評価していません。許容できるかは実際のタスクで比べてから決めてください。

Q. nvidia-smiの数値がモデルのファイルサイズより大きいのはなぜですか？

memory.usedはGPU全体の使用量で、デスクトップ描画や他のアプリケーション、別に立ち上がっている推論プロセスの分も含むためです。モデル単体の増分を知りたければロード前後の差分を取ります。あわせてollama psのPROCESSOR列でGPUに載りきっているかも確認してください。

Q. OLLAMA_MAX_LOADED_MODELSを上げれば複数モデルを常駐させられますか？

この値は同時にロードできるモデル数の上限であって、常駐させる設定ではありません。既定はGPU数の3倍（CPU推論時は3）。1枚構成でも3本載る余地が最初から開いているため、呼び分けたモデルが意図せず居座ります。常駐を1本に絞るなら1へ下げると配分が読みやすくなります。

Q. llama.cppを直接使う場合も同じ考え方でいいですか？

同じです。並列スロット数-np/--parallelの既定は-1（auto）、コンテキスト長-c/--ctx-sizeの既定は0（モデル定義から読み込み）で、スロットを増やせばその分の確保が積み上がります。KVキャッシュのデータ型は-ctk / -ctvで指定でき、既定はf16、q8_0やq4_0も選べます。

Q. 記事の実測値はご自身の環境でもそのまま出ますか？

計測条件が違えば変わります。掲載値は当サイトの検証環境（RTX 5080単体）で取得したもので、計測日はモデルにより2026年6月18日または7月22日です。think=false 統一、各モデル3〜5回計測のIQR外れ値除外後の中央値、Ollama 0.30.7 / NVIDIA driver 610.47（両日とも共通）。24GB級・32GB級の数値は実測ではなく、公称容量と実配布ファイルサイズからの割り振り方針です。