ローカルAIエージェントはなぜ重い？長文・KV cache・ツール呼び出しをPC負荷から解説
- 公開日
- 2026-07-28
- 更新日
- 2026-08-10
- 情報確認日
- 2026-08-10
- 編集・運営
- Local AI Compass
ローカルAIエージェントの重さは、モデルのparameter数だけでは決まりません。計画、ファイル検索、tool call、結果の再入力、長いcontext、KV cache、embedding、並列処理が積み重なるため、短い一問一答よりRAM・VRAM・CPU・SSD・GPUへ負荷が広がりやすくなります。
導入前に確認すること
- Windowsのバージョン、メモリ容量、GPU/VRAM、空き容量を確認する
- 最初は軽量モデル、短い質問、少ない同時作業から始める
- 公式サイトの対応OS、利用規約、モデルのライセンスを確認する
agent workloadをチャット負荷と分ける
ファイル検索、tool call、長いcontext、KV cache、embedding、checkpoint、並列処理が加わると、短い一問一答よりPC負荷が増えやすくなります。モデルサイズだけでなく、処理の回数とデータの往復を見ます。
- ローカルAIエージェントのPC負荷 - RAM、VRAM、CPU、GPU、SSD別の切り分けを見る
チャットとagent workflowの違い
| 処理 | 短いチャット | agent workflow |
|---|---|---|
| 入力 | 質問と短いcontext | 計画、ファイル、tool結果、履歴が増える |
| 推論回数 | 1回の回答で終わることがある | tool callごとに再推論や判断が続く |
| メモリ | モデルと現在のcontext | KV cache、長文context、embedding、複数modelが重なる |
| I/O | 画面への入出力 | ファイル読み書き、index、checkpoint、生成ファイル |
| 失敗の見え方 | 遅い、止まる | tool timeout、loop、OOM、保存失敗、外部通信 |
prompt処理・生成・KV cache
長いpromptは、回答を生成する前の入力処理だけでも時間と計算資源を使います。会話やtool結果が蓄積するとcontextが増え、KV cacheが必要になります。cacheは毎回の再計算を減らす方向へ役立つ一方、設定、parallel slots、context長、runtimeによって必要メモリが変わるため、常に軽くなるとは限りません。
- コンテキスト長とは - 長文・PDF・context設定の基本を見る
- LM Studio 0.4.0公式 - Unified KV Cache、parallel requests、歴史的な/v1/chat表記を確認する
tool callとファイル処理が重さを増やす理由
- codebaseを検索すると、複数ファイルの読み取りと要約が積み重なる。
- toolの結果が次のpromptへ入り、contextが長くなる。
- PDFでは抽出、chunk、embedding、検索、rerank、生成が分かれる。
- 画像や音声ではtranscriptionやvision処理が追加される。
- checkpoint、preview、生成ファイルはSSD I/Oや保存容量も使う。
parallel requestsと複数model
現行のLM Studio Parallel Requests docsでは、Max Concurrent Predictionsによる複数要求の処理をllama.cpp engineのcontinuous batchingとして説明し、公式ページ上の既定値は4です。MLXは同ページでcoming soonとされています。0.4.0の発表は背景資料として扱い、現在の対応engine、モデルロード設定、同時要求数、待ち時間とthroughputを実測で分けます。
| 設定・構成 | 起きやすいこと | 切り分け |
|---|---|---|
| contextを伸ばす | prompt処理、KV cache、待ち時間、memoryが増えやすい | 短いcontextへ戻して比較する |
| parallel slotsを増やす | 同時処理でthroughputを上げられる可能性、resource競合も増える | 1 slotと同じ質問で測る |
| local + embedding + rerank | LLM以外のmodelやindex処理が加わる | embedding、検索、生成を個別に測る |
| agent + cloud | PC計算を抑えられるが通信・費用・送信範囲が増える | provider、latency、usage、privacyを確認する |
RAM・VRAM・CPU・GPU・SSDの役割
| 資源 | agentで増えやすい負荷 | まず試す対策 |
|---|---|---|
| RAM | CPU推論、context、embedding、複数アプリ | モデル、context、同時アプリを減らす |
| VRAM | GPUに載せるweights、KV cache、vision | 量子化、モデルサイズ、GPU offloadを見直す |
| CPU | prompt処理、CPU推論、PDF抽出、tool処理 | 処理を短くし、CPU実行の速度を測る |
| GPU | 生成、offload、画像・vision処理 | VRAM使用量とcomputeグラフを分けて見る |
| SSD | モデル、index、cache、生成物、checkpoint | 空き容量と読み書き、古い生成物を確認する |
- ローカルAI用PCスペック - メモリ、GPU、VRAM、CPUの基本へ戻る
- GPUオフロード - CPU 100%やGPU使用率が低い時を確認する
- メモリ別ガイド - 8GB/16GB/32GBで始める目安を見る
8GB・16GB・32GBの始め方
| PCメモリ | agentを試す入口 | 避けたい始め方 |
|---|---|---|
| 8GB | 短文chat、軽いmodel、公開テキストを少量 | 長いcontext、PDF/RAG、複数model、parallel |
| 16GB | 7B/8B級local model、短いcodeや小さな文書 | 大きいmodelとagent toolを同時に増やす |
| 32GB以上 | 複数条件の比較、長めの文書、API/agentへ段階的に進む | 容量だけを根拠に巨大modelや1M contextを常用する |
これは機種別の保証値ではなく、モデル、量子化、GPU、OS、他アプリ、context、runtimeで変わる始め方の目安です。
重い・止まる時の切り分け
- 短い質問と小さいlocal modelで単体動作を確認する。
- agentを外し、同じmodelでtokens/s、TTFT、RAM/VRAMを測る。
- context、添付ファイル、tool call、parallel slotsを1つずつ減らす。
- PDFなら抽出、embedding、検索、rerank、生成を分ける。
- cloudに切り替える場合は、PC負荷と通信・費用・privacyのトレードオフを記録する。
関連ページ
- WindowsローカルAIエージェント比較 - Bionic、Ollama、AnythingLLM、Hermesの役割へ戻る
- LM Studio Bionic - Code/Work project、checkpoint、local/cloudを確認する
- AnythingLLM PDF/RAG - 文書処理の重さと通信先を見る
- 速度を測る方法 - 同じ条件で実測を残す
2026年8月の公式docsでagent負荷を4つに分けて測る
agentの重さを「モデルが大きいから」だけで説明すると、context、並列、KV cache、tool loopのどこが効いたのか分からなくなります。OllamaとLM Studioの現行公式docsを基準に、設定値と実測値を別々に記録します。
| 要因 | 公式docsで確認できる境界 | 実測で残す値 |
|---|---|---|
| contextと並列 | Ollamaでは`OLLAMA_NUM_PARALLEL`と`OLLAMA_CONTEXT_LENGTH`の組み合わせで必要メモリが増え、余裕がなければ要求が待ち行列に入ります。 | context length、parallel数、同時要求数、peak RAM/VRAM、queueやOOMの有無 |
| LM Studioの同時予測 | LM StudioのMax Concurrent Predictionsは複数リクエストをキュー待ちではなく処理するための設定です。現行docsではllama.cpp engineのcontinuous batchingとして説明され、1つの短いchatが必ず速くなる保証ではありません。 | engine/runtime、設定した同時予測数、複数要求時の総時間、1要求あたりの待ち時間 |
| KV cache・attention | Ollama FAQではFlash AttentionとKV cache typeがメモリや精度のトレードオフに関係します。設定名だけで品質や速度を固定値として扱いません。 | KV cache type、Flash Attention、同じ入力での速度・メモリ・回答差 |
| tool loop・文書処理 | tool結果、ファイル、RAG検索結果が次の入力へ入ると、推論回数とcontextが増えます。これはruntimeの並列設定とは別のagent workflow要因です。 | tool call回数、入力token、総時間、ファイルI/O、失敗・再試行 |
- モデル、量子化、runtime、質問、出力長を固定し、まずtoolなし・parallel 1の短いchatを測る。
- 同じ条件でcontext lengthだけを変え、TTFT、prompt処理時間、生成速度、peak RAM/VRAMを記録する。
- toolを1つ、ファイルを1つ、RAG検索を1回ずつ追加し、tool call回数と総時間の増分を分けて記録する。
- Ollamaは`OLLAMA_NUM_PARALLEL`と`OLLAMA_CONTEXT_LENGTH`、ロード後の`ollama ps`を確認し、LM StudioはMax Concurrent Predictionsとengineを記録する。
- 最後に複数要求を比較する。単一chatの速さ、複数要求のthroughput、回答の安定性を同じ指標にまとめない。
自分のPCでの実用値は、モデル、GPU offload、他アプリ、ドライバ、runtime、入力、温度、電源設定でも変わります。公式設定の意味と自分の測定結果を分けて書くと、別のWindows PCへ誤って速度保証を広げずに済みます。
- Ollama FAQ - parallel、context、Flash Attention、KV cache typeの現行説明を見る
- Ollama Context length - context設定とVRAM・メモリの関係を見る
- Ollama API /api/ps - ロード中のcontextとVRAM使用量を確認する
- LM Studio Parallel Requests - Max Concurrent Predictionsとcontinuous batchingを見る
- LM Studio Per-model Defaults - context、GPU offload、Flash Attentionのモデル別設定を見る
- 速度を測る方法 - tokens/sだけでなく総時間とメモリを記録する
よくある質問
ローカルAIエージェントは普通のchatより重いですか？
重くなりやすいです。tool call、ファイル検索、context蓄積、embedding、再推論、checkpointなどが増えるためです。ただしmodel、task、runtime、PCで差があります。
KV cacheがあれば必ず軽くなりますか？
再計算を減らす方向に役立つ場合がありますが、cache自体のメモリ、context長、parallel slots、runtime設定が関係します。測定せずに軽さを断定しません。
cloud modelならPC負荷はゼロですか？
推論計算をPCから外せても、アプリ、ファイル処理、画面、音声、network、表示、RAG indexはPC側で動く場合があります。通信・費用・送信データも増え得ます。
GPUなしPCでagentを使えますか？
軽いmodel、短いcontext、少ないtoolから試せる場合があります。長文、PDF、複数model、並列処理はRAMとCPUの余裕を見てください。
一番最初に減らす設定は何ですか？
短いcontext、小さいmodel、1つのtool、1つのファイル、parallelなしから始め、同じ質問で測ります。複数条件を同時に変えないことが切り分けのコツです。
Ollamaの`OLLAMA_NUM_PARALLEL`を増やすと1つの回答も速くなりますか？
速くなるとは限りません。複数要求を同時に処理できる可能性がある一方、公式FAQでは必要メモリが`OLLAMA_NUM_PARALLEL`と`OLLAMA_CONTEXT_LENGTH`の組み合わせで増え、余裕がなければ待ち行列に入ると説明されています。単一chatの速度と複数要求のthroughputを分けて測ってください。
LM StudioのMax Concurrent Predictionsは一人のchatを速くする設定ですか？
主な目的は複数リクエストの同時処理です。現行公式docsではllama.cpp engineのcontinuous batchingとして説明されていますが、engine、モデル、context、PCによって結果は変わります。1要求のTTFTや生成速度が必ず改善すると断定せず、設定値と実測値を記録します。
KV cacheを量子化すれば常に同じ品質で軽くなりますか？
常に同じとは言えません。Ollama FAQでもKV cache typeはメモリと精度のトレードオフとして扱われています。同じモデル、入力、context、runtimeで、メモリ削減だけでなく速度と回答差も比較してください。
次に読むおすすめルート
ローカルAIエージェントを試したい人
Bionic、Ollama、AnythingLLM、Hermesを役割別に分け、local/cloud、tool、保存、PC負荷を順番に確認します。
- ローカルAIエージェント比較
- LM Studio Bionicのlocal/cloud
- Kimi K3はlocalかcloudか
- AnythingLLM Model Router
- Scheduled JobsとMemories
- Magic Echo・Beacon・Tab
- WindowsでローカルAIコーディングを始める
- VS CodeでローカルAIを使う
- local modelでもprivacyを確認
- Ollamaのlocal/cloud
- LM Studio 0.4.0のAPI入口
- AnythingLLMの解説
- PC診断ページ
あなたはどのタイプ？
- 初めてローカルAIを触る人 - まず全体像をつかみ、LM StudioとOllamaの違い、モデルサイズの考え方を順番に確認します。
- LM Studio・Ollamaの症状別トラブルを解決したい人 - 起動、モデルロード、Prompt Processing、generation、API接続、GPU確認をツール別に分けて読みます。
- GPUなし・低スペックPCの人 - 軽量モデル、メモリ別の目安、重いときの確認ポイントを先に見ます。
- PDFや資料を読ませたい人 - 先に基本を押さえ、モデル単体の確認後にAnythingLLMへ進みます。
- ローカルAIエージェントを試したい人 - Bionic、Ollama、AnythingLLM、Hermesを役割別に分け、local/cloud、tool、保存、PC負荷を順番に確認します。
- 開発・API連携したい人 - LM StudioとOllamaの違いを確認し、API、長文処理、RAGまで段階的に進みます。
関連チェック先
- Introducing LM Studio 0.4.0 - llmster、parallel requests、Unified KV Cache、Developer Mode、歴史的な/v1/chat案内、permission keysの公式発表です。
- LM Studio Bionic公式発表 - Bionicの役割、local・LM Link・Secure Cloud、Code/Work project、音声入力を確認する公式記事です。
- AnythingLLM Scheduled Jobs overview - job、run、schedule、allowed tools、結果保存、single-user modeの公式ドキュメントです。
- Ollama Cloud docs - local modelとcloud modelの実行場所、オフロード、利用条件を確認する公式ドキュメントです。
- LM Studio Parallel Requests - LM StudioのMax Concurrent Predictions、continuous batching、llama.cpp engineでの並列リクエストを確認できます。
- LM Studio Get Context Length - LM Studioでモデルの最大context lengthを確認し、入力がcontextに収まるか調べる公式ドキュメントです。
- LM Studio Per-model Defaults - LM Studioでモデルごとのcontext size、GPU offload、Flash Attentionなどのロード既定値を設定する公式ドキュメントです。
- Ollama FAQ - parallel requests、context length、Flash Attention、KV cache typeのメモリと精度の関係を確認できます。
- Ollama Context length - Ollamaのcontext length、VRAMに応じた既定値、OLLAMA_CONTEXT_LENGTH、ollama psでの確認方法を確認できます。
- Ollama API /api/ps - Ollamaで現在ロード中のモデル、size_vram、context_lengthなどを確認する公式APIです。