Mistral AIのエンジニアチームが、高スループット推論フレームワーク「vLLM」で発生した持続的なメモリリークに関する技術レポートを公開した。この問題は、同社の基盤モデル「Mistral Medium 3.1」のデプロイ中に浮上したものだ。特に、プリフィルとデコードのフェーズを個別のインスタンスで処理する「非集約型アーキテクチャ」での運用が引き金となった。 監視データでは毎分400MBものメモリ増加が確認されていた。しかし、標準的なPythonプロファイリングツールでは、マネージドヒープ内に異常を検出できなかったという。この乖離を受け、チームはLinuxカーネルレベルの調査へと踏み切る。プロセスが占有する実際の物理メモリ量（RSS）をpmapコマンドで詳細に検査した結果、リーク箇所がヒープではなく「無名メモリマッピング」領域にあることを突き止めた。 調査の結果、低レベルなシステムコールによって再割り当てされたメモリが、適切に解放されていなかった実態が浮き彫りになった。最終的な原因は、サーバーノード間でKVキャッシュ（モデル計算用の一次保存領域）を転送する通信ライブラリ、NIXLおよびUCXだ。リアルタイムカーネルトレースツールであるBPFtraceを駆使することで、どのライブラリが不正な挙動をしているかを特定することに成功した。 今回の事例は、ハードウェアアクセラレーションに依存する層が増える中で、ディープラーニングのインフラスタックが極めて複雑化している現状を物語っている。大規模言語モデル (LLM) の推論がより分散化される中、デバッグにはアプリケーションレベルのコードを超え、オペレーティングシステムのメモリ管理という深層にまで踏み込む姿勢が不可欠だ。

Mistral AIのエンジニアチームが、高スループット推論フレームワーク「vLLM」で発生した持続的なメモリリークに関する技術レポートを公開した。この問題は、同社の基盤モデル「Mistral Medium 3.1」のデプロイ中に浮上したものだ。特に、プリフィルとデコードのフェーズを個別のインスタンスで処理する「非集約型アーキテクチャ」での運用が引き金となった。 監視データでは毎分400MBものメモリ増加が確認されていた。しかし、標準的なPythonプロファイリングツールでは、マネージドヒープ内に異常を検出できなかったという。この乖離を受け、チームはLinuxカーネルレベルの調査へと踏み切る。プロセスが占有する実際の物理メモリ量（RSS）をpmapコマンドで詳細に検査した結果、リーク箇所がヒープではなく「無名メモリマッピング」領域にあることを突き止めた。 調査の結果、低レベルなシステムコールによって再割り当てされたメモリが、適切に解放されていなかった実態が浮き彫りになった。最終的な原因は、サーバーノード間でKVキャッシュ（モデル計算用の一次保存領域）を転送する通信ライブラリ、NIXLおよびUCXだ。リアルタイムカーネルトレースツールであるBPFtraceを駆使することで、どのライブラリが不正な挙動をしているかを特定することに成功した。 今回の事例は、ハードウェアアクセラレーションに依存する層が増える中で、ディープラーニングのインフラスタックが極めて複雑化している現状を物語っている。大規模言語モデル (LLM) の推論がより分散化される中、デバッグにはアプリケーションレベルのコードを超え、オペレーティングシステムのメモリ管理という深層にまで踏み込む姿勢が不可欠だ。