VPS上选Ollama还是llama.cpp？CPU部署与内存

Ollama 与 llama.cpp：您要运行哪一层？

Ollama 和 llama.cpp 并不是问题所暗示的竞争关系。llama.cpp 是推理引擎：它加载模型文件，并将提示词转换为 token。Ollama 是模型管理器、后台 daemon 和 HTTP API，运行在该引擎之上。Ollama 的 README 仍将 llama.cpp 列为其推理后端（截至 2 August 2026 检查）。因此，真正的问题是您希望在 VPS 上运行哪一层，而不是哪一个更快。

如果您需要一个可按名称获取模型并在无人值守时持续运行的服务，请运行 Ollama。如果 VPS 资源较少，而您需要精确选择模型文件、上下文大小和线程数，请直接运行 llama.cpp。因为在小型 VPS 上，这些设置中的每一项都会占用您无法提供的内存。

每个项目的实际定位

llama.cpp 是基于 ggml 库实现的 C 和 C++ Transformer 推理程序。它读取 GGUF 文件。GGUF（GGML 通用文件格式）是一个单文件容器，其中包含引擎运行模型所需的权重、分词器和元数据。该项目针对不同任务提供独立的二进制文件。llama-server 是 HTTP 服务器，llama-cli 是交互式提示程序，llama-bench 用于测量吞吐量。其发布版本使用构建编号标记，而不是语义化版本号。当前标记为 b10224，发布于 2026 年 8 月 2 日，并且几乎每个工作日都会发布新标记。

Ollama 是一个 Go 程序。使用 ollama serve 启动的后台守护进程负责加载模型并处理 HTTP 请求，命令行客户端则与该守护进程通信。两者背后都有一个位于 ollama.com 的注册表，其中存放预打包的模型。Ollama 使用语义化版本，v0.32.5 于 2026 年 7 月 27 日发布。ollama pull 会连同提示模板和一组默认参数一起获取 GGUF 文件，然后在 Linux 上将其存储到 /usr/share/ollama/.ollama/models 下。

这类打包方式就是两者的全部差异。Ollama 会替您决定量化方式、模板和上下文长度，并提供一个需要记住的名称。llama.cpp 不会替您做任何决定，而是提供各种标志。

坐标轴 1：模型和量化控制

量化会将每个权重从 16 位或 32 位缩减到 4 位、5 位或 8 位。这使 80 亿参数模型能够装入普通 VPS 的 RAM。了解命名模式后，GGUF 名称很容易读懂：Q4_K_M 表示 4 位 K 量化和中等大小。数字越大，保留的精度越高，占用的内存也越多。

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

这些是 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF Hugging Face 仓库中发布的文件大小，数据读取于 2026 年 8 月 2 日，并已从字节换算为 GiB。同一模型有 6 个构建版本，最小文件为 2.96 GiB，最大文件为 7.95 GiB。常见的默认选项 Q4_K_M 为 4.58 GiB。在 4 GiB VPS 上，这个选择直接决定模型是否能加载。

使用 llama.cpp 时，需要指定文件，因此由您自行选择对应的行。

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c 是 token 数量形式的上下文大小，-t 是线程数，-ngl 设置移至 GPU 的层数（仅使用 CPU 的服务器上设为 0）。所有参数都需要您明确指定。

使用 Ollama 时，量化版本会随您拉取的标签一起确定，ollama ls 可显示磁盘上实际存在的内容。如果仓库没有您需要的构建版本，请自行导入 GGUF。先写入一个 Modelfile：

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

然后构建并检查结果：

ollama create llama31-q4 -f ./Modelfile
ollama ls

上下文长度是最容易引发问题的设置。Ollama 会根据可用 VRAM 选择默认值，没有 GPU 的服务器会使用最小档位：4096 个 token。向它发送一份包含 20,000 个 token 的文档时，多出的 token 会在模型看到文档之前被丢弃。因此，模型只读了一部分文件，却可能给出看似确定、实际错误的答案。可在 daemon 上使用 OLLAMA_CONTEXT_LENGTH 调高该值，或在 Modelfile 中使用 PARAMETER num_ctx 调高该值。llama.cpp 也没有值得依赖的默认值。请显式设置 -c，并确认实际设置的值。

内存计算：文档通常不会展示的部分

模型文件并不是全部开销。KV 缓存（键值缓存）会为上下文中的每个 token、每一层保存一条记录，并且会随对话增长。

以 Llama 3.1 8B 为例。该模型有 32 层、8 个键值头，头维度为 128。f16 中，每个 token 的键和值各占 2 bytes，因此每层的开销为 2 x 8 x 128 x 2 = 4096 bytes。32 层合计为每个 token 128 KiB。4096 token 的上下文需要 512 MiB，32,768 token 的上下文需要 4 GiB。

因此，Q4_K_M 8B 模型在 4k 上下文下需要约 4.58 GiB 的权重空间，另加约 0.5 GiB 的缓存空间以及运行时本身的开销。它无法装入 4 GiB RAM。在 8 GiB RAM 中可以运行，并留有一定余量。如果在同一台 8 GiB 主机上将上下文提升到 32k，缓存本身就会耗尽可用余量。模型加载期间使用 free -h 实时观察内存，不要相信未经测量的估算值。

Ollama 会进一步放大这一开销。OLLAMA_NUM_PARALLEL 的默认值为 1，模型所需的内存会按该值与上下文长度的乘积增长。两者同时提高时，daemon 会悄然请求数倍于预期的 RAM。

轴 2：您需要运维的守护进程

Ollama 安装脚本会写入一个 systemd 单元，创建 ollama system 用户，并启用该服务。无需自行编写这些配置，即可获得完整的生命周期管理。配置通过 systemd 完成：

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE 在 CPU VPS 上比在其他环境中更重要。默认情况下，模型会在内存中保留 5 分钟，然后卸载。下一次请求必须先从磁盘重新读取整个文件，才能生成响应。因此，在慢速存储上，重新加载一个 4.58 GiB 的模型会将 2 秒的响应延长到 30 秒。延长 keep-alive 可以消除延迟，但会永久占用 RAM。这两者都会产生实际成本。请选择影响较小的一项。

llama.cpp 不提供守护进程，因此您需要自行编写单元，并将其保存为 /etc/systemd/system/llama-server.service：

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

使用 sudo systemctl enable --now llama-server 启用该服务。此后，进程会在其整个生命周期内保持模型加载。空闲时不会卸载模型，因此不会出现重新加载导致的延迟，但除非停止服务，否则也无法回收这部分内存。如果您不熟悉编写单元文件，这与在 VPS 上使用 systemd 运行自有服务采用的是相同模式。

轴 3：应用将调用的 API

这一点现在已经大幅收窄。两个项目目前都支持 OpenAI chat 格式，因此大多数客户端库只需修改基础 URL，即可用于其中任意一个项目。

Ollama 监听 127.0.0.1:11434。其 OpenAI 兼容路由为 http://localhost:11434/v1/chat/completions，同时还在 /api/chat 提供原生 API。此外，它还提供了 Anthropic 兼容路由的文档。

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server 监听 127.0.0.1:8080，提供 /v1/chat/completions、/v1/completions 和 /v1/embeddings，以及自有的 /completion 端点和内置 Web UI。它还提供 Ollama 没有的运维路由：/health 用于就绪探针，/props 用于查看已加载模型的设置，/slots 用于查看每个请求槽当前执行的操作，/metrics 使用 Prometheus 格式。如果您计划监控此服务，这一差异可能就是决定因素。

两个服务器都不会自动为您启用身份验证。出于合理的安全考虑，二者默认只监听回环地址。请通过 SSH 隧道或反向代理访问它们，绝不要将 11434 或 8080 暴露到互联网。

CPU-only VPS 能实际做到什么

CPU-only VPS 可以缓慢运行小型模型。准确地说，关键在于了解它的能力边界。围绕它设计方案前，请先进行测量：

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp 列表示提示词处理速度，tg 列表示 token 生成速度，单位都是每秒 token 数。在共享 vCPU 方案中，8B 模型使用 Q4_K_M 时，tg 通常只有个位数。最影响体验的是提示词处理：模型必须先处理完整提示词，才会生成第一个输出 token，因此较长的系统提示词会让每个请求都额外等待。

CPU 可以胜任：使用 1B 到 4B 模型进行分类、信息提取、简短摘要或路由。响应会在数秒内返回，内存也适合普通方案。CPU 无法胜任：以阅读速度进行交互式聊天、代码助手、长文档处理，或包含多个连续调用的 agent 循环。一个执行 12 次调用、每次耗时 4 秒的循环，在产生任何结果前就需要 1 分钟。

如果性能数据不满足要求，有两种解决方向。如果问题是并发，即许多用户同时访问同一个模型，应更换推理引擎；Ollama 与 vLLM 并发服务能力的比较会介绍这一点。如果问题是原始速度不足，答案是配备 GPU 的 VPS，此时 -ngl 才开始具有实际意义。在采取上述措施前，请先为硬件本身建立基线，因为磁盘和内存带宽对加载时间的影响不亚于 CPU。可重复执行的 VPS 基准测试值得投入 1 小时。

安装 llama.cpp，并固定构建版本

这两个项目每周都会更新，因此请记录已部署的版本。上游提供的一行命令会安装当前构建版本：

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

如需固定特定构建版本，请改为从 releases 页面获取预构建 tarball。b10224 是截至 2 August 2026 的当前标签：

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

也可以从源代码构建同一标签：

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev 是 HTTPS 功能所需的官方文档依赖项。编译需要几分钟，并且需要的 RAM 多于最小规格的计划所提供的容量，因此请在更大规格的服务器上构建；如果小规格服务器内存不足，再将二进制文件复制过去。

安装 Ollama 并固定版本

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

该脚本会读取 OLLAMA_VERSION，因此可以固定到已知稳定的版本，而不是直接使用今天早上发布的版本。v0.32.5 于 27 July 2026 发布。如果不希望将脚本通过管道传给 shell，也可以手动安装：

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

手动安装不会创建 systemd 单元或服务用户，因此需要自行创建。完整的 VPS 上 Ollama 部署指南将逐步介绍服务配置过程。

故障模式以及你将看到的字符串

Ollama 拒绝加载模型。 ollama run 返回以下格式的一行：

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama 会在加载前检查大小，因此会快速失败并说明原因。向下选择一行量化级别，降低上下文长度，或选择更小的模型。

llama.cpp 不会失败，而是运行极慢。 llama.cpp 默认使用内存映射加载 GGUF，因此大于 RAM 容量的文件仍然可以启动。随后，内核会在每个 token 上从磁盘反复换入和换出权重，生成速度会降至每个 token 几秒，同时磁盘占用率达到 100%。传入 --no-mmap 可强制执行实际内存分配，使其立即失败，而不是性能逐渐下降。内核介入时，dmesg 会显示原因：

Out of memory: Killed process 1234 (llama-server)

模型文件完全无法加载。 为比你的引擎更新的模型系列构建的 GGUF，会报错并指出引擎不识别的架构：

error loading model architecture: unknown model architecture: 'qwen3next'

解决方法是升级引擎，而不是更换文件。这就是固定版本的代价，也是记录构建编号的原因。你需要知道当前是从哪个版本升级。

API 在本机可以响应，但你的应用无法访问。 Ollama 绑定到 127.0.0.1:11434，因此其他主机会收到连接被拒绝的错误。只有当该端口位于防火墙或私有网络之后时，才通过 systemctl edit ollama 设置 OLLAMA_HOST=0.0.0.0:11434，因为 API 前面没有身份验证。

暂停后收到的第一条响应非常慢。 5 分钟空闲卸载已经发生，模型需要再次从磁盘读取。就在请求前运行 ollama ps，如果显示没有加载任何内容，即可确认这一点。提高 OLLAMA_KEEP_ALIVE。

那么应该运行哪一个？

如果您希望由系统代为管理模型，并且无需额外配置即可获得 OpenAI 风格的端点，请运行 Ollama。这是首次部署的合适默认选择，也适用于模型选择会持续变化的场景。

如果内存非常有限，您需要自行选择量化行；如果您需要使用 /health、/slots 和 /metrics 进行监控；或者如果您需要 Ollama 未提供的选项，请直接运行 llama.cpp。在 VPS 上，如果模型勉强才能装入内存，这是更稳妥的选择，因为决定模型能否装入内存的设置，正是 Ollama 会代您选择的设置。

同时运行两者很正常。使用 Ollama 进行实验，使用 llama.cpp 运行投入生产的唯一模型，并确保它不会被自动更换。

FAQ

Ollama 只是 llama.cpp 的封装吗？

基本是，但这个封装会执行实际工作。Ollama 的 README 将 llama.cpp 列为其推理后端（截至 2026 年 8 月 2 日已核实）。Ollama 在此基础上增加了模型注册表、将聊天消息转换为提示词的提示词模板、一组默认采样参数、支持空闲卸载的守护进程，以及 HTTP API。在设置完全相同的情况下比较每秒生成的 token 数，实际上是在比较同一个引擎自身的表现。您真正需要选择的是管理层。

仅使用 CPU 的 VPS 上哪个更快？

它们共用同一个引擎，因此在模型文件、量化方式、上下文大小和线程数相同的情况下，性能通常非常接近。人们报告的差异通常来自不同的默认设置，最常见的是上下文长度和线程数，而不是引擎本身。请使用 llama-bench -m <file> -p 512 -n 128 进行测试，并在相信任何已发布的数据前，先比较您自己的服务器上的 tg 列。

可以在 Ollama 中使用自己的 GGUF 文件吗？

可以。将文件放到服务器上，编写一个 Modelfile，使其第一行是 FROM ./your-model.gguf，然后添加所需的 PARAMETER 行，例如 num_ctx，最后运行 ollama create your-name -f ./Modelfile。ollama ls 会将它与从注册表拉取的其他模型一起列出。如果注册表中没有您需要的量化版本，可以通过这种方式使用它。

8B 模型需要多少 RAM？

需要为模型文件大小、KV 缓存和运行时分别预留内存。Llama 3.1 8B 的 Q4_K_M 构建版本在磁盘上约占 4.58 GiB，4096 token 的上下文还会增加约 512 MiB 缓存。因此，8 GiB RAM 足够，4 GiB 不够。缓存大小会随上下文增长：同一模型使用 32,768 token 的上下文时，仅缓存就需要约 4 GiB。使用 Ollama 时，还要注意内存需求也会随 OLLAMA_NUM_PARALLEL 增长。