何时从Ollama迁移到vLLM：本地LLM服务进阶指南

Ollama 是运行本地语言模型最简单的方式之一，但它的便利性可能会掩盖这样一个转折点：本地实验已经变成共享推理服务，需要更完善的调度能力和可观测性。

这正是 vLLM 开始体现价值的地方。不过，从 Ollama 迁移到 vLLM 并不意味着自动升级，而是一种取舍：你需要牺牲 Ollama 的部分简洁性，换取对批处理、内存管理、并发、分布式推理和生产运维更强的控制能力。

本指南将介绍表明迁移确有必要的实际信号、过早迁移的风险，以及一种在验证期间让两种服务器并行运行的分阶段方法。目标是帮助你依据实际测量结果，而不是功能列表做出决定。如果想了解除这两种运行时之外更广泛的本地、自托管和云端方案，可以参阅《2026 年 LLM 托管：本地、自托管与云基础设施对比》。

Ollama 与 vLLM 解决的是不同问题

Ollama 主要针对便捷的模型使用体验进行了优化。它为开发者提供了简洁的命令行界面、本地 API、模型库、Modelfile，以及对常见桌面计算机和工作站配置的直接支持。

vLLM 则是一个推理引擎和服务平台。它的核心关注点包括高吞吐量请求调度、高效的 KV 缓存管理、连续批处理、模型并行，以及与基于 OpenAI 风格 API 构建的应用程序保持兼容。

这一区别很重要，因为从外部看，两种服务器可能非常相似。它们都能提供聊天 API、流式输出 token、运行量化模型，并为本地应用程序提供服务。只有当服务器承受持续负载或并发负载时，它们在运行模式上的差异才会明显显现出来。

问题不在于哪一种服务器普遍更好，而在于你的工作负载是否仍然符合让 Ollama 具有吸引力的运行模式。如果你想全面了解这两种运行时之外的更多方案，我们对 Ollama、vLLM、LocalAI、Jan、LM Studio 和其他本地 LLM 工具的比较涵盖了更广泛的领域。

表明你已经超出 Ollama 能力范围的信号

响应缓慢本身并不足以证明迁移是合理的。生成速度通常受模型大小、量化方式、内存带宽、提示词长度或 GPU 能力限制，而不是取决于服务引擎。只有当工作负载本身的形态开始产生影响时，才会出现更明确的迁移信号。

多用户导致延迟不稳定

本地 LLM 服务器在单独测试时可能感觉很快，但当多个客户端连接后，性能可能会急剧下降。请求开始排在耗时较长的生成任务之后，首 token 响应时间变得不稳定，而一个很大的提示词就可能影响所有共享该模型的用户。

Ollama 可以处理并行请求，OLLAMA_NUM_PARALLEL 控制已加载模型可以同时处理多少个请求——有关该设置背后的队列与内存机制，请参阅 Ollama 处理并行请求的方式。这种并行能力并非没有代价：内存需求会随着配置的并行请求数量和上下文长度同时增长。

这通常是第一个实际预警。适用于一次 8K 上下文对话的配置，在四个客户端分别预留更大上下文时可能会变得不可行。

vLLM 旨在通过连续批处理合并活跃请求中的计算任务。它不会将每个请求视为孤立的推理任务，而是随着序列到达、生成 token 和结束，持续更新批次——这种调度模型通常会随着并发量增加而变得更有价值。

请求排队时 GPU 利用率仍然很低

出现队列并不一定意味着 GPU 已得到充分利用。在简单的服务架构中，即使额外请求原本可以为当前解码步骤提供有效计算，任务仍可能被串行处理。

vLLM 的调度器旨在让更多有效任务保持运行。PagedAttention 以块为单位管理 KV 缓存内存，而连续批处理允许活跃序列动态进入和退出执行批次。

这并不能保证每个请求都获得更低的延迟。但在负载下，它可以显著提高整体吞吐量，并让资源利用率更加可预测。

长提示词主导首 token 响应时间

长上下文编码助手、RAG 流水线和智能体会话可能会反复发送很长的系统提示词或共享文档前缀。处理这些输入 token 属于预填充阶段，它可能占据首 token 响应时间的大部分。

vLLM 支持分块预填充和自动前缀缓存。当后续请求的初始 token 序列与已经处理过的前缀匹配时，前缀缓存允许其复用 KV 缓存块。

当请求共享以下内容时，这项功能尤其有用：

• 相同的工具定义

• 稳定的代码仓库摘要

• 重复使用的少样本示例

• 通用的 RAG 文档前缀

• 共享的对话历史

前缀缓存不会加快输出生成速度。它减少的是重复的提示词计算，因此它能带来多大收益，取决于请求是否确实包含完全相同且可复用的前缀。

你需要使用多个 GPU

当模型无法装入单个 GPU 时，就有充分理由考虑 vLLM。它支持跨 GPU 的张量并行，以及跨多个节点或设备的流水线并行。

这并不会让多 GPU 推理变得毫不费力。GPU 互连带宽、PCIe 拓扑、模型架构、容器共享内存和通信开销仍会影响性能。

尽管如此，vLLM 仍然为分布式推理提供了一条明确的实现路径。对于所选模型能够轻松装入单台桌面计算机或工作站的场景，Ollama 通常更加合适。

你需要生产级可观测性

Ollama API 的响应会提供有用的计时字段，例如模型加载时长、提示词评估时长、生成的 token 数量以及生成时长。这些数据足以满足本地基准测试和应用级日志记录的需要。

vLLM 通过 /metrics 端点公开与 Prometheus 兼容的指标。这让你可以更轻松地持续跟踪请求量、排队情况、首 token 响应时间、token 间延迟、缓存使用情况、抢占次数、吞吐量和请求结果。

一旦用户开始依赖这项服务，可观测性就不再是可选项。如果缺少队列、缓存和延迟指标，就很难判断问题究竟来自容量不足的 GPU、过大的上下文限制、低效的调度、模型冷加载，还是仅仅因为同时发起的请求过多。

vLLM 真正胜出的地方

vLLM 最重要的优势，并不是它能在每台机器上都比 Ollama 更快地生成单次响应。真正有意义的优势在于，它为运维人员提供了更多机制，可以跨大量请求高效利用昂贵的加速器内存和计算资源。

传统静态批处理最适合输入和输出长度相近的请求。交互式 LLM 流量很少会呈现这种特征：一名用户请求进行简短分类，另一名用户提交包含 20K token 的提示词，第三名用户则生成数千 token 的代码。

连续批处理会随着请求处理进度改变活跃批次。已经完成的序列退出，新序列进入，引擎会尽量避免将批次容量浪费在已经完成的请求上。

当流量具有并发性且分布不均时，这可以提高吞吐量。如果只有一名用户每次发送一个请求，它带来的收益则很有限。

分页式 KV 缓存管理

生成过程中，服务器会存储先前已处理 token 的注意力键和值。此 KV 缓存可能会占用大量 GPU 内存，尤其是在上下文很长且同时存在多个活跃序列时。

vLLM 以块为单位管理这部分缓存，而不是要求每个序列预留一块连续的大内存。这种方式可以减少内存碎片，并允许系统更灵活地使用可用缓存容量。

其实际价值是在相同内存预算下获得更高的并发能力。它无法消除长上下文本身的开销，但可以减少围绕这项开销产生的不必要浪费。

许多生产请求会共享一段很长的开头。启用了工具的智能体可能会发送相同的函数模式，客服机器人可能会使用相同的策略文档，而编码助手可能会反复附带相同的代码仓库指令。

自动前缀缓存可以为匹配的前缀复用已经计算出的缓存。当稳定且较长的前缀之后只跟随一段相对较小、与具体请求相关的后缀时，它尤其有用。

如果模板、时间戳、文档顺序或动态生成的元数据在每次提示词开头附近都会发生变化，它的作用就会减弱。token 化过程中的微小差异也可能导致前缀无法匹配。

并行与分布式推理

vLLM 支持多种并行形式，包括张量并行、流水线并行、数据并行、专家并行和上下文并行。并非每个部署都需要这些模式，但当服务规模超出单个 GPU 的能力范围时，能够使用这些模式就非常重要。

对于配有两个合适 GPU 的工作站，张量并行可以让大型模型跨两个设备运行。对于复制型服务，数据并行可以创建多个引擎副本以增加吞吐量。

这些功能引入了运维复杂性。应该采用它们是因为测量表明存在容量问题，而不是因为分布式推理看起来更高级。

更多生产级控制选项

vLLM 暴露了 GPU 内存利用率、最大模型长度、最大活跃序列数、量化、缓存数据类型、推测解码、工具调用、结构化输出、模型别名、认证密钥和分布式执行的控制选项。

这种灵活性使得服务器更容易针对特定工作负载进行调优，但也会产生更多无效或低效配置的机会。迁移到 vLLM 意味着要对这些决策负责。

Ollama 仍然胜出的地方

个人工作站

对于使用聊天界面、代码助手或偶尔本地 API 的单个开发者来说，vLLM 的运维优势可能永远无法弥补其额外的设置。

Ollama 安装快速，通过简单的注册表下载模型，隐藏许多特定于模型的细节。它非常适合实验和私人桌面使用。

GGUF 模型集合

Ollama 围绕 GGUF 模型和 Modelfiles 有自然的工作流程。现有用户可能拥有经过筛选的量化、适配器、模板、系统提示和参数，这些都能在其硬件上可靠地运行。

vLLM 支持 GGUF，但其最强的路径通常是通过支持的 Hugging Face 模型仓库和量化格式，如 AWQ、GPTQ、BitsAndBytes、FP8 或供应商特定格式。将现有 GGUF 部署迁移到 vLLM 而不评估更本地的检查点格式，可能会保留迁移的不便之处，同时错过一些性能优势。

混合 CPU 和 GPU 卸载

桌面推理有时依赖部分 GPU 卸载，因为整个模型无法放入 VRAM。这对于偶尔使用可能是实用的，特别是当延迟不是关键因素时。

vLLM 通常最具吸引力的是当模型和所需的 KV 缓存容量能够由可用的加速器配置有效地处理时。依赖系统 RAM 和 CPU 卸载的工作负载可能更适合 Ollama 或 llama.cpp。

快速模型切换

Ollama 使拉取、运行、停止和在多个本地模型之间切换变得容易。这对于评估、写作、编码、嵌入、视觉和临时实验很有用。

vLLM 部署更常见的是围绕精心选择的模型构建，该模型保持作为服务加载。多模型部署是可能的，但需要更明确的资源规划。

最小化管理

Ollama 是有意见的。这在负载下可能是一个限制，但当没有人想维护推理平台时，这是一个优势，如果本地服务器有一个用户、可接受的延迟和没有有意义的队列，迁移可能会产生工作而不是删除它。

不要仅基于每秒令牌数进行迁移

单请求令牌生成速度是一个不完整的基准。两个服务器对于一个序列可能产生相似的解码吞吐量，但与八个并发客户端表现非常不同。

有用的评估应该至少测量：

端到端请求延迟

提示处理吞吐量

输出令牌吞吐量

每分钟完成的请求数

GPU 内存消耗

失败和超时率

在两个服务器上运行相同的模型系列、精度、上下文长度、提示集、输出限制和并发级别。否则，测试更可能比较模型打包和配置，而不是服务引擎。

最有用的比较是代表实际流量的小型负载测试。对于共享的编码助手，这可能包括长系统提示、重复的前缀、流响应和两到八个并发会话。

先规划模型迁移

Ollama 模型名称不会自动映射到等效的 vLLM 模型标识符。Ollama 包可能包含特定的 GGUF 量化、提示模板、停止令牌配置和默认参数。

在更改服务器之前，识别：

原始模型系列和版本

它是基础还是指令调优模型

当前量化和有效精度

提示或聊天模板

配置的上下文长度

停止令牌和生成默认值

工具调用或结构化输出要求

任何 LoRA 适配器或自定义系统提示

然后选择与预期行为匹配的 vLLM 支持的检查点。不要假设 AWQ 或 FP8 检查点会与之前在 Ollama 中使用的 GGUF 构建表现相同——模型迁移通常比 API 迁移更重要。

启动 vLLM 前检查 VRAM

模型适应 GPU 内存并不意味着它可以服务所需的工作负载。VRAM 必须覆盖超过模型权重。

实际的内存预算包括：

model weights
+ KV cache
+ CUDA graphs and runtime allocations
+ temporary workspace
+ multimodal processor caches, if used
+ safety margin

长上下文和并发序列主要扩展 KV 缓存需求。因此，增加最大上下文长度会减少可以容纳的同时请求数，即使大多数请求从不使用完整限制。

从现实的 --max-model-len 开始，而不是模型宣传的最大值，避免设置 GPU 内存利用率过于激进，导致微小的工作负载变化引起内存不足故障。稍微低于理论容量的稳定服务比在第一次流量尖峰时失败的服务更有用。

最小化的 vLLM Docker Compose 部署

以下示例在端口 8000 上启动与 OpenAI 兼容的 vLLM 服务器：

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm
    restart: unless-stopped
    ports:
      - "8000:8000"
    ipc: host
    gpus: all
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    environment:
      HF_TOKEN: ${HF_TOKEN:-}
    command:
      - --model
      - Qwen/Qwen3-8B
      - --served-model-name
      - local-model
      - --max-model-len
      - "16384"
      - --gpu-memory-utilization
      - "0.90"
      - --api-key
      - ${VLLM_API_KEY:-change-me}

创建一个环境文件：

cat > .env <<'EOF'
HF_TOKEN=
VLLM_API_KEY=replace-with-a-long-random-value
EOF

docker compose up -d

docker compose logs -f vllm

测试模型端点：

curl http://localhost:8000/v1/models \
  -H "Authorization: Bearer replace-with-a-long-random-value"

curl http://localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer replace-with-a-long-random-value" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-model",
    "messages": [
      {
        "role": "user",
        "content": "Explain continuous batching in two paragraphs."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300,
    "stream": false
  }'

对于维护的部署，将镜像固定到测试的 vLLM 版本，而不是保持最新。升级前查看发布说明，因为命令行选项、模型实现、指标和引擎行为可能会变化。这个 Compose 文件有意最小化；对于更完整的设置指南——OpenAI API 兼容性、PagedAttention 调优和更深入的 vLLM vs Ollama 比较——请参阅 vLLM 快速开始。

OpenAI API 兼容性不是完全可互换性

Ollama 和 vLLM 都提供与 OpenAI 兼容的端点，这可以使应用程序迁移相对较小。在许多客户端中，更改基础 URL、API 密钥和模型名称就足以建立连接。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="replace-with-a-long-random-value",
)

response = client.chat.completions.create(
    model="local-model",
    messages=[
        {
            "role": "user",
            "content": "What should I monitor on an LLM server?",
        }
    ],
    temperature=0.2,
)

print(response.choices[0].message.content)

兼容性仍应在功能级别进行测试。检查：

流事件行为

支持的请求参数

聊天模板选择

推理输出处理

JSON 或模式约束输出

令牌使用报告

错误响应格式

上下文长度执行

仅发送普通聊天完成的客户端通常比依赖特定工具调用解析器或非标准扩展的 AI 智能体框架更容易迁移。

聊天模板是常见的迁移失败原因

指令微调模型要求使用特定的聊天模板对对话进行序列化。该模板会按照训练时使用的格式插入角色标记、分隔符、控制 token 和生成提示。

Ollama 将这类行为的大部分封装在其模型定义中。使用 vLLM 时，模板通常从模型的 tokenizer 配置中获取，不过运维人员也可以显式提供模板。

即使所选模板错误，服务器也可能成功启动。问题会体现在模型行为上：

模型重复输出角色标签

响应中包含特殊 token

系统指令被忽略

工具调用格式错误

模型继续补写用户消息

输出质量远低于预期

在归咎于推理引擎之前，请先比较两个部署实际使用的完整渲染提示。

分阶段迁移

一步替换正在正常运行的本地服务器会带来不必要的风险。在验证新部署期间，可以让 Ollama 和 vLLM 分别监听不同端口并行运行。

阶段 1：复现一个模型

选择承担大部分 API 流量的模型，尽可能准确地匹配其指令微调方式、上下文需求、生成参数和聊天行为。不要一开始就迁移所有实验性模型。

阶段 2：验证 API 行为

针对 vLLM 端点运行现有的集成测试，包括流式传输、取消、超时、工具调用、格式错误的请求、上下文溢出以及并发访问。记录行为差异，而不是通过客户端重试来掩盖它们。

阶段 3：建立基准

首先测量单请求性能。这样可以确认模型已正确加载，并为后续测试提供参照。

记录每秒处理的提示 token 数、每秒输出的 token 数、首 token 延迟、总延迟以及 GPU 显存占用。

阶段 4：加入符合实际情况的并发负载

使用具有代表性的提示和输出长度，而不是完全相同的合成请求，测试正常运行时预计出现的并发请求数以及合理峰值期间的并发请求数。关注排队、缓存使用、抢占、首 token 延迟和尾延迟。

阶段 5：迁移一个客户端

将一个非关键应用或一小部分流量路由到 vLLM。在新服务器经过真实使用并证明能够可靠运行之前，保留 Ollama 作为回退方案。

阶段 6：根据测量结果调优

只有在确定了可测量的约束后，才调整模型长度、显存利用率、最大活跃序列数、前缀缓存、并行策略和量化方式。一次更改多个参数会使性能回退难以解释。

实用迁移检查清单

在切换客户端之前，请验证以下事项：

[ ] The target model is supported by vLLM
[ ] The selected checkpoint and quantization fit in VRAM
[ ] Enough VRAM remains for the required KV cache
[ ] The maximum context length reflects real usage
[ ] The correct chat template is available
[ ] Stop tokens and generation defaults are tested
[ ] Streaming works with existing clients
[ ] Tool calls and structured output are validated
[ ] The public model alias remains stable
[ ] Authentication is enabled
[ ] The server is not exposed directly to the internet
[ ] Prometheus metrics are collected
[ ] GPU metrics are collected separately
[ ] Load tests include realistic concurrency
[ ] Timeouts and cancellations are handled
[ ] A rollback path to Ollama exists

这份清单刻意侧重于运维。安装 vLLM 通常比证明它能为现有应用正确运行更容易。

安全与网络暴露

无论是本地 Ollama 端点还是 vLLM 端点，都不应随意暴露在公共互联网上。未经身份验证的推理服务器可能消耗昂贵的 GPU 容量、暴露模型行为，还可能因为超长提示或输出而成为拒绝服务攻击的入口。

vLLM 可以要求访问其 OpenAI 兼容端点时提供 API 密钥，但 API 密钥并不是完整的安全边界。对于共享或远程访问，应将服务置于反向代理或 API 网关之后，由其提供 TLS、网络访问限制、请求大小限制、速率限制、访问日志以及适当的身份验证——在 Ollama 前使用 Caddy 或 Nginx 反向代理的模式，同样适用于 vLLM。

还需要考虑模型特有的风险。多模态 URL 加载、自定义模型代码、远程文件和不受限制的工具执行，都可能使攻击面超出普通文本生成的范围。

在以下情况下继续使用 Ollama：

只有一两名用户访问服务器

请求大多按顺序执行

模型已经能够提供可接受的延迟

简便的 GGUF 管理非常重要

需要使用 CPU 或部分 GPU 卸载

频繁切换模型

没有人愿意运维额外的基础设施

不存在经过测量证实的并发或吞吐量问题

迁移到 vLLM 应当是为了解决具体限制。“生产环境”并不是一个会让 Ollama 自动失去适用性的神奇门槛，尤其对于流量不大的内部服务而言。

反过来，也不要仅仅因为 Ollama 更容易安装就坚持使用它。如果用户经常需要排队等待、重复前缀消耗了大量预填充时间，或者必须将更大的模型分布到多个 GPU 上，那么这个更简单的服务器可能已经成为运维成本更高的选择。

保留 Ollama 用于开发，并添加 vLLM 用于共享服务

最实用的架构通常不是彻底替换。开发者可以继续在工作站上通过 Docker Compose 运行 Ollama，用于模型探索、GGUF 测试和私有交互式使用；与此同时，由共享的 vLLM 实例向应用和团队提供稳定的模型服务。这种拆分对 AI 主权也很重要——保持两个运行时均为自托管，意味着无论由哪个服务器处理请求，提示、权重和推理日志始终处于你的控制之下。

这将两种不同的工作流区分开来：

Ollama:
experimentation -> model switching -> personal tools -> local chat

vLLM:
selected model -> shared endpoint -> concurrent traffic -> monitoring

该