vLLM 部署实战：不同硬件上的适配矩阵与调参要点
· 阅读需 3 分钟
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 默认配置已经不错，但仍有几个高频调整项：
- gpu-memory-utilization：默认 0.9，多进程共享一张卡或多卡跑多模型时建议压到 0.8 左右，避免 OOM 后进程被杀。
- max-model-len 与 max-num-seqs：上下文长度直接决定 KV Cache 预留显存，生产环境不要盲目拉到模型上限，按业务 P99 输入长度加余量设置。
- chunked prefill 与 prefix caching：新版默认开启，长输入场景收益明显；RAG 类应用务必确认前缀缓存生效。
- 量化方案：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 路线滞后一至两个版本，上线前要针对目标模型跑完整回归测试。
实操建议
- 用容器镜像锁定版本组合，不要在生产机器上直接 pip 安装三件套（vLLM、torch、底层驱动栈）。
- 换硬件或升级版本时，先在预发环境跑官方精度评测脚本，再压测吞吐与时延曲线。
- 关注 vllm-ascend 与 ROCm 后端的 Release Note，特性差距在缩小，但"最新特性"往往只在 CUDA 路线可用。
- 混合集群建议统一 OpenAI 兼容 API 层，让业务侧对硬件无感，方便后续按成本迁移。