AI
Ollama 遅い原因と高速化方法｜llama.cppへの移行判断
Ollama 遅い原因を、GPUの利用状況、VRAM、コンテキスト長、モデル保持時間、同時処理から切り分けます。速度と品質を同じ条件で測る方法、設定変更で改善できる範囲、llama.cppへの移行を検討する基準を、非技術部門の責任者向けに解説します。
はじめに
「Ollama 遅い」と感じたときは、モデルの読み込み、入力処理、回答生成にかかった時間を分けて測ります。 内訳が分かれば、設定を変えるべきか、実行基盤を見直すべきかを判断できます。
Ollamaには、外部サービスへデータを送らず、手元の機器で大規模言語モデルを動かせる利点があります。 ただし、回答までの時間や同時利用時の待ち時間が長ければ、実証実験では使えても日常業務には定着しません。 会議中の照会、問い合わせ案の作成、文書確認に支障が出ない範囲まで、待ち時間を短縮します。
社内文書の要約や検索を試験導入している事業責任者は、まずGPUの利用状況とメモリ量を確認します。 次に調べるのは、コンテキスト長と同時利用数です。 調整後も業務要件を満たさなければ、llama.cppと比較します。
Ollama 遅いときは処理時間を分けて測る
測定では、一人で使っているときも遅いのか、最初の一回だけ遅いのかを区別します。 区別しなければ、モデルの再読み込み時間と生成速度を取り違え、効果の薄い機器増強を選ぶおそれがあります。
OllamaのAPIは、処理全体の時間、モデルの読み込み時間、入力トークン数と処理時間、出力トークン数と生成時間を返します。 時間の単位はナノ秒です。 各項目の定義は、Ollama APIの利用状況メトリクス↗で確認できます。
| 見る指標 | 分かること | 事業上の問い |
|---|---|---|
load_duration | モデル読み込みの待ち時間 | 最初の一回だけ遅いのか |
prompt_eval_duration | 入力を読み込む時間 | 長い資料や会話履歴が負荷になっているか |
eval_count ÷ eval_duration | 回答生成のおおよその速度 | 一人の利用でも回答が遅いか |
| 同時利用時の完了時間 | 待ち行列を含む利用者の待ち時間 | 部署で共有しても業務が止まらないか |
生成速度を比較する場合は、eval_count / eval_duration × 10億で1秒当たりの出力トークン数を求めます。
ただし、この数値にはモデルの読み込みや入力処理の待ち時間が含まれません。
利用者が実際に待つ処理全体の時間も、あわせて記録します。
Ollamaが遅くなる原因はGPUだけではない
生成速度が低い場合は、まずGPUの利用状況を調べます。 GPU対応機種でも、すべての処理がGPUに収まるとは限りません。
GPUとCPUへのモデルの配置は、ollama psのPROCESSOR欄で確認できます。
この欄には、モデルがGPUとCPUにどの割合で載っているかが表示されます。
100% GPU、100% CPU、CPUとGPUの混在という表示の読み方は、Ollama公式FAQ↗で確認できます。
モデルと実行時のメモリがVRAMに収まらない場合は、GPU対応機種でもCPU側を使っている可能性があります。
次に、モデルが一度に参照できる情報量を確認します。 この情報量をコンテキスト長と呼びます。 コンテキスト長を長くすると、会話履歴や資料を多く渡せる一方、必要なメモリも増えます。
Ollamaの現行資料では、VRAMが24GiB未満なら4K、24〜48GiBなら32K、48GiB以上なら256Kが既定値です。 Ollamaのコンテキスト長設定↗には、この基準と割り当て値の確認方法が掲載されています。 長い資料を扱うために設定値を増やした結果、メモリが足りなくなることもあります。
間隔を空けた後の初回だけ遅い場合は、モデルの再読み込み時間を確認します。 Ollamaは既定でモデルを5分間メモリに保持するため、保持時間を過ぎた後の実行では再読み込みが発生します。
同時利用時の遅さは、単独利用時とは分けて測ります。 並列数を増やすと必要なメモリも増えるため、利用者数に比例して処理量が増えるとは限りません。 CPU側の処理、長いコンテキスト、モデルの再読み込み、待ち行列を個別に確認します。
Ollama 高速化は設定変更から試す
原因を測定した後は、機器を買い足す前に設定を見直します。 業務に不要な負荷があれば、設定変更だけで待ち時間を短縮できる可能性があります。
ollama psでPROCESSORとCONTEXTを記録します。- 業務で必要な資料量に合わせてコンテキスト長を短くし、回答品質を再評価します。
- モデルがVRAMに収まらない場合は、より小さいモデルや軽い量子化版を同じ業務データで比較します。
- 初回だけ遅い場合は、APIの
keep_aliveでモデル保持時間を変えて測ります。 - 複数人で遅い場合は、並列数を変えながら待ち時間とメモリ使用量を記録します。
設定を変えると、速度と回答品質の両方が変わる場合があります。 コンテキスト長を短くすれば入力処理は軽くなりますが、長い資料の一部を参照できなくなる可能性があります。 モデルを小さくするとVRAMには収まりやすくなるものの、回答品質や指示への追従が変わります。
| 変更案 | 期待できる改善 | 確認項目 |
|---|---|---|
| コンテキスト長を短くする | メモリ使用量と入力処理を抑える | 長い資料の取りこぼし |
| 小さいモデルへ替える | VRAMへ収まりやすくする | 回答品質や指示追従の変化 |
| 軽い量子化版へ替える | モデルのメモリ負荷を下げる | 業務ごとの品質差 |
| モデルを保持する | 初回の読み込み待ちを減らす | 他モデルが使えるメモリの減少 |
| 並列数を増やす | 同時利用の処理量を増やす可能性 | コンテキストを含むメモリ消費の増加 |
設定を採用する条件は、待ち時間の短縮と、業務に必要な回答品質の維持です。 品質を調べる際は、実際の入力から個人情報や機密情報を除いた評価用データを使えます。 要約では必須項目の欠落を、問い合わせ案では事実誤認を確認します。 社内検索では、回答と根拠文書が一致しているかを記録します。 事業責任者は、この記録を使って速度と品質を比較できます。
Ollamaとllama.cppは同じ条件で比較する
Ollamaの設定を変えても要件に届かなければ、同じ条件でllama.cppを測ります。 比較中にモデルや入力条件まで変えると、実行基盤による差とモデルによる差を分けられません。
比較では、同じモデルファイル、量子化、入力長、出力長、機器を使います。 短い質問だけでなく、対象業務に近い長さの入力も用意します。 初回と二回目以降を分けて測定すれば、モデルの読み込み時間を区別できます。 単独利用と想定人数での同時利用も分けると、利用者の待ち時間とサーバーの処理能力を個別に確認できます。
- 機器、OS、各ソフトウェアの版を固定します。
- モデル、量子化、コンテキスト長、入力文、最大出力長をそろえます。
- 初回実行とモデル読み込み後の実行を分けます。
- 各条件を複数回測り、平均値とばらつきを残します。
- 回答の欠落や誤りも同じ基準で採点します。
llama.cppには、入力処理と文章生成を分け、反復回数や出力形式を指定して計測できるllama-benchが付属します。
ただし、この計測にはトークン化と回答候補の選択にかかる時間が含まれません。
業務で発生する総待ち時間は、別に測ります。
llama.cppへの移行は運用コストも含めて判断する
同じ条件でllama.cppが速くても、速度差が小さければ移行理由としては不十分です。 移行すると、導入手順、保守工数、既存ツールとの接続方法も変わります。
移行を検討する条件は、Ollamaの設定を調整しても速度要件を満たさず、担当者が細かな実行条件を継続して管理できることです。 専任の技術担当者が少なく、標準的なAPIと簡単な配布を優先する組織では、Ollamaを継続しやすいでしょう。
| 判断条件 | Ollamaを続けやすい | llama.cppを検討しやすい |
|---|---|---|
| 運用体制 | 専任の技術担当者が少ない | ビルドや設定を管理できる |
| 改善余地 | モデルやコンテキストの調整で要件に届く | 調整後も待ち時間が要件を超える |
| 制御の細かさ | 標準的なAPIと簡単な配布を重視 | GPUへの割り当てやバッチを細かく比較したい |
| 変更コスト | 既存ツールがOllama APIへ接続済み | 接続変更と回帰試験の費用を負担できる |
| 評価対象 | 少人数の対話利用が中心 | 高頻度処理や特定機器への最適化が重要 |
移行を判断する担当者は、1件当たりの処理時間、月間の待ち時間、保守時間、機器費用、回答品質を同じ表で比較します。 速度向上によって減る待ち時間より、移行後に増える保守工数のほうが大きければ、移行による効果は限られます。 定型処理が大量にあり、小さな時間差が月間では大きくなる業務なら、細かな調整に工数をかける余地があります。
まとめ
Ollamaが遅いときは、load_duration、入力処理、回答生成、同時利用時の完了時間を分けて記録します。
この記録を使えば、モデルの再読み込み、GPUとCPUの利用状況、コンテキスト長、待ち行列のうち、どこに時間がかかっているかを確認できます。
設定を変える担当者は、速度と回答品質を同じ業務データで測ります。 設定変更後に要件を満たせばOllamaを継続し、満たさなければ同じモデル、機器、入出力条件でllama.cppを測定します。
移行の判断材料は、速度差、回答品質、保守工数、機器費用です。 事業責任者は、これらを合計した費用と、削減できる待ち時間を比較して決定します。