今天和大家深入讲讲大语言模型（LLM）推理框架的不同优缺点对比，方便大家根据自己的场景选择合适的推理框架。

这场对比并不是要找出来哪一个框架最好，而是要了解哪个框架在不同的场景中表现更出色。

我们将重点关注以下几个方面：

1. 资源利用和效率
2. 部署和维护的便捷性
3. 特定的用例和建议
4. 安全性和生产就绪性
5. 文档

让我们深入对比实践，看看最终结果如何吧~?

基准设置 ⚡

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

1. 硬件配置：

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

• 模型：
• Qwen2.5–14B-Instruct（int4量化）
• 上下文长度：8192 个token
• 批大小：1（单用户场景）

对比 ?

接下来我们来分析一下两个框架是如何以不同方式管理系统资源的，重点关注它们的核心架构方法以及对资源利用的影响。

Ollama：

我举一个单个问题的例子，问题是 “给我讲一个 1000 字的故事”。对于一次请求，我得到的处理速度是 25.59 个token/秒。并且没有进行并行请求。



如果要进行并行请求，对于使用 Ubuntu 系统的用户，必须修改位于 /etc/systemd/system/ollama.service 的文件，并添加一行 Environment="OLLAMA_NUM_PARALLEL=4"，这样就可以进行最多 4 个并行请求。

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="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 上，但 GPU 中几乎还有 2GB 的显存是空闲的！但为什么 Ollama 会这样呢？

知道了这些，那么 Ollama 能够支持的最大上下文长度是多少，才能将模型 100% 加载到 GPU 上呢？我尝试修改我的模型文件，设置 PARAMETER num_ctx 24576，但我注意到同样的问题还是出现了：尽管 GPU 中几乎有 2GB 的空闲显存，CPU 还是被使用了 4%。

vLLM：

vLLM 采用了纯 GPU 优化方法。为了公平对比，我想为我的 GPU 找到最大的上下文长度。经过几次尝试，我的 RTX 4060 Ti 支持 24576 个token。所以我运行了这个修改后的 Docker 命令：

# Run the container with GPU support
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.futures

BASE_URL = "http://<your_vLLM_server_ip>: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.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  # 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 个token/秒的处理速度！我简直不敢相信用一块游戏 GPU 就能做到这一点。GPU 的利用率达到了 100%，这正是我想要的：充分利用 GPU 的全部性能（毕竟我可是为 100% 的 GPU 性能付了钱的?）。



而且这还不是最棒的部分，我们设置了 --max-num-seq 256，所以理论上我们可以发送 256 个并行请求！

最终的决定… ⚖️

1. 性能概述：显然，赢家是 vLLM。对于单个请求，vLLM 有 11% 的性能提升（Ollama 是 26 个token/秒，而 vLLM 是 29 个token/秒）。
2. 资源管理：在这方面，vLLM 绝对是王者。当我看到 Ollama 无法处理很多并行请求，甚至因为资源管理效率低下而无法处理 4 个并行请求时，我非常失望。
3. 易用性和开发难度：没有什么比 Ollama 更简单易用的了。即使你不是专家，也可以使用一行代码就轻松地与大语言模型进行对话。而 vLLM 则需要一些知识，比如 Docker 以及更多的参数设置。
4. 生产就绪性：vLLM 就是为生产环境而设计的，很多公司都在他们的Node中使用这个框架。
5. 安全性：vLLM 为了安全目的支持APIKEY授权，而 Ollama 则不支持。所以，如果没有很好地保护你的节点机器，任何人都可以访问它。
6. 文档：两个框架在文档方面采取了不同的方法：Ollama 的文档简单且适合初学者，但缺乏技术深度，特别是在性能和并行处理方面。他们的 GitHub 讨论区经常有一些重要问题没有得到解答。相比之下，vLLM 提供了全面的技术文档，包括详细的 API 参考和指南。他们的 GitHub 维护得很好，开发者响应迅速，有助于解决问题和理解框架，而且他们甚至还有一个专门的网站 https://docs.vllm.ai/en/latest/ 来介绍这些内容。

所以，在我看来，赢家是…… 两个都不是！

如果你经常需要在本地环境甚至远程服务器上快速对大语言模型进行实验，而不想有太多的设置麻烦，那么 Ollama 无疑是你的首选解决方案。它的简单性和易用性使其非常适合快速原型设计、测试想法，或者对于刚开始使用大语言模型并且希望有一个平缓学习曲线的开发者来说，也是非常好的选择。

然而，当我们把重点转移到生产环境中，在这种环境下性能、可扩展性和资源优化至关重要，vLLM 显然更胜一筹。它对并行请求的出色处理能力、高效的 GPU 利用率以及强大的文档支持，使其成为用于大规模严肃部署的有力竞争者。该框架能够从可用的硬件资源中榨取最大性能，这一点尤其令人印象深刻，对于那些希望优化其大语言模型基础设施的公司来说，可能是一个改变游戏规则的因素。

也就是说，在 Ollama 和 vLLM 之间做出选择时，不能孤立地进行。这必须取决于你的特定用例，需要考虑以下因素：

1. 项目的规模
2. 你团队的技术专长
3. 应用程序的特定性能要求
4. 你的开发时间线和资源
5. 定制和微调的需求
6. 长期维护和支持的考虑因素

从本质上讲，虽然 vLLM 可能在生产环境中提供卓越的性能和可扩展性，但 Ollama 的简单性在某些情况下可能是无价的，特别是在开发的早期阶段或对于较小规模的项目。

最终，最好的选择将是最符合你项目独特需求和限制的那个。值得考虑的是，在某些情况下，你甚至可能同时使用两者而受益：使用 Ollama 进行快速原型设计和初始开发，当你准备好扩展并为生产进行优化时，再使用 vLLM。这种混合方法可以让你兼得两者的优势，使你能够在项目生命周期的不同阶段利用每个框架的优势。