هدر دادن هزینه های GPU را متوقف کنید! راهنمای بهینه سازی ترانسفورماتور 3 مرحله ای

صورت‌حساب‌های GPU می‌توانند از انتخاب‌های کوچک در گردش کار Transformer رشد کنند. ممکن است از یک مدل بزرگ استفاده کنم، ورودی‌های بالشتکی ارسال کنم، ریاضیات با دقت کامل را اجرا کنم و GPU را بین درخواست‌ها در انتظار بگذارم. هر انتخاب بدون اینکه همیشه خروجی را بهبود بخشد، هزینه را اضافه می کند. من از سه مرحله عملی برای کاهش ضایعات استفاده می‌کنم و در عین حال کیفیت مدل را بررسی می‌کنم. ## مرحله 1: کاهش بالشتک و کنترل طول توالی ترانسفورماتورها هر توکن را در شکل ورودی پردازش می کنند. اگر یک درخواست 80 توکن و دیگری 900 توکن داشته باشد، اضافه کردن هر دو به 900 توکن باعث می‌شود درخواست کوتاه‌تر از حافظه گرافیکی بیشتری نسبت به نیاز استفاده کند. من درخواست های با طول های مشابه را گروه بندی می کنم و یک محدودیت رمز مفید تعیین می کنم. پایتون از ترانسفورماتور import AutoTokenizer = AutoTokenizer.from_pretrained("bert-base-uncased") batch = tokenizer( texts, padding=True, truncation=True, max_length=512, return_tensors="ptnamic" بهتر از "" padding padding به "" طول ثابت برای طبقه بندی متن، ممکن است محدودیت هایی مانند توکن های 128، 256 و 512 را آزمایش کنم. بهترین تنظیمات به داده ها بستگی دارد. تیم پشتیبانی که پیام‌های کوتاه مشتری را پردازش می‌کند ممکن است به محدودیت 512 توکن نیاز نداشته باشد. یک مدل سند قانونی ممکن است به ورودی‌های طولانی‌تری نیاز داشته باشد، اما همچنان می‌تواند فضای بلااستفاده را از طریق دسته‌بندی مبتنی بر طول حذف کند. من سه عدد را در طول آزمایش دنبال می‌کنم: - میانگین طول ورودی - استفاده از حافظه GPU - کیفیت مدل در یک مجموعه اعتبارسنجی ثابت محدودیت نشانه کمتر می‌تواند هزینه را کاهش دهد، اما ممکن است زمینه مفید را حذف کند. من حد را به عنوان یک انتخاب سنجیده به جای حدس و گمان در نظر می‌گیرم. ## مرحله 2: پس از بررسی خروجی مدل از دقت ترکیبی استفاده کنید بسیاری از GPUهای مدرن می توانند عملیات ترانسفورماتور انتخابی را با FP16 یا BF16 اجرا کنند. این فرمت ها از حافظه کمتری نسبت به FP32 استفاده می کنند و ممکن است توان عملیاتی را بهبود بخشند. برای استنباط با PyTorch، من می‌توانم autocast را به این صورت آزمایش کنم: «مدل مشعل وارداتی پایتون. `` python با torch.no_grad(): با torch.autocast( device_type="cuda", dtype=torch.bfloat16 ): output = model(**batch) ``` من دقت را بدون بررسی نتایج تغییر نمی دهم. من دقت، امتیاز F1، کیفیت پاسخ، نرخ خطا و تأخیر را با خط پایه FP32 مقایسه می‌کنم. یک طبقه‌بندی‌کننده متن ممکن است تقریباً هیچ تغییری در کیفیت پس از انتقال به FP16 نشان ندهد. یک مدل با عملیات عددی حساس ممکن است نیاز به آزمایش بیشتری داشته باشد. سخت افزار نیز مهم است، بنابراین من در طول هر تست نوع GPU و نسخه های نرم افزار را ضبط می کنم. این مرحله زمانی بهترین کار می کند که مدل، تنظیم CUDA و نسخه PyTorch از نوع داده انتخابی پشتیبانی می کنند. ## مرحله 3: GPU را با دسته بندی و استفاده مجدد مشغول نگه دارید. دسته های کوچک ممکن است بخشی از دستگاه را بیکار بگذارند، در حالی که دسته های بسیار بزرگ می توانند باعث فشار حافظه شوند. من اندازه‌های دسته‌ای مانند 4، 8، 16، و 32 را آزمایش می‌کنم. برای هر اندازه، موارد زیر را اندازه‌گیری می‌کنم: - درخواست‌های پردازش‌شده در ثانیه - میانگین زمان پاسخگویی - حداکثر حافظه GPU - مهلت زمانی یا میزان خطا یک سرویس کاربردی ممکن است از یک پنجره دسته‌بندی کوتاه استفاده کند. درخواست هایی که در آن پنجره می رسند در یک دسته گروه بندی می شوند. پنجره باید به اندازه کافی برای زمان پاسخگویی مورد انتظار کوچک بماند. برای متون مکرر، من همچنین از کارهایی که در کش نتایج امن است استفاده مجدد می‌کنم. یک سرویس جستجوی محصول ممکن است بارها برچسب‌های دسته‌بندی مشابه یا درخواست‌های کوتاه را دریافت کند. ذخیره آن نتایج می تواند تماس های مکرر مدل را کاهش دهد. برای مدل‌های زبانی که فقط رمزگشا هستند، حافظه پنهان KV می‌تواند توجه مکرر را در طول تولید توکن کاهش دهد. ابزارهایی مانند vLLM و Hugging Face Text Generation Inference از ویژگی‌هایی پشتیبانی می‌کنند که به مدیریت بارهای کاری تولید کمک می‌کنند. من همچنان استفاده از حافظه و زمان پاسخگویی را روی ترافیک خودم آزمایش می‌کنم زیرا نتایج بر اساس مدل و طول درخواست متفاوت است. یک جدول مانیتورینگ ساده به من کمک می‌کند از تصمیم‌گیری تنها بر اساس استفاده از GPU اجتناب کنم: | تست | اندازه دسته | دقت | توکن ها/درخواست | تأخیر | حافظه GPU | کیفیت | |---|---:|---|---:|---:|---:|---:| | A | 1 | FP32 | 256 | رکورد | رکورد | پایه | | ب | 8 | FP16 | 256 | رکورد | رکورد | مقایسه کنید | | ج | 16 | FP16 | 128 | رکورد | رکورد | مقایسه کنید | من راه اندازی را انتخاب می کنم که با هدف خدمات با کیفیت قابل قبول مطابقت دارد. پایین‌ترین میزان خواندن حافظه، اگر پاسخ‌های کند یا درخواست‌های ناموفق بیشتری ایجاد کند، همیشه بهترین گزینه نیست. درس اصلی ساده است: کاهش توکن های استفاده نشده، تست ریاضی با دقت کمتر و ارسال کار به GPU در دسته های مناسب. من هر بار یک تغییر ایجاد می کنم، همان مجموعه آزمایشی را نگه می دارم و هزینه و کیفیت مدل را با هم مقایسه می کنم. یک برنامه شروع مفید به این صورت است: 1. طول توکن فعلی، تأخیر، استفاده از حافظه و ساعات GPU را اندازه گیری کنید. 2. بالشتک پویا را اضافه کنید و محدودیت توکن کوچکتری را آزمایش کنید. 3. FP16 یا BF16 را در برابر دقت فعلی آزمایش کنید. 4. اندازه های دسته ای را با ترافیک تولیدی آزمایش کنید. 5. تنظیماتی را که استفاده از GPU را کاهش می دهد بدون آسیب رساندن به هدف سرویس حفظ کنید. این مراحل نیاز به آزمایش را برطرف نمی کند. آنها به من یک راه روشن برای پیدا کردن محاسبات هدر رفته قبل از رفتن به یک GPU بزرگتر یا تغییر مدل می دهند.

صورتحساب های GPU می توانند سریعتر از کیفیت مدل رشد کنند. تیم‌هایی را دیده‌ام که کارت‌های بزرگ‌تری را زمانی اضافه می‌کنند که مشکل واقعی حافظه استفاده نشده، توکن‌های بالشتک‌شده یا اندازه دسته‌ای بود که با حجم کار مطابقت نداشت. یک ترانسفورماتور به طور پیش فرض به گران ترین GPU نیاز ندارد. من با سه بررسی شروع می‌کنم: اندازه‌گیری حجم کار، کاهش محاسبات تلف شده، و انتخاب مسیر اجرای کم‌هزینه. ## مرحله 1: اندازه‌گیری کنید که مدل واقعاً از چه چیزی استفاده می‌کند. قبل از جمع‌آوری داده‌های اولیه، GPU را تغییر نمی‌دهم. مسیر: - استفاده از حافظه GPU - استفاده از GPU - رمزهای پردازش شده در هر ثانیه - تاخیر درخواست - اندازه دسته - طول توالی ورودی - زمان صرف شده در بارگیری و پیش پردازش داده ها یک GPU که در استفاده 35٪ باقی می ماند ممکن است به حافظه بیشتر یا کارت جدیدتری نیاز نداشته باشد. این مدل می‌تواند منتظر CPU باشد، درخواست‌ها را یک به یک دریافت کند، یا ورودی‌های پرشده را پردازش کند. برای یک طبقه‌بندی‌کننده مبتنی بر BERT، دو دسته را مقایسه کنید: - 16 متن با 512 نشانه - 16 متن به طولانی‌ترین متن در آن دسته اضافه شده است. دسته دوم ممکن است حاوی نشانه‌های padding بسیار کمتری باشد. سود دقیق به داده، مدل و سخت افزار بستگی دارد، بنابراین من آن را با همان مجموعه تست و الگوی درخواست اندازه گیری می کنم. ابزارهای مفید عبارتند از: bash nvidia-smi ``` برای بارهای کاری PyTorch، حافظه و زمان اجرا را نیز ضبط می کنم: ```python start = torch.cuda.Event(enable_timing=True) end = torch.cuda.Event(enable_timing=True) start.moch):(out) start.moch:(out) model(**inputs) end.record() torch.cuda.synchronize() print(f"{start.elapsed_time(end):.2f}ms") print(torch.cuda.memory_allocated() / 1024**2، "MB") ``` یک اجرا سریع می تواند من را گمراه کند. من از درخواست‌های گرم کردن استفاده می‌کنم و تاخیر متوسط ​​را در چندین اجرا گزارش می‌دهم. ## مرحله 2: حذف توکن های هدر رفته و کارهای غیر ضروری طول توالی تأثیر مستقیمی بر هزینه ترانسفورماتور دارد. ورودی‌های طولانی می‌توانند حافظه را مصرف کنند، حتی زمانی که بیشتر توکن‌ها ارزش کمی اضافه می‌کنند. من از padding پویا استفاده می کنم: ```python tokenizer( texts, padding=True, truncation=True, max_length=256, return_tensors="pt" ) ``` مقدار `max_length` باید از کار گرفته شود. یک طبقه‌بندی کننده بلیط پشتیبانی ممکن است با 128 یا 256 توکن به خوبی کار کند، در حالی که یک مدل سند ممکن است به زمینه بیشتری نیاز داشته باشد. من کیفیت را بعد از هر تغییر آزمایش می‌کنم به جای اینکه فرض کنم ورودی کوتاه‌تر ایمن است. برای استنتاج، حالت ارزیابی را نیز فعال می‌کنم:python model.eval() با torch.inference_mode(): output = model(ورودی‌ها) این کار از ذخیره شدن کارهای مرتبط با آموزش در حین پیش‌بینی جلوگیری می‌کند. دسته بندی نیاز به یک محدودیت عملی دارد. یک دسته بزرگتر می تواند توان عملیاتی را بهبود بخشد، اما ممکن است تاخیر و استفاده از حافظه را افزایش دهد. من چندین اندازه مانند 1، 8، 16 و 32 را آزمایش می کنم، سپس نقطه ای را انتخاب می کنم که با هدف سرویس مناسب باشد. ## مرحله 3: از استنتاج با دقت کمتر با بررسی های کیفیت استفاده کنید بسیاری از کارهای استنتاج Transformer می توانند از FP16 یا BF16 در GPU های پشتیبانی شده استفاده کنند.python با torch.inference_mode(), torch.autocast("cuda", dtype=torch.float16): output = model(ورودی ها) ``` BF16 ممکن است برای سخت افزارهایی که از آن پشتیبانی می کنند مناسب تر باشد، به خصوص زمانی که FP16 مشکلات عددی ایجاد می کند. من مقایسه می کنم: - دقت یا امتیاز F1 - تأخیر میانه و درصد بالا - توکن ها در ثانیه - حداکثر حافظه GPU - موارد خطا Quantization گزینه دیگری برای استنتاج است. یک مدل 8 بیتی یا 4 بیتی می تواند نیاز به حافظه را کاهش دهد، اگرچه نتیجه به کتابخانه، معماری مدل، GPU و حجم کاری بستگی دارد. من مدل کوانتیزه شده را بر روی داده های نماینده قبل از انتقال آن به یک سرویس تأیید می کنم. یک مسیر عملی به این صورت است: 1. مدل و ترافیک فعلی را نمایه کنید. 2. بالشتک را کاهش دهید و یک محدودیت توالی آزمایش شده تعیین کنید. 3. حالت استنتاج را فعال کنید و اندازه دسته را تنظیم کنید. 4. FP16 یا BF16 را تست کنید. 5. کمیت را فقط پس از درک تغییرات قبلی اندازه گیری کنید. درس اصلی من ساده است: هزینه GPU اغلب منعکس کننده اجرای ناکارآمد است تا اندازه مدل به تنهایی. ورودی کوچکتر، دسته بهتر و تنظیم دقت اندازه گیری شده می تواند به ترانسفورماتور کمک کند تا از سخت افزار فعلی خود به طور موثرتری استفاده کند. هنگامی که پس از این بررسی‌ها، حجم کار همچنان از هدف فراتر می‌رود، ارتقای GPU به جای حدس زدن، به یک تصمیم فنی واضح‌تر تبدیل می‌شود.

استنتاج ترانسفورماتور می تواند قبل از اینکه یک محصول کاربران زیادی داشته باشد گران شود. یک مدل ممکن است در آزمایش به خوبی پاسخ دهد، اما زمانی که چندین درخواست با هم می رسند، سرعت خود را کاهش می دهد. حافظه GPU پر می شود، درخواست های طولانی تاخیر را افزایش می دهند و هر توکن تولید شده به صورت حساب اضافه می کند. من دریافته‌ام که استنتاج ترانسفورماتور سریع‌تر و ارزان‌تر معمولاً از سه تغییر عملی ناشی می‌شود: 1. از مدل و دقتی استفاده کنید که با کار مطابقت دارد. 2. دستورات، طول توالی و دسته بندی درخواست را کنترل کنید. 3. مدل را با یک موتور استنتاج که از سخت افزار به خوبی استفاده می کند، اجرا کنید. ترتیب صحیح به سیستم بستگی دارد، اما روند اندازه گیری ثابت می ماند. قبل از تغییر هر چیزی، تأخیر، توکن ها در ثانیه، استفاده از حافظه و هزینه هر درخواست را ثبت کنید. 1. کار مورد نیاز هر درخواست را کاهش دهید یک مدل بزرگ همیشه بهترین مناسب برای یک کار متمرکز نیست. اگر یک ربات پشتیبانی فقط بلیط ها را طبقه بندی کند یا نام محصولات را استخراج کند، یک مدل کوچکتر ممکن است همان نتیجه تجاری را با حافظه کمتر و تاخیر کمتر ارائه دهد. من معمولاً سه سؤال را بررسی می کنم: - آیا کار به تولید پایان باز نیاز دارد؟ - آیا مدل به پنجره زمینه طولانی نیاز دارد؟ - آیا دقت اضافی از یک مدل بزرگتر برای کاربر مفید است؟ برای بسیاری از وظایف طبقه بندی متن، یک مدل رمزگذار فشرده می تواند کافی باشد. برای تولید، یک مدل کوچک‌تر تنظیم‌شده با دستورالعمل ممکن است زمانی کار کند که درخواست واضح باشد و فرمت خروجی محدود باشد. کوانتیزاسیون می تواند تعداد بیت های مورد استفاده برای وزن مدل را کاهش دهد. انتقال از FP16 به INT8 یا فرمت 4 بیتی پشتیبانی شده می تواند استفاده از حافظه را کاهش دهد و درخواست های بیشتری را در یک GPU امکان پذیر کند. اثر بستگی به مدل، سخت افزار، کتابخانه و حجم کاری دارد. برخی از مدل ها کیفیت کمی را از دست می دهند، در حالی که برخی دیگر تغییرات مشهودی را در نوشتن طولانی یا فراخوانی ابزار نشان می دهند. من کوانتیزاسیون را به عنوان یک افزایش سرعت رایگان تلقی نمی کنم. من آن را با همان مجموعه ارزیابی مورد استفاده برای مدل با دقت کامل آزمایش می کنم. من مقایسه می کنم: - دقت کار - کیفیت خروجی - زمان تا اولین نشانه - توکن های تولید شده در ثانیه - استفاده از حافظه GPU - هزینه به ازای هر 1000 درخواست یک مثال عملی یک سیستم پشتیبانی مشتری است که از یک مدل زبان 7B یا 8B برای پاسخ های کوتاه استفاده می کند. این تیم ممکن است نسخه‌های FP16، INT8 و 4 بیتی را روی همان پردازنده گرافیکی آزمایش کند. اگر مدل 4 بیتی کیفیت پاسخ مورد نیاز را حفظ کند و از حافظه کمتری استفاده کند، سیستم ممکن است درخواست‌های همزمان بیشتری را بدون افزودن ماشین دیگری انجام دهد. این نتیجه باید اندازه گیری شود نه اینکه فرض شود. 2. دستورات و دسته ها را تحت کنترل نگه دارید اعلان های طولانی از دو طریق بر استنتاج ترانسفورماتور تأثیر می گذارد. سیستم زمان بیشتری را صرف خواندن ورودی می‌کند و حافظه پنهان کلید-مقدار با پردازش توکن‌های بیشتر توسط مدل افزایش می‌یابد. سابقه چت که در یک رابط کاربری کوچک به نظر می رسد می تواند پس از چرخش های زیاد بزرگ شود. من زمینه های غیر ضروری را با موارد زیر کاهش می دهم: - حذف دستورالعمل های سیستمی مکرر - کوتاه کردن پیام های چت قدیمی - خلاصه کردن بخش های مکالمه قدیمی تر - ارسال فقط اسناد مورد نیاز برای سوال فعلی - تعیین حد مجاز خروجی عملی - اجتناب از مثال های بزرگ زمانی که یک راهنمای قالب کوتاه کار می کند یک اعلان کوتاه تر می تواند تاخیر را بدون تغییر مدل بهبود بخشد. همچنین می‌تواند هزینه‌های توکن ورودی را زمانی که ارائه‌دهنده خدمات صورت‌حساب‌های توکن را انجام می‌دهد، کاهش دهد. دسته بندی یکی دیگر از اهرم های مفید است. یک دسته چندین درخواست را در یک عملیات GPU ترکیب می کند. این می تواند توان عملیاتی را افزایش دهد، به خصوص برای کارهای آفلاین مانند برچسب گذاری اسناد یا تولید جاسازی. برنامه های آنلاین نیاز به مراقبت بیشتری دارند زیرا انتظار برای یک دسته کامل می تواند زمان پاسخگویی را افزایش دهد. برای یک ربات چت زنده، من اندازه‌گیری می‌کنم: - زمان تا اولین توکن - کل زمان پاسخ - درخواست‌ها در هر ثانیه تکمیل می‌شود - زمان انتظار در صف - عملکرد در اندازه‌های دسته‌های مختلف اندازه دسته هشت ممکن است توان عملیاتی را برای یک بار کاری بهبود بخشد و انتظار زیادی را برای دیگری ایجاد کند. بهترین تنظیم معمولاً از طریق یک آزمایش بار کوچک یافت می شود، نه از طریق یک قانون ثابت. دسته‌بندی پویا می‌تواند درخواست‌هایی را که نزدیک به هم می‌رسند گروه‌بندی کند. ابزارهایی مانند vLLM و NVIDIA TensorRT-LLM از روش هایی پشتیبانی می کنند که می توانند استفاده از GPU را برای مدل های پشتیبانی شده بهبود بخشند. پیکربندی هنوز مهم است. یک سرویس باید دارای محدودیت صف، حداکثر زمان انتظار و هدف زمان پاسخگویی باشد. 3. استفاده از زمان اجرای استنتاج متناسب با مدل فراخوانی مدل خام پایتون ممکن است برای آزمایش اولیه مفید باشد. استنتاج تولید اغلب به کنترل بیشتری بر حافظه، زمان‌بندی و هسته‌های GPU نیاز دارد. گزینه‌های رایج عبارتند از: - vLLM برای ارائه درخواست‌های مدل زبانی - TensorRT-LLM برای استقرار GPU NVIDIA - ONNX Runtime برای مدل‌های ترانسفورماتور پشتیبانی شده - Hugging Face Optimum برای صادرات مدل و اجرای خاص سخت‌افزار این ابزارها برای هر مدلی قابل تعویض نیستند. قبل از تغییر زمان اجرا، پشتیبانی مدل، پشتیبانی کوانتیزاسیون، رفتار جریان، ویژگی‌های دسته‌بندی و الزامات استقرار را بررسی می‌کنم. حافظه پنهان کلید-مقدار در تولید اتورگرسیو شایسته توجه است. این مدل داده‌های توجه متوسط ​​را ذخیره می‌کند، بنابراین مکالمه کامل را برای هر نشانه جدید دوباره محاسبه نمی‌کند. این کش سرعت تولید را افزایش می دهد، اما از حافظه استفاده می کند. ورودی‌های طولانی، خروجی‌های طولانی و بسیاری از کاربران همزمان می‌توانند حافظه پنهان را به حد اصلی تبدیل کنند. توجه صفحه‌بندی شده و دسته‌بندی پیوسته می‌تواند به برخی از بارهای کاری کمک کند تا از حافظه پنهان به طور موثرتری استفاده کنند. آنها نیاز به تعیین محدودیت را برطرف نمی کنند. من هنوز حداکثر نشانه‌های ورودی، حداکثر نشانه‌های خروجی و محدوده همزمانی را تعریف می‌کنم که سخت‌افزار بتواند از عهده آن برآید. یک معیار ساده باید از داده‌های تولید مانند استفاده کند: ```مدل متن: همان نقطه بازرسی مورد استفاده برنامه ورودی: اعلان‌های کوتاه، متوسط ​​و طولانی خروجی: حد معمول رمز همزمانی: 1، 4، 8، 16 و موارد بیشتر در صورت نیاز معیارها: تأخیر، توان عملیاتی، حافظه، خطاها و هزینه، بیش از یک بار هر آزمایش را اجرا می‌کنم. درخواست اول ممکن است شامل بارگذاری مدل یا تنظیم حافظه باشد، بنابراین نباید با نتایج حالت پایدار مخلوط شود. یک تیم ممکن است متوجه شود که تغییر زمان اجرا میانگین زمان پاسخگویی را کاهش می دهد، در حالی که تیمی دیگر سود کمی می بیند زیرا مشکل واقعی درخواست های بزرگ است. به همین دلیل است که پروفایل سازی بیش از کپی کردن یک تنظیمات از پروژه دیگر اهمیت دارد. مفیدترین بهینه سازی اغلب کمترین چشمگیر است: درخواست را از 12000 توکن به 3000 کاهش دهید، یک محدودیت خروجی واضح تعیین کنید و ارسال درخواست هایی را که نیازی به تولید ندارند متوقف کنید. پس از آن، کوانتیزاسیون، دسته بندی و موتور استنتاج بهتر می تواند فضای بیشتری را فراهم کند. من استنتاج ترانسفورماتور را به عنوان یک مشکل اندازه گیری در نظر می گیرم. با کوچکترین مدلی که نیازهای کار را برآورده می کند شروع کنید. دستورات را در یک محدوده مفید نگه دارید. دقت تست با داده های ارزیابی واقعی تغییر می کند. دسته بندی را برای هدف پاسخ تنظیم کنید، نه فقط برای حداکثر توان. زمان اجرای سرویس را انتخاب کنید که با مدل و سخت افزار مطابقت داشته باشد. این رویکرد نتیجه یکسانی را برای هر استقرار نوید نمی دهد. این به من یک راه روشن برای یافتن گلوگاه واقعی، استفاده از محاسبات قابل اجتناب کمتر، و بهبود سرعت استنتاج بدون قربانی کردن کیفیت واقعی مورد نیاز کاربران می دهد.

مدل‌های ترانسفورماتور می‌توانند نتایج قوی ارائه دهند، اما زمانی که هر درخواستی از دقت کامل، ورودی‌های طولانی و یک مدل بزرگ استفاده می‌کند، صورتحساب‌های GPU به سرعت افزایش می‌یابند. من دیده ام که تیم ها برای ظرفیت GPU بیکار بیشتر از بارهای کاری فعال هزینه می کنند. خبر خوب این است که بسیاری از صرفه جویی ها از تغییرات مهندسی کوچک به جای بازسازی کامل مدل حاصل می شود. در اینجا سه ​​راه عملی برای کاهش استفاده از GPU و در عین حال تحت کنترل نگه داشتن کیفیت مدل وجود دارد. 1. در جایی که مدل از آن پشتیبانی می‌کند از دقت ترکیبی استفاده کنید بسیاری از بارهای کاری ترانسفورماتور برای استفاده از اعداد ممیز شناور 32 بیتی به هر محاسباتی نیاز ندارند. دقت مختلط به عملیات انتخاب شده اجازه می دهد تا با FP16 یا BF16 اجرا شود و در عین حال محاسبات حساس را با دقت ایمن تر حفظ کند. این می تواند استفاده از حافظه را کاهش دهد و توان پردازش گرافیکی هایی که از این فرمت ها پشتیبانی می کنند را بهبود بخشد. استفاده کمتر از حافظه همچنین ممکن است به اندازه دسته بزرگتر اجازه دهد، که به GPU کمک می کند تا درخواست های بیشتری را در طول هر اجرا پردازش کند. یک مثال اصلی PyTorch به این صورت است: python with torch.autocast(device_type="cuda", dtype=torch.float16): outputs = model(**ورودی ها) برای GPU های جدیدتر مرکز داده، BF16 می تواند گزینه مفیدی باشد: python with torch.autocast, dtype=torch.bfloat16): خروجی ها = مدل(**ورودی ها) قبل از انتقال دقت ترکیبی به تولید، مدل را روی یک مجموعه اعتبارسنجی کوچک آزمایش می کنم. دقت، کیفیت پاسخ، مقادیر تلفات و نرخ خطا را بررسی کنید. برخی از مدل ها با FP16 یا BF16 با کمی تغییر کار می کنند. مدل‌های دیگر ممکن است خروجی‌های ناپایدار را به‌ویژه در حین تمرین نشان دهند. یک فرآیند آزمایش مفید ساده است: - مجموعه ثابتی از نمونه های ارزیابی را با دقت کامل اجرا کنید. - همان نمونه ها را با دقت ترکیبی اجرا کنید. - کیفیت و تأخیر را مقایسه کنید. - مراقب سرریز، مقادیر «NaN» یا تغییرات در متن تولید شده باشید. - قالبی را که با هدف محصول شما مطابقت دارد حفظ کنید. دقت مختلط اغلب نقطه شروع کم خطری است زیرا روش انجام محاسبات را بدون تغییر در معماری مدل تغییر می دهد. 2. توکن‌های هدر رفته را کاهش دهید و دسته‌بندی را بهبود ببخشید یک ترانسفورماتور محاسباتی را روی توکن‌ها خرج می‌کند. درخواست‌های طولانی، دستورالعمل‌های مکرر، بالشتک‌ها و فضای خروجی استفاده نشده، همگی حجم کار را افزایش می‌دهند. من اغلب با اندازه‌گیری چهار مقدار شروع می‌کنم: - میانگین طول ورودی - میانگین طول خروجی - درصد توکن‌های پرشده - درخواست‌های پردازش شده در هر دسته این داده‌ها می‌تواند یک مشکل ساده را آشکار کند. برای مثال، یک ربات چت پشتیبانی ممکن است محدودیت 4096 توکن را بپذیرد، حتی اگر بیشتر مکالمات از کمتر از 900 توکن استفاده کنند. ظرفیت استفاده نشده همچنان بر برنامه ریزی حافظه تأثیر می گذارد و می تواند تعداد درخواست هایی را که یک GPU با هم انجام می دهد محدود کند. چندین تغییر می تواند به شما کمک کند: محتوای درخواستی مکرر را برش دهید. دستورالعمل های سیستم را متمرکز نگه دارید. هنگامی که برنامه فقط می تواند بخش های مربوطه را بازیابی کند، مواد مرجع پایدار را در خارج از اعلان ذخیره کنید. ** درخواست‌ها را بر اساس طول گروه‌بندی کنید. ** یک دسته شامل یک درخواست 2000 توکن و چندین درخواست 200 توکن ممکن است مقدار زیادی padding ایجاد کند. سطل کردن درخواست ها با طول مشابه می تواند استفاده از GPU را بهبود بخشد. محدودیت های خروجی را بر اساس وظیفه تنظیم کنید. یک پاسخ طبقه بندی کوتاه به محدودیت تولید یک ابزار گزارش نویسی نیاز ندارد. از دسته بندی پویا برای استنتاج استفاده کنید. یک صف درخواست می تواند درخواست های نزدیک را جمع آوری کرده و به صورت یک دسته به مدل ارسال کند. پنجره دسته ای باید در محدوده هدف تأخیر شما باقی بماند. برای مثال، تیمی که طبقه‌بندی متن را ارائه می‌کند ممکن است متوجه شود که درخواست‌ها در فواصل زمانی ناهموار می‌رسند. اجرای هر درخواست به تنهایی بخشی از GPU را بدون استفاده می گذارد. یک دسته پویا کوچک می تواند توان عملیاتی را بدون تغییر مدل افزایش دهد. تنظیم مناسب به ترافیک بستگی دارد. دسته های بزرگتر می توانند توان عملیاتی را بهبود بخشند، اما ممکن است زمان انتظار و استفاده از حافظه را افزایش دهند. من به جای بهینه سازی یک عدد، هزینه هر درخواست و تأخیر پاسخ را اندازه می‌گیرم. 3. کوانتیزاسیون را اعمال کنید یا از یک مدل کوچکتر برای کار مناسب استفاده کنید کوانتیشن وزن های مدل را با بیت های کمتر ذخیره می کند. بسته به سخت افزار، پشته نرم افزار و هدف کیفیت، مدلی که از وزن های 16 بیتی استفاده می کند، ممکن است برای استنتاج به فرمت های 8 بیتی یا 4 بیتی تبدیل شود. گزینه های رایج عبارتند از: - کوانتیزه کردن وزن 8 بیتی برای تعادل بین استفاده از حافظه و کیفیت - کمی سازی 4 بیتی زمانی که فشار حافظه زیاد است - کمی سازی فقط وزنی برای بارهای کاری استنتاج انتخاب شده - تقطیر دانش برای آموزش مدل کوچکتر از مدل بزرگتر. این سرعت یا کیفیت خروجی یکسان را در هر راه اندازی تضمین نمی کند، بنابراین آزمایش اهمیت دارد. من مدل های اصلی و کوانتیزه شده را بر روی داده هایی که درخواست های واقعی کاربر را منعکس می کند، مقایسه می کنم. برای مدل پشتیبانی مشتری، مجموعه آزمایشی باید شامل سوالات کوتاه، مکالمات طولانی، نام محصول، اشتباهات املایی و درخواست‌هایی باشد که نیاز به رد یا تشدید دقیق دارند. ردیابی: - دقت کار - نمرات بررسی انسانی - تاخیر پاسخ - استفاده از حافظه GPU - نرخ خطا و بازگشت - هزینه به ازای هر 1000 درخواست یک مدل کوچکتر ممکن است انتخاب بهتری برای کارهای ساده ای مانند تشخیص قصد، تجزیه و تحلیل احساسات، یا مسیریابی سند باشد. یک مدل بزرگ می تواند برای موارد پیچیده در دسترس باقی بماند. این رویکرد مسیریابی مدل مانع از استفاده هر درخواستی از گران ترین گزینه می شود. من یک مدل را فقط به این دلیل فشرده نمی کنم که ردپای حافظه آن بزرگ به نظر می رسد. اگر کیفیت کاهش یابد، پشتیبانی اضافی و درخواست‌های ناموفق می‌توانند پس‌انداز مورد انتظار را حذف کنند. کنترل هزینه GPU به عنوان یک فرآیند اندازه گیری بهترین عملکرد را دارد. با دقت ترکیبی شروع کنید، توکن‌های غیر ضروری را حذف کنید، دسته‌بندی را بهبود ببخشید، سپس کوانتیزاسیون یا مسیریابی مدل را آزمایش کنید. در هر مرحله یک بررسی کیفیت داشته باشید. صورتحساب کمتر تنها زمانی مفید است که سرویس همچنان نیازهای کاربران خود را برآورده کند. یک معیار کوچک می‌تواند تصمیم را راهنمایی کند: «متن فرمت مدل: حافظه گرافیکی FP32: 18 گیگابایت تأخیر: 210 میلی‌ثانیه امتیاز کیفیت: 92 فرمت مدل: حافظه GPU BF16: 11 گیگابایت تأخیر: 145 میلی‌ثانیه امتیاز کیفیت: 91 قالب مدل: امتیاز مدل: 8 بیت امتیاز کارت گرافیک: 8 گیگابایت «حافظه گرافیکی Latms: 01» این ارقام نمونه هستند، نه یک وعده برای هر مدل. نیازهای ترافیک، سخت افزار، طول سریع و کیفیت شما نتیجه را تعیین می کند.

مدل‌های ترانسفورماتور می‌توانند مدت‌ها قبل از اینکه GPU به حد کامل محاسباتی خود برسد گران شوند. ترافیک حافظه، توالی های ورودی طولانی، بارگذاری مکرر مدل و دسته بندی ضعیف اغلب گلوگاه واقعی را ایجاد می کنند. من تیم‌هایی را دیده‌ام که وقتی یک تغییر کوچک‌تر می‌توانست فشار یکسانی را کاهش دهد، سخت‌افزار اضافه می‌کنند: ورودی‌های کوتاه‌تر، دقت کمتر، حافظه پنهان بهتر، یا تنظیم سرویس تمیزتر. هدف حذف هر لایه یا فشار دادن هر تنظیم به کمترین مقدار آن نیست. هدف این است که پیدا کنید مدل زمان و حافظه خود را کجا صرف می کند، سپس این هزینه را بدون آسیب رساندن به کیفیت خروجی مورد نیاز کاربران کاهش دهید. ** حجم کار فعلی را اندازه گیری کنید ** من با یک مجموعه تست کوچک شروع می کنم که منعکس کننده استفاده واقعی است. باید شامل درخواست‌های کوتاه و طولانی، اعلان‌های رایج، نرخ‌های اوج درخواست و طول خروجی معمولی مدل باشد. من ثبت می کنم: - میانگین و تاخیر p95 - توکن های پردازش شده در هر ثانیه - استفاده از حافظه GPU - تعداد توکن های ورودی و خروجی - اندازه دسته - نرخ خطا - کیفیت خروجی در یک مجموعه ارزیابی ثابت این مرحله از حدس و گمان جلوگیری می کند. یک مدل ممکن است استفاده کم محاسباتی را در حین انتظار برای دسترسی به حافظه نشان دهد. مدل دیگری ممکن است از بیشتر پردازنده گرافیکی استفاده کند زیرا طول توالی بیش از حد بزرگ است. اصلاح متفاوت خواهد بود. یک نمایه ساده می‌تواند نشان دهد که آیا هزینه اصلی از این موارد ناشی می‌شود: - ضرب ماتریس - توجه به دنباله‌های طولانی - رشد حافظه پنهان کلید-مقدار - انتقال داده بین CPU و GPU - توکن‌سازی - بارگذاری مدل - دسته‌های کوچک من شرایط آزمایش را ثابت نگه می‌دارم در حالی که یک تنظیم را تغییر می‌دهم. این باعث می شود که به نتیجه راحت تر اعتماد کنید. کاهش هدر رفت توکن هر نشانه ورودی حافظه و زمان پردازش را مصرف می کند. بسیاری از برنامه ها دستورالعمل های مکرر، سابقه چت طولانی، بخش های سند استفاده نشده یا ابرداده های تکراری را ارسال می کنند. من درخواست کامل را قبل از رسیدن به مدل بررسی می‌کنم: - متن مکرر سیستم را در جایی که طراحی ارائه می‌دهد حذف می‌کند - برش نوبت‌های مکالمه قدیمی - ذخیره اسناد طولانی خارج از درخواست و بازیابی فقط بخش‌های مفید - حذف فیلدهای خالی و قالب‌بندی مکرر - تنظیم یک حد خروجی عملی - استفاده از یک الگوی درخواست کوچک‌تر یک دستیار پشتیبانی ممکن است یک سوال 12000 دانشی را دریافت کند که به یک صفحه تا 80 پاسخ نیاز دارد. بازیابی می تواند ورودی را کاهش دهد در حالی که قسمت های مربوطه را حفظ می کند. این تغییر اغلب هزینه کمتری نسبت به جراحی مدل دارد. همچنین از افت کیفیت ناشی از فشرده سازی تهاجمی جلوگیری می کند. از دقت کمتری استفاده کنید بسیاری از مدل های ترانسفورماتور با وزنه های 16 بیتی آموزش دیده یا ارائه می شوند. فرمت‌های با دقت پایین‌تر می‌توانند استفاده از حافظه را کاهش دهند و ممکن است عملکرد سخت‌افزاری را که از آن‌ها پشتیبانی می‌کنند، بهبود بخشند. انتخاب‌های متداول عبارتند از: - FP16 یا BF16 برای پشتیبانی گسترده - INT8 برای وزن یا کوانتیشن فعال - INT4 برای استفاده کمتر از حافظه - GPTQ یا AWQ برای برخی از مدل‌های زبان بزرگ، کمی‌سازی نحوه ذخیره مقادیر مدل را تغییر می‌دهد. یک نمایش کوچکتر می تواند ترافیک حافظه را کاهش دهد، اما تأثیر آن به مدل، سخت افزار، زمان اجرا و حجم کار بستگی دارد. من نسخه های کوانتیزه شده را در برابر همان مجموعه ارزیابی آزمایش می کنم. من پاسخ‌های واقعی، دقت طبقه‌بندی، خروجی کد، رفتار امتناع و سبک پاسخ را بررسی می‌کنم که این ویژگی‌ها برای محصول مهم باشند. یک الگوی مفید این است که لایه‌های حساس را با دقت بالاتر در حالی که لایه‌های دیگر را کوانتیزه می‌کنید، نگه دارید. لایه‌های جاسازی شده، سرهای خروجی و بلوک‌های توجه ممکن است واکنش متفاوتی نشان دهند. بهترین تنظیم اغلب یک مصالحه اندازه گیری شده است تا کمترین عرض بیت موجود. کتابخانه هایی مانند bitsandbytes، llama.cpp، TensorRT-LLM، و ONNX Runtime مسیرهای کوانتیزاسیون متفاوتی را ارائه می دهند. نتایج آنها قابل تعویض نیستند، بنابراین من زمان اجرای دقیق مورد استفاده در تولید را معیار قرار می دهم. کارهایی را که بر نتیجه تأثیر نمی گذارند حذف کنید هرس وزن ها یا ساختارهای انتخاب شده در شبکه را کاهش می دهد. هرس بدون ساختار می تواند مقادیر صفر زیادی ایجاد کند، اما سخت افزار ممکن است از آنها به طور موثر استفاده نکند. هرس ساختاری کانال‌ها، سرها یا بلوک‌های کامل را حذف می‌کند و می‌تواند برای یک زمان اجرا آسان‌تر باشد. فرآیند به این صورت است: 1. یک خط پایه کیفیت ایجاد کنید. 2. لایه ها یا سرهای با ضربه کم را شناسایی کنید. 3. یک سطح هرس کوچک اعمال کنید. 4. در صورت نیاز تنظیم دقیق کنید. 5. کیفیت، تأخیر و حافظه را دوباره اندازه گیری کنید. 6. تغییر را فقط زمانی نگه دارید که پشته سرو بتواند از آن استفاده کند. هرس به طور خودکار یک بهبود سرعت نیست. اگر هسته با ماتریس متراکم برخورد کند، یک مدل با وزن‌های صفر زیاد ممکن است با همان سرعت اجرا شود. تغییرات ساختاری مسیر روشن تری برای محاسبه کمتر دارند، اما می توانند باعث کاهش کیفیت بیشتر شوند. تقطیر مدل برای کارهای معمول تقطیر دانش یک مدل دانش آموز کوچکتر را برای مطابقت با معلم بزرگتر آموزش می دهد. این کار زمانی به خوبی کار می‌کند که کار دارای محدوده روشنی باشد، مانند طبقه‌بندی احساسات، تشخیص قصد، برچسب‌گذاری سند یا پشتیبانی کوتاه پاسخ. به عنوان مثال، DistilBERT به عنوان یک نسخه کوچکتر از BERT از طریق تقطیر و روش های آموزشی مرتبط ایجاد شد. تیمی که فقط به طبقه بندی بلیط نیاز دارد ممکن است برای هر درخواست نیازی به یک مدل زبان عمومی بزرگ نداشته باشد. من دانش آموز را حول تکلیف واقعی تعریف می کنم: - چه ورودی هایی دریافت می کند؟ - چه برچسب ها یا خروجی هایی تولید می کند؟ - کدام خطاها پرهزینه هستند؟ - چقدر زمینه نیاز دارد؟ - آیا به نسل باز نیاز دارد؟ یک مدل کوچکتر می تواند در همان GPU سریعتر و ارزانتر باشد. ممکن است در مورد استدلال گسترده یا درخواست‌های غیرعادی با معلم مطابقت نداشته باشد، بنابراین من فقط وظایف مناسب را به آن هدایت می‌کنم. یک طراحی عملی از یک مدل کوچک برای درخواست های مشترک و باریک استفاده می کند و موارد نامشخص را به یک مدل بزرگتر ارسال می کند. قانون مسیریابی باید با نمونه های ترافیک واقعی آزمایش شود نه اینکه تنها بر اساس اندازه مدل باشد. بچینگ را بهبود ببخشید ارائه یک درخواست در یک زمان باعث می شود سخت افزار زمانی که درخواست ها نزدیک به یکدیگر می رسند بیکار می شوند. دسته بندی کار را در یک مرحله اجرا ترکیب می کند. بچینگ استاتیک منتظر یک گروه ثابت است. دسته‌بندی پویا درخواست‌های یک پنجره کوتاه را جمع‌آوری می‌کند. دسته‌بندی مداوم گروه را با اتمام دنباله‌ها به‌روزرسانی می‌کند، که می‌تواند برای تولید متن به خوبی کار کند. این مبادله به راحتی از دست می رود. یک پنجره انتظار طولانی‌تر ممکن است با افزایش تأخیر پاسخ، توان عملیاتی را بهبود بخشد. من حداکثر زمان انتظار را تنظیم کردم و هر دو مقدار را اندازه گرفتم. من همچنین زمانی که شکل آنها متفاوت است، بارهای کاری را جدا می کنم. دسته‌ای که حاوی یک فرمان بسیار طولانی و بسیاری از اعلان‌های کوتاه است، می‌تواند حافظه را هدر دهد و درخواست‌های کوتاه را به تأخیر بیندازد. گروه بندی درخواست ها بر اساس طول تقریبی ورودی می تواند عملکرد ثابت تری ایجاد کند. ابزارهای ارائه‌دهنده مانند vLLM، TensorRT-LLM، و Hugging Face TGI از استراتژی‌های مختلف Batching و Cache پشتیبانی می‌کنند. انتخاب مناسب به معماری مدل و تولید GPU بستگی دارد. مدیریت حافظه نهان کلید-مقدار تولید خودروگرسیو وضعیت های کلیدی و ارزشی را از توکن های قبلی ذخیره می کند. این حافظه نهان از محاسبه مجدد تاریخچه کامل برای هر توکن جدید توسط مدل جلوگیری می کند، اگرچه با طول زمینه، تعداد لایه ها و اندازه دسته ای رشد می کند. من رشد حافظه پنهان را با این موارد کنترل می‌کنم: - تنظیم محدودیت زمینه که مطابق با نیازهای محصول باشد - محدود کردن حداکثر نشانه‌های خروجی - استفاده مجدد از پیشوند مشترک در زمانی که زمان اجرا از آن پشتیبانی می‌کند - حذف سابقه چت قدیمی - استفاده از توجه صفحه‌شده یا مدیریت حافظه مشابه - آزمایش دقت حافظه پنهان در جایی که مکالمات طولانی پشتیبانی می‌توانند حافظه بیشتری نسبت به وزن مدل مصرف کنند. مدلی که در طول یک آزمایش کوتاه مناسب است ممکن است زمانی که چندین کاربر همزمان تاریخچه های طولانی را ارسال می کنند شکست بخورد. زمانی که بسیاری از درخواست‌ها از یک فرمان سیستمی یا پیشوند سند استفاده می‌کنند، ذخیره پیشوند می‌تواند کمک کند. مزیت بستگی به این دارد که آن پیشوند چند بار تکرار شود و زمان اجرا چگونه آن را ذخیره می کند. از توجه و هسته های بهینه استفاده کنید عملکرد توجه به طول دنباله و جزئیات پیاده سازی بستگی دارد. هسته هایی مانند FlashAttention با تغییر نحوه محاسبه و ذخیره توجه، حرکات غیرضروری حافظه را کاهش می دهند. خروجی مدل طوری طراحی شده است که نزدیک به توجه استاندارد باشد، اما پشتیبانی دقیق بسته به معماری و پشته نرم افزار متفاوت است. ابزارهای کامپایلر می توانند چندین عملیات را در یک هسته ترکیب کنند. ویژگی‌های کامپایل ONNX Runtime، TensorRT و PyTorch ممکن است سربار راه‌اندازی را برای بارهای کاری پایدار کاهش دهند. من از فعال کردن هر بهینه سازی به یکباره اجتناب می کنم. یک تغییر هسته می تواند یک شکل ورودی را بهبود بخشد و در دیگری عملکرد ضعیفی داشته باشد. من اعلان های کوتاه، اعلان های طولانی، دسته های کوچک و سطح همزمانی استفاده شده توسط برنامه را آزمایش می کنم. در صورت امکان مدل را روی دستگاه نگه دارید حرکت تانسورها بین CPU و GPU باعث ایجاد تاخیر می شود. نقل و انتقالات مکرر می تواند ارزش یک مدل کوچکتر را حذف کند. بررسی می‌کنم: - جایی که وزن‌های مدل بارگیری می‌شوند - جایی که توکن‌سازی اجرا می‌شود - جایی که ورودی‌ها کپی می‌شوند - اینکه آیا تانسورهای میانی در دستگاه‌ها حرکت می‌کنند - آیا چارچوب مجدداً بارگیری می‌شود یا مجدداً حافظه را تخصیص می‌دهد - اینکه آیا چندین فرآیند برای تخلیه CPU واحد پردازشگر گرافیکی رقابت می‌کنند می‌تواند به یک مدل کمک کند تا در حافظه جا بیفتد، اما ممکن است سرعت پاسخ را کاهش دهد. باید به عنوان یک گزینه ظرفیت در نظر گرفته شود، نه یک اصلاح عملکرد تضمین شده. بارگذاری مدل نیز مهم است. سرویسی که وزن را برای هر درخواست بارگیری می کند، قبل از شروع تولید، هزینه زیادی می پردازد. گرم نگه داشتن کارگر می تواند از انجام کارهای مکرر جلوگیری کند، در حالی که محدودیت های حافظه هنوز نیاز به نظارت دارند. کوچکترین مدلی را انتخاب کنید که با هدف مطابقت دارد اندازه مدل تنها بخشی از تصمیم است. یک مدل بزرگتر با کوانتیزاسیون و دسته بندی خوب ممکن است نسبت به یک مدل کوچکتر با کنترل ورودی ضعیف، حجم کاری را راحت تر انجام دهد. یک مدل کوچک ممکن است اغلب شکست بخورد و کار بررسی اضافی ایجاد کند. من مدل‌های کاندید را با استفاده از موارد مشابه مقایسه می‌کنم: - اعلان‌های ارزیابی - محدوده طول ورودی - محدودیت طول خروجی - سخت‌افزار - زمان اجرا - خط‌مشی دسته‌ای - آستانه کیفیت برای طبقه‌بندی‌کننده پشتیبانی مشتری، دقت و دسته‌های خطا ممکن است بیشتر از تسلط بدون پایان مهم باشند. برای یک دستیار کدنویسی، اعتبار نحو و نتایج آزمون ممکن است بیشتر از میانگین زمان پاسخ کوتاه باشد. یک مسیر عرضه عملی من از این دستور برای اکثر پروژه ها استفاده می کنم: 1. نمایه سیستم فعلی. 2. ژتون های تکراری و غیر ضروری را برش دهید. 3. محدودیت های ورودی و خروجی معقولی را تعیین کنید. 4. دسته بندی مناسب را فعال کنید. 5. گزینه های FP16، BF16، INT8 یا INT4 را آزمایش کنید. 6. توجه بهینه شده یا هسته های کامپایل شده را اضافه کنید. 7. استفاده از حافظه پنهان و انتقال دستگاه را بررسی کنید. 8. یک مدل کوچکتر یا مقطر را تست کنید. 9. هرس را فقط زمانی اضافه کنید که زمان اجرا بتواند از آن استفاده کند. 10. نظارت بر کیفیت و تأخیر پس از استقرار. این دنباله با تغییراتی شروع می شود که به راحتی قابل برگشت هستند. همچنین به تفکیک ضایعات نرم افزار از اندازه مدل کمک می کند. یک تیم همیشه به GPU دیگری نیاز ندارد تا مدل ترانسفورماتور را به خوبی ارائه کند. مسیر بهتر ممکن است یک پیام کوتاه تر، یک نقطه بازرسی کوانتیزه، یک مدل دانشجویی کوچکتر یا یک لایه سرویس دهی باشد که GPU را مشغول نگه می دارد. من هر تغییر را به‌عنوان یک آزمایش اندازه‌گیری شده در نظر می‌گیرم: هدف کیفیت مورد نظر کاربر را ثابت نگه دارید، یک محرک هزینه را تغییر دهید و نتیجه را با حجم کاری مشابه مقایسه کنید. برای هرگونه سوال در مورد محتوای این مقاله، لطفا با امی وو تماس بگیرید: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

واسوانی، آشیش و همکاران. 2017، توجه همه آن چیزی است که شما نیاز دارید Micikevicius, Paulius, et al. 2018، Mixed Precision Training Sanh، ویکتور، و همکاران. 2019، DistilBERT: نسخه مقطر BERT Frantar، Elias، و همکاران. 2022، GPTQ: کمی سازی دقیق پس از آموزش برای ترانسفورماتورهای از پیش آموزش دیده مولد Dao، Tri، و همکاران. 2022، FlashAttention: توجه دقیق سریع و کارآمد با IO-Awareness Kwon، Woosuk، و همکاران. 2023، مدیریت حافظه کارآمد برای ارائه مدل زبان بزرگ با PagedAttention