LM StudioのPrompt Processingが遅い時の直し方｜長い入力・履歴・contextを切り分ける

native /api/v1/chatで入力・TTFT・ロードを別々に記録する

LM Studio公式のnative Chat APIでは、入力欄の文字数だけではなく、formatting、tool definitions、過去のmessagesなどを含む input_tokens が返ります。最初のtokenまでの time_to_first_token_seconds と、モデルが未ロードだった場合だけ返る model_load_time_seconds は別の測定項目です。Prompt Processingが遅いかを確認する時は、これらを一つの待ち時間へまとめません。

1. endpoint、stream、model identifier、context、入力履歴、tool/MCPの有無を保存する。
2. 短い新規チャットでChat statsを取り、同じモデルの継続チャットと比較する。
3. cold loadとwarm loadを別の測定として、model_load_time_secondsの有無を記録する。
4. input_tokensとtime_to_first_token_secondsが増えた条件を、文字数だけでなく追加文脈と合わせて読む。

• [公式] LM Studio REST APIのChat - input_tokens、time_to_first_token_seconds、tokens_per_second、model_load_time_secondsを確認します。
• [公式] LM Studio REST API - native v1 REST API、OpenAI互換API、モデルロードとprompt processingの違いを確認します。
• [公式] LM Studio REST APIのStreaming events - model_load、prompt_processing、message、error、chat.endのイベントを確認します。
• [公式] LM Studio REST APIのモデルロード - POST /api/v1/models/loadのcontext_length、eval_batch_size、Flash Attention、KV cache offload、load_config、load_time_secondsを確認します。

SSEイベントとlms log streamを診断材料として使う

native Chat APIのstreamingはSSEで、chat.startからmodel_load、prompt_processing、message、必要ならerrorを経てchat.endへ進みます。prompt_processing.start・progress・endが見えている場合は、画面の表示だけで完全停止と断定せず、イベントの順番と経過時間を保存します。

LM Studio公式CLIのlms log streamでは、model側の送受信、server側のHTTP API・起動・終了・statusを確認できます。--jsonや--statsを使う場合も、現在のCLIで利用できるflagを実行前に確認し、ログへAPI key、個人パス、機密promptを残さないでください。

lms log stream --source model --stats
lms log stream --source server --json

lms log streamは開発者向けの診断手段であり、デスクトップChat画面の全バージョンの内部表示を保証するものではありません。画面、native API、server logを使った条件を混ぜずに保存します。

• [公式] LM Studio REST APIのStreaming events - model_load、prompt_processing、message、error、chat.endのイベントを確認します。
• [公式] LM Studioのlms log stream - model/serverのログ、入力・出力、JSON、statsの確認方法を確認します。

30秒で結論：最初の1文字が遅いなら入力処理を見る

モデルを選んだ後の待ち時間と、送信後に最初の1文字が出るまでの待ち時間は同じではありません。Prompt Processingは入力プロンプトをモデルへ処理する段階で、長い会話履歴、system prompt、tool定義、MCPの説明、PDF由来の文脈が増えるほど、同じモデルでも条件が変わります。

Prompt Processing Progressは何を示すか

LM Studioの公式native v1 REST APIでは、streaming時に model_load.start、model_load.progress、model_load.end、prompt_processing.start、prompt_processing.progress、prompt_processing.end、message.delta、error、chat.end などのイベントが案内されています。Progressが進んでいるなら、画面が完全に固まったと断定せず、どの段階の処理かを記録します。

このSSEイベントは開発者向けAPIの確認材料です。デスクトップアプリの表示名や進み方を、そのまま全バージョンの画面仕様として断定しないでください。公式REST APIを使っていない通常のChat画面では、まず入力長と履歴を短くして再現差を見ます。

• [公式] LM Studio REST API - native v1 REST API、OpenAI互換API、モデルロードとprompt processingの違いを確認します。
• [公式] LM Studio REST APIのStreaming events - model_load、prompt_processing、message、error、chat.endのイベントを確認します。

長い入力・履歴・contextを切り分ける

同じ質問でも、会話履歴が蓄積していれば入力処理の対象が増えます。まず現在のスレッドを保存できる範囲で記録し、新規チャットに短い固定文を送ります。速くなった場合は、モデル本体より入力条件の差を優先して調べます。

1. モデル名、量子化、context、入力文、出力上限をメモする。
2. 新規チャットで短い固定質問を送り、最初の文字までの時間だけを記録する。
3. 同じ質問へ履歴、長いsystem prompt、tool定義を1つずつ戻す。
4. PDFやMCPを使う場合は、モデル単体の短文テストと別の測定として扱う。

system prompt・tool定義・MCPの影響を混ぜない

入力欄に見える質問だけがprompt processingの対象とは限りません。長いsystem prompt、toolのschema、MCPの説明、過去のassistantメッセージ、文書検索で追加された文脈が入力へ含まれる構成では、最初の返答までの条件が変わります。

• まず通常の短文チャットで基準を作り、toolやMCPを有効にした結果と混ぜない。
• 同じtool定義を使う場合でも、定義の数、description、schemaの長さを記録する。
• PDF/RAGは抽出・embedding・検索の待ち時間とPrompt Processingを分けて見る。

モデルサイズ・量子化・GPU offloadは一度に変えない

入力処理が遅いからといって、すぐにモデルサイズや量子化を変えると、原因が入力長なのか実行条件なのか分からなくなります。モデル、量子化、GPU offload、contextの4つは、変更した項目を1つだけにして再測定します。

• モデルサイズ早見表 - 大きすぎるモデルをロード・生成・安定性から見直す
• Q4/Q5/Q8の違い - 量子化を安全ランクと混同せず比較する
• LM StudioのGPUオフロード - CPU/GPU/VRAMの観測を合わせる

短い基準を作る具体的な順番

1. 現在ロードしているモデル、GGUF、量子化、context、GPU設定を記録する。
2. 新規チャットで短い固定プロンプトを使い、最初の文字までと生成中を別々に見る。
3. 同じモデルで履歴を消した場合と、履歴を戻した場合を比べる。
4. contextを小さい値へ変更した場合は、入力長とピークRAM/VRAMも記録する。
5. 最後にモデルサイズ、量子化、GPU offloadを1項目ずつ変更する。

短いテストで速くても、長文やtool使用時の安定性を保証するわけではありません。用途が長文なら、短文の基準と別に長文条件を測り、結果を混ぜないでください。

lms load --estimate-onlyを使う時

LM Studio公式CLIのlms loadには、context length、GPU offload、TTLの指定と、実際にロードせずメモリを見積もる --estimate-only があります。ロードに失敗するモデルを何度も読み込む前に、モデルキーと条件を記録して見積もりを確認する入口になります。

lms ls
lms load --estimate-only <model_key>
lms load <model_key> --context-length 4096 --gpu max

このコマンドの結果は、手元のモデル、GPU、context、runtimeの条件に対する見積もりです。実際のPrompt Processing時間や生成速度を測った値ではありません。利用できるflagや表示は、実行前に公式CLI Docsで確認してください。

• [公式] LM Studioのlms load - context length、GPU offload、lms load --estimate-onlyなどを確認します。

それでも遅い場合に保存する情報

• Windowsの版、CPU、RAM、GPU名、専用VRAM、空きストレージ。
• LM Studioのバージョン、runtime、モデル名、GGUFファイル名、量子化、context。
• 新規チャットか継続チャットか、入力文字数、履歴、system prompt、tool/MCPの有無。
• model load、prompt processing、最初の文字、generationのどこで何分待ったか。
• 変更前後の設定と、公式changelogで確認したバージョン・変更点。

ログや画面を共有する場合は、ユーザー名、個人パス、API key、機密prompt、仕事の文書を伏せてください。

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

やってはいけないこと

• Prompt Processingが遅いだけで、アプリを強制終了して状態を記録しない。
• 履歴、system prompt、tool、context、モデルを一度に全部変える。
• 実測していないtokens/sや「何秒なら正常」という値を作る。
• GPU使用率の低さだけで、GPUが使われていないと断定する。
• 設定やモデルフォルダを最初に削除して、再現条件を失う。

次に読む順番

• LM Studio症状別トラブルシュート - 別の段階で止まる場合に戻る
• ローカルAIの速度を測る方法 - ロード、TTFT、generationを測定項目へ分ける
• コンテキスト長とは - 長文・PDF・KV cacheの負荷を整理する
• メモリ8GB・16GB・32GBの目安 - RAMとWindows全体の余白を確認する
• LM StudioでGGUFが読み込めない時 - ロード段階の問題へ戻る