ローカルAIサービスがアクセラレーターのメモリを奪い合うと何が起こるのか？
ローカルAIサービスがアクセラレータメモリを奪い合うと、各ランタイムが他のモデル、リクエスト、キャッシュ、一時テンソルに利用可能な容量を減らします。
ホームサーバーでは、チャット、埋め込み、画像生成、音声認識、音声合成、画像認識、カメラ分析を、別々のコンテナやプロセスで実行することがあります。ダッシュボード上はアイドル状態に見えても、モデルの重みやアロケータプールは同じGPU、NPU、または共有メモリ型アクセラレータ上に常駐したままです。すると新しいリクエストでは、静的なモデルのフットプリントからは分からなかったプロンプト状態、アクティベーション、出力バッファ用の領域が必要になります。以下では、独立したサービスが、公称アクセラレータ容量をリクエスト受け入れ失敗や不安定なレイテンシへと変えてしまう仕組みを説明します。
各サービスが持ち込むのはモデルの重みだけではない
ロードされたモデルはパラメータメモリを占有しますが、推論の実行中にはランタイムライブラリ、実行コンテキスト、一時ワークスペース、入力バッファ、アクティベーション、リクエスト固有の状態も必要です。
大規模言語モデルのサービングに関する研究では、KVキャッシュメモリが、アクティブなシーケンス数とコンテキスト長に応じて増加するため、同時実行数を制限する主要因として特定されています。アイドル時には収まるモデルでも、長いリクエストが複数同時にアクティブになると失敗する可能性があります。
画像認識、拡散モデル、音声、埋め込みの各サービスは、それぞれ異なる一時メモリの使用パターンを持ちます。平均使用率が低いままでも、ピーク時の割り当てが重なることがあります。
分離されたプロセスはコンテキストとランタイムのオーバーヘッドを重複させる
各AI機能を独自のコンテナで実行すると運用上の分離性は高まりますが、別々のプロセスによって、アクセラレータコンテキスト、ライブラリ、アロケータプール、共有モデルコンポーネントのコピーがそれぞれ作成される場合があります。
マルチモデルシステムでは、マルチモデルサービングが研究されています。これは、モデルごとに単純に1サービスを割り当てる方式では、メモリと計算資源の両方が無駄になるためです。各ランタイムがデバイスを自分だけで使えると想定するよりも、協調的な同居配置のほうが容量を効果的に共有できます。
同じトークナイザー、画像エンコーダー、または言語モデルを使用する2つのサービスが、自動的に1つの物理コピーを共有するわけではありません。共有には、ランタイムの対応と互換性のあるプロセス境界が必要です。
この重複による負担は、数百MB程度のコンテキストやライブラリのオーバーヘッドが、別のモデルを起動できるかどうかを左右する小容量のアクセラレータで特に顕著になります。
予約プールは他のランタイムからメモリを隠すことがある
フレームワークは、後続のリクエストで高コストなデバイス割り当てや同期を避けるため、解放済みのブロックを保持することがあります。サービス上はアクティブに割り当てられたメモリが少なく表示されても、別のプロセスは予約済みの物理領域を利用できません。
統計的多重化などのシステムは、各モデルサーバーが自分の最悪ケースに備えて予約するのではなく、配置とバーストパターンを全体的な問題として扱います。独立したローカルサービスは、オーケストレーターによる制御がない限り、この全体像を把握できません。
これが、アクセラレータの計算使用率が低いのに新しいモデルを受け付けない理由です。容量はアクティブなカーネルではなく、重み、予約済みブロック、または断片化した空き領域によって占有されている可能性があります。
競合はOOMエラーが発生する前にレイテンシを変化させる
ランタイムはメモリ不足に対応するため、バッチサイズを減らしたり、同時実行するシーケンス数を制限したり、追い出した状態を再計算したり、レイヤーをCPU RAMへ移動したり、別のモデルをアンロードしたりすることがあります。
Aegaeonは、需要の変化に対応しながら多数のモデルを協調させるために、トークンレベルのスケジューリングを使用します。同等の協調機能を持たないホームサーバーでは、この不足が、最初のトークンの遅延、停止、モデルの入れ替え、不規則なキュー待ち時間として現れることがよくあります。
ZimaSpaceの家族での同時利用に関する記事では、同じ境界をリクエスト単位で示しています。1人でのテストは高速でも、アクティブな会話同士がメモリとスケジューラーの処理能力を奪い合います。
メモリ不足例外は、最終的な障害形態にすぎません。レイテンシの不安定化やスループットの低下は、多くの場合それより先に現れます。
モデルの追い出しは、即時応答と容量を交換する
非アクティブなモデルをアンロードすると、別のサービス用に大きく連続した領域を解放できます。追い出されたサービスへの次のリクエストでは、重みの再ロードとランタイム状態の再構築が必要になるため、メモリ圧迫がコールドスタートの遅延に変わります。
WarmServeは、頻繁な切り替えによって最初のトークンまでの時間が悪化するため、追い出しを考慮した配置を検討しています。すべてのモデルをウォーム状態に保つほうが高速なのは、アクセラレータにそれらの常駐状態とアクティブ状態を合計して収容できる十分なメモリがある場合に限られます。
ホームサーバーでは、適切なポリシーはワークロードによって異なります。音声操作は常駐させる価値がありますが、たまにしか使わない画像生成なら再ロードを許容できるでしょう。
1つのリソースマネージャーで実際の容量境界を適用する
可能であれば、サービスを1つの推論サーバーで調整するか、サービスごとに明示的なメモリ制限、デバイスの可視性、モデルの常駐ルール、同時実行数の上限、優先度を設定します。
メモリバルーニングに関する近年の研究は、モデルの人気度やリクエスト負荷が変化する際に、静的な割り当てが容量を無駄にする理由を示しています。動的な共有によって使用率を改善できますが、そのためには競合するすべてのワークロードを把握する1つのシステムが必要です。
サービスごとに、重み、予約済みメモリ、アクティブな割り当て、KVキャッシュ、リクエストの同時実行数、コンテキスト長、バッチサイズ、モデル切り替え頻度を測定します。サービスごとの内訳がないデバイス全体の合計値だけでは、衝突の原因を説明できません。
レイテンシに敏感なサービスを優先的に保護し、埋め込みやインデックス作成はメンテナンス時間帯に実行し、一時的なピークに備えて未割り当ての余裕を残します。目的はアイドル時に1バイト残らず埋めることではなく、需要が同時に発生しても想定したサービス構成を安定して維持することです。
よくある質問
GPU使用率が低いのに、なぜアクセラレータメモリは満杯なのですか？
計算使用率は実行中の処理を測定します。一方、モデルの重み、コンテキスト、キャッシュ、予約済みのアロケータブロックは、リクエスト間もメモリを占有することがあります。
コンテナはGPUメモリの制限を自動的に適用できますか？
すべてのランタイムで確実に適用できるわけではありません。デバイスの割り当てやプロセス分離だけでは、複数のフレームワークが内部予約を協調して管理することは保証されません。
共有推論サーバーは常に優れていますか？
いいえ。重複を減らし、スケジューリングを改善できる一方で、サービス分離、フレームワークの互換性、セキュリティ、障害復旧、モデルのサポート状況によっては、別々のランタイムが適している場合もあります。
おすすめ商品
テック＆AIハブ
もっと読む
季節による生活習慣の変化後、スマートホームの予測精度が低下するのはなぜですか？
季節ごとの習慣によって、時間、センサー、在室状況、望ましいアクションの関係が変化するため、以前の習慣で訓練したモデルは陳腐化します。
物体追跡を有効にすると、なぜホームNVRは短時間の出来事を見逃すのですか？
追跡には軌跡を開始して確認するために十分な検出回数が必要なため、物体が短時間で消えると、NVRが有効なイベントを作成する前に見失われることがあります。
モデルのアップグレード後にAI写真ラベルが変わるのはなぜですか？
モデルのアップグレードにより、ラベルの割り当てに使用される表現とランキングが変わるため、同じ写真でも異なる意味的境界や信頼度の境界を越えることがあります。
