LM StudioでGPUが使われないときの原因と確認手順

LM Studioの返答を待っているのに、GPUのグラフはほとんど動かない。3Dグラフだけを見ていると、推論に使われていないように見えます。

この記事では、Windowsで動かすローカルモデルを対象に、返答中のGPUの動き、GPU Offload、ランタイムの順で見ていきます。GPUを使っていると分かれば、次は待ち時間を減らす調整へ。使っている様子が見つからなければ、読み込み方から調べましょう。

同じ質問を送り、返答中のGPUを見る

グラフを開く前に、選んだモデルの実行先を見ます。ここで調べるのは、通常のLM Studioで取得して、このPCへ読み込んだモデルです。Bionicの選択欄ならLocalが手元、Cloudがクラウド、RemoteがLM Linkでつながった別端末を示します。CloudやRemoteの返答を待つ間に手元のGPUが静かでも、それだけで異常とは言えません。計算している実行先が違うためです。

ローカルモデルを読み込んだら、タスクマネージャーの「パフォーマンス」でGPUを開きます。GPU 0や1という番号より、製品名で合わせるのがおすすめです。GPUが複数あるPCでは、WindowsとLM Studioで並び順が違うこともあります。

タスクマネージャーのGPUグラフは、エンジン名をクリックして別の処理へ切り替えられます。3D以外にCUDAやComputeなどが表示される場合は、そのグラフも見られる状態にします。

Chatで「雨が降る仕組みを三段落で説明してください」と送り、文字が返ってくる間のグラフを眺めます。「プロセス」のGPUエンジン列も見てみてください。LM Studioの画面を描く処理と、モデルを動かす処理が別なら、追いたいのは後者です。

専用・共有GPUメモリは、読み込み前から見ると変化をつかみやすくなります。読み込み後と生成中の値を比べましょう。すでにモデルが載っていれば、質問を送るたびに大きく増えるとは限りません。GPU全体の表示には別アプリも含まれるので、数字の大きさだけでLM Studioの使用分を決めないようにします。

NVIDIAでは、PowerShellの次の表示も併用できます。

nvidia-smi -l 1

1秒ごとに同じGPUの使用量や利用率を確認でき、Ctrl+Cで終了します。取得できない項目のN/Aは、使用量ゼロではありません。

返答に合わせて推論プロセスが動き、GPUメモリの変化も対応していれば、GPUを使っていると考える根拠になります。それでも待ち時間が長いなら、モデルの大きさ、CPU側に残った処理、入力の長さを見直してみましょう。GPUへ載せる量を増やす場合も、モデル本体だけでVRAMを埋めず、会話を処理するための空きを残します。

GPU Offloadを変えたら、モデルを読み込み直す

GPUの活動を確認できないときは、My Modelsのモデル名横の歯車から読み込み設定を開き、GPU Offloadを見ます。これは、モデルの層をGPUへどこまで任せるかの設定です。

GPU Offloadが0なら、VRAMへ収まる少なめの層数から試せます。このときモデル、量子化、コンテキスト長まで一緒に変えると、どの変更が効いたか分かりにくくなります。ほかの条件はそろえ、設定を保存した後にモデルを読み込み直してください。保存した既定値は、すでに動いているモデルへその場で反映されるものではありません。

読み込み直せたら、最初と同じ質問でもう一度GPUを見ます。GPU Offloadの数字は「どこまで載せたいか」という指定です。実際に載った量を保証する表示として扱わず、動作と合わせて判断しましょう。メモリ不足になったら、直前の層数へ戻します。

GPU Offloadを操作できない、GPUが0台と表示される、変更してもCPUの実行環境が残る場合は、次のランタイムも確認してください。

CPU用のランタイムが選ばれていた例

Offloadを増やしても変わらないなら、ランタイムを見ます。これはモデルを動かす処理部分で、NVIDIA GPUが付いているPCでも、CPU用を使っていればCUDAの経路では計算できません。次は、2026年10月17日に残したGemmaの確認例です。

LM Studio 0.4.25+1でGemma 4 E4B QAT Q4_0を使った確認では、CPU llama.cpp 2.59.0の状態でGPU Offloadは0、GPU検出も0台でした。設定のRuntimeで、すでに入っていたCUDA 12 llama.cpp 2.54.0へ切り替えると、HardwareにはRTX 5090が一台表示されました。

この例では、CUDAを選んでから既存モデルのReloadを押しても、動作中の実行ファイルがCPU 2.59.0のままでした。そこで使ったのが、読み込み済みのモデルを外すEjectです。

この確認では、読み込み済みの二つのCPUインスタンスをEjectでメモリから降ろし、Ctrl+Lで同じGGUFを新しく読み込みました。保存したモデルファイルは削除していません。手元で行うときも、対象モデルを使っている別のチャットやAPIの処理を終えてから進めます。My Modelsのファイル削除と取り違えず、読み込み済みモデルのEjectを選んでください。新しく読み込んだ後に見るのは、設定画面で選んだ名前だけでなく、そのモデルが実際に使うランタイムです。

新しい読み込みでは、CUDA 12の2.54.0実行ファイルを確認できました。設定はGPU Offload 42、コンテキスト8192、CPUスレッド12、同時要求4です。次の入力を送りました。

「GPU検証の入力を受け取りました。」の一文だけを、そのまま返してください。

返答は「GPU検証の入力を受け取りました。」でした。

Windows側でも、このCUDAプロセスに専用GPUメモリが割り当てられたことを確認しています。設定欄の選択が変わっても、すでに動いているモデルまで切り替わったとは限らない。この例は、そこを確かめる手掛かりになります。バックエンドと版の両方を変えているため、速度比較の結果には使えません。手元では、GPUとモデルに対応するランタイムを選びましょう。

手元でも同じ状態なら、画面の変化を次の順で追ってみてください。これは上のGemmaの記録を操作順に並べたもので、すべてのモデルで同じ層数になる手順ではありません。

いま見えている状態	次の操作	操作後に見るところ
RuntimeがCPU、HardwareのGPU検出が0台	SettingsのRuntimeで、手元のGPUとモデルに対応するインストール済みランタイムを選ぶ	NVIDIAの例なら、Hardwareに目的のGPU名が出るか
CUDAを選んだが、読み込み済みモデルはCPUのまま	返答を終えて対象をEjectし、同じGGUFを新しく読み込む	新しい実行ランタイムと、同じ質問への返答
返答は出るが、GPUを使ったか分からない	返答中の対象プロセスと同じGPUを観察する	GPUメモリの割り当てや計算の動きが対応するか

読み込み直す前にモデル名・量子化・文脈長を控えると、変更後も同じ条件で比べられます。通常のモデル別設定の入口は公式のPer-model Defaultsでも確認できます。GPU名が出ただけ、Offloadが42になっただけでは、実際の全層配置まで確認できたことにはしません。

読み込めないときは、エラーから調べる

新しい設定でモデルを読み込めない場合は、GPU使用率より先にエラーを確認します。メモリ不足なら最後に動いた配置量や文脈長へ戻し、モデル形式が未対応なら、アプリと実行環境の版がそのモデルに対応するかを配布元の説明と照合します。取得したGGUFの場所はLM Studioへの取り込み手順でも確認できます。

画面で読み込み状態を追いにくいときは、CLIのlms lsで取得済みモデル、lms psで現在読み込まれているモデルを確認できます。ただし、lms psのSizeはファイルの情報で、実行中のVRAM使用量ではありません。lms runtime lsもインストール済みランタイムの一覧なので、それだけで今回の実行先までは分かりません。

CLIのlms loadで試す場合も、My Modelsで保存したモデル別の既定値が使われます。--gpuを省略したから以前の設定が解除されるとは考えず、保存済みの値を確かめます。--gpuにはoff・max・0〜1の比率を指定できますが、変更後は同じ質問で動作を見ます。読み込み前の--estimate-onlyは見積もりなので、実際のGPU観測には使えません。

同じモデルで返答が終わり、GPUの動きも対応していれば、グラフを高くするために再インストールする必要はありません。解決しない場合は、モデル名と量子化、LM Studioとランタイムの版、読み込み設定、表示されたエラーを残します。どこで止まったかが分かれば、次に見直す場所を選びやすくなります。