مقایسه 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 و یک API مبتنی بر HTTP در اختیار شما قرار می‌دهد. مدل‌هایی که این ابزار ارائه می‌دهد، فایل‌های GGUF هستند که معمولاً با دقت 4-bit کوانتیزه شده‌اند؛ به همین دلیل است که یک مدل 7B یا 8B به جای 16 GB، حدود 5 GB فضا روی دیسک اشغال می‌کند. کوانتیزاسیون همان عاملی است که اجرای استنتاج (inference) روی CPU را ممکن می‌سازد.

موتور اجرای آن بر پایه llama.cpp ساخته شده است؛ همان کتابخانه استنتاج C++ که کوانتیزاسیون GGUF را روی سخت‌افزارهای معمولی کاربردی کرد. Ollama از آن زمان برای برخی خانواده‌های مدل جدیدتر، موتور اختصاصی خود را اضافه کرده است، اما llama.cpp همچنان زیربنای اکثر مدل‌هایی است که ارائه می‌دهد. بنابراین وقتی افراد Ollama را با llama.cpp مقایسه می‌کنند، در واقع در حال مقایسه یک لایهٔ ارگونومیک با ابزاری هستند که آن لایه در بر گرفته است.

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

vLLM دقیقاً چیست

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

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

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

تفاوت اصلی در Continuous batching نهفته است

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

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

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

شما می‌توانید OLLAMA_NUM_PARALLEL=4 را تنظیم کنید و بخشی از این قابلیت را به دست آورید. هزینه این کار، حافظه است. هر اسلات موازی به KV cache اختصاصی خود نیاز دارد و Ollama پنجره کانتکست را بین اسلات‌ها تقسیم می‌کند؛ بنابراین چهار درخواست موازی برای مدلی که روی 8192 توکن تنظیم شده، برای هر درخواست 2048 توکن کانتکست باقی می‌گذارد. عدد 8192 خود یک انتخاب است، نه یک مقدار ثابت؛ بنابراین افزایش num_ctx و تعیین اندازه RAM مورد نیاز گامی است که مشخص می‌کند آیا چهار اسلات اصلاً قابل استفاده هستند یا خیر. حافظه کش صفحه‌بندی‌شده (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

نرم‌افزار vLLM به سیستم‌عامل Linux و نسخه 3.10 تا 3.13 از Python نیاز دارد. آن را در یک محیط مجازی (virtual environment) اختصاصی نصب کنید، زیرا این برنامه یک نسخه خاص از PyTorch را فراخوانی می‌کند:

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

سپس یک مدل را ارائه دهید. نام مدل باید شناسه مخزن در 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 الزامی است و جنبه تزئینی ندارد؛ PyTorch تانسورها را بین پردازش‌ها از طریق حافظه مشترک (shared memory) منتقل می‌کند و مقدار پیش‌فرض حافظه مشترک در Docker برای استنتاج (inference) موازی تانسورها بسیار کم است.

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

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

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

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

همین مقدار می‌تواند از طریق متغیر محیطی VLLM_API_KEY نیز تعیین شود. درخواستی که فاقد این توکن باشد، خطای HTTP 401 دریافت می‌کند. با این حال، این موضوع دلیلی برای انتشار پورت 8000 روی یک رابط عمومی نیست، زیرا vLLM فاقد قابلیت rate limiting است و یک توکن ساده HTTP در حین انتقال قابل خواندن است؛ اما این ویژگی به این معناست که سرور مفهوم «تماس‌گیرنده» را می‌شناسد.

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

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

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

برنامه vLLM فرض را بر وجود GPU می‌گذارد. مسیر پیش‌فرض آن، وزن‌های غیرکوانتایز شده را با دقت 16-بیتی ارائه می‌دهد که تقریباً معادل 2 گیگابایت به ازای هر میلیارد پارامتر است: یک مدل 8B پیش از در نظر گرفتن KV cache که concurrency مورد نیاز شما را فراهم می‌کند، به حدود 16 گیگابایت حافظه ویدیویی فقط برای وزن‌ها نیاز دارد. روی یک کارت 24 گیگابایتی، این مقدار فضای کافی برای cache باقی می‌گذارد. روی یک کارت 16 گیگابایتی چنین نیست، بنابراین یا باید مدل کوچک‌تری انتخاب کنید یا --quantization را با یک checkpoint کوانتایز شده ارسال کنید. یک backend برای CPU وجود دارد، اما پکیج‌های استاندارد برای آن ساخته نشده‌اند و استفاده از آن، دلیل اصلی استفاده از 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: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

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

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

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

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

vLLM می‌گوید مدل پیدا نشد. Ollama مدل‌ها را در لحظه دانلود (pull) می‌کند، اما 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، این پرسش موضوعیت ندارد: Ollama در آنجا اجرا می‌شود اما vLLM عملاً خیر.

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

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

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

llama.cpp کتابخانه استنتاج است و GGUF فرمت وزن‌های کوانتایز شده آن است. runner برنامه Ollama بر پایه آن ساخته شده و بخش‌هایی را که llama.cpp به عهده خودتان می‌گذارد، اضافه می‌کند: رجیستری مدل، دانلود خودکار، سرور مقیم (resident server)، یک unit برای systemd و یک endpoint سازگار با OpenAI. برنامه Ollama برای برخی خانواده‌های مدل جدیدتر، موتور اختصاصی خود را اضافه کرده است، بنابراین این دو در لایه‌های زیرین دیگر کاملاً یکسان نیستند.

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

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

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

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