如果你維護著瞄準 Grace、Grace Hopper 或 Grace Blackwell 機器的 Dockerfile 或 CI,現在可以把 `--index-url https://download.pytorch.org/whl/cu128` 這個 workaround 拿掉了:PyTorch 2.11.0(2026 年 4 月)把啟用了 CUDA 的 GPU wheel 發布到預設 PyPI 索引,針對 aarch64 Linux。在 2.11.0 之前,aarch64 上的 `pip install torch` 會默默拉到純 CPU 的 wheel;傳遞依賴還可能以微妙的方式打破 GPU 偵測。這次 fix 是 packaging 層的,不是 kernel 層的 —— 但對任何在 ARM-host 推論機器上跑 vLLM 的人來說,這一下就把一個長期的「CUDA 為什麼不可用」的 debug 來源給合上了。
機制是 NVIDIA/Astral 的 Wheel Variants 標準,它讓 PyPI 在同一個 package 名下能區分 architecture/accelerator-specific 的構建。PyTorch 的實作對 NCCL 和 cuBLAS 用動態連結,而不是靜態打包 —— 這是 wheel 能小到放上 PyPI 的前提。點名支援的 host 平台:GB200、GB300、GH200(Grace Blackwell 和 Grace Hopper 系統)。vLLM 之前自己背了一些臨時 workaround(`use_existing_torch.py` 把 torch 從安裝檔裡剝掉;pyproject.toml 裡的 `[tool.uv] no-build-isolation-package = ["torch"]`)。這兩個對 custom/nightly torch 構建還是有用,但對 stock 安裝不再是必須的了。
把這件事放到更大的 stack 裡看。Grace Hopper / Grace Blackwell —— 還有現在 NVIDIA 那顆為 agent 做了最佳化、跟 Rubin GPU 配對的 88 核 CPU Vera —— 都是 ARM-host 加 NVIDIA GPU 的拓樸。它們是 Vera Rubin NVL72 參考設計背後的系統,也是 Oracle Cloud、CoreWeave、Lambda、Nebius 這些營運商提供的 GH200/GB200 實例背後的系統。在 2.11 之前,ARM-host 的 AI 開發就意味著每個安裝腳本裡都得有一段知道怎麼換 PyPI 索引的分支。這個分支現在是可選的了。在 PyTorch 之外更廣的層面,Wheel Variants 是那個讓整個 Python GPU 生態可以把「架構 × 加速器」當成一等公民的 packaging 維度,而不是靠ad-hoc 的 index URL。JAX、CuPy、Triton 等等的採用,是更長線要追的故事。
週一上手:在你 Grace/GH200/GB200 的構建裡把 `torch>=2.11.0` 提上來,把 index-url override 拿掉。如果你依賴 torch nightly 或 custom 構建,vLLM 的那些 workaround 留著 —— 它們還能給你點東西。長線的動作:看 Wheel Variants 在整個 Python GPU stack 上的採用。等 JAX/CuPy/Triton 都跑在同一個標準上,你 install 腳本裡 x86-vs-aarch64 的分支就整個消失了。對計劃晚些時候在 Vera Rubin NVL72 等級硬體上部署的 team,這是 developer-experience 這一層管道裡第一塊落到穩定版的拼圖。ARM-host 推論的 kernel 級 perf 故事是分開的、還在成熟 —— 但「裝好就能跑」的問題現在解決了。