没有 GPU，还能跑大模型吗？vLLM vs llama.cpp 实测对比

tmlx3I081

180人浏览 · 2026-07-02 14:36:24

tmlx3I081 · 2026-07-02 14:36:24 发布

地推理领域的“常驻选手”。

那么问题来了：

同样是在纯 CPU 环境下，vLLM 和 llama.cpp 的实际表现究竟如何？

这篇文章将基于 GPUStack 进行完整实测，对比两者在 CPU 场景下的部署与推理表现。

测试环境使用三台同规格服务器，配置均为 4 vCPU + 16GB 内存。其中：

1 台作为 GPUStack Server
1 台用于部署 vLLM-CPU
1 台用于部署 llama.cpp

两组测试分别运行在独立 Worker 节点上，尽量减少相互干扰带来的性能影响。

全文分为以下几个部分：

安装 GPUStack，并初始化集群
添加 vLLM-CPU 自定义后端
部署模型并测试
启用 llama.cpp 社区后端
部署 GGUF 模型并测试
更多模型实测
高性能 CPU 环境实测
压测结果分析
小结

安装 GPUStack，并初始化集群

在开始测试之前，需要先完成 GPUStack 的安装与集群初始化。

考虑到这部分内容此前已经进行过较为完整的介绍，这里不再重复展开。如果你是第一次接触 GPUStack，可以先阅读下面这篇安装教程：

<这里留空，会插入公众号已发表的文章-GPUStack v2.1.2 安装教程>

添加纯 CPU Worker 节点

前文演示的是 NVIDIA GPU 节点的添加流程，而本文主要测试纯 CPU 推理，因此这里额外介绍如何实际添加一个 CPU Worker 节点。

示例命令如下：

docker run -d --name gpustack-worker \
  -e "GPUSTACK_RUNTIME_DEPLOY_MIRRORED_NAME=gpustack-worker" \
  -e "GPUSTACK_TOKEN=gpustack_8a9deabfdce64e0b_d5394d64567d6a304eaaa8d627e494db" \
  --restart=unless-stopped \
  --privileged \
  --network=host \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume gpustack-data:/var/lib/gpustack \
  gpustack/gpustack:v2.1.2 \
  --server-url http://100.109.241.71 \
  --worker-ip 100.101.65.74

与 GPU 节点不同，这里省略了 --runtime 参数。

命令中的关键参数说明如下，可根据实际环境进行调整：

GPUSTACK_TOKEN：Worker 与 Server 之间的认证 Token，可在 UI 中生成添加 Worker 的命令时获取。
--server-url：GPUStack Server 服务地址。
--worker-ip：Server 与 Worker 通信的 IP 地址。如果机器有多个网卡，或者默认 IP 不是期望值，需要手动指定。

节点添加完成后，可在 GPUStack 控制台查看对应 Worker 是否已成功上线：

添加 vLLM-CPU 自定义后端

目前 GPUStack 默认提供的是 GPU 版本 vLLM，因此这里需要手动添加 CPU 版本后端。

暂不支持直接在内置 vLLM 后端中通过添加自定义版本实现，这会导致模型部署 Pending。

进入 GPUStack 控制台（Web UI）后，在左侧边栏中导航到推理后端：

按下图所示填写配置：

或者使用 YAML模式，填入以下内容：

backend_name: vLLM-CPU-custom
health_check_path: /ping
default_run_command: "{{model_path}} --port {{port}} --host {{worker_ip}} --served-model-name {{model_name}}"
version_configs:
  0.21.0:
    image_name: swr.cn-south-1.myhuaweicloud.com/gpustack/vllm-openai-cpu:v0.21.0
    custom_framework: cpu

从微信公众号复制出的内容可能包含特殊符号，可直接使用我们准备好的 yaml 文件：https://gpustack-cn-blogs.oss-cn-shanghai.aliyuncs.com/assets/cpu/vllm-cpu.yml

实际配置使用的国内镜像，vLLM 官方原版镜像地址为：vllm/vllm-openai-cpu:v0.21.0

添加完成后，效果如图所示：

部署模型并测试

这里我们选择最近发布的 openbmb/MiniCPM5-1B 作为测试模型。

作为一款 1B 级别的小模型，MiniCPM5-1B 在轻量化场景下表现较为突出，近期一直位于 Hugging Face 热门模型榜单前列，因此比较适合作为本次纯 CPU 推理测试对象。

打开部署页面，在右上角 部署模型 菜单中选择 Hugging Face 或 ModelScope：

随后在弹出的模型窗口中搜索：

openbmb/MiniCPM5-1B

调整部署参数

1. 调整推理引擎

将推理后端切换为前面创建的：

vLLM-CPU

2. 绑定调度节点

由于本文分别使用独立 Worker 节点测试 vLLM 与 llama.cpp，因此这里需要手动绑定对应 Worker。

3. 调整启动参数与环境变量

这里使用的关键参数如下：

--dtype=bfloat16

由于 PyTorch CPU 对 float16 的支持并不稳定，因此这里显式指定 bfloat16，避免出现性能异常或精度问题。
--max-model-len=8192

本次测试机器配置较低，因此这里适当降低上下文长度，减少内存压力。后续 llama.cpp 测试中也会保持一致，以尽量保证测试条件统一。
VLLM_CPU_KVCACHE_SPACE=8

指定 CPU KV Cache 可使用容量，单位为 GB。这里设置为 8，表示允许 vLLM 使用约 8GB 内存作为 KV Cache。
VLLM_CPU_OMP_THREADS_BIND=nobind

禁用 OpenMP 线程绑定到固定 CPU 核心，实际测试中通常能够提高 CPU 利用率，并减少部分场景下的线程调度限制。

更多配置选项请访问 vLLM CPU 官方文档：CPU - vLLM

参数配置完成后，点击保存按钮即可开始部署模型。

试验场测试

测试时的系统资源检测情况：

启用 llama.cpp 社区后端

相比 vLLM，llama.cpp 在 CPU 推理领域已经发展多年。

其核心特点包括：

原生 CPU 优化
GGUF 量化生态成熟
内存占用较低
非常适合边缘设备
模型服务启动迅速

GPUStack 社区后端已经支持 llama.cpp，因此这里只需要启用即可。

部署 GGUF 模型

接下来部署 GGUF 格式的 MiniCPM5-1B 模型：

openbmb/MiniCPM5-1B-GGUF

为了尽量保证测试条件一致，这里选择与 vLLM-CPU 相同规格的 MiniCPM5-1B-F16.gguf，而没有使用更小体积的量化版本。

调整部署参数

1. 调整推理引擎

将推理后端切换为：

llama.cpp

2. 绑定调度节点

这里同样绑定到独立 CPU Worker 节点，避免与 vLLM 测试环境互相影响。

3. 调整启动参数与环境变量

本文测试使用的核心参数如下：

--ctx-size 32768

设置 KV Cache 可用的总上下文容量。由于本文测试中 --parallel 设置为 4，因此这里将总上下文设置为 32768，相当于为每个并发请求预留约 8192 上下文长度，以尽量与 vLLM-CPU 测试中的 --max-model-len=8192 保持一致。

注意：llama.cpp 的 --ctx-size 并不是为每个并发请求严格独立分配的，更接近于多个请求共享同一块 KV Cache 容量。

--parallel 4

设置并行请求槽位数量为 4，允许 llama.cpp 同时处理多个请求。
--threads 4

设置生成阶段使用的 CPU 线程数。当前测试机器为 2C4T，因此这里直接使用全部逻辑线程。
--threads-batch 4

设置 Batch 处理阶段线程数，与 --threads 保持一致。

更多配置选项请访问 llama.cpp 官方文档：llama.cpp/tools/server/README.md at master · ggml-org/llama.cpp · GitHub

参数配置完成后，点击保存即可开始部署模型。

试验场测试 GGUF 模型

测试时的系统资源检测情况：

从 CPU 占用情况来看，llama.cpp 基本能够持续占满全部逻辑核心，整体 CPU 利用率相比 vLLM-CPU 更高。

高性能 CPU 环境实测

为了观察纯 CPU 推理在更充足资源下的表现，我们将测试环境升级为：

CPU：AMD EPYC Genoa 32 vCPUs
内存：128 GiB
操作系统：Ubuntu 24.04 LTS
特性支持：AVX-512F 指令集

相较于之前的 2C4T + 16GB 环境，这套高性能环境能够充分发挥 CPU 并行能力，同时支持高级向量化指令，对 vLLM-CPU 和 llama.cpp 的推理性能都有一定提升。

本次测试以 Qwen3-0.6B 模型为对象，分别在 vLLM-CPU 与 llama.cpp 后端上进行部署和实测。

部署方式与前文一致，只是在 CPU 资源配置上充分利用新机器：

亚马逊云科技技术品牌专区

更多推荐

百万Token不是数字游戏：Kimi K3完整吞下10万行代码库后，我测出了它的真实理解力

亚马逊云科技技术品牌专区

洛雪音乐音源终极指南：免费获取全网无损音乐的完整方案

洛雪音乐音源项目为音乐爱好者提供了一个强大的开源解决方案，通过社区维护的多样化音源配置，让用户能够免费获取QQ音乐、网易云、酷狗、酷我、咪咕五大平台的音乐资源。这个项目不仅支持跨平台音乐聚合，还提供了无损音乐配置方案，确保用户能够享受到高品质的音频体验。## 🎯 为什么选择洛雪音乐音源？**核心优势解析**洛雪音乐音源项目经过多次测试和迭代，已经成为目前最稳定、最全面的开源音乐聚合方

亚马逊云科技技术品牌专区

为什么选择Warcraft Font Merger？轻量、快速、多功能的字体工具解析

Warcraft Font Merger是一款专为魔兽世界玩家打造的字体合并与补全工具，它能够帮助玩家轻松解决游戏中的字体显示问题，让游戏界面更加美观、易读。无论是中文显示乱码，还是特殊符号缺失，这款工具都能提供高效的解决方案。## 一、轻量级设计，不占用过多系统资源Warcraft Font Merger采用轻量级架构，整个工具包体积小巧，不会占用过多的硬盘空间和系统内存。这意味着即使在

亚马逊云科技技术品牌专区

所有评论(0)

查看更多评论

tmlx3I081

@tmlx3I081

已为社区贡献3条内容

没有 GPU，还能跑大模型吗？vLLM vs llama.cpp 实测对比

tmlx3I081

安装 GPUStack，并初始化集群

添加纯 CPU Worker 节点

添加 vLLM-CPU 自定义后端

部署模型并测试

调整部署参数

1. 调整推理引擎

2. 绑定调度节点

3. 调整启动参数与环境变量

试验场测试

启用 llama.cpp 社区后端

部署 GGUF 模型

调整部署参数

1. 调整推理引擎

2. 绑定调度节点

3. 调整启动参数与环境变量

试验场测试 GGUF 模型

更多模型实测

Qwen3-0.6B & Qwen3-0.6B-GGUF

Qwen3.5-0.8B & Qwen3.5-0.8B-GGUF

gemma-4-E2B-it-GGUF

高性能 CPU 环境实测

所有评论(0)

tmlx3I081

没有 GPU，还能跑大模型吗？vLLM vs llama.cpp 实测对比

tmlx3I081

安装 GPUStack，并初始化集群

添加纯 CPU Worker 节点

添加 vLLM-CPU 自定义后端

部署模型并测试

调整部署参数

1. 调整推理引擎

2. 绑定调度节点

3. 调整启动参数与环境变量

试验场测试

启用 llama.cpp 社区后端

部署 GGUF 模型

调整部署参数

1. 调整推理引擎

2. 绑定调度节点

3. 调整启动参数与环境变量

试验场测试 GGUF 模型

更多模型实测

Qwen3-0.6B & Qwen3-0.6B-GGUF

Qwen3.5-0.8B & Qwen3.5-0.8B-GGUF

gemma-4-E2B-it-GGUF

高性能 CPU 环境实测

所有评论(0)

温馨提示：您尚未绑定手机号

tmlx3I081