LM StudioのGPUオフロードとは？CPU 100%・GPU使用率が低い時の確認

WindowsのVulkanでiGPUへロードされた時は版・backend・deviceを分ける

LM Studio公式Changelogでは、0.4.17 Build 1に「WindowsでVulkanを使うとモデルがiGPUへロードされる不具合の修正」、Build 2に「Vulkan backendのiGPUを表示するが既定では無効」、driver更新後にAMD GPUが検出されない問題の修正が記録されています。iGPUが一覧に出ること、iGPUが実際に選択されていること、GPU offloadがモデルへ適用されたことは別の確認です。

2026-09-30時点のChangelog先頭はLM Studio 0.4.25（2026-09-19）で、M3以降かつmacOS 26.4以降を対象としたSplash engine対応です。Windows Vulkan/iGPUとAMD GPU検出の修正は0.4.17 Build 1/2、GGUF向けadvanced llama.cpp argument overridesの追加は0.4.24に記録されています。アプリの版だけで解決を判断せず、Windowsでは使用中のbackend、選択device、runtime/engine、モデルload結果を記録します。

1. アプリに表示されるLM Studioの版と、使用中のruntime/backendを記録する。
2. VulkanのGPU一覧で、iGPUが見えるだけなのか、実際に選択・有効になっているのかを分けて確認する。
3. 小さなGGUF、短い固定入力、同じcontextでロードし、選択device、専用/共有VRAM、CPU、ロード成否を保存する。
4. driverやdeviceを変えた時は、GPU使用率の瞬間値ではなく、同じモデルのload・TTFT・generationを前後で比較する。

• LM Studioの起動・版・runtime確認 - アプリ自体が開かない問題と、起動後のGPU問題を分ける
• 速度・RAM・VRAMを測る方法 - load・TTFT・generationを同じ条件で測る

• [公式] LM Studio Changelog - バージョンごとの不具合修正、APIやruntimeの変更を確認します。

現行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最適化を同じ設定名として扱わないための確認材料です。

1. 同じmodel ID、context、入力、出力上限、runtime/engineを決め、モデルをロードする。
2. LM Studioの版、backend、engine/runtimeを記録し、GGUFのadvanced llama.cpp argument overridesを使用中なら正確な値も保存する。
3. `echo_load_config: true`で返った`load_config`と`load_time_seconds`を保存し、設定値が実際に適用されたか確認する。
4. モデルload、Prompt Processing、generationそれぞれでCPU、GPU engine、専用VRAM、共有GPU memory、RAMを記録する。
5. 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表示とは混ぜません。

• 速度・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を同じ測定行に残します。

• ローカル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と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のロード設定、生成速度を合わせて見ます。

• モデルを小さくする - 7B/8BとPCメモリの目安
• Q4を選ぶ理由 - 品質と必要メモリの調整
• PCスペックを確認 - RAM・VRAM・冷却の見方
• 症状全体から探す - 停止・遅延・日本語問題を切り分け

症状別ハブから来た人へ

LM StudioでCPU 100%、GPUが使われない、GPU使用率が低い、VRAMだけ使われているように見える時は、このページでGPU offloadとタスクマネージャーの見方を確認します。起動しない、モデルが読み込めない、PDFだけ重い場合は症状別ハブへ戻って、モデル・PC・接続・RAGを分けてください。

• LM Studio症状別トラブルシュート - GPU以外の原因も含めて確認する
• モデルサイズ早見表 - VRAMに載らない時はモデルサイズへ戻る

30秒結論：CPU使用率とGPU使用率だけで判断しない

GPUオフロードとは

ローカルLLMの計算をCPUだけで行うのではなく、対応する処理をGPUへ移すことです。GPUが対応し、VRAMに余裕があり、実行環境が正しく認識している場合は、応答速度が改善することがあります。

一方、モデル全体や実行時データがVRAMに収まらない場合は、一部をCPUや共有メモリ側で扱う構成になります。オフロード数を増やしすぎると、ロード失敗、不安定化、メモリ不足につながる場合があります。

オフロード数を上げると何が変わるか

GPU使用率が低く見える理由

• Windowsタスクマネージャーが3Dグラフを表示し、計算用エンジンを見ていない。
• 生成は短い処理の繰り返しで、瞬間的な使用率を見逃している。
• モデルの一部しかGPUへオフロードされていない。
• プロンプト処理と生成でCPU/GPUの負荷配分が異なる。
• VRAM不足でCPU側や共有メモリ側の処理が増えている。

遅い時に確認する順番

1. 短い質問へ戻し、トークン生成が本当に遅いか確認する。
2. モデル規模、GGUF量子化、ファイル容量を確認する。
3. LM StudioでGPUが認識され、offload設定が有効か確認する。
4. 専用GPUメモリ使用量とPCメモリ使用量を見る。
5. offload量を段階的に変更し、ロード失敗や速度を比較する。
6. コンテキスト長を下げ、他の重いアプリを閉じる。

Windowsタスクマネージャーで見る時の注意

GPU使用率の1つの数字だけでは、LLM計算がGPUへ載っているか判断できません。GPUのグラフ種類を切り替え、Compute系の利用率、専用GPUメモリ、共有GPUメモリを確認します。LM Studio側のロード情報やログも合わせて見てください。

16GBメモリ・GPUなし・ミニPCの注意

次に確認する記事

• LM Studioが止まる・固まる原因 - メモリ不足とモデル負荷を切り分ける
• モデルサイズ早見表 - PCに合う規模へ下げる
• Q4・Q5・Q8の違い - 量子化で負荷を調整する
• GPUなしPCで使う方法 - CPU実行の現実的な範囲を見る