如何在让 @vllm_project 保持光速前进的同时，不排斥那些在多样化硬件上运行多样化模型的用户？

在一篇新的 PyTorch Foundation 博客文章中，来自 @IBM、@Meta 和 @huggingface 的贡献者们介绍了旨在平衡前沿性能与可移植性的硬件无关层，以帮助确保 vLLM 继续满足更广泛开源生态系统的需求。

阅读博客了解更多：https://bit.ly/4xEH7Wk

@hmellor_ @th_ortner

vLLM 中的硬件无关模型 – PyTorch

来源：https://pytorch.org/blog/hardware-agnostic-models-in-vllm/

特色项目

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

概要

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

处于前沿的 vLLM

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

然而，前沿开源模型的架构正在迅速分化，这促使社区重新审视现有的一些抽象层是否仍然适用。模型越来越多地附带定制层和优化的内核。这甚至扩展到了核心注意力机制：DeepSeek V4 和 Kimi K3 通过完全不同的方法实现了百万级 token 上下文。将其中一个模型适配到 vLLM 中，意味着需要从 model_executor/layers 中的共享层进行组合，并保持整个模型可进行全图编译：代码需编写为 Dynamo 可以追踪的形式，每个新内核都注册为一个 torch library op，带有伪实现和正确的变异注释。这项工作是对模型开发的征税，由添加模型的任何人支付，包括带来自己模型的高级用户。

与此同时，NVIDIA Blackwell GPU 和机架级系统（如 NVIDIA GB300 NVL72）需要精心的内核工程以利用新功能，并有效重叠计算与通信。

在所有这些趋势发生的同时，我们看到了编码代理（如 Claude Code 和 OpenAI Codex）的兴起，它们使得生成代码变得更加容易。特别是，这些代理在为特定硬件上的特定模型设计优化方面非常有效。然而，如果它们不必担心特定更改是否会损害另一个加速器上的另一个模型，它们的效果最佳。

这些趋势汇聚在一起意味着，为了在最新的 GPU 硬件上实现最先进的性能，社区希望拆解 vLLM 中现有的一些抽象。特别是，vLLM 开始维护针对特定硬件的模型定义 (https://github.com/vllm-project/vllm/issues/42770)，也称为“扁平”模型。扁平模型不使用 torch.compile，而是使用自定义融合以及其他针对模型和硬件的优化。最近添加到 vLLM 的新前沿模型都使用了这种扁平模型定义。关键是，模型定义使用的现有层和操作很可能会被重构，从而与 torch.compile 根本不兼容。

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

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

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

目前，vLLM 提供三种风格的模型定义。

1. 新的“扁平”模型，位于 vllm/models/ 下
2. 传统模型，位于 vllm/model_executor/models 下
3. Transformers 建模后端，从 transformers 导入模型。

当前状态的高层概览如下所示。

图 1：vLLM 中模型定义的当前状态。所有三种风格都解析为每个公共层的单一实现，此处以 RowParallelLinear 为例。SpyreRowParallelLinear 是一个非树上插件，在一种加速器上覆盖该层。

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

vLLM 的层实现经过数年演进，提供了两个重要特性，我们现在将更详细地讨论：（a）torch 编译支持，和（b）非树上可扩展性。

虽然扁平模型不使用全图 torch 编译，但它对于像 IBM Spyre (https://github.com/torch-spyre/spyre-inference) 这样的非树上插件仍然是一个关键特性。Spyre 依赖于 TorchDynamo 来追踪模型图，并使用 TorchInductor 将图降级到可以在目标硬件上最优运行的表示形式。关键是，torch 编译也是使 vLLM 的 transformers 后端能够在 NVIDIA GPU 上为 Qwen3 等模型实现原生速度 (https://huggingface.co/blog/native-speed-vllm-transformers-backend) 的必要组件。

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

那么，这里的问题是什么？

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

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

首先，它使非树上面面临维护自己的一套模型定义和层的前景，带来了巨大的维护负担。支持一个新模型将涉及向 transformers、vLLM 以及可能每个想要支持它的非树上插件提交拉取请求。是的，编码代理使这变得更容易，但这仍然需要在多个不同的组织中消耗 token 预算，最终没有任何实际益处。

第二，vLLM 越来越依赖 transformers 后端来支持较旧或更特殊的模型。传统模型定义正从 model_executor/models 中积极移除，其注册表条目被更新为直接指向 transformers 建模后端。没有可编译的层，这些模型在 GPU 上的性能将显著下降。

最后，虽然扁平模型和层将针对前沿 GPU 进行优化，但我们不期望它们提供对旧款 GPU 或消费级/准专业级 GPU 的支持。vLLM 自己的使用统计 (https://app.hex.tech/019c4540-72b8-7005-9d68-08e0191ac583/app/vLLM-Weekly-Usage-Stats-032Vh7ZNLdI3OI2hNYJaPv/latest) 显示，很大一部分用户群继续使用此类硬件。我们认为该项目也应以满足他们需求的方式演进。

我们的解决方案是什么？

我们正在 vLLM 的代码库中构建一组硬件无关层。这些层的目标是确保 vLLM 能够继续支持那些关心在多样化硬件上运行多样化模型的用户群。

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

1. 可编译。模型定义将是全图 torch 可编译的；需要编译以获得性能的加速器可以继续像今天一样使用它。
2. 可扩展。我们将保留 vLLM 的 CustomOp 和 PluggableLayer 等机制，以确保非树上插件可以在必要时覆盖实现。
3. 隔离。模型定义将使用自己的一组层和操作构建，这些层和操作与硬件特定路径使用的层和操作分离并隔离。这将确保两个方向的开发都能快速进行，而不会阻碍彼此。
4. 可移植。我们将努力使用原生 PyTorch 代码或可移植的 DSL（如 Triton 和 Helion）实现所有层和操作。这将使模型可以在所有支持这些框架的加速器之间移植。那些不支持的仍可以在必要时依赖（2）。

我们正在设计的方案如下图所示：

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

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

对于 transformers 后端，我们已修改了“重新连接”过程，使其指向位于 model_executor/hw_agnostic 的新硬件无关层，而不是现有的位于 model_executor/layers 的层。此支持已合入 (https://github.com/vllm-project/vllm/pull/49458) vLLM 主分支（仅限于少量层），可以通过在运行 vLLM 与 transformers 后端时设置 USE_HW_AGNOSTIC=1 来启用：

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

我们已使用 Spyre 非树上插件对 Gemma 4、Qwen3 和 Granite 4.2 等模型验证了这条新路径。很快，我们将开始在 CI 中包含硬件无关模型，并逐步将其切换为在 Spyre 上提供模型的默认路径。

虽然尚未合入，但我们计划为每个扁平模型提供一个新的 model.py，使用硬件无关层实现该模型。跨多个扁平模型重用的层将位于共享位置（model_executor/hw_agnostic），而特定于模型的层（例如，DeepSeekV4FlashMLAAttention）将位于包含 model.py 的本地目录中，但仍需遵守上述 4 个设计原则。作为示例，请查看目前正在审查中的硬件无关 DeepSeek V4 PR (https://github.com/vllm-project/vllm/pull/45470)。

但是，它在 GPU 上的性能如何？

我们强调，在 Blackwell、CDNA 4 及以后的硬件上实现最先进的性能并非这些模型定义的目标。我们的目标是在包括非树上加速器、旧款 GPU 以及准专业级 GPU 在内的多样化硬件上实现平台和性能可移植性。

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

正如我们所看到的，尽管完全由底层层和操作的可移植实现构建，硬件无关模型的性能与使用 CUDA 优化库（如 FlashAttention 和 CUTLASS）的原生模型相比，相当接近，在某些情况下甚至略优。

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

结论

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

更多信息，请查看 RFC (https://github.com/vllm-project/vllm/issues/44219) 或在 vLLM Slack 上关注 Slack 频道 #hw-agnostic-models (https://vllm-dev.slack.com/archives/C0B8VV3CRC7)。您也可以在 vLLM.ai (http://vllm.ai/) 或 vLLM GitHub (https://github.com/vllm-project/vllm) 项目页面了解更多关于 vLLM 的信息。