vLLM 多硬件后端抽象：为什么 PyTorch 支持设备还不等于推理框架支持设备

整理日期：2026-09-16。问题起点是：既然 PyTorch 已支持 Ascend、ROCm、Intel GPU 等设备，为什么 vLLM 还需要大量硬件适配代码，尤其 vLLM Ascend 为什么会形成一个很大的独立插件？

核心结论

PyTorch 的设备支持主要解决“张量和基础算子如何在某种硬件上执行”；vLLM 的硬件后端还必须解决“一个高性能 LLM Serving Runtime 如何利用这种硬件”。 二者不是同一层抽象。

因此，torch_npu、ROCm PyTorch 或 torch.xpu 可让许多普通 PyTorch 算子运行，但不会自动提供 Paged Attention、KV Cache 布局、连续批处理对应的 metadata、量化 kernel、图捕获、collective 通信、模型 runner、PD/DCP 等推理运行时机制。

一、把问题放回正确的软件栈

可以把现代 LLM 推理系统粗略分成五层：

1. Serving / Scheduler：请求队列、continuous batching、优先级、SLO。
2. Runtime：ModelRunner、KV Cache、block table、slot mapping、graph capture、memory manager。
3. 高性能算子：Attention、MoE、GEMM、量化、采样等 fused/custom kernels。
4. 框架 / 编译器：PyTorch、torch.compile、torch_npu、Inductor/Triton 等。
5. 硬件 Runtime / 通信：CUDA/CANN、NCCL/HCCL/XCCL、stream/event、driver。

PyTorch 设备后端主要覆盖第 4 层，并向第 5 层提供接口；而 vLLM 的硬件适配大量发生在第 2～5 层之间。

一个推理框架真正需要的不是单一 Operator 抽象，而是一整套 Hardware Backend Abstraction。

二、为什么“做好算子抽象”仍然不够

即使定义统一的 AttentionOp，仍有大量非数学算子的硬件语义：

• Device/Platform 初始化与能力探测；
• Worker / ModelRunner 生命周期；
• KV Cache 的物理布局、block size、slot mapping；
• Attention backend 与 metadata；
• stream、event、异步拷贝与 graph capture；
• TP/EP 等 collective communicator；
• quantization kernel 与 dtype 支持；
• fused MoE / sampling / custom op；
• 编译器 pass、shape 限制和 graph replay；
• PD、KV transfer、DCP 等跨设备状态移动。

例如普通 Attention 可以由 matmul + softmax 组合；但 vLLM 的 Paged Attention 输入还包含 block table、sequence metadata、KV pages 等运行时状态。后端必须同时满足语义正确性、内存布局和性能，不是把一个 ATen 算子映射到新设备即可。

三、vLLM 当前的多硬件格局

截至 2026-09-16，vLLM 主仓库的平台探测代码直接包含 CUDA、ROCm、XPU、CPU 等 backend；官方发布也分别提供 CUDA、ROCm、CPU、XPU 的镜像/构建路径。Ascend 则通过独立的 vLLM Ascend hardware plugin 接入。

平台	主要软件栈	与 CUDA 的距离	学习定位
NVIDIA CUDA	PyTorch CUDA + CUDA/NCCL + CUDA/Triton kernels	基准	深入
AMD ROCm	PyTorch ROCm + HIP/RCCL + AITER/Triton 等	相对近	重点理解差异
Intel XPU	torch.xpu • XCCL + Intel GPU kernels	更远	先懂体系与源码边界
CPU	PyTorch CPU + SIMD/NUMA/thread runtime	不同计算模型	学系统原理，不必先钻 kernel
Ascend	torch_npu • CANN/HCCL + Ascend kernels	较远	结合工作场景深入

ROCm 为什么相对容易迁移

ROCm/HIP 在编程模型上与 CUDA 高度相似，vLLM 代码中甚至保留了若干 CUDA 语义兼容，例如 ROCm platform 的 device_type / dispatch 仍可复用 CUDA 路径。因此 ROCm 能共享更多 GPU runtime 和 kernel 结构。

但这不代表“无需适配”：ROCm 仍有自己的 Attention backend、AITER、Triton 路径、MoE、量化、设备能力判断和性能调优。

XPU 是什么

这里的 XPU 指 vLLM/PyTorch 语境中的 Intel GPU backend。上层通过 torch.xpu 使用 Intel GPU，分布式通信可使用 XCCL。它同样需要平台、kernel、Attention、通信等适配，并不是一个简单的设备字符串替换。

CPU 为什么也有专门 backend

CPU 不需要显卡 runtime，却会遇到另一套性能问题：NUMA、线程亲和性、cache hierarchy、SIMD/AVX/AMX、内存带宽等。因此“PyTorch 能在 CPU 上跑”也不等于“高性能 vLLM CPU backend 不需要专门优化”。

四、为什么 vLLM Ascend 看起来格外“大”

一部分原因是代码组织形式造成的视觉差异。

ROCm、XPU、CPU 的很多适配代码位于 vLLM 主仓库内部；Ascend 把 Platform、Worker、ModelRunner、Attention、Quantization、Graph、Communication、Custom Ops 等大量硬件相关能力集中到了独立仓库，因此更容易直观看见一个完整硬件 backend 的规模。

更深层原因是 CUDA 与 Ascend 在 kernel programming model、graph runtime、通信栈、编译工具链和设备语义上的差异更大，难以像 HIP 那样大量复用 CUDA 兼容路径。

可以把关系理解为：

                vLLM Core
                    │
            Hardware Abstraction
                    │
   ┌────────────────┼────────────────┐
   │                │                │
 CUDA             ROCm/XPU          Plugins
   │                                 │
NVIDIA                           vLLM Ascend
                                     │
                            torch_npu / CANN

五、对学习路线的直接含义

不需要成为“后端收藏家”。更合理的能力结构是：

• CUDA：深入。 把它作为 GPU/NPU 高性能计算和推理 Infra 的基准生态，学习 memory hierarchy、kernel、stream/event、graph、collective、Attention/MoE。
• Ascend：深入。 学 CANN、HCCL、vLLM Ascend，并在需要时下钻 AscendC，形成工作场景中的差异化能力。
• ROCm：对照学习。 重点研究 CUDA → HIP/ROCm 后哪些抽象能复用、哪些必须重写，不需要现在专门成为 ROCm kernel 专家。
• XPU：架构级理解。 知道 torch.xpu、XCCL、Intel GPU backend 如何映射到 vLLM 即可，除非未来项目明确需要。
• CPU：系统基础必学，vLLM CPU kernel 暂不必深挖。 NUMA、cache、SIMD、memory bandwidth 对任何 Infra 工程师都重要。

真正应该围绕同一个问题纵向学习，例如 Decode Attention：算法 → KV Cache → vLLM AttentionBackend → CUDA kernel → Ascend backend；ROCm/XPU 用作对照组，而不是再开三条完整学习主线。

六、推荐的源码比较方法

选择同一个 abstraction 横向读，而不是从头通读每个仓库：

Platform
  CUDA → ROCm → XPU → CPU → Ascend

AttentionBackend
  CUDA → ROCm → XPU → Ascend

ModelRunner / Worker
  upstream → Ascend

Communicator
  NCCL/RCCL/XCCL/HCCL

Graph
  CUDA Graph → Ascend ACLGraph/NPUGraph

每次比较都回答三个问题：

1. 哪些是推理框架的稳定语义？
2. 哪些只是 CUDA 历史实现细节？
3. 哪些差异来自硬件本身，必须泄露到 Runtime？

这比记 API 更接近真正的 Hardware Abstraction 研究。

知识联系

• 学习路线：如何分层学习推理 Infra：从 CUDA 基线到昇腾，再到训练与 RL
• 昇腾栈：昇腾软硬件生态专题：从 CANN、算子编程到灵衢超节点
• 长上下文 Runtime：Decode Context Parallelism（DCP）详解：长上下文解码中的 KV Cache 分片、通信与 vLLM/昇腾实现

参考资料

• vLLM Quickstart：多平台与 Attention backends
• vLLM GPU installation：CUDA / ROCm / XPU
• vLLM platform detection 源码
• vLLM ROCm Platform 源码
• vLLM Ascend