vLLM中的硬件无关模型（10分钟阅读）

# vLLM中的硬件无关模型 – PyTorch 来源：https://pytorch.org/blog/hardware-agnostic-models-in-vllm/ ### 精选项目 - vLLM 标志 (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库操作进行注册。这项工作增加了模型开发的负担，由添加模型的人承担，包括带来自有模型的高级用户。 同时，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是树外插件，用于在一种加速器上覆盖该层。* 虽然建模逻辑可能位于不同位置，但大多数模型由公共层组成，如注意力、混合专家、线性投影、归一化和激活。重要的是要理解，在上述所有三种情况下，这些公共层仍然在单一位置实现。在情况（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**（允许插件覆盖前向函数）和**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`的现有层。此支持已合并到vLLM主分支（https://github.com/vllm-project/vllm/pull/49458）（针对有限数量的层），可以通过在使用transformers后端运行vLLM时设置`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后端的性能。 如我们所见，尽管完全由底层层和操作的**可移植实现**构建，硬件无关模型实现了与使用FlashAttention和CUTLASS等CUDA优化库的原生模型相对接近，在某些情况下甚至略优的性能。 ****** ***图3:** 硬件无关层对H100 GPU性能的影响。* ## 结论 我们正在将硬件无关层引入vLLM，以确保该项目能够继续支持多样化硬件上的多样化模型，而不减缓前沿性能工程。我们相信这项努力对于vLLM继续服务于更广泛开源生态系统的需求非常重要。虽然我们已经开始合并拉取请求来实现这一努力，但这仍是一个进行中的工作，我们欢迎任何反馈。 更多信息，请查看RFC（https://github.com/vllm-project/vllm/issues/44219）或关注vLLM 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的信息。