vLLM vs. ollama综合对比（附DeepSeek资料下载）

摘要：大型语言模型 (LLM) 的兴起改变了 AI 驱动的应用程序，实现了从聊天机器人到自动代码生成的一切。然而，高效运行这些模型仍然是一个挑战，因为它们通常需要大量的计算资源。

大型语言模型 (LLM) 的兴起改变了 AI 驱动的应用程序，开发人员依赖于优化的推理框架，这个领域的两个杰出解决方案是 VLLM 和 Ollama。

VLLM vs. Ollama

大型语言模型 (LLM) 的兴起改变了 AI 驱动的应用程序，实现了从聊天机器人到自动代码生成的一切。然而，高效运行这些模型仍然是一个挑战，因为它们通常需要大量的计算资源。

为了解决这个问题，开发人员依赖于优化的推理框架，旨在最大限度地提高速度、最大限度地减少内存使用量并无缝集成到应用程序中。这个领域的两个杰出解决方案是 VLLM 和 Ollama——每个解决方案都满足不同的需求。

VLLM 是一个优化的推理引擎，可提供高速令牌生成和高效的内存管理，使其成为大型 AI 应用程序的理想选择。Ollama 是一个轻量级且用户友好的框架，可简化在本地机器上运行开源 LLM 的过程。

那么，你应该选择哪一个呢？在这次全面的比较中，我们将分解它们的性能、易用性、用例、替代方案和分步设置，以帮助你做出明智的决定。

在深入了解细节之前，让我们先了解这两个框架的核心目的。

VLLM（超大型语言模型）是由 SKYPILOT 构建的推理优化框架，旨在提高在 GPU 上运行的 LLM 的效率。它专注于：

使用连续批处理快速生成令牌。通过 PagedAttention 实现高效的内存使用，允许处理大型上下文窗口而不会消耗过多的 GPU 内存。无缝集成到 AI 工作流中，兼容 PyTorch 和 TensorFlow 等主要深度学习平台。

VLLM 被需要大规模高性能推理的 AI 研究人员和企业广泛使用。

Ollama 是一个本地 LLM 运行时，可简化部署和使用开源 AI 模型。它提供：

预打包模型，例如 LLaMA、Mistral 和 Falcon。优化的 CPU 和 GPU 推理，用于在日常硬件上运行 AI 模型。一个简单的 API 和 CLI，允许开发人员以最少的配置启动 LLM。

对于希望在个人机器上试验 AI 模型的开发人员和 AI 爱好者来说，Ollama 是一个绝佳的选择。

性能是选择推理框架的关键因素。让我们在速度、内存效率和可扩展性方面比较一下 VLLM 和 Ollama。

关键性能指标：

VLLM 利用 PagedAttention 来最大化推理速度并有效处理大型上下文窗口。这使得它成为聊天机器人、搜索引擎和 AI 写作助手等高性能 AI 应用程序的首选解决方案。

Ollama 提供了不错的速度，但受到本地硬件的限制。它非常适合在 MacBook、PC 和边缘设备上运行较小的模型，但在处理非常大的模型时会遇到困难。

结论：Ollama 更适合初学者，而 VLLM 是需要深度定制的开发人员的选择。

VLLM 的最佳用例

企业 AI 应用程序（例如客户服务机器人、AI 驱动的搜索引擎）在高端 GPU（A100、H100、RTX 4090 等）上部署基于云的 LLM微调和运行自定义模型需要大型上下文窗口的应用程序

不适合：个人笔记本电脑、休闲 AI 实验

Ollama 的最佳用例

在没有云资源的情况下在 Mac、Windows 或 Linux 上运行 LLM无需复杂设置即可在本地试验模型想要使用简单 API 将 AI 集成到应用程序中的开发人员边缘计算应用程序

不适合：大规模 AI 部署、繁重的 GPU 工作负载

结论：VLLM 适用于 AI 工程师，而 Ollama 适用于开发人员和业余爱好者。

4、快速上手

VLLM要首先安装依赖项：

pip install vllm

在 LLaMA 模型上运行推理：

from vllm import LLMllm = LLM(model="meta-llama/Llama-2-7b")output = llm.generate("What is VLLM?")

Ollama要安装 Ollama (Mac/Linux)：

brew install ollama

然后下载并运行模型：

ollama run mistral

调用 Ollama 的 API：

import requestsresponse = requests.post("http://localhost:11434/api/generate", json={"model": "mistral", "prompt": "Tell me a joke"})print(response.json)

结论：Ollama 更易于安装，而VLLM 提供更多定制。

现在到了决定性的一轮：面对面的比较，以帮助您根据特定需求选择合适的框架。

这次比较并不是要宣布绝对的赢家——而是要了解哪种框架在不同场景中表现出色。我们将重点关注：

资源利用率和效率部署和维护的简易性具体用例和建议安全和生产准备文档

让我们深入研究数据，看看我们的测试揭示了什么！

只有一个可以成为冠军，或者可能不是？

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

硬件配置：

GPU：NVIDIA RTX 4060 16GB TiRAM：64GB RAMCPU：AMD Ryzen 7存储：NVMe SSD

型号：

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

让我们分析一下这两个框架如何以不同的方式管理系统资源，重点关注它们的核心架构方法和实际影响。

6.1 Ollama

我举了一个问题“给我讲一个 1000 字的故事”的例子。我一个请求的 tok/sec 为 25.59。没有并行请求

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

对于并行请求，用户必须修改位于 /etc/systemd/system/ollama.service 中的文件（对于 Ubuntu）并添加一行 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 的 VRAM 可用！但 Ollama 为什么要这样做？

在我写这些行时，GitHub 上有一个问题仍未解决，但 Ollama 开发人员并未对此予以关注。几个用户都面临着同样的问题，加载整个神经网络似乎非常困难，即使我们谈论的是仅并行 4 个请求。Ollama 没有提供任何文档。

知道这一点后，Ollama 可以支持的最大上下文量是多少，才能在 GPU 中加载 100% 的模型？我尝试通过设置 PARAMETER num_ctx 24576（稍后你将看到为什么是这个数字）来修改我的模型文件，我注意到出现了同样的问题：尽管 GPU 中有近 2GB 的 VRAM 可用，但 CPU 的使用率为 4%。

Ollama 在 CPU 中加载了 4% 的模型 :(

6.2 vLLM

vLLM 采用纯 GPU 优化方法，正如我们在本系列的第二部分中看到的，GGUF 量化仍处于实验阶段。我必须进行同类比较，所以我想为我的 GPU 获得最大的上下文长度。经过几次尝试，我的 RTX 4060 Ti 支持 24576 个令牌。所以我运行了这个修改后的 docker（相对于本系列的第二部分）：

# Run the container with GPU supportdocker 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 requestsimport concurrent.futuresBASE_URL = "http://:5000/v1"API_TOKEN = "sk-1234"MODEL = "VLLMQwen2.5-14B"def create_request_body: return { "model": MODEL, "messages": [ {"role": "user", "content": "Tell me a story of 1000 words."} ] }def make_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.jsondef parallel_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 _ in range(num_requests)] results = [future.result for future in concurrent.futures.as_completed(futures)] return resultsif __name__ == "__main__": num_requests = 50 # Example: Set the number of parallel requests responses = parallel_requests(num_requests) for i, response in enumerate(responses): print(f"Response {i+1}: {response}")

我获得了超过 100 个令牌/秒！我不敢相信这是使用游戏 GPU 可以实现的。 GPU 利用率达到 100%，这正是我想要的：获得最大数量的 GPU（因为我支付了 100% 的 GPU ）。

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

这还不是最好的部分，我们设置了 --max-num-seq 256，所以理论上我们可以并行发送 256 个请求！！我不敢相信，也许我以后会尝试这些测试。

以下是我的最终想法

性能概述：获胜者显然是 vLLM。正如我们在本文第二部分中看到的那样，通过 1 个请求，我获得了 11% 的改进（Ollama 26 tok/秒 vs vLLM 29 tok/秒）。资源管理：毫无疑问，vLLM 是这里的王者。当我看到 Ollama 无法并行处理许多请求时，我感到非常失望，由于资源管理效率低下，它甚至无法并行处理 4 个请求。易用性和开发性：没有什么比 Ollama 更容易的了。即使你不是专家，也可以使用一行代码轻松与 LLM 聊天。同时，vLLM 需要一些知识，例如 docker 和更多参数。生产就绪性：vLLM 就是为此而创建的，甚至许多无服务器端点提供商公司（我有我的来源）都在将此框架用于他们的端点。安全性：vLLM 出于安全目的支持令牌授权，而 Ollama 则不支持。因此，如果你没有很好地保护它，任何人都可以访问你的端点。文档：这两个框架采用不同的文档方法：Ollama 的文档简单且适合初学者，但缺乏技术深度，尤其是在性能和并行处理方面。他们的 GitHub 讨论经常留下关键问题未得到解答。相比之下，vLLM 提供全面的技术文档，其中包含详细的 API 参考和指南。他们的 GitHub 维护良好，开发人员反应迅速，有助于排除故障和理解，他们甚至为此专门设立了一个网站。

所以，从我的角度来看，赢家是…… 没有一个！

在我看来，如果你的目标是在本地环境甚至远程服务器上快速试验大型语言模型，而无需太多设置麻烦，Ollama 无疑是你的首选解决方案。它的简单性和易用性使其非常适合快速原型设计、测试想法，或者适合刚开始使用 LLM 并希望学习曲线平缓的开发人员。

但是，当我们将重点转移到性能、可扩展性和资源优化至关重要的生产环境时，vLLM 显然大放异彩。它对并行请求的出色处理、高效的 GPU 利用率和强大的文档使其成为严肃、大规模部署的有力竞争者。该框架从可用硬件资源中榨取最大性能的能力尤其令人印象深刻，并且可能会改变那些希望优化其 LLM 基础设施的公司的游戏规则。

话虽如此，Ollama 和 vLLM 之间的决定不应凭空而来。它必须取决于你的特定用例，并考虑以下因素：

你的项目规模你团队的技术专长应用程序的特定性能要求你的开发时间表和资源定制和微调的需求长期维护和支持注意事项

本质上，虽然 vLLM 可能为生产环境提供更高性能和可扩展性提供支持，Ollama 的简单性对于某些场景来说可能是无价的，尤其是在开发的早期阶段或较小规模的项目。

最终，最好的选择将是最符合你项目独特需求和约束的选择。值得考虑的是，在某些情况下，你甚至可能受益于同时使用：Ollama 用于快速原型设计和初始开发，而 vLLM 则用于你准备扩展和优化生产。这种混合方法可以为你提供两全其美的效果，让你可以在项目生命周期的不同阶段利用每个框架的优势。

DeepSeek资料下载方式