هدایت استقرار مدل‌های زبانی بزرگ (Navigating LLM Deployment) به چه معناست؟

نکات کلیدی

• کسب‌وکارها برای سه دلیل اصلی تصمیم می‌گیرند self-host کنند: حریم خصوصی و امنیت، عملکرد بهتر، کاهش هزینه در مقیاس.

• self-host کردن به سه دلیل سخت است: اندازه مدل، GPUهای گران‌قیمت، و حوزه‌ای که به‌سرعت در حال تکامل است.

• برای رسیدگی به اندازه مدل، کوانتیزه (quantize) کنید. برای یک بودجه ثابتِ اندازه مدل، تقریباً همیشه با استفاده از مدل‌های بزرگ‌تر که تا ۴ بیت کوانتیزه شده‌اند عملکرد بهتری می‌گیرید، نسبت به استفاده از نسخه full-precision همان مدل.

• بهینه‌سازی inference با استفاده از batching و parallelism می‌تواند افزایش‌های قابل توجهی در بهره‌وری GPU فراهم کند.

• اپلیکیشن خود را آینده‌نگر کنید با استفاده از abstractionها، ابزارها، و فریم‌ورک‌هایی که با LLMها مثل بلوک‌های سازنده رفتار می‌کنند که به‌راحتی قابل جایگزینی هستند.

وقتی بیشتر مردم به مدل‌های زبانی بزرگ فکر می‌کنند، ممکن است به یکی از مدل‌های OpenAI فکر کنند. این‌ها مدل‌های بزرگ و توانمندی هستند که روی سرورهای OpenAI میزبانی می‌شوند و با استفاده از یک API مبتنی بر وب فراخوانی می‌شوند. این مدل‌های مبتنی بر API راهی هستند برای این‌که سریع با LLMها آزمایش کنید.

با این حال، همچنین برای یک کسب‌وکار ممکن است که LLM خودش را مستقر کند. استقرار، یا self-host کردن، یک LLM چالش‌برانگیز است. این به سادگیِ فراخوانی OpenAI API نیست. اولین سؤالی که ممکن است بپرسید این است: اگر استقرارهای self-hosted LLM این‌قدر سخت هستند، چرا اصلاً زحمتش را بکشیم؟ کسب‌وکارها برای سه دلیل اصلی تصمیم می‌گیرند self-host کنند:

1. حریم خصوصی و امنیت (Privacy & Security): استقرار داخل محیط امنِ خودشان (VPC یا on-premise).

2. عملکرد بهتر (Improved Performance): مدل‌های state-of-the-art برای بسیاری از دامنه‌ها نیاز به self-hosting دارند، به‌خصوص در دامنه (RAG).

3. کاهش هزینه در مقیاس (Decreased Cost at Scale): در حالی که مدل‌های مبتنی بر API ممکن است در ابتدا ارزان به نظر برسند، self-hosting می‌تواند برای استقرارهای در مقیاس بزرگ خیلی مقرون‌به‌صرفه‌تر باشد.

یک گزارش از A16Z آشکار کرد که ۸۲٪ از سازمان‌ها قصد دارند قابلیت‌های self-hosted بسازند. با توجه به این، سؤال بعدی این است: چرا self-hosting این‌قدر سخت است؟ اینجا سه دلیل وجود دارد:

1. اندازه مدل (Model Size): مدل‌های زبانی بزرگ عظیم هستند. یک مدل ۷ میلیارد پارامتر «کوچک» در نظر گرفته می‌شود، اما واقعاً کوچک نیست: ۱۴GB RAM مصرف می‌کند.

2. GPUهای گران‌قیمت (Expensive GPUs): GPUها یک منبع کمیاب و پرهزینه هستند، که بهره‌برداری کارآمد را حیاتی می‌کند.

3. حوزه‌ای که سریع تکامل می‌یابد (Rapidly Evolving Field): این حوزه سریع پیش می‌رود و استقرارهای future-proof را لازم می‌کند.

با توجه به این چالش‌ها، اینجا هفت نکته و ترفند برای توسعه و استقرار اپلیکیشن‌های self-hosted LLM آمده است:

۱. نیازمندی‌های تولید را مشخص کنید و از آن‌جا به عقب برگردید

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

به‌طور مشخص، ما پیشنهاد می‌کنیم مشتریانمان این موارد را ارزیابی کنند:

• نیازمندی‌های latency:
  real-time یا پردازش batch؟

• بار مورد انتظار (Expected Load): سرویس‌دهی به ۱۰ کاربر همزمان یا ۱۰٬۰۰۰ کاربر همزمان؟

• دسترس‌پذیری سخت‌افزار (Hardware Availability): نیازمندی‌های سخت‌افزاری مشخص، به‌خصوص برای استقرارهای on-premise.

وقتی این‌ها به‌خوبی فهمیده شوند، تیم‌ها می‌توانند تصمیم‌های شفاف درباره بهترین راه‌های ساخت با توجه به این محدودیت‌ها بگیرند.

۲. همیشه کوانتیزه کنید (Always quantize)

با توجه به این‌که شما دسترس‌پذیری سخت‌افزار نامحدود ندارید (اکثر کسب‌وکارها ندارند) و شما نیازمندی‌های تولید خواهید داشت (اکثر تیم‌ها دارند)، تقریباً همیشه با استفاده از نسخه‌های کوانتیزه‌شده LLMها نسبت به نسخه‌های کوانتیزه‌نشده بهتر نتیجه می‌گیرید. در مقاله دسامبر ۲۰۲۲ خود با عنوان “The case for 4-bit precision: k-bit Inference Scaling Laws”، Tim Dettmers نشان داد که برای یک اندازه ثابت منابع، تقریباً همیشه با استفاده از مدل‌های بزرگ‌تر که تا ۴ بیت به آن اندازه کوانتیزه شده‌اند عملکرد بهتری می‌گیرید، نسبت به استفاده از نسخه full precision مدل.

شکل ۱. قوانین مقیاس‌گذاری در سطح بیت برای میانگین عملکرد zero-shot در چهار دیتاست برای مدل‌های OPT با ۱۲۵M تا ۱۷۶B پارامتر. عملکرد zero-shot برای بیت‌های ثابت مدل، با کاهش دقت کوانتیزه‌سازی از ۱۶ به ۴ بیت به‌طور پیوسته افزایش می‌یابد. در ۳ بیت، این رابطه معکوس می‌شود، که ۴ بیت را بهینه می‌کند. منبع: Dettmers, The case for 4-bit precision: k-bit Inference Scaling Laws

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

با توجه به این‌که نیازمندی‌های سخت‌افزاری‌تان را مشخص کرده‌اید (نکته ۱ را ببینید)، می‌توانید از آن‌جا به عقب برگردید تا ارزیابی کنید بهترین مدلی که وقتی به ۴ بیت کوانتیزه شود در محدوده‌های شما جا می‌گیرد کدام است. برای پیدا کردن نسخه‌های ۴-بیتی کوانتیزه‌شده از LLMهای محبوب، صفحه TitanML در HuggingFace را بررسی کنید.

۳. زمان بگذارید برای فکر کردن درباره بهینه‌سازی inference

GPUها گران هستند، پس استقرار مدل‌های زبانی self-hosted می‌تواند مثل یک کار فوق‌العاده گران به نظر برسد. با این حال، با کمی تلاش و فکر کردن درباره این‌که چطور inference را بهینه کنید، استقرار می‌تواند خیلی آسان‌تر شود، بهره‌برداری از GPU می‌تواند خیلی بالاتر برود، و هزینه‌های compute خیلی پایین‌تر بیاید. راه‌های زیادی برای بهینه‌سازی inference وجود دارد، اما من فقط دو مثال می‌زنم تا نشان دهم چه اثر بزرگی می‌تواند روی بهره‌برداری GPU داشته باشد.

Batching

استراتژی‌های مختلفی برای batching وجود دارد که می‌توانید هنگام استقرار Generative AI پیاده‌سازی کنید.

ساده‌ترین (naive) راه این است که اصلاً batching نداشته باشید: این همان چیزی است که ما در فریم‌ورک‌های اینترفیس مثل ollama می‌بینیم که برای اپلیکیشن‌های چت‌بات سبک هَکرها بهینه شده‌اند. این به بهره‌برداری افتضاح از GPU منجر می‌شود. با توجه به این‌که می‌خواهید batching را امتحان کنید، خیلی از تیم‌ها dynamic batching را امتحان می‌کنند: این زمانی است که بین درخواست‌ها صبر می‌کنید و آن‌ها را گروهی پردازش می‌کنید؛ با این حال این باعث یک نمودار بهره‌برداری GPU خیلی spike-y می‌شود، که ایده‌آل نیست.

بهترین راه batching برای مدل‌های مولد استفاده از continuous batching است، این اجازه می‌دهد درخواست‌های ورودی درخواست‌های در حال اجرا را قطع کنند تا بهره‌برداری بالا نگه داشته شود، این همان کاری است که ما در inference stack خودمان (Titan Takeoff) انجام می‌دهیم. فقط با پیاده‌سازی یک استراتژی batching متفاوت، بدون هیچ اثر روی مدل، می‌توانیم حدود ۵ برابر بهبود در بهره‌برداری GPU ببینیم، که سپس یک تجربه کاربری خیلی بهتر فراهم می‌کند.

شکل ۳. استراتژی‌های Batching و بهره‌برداری GPU آن‌ها

Parallelism

یک مثال دیگر از این‌که فکر کردن درباره بهینه‌سازی inference چه اثر بزرگی می‌تواند داشته باشد، در استقرارهای چند-GPU (multi-GPU deployments) است. این‌ها وقتی استفاده می‌شوند که یک مدل روی یک GPU منفرد جا نمی‌شود و باید بین چند GPU تقسیم شود.

فرض کنید ما یک مدل ۹۰GB داریم و GPUهایی که فقط ۳۰GB هستند. این مدل در یک GPU جا نمی‌شود اما اگر تقسیم شود، روی ۳ GPU مختلف جا می‌گیرد. دو راه وجود دارد که من مدل را تقسیم کنم. راه ساده (naive) (که در کتابخانه HuggingFace Accelerate استفاده می‌شود) layer splitting است، که مدل را لایه به لایه تقسیم می‌کند.

با این حال، این کار GPU را برای بخش قابل‌توجهی از زمان مداخله بیکار می‌گذارد، که برای بهره‌وری خوب نیست. راه بهتر برای تقسیم مدل‌ها بین GPUها Tensor Parallel است، این همان کاری است که ما در Titan Takeoff انجام می‌دهیم. Tensor Parallel اجازه نمی‌دهد GPU در طول فرایند مداخله بیکار شود.

شکل ۴. استراتژی‌های Parallelism و بهره‌برداری GPU آن‌ها

در فقط همین دو مثالی که ارائه کردم، می‌بینید که افزایش‌های کارایی بسیار قابل‌توجهی فقط با کمی فکر کردن درباره بهینه‌سازی inference و بهره‌برداری GPU به دست می‌آید. پس یا آن زمان را صرف کنید یا با یک inference stack کار کنید که آن زمان را صرف می‌کند تا آن را حل کند.

۴. GenAI از تجمیع زیرساخت (consolidation of infrastructure) سود می‌برد

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

استقرار مدل‌های زبانی open-source سخت است، خیلی سخت‌تر از این‌که فقط با OpenAI API بسازید. پس این باید به‌صورت مرکزی و با ابزارات خوب انجام شود، نه این‌که به تیم‌های ML منفرد واگذار شود تا خودشان مسیر را پیدا کنند. تیم مرکزی می‌تواند یک API شبیه OpenAI برای بقیه شرکت ارائه کند که با آن کار کنند. این نتیجه می‌دهد:

• کاهش هزینه مداخاه به خاطر بهره‌برداری بالاتر از GPU

• توسعه آسان‌تر و سریع‌تر

• اپلیکیشن‌های مقیاس‌پذیرتر

در نتیجه، مهم است که تیم‌ها با یک inference stack کار کنند که به آن اعتماد دارند، که پشتیبانی LoRA adapter دارد و بهره‌برداری خیلی بالایی از GPUها می‌گیرد.

شکل ۵. نمایش استقرار LLMها روی زیرساخت تجمیع‌نشده در برابر تجمیع‌شده

۵. طوری بسازید انگار قرار است مدل خود را در ۱۲ ماه آینده عوض کنید

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

شکل ۶. منبع: Everypixel – انتشار مدل‌های سال ۲۰۲۳

این برای این‌که چطور باید بسازید چه معنایی دارد؟ خب یعنی abstraction خوب است و شما باید با ابزارها و فریم‌ورک بسازید که با LLMها مثل بلوک‌های سازنده رفتار می‌کند که به‌راحتی قابل تعویض هستند.

۶. GPUها گران به نظر می‌رسند، اما بهترین گزینه شما هستند

خیلی وقت‌ها می‌بینیم مشتریان ما نگران قیمت اولیه GPUها هستند، درست هم تشخیص می‌دهند که به ازای هر ساعت به‌طور قابل‌توجهی از CPUها گران‌ترند. با این حال، GPUها انتخاب واضح برای بارهای کاری generative AI هستند به خاطر عملکرد و بهره‌وری برترشان نسبت به CPUها.

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

از طرف دیگر، CPUها برای کارهایی مناسب‌ترند که پردازش ترتیبی لازم دارند. پس با وجود قیمت اولیه بالاتر، قیمت به ازای هر توکن در GPUها به‌طور قابل‌توجهی پایین‌تر از CPUهاست. و بنابراین، با توجه به این‌که بتوانید بهره‌برداری بالای GPU به دست بیاورید، باید همیشه از GPUها برای بارهای کاری AI استفاده کنید.

۷. چه زمانی می‌توانید از مدل‌های کوچک استفاده کنید

مدل‌های بزرگ چشمگیر هستند، اما مدل‌های کوچک‌تر اغلب برای بسیاری از موارد استفاده سازمانی کافی‌اند و استقرارشان آسان‌تر است. مدل‌های غیرمولد یا LLMهای کوچک‌تر مثل Llama3-8B را برای بخش‌هایی از اپلیکیشن‌تان در نظر بگیرید.

نتیجه‌گیری

استقرار LLMها سخت است، اما چالشی است که ارزش مواجهه دارد. self-hosting مزیت‌های بزرگی در حریم خصوصی، عملکرد، و کارایی هزینه دارد، که آن را برای بسیاری از کسب‌وکارها با وجود موانع، یک حرکت هوشمندانه می‌کند.

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

حوزه AI سریع حرکت می‌کند، و چابک و مطلع بودن ضروری است. امیدوارم این نکته‌ها و ترفندها کمک کنند جلوتر از منحنی بمانید و بیشترین بهره را از LLMهای self-hosted ببرید.

با دنبال کردن این شیوه‌ها، می‌توانید اپلیکیشن‌های AI بسازید که نه‌تنها کارآمد و مقرون‌به‌صرفه‌اند، بلکه مقیاس‌پذیر و future-proof نیز هستند. به این شکل، سازمان شما می‌تواند به‌طور کامل از قدرت فناوری LLM بهره‌برداری کند.