vLLM-ollama 綜合對比

本文比較 vllm 和 ollama 在不同場景中的表現。我們將重點關注：資源利用率和效率、部署和維護的簡易性、具體用例和建議、安全和生產準備、文檔。

關於 LangChat

LangChat 是 Java 生態下企業級 AIGC 項目解決方案，集成 RBAC 和 AIGC 大模型能力，幫助企業快速定製 AI 知識庫、企業 AI 機器人。

支持的 AI 大模型： Gitee AI / 阿里通義 / 百度千帆 / DeepSeek / 抖音豆包 / 智譜清言 / 零一萬物 / 訊飛星火 / OpenAI / Gemini / Ollama / Azure / Claude 等大模型。

開源地址：

歡迎來到我們深入研究 LLM 推理框架的最後一部分！在第一部分和第二部分中，我們分別探討了 Ollama 和 vLLM，瞭解了它們的架構、功能和基本性能特徵。現在到了決定性的一輪：面對面的比較，以幫助您根據特定需求選擇合適的框架。

這次比較並不是要宣佈絕對的贏家——而是要了解哪種框架在不同場景中表現出色。我們將重點關注：

讓我們深入研究數據，看看我們的測試揭示了什麼！🚀

只有一個可以成爲冠軍，或者可能不是？ 🤔

1、基準測試設置⚡

爲了確保公平比較，我們將對兩個框架使用相同的硬件和模型：

硬件配置：

型號：

2、非常公平的比較📊

讓我們分析一下這兩個框架如何以不同的方式管理系統資源，重點關注它們的核心架構方法和實際影響。

2.1 Ollama

我舉了一個問題 “給我講一個 1000 字的故事” 的例子。我一個請求的 tok/sec 爲 25.59。沒有並行請求

問題：“給我講一個 1000 字的故事” 用於 Ollama

對於並行請求，用戶必須修改位於 /etc/systemd/system/ollama.service 中的文件（對於 Ubuntu）並添加一行 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 中加載

這還不是最糟糕的部分。我看到的是 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% 的模型 :(

2.2 vLLM

vLLM 採用純 GPU 優化方法，正如我們在本系列的第二部分中看到的，GGUF 量化仍處於實驗階段。我必須進行同類比較，所以我想爲我的 GPU 獲得最大的上下文長度。經過幾次嘗試，我的 RTX 4060 Ti 支持 24576 個令牌。所以我運行了這個修改後的 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 個令牌 / 秒！我不敢相信這是使用遊戲 GPU 可以實現的。 GPU 利用率達到 100%，這正是我想要的：獲得最大數量的 GPU（因爲我支付了 100% 的 GPU 🤣）。

並行 20 個請求進行推理！！！

這還不是最好的部分，我們設置了 --max-num-seq 256，所以理論上我們可以並行發送 256 個請求！！我不敢相信，也許我以後會嘗試這些測試。

以下是我的最終想法

3、最終決定……⚖️

所以，從我的角度來看，贏家是…… 沒有一個！

在我看來，如果你的目標是在本地環境甚至遠程服務器上快速試驗大型語言模型，而無需太多設置麻煩，Ollama 無疑是你的首選解決方案。它的簡單性和易用性使其非常適合快速原型設計、測試想法，或者適合剛開始使用 LLM 並希望學習曲線平緩的開發人員。

但是，當我們將重點轉移到性能、可擴展性和資源優化至關重要的生產環境時，vLLM 顯然大放異彩。它對並行請求的出色處理、高效的 GPU 利用率和強大的文檔使其成爲嚴肅、大規模部署的有力競爭者。該框架從可用硬件資源中榨取最大性能的能力尤其令人印象深刻，並且可能會改變那些希望優化其 LLM 基礎設施的公司的遊戲規則。

話雖如此，Ollama 和 vLLM 之間的決定不應憑空而來。它必須取決於你的特定用例，並考慮以下因素：

本質上，雖然 vLLM 可能爲生產環境提供更高性能和可擴展性提供支持，Ollama 的簡單性對於某些場景來說可能是無價的，尤其是在開發的早期階段或較小規模的項目。

最終，最好的選擇將是最符合你項目獨特需求和約束的選擇。值得考慮的是，在某些情況下，你甚至可能受益於同時使用：Ollama 用於快速原型設計和初始開發，而 vLLM 則用於你準備擴展和優化生產。這種混合方法可以爲你提供兩全其美的效果，讓你可以在項目生命週期的不同階段利用每個框架的優勢。

聯繫我

最後，推薦大家關注一下開源項目：LangChat，Java 生態下的 AIGC 大模型產品解決方案。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/M4EKYpEuMmBchuT0UKyNig

猜你喜歡