AREX Feed Article
vLLM 接入 PyTorch LibTorch Stable ABI，新 PyTorch 版本不再强制重建
2026 年 11 月 10 日，vLLM 项目官方 X 账号 发帖宣布：vLLM 已采用 PyTorch 的 LibTorch Stable ABI，新的 PyTorch 版本发布不再强制 vLLM 重新构建（rebuild）。帖文点名三类直接受益者：用户可以更早升级新 torch，发行方减少重建次数，开发者无需重编译 vLLM 即可测试 PyTorch 侧的改动。
帖文链接的迁移博客《Migrating vLLM to the LibTorch Stable ABI》已于 2026 年 11 月 6 日发布在 ，署名为 vLLM 团队、Red Hat PyTorch 团队和 Meta PyTorch 团队。博客给出的关键节点是：自 v0.33.0 起，vLLM 开始发布 LibTorch ABI Stable 的 CUDA wheels；此后在兼容的 PyTorch 版本之间，同一个 vLLM wheel 可以继续使用，升级时只需换掉 torch wheel，再把它直接导入 vLLM 包。vLLM 本身是一个面向 LLM 的高吞吐、省显存的推理与服务引擎，其 C++ 后端频繁调用 LibTorch，这是这次迁移的由来。
从 2025 年 10 月的 RFC 到 2026 年的迁移计划
这条迁移线的起点是 2025 年 10 月 15 日 PyTorch 团队在 vLLM 仓库开出的 。RFC 写明的动机是：PyTorch 正在搭建一套受限 ABI，让自定义算子作者「用一个 torch 版本编译，在另一个 torch 版本上运行」；vLLM 是生态里重要的 torch 依赖方，PyTorch 希望帮助构建不再绑定特定 torch 版本的 vLLM wheels。当时 RFC 的预期是到 2025 年 12 月初切分支的 PyTorch 2.10 为止支持 vLLM 的 CUDA 内核。
2026 年 5 月 7 日，PyTorch 的 Jane Xu 在 PyTorch 官方开发者论坛发帖公布 ，把这项工作称作 Project H-Beam，并表示团队当年将为 torchvision 和 vLLM 这类库提供「white glove」迁移协助；彼时 Flash-Attn-3、xformers、torchao、torchaudio 已经完成迁移。到 11 月 6 日博客发布时，vLLM 的整个 CUDA wheel 达到了 LibTorch ABI Stable。
「换 torch、不换 vLLM」：稳定 ABI 的三层结构
博客先交代问题所在：ABI（应用二进制接口）规定编译后的代码如何与库交互——函数怎么调用、数据怎么排布、符号怎么命名。源代码里的 API 看起来没变，ABI 一变，扩展照样要重新编译。此前 torch 出新版时，vLLM 可能要重建、重链才能继续用，对新版及其特性的支持因此被拖慢。
Stable ABI 的做法是在兼容版本之间保留一组受支持的二进制接口，扩展只用这组接口就能免于重建。PyTorch 的 LibTorch Stable ABI 分三层：暴露精选 LibTorch API 的稳定 C shim，让 shim 更易用的高层 C++ 封装，以及不链接 libtorch.so 的 torch::headeronly 头文件工具库。
175 个以上 CUDA 源文件、7 个编译依赖的分块迁移
vLLM 仅 CUDA 构建就有超过 175 个 .cpp/.cu 源文件，另有 120 多个头文件，一次性迁移难以评审。团队新建了一个独立的 stable 库，把内核分块迁入；构建标志 TORCH_TARGET_VERSION 在包含任何不稳定 LibTorch 头文件时直接让构建失败，用来守住 ABI 稳定。
迁移中有两类函数必须改写到 Python：Stable ABI 目前不支持稳定的 SymInt，meta 函数要写成 Python；Stable ABI 也不暴露 PyTorch 的 autograd 机制，AutogradFunctions 同样要写成 Python。博客称 vLLM 本来就把多数 meta 函数放在 Python 里，这部分改动不大。算子注册则从 TORCH_LIBRARY 换成 STABLE_TORCH_LIBRARY，实现用 TORCH_BOX 包一层，把 C++ 类型装箱成能穿过稳定 ABI 的 StableIValue。单个源文件的替换大多机械：torch::Tensor 换成 torch::stable::Tensor，at::kInt 换成 torch::headeronly::ScalarType::Int，t.view({...}) 换成 torch::stable::view(t, {...})。团队还写了一套给 AI agent 用的 skills 来映射稳定 API、标记常见错误，但博客同时承认尚未建立评估来衡量这些 skills 的效果。
只迁移 vLLM 自身源码还不够。博客指出，vLLM 目前有七个同样依赖 LibTorch 的编译依赖——FlashMLA、DeepGEMM、FlashAttention-2、FlashAttention-3、DeepSelect、FlashKDA、QuTLASS——它们也要迁完，整个 wheel 才算稳定。其中 DeepGEMM 最能说明难度：迁移进行期间，DeepGEMM 从 1 版升到 2 版、新增了同样依赖 LibTorch 的 DeepJIT，vLLM 又把代码源从上游 deepseek-ai/DeepGEMM 换到自己的 vllm-project/DeepGEMM fork，迁移只能在新 fork 上重做；DeepGEMM 原本用 pybind11 注册算子，得先改成 TORCH_LIBRARY 才能接入稳定注册机制。博客致谢栏中，vLLM 社区的 Shengqi Chen 是迁移协调人，DeepSeek 的 Chenggang Zhao、Yichen Yan 和 Shengyu Liu 也在贡献者名单中。
torch-abi-audit 审计与 torch 2.14.1 到 2.15.0 的实测
博客把「验证」列为迁移最重要的一步：博客作者称 vLLM 被多个行业的数百万用户使用，迁移不能打断他们的流程。除单元与性能测试、逐行复查每处迁移 diff 外，团队用 Ralf Gommers 开发的 检查 .so 文件，把 PyTorch 符号分成稳定与不稳定两类。依赖迁移前，审计结果是 Torch ABI: UNSTABLE，例如 _flashmla_C 一项就含 70 个不稳定符号；七项依赖迁完后，13 个扩展全部为 STABLE 或不依赖 torch 的 NO-TORCH，无一不稳定，整个 wheel 要求的最低 torch 版本从 2.11.0 升到 2.13.0。这套审计已进入 vLLM CI，防止 wheel 退回不稳定状态。
博客还给出实测：先用 torch 2.14.1+cu132 跑通一个加载 HuggingFaceTB/SmolLM2-135M-Instruct 的示例，再执行 uv pip install torch==2.15.0 换掉 torch wheel，不重建 vLLM 直接重跑——运行时显示 PyTorch 2.15.0+cu132，vLLM 仍是同一个构建，提示词「The capital of France is」正常返回「Paris. Paris is a city known for」。
API 子集、host 侧开销与仍然存在的兼容条件
Stable ABI 覆盖的是全部 LibTorch 的一个有限子集。博客举例 is_pinned()：迁移期间它没有稳定等价物，团队靠通用的 torch_call_dispatcher C shim 以 ABI 稳定的方式走 dispatcher 调用，保住了行为；PyTorch 2.14 后来补上了稳定的 C++ is_pinned()。博客称这次迁移也帮助 PyTorch 弄清了哪些 API 被常用。
第二个代价是少量 host 侧额外开销：C shim 引入类型转换，部分封装还要做算子查找和装箱。博客称这通常可以忽略，在 CUDA Graphs 预热后消失，但在 eager 模式下反复启动极快的内核时可能有影响；作者称迁移过程中没有观察到明显的运行时回退。
稳定 ABI 只解决二进制兼容。博客明确提示：vLLM 与 PyTorch 的兼容性仍取决于 Python API、GPU 相关要求（如最低支持的 CUDA 版本）和第三方依赖。Jane Xu 在 RFC 讨论中说过另一层边界：C shim 是这项工作的基石，可预见的未来不会变动、只会扩充；torch::stable::Tensor 这类高层 C++ 封装只存在于头文件中，仍处于改进期，可能变化。
下一步：CPU 与 ROCm 构建，以及上游尚未跟上的依赖
博客列出的下一步是把 vLLM 的全部构建纳入 ABI 稳定，包括 CPU 和 ROCm 构建；ROCm 构建与 CUDA 共享大量源文件——hipify 把 .cu 转成 .hip，这些文件已经在用稳定 ABI——只剩少数 ROCm 专属文件待迁移。PyTorch 侧的计划是继续扩大稳定 API 面，让 vLLM 及其依赖不再需要包装层，并同步更新 PyTorch 上游测试来守住这批 API 的稳定性。
依赖清单里还留着未完成项：DeepGEMM、DeepSelect 的上游迁移仍在进行，FlashAttention-2 有一个待合并的 PR，FlashKDA 的上游迁移尚未开始——七个编译依赖中，这四项的上游仓库还没跟上 vLLM fork 侧已完成的迁移。
参考链接
- _