判断：まずモデル、コンテキスト、メモリ交換、スレッドとコンテナ制限を切り分けてください。 そのうえで、CPUが継続的に処理の上限になっている場合にサーバー更新を検討します。低遅延や高い同時処理が必須なら、CPUサーバーへの変更だけでは解決しないため、GPU推論や外部モデルAPIも選択肢に含めてください。
この記事は、CPU-onlyでOllamaを使い、応答時間の改善方法を探している開発者向けです。
自社のAIアプリやナレッジベースを運用する小規模チームは、アプリと推論サービスの分離を検討できます。
VPSから専用サーバーへの移行を考えている担当者は、監視データでボトルネックを確かめてから判断できます。
最終更新：2026年10月23日。Ollamaの公式ブログ、公式ドキュメント、リリース記録を確認しています。
OllamaのCPU推論が遅いときは、まず症状を分けます
CPU-only推論は、GPU推論と同じ応答速度を前提にできません。一方で、遅さの原因がCPUそのものとは限らず、長すぎる入力、メモリ不足によるディスク交換、コンテナの資源制限が関係している場合があります。
Ollama公式は、2026年6月5日付の0.30更新で、llama.cppを通じた性能改善とGGUF互換性の向上を紹介しています。ただし、これは特定のCPUでの速度保証ではなく、現在の最新版を示す情報でもありません。個別の挙動は公式ブログの更新内容とリリース履歴を照合してください。
まずは次の項目を記録します。測定中にモデル、入力、コンテキストを変えると比較できなくなるため、一度に変更する条件は一つに絞ります。
- [ ] モデル名と量子化の種類
- [ ] 入力プロンプトと会話履歴の長さ
- [ ] 最初のトークンが返るまでの時間と、生成完了までの時間
- [ ] 実行中の使用メモリ、swapの有無、CPU使用状況
- [ ] 単独リクエストか、別の推論やコンテナも動いていたか
Ollamaの生成APIは、応答にモデル読み込み、プロンプト評価、生成処理などの時間情報を含められます。API仕様にある計測項目を利用すれば、モデルの読み込み待ちと、入力処理・生成中の遅さを区別しやすくなります。速度の比較には同じ入力、同じモデル、同じ実行環境を使い、根拠となる測定がない段階ではtokens/sを断定しないでください。
モデルとコンテキストを変えて負荷を確かめます
モデルファイルのサイズは、必要メモリを考える出発点にすぎません。推論中の実行領域やKVキャッシュも必要になるため、ファイルがストレージに収まることと、メモリ上で余裕をもって動くことは同じではありません。
概算の入口は「パラメーター数 × 量子化ビット数 ÷ 8」です。ただし、この値は重みの容量を考えるための目安であり、実際の使用量には量子化形式の付加情報、実行時の領域、コンテキストに応じたキャッシュなどが加わります。GGUFモデルの形式とデータに関する説明を確認し、最終的には実行中のメモリ使用量で判断してください。
まず小さいモデル、または別の量子化を同じプロンプトで試します。次に、要約や分類などのタスクに必要な範囲までコンテキストを縮め、入力処理時間と生成時間を比較します。入力が長くなったときだけ遅くなるなら、サーバーのCPUを増やす前に、履歴を短くする、検索結果を絞るなどの設計変更が有効かもしれません。
メモリ交換とDockerの制限を順に調べます
CPU使用率が高いという理由だけで、コア数の追加が必要とは決められません。メモリ不足によるswap、CPU計算の飽和、コンテナの上限は、それぞれ別の原因です。症状と対処を次のように分けてください。
| 症状 | 最初に確かめること | 次に試す判断 |
|---|---|---|
| モデル読み込み後にメモリが不足し、swapも使われる | 空きメモリとswap、他の常駐サービス | 小さいモデルや短いコンテキストで再測定。継続するなら必要メモリを見直す |
| メモリに余裕があり、単独実行でも生成が遅い | CPU使用状況と同条件での生成時間 | CPU-onlyが要件に合うか検討。低遅延が必須ならGPU推論やAPIを候補にする |
| Docker内だけ遅く、ホスト側には余力がある | CPU quota、cpuset、メモリ上限 | コンテナの上限とOllamaのスレッド設定を見直す |
| モデル読み込み時だけ待たされる | モデルがメモリに保持されるか、他サービスとの競合 | 読み込み時間を生成時間と分けて測る。負荷分離も検討する |
| 複数リクエストで待ち行列ができる | 単独実行との違い、同時稼働サービス | 同時処理の要件を整理し、CPU増強だけで足りるか再評価する |
DockerではCPU quotaやCPUセットなどでコンテナが利用できるCPUを制限できます。Dockerのリソース制約に関する資料を確認し、ホスト全体で見えるCPUと、コンテナ内の実行環境を混同しないようにします。OllamaをDockerで使う場合の構成や起動方法は、利用中の版に対応する公式Docker資料を参照してください。スレッド数や環境変数は、特定環境の投稿例をそのまま標準設定として扱わず、変更前後を同条件で比べます。
サービスを分けてからサーバー更新を判断します
推論以外の処理が同じマシンに集まっていると、CPUやメモリの使い道が競合します。アプリケーション、ベクトル検索、Embedding、モデル推論を一覧にし、それぞれの負荷が集中する時間帯と必要な応答時間を記録してください。モデルの生成が遅いのか、検索や前処理が遅いのかを区別できれば、移行先の選び間違いを減らせます。
- 測定条件を固定します。 モデル、量子化、プロンプト、コンテキストを記録し、変更前の基準にします。
- 単独リクエストを測ります。 読み込み、入力評価、生成を分け、何が待ち時間を占めるか確認します。
- メモリとswapを確認します。 実行中に不足が続くのか、ストレージへの交換が起きているのかを調べます。
- Dockerの割り当てを確認します。 CPU quota、cpuset、メモリ上限を見て、ホスト側の余力と比較します。
- モデルとコンテキストを一つずつ変更します。 同じ条件で再測定し、改善がどの変更によるものか記録します。
- 他サービスと同時実行で再測定します。 単独では問題がなく、同時実行時だけ待つなら、処理の分離や運用時間の調整も検討します。
- 実測と要件で移行先を選びます。 CPUやメモリの不足が継続しているなら専用サーバーを検討し、低遅延や高い同時処理が必須ならGPU推論または外部APIも比較します。
FAQ
OllamaをCPUだけで動かすと、なぜ応答が遅くなりやすいのですか？
CPU-only推論では、GPUを使う場合と同じ応答速度を前提にできません。モデルの大きさや量子化だけでなく、コンテキストの長さ、メモリ交換、スレッド設定も影響します。まず同じモデルと入力で測定し、プロンプト処理と生成のどちらが遅いか分けてください。
小さいモデルに替えるのと、メモリを増やすのはどちらが先ですか？
モデルがメモリに収まらず、システムでswapが発生しているなら、メモリ不足の解消が優先候補です。交換が起きておらず、モデル自体の計算負荷が大きい場合は、小さいモデルや別の量子化を同じ条件で試してください。測定前にメモリだけ増やしても、計算ボトルネックは残ることがあります。
コンテキストを長くすると、OllamaのCPU推論にも影響しますか？
影響する可能性があります。入力の評価時間と、会話履歴などを保持するKVキャッシュの必要量は、モデルや入力条件によって変わります。実際のタスクに必要な範囲までコンテキストを縮め、同じプロンプトで処理時間とメモリ使用量を比べると、影響を切り分けやすくなります。
Docker内でOllamaが遅いとき、どの設定を確認すべきですか？
まずコンテナに設定されたCPU上限やCPUセット、メモリ上限を確認し、ホスト側の利用可能な資源と照らし合わせます。そのうえで、Ollamaが使うスレッド数とコンテナが利用できるCPUが矛盾していないか確認してください。設定名や挙動は利用中のDockerとOllamaのバージョンに合わせ、公式資料で再確認します。
サーバー更新が妥当なのは、モデルやコンテキストを調整してもメモリ不足やCPU飽和、待ち行列が運用上の問題として残る場合です。共有VPSではCPUの割り当てや同居負荷が読みにくく、CPUやメモリを増やしても推論処理以外の競合が残ることがあります。一方、学習や低遅延の高並列推論を求めるなら、GPUを備えないCPUサーバーは代替になりません。
まず測定表にモデル、コンテキスト、メモリ使用量、待ち時間を記録し、SFP Cloudのサーバー構成と提供内容および料金ページで、現在選べる資源と費用を照合してください。専用AMDサーバーは、共有環境のCPU競合を避けて長時間の自前サービスを運用したい場合の候補です。必要なのがGPU推論や高並列・低遅延なら、CPUサーバーへの移行ではなく別方式を選ぶのが適切です。
よくある質問
-
Q
OllamaをCPUだけで動かすと、なぜ応答が遅くなりやすいのですか？
CPU-only推論では、GPUを使う場合と同じ応答速度を前提にできません。モデルの大きさや量子化だけでなく、コンテキストの長さ、メモリ交換、スレッド設定も影響します。まず同じモデルと入力で測定し、プロンプト処理と生成のどちらが遅いか分けてください。
-
Q
小さいモデルに替えるのと、メモリを増やすのはどちらが先ですか？
モデルがメモリに収まらず、システムでswapが発生しているなら、メモリ不足の解消が優先候補です。交換が起きておらず、モデル自体の計算負荷が大きい場合は、小さいモデルや別の量子化を同じ条件で試してください。測定前にメモリだけ増やしても、計算ボトルネックは残ることがあります。
-
Q
コンテキストを長くすると、OllamaのCPU推論にも影響しますか？
影響する可能性があります。入力の評価時間と、会話履歴などを保持するKVキャッシュの必要量は、モデルや入力条件によって変わります。実際のタスクに必要な範囲までコンテキストを縮め、同じプロンプトで処理時間とメモリ使用量を比べると、影響を切り分けやすくなります。
-
Q
Docker内でOllamaが遅いとき、どの設定を確認すべきですか？
まずコンテナに設定されたCPU上限やCPUセット、メモリ上限を確認し、ホスト側の利用可能な資源と照らし合わせます。そのうえで、Ollamaが使うスレッド数とコンテナが利用できるCPUが矛盾していないか確認してください。設定名や挙動は利用中のDockerとOllamaのバージョンに合わせ、公式資料で再確認します。