モデルキャッシュでホームAIサーバーの応答時間はどう変わる？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does Model Caching Change Home AI Server Response Time? - Zima Store Online

モデルキャッシュは、繰り返し行われるリクエストで、ダウンロード済みファイル、メモリ上に常駐する重み、コンパイル済みカーネル、または以前に処理したプロンプトの状態を再利用できるようにすることで、応答時間を変化させます。

家庭用AIサーバーに、万能なキャッシュが1つだけ存在するわけではありません。モデルのアーティファクトがローカルストレージにすでに存在している場合もあれば、そのファイルページがシステムRAMに残っている場合もあります。重みがアクセラレーターのメモリに読み込まれたままになっていることもあれば、コンパイル済みの実行コードを再利用できる場合もあります。また、繰り返し使用するシステムプロンプトに有効なKV状態が残っていることもあります。それぞれの層が、リクエスト処理経路の異なる部分を短縮します。以下では、これらの層を分けて説明します。これにより、2回目の返信が速かったことを、モデル生成の高速化やハードウェア性能の向上と取り違えずに済みます。

モデルキャッシュはいくつかの独立した層を指す

まず重要なのは、何がキャッシュされているかを区別することです。ダウンロード済みのチェックポイントがあればネットワーク転送を回避でき、ファイルシステムのページキャッシュがあればストレージから一部のブロックを再読み込みせずに済みます。常駐している重みがあればモデルの読み込みを省略でき、コンパイル済みアーティファクトがあれば初期設定の処理を回避できます。プレフィックスキャッシュがあれば、共有されるプロンプトトークンの再計算を避けられます。

多層キャッシュに関する研究では、モデルの起動を、単純なコールド状態とウォーム状態の二択ではなく、ストレージ、ホストメモリ、アクセラレーターのメモリを経由する移動として捉えています。ある層ではウォームでも、別の層ではコールドということがあります。

そのため、「モデルはキャッシュされている」という説明だけでは不十分です。サーバーにファイルがローカル保存されていても、VRAMの確保、重みの読み込み、カーネルのコンパイル、トークン生成前のプロンプト処理が必要になる場合があります。

アーティファクトキャッシュはダウンロードとリポジトリの遅延をなくす

モデルファイルが家庭用サーバーにすでに配置されていれば、起動時の認証、リポジトリのメタデータ確認、リモートからの転送、数GBに及ぶシャードのダウンロードを省略できます。ランタイムはローカルコピーから処理を開始できます。

Netflixは、起動時に大容量の重みをダウンロードすると、実用的なスケジューラーの許容遅延を超えてしまうため、モデルアーティファクトのキャッシュが必要だと説明しています。コンテナを再作成した場合や、クリーンアップ後にモデルを起動する場合、家庭内でも同じ仕組みが重要になります。

ただし、アーティファクトキャッシュがあるからといって、初回トークンが速く生成されるとは限りません。ローカルのチェックポイントでも、低速なディスク上にあったり、多数のシャードに分かれていたり、変換が必要だったり、NASの読み書きと競合したりする可能性があります。

ファイルシステムキャッシュによって2回目の読み込みが大幅に速くなることがある

オペレーティングシステムがモデルファイルを読み込んだ後、クリーンなファイルページが未使用のシステムRAMに残ることがあります。次回の起動では、ストレージデバイスから再び読み込む代わりに、メモリからデータを取得できます。

MAIOは、モデル読み込み時に使用されるファイルシステムのキャッシュポリシーを最適化することで、LLMの起動を改善します。同じNVMeパスから2回起動しても、どのモデルページがキャッシュに残っているかによって読み込み時間が異なる理由を、その結果が示しています。

このキャッシュは解放可能です。バックアップ、ファイル提供、データベース、別のモデルなどによってページが置き換えられることがあるため、昨日は速かった応答が、メモリ不足や再起動の後にストレージ依存の動作へ戻る場合があります。

ページキャッシュの状態を定義せずにベンチマークを行うと、2つの異なるストレージ条件を混同し、ドライブ交換による改善を過大評価する可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

常駐する重みによって最大の再読み込み境界をなくせる

重みをRAM、ユニファイドメモリ、またはVRAMに保持しておけば、ランタイムはプロンプト処理へ直接移行できます。モデルをアンロードすると他のアプリケーション用の容量を確保できますが、次のリクエストでは再び読み込み処理に時間がかかります。

ZimaSpaceのモデル常駐に関するガイドでは、典型的なパターンを説明しています。追い出し後の1回目のリクエストだけが遅く、その後はモデルがウォームな状態にある間、通常どおりの返信が続きます。

常駐は主に、準備状態と初回トークンまでの時間を変化させます。生成が始まった後の出力トークン速度を、必ずしも向上させるわけではありません。

すべてのモデルを常駐させると、別のモデル、KVキャッシュ、または家庭用サーバーのアプリが追い出されるほどのメモリ圧迫を引き起こすこともあります。

コンパイルキャッシュとカーネルキャッシュは初回実行時の処理を省略する

一部のランタイムは、アクティブなモデル、GPUアーキテクチャ、テンソル形状、ランタイム設定に合わせてカーネルを特化したり、実行グラフをキャプチャしたり、コードをコンパイルしたりします。最初の互換性のあるリクエストでは、後続のリクエストで再利用できる処理が実行されることがあります。

実際のコールドスタート分析では、ランタイムコンパイルが、重みの読み込みと初回応答の提供の間に位置する可能性が指摘されています。永続化されたコンパイルキャッシュにより、モデル、ドライバー、ランタイム、またはハードウェアが変更されて無効になるまで、そのコストを後続の起動から取り除けます。

これにより、別のウォーム状態が生まれます。ファイルと重みがすでに存在していても、新しい形状や実行経路を初めて使用すると、依然として遅延スパイクが発生することがあります。

プレフィックスキャッシュはプリフィルを短縮するが、新しいトークンのデコードは短縮しない

同じシステムプロンプト、長い文書のプレフィックス、または共有命令ブロックを繰り返し使用する場合、通常は新しいユーザー入力に到達する前に、同じトークンを再びモデルに処理させる必要があります。プレフィックスキャッシュは、以前のプリフィルで生成された再利用可能なアテンション状態を保存します。

Prompt Cacheの研究では、長いプロンプトモジュールを再利用するリクエストにおいて、初回トークンまでの遅延が短縮されると報告しています。共有されるプレフィックスが長いほど、スキップできるプリフィル処理が増えるため、効果も大きくなります。

任意の新しいプロンプトが速くなるわけではなく、新しく出力するトークンのデコード処理をなくすこともありません。キャッシュヒットは、完全一致または対応しているプレフィックスの再利用、利用可能なキャッシュ容量、ランタイムの追い出しポリシーに左右されます。

コールドパスとウォームパスを別々の応答クラスとして測定する

固定した1つのリクエストを、再起動直後、モデル読み込み直後、すぐに繰り返したとき、長時間アイドル状態にした後、競合するワークロードの実行後にテストします。アーティファクトのダウンロード、ストレージの読み込み、モデルの読み込み、コンパイル、プロンプト評価、初回トークン、出力トークン速度をそれぞれ記録します。

コールドキャッシュの分析では、ウォームキャッシュ時の遅延によって、一部のリクエストがキャッシュミスした際の遅いテールレイテンシが隠れる可能性が指摘されています。家庭用アシスタントは、すぐに繰り返すベンチマークだけでなく、ユーザーが実際に遭遇する条件の組み合わせで評価すべきです。

どの層でキャッシュミスが起きたかを特定できれば、対策も具体的になります。モデルファイルを事前取得する、ページキャッシュ用の余裕を確保する、モデルのキープアライブ時間を延長する、コンパイル済みアーティファクトを永続化する、または安定した共有プロンプトでプレフィックスの再利用を有効にするといった方法です。