Ollama 与 vLLM 怎么选：本地单用户还是 GPU 服务

Ollama 与 vLLM：一段话说明

Ollama 是附带服务器的模型管理器：它下载量化权重、加载权重，并在 127.0.0.1:11434 上响应；如果设备只有 CPU，也可以使用 CPU。vLLM 是吞吐引擎：它让 GPU 同时处理大量请求，以充分利用 GPU；没有 GPU 的机器不适合使用它。决策依据就是这些。一个人使用本地助手属于 Ollama 场景。一个应用为团队提供服务属于 vLLM 场景。

两者都提供兼容 OpenAI 的 HTTP API，因此只需更改 base URL，客户端代码就可以在两者之间切换。区别不在 API，而在第一个请求仍在生成 token 时，第二个请求到达后会发生什么。

Ollama 的实际作用

Ollama 是一个便捷层。通过一条安装命令，它会为您提供模型注册表（ollama pull llama3.1:8b）、本地权重存储、聊天提示词、systemd 服务和 HTTP API。它提供的模型是 GGUF 文件，通常经过 4-bit 量化。因此，7B 或 8B 模型在磁盘上通常约占 5 GB，而不是 16 GB。量化使 CPU 推理成为可能。

其运行器基于 llama.cpp。llama.cpp 是一个 C++ 推理库，使 GGUF 量化能够在普通硬件上实际运行。此后，Ollama 为一些较新的模型系列添加了自己的引擎，但 llama.cpp 仍是其大多数服务所依赖的底层组件。因此，人们比较 Ollama 和 llama.cpp 时，主要是在比较一个易用性层与它所封装的组件。

该设计面向单个用户。截至 July 2026，OLLAMA_NUM_PARALLEL 的默认值为 1。这意味着一个模型一次处理一个请求，其他请求都会进入队列等待。该队列默认可容纳 512 个条目（OLLAMA_MAX_QUEUE）。您可以提高并行设置，下面的章节会说明这样做的代价。如果您以前没有运行过 Ollama，请先阅读在 VPS 上托管 Ollama 并保持端口 11434 关闭，因为其 API 完全没有身份验证机制。

vLLM 的实际作用

vLLM 只是一个推理服务器。它不管理模型库，也不提供聊天提示词，并且不会在收到请求时为您下载模型。您在启动时指定一个 Hugging Face 仓库，vLLM 会加载其中的一个模型，并持续提供服务，直到您停止进程。

这种专注带来的优势是吞吐量。两个机制负责实现这一点。PagedAttention 将 KV cache（键值缓存，即模型为每个活动请求保留的逐 token 注意力状态）存储在固定大小的块中，方式类似于操作系统对内存进行分页。请求不再需要按照最坏情况预留一大块连续内存，因此原本被预留但未使用的内存可以用于处理更多并发请求。Continuous batching 允许新请求在下一次解码步骤加入正在运行的批处理，而不必等待当前批处理完成。序列完成后会立即离开批处理，其位置会被新的请求填充。

实际效果是：在单个 GPU 上，并发用户数从 1 增加到 30 时，总 tokens/秒会显著提高，而每个用户的速度下降幅度远小于预期。在 Ollama 的默认行为下，用户数从 1 增加到 30 只会让另外 29 个人等待。

连续批处理才是根本区别

假设在相同硬件上，每台服务器同时收到 5 个请求。

Ollama 使用默认设置时，会先处理完第 1 个请求，再处理第 2 个请求，依此类推。第 5 个调用方需要等待前 4 次完整生成。总吞吐量大致等于 1 次生成的速度，因为处理器始终只处理 1 个序列。

vLLM 在同一次前向传递中解码全部 5 个请求。为 5 个序列生成 1 个 token 的成本仅略高于为 1 个序列生成 1 个 token，因为开销最大的部分是从内存中读取模型权重，而整个批次共享这次读取。这与导致 CPU 推理速度较慢的内存带宽事实相同：成本主要来自移动权重，而不是执行算术运算。

您可以设置 OLLAMA_NUM_PARALLEL=4，以获得部分效果。代价是内存。每个并行槽都需要独立的 KV cache，而且 Ollama 会在各槽之间划分上下文窗口。因此，对于配置为 8192 tokens 的模型，4 个并行请求会使每个请求只能获得 2048 tokens 的上下文。vLLM 的分页缓存避免了这种权衡，因为它会随着请求实际增长，按需为请求分配内存块。

使用 Ollama 安装并提供服务

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

安装脚本会创建一个 ollama 系统用户，安装二进制文件，并注册绑定到 127.0.0.1:11434 的 ollama.service。--verbose 输出的 eval rate 行表示该主机上的实际每秒令牌数。请以此为准，不要参考发布的性能数据。

要提高并发数，请使用 systemd drop-in，这样升级时不会覆盖该更改：

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps 显示已加载的配置，其 PROCESSOR 列显示实际值。100% CPU 表示未使用 GPU，这是大多数 Ollama 运行缓慢报告的真实原因。

使用 vLLM 安装并提供服务

vLLM 需要 Linux 和 Python 3.10 至 3.13。请将其安装到独立的虚拟环境中，因为它会安装特定的 PyTorch 构建版本：

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

然后提供模型服务。模型名称必须是 Hugging Face 仓库 ID，不能使用简短标签：

vllm serve Qwen/Qwen2.5-1.5B-Instruct

首次启动较慢，因为 vLLM 需要先下载权重，然后分析 GPU，以确定可容纳多少个 KV 缓存块。服务监听端口 8000。请先检查服务，再编写客户端代码：

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

如果服务器上已经安装 Docker，官方镜像可以避免处理 CUDA 依赖：

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host 是必需设置，不是装饰性参数：PyTorch 通过共享内存在进程之间传递张量，而 Docker 的默认共享内存分配对于张量并行推理来说太小。

生产环境中最重要的参数是 --max-model-len（您愿意为其付费的上下文窗口）、--gpu-memory-utilization（vLLM 可以占用的 GPU 显存比例；截至 2026 年 7 月，默认值为 0.92）、用于将一个模型拆分到多个 GPU 上的 --tensor-parallel-size，以及 --api-key。

vLLM 的身份验证通过一个标志启用，Ollama 不提供身份验证

如果为 vLLM 设置 bearer token，vLLM 会强制要求该令牌：

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

相同的值也可以来自 VLLM_API_KEY 环境变量。不带该令牌的请求会收到 HTTP 401。即使如此，也不应因此在公共接口上开放端口 8000，因为 vLLM 没有速率限制，明文 HTTP 令牌在传输过程中可被读取。但这意味着服务器能够识别调用方。

Ollama 不提供任何身份验证。它没有密钥、登录功能或允许列表。任何能够访问 11434 的进程都可以运行、拉取或删除模型。将其限制在回环地址上，并通过自行托管的 WireGuard VPN访问；或者使用会终止 TLS（传输层安全）的身份验证反向代理。

硬件：每种方案的需求

Ollama 在 CPU 上运行。4-bit 量化模型每 10 亿个参数大约需要 0.5 GB RAM，此外还需要约 1 GB 运行时开销，较大的上下文还会增加需求。因此，3B 模型需要约 4 GB 可用内存，8B 模型需要约 8 GB。共享 vCPU 上的速度为每秒个位数到十几 tokens。这是内存带宽造成的限制，不是配置错误，任何 flag 都无法修复。

vLLM 假设使用 GPU。其默认路径以 16-bit 精度提供未量化权重，每 10 亿个参数大约需要 2 GB 显存：8B 模型仅权重就需要约 16 GB 显存，还未计算为并发请求预留的 KV cache。在 24 GB 显卡上，剩余显存足以提供可用的 cache。在 16 GB 显卡上则不够，因此您需要选择更小的模型，或使用带量化 checkpoint 的 --quantization。vLLM 也提供 CPU backend，但标准 wheels 并非为其构建，而且这会失去运行 vLLM 的主要意义。

因此，大多数情况下，硬件问题也就回答了软件问题。没有 GPU，就使用 Ollama。租用的 GPU 利用率只有 5%，因为请求被串行处理，就使用 vLLM。

适合您的工作负载

• 一名用户，使用 CPU VPS 进行起草和摘要：Ollama。速度可以接受，而且没有更简单的方案。
• 编程助手，或将您的工具连接到本地模型的 MCP 服务器，且只有您自己调用：Ollama。并发数为 1 就是实际工作负载。
• 本周比较 5 个模型：Ollama。拉取和删除带标签的模型正是它的优势，而 vLLM 每更换一个模型都需要重启进程。
• 内部应用、聊天产品或有真实用户的检索流水线：vLLM。批处理能在这里体现 GPU 成本的价值。
• 需要在一夜之间为 100000 份文档评分的批处理作业：vLLM，并设置较高的 --max-num-seqs。吞吐量是唯一重要的指标，单份文档的延迟并不重要。
• 多个自托管 AI 代理会同时访问模型的代理平台：vLLM，因为代理流量具有突发性，并且本质上是并行的。

故障模式及其对应的错误字符串

vLLM 因 KV cache 错误拒绝启动。 消息会同时显示这两个数值：

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

模型声明的上下文窗口大于加载权重后剩余的显存。使用 --max-model-len 8192 降低上下文窗口；如果没有其他程序使用该显卡，也可以提高 --gpu-memory-utilization。将利用率提高到约 0.95 以上，通常会使启动错误变成后续负载运行期间的 CUDA 显存不足崩溃，后者更难处理。

Ollama 在生成过程中输出 Killed。 Linux 的内存不足终止程序，因为模型所需的 RAM 超过了服务器的可用内存。使用 sudo dmesg | grep -i oom 确认。解决方法是使用更小或量化程度更高的模型，而不是修改设置。

Ollama 单独运行时响应正常，但在负载下停滞。 任何位置都不会出现错误。随着调用方增加，请求只会逐渐变慢，因为 OLLAMA_NUM_PARALLEL=1 会将请求串行化。提高该值，并接受每个请求的上下文更小；或者将工作负载迁移到 vLLM。

vLLM 对每次调用都返回 401。 你使用 --api-key 启动了服务，但客户端未发送 Authorization header。大多数 OpenAI 客户端库会将你传入的值作为 key 发送，因此应在客户端设置该值，而不是删除此标志。

vLLM 提示找不到模型。 Ollama 会按需拉取模型，而 vLLM 不会。请求体中的 model 字段必须与启动时使用的 repository id 匹配；如果设置了 --served-model-name，则必须与其值匹配。使用 curl http://localhost:8000/v1/models 确认准确的字符串。

同时运行两者是合理的方案

两者并不互斥。一种常见架构是：在 GPU 实例上运行 vLLM 为应用提供服务，同时在旁边的普通 VPS 上运行 Ollama，用于本地脚本、cron 任务和试用新版本模型。两个端点都兼容 OpenAI，因此使用同一个客户端库并切换 base URL 即可。相比选择哪种服务器，引擎成本控制更为重要，因为空闲 GPU 的计费与繁忙 GPU 相同，而保持代理和推理成本可预测是独立于服务器选择的另一项工作。

FAQ

vLLM 比 Ollama 快吗？

在同一 GPU 上处理单个请求时，差距不大，因为两者执行相同的计算。处理大量并发请求时，vLLM 明显更快，因为连续批处理会在一次前向传递中解码所有活动序列，而 Ollama 的默认行为是依次处理这些请求。在仅使用 CPU 的计算机上，这个问题不适用：Ollama 可以运行，而 vLLM 实际上无法运行。

vLLM 可以在没有 GPU 的情况下运行吗？

基本没有实际用途。标准 wheel 面向 NVIDIA 或 AMD GPU，而 vLLM 的作用就是通过批处理请求使加速器保持高利用率；在 CPU 上，这一优势不复存在。vLLM 提供 CPU 后端用于开发工作。要在 CPU 上进行实际推理，请直接使用 Ollama 或 llama.cpp。

Ollama 和 llama.cpp 有什么区别？

llama.cpp 是推理库，GGUF 是其量化权重格式。Ollama 的运行器基于 llama.cpp 构建，并增加了 llama.cpp 留给用户自行处理的功能：模型注册表、自动下载、常驻服务器、systemd unit 和兼容 OpenAI 的端点。Ollama 已为一些较新的模型系列添加了自己的引擎，因此两者底层实现不再完全相同。

vLLM 运行 8B 模型需要多少 GPU 内存？

使用 16-bit 精度时，仅权重就约需 16 GB，约为每 1 billion 个参数 2 GB，此外还需要为 KV cache 预留空间。24 GB 显卡可以轻松满足需求。16 GB 显卡需要使用量化 checkpoint 或更小的模型。截至 July 2026，vLLM 使用显卡容量中由 --gpu-memory-utilization 设置的比例，该值默认为 0.92。

在两者之间切换时，需要修改应用程序代码吗？

通常只需要修改 base URL、API key 和模型名称。Ollama 在 http://127.0.0.1:11434/v1 提供兼容 OpenAI 的接口，并忽略 API key；vLLM 在 http://localhost:8000/v1 提供该接口，如果设置了 API key，则会强制验证。模型名称的格式不同：Ollama 使用 llama3.1:8b，vLLM 使用完整的 repository id，例如 Qwen/Qwen2.5-1.5B-Instruct。