ローカルAIが重い・動かないときの確認ポイント

2026年8月の再現確認：症状・状態・ログを1セットで残す

「動かない」は、アプリが開かない、モデルをロードできない、入力処理が長い、生成途中で止まる、APIにつながらない、GPUが使われないように見える、のどこで起きたかで確認場所が変わります。再インストールの前に、同じ短い条件と発生時刻を残します。

1. モデル名、GGUF/量子化、context、使ったツール、操作時刻、Windows版、アプリ版を記録する。
2. 短い固定promptを新規状態で送り、モデルload、入力処理、最初の文字、generationのどこまで進むか確認する。
3. OllamaはWindowsのログと`ollama ps` / `/api/ps`を保存し、LM StudioはREST loadを使った場合だけ`load_config`と`load_time_seconds`を保存する。
4. モデル、context、GPU設定、driver、接続先を一度に変えず、1項目ずつ再現結果を比較する。

• [公式] Ollama for Windows - Windows要件、localhost:11434、PATH、ログ保存場所、モデル保存場所を確認します。
• [公式] Ollama Troubleshooting - Windowsのserver.log、LLM library、追加ログ、GPU検出の切り分けを確認します。
• [公式] Ollama FAQ - ollama psのPROCESSOR表示とCPU/GPU分割、環境変数の公式説明を確認します。
• [公式] Ollama List running models - 実行中モデルのsize_vram、context_length、quantization_levelなどを確認します。
• [公式] LM Studio REST APIのモデルロード - POST /api/v1/models/loadのcontext_length、eval_batch_size、Flash Attention、KV cache offload、load_config、load_time_secondsを確認します。

30秒症状選択：どの段階で止まったかを先に分ける

「動かない」「遅い」「止まる」は、LM StudioやOllamaのアプリ本体、モデルのロード、入力処理、回答生成、API接続のどこで起きたかによって読むページが変わります。最初に同じ言葉でまとめず、画面やログに出た段階を1つだけ選んでください。

• LM Studioとは - アプリの意味・用途・導入を知りたい場合は定義記事へ進む
• LM StudioのPrompt Processingが遅い - 入力処理と最初の1文字までの遅さを切り分ける
• LM Studioの回答が途中で止まる - 生成開始後の停止と正常終了を分ける
• LM Studioが起動しない - アプリ起動とモデルロードを分けて確認する
• Ollamaが遅い - load、prompt eval、generationとPROCESSORを確認する
• Ollamaの回答が途中で止まる - done_reason、context、ログを記録する
• Ollamaが起動しない・localhost:11434につながらない - tray、CLI、API、portのどこで止まるか確認する
• OllamaでGPUが使われない - ollama psのPROCESSORと公式対応表を読む

LM StudioとOllamaを混ぜない：最初の分岐

LM Studioは画面上のChat、model loader、モデル別設定やnative v1 APIを手がかりにします。Ollamaはtrayで動くWindowsアプリ、CLI、localhost:11434、ollama ps、server.logを手がかりにします。同じPCで両方を起動している場合は、最初のテストでは片方だけに絞ってください。

• LM StudioとOllamaの違い - 比較ページで役割を先に確認する
• ローカルAIをAPIで使う方法 - LM StudioのAPIとOllama localhostの入口を分ける
• Ollamaのローカルモデルとcloudモデルの違い - cloudモデルをPC内推論として扱わない

このクラスターの安全な読み順

最初に親ハブで症状を選び、子記事では短い固定条件で再現します。軽いモデルへ戻す、contextを下げる、設定を一度に変えない、ログや環境情報を保存する、という順序を守ると、再インストールやモデル全削除で証拠を失いにくくなります。

• 1. 速度・RAM・VRAMを測る方法 - ロード、TTFT、生成速度を別の指標として記録する
• 2. コンテキスト長とは - 長い入力とKV cacheの負荷を確認する
• 3. モデルサイズ早見表 - PCに対してモデル規模が大きすぎないか判断する
• 4. メモリ8GB・16GB・32GBの目安 - Windows全体の空きメモリも含めて考える
• 5. GPUオフロードとは - GPU使用率の瞬間値だけで断定しない
• 6. GGUFが読み込めない時 - 形式、保存場所、破損、容量を分ける

local modelでもproviderとtoolを確認する

local modelを選んだことは、web search、MCP、embedding、router fallback、Scheduled Jobs、Magic機能、memoryまでlocalになることを意味しません。provider、tool、保存先、ログ、外部通信を分けて確認します。

• ローカルLLMの安全性とprivacy - 履歴、ログ、外部送信、モデル出所を確認する
• AnythingLLM Model Router - fallbackとrouteごとのproviderを確認する

Colab・T4・GGUFのOOMを別入口で切り分ける

手元Windowsの「LM Studioが遅い」と、Colabの「CUDA out of memory」は同じ症状名でも確認箇所が違います。Colabでは、GPU割り当て、GGUF download、llama.cpp build、model load、context、MTPを段階別に分けます。

• Colab T4でGGUFがOOMになる原因 - nvidia-smiから始める症状別フロー
• Qwen3.6-27Bの実践手順 - baselineを動かしてからMTPを試す

速度と停止を測定値へ分ける

「遅い」と「途中で止まる」は同じ原因とは限りません。ロード、最初のトークン、生成中のtokens/s、ピークRAM/VRAMを測れると、モデルサイズやGPUオフロードをむやみに変えずに済みます。ただし、症状別記事へ進む前の測定は必須ではなく、急いでいる場合は表示された症状から直接確認できます。

• ローカルAIの速度を測る方法 - LM Studio・Ollamaの測定記録テンプレート

GGUFが表示されない・読み込めない場合

LM Studioが重いだけでなく、GGUFが一覧に出ない、ロードできない、保存場所を移動してから見つからない場合は、専用の切り分け記事へ進んでください。

• LM StudioでGGUFが読み込めない時 - 保存場所、形式、破損、メモリ不足を確認する
• GGUFモデルの保存先 - SSD/HDD、外付け、移動の考え方を見る
• Q4_K_M・Q5_K_M・Q8_0の違い - 重いモデルを量子化で切り分ける
• GGUFとは何かを30秒で確認する - 形式、モデル規模、量子化を分ける

まず結論：再インストール前に切り分ける

再インストールは最後の候補です。LM Studioが遅い、止まる、起動しない、モデルが読み込めない時は、まず「LM Studio単体で問題が出るか」を確認します。Hermes Desktop、AnythingLLM、Ollama、PDF/RAGをつないだ状態で調べると、モデル負荷、接続設定、文書処理の問題が混ざります。

1. LM Studio単体で、新規チャットと短い日本語質問を試す。
2. 使ったモデル名、GGUFファイル名、量子化、ファイルサイズをメモする。
3. タスクマネージャーでCPU、メモリ、GPU、専用GPUメモリを分けて見る。
4. 空きストレージと同時起動アプリを確認する。
5. Q8や大きいモデルではなく、7B/8B級のQ4_K_M前後へ戻す。
6. LM Studio単体が安定してから、AnythingLLM、Hermes、Ollama連携へ戻す。

LM Studioが遅い時

遅い時は、LM Studio本体だけでなく、モデルサイズ、量子化、CPU実行、VRAM不足、context長、同時起動アプリ、PDF/RAG負荷を分けて見ます。最初から長文要約やPDFを投げると、モデルが遅いのか、文書処理が重いのか判断しにくくなります。

• 大きいモデル、Q8、13B/14B以上を選んでいないか確認する。
• GPUがある場合も、VRAMに載っているか、CPU側へ戻っていないか確認する。
• 長い会話履歴、長いcontext、長い出力指定を短くする。
• ブラウザ、動画、ゲームランチャー、Officeなどを閉じてメモリを空ける。
• PDF/RAGやAnythingLLMは後回しにし、短文チャットで基準速度を作る。

• ローカルAIのモデルサイズ早見表 - 8GB・16GB・32GBで無理の少ないサイズへ戻す
• Q4/Q5/Q8の違い - Q8が重い時にQ4/Q5へ戻す判断を見る
• GPUオフロードとは - CPU 100%やGPUが使われない時の見方を確認する
• GGUFとは - GGUF、モデルサイズ、量子化の入口へ戻る

LM Studioが途中で止まる時

「止まった」は、モデルロード中に止まる、回答生成中に止まる、極端に遅いだけ、長文入力で止まる、PDF/RAG処理で止まる、のどれかで対処が変わります。まずロード中と回答生成中を分けてください。

保存容量が少ない場合、ダウンロードやモデル更新の途中で失敗したように見えることがあります。モデルファイルは数GB以上になるため、空き容量と保存先も確認してください。

LM Studioが起動しない時

起動しない問題と、起動後にモデルが読み込めない問題は分けて考えます。アプリ自体が開かない場合は、まず公式のSystem RequirementsでOS、CPU、AVX2、RAM、GPU/VRAMの条件を確認してください。

• Windows x64 / ARMなど、自分のOSとCPUに合うインストーラーか確認する。
• x64環境ではAVX2が必要とされるため、古いCPUでは無理に進めない。
• RAMは16GB以上推奨、専用GPUは4GB以上のVRAM推奨という公式目安を確認する。
• 公式サイトから現在のインストーラーを再取得する。
• セキュリティソフトや権限の警告が出ていないか確認し、エラー文をメモする。

OS/CPUが要件外の場合、設定変更や再インストールで解決しないことがあります。その場合は軽い別環境やクラウド/API利用も含めて検討してください。

モデルが読み込めない時

モデルが読み込めない時は、ファイル形式、保存場所、ダウンロード途中、破損、容量不足、モデル名とファイル名の混同を疑います。Discoverから1本だけ再取得し、同じ問題が出るか確認すると切り分けやすいです。

• Discoverタブで見つかるモデルを1本だけダウンロードして試す。
• 外部で入手したGGUFは、import手順やmodels directoryの構造を確認する。
• GGUFファイル名、モデル表示名、API上のmodel IDを混同しない。
• Hugging FaceではModel Card、Files、license、配布元、ファイルサイズを見る。
• 信頼できるModel Cardから小さい候補を1本だけ選び、複数モデルを同時に増やさない。

• GGUFとは - GGUF版、Q4_K_M、ファイル名の見方を確認する
• Hugging FaceでGGUFモデルを探す方法 - Model CardとFilesの確認へ進む
• Hugging Face安全チェックリスト - 配布元・license・安全確認を見る

CPU 100% / GPUが使われない時

CPU推論ではCPU使用率が高くなることがあります。GPUがある場合でも、VRAMに載っていない、offload設定が少ない、対応環境が合っていない、タスクマネージャーの表示グラフが違う、といった理由でGPU使用率が低く見えることがあります。

CPU 100%

CPUだけ、またはCPU側の処理が多い可能性があります。異常と決めつけず、モデルサイズとGPU offloadを確認します。

GPU使用率が低い

3Dグラフだけを見ていると低く見える場合があります。Compute系、専用GPUメモリ、共有GPUメモリを分けて見ます。

VRAM不足

モデルやcontextがVRAMに収まらない場合、CPU側や共有メモリ側に負荷が戻りやすくなります。

• LM StudioのGPUオフロード - CPU 100%・GPU使用率が低い時の確認順を見る
• VRAMとは - 専用GPUメモリとモデルの関係を確認する
• ローカルAI用PCスペック - CPU、GPU、RAM、VRAMの見方へ進む

日本語が不自然な時

日本語が不自然、英語で返る、指示を守らない場合は、LM Studio本体よりモデル選びが原因のことがあります。BaseモデルとInstruct/Chatモデルを分け、日本語対応の説明があるか、Model Cardに用途が書かれているかを確認します。

• 会話用途ならInstructまたはChat向けを優先する。
• 短い日本語質問、要約、言い換えの3種類で確認する。
• 同じGGUF形式でもモデルごとに日本語性能や指示追従は変わる。
• 回答品質を上げるために、いきなりQ8や巨大モデルへ上げない。

• LM Studioで最初に選ぶモデル - Instruct / Chat / Baseと最初の1本を確認する
• Hugging FaceでGGUFモデルを探す方法 - 日本語対応やModel Cardの見方へ進む

AnythingLLM / PDF / RAGで重い時

PDFやRAGは、通常の短文チャットより負荷が増えます。モデル実行、PDFの文字抽出、embedding、検索、回答生成、引用確認が重なるため、最初から大量PDFや機密資料を入れると原因が分かりにくくなります。

1. LM Studio単体で短い日本語質問に答えられるか確認する。
2. 公開できる短いPDFを1つだけ使う。
3. 文字抽出、embedding、検索、回答生成を分けて見る。
4. 大量PDF、長文要約、機密資料は後回しにする。
5. 外部APIや埋め込みモデルを使っていないか通信先を確認する。

• AnythingLLMでPDFを読むには - PDF活用までの最小手順を見る
• AnythingLLMでPDFを読ませても期待通りに答えない理由 - 抽出・検索・回答を切り分ける
• PDF/RAG/引用確認ガイド - 根拠と回答のズレを確認する
• ローカルRAGのプライバシー確認 - 保存先・外部送信・機密資料の扱いを見る

Ollama / Hermes / 外部接続との切り分け

LM Studio単体で遅いなら、まずPCスペック、モデルサイズ、量子化、GPU offloadを見ます。LM Studio単体は動くのにHermes Desktopから遅い、またはつながらない場合は、local server、base URL、model ID、provider設定を分けて確認します。

• 速度・RAM・VRAMを測る方法 - ロード、Prompt Processing、generationを分けて記録する
• Ollamaが起動しない・localhost:11434につながらない - tray、server、port、ログを切り分ける
• AnythingLLMでPDFがうまく動かない - PDF、embedding、検索、回答生成を分ける

• Hermes Desktop × LM Studio - LM Studioをproviderとして使う流れを見る
• Hermes Desktop接続トラブル - base URL、port、model IDを確認する
• Hermes Desktop症状別ハブ - connection refusedやmodel not foundを切り分ける
• LM StudioとOllamaの違い - 2つの役割を混ぜずに比較する

やってはいけないこと

• エラー文を読まずに、すぐ再インストールする。
• 大きいモデルを何本も追加して原因を増やす。
• 遅い原因を探しているのにQ8や巨大モデルへ上げる。
• LM Studio単体を確認せず、いきなりPDFを大量投入する。
• API/Server接続とモデル単体の問題を混ぜる。
• 本物のAPI key、個人情報、機密PDFをスクリーンショットやGitに貼る。
• 公式要件を確認せず、対応外の古いPCで無理に進める。

公式情報を確認したポイント

次に読む記事

• GGUFとは - GGUF、Q4_K_M、モデルファイルの意味を確認する
• Q4/Q5/Q8の違い - 重い時にどこへ戻すかを見る
• ローカルAIのモデルサイズ早見表 - 8GB・16GB・32GBで現実的なモデルを選ぶ
• LM Studioで最初に選ぶモデル - トラブル後に最初の1本へ戻る
• LM StudioのGPUオフロード - CPU 100%やGPUが使われない時に確認する
• AnythingLLMでPDFを読むには - PDF/RAGはモデル単体確認後に進める
• Hermes Desktop × LM Studio - local server連携の役割を確認する

PDF/RAGトラブルへの分岐

通常チャットは動くのにPDFだけ答えない場合は、モデル負荷だけでなくPDF抽出、埋め込み、検索、引用を疑います。

• PDFのOCR・テキスト抽出トラブル - 画像PDFと抽出テキストを確認する
• RAGのチャンク・検索漏れ - 検索された断片と回答の関係を確認する
• 仕事PDFをローカルAIで扱う確認項目 - 外部API、保存先、ログを確認する

• PDF/RAG/引用確認の親ガイド - PDF回答が間違う場所を全体で確認する
• AnythingLLM検証チェックリスト - 公開PDFで根拠確認の手順を作る
• 引用faithfulness確認 - 引用がある回答を元PDFで照合する
• ローカルRAGのプライバシー - 外部API・埋め込み・保存先・ログを確認する

GGUF安全・RAG/NPU系の新しい確認先

モデルを変えた直後に挙動が不自然、PDFだけ重い、知らないGGUFを試すのが不安、という場合は、通常のメモリ/VRAM確認に加えて出所確認とRAG工程の切り分けを行います。