برای بسیاری از سازمان‌ها دیگر پرسش این نیست که از مدل‌های زبانی بزرگ استفاده کنند یا نه؛ پرسش این است که این مدل‌ها کجا اجرا شوند. APIهای میزبانی‌شده سریع‌ترین راه شروع‌اند. اما بانک‌ها، کارگزاری‌ها، مراکز درمانی و نهادهای عمومی اغلب نمی‌توانند داده مشتری را برای یک ارائه‌دهنده بیرونی بفرستند، با محدودیت انتقال داده به خارج از کشور روبه‌رو هستند یا به‌سادگی به دسترس‌پذیری تضمین‌شده و هزینه قابل پیش‌بینی نیاز دارند. مدل‌های با وزن باز (open-weight) آن‌قدر خوب شده‌اند که میزبانی خودی برای طیف گسترده‌ای از کارها گزینه‌ای واقع‌بینانه است. در این مقاله بررسی می‌کنیم راه‌اندازی LLM روی سرور شخصی چه زمانی و چگونه به‌صرفه است.
در این مقاله بده‌بستان‌ها و اهرم‌های فنی را بررسی می‌کنیم: انتخاب مدل، کوانتیزه‌سازی، سرویس‌دهی و هزینه.
چرا میزبانی خودی
- حاکمیت و محرمانگی داده. پرامپت‌ها اغلب حساس‌ترین داده‌های سازمان را در خود دارند: گفت‌وگو با مشتری، قراردادها، موقعیت‌های معاملاتی. روی زیرساخت خودتان داده هرگز از کنترل شما خارج نمی‌شود و می‌توانید این را به ممیزان نشان دهید.
- سازگاری با مقررات. رعایت الزامات محل نگهداری داده، مقررات ناظران بخشی و سیاست‌های داخلی وقتی پردازش در حوزه قضایی و مرکز داده مشخصی انجام می‌شود ساده‌تر است.
- دسترس‌پذیری و استقلال. بدون وابستگی به قطعی‌ها، محدودیت نرخ، تغییر قیمت، کنار گذاشتن مدل‌ها یا محدودیت‌های دسترسی یک ارائه‌دهنده.
- سفارشی‌سازی. می‌توانید مدل را تنظیم دقیق (fine-tune) کنید، آداپتورها را ادغام کنید، روش تولید متن را کنترل کنید و نسخه دقیق را ثابت نگه دارید تا رفتار مدل بی‌خبر تغییر نکند.
- هزینه در حجم پایدار. در بهره‌برداری بالا و پایدار، GPU خریداری‌شده یا رزروشده می‌تواند به ازای هر توکن ارزان‌تر از API باشد. در حجم کم یا نامنظم معمولاً این‌طور نیست.
نقطه مقابل را هم باید صادقانه گفت: عملیات، وصله‌های امنیتی، برنامه‌ریزی ظرفیت و ارزیابی مدل بر عهده خودتان است و بزرگ‌ترین مدل‌های تجاری ممکن است در دشوارترین کارهای استدلالی همچنان قوی‌تر باشند. بسیاری از سازمان‌ها در نهایت ترکیبی عمل می‌کنند: مدل‌های میزبانی خودی برای کارهای حساس یا پرحجم و APIهای بیرونی برای کارهای غیرحساس که در آن‌ها ارزش افزوده دارند.
انتخاب مدل
بر اساس وظیفه، زبان و اندازه انتخاب کنید و سپس روی داده خودتان بیازمایید:
- اندازه در برابر نیاز. مدل‌های ۷ تا ۱۴ میلیارد پارامتری در طبقه‌بندی، استخراج اطلاعات، خلاصه‌سازی و پاسخ‌گویی RAG، به شرط داشتن زمینه خوب، عملکرد مناسبی دارند. مدل‌های ۳۰ تا ۷۰ میلیارد پارامتری یا مدل‌های ترکیب خبرگان (MoE) برای استدلال پیچیده، اسناد طولانی و استفاده عامل‌محور از ابزار بهترند.
- پوشش زبانی. برای فارسی و زبان‌های کم‌نماینده‌تر، روانی متن، کارایی توکن‌ساز (اینکه یک جمله معمولی چند توکن می‌شود) و پیروی از دستورالعمل را بیازمایید. توکن‌سازی ضعیف می‌تواند هزینه را دو برابر و زمینه مؤثر را نصف کند.
- مجوز. مجوزهای مدل‌های با وزن باز در استفاده تجاری، سقف کاربران و بازتوزیع با هم تفاوت دارند. پیش از ساختن روی یک مدل، مجوزش را به بررسی حقوقی بسپارید.
- طول زمینه. زمینه طولانی مفید است، اما حافظه کش توجه (attention) با آن بزرگ می‌شود. اگر پایپ‌لاین RAG شما ۸ هزار توکن می‌فرستد، هزینه ۱۲۸ هزار توکن را نپردازید.
کوانتیزه‌سازی مدل: بزرگ‌ترین اهرم روی سخت‌افزار
وزن‌های مدل با دقت ۱۶ بیتی آموزش داده می‌شوند. بنابراین یک مدل ۷۰ میلیارد پارامتری فقط برای وزن‌ها حدود ۱۴۰ گیگابایت حافظه می‌خواهد، آن هم پیش از کش کلید–مقدار (KV cache). کوانتیزه‌سازی وزن‌ها را با بیت‌های کمتری ذخیره می‌کند:
- ۸ بیتی (INT8 یا FP8) حافظه را نصف می‌کند و برای بیشتر کارها افت کیفیت ناچیزی دارد. FP8 روی GPUهای جدید مراکز داده به‌طور سخت‌افزاری شتاب می‌گیرد.
- ۴ بیتی با روش‌هایی مانند GPTQ و AWQ و قالب‌های GGUF که llama.cpp استفاده می‌کند، حافظه را تقریباً به یک‌چهارم می‌رساند و یک مدل ۷۰B در حدود ۴۰ گیگابایت وزن جا می‌شود. افت کیفیت برای چت و RAG معمولاً اندک است، اما آن را روی کارهای خودتان بسنجید، به‌ویژه در استدلال، ریاضیات و متن غیرانگلیسی.
- کوانتیزه‌سازی کش KV حافظه هر درخواست هم‌زمان را کاهش می‌دهد و تعداد کاربرانی را که یک GPU هم‌زمان پاسخ می‌دهد بالا می‌برد.
قاعده سرانگشتی برای حافظه وزن‌ها: تعداد پارامتر × تعداد بیت ÷ ۸ بایت، به‌علاوه ۱۰ تا ۳۰ درصد سربار، به‌علاوه کش KV که با اندازه دسته و طول زمینه رشد می‌کند. همیشه دقت را پیش و پس از کوانتیزه‌سازی روی مجموعه ارزیابی خودتان بسنجید؛ مدلی که در معیارهای انگلیسی ۲ درصد افت دارد، ممکن است در فارسی به‌طور محسوسی ضعیف‌تر شود.
سرویس‌دهی: توان عملیاتی از موتور می‌آید
موتور سرویس‌دهی به اندازه خود GPU اهمیت دارد. موتورهای امروزی مانند vLLM، Hugging Face TGI، NVIDIA TensorRT-LLM و SGLang این قابلیت‌ها را فراهم می‌کنند:
- دسته‌بندی پیوسته (Continuous batching): درخواست‌های جدید در هر گام به دسته در حال اجرا می‌پیوندند و منتظر پایان کل دسته نمی‌مانند. همین به‌تنهایی توان عملیاتی را چند برابر می‌کند.
- توجه صفحه‌بندی‌شده (Paged attention): کش KV مانند حافظه مجازی در بلوک‌ها ذخیره می‌شود، پراکندگی کاهش می‌یابد و درخواست‌های بیشتری جا می‌شوند.
- کش پیشوند: استفاده دوباره از محاسبات برای پیشوندهای مشترک پرامپت، مانند پرامپت سیستمی و دستورالعمل‌های RAG.
- رمزگشایی گمانه‌زنانه (Speculative decoding): یک مدل کوچک پیش‌نویس توکن‌ها را پیشنهاد می‌دهد و مدل بزرگ آن‌ها را به‌صورت موازی تأیید می‌کند و تأخیر کم می‌شود.
- موازی‌سازی تانسوری و خط لوله‌ای: تقسیم مدل‌های بزرگ میان چند GPU.
- API سازگار با OpenAI: تا برنامه‌ها بتوانند فقط با تغییر پیکربندی میان سرویس میزبانی‌شده و میزبانی خودی جابه‌جا شوند.
برای استقرار فقط با CPU یا در لبه شبکه، llama.cpp همراه با کوانتیزه‌سازی GGUF گزینه‌ای عملی برای مدل‌های کوچک‌تر و هم‌زمانی کم است.
از نظر عملیاتی، با سرور مدل مثل هر سرویس عملیاتی دیگری رفتار کنید: بررسی سلامت، مقیاس‌پذیری خودکار بر اساس طول صف، مهلت زمانی درخواست، محدودیت نرخ برای هر مشتری داخلی، لاگ ساختاریافته و شاخص‌هایی مانند زمان تا نخستین توکن، توکن در ثانیه و مصرف حافظه GPU. یک دروازه داخلی جلوی آن قرار دهید برای احراز هویت، مسیریابی میان مدل‌ها، حسابداری مصرف و سیاست‌های محتوا.
برآورد هزینه LLM
بر حسب هزینه هر یک میلیون توکن در بهره‌برداری واقعی فکر کنید:
۱. توان عملیاتی پایدار (توکن در ثانیه) را برای طول معمول پرامپت و خروجی، در تأخیر هدف، روی GPU و کوانتیزه‌سازی انتخابی‌تان اندازه بگیرید.
۲. ظرفیت ماهانه را محاسبه کنید: توکن در ثانیه × ۳۶۰۰ × ۲۴ × ۳۰ × ضریب بهره‌برداری مورد انتظار (برای بارهای تعاملی اغلب ۳۰ تا ۶۰ درصد).
۳. هزینه ماهانه سخت‌افزار (استهلاک سه‌ساله یا قیمت رزرو ابری)، برق، سرمایش، میزبانی و سهم واقع‌بینانه‌ای از زمان مهندسی را بر این ظرفیت تقسیم کنید.
ضریب بهره‌برداری تعیین‌کننده است. GPU که ۷۰ درصد زمان مشغول است می‌تواند بسیار اقتصادی باشد؛ همان GPU با ۵ درصد اشغال گران تمام می‌شود. بارهای دسته‌ای مانند پردازش شبانه اسناد، خلاصه‌سازی تماس‌ها یا غنی‌سازی داده برای پر کردن ظرفیت بیکار عالی‌اند. مدل‌های کوچک‌تر و تنظیم‌شده برای کارهای محدود اغلب بهترین هزینه را به ازای هر پاسخ مفید دارند.
امنیت و حاکمیت
میزبانی خودی فقط وقتی حاکمیت داده را تضمین می‌کند که امن باشد. سرورهای مدل را در شبکه‌های خصوصی جدا کنید، ترافیک و ذخیره‌سازی را رمزنگاری کنید، کنترل کنید چه کسی می‌تواند مدلی را بارگذاری یا تغییر دهد، فایل‌های مدل را از منابع معتبر و با بررسی checksum دریافت کنید و وابستگی‌ها را اسکن کنید. پرامپت‌ها و خروجی‌ها را با احتیاط ثبت کنید؛ این‌ها داده حساس‌اند و باید همان قواعد نگهداری و دسترسی سامانه‌های منبع بر آن‌ها اعمال شود. فهرستی از مدل‌ها، نسخه‌ها، مجوزها و نتایج ارزیابی نگه دارید.
نقشه راه عمل‌گرایانه
با یک مورد کاربرد ارزشمند و حساس شروع کنید، مثلاً RAG روی دستورالعمل‌های داخلی یا خلاصه‌سازی گفت‌وگوهای مشتری. دو یا سه مدل با وزن باز را در حالت ۸ بیتی و ۴ بیتی روی مجموعه ارزیابی خودتان مقایسه کنید. آن را روی یک موتور سرویس‌دهی مدرن، پشت یک دروازه داخلی با API سازگار با OpenAI مستقر کنید. یک ماه کیفیت، تأخیر و بهره‌برداری واقعی را بسنجید و سپس سخت‌افزار را برای موارد کاربرد بعدی اندازه‌گذاری کنید. با این رویکرد، حاکمیت داده از یک محدودیت به یک توانمندی مهندسی تبدیل می‌شود.