مقایسه Ollama و vLLM: کدام سرور برای اجرای مدل مناسب است؟

مقایسه Ollama و vLLM در یک پاراگراف

Ollama یک مدیر مدل است که یک سرور داخلی دارد: وزن‌های کوانتایز شده را دانلود و بارگذاری می‌کند و روی 127.0.0.1:11434 پاسخ می‌دهد، حتی اگر دستگاه فقط به CPU مجهز باشد. در مقابل، vLLM یک موتور پردازش با توان عملیاتی بالا است: این ابزار GPU را با اجرای همزمان چندین درخواست در حالت اشباع نگه می‌دارد و برای دستگاه‌های فاقد GPU گزینه مناسبی نیست. کل تصمیم‌گیری به همین نکته برمی‌گردد؛ تعامل یک کاربر با یک دستیار محلی، وظیفه Ollama است، در حالی که سرویس‌دهی به یک تیم، وظیفه vLLM محسوب می‌شود.

هر دو ابزار از API سازگار با OpenAI پشتیبانی می‌کنند، بنابراین کد کلاینت با تغییر base URL به‌راحتی بین آن‌ها جابه‌جا می‌شود. تفاوت در API نیست، بلکه در نحوه مدیریت درخواست دوم در زمانی است که درخواست اول هنوز در حال تولید توکن است.

Ollama دقیقاً چیست

Ollama یک لایهٔ تسهیل‌کننده است. این ابزار با یک دستور نصب، یک رجیستری مدل (ollama pull llama3.1:8b)، فضای ذخیره‌سازی محلی برای وزن‌ها، یک رابط چت، یک سرویس systemd و یک HTTP API در اختیار شما قرار می‌دهد. اکثر مدل‌هایی که Ollama ارائه می‌دهد فایل‌های GGUF هستند که معمولاً با دقت 4-bit کوانتایز شده‌اند؛ به همین دلیل است که یک مدل 7B یا 8B به جای 16 گیگابایت، حدود 5 گیگابایت روی دیسک فضا اشغال می‌کند. کوانتایز کردن، حافظهٔ مورد نیاز برای استنتاج (inference) روی CPU را کاهش می‌دهد. در سیستم‌های Apple Silicon، این ابزار می‌تواند مدل‌های مبتنی بر safetensors را نیز از طریق موتور MLX اجرا کند و از نسخه v0.40.0 (سپتامبر 2026) به بعد، معماری‌های پشتیبانی‌شده به‌طور خودکار روی MLX اجرا می‌شوند.

اجراکنندهٔ GGUF در Ollama بر پایه llama.cpp ساخته شده است؛ کتابخانهٔ استنتاج C++ که کوانتایز GGUF را روی سخت‌افزارهای معمولی عملیاتی کرد. تا اکتبر 2026، Ollama از دو موتور llama.cpp و MLX پشتیبانی می‌کند و نسخه‌های لینوکس نیز از استنتاج MLX با CUDA پشتیبانی می‌کنند. راهنمای توسعه، این بک‌اند را با cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 و با پیش‌نیازهای CUDA 13+ و cuDNN 9+ فعال می‌کند. بنابراین وقتی افراد Ollama را با llama.cpp مقایسه می‌کنند، در واقع در حال مقایسهٔ یک لایهٔ ارگونومیک با ابزاری هستند که آن لایه در بر گرفته است.

هدف طراحی این ابزار، یک کاربر واحد است. تا اکتبر 2026، مقدار پیش‌فرض برای OLLAMA_NUM_PARALLEL برابر با 1 است؛ این یعنی یک مدل در هر لحظه یک درخواست را پردازش می‌کند و سایر درخواست‌ها در صفی که به‌طور پیش‌فرض 512 ورودی دارد (OLLAMA_MAX_QUEUE)، منتظر می‌مانند. شما می‌توانید تنظیمات موازی‌سازی را افزایش دهید، اما بخش زیر هزینه‌های این کار را توضیح می‌دهد. اگر قبلاً با Ollama کار نکرده‌اید، با میزبانی Ollama روی یک VPS و بستن پورت 11434 شروع کنید، زیرا API محلی آن هیچ‌گونه احراز هویتی ندارد.

vLLM دقیقاً چیست

vLLM صرفاً یک سرور استنتاج (inference server) است و هیچ کارکرد دیگری ندارد. این ابزار یک کتابخانه مدل را مدیریت نمی‌کند، یک vllm chat کلاینت برای سروری که در حال اجراست فراهم می‌کند و در زمان درخواست، مدلی را برای شما دانلود نمی‌کند. شما در هنگام راه‌اندازی، نام یک مخزن Hugging Face را مشخص می‌کنید، vLLM همان یک مدل را بارگذاری کرده و تا زمانی که پروسه را متوقف نکنید، به آن سرویس می‌دهد.

آنچه در ازای این محدودیت به دست می‌آورید، توان عملیاتی (throughput) است. دو مکانیزم این کار را انجام می‌دهند. PagedAttention کش KV (کش کلید-مقدار، یعنی وضعیت توجه به ازای هر توکن که مدل برای هر درخواست فعال نگه می‌دارد) را در بلوک‌هایی با اندازه ثابت ذخیره می‌کند؛ دقیقاً همان‌طور که یک سیستم‌عامل حافظه را صفحه‌بندی (page) می‌کند. یک درخواست دیگر نیازی به رزرو یک فضای بزرگ و پیوسته برای بدترین سناریوی ممکن ندارد؛ بنابراین حافظه‌ای که قبلاً رزرو شده و بلااستفاده می‌ماند، برای درخواست‌های همزمان بیشتر آزاد می‌شود. Continuous batching به یک درخواست جدید اجازه می‌دهد تا به جای انتظار برای پایان یافتن دسته (batch) فعلی، در مرحله رمزگشایی (decoding) بعدی به دسته در حال اجرا بپیوندد. یک توالی تکمیل‌شده بلافاصله دسته را ترک می‌کند و جایگاه آن پر می‌شود.

نتیجه عملی این است: روی یک GPU واحد، افزایش تعداد کاربران همزمان از یک به سی نفر، تعداد کل توکن‌ها در ثانیه را به‌شدت بالا می‌برد، در حالی که سرعت به ازای هر کاربر بسیار کمتر از حد انتظار کاهش می‌یابد. در تنظیمات پیش‌فرض Ollama، افزایش کاربران از یک به سی نفر، صرفاً باعث می‌شود بیست و نه نفر منتظر بمانند.

دسته‌بندی پیوسته (Continuous batching) تفاوت اصلی است

پنج درخواست را تصور کنید که هم‌زمان به یک سرور روی سخت‌افزاری مشابه می‌رسند.

Ollama با تنظیمات پیش‌فرض، درخواست اول را تا پایان اجرا می‌کند، سپس به سراغ درخواست دوم می‌رود و به همین ترتیب ادامه می‌دهد. نفر پنجم باید منتظر چهار تولید کامل بماند. توان عملیاتی (throughput) کلی تقریباً برابر با سرعت یک تولید است، زیرا پردازنده در هر لحظه فقط روی یک توالی کار می‌کند.

vLLM هر پنج درخواست را در یک forward pass مشابه رمزگشایی می‌کند. تولید یک توکن برای پنج توالی، هزینه‌ای تقریباً برابر با تولید یک توکن برای یک توالی دارد؛ زیرا بخش پرهزینه، خواندن وزن‌های مدل از حافظه است و این خواندن بین کل دسته (batch) به اشتراک گذاشته می‌شود. این همان واقعیتِ پهنای‌باند حافظه است که باعث کندی استنتاج (inference) روی CPU می‌شود: شما هزینه جابه‌جایی وزن‌ها را می‌پردازید، نه هزینه محاسبات ریاضی را.

شما می‌توانید OLLAMA_NUM_PARALLEL=4 را تنظیم کنید و بخشی از این قابلیت را به دست آورید. هزینه این کار، حافظه است. هر اسلات موازی به KV cache اختصاصی خود نیاز دارد و Ollama تخصیص کانتکست را ضرب می‌کند، نه تقسیم؛ در FAQ آن ذکر شده که رم مورد نیاز با ضریب OLLAMA_NUM_PARALLEL در OLLAMA_CONTEXT_LENGTH مقیاس می‌شود. بنابراین، چهار درخواست موازی برای مدلی که برای 8192 توکن پیکربندی شده، هر کدام 8192 توکن را نگه می‌دارند، اما سرور باید در مجموع کش برای 32768 توکن را در خود جای دهد. عدد 8192 خود یک انتخاب است، نه یک مقدار ثابت؛ بنابراین افزایش num_ctx و محاسبه هزینه رم آن گامی است که تعیین می‌کند آیا چهار اسلات اصلاً در حافظه جا می‌شوند یا خیر. کش صفحه‌بندی‌شده (paged cache) در vLLM همان چیزی است که از رزرو کامل پنجره برای هر اسلات از همان ابتدا جلوگیری می‌کند، زیرا بلوک‌ها در حین رشد واقعی درخواست، به آن اختصاص می‌یابند. در هر صورت، سقف تعداد کاربرانی که یک سرور می‌تواند هم‌زمان سرویس‌دهی کند، به اندازه KV cache، هزینه prefill و عمق صف بستگی دارد؛ که این همان دلیلی است که سروری که برای یک نفر عملکرد مناسبی داشت، با پنج نفر کند می‌شود.

نصب و سرویس‌دهی با Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

اسکریپت نصب، یک کاربر سیستمی به نام ollama ایجاد می‌کند، فایل باینری را نصب کرده و ollama.service را که به 127.0.0.1:11434 متصل است، ثبت می‌کند. مقدار eval rate که توسط --verbose چاپ می‌شود، تعداد واقعی توکن در ثانیه روی آن دستگاه است. به این عدد بیش از هر آمار منتشرشده‌ای اعتماد کنید. یک بار خواندن از یک پرامپت، صرفاً یک نقطه شروع است و نه یک عدد ظرفیت؛ بنابراین زمان‌سنجی توکن در ثانیه در یک بازه هم‌روندی همان چیزی است که به شما می‌گوید آیا دستگاه در بار کاری مورد انتظار شما دوام می‌آورد یا خیر، و آیا اجاره یک GPU به‌صرفه‌تر از پرداخت هزینه به ازای هر توکن است.

برای افزایش هم‌روندی (concurrency)، از یک drop-in در systemd استفاده کنید تا با ارتقای نرم‌افزار، تغییرات شما بازنویسی نشود:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps نشان می‌دهد چه چیزی بارگذاری شده است و ستون PROCESSOR آن حقیقت را بیان می‌کند. 100% CPU به این معنی است که هیچ GPU درگیر نیست؛ این توضیح صادقانه‌ای برای اکثر گزارش‌هایی است که می‌گویند Ollama کند است. خط OLLAMA_KEEP_ALIVE=30m در آن فایل drop-in، حتی در یک دستگاه خلوت نیز اهمیت زیادی دارد، زیرا مقدار پیش‌فرض، مدل را پس از پنج دقیقه بدون درخواست تخلیه می‌کند و نگه داشتن مدل در حافظه بین درخواست‌ها همان چیزی است که باعث می‌شود اولین پرامپت پس از یک وقفه تا نیم‌ساعت، دوباره هزینه کامل زمان بارگذاری را نپردازد. اگر دوره‌های خلوت شما طولانی‌تر از این است، مقدار بیشتری تنظیم کنید.

نصب و سرویس‌دهی با vLLM

نسخه‌های GPU در vLLM به Linux نیاز دارند (پشتیبانی از CPU در macOS روی Apple Silicon با یک wheel از پیش ساخته‌شده در نسخه 0.32.0 ارائه شده است، و شتاب‌دهنده GPU در آن مک‌ها از طریق vLLM-Metal تأمین می‌شود که یک افزونه جداگانه و تحت نگهداری جامعه است که بر پایه MLX ساخته شده). در مورد Python، نسخه فعلی (0.32.0، اکتبر 2026) از نسخه‌های 3.11 تا 3.14 پشتیبانی می‌کند و راهنمای نصب نیز همین بازه را ذکر کرده است. پشتیبانی از Python 3.10 در نسخه 0.32.0 حذف شد، بنابراین نسخه 3.12 که در ادامه استفاده شده، انتخاب مطمئنی است. آن را در یک virtual environment اختصاصی نصب کنید، زیرا این ابزار یک نسخه خاص از PyTorch را فراخوانی می‌کند:

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

خط آخر در راهنمای نصب NVIDIA برای vLLM تا اکتبر 2026 وجود دارد. این خط کرنل‌های از پیش کامپایل‌شده FlashInfer را نصب می‌کند. بدون این کرنل‌ها، vLLM در زمان راه‌اندازی اقدام به دانلود و کامپایل کرنل‌ها می‌کند که طبق راهنما، می‌تواند چندین دقیقه به زمان شروع در پردازنده‌های گرافیکی Hopper و جدیدتر اضافه کند. پس از هر بار ارتقای vLLM، این دستور را دوباره اجرا کنید، زیرا اگر کرنل‌ها مطابقت نداشته باشند، FlashInfer از import شدن خودداری می‌کند.

سپس یک مدل را سرویس‌دهی کنید. نام مدل، شناسه مخزن در Hugging Face است، نه یک تگ کوتاه:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

راه‌اندازی در اولین بار کند است، زیرا وزن‌های مدل دانلود شده و سپس GPU پروفایل می‌شود تا مشخص شود چه تعداد بلوک KV cache در آن جای می‌گیرد. این سرویس روی پورت 8000 گوش می‌دهد. پیش از نوشتن هرگونه کد کلاینت، آن را بررسی کنید:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

اگر Docker از قبل روی سیستم نصب است، استفاده از image رسمی، نیاز به مدیریت وابستگی‌های CUDA را برطرف می‌کند:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

فلگ --ipc=host به کانتینر اجازه دسترسی به حافظه اشتراکی میزبان را می‌دهد؛ افزایش --shm-size گزینه دیگری برای این کار است. PyTorch تانسورها را بین پردازش‌ها از طریق حافظه اشتراکی منتقل می‌کند، به‌ویژه برای استنتاج موازی تانسوری (tensor-parallel inference).

فلگ‌هایی که در محیط production بیشترین اهمیت را دارند عبارتند از --max-model-len (پنجره متنی که مایل به پرداخت هزینه آن هستید)، --gpu-memory-utilization (کسری از کارت گرافیک که vLLM مجاز است اشغال کند، که تا اکتبر 2026 به‌صورت پیش‌فرض 0.92 است)، --tensor-parallel-size برای تقسیم یک مدل روی چندین GPU، و --api-key.

احراز هویت در vLLM یک فلگ است، اما در API محلی Ollama وجود ندارد

vLLM در صورت تعیین توکن، آن را به عنوان bearer token اعمال می‌کند:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

همین مقدار می‌تواند از طریق متغیر محیطی VLLM_API_KEY نیز تنظیم شود. درخواست به مسیرهای /v1 بدون این توکن، با خطای HTTP 401 مواجه می‌شود. با این حال، این کلید تمام سرور را پوشش نمی‌دهد. راهنمای امنیتی vLLM و کد احراز هویت در نسخه 0.32.0، آن را فقط برای endpointهای تحت پیشوند مسیرهای /v1، /v2، /inference و /cohere اعمال می‌کنند. متن راهنمای --api-key در صفحه vllm serve تنها سه مورد اول را ذکر کرده است، اما کد برنامه هر چهار مورد را بررسی می‌کند. هم راهنما و هم متن راهنما تأکید دارند که سایر endpointها، به‌ویژه /invocations که همان قابلیت استنتاج (inference) را مانند /v1 ارائه می‌دهد، احراز هویت نمی‌شوند. همین موضوع دلیل کافی برای عدم انتشار پورت 8000 روی یک رابط عمومی است. راهنمای امنیتی vLLM همچنین محدودیت نرخ (rate limiting) را به یک reverse proxy در مقابل آن واگذار می‌کند و توکنی که از طریق HTTP ساده ارسال شود، در حین انتقال قابل خواندن است؛ با این حال، وجود این فلگ به این معناست که سرور مفهوم فراخواننده (caller) را درک می‌کند.

API محلی Ollama نیازی به احراز هویت ندارد. مدل‌های ابری، انتشار مدل و دانلود مدل‌های خصوصی نیازمند ورود به سیستم هستند؛ دسترسی مستقیم API به ollama.com به یک API key نیاز دارد. هر فرآیندی که بتواند به پورت 11434 دسترسی پیدا کند، می‌تواند مدل‌ها را اجرا، دریافت (pull) یا حذف کند. آن را روی loopback نگه دارید و از طریق یک VPN از نوع WireGuard که خودتان میزبانی می‌کنید یا یک reverse proxy احراز هویت‌کننده که TLS (امنیت لایه انتقال) را خاتمه می‌دهد، به آن متصل شوید.

سخت‌افزار: نیازهای هر مورد

برنامه Ollama روی CPU اجرا می‌شود. یک مدل با کوانتیزاسیون 4-bit تقریباً به ازای هر یک میلیارد پارامتر، به نیم گیگابایت RAM نیاز دارد؛ به علاوه حدود یک گیگابایت برای سربار زمان اجرا و مقداری بیشتر برای context. بنابراین یک مدل 3B به حدود 4 گیگابایت فضای آزاد و یک مدل 8B به حدود 8 گیگابایت نیاز دارد. سرعت روی یک vCPU اشتراکی، تک‌رقمی یا در حد پایین دو‌رقمی توکن در ثانیه است. این محدودیت ناشی از پهنای باند حافظه است، نه پیکربندی نادرست، و هیچ flagای آن را اصلاح نمی‌کند. برای مشاهدهٔ این محاسبات در یک نسخهٔ خاص به‌جای استفاده از یک قاعدهٔ کلی، اجرای Nemotron 3.5 Lightning روی یک VPS تگ دقیق برای pull کردن، میزان RAM اشغال‌شده پس از بارگذاری و اینکه آیا سرعت اجرای صرفاً روی CPU برای نیاز شما کافی است یا خیر را مشخص می‌کند.

برنامه vLLM فرض را بر وجود GPU می‌گذارد. مسیر پیش‌فرض آن، وزن‌های غیرکوانتیزه را با دقت 16-bit ارائه می‌دهد که تقریباً معادل 2 گیگابایت به ازای هر یک میلیارد پارامتر است: یک مدل 8B پیش از در نظر گرفتن KV cache که دلیل اصلی نصب vLLM برای دستیابی به concurrency است، به حدود 16 گیگابایت حافظه ویدیویی فقط برای وزن‌ها نیاز دارد. روی یک کارت 24 گیگابایتی، این مقدار فضای کافی برای cache باقی می‌گذارد. روی یک کارت 16 گیگابایتی این‌طور نیست؛ بنابراین یا باید مدل کوچک‌تری انتخاب کنید، یا از --quantization (با یک checkpoint کوانتیزه یا برای کوانتیزه کردن وزن‌های full-precision در زمان بارگذاری) استفاده کنید، یا بخشی از وزن‌ها را با --cpu-offload-gb به RAM سیستم منتقل کنید. این کار دقت را حفظ می‌کند اما سرعت را کاهش می‌دهد، زیرا آن وزن‌ها در هر forward pass باید به GPU منتقل شوند. یک backend برای CPU نیز وجود دارد که پکیج‌های (wheels) جداگانه خود را دارد، اما استفاده از آن عملاً دلیل اصلی اجرای vLLM را از بین می‌برد.

بنابراین، پرسش دربارهٔ سخت‌افزار در بیشتر مواقع پاسخ پرسش دربارهٔ نرم‌افزار را مشخص می‌کند. نبود GPU یعنی Ollama. یک GPU اجاره‌ای که به دلیل سریال‌سازی درخواست‌ها، تنها 5 درصد از ظرفیتش استفاده می‌شود، یعنی vLLM.

کدام گزینه برای حجم کاری شما مناسب است

• یک نفر، یک VPS با یک CPU، برای پیش‌نویس و خلاصه‌سازی: Ollama. سرعت آن قابل‌قبول است و هیچ گزینهٔ ساده‌تری وجود ندارد.
• یک دستیار برنامه‌نویسی، یا یک سرور MCP که ابزارهای شما را به یک مدل محلی متصل می‌کند، که فقط خودتان از آن استفاده می‌کنید: Ollama. هم‌زمانی یک کاربر، حجم کاری واقعی شماست.
• مقایسهٔ پنج مدل در این هفته: Ollama. دریافت و حذف مدل‌های دارای تگ دقیقاً همان کاری است که این ابزار در آن مهارت دارد، در حالی که vLLM برای هر مدل نیاز به راه‌اندازی مجدد پردازش دارد.
• یک برنامهٔ داخلی، یک محصول چت، یا یک خط‌لوله بازیابی (retrieval pipeline) با کاربران واقعی: vLLM. اینجاست که دسته‌بندی (batching) هزینه‌های GPU را توجیه می‌کند.
• یک پردازش دسته‌ای (batch job) برای امتیازدهی به صد هزار سند در طول شب: vLLM، با یک --max-num-seqs بالا. در اینجا نرخ توان عملیاتی (throughput) تنها معیار مهم است و تأخیر برای هر سند اهمیتی ندارد.
• یک پلتفرم عامل (agent platform) که در آن چندین عامل هوش مصنوعی خود-میزبان به‌طور هم‌زمان به مدل درخواست می‌فرستند: vLLM، زیرا ترافیک عامل‌ها ماهیتی انفجاری و موازی دارد.

حالت‌های شکست و پیام‌های خطای متناظر

سرویس vLLM به دلیل خطای KV cache اجرا نمی‌شود. پیام خطا هر دو عدد را ذکر می‌کند:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

مدل، پنجرهٔ متنی (context window) بزرگ‌تری نسبت به حافظهٔ باقی‌مانده پس از بارگذاری وزن‌ها اعلام می‌کند. با استفاده از --max-model-len 8192 آن را کاهش دهید، یا اگر برنامهٔ دیگری از کارت گرافیک استفاده نمی‌کند، مقدار --gpu-memory-utilization را افزایش دهید.

سرویس Ollama در حین تولید متن، خطای Killed را چاپ می‌کند. مکانیزم OOM Killer در لینوکس، پردازش را متوقف کرده است زیرا مدل به RAM بیشتری نسبت به ظرفیت موجود در سیستم نیاز داشته است. این موضوع را با sudo dmesg | grep -i oom تأیید کنید. راه‌حل این مشکل، استفاده از یک مدل کوچک‌تر یا مدل با کوانتیزاسیون سنگین‌تر است، نه تغییر تنظیمات.

سرویس Ollama در حالت تک‌کاربره به‌خوبی پاسخ می‌دهد اما زیر بار ترافیک متوقف می‌شود. هیچ خطایی در لاگ‌ها دیده نمی‌شود. هرچه تعداد درخواست‌کنندگان بیشتر می‌شود، زمان پاسخ‌دهی افزایش می‌یابد، زیرا OLLAMA_NUM_PARALLEL=1 درخواست‌ها را به‌صورت سری پردازش می‌کند. پاسخ‌های طولانی وضعیت صف را بدتر می‌کنند، زیرا یک کاربر تا زمانی که مدل به پایان تولید نرسد، تنها اسلات موجود را اشغال می‌کند و سایر درخواست‌ها را مسدود می‌نماید. بنابراین محدود کردن پاسخ با num_predict سقفی برای مدت‌زمانی که یک نوبت می‌تواند سرور را اشغال کند، تعیین می‌کند. مقدار موازی‌سازی را افزایش دهید و هزینهٔ RAM اضافی برای context هر اسلات را بپذیرید، یا بار کاری را به vLLM منتقل کنید.

سرویس vLLM برای تمام فراخوانی‌های /v1 خطای 401 برمی‌گرداند. شما سرویس را با --api-key اجرا کرده‌اید و کلاینت هدر Authorization را ارسال نمی‌کند. اکثر کتابخانه‌های کلاینت OpenAI هر مقداری را که به‌عنوان کلید به آن‌ها بدهید ارسال می‌کنند، بنابراین به‌جای حذف فلگ، کلید را در کلاینت تنظیم کنید.

سرویس vLLM اعلام می‌کند که مدل یافت نشد. سرویس Ollama مدل‌ها را در صورت نیاز دانلود می‌کند، اما vLLM این کار را انجام نمی‌دهد. فیلد model در بدنهٔ درخواست باید با شناسهٔ مخزنی که با آن سرویس را اجرا کرده‌اید، یا مقدار --served-model-name (در صورت تنظیم) مطابقت داشته باشد. رشتهٔ دقیق را با curl http://localhost:8000/v1/models بررسی کنید.

اجرای همزمان هر دو، پاسخی منطقی است

این دو با یکدیگر منافاتی ندارند. یک ساختار رایج، استفاده از vLLM روی یک instance دارای GPU برای سرویس‌دهی به برنامه، و استفاده از Ollama روی یک VPS معمولی در کنار آن برای اسکریپت‌های محلی، cron jobها و تست نسخه‌های جدید مدل‌ها است. هر دو endpoint با OpenAI سازگار هستند، بنابراین با یک کتابخانه کلاینت و تغییر base-URL می‌توان هر دو را مدیریت کرد. در اینجا کنترل هزینه اهمیت بیشتری نسبت به انتخاب موتور دارد، زیرا هزینه یک GPU بلااستفاده با یک GPU در حال کار برابر است و قابل پیش‌بینی نگه داشتن هزینه‌های عامل و استنتاج، تخصصی جدا از انتخاب سرور است.

FAQ

آیا vLLM سریع‌تر از Ollama است؟

برای یک درخواست واحد روی همان GPU، تفاوت ناچیز است، زیرا هر دو محاسبات یکسانی انجام می‌دهند. برای تعداد زیادی درخواست همزمان، vLLM بسیار جلوتر است، زیرا continuous batching هر دنباله فعال را در یک forward pass رمزگشایی می‌کند، در حالی که حالت پیش‌فرض Ollama آن‌ها را یکی پس از دیگری اجرا می‌کند. در دستگاه‌های فقط CPU، هر دو مسیرهای استنتاج (inference) پشتیبانی‌شده دارند و vLLM از wheelهای جداگانه برای CPU استفاده می‌کند.

آیا vLLM می‌تواند بدون GPU اجرا شود؟

بله، از طریق backend مخصوص CPU. نسخه استاندارد wheelها برای GPUهای NVIDIA یا AMD طراحی شده‌اند و دلیلی که vLLM برای آن وجود دارد—یعنی اشباع نگه داشتن شتاب‌دهنده با درخواست‌های دسته‌ای (batched)—در CPU از بین می‌رود. یک backend برای CPU وجود دارد که دارای wheelهای جداگانه برای x86 و Arm است. برای استنتاج واقعی روی CPU، مستقیماً از Ollama یا llama.cpp استفاده کنید.

تفاوت بین Ollama و llama.cpp چیست؟

llama.cpp کتابخانه استنتاج است و GGUF فرمت وزن‌های کوانتایز شده آن است. Ollama از آن برای استنتاج GGUF استفاده می‌کند و یک رجیستری مدل، دانلودهای برچسب‌دار، مدیریت مدل و یک unit برای systemd به آن می‌افزاید. Ollama همچنین یک موتور MLX دارد که مدل‌های مبتنی بر safetensors را روی Apple Silicon اجرا می‌کند و از buildهای CUDA در Linux پشتیبانی می‌کند، بنابراین این دو در لایه‌های زیرین همیشه یکسان نیستند.

vLLM برای یک مدل 8B به چه مقدار حافظه GPU نیاز دارد؟

در دقت 16-bit، وزن‌ها به تنهایی حدود 16 GB هستند (تقریباً 2 GB به ازای هر میلیارد پارامتر) و KV cache نیز به فضایی فراتر از آن نیاز دارد. یک کارت 24 GB برای این کار مناسب است. یک کارت 16 GB به یک مدل کوانتایز شده، یک مدل کوچک‌تر یا --cpu-offload-gb نیاز دارد تا بخشی از وزن‌ها را با هزینه کاهش سرعت به RAM سیستم منتقل کند. vLLM بخشی از حافظه کارت را که توسط --gpu-memory-utilization تعیین می‌شود اشغال می‌کند که از اکتبر 2026 به صورت پیش‌فرض روی 0.92 تنظیم شده است.

آیا برای جابه‌جایی بین آن‌ها باید کد برنامه خود را تغییر دهم؟

معمولاً فقط base URL، کلید API و نام مدل نیاز به تغییر دارند. Ollama رابط سازگار با OpenAI خود را در http://127.0.0.1:11434/v1 ارائه می‌دهد و کلید را نادیده می‌گیرد، در حالی که vLLM آن را در http://localhost:8000/v1 ارائه می‌دهد و اگر کلیدی تنظیم کرده باشید، آن را در مسیرهای /v1 اعمال می‌کند. نام مدل‌ها از نظر فرمت متفاوت هستند: llama3.1:8b برای Ollama، و یک شناسه مخزن کامل مانند Qwen/Qwen2.5-1.5B-Instruct برای vLLM.