پیمایش استقرار مدل‌های زبانی بزرگ: نکات، ترفندها و تکنیک‌ها

آریک: من این ارائه را «پیمایش استقرار مدل‌های زبانی بزرگ (LLM): نکات، ترفندها و تکنیک‌ها نسخه ۲.۰» نامیده‌ام. می‌توانستم نام آن را به «چگونه مدل‌های زبانی بزرگ را مستقر کنیم اگر در متا، OpenAI، گوگل، میسترال یا آنتروپیک کار نمی‌کنید» تغییر دهم. من به طور خاص علاقه‌مندم که چگونه LLMها را مستقر می‌کنید اگر آن را به عنوان یک کسب‌وکار ارائه نمی‌دهید، و به جای آن، آن را سرویس می‌دهید تا بتوانید برنامه‌های کاربردی بر روی آن بسازید، و در نهایت اگر در یک شرکت معمولی کار کنید در مقایسه با یکی از این غول‌ها، آن را به روش‌های کاملاً متفاوتی مستقر می‌کنید.

امیدوارم سه چیز از این جلسه به دست آورید. اولاً، یاد خواهید گرفت که چه زمانی میزبانی شخصی (self-hosting) برای شما مناسب است، زیرا متوجه خواهید شد که می‌تواند کمی دردسرساز باشد و کاری است که فقط باید در صورت نیاز واقعی انجام دهید. درک تفاوت‌های بین استقرارهای شما و استقرارهای آزمایشگاه‌های هوش مصنوعی. سپس، همچنین، من برخی از بهترین شیوه‌ها، نکات، ترفندها، تکنیک‌ها، یک لیست غیرجامع برای نحوه استقرار هوش مصنوعی در محیط‌های شرکتی و سازمانی را ارائه خواهم داد. اساساً، ما زیرساخت برای سرویس‌دهی LLMها می‌سازیم.

اولاً، چه زمانی باید میزبانی شخصی انجام دهید؟ برای توضیح اینکه این چیست، فقط روشن می‌کنم که منظورم از میزبانی شخصی چیست. من میزبانی شخصی را در مقایسه با تعامل با LLMها از طریق یک ارائه‌دهنده API متمایز می‌کنم. این نحوه تعامل شما با LLMها از طریق یک ارائه‌دهنده API است. آنها تمام سرویس‌دهی و میزبانی را برای شما انجام می‌دهند. روی پردازنده‌های گرافیکی (GPU) آنها مستقر می‌شود، نه GPUهای شما. آنها تمام زیرساخت‌های خود را مدیریت می‌کنند و آنچه که ارائه می‌دهند فقط یک API است که می‌توانید با آن تعامل داشته باشید. این همان چیزی است که یک مدل میزبانی‌شده توسط API نامیده می‌شود. همه آن شرکت‌هایی که در ابتدا ذکر کردم این مدل‌ها را برای شما میزبانی می‌کنند. در مقابل، میزبانی شخصی وجود دارد. وقتی شما میزبانی شخصی می‌کنید، کنترل GPUها در دست شماست. شما یک مدل را از Hugging Face یا هرجایی که آن مدل را می‌گیرید، برمی‌دارید و آن را مستقر می‌کنید و به کاربران نهایی خود سرویس می‌دهید. این تفاوت کلی است. اساساً موضوع این است که چه کسی مالک GPUها است و چه کسی مسئول آن زیرساخت سرویس‌دهی است. چرا اصلاً باید بخواهید میزبانی شخصی کنید؟ زیرا وقتی دیگران کارها را برای شما مدیریت می‌کنند، زندگی شما کمی آسان‌تر است.

سه دلیل اصلی وجود دارد که چرا ممکن است بخواهید میزبانی شخصی کنید. اولی کاهش هزینه‌ها است. شما زمانی که شروع به مقیاس‌بندی می‌کنید، هزینه‌ها را کاهش داده‌اید. در مراحل بسیار اولیه اثبات مفهوم (Proof of Concept - PoC) و امتحان کردن چیزها، هزینه‌های کاهش‌یافته‌ای ندارید. در واقع استفاده از یک ارائه‌دهنده API که در آن به ازای هر توکن پرداخت می‌کنید و قیمت هر توکن بسیار پایین است، بسیار ارزان‌تر است. هنگامی که به هر نوع مقیاسی می‌رسید که بتوانید به طور کامل از یک GPU استفاده کنید یا نزدیک به آن، در واقع بسیار مقرون به صرفه‌تر می‌شود. دلیل دوم که چرا ممکن است بخواهید میزبانی شخصی کنید، بهبود عملکرد است. این ممکن است غیرمنطقی به نظر برسد، زیرا در تمام محک‌های (benchmarks) پیشرو، مدل‌های GPT و مدل‌های Claude بهترین در کلاس خود نسبت به آن محک‌ها هستند.

با این حال، اگر دامنه خود و مورد استفاده خاص خود را بشناسید، می‌توانید عملکرد بسیار بهتری هنگام میزبانی شخصی داشته باشید. کمی بعد بیشتر در این مورد صحبت خواهم کرد. این به ویژه برای مدل‌های تعبیه‌سازی (embedding models)، مدل‌های جستجو، مدل‌های رتبه‌بندی مجدد (reranker models) صادق است. پیشرفته‌ترین‌ها برای اکثر آنها در واقع در حوزه متن‌باز هستند، نه در LLMها. اگر بهترین مدل‌ها را می‌خواهید، ترکیبی از میزبانی شخصی برای برخی مدل‌ها و استفاده از ارائه‌دهندگان API برای برخی دیگر خواهید داشت. شما می‌توانید با میزبانی شخصی عملکرد بسیار بهتری کسب کنید. مقداری حریم خصوصی و امنیت. من از اروپا هستم و ما واقعاً به این موضوع اهمیت می‌دهیم. ما همچنین با صنایع تحت نظارت اینجا در ایالات متحده کار می‌کنیم، جایی که دلایل مختلفی وجود دارد که ممکن است بخواهید آن را در محیط خود مستقر کنید. شاید شما یک محیط چند ابری (multi-cloud) دارید، یا شاید هنوز در محل (on-prem) هستید. این با داده‌هایی که a16z جمع‌آوری کرده است مطابقت دارد، که به طور کلی سه دلیل وجود دارد که چرا مردم میزبانی شخصی می‌کنند: کنترل، قابلیت سفارشی‌سازی و هزینه. این چیزی است که بسیاری از مردم به آن فکر می‌کنند.

چگونه بفهمم که آیا در یکی از این دسته‌ها قرار می‌گیرم؟ به طور کلی، اگر به کاهش هزینه اهمیت می‌دهم، این برای من مرتبط است اگر در مقیاس بزرگ مستقر می‌کنم، یا اگر قادر به استفاده از یک مدل تخصصی کوچک‌تر برای کارم هستم به جای یک مدل عمومی بسیار بزرگ مانند GPT-4. اگر به عملکرد اهمیت می‌دهم، اگر در حال اجرای بارهای کاری تعبیه‌سازی یا رتبه‌بندی مجدد هستم، یا اگر در یک دامنه تخصصی فعالیت می‌کنم که ممکن است از تنظیم دقیق (fine-tuning) بهره‌مند شود، عملکرد بهبود یافته‌ای خواهم داشت. یا اگر الزامات وظیفه بسیار مشخصی دارم، اغلب می‌توانم با میزبانی شخصی بهتر عمل کنم، به جای استفاده از این مدل‌های بسیار عمومی.

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

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

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

درک تفاوت بین استقرارهای شما و استقرارها در آزمایشگاه‌های هوش مصنوعی. اگر من، برای مثال، در OpenAI باشم و این مدل‌های زبانی را سرویس می‌دهم، فقط یک مورد استفاده را سرویس نمی‌دهم. من به معنای واقعی کلمه میلیون‌ها مورد استفاده مختلف را سرویس می‌دهم. این بدان معناست که من در نهایت پشته سرویس‌دهی خود را بسیار متفاوت می‌سازم. شما، فرض کنیم من در یک محیط سازمانی یا شرکتی میزبانی می‌کنم. شاید من ۲۰ مورد استفاده را سرویس می‌دهم، مانند یک شرکت بالغ‌تر. شاید الان فقط چند مورد را سرویس می‌دهم. چون این تفاوت را دارم، قادر به اتخاذ تصمیمات طراحی متفاوتی در مورد زیرساختم هستم. در اینجا چند دلیل وجود دارد که چرا رژیم میزبانی شخصی شما بسیار متفاوت از رژیم میزبانی شخصی OpenAI خواهد بود. اول اینکه، آنها تعداد زیادی H100 و پول نقد زیادی دارند.

اکثر شما تعداد زیادی H100 ندارید و احتمالاً آنها را از طریق AWS اجاره می‌کنید. آنها به احتمال زیاد محدود به محاسبات (compute bound) هستند زیرا از GPUهایی مانند H100 استفاده می‌کنند، به جای چیزهایی مانند A10. آنها اطلاعات بسیار کمی در مورد بار کاری (workload) نهایی شما دارند، بنابراین آنها فقط بر اساس این پیش می‌روند که، ما فقط در تلاشیم تا توکن‌ها را برای بارهای کاری دلخواه استریم کنیم. شما اطلاعات بسیار بیشتری در مورد بار کاری خود دارید. آنها برای یک یا دو مدل بهینه‌سازی می‌کنند، که به این معنی است که می‌توانند کارهایی انجام دهند که برای افراد عادی که میزبانی شخصی می‌کنند، مقیاس‌پذیر نیست. اگر من فقط GPT-4 را مستقر می‌کنم، پس قادر به انجام بهینه‌سازی‌های بسیار خاصی هستم که فقط برای آن مدل کار می‌کنند، که در هیچ جای دیگری کار نمی‌کنند.

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

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

بیایید با مرزهای استقرار شروع کنیم. با فرض اینکه شما محاسبات نامحدود ندارید، و حتی آزمایشگاه‌های هوش مصنوعی هم محاسبات نامحدود ندارند. در حال حاضر این یک منبع واقعاً کمیاب است. شما باید بسیار آگاه باشید که الزامات استقرار شما چیست، و سپس از آنچه در مورد آنها می‌دانید به عقب کار کنید. اگر می‌دانید که فقط سخت‌افزار موجود خاصی دارید، شاید شما، برای مثال، فقط محدود به CPU هستید و کاملاً در محل (on-prem) مستقر می‌کنید و GPU ندارید، پس احتمالاً نباید به دنبال استقرار یک Llama ۴ یا ۵ میلیارد پارامتری باشید. دانستن آن مرز از همان ابتدا مهم است. شما باید ایده‌ای از تأخیر (latency) هدف خود نیز داشته باشید. شما باید ایده‌ای از بار مورد انتظار خود داشته باشید.

اگر همه اینها را با هم دارید، و می‌توانید جمله‌ای مانند این بسازید: «من می‌خواهم روی نمونه‌ای ارزان‌تر از x مستقر کنم، که به y کاربر همزمان با میانگین تأخیر کمتر از z سرویس دهد». اگر بتوانید آن جمله را تشکیل دهید، همه کارهای دیگری که باید انجام دهید بسیار آسان‌تر می‌شود، و شما آن گلوگاه را نخواهید داشت که بگویید: «من این برنامه عالی را ساختم. فقط هیچ ایده‌ای ندارم که چگونه آن را مستقر کنم». من می‌توانم از آن اطلاعات برای کار به عقب استفاده کنم و بفهمم چه نوع مدل‌هایی را باید بررسی کنم و چقدر تلاش باید برای چیزهایی مانند مهندسی پرامپت (prompting) و واقعاً اصلاح تکنیک‌های جستجوی خود صرف کنم، به جای ارتقا به مدل‌های بزرگتر.

که مرا به نکته دومم می‌رساند، و آن این است که، شما تقریباً همیشه باید از مدل‌های کوانتیزه‌شده استفاده کنید، به چند دلیل مختلف. اولین دلیلی که می‌گویم شما باید کم و بیش همیشه از مدل‌های کوانتیزه‌شده استفاده کنید این است که دقت تقریباً همیشه بهتر از مدلی با همان نیاز حافظه است که شما آن را به آن اندازه کوانتیزه کرده‌اید، بنابراین شما مقدار زیادی از آن دقت را حفظ می‌کنید. دلیل دوم اینکه تقریباً همیشه باید کوانتیزه کنید این است که در واقع افت دقت آنقدرها با مدل اصلی متفاوت نیست. من به دو تحقیق که این را نشان می‌دهند ارجاع خواهم داد. مقاله‌ای در سال ۲۰۲۳ توسط تیم دتمرز (Tim Dettmers)، از جمله دیگران، که کمی در این زمینه اسطوره است، منتشر شد و نام آن «موردی برای دقت ۴ بیتی» است. آنچه او در این مقاله نشان داد، در واقع، شکل برجسته، این است که برای یک اندازه بیت مدل ثابت، دقت مدل اگر از یک مدل کوانتیزه‌شده استفاده می‌کنید بسیار بالاتر است.

با توجه به اینکه می‌دانیم وقتی مدلی با پارامترهای بیشتر داریم، با افزایش مقیاس پارامترها، دقت مدل بالا می‌رود. آنچه جالب است این است که، اگر من یکی از آن مدل‌های بزرگ را بردارم و آن را به یک اندازه کوچکتر بومی کوانتیزه کنم، مقدار زیادی از آن دقتی که در ابتدا داشتیم را حفظ می‌کند، که بسیار خوب است. من تقریباً همیشه عملکرد بهتری با یک مدل بزرگ کوانتیزه‌شده نسبت به یک مدل کوچک بومی که اندازه حافظه مشابهی دارد، به دست می‌آورم. این تحقیق اول است. تحقیق دومی که به آن ارجاع می‌دهم، در واقع کمی جدیدتر است. این در واقع از یک شرکت ارائه‌دهنده API به نام Together AI است. آنها در مورد این موضوع تحقیق می‌کنند که، آیا باید برای استنتاج خود از FP16 یا INT8 استفاده کنید؟ آنچه آنها در اینجا دریافتند، که واقعاً جالب است، این است که این دو رنگ، بنفش و قرمز، بسیار نزدیک به هم هستند. این تفاوت بین FP16 و INT8 است. در واقع، تفاوت بسیار کمی در دقت بین این دو وجود دارد، که دوباره همان ایده‌ای را که دتمرز سال گذشته به آن رسید، تقویت می‌کند. شما باید کوانتیزه کنید، و تقریباً باید همیشه آن را انجام دهید.

نکته بعدی این است که دسته‌بندی (batching) واقعاً اهمیت دارد. دسته‌بندی، زمانی که به درستی انجام شود، استفاده از GPU شما را افزایش می‌دهد. این کار را با پردازش همزمان چندین درخواست انجام می‌دهد. اگر من فقط یک درخواست را همزمان پردازش کنم، به احتمال زیاد استفاده من از GPU بسیار پایین خواهد بود. اگر بتوانم چندین درخواست را همزمان پردازش کنم، می‌توانم استفاده خود را افزایش دهم. با این حال، یک تبادل وجود دارد، و آن این است که، اگر اندازه دسته (batch size) من بیش از حد بزرگ باشد، با وجود اینکه می‌توانم از GPU خود به طور کامل استفاده کنم، در واقع تأخیر را افزایش می‌دهم، زیرا باید منتظر بمانم تا تمام درخواست‌های آن دسته به پایان برسند. انواع مختلفی از دسته‌بندی وجود دارد. دسته‌بندی ایستا یا ساده وجود دارد. این همان چیزی است که شما به طور سنتی در یک محیط یادگیری ماشین با آن فکر می‌کنید. دسته‌بندی پویا (Dynamic batching) وجود دارد که به عنوان دسته‌بندی پیوسته یا درون پروازی (in-flight batching) نیز شناخته می‌شود. این نوع دسته‌بندی است که باید برای استنتاج LLM استفاده کنید. اساساً دسته‌بندی پویا به جای اینکه منتظر بماند تا تمام درخواست‌ها در یک دسته به پایان برسند، اجازه می‌دهد تا درخواست‌های جدید به محض آزاد شدن ظرفیت در GPU به دسته اضافه شوند. اگر می‌خواهید جزئیات بیشتری در این مورد بدانید، vLLM، که یک پروژه متن‌باز از برکلی است، در واقع یک پست وبلاگ واقعاً خوب در مورد اینکه چرا این مهم است و چگونه می‌توانید به آن دست پیدا کنید، دارد. این همان چیزی است که باید برای اکثر استقرارهای خود هدف قرار دهید.

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

شما باید اندازه دسته را بهینه کنید. من قبلاً در مورد آن صحبت کردم. شما باید آن نقطه بهینه را بین توان عملیاتی (throughput) و تأخیر (latency) پیدا کنید. شما باید از دسته‌بندی پویا استفاده کنید. شما باید الگوریتم‌های رمزگشایی خود را بهینه کنید. آنچه که بیشتر مردم با آن آشنا هستند، نمونه‌گیری حریصانه (greedy sampling) است. الگوریتم‌های بسیار پیچیده‌تر دیگری برای رمزگشایی وجود دارد، مانند نمونه‌گیری هسته‌ای (nucleus sampling) یا جستجوی پرتویی (beam search). برخی از اینها ممکن است برای مورد استفاده شما منطقی‌تر باشند. سپس، در نهایت، باید برای استنتاج حدسی (speculative inference) بهینه‌سازی کنید. استنتاج حدسی، که گاهی اوقات به آن رمزگشایی حدسی نیز گفته می‌شود، راهی است که در آن از یک مدل کوچک‌تر برای حدس زدن توکن بعدی که مدل بزرگ‌تر می‌خواهد تولید کند، استفاده می‌کنید. اگر درست حدس بزند، مدل بزرگ‌تر نیازی به انجام محاسبات ندارد و شما مقداری زمان صرفه‌جویی می‌کنید. اگر اشتباه حدس بزند، مدل بزرگ‌تر باید محاسبات را انجام دهد، اما شما اساساً زمان زیادی از دست نداده‌اید. این یک راه بسیار خوب برای سرعت بخشیدن به استنتاج است و کاری است که ما به طور فزاینده‌ای در صنعت شاهد آن هستیم. مقاله‌ای از گوگل وجود دارد که توضیح می‌دهد چگونه این کار را انجام می‌دهند. اگر به جزئیات فنی آن علاقه‌مند هستید، می‌توانید آن را بررسی کنید.

نکته پنجم این است که در مورد مدل‌هایی که استفاده می‌کنید معقول باشید. این یک دام بسیار رایج است که ما می‌بینیم مردم در آن گرفتار می‌شوند، جایی که می‌گویند، "من می‌خواهم بهترین مدل ممکن را برای این کار داشته باشم". اغلب، بهترین مدل

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

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

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

شرکت‌کننده ۱: ما در حال حاضر در تلاش برای تصمیم‌گیری هستیم که آیا یک مدل بزرگ یا چندین مدل کوچک را برای چندین تیم اتخاذ کنیم. به نظر می‌رسد که مدل‌های کوچک‌تر در هر واحد کسب‌وکار ممکن است هزینه بیشتری داشته باشند، اما ممکن است عملکرد بهتری داشته باشند زیرا خاص دامنه هستند. شما چه فکر می‌کنید؟

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

شرکت‌کننده ۲: شما به بهینه‌سازی برای بار کاری اشاره کردید. ما کارهای زیادی با RAG طولانی‌مدت انجام می‌دهیم. آیا نکات خاصی برای بهینه‌سازی برای آن نوع بار کاری وجود دارد؟

آریک: منظورتان از طولانی‌مدت چیست؟ آیا منظورتان این است که ما یک پنجره زمینه بسیار طولانی داریم، یا زنجیره‌های طولانی پرامپت داریم؟

شرکت‌کننده ۲: زنجیره‌های طولانی پرامپت.

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