ローカルLLMが遅いと感じたら、まず「最初の回答が出るまで」と「回答が終わるまで」を分けて測りましょう。初回のモデル読み込み、長い資料の入力、回答生成、他の利用者の処理待ちでは、見直す場所が変わります。
いきなり高いPCへ買い替えるより、同じ質問・同じモデルで条件を一つずつ変える方が、次に何を調べるべきか判断しやすくなります。RAGを使っている場合は、資料検索の時間も分けて確認します。
この記事では、既にローカルLLMが動いている環境を対象に、少人数のチームでも始められる確認手順を紹介します。特定PCの実測ベンチマークや、速度改善を保証する設定集ではありません。
「遅い」を二つの時間に分ける
最初に、利用者から見える時間を記録します。
- 表示開始まで：送信してから、最初の回答文字が見えるまで。
- 回答完了まで：送信してから、回答が最後まで表示されるまで。
途中経過を表示するストリーミング対応の画面なら、この二つを別々に測れます。対応していない画面では、完了時にまとめて表示されるため、表示開始時間だけでモデルの動きを判断できません。「一括表示」とメモし、必要なら管理者に内部の処理時間を確認してもらいます。
| 症状 | 最初に確かめたいこと | 次に比べる条件 |
|---|---|---|
| 起動直後の一回だけ待つ | モデル読み込みの影響 | 読み込み後に同じ質問を再送する |
| 長い資料を付けたときだけ待つ | 入力の処理、履歴、RAG検索 | 短い質問と、代表資料を付けた質問 |
| 回答は始まるが終わらない | 回答量、生成中の負荷 | 同じ質問で回答の長さだけ変える |
| 一人なら使えるが重なると待つ | 処理待ち、メモリ、並列実行 | 一件ずつと、二件同時の比較 |
| RAGを使うときだけ待つ | 検索・再ランキング・入力作成 | 各工程の開始・終了記録 |
この表は診断の出発点です。症状が一致しても原因が確定したわけではありません。例えば、最初の表示が遅い場合でも、モデルの読み込みだけでなく、画面側の表示方法や検索処理が影響している可能性があります。
手順1：比較する条件をメモする
比較前に、PC、実行アプリ、モデルの条件をそろえます。最低限、次を残してください。
- OS、CPUまたはチップ名、メモリ、GPUと専用メモリの有無
- 実行アプリ名とバージョン、モデル名・タグ、分かれば量子化方式
- 入力する質問、会話履歴の有無、添付資料や検索結果の量
- 回答の長さの指定、設定を変えた場合はその内容
- 同時実行した処理、電源・省電力の状態
「昨日より速い」だけでは、モデルを変えたのか、短い質問だったのか分かりません。同じPCでも、別の重い作業が動いていれば比較条件が変わります。
ハードウェアの確認方法は、ローカルLLM用PCスペックの目安も参考になります。本稿では購入候補を決める前に、今の環境の症状を記録します。
手順2：短い質問を一件ずつ試す
最初はRAGや添付資料を外し、新しい会話で短い質問を送ります。例えば「次の架空の問い合わせへの返信案を、確認事項を含む短い文章で作ってください」といった、実業務に近く機密を含まない質問です。
モデルが未読込の状態から始めた結果と、読み込み後の結果を分けます。その後、同じ条件で数回試し、最も速い一回だけを採用しないようにします。初期の確認なら、読み込み後に三回程度記録して、ばらつきを見る方法から始められます。これは正式な性能評価に十分な試行数という意味ではありません。
| 記録項目 | 記入内容 |
|---|---|
| ケースID・実施時刻 | 比較できる名前と日時 |
| モデル状態 | 未読込／読込済み／不明 |
| 表示方式 | 逐次表示／一括表示 |
| 表示開始・回答完了 | それぞれ実測秒数。一括表示では表示開始を比較対象外にする |
| 入力・出力の量 | 文字数の目安、取得できる場合はトークン数 |
| 回答品質 | 必須事項を含むか、誤りや確認の手間がないか |
| 周辺条件 | 他の処理、エラー、設定変更 |
空欄は未測定のまま残してください。本記事の表は記録用のひな型で、実際の計測結果ではありません。
手順3：資料と回答の長さを一つずつ変える
短い質問では使えるなら、次は実際の業務に近づけます。
まず、代表的な長さの資料を一つ加えます。モデルや回答の指定は変えず、表示開始と完了を測ります。その後、資料の条件を固定して、回答を短い箇条書きにする場合と、詳しい文章にする場合を比べます。
入力を減らしたときだけ待ち時間が短くなるなら、長い履歴や不要な資料が含まれていないか調べます。ただし、必要な根拠まで削ると回答の正しさを損ないます。入力の量と品質を一緒に確認してください。
回答を短くした場合も同じです。返答が早く終わっても、担当者が何度も聞き直すなら、業務全体の時間は短くなりません。「回答完了まで」に加え、「確認して使える状態にするまで」も見ておきます。
Ollamaの記録を確認できる場合
OllamaのAPIでは、モデル読込、入力評価、出力生成の時間と入出力のトークン数などを確認できます。時間の単位はナノ秒です。生成速度を計算するなら、eval_count ÷ (eval_duration / 1,000,000,000) が出力トークン毎秒になります。ただし、この値だけでは画面表示や検索を含む利用者の待ち時間は分かりません。Ollama Usage
APIを使わない利用者は、画面の時間と条件のメモから始めて構いません。内部の時間を確認する作業は、環境の管理者や構築担当者と進められます。
手順4：同時利用で何が変わるか確認する
一件ずつなら問題ない場合、実際に想定する利用人数に近づけて試します。最初は二件を同じタイミングで送信し、それぞれの開始と完了、エラーの有無を残す方法があります。
「二人が使える」と「二件を並列に処理できる」は同じ意味ではありません。順番待ちでも利用自体はできますが、待ち時間の許容範囲が変わります。
Ollamaの公式FAQは、利用可能メモリに応じた並列処理と待ち行列、並列数とコンテキストに伴うメモリ増加を説明しています。並列数を増やせば必ず速くなるとは考えず、変更前後を測ってください。Ollama FAQ
小規模チームでは、長い要約処理を空いている時間へ回す、対話とまとめ処理を分ける、といった運用も比較候補です。設定変更とPC更新の前に、どの使い方が待ち時間を増やすのかを押さえます。
保存先・起動停止・共用のルールは、ローカルLLMを共用PCで使う前に決めることにまとめています。
RAGだけ遅い場合は検索工程を分ける
RAGでは、質問を受けてから回答するまでに、文書検索、検索結果の並べ直し、モデルに渡す入力の作成などが入る構成があります。使っている構成に合わせて、工程ごとに開始・終了時刻を記録します。
例えば、次のように分けます。
- 質問を受け付ける。
- 関連する資料を検索する。
- 必要な場合は検索結果を並べ直す。
- 根拠となる文章をモデルへ渡す。
- 回答を生成して表示する。
検索だけで待っているのか、検索結果が長すぎてモデル側で待っているのかを分けると、見直す範囲が絞れます。検索結果の件数を減らす場合も、必要な資料が落ちていないか確認します。
RAGを外す比較は、どの工程が影響するか調べるためのものです。根拠を必要とする社内回答を、根拠なし生成へ置き換えてよいという意味ではありません。変更後は、RAGの質問テスト集で回答品質も確かめます。
PCの買い替えを検討する前の判断基準
改善案は、症状の記録とセットで選びます。
| 確認結果 | 次の検討候補 | 同時に確認すること |
|---|---|---|
| 未読込時だけ遅い | 読込・常駐の運用 | 他の業務へのメモリ影響 |
| 不要な履歴・資料が増えるほど待つ | 入力内容と検索結果の整理 | 根拠・必要情報の欠落 |
| 読込後の短い質問でも遅い | モデルの適合性、実行先、PC資源 | 小さいモデルでも業務品質を満たすか |
| 同時に使う場合だけ待つ | 実行時間の分離、待ち行列、構成変更 | 各利用者の待ち時間・失敗 |
| 検索工程で時間がかかる | 検索処理と資料の取り込み状態 | 検索漏れと根拠表示 |
この比較で、必要な品質を維持したまま待ち時間を許容できるなら、現状PCで小さく運用する選択肢があります。逆に、代表的な業務で待ち時間や同時利用の条件を満たせなければ、専用環境やPC更新を検討する材料になります。
「何秒なら合格か」は業務ごとに決めます。対話中に待てる時間と、まとめ処理を後で受け取る場合の許容時間は違います。普遍的な合格秒数を置くより、実際の利用者と「この待ち時間なら使い続けられるか」を確認しましょう。
相談前にまとめたいメモ
ローカルLLMの相談では、「遅いです」だけでも入口になります。次が分かると、検証範囲を整理しやすくなります。
目的：社内手順書を探し、問い合わせ返信案を作りたい。
現状：PC・OS・メモリ・GPU、アプリのバージョン、モデル名。
症状：起動直後だけ／長い資料だけ／いつも／複数人のとき。
記録：同じ質問で測った表示開始・完了時間、回答品質。未測定ならその旨。
利用条件：人数、使う時間帯、待てる時間、外部へ出せない情報。
希望：今のPCで試す範囲を決めたい／専用環境が必要か相談したい。
実データを送る前に、公開情報や架空の内容で症状を説明できると、初期相談を始めやすくなります。試す範囲自体が決まっていない場合は、ローカルLLMの小さな試作範囲の決め方から整理できます。
YOSHIO.devに相談できること
YOSHIO.devでは、ローカルLLM・RAG環境構築を相談できます。手元のPCで何を試すか、どの資料を対象にするか、どの範囲の環境が必要かを整理する入口として利用してください。
「動いているが仕事に使える速度か分からない」という場合は、現在の環境と症状のメモを添えてご相談ください。対応可否・作業範囲・費用は個別に確認します。
よくある質問
ローカルLLMが遅いときは、PCを買い替えるべきですか？
まずは同じモデル・質問で、未読込時と読込後、短文と長文、一件ずつと同時利用を比べてください。必要な品質を維持しても待ち時間を満たせない場合に、PC更新や専用環境を検討します。
最初の回答だけ遅いのはなぜですか？
モデルの読み込みが影響している可能性があります。ただし、画面側の処理や検索も考えられるため、読込状態を記録して同じ質問を繰り返し、必要なら内部の処理時間を確認します。
トークン毎秒が高ければ、業務でも快適ですか？
生成速度だけでは判断できません。送信後の待ち時間、検索、画面表示、回答を確認して使える状態にする手間まで含めて比べます。回答が短くても聞き直しが増えるなら、業務全体では効率が下がる場合があります。
同時利用を増やす設定にすれば解決しますか？
設定だけで解決するとは限りません。並列処理による資源の消費と処理待ちの変化を確認し、一件ずつの利用と同時利用を同じ条件で比べて判断してください。
RAGを使うときだけ遅い場合、モデルを変えればよいですか？
先に文書検索、検索結果の並べ直し、入力作成、回答生成を分けて記録します。遅い工程を絞り、変更後も必要な資料が検索でき、根拠を確認できるか確かめます。
