企业官网建设流程全解析

vLLM CPU 后端 x86 平台安装指南：预编译 Wheel、源码编译与 Docker 部署实践

【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm

导读

本指南面向需要在x86 CPU（Intel / AMD）平台上运行 vLLM 推理与在线服务的开发者，完整覆盖四条从简到繁的安装路径：直接使用官方预编译 Wheel、从源码自行编译、使用 Docker 预编译镜像、以及为特定目标 CPU 或 AMD Zen 平台自建镜像。读完本文你将掌握：如何用uv/pip干净地搭建 CPU 版环境、为什么必须设置LD_PRELOAD指向 Intel OpenMP（以及何时需要 TCMalloc）、如何拉取与运行vllm-openai-cpu镜像、如何开启并验证 AMD Zen（ZenDNN/zentorch）优化路径，以及VLLM_CPU_KVCACHE_SPACE、VLLM_CPU_OMP_THREADS_BIND等关键运行时变量的正确用法。

本文主体源自 docs/getting_started/installation/cpu.x86.inc.md 及其宿主文档 docs/getting_started/installation/cpu.md，并补充了当前仓库中对应的平台源码与 Docker 构建脚本作为印证。

一、x86 CPU 后端能力与前置要求

vLLM 支持在 x86 CPU 平台上进行基础的模型推理与在线服务（serving），支持的推理数据类型为FP32、FP16 与 BF16。这份能力声明同样是后续所有安装方式的前提——无论采用哪种安装路径，最终交付的都是同一个面向 CPU 目标的 vLLM 构建产物。

安装前请确认满足以下前置条件：

检查 CPU flags 的最直接方式是使用lscpu：

lscpu | grep -E 'Flags|型号名称' # Flags 一栏中应包含 avx512f 或 avx2

需要特别说明：仅具备avx2的 CPU 只能获得“受限功能”，vLLM 的部分算子实现（例如依赖 AVX-512 的 GEMM 调度路径）无法启用，因此在生产部署中优先选择带avx512f的处理器。此外，AMD 平台用户需要注意：AMD 处理器至少需要第 4 代（Zen 4 / Genoa）或更新的架构才支持 AVX-512，从而满足 vLLM CPU 运行要求（详见后文“疑难排查”一节）。

本仓库为 CPU 目标提供了多平台支持文档，x86 只是其中之一（另有 ARM AArch64、Apple silicon、IBM Z s390x），可参考 CPU 安装总览 选择对应分支。

二、三条安装路径的选择

针对 x86 CPU，官方提供以下三类主流安装方式，你可按场景组合使用：

在开始任一方式之前，建议先用uv创建干净的 Python 环境（详见第三节）。如果你已有现成环境并想先快速验证推理，可直接跳到第四节的预编译 Wheel。

三、准备 Python 环境（推荐 uv）

官方推荐使用 uv（由 Astral 出品的极速 Python 环境/包管理器）来创建和管理虚拟环境。创建 CPU 开发环境的标准做法是：

uv venv --python 3.12 --seed --managed-python source .venv/bin/activate

说明：

• --python 3.12：CPU 后端与构建链路在 3.10–3.13 上均有验证，3.12 为当前默认推荐版本；
• --seed：在环境中预置pip与setuptools，便于后续回退使用pip安装；
• --managed-python：允许 uv 在缺失对应 Python 版本时自动下载托管版本。

这套流程来自被 cpu.x86.inc.md 引用的公共片段 python_env_setup.inc.md。此外，CPU 安装的 uv/pip 命令普遍带有--torch-backend cpu或--extra-index-url https://download.pytorch.org/whl/cpu，作用是让包解析器优先从 PyTorch 官方 CPU index 拉取带+cpu后缀的 PyTorch 轮子，避免误装 CUDA 版本。

四、方式一：安装官方预编译 Wheel

4.1 Release Wheel（稳定版）

官方为 x86（AVX512/AVX2）提供预编译 vLLM Wheel，自v0.17.0起可用。安装步骤如下：

export VLLM_VERSION=$(curl -s https://api.github.com/repos/vllm-project/vllm/releases/latest | jq -r .tag_name | sed 's/^v//') # 使用 uv（推荐） uv pip install https://github.com/vllm-project/vllm/releases/download/v${VLLM_VERSION}/vllm-${VLLM_VERSION}+cpu-cp38-abi3-manylinux_2_34_x86_64.whl --torch-backend cpu

如果习惯用pip，等价命令为：

pip install https://github.com/vllm-project/vllm/releases/download/v${VLLM_VERSION}/vllm-${VLLM_VERSION}+cpu-cp38-abi3-manylinux_2_34_x86_64.whl --extra-index-url https://download.pytorch.org/whl/cpu

关于 Wheel 文件名值得解读一下：vllm-<版本>+cpu-cp38-abi3-manylinux_2_34_x86_64.whl中：

• +cpu：标明这是 CPU 构建产物（与 CUDA/ROCm 版区分，vLLM 构建系统通过VLLM_TARGET_DEVICE决定目标）；
• cp38-abi3：采用 CPython 的稳定 ABI（limited API），即一个 Wheel 可覆盖 Python 3.8+ 的多个版本，因此能服务 3.10–3.13 环境；
• manylinux_2_34_x86_64：面向 glibc ≥ 2.34 的 x86_64 Linux 平台。

4.2 安装后必须设置LD_PRELOAD

⚠️ 通过 Wheel 安装的 vLLM CPU，使用前必须确保Intel OpenMP 已被加入LD_PRELOAD：

# 手动定位 libiomp5.so 路径 sudo find / -iname *libiomp5.so IOMP_PATH=... # 注入 LD_PRELOAD export LD_PRELOAD="$IOMP_PATH:$LD_PRELOAD"

原因在于：vLLM CPU 推理的核心算子依赖 OpenMP 并行，而 vLLM 分发环境中的libiomp5.so（Intel OpenMP runtime）需要被预加载，以保证其线程池与 NUMA/亲和性策略按照 vLLM 预期的方式运行，避免运行时符号冲突或线程调度异常。

4.3 Nightly 与指定 Commit 的 Wheel

安装最新 main 分支构建的轮子（适用于抢先体验新功能、跟进 bug 修复）：

uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly/cpu --index-strategy first-index --torch-backend cpu

安装特定 commit 的轮子——当你需要定位行为变更或性能回归（如做 bisect）时，可在 index URL 中直接指定完整的 commit hash：

export VLLM_COMMIT=730bd35378bf2a5b56b6d3a45be28b3092d26519 # 使用 main 分支的完整 commit hash uv pip install vllm --extra-index-url https://wheels.vllm.ai/${VLLM_COMMIT}/cpu --index-strategy first-index --torch-backend cpu

--index-strategy first-index指示 uv 在解析依赖时以"第一个命中即用"的策略同时查询多个 index，配合 CPU 专属 index 能显著减少解析冲突。这类"按版本/提交归档 wheel"的持续交付机制，正是 CPU 用户不必自己编译即可回归测试历史版本的便捷通道。

五、方式二：从源码构建 x86 CPU 版 vLLM

当需要二次开发、定制编译参数，或希望使用尚未发布 Wheel 的代码时，选择源码构建。

5.1 安装推荐的编译器

源码构建会编译大量 C++/CUDA-free 内核，编译器版本直接影响构建成功率。官方建议使用gcc/g++ >= 12.3.0作为默认编译器以避免潜在问题。例如在 Ubuntu 22.04 上：

sudo apt-get update -y sudo apt-get install -y gcc-12 g++-12 libnuma-dev sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 10 --slave /usr/bin/g++ g++ /usr/bin/g++-12

libnuma-dev用于编译 NUMA 相关绑定逻辑；update-alternatives则把系统默认gcc/g++切换到 12.x。仓库的 CPU Dockerfile docker/Dockerfile.cpu 在 Ubuntu 25.04 基础镜像中进一步用到了 gcc-15（同样通过update-alternatives接管默认编译器），说明"以较新 GCC 为默认编译器"是官方一贯做法。

5.2 克隆仓库并安装依赖

git clone https://github.com/vllm-project/vllm.git vllm_source cd vllm_source

先完成第三节的 Python 环境创建，然后安装构建期与运行期依赖：

uv pip install -r requirements/build/cpu.txt --torch-backend cpu --index-strategy unsafe-best-match uv pip install -r requirements/cpu.txt --torch-backend cpu --index-strategy unsafe-best-match

使用pip的等价命令为：

pip install --upgrade pip pip install -v -r requirements/build/cpu.txt --extra-index-url https://download.pytorch.org/whl/cpu pip install -v -r requirements/cpu.txt --extra-index-url https://download.pytorch.org/whl/cpu

其中 requirements/cpu.txt 是 CPU 运行期依赖清单（含 torch、oneDNN 相关绑定等），requirements/build/cpu.txt是编译期依赖清单（cmake、ninja 等）；unsafe-best-match策略允许 uv 跨越 index 边界挑选最优匹配版本。若不需要可移植性而只要本机运行，跳过requirements/build/cpu.txt之外的额外编译依赖即可。

5.3 构建与安装

关键环境变量是VLLM_TARGET_DEVICE=cpu——它告诉 vLLM 的构建系统（见 setup.py 与 CMake 配置）本机没有 GPU，需编译 CPU 目标的内核与算子：

VLLM_TARGET_DEVICE=cpu uv pip install . --no-build-isolation

开发者模式（editable install，改动源码即时生效，适合调试 vLLM 本体）：

VLLM_TARGET_DEVICE=cpu python3 setup.py develop

可选地，构建一个可分发的可移植 Wheel，便于在其它同平台机器安装：

VLLM_TARGET_DEVICE=cpu uv build --wheel --no-build-isolation # 安装产物 uv pip install dist/*.whl

使用pip/python -m build的等价流程：

VLLM_TARGET_DEVICE=cpu python -m build --wheel --no-isolation pip install dist/*.whl

仓库中 docker/Dockerfile.cpu 的vllm-build阶段正是这一流程的容器化实现：设置VLLM_TARGET_DEVICE=cpu后执行python3 setup.py bdist_wheel --dist-dir=dist --py-limited-api=cp38，其中--py-limited-api=cp38对应上文 Wheel 文件中的cp38-abi3。此外该 Dockerfile 还会在编译前通过 build_rust.sh 先构建 Rust 前端vllm-rs，因此从源码构建本仓库最新代码时，工具链中还需具备 Rust 环境（直接使用官方 release 源即可自动处理）。

5.4 从源码构建后的LD_PRELOAD要求

从源码安装的 vLLM CPU，使用前除了 Intel OpenMP 还需要TCMalloc（内存分配器），两者都要加入LD_PRELOAD：

# 安装 TCMalloc（Intel OpenMP 随 vLLM CPU 一并安装） sudo apt-get install -y --no-install-recommends libtcmalloc-minimal4 # 定位动态库路径 sudo find / -iname *libtcmalloc_minimal.so.4 sudo find / -iname *libiomp5.so TC_PATH=... IOMP_PATH=... # 按顺序注入 export LD_PRELOAD="$TC_PATH:$IOMP_PATH:$LD_PRELOAD"

这与官方 Docker 镜像的做法完全一致：docker/Dockerfile.cpu在 x86_64 基础阶段直接写入ENV LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4:/opt/venv/lib/libiomp5.so"。也就是说，容器内的运行环境已经替你完成了这一步。

5.5 疑难排查（Troubleshooting）

[build-system] requires = [ "cmake>=3.26.1", ... "torch==X.Y.Z+cpu" # <------- 显式加上 +cpu 后缀 ]

之所以出现+cpu+cpu这类双后缀，通常是 pyproject 里torch==X.Y.Z与 PyTorch CPU index 提供的X.Y.Z+cpu无法精确匹配所致；显式声明+cpu后 pip/uv 才能命中 CPU 轮子。

六、方式三：使用 Docker 部署 CPU 版 vLLM

6.1 拉取官方预编译镜像

从 Docker Hub 拉取最新的 x86_64 CPU 镜像：

docker pull vllm/vllm-openai-cpu:latest-x86_64

拉取指定 vLLM 版本的镜像：

export VLLM_VERSION=$(curl -s https://api.github.com/repos/vllm-project/vllm/releases/latest | jq -r .tag_name | sed 's/^v//') docker pull vllm/vllm-openai-cpu:v${VLLM_VERSION}-x86_64

镜像使用示例（latest-x86_64标签对应linux/amd64，注意与 ARM 的vllm-openai镜像 tag 体系区分）：

docker run \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --env "HF_TOKEN=<secret>" \ vllm/vllm-openai-cpu:latest-x86_64 <args...>

参数含义：

• -v ~/.cache/huggingface:/root/.cache/huggingface：挂载 Hugging Face 缓存，避免容器内重复下载模型权重；
• -p 8000:8000：将容器内 OpenAI 兼容服务端口映射到宿主机；
• --env "HF_TOKEN=..."：注入私有模型所需的访问令牌；
• <args...>：追加 vLLM OpenAI server 参数（如模型名、--dtype），容器默认入口即vllm serve。

6.2 从源码构建 Docker 镜像

面向目标 CPU 构建（默认构建会使用宿主机架构/指令集）：

docker build -f docker/Dockerfile.cpu \ --build-arg VLLM_CPU_X86=<false (default)|true> \ # 用于交叉编译 --tag vllm-cpu-env \ --target vllm-openai .

VLLM_CPU_X86=true用于在交叉编译场景下显式开启 x86 ISA（AVX2/AVX512）支持，例如在 arm64 构建机上产出 amd64 镜像时使用。仓库里的 docker/Dockerfile.cpu 会校验该参数：在linux/arm64下设置VLLM_CPU_X86会直接报错退出，防止混用 ISA 标志。该文件还支持PYTHON_VERSION=3.10|3.11|3.12|3.13、ENABLE_AMX_FP8等构建参数。

AMD Zen 优化镜像（仅linux/amd64）：vllm-openai-zen目标在默认vllm-openai镜像之上通过vllm[zen]extra 额外安装zentorch，使运行时自动激活ZenCpuPlatform：

docker build -f docker/Dockerfile.cpu \ --tag vllm-cpu-zen-env \ --target vllm-openai-zen .

该镜像接受的参数与环境变量与vllm-openai一致（见下文 6.3），无需额外 flag 即可启用 Zen 优化；关于运行时行为与受支持 dtype 的注意事项见 AMD Zen 优化章节。

6.3 启动 OpenAI 兼容服务

自建镜像启动 CPU 推理服务的标准命令如下：

docker run --rm \ --security-opt seccomp=unconfined \ --cap-add SYS_NICE \ --shm-size=4g \ -p 8000:8000 \ -e VLLM_CPU_KVCACHE_SPACE=<KV cache space> \ vllm-cpu-env \ meta-llama/Llama-3.2-1B-Instruct \ --dtype=bfloat16 \ other vLLM OpenAI server arguments

• --security-opt seccomp=unconfined与--cap-add SYS_NICE：放开容器对 NUMA 相关系统调用（如get_mempolicy、migrate_pages）的限制，详见下一节；
• --shm-size=4g：增大/dev/shm，满足多进程/多 rank 数据交换需求；
• VLLM_CPU_KVCACHE_SPACE：给 CPU 后端分配的 KV cache 空间（GiB），见"运行时环境变量"一节；
• --dtype=bfloat16：CPU 上推荐显式使用 bfloat16（原因见 FAQ 部分）。

6.4 Docker 中 NUMA 系统调用受限的应对

部分容器运行时（Docker 等）默认 seccomp/capabilities 配置会拦截 vLLM 用到的 NUMA 系统调用（get_mempolicy、migrate_pages），表现为主机日志出现get_mempolicy: Operation not permitted。功能不受影响，但 NUMA 内存绑定/迁移优化不会生效，性能可能打折扣。官方建议的最小权限放行方案如下：

docker run ... --cap-add SYS_NICE --security-opt seccomp=unconfined ... # 1) --cap-add SYS_NICE 用于解决 get_mempolicy 的 EPERM 问题； # 2) --security-opt seccomp=unconfined 用于放行 migrate_pages（供 numa_migrate_pages() 使用）； # 若不能接受关闭 seccomp，可基于 runtime 默认 seccomp 配置自定义 profile， # 将 migrate_pages 加入 SCMP_ACT_ALLOW 列表。

--privileged=true也能达到目的但权限过大，一般不推荐。在 Kubernetes 中可用如下securityContext等价配置：

securityContext: seccompProfile: type: Unconfined capabilities: add: - SYS_NICE

七、AMD Zen 优化（AMD Zen Optimizations）{#amd-zen-optimizations}

在 AMD Zen CPU 上，vLLM 会自动选择ZenCpuPlatform（CpuPlatform的子类），将线性层（Linear/GEMM）调度到基于zentorch明确注释了这一行为：模型加载期（vllm/model_executor/layers/utils.py的 dispatch 逻辑）会把线性算子路由到zentorch_linear_unary，当VLLM_ZENTORCH_WEIGHT_PREPACK=1时还会在加载阶段用zentorch_weight_prepack_for_linear预先重排权重。

7.1 自动检测规则（Detection rules）

ZenCpuPlatform的启用需要同时满足以下全部条件：

1. vLLM 面向 CPU 构建（wheel 带+cpu或VLLM_TARGET_DEVICE=cpu编译）；
2. /proc/cpuinfo报告AuthenticAMD且包含avx512；
3. import zentorch成功。

否则 vLLM 回退到默认的CpuPlatform（oneDNN / sgl-kernel 路径）。

这段逻辑与仓库实现完全对应：vllm/platforms/init.py 中的_is_amd_zen_cpu()通过读取/proc/cpuinfo检查"AuthenticAMD" in cpuinfo and "avx512" in cpuinfo，随后在cpu_platform_plugin()里尝试import zentorch：成功则打印"AMD Zen CPU detected with zentorch installed, using ZenCpuPlatform."并返回ZenCpuPlatform；失败则回退CpuPlatform。也就是说，不需要任何额外开关参数，装好zentorch即自动生效。

7.2 支持的 dtype

float16在ZenCpuPlatform上不受支持。ZenCpuPlatform.supported_dtypes只对外宣称bfloat16与float32（见 vllm/platforms/zen_cpu.py 第 30-32 行）。因此以torch_dtype=float16声明的模型在加载时会被自动降级为bfloat16，并打印标准警告：

"Your device 'cpu' doesn't support torch.float16. Falling back to torch.bfloat16 for compatibility."

该警告由 vllm/config/model.py 抛出。这解释了为什么官方示例一律建议--dtype=bfloat16。

7.3 环境变量：VLLM_ZENTORCH_WEIGHT_PREPACK

• 默认值为1：在模型加载时就急切（eagerly）把线性层权重预打包成 ZenDNN 的 blocked 布局，从而消除每次推理时的布局转换开销；
• 设为0：关闭该行为（内存有限或排查问题时使用）。

7.4 如何启用 AMD Zen 优化

在 AMD Zen 4 / Zen 5 机器上，安装带zenextra 的 CPU Wheel，即可随发布拉入该版本配套测试过的zentorch：

export VLLM_VERSION=$(curl -s https://api.github.com/repos/vllm-project/vllm/releases/latest | jq -r .tag_name | sed 's/^v//') uv pip install "vllm[zen]" --extra-index-url https://wheels.vllm.ai/${VLLM_VERSION}/cpu --index-strategy first-index --torch-backend cpu

启动服务并确认平台选择日志：

vllm serve Qwen/Qwen3-0.6B 2>&1 | grep "AMD Zen CPU detected with zentorch installed"

如需查看每个线性层实际绑定到哪个内核，可加VLLM_LOGGING_LEVEL=DEBUG并检索CPU unquantized GEMM dispatch。从源码层面看，Zen 快速路径的可选内核包括：W4A16 GPTQ 的zentorch_woq_linear（vllm/model_executor/kernels/linear/mixed_precision/zentorch.py）、W8A8 dynamic 量化的zentorch_dynamic_qlinear（vllm/model_executor/kernels/linear/scaled_mm/zentorch.py）、以及 MoE 的zentorch_fused_moe（vllm/model_executor/kernels/linear/zentorch_utils.py）——这些实现均以current_platform.is_zen_cpu()作为分派前置条件。

八、CPU 运行时环境变量

无论走哪条安装路径，下面四个环境变量都直接影响 CPU 推理的资源利用率，x86 多路服务器场景尤其关键（完整清单见 CPU 安装总览 的 "Related runtime environment variables" 一节）：

• VLLM_CPU_KVCACHE_SPACE：指定 KV cache 大小（GiB）。例如VLLM_CPU_KVCACHE_SPACE=40表示预留 40 GiB 给 KV cache；取值越大，可并行处理的请求越多。应依据硬件配置与内存管理模式设定；官方 FAQ 指出未显式配置时 CPU 后端默认约为 4GB（注意环境变量段标注的默认值0表示“未显式开启”）。若某 TP rank 的权重分片大小 + KVCACHE_SPACE超过单个 NUMA 节点容量，worker 会因 OOM 以exitcode 9被杀死。
• VLLM_CPU_OMP_THREADS_BIND：指定专用于 OpenMP 线程的 CPU 核心。可设为 CPU id 列表、auto（默认）或nobind（不做核心绑定，继承用户自定义 OpenMP 变量）：
  • VLLM_CPU_OMP_THREADS_BIND=0-31：32 个 OpenMP 线程绑定在 0-31 号核心；
  • VLLM_CPU_OMP_THREADS_BIND=0-31|32-63：两个 tensor-parallel rank，rank0 的 32 线程绑 0-31，rank1 的 32 线程绑 32-63；
  • auto：每个 rank 的 OpenMP 线程分别绑定到各自 NUMA 节点的核心；
  • nobind：线程数由标准OMP_NUM_THREADS决定。
• VLLM_CPU_NUM_OF_RESERVED_CPU：每个 rank 预留（不交给 OpenMP）的核心数。仅在VLLM_CPU_OMP_THREADS_BIND=auto时生效；默认None，此时world_size == 1不预留、world_size > 1时每个 rank 预留 1 核。
• CPU_VISIBLE_MEMORY_NODES：限定 CPU worker 可见的 NUMA 内存节点，作用类似CUDA_VISIBLE_DEVICES；同样仅在auto绑定模式下生效，用于掩蔽节点或调整节点绑定顺序。

九、启动服务与性能调优 FAQ（x86 CPU）

以下经验来自 CPU 安装总览 的 FAQ，是 x86 平台落地时的直接参考。

9.1 选择什么 dtype？

• CPU 后端默认跟随模型自身的默认dtype；但由于 torch CPU 对 float16 的支持不稳定，一旦出现性能或精度问题，建议显式指定--dtype=bfloat16；
• 在 AMD Zen（ZenCpuPlatform）上，float16完全不受支持，只有bfloat16与float32可用（见 7.2）。

9.2 如何在 CPU 上启动 vLLM 服务？

在线服务建议预留 1-2 个 CPU 核给 serving 框架，避免 CPU 过订阅。例如 32 物理核平台上，把 31 号核留给框架、0-30 号核给推理线程：

export VLLM_CPU_KVCACHE_SPACE=40 export VLLM_CPU_OMP_THREADS_BIND=0-30 vllm serve facebook/opt-125m --dtype=bfloat16

或使用默认的 auto 线程绑定并显式预留 1 核：

export VLLM_CPU_KVCACHE_SPACE=40 export VLLM_CPU_NUM_OF_RESERVED_CPU=1 vllm serve facebook/opt-125m --dtype=bfloat16

注意：当world_size == 1时，仍建议手动为 vLLM 前端进程预留 1 个 CPU。

9.3 如何选择VLLM_CPU_OMP_THREADS_BIND？

默认的auto线程绑定适用于大多数场景：每个 OpenMP 线程绑定到独立物理核，各 rank 线程绑定到同一 NUMA 节点，并在world_size > 1时为每个 rank 预留 1 核。若遇到性能异常或绑定行为不符合预期，可先通过lscpu -e查看逻辑核与物理核的映射关系后手动绑定。

在启用超线程的平台上，例如 16 逻辑核 / 8 物理核的机器，建议只把 OpenMP 线程绑定到同一物理核组（0-7 或 8-15）的一半逻辑核上：

$ lscpu -e # CPU 列为逻辑核 ID，CORE 列为物理核 ID # 建议绑定逻辑核 0-7 或 8-15 $ export VLLM_CPU_OMP_THREADS_BIND=0-7 $ python examples/basic/offline_inference/basic.py

在启用 tensor parallel / pipeline parallel 的多路（multi-socket）NUMA 机器上，每个 NUMA 节点会被视为一个 TP/PP rank，务必让单个 rank 的核落在同一 NUMA 节点内，避免跨节点内存访问。

9.4 有哪些性能调优参数？

• 线程绑定与 KV cache 空间设置到位后，可通过htop观察运行 benchmark 时的核心占用率来确认生效；
• 建议--block-size取 32 的倍数（默认 128）；
• batch 大小是关键参数：batch 越大吞吐越高、越小延迟越低。两个核心参数：
  • --max-num-batched-tokens：单 batch 的 token 数上限，主要影响首 token（TTFT）性能。默认 Offline 推理4096 * world_size，在线服务2048 * world_size；
  • --max-num-seqs：单 batch 的序列数上限，主要影响输出 token 性能。默认 Offline 推理256 * world_size，在线服务128 * world_size。
• vLLM CPU 支持数据并行（DP）、张量并行（TP）与流水线并行（PP）以利用多路 socket 与多内存节点，详见 并行优化文档；若 socket/内存节点充足，推荐 DP、TP、PP 组合使用。

9.5 支持哪些量化方案？

vLLM CPU 支持以下量化（x86 与 s390x 均可用）：AWQ、GPTQ、compressed-tensor INT8 W8A8（W8A8 仅 x86/s390x）。在 AMD Zen 平台上，W4A16 GPTQ 与 W8A8 还会进一步走 7.4 节所述的 zentorch 加速内核。

9.6 支持哪些模型？

在 CPU 上经过验证支持的模型完整、实时列表见 Supported Models on CPU。官方建议为每个 CPU 支持模型配套的优化运行配置做基准测试（见总览文档 FAQ 的 Benchmark Suite 说明），并在配置 tensor-parallel-size 时匹配系统 NUMA 节点数（可用lscpu | grep "NUMA node(s):" | awk '{print $3}'查询；注意当前发布不支持tensor-parallel-size=6）。

小结

x86 CPU 是 vLLM CPU 后端覆盖最完整、社区最活跃的硬件分支：从 v0.17.0 起官方直接提供cp38-abi3预编译 Wheel，覆盖 FP32/FP16/BF16 推理与 OpenAI 兼容 serving；源码构建仅需确保gcc >= 12.3与VLLM_TARGET_DEVICE=cpu；Docker 侧则同时提供vllm-openai-cpu预构建镜像与vllm-openai-zen的 AMD Zen 优化目标。无论选择哪条路径，请牢记两件"必做"事项：为运行期配置好LD_PRELOAD（Wheel 需 Intel OpenMP，源码构建还需 TCMalloc），以及按机器拓扑设置VLLM_CPU_KVCACHE_SPACE与VLLM_CPU_OMP_THREADS_BIND。若你运行在 AMD Zen 4/5 上，装上vllm[zen]后即可在启动日志中看到ZenCpuPlatform自动接管线性层分派的提示，无需任何手工配置。

【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm