LLM运行框架对比:ollama与vllm浅析
推荐语
探索开源LLM部署的最佳实践,对比Ollama与vLLM的性能与易用性。
核心内容:
1. 开源LLM在企业私有化部署中的重要性
2. Ollama框架的安装与运行LLM模型的简便性
3. vLLM框架与Ollama的性能及易用性对比分析
杨芳贤
53A创始人/腾讯云(TVP)最具价值专家
开源的LLM已经成为程序员、爱好者和希望在日常工作中使用生成式AI并保持隐私的用户的最佳选择,对于企业的私有化部署而言也是如此。这些模型提供了优秀的性能,有时在许多任务中可以与大型的闭源模型 (如 GPT-4o 或 Claude Sonnet 3.5) 相媲美。
这些LLM是开源的,但并不意味着它们可以开箱即用,需要一个运行框架在本地或服务器上运行大模型以获得特定的用例。另外,兼容 OpenAI 的服务器已经成为部署任何模型的最流行方式,因为这些API 允许我们在几乎任何 SDK 或客户端上使用 LLM服务能力,如 OpenAI SDK,Transformers,LangChain 等等。
那么,部署LLM以兼容 OpenAI 的最佳运行框架是什么呢?这里尝试分析 Ollama 和 vLLM,这两个流行的运行框架都可以用于部署具有兼容 OpenAI API 的模型。我们可以从性能、易用性、定制和其他方面对二者进行比较。

Ollama 是一个强大的运行框架,旨在使运行LLM尽可能简单。Ollama 简化了在本地机器或服务器上下载、运行和管理大型语言模型的整个过程。
使用 Ollama 很简单,可以在不同的平台上完成安装:
Ollama 提供了一个现成的模型运行环境,可以用一行命令运行大模型服务:Ollama run
。这一命令将轻松地运行终端中 Ollama 模型存储库中列出的任何模型。例如:
ollama run qwen2.5:14b --verbose
添加了--verbose这一标志,这样就可以看到每秒的token 吞吐量(token/sec)。
如果需要创建具有特定参数的私有模型,我们需要创建一个 Modelfile,这是一个单独的纯文本文件,其中包含了需要设置的参数。
我们可以构建并运行该定制的模型:
Ollama 提供了两种与模型交互的方式:
Ollama的API具有许多基本功能,使其成为开发人员的重要选择之一,其主要功能如下:
vLLM 是一个为 LLM 推理设计的高性能框架,侧重于效率和可伸缩性。它基于 PyTorch,它利用 CUDA 加速 GPU,并实现先进的优化技术,如连续批处理和有效的内存管理以及张量并行性,使其特别适合生产环境和高吞吐量场景。
vLLM 并不像使用 Ollama 那样简单,最佳方可能是使用 Docker 进行安装。Docker 提供了一致的环境,使得跨系统部署更加简单。使用Dock来执行vLLM的先决条件如下:
GGUF 被许多人认为是 GGML 的继承者,它是一种量化方法,能够混合 CPU-GPU 执行大型语言模型,优化内存使用和推理速度。它是Ollama支持的模型运行的唯一格式。该格式在 CPU 架构和 Apple Silicon 上特别有效,支持各种量化级别 (从 4 位到 8 位) ,同时保持模型质量。
虽然 vLLM 目前仅提供了有限的 GGUF 支持,重点放在本地 GPU 优化,但是理解这种格式对于大模型运行框架的比较分析非常重要。
我们继续部署 Qwen 2.5-14B 作为参考模型,下载模型可能需要一点时间,取决于当前的互联网连接速度:
我们还需要设置 generation_ config.son 文件, 为了测试方便,这里设置temperature = 0。
因此,需要创建一个文件夹,其中包含这个 JSON 文件,并确保它的名称为 generation_ config. json。然后,使用多个参数运行 docker 容器:
这些参数的含义如下:
这些参数可以根据具体的硬件能力和性能要求进行调整。运行此命令后,将显示大量日志,一旦看到类似如下的输出,就可以使用它了。

默认情况下,vLLM的REST API 在端口 8000 上运行本地,可以使用标准的 HTTP 请求与它交互:
vLLM 的 API 是为高性能推理和生产环境设计的,主要特性如下:
虽然vLLM需要更多的参数和环境设置,但它展示了出色的性能和面向生产环境的特性。
我们更应该使用哪个运行推理框架呢?我们可以从以下几个维度对比Ollama 与 vLLM :
我们对两个框架使用相同的硬件和模型:
硬件配置:
模型:
一个简单的问题 “生成一个 1000 词的故事” 的示例。
Ollama的一个请求时间是 25秒左右,且没有执行并行请求。对于并行请求,用户必须修改位于 /etc/systemd/system/OLLAMA.service 中的文件 ( 服务器为Ubuntu的操作系统) ,并添加一行 Environment = “OLLAMA _NUM_PARALLEL = 4”,即可以最多执行 4 个并行请求。
这就是Ollama的局限性,不是面向生产环境的大模型运行框架。即使当前仅使用了部分内存,Ollama占用了所有需要的内存。即使只是 4 个并行请求,Ollama加载整个神经网络似乎仍然非常困难,而且没能找到相关的参考文档。
Ollama 可以支持的最大上下文数量是多少,以便在GPU中 100% 加载模型呢?尝试通过设置 PARAMETER num_ ctx 24576 来修改模型文件。尽管 GPU 中几乎有 2GB 的 VRAM 是空闲的,但仍然使用了 4% 的 CPU。
VLLM 有一个纯 GPU 的优化方法,GGUF 量化却仍然处于实验阶段。经过几次尝试,RTX 4060Ti 也支持了 24576 上下文数量。
每秒可以得到超过 100 个token,GPU 利用率达到 100% 。这里设置了并发请求数为50,所以理论上可以并行发送 50个请求!
总体而言, Ollama 和 vLLM 的综合对比如下:
性能概述: 获胜者显然是 vLLM,只有一个请求,也得到了 10% 以上的提升 (Ollama 约25 token/sec vs vLLM 约 29 token/sec)。
资源管理: vLLM 再次获胜, Ollama 不能并行处理多个请求非常令人失望,由于资源管理效率低下,它甚至不能并行处理 4 个请求。
易于使用和开发:Ollama 更容易使用,一行代码就可以轻松地与 LLM 进行快速聊天。同时,vLLM 需要一些像 docker 这样的知识和更多的参数配置。
面向生产环境: vLLM 更适合于生产环境,甚至许多AI服务提供商也在使用这个运行框架作为AI服务的端点。
安全性: vLLM 出于安全目的支持token授权,而 Ollama 不支持。因此,任何人都可以访问你的Ollama 端点,如果你没有很好地保护它。
文档化支撑: 两个框架采用不同的文档支撑方式,Ollama 的文档简单且对初学者友好,但缺乏技术深度,特别是关于性能和并行处理方面。 GitHub 上的讨论经常留下一些关键问题没有得到解答。相比之下,vLLM 提供了包含详细 API 参考和指南的全面技术文档,其GitHub 得到了开发人员的良好维护,有助于故障排除和理解,甚至还专门为此建立了一个网站。
所以,如果目标是在本地环境中或甚至在远程服务器上快速试验大模型,那么 Ollama 无疑是首选解决方案。它的简单易用性非常适合快速成型、测试想法,或者面向刚开始使用 LLM 的开发人员,学习曲线非常平滑。
然而,当重点转移到性能、可伸缩性和资源优化的生产环境时,vLLM 大放异彩。它对并行请求的出色处理、高效的 GPU 利用率和健壮的文档使其成为在生产环境大规模部署的有力竞争者。该运行框架从可用硬件资源中挤出最大性能的能力尤其令人心动。

大模型运行框架的选择必须取决于我们自己的特定用例,同时考虑以下因素:
从本质上说,尽管 vLLM 可以为生产环境提供卓越的性能和可伸缩性,但是 Ollama 的简单性对于某些场景可能更具价值,特别是在开发的早期阶段或者demo级的项目中。
大模型运行框架的采用是项目独特需求和约束最密切相关的选择。在某些情况下,甚至可以同时使用: 用于快速成型和初始开发的Ollama ,以及用于扩展和优化生产环境的 vLLM。这种混合方法可以允许我们在项目生命周期的不同阶段利用不同运行框架的优势。
【参考资料与关联阅读】