برای هر کاربرد واقعاً چه اندازه مدلی لازم داریم؟ از مدل تخصصی و SLM تا LLM

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

اندازه مناسب، ویژگی ثابت یک عنوان مثل «چت‌بات» نیست. به دامنه پرسش‌ها، زبان، طول ورودی، خطاهای قابل تحمل و تعداد درخواست‌های همزمان بستگی دارد. برای رسیدن به آن باید ابتدا روشن کنیم خروجی قابل قبول چیست و سپس ببینیم کدام مدل آن را با هزینه و زمان مناسب تولید می‌کند.

«تخصصی» و «کوچک» دو ویژگی متفاوت‌اند

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

اصطلاح SLM، یا مدل زبانی کوچک، مرز عددی واحدی ندارد؛ مرور پژوهشی مدل‌های زبانی کوچک نیز تغییر معنای «کوچک» با زمینه و زمان را توضیح می‌دهد. در این نوشته، هنگام صحبت از مدل‌های مولد، منظور عمدتاً مدل‌هایی در مقیاس چندصد میلیون تا چند میلیارد پارامتر است؛ برای انتخاب واقعی، اندازه دقیق هر مدل را در نظر می‌گیریم. مدل ۸ میلیاردی نیز در مقایسه با مدل ۷۰ میلیاردی کوچک است، اما برای یک کار ساده همچنان می‌تواند بیش از نیاز باشد.

تفاوت نقش را می‌توان در دو مدل از یک خانواده دید. BGE-M3 برای بازنمایی و بازیابی متن است و روش‌های برداری، تنک و چندبرداری دارد. BGE-Reranker-v2-M3 پرسش و متن را با هم دریافت می‌کند و به ارتباط آن‌ها امتیاز می‌دهد. هر دو می‌توانند بخش مهمی از یک دستیار سازمانی باشند، اما تولید پاسخ نهایی نقش دیگری است که مدل مولد انجام می‌دهد. انتخاب اندازه زمانی معنا پیدا می‌کند که این نقش‌ها از ابتدا مشخص باشند.

چت ساده، پاسخ مستند و تحلیل پیچیده چه تفاوتی دارند؟

در چت ساده و پاسخ‌گویی محدود، کار مدل غالباً فهم درخواست، رعایت چند دستور و نوشتن پاسخی کوتاه است. در RAG ساده نیز دانش لازم از اسناد به ورودی می‌رسد و مدل باید همان شواهد را درست بخواند و بیان کند. این شرایط، مدل کوچک دارای توان مناسب در زبان مورد نیاز را به گزینه اقتصادی خوبی برای شروع تبدیل می‌کند؛ نمونه‌هایی مانند SmolLM2-1.7B-Instruct نیز نتایج مشخصی برای بازنویسی و پیروی از دستور دارند. کیفیت بازیابی، محدودبودن دامنه و سادگی پاسخ در این انتخاب نقش تعیین‌کننده دارند.

SmolLM2-1.7B عمدتاً برای انگلیسی آموزش دیده است؛ کوچکی آن به‌تنهایی دلیل انتخاب برای پاسخ‌گویی فارسی نیست.

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

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

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

جدول تخمینی تناسب اندازه مدل با کاربرد

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

برای embedding و reranking، انتخاب از خانواده تخصصی همان نقش آغاز می‌شود؛ مثلاً Qwen3-Embedding-0.6B با ۶۰۰ میلیون پارامتر برای بازنمایی متن عرضه شده است. در دسته‌بندی نیز روش‌های کلاسیک متن خط مبنای مفیدی هستند. در اسناد تصویری، ابتدا باید میان OCR همراه مدل متنی و مدل دارای ورودی تصویر تصمیم گرفت؛ اندازه بیشتر، قابلیت دیدن تصویر را به یک مدل صرفاً متنی اضافه نمی‌کند.

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

اعداد منتشرشده چه چیزی را روشن می‌کنند؟

در گزارش ناشر SmolLM3، دو مدل کوچک روی دو آزمون نتیجه متفاوتی دارند. IFEval پیروی از دستورهای قابل بررسی و LiveCodeBench توان حل مسئله کدنویسی را می‌سنجد.

این اعداد از بخش بدون حالت تفکر در کارت رسمی SmolLM3-3B آمده‌اند. مدل ۳ میلیاردی در آزمون نخست بالاتر و در آزمون دوم پایین‌تر است. نتایج، گزارش ناشرند و آزمایش کنترل‌شده اثر تعداد پارامتر نیستند؛ داده آموزشی و روش آموزش دو مدل نیز تفاوت دارد. همین نمونه نشان می‌دهد چرا یک رتبه کلی برای تمام کاربردها کافی نیست.

در گزارش رسمی DeepSeek-R1، نسخه‌های تقطیرشده ۱۴ و ۳۲ میلیاردی مبتنی بر Qwen در MATH-500 به‌ترتیب امتیاز ۹۳٫۹ و ۹۴٫۳ دارند؛ فاصله ۰٫۴ واحد است. فاصله همان دو مدل در GPQA Diamond بیشتر است: ۵۹٫۱ در برابر ۶۲٫۱. هر دو نتیجه با معیار pass@1 گزارش شده‌اند. پس حتی در یک مجموعه مدل، ارزش افزایش اندازه به نوع مسئله وابسته است. برای کاربردی نزدیک به آزمون اول و کاربردی نزدیک به آزمون دوم، تصمیم اقتصادی می‌تواند متفاوت باشد.

مدل‌های تخصصی هم از این قاعده مستثنا نیستند. در مقاله Qwen3 Embedding، جدول ۴، reranker چهارمیلیاردی در مجموعه بازیابی انگلیسی MTEB-R امتیاز ۶۹٫۷۶ و نسخه هشت‌میلیاردی ۶۹٫۰۲ دارد. در مجموعه چندزبانه MMTEB-R ترتیب برعکس است: ۷۲٫۷۴ و ۷۲٫۹۴. این مقایسه با بازمرتب‌سازی ۱۰۰ نتیجه اولیه بازیابی‌شده توسط Qwen3-Embedding-0.6B انجام شده است.

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

اندازه را پس از تعیین وظیفه انتخاب کنید

در جدول Qwen، گونهٔ Qwen3-4B-Instruct-2507 روی LiveCodeBench v6 امتیاز 35.1 دارد و Qwen3-30B-A3B در حالت non-thinking امتیاز 29.0؛ اما در Aider-Polyglot ترتیب برعکس می‌شود: 12.9 در برابر 24.4. معیار اول برای مسئله‌های کدنویسی و معیار دوم برای ویرایش کد در گردش‌کار Aider شاهد می‌دهد. بنابراین عنوان «مدل بهتر برای کدنویسی» بیش از داده ادعا می‌کند. مدل را با نام دقیق، حالت تولید و وظیفهٔ آزمون انتخاب کنید.

در RAG، اندازه مدل پاسخ‌گو فقط یکی از تصمیم‌هاست

در یک دستیار دانش سازمانی معمولاً سه کار جدا انجام می‌شود: پیدا کردن متن مرتبط، اولویت‌بندی آن و ساختن پاسخ با استفاده از شواهد. embedding به بخش اول کمک می‌کند، reranker می‌تواند بخش دوم را بهتر کند و مدل مولد مسئول نوشتن پاسخ است.

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

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

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

دانش را به مدل برسانیم یا مدل را دوباره آموزش دهیم؟

وجود داده اختصاصی سازمان، به‌خودی‌خود دلیل کافی برای fine-tuning نیست. باید مشخص شود مدل به اطلاعات دسترسی ندارد یا با وجود اطلاعات درست، رفتار و مهارت مورد نیاز را نشان نمی‌دهد؛ روش مناسب برای این دو وضعیت می‌تواند متفاوت باشد. RAG، CAG و KAG عمدتاً درباره چگونگی استفاده از دانش در سامانه‌اند، در حالی که fine-tuning و instruction tuning به آموزش مربوط می‌شوند و می‌توانند در کنار آن روش‌ها قرار گیرند.

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

منظور از CAG در اینجا Cache-Augmented Generation است: مجموعه مشخصی از منابع، از قبل به زمینه مدل وارد می‌شود و وضعیت محاسبه‌شده آن، معمولاً KV cache، برای پرسش‌های بعدی دوباره استفاده می‌شود. برای راهنما یا مجموعه دانشی محدود و نسبتاً ثابت، این کار می‌تواند جست‌وجوی هر درخواست و محاسبه تکراری پیشوند را کاهش دهد؛ دانش و پرسش و فضای لازم برای پاسخ باید در زمینه قابل استفاده جا شوند و تغییر منابع نیز به بازسازی بخش مربوط از کش نیاز دارد. در پژوهش CAG، محدود و قابل مدیریت بودن مجموعه اسناد شرط مهم کاربرد روش است؛ ذخیره این وضعیت به معنی آموزش وزن‌های مدل نیست.

در KAG یا Knowledge Augmented Generation، با معنای مشخص آن در چارچوب OpenSPG، گراف دانش، قطعه‌های متن و استدلال هدایت‌شده با صورت منطقی به هم متصل می‌شوند. این طراحی برای پرسش‌هایی که به رابطه، قاعده و چند گام استنتاج وابسته‌اند قابل بررسی است، اما ساخت و نگهداری دانش ساختاریافته هم هزینه دارد. KAG صرفاً نام دیگری برای بزرگ‌کردن زمینه یا یک روش تضمین‌شده برای حذف خطای مدل نیست؛ چارچوب اصلی حتی تقویت مدل با آموزش را هم در کنار اجزای بازیابی و استدلال بررسی می‌کند.

Fine-tuning یا تنظیم تکمیلی، ادامه آموزش مدل ازپیش‌آموزش‌دیده برای سازگاری با داده، دامنه یا وظیفه است؛ مستندات Transformers همین تمایز را توضیح می‌دهد. Instruction tuning یا تنظیم مبتنی بر دستور، نوعی fine-tuning است که نمونه‌های وظیفه را همراه دستور و پاسخ مطلوب به کار می‌گیرد تا رفتار پاسخ‌گویی مدل بهتر شود؛ این تعریف در پژوهش FLAN نیز آمده است. بنابراین استفاده از یک مدل آماده Instruct می‌تواند از ابتدا بخش زیادی از نیاز به پیروی از دستور را پوشش دهد، بدون اینکه سازمان خودش مرحله آموزش تازه‌ای اجرا کند.

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

این انتخاب می‌تواند ترکیبی باشد: یک مدل کوچک برای استخراج یا پیروی از دستور تنظیم شود و اطلاعات جاری را از RAG بگیرد؛ بخشی از زمینه ثابت هم با کش دوباره استفاده شود. اثر هر ترکیب بر کیفیت، حافظه و هزینه متفاوت است و باید با نیاز کار هماهنگ شود. مقایسه کامل این روش‌ها و معیار انتخاب میان آن‌ها در مقاله «RAG، CAG، KAG، Fine-tuning و Instruction tuning؛ چه تفاوتی دارند و کدام را انتخاب کنیم؟» توضیح داده شده است.

فارسی را با نتیجه انگلیسی جایگزین نکنیم

برای انتخاب اولیه، زبان‌های اعلام‌شده مدل سرنخ خوبی هستند. مثلاً Aya Expanse 8B فارسی را در میان ۲۳ زبان پشتیبانی‌شده نام می‌برد. این ویژگی آن را به گزینه‌ای مرتبط برای مقایسه فارسی تبدیل می‌کند؛ برتری آن در هر کار فارسی از همین فهرست نتیجه نمی‌شود.

در تجربهٔ عملی ترگمان با Aya Expanse، نسخهٔ هشت‌میلیاردی را با دادگان فارسی TLPC فاین‌تیون کردیم و برای ترجمه، خلاصه‌سازی و گفت‌وگو در اختیار کاربران گذاشتیم. این تجربه برای ما نشان داد که Aya می‌تواند پایهٔ یک سرویس کاربردی برای کاربران فارسی‌زبان باشد. در این نتیجه، سازگارکردن مدل با متن فارسی و اطلاعاتی که هنگام پاسخ در اختیارش می‌گذاشتیم هم نقش داشتند؛ پس هنگام انتخاب، کیفیت نسخهٔ نهایی را با نمونه‌های واقعیِ کار فارسی بسنجیم.

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

تعداد پارامتر، اندازه فایل و حافظه اجرا یکی نیستند

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

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

در مدل‌های MoE، پارامتر فعال نیز با پارامتر کل تفاوت دارد. Qwen3-Coder-30B-A3B-Instruct طبق کارت رسمی ۳۰٫۵ میلیارد پارامتر کل و ۳٫۳ میلیارد پارامتر فعال دارد. فعال‌بودن بخشی از پارامترها، حجم تمام وزن‌های مدل را به حجم یک مدل ۳٫۳ میلیاردی تبدیل نمی‌کند؛ برای نگهداری کامل وزن‌ها روی GPU، پارامتر کل و قالب ذخیره‌سازی اهمیت دارند.

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

یک بار استنتاج با ارائه سرویس به چند کاربر فرق دارد

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

مدل کوچک‌تر در اینجا دو مزیت بالقوه دارد: می‌تواند دامنه انتخاب GPUهای کم‌حافظه‌تر و ارزان‌تر را گسترش دهد و با اشغال فضای کمتر برای وزن‌ها، حافظه بیشتری برای درخواست‌های فعال باقی بگذارد. اگر کیفیت کافی باشد، بودجه یک مدل بزرگِ نیازمند چند GPU را می‌توان با چند نسخه مستقل از مدل کوچک روی کارت‌های جداگانه مقایسه کرد. در استقرار data parallel، همین نسخه‌ها دسته‌های مستقلی از درخواست‌ها را پردازش می‌کنند و بار میان آن‌ها توزیع می‌شود؛ مستندات vLLM این شیوه استقرار را توضیح می‌دهد. سود نهایی به قیمت کل زیرساخت، توان هر کارت و بار کاری بستگی دارد.

برای هر کاربر لازم نیست یک نسخه جدا از وزن‌های مدل بارگذاری شود؛ یک موتور سرویس‌دهی می‌تواند چند درخواست را با وزن‌های مشترک پردازش کند، در حالی که وضعیت زمینه هر درخواست مدیریت می‌شود. افزایش تعداد درخواست‌های همزمان در یک موتور، با افزایش تعداد نسخه‌های مستقل مدل فرق دارد. اجرای چند نسخه روی یک GPU نیز وزن‌ها را تکرار می‌کند و منابع مشترک را به رقابت می‌گذارد؛ در مقابل، batching و مدیریت مناسب KV cache می‌توانند از همان نسخه استفاده بیشتری بگیرند، موضوعی که در پژوهش PagedAttention و vLLM بررسی شده است.

یک مثال آموزشی از بودجه حافظه: فرض کنیم ۲۴ GiB حافظه در دسترس است و ۴ GiB برای سربار اجرا کنار گذاشته شده است. با ۴ GiB وزن مدل، ۱۶ GiB و با ۱۶ GiB وزن، ۴ GiB برای KV cache باقی می‌ماند؛ اگر هر درخواست فعال یک GiB کش بخواهد، سقف صرفاً حافظه‌ای به‌ترتیب ۱۶ و ۴ درخواست است. اگر زمینه بلندتر نیاز هر درخواست را به ۴ GiB برساند، این سقف‌ها به ۴ و ۱ کاهش می‌یابند. این محاسبه فرضی اثر بودجه حافظه را نشان می‌دهد؛ مصرف KV در مدل‌های واقعی به معماری و دقت کش وابسته است و این سقف، تضمین سرعت پاسخ یا تعداد کاربر قابل خدمت نیست.

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

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

AirLLM و انتخاب موتور اجرا چه اثری دارند؟

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

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

از چند گزینه به یک تصمیم قابل دفاع برسیم

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

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

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

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

۴. خطا را به بخش مسئول برگردانیم. شکست OCR، نبود سند، پاسخ اشتباه ابزار و خطای مدل یکسان نیستند. بزرگ‌کردن مدل وقتی توجیه دارد که بهبود آن، خطای باقی‌مانده و مهم را کاهش دهد.

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

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

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

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