استقرار مدل‌های زبانی بزرگ روی کوبرنتیز

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

کوبرنتیز برای بسیاری از تیم‌ها پاسخ رایج این سؤال است. در این مقاله توضیح می‌دهیم چرا، کدام موتور اجرا را انتخاب کنیم، وزن‌های مدل را کجا نگه داریم، سرویس را چطور مقیاس دهیم و پیش از انتشار چه چیزهایی را بررسی کنیم.

چرا کوبرنتیز برای اجرای مدل زبانی؟

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

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

انتخاب موتور سرو مدل زبانی بزرگ

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

• vLLM: از رایج‌ترین موتورهای متن‌باز برای سرو مدل‌های زبانی؛ با مدیریت بهینه حافظه KV Cache، بچینگ پیوسته و API سازگار با قالب رایج OpenAI.
• SGLang: موتور متن‌باز دیگری با تمرکز بر کارایی بالا و استفاده دوباره از پیشوندهای مشترک پرامپت، مناسب بارهای پیچیده و چندمرحله‌ای.
• TensorRT-LLM و Triton Inference Server: گزینه‌های بهینه‌شده برای سخت‌افزار NVIDIA که کارایی بالایی دارند اما پیکربندی‌شان پیچیده‌تر است.
• llama.cpp و Ollama: مناسب مدل‌های کوچک و فشرده‌شده، اجرای روی پردازنده و محیط‌های آزمایشی؛ برای بار هم‌زمان زیاد معمولاً انتخاب اول نیستند.

چرا بچینگ پیوسته اهمیت دارد؟

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

وزن‌های مدل را کجا نگه داریم؟

فایل وزن‌های یک مدل زبانی بزرگ می‌تواند از چند گیگابایت تا صدها گیگابایت حجم داشته باشد. قرار دادن آن داخل ایمیج کانتینر، ایمیج را سنگین و انتشار را کند می‌کند. الگوی بهتر این است که وزن‌ها در فضای ذخیره‌سازی فایل (Object Storage) با نسخه مشخص نگه داشته شوند و هنگام راه‌اندازی، یک کانتینر آماده‌ساز (Init Container) آن‌ها را روی دیسک محلی یا یک Persistent Volume دانلود کند. اگر چند نمونه از مدل روی یک سرور اجرا می‌شوند، یک نسخه کش‌شده مشترک زمان راه‌اندازی را بسیار کوتاه می‌کند.

از قالب safetensors برای وزن‌ها استفاده کنید؛ این قالب برخلاف فایل‌های pickle قدیمی، هنگام بارگذاری کدی اجرا نمی‌کند. هش فایل‌ها را هم ثبت کنید تا مطمئن باشید همان مدلی اجرا می‌شود که آزمایش کرده‌اید.

فشرده‌سازی مدل (Quantization)

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

الگوی اجرای LLM روی کوبرنتیز

یک استقرار قابل اعتماد معمولاً این اجزا را دارد:

• یک Deployment برای موتور سرو با درخواست و سقف منابع دقیق؛ اگر از GPU استفاده می‌کنید، افزونه دستگاه (Device Plugin) یا GPU Operator باید روی خوشه نصب باشد.
• قرار دادن پادهای مدل روی نودهای مناسب با nodeSelector و taint و toleration تا سرویس‌های سبک روی نودهای گران اجرا نشوند.
• Startup Probe و Readiness Probe با زمان کافی؛ بارگذاری مدل ممکن است چند دقیقه طول بکشد و نباید پیش از آماده شدن، ترافیک بگیرد.
• PodDisruptionBudget تا هنگام نگهداری نودها همه نمونه‌ها هم‌زمان از دسترس خارج نشوند.
• یک دروازه API جلوی موتور برای احراز هویت، محدودیت نرخ، ثبت مصرف و مسیریابی میان نسخه‌ها؛ موتور سرو را مستقیم در معرض اینترنت قرار ندهید.
• در صورت نیاز، ابزارهایی مانند KServe که الگوی استاندارد سرو مدل روی کوبرنتیز را آماده می‌کنند.

بخش‌های سبک مانند دروازه API، مدل Embedding کوچک و سرویس‌های واسط را می‌توانید روی سرور ابری معمولی اجرا کنید و ارتباط آن‌ها با موتور مدل را از طریق شبکهٔ خصوصی پروژه برقرار کنید. ورودی عمومی هم از طریق توزیع‌کنندهٔ بار و فایروال کنترل می‌شود.

مقیاس‌پذیری مدل زبانی

مقیاس‌دهی خودکار بر اساس مصرف پردازنده، که برای سرویس‌های وب رایج است، برای مدل زبانی گمراه‌کننده است. معیار بهتر، طول صف درخواست‌های در انتظار، تعداد درخواست هم‌زمان هر نمونه یا میزان پر شدن KV Cache است. ابزارهایی مانند KEDA یا Horizontal Pod Autoscaler با معیارهای سفارشی این امکان را می‌دهند.

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

پایش و انتشار نسخه جدید

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

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

چک‌لیست استقرار مدل زبانی

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

پرسش‌های متداول

آیا می‌توان مدل زبانی را بدون GPU اجرا کرد؟

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

vLLM بهتر است یا Ollama؟

هدفشان متفاوت است. Ollama برای راه‌اندازی سریع و آزمایش روی یک دستگاه مناسب است. vLLM برای سرو هم‌زمان کاربران زیاد در محیط اصلی طراحی شده و معمولاً با همان سخت‌افزار ظرفیت بیشتری می‌دهد.

چطور مدل را بدون قطعی سرویس عوض کنیم؟

نسخه جدید را کنار نسخه فعلی بالا بیاورید، صبر کنید تا Readiness Probe آماده بودنش را تأیید کند، بخشی از ترافیک را به آن بفرستید و پس از اطمینان از معیارها، نسخه قدیم را کنار بگذارید.