Agent AI時代のローカルAIマシン選び:VRAMだけでは足りなくなり、CONTEXTとUMAが重要になる理由

投稿者: | 5月 11, 2026
Open WebUIのフルスタック構成を作って、標準では使えない機能をアクティベートしていったが、昨今のOpen WebUIの大きな変化といえば、単純なLLMチャットのUIから、Agent UIへの変化が一番大きい。単純なLLMチャットで使うならば、Ollama単体でもいまやUIが付いている。Open WebUIのような、MCPやRAG連携を使う場合、従来のモード(Defaultモード)だと、はっきり言って、うまくいくかどうかは、モデル選択と運に近い動きをしていたが、Agent AIのモード(Nativeモード)だと「使えるかも」から「使える」に化ける。ただし、ちゃんと使うためには、CONTEXTサイズを従来の値だった、4096や8192だと全然足りない。
 
以下にQNAPのMCPを動かした例のキャプチャがこれ。
Qwen 3.5 9bをNativeモードでMCPでQNAPの情報を問い合わせた。Defaultモードよりだいぶスムーズに、それに確実に回答がでる。
 
 
青い四角で囲った部分が、MCPを呼び出した部分
QNAPのMCP Assistantのコマンドが呼び出されているのがわかる。
 
赤い四角で囲った部分が、利用したコンテキストサイズ
  • 入力コンテキストサイズ:10,402
  • オペレーションコンテキストサイズ:1,155
  • トータルコンテキストサイズ:11,557
つまり、MCPに問い合わせるだけで、コンテキストサイズが12Kくらい必要になる。4096とか8192だと全然足りない。
ちなみに、QNAP NASにGPUカードを入れると使えるLLMcore (Ollama)のコンテキストサイズは、4096しかなくやはり足りない。
この時点で、問題はモデル性能だけではなく、昨今のMCPやAgent AIを成立させるためのcontextと実行時メモリに移っていることが分かる。
 
 
閑話休題
 
 
ここからは、Open WebUIやMCPを実際に使って見えてきた「ローカルAIマシン選びの前提の変化」について整理する。

2025年まではVRAMが主役だった

2025年末以降、AI用途に使われるメモリの需要が急激に高まっている。DRAM、LPDDR、GPU向けメモリ、AI向け大容量メモリの不足や価格上昇が重なり、ローカルAI環境を構築する人にとって、マシン選びの前提が変わりつつある。
これまでローカルAI関連でよく語られていたのは、主にdGPUのVRAM容量であった。
たとえば、画像生成ではVRAM容量とGPU演算性能が非常に重要である。Stable Diffusion、Flux、ComfyUI、Upscalerなどでは、CUDA、Tensor Core、VRAM帯域、FP16/BF16性能が効いてくる。そのため、2023年から2024年頃までは、ローカルAIマシンを語るときに「何GBのVRAMを積んでいるか」が中心的な話題であった。
RTX 4060 Ti 16GB、RTX 3090 24GB、RTX 4090 24GB、RTX 5090 32GB、RTX 6000 Ada 48GBといった具合に、基本的には「より大きなVRAMを持つdGPUを選ぶ」ことが分かりやすい正解だった。
しかし、2025年から2026年にかけて、この前提が少しずつ崩れ始めている。
 
理由は、Agent AIの台頭である。

 

Agent AIで重視されるものが変わった

従来のLLM利用は、比較的単純だった。
ユーザーが質問し、モデルが回答する。会話履歴はある程度保持されるが、4096や8192程度のcontextで十分なケースも多かった。単発のチャット、短い要約、簡単なコード生成、短文の翻訳であれば、dGPUのVRAM容量が16GB程度でも十分実用的であった。
 
ところが、Agent AIでは事情が異なる。
 
Agent AIでは、単なるチャットではなく、以下のような情報を大量に扱う。
  • ユーザーとの会話履歴
  • ツール呼び出しの結果
  • Web検索結果
  • RAGで取得した文書
  • ファイル一覧やファイル内容
  • 実行ログ
  • エラー出力
  • 中間ステップ
  • 過去の作業履歴
  • MCP連携で取得した外部情報
  • マルチエージェント間のやり取り
つまり、Agent AIでは「質問と回答」だけではなく、作業状態そのものを長く保持する必要がある。
 
これをOllamaの設定で見ると、重要になるのが OLLAMA_CONTEXT_LENGTH である。
 
従来の通常チャットであれば、4096や8192程度でも実用になることが多い。しかし、Agent AI、MCP連携、長文RAG、コードベース解析、複数ツール呼び出しを前提にすると、32768、65536、131072といった大きなcontextを使いたくなる。
ここで問題になるのは、contextを増やすほど実行時のメモリ消費が増えることである。
 
単に「モデルファイルが何GBか」だけを見ても不十分である。実際には、モデル本体に加えて、長いcontextを保持するためのメモリが必要になる。そのため、Agent AI時代には、モデルファイルサイズではなく、context込みの実行時SIZEを見る必要がある。

2023年から2026年にかけて起きた変化

ローカルAIのマシン選びは、かなり大きく変化している。
時期
主な関心
代表的な見方
2023年
GPU演算性能 / VRAM
7B、13Bを高速に動かしたい
2024年
VRAM容量 / 量子化
Q4量子化でどこまで載るか
2025年
long context / RAG
長文をどこまで扱えるか
2026年
Agent AI / MCP / 大容量メモリ
作業履歴、ツール結果、RAGを全部保持できるか
 
以前は「速く生成できるか」が中心であった。
 
しかし現在は、「どれだけ多くの状態を保持できるか」が重要になっている。
 
この変化により、dGPUとUMAの棲み分けが明確になり始めている。
 

dGPUはフェラーリ、UMAは大型バスである

dGPUとUMAの違いは、人の送迎に例えると分かりやすい。
  • dGPUはフェラーリのようなスポーツカーである
  • UMAは大型バスである
  • CPU-onlyは、高性能のCPUですら軽トラに近い
dGPUは非常に速い。専用VRAMを持ち、メモリ帯域も広く、CUDAやTensor Coreに最適化された処理では非常に強い。画像生成、ComfyUI、Flux、Upscaler、CUDA依存ワークフローでは、dGPUが圧倒的に有利である。
しかし、フェラーリは荷物や人を大量に載せる用途には向かない。
dGPUも同じである。VRAM容量を超えると、システムメモリへの退避やCPUオフロード、PCIe経由の転送が発生し、急激に遅くなる。特にAgent AIのようにcontextを大きく使う用途では、VRAM容量が制約になりやすい。
 
一方、UMAは大型バスである。
Apple Silicon、AMD Strix Halo、DGX Spark系、その他の大容量共有メモリ構成では、CPUとGPUが同じメモリ空間を使う。GPU専用VRAMという境界が弱く、64GB、96GB、128GB、192GBといった大容量メモリをAI用途に使いやすい。
そのため、UMAは「最高速」ではなく「大量に載る」ことに強い。
 
Agent AIは、まさにこの「大量に載る」能力を必要とする。
 
ちなみに、フェラーリのバスを作ることは可能と言えば、可能。大容量のVRAMを積んだGPUカードを複数枚用意すればいいのだが、価格が全く合わないし、電気消費量が膨大。また、大容量RAMを積んだMACは、LLMのパフォーマンスがよく、電気消費量も少ないのだが、今や入手が不可能に違い。
 

dGPUが強い用途

dGPUは今でも非常に強い。特に以下の用途では、dGPUを選ぶ理由が明確にある。
用途
dGPUが強い理由
画像生成
GPU演算性能とVRAM帯域が効く
ComfyUI
CUDA最適化された処理が多い
Flux
高いGPU演算性能が必要
Upscaler
CUDA依存のワークフローが多い
通常のLLMチャット
contextが短ければ高速
Whisper
GPU推論が有効
embedding
小中規模なら高速
batch inference
並列処理に強い
 
短いcontextでLLMを動かすなら、dGPUは非常に強い。4096や8192程度のcontextで、7Bから14B程度のモデルを高速に動かす用途では、dGPUは今でも優れた選択肢である。
また、画像生成ではdGPUが圧倒的に有利である。ComfyUI、Flux、SDXL、Upscalerなどでは、CUDAとVRAM帯域が効くため、UMAよりdGPUの方が高速に処理できることが多い。
 

UMAが強い用途

一方、UMAが強いのは以下のような用途である。
用途
UMAが強い理由
Agent AI
長い履歴とツール結果を保持しやすい
MCP連携
外部ツールの結果がcontextを圧迫する
long context
大容量メモリを使いやすい
長文RAG
取得文書を多く保持できる
コードベース解析
多数のファイル内容を扱いやすい
マルチエージェント
履歴や状態が増えやすい
ローカルAI常時運用
低消費電力で大容量メモリを使いやすい
 
Agent AIでは、単に「モデルが速く動く」だけでは足りない。
ツール結果、Web検索結果、RAG文書、実行ログ、履歴、作業状態を保持する必要がある。これらをcontextに積んでいくと、4096や8192ではすぐに足りなくなる。
そのため、Agent AIでは32768、65536、131072といった大きな OLLAMA_CONTEXT_LENGTH を使いたくなる。しかし、この領域では実行時メモリ消費が大きく増える。
ここで、dGPUの16GB VRAMでは余裕が少なくなる。
一方、UMA 128GBのような構成であれば、純粋な演算性能ではdGPUに劣るとしても、巨大なcontextを保持しやすい。Agent AIでは「速いが途中で詰まる」よりも、「多少遅くても最後まで載る」方が重要になる場面が多い。
 

16GB VRAMはもう万能ではない

2023年頃の感覚では、16GB VRAMはかなり強い構成であった。
7Bから13B程度のモデルをQ4量子化で動かす。Stable DiffusionやSDXLを動かす。通常のチャットをする。こうした用途では、16GB VRAMは十分に実用的であった。
しかし、2026年のAgent AI、long context、MCP連携、RAGを前提にすると、16GB VRAMは万能とは言いにくい。
もちろん、16GB VRAMが不要になったわけではない。画像生成、通常チャット、小中規模モデル、CUDA開発では今でも強い。
問題は、「16GB VRAMがあれば何でもできる」と考えることである。
特に、Agent AI用途では、モデル本体だけでなく、context込みの実行時SIZEが問題になる。
ちなみに、2026年5月時点でのNVIDIAのGPUで最安値は、5060Ti VRAM 16GB単体で、92,000円程度である。
 

OLLAMA_CONTEXT_LENGTHで見る実測

ここからは、実際に OLLAMA_CONTEXT_LENGTH を変えた場合の実行時SIZEを確認する。
測定は、Ollama上で同じモデルに対してcontextを変え、ollama ps に表示されるSIZEを比較したものである。
ここで重要なのは、モデルファイルサイズではなく、実行時にどれだけのSIZEとして扱われるかである。

qwen3.5:0.8b

モデルファイルサイズは約1.0GBである。
qwen3.5:0.8b f3817196d142 1.0 GB
OLLAMA_CONTEXT_LENGTH
実行時SIZE
4096比
モデルファイル比
4096
2.2GB
1.00倍
2.2倍
8192
2.3GB
1.05倍
2.3倍
16384
2.4GB
1.09倍
2.4倍
32768
2.8GB
1.27倍
2.8倍
65536
3.6GB
1.64倍
3.6倍
131072
5.2GB
2.36倍
5.2倍
 
実測コマンド例は以下である。
OLLAMA_CONTEXT_LENGTH: “4096”
docker exec ollama ollama run qwen3.5:0.8b “hello”
docker exec ollama ollama ps
 
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:0.8b f3817196d142 2.2 GB 100% GPU 4096 6 hours from now
OLLAMA_CONTEXT_LENGTH: “131072”
docker exec ollama ollama run qwen3.5:0.8b “hello”
docker exec ollama ollama ps
 
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:0.8b f3817196d142 5.2 GB 100% GPU 131072 6 hours from now
 
qwen3.5:0.8bのような小型モデルでも、contextを131072まで上げると、実行時SIZEは5.2GBになる。モデルファイルは1.0GBしかないため、「1GBのモデルだから軽い」と判断すると誤る。
131072 contextでは、モデルファイルサイズの5倍以上の実行時SIZEになる。

qwen3.5:4b

モデルファイルサイズは約3.4GBである。
qwen3.5:4b 2a654d98e6fb 3.4 GB
OLLAMA_CONTEXT_LENGTH
実行時SIZE
4096比
モデルファイル比
4096
5.9GB
1.00倍
1.74倍
8192
6.1GB
1.03倍
1.79倍
16384
6.4GB
1.08倍
1.88倍
32768
7.1GB
1.20倍
2.09倍
65536
8.6GB
1.46倍
2.53倍
131072
11GB
1.86倍
3.24倍
 
実測コマンド例は以下である。
OLLAMA_CONTEXT_LENGTH: “4096”
docker exec ollama ollama run qwen3.5:4b “hello”
docker exec ollama ollama ps
 
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:4b 2a654d98e6fb 5.9 GB 100% GPU 4096 6 hours from now
OLLAMA_CONTEXT_LENGTH: “131072”
docker exec ollama ollama run qwen3.5:4b “hello”
docker exec ollama ollama ps
 
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:4b 2a654d98e6fb 11 GB 100% GPU 131072 6 hours from now
 
4Bでも、131072 contextでは実行時SIZEが11GBまで増える。モデルファイルは3.4GBだが、快適にGPUへ載せるには、その3倍以上の空きVRAMが必要になる。

qwen3.5:9b

モデルファイルサイズは約6.6GBである。
qwen3.5:9b 6488c96fa5fa 6.6 GB
OLLAMA_CONTEXT_LENGTH
実行時SIZE
4096比
モデルファイル比
4096
8.6GB
1.00倍
1.30倍
8192
8.8GB
1.02倍
1.33倍
16384
9.2GB
1.07倍
1.39倍
32768
9.9GB
1.15倍
1.50倍
65536
11GB
1.28倍
1.67倍
131072
14GB
1.63倍
2.12倍
 
実測コマンド例は以下である。
OLLAMA_CONTEXT_LENGTH: “4096”
docker exec ollama ollama run qwen3.5:9b “hello”
docker exec ollama ollama ps
 
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:9b 6488c96fa5fa 8.6 GB 100% GPU 4096 6 hours from now
OLLAMA_CONTEXT_LENGTH: “131072”
docker exec ollama ollama run qwen3.5:9b “hello”
docker exec ollama ollama ps
 
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:9b 6488c96fa5fa 14 GB 100% GPU 131072 6 hours from now
 
qwen3.5:9bでは、4096 contextでも8.6GBを消費する。131072 contextでは14GBまで増える。
つまり、16GB VRAMのGPUでqwen3.5:9bを131072 contextで使うと、残りは約2GBしかない。
ここに以下の要素が加わる。
  • OS側のGPU使用
  • Docker / CUDA管理領域
  • 他プロセス
  • 並列実行
  • embedding
  • rerank
  • ComfyUI
  • Open WebUI関連処理
  • 追加モデルロード
そのため、理論上は載っても、実運用では余裕が少ない。

実測結果から分かること

今回の測定で重要なのは、4096や8192 contextではメモリ増加が小さい点である。
4096 → 8192
この程度であれば、実行時SIZEの増加はそれほど大きくない。
しかし、Agent AI向けに以下のようなcontextへ上げると状況が変わる。
32768
65536
131072
この領域では、context拡大による実行時メモリ消費の増加が明確に見え始める。
特にqwen3.5:0.8bでは、モデルファイルは1.0GBしかないにもかかわらず、131072 contextでは5.2GBを消費する。これはモデルファイルサイズの5倍以上である。
  • qwen3.5:4bでも、モデルファイル3.4GBに対して、131072 contextでは11GBを消費する。
  • qwen3.5:9bでは、モデルファイル6.6GBに対して、131072 contextでは14GBを消費する。
 
この結果から分かるのは、Agent AI時代には「モデルファイルサイズ」だけを見ても意味が薄いということである。
見るべきなのは、以下である。
モデルファイルサイズではなく、
context込みの実行時SIZEである。
さらに興味深いのは、131072 context時の実行時SIZEを見ると、qwen3.5:4b(モデルファイル3.4GB)が11GB、qwen3.5:9b(モデルファイル6.6GB)が14GBであり、モデルサイズ差ほど大きな開きになっていない点である。
 
従来の感覚では、「モデルサイズが大きいほどVRAM消費が大きくなる」と考えられていた。しかし、huge context領域では、モデル本体よりもcontext保持側のメモリ消費比率が大きくなり始める。その結果、4Bと9Bの実行時SIZE差は、モデルファイルサイズ差ほど広がらない。もちろん、4B側にも速度や軽量性の利点はある。しかし、Agent AI向けに huge context を前提にすると、「VRAM節約のために4Bを選ぶ」という意味は以前より薄くなりつつある。
 
特に、qwen3.5:4b が11GB、qwen3.5:9b が14GB程度で収まるのであれば、推論品質を考慮して、最初から9Bを選んだ方が実用的な場面も増えてくる。
 
つまり、2026年のAgent AIでは、「モデルサイズ」よりも、「どれだけ巨大なcontextを保持できるか」がVRAM消費を支配し始めている。

なぜ16GB VRAMがAgent AI用途で厳しくなるのか

qwen3.5:9bの実測を見ると、16GB VRAMの限界が分かりやすい。
4096 context → 8.6GB
131072 context → 14GB
 
16GB VRAMのGPUでは、131072 contextを使った時点で残りは約2GBである。
単体で1モデルを動かすだけなら、動く可能性はある。しかし、実際のAgent AI運用では、Open WebUI、MCP、RAG、embedding、rerank、別モデル、ComfyUI、Dockerのオーバーヘッドなどが同時に関係する。
そのため、16GB VRAMでは、短いcontextなら問題なくても、Agent AIらしく長い履歴、RAG、ツール結果、MCP連携を積むと余裕がなくなる。
ここで重要なのは、「モデルが一応載る」ことと「快適に使える」ことは違うという点である。
 
Agent AIで快適に使うには、以下が必要である。
モデル本体
+ context保持に必要な実行時メモリ
+ 実行時オーバーヘッド
+ 余裕VRAM
 
つまり、モデルファイルサイズだけで判断してはいけない。
 

dGPUとUMAの棲み分け

この実測を踏まえると、dGPUとUMAの棲み分けはかなり明確になる。
用途
dGPU
UMA
短い通常チャット
画像生成
ComfyUI
CUDA依存処理
×
Agent AI
MCP連携
long context
長文RAG
大量の履歴保持
1台で全部
DGX Spark系なら◎
 
dGPUは速い。
しかし、VRAM容量に制限がある。
UMAはdGPUほど速くない場合がある。
しかし、大容量メモリをGPUが使いやすい。
そのため、Agent AI時代には、dGPUとUMAの役割が分かれ始めている。
 
 

Agent AIではGPUだけではなく、システム全体が効く

ちなみに、Agent AI時代になると、単純なGPU性能だけではなく、
  • GPU
  • VRAM
  • CPU
  • RAM
  • PCIe帯域
の全体バランスがかなり重要になる。
 
従来のローカルLLM用途では、「GPUにモデルを載せて推論する」ことが中心だったため、CPU性能はそこまで重視されていなかった。
 
しかし、最近のAgent AIでは、
  • MCP
  • Tool呼び出し
  • RAG
  • Embedding
  • rerank
  • Python実行
  • memory処理
  • Multi-Agent
など、CPUやRAM側の処理が大きく増えている。
 
さらに、VRAM不足になると、dGPU環境ではPCIe経由でメインメモリへ退避が発生し、急激にパフォーマンスが低下する。
 
一方、UMA(Unified Memory Architecture)では、VRAMとRAMを分離しないため、ピーク性能ではdGPUより不利でも、「全部載る」ことで極端な性能低下を避けやすい。
特に、
  • long context
  • huge KV cache
  • memory付きAgent
  • Multi-Agent
では、この差がかなり大きくなる。
そのため、2026年のAgent AIでは、「最速GPU」より、「巨大メモリ空間をどう破綻なく扱うか」が重要になり始めている。
 
 

NVIDIAのGPUだけで比較をすると

NVIDIA系で、Agent AI / RAG / 画像生成まで含めて考えると、2026年時点では大きく以下の3系統になる。VRAM/UMA 128GBクラスだと
  • RTX 5090 x2 VRAM 32GB x 2  VRAM合計 64GB
  • NVIDIA RTX PRO 6000 Blackwell Max-Q VRAM 96GB
  • DGX Spark UMA 128GB
RTX PRO 6000 Blackwell Max-Q
96GB ECC VRAMを搭載した企業向けGPUであり、long context や multi-agent では非常に強力である。 ただし、GPU単体でも非常に高額で、さらに、
  • Xeon / Threadripper級CPU
  • ECCメモリ
  • 大型電源
  • 大型冷却 なども必要になるため、システム全体としてはかなり大規模になる。
  • 価格目安:300-500万円 (サーバ:100-250万円 GPU:180-250万円)
RTX 5090 x2
現在の「個人向け本気AIサーバ」に近い構成である。 VRAM容量は非常に魅力的で、画像生成や大規模モデルではかなり強い。 しかし、
  • 消費電力
  • 発熱
  • 騒音
  • 電源容量 も非常に大きく、家庭環境ではかなり重い構成になる。 また、Blackwell世代のGeForceではNVLinkがないため、「64GBの巨大VRAM空間」として扱えるわけではなく、multi-GPU対応ソフトウェア前提になる。
  • 価格目安:180-300万円 (サーバ:60-120万円 GPU:120-180万円)
DGX Spark
  • 128GB Unified Memory
  • 低消費電力
  • 小型筐体
  • 全部入り構成 特に重要なのは、VRAMとRAMを分離して考えなくてよい点である。
  • 価格目安:60-80万円(マザボベンダー価格)
画像生成が最速ではなく快適に使えて、Agent AIに必要な大コンテキストサイズを扱うとなるとコストパフォーマンスが一番高い。 DGX Sparkだけ妙に現実的と言える。
 

 

まとめ

ローカルAIのマシン選びは、2025年から2026年にかけて大きく変わった。
従来は、dGPUのVRAM容量とGPU演算性能が中心であった。画像生成、ComfyUI、通常のLLMチャットでは、今でもdGPUは非常に強い。
しかし、Agent AI、MCP連携、long context、長文RAGの時代になると、単にVRAMが大きいだけでは足りなくなる。
特に重要なのは、Ollamaの OLLAMA_CONTEXT_LENGTH を大きくしたときの実行時SIZEである。
今回の実測では、qwen3.5:0.8bのような1.0GBの小型モデルでも、131072 contextでは5.2GBを消費した。qwen3.5:4bでは11GB、qwen3.5:9bでは14GBまで増えた。
つまり、Agent AI時代には、モデルファイルサイズだけを見ても意味が薄い。
見るべきなのは、context込みの実行時SIZEである。
短いcontextなら、dGPU 16GBでも十分に使える。しかし、Agent AIらしく長い履歴、RAG、ツール結果、MCP連携を積むと、16GB VRAMでは余裕がなくなる。
このため、Agent AI用途では「速いGPU」よりも、「大容量メモリをGPUが使える構成」が評価されやすい。
その代表が、Apple Silicon、AMD Strix Halo、DGX Spark系のようなUMA構成である。
 
結論として、現在のローカルAIマシン選びは以下のように考えるのが分かりやすい。
 
画像生成 / ComfyUI / 普通のLLMチャット
→ dGPU 8GB〜48GB VRAM
 
Agent AI / MCP連携 / long context / 長文RAG
→ UMA 96GB〜128GB以上
 
両方を1台でやりたい
→ DGX Spark系
 
今となっては、dGPUとVRAMだけが最適解ではない。
dGPUはフェラーリであり、UMAは大型バスである。
最高速が必要ならフェラーリでよい。しかし、Agent AIのように大量の履歴、文書、ツール結果、状態を運ぶ必要があるなら、大型バスが必要になる。
ローカルAIの主戦場は、単なる推論速度から、どれだけ大きなcontextを保持できるかへ移りつつある。
その意味で、Agent AI時代のマシン選びでは、GPU性能だけでなく、OLLAMA_CONTEXT_LENGTH を上げたときに実行時SIZEがどこまで増えるかを確認することが重要である。
次回は、実際、どれを買うべきかという話を書く。

コメントを残す