ローカルLLMの初回実行が遅いときに確認する五つのこと

ダウンロード率や転送量が表示されているなら、まだモデルファイルを取得中です。転送量が増えていれば完了まで待ちます。止まった場合は接続とエラーメッセージを確認し、アプリの再試行機能を使ってください。この段階の問題は、コンテキスト長や出力設定を変えても解消できません。

取得後、アプリはディスクに保存したモデルをメモリに読み込みます。「モデル読み込み」が長く続く場合は、ファイル読み込みとメモリ使用量を調べてください。進捗表示はアプリによって異なります。詳細ログがなければ、画面に表示された段階とエラーを書き留めれば十分です。準備後に質問を送ってからの待ち時間は、次の節で分けて考えます。

モデルは回答を書く前に、質問と一緒に送られた文書を処理します。この入力処理がプリフィル²です。同じ規程文書について「申請期限と例外を教えて」と質問してください。まず両方を含む抜粋を、次に全文を入力し、最初の回答が出るまでの時間を比べます。

モデルと設定を固定し、それぞれ新しい会話で試します。同じ会話に文書を追加し続けると、前の質問や回答も次の入力に含まれるからです。新しい会話で履歴を減らし、入力キャッシュの状態はアプリで別に確認してください。結果を比較できるよう、抜粋にも回答に必要な根拠をすべて残します。

最初の応答は同じくらいに始まるのに、長い回答だけ完了が遅い場合は、出力の長さを調べます。文書を読む負荷は最初の応答まで、回答を続ける負荷はそこから完了まで、と時間を分けて比較できます。

ディスクリートGPU³を使うPCでは、実行プログラムのメモリ表示やログで、モデルがGPUにどれだけ配置されたか確認します。一部をCPU⁴で処理する構成では、GPUだけで動かす場合と速度が変わることがあります。Macではモデル、OS、ブラウザーが共有メモリを使うため、他のアプリが多いほどモデルに使える余裕が減ります。

まずモデルは変えずに他のアプリを閉じ、短い質問と文書付きの質問を試します。次に小さいモデルへ替え、同じ質問をしてください。条件を一つずつ変えると、メモリの空きとモデルサイズの影響を分けて調べられます。小型モデルでは計算量や実行方式も変わるため、速度だけでなく申請の例外まで正しく回答できたか確認しましょう。

2回目の質問が速くなる理由は複数あります。ファイルがディスクに残っていれば再取得は不要です。アプリがモデルをメモリに保持していれば読み込みを省けます。同じ入力の先頭部分をキャッシュから再利用できる場合は、プリフィルの再計算も減ります。

普段アプリを開いたまま使うならモデルの読み込み後に、必要なときだけ起動するなら再起動後に比べてください。終了後もOSのファイルキャッシュが残る場合があり、入力キャッシュの消去方法もプログラムごとに異なります。開始条件を記録し、同じアプリ、モデル、バージョンで繰り返すと、普段の待ち時間が分かります。

画面上の待ち時間を比べるには、質問を送ってから回答が表示されるまでを測ってください。サーバーログには計算時間だけが記録される場合があるため、待機、読み込み、画面表示を含む利用者側の時間も残すとよいでしょう。

回答が文の途中で終わった場合は、アプリやサーバーログの終了理由を確認します。出力上限に達していたら、同じ質問で上限だけを増やして再実行してください。出力上限は、1回のリクエストで生成できる回答の長さを決める設定です。増やすと長い回答を受け取れますが、完了時間や必要なメモリも変わることがあります。

最後に、申請期限と例外の両方が回答に含まれたか確認します。必要な内容を保った状態で、リクエスト、最初のトークン⁵、完了の時刻と終了理由を記録してください。準備後も最初の回答が遅いなら入力処理とメモリを、すぐ始まるのに完了が遅いなら回答長とデコード⁶速度を比べます。短縮すべき段階が分かれば、機器選びの基準も具体的になります。