vLLM 引入硬件无关层以兼容 torch.compile 与 OOT 加速器

TL;DR

为了在前沿领域实现最先进的性能，vLLM 正在改变其内部实现方式，这使其与 fullgraph torch.compile 不兼容。这可能会对关心树外加速器、较旧 GPU 或更特殊模型的用户产生影响。为解决这一问题，我们在 vLLM 中引入了一组新的“硬件无关”层。这些层将确保 vLLM 能够继续以光速前进，同时满足关心可移植性的用户的需求。在 NVIDIA H100 GPU 上，硬件无关层的总 token 吞吐量与原生实现相差在 3.4% 以内（三个近期模型的几何平均值）。

前沿领域的 vLLM

vLLM 通过将自身定位为支持多种硬件上多种模型的抽象层，取得了前所未有的成功。通过使用一组精心设计的抽象以及 torch.compile 进行优化与融合，该项目得以让定义实际模型逻辑的代码（通常称为“模型定义”）保持相对简单，同时仍在 NVIDIA GPU、AMD GPU、Intel XPU、Google TPU、IBM Spyre、华为昇腾等硬件上实现高性能。

然而，前沿开放权重模型的架构正在迅速分化，这促使社区重新审视某些现有抽象是否仍然适用。模型越来越多地自带定制层和优化内核。这甚至延伸到了核心注意力机制：DeepSeek V4 和 Kimi K3 通过完全不同的方法实现百万 token 上下文。将其中之一适配到 vLLM 中，意味着要用 model_executor/layers 中的共享层来组合它，并保持整个模型可进行 fullgraph 编译：编写方式要能让 Dynamo 追踪，每个新内核都要注册为带有 fake 实现和正确 mutation 注解的 torch 库算子。这项工作是模型开发的一种负担，由添加模型的人承担，包括自带模型的高级用户。

与此同时，NVIDIA Blackwell GPU 和 NVIDIA GB300 NVL72 等机架级系统需要精细的内核工程，以利用新特性并有效地将计算与通信重叠。

在这一切发生的同时，我们见证了 Claude Code 和 OpenAI Codex 等编码智能体的兴起，它们让生成代码变得容易得多。特别是，这些智能体非常擅长为特定硬件上的特定模型设计优化。然而，它们最擅长的是无需担心某项特定改动是否会让不同加速器上的不同模型变得更糟。

这些趋势汇聚在一起，意味着为了在最新 GPU 硬件上实现最先进的性能，社区希望拆除 vLLM 中的一些现有抽象。特别是，vLLM 开始维护硬件特定的模型定义，也称为“扁平”模型。扁平模型不使用 torch.compile，而是使用自定义融合以及其他模型特定和硬件特定的优化。近几个月添加到 vLLM 的新前沿模型都使用这种扁平模型定义。至关重要的是，模型定义所使用的现有层和算子很可能会以某种方式重构，使其从根本上与 torch.compile 不兼容。

这项工作对于让 vLLM 在最新的 GPU 基准测试中保持竞争力是必要的。然而，同样重要的是，vLLM 需要继续服务于那些关心在多样化硬件（如旧款 GPU 或树外（OOT）加速器）上运行多样化模型的用户。

那么，我们能做些什么呢？让我们先回顾一下 vLLM 目前是如何处理模型定义的。

vLLM 中的模型定义是如何工作的？

目前，vLLM 提供三种形式的模型定义。

新的“扁平”模型，位于 vllm/models/ 下
旧版模型，位于 vllm/model_executor/models 下
transformers 建模后端，从 transformers 导入模型。

当前状态的高层示意图如下所示。

图 1：vLLM 中模型定义的当前状态。所有三种形式都解析为每个通用层的单一实现，此处以 RowParallelLinear 为例展示。SpyreRowParallelLinear 是一个树外插件，在某个加速器上覆盖了该层。

虽然建模逻辑可能位于不同位置，但大多数模型都由通用层组成，如注意力、混合专家、线性投影、归一化和激活函数。重要的是要理解，在上述所有 3 种情况下，这些通用层仍然在单一位置实现。在情况 (1) 和 (2) 中，这些层显式地从 vllm/model_executor/layers 导入。在情况 (3) 中，transformers 模型会被自动融合并重新连接以使用 vLLM 层。因此，无论模型定义来自何处，我们仍然使用支撑它的绝大多数层的通用实现。

vLLM 的层实现经过数年的演进，提供了两个重要特性，我们现在将更详细地讨论：(a) torch compile 支持，以及 (b) OOT 可扩展性。

虽然扁平模型不使用 fullgraph torch compile，但它对于像 IBM Spyre 这样的 OOT 插件来说仍然是一个关键特性。Spyre 依赖 TorchDynamo 来追踪模型图，并依赖 TorchInductor 将图降低为目标硬件上最优运行的表示形式。至关重要的是，torch compile 也是使 vLLM 的 transformers 后端能够在 NVIDIA GPU 上为 Qwen3 等模型实现原生速度的必要组件。

然而，对于 OOT 插件来说，torch compile 并非全部。像 Spyre 这样的加速器偶尔也需要向层中注入行为（例如，自定义内存布局）以实现最优性能。vLLM 的层提供了两种不同的机制来注入自定义行为：CustomOp（使插件能够覆盖前向函数）和 PluggableLayer（使插件能够覆盖整个层）。如果没有这种可扩展性，OOT 插件将需要自行重新实现许多层。

那么，问题出在哪里呢？

除了将模型定义放在三个地方相当令人困惑之外，上述设计还有一个更紧迫的问题。

扁平模型工作流需要更改模型定义及其底层层实现，以破坏与 torch compile 的兼容性并移除通过 CustomOp 实现的可扩展性支持。这将使它们能够更快地开发针对硬件和模型的性能优化，但也引发了一些担忧。

首先，这会让 OOT 插件面临维护自己一套模型定义和层的前景，造成巨大的维护负担。支持一个新模型将涉及向 transformers、vLLM 以及随后可能每一个想要支持它的 OOT 插件提交 pull request。是的，编码智能体让这变得更容易，但这仍然需要在多个不同组织之间消耗 token 预算，最终却没有真正的收益。

其次，vLLM 越来越依赖 transformers 后端来为更旧或更奇特的模型提供支持。旧版模型定义正被主动从 model_executor/models 中移除，其注册表条目也被更新为直接指向 transformers 建模后端。如果没有可进行 torch 编译的层，这些模型在 GPU 上的性能将显著退化。

最后，虽然扁平化模型和层将针对前沿 GPU 进行优化，但我们并不期望它们能为较旧的 GPU 或消费级/准消费级 GPU 提供支持。vLLM 自己的使用统计显示，相当一部分用户仍在使用此类硬件。我们认为该项目也应该以满足他们需求的方式演进。

我们的解决方案是什么？

我们正在 vLLM 树内构建一组硬件无关的层。这些层的目标是确保 vLLM 能够继续支持那些关心在不同硬件上运行不同模型的用户群体。

硬件无关层遵循以下四项设计原则：

可编译。模型定义将支持全图 torch 编译；需要编译来提升性能的加速器可以像今天一样继续使用它。
可扩展。我们将保留 vLLM 的 CustomOp 和 PluggableLayer 等机制，以确保 OOT 插件在必要时可以覆盖实现。
隔离。模型定义将使用自己的一套层和算子来构建，这些层和算子与硬件特定路径所使用的层和算子相互分离、彼此隔离。这将确保两个方向的开发都能快速推进，而不会相互阻碍。
可移植。我们将努力使用原生 PyTorch 代码或 Triton、Helion 等可移植 DSL 来实现所有层和算子。这将使模型可移植到所有支持这些框架的加速器上。不支持这些框架的加速器在必要时仍可依赖 (2)。

我们正在努力实现的设计如下所示：

图 2：vLLM 中的硬件无关层。

随着旧版模型定义被逐步移除，模型要么以扁平化方式重新实现（例如，为 NVIDIA、AMD、XPU 等提供不同实现），要么回退到 transformers 后端。我们打算在这两种情况下都提供硬件无关支持。

对于 transformers 后端，我们修改了“重新接线”过程，使其指向位于 model_executor/hw_agnostic 的新硬件无关层，而不是位于 model_executor/layers 的现有层。此支持已经落地到 vLLM 的主分支（针对有限数量的层），并且可以在使用 transformers 后端运行 vLLM 时通过设置 USE_HW_AGNOSTIC=1 来启用：

USE_HW_AGNOSTIC=1 vllm serve google/gemma-4-31B --model-impl=transformers

我们已经使用 Spyre OOT 插件对 Gemma 4、Qwen3 和 Granite 4.2 等模型验证了这条新路径。很快，我们将开始把硬件无关模型纳入 CI，并逐步将其切换为在 Spyre 上服务模型的默认路径。

虽然尚未落地，我们计划为每个 flat model 提供一个全新的 model.py，使用硬件无关层来实现该模型。在多个 flat model 之间复用的层将存放在共享位置（model_executor/hw_agnostic），而模型特定的层（例如 DeepSeekV4FlashMLAAttention）将存放在本地目录中，与 model.py 放在一起，但仍遵循上述 4 项设计原则。作为其中一个示例，请查看目前正在审核中的硬件无关 DeepSeek V4 PR。

但是，它在 GPU 上的表现会如何？

我们强调，在 Blackwell、CDNA 4 及更高版本上实现最先进的性能并不是这些模型定义的目标。我们的目标是在各种硬件上实现平台和性能的可移植性，包括 OOT 加速器、较旧的 GPU 以及专业消费级 GPU。

为了评估新路径在广泛可用的 GPU 上的表现，我们在 NVIDIA H100 GPU 上针对一些近期模型进行了一些实验。我们在图 3 中比较了 vLLM 的 transformers 后端使用 USE_HW_AGNOSTIC=0 与 USE_HW_AGNOSTIC=1 时的性能。

正如我们所见，尽管仅由底层层和算子的可移植实现构建而成，硬件无关模型所达到的性能相对接近，在某些情况下甚至略优于使用 FlashAttention 和 CUTLASS 等 CUDA 优化库的原生模型。

图 3：硬件无关层对 H100 GPU 性能的影响。

结论

我们正在将硬件无关层引入 vLLM，以确保该项目能够继续在多样化的硬件上支持多样化的模型，同时不拖慢前沿的性能工程。我们相信这项工作对于 vLLM 继续服务更广泛的开源生态系统的需求非常重要。虽然我们已经开始提交 PR 来实现这一目标，但这仍然是一项进行中的工作，我们欢迎任何反馈。

如需了解更多信息，请查看 RFC 或关注 vLLM slack 上的 slack 频道 #hw-agnostic-models。您还可以在 vLLM.ai 或 vLLM github 项目页面上了解更多关于 vLLM 的信息。