VPS 上 Ollama 和 llama.cpp 怎么选？

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

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

如果您希望获得一个可按名称获取模型、无需持续维护即可运行的服务，请运行 Ollama。如果 VPS 资源较少，并且您需要精确选择模型文件、上下文大小和线程数，请直接运行 llama.cpp，因为在小型 VPS 上，这些设置中的每一项都会占用您并不具备的内存。

各项目的实际定位

llama.cpp 是基于 ggml 库实现的 C 和 C++ Transformer 推理程序。它读取 GGUF 文件。GGUF（GGML universal file format）是一种单文件容器，其中包含模型运行所需的权重、分词器和元数据。该项目会为不同任务提供独立的二进制文件。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 仓库中发布的文件大小，数据读取于 2 August 2026，并已从字节转换为 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 会在模型看到文档前被丢弃，因此模型只读了一半文件，却会自信地给出错误答案。可通过守护进程上的 OLLAMA_CONTEXT_LENGTH 调高该值，也可在 Modelfile 中使用 PARAMETER num_ctx 设置。llama.cpp 也没有值得信任的默认值。请显式设置 -c，并确认实际设置的值。

您很少会看到的内存计算

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

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

因此，在 4k 上下文下，Q4_K_M 8B 模型需要约 4.58 GiB 的权重空间，此外还需要约 0.5 GiB 的缓存空间和运行时本身占用的内存。它无法装入 4 GiB RAM。在 8 GiB RAM 的机器上可以运行，并且还有一定余量。如果在同一台 8 GiB 机器上将上下文提升到 32k，缓存本身就会耗尽剩余内存。在模型加载期间使用 free -h 实时观察内存占用，不要相信未经实测的估算。如果目标模型明显超过 8B，那么仅使用 CPU 的 VPS 上运行 27B 模型时的相同计算，可以说明 8 到 64 GB 的各个内存档位实际能容纳什么。

Ollama 会进一步放大这一影响。OLLAMA_NUM_PARALLEL 的默认值为 1，模型所需内存会按该值与上下文长度的乘积增长。两者同时提高时，daemon 会悄然申请数倍于预期的 RAM。相同的计算也决定了同时用户数的上限，因为每个并发请求都需要独立的一部分 KV cache。这也解释了为什么服务器单人使用时运行正常，五人同时使用就会停滞。

轴 2：您必须管理的守护进程

Ollama 安装脚本会写入一个 systemd 单元，创建一个 ollama 系统用户，并启用该服务。您无需自行编写这些配置，即可获得完整的生命周期管理。配置通过 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 /api/chat。此外，它也提供 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 的 VPS 可以缓慢运行小型模型。这是准确的总结，关键在于确定它的适用边界。在围绕它进行设计前，先进行测量：

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

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

CPU 上可用的场景：使用 1B 到 4B 模型进行分类、信息提取、简短摘要或路由。响应会在数秒内返回，内存也适合普通方案。CPU 上不可用的场景：达到阅读速度的交互式聊天、代码助手、长文档处理，以及包含多次连续调用的代理循环。一个循环如果连续发起十二次调用，每次耗时四秒，就要等待一分钟才会产生结果。如果原本计划使用代码助手，让代理调用自行托管的模型说明了小型本地模型真正擅长哪些任务，以及哪些任务必须继续使用托管 API。

如果性能指标不满足要求，有两种解决方向。如果问题是并发，即许多用户同时访问一个模型，应更换推理引擎；Ollama 与 vLLM 的并发服务对比对此进行了说明。如果问题是原始速度，则应选择配备 GPU 的 VPS，此时 -ngl 才具有实际意义。在此之前，应先获取硬件本身的基准数据，因为磁盘和内存带宽对加载时间的影响不亚于 CPU。可重复执行的 VPS 基准测试值得投入一小时。

安装 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 unit 或服务用户，因此需要自行创建。Ollama 在 VPS 上的完整操作指南将逐步介绍服务配置过程。

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

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 扩展。