VPS上Ollama还是llama.cpp：CPU部署怎么选

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 通用文件格式）是一个单文件容器，其中包含引擎运行模型所需的权重、分词器和元数据。该项目针对不同任务提供独立的二进制文件。llama-server 是 HTTP 服务器，llama-cli 是交互式提示程序，llama-bench 用于测量吞吐量。版本发布按构建编号标记，而不是按语义化版本标记。当前标记为 b10224，于 2026 年 8 月 2 日发布，并且每个工作日通常都会发布新的标记。

Ollama 是一个 Go 程序。使用 ollama serve 启动的后台 daemon 会加载模型并响应 HTTP 请求，命令行客户端则与该 daemon 通信。这两者背后都有一个位于 ollama.com 的注册表，其中存放预先打包的模型。Ollama 使用语义化版本，v0.32.5 于 2026 年 7 月 27 日发布。ollama pull 会同时获取 GGUF、提示模板和一组默认参数，然后在 Linux 上将它们存储到 /usr/share/ollama/.ollama/models 下。这些文件位于根磁盘上，每个文件可能占用数 GB。因此，在根卷大小为 25 GB 的 VPS 上，第三次下载将磁盘占满之前，最好先了解pull 会留下哪些文件，以及如何将模型目录移到其他位置。

这就是两者的全部区别。Ollama 会替你决定量化方式、模板和上下文长度，并提供一个易于记忆的名称。llama.cpp 不做任何决定，而是为你提供各种 flags。

模型与量化控制

量化会将每个权重从 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
  }
]

这些是 Hugging Face 的 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 仓库中公布的文件大小，数据读取于 2 August 2026，并已从字节转换为 GiB。同一个模型有 6 个构建版本，最小文件为 2.96 GiB，最大文件为 7.95 GiB。常用的默认版本 Q4_K_M 为 4.58 GiB。在 4 GiB VPS 上，这个选择会直接决定模型能否加载。大小只是这个决定的一半，因为能负担得起的版本不一定值得使用，而Q4、Q8 和 fp16 对回答质量的实际影响才能说明额外的 GiB 是否带来可察觉的收益。

使用 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 提高该值。如果只有一个任务需要更大的上下文窗口，可以按请求设置 num_ctx，而不是对整个服务器统一设置，这样 daemon 处理其他任务时不会为它们保留额外缓存。llama.cpp 也没有值得信任的默认值。请显式设置 -c，并确认实际设置的值。

内存计算中没人告诉你的部分

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

以 Llama 3.1 8B 为例。该模型有 32 层、8 个键/值头，head dimension 为 128。f16 中每个 token 的 key 和 value 各占 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 实时查看内存占用；不要相信未经实际测量的估算。如果目标模型明显超过 8B，那么 仅使用 CPU 的 VPS 运行 27B 模型中的相同计算可以说明 8 到 64 GB 的各个内存级别实际能够容纳什么。

Ollama 会进一步放大这一影响。OLLAMA_NUM_PARALLEL 的默认值为 1，模型所需的内存会随该值和上下文长度的乘积增长。两者同时提高时，daemon 会在不明显提示的情况下请求数倍于预期的 RAM。同样的计算也决定了同时服务的用户上限，因为每个并发请求都需要占用自己的 KV cache，这就是服务器单用户运行正常、五名用户同时使用却停滞的原因。

轴 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。这两者都会产生实际成本。请选择影响较小的方案。如果您决定让模型始终驻留在内存中，可以通过 设置 keep_alive，使其在空闲期间和重启后保持驻留 用几行配置实现，无需每次服务器重启后手动预热模型。

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 的 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。因此，较长的系统提示词会让每个请求都额外等待。回复长度是你真正可以控制的计费因素之一，因为速度为每秒 3 个 token 时，一个生成 600 个 token 的冗长回复会让服务器持续运行 3 分钟。因此，使用 num_predict 限制输出 是避免单个冗长回复导致超时的最低成本方法。

CPU 上适用的场景包括：使用 1B 到 4B 模型进行分类、信息提取、简短摘要或路由。回复可在几秒内返回，内存需求也适合普通方案。对于这一规模的具体示例，在 VPS 上拉取并测量 Nemotron 3.5 Lightning 给出了准确的 tag、实际内存需求，以及无 GPU 时可维持的速度。CPU 上不适用的场景包括：按阅读速度进行交互式聊天、代码助手、长文档处理，或包含连续多次调用的 agent 循环。一个执行 12 次调用、每次耗时 4 秒的循环，需要 1 分钟才能产生结果。如果原计划是使用代码助手，让 agent 调用自行托管的模型 说明了小型本地模型真正适合哪些任务，以及哪些任务仍应交给托管 API。

当这些数据无法满足需求时，有两种解决方向。如果问题是并发，即多个用户同时访问同一个模型，可以更换推理引擎；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。2026 年 8 月 2 日，构建版本 b10224 是当前标签：

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 增长。