症状ごとに最初に確認する手順

ローカルLLMのトラブルの多くは、GPUが使われていないか、モデルがVRAM(GPU専用メモリ)に収まっていないかのどちらかです。下の表で症状に合う手順から始めてください。原因が1つとは限りません。1つ直しても改善しないときは、次の手順に進みます。

症状最初に見る手順
応答が極端に遅い(1秒に数トークン程度)手順1 → 手順3
GPU使用率がほぼ0%のまま手順1 → 手順2
以前は速かったのに急に遅くなった手順4 → 手順1
読み込み中や長い会話の途中で落ちる手順3 → 手順4

手順1: モデルがGPUで動いているかを確認する

最も手軽な確認です。Ollamaでは、モデルを動かしたまま別のターミナルで次を実行します。

ollama ps

PROCESSOR列に100% GPUと出ていれば、モデル全体がGPUに載っています。この場合は手順4へ進みます。100% CPUなら、GPUがまったく使われていません。手順2へ進みます。40%/60% CPU/GPUのように分かれていれば、VRAMに収まらず一部がCPU側に回されています(オフロード)。手順3へ進みます。

LM Studioでは、モデル読み込み時の設定にある「GPU Offload」の値を見ます。これはGPUに載せる層(レイヤー)の数です。最大値より小さいと、残りの層はCPUで計算されます。CPUで計算する層が少しでもあると、全体の速度はそちらに引きずられて大きく落ちます。

手順2: GPUがOSとランタイムから見えているかを確認する

GPUが使われないときは、まずOSからGPUが見えているかを確かめます。NVIDIAならnvidia-smi、AMD(Linux)ならrocm-smiを実行します。GPU名とドライバのバージョンが表示されれば、OSからは認識されています。コマンドがない、またはエラーになる場合は、ドライバの再インストールから始めます。

OSから見えているのにOllamaが使わない場合は、サーバーのログを確認します。起動時に検出したGPUや、使えなかった理由が書かれています。保存場所は、Linuxではjournalctl -u ollama、macOSでは~/.ollama/logs/server.log、Windowsでは%LOCALAPPDATA%\Ollama\server.logです。よくある原因は次のとおりです。ドライバが古い。AMDのGPUがROCmの対応リストに入っていない。Dockerで動かしていて、--gpus=allの指定やNVIDIA Container Toolkitが抜けている。対応GPUは公式ドキュメントに一覧があるので、自分のGPUが含まれるかを確認してください。

LM Studioでは、設定画面のランタイム(実行エンジン)の項目を確認します。CUDA版、Vulkan版などのllama.cppランタイムから、自分のGPUに合うものが選ばれているかを見ます。

Macの場合、Apple Silicon搭載機ではMetal(AppleのGPU向けAPI)が自動で使われます。特別な設定は通常いりません。一方、Intel搭載MacではGPUが使われず、CPUで動く前提になります。

手順3: モデルがVRAMに収まっているかを見積もる

必要なメモリは、おおよそ「モデルファイルのサイズ+KVキャッシュ+作業用の余白」です。KVキャッシュとは、会話の文脈を保持するための領域です。モデルのサイズはollama listやLM Studioのモデル一覧で確認できます。このサイズがVRAM容量に近い、または超えている場合は、まずオフロードを疑います。

見落としやすいのはコンテキスト長です。コンテキスト長とは、一度に扱えるトークン数の上限です。KVキャッシュはこの長さにほぼ比例して増えます。そのため、モデル本体は収まるのに、コンテキスト長を大きくした途端に溢れる、ということが起きます。Ollamaではパラメータnum_ctxや環境変数OLLAMA_CONTEXT_LENGTHで、LM Studioでは読み込み時のContext Lengthで調整できます。値を下げてollama psの表示が100% GPUに変われば、原因はコンテキスト長です。

それでも収まらないときは、量子化の段階を下げます。量子化とは、重みを少ないビット数で表してサイズを縮める手法です。Q8よりQ5、Q5よりQ4と下げるほど小さく速くなります。その代わり、精度は少しずつ落ちます。Ollamaでは、KVキャッシュを量子化してメモリを節約する設定もあります(OLLAMA_FLASH_ATTENTIONとOLLAMA_KV_CACHE_TYPE)。対応状況はバージョンによって変わるため、公式ドキュメントで確認してください。

Windows+NVIDIAの環境では、VRAMが足りなくなるとエラーにならず、ドライバがメインメモリを代わりに使う場合があります。この場合は落ちない代わりに極端に遅くなります。タスクマネージャーで「共有GPUメモリ」の使用量が増えていたら、この状態を疑ってください。

手順4: 同時ロードや他のプロセスとの競合を確認する

以前は速かったのに急に遅くなった場合は、VRAMを他のものが使っていないかを見ます。nvidia-smiを実行すると、VRAMを使っているプロセスが一覧で表示されます。ブラウザ、ゲーム、画像生成ツール、別のLLMアプリが占有していることがよくあります。OllamaとLM Studioを同時に起動していると、それぞれがモデルを抱えたまま競合することもあります。

Ollamaは複数のモデルを同時にメモリに保持することがあり、使い終わったモデルもしばらくは残ります。ollama psに複数のモデルが並んでいたら、ollama stop モデル名で解放します。常に1つだけにしたい場合は、OLLAMA_MAX_LOADED_MODELS=1を設定します。同時リクエスト数を決めるOLLAMA_NUM_PARALLELを大きくすると、その分KVキャッシュも増えます。メモリが厳しい環境では小さい値にしてください。

ここまでで直らない場合の次の手

ログにもエラーがなく、すべてGPUに載っているのに遅い場合は、ハードウェアの限界と考えるのが妥当です。その場合は、パラメータ数の小さいモデルに切り替えるのが最も効果的です。同じ系統のモデルでも、サイズを1段階下げるだけで速度は大きく変わります。用途を絞れるなら、小型モデルでも実用になる場面は多くあります。

長い文書の要約や高度な推論など、どうしても大きなモデルが必要な処理は、クラウドAPIとの併用を検討します。社外に出せないデータや日常的な軽い処理はローカルで、重い処理はクラウドで、と分けるのが現実的です。どちらに回すかは、性能よりも先にデータの扱いの方針で決めてください。

判断の目安として、ollama psが100% GPUになるまで、コンテキスト長と量子化を調整してください。それでも収まらなければ、モデルを小さくするかクラウドを使うかを選ぶ段階です。なお、対応GPUや設定項目の名前は更新で変わることがあります。執筆時点の情報をもとにしているため、作業の前にOllamaの公式ドキュメントやLM Studioの公式ドキュメントで最新の情報を確認してください。