Mistral AIは2026年4月26日、vLLMを本番運用する中で発生したメモリリークの調査・修正過程を詳細な技術記事として公開した。
問題の核心は、Prefill/Decode分散構成におけるデコード側インスタンスでのみ発生する毎分400MBのメモリ増加だった。このペースで増加が続くと数時間後にはOOM（Out of Memory）状態に陥り、本番サービスが停止する深刻な障害となる。
調査の難しさは、リークの発生場所にあった。Memray・Guppy3・GDB・Valgrindといった一般的なPythonメモリプロファイラやデバッガはいずれも有効な検出ができなかった。Heaptrackによる分析でヒープ自体は安定していることが判明したが、ピークRSS（Resident Set Size）との間に明確な差異が存在した。この差異が、リークがヒープ外の匿名メモリマッピング領域で起きていることを示す手がかりとなった。
最終的にHeaptrackとpmapなどシステムレベルのツールへ移行することで、NIXL経由のKVキャッシュ転送が原因として特定された。NIXLはGPU間の高性能データ転送を担うライブラリであり、vLLMの分散推論構成では不可欠なコンポーネントだが、その深い依存層にリークの原因が潜んでいた。
この知見がvLLMチームのGitHubイシューに報告されると、同様の問題が他の利用者にも再現することが確認された。つまり特定環境固有の問題ではなく、NIXL経由のKVキャッシュ転送を使う分散推論構成全般に潜在するリスクであることが明らかになった。
日本の開発現場への示唆は明確だ。vLLMを本番採用する際、監視対象をPythonヒープだけに限定していると、今回のようなヒープ外リークを見逃す。デコード側インスタンスのRSS推移を継続的に計測し、ヒープ使用量との乖離をアラート条件に組み込む設計が必要になる。また、NIXLやUCXなど高性能通信ライブラリを組み合わせた構成では、依存ライブラリのバージョン管理と既知イシューの追跡が運用品質に直結することを、今回の事例は改めて示している。
