開源的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。這種混合方法可以允許我們在項目生命周期的不同階段利用不同運行框架的優勢。
