ローカルAIランタイムは、リクエスト後もなぜメモリを確保したままにするのか?

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

ローカルAIランタイムは、リクエスト処理後もメモリを確保しておきます。これにより、今後のテンソルがデバイス上のメモリブロックを再利用でき、割り当てや同期のコストを繰り返し支払わずに済みます。

目に見える結果はメモリリークのように見えることがあります。GPUの計算負荷はゼロになり、応答も完了しているのに、プロセスがアクセラレーターのメモリの大部分を占有し続けるためです。その使用量の一部は、稼働中のモデル重みやKV状態である可能性があります。一方で、キャッシュアロケーター、実行コンテキスト、グラフキャプチャ、ライブラリのワークスペース、モデルのキープアライブポリシーに由来する部分もあります。以下では、アクティブな割り当てと再利用可能な予約領域を区別し、メモリが保持され続けることが正常なのか、無駄なのか、それとも実際のリークの兆候なのかを説明します。

デバイスメモリの割り当てはキャッシュする価値があるほど高コスト

リクエストごとに使用されるテンソルは、繰り返し作成および解放されます。すべてのブロックをドライバーに返却すると、同期が発生し、次のリクエストで同じメモリレイアウトを再構築することになるため、処理に時間がかかる可能性があります。

PyTorchのCUDAアロケーターは、キャッシュされたアロケーターブロックと、アクティブに割り当てられたままのテンソルを分けて管理します。

空きブロックをプロセス内に保持すると、リクエストを繰り返す際のレイテンシーを短縮できます。ただし、アロケーターがそれらをドライバーに解放するまで、別のAIサービスはそのメモリを使用できません。

割り当て済みメモリ、予約済みメモリ、デバイスの空きメモリは異なる指標

割り当て済みメモリは、稼働中のテンソルが使用しているメモリです。予約済みメモリはランタイムのアロケーターが管理する領域で、稼働中の割り当てと、現在は使用されていない再利用可能なブロックの両方を含む場合があります。

そのため、テンポラリテンソルを破棄した後でも、ランタイムには予約済みメモリの差分が表示されることがあります。

nvidia-smiなどのデバイスツールが報告するのは、ドライバーから見えるプロセスの使用量であり、フレームワーク内部でどのブロックが論理的に空いているかではありません。

モデルとランタイムの状態は意図的にウォームなまま保持されることがある

プロセスは、モデルの重み、トークナイザーの状態、カーネル、実行グラフ、アクセラレーターのコンテキストをすぐに使える状態で保持することがあります。これらをアンロードすると、次のリクエストがコールドスタートになってしまうためです。

ZimaSpaceによるモデル常駐の解説では、現在ユーザーがトークンを生成していない場合でも、ウォームなサービスがメモリを消費する理由を説明しています。

これは容量とレイテンシーの意図的なトレードオフです。計算の観点ではメモリがアイドル状態でも、すぐに使える状態としては価値があります。

断片化によって予約済みブロックが再利用しにくくなることがある

メモリプール全体では十分な未使用領域があっても、ブロックのサイズが次のリクエストに合わない場合があります。プロンプトの長さ、画像サイズ、バッチ、モデルの切り替えが変動すると、予約領域が断片化することがあります。

GMLakeは、不規則な割り当てサイズによって生じるアロケーターの断片化について研究しています。

この場合、保持されているメモリはアクティブに役立っていない一方で、他のプロセスも利用できません。プロセスを再起動すると、一時的により整理されたメモリレイアウトに戻ることがあります。

使用量が安定するのか増加するのかを測定する

同じ固定リクエストを繰り返し実行し、各処理の完了後に、割り当て済みメモリ、予約済みメモリ、KVキャッシュ、モデル重み、デバイスの空きメモリを記録します。

高い使用量の上限が安定しているなら、通常のキャッシュ動作やキープアライブ動作である可能性が高いです。同一のリクエストを実行するたびに使用量が増え、以前のブロックが再利用されない場合は、リーク、上限のないキャッシュ、保持されたセッション、またはワークロードの変化が疑われます。

キャッシュ解放機能は、どの状態が削除されるのかを確認してから使用してください。未使用のアロケーターブロックを空にしても、稼働中のモデル重みはアンロードされません。また、モデルをアンロードすると応答時間が悪化する可能性があります。

複数のサービスを運用するホームサーバーでは、ランタイムごとにメモリの予算とアイドル時のポリシーを定めましょう。そうすれば、あるサービスの予約領域が別のサービスの起動を気付かないうちに妨げる事態を防げます。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.