Ollama یا llama.cpp؛ سرعت نزدیک است، تنظیمات پیش‌فرض نه

برای اجرای محلی یک مدل زبانی، نتایج منتشرشده برندهٔ ثابت و قاطعی در سرعت تولید میان Ollama و llama.cpp نشان نمی‌دهند. اگر راه‌اندازی سریع، مدیریت مدل و یک API آماده می‌خواهید، Ollama انتخاب راحت‌تری است. اگر باید رفتار سرور و تخصیص منابع را با دقت تعیین کنید، اجرای مستقیم llama.cpp کنترل بیشتری می‌دهد.

تفاوت عملی اغلب از تنظیمات پیش‌فرض آغاز می‌شود. طول context، تعداد جایگاه‌های درخواست و شیوهٔ بارگذاری مدل می‌توانند مصرف حافظه و زمان شروع را تغییر دهند، حتی وقتی سرعت تولید متن نزدیک است. به همین دلیل، عدد توکن‌برثانیه فقط در کنار شرایط آزمون و نوع بار کاری معنا دارد.

نتیجهٔ آزمون GPU: اختلاف کوچک در تولید متن

در آزمون GPU مؤسسهٔ AIMEC، فایل یکسان Qwen2.5-Coder-7B-Instruct با کوانتیزه‌سازی Q5_K_M روی NVIDIA GeForce RTX 2050 و context برابر با ۸۱۹۲ توکن اجرا شد؛ میانهٔ سرعت تولید Ollama برابر ۱۰٫۷۳ و llama.cpp برابر ۱۱٫۲۰ توکن‌برثانیه بود. برتری حدود ۴٫۴ درصدی اجرای مستقیم به همین مدل، سخت‌افزار، نسخه‌ها و پیکربندی محدود است. در همان آزمون، اوج ثبت‌شدهٔ RAM برای Ollama بیشتر بود، اما اوج آن هنگام اجرای سرد رخ داد و با مصرف پایدار دو سرور یکی نیست.

وقتی آزمایشگران context اجرای مستقیم llama.cpp را کوتاه‌تر کردند، سرعت تولید تغییر اندکی داشت، ولی زمان آماده‌شدن سرور کاهش یافت. برای برنامه‌ای که مدل را میان درخواست‌ها در حافظه نگه می‌دارد، این زمان شروع معمولاً سهم کمتری از تجربهٔ کاربر دارد؛ برای برنامه‌ای که مدل‌ها را مرتب عوض می‌کند، می‌تواند محسوس باشد. سرعت تولید، زمان بارگذاری و زمان رسیدن نخستین توکن را باید سه اندازه‌گیری جدا دانست.

جدول GPU برای پردازش پرامپت و نخستین توکن نیز فاصلهٔ بزرگی نشان می‌دهد. با این حال، پرامپت در اجراهای گرم تکرار شده بود و استفاده از cache می‌توانست میان دو مسیر متفاوت باشد. بنابراین آن ستون‌ها مبنای محکمی برای حکم کلی دربارهٔ سرعت پاسخ‌گویی نیستند؛ نتیجهٔ روشن‌تر آزمون، نزدیکی سرعت تولید در پیکربندی هم‌شرایط آن است.

نتیجهٔ آزمون CPU: پیش‌فرض‌ها بر حافظه اثر گذاشتند

در آزمون CPU در AI Tool Labs، با فایل‌های GGUF یکسان، کوانتیزه‌سازی Q4_K_M و پرچم‌های یکسان با دو thread، سرعت Ollama و اجرای مستقیم به‌ترتیب برای Qwen 2.5 1.5B برابر ۱۴٫۶۲ و ۱۴٫۶۹ و برای Llama 3.2 3B برابر ۶٫۸۱ و ۷٫۰۶ توکن‌برثانیه بود. آزمون روی یک لپ‌تاپ دو‌هسته‌ای و برای درخواست تک‌کاربره انجام شد. تفاوت نسخهٔ موتور تعبیه‌شده در Ollama با نسخهٔ مستقل نیز از محدودیت‌های همین مقایسه است.

در همان دستگاه، Ollama سرور استنتاج را با context کوتاه‌تر و یک جایگاه درخواست راه‌اندازی می‌کرد. اجرای مستقیم llama-server با پیش‌فرض‌های نسخهٔ آزموده‌شده برای context بلندتر و چند جایگاه آماده می‌شد؛ در نتیجه، مدل بزرگ‌تر زیر سقف حافظهٔ آزمایش در حالت پیش‌فرض آن بارگذاری نشد، در حالی که با پیکربندی Ollama اجرا شد. این نتیجه به معنی ناتوانی llama.cpp در اجرای مدل نیست: با تعیین context و شمار جایگاه‌ها، می‌توان حافظهٔ رزروشده را متناسب با دستگاه تنظیم کرد.

حتی برابرکردن این دو گزینه به‌تنهایی همهٔ اختلاف حافظهٔ گزارش‌شده را حذف نکرد. اجرای مستقیم، فایل مدل را در حافظه نگاشت می‌کرد و صفحه‌های وابسته به فایل در اندازه‌گیری حافظهٔ فرایند دیده می‌شدند؛ سیستم‌عامل می‌تواند بخشی از آن‌ها را زیر فشار حافظه آزاد کند. وقتی شیوهٔ بارگذاری نیز مانند Ollama تنظیم شد، مصرف فرایندهای استنتاج در آزمون بسیار نزدیک شد. پس یک عدد RAM بدون دانستن روش بارگذاری و شاخص اندازه‌گیری، مقایسهٔ کاملی نیست.

کدام شرایط باید برای مقایسه یکسان باشند؟

نام یکسان مدل کافی نیست؛ نقطهٔ شروع، همان فایل GGUF با کوانتیزه‌سازی یکسان است. سپس طول context، تعداد جایگاه‌های موازی، threadها، میزان واگذاری لایه‌ها به GPU، طول پرامپت و سقف خروجی باید روشن باشند. قالب گفت‌وگو و امکان استفادهٔ دوباره از cache نیز به‌ویژه بر زمان پردازش پرامپت اثر می‌گذارند.

دو آزمون بالا را هم نباید در یک جدول رتبه‌بندی ادغام کرد. آزمون GPU از مدل بزرگ‌تر و شتاب‌دهندهٔ گرافیکی استفاده کرده است؛ آزمون CPU مدل‌های کوچک‌تر را روی پردازنده اجرا کرده و تنظیمات حافظه را نیز بررسی می‌کند. هر کدام به پرسشی متفاوت پاسخ می‌دهد: اولی فاصلهٔ سرعت تولید را در یک پیکربندی گرافیکی نشان می‌دهد و دومی توضیح می‌دهد چرا دو اجرای نزدیک از نظر سرعت، روی دستگاه کم‌حافظه رفتار متفاوتی دارند.

API آماده در برابر کنترل مستقیم سرور

مستندات رسمی API در Ollama نشانی رابط محلی اصلی را http://localhost:11434/api و نشانی سازگار با OpenAI را http://localhost:11434/v1 معرفی می‌کند. این رابط، همراه با مدیریت مدل توسط Ollama، برای برنامه‌ای که صرفاً به یک سرویس محلی آماده نیاز دارد کار راه‌اندازی را کوتاه می‌کند. سازگاری با رابط OpenAI به‌تنهایی تضمین نمی‌کند که همهٔ گزینه‌های استنتاج یا رفتار پاسخ‌ها در دو سرور یکسان باشند.

در اجرای مستقیم llama.cpp، تنظیماتی مانند طول context، تعداد threadها و واگذاری لایه‌ها به GPU در اختیار اداره‌کنندهٔ سرور است. این انعطاف برای دستگاهی با حافظهٔ محدود یا باری با نیاز مشخص ارزش دارد، چون می‌توان ظرفیت موردنیاز را آگاهانه تعیین کرد. در عوض، انتخاب تنظیمات و نگهداری فرایند سرور نیز بر عهدهٔ همان اداره‌کننده خواهد بود.

سرعت تک‌کاربره، ظرفیت چندکاربره نیست

مستندات رسمی سرور llama.cpp مسیرهای HTTP سازگار با OpenAI، پردازش موازی، continuous batching و گزینهٔ --parallel برای تعیین شمار جایگاه‌های درخواست را شرح می‌دهد. وجود این قابلیت‌ها امکان تنظیم سرویس برای چند درخواست هم‌زمان را می‌دهد، اما عدد سرعت تولید یک درخواست، توان عملیاتی یا تأخیر آن سرویس زیر بار چندکاربره را مشخص نمی‌کند.

با هم‌زمان‌شدن درخواست‌ها، حافظه و توان پردازش میان آن‌ها تقسیم می‌شود. ممکن است مجموع خروجی سرور افزایش یابد، در حالی که هر کاربر برای پاسخ خود بیشتر منتظر بماند. برای چت چندکاربره یا سرویس پشت یک برنامه، شمار درخواست‌های هم‌زمان، تأخیر هر درخواست و مصرف حافظه در همان بار باید کنار سرعت تولید سنجیده شوند؛ آزمون‌های تک‌کاربرهٔ بالا این نتیجه را اندازه‌گیری نکرده‌اند.

انتخاب بر اساس نیاز اجرا

• Ollama برای کسی مناسب‌تر است که مدیریت مدل، راه‌اندازی ساده و API محلی آماده می‌خواهد و کنترل‌های آن نیاز برنامه را پوشش می‌دهند.
• llama.cpp برای کسی مناسب‌تر است که می‌خواهد context، thread، مصرف منابع و رفتار سرور را مستقیم تنظیم و نگهداری کند.
• برای بار چندکاربره انتخاب به ظرفیت و تأخیر زیر بار واقعی وابسته است؛ نزدیکی سرعت در یک درخواست، پاسخ این بخش از تصمیم نیست.

اگر محدودیت اصلی دستگاه حافظه است، تنظیمات پیش‌فرض را جزئی از تصمیم بدانید: همان‌ها می‌توانند تعیین کنند مدل بارگذاری شود یا نه. اگر اولویت، رساندن سریع یک مدل محلی به برنامه است، سادگی API و مدیریت مدل وزن بیشتری پیدا می‌کند. اختلاف کوچک سرعت تولید در آزمون‌های منتشرشده، به‌تنهایی دلیل کافی برای صرف‌نظرکردن از این تفاوت‌ها نیست.

بیشتر بخوانید:

• Signal یا Telegram؛ رمزنگاری پیش‌فرض مهم‌تر از فهرست امکانات است
• Bun یا Deno؛ توان عملیاتی نزدیک است، مصرف حافظه نه
• Ollama یا LM Studio؛ سرعت تولید و پاسخ نخست یک برنده ندارند