开源的LLM已经成为程序员、爱好者和希望在日常工作中使用生成式AI并保持隐私的用户的最佳选择，对于企业的私有化部署而言也是如此。这些模型提供了优秀的性能，有时在许多任务中可以与大型的闭源模型 (如 GPT-4o 或 Claude Sonnet 3.5) 相媲美。
这些LLM是开源的，但并不意味着它们可以开箱即用，需要一个运行框架在本地或服务器上运行大模型以获得特定的用例。另外，兼容 OpenAI 的服务器已经成为部署任何模型的最流行方式，因为这些API 允许我们在几乎任何 SDK 或客户端上使用 LLM服务能力，如 OpenAI SDK，Transformers，LangChain 等等。
那么，部署LLM以兼容 OpenAI 的最佳运行框架是什么呢？这里尝试分析 Ollama 和 vLLM，这两个流行的运行框架都可以用于部署具有兼容 OpenAI API 的模型。我们可以从性能、易用性、定制和其他方面对二者进行比较。
1. Ollama
Ollama 是一个强大的运行框架，旨在使运行LLM尽可能简单。Ollama 简化了在本地机器或服务器上下载、运行和管理大型语言模型的整个过程。
使用 Ollama 很简单，可以在不同的平台上完成安装：
curl -fsSL https://ollama.com/install.sh | sh （Linux）
brew install ollama （macOS）Ollama 提供了一个现成的模型运行环境，可以用一行命令运行大模型服务： Ollama run <anymodel> 。这一命令将轻松地运行终端中 Ollama 模型存储库中列出的任何模型。例如：
ollama run qwen2.5:14b --verbose
添加了--verbose这一标志，这样就可以看到每秒的token 吞吐量(token/sec)。
1.1 Ollama 的参数
如果需要创建具有特定参数的私有模型，我们需要创建一个 Modelfile，这是一个单独的纯文本文件，其中包含了需要设置的参数。
FROM qwen2.5:14b
PARAMETER temperature 0.5
# 上下文大小
PARAMETER num_ctx 8192
# tokens最大为4096
PARAMETER num_predict 4096
# 系统的提示词配置
SYSTEM """You are a helpful AI assistant."""我们可以构建并运行该定制的模型：
# 构建模型
ollama create mymodel -f Modelfile
# 运行
ollama run mymodel --verboseOllama 提供了两种与模型交互的方式：
- 原生的REST API： Ollama 默认在端口 11434 上运行一个本地服务器，我们可以使用标准的 HTTP 请求与它交互：
import requests
response = requests.post('http://<my_ollama_server_ip>:11434/api/chat',
jsnotallow={
'model': 'qwen2.5:14b',
'messages': [
{
'role': 'system',
'content': 'You are a helpful AI assistant.'
},
{
'role': 'user',
'content': 'What is AI Agent?'
}
],
'stream': False
}
)
print(response.json()['message']['content'])- 为了实现与现有应用程序的无缝集成，Ollama 提供了 OpenAI API 兼容性，可以与 OpenAI Python SDK 一起使用：
from openai import OpenAI
client = OpenAI(
base_url="http://<my_ollama_server_ip>:11434/v1",
api_key="Abel" # 可设成任意字符串
)
response = client.chat.completions.create(
model="qwen2.5:14b",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "What is AI Agent?"}
]
)
print(response.choices[0].message.content)1.2 Ollama API 的功能特性
Ollama的API具有许多基本功能，使其成为开发人员的重要选择之一，其主要功能如下：
- 流支持：实时token生成，完全兼容OpenAI API，非常适合创建响应式应用程序。
- 多模型管理： 能够同时运行不同的模型，但有一个警告。 当 VRAM 有限时，Ollama 将停止一个模型来运行另一个模型，这需要仔细的资源规划。
- 参数控制： 通过 API 调用进行高度可定制的设置，它提供了很大的灵活性，但对于初学者和生产环境的服务器来说并不友好。
- CPU 兼容性： 当 VRAM 不足时，智能资源管理可以自动将模型卸载到 CPU执行，使得在 GPU 内存有限的系统上也可以运行大模型服务。
- 语言无关性： 可以自由使用Python、 JavaScript、 Go等编程语言，以及其他任何具有 HTTP 功能的编程语言。
2. vLLM
vLLM 是一个为 LLM 推理设计的高性能框架，侧重于效率和可伸缩性。它基于 PyTorch，它利用 CUDA 加速 GPU，并实现先进的优化技术，如连续批处理和有效的内存管理以及张量并行性，使其特别适合生产环境和高吞吐量场景。
vLLM 并不像使用 Ollama 那样简单，最佳方可能是使用 Docker 进行安装。Docker 提供了一致的环境，使得跨系统部署更加简单。使用Dock来执行vLLM的先决条件如下：
- 系统上安装了 Docker。
- NVIDIA 容器工具包 (支持 GPU)。
- 至少 16GB 内存 (推荐)。
- 为目标模型配置 NV的GPU与足够的 VRAM。
2.1 GGUF (GPT-Generated Unified Format)
GGUF 被许多人认为是 GGML 的继承者，它是一种量化方法，能够混合 CPU-GPU 执行大型语言模型，优化内存使用和推理速度。它是Ollama支持的模型运行的唯一格式。该格式在 CPU 架构和 Apple Silicon 上特别有效，支持各种量化级别 (从 4 位到 8 位) ，同时保持模型质量。
虽然 vLLM 目前仅提供了有限的 GGUF 支持，重点放在本地 GPU 优化，但是理解这种格式对于大模型运行框架的比较分析非常重要。
2.2 Docker 部署与运行
我们继续部署 Qwen 2.5-14B 作为参考模型，下载模型可能需要一点时间，取决于当前的互联网连接速度：
mkdir models/
mkdir models/Qwen2.5-14B-Instruct/
# 下载一个4bit 量化模型
wget -P models/Qwen2.5-14B-Instruct/ https://huggingface.co/lmstudio-community/Qwen2.5-14B-Instruct-GGUF/resolve/main/Qwen2.5-14B-Instruct-Q4_K_M.gguf我们还需要设置 generation_ config.son 文件, 为了测试方便，这里设置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 ./model:/vllm-workspace/model: 将本地模型目录装入容器，目录包含了示例的Qwen2.5–14B模型
--model: 指定 GGUF 模型文件的路径。
--tokenizer: 定义要使用的 HuggingFace tokenizer。
--gpu-memory-utilization 1: 将 GPU 内存使用率设置为 100% 。
--served-model-name: 通过 API 提供服务时模型的自定义名称，可以指定所需的名称。
--max-num-batched-tokens: 批处理中的最大token数量。
--max-num-seqs: 同时处理的序列的最大数目。
--max-model-len: 模型的最大上下文长度。这些参数可以根据具体的硬件能力和性能要求进行调整。运行此命令后，将显示大量日志，一旦看到类似如下的输出，就可以使用它了。
图片
默认情况下，vLLM的REST API 在端口 8000 上运行本地，可以使用标准的 HTTP 请求与它交互：
import requests
response = requests.post('http://192.168.123.23:5000/v1/chat/completions',
jsnotallow={
'model': 'VLLMQwen2.5-14B',
'messages': [
{
'role': 'system',
'content': 'You are a helpful AI assistant.'
},
{
'role': 'user',
'content': 'What is artificial intelligence?'
}
],
'stream': False
}
)
print(response.json()['choices'][0]['message']['content'])为了与现有应用程序无缝集成，vLLM 也提供了 OpenAI API 的兼容性接口。
from openai import OpenAI
client = OpenAI(
base_url="http://<my_vLLM_server_ip>:5000/v1",
api_key="Abel" # vLLM 支持API的权限认证，为了测试对比，也设为Abel
)
response = client.chat.completions.create(
model="VLLMQwen2.5-14B",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "What is AI Agent?"}
]
)
print(response.choices[0].message.content)2.3 vLLM API 特性
vLLM 的 API 是为高性能推理和生产环境设计的，主要特性如下：
- 高效 GPU 优化： 利用 CUDA 和 PyTorch 最大限度地利用 GPU，导致更快的推理速度。
- 批处理能力： 实现连续批处理和高效的内存管理，从而提高多个并发请求的吞吐量。
- 安全特性： 内置的 API 密钥支持和正确的请求验证，而不是完全跳过身份验证。
- 灵活部署： 对 GPU 内存使用和模型参数进行细粒度控制的全面 Docker 支持。
虽然vLLM需要更多的参数和环境设置，但它展示了出色的性能和面向生产环境的特性。
3. Ollama 与 vLLM 的对比
我们更应该使用哪个运行推理框架呢？我们可以从以下几个维度对比Ollama 与 vLLM ：
- 资源利用和效率
- 易于部署和维护
- 特定的用例和推荐
- 生产环境就绪和安全性
- 文档的支持程度
3.1 基准
我们对两个框架使用相同的硬件和模型：
硬件配置：
- GPU: NVIDIA RTX 4060 16GB Ti
- RAM: 64GB 内存
- CPU: AMD Ryzen 7
- 储存： NVMe SSD固态硬盘。
模型：
- Qwen2.5–14B-Instruct (4-bit 量化)
- 上下文长度： 8192 令牌。
- 批量大小： 1 (单用户情况)。
3.2 模型运行
一个简单的问题 “生成一个 1000 词的故事” 的示例。
Ollama的一个请求时间是 25秒左右，且没有执行并行请求。对于并行请求，用户必须修改位于 /etc/systemd/system/OLLAMA.service 中的文件 ( 服务器为Ubuntu的操作系统) ，并添加一行 Environment = “OLLAMA _NUM_PARALLEL = 4”，即可以最多执行 4 个并行请求。
[Unit]
Descriptinotallow=Ollama Qwen Service
After=network-online.target
[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Envirnotallow="PATH=/home/abel_cao/.local/bin:/usr/local/cuda/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Envirnotallow="OLLAMA_HOST=0.0.0.0:11434"
Envirnotallow="OLLAMA_DEBUG=1"
Envirnotallow="OLLAMA_NUM_PARALLEL=4"
Envirnotallow="OPENAI_BASE_URL=http://0.0.0.0:11434/api"
[Install]
WantedBy=multi-user.target这就是Ollama的局限性，不是面向生产环境的大模型运行框架。即使当前仅使用了部分内存，Ollama占用了所有需要的内存。即使只是 4 个并行请求，Ollama加载整个神经网络似乎仍然非常困难，而且没能找到相关的参考文档。
Ollama 可以支持的最大上下文数量是多少，以便在GPU中 100% 加载模型呢？尝试通过设置 PARAMETER num_ ctx 24576 来修改模型文件。尽管 GPU 中几乎有 2GB 的 VRAM 是空闲的，但仍然使用了 4% 的 CPU。
VLLM 有一个纯 GPU 的优化方法，GGUF 量化却仍然处于实验阶段。经过几次尝试，RTX 4060Ti 也支持了 24576 上下文数量。
import requests
import concurrent.futures
BASE_URL = "http://<my_vLLM_server_ip>:5000/v1"
API_TOKEN = "Abel-1234"
MODEL = "VLLMQwen2.5-14B"
def create_request_body():
return {
"model": MODEL,
"messages": [
{"role": "user", "content": "生成一个 1000 词的故事"}
]
}
def make_request(request_body):
headers = {
"Authorization": f"Bearer {API_TOKEN}",
"Content-Type": "application/json"
}
response = requests.post(f"{BASE_URL}/chat/completions", jsnotallow=request_body, headers=headers, verify=False)
return response.json()
def 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 results
if __name__ == "__main__":
num_requests = 50 # 并发轻轻数
responses = parallel_requests(num_requests)
for i, response in enumerate(responses):
print(f"Response {i+1}: {response}")每秒可以得到超过 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 利用率和健壮的文档使其成为在生产环境大规模部署的有力竞争者。该运行框架从可用硬件资源中挤出最大性能的能力尤其令人心动。
图片
4. 大模型运行框架的其他考量
大模型运行框架的选择必须取决于我们自己的特定用例，同时考虑以下因素：
- 项目的规模
- 团队的技术专长
- 应用程序的特定性能要求
- 开发时间表和资源
- 是否需要定制和微调
- 长期的维护和支持方面的考量
从本质上说，尽管 vLLM 可以为生产环境提供卓越的性能和可伸缩性，但是 Ollama 的简单性对于某些场景可能更具价值，特别是在开发的早期阶段或者demo级的项目中。
5. 一句话小结
大模型运行框架的采用是项目独特需求和约束最密切相关的选择。在某些情况下，甚至可以同时使用： 用于快速成型和初始开发的Ollama ，以及用于扩展和优化生产环境的 vLLM。这种混合方法可以允许我们在项目生命周期的不同阶段利用不同运行框架的优势。
