Skip to main content

vLLM 部署实战：不同硬件上的适配矩阵与调参要点

· 3 min read
AI Compute Cards Wiki Editorial
Industry Research Team

vLLM 早已不只是"NVIDIA 专属"的推理引擎。随着硬件插件化 RFC 落地，AMD、昇腾、TPU 都有了官方或社区维护的后端，但各家成熟度差异悬殊。本文按硬件路线梳理适配矩阵与部署要点。

主流硬件后端适配矩阵​

硬件路线接入方式关键依赖成熟度评估
NVIDIA CUDA内置后端，开箱即用CUDA 12.x + 主线 PyTorch最高，特性首发地
AMD ROCm内置支持（Docker 镜像分发）ROCm 6.x + PyTorch ROCm 版较高，主流模型覆盖
华为昇腾vllm-ascend 硬件插件CANN 8.0 以上 + torch-npu快速追赶，2025 年完成 V1 引擎适配
Intel Xeon CPU内置 CPU 后端AVX-512 / AMX稳定，适合中小模型与降本场景

需要提醒的是，vllm-ascend 从 2025 年 2 月立项后保持了约两周一个版本的节奏，v0.7.3 实现核心加速特性支持，v0.9.1 引入大规模专家并行（EP），v0.11.0 显著提升稳定性，社区反馈显示互联网、银行、运营商场景已有规模化生产落地。版本号与 vLLM 本体严格对齐，升级时必须成对更新。

NVIDIA 路线的调参要点​

在 H100/A100 上，vLLM 默认配置已经不错，但仍有几个高频调整项：

  1. gpu-memory-utilization：默认 0.9，多进程共享一张卡或多卡跑多模型时建议压到 0.8 左右，避免 OOM 后进程被杀。
  2. max-model-len 与 max-num-seqs：上下文长度直接决定 KV Cache 预留显存，生产环境不要盲目拉到模型上限，按业务 P99 输入长度加余量设置。
  3. chunked prefill 与 prefix caching：新版默认开启，长输入场景收益明显；RAG 类应用务必确认前缀缓存生效。
  4. 量化方案：FP8 适合 Hopper 及以上，AWQ/GPTQ 适合消费级卡与老卡，选型前先跑精度评测再上量。

昇腾与 AMD 路线的现实​

昇腾路线要求 CANN 8.0 以上、torch-npu 与 vLLM 版本严格匹配，官方推荐通过容器镜像部署以规避环境漂移。Atlas 800I A2 系列是当前插件的主战场，DeepSeek、Qwen、GLM 等主流开源模型均已覆盖，PD 分离（Prefill/Decode 分离）与专家并行也在持续增强。

AMD 路线则相对简单，官方 Docker 镜像内置 ROCm 支持，MI300X 凭借 192GB 显存在 70B 级稠密模型上可以单卡部署，省去张量并行带来的通信开销。但部分自定义算子和投机解码特性更新会比 CUDA 路线滞后一至两个版本，上线前要针对目标模型跑完整回归测试。

实操建议​

  1. 用容器镜像锁定版本组合，不要在生产机器上直接 pip 安装三件套（vLLM、torch、底层驱动栈）。
  2. 换硬件或升级版本时，先在预发环境跑官方精度评测脚本，再压测吞吐与时延曲线。
  3. 关注 vllm-ascend 与 ROCm 后端的 Release Note，特性差距在缩小，但"最新特性"往往只在 CUDA 路线可用。
  4. 混合集群建议统一 OpenAI 兼容 API 层，让业务侧对硬件无感，方便后续按成本迁移。