Ollama یا LM Studio؛ سرعت تولید و پاسخ نخست یک برنده ندارند

در اجرای محلی مدل، Ollama و LM Studio برندهٔ واحدی در سرعت ندارند: یکی می‌تواند پاسخ را زودتر آغاز کند و دیگری ادامهٔ آن را سریع‌تر بسازد. در آزمون asiai روی Qwen3-Coder-30B و Mac Mini M4 Pro، LM Studio با بک‌اند MLX به ۱۰۲٫۲ توکن در ثانیه رسید، در برابر ۶۹٫۸ برای Ollama با llama.cpp؛ اما زمان تا نخستین توکن برای Ollama ۱۷۵ میلی‌ثانیه و برای LM Studio ۲۹۱ میلی‌ثانیه بود.

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

چرا پاسخ نخست و سرعت تولید دو انتخاب متفاوت می‌سازند؟

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

در پیکربندی آزموده‌شده، برتری LM Studio در آهنگ تولید به معنای پایان سریع‌تر هر پاسخ نیست؛ طول متن خروجی نیز در زمان تکمیل نقش دارد. به همین ترتیب، جلو افتادن Ollama در پاسخ نخست تضمین نمی‌کند که خروجی بلند زودتر تمام شود. اگر پاسخ بسیار کوتاه باشد، بخش آغازین سهم بزرگی از انتظار است؛ با افزایش طول خروجی، سهم تولید ادامهٔ متن بیشتر می‌شود. این یک رابطهٔ زمانی است، نه ویژگی ثابت نام تجاری هر ابزار.

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

فاصلهٔ مصرف حافظه از کجا می‌آید؟

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

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

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

رابط گرافیکی چه چیزی را آسان می‌کند؟

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

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

برای API محلی کدام تفاوت مهم است؟

هر دو محصول می‌توانند مدل محلی را از راه API در اختیار برنامه یا اسکریپت بگذارند. معرفی API در Ollama نشانی سرویس محلی، مسیر API خود محصول و مسیر سازگار با OpenAI را مشخص می‌کند. LM Studio نیز از طریق برنامهٔ دسکتاپ یا سرویس بدون رابط گرافیکی، endpointهای محلی و سازگار ارائه می‌دهد. صرف وجود API، امتیاز انحصاری هیچ‌کدام نیست.

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

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

جابه‌جایی میان مدل‌ها چگونه نتیجه را عوض می‌کند؟

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

LM Studio نیز برای مدل بارگذاری‌شده زمان تخلیهٔ خودکار دارد؛ بنابراین در هر دو محیط، مدت نگهداری مدل بر تعادل میان حافظهٔ آزاد و تأخیر درخواست بعدی اثر می‌گذارد. نگه داشتن مدلی که پیوسته استفاده می‌شود، بارگذاری دوباره را حذف می‌کند، اما برای مدل‌های دیگر فضای کمتری می‌گذارد. تخلیهٔ سریع، حافظه را آزاد می‌کند و در عوض نخستین درخواست بعدی را سنگین‌تر می‌سازد. برای کار چندمدلی، این مبادله می‌تواند از اختلاف سرعت تولید یک پاسخ منفرد مهم‌تر باشد.

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

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

• رونویسی زندهٔ Microsoft رکورد زد؛ اما هنوز برای تولید آماده نیست
• Zapier یا Make؛ گردش‌کار هشت‌مرحله‌ای می‌تواند برنده را عوض کند
• Docker یا Podman؛ سرعت تقریباً برابر است، مدل دسترسی تصمیم را عوض می‌کند