リクエスト間にローカルモデルサーバーのメモリ使用量が徐々に増加する原因は何ですか？

エヴァ・ウォン

IceWhale author

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

What Causes Local Model Server Memory to Creep Up Between Requests?

ローカルモデルサーバーのメモリ使用量は通常、キャッシュやアロケーターが再利用可能なブロックを保持することで徐々に増加しますが、解放されない参照やネイティブメモリリークによって実際に増え続けることもあります。

ホームサーバーへの各リクエスト後、ダッシュボード上でRAMやVRAMの使用量が増え、元のベースラインまで戻らないことがあります。ランタイムは、KVブロック、プレフィックスエントリ、カーネル、グラフ、ワークスペース、解放済みテンソルブロックを再利用のために保持できます。プロンプト長が変動するとプールが断片化する可能性があり、ログ、セッション、画像バッファー、拡張機能がオブジェクトを無期限に保持することもあります。そのため、これらの仕組みにはそれぞれ異なる証拠と上限が必要です。

キャッシュアロケーターは解放済みブロックを再利用のために予約する

GPUフレームワークは、高コストなデバイス割り当てを避けるため、解放されたブロックをプロセス所有のプールに保持します。アプリケーションのテンソルが消滅していても、ドライバー上ではモデルサーバーが予約済みプールを使用中と報告する場合があります。この違いは、その後の家庭内テストでも確認できます。

アロケーターの分析では、キャッシュされたGPUメモリブロックがCUDAブロックを丸め、分割、結合、キャッシュする仕組みを説明しています。典型的な兆候は、リクエスト後に割り当て済みテンソルメモリが減少する一方、予約済みメモリは高いままで、その後のリクエストが同じメモリを再利用することです。

このプラトーは自動的にメモリリークを意味するわけではありません。プールによって別のサービスが割り当てを行えなくなったり、ウォームアップ後に同じ形状のリクエストを繰り返すたびに増え続けたりする場合に問題となります。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

サービングキャッシュとリクエスト形状は想定ワーキングセットを拡大する

KVキャッシュはアクティブなコンテキストに応じて増加し、プレフィックスキャッシュは再利用可能なプロンプトを保持し、コンパイル済みグラフやカーネルは観測されたバッチ形状をカバーします。新しいコンテキスト長、モダリティ、同時実行プロファイルによって、リクエスト間でエントリが追加されることがあります。この境界は、現実的な運用条件の下で個別に測定する必要があります。

LLMのメモリ断片化に関する研究では、LLMサービングにおけるアクティベーションメモリ領域とKVキャッシュメモリ領域の間の断片化が示されています。この観察結果は、単一のライブリクエストが大きくなくても、総容量が増加する理由を説明します。実際の影響は、複数の要因が限られたコンテキスト容量を奪い合うときに現れます。

キャッシュエントリ数と形状クラスを記録します。ワークロードの分布が安定した後に増加が止まるなら、それは制限されたウォームアップです。総リクエスト数や一意のセッションIDに比例して増加するなら、エビクションが不足している可能性があります。この依存関係は、最終的なインターフェースでも明示したままにする必要があります。

保持されたCPUオブジェクトとネイティブバッファーは実際の増加を引き起こす

リクエスト履歴、ストリーミングキュー、メトリクスラベル、トークナイザー出力、アップロード画像、ページ固定ホストバッファー、拡張機能の割り当てが、完了後も参照されたままになることがあります。GPUスナップショットが安定していても、プロセスのRSSが増え続ける場合があります。そのため、元の証拠と照合して結果を確認する必要があります。

割り当て済みメモリと予約済みメモリに関する実践的な調査では、割り当て済みメモリ、予約済みメモリ、プロセスメモリの各シグナルを分離しています。この階層的な見方により、CPU側の保持問題をGPUアロケーターの挙動と誤診するのを防げます。この違いは、その後の家庭内テストでも確認できます。

障害の境界は、一度増加した後に高い水準で安定する状態です。キャッシュ上限、ガベージコレクション、想定されたプールを考慮した後も、管理された同一リクエストによって保持メモリが増え続け、割り当てスタックから所有者を特定できる場合にのみ、メモリリークと呼びます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

リクエストごとのメモリ保持曲線を作成する

数百回の同一リクエストを再生し、その後、長さとモダリティを混在させながら、GPUの割り当て済みバイト数と予約済みバイト数、KVおよびプレフィックスエントリ、グラフキャッシュ、ページ固定メモリ、プロセスRSS、オブジェクト数、リクエストセッション、ワーカーの再起動、アロケーターのスナップショットを記録します。

リクエスト後のメモリ予約を使用して、意図的なリクエスト後の予約を区別します。モデルと同時実行数を固定したまま、オプションの各キャッシュ、拡張機能、アップロード経路、メトリクスラベルをそれぞれ個別に無効にして再試行します。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

宣言したメモリ予算内でプラトーに達する、制限されたウォームアップは許容します。キャッシュの要素数がメリットなしに増加する場合はエビクションを追加し、断片化が支配的な場合はリクエスト形状を標準化します。保持された割り当てスタックから所有者を特定できた後にのみ、実際のメモリリークを分離します。