【深度收藏】大模型部署框架对决：Ollama与vLLM谁更适合你？从入门到生产环境全方位解析

引言 🎯

开源 LLM 模型已经成为爱好者、程序员和希望在日常工作中使用生成式 AI 同时保护隐私的用户的热门选择。这些模型性能出色，有时在许多任务上甚至可以媲美像 GPT-4o 或 Claude Sonnet 3.5 这样的大型闭源模型。

虽然它们是开源的，但并不意味着开箱即用，你需要一个框架来在本地或服务器上运行它们，满足特定用例。此外，OpenAI 兼容的服务器已成为部署模型最流行的方式，因为这种 API 让你可以用几乎任何 SDK 或客户端来使用你的 LLM，比如 OpenAI SDK、Transformers、LangChain 等。所以问题来了：哪个框架最适合部署与 OpenAI 兼容的 LLM？

我们将分析 Ollama 和 vLLM 这两个最受欢迎的框架，它们都支持 OpenAI API 兼容性。本分析将涵盖性能、易用性、自定义能力以及其他有助于选择最适合你特定用例的框架的公平比较。

对比大战开始啦！

Ollama 是什么？🦙

Ollama 是一个强大的框架，目标是让运行 LLM 变得尽可能简单。可以把它想象成 LLM 的 Docker——它简化了下载、运行和管理大型语言模型的整个过程，无论是在本地机器还是服务器上。

安装 🛠️

Ollama 的安装非常简单。以下是在不同平台上的安装方法：

Linux（我用的这个）

curl -fsSL https://ollama.com/install.sh | sh

macOS

brew install ollama

Windows
我不用 Windows，但 Ollama 的一个优势就是它的多功能性：

安装 WSL（Windows Subsystem for Linux）
按照 Linux 的安装说明操作

感谢用户Quark Quark的建议，你也可以通过这个链接在 Windows 上安装 Ollama：[链接地址]。

使用 🚀

Ollama 提供了一个现成的模型库，你只需要一行代码就能运行：

ollama run <anymodel>

这让你可以轻松在终端运行 Ollama 模型库中的任何模型。在本教程中，我将使用我最喜欢的模型之一 Qwen2.5–14B，它可以在我的 RTX 4060（16GB 显存）上运行：

ollama run qwen2.5:14b --verbose

就这样！只用一行代码，你就能在本地或服务器上运行一个 LLM，想问啥就问啥。我加了--verbose参数，这样可以看到每秒处理的 token 数（tok/sec）性能——在我的机器上，达到了 26 tok/sec.

Ollama 参数 🔧

上一节展示了 Ollama 使用的简便性。但我们之前用的是默认参数。如果想改参数怎么办？

Modelfile 创建 📝

要用特定参数创建自己的模型，你需要创建一个 Modelfile，这是一个包含你想设置参数的纯文本文件。示例：

FROM qwen2.5:14b # 设置温度为 1 [越高越有创造性，越低越连贯] PARAMETER temperature 0.5 # 设置上下文窗口大小为 8192，控制 LLM 生成下一个 token 时可用的上下文 token 数 PARAMETER num_ctx 8192 # 设置生成 token 数为 4096（最大值） PARAMETER num_predict 4096 # 系统提示配置 SYSTEM """You are a helpful AI assistant."""

构建并运行自定义模型：

# 构建模型 ollama create mymodel -f Modelfile # 运行模型 ollama run mymodel --verbose

完整的可自定义参数列表可以查看这个链接：[链接地址]。

Ollama API 🔌

目前为止，我们已经在终端运行了一个模型，这是个很棒的功能，方便你轻松尝试各种模型。但我们研究的目标是用与 OpenAI 兼容的方式使用这些模型。Ollama 怎么做到呢？Ollama 提供了两种与模型交互的方式：

原生 REST API 📡
Ollama 默认在 11434 端口运行一个本地服务器。你可以用标准的 HTTP 请求与之交互：

import requests # 基本聊天完成请求 response = requests.post('http://<your_ollama_server_ip>:11434/api/chat', json={ 'model': 'qwen2.5:14b', 'messages': [ { 'role': 'system', 'content': 'You are a helpful AI assistant.' }, { 'role': 'user', 'content': '什么是人工智能？' } ], 'stream': False } ) print(response.json()['message']['content'])

OpenAI 兼容层 🔄

为了与现有应用无缝集成，Ollama 提供了 OpenAI API 兼容性。首先，启动 OpenAI 兼容服务器：

用 OpenAI Python SDK：

from openai import OpenAI client = OpenAI( base_url="http://<your_ollama_server_ip>:11434/v1", api_key="dummy"# vLLM 要求 API key，这是它对比 Ollama 的一个优势。我们这里设为 None，所以可以随便填个字符串 ) # 聊天完成 response = client.chat.completions.create( model="qwen2.5:14b", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "什么是人工智能？"} ] ) print(response.choices[0].message.content)

Ollama API 的主要功能 🎯

Ollama 的 API 功能强大，为开发者提供了很多实用特性。我们将在本教程的第三部分详细讨论这个框架的优缺点，现在先列出主要功能：

•流式支持：实时生成 token，完全兼容 OpenAI API，非常适合创建响应迅速的应用。
•多模型管理：可以同时运行不同模型，但有个问题：当显存（VRAM）不足时，Ollama 会停掉一个模型来运行另一个，需要仔细规划资源。
•参数控制：通过 API 调用高度自定义设置——这是一把双刃剑，灵活性高，但对新手和生产服务器可能有点复杂。
•CPU 兼容性：智能资源管理，当显存不足时会自动将模型层卸载到 CPU，让即使显存有限的系统也能运行大型模型。
•语言无关：可以用你喜欢的编程语言，无论是 Python、JavaScript、Go，还是任何支持 HTTP 的语言。

对比大战第二回合！
让我们深入了解这个框架为何是 LLM 推理的引人注目的选择！🚀

vLLM 是什么？🚀

vLLM 是一个专注于效率和可扩展性的高性能 LLM 推理框架。基于 PyTorch 构建，它利用 CUDA 进行 GPU 加速，并实现了连续批处理和高效内存管理等先进优化技术，使其特别适合生产环境。

使用 🛠️

使用 vLLM 不像 Ollama 那么简单，我认为最好的方式是通过 Docker 进行干净且隔离的安装。Docker 提供了一致的运行环境，简化了在不同系统上的部署。

前提条件

• 系统已安装 Docker
• NVIDIA Container Toolkit（用于 GPU 支持）
• 至少 16GB 内存（推荐）
• 具有足够显存（VRAM）的 NVIDIA GPU

在我撰写本文时，vLLM 对 GGUF 量化模型的支持还不完整，但未来可能会改变。以下是 vLLM 文档网站上的信息：

截图来自 vLLM 文档网站。

但什么是 GGUF？为什么对我们的研究如此重要？

GGUF（GPT-Generated Unified Format）🔍

GGUF 被许多人认为是 GGML 的继承者，是一种量化方法，支持大型语言模型在 CPU 和 GPU 上的混合执行，优化内存使用和推理速度。它对我们的研究尤为重要，因为这是 Ollama 支持模型执行的唯一格式。

该格式在 CPU 架构和 Apple Silicon 上特别高效，支持多种量化级别（从 4 位到 8 位），同时保持模型质量。

虽然 vLLM 目前对 GGUF 的支持有限，专注于原生 GPU 优化，但了解这种格式对我们的比较分析至关重要，因为它是 Ollama 操作的基础。在本研究的第三部分，我们将探讨这些不同的模型优化方法如何影响性能指标，全面展示两种框架在不同硬件配置下的能力。

使用 Docker 部署 🐳

弄清楚这些后，我们继续部署 Qwen2.5–14B 作为本研究的参考模型。由于 vLLM 尚不支持多文件量化模型（见上图），我们不能使用 Qwen 官方提供的 GGUF 模型，因此只需下载单个文件。这可能需要一些时间，具体取决于你的网络速度：

# 在工作目录中创建 models 文件夹 mkdir models/ mkdir models/Qwen2.5-14B-Instruct/ # 从 lmstudio 社区下载模型，这是一个 4 位量化的单一文件模型 huggingface-cli download lmstudio-community/Qwen2.5-14B-Instruct-GGUF Qwen2.5-14B-Instruct-Q4_K_M.gguf --local-dir ./models/Qwen2.5-14B-Instruct/ # 从官方仓库下载生成配置文件并修改 huggingface-cli download Qwen/Qwen2.5-14B-Instruct generation_config.json --local-dir ./config

你还需要设置一个generation_config.json文件。这部分很关键，我第一次尝试修改 temperature 参数时简直头大。实际上，我在官方仓库开了个 issue，连官方维护者都没能给出一个有效答复，所以我自己摸索出来了。下面是generation_config.json的样子，我在这里设置了temperature=0：

{ "bos_token_id":151643, "pad_token_id":151643, "do_sample":true, "eos_token_id":[ 151645, 151643 ], "repetition_penalty":1.05, "temperature":0.0, "top_p":0.8, "top_k":20, "transformers_version":"4.37.0" }

因此，你需要创建一个包含这个 JSON 文件的文件夹，并确保文件名精确为generation_config.json。

运行 Docker 容器，带上很多参数：

# 使用 GPU 支持运行容器 docker run -it \ --runtime nvidia \ --gpus all \ --network="host" \ --ipc=host \ -v ./models:/vllm-workspace/models \ -v ./config:/vllm-workspace/config \ vllm/vllm-openai:latest \ --model models/Qwen2.5-14B-Instruct/Qwen2.5-14B-Instruct-Q4_K_M.gguf \ --tokenizer Qwen/Qwen2.5-14B-Instruct \ --host "0.0.0.0" \ --port 5000 \ --gpu-memory-utilization 1.0 \ --served-model-name "VLLMQwen2.5-14B" \ --max-num-batched-tokens 8192 \ --max-num-seqs 256 \ --max-model-len 8192 \ --generation-config config

哇，这里发生了好多事 🤣，参数一大堆，每个都啥意思？

•--runtime nvidia --gpus all：为容器启用 NVIDIA GPU 支持。
•--network="host"：使用主机网络模式以获得更好性能。
•--ipc=host：允许主机和容器之间共享内存。
•-v ./models:/vllm-workspace/models：将本地模型目录挂载到容器中。这是包含 Qwen2.5–14B 模型的文件夹。
•--model：指定 GGUF 模型文件的路径。
•--tokenizer：定义使用的 HuggingFace 分词器。
•--gpu-memory-utilization 1：将 GPU 内存使用率设为 100%。
•--served-model-name：通过 API 服务时的自定义模型名称，你可以随意指定。
•--max-num-batched-tokens：批处理中的最大 token 数。
•--max-num-seqs：同时处理的最大序列数。
•--max-model-len：模型的最大上下文长度。

这些参数可以根据你的硬件能力和性能需求进行调整。运行这个命令后，会出现一大堆日志，别担心，一切正常。当你看到类似下面的信息时，说明 API 已经可以使用了：

这表示你的 API 已准备就绪

vLLM API 🔌

目前，我们已经在服务器（或本地机器）上运行了一个 100% 兼容 OpenAI 的 API。让我们尝试调用它，并检查单次 POST 请求和使用 Python 的 OpenAI SDK 的推理性能。

REST API 📡

vLLM 默认在 8000 端口运行本地服务器，但我喜欢 5000 端口，所以我用了这个 🤣。你可以用标准 HTTP 请求与之交互：

import requests # 基本聊天完成请求，注意 endpoint 与 Ollama 不同response = requests.post('http://192.168.100.60:5000/v1/chat/completions', json={ 'model': 'VLLMQwen2.5-14B', 'messages': [ { 'role': 'system', 'content': 'You are a helpful AI assistant.' }, { 'role': 'user', 'content': '什么是人工智能？' } ], 'stream': False })print(response.json()['choices'][0]['message']['content'])

OpenAI 兼容层 🔄

为了与现有应用无缝集成，vLLM 提供 OpenAI API 兼容性。首先，启动 OpenAI 兼容服务器：

使用 OpenAI Python SDK：

from openai import OpenAI client = OpenAI( base_url="http://<your_vLLM_server_ip>:5000/v1", api_key="dummy"# vLLM 支持要求 API key，这是它对比 Ollama 的一个优势。我们这里设为 None，所以可以随便填个字符串 ) # 聊天完成 response = client.chat.completions.create( model="VLLMQwen2.5-14B", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "什么是人工智能？"} ] ) print(response.choices[0].message.content)

初步性能测试显示，vLLM 达到了 29 tokens/sec（首 token 生成预计较慢），比第一部分记录的 Ollama 的 26 tokens/sec 提高了 11%。我们将在本系列的第三部分深入比较性能。🚀

vLLM 的日志

vLLM API 的主要功能 🎯

vLLM 的 API 专为高性能推理和生产环境设计。我们将在本教程的第三部分深入探讨其优缺点，现在先来看主要功能：

•高级 GPU 优化：利用 CUDA 和 PyTorch 最大化 GPU 使用率，带来更快的推理速度（正如我们看到的 29 tok/sec 性能）。
•批处理能力：实现连续批处理和高效内存管理，支持多个并发请求的更高吞吐量。
•安全特性：内置 API key 支持和适当的请求验证，不像其他框架完全跳过认证。
•灵活部署：全面支持 Docker，精细控制 GPU 内存使用率和模型参数。

Ollama VS vLLM

公平比较，选择最佳 OpenAI 兼容解决方案

只有一个能成为冠军，或者未必？🤔

基准测试设置 ⚡

为了确保公平比较，我们将对两种框架使用相同的硬件和模型：

硬件配置：

• GPU：NVIDIA RTX 4060 16GB Ti
• 内存：64GB RAM
• CPU：AMD Ryzen 7
• 存储：NVMe SSD

模型：

• Qwen2.5–14B-Instruct（4位量化）
• 上下文长度：8192 token
• 批处理大小：1（单用户场景）

非常公平的比较 📊

让我们分析两种框架如何以不同方式管理系统资源，重点关注它们的核心架构方法和现实世界的意义。

Ollama：

我用了一个单一问题“给我讲一个1000字的故事”作为例子。单次请求的性能为 25.59 tok/sec，没有进行并行请求。

问题：“给我讲一个1000字的故事” 用于 Ollama

对于并行请求，用户需要修改（在 Ubuntu 系统上）位于/etc/systemd/system/ollama.service的文件，添加一行Environment="OLLAMA_NUM_PARALLEL=4"，这样最多允许 4 个并行请求：

[Unit] Description=Ollama ServiceAfter=network-online.target[Service]ExecStart=/usr/local/bin/ollama serveUser=ollamaGroup=ollamaRestart=alwaysRestartSec=3Environment="PATH=/home/henry/.local/bin:/usr/local/cuda/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"Environment="OLLAMA_HOST=0.0.0.0:11434"Environment="OLLAMA_DEBUG=1"Environment="OLLAMA_NUM_PARALLEL=4"Environment="OPENAI_BASE_URL=http://0.0.0.0:11434/api"[Install] WantedBy=multi-user.target

这里是我完全不喜欢 Ollama 的地方，我认为它不适合生产环境。Ollama 会预留所有需要的内存，即便实际只用了一小部分。也就是说，即便只有 4 个并发请求，也无法将完整模型加载到 GPU 上，部分层会被加载到 CPU 上，你可以通过下面的图片或在终端运行ollama ps看到：

15%的神经网络被加载到 GPU 上

这还不是最糟的。我发现只有 15%的神经网络被加载到 GPU 上，但 GPU 还有将近 2GB 的显存空闲！为什么 Ollama 会这样？

在 GitHub 上有一个至今未关闭的问题，Ollama 开发者对此毫无回应。好几个用户都遇到了同样的问题，即使只有 4 个并行请求，加载整个神经网络似乎都非常困难。Ollama 没有任何相关文档。

了解了这个情况，Ollama 支持的最大上下文长度是多少，能否 100% 将模型加载到 GPU 上？我尝试修改 Modelfile，设置PARAMETER num_ctx 24576（稍后会解释为什么是这个数字），结果发现同样的问题：尽管 GPU 还有将近 2GB 显存空闲，4%的模型还是被加载到 CPU 上。

Ollama 将 4%的模型加载到 CPU 上 😦

vLLM：

vLLM 采用纯粹的 GPU 优化方法，正如我们在本系列第二部分看到的，GGUF 量化仍处于实验阶段。为了公平比较，我想用我的 GPU 支持的最大上下文长度。经过多次尝试，我的 RTX 4060 Ti 支持 24576 token。所以我运行了以下修改过的 Docker 命令（相比本系列第二部分）：

# 使用 GPU 支持运行容器 docker run -it \ --runtime nvidia \ --gpus all \ --network="host" \ --ipc=host \ -v ./models:/vllm-workspace/models \ -v ./config:/vllm-workspace/config \ vllm/vllm-openai:latest \ --model models/Qwen2.5-14B-Instruct/Qwen2.5-14B-Instruct-Q4_K_M.gguf \ --tokenizer Qwen/Qwen2.5-14B-Instruct \ --host "0.0.0.0" \ --port 5000 \ --gpu-memory-utilization 1.0 \ --served-model-name "VLLMQwen2.5-14B" \ --max-num-batched-tokens 24576 \ --max-num-seqs 256 \ --max-model-len 8192 \ --generation-config config

我居然能运行多达 20 个并行请求！！太疯狂了！！为了测试这个框架，我使用了以下代码：

import requests import concurrent.futuresBASE_URL = "http://<your_vLLM_server_ip>:5000/v1"API_TOKEN = "sk-1234"MODEL = "VLLMQwen2.5-14B"defcreate_request_body(): return { "model": MODEL, "messages": [ {"role": "user", "content": "给我讲一个1000字的故事。"} ] }defmake_request(request_body): headers = { "Authorization": f"Bearer {API_TOKEN}", "Content-Type": "application/json" } response = requests.post(f"{BASE_URL}/chat/completions", json=request_body, headers=headers, verify=False) return response.json()defparallel_requests(num_requests): request_body = create_request_body() with concurrent.futures.ThreadPoolExecutor(max_workers=num_requests) as executor: futures = [executor.submit(make_request, request_body) for _ inrange(num_requests)] results = [future.result() for future in concurrent.futures.as_completed(futures)] return resultsif __name__ == "__main__": num_requests = 50# 示例：设置并行请求数量 responses = parallel_requests(num_requests) for i, response inenumerate(responses): print(f"Response {i+1}: {response}")

我竟然达到了超过 100 tokens/sec！简直不敢相信这在一块游戏 GPU 上是可能的。GPU 使用率达到了 100%，这正是我想要的：充分利用 GPU（毕竟我花钱买了 100%的 GPU 🤣）。

20 个并行请求的推理！！！

这还不是最棒的，我们设置了--max-num-seqs 256，理论上可以并行发送 256 个请求！！我简直不敢相信，也许我稍后会试试这些测试。

以下是我的最终想法：

最终决定…… ⚖️

性能概览：显然 vLLM 是赢家。正如我们在第二部分看到的，单次请求下，vLLM 比 Ollama（26 tok/sec）提高了 11%（29 tok/sec）。

资源管理：vLLM 绝对是王者。看到 Ollama 无法处理多个并行请求，甚至 4 个并行请求都因为资源管理效率低下而失败，我非常失望。

易用性和开发：没有什么比 Ollama 更简单的了。即使你不是专家，也能用一行代码轻松与 LLM 交互。而 vLLM 需要一些 Docker 和更多参数的知识。

生产就绪性：vLLM 就是为此而生，甚至许多无服务器端点提供商（我有我的消息来源 🤣）都在用这个框架作为他们的端点。

安全性：vLLM 支持 token 授权以确保安全，而 Ollama 没有。如果不做好安全措施，任何人都能访问你的 Ollama 端点。

文档：两种框架的文档风格不同：Ollama 的文档简单、适合初学者，但缺乏技术深度，尤其是在性能和并行处理方面。他们的 GitHub 讨论经常对关键问题置之不理。相比之下，vLLM 提供了全面的技术文档，包含详细的 API 参考和指南。他们的 GitHub 维护良好，开发者响应及时，有助于问题排查和理解，甚至还有专门的网站。

所以，在我看来，赢家是……没有赢家！

在我看来，如果你的目标是在本地或远程服务器上快速试验大型语言模型，且不想费太多心思设置，Ollama 无疑是你的首选。它的简单易用非常适合快速原型设计、测试想法，或者适合刚开始接触 LLM 的开发者，想有个平缓的学习曲线。

然而，当我们将焦点转向性能、可扩展性和资源优化至关重要的生产环境时，vLLM 显然更胜一筹。它处理并行请求的能力、有效的 GPU 利用率和强大的文档使其成为大规模部署的强力竞争者。该框架从可用硬件资源中榨取最大性能的能力尤其令人印象深刻，对希望优化 LLM 基础设施的公司来说可能是游戏规则的改变者。

话虽如此，Ollama 和 vLLM 的选择不能孤立决定。必须根据你的具体用例，考虑以下因素：