なぜモデルの削除がホームAIサーバーでレイテンシの急増を引き起こすのか？

モデルの追い出しはレイテンシのスパイクを生みます。前回のリクエストを処理したモデルが高速メモリに常駐していないため、次のリクエストは重みを再ロードし、ランタイム状態を復元し、プロンプトを処理してから通常のトークン生成を開始しなければなりません。モデルが再びウォーム状態になると、その後のリクエストは速く感じられることがあります。

ホームAIアシスタントがアクティブな会話中は迅速に応答するが、アイドル状態の後、モデル切り替え時、またはGPUを他のサービスと共有しているときに一時停止する場合、モデル自体が遅いわけではないかもしれません。重要なのは、時間がモデルのロードに使われているのか、回答の生成に使われているのかという点です。その違いが何を変更すべきかを決定します。

モデルの追い出しは最初のリクエストに影響し、すべてのリクエストに影響するわけではありません

ローカル推論ランタイムは、モデルがアクティブな間、GPUメモリ、統合メモリ、またはシステムRAMにモデルの重みを保持します。追い出しは、ランタイムがその常駐状態の一部または全部を削除するときに発生します。これはアイドルタイムアウト後、別のモデルが同じメモリを必要とするとき、またはサービスが再起動したときに起こることがあります。

ウォーム状態のリクエストは、重みがすでに推論エンジンに利用可能なため、直接プロンプト処理に移行できます。追い出し後のリクエストはより長い経路をたどります：モデルファイルの場所を特定し、重みを読み込み、必要なメモリ階層に配置し、実行パスを初期化してからプロンプトを評価します。

このため、追い出しは通常、トークン毎秒の恒常的な低下ではなく、一時的な停止として現れます。静かな期間の後の最初の応答は遅いですが、同じモデルへの2回目のリクエストは正常です。すべてのリクエストが遅い場合は、生成、CPUオフロード、メモリ帯域幅、キューイング、または熱制限がボトルネックである可能性が高いです。

AIのレイテンシは生成速度だけでなく全体のチェーンです

ユーザーはしばしばすべての待機時間を「推論レイテンシ」と表現しますが、ローカルAIリクエストにはいくつかの段階があります。キューで待つこともあれば、モデルをロードし、入力プロンプトを処理し、出力トークンを生成することもあります。したがって、サーバーは正常な生成速度を報告していても、最初のトークンが表示される前に応答が遅く感じることがあります。

モデルの追い出しは主に最初のトークンまでの時間を増加させます。続くトークンの速度が必ずしも変わるわけではありません。これが、トークン毎秒のベンチマークだけでは問題を見逃す可能性がある理由です：ベンチマークはロードが完了した後に開始されるか、すでにウォーム状態のモデルを再利用している可能性があります。

ランタイムがタイミングフィールドを公開している場合は、感覚に頼るのではなくそれらを比較してください。モデルのロード時間と評価時間を分けて表示することで、遅延がプロンプト処理の前に発生しているのか、処理中に発生しているのかがわかります。最初のリクエストで大きなロード時間があり、次のリクエストで小さい場合は、遅いデコードではなくコールドモデルである強い証拠です。

なぜ家庭用AIサーバーはモデルを追い出すのか

最も単純な原因はアイドルポリシーです。ランタイムは非アクティブなモデルを解放し、メモリをOSや他のアプリケーションに戻します。Ollamaでは、モデルはデフォルトで5分間ロードされたままですが、キープアライブ設定で常駐時間を延長できます。同じアイドル間隔の後に一貫して一時停止が発生する場合は、ハードウェアの故障ではなくポリシーが原因です。

メモリ圧力は予測しにくいパターンを生みます。2つの言語モデル、埋め込みモデル、画像生成モデル、またはビデオサービスがRAMやVRAMを競合することがあります。PlexとローカルAIを1台のサーバーで共有するシステムは特に脆弱で、トランスコードやバックグラウンドジョブがAIサービス自体がアイドル状態でなくてもモデルを追い出すことがあります。

モデルの切り替えも同様の混乱を引き起こすことがあります。大きなモデルが1つだけ快適に収まる場合、モデルBを要求するとモデルAが追い出されることがあります。モデルAに戻ると再度ロードが発生します。サーバーはランダムに遅く見えますが、実際にはモデルの使用順にスパイクが発生しています。

再起動もまた境界です。コンテナの更新、サービスのクラッシュ、ホストの再起動、または手動停止は、キープアライブ値に関係なく常駐状態をクリアします。そのイベント後の最初のリクエストは設計上コールドスタートです。これを追い出しバグとみなすと、通常の動作を改善せずにメモリを消費する過剰な設定につながる可能性があります。

追い出し遅延が蓄積される場所

最初のコストはモデルの移動です。モデルの重みをGPUメモリにロードするには通常、ストレージからCPUメモリに読み込み、その後GPUに転送する必要があります。ファイルが大きいほど、またストレージパスが遅いほど、その待ち時間は長くなります。

データパスはドライブラベルと同じくらい重要です。重みは推論が始まる前に、ストレージ、システムメモリ、PCIeまたは統合メモリパスを横断することがあります。その転送中、限られたメモリ帯域幅がAIのレイテンシを延ばすことがあり、特に他のワークロードが同時に大量のデータを移動している場合に顕著です。

バイトの読み込みは必ずしもコールドパスの終わりではありません。ランタイムによっては、サーバーがGPUコンテキストを作成したり、メモリプールを割り当てたり、カーネルを準備したり、実行グラフをキャプチャしたりすることもあります。初期化されたCUDA状態を保持するシステムは、これらのセットアップ手順をすべて繰り返す必要がないため、完全な再起動よりも速く起動できます。

その後、プロンプトは再評価される必要があります。追い出しは通常モデルのアクティブキャッシュを破棄するため、長いシステムプロンプト、取得されたコンテキスト、またはチャット履歴は最初の新しいトークンが現れる前にプリフィルを通過しなければなりません。その遅延は重みの読み込みではありませんが、ユーザーは両方のコストを1つの静かな停止として体験します。

異なるレイテンシパターンが通常意味すること

タイミングパターンは単なる速度テスト以上の情報を示します。停止がいつ起こるか、どの指標が増加するか、直後の繰り返しリクエストで何が起こるかを比較してください。

最も特徴的な追い出しのサインは最初の行です：高負荷のリクエスト1回の後に同じモデルからの通常の応答が続きます。他の行は、実際の問題がリクエスト経路の別の場所にある場合にモデルをメモリに固定できないことを示します。

追い出しが原因かどうかをテストする方法

1つのモデルと1つの固定プロンプトから始めます。プロンプトを短い間隔を空けて2回送信し、その後サーバーが現在のアンロードポリシーを超えて十分にアイドル状態になった後にテストを繰り返します。プロンプトの長さとモデル設定は変更せず、滞在時間の影響を比較します。

ランタイムが公開している場合は、総応答時間、モデルロード時間、プロンプト評価時間、生成時間を記録します。アイドル期間後にロード時間だけが伸びる場合は追い出しの証拠です。代わりにプロンプト評価が増加する場合は、コンテキスト長やキャッシュ再利用がより有力な原因です。

同時にメモリを監視します。モデルは最初のリクエスト後にRAMまたはVRAMに現れ、ウォームテスト中にそこに留まるべきです。遅いリクエストの前にフットプリントが消える場合は、ランタイムや他のワークロードがそれを解放したことの直接的な確認となります。

最後に、1つの条件を変更します。キープアライブを延長する、競合するGPUサービスを一時停止する、またはテストリクエストの前にモデルをプリロードするなどです。実際の追い出し診断はこの変更に反応すべきです。レイテンシが変わらなければ、モデルがアンロードされたと仮定せずに計算、メモリ、ストレージ、ネットワークのボトルネックに戻ってください。

追い出しスパイクを減らす実用的な設定

インタラクティブなリクエストに応答するモデルは、実際の使用に合わせた期間だけ常駐させます。数分ごとに使われる家庭用アシスタントは、より長いキープアライブ時間が有効かもしれません。1日に1回使われる大きなモデルはそうではないかもしれません。この設定はホットパスを保護するものであり、ダウンロードされたすべてのモデルを永久的なメモリ消費にするものではありません。

実際のメモリの余裕を残します。搭載されているVRAMは、モデルの重み用に利用可能なメモリと同一ではありません。ディスプレイ、ランタイム、コンテキストキャッシュ、その他のアプリケーションも消費するためです。nvidia-smiで使用中および残りのメモリを確認すると、実際の空きVRAMを測定してからモデルサイズと量子化を選択できます。

ホットモデルがかろうじて収まる場合は、常駐作業セットを減らします。より小さい量子化、短いコンテキスト制限、または小さいデフォルトモデルが、ルーチンの追い出しを防ぐ十分な余裕を生み出せます。モデルとコンテキストの選択は、パラメータ数だけでなく、ワークロードのRAMとアクセラレータの要件に従うべきです。

モデルの切り替えを制御します。一般的なリクエストは1つのデフォルトモデルにルーティングし、リロードが正当化されるタスクにはより大きな専門モデルを予約します。複数のモデルを利用可能にする必要がある場合は、同時実行制限を無闇に増やすのではなく、それらの合計の重み、キャッシュ、およびランタイムのオーバーヘッドが収まるかを確認してください。

モデルファイルには高速なローカルストレージを使い、計画的な再起動後に対話型モデルをプリロードします。高速ストレージは初期化やプロンプトの事前入力作業をなくせませんが、転送段階を短縮できます。プリロードはそのコストを制御されたタイミングに移し、最初に質問する人を待たせません。

追い出しが依然として適切なトレードオフである場合

追い出しは自動的に欠陥ではありません。メモリ制約のあるホームサーバーでは、時折のAIワークロードがファイル共有、コンテナ、メディアサービス、または他のモデルに必要なリソースを独占するのを防ぎます。サーバーは即時起動時間を犠牲にして容量と安定性を得ます。

適切な方針はワークロードに従います。頻繁に使われ遅延に敏感なアシスタントは温かく保ち、バッチモデル、画像モデル、滅多に使わない実験はアンロードさせます。2つの対話型モデルが常に互いに追い出し合うなら、耐久性のある選択肢は小さいモデル、より多いメモリ、または別のアクセラレータであり、無限のキープアライブ値ではありません。

実用的な境界は繰り返し頻度です。ユーザーがモデルがアンロードされる前に頻繁に戻るなら、滞在時間を延ばすことで目に見える摩擦を減らせますが、メモリコストは控えめです。リクエストが数時間離れていてマシンに他の仕事がある場合は、1回のコールドスタートを受け入れる方がシステム設計としてはすっきりします。

よくある質問

モデルの追い出しはAIの回答を悪化させますか？

追い出しは準備状態を変えるものであって、保存されたモデルの重みを変えるものではありません。同じモデルを同じプロンプトと設定で再読み込みしても、その能力は低下しません。ただし、破棄された会話やプレフィックスキャッシュは再処理すべきコンテキスト量を変え、別に保存されていなければ欠落したアプリケーション状態が連続性に影響を与えることがあります。

より高速なNVMeドライブで遅延の急増をなくせますか？

特に前回のストレージパスが遅いか混雑していた場合、重みの読み込み段階を短縮できますが、GPUのセットアップ、メモリ割り当て、カーネル準備、プロンプトの事前入力はなくせません。ストレージが測定されたロード時間のごく一部であれば、NVMeのアップグレードで全体の停止時間をなくすことはできません。

すべてのローカルモデルは常に読み込んだままでいるべきですか？

いいえ。すべてのモデルをピン留めすると、メモリ圧迫が発生し、キャッシュや他のサービスの容量が減少します。遅延に敏感な少数のモデルを温かく保ち、時折使うモデルはアンロードさせ、サーバーの実際の負荷下での合計常駐フットプリントを確認してください。

最も簡単なルールは、最初のリクエストと直後の繰り返しを比較することです。大きなロード時間の差は追い出しを示し、両方のリクエストで遅い生成は別の原因を示します。まずその境界を測定し、次に実際に即時性を感じるためにモデルユーザーが必要とする滞在時間、モデルサイズ、共有リソースを調整します。