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)

核對官方附件可確認，兩種 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 文件仍以舊平台標籤組合最新版下載網址。按文件自動取最新版本的腳本，應先核對實際附件名稱；把網址改成新標籤，只能修正檔名，不能使舊系統取得相容性。[安裝文件](https://docs.vllm.ai/en/latest/getting_started/installation/cpu/)

工程團隊可先在與正式環境相同的映像中驗證安裝，再評估固定既有版本、更新執行環境或自行建置。自行編譯仍須另查工具鏈與硬體條件。截至查核，議題仍開放，未見維護者答覆；後續關鍵是是否補發較低門檻的套件，以及文件能否與發布附件同步。