vLLM 和 PyTorch 携手解决了一个长期困扰 aarch64 架构的安装难题——从 PyTorch 2.11.0 开始，在 GB200 / GB300 / GH200 上执行 pip install torch 就能正常工作。具体变化是：PyTorch 2.11.0 现在已向默认的 PyPI 索引发布支持 CUDA 的 aarch64 wheel。不再需要自定义的 --index-url 标志，也不会再出现传递依赖偷偷将你精心安装的 GPU 版替换为 CPU wheel 的情况。使用 Grace Hopper 和 Grace Blackwell 系统的新用户，只需遵循标准安装说明，vLLM 首次即可正常运行。在我们的最新博客中，@KaichaoYou（@inferact 联合创始人，@vllm_project 首席维护者）分享了完整的故事：

• 2024 年黑客马拉松上，在 GH200 上运行 vLLM 时遇到的 bug
• vLLM 内部的工作区变通方案（use_existing_torch.py 和 [tool.uv] build-isolation passthrough）
• 从 GitHub issue 到 PyTorch 基金会 TAC 讨论
• 由 NVIDIA 和 PyTorch 核心团队推动，在 PyTorch 2.11.0 中落地的修复

这是 PyTorch 基金会框架下跨项目协作的绝佳范例——同时也提醒我们，平淡无奇的基础设施优化能带来复利效应。

阅读完整故事：https://pytorch.org/blog/vllm-and-pytorch-work-together-to-improve-the-developer-experience-on-aarch64/

… : Piotr Bialecki (@nvidia) — @ptrblck_de, Alban Desmaison (@Meta), Andrey Talman (@Meta), Nikita Shulga (@Meta)

vLLM 与 PyTorch 携手提升 aarch64 上的开发者体验 – PyTorch

来源：https://pytorch.org/blog/vllm-and-pytorch-work-together-to-improve-the-developer-experience-on-aarch64/

特色项目

• vLLM 标志 (https://pytorch.org/projects/vllm/)

简而言之：PyTorch 2.11 允许直接在 PyPI 上为 aarch64 Linux 安装支持 CUDA 的 PyTorch wheel，无需再使用自定义包索引和变通方案，从而简化了在 NVIDIA GH200、GB200 和 GB300 等系统上的部署。在这篇文章中，Kaichao You (Inferact) 解释了这一打包变更如何改善 vLLM 用户的安装体验，并强调了 vLLM 与 PyTorch 通过 PyTorch 基金会合作将修复方案投入生产的过程。

这一修复历时两年，终于让 GB200 / GB300 / GH200 上的使用变得轻松许多。

我在一次黑客马拉松中首次遇到这个问题

这个故事实际上始于 2024 年 10 月。我当时在 CUDA MODE（现 GPU MODE）线下黑客马拉松上，试图在 GH200 机器上运行 vLLM。这本该是五分钟就能搞定的事，结果我却花了令人沮丧的大半天时间盯着 pip install。表面上看一切正常——wheel 解析完成，依赖满足，安装没有报错——但在运行时，torch.cuda.is_available() 却顽固地返回 False。

经过深入调查，原因简单得几乎可笑：在 aarch64 Linux 上，pip install torch 从 PyPI 拉取的是仅 CPU 的 wheel。默认的 PyPI 索引上根本没有发布 aarch64 的 GPU wheel。要获得支持 CUDA 的构建版本，你必须明确指定 PyTorch 的下载索引：

pip install torch --index-url https://download.pytorch.org/whl/cu128

仅此而已，虽然有点烦人，但还算可以接受。真正的问题在于这与传递依赖的交互方式。PyPI 不允许某个包为其依赖项指定自定义索引。因此，如果 vLLM 依赖树中的任何包声明了 torch== 的某个版本，且该版本不匹配，pip 就会愉快地回到默认的 PyPI 索引，找到 CPU wheel，静默卸载我刚刚精心安装的 GPU 构建版本，然后用 CPU 版取而代之。你可能会觉得一切正常，直到你的模型找不到 GPU。

对于任何试图在 GH200（以及后来的 GB200 / GB300）上运行 vLLM 的人来说，这原本的一行安装命令，变成了一堆 --index-url 标志、固定版本和安装后健全性检查的迷宫。

在此期间 vLLM 采取的变通方案

在等待上游提供正确修复的同时，vLLM 不得不自带变通方案，以免 aarch64 用户陷入困境。第一个方案是 use_existing_torch.py (https://github.com/vllm-project/vllm/blob/main/use_existing_torch.py)，于 2024 年 9 月在 vllm-project/vllm#8713 (https://github.com/vllm-project/vllm/pull/8713) 中加入，PR 标题明确表示为 “支持现有 PyTorch（用于 GH200、aarch64、nightly）”。它的流程正如其名：你先自己安装正确的 torch 构建版本（来自 PyTorch 索引、nightly 版或自定义构建），然后运行 python use_existing_torch.py，它会从 vLLM 的 requirements/*.txt、requirements/*.in 和 pyproject.toml 中移除所有 torch/torchvision/torchaudio 的依赖。去掉这些固定版本后，后续的 vLLM 安装就不会触发 pip“好心”地回到默认 PyPI 索引，静默地将你的 CUDA 版 torch 替换为 CPU wheel。这个方法虽然丑陋——我们在安装时实际上是在重写自己的依赖文件——但它让 GH200 用户在一年多的时间里得以解困。

后来，随着 uv 的成熟，我们得到了一种更干净的方案。在 vllm-project/vllm#24303 (https://github.com/vllm-project/vllm/pull/24303) 中，我们在 pyproject.toml 中添加了以下内容：

[tool.uv]
no-build-isolation-package = ["torch"]

这告诉 uv 不要在隔离环境中构建 torch——实际上，uv 会重用当前环境中已经存在的 torch，而不是尝试解析并重新安装自己的副本。结合先从正确的索引安装 torch 的做法，这为我们提供了一条比重写文件更人性化的路径：只需在 pyproject.toml 中添加一行配置，uv pip install vllm（或 uv sync）就会在 aarch64 上尊重预先安装好的 CUDA 版 torch。

vLLM 的变通方案是社区在包装标准存在缺口时的一种临时措施。而 Wheel 变体 (https://developer.nvidia.com/blog/streamline-cuda-accelerated-python-install-and-packaging-workflows-with-wheel-variants/) 是 NVIDIA 和 Astral 将这些临时措施正式化，使其不再必要。

从黑客马拉松的头痛到 TAC 的议程项目

时间来到 2025 年。vLLM 加入了 PyTorch 基金会，我成为其技术咨询委员会 (TAC) 的代表之一。aarch64 wheel 的问题不断被提及——既来自我自己的工作，也来自其他使用 Grace Hopper 和 Grace Blackwell 系统的 vLLM 用户。2025 年 8 月，我在 pytorch/pytorch#160162 (https://github.com/pytorch/pytorch/issues/160162) 中正式提交了这个问题。今年早些时候，在 2026 年 1 月的一次 TAC 会议上，我代表 vLLM 用户直接提出了这个问题。要求很明确：将 aarch64 GPU wheel 发布到默认的 PyPI 索引，这样 pip install torch 在 GB200 级别的机器上就能像在 x86 上一样“直接工作”。这些 wheel 会动态链接到 NCCL 和 cuBLAS 等库——这与 x86 上已经采用的方法相同——所以不会膨胀到很大。过大的二进制文件既让用户难以下载，也让 PyPI 项目维护者承担高昂的托管成本，因此 PyPI 维护者严格限制并强烈不鼓励这种做法。NVIDIA 工程团队要求将 CUDA SBSA wheel 发布到 PyPI，然后推动了与其链接的小型 wheel 方案。

这正是 PyTorch 基金会有能力协调的那种跨项目、基础设施层面的问题。vLLM 和 PyTorch 都是基金会的项目，拥有一个共同的论坛来暴露生态系统中的摩擦——而不是每个项目各自为政地变通——结果证明这带来了真正的改变。

修复已经落地

2026 年 4 月，在另一次 TAC 会议上，我得知问题已经解决：从 PyTorch 2.11.0 开始，在 aarch64 Linux 上默认执行 pip install torch 现在会拉取支持 CUDA 的 wheel，而不是仅 CPU 的。NVIDIA 的 Piotr Bialecki 确认该变更已在 2.11.0 版本中生效。我在 GB200 上进行了验证，差异正是你所期望的——平淡无奇，却是最好的方式：

$ uv run --no-project --python 3.12 --with 'torch==2.11.0' -- python -c "import torch; print(torch.cuda.is_available())"
True
$ uv run --no-project --python 3.12 --with 'torch==2.10.0' -- python -c "import torch; print(torch.cuda.is_available())"
False

仅仅升级一个版本，整个变通方案栈就消失了。不再需要在依赖文件中传播自定义索引 URL，不再有静默的 CPU wheel 替换破坏一个可用的安装，新用户也不再需要经历“为什么我的 GB200 找不到 GPU”这样的调试过程。

对于 vLLM 而言，这意味着在 GB200 / GB300 上的安装现在真正顺畅了。初次使用 Grace Blackwell 系统的新用户可以遵循标准安装说明，让一切首次就正常运行——当你试图在一个全新平台上快速启动推理时，这一点至关重要。vLLM 中的变通方案——无论是 use_existing_torch.py 还是 [tool.uv] no-build-isolation-package = ["torch"] 设置——将继续保留。它们对于高级用户仍然有用，这些用户可能运行自定义的 PyTorch 构建版本（nightly 版、打过补丁的分支或与 vLLM 源码构建搭配的从源码构建版本），并且需要 vLLM 的安装严格保持 torch 不变。发生变化的是默认路径：普通用户不再需要知道这些变通方案的存在。他们只需 pip install，然后继续工作；变通方案悄无声息地转变为高级用户工具，而不是对所有人的额外负担。

为什么这值得写

从宏观角度来看，这是一个很小的改变——一个包装调整，而不是一个新功能。但我认为值得花点时间来欣赏它，原因有二。

首先，这是 vLLM 和 PyTorch 在 PyTorch 基金会框架下进行卓有成效协作的具体例子。TAC 不仅仅是一个治理仪式；它是一个场所，让下游项目遇到痛点时，能够直接呈现在可能修复它们的人面前，并且跨项目的协调是自然而然的，而不是偶然发生的。这个问题走完了完整的路径——从开发者在黑客马拉松上对着终端咒骂，到 TAC 讨论，到追踪的 GitHub issue，再到发布——而基金会正是这条路径变短的原因。

其次，开发者体验是复利累积的。如果某人不必为了 --index-url 标志而挣扎一小时，那么这一小时就可以用来在 vLLM 和 PyTorch 之上真正构建东西。aarch64 GPU 系统只会越来越普遍，现在就在平淡无奇的基础设施层面解决这个问题，远比让每个用户自己去发现并变通要好得多。uv 端的变通方案（构建隔离透传）是更广泛的 WheelNext 努力 (https://wheelnext.dev/proposals/pepxxx_build_isolation_passthrough/) 的一部分——这是一股非常受欢迎的推动力，旨在重新思考 AI 时代 Python 打包如何处理加速器相关的依赖。

向所有促成此事的人致以诚挚的感谢：PyTorch 核心团队的 Alban Desmaison、Nikita Shulga 和 Andrey Talman，他们接过了最初的请求并推动其进展；NVIDIA PyTorch 团队，他们推动了 aarch64 构建工作并确认修复已在 2.11.0 中落地，Piotr Bialecki 支持了这项工作，并在 NVIDIA 和上游之间就此问题扮演了稳定的联络人角色；PyTorch 发布工程团队，他们负责构建并发布 wheel；还有背后众多来自 PyTorch、NVIDIA 和 Arm 的工程师，他们在工具链、CI 基础设施和打包方面所做的工作使这一切成为可能。也感谢 TAC 的每一位成员，他们为这类对话敞开了大门。

继续前进。