vLLM 0.30.0のCPUパッケージ、glibcの最低要件を引き上げ　旧版Linuxでのデプロイに影響

vLLMが9月22日に0.30.0をリリースした翌日、CPUパッケージのインストール互換性に関する問題が報告された。報告に挙げられたUbuntu 22.04とRHEL 9.6の環境は、それぞれglibc 2.35、2.34を使用しており、新版のビルド済みパッケージをインストールできない。既存のLinuxベース環境を使い続ける推論サービスでは、モデルを読み込む前の段階でアップグレードの障害に直面することになる。[問題報告](https://github.com/vllm-project/vllm/issues/58270)

公式の配布ファイルを確認すると、2種類のLinux CPUアーキテクチャ向けパッケージは、いずれもタグが0.29.0のmanylinux_2_34から0.30.0のmanylinux_2_39に変更されている。同じバージョンのCUDA向けとXPU向けの配布ファイルは、それぞれ2_28、2_34のままだ。このため、影響は該当するCPU向け配布ファイルに限定して捉えるべきであり、すべてのバックエンドで最低要件が引き上げられたとは判断できない。[新版の配布ファイル](https://github.com/vllm-project/vllm/releases/expanded_assets/v0.30.0)、[前バージョンの配布ファイル](https://github.com/vllm-project/vllm/releases/expanded_assets/v0.29.0)

Pythonのパッケージング仕様では、manylinuxに続くバージョン番号は対応するglibcの最低バージョンを示す。Python、ABI、プラットフォームには、それぞれ独立したタグがある。そのため、パッケージがPythonの安定ABIを使用していても、システムライブラリの制約を超えて動作できるとは限らない。Pythonの仮想環境を変えるだけでは、このプラットフォーム要件は解消できない。[互換性仕様](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/)

問題報告では、この変更をネイティブのAMX-FP8アテンション対応と関連付けている。関連するプルリクエストは、実際に新しい命令をアセンブルするために、より新しいbinutilsを要求し、ビルドイメージとコンパイラも変更している。これは、新しいハードウェア命令への対応に伴うリリース上のトレードオフを示している。ただし、最低互換バージョンの引き上げが当初から意図されたものだったかどうかは、メンテナーの説明を待つ必要がある。[技術提案](https://github.com/vllm-project/vllm/pull/49410)

デプロイ時には、もう一つ注意すべき点がある。確認時点では、公式のCPU向けドキュメントは依然として旧プラットフォームタグを使って最新版のダウンロードURLを組み立てていた。ドキュメントに従って最新版を自動取得するスクリプトでは、まず実際の配布ファイル名を確認する必要がある。URLを新しいタグに変更しても、修正できるのはファイル名だけであり、古いシステムでの互換性が得られるわけではない。[インストールドキュメント](https://docs.vllm.ai/en/latest/getting_started/installation/cpu/)

開発チームは、まず本番環境と同じイメージでインストールを検証し、そのうえで既存バージョンへの固定、実行環境の更新、ソースからのビルドを検討できる。自前でビルドする場合も、ツールチェーンとハードウェアの要件を別途確認する必要がある。確認時点では、このIssueは未解決のままで、メンテナーからの回答は見当たらない。今後の焦点は、最低要件を抑えたパッケージが追加提供されるか、そしてドキュメントとリリースの配布ファイルの整合性が保たれるかにある。