LM StudioのGPUオフロードとは?CPU 100%・GPU使用率が低い時の確認
- 公開日
- 2026-06-06
- 更新日
- 2026-08-10
- 情報確認日
- 2026-08-10
- 編集・運営
- Local AI Compass
GPUオフロードは、モデル処理の一部または多くをGPUへ担当させる考え方です。値を上げれば必ず速くなるわけではなく、VRAMに収まるか、モデルサイズ、量子化、コンテキスト長、利用するバックエンドを合わせて確認します。
導入前に確認すること
- Windowsのバージョン、メモリ容量、GPU/VRAM、空き容量を確認する
- 最初は軽量モデル、短い質問、少ない同時作業から始める
- 公式サイトの対応OS、利用規約、モデルのライセンスを確認する
現行REST loadの設定と実測を分けて保存する
LM StudioのGPUオフロードは、画面の瞬間的なGPU使用率だけで判断しません。現行native REST APIの`POST /api/v1/models/load`では、`context_length`、`eval_batch_size`、`flash_attention`、`offload_kv_cache_to_gpu`を指定でき、`echo_load_config: true`で実際に適用された設定をレスポンスへ含め、`load_time_seconds`も記録できます。これらはモデル全体の配置、KV cacheの配置、入力処理のbatch、attention最適化を同じ設定名として扱わないための確認材料です。
| 項目 | 公式APIで確認できること | 測定時の注意 |
|---|---|---|
| `context_length` | モデルが考慮する最大token数 | 入力長・KV cache・RAM/VRAMの条件として固定し、上限値を快適さや速度保証と混同しない |
| `eval_batch_size` | 入力tokenを一度に処理するbatch。llama.cpp engineのLLMで作用 | Prompt Processingとgenerationを分け、engineが異なる場合は同じ意味として比較しない |
| `flash_attention` | attention計算の最適化。llama.cpp engineではメモリ使用量を下げたり生成速度を改善する可能性 | 有効化だけで全PCが速くなると断定せず、同じprompt・context・モデルでA/B測定する |
| `offload_kv_cache_to_gpu` | KV cacheをGPU memoryへ置くか、falseならCPU memory/RAMへ置く設定。llama.cpp engineのLLMで作用 | モデル重みのGPU offloadとは別項目として、専用VRAM・共有メモリ・RAMのピークを記録する |
| `echo_load_config` / `load_time_seconds` | 適用されたload configとモデルload時間 | 設定値だけでなくレスポンス、ロード状態、生成中のRAM/VRAMを保存する |
- 同じmodel ID、context、入力、出力上限、runtime/engineを決め、モデルをロードする。
- `echo_load_config: true`で返った`load_config`と`load_time_seconds`を保存し、設定値が実際に適用されたか確認する。
- モデルload、Prompt Processing、generationそれぞれでCPU、GPU engine、専用VRAM、共有GPU memory、RAMを記録する。
- GPU offload、KV cache offload、Flash Attention、eval batchのうち1つだけを変え、速度・安定性・メモリの差を比較する。
LM StudioのSystem RequirementsにあるWindowsのAVX2、16GB RAM推奨、4GB専用VRAM推奨は開始条件の目安であり、特定モデルのロード成功や快適な速度を保証する値ではありません。
- [公式] LM Studioのシステム要件 - Windows x64/ARM、x64のAVX2、RAM、専用VRAMの公式要件を確認します。
- [公式] LM StudioのPer-model Defaults - モデルごとのGPU offload、context size、Flash Attentionなどの設定を確認します。
- [公式] LM Studio REST API - native v1 REST API、OpenAI互換API、モデルロードとprompt processingの違いを確認します。
- [公式] LM Studio REST APIのモデルロード - POST /api/v1/models/loadのcontext_length、eval_batch_size、Flash Attention、KV cache offload、load_config、load_time_secondsを確認します。
- [公式] LM Studioのlms load - context length、GPU offload、lms load --estimate-onlyなどを確認します。
LM StudioでGPUが認識されないように見える時の分岐
GPU一覧に出ない、GPU使用率が低い、VRAMは増える、CPU 100%になる、モデルがロードできない、は同じ症状ではありません。まずLM Studio側のGPU offload・専用VRAM・Compute系グラフ・runtimeを確認し、OllamaのPROCESSOR表示とは混ぜません。
| 症状 | 最初に確認 | 次に読む |
|---|---|---|
| GPUが一覧に出ない | GPU/driver、LM Studio版、runtime、Windows表示 | このページのGPU/runtime確認か親ハブへ戻る |
| GPU使用率が低い | Compute系、専用/共有VRAM、処理段階 | Prompt Processing記事を確認 |
| VRAMは使うが生成が遅い | context、入力長、CPU側処理、generation | 速度測定記事を確認 |
| OllamaだけCPUになる | Ollama公式GPU表とPROCESSOR | Ollama GPU記事を確認 |
- 速度・RAM・VRAMを測る方法 - 生成速度とGPU観測を分けて記録する
- LM StudioのPrompt Processingが遅い - 入力処理の遅さをGPU使用率と分ける
- LM Studioの回答が途中で止まる - 生成開始後の停止を確認する
- 症状別トラブル解決ハブ - GPU一覧に出ない段階を親ハブで切り分ける
- OllamaでGPUが使われない - Ollama固有のPROCESSORと対応表へ進む
agent workloadをチャット負荷と分ける
ファイル検索、tool call、長いcontext、KV cache、embedding、checkpoint、並列処理が加わると、短い一問一答よりPC負荷が増えやすくなります。モデルサイズだけでなく、処理の回数とデータの往復を見ます。
- ローカルAIエージェントのPC負荷 - RAM、VRAM、CPU、GPU、SSD別の切り分けを見る
ColabのnglとLM StudioのGPU設定を混同しない
Colabのllama.cppで使うnglは、LM Studio UIのGPU offload表示と完全に同じ設定名・意味ではありません。一部CPU offloadで動いた場合は、全部VRAMへ載った結果と区別し、RAM、VRAM、CPU、速度を記録します。
- Colab T4のGPU layersとOOM - model loadと一部CPU offloadを分ける
GPUオフロードは設定と測定値を合わせて読む
GPU使用率が低い、CPUが高いという瞬間のグラフだけでは、GPUオフロードの成否は決められません。モデル設定、専用VRAM、共有メモリ、CPU/GPUの負荷、生成中のtokens/sを同じ測定行に残します。
| 確認順 | 記録 | 判断 |
|---|---|---|
| 1 | GPU layersやモデル別オフロード設定 | 意図した設定になっているか |
| 2 | Processor表示、専用VRAM、共有メモリ | CPU、GPU、部分処理のどれか |
| 3 | ロード・TTFT・tokens/s・ピークRAM/VRAM | オフロード変更でどの段階が変わったか |
- ローカルAIの速度を測る方法 - オフロード変更を1つずつ比較する
GPUオフロードの前にGGUFと量子化を分ける
LM StudioのCPU/GPU負荷を確認するときは、GGUFというファイル形式、7B/8Bなどのモデル規模、Q4_K_Mなどの量子化を別々に見ます。GPU設定だけを変えても、モデルが大きすぎる・量子化が重いという原因は残ります。
- GGUFとは何かを30秒で確認する - 形式、モデル規模、量子化を分けて見る
- Q4_K_M・Q5_K_M・Q8_0の違い - 重さと品質の比較へ進む
GPU offloadで速くなる場合と残るボトルネック
GPU offloadは、モデルの一部をGPUへ載せて速度改善を狙う設定です。ただしVRAM不足、CPU/RAM、context length、冷却が残ると、期待どおり速くならないことがあります。
| 症状 | 疑うもの | 次の確認 |
|---|---|---|
| GPU使用率が低い | offload設定、対応GPU | 少しずつlayerを調整 |
| VRAM不足 | モデルが重い、Q8、大きいcontext | Q4/Q5や短いcontextへ下げる |
| CPU 100% | CPU側処理が残る | モデルサイズと同時起動アプリを確認 |
| 発熱で遅い | 冷却/電力制限 | 短時間テストと長時間テストを分ける |
- 電力効率ガイド - GPUとCPUの効率を読む
Hermes Desktopでつながらない時の読み順
Hermes Desktopの設定を何度も変える前に、症状別ハブで provider 側、base URL、model ID、API key、PC負荷を分けて確認してください。
- Hermes Desktopトラブル解決ハブ - connection refused、model not found、401/429、timeout、WSL2を症状別に切り分ける
- Hermes Desktop接続トラブル診断 - 数問選んで最初に疑う原因と読む記事を確認する
GPUオフロードを触る前に見る表
CPU 100%・GPU 5%でも、直ちに設定ミスとは限りません。モデルの一部だけがGPUに載っている、タスクマネージャーで3Dグラフを見ている、前処理やデータ転送をCPUが担当している場合があります。使用率だけでなく、専用GPUメモリ、LM Studioのロード設定、生成速度を合わせて見ます。
| 症状 | 先に変えるもの | 理由 |
|---|---|---|
| ロード時に失敗 | モデルサイズ・量子化を下げる | 推論以前にRAM/VRAMへ収まっていない |
| VRAMが上限近い | Offloadを少し下げる | 上げすぎると確保失敗や不安定化が起きる |
| CPU 100%で遅い | 軽いQ4、Context Lengthを下げる | 計算量とKVキャッシュを減らせる |
| GPU 0~数%に見える | 専用GPUメモリとCompute系グラフを見る | 3D使用率だけでは推論負荷を判断しにくい |
| GPUなし・内蔵GPU | 7B/8B未満も含む軽量候補、短文用途 | 共有メモリ・帯域・冷却の制約が大きい |
症状別ハブから来た人へ
LM StudioでCPU 100%、GPUが使われない、GPU使用率が低い、VRAMだけ使われているように見える時は、このページでGPU offloadとタスクマネージャーの見方を確認します。起動しない、モデルが読み込めない、PDFだけ重い場合は症状別ハブへ戻って、モデル・PC・接続・RAGを分けてください。
- LM Studio症状別トラブルシュート - GPU以外の原因も含めて確認する
- モデルサイズ早見表 - VRAMに載らない時はモデルサイズへ戻る
30秒結論:CPU使用率とGPU使用率だけで判断しない
GPU offload、VRAM、モデルロード設定を確認します。
3DグラフだけでなくCompute系と専用GPUメモリを見ます。
モデル、コンテキスト、offload量を下げて安定性を見ます。
GPUオフロードとは
ローカルLLMの計算をCPUだけで行うのではなく、対応する処理をGPUへ移すことです。GPUが対応し、VRAMに余裕があり、実行環境が正しく認識している場合は、応答速度が改善することがあります。
一方、モデル全体や実行時データがVRAMに収まらない場合は、一部をCPUや共有メモリ側で扱う構成になります。オフロード数を増やしすぎると、ロード失敗、不安定化、メモリ不足につながる場合があります。
オフロード数を上げると何が変わるか
| 変更 | 期待できること | 注意 |
|---|---|---|
| GPUへ載せる量を増やす | CPU側の計算を減らしやすい | VRAM使用量が増える |
| モデルを小さくする | VRAMへ載せやすくなる | モデル能力は変わる |
| Q4へ下げる | 必要メモリを減らしやすい | 量子化による品質差がある |
| コンテキストを短くする | 実行時負荷を減らしやすい | 一度に扱える文章量が減る |
GPU使用率が低く見える理由
- Windowsタスクマネージャーが3Dグラフを表示し、計算用エンジンを見ていない。
- 生成は短い処理の繰り返しで、瞬間的な使用率を見逃している。
- モデルの一部しかGPUへオフロードされていない。
- プロンプト処理と生成でCPU/GPUの負荷配分が異なる。
- VRAM不足でCPU側や共有メモリ側の処理が増えている。
遅い時に確認する順番
- 短い質問へ戻し、トークン生成が本当に遅いか確認する。
- モデル規模、GGUF量子化、ファイル容量を確認する。
- LM StudioでGPUが認識され、offload設定が有効か確認する。
- 専用GPUメモリ使用量とPCメモリ使用量を見る。
- offload量を段階的に変更し、ロード失敗や速度を比較する。
- コンテキスト長を下げ、他の重いアプリを閉じる。
Windowsタスクマネージャーで見る時の注意
GPU使用率の1つの数字だけでは、LLM計算がGPUへ載っているか判断できません。GPUのグラフ種類を切り替え、Compute系の利用率、専用GPUメモリ、共有GPUメモリを確認します。LM Studio側のロード情報やログも合わせて見てください。
16GBメモリ・GPUなし・ミニPCの注意
| 環境 | 現実的な対処 |
|---|---|
| メモリ16GB | 7B/8B級Q4、短いコンテキスト、他アプリを閉じる |
| GPUなし | CPU推論前提で軽いモデルと短い入力を使う |
| 内蔵GPU | 共有メモリを使うため、PCメモリ全体の余裕を見る |
| ミニPC | 冷却、電力制限、増設可否、長時間負荷に注意する |
次に確認する記事
- LM Studioが止まる・固まる原因 - メモリ不足とモデル負荷を切り分ける
- モデルサイズ早見表 - PCに合う規模へ下げる
- Q4・Q5・Q8の違い - 量子化で負荷を調整する
- GPUなしPCで使う方法 - CPU実行の現実的な範囲を見る
よくある質問
GPUオフロードを増やせば必ず速くなりますか?
必ず速くなるわけではありません。VRAM不足や不安定な設定では遅くなったり、読み込みに失敗したりする可能性があります。
CPU使用率が高いのは異常ですか?
異常とは限りません。CPU推論中心の構成、GPUに十分載っていないモデル、長いコンテキスト、重い量子化などでCPU使用率は高くなりやすいです。
GPU使用率が低いのはなぜですか?
タスクマネージャーの見方、GPUへ載っている量、処理内容、設定によって低く見える場合があります。VRAM使用量や回答速度も合わせて確認してください。
VRAMが足りないとどうなりますか?
読み込みに失敗する、CPU側へ回って遅くなる、不安定になる、といった症状につながる可能性があります。必要量はモデルと設定で変わります。
GPUなしでもLM Studioは使えますか?
軽量モデルなら試せる場合があります。ただしCPU実行では遅くなりやすいため、Q4前後、短い質問、小さめのモデルから始めてください。
Q8のほうがGPUを使えて速いですか?
そうとは限りません。Q8は重くなりやすく、VRAMやメモリに余裕がないと遅くなる場合があります。初心者はQ4/Q5前後から比較するほうが切り分けやすいです。
LM StudioでCPU 100%、GPU 5%なのは異常ですか?
必ずしも異常ではありません。GPU offloadが少ない、VRAMに収まらない、タスクマネージャーで3Dグラフを見ているなど複数の可能性があります。専用GPUメモリ、Compute系グラフ、LM Studioのロード設定を合わせて確認してください。
GPUオフロードを最大にすれば速くなりますか?
VRAMに収まり、実行環境が安定する範囲では改善することがありますが、最大が常に最速とは限りません。VRAM不足になる場合はロード失敗や不安定化が起こるため、段階的に比較してください。
GPUオフロードでCPU負荷は下がりますか?
GPUへ移せる計算が増えればCPU負荷が下がる場合があります。ただし、前処理、データ転送、GPUへ載らない処理などでCPUも使うため、0%になるとは限りません。
GPU使用率の瞬間値だけでオフロードを判断できますか?
判断できません。GPUエンジンの違い、処理段階、表示の瞬間値があるため、設定、Processor、専用VRAM、ピーク値、tokens/sを合わせて確認します。
LM StudioでGPUオフロードを確認する時、設定値だけで十分ですか?
十分ではありません。現行REST loadの`echo_load_config`で適用された設定と`load_time_seconds`を保存し、モデルload・Prompt Processing・generationのCPU/GPU engine、専用VRAM、共有GPU memory、RAMを同じ条件で確認します。
offload_kv_cache_to_gpuはモデルのGPUオフロードと同じですか?
同じではありません。`offload_kv_cache_to_gpu`はKV cacheの配置を指定する項目で、モデル重みのGPU offloadとは分けて読みます。公式REST Docsではllama.cpp engineのLLMに作用する項目として説明されているため、設定名だけで全runtimeへ一般化せず、実際のload configとメモリを記録します。
次に読むおすすめルート
GPUなし・低スペックPCの人
軽量モデル、メモリ別の目安、重いときの確認ポイントを先に見ます。
- ローカルAI用PCスペックの見方
- GPUなしPCで使える範囲を整理
- GPUなしで音声を文字起こしする
- 古いWindows PCでLM Studioを使うなら
- 中古PCでローカルAIは使える?
- ミニPCでローカルAIは使える?
- メモリ別に始める前に知ること
- 速度・RAM・VRAMを測る方法
- Google ColabでQwen3.6-27Bを動かす
- MTPとspeculative decoding
- Colab T4のGGUF OOM対策
- Gemma 4 12Bの更新メモ
- 重い・動かないときの確認ポイント
- 診断ページ
あなたはどのタイプ?
- 初めてローカル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まで段階的に進みます。
関連チェック先
- LM Studio lms load - LM Studio CLIでのモデル読み込み、GPUオフロード、コンテキスト長、推定読み込みを確認できます。
- [公式] LM Studio REST API - native v1 REST API、OpenAI互換API、モデルロードとprompt processingの違いを確認します。
- LM Studio Local Server - LM StudioのローカルLLM APIサーバー、localhostやネットワーク公開、起動方法を確認できます。
- LM Studio Docs - LM Studioのアプリ、ローカルモデル、GGUF実行、オフライン利用、API機能の公式説明です。
- Characterizing and Understanding Energy Footprint and Efficiency of Small Language Model on Edges - Raspberry Pi 5、Jetson Nano、Jetson Orin Nanoで小型言語モデルの電力効率を比較した研究です。
- [公式] LM StudioのPer-model Defaults - モデルごとのGPU offload、context size、Flash Attentionなどの設定を確認します。
- [公式] LM Studio REST APIのモデルロード - POST /api/v1/models/loadのcontext_length、eval_batch_size、Flash Attention、KV cache offload、load_config、load_time_secondsを確認します。
- [公式] Ollama FAQのProcessor表示 - ollama psでCPU、GPU、CPU/GPUの一部処理を確認する方法を説明する公式FAQ。
- Introducing LM Studio 0.4.0 - llmster、parallel requests、Unified KV Cache、Developer Mode、歴史的な/v1/chat案内、permission keysの公式発表です。
- [公式] LM Studioのシステム要件 - Windows x64/ARM、x64のAVX2、RAM、専用VRAMの公式要件を確認します。
- [公式] LM Studioのlms load - context length、GPU offload、lms load --estimate-onlyなどを確認します。
- [公式] LM Studio Changelog - バージョンごとの不具合修正、APIやruntimeの変更を確認します。