Ollama 与 vLLM 怎么选：本地推理还是高并发服务

Ollama 与 vLLM：一段话说明

Ollama 是带有服务端的模型管理器：它会下载量化权重、加载模型，并在 127.0.0.1:11434 上响应请求；如果服务器只有 CPU，也可以使用 CPU。vLLM 是吞吐引擎：它让 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 推理所需的内存。在 Apple Silicon Mac 上，它还可以通过 MLX 引擎运行基于 safetensors 的模型；从 v0.40.0（September 2026）开始，支持的架构会自动使用 MLX 运行。

Ollama 的 GGUF 运行器基于 llama.cpp。llama.cpp 是一个 C++ 推理库，让 GGUF 量化可以在普通硬件上实用。截至 October 2026，Ollama 支持 llama.cpp 和 MLX 两个引擎，Linux 构建版本还支持使用 CUDA 进行 MLX 推理。开发指南通过 cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 启用该后端，前提是安装 CUDA 13+ 和 cuDNN 9+。因此，人们比较 Ollama 和 llama.cpp 时，主要是在比较一个易用性层与它所封装的组件。

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

vLLM 实际是什么

vLLM 是推理服务器，仅此而已。它不管理模型库，而是提供用于连接运行中服务器的 vllm chat 客户端；它也不会在收到请求时替您拉取模型。您在启动时指定一个 Hugging Face 仓库，vLLM 加载该模型，并持续提供服务，直到您停止进程。

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

实际效果是：在单个 GPU 上，并发用户数从 1 增加到 30 时，总 token 每秒数会显著提升，而单个用户的速度下降幅度远小于预期。在 Ollama 的默认配置下，用户数从 1 增加到 30 只会导致其中 29 人等待。

连续批处理决定了全部性能差异

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

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

vLLM 会在同一次前向传递中解码全部 5 个请求。为 5 个序列各生成 1 个 token，成本几乎不比为 1 个序列生成 1 个 token 高，因为开销最大的部分是将模型权重从内存中读出，而这次读取由整个批次共享。这正是 CPU 推理速度较慢的原因：主要成本在于移动权重，而不是执行计算。

您可以设置 OLLAMA_NUM_PARALLEL=4，获得部分类似效果。代价是内存。每个并行槽都需要独立的 KV cache，而且 Ollama 会乘倍分配上下文，而不是对其进行分摊：其 FAQ 表示，所需 RAM 会按 OLLAMA_NUM_PARALLEL 乘以 OLLAMA_CONTEXT_LENGTH 的比例增长。因此，针对一个配置为 8192 tokens 的模型发起 4 个并行请求时，每个请求仍保留 8192 tokens，但服务器总共必须容纳 32768 tokens 的 cache。8192 本身也是一个配置选择，并非固定值，因此 提高 num_ctx 并为其内存开销配置 RAM，决定了 4 个槽是否能够同时运行。vLLM 的分页 cache 无需预先为每个槽预留完整上下文窗口，因为它会随着请求实际增长，为请求分配相应的块。无论采用哪种方式，单台服务器能够同时服务多少用户，最终取决于 KV cache 大小、prefill 开销和队列深度。这也解释了 为什么一台供单人使用时运行良好的服务器，在 5 人同时使用时会变得缓慢。

使用 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 行表示该主机上的实际每秒令牌数。应以此为准，不要盲目采用已发布的数据。单次提示词的单次测量只能作为起点，不能代表容量。因此，在不同并发度下测量每秒令牌数，才能判断主机是否能承受预期负载，以及租用 GPU 是否比按令牌付费更划算。

要提高并发度，请使用 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 运行缓慢报告的真实原因。该 drop-in 中的 OLLAMA_KEEP_ALIVE=30m 行在负载较低的主机上同样重要，因为默认配置会在 5 分钟内没有请求时卸载模型，而让模型在请求之间保持驻留可以避免空闲最多半小时后的第一个提示词再次承担完整的加载时间。如果空闲间隔超过这个时长，请设置更长的值。

使用 vLLM 安装并提供服务

vLLM 的 GPU 构建版本需要 Linux（Apple Silicon 上的 macOS 仅支持 CPU；在 0.32.0 版本中可通过预构建 wheel 使用 CPU 支持，而这些 Mac 上的 GPU 加速由 vLLM-Metal 提供，这是一个基于 MLX 构建、由社区单独维护的插件）。当前版本（0.32.0，2026 年 10 月）支持 Python 3.11 到 3.14，安装指南也列出了相同范围。Python 3.10 已在 0.32.0 中移除，因此下面使用的 Python 3.12 是安全选择。请将其安装到独立的虚拟环境中，因为它会安装特定的 PyTorch 构建版本：

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

截至 2026 年 10 月，上一行命令仍在 vLLM 的 NVIDIA 安装指南中。它会安装 FlashInfer 的预编译内核。如果没有这些内核，vLLM 会在启动时下载并编译内核；指南指出，在 Hopper 及更新的 GPU 上，这可能增加数分钟的启动时间。每次升级 vLLM 后都要再次运行该命令，因为内核不匹配时 FlashInfer 会拒绝导入。

然后提供一个模型的服务。该名称是 Hugging Face 仓库 ID，而不是简短标签：

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

首次启动速度较慢，因为 vLLM 需要先下载权重，然后分析 GPU，以确定可以容纳多少个 KV cache 块。它监听端口 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 使容器可以访问主机共享内存；增加 --shm-size 也是一种选择。PyTorch 通过共享内存在进程之间传递张量，张量并行推理尤其如此。

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

vLLM 只需一个标志即可启用身份验证，而 Ollama 的本地 API 没有身份验证

如果为 vLLM 提供 bearer token，vLLM 会强制要求使用该 token：

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

同一个值也可以来自 VLLM_API_KEY 环境变量。不带该 token 的请求访问 /v1 时会返回 HTTP 401。不过，该密钥并不覆盖整个服务器。vLLM 的安全指南以及 0.32.0 源代码中的身份验证代码，只将其应用于 /v1、/v2、/inference 和 /cohere 路径前缀下的端点。vllm serve 页面中的 --api-key 帮助文本只列出前三个路径，但代码会检查全部四个路径。安全指南和帮助文本都说明，其他端点，尤其是 /invocations（提供与 /v1 相同的推理功能），不进行身份验证。这已经足以说明不要在公共接口上发布端口 8000。vLLM 的安全指南还要求在其前方的反向代理中处理速率限制；通过普通 HTTP 发送的 token 会在传输过程中被读取。不过，该标志确实表示服务器具备调用方的概念。

Ollama 的本地 API 不需要身份验证。云模型、模型发布和私有模型下载需要登录；直接访问 ollama.com 的 API 需要 API 密钥。任何能够连接到 11434 的进程都可以运行、拉取或删除模型。请将其限制在回环地址上，并通过您自行托管的 WireGuard VPN访问，或者使用会终止 TLS（传输层安全）的身份验证反向代理。

硬件：每种方案的需求

Ollama 在 CPU 上运行。4-bit 量化模型每 1B 个参数大约需要 0.5 GB RAM，此外还需要约 1 GB 的运行时开销，并且上下文还会增加需求。因此，3B 模型需要约 4 GB 可用内存，8B 模型需要约 8 GB。在共享 vCPU 上，速度通常为个位数到十几 token/秒。这是内存带宽造成的限制，不是配置错误，也没有任何 flag 可以修复。若要观察某个具体版本的实际表现，而不是依赖经验值，请参阅在 VPS 上运行 Nemotron 3.5 Lightning，其中会明确要拉取的 exact tag、模型加载后的 RAM 占用，以及仅使用 CPU 的速度是否足以满足实际需求。

vLLM 默认使用 GPU。其默认路径以 16-bit 精度提供未量化权重，每 1B 个参数大约需要 2 GB 显存；因此，8B 模型仅权重就需要约 16 GB 显存，还未计入你安装 vLLM 所需的并发 KV cache。使用 24 GB 显卡时，通常还能为 cache 留出可用空间。使用 16 GB 显卡时则不够，因此你需要选择更小的模型，传入 --quantization（配合量化 checkpoint，或在加载时量化全精度权重），或者通过 --cpu-offload-gb 将部分权重放入系统 RAM。后者会保留权重精度，但速度更慢，因为每次 forward pass 都要将这些权重传输到 GPU。vLLM 也提供 CPU backend，但需要单独的 wheels；使用它会失去运行 vLLM 的主要理由。

因此，在大多数情况下，硬件问题也就决定了软件方案。没有 GPU，就使用 Ollama。租用的 GPU 只有 5% 利用率，而请求又被串行处理，就使用 vLLM。

适合您的工作负载

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

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

vLLM 因 KV cache 错误而拒绝启动。 错误消息会同时列出这两个数字：

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

模型声明的上下文窗口大于加载权重后剩余的内存。使用 --max-model-len 8192 降低该值；如果没有其他程序使用显卡，也可以提高 --gpu-memory-utilization。

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

Ollama 单独运行时响应正常，但负载增加后出现停顿。 任何位置都不会显示错误。调用方越多，请求耗时越长，因为 OLLAMA_NUM_PARALLEL=1 会将请求串行化。较长的回答会进一步加重队列问题：一个调用方占用唯一的处理槽位，直到模型决定停止，后面的所有请求都会被阻塞。因此，使用通过 num_predict 限制回复长度可以限制单次对话占用服务器的时间上限。您可以提高并行设置，但必须接受每个槽位的上下文所需的额外 RAM；或者将工作负载迁移到 vLLM。

vLLM 对每个 /v1 调用都返回 401。 您使用 --api-key 启动了 vLLM，但客户端没有发送 Authorization 标头。大多数 OpenAI 客户端库会将您传入的值作为密钥发送，因此应在客户端中设置该值，而不是删除此标志。

vLLM 提示找不到模型。 Ollama 会按需拉取模型，而 vLLM 不会。请求正文中的 model 字段必须与启动时使用的仓库 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 的机器也支持两者的推理路径，但 vLLM 使用单独的 CPU wheel。

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

可以，通过其 CPU 后端运行。标准 wheel 面向 NVIDIA 或 AMD GPU，而 vLLM 的设计目标是通过批处理请求让加速器保持高利用率；在 CPU 上运行时，这一优势不再存在。vLLM 提供 CPU 后端，并为 x86 和 Arm 提供单独的 wheel。要进行实际的 CPU 推理，请直接使用 Ollama 或 llama.cpp。

Ollama 和 llama.cpp 有什么区别？

llama.cpp 是推理库，GGUF 是其量化权重格式。Ollama 使用 GGUF 执行推理，并增加了模型注册表、带标签的下载、模型管理和 systemd 单元。Ollama 还提供 MLX 引擎，可在 Apple Silicon 上运行基于 safetensors 的模型，并支持 Linux 上的 CUDA 构建，因此两者底层实现并不总是相同。

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

在 16 位精度下，仅权重就约占 16 GB，约为每 10 亿个参数 2 GB，此外还需要为 KV cache 预留空间。24 GB 显存的显卡可以轻松运行。16 GB 显存的显卡需要使用量化模型、更小的模型，或使用 --cpu-offload-gb 将部分权重移入系统 RAM，但会降低速度。vLLM 声明使用显卡容量的一定比例，该比例由 --gpu-memory-utilization 设置；截至 October 2026，其默认值为 0.92。

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

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