vLLM 引入硬件无关层，解决 torch.compile 兼容性问题

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

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

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

与此同时，NVIDIA Blackwell GPU 和 NVIDIA GB300 NVL72 这类机架级系统需要精心的 kernel 工程来利用新特性，并有效地将计算与通信重叠。

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

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

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

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

如今，vLLM 提供三种形式的模型定义。

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

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

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

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

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

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

除了模型定义分散在三处这一点相当令人困惑之外，上述设计还有一个更紧迫的问题。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）