開源的LLM已經(jīng)成為程序員、愛好者和希望在日常工作中使用生成式AI并保持隱私的用戶的最佳選擇，對(duì)于企業(yè)的私有化部署而言也是如此。這些模型提供了優(yōu)秀的性能，有時(shí)在許多任務(wù)中可以與大型的閉源模型 (如 GPT-4o 或 Claude Sonnet 3.5) 相媲美。

這些LLM是開源的，但并不意味著它們可以開箱即用，需要一個(gè)運(yùn)行框架在本地或服務(wù)器上運(yùn)行大模型以獲得特定的用例。另外，兼容 OpenAI 的服務(wù)器已經(jīng)成為部署任何模型的最流行方式，因?yàn)檫@些API 允許我們?cè)趲缀跞魏?SDK 或客戶端上使用 LLM服務(wù)能力，如 OpenAI SDK，Transformers，LangChain 等等。

那么，部署LLM以兼容 OpenAI 的最佳運(yùn)行框架是什么呢？這里嘗試分析 Ollama 和 vLLM，這兩個(gè)流行的運(yùn)行框架都可以用于部署具有兼容 OpenAI API 的模型。我們可以從性能、易用性、定制和其他方面對(duì)二者進(jìn)行比較。

1. Ollama

Ollama 是一個(gè)強(qiáng)大的運(yùn)行框架，旨在使運(yùn)行LLM盡可能簡(jiǎn)單。Ollama 簡(jiǎn)化了在本地機(jī)器或服務(wù)器上下載、運(yùn)行和管理大型語(yǔ)言模型的整個(gè)過(guò)程。

使用 Ollama 很簡(jiǎn)單，可以在不同的平臺(tái)上完成安裝：

curl -fsSL https://ollama.com/install.sh | sh （Linux）
brew install ollama （macOS）

Ollama 提供了一個(gè)現(xiàn)成的模型運(yùn)行環(huán)境，可以用一行命令運(yùn)行大模型服務(wù)： Ollama run <anymodel> 。這一命令將輕松地運(yùn)行終端中 Ollama 模型存儲(chǔ)庫(kù)中列出的任何模型。例如：

ollama run qwen2.5:14b --verbose

添加了--verbose這一標(biāo)志，這樣就可以看到每秒的token 吞吐量(token/sec)。

1.1 Ollama 的參數(shù)

如果需要?jiǎng)?chuàng)建具有特定參數(shù)的私有模型，我們需要?jiǎng)?chuàng)建一個(gè) Modelfile，這是一個(gè)單獨(dú)的純文本文件，其中包含了需要設(shè)置的參數(shù)。

FROM qwen2.5:14b

PARAMETER temperature 0.5

# 上下文大小
PARAMETER num_ctx 8192

# tokens最大為4096 
PARAMETER num_predict 4096

# 系統(tǒng)的提示詞配置
SYSTEM """You are a helpful AI assistant."""

我們可以構(gòu)建并運(yùn)行該定制的模型：

# 構(gòu)建模型
ollama create mymodel -f Modelfile

# 運(yùn)行
ollama run mymodel --verbose

Ollama 提供了兩種與模型交互的方式：

• 原生的REST API： Ollama 默認(rèn)在端口 11434 上運(yùn)行一個(gè)本地服務(wù)器，我們可以使用標(biāo)準(zhǔn)的 HTTP 請(qǐng)求與它交互：

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'])

• 為了實(shí)現(xiàn)與現(xiàn)有應(yīng)用程序的無(wú)縫集成，Ollama 提供了 OpenAI API 兼容性，可以與 OpenAI Python SDK 一起使用：

from openai import OpenAI

client = OpenAI(
    base_url="http://<my_ollama_server_ip>:11434/v1",
    api_key="Abel" # 可設(shè)成任意字符串
)

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具有許多基本功能，使其成為開發(fā)人員的重要選擇之一，其主要功能如下：

• 流支持：實(shí)時(shí)token生成，完全兼容OpenAI API，非常適合創(chuàng)建響應(yīng)式應(yīng)用程序。
• 多模型管理： 能夠同時(shí)運(yùn)行不同的模型，但有一個(gè)警告。 當(dāng) VRAM 有限時(shí)，Ollama 將停止一個(gè)模型來(lái)運(yùn)行另一個(gè)模型，這需要仔細(xì)的資源規(guī)劃。
• 參數(shù)控制： 通過(guò) API 調(diào)用進(jìn)行高度可定制的設(shè)置，它提供了很大的靈活性，但對(duì)于初學(xué)者和生產(chǎn)環(huán)境的服務(wù)器來(lái)說(shuō)并不友好。
• CPU 兼容性： 當(dāng) VRAM 不足時(shí)，智能資源管理可以自動(dòng)將模型卸載到 CPU執(zhí)行，使得在 GPU 內(nèi)存有限的系統(tǒng)上也可以運(yùn)行大模型服務(wù)。
• 語(yǔ)言無(wú)關(guān)性： 可以自由使用Python、 JavaScript、 Go等編程語(yǔ)言，以及其他任何具有 HTTP 功能的編程語(yǔ)言。

2. vLLM

vLLM 是一個(gè)為 LLM 推理設(shè)計(jì)的高性能框架，側(cè)重于效率和可伸縮性。它基于 PyTorch，它利用 CUDA 加速 GPU，并實(shí)現(xiàn)先進(jìn)的優(yōu)化技術(shù)，如連續(xù)批處理和有效的內(nèi)存管理以及張量并行性，使其特別適合生產(chǎn)環(huán)境和高吞吐量場(chǎng)景。

vLLM 并不像使用 Ollama 那樣簡(jiǎn)單，最佳方可能是使用 Docker 進(jìn)行安裝。Docker 提供了一致的環(huán)境，使得跨系統(tǒng)部署更加簡(jiǎn)單。使用Dock來(lái)執(zhí)行vLLM的先決條件如下：

• 系統(tǒng)上安裝了 Docker。
• NVIDIA 容器工具包 (支持 GPU)。
• 至少 16GB 內(nèi)存 (推薦)。
• 為目標(biāo)模型配置 NV的GPU與足夠的 VRAM。

2.1 GGUF (GPT-Generated Unified Format)

GGUF 被許多人認(rèn)為是 GGML 的繼承者，它是一種量化方法，能夠混合 CPU-GPU 執(zhí)行大型語(yǔ)言模型，優(yōu)化內(nèi)存使用和推理速度。它是Ollama支持的模型運(yùn)行的唯一格式。該格式在 CPU 架構(gòu)和 Apple Silicon 上特別有效，支持各種量化級(jí)別 (從 4 位到 8 位) ，同時(shí)保持模型質(zhì)量。

雖然 vLLM 目前僅提供了有限的 GGUF 支持，重點(diǎn)放在本地 GPU 優(yōu)化，但是理解這種格式對(duì)于大模型運(yùn)行框架的比較分析非常重要。

2.2 Docker 部署與運(yùn)行

我們繼續(xù)部署 Qwen 2.5-14B 作為參考模型，下載模型可能需要一點(diǎn)時(shí)間，取決于當(dāng)前的互聯(lián)網(wǎng)連接速度：

mkdir models/
mkdir models/Qwen2.5-14B-Instruct/

# 下載一個(gè)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

我們還需要設(shè)置 generation_ config.son 文件, 為了測(cè)試方便，這里設(shè)置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"
}

因此，需要?jiǎng)?chuàng)建一個(gè)文件夾，其中包含這個(gè) JSON 文件，并確保它的名稱為 generation_ config. json。然后，使用多個(gè)參數(shù)運(yùn)行 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

這些參數(shù)的含義如下：

--runtime nvidia --gpus all: 啟用對(duì)容器的 NVIDIA GPU 支持。
--network="host": 使用主機(jī)網(wǎng)絡(luò)模式以獲得更好的性能。
--ipc=host:  允許主機(jī)和容器之間共享內(nèi)存。
- v ./model:/vllm-workspace/model: 將本地模型目錄裝入容器，目錄包含了示例的Qwen2.5–14B模型
--model: 指定 GGUF 模型文件的路徑。
--tokenizer: 定義要使用的 HuggingFace tokenizer。
--gpu-memory-utilization 1: 將 GPU 內(nèi)存使用率設(shè)置為 100% 。
--served-model-name: 通過(guò) API 提供服務(wù)時(shí)模型的自定義名稱，可以指定所需的名稱。
--max-num-batched-tokens: 批處理中的最大token數(shù)量。
--max-num-seqs: 同時(shí)處理的序列的最大數(shù)目。
--max-model-len: 模型的最大上下文長(zhǎng)度。

這些參數(shù)可以根據(jù)具體的硬件能力和性能要求進(jìn)行調(diào)整。運(yùn)行此命令后，將顯示大量日志，一旦看到類似如下的輸出，就可以使用它了。

圖片

默認(rèn)情況下，vLLM的REST API 在端口 8000 上運(yùn)行本地，可以使用標(biāo)準(zhǔn)的 HTTP 請(qǐng)求與它交互：

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'])

為了與現(xiàn)有應(yīng)用程序無(wú)縫集成，vLLM 也提供了 OpenAI API 的兼容性接口。

from openai import OpenAI

client = OpenAI(
    base_url="http://<my_vLLM_server_ip>:5000/v1",
    api_key="Abel" # vLLM 支持API的權(quán)限認(rèn)證，為了測(cè)試對(duì)比，也設(shè)為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 是為高性能推理和生產(chǎn)環(huán)境設(shè)計(jì)的，主要特性如下：

• 高效 GPU 優(yōu)化： 利用 CUDA 和 PyTorch 最大限度地利用 GPU，導(dǎo)致更快的推理速度。
• 批處理能力： 實(shí)現(xiàn)連續(xù)批處理和高效的內(nèi)存管理，從而提高多個(gè)并發(fā)請(qǐng)求的吞吐量。
• 安全特性： 內(nèi)置的 API 密鑰支持和正確的請(qǐng)求驗(yàn)證，而不是完全跳過(guò)身份驗(yàn)證。
• 靈活部署： 對(duì) GPU 內(nèi)存使用和模型參數(shù)進(jìn)行細(xì)粒度控制的全面 Docker 支持。

雖然vLLM需要更多的參數(shù)和環(huán)境設(shè)置，但它展示了出色的性能和面向生產(chǎn)環(huán)境的特性。

3. Ollama 與 vLLM 的對(duì)比

我們更應(yīng)該使用哪個(gè)運(yùn)行推理框架呢？我們可以從以下幾個(gè)維度對(duì)比Ollama 與 vLLM ：

• 資源利用和效率
• 易于部署和維護(hù)
• 特定的用例和推薦
• 生產(chǎn)環(huán)境就緒和安全性
• 文檔的支持程度

3.1 基準(zhǔn)

我們對(duì)兩個(gè)框架使用相同的硬件和模型：

硬件配置：

• GPU: NVIDIA RTX 4060 16GB Ti
• RAM: 64GB 內(nèi)存
• CPU: AMD Ryzen 7
• 儲(chǔ)存： NVMe SSD固態(tài)硬盤。

模型：

• Qwen2.5–14B-Instruct (4-bit 量化)
• 上下文長(zhǎng)度： 8192 令牌。
• 批量大小： 1 (單用戶情況)。

3.2 模型運(yùn)行

一個(gè)簡(jiǎn)單的問(wèn)題 “生成一個(gè) 1000 詞的故事” 的示例。

Ollama的一個(gè)請(qǐng)求時(shí)間是 25秒左右，且沒(méi)有執(zhí)行并行請(qǐng)求。對(duì)于并行請(qǐng)求，用戶必須修改位于 /etc/systemd/system/OLLAMA.service 中的文件 ( 服務(wù)器為Ubuntu的操作系統(tǒng)) ，并添加一行 Environment = “OLLAMA _NUM_PARALLEL = 4”，即可以最多執(zhí)行 4 個(gè)并行請(qǐng)求。

[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的局限性，不是面向生產(chǎn)環(huán)境的大模型運(yùn)行框架。即使當(dāng)前僅使用了部分內(nèi)存，Ollama占用了所有需要的內(nèi)存。即使只是 4 個(gè)并行請(qǐng)求，Ollama加載整個(gè)神經(jīng)網(wǎng)絡(luò)似乎仍然非常困難，而且沒(méi)能找到相關(guān)的參考文檔。

Ollama 可以支持的最大上下文數(shù)量是多少，以便在GPU中 100% 加載模型呢？嘗試通過(guò)設(shè)置 PARAMETER num_ ctx 24576 來(lái)修改模型文件。盡管 GPU 中幾乎有 2GB 的 VRAM 是空閑的，但仍然使用了 4% 的 CPU。

VLLM 有一個(gè)純 GPU 的優(yōu)化方法，GGUF 量化卻仍然處于實(shí)驗(yàn)階段。經(jīng)過(guò)幾次嘗試，RTX 4060Ti 也支持了 24576 上下文數(shù)量。 

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": "生成一個(gè) 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  # 并發(fā)輕輕數(shù)
    responses = parallel_requests(num_requests)
    for i, response in enumerate(responses):
            print(f"Response {i+1}: {response}")

每秒可以得到超過(guò) 100 個(gè)token，GPU 利用率達(dá)到 100% 。這里設(shè)置了并發(fā)請(qǐng)求數(shù)為50，所以理論上可以并行發(fā)送 50個(gè)請(qǐng)求！

總體而言， Ollama 和 vLLM 的綜合對(duì)比如下：

• 性能概述： 獲勝者顯然是 vLLM，只有一個(gè)請(qǐng)求，也得到了 10% 以上的提升 (Ollama 約25 token/sec vs vLLM 約 29 token/sec)。
• 資源管理： vLLM 再次獲勝， Ollama 不能并行處理多個(gè)請(qǐng)求非常令人失望，由于資源管理效率低下，它甚至不能并行處理 4 個(gè)請(qǐng)求。
• 易于使用和開發(fā)：Ollama 更容易使用，一行代碼就可以輕松地與 LLM 進(jìn)行快速聊天。同時(shí)，vLLM 需要一些像 docker 這樣的知識(shí)和更多的參數(shù)配置。
• 面向生產(chǎn)環(huán)境： vLLM 更適合于生產(chǎn)環(huán)境，甚至許多AI服務(wù)提供商也在使用這個(gè)運(yùn)行框架作為AI服務(wù)的端點(diǎn)。
• 安全性: vLLM 出于安全目的支持token授權(quán)，而 Ollama 不支持。因此，任何人都可以訪問(wèn)你的Ollama 端點(diǎn)，如果你沒(méi)有很好地保護(hù)它。
• 文檔化支撐： 兩個(gè)框架采用不同的文檔支撐方式，Ollama 的文檔簡(jiǎn)單且對(duì)初學(xué)者友好，但缺乏技術(shù)深度，特別是關(guān)于性能和并行處理方面。 GitHub 上的討論經(jīng)常留下一些關(guān)鍵問(wèn)題沒(méi)有得到解答。相比之下，vLLM 提供了包含詳細(xì) API 參考和指南的全面技術(shù)文檔，其GitHub 得到了開發(fā)人員的良好維護(hù)，有助于故障排除和理解，甚至還專門為此建立了一個(gè)網(wǎng)站。

所以，如果目標(biāo)是在本地環(huán)境中或甚至在遠(yuǎn)程服務(wù)器上快速試驗(yàn)大模型，那么 Ollama 無(wú)疑是首選解決方案。它的簡(jiǎn)單易用性非常適合快速成型、測(cè)試想法，或者面向剛開始使用 LLM 的開發(fā)人員，學(xué)習(xí)曲線非常平滑。

然而，當(dāng)重點(diǎn)轉(zhuǎn)移到性能、可伸縮性和資源優(yōu)化的生產(chǎn)環(huán)境時(shí)，vLLM 大放異彩。它對(duì)并行請(qǐng)求的出色處理、高效的 GPU 利用率和健壯的文檔使其成為在生產(chǎn)環(huán)境大規(guī)模部署的有力競(jìng)爭(zhēng)者。該運(yùn)行框架從可用硬件資源中擠出最大性能的能力尤其令人心動(dòng)。

圖片

4. 大模型運(yùn)行框架的其他考量

大模型運(yùn)行框架的選擇必須取決于我們自己的特定用例，同時(shí)考慮以下因素：

• 項(xiàng)目的規(guī)模
• 團(tuán)隊(duì)的技術(shù)專長(zhǎng)
• 應(yīng)用程序的特定性能要求
• 開發(fā)時(shí)間表和資源
• 是否需要定制和微調(diào)
• 長(zhǎng)期的維護(hù)和支持方面的考量

從本質(zhì)上說(shuō)，盡管 vLLM 可以為生產(chǎn)環(huán)境提供卓越的性能和可伸縮性，但是 Ollama 的簡(jiǎn)單性對(duì)于某些場(chǎng)景可能更具價(jià)值，特別是在開發(fā)的早期階段或者demo級(jí)的項(xiàng)目中。

5. 一句話小結(jié)

大模型運(yùn)行框架的采用是項(xiàng)目獨(dú)特需求和約束最密切相關(guān)的選擇。在某些情況下，甚至可以同時(shí)使用： 用于快速成型和初始開發(fā)的Ollama ，以及用于擴(kuò)展和優(yōu)化生產(chǎn)環(huán)境的 vLLM。這種混合方法可以允許我們?cè)陧?xiàng)目生命周期的不同階段利用不同運(yùn)行框架的優(yōu)勢(shì)。