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

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

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

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

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

一、基准设置

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

1. 硬件配置：

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

2. 模型：

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

二、对比

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

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%。

2、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。这种混合方法可以让你兼得两者的优势，使你能够在项目生命周期的不同阶段利用每个框架的优势。

---

四、如何系统学习掌握AI大模型？

AI大模型作为人工智能领域的重要技术突破，正成为推动各行各业创新和转型的关键力量。抓住AI大模型的风口，掌握AI大模型的知识和技能将变得越来越重要。

学习AI大模型是一个系统的过程，需要从基础开始，逐步深入到更高级的技术。

这里给大家精心整理了一份全面的AI大模型学习资源，包括：AI大模型全套学习路线图（从入门到实战）、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！

1. 成长路线图&学习规划

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

这里，我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。

2. 大模型经典PDF书籍

书籍和学习文档资料是学习大模型过程中必不可少的，我们精选了一系列深入探讨大模型技术的书籍和学习文档，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。（书籍含电子版PDF）

3. 大模型视频教程

对于很多自学或者没有基础的同学来说，书籍这些纯文字类的学习教材会觉得比较晦涩难以理解，因此，我们提供了丰富的大模型视频教程，以动态、形象的方式展示技术概念，帮助你更快、更轻松地掌握核心知识。

4. 2024行业报告

行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

5. 大模型项目实战

学以致用 ，当你的理论知识积累到一定程度，就需要通过项目实战，在实际操作中检验和巩固你所学到的知识，同时为你找工作和职业发展打下坚实的基础。

6. 大模型面试题

面试不仅是技术的较量，更需要充分的准备。

在你已经掌握了大模型技术之后，就需要开始准备面试，我们将提供精心整理的大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

全套的AI大模型学习资源已经整理打包，有需要的小伙伴可以微信扫描下方CSDN官方认证二维码，免费领取【保证100%免费】