«vLLM برای سرورها و Ollama برای شخصی»؛ معیار انتخاب موتور LLM

اگر قصد دارید یک مدل زبانی را روی سخت‌افزار خودتان اجرا کنید، باید بدانید که انتخاب موتور استنتاج، تصمیمی دربارهٔ مدیریت ترافیک و هم‌زمانی (Concurrency) است، نه فقط سرعت خام. در ۱ اکتبر ۲۰۲۶، یک تحلیل فنی فاش کرد که حتی اگر اولاما (Ollama)، لاماسی‌پلاس‌پلاس (llama.cpp) و vLLM یک مدل واحد را اجرا کنند، معماری آن‌ها در مواجهه با درخواست‌های هم‌زمان، نتایج عملکردی کاملاً متفاوتی خلق می‌کند. پرسش بنیادین این است: در هر لحظه چند نفر یا چند عامل (Agent) قرار است به مدل درخواست بفرستند؟

استنتاج محلی — یعنی لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی است نه دوره‌ی آموزش آشپز — از یک سرگرمی برای توسعه‌دهندگان به یک ضرورت تولیدی تبدیل شده است. همان‌طور که در تحلیل قبلی ما درباره‌ی laya-evals اشاره کردیم، مدل‌های محلی می‌توانند هزینه‌های ارزیابی را به صفر برسانند؛ حالا چالش اصلی، نحوهٔ سرویس‌دهی بهینه به این مدل‌هاست. انتخاب موتور مناسب در این مرحله شبیه انتخاب وسیلهٔ نقلیه است: دوچرخه برای سفر تک‌نفره، ماشین برای گروه کوچک و اتوبوس برای جمعیت. برای درک بهتر تفاوت‌های ابزارهای رایج در این حوزه، می‌توانید مقایسه جامع اولاما، LM Studio و llama.cpp را مطالعه کنید تا متوجه شوید کدام استک با نیازهای شما سازگارتر است.

کالبدشکافی موتورها

llama.cpp به عنوان موتور زیربنایی بسیاری از ابزارهای هوش مصنوعی محلی عمل می‌کند. این ابزار یک پیاده‌سازی خالص به زبان C/C++ است که هیچ وابستگی (Dependency) خارجی ندارد و برای اجرا روی تقریباً هر سخت‌افزاری طراحی شده است. طبق مستندات (README) این پروژه، هدف آن پشتیبانی از طیف وسیعی از سخت‌افزارها، از جمله CPUها و شتاب‌دهنده‌های مختلف مانند CUDA, Metal, HIP, Vulkan و SYCL است. این موتور عمدتاً با فایل‌های GGUF کار می‌کند و از کوانتش (Quantization) — که شبیه فشرده‌سازی یک عکس برای اشغال فضای کمتر بدون از دست دادن زیاد کیفیت است — در بازه ۱.۵ تا ۸ بیت پشتیبانی می‌کند. در نسخه v0.5.0، گردش کار آن ساده‌تر شده و دستور قدیمی llama-server اکنون به llama serve تغییر یافته است. کاربران می‌توانند مستقیماً با دستور llama cli -hf ggml-org/Qwen3-4B-GGUF مدل‌ها را از Hugging Face فراخوانی کنند یا با دستور llama serve -m ./Qwen3-4B-Q4_K_M.gguf --port 8080 یک سرور سازگار با OpenAI روی پورت ۸۰۸۰ راه‌اندازی کنند. در همین راستا، ابزارهای جدیدتری مانند Magnitude توانسته‌اند سرعت استنتاج مدل‌های باز را تا دو برابر llama.cpp افزایش دهند.

Ollama در واقع یک مدیریت‌کنندهٔ مدل است که فرآیند استنتاج را در بسته‌بندی راحتی ارائه می‌دهد. این ابزار با ارائه یک سرویس پس‌زمینه و رابط خط فرمان ساده (ollama run)، مدیریت کتابخانه‌های مدل و API را از طریق دستور ollama pull تسهیل می‌کند. اولاما هم API بومی خود و هم یک API سازگار با OpenAI را روی پورت ۱۱۴۳۴ ارائه می‌دهد. این ابزار کنترل دقیق و جزئی را فدای تجربه‌ی راه‌اندازی تقریباً آنی کرده است و به همین دلیل نقطهٔ ورود اصلی اکثر توسعه‌دهندگان است. اگرچه این ابزار از استک ggml/llama.cpp برای اجرای مدل‌های GGUF استفاده می‌کند، اما قابلیت‌های خاص خود را نیز اضافه کرده است، از جمله پشتیبانی از MLX برای تراشه‌های اپل سیلیکون.

vLLM یک موتور سرویس‌دهی با توان عملیاتی (Throughput) بالا است که به‌طور اختصاصی برای سرورهای GPU ساخته شده است. این موتور از تکنیک PagedAttention برای مدیریت حافظه KV Cache — که شبیه یادداشت‌برداری مدل از کلمات قبلی برای سریع‌تر جواب دادن است — و همچنین از دسته‌بندی پیوسته (Continuous Batching)، پیش‌پر کردن تکه‌ای (Chunked Prefill) و کش پیشوند (Prefix Caching) استفاده می‌کند تا ده‌ها درخواست هم‌زمان را مدیریت کند. vLLM می‌تواند مدل‌ها را با استفاده از موازی‌سازی تنسور (Tensor)، خط لوله (Pipeline) و متخصص (Expert) بین چندین GPU تقسیم کند. برخلاف دو مورد قبلی، هدف vLLM به حداکثر رساندن بهره‌وری GPU برای APIهای داخلی است که چندین عامل یا کاربر را پشتیبانی می‌کنند. این موتور را می‌توان از طریق uv pip install vllm نصب کرد و با دستور vllm serve Qwen/Qwen3-4B به خدمت گرفت.

تحلیل شکاف عملکردی

برای سنجش این تفاوت‌ها، بنچمارکی روی یک دستگاه Apple M1 با ۱۶ گیگابایت رم و مدل Qwen3-4B (نسخه Q4_K_M GGUF با حجم ۲.۵ گیگابایت) اجرا شد. در این تست از Ollama 0.34.4 و llama.cpp 0.5.0 استفاده شد و هر موتور برای یک پرامپت یکسان، ۲۵۶ توکن تولید کرد. نتایج نشان داد که تنظیمات پیش‌فرض اغلب مهم‌تر از خودِ موتور هستند:

• تک کاربر: در حالت پیش‌فرض، Ollama با ۱۸.۷ توکن در ثانیه از llama.cpp (۱۳.۷ توکن در ثانیه) سریع‌تر بود. دلیل این اتفاق این بود که اولاما پنجره متنی (Context) را بر اساس VRAM موجود روی ۴,۰۹۶ توکن تنظیم کرد، در حالی که llama serve به‌طور خودکار ۴ اسلات با پنجره متنی بسیار بزرگتر (۴۰,۹۶۰ توکن برای هر کدام) پیکربندی کرده بود.
• بار هم‌زمان (۴ درخواست): در حالت پیش‌فرض، اولاما درخواست‌ها را در صف قرار داد، به این معنی که کاربر آخر تقریباً یک دقیقه (۵۴ ثانیه زمان واقعی یا Wall Time) منتظر ماند. توان عملیاتی مجموع در ۱۸.۹ توکن در ثانیه باقی ماند. اما llama.cpp با استفاده از اسلات‌های موازی، هر چهار درخواست را در ۳۵ ثانیه به پایان رساند، هرچند سرعت هر درخواست به ۸ توکن در ثانیه کاهش یافت (توان عملیاتی مجموع ۲۸.۹ توکن در ثانیه).
• بار بهینه‌شده: وقتی اولاما با تنظیم OLLAMA_NUM_PARALLEL=4 پیکربندی شد، سریع‌ترین گزینه بود و چهار درخواست هم‌زمان را در ۲۹ ثانیه با توان عملیاتی مجموع ۳۵.۰ توکن در ثانیه پردازش کرد.

باید توجه داشت که این اعداد مربوط به مدل‌های کوچک روی یک لپ‌تاپ است و نشان‌دهنده شکل تفاوت‌هاست، نه یک رتبه‌بندی جهانی. در یکی از اجراهای اولیه، llama.cpp جلوتر بود، اما در آن زمان میانگین بار (Load Average) مک حدود ۹ بود؛ اعداد تنها زمانی تثبیت شدند که دستگاه در حالت Idle (بیکار) بود.

محدودیت‌های سخت‌افزاری و حافظه

سازگاری سخت‌افزاری در این ابزارها تفاوت زیادی دارد. اولاما و llama.cpp به دلیل بهره‌گیری از Metal برای شتاب‌دهی GPU، انتخاب‌های طبیعی برای کاربران macOS هستند. آن‌ها همچنین از ویندوز، لینوکس و سخت‌افزارهای NVIDIA و AMD پشتیبانی می‌کنند.

در مقابل، پشتیبانی vLLM از تراشه‌های اپل سیلیکون هنوز آزمایشی است و برای اجرا روی CPU نیاز به کامپایل از سورس (Build from source) دارد. vLLM اساساً برای GPUهای انویدیا، AMD و اینتل و همچنین TPUها بهینه شده است.

مدیریت حافظه نیز یک نقطهٔ تمایز کلیدی است:

• تصاحب حافظه توسط vLLM: این موتور به‌طور پیش‌فرض ۹۲٪ از حافظه GPU را از طریق پرچم --gpu-memory-utilization تصاحب می‌کند. این حافظه آزاد به KV Cache تبدیل می‌شود که هم‌زمانی بالا را ممکن می‌سازد.
• شکست در تخصیص: به دلیل همین پیش‌فرض ۰.۹۲، اجرای دومین نمونه از vLLM یا هر فرآیند دیگری روی آن GPU با خطای تخصیص حافظه مواجه خواهد شد.
• تقسیم دستی: برای اجرای دو نمونه روی یک GPU، باید میزان بهره‌برداری را دستی تقسیم کنید. برای مثال: vllm serve Qwen/Qwen3-4B --gpu-memory-utilization 0.45 --port 8000 و vllm serve Qwen/Qwen3-1.7B --gpu-memory-utilization 0.45 --port 8001.

مرز سازگاری با GGUF

فرمت مدل‌ها مرز سخت‌گیرانه‌ای برای انتخاب ایجاد می‌کند. llama.cpp و اولاما برای فایل‌های GGUF ساخته شده‌اند. llama.cpp موتور زیربنایی بخش بزرگی از دنیای LLMهای محلی است و GGUF زبان مادری آن محسوب می‌شود.

در حالی که vLLM پشتیبانی از GGUF را اضافه کرده است، اما توسعه‌دهندگان آن را «بسیار آزمایشی و بهینه‌نشده» می‌نامند و برای استفاده از آن نیاز به بسته جداگانه vllm-gguf-plugin است. بنابراین اگر مدل‌های شما در قالب GGUF هستند، vLLM عموماً انتخاب طبیعی و مناسبی نیست.

خلاصه کاربردهای عملی

• توسعه‌دهندگان تک‌نفره: از Ollama برای سریع‌ترین مسیر نصب و اجرا روی لپ‌تاپ استفاده کنید. دستور ollama run سریع‌ترین شروع است و راهنمای سخت‌افزاری آن‌ها کمک می‌کند بفهمید چه مدلی با سیستم شما سازگار است.
• کاربران حرفه‌ای: از llama.cpp برای کنترل حداکثری روی کوانتش، اندازه پنجره متنی، تعداد اسلات‌ها و بک‌اندهای سخت‌افزاری غیرمعمول استفاده کنید.
• تیم‌های تولیدی: از vLLM برای نقاط انتهایی مشترک روی GPUهای انویدیا یا AMD استفاده کنید، جایی که درخواست‌ها به‌طور مکرر هم‌پوشانی دارند. قابلیت دسته‌بندی پیوسته (Continuous Batching) به محض اینکه درخواست‌ها هم‌پوشانی کنند، اثر خود را نشان می‌دهد.

برای تیم‌های کوچکی که یک سرور اولاما را به اشتراک می‌گذارند، کلید موفقیت افزایش تنظیم OLLAMA_NUM_PARALLEL است (مقدار پیش‌فرض ۱ است). در غیر این صورت، به محض اینکه OLLAMA_MAX_QUEUE پر شود، سیستم خطاهای ۵۰۳ برمی‌گرداند. به یاد داشته باشید که مصرف حافظه با ضربِ OLLAMA_NUM_PARALLEL در OLLAMA_CONTEXT_LENGTH افزایش می‌یابد، بنابراین هنگام افزایش این مقدار، مراقب رم و VRAM خود باشید.

این تقسیم‌بندی معماری به این معناست که مسیر توسعه AI اکنون به یک خط لوله تبدیل شده است: نمونه‌سازی با Ollama، بهینه‌سازی با llama.cpp و مقیاس‌پذیری با vLLM. از آنجایی که هر سه API سازگار با OpenAI ارائه می‌دهند (vLLM همچنین از Anthropic Messages API و gRPC پشتیبانی می‌کند)، جابه‌جایی بین آن‌ها معمولاً فقط نیاز به تغییر یک URL پایه و نام مدل دارد.

این چرخش در استراتژی استنتاج نشان می‌دهد که گلوگاه هوش مصنوعی محلی دیگر فقط اندازه مدل نیست، بلکه نحوه مدیریت حافظه در گفتگوهای هم‌زمان است. با افزایش گردش‌های کاری عامل‌محور (Agentic) که تعداد فراخوانی‌های هم‌زمان به یک مدل را زیاد می‌کنند، صنعت احتمالاً از پردازش متوالی ساده به سمت دسته‌بندی پیوسته در vLLM حرکت خواهد کرد.

گام بعدی شما

• اگر در سرور محلی خود با تأخیر مواجه هستید، پیش از ارتقای سخت‌افزار، تنظیمات موازی (Parallel) را بررسی کنید.
• توان عملیاتی فعلی خود را با شبیه‌سازی چهار درخواست هم‌زمان و اندازه‌گیری زمان کل (Wall Time) تست کنید.
• برای مدل‌های GGUF در محیط تولیدی، ابتدا اولاما را با تنظیمات بهینه‌شده تست کنید و در صورت نیاز به vLLM مهاجرت کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.