# MacでOllamaが遅い場合：読み込み、コンテキスト、メモリを確認する > Ollamaのランタイムとタイミング情報を使い、コールドロード、コンテキストサイズ、メモリプレッシャーを切り分け、アイドル状態のモデルを削除せずにアンロードします。 Published: 2026-10-22 | Updated: 2026-10-25 Ollamaが遅い原因は、モデルがまだ読み込み中である、プロンプトのコンテキストが大きい、モデルの一部がCPUで実行されている、Macがメモリプレッシャー下にある、などが考えられます。これらのケースでは必要な対処が異なります。ダウンロード済みのモデルを削除するとディスク容量は解放できますが、現在回答を生成中のモデルが自動的に速くなるわけではありません。 ## コールドロードと2回目のリクエストを比較する モデル、プロンプト、設定を同じに保ちます。短いリクエストを実行し、モデルが読み込まれたままの状態で繰り返します。最初のリクエストだけが遅い場合は、読み込みが有用な手がかりになります。両方とも生成が遅い場合は、実行とメモリを調べます。1回の応答をベンチマークとして扱わず、比較を記録します。 Ollamaの[APIドキュメント](https://docs.ollama.com/api/generate)は、完了した応答に`load_duration`、`prompt_eval_duration`、`eval_duration`などの個別のタイミングフィールドを公開しています。これらは読み込み、プロンプトの読み取り、出力の生成を区別します。異なるモデル、コンテキストサイズ、プロンプトのトークン速度を、1つの変更を測定したかのように比較しないでください。 ## 段階ごとにローカルリクエストを1回測定する 通常のポートで動作するローカルサーバーでは、次のリクエストは1つのJSONレスポンスを返すため、タイミングフィールドを確認しやすくなります。`MODEL_NAME`を、`ollama list`の中からすでにインストール済みのローカルモデルに置き換えてください。この比較にはクラウドモデルを使わないでください。このリクエストは推論を実行してリソースを消費しますが、モデルデータは削除しません。 ```bash curl -sS http://localhost:11434/api/generate \ -H 'Content-Type: application/json' \ -d '{"model":"MODEL_NAME","prompt":"Explain what a file cache does in two sentences.","stream":false,"options":{"num_predict":128}}' ``` モデルを読み込んだまま、同じリクエストをもう一度実行します。ストリーミングを無効にすると、ターミナルは完了後にレスポンスを表示するため、このコマンドは返されるタイミングフィールドを確認するためのものであり、最初のトークンを目視で計測するためのものではありません。リクエストが失敗した場合は、そのエラーを保持し、欠落したフィールドをゼロと解釈するのではなく比較を中止してください。 | 返されるフィールド | 使い方 | | --- | --- | | `load_duration` | 初回と再読み込みの時間を比較する | | `prompt_eval_count` と `prompt_eval_duration` | 入力がどれだけ処理され、そのコストがいくらか確認する | | `eval_count` と `eval_duration` | 同じワークロードでの出力生成を比較する | | `total_duration` | リクエスト全体のコストを個別のタイミングと並べて確認する | 文書化されている時間の単位はナノ秒です。秒を求めるには、時間を1,000,000,000で割ります。出力速度については、時間が正であることを前提に、`eval_count`を`eval_duration / 1,000,000,000`で割ります。計算例として、`5,000,000,000`ナノ秒あたり`100`トークンは1秒あたり`20`トークンになりますが、これは特定のMacやモデルで測定された結果ではありません。 出力トークンを総時間で割った値を、純粋な生成速度と呼んではいけません。それには読み込みと入力処理の時間が含まれてしまいます。また、繰り返しのプロンプトがキャッシュされた入力を利用しているかどうかも確認してください。2回目のリクエストが速い場合、モデルがウォームアップされていることとプロンプトが再利用されていることの両方を反映している可能性があります。最も都合のよい数値だけを報告するのではなく、レスポンス全体を保持してください。 ## 実際に何が読み込まれているかを確認する ターミナルで現在の状態を確認します： ``` ollama ps ``` [Ollama FAQ](https://docs.ollama.com/faq)は`PROCESSOR`列について説明しています。GPU、CPU、または分割を示すことがあります。[ハードウェアガイド](https://docs.ollama.com/gpu)はApple GPUでのMetalアクセラレーションを説明しています。ローカルモデルがGPUを使うと期待していた場合、Macの名前から推測するよりも実行結果のほうが有用です。 また、リクエストが確認しているローカルサーバーに送信されていることを確かめてください。フロントエンドが別のホストやクラウドモデルを指している場合があります。その場合、ローカルの`ollama ps`出力はリモートリクエストを表しません。 ## モデルサイズを疑う前にコンテキストを減らす モデルファイルはメモリ要件の一部にすぎません。コンテキストが大きいと追加のメモリが必要になり、同時リクエストは作業を増やします。Ollamaの[コンテキスト長ドキュメント](https://docs.ollama.com/context-length)はハードウェア依存のデフォルトとアプリのコンテキスト制御について説明しています。すべてのインストールが同じデフォルトを持つと想定しないでください。 制御されたテストでは、短いプロンプト、1回のリクエスト、そのテストに必要な情報を依然として含むより小さなコンテキストを使います。後で完全なコーディングタスクにもっと大きなコンテキストが必要な場合は、その意味を保つだけの十分な量に戻します。必要な指示を黙って失ったまま速い回答は、成功した最適化ではありません。 より小さなモデルや量子化を試すのは、別の比較としてのみ行ってください。リソース使用量と回答品質の両方が変わります。代表的な質問をいくつか用意し、速い選択肢が依然として有用かを評価できるようにします。 ## コンテキストの変更を永続化せずに試す 短い診断用プロンプトでは、APIはリクエストごとのコンテキストオプションを受け付けます。前述のリクエストで、`num_predict`と並べて`options`の中に`"num_ctx":4096`を追加し、そのコンテキストをサポートするローカルモデルを使用します。これはテストサイズの一例であり、すべてのモデルやコーディング作業に推奨される設定ではありません。 モデルとプロンプトを変更せずに、`ollama ps`で実行中のモデルを確認し、メモリプレッシャーを比較します。大きな会話の周りでコンテキストを縮小し、それでも回答にすべての指示が含まれると仮定しないでください。まず収まる小さなタスクで比較し、その後、実際のワークロードをその入力に十分なコンテキストでテストしてください。 FAQとコンテキスト長に関する専用ページではデフォルトの説明が異なるため、このガイドは普遍的なデフォルトに依存しません。アプリの設定、フロントエンド、またはリクエストレベルのオプションも実行時の値に影響する可能性があります。インストールされているバージョンが`ollama ps`で`CONTEXT`を報告する場合は、モデルファイルのサイズから推測するのではなく、その値を`PROCESSOR`と並べて記録してください。 メモリの読み取り値が低いことだけが成功条件ではありません。タスクは許容できる回答で完了する必要があり、Macの残りの部分も使用可能なままでなければなりません。コンテキストを小さくすると重要な事実が失われる場合や、変更によって再現性のある違いが生まれない場合は、テストオプションを削除し、以前の動作する設定に戻してください。 ## 生成中はMac全体を監視する **アクティビティモニタ › メモリ**を開き、応答が終わった後だけでなく生成中のメモリプレッシャーを監視します。Apple Siliconは共有システムメモリを使うため、他のアプリも重要です。モデルがディスク上に収まることは、残りのワークロードと並べて余裕を持って収まることを証明しません。 作業を保存し、不要な重いタスクを閉じてから、同じリクエストを繰り返します。プレッシャーが改善し、それに伴って遅さが変わるなら、有用な手がかりがあります。[メモリプレッシャーガイド](https://mole.fit/ja/blog/mac-memory-pressure-explained)は、キャッシュされたすべてのバイトを無駄とみなさずにMacの指標を読む方法を説明しています。 ## アイドル状態のモデルを削除せずにアンロードする まず、そのモデルを使うリクエストがすべて終わるのを待ちます。不要になった読み込み済みモデルを解放するには、`ollama stop`に続けて`ollama ps`からの正確な名前を指定します： ``` ollama stop MODEL_NAME ``` コマンドを実行する前に`MODEL_NAME`を置き換えてください。これはモデルをメモリからアンロードします。ダウンロード済みファイルは削除されず、次のリクエストで再び読み込みコストがかかる場合があります。そのため、リクエストの合間にモデルを繰り返しアンロードすると、体験が遅くなることがあります。 ディスク容量が実際の制約である場合は、[AIモデルクリーンアップガイド](https://mole.fit/ja/blog/how-to-remove-ai-tool-leftovers-mac)で保存済みモデルを別途確認します。ローカルで作成したモデルと、確実に再ダウンロードできないものは保持してください。パフォーマンスについては、一度に1つの変更を比較し、結果を同じワークロードに関連付けます。 ## サーバーログとの不一致を調査する ローカルリクエストが依然として遅い場合や、プロセッサの分割が想定外である場合、Ollamaの[トラブルシューティングガイド](https://docs.ollama.com/troubleshooting)ではMacのサーバーログが`~/.ollama/logs/server.log`にあると説明されています。テスト時刻の前後の部分を読み、読み込みの失敗、メモリ割り当ての問題、または選択された実行バックエンドを探してください。手動で起動したサーバーの場合、対応するメッセージはそのターミナルにあるかもしれません。 Ollamaのバージョン、正確なモデルタグ、コンテキスト、プロセッサの分割、およびタイミングの大部分を占める段階を記録してください。ログの抜粋を共有する前に、プライベートなプロンプトやローカルパスが含まれていないか確認してください。古い最適化の投稿に登場するという理由だけで、いくつかのGPUやサーバーの環境変数を変更しないでください。まずログによって、変更が対処しようとしている不一致を特定する必要があります。 --- Canonical HTML page: https://mole.fit/ja/blog/ollama-slow-on-mac Blog index for agents: https://mole.fit/ja/blog/llms.txt Site index for agents: https://mole.fit/llms.txt