چرا یک مدل بزرگ برای اجرای محلی LLM کافی نیست؟ راهکار «روتر مدل» برای افزایش سرعت، کاهش مصرف حافظه و بهبود دقت

در دنیای اجرای محلی مدل‌های زبانی، بسیاری از کاربران در ابتدا تصور می‌کنند بهترین راه این است که بزرگ‌ترین مدلی را که سخت‌افزارشان تحمل می‌کند، همیشه فعال نگه دارند. این نگاه در ظاهر منطقی است، چون مدل‌های بزرگ‌تر معمولاً در استدلال، تحلیل و تولید پاسخ‌های پیچیده عملکرد بهتری دارند. اما در عمل، اجرای local LLM فقط به کیفیت خروجی وابسته نیست. سرعت پاسخ، مصرف حافظه، فشار روی سیستم، تأخیر در بارگذاری مدل و تجربه کاربری هم به همان اندازه تعیین‌کننده هستند.

همین مسئله باعث شد ایده «روتر مدل» یا Model Router به‌عنوان یک راهکار عملی و حرفه‌ای مطرح شود. در این معماری، به‌جای استفاده دائمی از یک مدل سنگین برای همه نوع درخواست، یک مدل سبک همیشه در حافظه فعال می‌ماند و نقش پذیرش‌گر را بازی می‌کند. این مدل ابتدا درخواست را طبقه‌بندی می‌کند و سپس آن را به مناسب‌ترین مدل تخصصی ارجاع می‌دهد.

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

مسئله اصلی در اجرای محلی LLM چیست؟

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

در سیستم‌های Apple Silicon، این مسئله حتی مهم‌تر است، چون معماری unified memory باعث می‌شود CPU و GPU از یک استخر حافظه مشترک استفاده کنند. این ویژگی از یک طرف مزیت بزرگی برای اجرای local LLM به شمار می‌رود و از طرف دیگر، نیاز به مدیریت دقیق‌تر منابع را افزایش می‌دهد.

اگر یک مدل 32B با کوانتیزه Q4 چیزی حدود ۲۲ تا ۲۵ گیگابایت حافظه اشغال کند، عملاً بخش بزرگی از رم سیستم از دسترس خارج می‌شود. در چنین شرایطی، حتی اگر مدل روی کاغذ «جا شود»، فضای کافی برای سیستم‌عامل، مرورگر، IDE، Docker، context window و درخواست‌های موازی باقی نمی‌ماند. این یعنی کاربر با کندی، فشار حافظه و افت تجربه کاربری روبه‌رو می‌شود.

روتر مدل چیست و چگونه کار می‌کند؟

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

در الگوی مطرح‌شده، یک مدل کوچک همیشه در حافظه فعال باقی می‌ماند و دو نقش را هم‌زمان انجام می‌دهد:

• طبقه‌بندی نوع درخواست
• پاسخ‌گویی مستقیم به پرسش‌های عمومی

در کنار آن، مدل‌های تخصصی فقط در مواقع ضروری بارگذاری می‌شوند. به‌عنوان مثال:

• یک مدل عمومی 7B برای سؤالات روزمره، خلاصه‌سازی و ترجمه
• یک مدل تخصصی برای کدنویسی، دیباگ و بازبینی کد
• یک مدل 32B برای استدلال‌های پیچیده، تحلیل چندمرحله‌ای و reasoning سنگین

این ساختار باعث می‌شود که مدل‌های بزرگ فقط زمانی حافظه اشغال کنند که واقعاً لازم باشند.

چرا استفاده از یک مدل بزرگ برای همه درخواست‌ها بهینه نیست؟

نگه داشتن دائمی یک مدل بزرگ در حافظه شاید از نظر تئوری جذاب باشد، اما در عمل بهینه نیست. دلیل اصلی این است که همه درخواست‌ها به سطح توانایی یک مدل 32B نیاز ندارند.

پرسش‌های ساده‌ای مانند ترجمه، خلاصه‌سازی، سؤال‌های عمومی یا مکالمه روزمره را می‌توان با یک مدل کوچک‌تر و سریع‌تر پاسخ داد. استفاده از مدل سنگین برای این نوع درخواست‌ها مانند این است که برای انجام یک کار ساده، همیشه پرهزینه‌ترین و سنگین‌ترین ابزار ممکن را به کار بگیرید.

در معماری روتر مدل، این مسئله برعکس می‌شود. بیشتر درخواست‌ها توسط مدل همیشه‌فعال و سریع پاسخ داده می‌شوند و فقط درخواست‌های تخصصی به مدل‌های کدنویسی یا reasoning ارجاع داده می‌شوند. این یعنی:

• مصرف حافظه بهینه‌تر می‌شود
• سرعت پاسخ در اغلب سناریوها بالاتر می‌رود
• فشار کلی روی سیستم کاهش پیدا می‌کند
• مدل بزرگ فقط زمانی فعال می‌شود که واقعاً ارزش استفاده داشته باشد

چرا طبقه‌بندی با LLM از روش‌های قانون‌محور و embedding-based بهتر عمل می‌کند؟

برای مسیریابی درخواست‌ها، معمولاً سه رویکرد اصلی وجود دارد:

روش قانون‌محور

در این روش، با استفاده از کلیدواژه‌ها یا الگوهای متنی، نوع درخواست تشخیص داده می‌شود. این راهکار سریع است، اما در برابر تنوع زبان طبیعی ضعف دارد. کاربران همیشه از کلمات یکسان برای بیان خواسته‌های مشابه استفاده نمی‌کنند و همین موضوع باعث کاهش دقت می‌شود.

روش embedding-based

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

روش طبقه‌بندی با خود LLM

در این معماری، همان مدل کوچکی که همیشه در حافظه فعال است، وظیفه طبقه‌بندی را هم برعهده می‌گیرد. این مدل با یک پرامپت کوتاه و دمای صفر، درخواست را تنها به یکی از دسته‌های GENERAL، CODE یا REASONING نسبت می‌دهد.

مزیت این روش این است که:

• نیاز به زیرساخت اضافی ندارد
• درک معنایی بهتری از intent کاربر دارد
• برای استک محلی بسیار ساده و عملی است
• هزینه سیستمی آن پایین است، چون مدل از قبل بارگذاری شده است

مشکل cold start در Ollama چرا مهم است؟

یکی از مسائل مهم در اجرای چندمدلی، تأخیر ناشی از بارگذاری مدل‌های تخصصی است. اگر مدل هدف در حافظه نباشد، Ollama باید آن را از دیسک بارگذاری کند. این فرایند برای مدل‌های 7B ممکن است چند ثانیه زمان ببرد و برای مدل‌های 32B حتی بیشتر هم طول بکشد.

مشکل اصلی cold start فقط این نیست که کاربر چند ثانیه بیشتر صبر می‌کند. مسئله مهم‌تر این است که اگر هیچ بازخوردی دریافت نکند، احتمالاً تصور می‌کند سیستم متوقف شده یا دچار مشکل شده است. این موضوع مستقیماً به اعتماد کاربر و تجربه استفاده مربوط می‌شود.

راهکار عملی برای مدیریت cold start

راه‌حل مؤثر این مشکل، الزاماً سریع‌تر کردن بارگذاری نیست؛ بلکه اطلاع‌رسانی شفاف به کاربر است.

پیش از ارسال درخواست به مدل نهایی، می‌توان از endpoint مربوط به Ollama /api/ps استفاده کرد تا مشخص شود کدام مدل‌ها هم‌اکنون در حافظه بارگذاری شده‌اند. اگر مدل موردنظر فعال نباشد، سیستم باید پیش از شروع پردازش، پیام مناسبی به کاربر نمایش دهد؛ برای مثال:

در حال بارگذاری مدل موردنیاز؛ این فرایند ممکن است چند ثانیه طول بکشد.

همین پیام ساده باعث می‌شود کاربر دلیل تأخیر را بداند و رفتار سیستم را به‌عنوان یک خطا برداشت نکند.

معماری عملی این راهکار چگونه پیاده‌سازی می‌شود؟

پیاده‌سازی روتر مدل از نظر معماری پیچیده نیست. در ساده‌ترین شکل، فرایند شامل چهار مرحله است:

مرحله اول: طبقه‌بندی درخواست

مدل کوچک همیشه‌فعال، متن کاربر را دریافت می‌کند و مشخص می‌کند که درخواست از چه نوعی است.

مرحله دوم: انتخاب مدل هدف

براساس دسته‌بندی انجام‌شده، مدل مناسب از جدول مسیریابی انتخاب می‌شود.

مرحله سوم: بررسی وضعیت بارگذاری مدل

پیش از dispatch، از طریق API بررسی می‌شود که مدل موردنظر در حافظه فعال است یا خیر.

مرحله چهارم: ارسال درخواست با timeout مناسب

در صورت نیاز، زمان مناسب برای cold start در نظر گرفته می‌شود تا درخواست با خطای زودهنگام قطع نشود.

این معماری را می‌توان با تعداد کمی کلاس و یک routing table ساده در پایتون پیاده‌سازی کرد. همین سادگی، یکی از مزیت‌های اصلی این الگو است.

تنظیمات مهم Ollama برای این سناریو

برای اینکه این معماری عملکرد بهتری داشته باشد، برخی تنظیمات Ollama اهمیت زیادی دارند.

محدود کردن تعداد مدل‌های بارگذاری‌شده

با استفاده از OLLAMA_MAX_LOADED_MODELS می‌توان سقف مدل‌هایی را که هم‌زمان در حافظه می‌مانند کنترل کرد. این تنظیم از اشغال بی‌رویه حافظه جلوگیری می‌کند.

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

متغیر OLLAMA_NUM_PARALLEL امکان پردازش هم‌زمان چند درخواست را فراهم می‌کند، اما باید با دقت تنظیم شود؛ چون هر درخواست موازی می‌تواند بخشی از KV cache را مصرف کند و فشار حافظه را افزایش دهد.

در نتیجه، تنظیم این دو پارامتر باید با توجه به headroom واقعی سیستم انجام شود، نه صرفاً بر اساس بیشترین مقدار ممکن.

محدودیت‌های مهم روتر مدل

هرچند این رویکرد بسیار مؤثر است، اما محدودیت‌هایی هم دارد که نباید نادیده گرفته شوند.

مشکل context handover

اگر مکالمه چندمرحله‌ای باشد و نوع درخواست در میانه گفتگو تغییر کند، مدل جدید باید کل تاریخچه مکالمه را دوباره ingest کند. این مسئله می‌تواند چند ثانیه تأخیر اضافه ایجاد کند.

هزینه جابه‌جایی بین مدل‌ها

در درخواست‌های single-turn، این هزینه تقریباً ناچیز است. اما در گفتگوهای طولانی و چندمرحله‌ای، هر تغییر مسیر بین مدل‌ها می‌تواند سربار پردازشی قابل‌توجهی ایجاد کند.

مقیاس‌پذیری محدود در سناریوهای پرترافیک

برای استفاده شخصی یا تیم‌های کوچک، این معماری بسیار مناسب است. اما اگر تعداد کاربران زیاد شود، ممکن است مدل هم‌زمانی Ollama به گلوگاه تبدیل شود و نیاز به زیرساخت‌هایی مثل چند instance یا inference serverهای تخصصی‌تر به وجود آید.

مهم‌ترین مزیت این معماری برای کاربران local AI چیست؟

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

در چنین مدلی:

• درخواست‌های ساده با سرعت بالا پاسخ داده می‌شوند
• مدل‌های بزرگ‌تر فقط برای کارهای پیچیده وارد عمل می‌شوند
• حافظه سیستم آزادتر باقی می‌ماند
• تجربه کاربری در بیشتر مواقع سریع‌تر و روان‌تر است
• هزینه فرصت اجرای local LLM کاهش پیدا می‌کند

این یعنی مدل 32B به‌جای آنکه همیشه در حافظه بماند و منابع را اشغال کند، فقط زمانی فعال می‌شود که واقعاً ارزش این هزینه را داشته باشد.

جمع‌بندی

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

روتر مدل دقیقاً همین مسئله را حل می‌کند. یک مدل کوچک همیشه آماده می‌ماند، درخواست‌ها را می‌فهمد و کارهای عمومی را سریع انجام می‌دهد. در مقابل، مدل‌های تخصصی فقط زمانی بارگذاری می‌شوند که مسئله مطرح‌شده واقعاً به آن‌ها نیاز داشته باشد.

برای کسانی که با Ollama، Apple Silicon و local LLMها کار می‌کنند، این الگو می‌تواند یک مسیر عملی برای کاهش مصرف حافظه، افزایش سرعت پاسخ و استفاده حرفه‌ای‌تر از چند مدل باشد. به‌جای یک مدل برای همه چیز، شما یک تیم از مدل‌ها می‌سازید که هرکدام در زمان مناسب وارد عمل می‌شوند.

سوالات متداول

آیا روتر مدل فقط برای Apple Silicon مناسب است؟

خیر. این الگو از نظر معماری backend-agnostic است و محدود به Apple Silicon نیست. با این حال، به دلیل unified memory، روی دستگاه‌های Apple Silicon مزایای آن ملموس‌تر دیده می‌شود.

آیا یک مدل 7B برای طبقه‌بندی درخواست‌ها کافی است؟

بله. برای سه دسته اصلی مانند GENERAL، CODE و REASONING، یک مدل 7B معمولاً کافی است. حتی در برخی سناریوها، مدل‌های کوچک‌تر هم می‌توانند این نقش را ایفا کنند.

آیا این روش برای Ollama بهترین گزینه است؟

برای استفاده شخصی و تیم‌های کوچک، Ollama یک گزینه بسیار عملی و ساده است. اما در مقیاس بالاتر، ممکن است به زیرساخت‌های تخصصی‌تر نیاز باشد.

مهم‌ترین چالش این روش چیست؟

مهم‌ترین چالش، هزینه context handover در مکالمات چندمرحله‌ای و تأخیر ناشی از cold start در زمان جابه‌جایی بین مدل‌ها است.