Ollama، vLLM و llama.cpp: کدام برای اجرای محلی؟

هر سه ابزار مدل زبانی با وزن باز را روی سرور خودتان اجرا می‌کنند و API سازگار با OpenAI می‌دهند، ولی برای سه کار متفاوت ساخته شده‌اند. llama.cpp موتور C/C++ اجرای مدل‌های GGUF است که روی تقریباً هر سخت افزاری کار می‌کند: CPU، GPUهای NVIDIA و AMD، Apple Silicon و Vulkan، حتی وقتی مدل در VRAM جا نشود. Ollama روی همین موتور ساخته شده و نصب، دانلود مدل و سرویس را به چند دستور ساده تبدیل می‌کند؛ برای یک نفر تا یک تیم کوچک بهترین شروع است. vLLM سرور سرویس دهی پایتونی برای GPU است که با PagedAttention و continuous batching ده‌ها تا صدها درخواست هم‌زمان را جواب می‌دهد و مدل را مستقیم از Hugging Face (فرمت safetensors) اجرا می‌کند؛ ابزار مناسب سرویس سازمانی روی GPU دیتاسنتری است و نسخه‌ی GPU آن فقط روی لینوکس نصب می‌شود.

مقایسه‌ی کلی#

رابطه‌ی سه ابزار#

• llama.cpp لایه‌ی پایه است: پیاده سازی C/C++ بدون وابستگی روی کتابخانه‌ی ggml، به همراه ابزارهایی مثل llama-cli، llama-server، llama-quantize و llama-bench.
• Ollama در README خودش llama.cpp را backend معرفی می‌کند. کار Ollama مدیریت است: کتابخانه‌ی مدل با نام‌هایی مثل llama3.1:8b، سرویس systemd، بارگذاری و خارج کردن خودکار مدل از حافظه، و API.
• vLLM پروژه‌ی جداگانه‌ای است که در Sky Computing Lab دانشگاه برکلی شروع شد و روی PyTorch کار می‌کند. هدفش throughput بالا در سرویس دهی است، نه اجرا روی هر سخت افزاری.

فرمت مدل: GGUF یا safetensors#

GGUF فرمت تک فایلی llama.cpp است که وزن‌ها (معمولاً کوانتیزه شده)، tokenizer و metadata مدل را با هم نگه می‌دارد. Ollama و llama.cpp با همین فرمت کار می‌کنند. تبدیل مدل Hugging Face به GGUF و بعد کوانتیزه کردن آن با ابزارهای خود llama.cpp انجام می‌شود:

python convert_hf_to_gguf.py --outfile model-bf16.gguf --outtype bf16 /path/to/hf-model
./build/bin/llama-quantize model-bf16.gguf model-Q4_K_M.gguf Q4_K_M

Ollama فایل GGUF را هنگام import کوانتیزه نمی‌کند؛ فایلی را بدهید که از قبل کوانتیزه شده است. Ollama پوشه‌ی safetensors را هم برای معماری‌هایی که پشتیبانی می‌کند مستقیم می‌پذیرد (FROM /path/to/safetensors در Modelfile).

safetensors فرمت استاندارد مدل‌ها در Hugging Face است و vLLM مستقیم با آن کار می‌کند: vllm serve نام repository را می‌گیرد، مدل را دانلود و اجرا می‌کند. طبق README، vLLM بیش از ۲۰۰ معماری مدل را پشتیبانی می‌کند. پشتیبانی GGUF در vLLM طبق مستندات خودش «بسیار آزمایشی و بهینه نشده» است، به plugin جداگانه‌ی vllm-gguf-plugin نیاز دارد و مستندات توصیه می‌کند tokenizer مدل پایه را جدا بدهید. اگر مدل در قالب GGUF دارید، آن را با llama.cpp یا Ollama اجرا کنید.

quantization#

در vLLM همه‌ی روش‌ها روی همه‌ی GPUها کار نمی‌کنند. مثلاً طبق جدول سخت افزار vLLM، FP8 از نوع W8A8 فقط روی Ada و Hopper پشتیبانی می‌شود و روی Ampere (مثل A100) وزن FP8 فقط با kernel از نوع Marlin اجرا می‌شود؛ جزئیات در مقایسه‌ی H100 و A100 آمده است. حافظه‌ی لازم برای هر دقت را با سخت افزار لازم برای اجرای LLM روی سرور حساب کنید.

سخت افزار#

• فقط CPU: llama.cpp مناسب‌ترین گزینه است؛ برای x86 از AVX، AVX2، AVX512 و AMX و روی ARM از NEON استفاده می‌کند. Ollama همین توانایی را از llama.cpp به ارث می‌برد. vLLM نسخه‌ی CPU دارد (image داکر vllm/vllm-openai-cpu)، ولی هدف اصلی‌اش GPU است.
• مدل بزرگ‌تر از VRAM: llama.cpp و Ollama بخشی از لایه‌ها را روی GPU و بقیه را روی CPU اجرا می‌کنند (-ngl در llama.cpp). سرعت افت می‌کند، ولی مدل اجرا می‌شود.
• GPU قدیمی: Ollama کارت‌های NVIDIA از compute capability 5.0 را پشتیبانی می‌کند (کارت‌های 5.0 تا 6.2 با درایور 570 به بعد). vLLM دست کم 7.5 می‌خواهد؛ یعنی T4 و RTX سری 20 به بعد.
• AMD: vLLM روی Instinct MI200، MI300 و MI350 و Radeon RX 7900 و سری 9000 با ROCm 6.3 به بالا کار می‌کند. Ollama درایور ROCm v7 می‌خواهد و llama.cpp با backend از نوع HIP یا Vulkan کار می‌کند.
• Apple Silicon: llama.cpp و Ollama با Metal روی Mac با تراشه‌ی سری M اجرا می‌شوند. vLLM برای macOS فقط wheel مخصوص CPU منتشر می‌کند و GPU اپل را از طریق plugin سخت افزاری پشتیبانی می‌کند.

چند GPU#

• Ollama: اگر مدل در یک GPU جا شود، روی همان GPU بارگذاری می‌شود تا داده‌ی کمتری از باس PCI عبور کند. در غیر این صورت بین همه‌ی GPUهای موجود پخش می‌شود.
• llama.cpp: با --split-mode سه حالت دارد. layer (پیش فرض) همان pipeline parallelism است: هر GPU بخشی از لایه‌ها را نگه می‌دارد و با لینک کند بین کارت‌ها هم کار می‌کند. tensor هر لایه را بین GPUها تقسیم می‌کند، تأخیر هر توکن را کم می‌کند، به لینک سریع بین کارت‌ها وابسته است و هنوز آزمایشی است. --tensor-split 3,1 سهم هر کارت را تعیین می‌کند. برای اجرا روی چند سیستم، backend از نوع RPC هم هست.
• vLLM: داخل یک سرور --tensor-parallel-size برابر تعداد GPUها و بین چند سرور ترکیب آن با --pipeline-parallel-size برابر تعداد سرورها؛ برای اجرای چند سروری به طور پیش فرض از Ray استفاده می‌کند. مستندات vLLM برای کارت‌های بدون NVLink مثل L40S، pipeline parallelism را پیشنهاد می‌کند.

کاربر هم‌زمان و throughput#

vLLM برای بار چند کاربره دو تکنیک اصلی دارد. PagedAttention حافظه‌ی KV cache هر درخواست را، مثل صفحه بندی حافظه در سیستم عامل، در بلوک‌های کوچک با اندازه‌ی ثابت نگه می‌دارد؛ لازم نیست برای هر درخواست از ابتدا حافظه‌ی پیوسته برای بیشترین طول ممکن رزرو شود. تیم vLLM در ۲۰۲۳ اعلام کرد سیستم‌های پیشین ۶۰ تا ۸۰ درصد این حافظه را هدر می‌دادند و با PagedAttention هدر رفتن حافظه به کمتر از ۴ درصد می‌رسد. continuous batching درخواست تازه را در گام‌های بعدی تولید وارد batch در حال اجرا می‌کند و منتظر تمام شدن batch قبلی نمی‌ماند. chunked prefill و prefix caching (استفاده‌ی دوباره از KV cache بخش مشترک promptها) هم در نسخه‌ی فعلی vLLM به طور پیش فرض روشن‌اند.

vLLM از همان ابتدا بخش بزرگی از VRAM را برای خودش برمی‌دارد: پیش فرض --gpu-memory-utilization در نسخه‌ی 0.30 برابر 0.92 است، یعنی ۹۲ درصد حافظه‌ی GPU. اگر برنامه‌ی دیگری هم از همان GPU استفاده می‌کند، این عدد را کم کنید.

llama.cpp در llama-server چند slot موازی دارد (-np، پیش فرض خودکار) و continuous batching به طور پیش فرض روشن است. به طور پیش فرض یک KV cache مشترک بین همه‌ی slotها استفاده می‌شود و وضعیت هر slot از endpoint /slots دیده می‌شود.

Ollama به طور پیش فرض برای هر مدل فقط یک درخواست را هم‌زمان پردازش می‌کند (OLLAMA_NUM_PARALLEL=1) و بقیه را تا ۵۱۲ درخواست در صف نگه می‌دارد؛ بعد از آن خطای 503 می‌دهد. با بالا بردن OLLAMA_NUM_PARALLEL، حافظه‌ی لازم به نسبت OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH بالا می‌رود. تنظیم این متغیرها در آموزش Ollama آمده است.

در عمل، برای یک توسعه دهنده یا چند کاربر گاه به گاه، تفاوت سرعت این سه ابزار کم است. وقتی ده‌ها درخواست هم‌زمان با context طولانی دارید، مدیریت حافظه‌ی KV cache و batching در vLLM تعداد کاربر قابل سرویس روی همان GPU را بالا می‌برد. عدد دقیق را فقط با آزمون بار روی مدل و سخت افزار خودتان می‌گیرید.

API سازگار با OpenAI و امنیت#

چون هر سه با OpenAI سازگارند، برنامه‌ای که با Ollama ساخته‌اید با عوض کردن base_url (مثلاً از http://localhost:11434/v1 به http://localhost:8000/v1) و نام مدل به vLLM یا llama.cpp منتقل می‌شود.

نصب#

Ollama#

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

روی ویندوز irm https://ollama.com/install.ps1 | iex در PowerShell، یا نصب کننده‌ی OllamaSetup.exe. image رسمی داکر ollama/ollama است. روی سرور، اسکریپت را پیش از اجرا دانلود و بخوانید؛ جزئیات، نصب دستی و نصب بدون اینترنت در آموزش Ollama است.

vLLM#

روش توصیه شده در مستندات vLLM، محیط مجازی پایتون با uv است:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

export VLLM_API_KEY="$(openssl rand -hex 32)"
vllm serve Qwen/Qwen2.5-1.5B-Instruct --host 127.0.0.1 --port 8000

wheel پیش فرض vLLM 0.30.0 روی PyPI برای CUDA 13.0 ساخته شده است. image داکر هم برای همین نسخه منتشر شده است (vllm/vllm-openai:v0.30.0؛ برای CUDA 12.9 tag v0.30.0-cu129، برای ROCm vllm/vllm-openai-rocm:v0.30.0). vLLM به طور پیش فرض generation_config.json مدل را برای پارامترهای نمونه برداری اعمال می‌کند. برای مدل روی چهار GPU:

vllm serve <model> --tensor-parallel-size 4 --host 127.0.0.1

llama.cpp#

نسخه‌ی آماده با brew install llama.cpp (macOS و لینوکس)، winget install llama.cpp (ویندوز) یا conda-forge نصب می‌شود. image داکر سرور ghcr.io/ggml-org/llama.cpp است، با tag server-cuda برای CUDA 12، server-cuda13 برای CUDA 13، server-rocm برای ROCm و server-vulkan برای Vulkan. build از سورس برای GPU از نوع NVIDIA:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j 8

اجرای سرور با یک فایل GGUF محلی، context هشت هزار توکنی و چهار slot:

./build/bin/llama-server -m ./model-Q4_K_M.gguf -c 8192 -np 4 \
    --host 127.0.0.1 --port 8080 --api-key-file /etc/llama/keys

با -hf <user>/<model> مدل مستقیم از Hugging Face دانلود می‌شود و اگر quant را مشخص نکنید، Q4_K_M برداشته می‌شود. -ngl تعداد لایه‌های روی GPU را تعیین می‌کند (پیش فرض auto).

کدام را انتخاب کنیم#

پیش از انتخاب نهایی، همان مدل را با quantization مشابه روی سخت افزار واقعی با دو ابزار اجرا کنید و با تعداد درخواست هم‌زمانی که در ساعت اوج انتظار دارید آزمون بار بگیرید. زمان رسیدن اولین توکن و توکن بر ثانیه‌ی هر کاربر را در هر دو ثبت کنید؛ اگر Ollama در این عدد هم‌زمانی پاسخ قابل قبول می‌دهد، دلیلی برای پیچیدگی بیشتر vLLM ندارید.