Ollama がいくつかのモデルをインストールした後、多くの人が最初に抱く疑問は、チャット、コード、翻訳、埋め込みモデルを素早く切り替えるにはどうすればよいかということです。 2 番目の質問は、多くの場合、より現実的です。別のモデルに切り替えた直後に、前の質問がビデオ メモリから消えるのはなぜですか?
結論から始めましょう。Ollama は各モデルを個別に提供する必要はありません。毎日の切り替えには ollama run <模型名> を使用します。 ollama ps を使用して、現在メモリ内にあるモデルを確認します。 ollama stop <模型名> を使用して不要なモデルを解放します。複数のモデルを同時に常駐できるかどうかは、ローカル ディスクにダウンロードされるモデルの数ではなく、使用可能なビデオ メモリまたはメモリにモデルが収まるかどうかによって決まります。
最も一般的に使用される切り替えコマンド
まず、このマシンによってダウンロードされたモデルをリストします。
|
|
チャットまたはコード モデルを開始します。
|
|
別のモデルに変更する必要がある場合は、別の名前を直接実行します。
|
|
または、テストのために埋め込みモデルに切り替えます。
|
|
モデル ファイルはローカルに残り、切り替え時に再ダウンロードされません。モデルを初めてロードするときに、重みをビデオ メモリまたはシステム メモリに入れる必要があります。モデルがまだメモリに保持されている場合は、再度呼び出す方が速くなります。
ollama ps: まずビデオ メモリを誰が占有しているかを確認します。
切り替えがスムーズでない場合は、まず以下を実行してください。
|
|
実行中のモデル、またはメモリ内にまだ常駐しているモデルがリストされます。ここで注目すべき最も興味深い点は、モデル名、設置面積、プロセッサの場所、有効期限です。
中型のグラフィック カードしか持っておらず、2 つの大きなモデルを続けて起動すると、Ollama は 2 番目のモデル用のスペースを空けるために最初のモデルをアンインストールすることがあります。これは通常のリソース スケジューリングであり、モデルが失われるわけではありません。モデルはまだディスク上にあるため、次の呼び出し時に再ロードされます。
自然に期限切れになるのを待ちたくない場合は、事前に停止できます。
|
|
次に、ollama ps を使用して、ビデオ メモリが解放されたことを確認します。
デフォルトの滞留時間: 5 分
Ollama のデフォルトでは、モデルが最後に使用されてから約 5 分間保持されます。この設計は継続的な質問に適しています。最初の読み込みはわずかに遅く、後続のリクエストでは同じモデルを繰り返しビデオ メモリに戻す必要がありません。
ビデオメモリが少ないマシンで複数のモデルを順番に使っていると、5分も経つと実際には「1台を動かし終わったばかりで、まだビデオメモリが戻っていない」という感覚になるかもしれない。現時点での制御方法は3つあります。
方法 1: 1 回の呼び出し後すぐにアンインストールする
API 経由で keep_alive を 0 に設定します。
|
|
これは、モデルが大きく、ビデオ メモリが不足し、各タスクが独立している状況に適しています。
方法 2: モデルを長期間常駐させておく
同じコード モデルを 1 日中使用している場合は、keep_alive を負の数に設定できます。
|
|
こうすることで、手動で ollama stop を実行するか、サービスが再起動されるまで、モデルはメモリ内に残ります。十分なビデオ メモリがない場合は、複数の大規模モデルに対してこれを設定しないでください。
方法 3: デフォルトの常駐時間をグローバルに変更する
OLLAMA_KEEP_ALIVE は Ollama サービスに設定できます。たとえば、すべてのモデルをデフォルトで 30 秒間保持したい場合は、次のようにします。
|
|
Windows では、Ollama はユーザーまたはシステムの環境変数を継承します。セットアップが完了したら、トレイから Ollama を終了し、[スタート] メニューから再起動する必要があります。 Ollama が Linux 上の systemd によって管理されている場合は、サービス環境変数を設定し、サービスを再起動します。
API リクエストの keep_alive はグローバル OLLAMA_KEEP_ALIVE をオーバーライドするため、タスクごとに異なるポリシーを設定する方が適しています。
マルチモデル永続性の鍵: OLLAMA_MAX_LOADED_MODELS
OLLAMA_MAX_LOADED_MODELS は、同時にロードできるモデルの数を制限するために使用されます。たとえば、サービスで最大 1 つのモデルのみを保持したいとします。
|
|
この設定の目的は、モデルを回転させたときに長時間ビデオメモリがいっぱいになることを避けるためですが、「大きなモデルをグラフィックスカードに無理やり収める」方法ではありません。 GPU 推論中、新しいモデルは、利用可能なビデオ メモリに完全に収まる場合にのみ、他のモデルと同時に存在できます。そうしないと、Ollama は古いモデルをアンロードするか、モデルをより遅いメモリ パスに配置します。
単一の 8GB、12GB、または 16GB グラフィックス カードの場合、通常、より安定した戦略は次のとおりです。
| シーン | 提案 |
|---|---|
| 毎日 1 つのチャット モデルのみを使用する | OLLAMA_MAX_LOADED_MODELS=1、5 分以内に保持します |
| 小規模モデルチャット + 埋め込み | まずは両方の実際の占有状況を確認してください。同時に置ける場合は量を増やしてください。 |
| コードモデルと一般モデルを交互に使用 | 二重常駐にこだわらず、業務に応じて切り替えて主体的に行動しましょう ollama stop |
| サーバーのマルチユーザー呼び出し | モデル サイズ、ビデオ メモリ、リクエスト量を組み合わせて、同時実行数とキューを設定します。 |
同時実行性を無視しないでください: コンテキストもメモリを消費します
マルチモデルの問題はモデルの重みだけの問題ではありません。並列リクエストごとに、コンテキストと KV キャッシュのリソース消費量が増加します。
Ollama は、次の 2 つの関連する環境変数も提供します。
|
|
OLLAMA_NUM_PARALLEL は、同じモデルで並列処理できるリクエストの数を制御します。同時実行数が増加すると、コンテキストの長さに応じて必要なリソースも増加します。単一のカードをローカルで使用する場合、多くの場合、デフォルトのままにするか、明示的に 1 に設定すると、トラブルシューティングが容易になります。同時実行性を高める際には、複数のモデルをロードしないでください。
OLLAMA_MAX_QUEUE は、ビジー時にキューに入れることができるリクエストの数です。キューイングを解決するだけであり、ビデオ メモリは増加しません。
Modelfile を使用してさまざまな目的の固定エイリアスを作成する
同じ基本モデルに対してシステム プロンプト ワード、温度、またはコンテキスト ポリシーを常に繰り返し設定する場合は、Modelfile を使用して複数のローカル エイリアスを作成できます。重みのセット全体を複製するのではなく、モデルに基づいてさまざまな構成を定義します。
たとえば、コードに偏った構成ファイル Modelfile.code を作成します。
|
|
モデルのエイリアスを作成します。
|
|
次に、直接実行します。
|
|
書き込み指向のバージョンを作成することもできます。
|
|
|
|
注: qwen3-code と qwen3-write は、同じ基本方向を共有していますが、実行時には異なるモデル構成になります。ビデオ メモリが不足している場合は、同時に無限に常駐できると想定しないでください。
タスクごとにモデルを切り替えるためのスクリプトまたは API を提供します
API では、モデル名自体がルーティング フィールドになります。スクリプトはサービスを再起動する必要はなく、タスクに応じて別の model を渡すだけです。
|
|
一般的な役割分担は次のとおりです。
- 小規模モデル: 分類、書き換え、要約、簡単な質問と回答。
- コード モデル: ウェアハウスを解釈し、スクリプトを生成し、エラーを修正します。
- 埋め込みモデル: ベクトル検索、チャットを担当しません。
- 大規模モデル: 複雑な問題があり、オンデマンドでロードされ、使用後にリリースされます。
コードのタスクルーティングに「どのモデルを選択するか」を記述することで、すべての作業を 1 つの大きなモデルに詰め込むよりも速度とメモリの制御が容易になります。
Windows でよくある落とし穴
環境変数が変更されましたが、有効になりませんでした
Windows で OLLAMA_KEEP_ALIVE、OLLAMA_MAX_LOADED_MODELS、または OLLAMA_MODELS を変更した後は、実行中の Ollama トレイ プログラムを終了して再起動する必要があります。通常、PowerShell を再度開くだけでは十分ではありません。
モデル ファイルがシステム ディスクに集中します
OLLAMA_MODELS を設定すると、モデル ディレクトリを別のディスクに移動できます。次に例を示します。
|
|
Ollama を保存して再起動します。既存のモデルを移行する前に、ディスク容量とディレクトリのアクセス許可を確認してください。ボリュームを変更するためだけに古いディレクトリを削除しないでください。
モデルが削除されたのかと思った
切り替え後、ollama ps を持つ古いモデルは表示されません。これは、単にメモリからアンロードされたことを意味します。ダウンロードしたモデルは ollama ls で引き続き確認できます。ローカル モデル ファイルは、次のコマンドを実行することによってのみ削除されます。
|
|
単一のカードに適したデフォルト戦略のセット
消費者向けグラフィックス カードが 1 つしかなく、複数のモデルを頻繁に切り替える場合は、次の戦略から始めることができます。
|
|
次に、タスクごとに qwen3-code、qwen3-write、または埋め込みモデルを呼び出します。大規模なモデルを実行する必要がある場合は、最初に ollama stop を実行して不要なモデルを停止します。長いコンテキストまたは大きなファイルに遭遇した場合は、同時実行数と常駐数を減らします。
この構成の目的は、グラフィックス カードができるだけ多くのモデルを同時にロードできるようにすることではなく、各スイッチを予測可能にし、グラフィックス メモリが長期間忘れられるモデルでいっぱいにならないようにすることです。
要約する
Ollama マルチモデル スイッチングのコア コマンドは 4 つだけです。
|
|
さまざまな目的に合わせてモデルをより適切に管理したい場合は、Modelfile を使用してエイリアスを作成します。ロードとリリースを制御したい場合は、keep_alive、OLLAMA_KEEP_ALIVE、OLLAMA_MAX_LOADED_MODELS を使用します。まずビデオ メモリに応じて同時居住者数を決定し、次にマルチモデル ルーティングと同時実行性を考慮します。構成はより安定します。
参照: