Как да оптимизираме AI модели

Кратък отговор: За да оптимизирате моделите с изкуствен интелект, изберете едно основно ограничение (латентност, цена, памет, качество, стабилност или пропускателна способност), след което определете надеждна базова линия, преди да промените каквото и да било. Първо премахнете пречките в конвейера, след това приложете нискорискови подобрения, като смесена прецизност и пакетна обработка; ако качеството се запази, преминете към инструменти за компилиране/изпълнение и едва след това намалете размера на модела чрез квантуване или дестилация, когато е необходимо.

Ключови изводи:

Ограничение: Изберете една или две целеви показатели; оптимизацията е пейзаж от компромиси, а не безплатни победи.

Измерване: Профилирайте реални натоварвания с p50/p95/p99, пропускателна способност, използване и пикове на паметта.

Тръбопровод: Поправете токенизацията, зареждащите устройства за данни, предварителната обработка и пакетирането, преди да докоснете модела.

Обслужване: Използвайте кеширане, целенасочено пакетиране, настройване на паралелизъм и следете внимателно латентността на опашката.

Предпазни парапети: Изпълнявайте златни подкани, показатели за задачи и проверки на място след всяка промяна в производителността.

🔗 Как да оценяваме ефективно модели с изкуствен интелект
Ключови критерии и стъпки за справедлива и надеждна оценка на моделите.

🔗 Как да измерите производителността на ИИ с реални показатели
Използвайте бенчмаркове, латентност, цена и сигнали за качество, за да сравните.

🔗 Как да тестваме AI модели преди производство
Практически работен процес на тестване: разделяне на данни, стресови сценарии и мониторинг.

🔗 Как да използвате изкуствен интелект за създаване на съдържание
Превърнете идеите в чернови по-бързо със структурирани подкани и итерации.

---

1) Какво означава „Оптимизиране“ на практика (защото всеки го използва по различен начин) 🧠

Когато хората казват „оптимизиране на модел на изкуствен интелект“, те може да имат предвид:

• Направете го по-бързо (по-ниска латентност)

• Направете го по-евтино (по-малко часове работа на графичния процесор, по-ниски разходи за облак)

• Направете го по-малък (заемане на памет, внедряване на периферия)

• Направете го по-точно (подобряване на качеството, по-малко халюцинации)

• Направете го по-стабилно (по-малко вариации, по-малко повреди в производството)

• Улесняване на обслужването (производителност, пакетиране, предвидима производителност)

Ето леко досадната истина: не можете да увеличите максимално всички тези неща наведнъж. Оптимизацията е като стискане на балон - натиснете едната страна навътре и другата страна изскача. Не винаги, но достатъчно често, за да планирате компромиси.

Така че, преди да докоснете каквото и да било, изберете основното си ограничение:

• Ако обслужвате потребители на живо, ви интересува латентността на p95 (персентили на AWS CloudWatch) и производителността на опашката (най-добра практика за „латентност на опашката“) 📉

• Ако тренирате, ви е важно времето за постигане на качество и използването на графичния процесор 🔥

• Ако внедрявате на устройства, ви е грижа за RAM паметта и захранването 🔋

---

2) Как изглежда една добра версия на оптимизация на AI модели ✅

Една добра версия на оптимизация не е просто „приложи квантуване и се моли“. Тя е система. Най-добрите настройки обикновено имат:

• Базова линия, на която имате доверие.
  Ако не можете да възпроизведете текущите си резултати, няма да знаете, че сте подобрили нещо. Просто е... но хората го пропускат. После се въртят в спирала.

• Ясният целеви показател
  „По-бързо“ е неясен. „Намаляване на латентността на p95 от 900 ms на 300 ms при същия качествен резултат“ е реална цел.

• Предпазни мерки за качество
  Всяка победа в представянето рискува тих регрес в качеството. Нуждаете се от тестове, оценки или поне пакет за здрав разум.

• Хардуерна осведоменост
  „Бърз“ модел на един графичен процесор може да се разпространи на друг. Процесорите са свой собствен специален вид хаос.

• Итеративни промени, а не рязко пренаписване.
  Когато промените пет неща едновременно и производителността се подобри, не знаете защо. Което е... обезпокоително.

Оптимизацията трябва да се усеща като настройване на китара - малки корекции, слушайте внимателно, повтаряйте 🎸. Ако се усеща като жонглиране с ножове, нещо не е наред.

---

3) Сравнителна таблица: Популярни опции за оптимизиране на AI модели 📊

По-долу е дадена бърза и леко неподредена сравнителна таблица на често срещани инструменти/подходи за оптимизация. Не, не е напълно „справедливо“ - реалният живот също не е.

Инструмент / Опция	Аудитория	Цена	Защо работи
PyTorch torch.compile (документация на PyTorch)	Хора от PyTorch	Безплатно	Заснемането на графики + трикове за компилиране могат да намалят разходите... понякога е магия ✨
ONNX Runtime (документация за ONNX Runtime)	Екипи за разполагане	Свободно	Силни оптимизации за извод, широка поддръжка, подходящи за стандартизирано обслужване
TensorRT (документация на NVIDIA TensorRT)	Разгръщане на NVIDIA	Платени вибрации (често в пакет)	Агресивно сливане на ядра + прецизна обработка, много бързо, когато щракне
DeepSpeed ​​(ZeRO документация)	Тренировъчни екипи	Безплатно	Оптимизации на паметта + пропускателната способност (ZeRO и др.). Може да се усеща като реактивен двигател
FSDP (PyTorch) (документация на PyTorch FSDP)	Тренировъчни екипи	Безплатно	Параметри/градиенти на Shards, правят големите модели по-малко страшни
квантуване на битове и байтове (bitsandbytes)	LLM майстори	Безплатно	Ниско битовото тегло, огромни икономии на памет - качеството зависи, но уф 😬
Дестилация (Hinton et al., 2015)	Продуктови екипи	„Цена на времето“	Моделът на по-малките студенти наследява поведението, обикновено с най-добра възвръщаемост на инвестициите в дългосрочен план
Подрязване (урок за подрязване на PyTorch)	Проучване + продукт	Безплатно	Премахва мъртвото тегло. Работи по-добре, когато се комбинира с преквалификация
Светкавично внимание / слети зърна (хартия FlashAttention)	Манери по представянето	Безплатно	По-бързо внимание, по-добра памет. Истинска победа за трансформаторите
Triton Inference Server (динамично пакетиране)	Операции/инфраструктура	Безплатно	Обслужване на производството, пакетиране, многомоделни тръбопроводи - усещане за корпоративно ниво

Признание за странностите във форматирането: „Цената“ е неподредена, защото отвореният код все още може да ви струва уикенд за отстраняване на грешки, което си е... цена. 😵💫

---

4) Започнете с измерване: Профилирайте така, сякаш го мислите сериозно 🔍

Ако правите само едно нещо от цялото това ръководство, направете това: измервайте правилно.

В моите собствени тестове, най-големите „пробиви в оптимизацията“ дойдоха от откриването на нещо смущаващо просто като:

• зареждащата система за данни изтощава графичния процесор

• Затруднено място в предварителната обработка на процесора

• малки размери на партидите, причиняващи режийни разходи за стартиране на ядрото

• бавна токенизация (токенизаторите могат да бъдат тихи злодеи)

• фрагментация на паметта (бележки за разпределителя на памет в PyTorch CUDA)

• еднослойно доминиране на изчисленията

Какво да се измерва (минимален набор)

• Латентност (p50, p95, p99) (SRE върху латентни персентили)

• Пропускателна способност (токени/сек, заявки/сек)

• Използване на графичния процесор (изчисления + памет)

• Пикове на VRAM / RAM

• Цена за 1000 токена (или за извод)

Практическо профилиране на мисленето

• Опишете един сценарий, който ви интересува (не е детска игра).

• Записвайте всичко в малък „дневник за ефективност“.
  Да, досадно е... но ви спестява възможността да се самокритикувате по-късно.

(Ако искате конкретен инструмент, с който да започнете: PyTorch Profiler (torch.profiler docs) и Nsight Systems (NVIDIA Nsight Systems) са обичайните заподозрени.)

---

5) Оптимизация на данни + обучение: Тихата суперсила 📦🚀

Хората се вманиачават в архитектурата на модела и забравят за конвейера. Междувременно, конвейерът тихо изгаря половината от графичния процесор.

Лесни победи, които се появяват бързо

• Използвайте смесена прецизност (FP16/BF16, където е стабилно) (PyTorch AMP / torch.amp).
  Обикновено е по-бързо, често е добре - но внимавайте за числови особености.

• Натрупване на градиент , когато размерът на партидата е ограничен (🤗 Ръководство за ускоряване)
  Поддържа оптимизацията стабилна без експлодиране на паметта.

• Градиентно контролно поставяне (torch.utils.checkpoint)
  Заменя изчисленията с памет - прави по-големи контексти осъществими.

• Ефективна токенизация (🤗 Токенизатори)
  Токенизацията може да се превърне в пречка в голям мащаб. Не е бляскава; тя е важна.

• Настройка на зареждащата система за данни
  Повече работници, закачена памет, предварително извличане - ненатрапчиво, но ефективно 😴➡️💪 (Ръководство за настройване на производителността на PyTorch)

Параметрично ефективна фина настройка

Ако настройвате фина настройка на големи модели, PEFT методите (като адаптери в стил LoRA) могат значително да намалят разходите за обучение, като същевременно останат изненадващо силни (🤗 Ръководство за PEFT на Transformers, статия за LoRA). Това е един от онези моменти от типа „защо не направихме това по-рано?“.

---

6) Оптимизация на ниво архитектура: Правилно оразмеряване на модела 🧩

Понякога най-добрият начин за оптимизация е... да спрете да използвате модел, който е твърде голям за работата. Знам, светотатство 😄.

Обадете се на няколко основни неща:

• Решете дали имате нужда от пълноценно общо разузнаване или от специалист.

• Поддържайте контекстния прозорец толкова голям, колкото е необходимо, не по-голям.

• Използвайте модел, обучен за съответната задача (класификационни модели за класификационна работа и т.н.).

Практични стратегии за правилно оразмеряване

• Превключете към по-малка гръбначна мрежа за повечето заявки.
  След това насочете „трудните заявки“ към по-голям модел.

• Използвайте двуетапна настройка.
  Бързо изготвяне на чернови на модели, по-надежден модел - проверка или редакция.
  Все едно пишете с приятел, който е придирчив - досадно, но ефективно.

• Намалете дължината на изхода.
  Изходните маркери струват пари и време. Ако моделът ви е отклоняващ се, вие плащате за отклоненията.

Виждал съм екипи да намаляват драстично разходите, като налагат по-кратки резултати. Струва ми се дребнаво. Работи.

---

7) Компилатор + Оптимизация на графи: Откъде идва скоростта 🏎️

Това е слоят „накарайте компютъра да прави по-умни компютърни неща“.

Често срещани техники:

• Сливане на оператори (комбиниране на ядра) (NVIDIA TensorRT „сливане на слоеве“)

• Константно сгъване (предварително изчисляване на фиксирани стойности) (оптимизации на графи по време на изпълнение на ONNX)

• Изборът на ядро, съобразен с хардуера

• Заснемане на графи за намаляване на натоварването на Python (на torch.compile общ преглед)

Казано по-просто: вашият модел може да е бърз математически, но бавен оперативно. Компилаторите поправят част от това.

Практически бележки (известни още като белези)

• Тези оптимизации могат да бъдат чувствителни към промените във формата на модела.

• Някои модели ускоряват много, други едва помръдват.

• Понякога се получава ускорение и озадачаващ бъг - все едно се е настанил гремлин 🧌

Все пак, когато работи, това е една от най-чистите победи.

---

8) Квантиране, подрязване, дестилация: По-малко без плач (твърде много) 🪓📉

Това е секцията, която хората искат... защото звучи като безплатно изпълнение. Може да бъде, но трябва да се отнасяте към нея като към хирургическа намеса.

Квантиране (тегла/активации с по-ниска точност)

• Чудесно за скорост на извод и памет

• Риск: спад в качеството, особено в крайни случаи

• Най-добра практика: оценявайте върху реален тестов набор, а не върху вибрации

Често срещани вкусове, за които ще чуете:

• INT8 (често твърдотелен) (квантовани типове от TensorRT)

• INT4 / нискобитов (огромни спестявания, рискът за качеството се увеличава) (квантуване на bitsandbytes k-bit)

• Смесена величина (не всичко изисква еднаква точност)

Подрязване (премахване на параметри)

• Премахва „неважни“ тегла или структури (урок за подрязване на PyTorch)

• Обикновено е необходимо преквалификация, за да се възстанови качеството

• Работи по-добре, отколкото хората си мислят... когато се прави внимателно

Дестилация (ученикът учи от учителя)

Това е моят личен любим дългосрочен лост. Дестилацията може да създаде по-малък модел, който се държи подобно и често е по-стабилен от екстремното квантуване (Дестилация на знанието в невронна мрежа).

Несъвършена метафора: дестилацията е като да прелееш сложна супа през филтър и да получиш... по-малка супа. Супата не работи така, но разбираш идеята 🍲.

---

9) Сервиране и изводи: Истинската бойна зона 🧯

Можете да „оптимизирате“ даден модел и въпреки това да го обслужвате лошо. Обслужването е мястото, където латентността и разходите стават реални.

Сервирането печели, което има значение

• Пакетирането
  подобрява пропускателната способност. Но увеличава латентността, ако прекалите. Балансирайте го. (Динамично пакетиране на Triton)

• Кеширане
  Кеширането на подкани и повторната употреба на KV-кеша могат да бъдат масивни за повтарящи се контексти. (Обяснение на KV кеша)

• на стрийминг изход
  смятат, че е по-бързо, дори ако общото време е сходно. Възприятието е важно 🙂.

• Намаляване на натоварването токен по токен
  Някои стекове извършват допълнителна работа за всеки токен. Намалете това натоварване и ще спечелите много.

Внимавайте за латентността на опашката

Средната ви стойност може да изглежда страхотно, докато вашият p99 е катастрофа. За съжаление, потребителите живеят в опашката. („Латентност на опашката“ и защо средните стойности лъжат)

---

10) Оптимизация, съобразена с хардуера: Съобразете модела с машината 🧰🖥️

Оптимизирането без да се знае за хардуера е като тунинг на състезателна кола без да се проверяват гумите. Разбира се, можете да го направите, но е малко глупаво.

Съображения за графичен процесор

• Пропускателната способност на паметта често е ограничаващ фактор, а не суровите изчисления

• По-големите партиди могат да помогнат, докато не спрат да работят

• Сливането на ядрото и оптимизациите за внимание са огромни за трансформаторите (FlashAttention: точно внимание, съобразено с IO)

Съображения за процесора

• Нишките, векторизацията и локалността на паметта са от голямо значение

• Разходите за токенизация могат да доминират (🤗 „бързи“ токенизатори)

• Може да ви трябват различни стратегии за квантуване, отколкото на GPU

Съображения за периферни/мобилни устройства

• Паметният отпечатък става приоритет номер едно

• Разликата в латентността е важна, защото устройствата са... капризни

• По-малките, специализирани модели често превъзхождат големите общи модели

---

11) Качествени предпазни мерки: Не се „оптимизирайте“ до степен да станете бъг 🧪

Всяка бърза победа трябва да е свързана с проверка на качеството. В противен случай ще празнувате, ще изпращате и след това ще получите съобщение от рода на „защо асистентът изведнъж говори като пират?“ 🏴☠️

Прагматични предпазни парапети:

• Златни подкани (фиксиран набор от подкани, които винаги тествате)

• Метрики за задачи (точност, F1, BLEU, каквото и да е подходящо)

• Човешки проверки на място (да, сериозно)

• Прагове на регресия („допуска се спад не повече от X%)

Също така проследявайте режимите на повреда:

• отклонение на форматирането

• промени в поведението при отказ

• честота на халюцинации

• инфлация на дължината на отговора

Оптимизацията може да промени поведението по изненадващи начини. Странно. Дразнещо. Предсказуемо, с поглед назад.

---

12) Контролен списък: Как да оптимизирате AI модели стъпка по стъпка ✅🤖

Ако искате ясен ред на операциите за „Как да оптимизираме AI модели“, ето работния процес, който обикновено помага на хората да останат здрави:

1. Дефинирайте успех.
   Изберете 1-2 основни показателя (латентност, цена, пропускателна способност, качество).

2. Измерване на базовия
   профил на реалните натоварвания, записване на p50/p95, памет, разходи. (PyTorch Profiler)

3. Отстраняване на затруднения в конвейера:
   Зареждане на данни, токенизация, предварителна обработка, пакетиране.

4. Прилагане на нискорискови изчислителни решения
   със смесена прецизност, оптимизации на ядрото, по-добро пакетиране.

5. Опитайте оптимизации на компилатор/runtime:
   заснемане на графи, runtime за извод, сливане на оператори. (за torch.compile уроци, документация за ONNX Runtime).

6. Намалете разходите за модел.
   Квантифицирайте внимателно, дестилирайте, ако е възможно, подрежете, ако е уместно.

7. Кеширане на обслужването на
   тунинг, паралелизъм, тестване на натоварването, корекции на забавянето на опашката.

8. Валидиране на качеството.
   Изпълнявайте регресионни тестове и сравнявайте резултатите един до друг.

9. Повторете.
   Малки промени, ясни бележки, повторете. Ненатрапчиво - ефективно.

И да, това все още е „ Как да оптимизираме AI модели“, дори и да звучи по-скоро като „Как да спрем да стъпваме по гребла“. Същото е.

---

13) Често срещани грешки (за да не ги повтаряте като останалите от нас) 🙃

• Оптимизиране преди измерване
  Ще загубите време. И след това ще оптимизирате грешното нещо самоуверено…

• Преследване на един-единствен бенчмарк.
  Бенчмарковете лъжат чрез пропускане. Вашето работно натоварване е истината.

• Игнориране на паметта
  Проблемите с паметта причиняват забавяния, сривове и трептене. (Разбиране на използването на CUDA памет в PyTorch)

• Прекалено ранното квантуване.
  Нискобитовото квантуване може да бъде невероятно, но първо започнете с по-безопасни стъпки.

• Няма план за връщане към предишните настройки.
  Ако не можете да се върнете бързо, всяко внедряване става стресиращо. Стресът създава грешки.

---

Заключителни бележки: Човешкият начин за оптимизиране 😌⚡

Как да оптимизирате AI модели не е еднократна хакване. Това е многопластов процес: измерване, коригиране на конвейера, използване на компилатори и среди за изпълнение, настройване на обслужването, след което свиване на модела с квантуване или дестилация, ако е необходимо. Правете го стъпка по стъпка, спазвайте ограничения за качество и не се доверявайте на „усеща се по-бързо“ като показател (чувствата ви са прекрасни, чувствата ви не са профилировач).

Ако искате най-краткото хранене за вкъщи:

• Първо измерете 🔍

• Следващата стъпка е оптимизирането на тръбопровода 🧵

• След това оптимизирайте модела 🧠

• След това оптимизирайте сервирането 🏗️

• Винаги проверявайте качеството ✅

И ако това ви помага, напомнете си: целта не е „перфектен модел“. Целта е модел, който е бърз, достъпен и достатъчно надежден, за да можете да спите през нощта... през повечето нощи 😴.

Пример от реалния свят: Оптимизиране на обобщаващ инструмент за заявки за поддръжка 🎟️⚡

Сценарий

Представете си малък SaaS екип, който използва AI модел, за да обобщава входящите заявки за поддръжка, преди човешки агент да отговори. Моделът работи, но е бавен: агентите чакат твърде дълго за обобщения, а компанията плаща повече от очакваното за изводи.

Целта не е моделът да бъде „по-добър“ по всякакъв възможен начин. Екипът избира едно основно ограничение: намаляване на латентността на p95, като същевременно се запази приемливото качество на обобщението.

Тяхната цел е ясна:

Намалете латентността на p95 от около 2,4 секунди до под 1,2 секунди, с не повече от една сериозна обобщаваща грешка в тестов набор от 50 билета.

От какво се нуждае работният процес

За да направи това практично, екипът събира:

Златен тестов комплект от 50 билета с къси, средни и неподредени билети

Очакван стил на резюмето: 3 точки, без измислени факти, включете спешност, ако е очевидна

Базови показатели: латентност на p50, p95, p99, генерирани токени, цена на билет и брой грешки

Прост контролен списък за човешка проверка

Достъп до регистрационни файлове на модели, брой маркери и настройки за пакетна/едновременна работа

Опция за връщане назад, ако качеството спадне

Важното е, че те не започват с квантуване. Първо, проверяват дали конвейерът губи време.

Примерна инструкция

За всеки билет за поддръжка, обобщете проблема на клиента в точно три точки.

Включва:

• основният проблем

• всяка спомената продуктова област

• спешност или въздействие върху бизнеса, ако е посочено

Не измисляйте липсващи подробности. Ако клиентът не предостави достатъчно информация, кажете „не е посочено“.

Поддържайте резюмето под 80 думи.

Как да го тествам

Пуснете същите 50 билета през старата и новата система.

За всяко изпълнение запишете:

латентност на p50, p95 и p99

Средни изходни жетони

Цена за 1000 билета

Брой резюмета с измислени подробности

Брой резюмета, нуждаещи се от човешко пренаписване

След това тествайте няколко неудобни случая:

Билет с три отделни проблема

Съобщение от много ядосан клиент

Неясен билет с почти никакви подробности

Билет, съдържащ поставени лог файлове

Билет, в който клиентът споменава, че анулира акаунта си

Това улавя често срещания недостатък, при който оптимизацията прави модела по-бърз, но по-малко внимателен.

Резултат

Илюстративен резултат, базиран на отчитане на времето на 50 примерни билета преди и след три оптимизационни пропуска:

Базова линия:

p95 латентност: 2,4 секунди

p99 латентност: 3,1 секунди

Средна дължина на изхода: 142 думи

Човешки пренаписвания: 11 от 50

Сериозни грешки в измислените детайли: 3 от 50

След оптимизация:

p95 латентност: 1,1 секунди

p99 латентност: 1,6 секунди

Средна дължина на изхода: 61 думи

Човешки пренаписвания: 5 от 50

Сериозни грешки в измислените детайли: 1 от 50

Какво се промени:

Екипът ограничи дължината на изходния текст до 80 думи

Те групираха билетите с нисък приоритет в групи от по 8

Те кешираха повтарящ се контекст на продуктова политика

Те включиха смесена прецизност, след като потвърдиха, че качеството е налично

Те оставиха квантизацията за по-късно, защото целта за латентност вече беше постигната

Цената също намаля в този пример, защото моделът генерира по-малко токени. Ако старата настройка генерираше около 142 думи на билет, а новата - около 61 думи, дължината на изхода намаля с приблизително 57%. Това е показател, който екипът може да провери директно от лог файловете.

Какво може да се обърка

Най-изкушаваща грешка е оптимизирането само за скорост. По-бързо обобщение, което измисля обещание за възстановяване на сумата, не е подобрение.

Други лесни грешки:

Тестване само на чисти билети

Пренебрегване на латентността на p99

Забравяйки да сравните дължината на изхода

Едновременна промяна на настройките за пакетиране и модел

Използване на средна латентност вместо латентност на опашката

Твърдение, че „качеството е останало същото“ без контролен списък за преглед

Правилото за по-безопасен преглед е просто: ако повече от 2 от 50 резюмета измислят важни подробности, върнете се назад и проучете.

Практично извлечение

Ето как изглежда на практика оптимизацията на солиден ИИ модел: изберете едно ограничение, измерете текущата система, първо премахнете ненужните неща, приложете промени с нисък риск и след това проверете качеството с монотонни, но ценни тестове. Победата не е просто по-бърз модел. Това е по-бърз модел, на който все още можете да се доверите.

ЧЗВ

Какво означава на практика оптимизирането на AI модел

„Оптимизиране“ обикновено означава подобряване на едно основно ограничение: латентност, цена, обем на паметта, точност, стабилност или пропускателна способност. Трудната част са компромисите - натискането на една област може да повлияе на друга. Практически подход е да се избере ясна цел (като латентност на p95 или време за постигане на качество) и да се оптимизира спрямо нея. Без цел е лесно да се „подобри“ и все пак да се загуби.

Как да оптимизираме AI моделите, без тихо да навредим на качеството

Отнасяйте се към всяка промяна в скоростта или цената като към потенциална тиха регресия. Използвайте предпазни мерки като златни подсказки, показатели за задачи и бързи човешки проверки на място. Задайте ясен праг за приемливо отклонение в качеството и сравнявайте резултатите един до друг. Това предотвратява превръщането на „по-бързо е“ в „защо изведнъж стана странно в продукцията?“, след като пуснете продукта.

Какво да измерите, преди да започнете оптимизацията

Започнете с процентили на латентност (p50, p95, p99), пропускателна способност (токени/сек или заявки/сек), използване на графичния процесор и пикова VRAM/RAM. Проследявайте разходите за извод или за 1k токени, ако цената е ограничение. Направете профил на реален сценарий, който обслужвате, а не на зададена играчка. Воденето на малък „дневник на производителността“ ви помага да избегнете догадки и повтаряне на грешки.

Бързи победи с нисък риск за постиженията в тренировките

Смесената прецизност (FP16/BF16) често е най-бързият първи лост, но внимавайте за числови особености. Ако размерът на партидата е ограничен, натрупването на градиент може да стабилизира оптимизацията, без да изразходва памет. Контролните точки с градиент заменят допълнителни изчисления с по-малко памет, което позволява по-големи контексти. Не пренебрегвайте токенизацията и настройката на зареждащия механизъм за данни - те могат тихомълком да изтощят графичния процесор.

Кога да използвате torch.compile, ONNX Runtime или TensorRT

Тези инструменти са насочени към оперативни разходи: заснемане на графи, сливане на ядра и оптимизации на графи по време на изпълнение. Те могат да осигурят чисто ускорение на извода, но резултатите варират в зависимост от формата на модела и хардуера. Някои настройки се усещат като магия; други едва се движат. Очаквайте чувствителност към промени във формата и случайни грешки „гремлини“ - измерете преди и след реалното си натоварване.

Дали квантизацията си струва и как да се избегне прекаляването

Квантирането може да намали паметта и да ускори извода, особено с INT8, но качеството може да се влоши в гранични случаи. Опциите с по-ниски битове (като INT4/k-bit) носят по-големи спестявания с по-висок риск. Най-безопасният навик е да се оценява върху реален тестов набор и да се сравняват резултатите, а не интуицията. Започнете първо с по-безопасни стъпки, след което преминете към по-ниска точност само ако е необходимо.

Разликата между подрязване и дестилация за намаляване на размера на модела

Подрязването премахва параметрите на „мъртвото тегло“ и често се нуждае от преобучение, за да се възстанови качеството, особено когато се прави агресивно. Дестилацията обучава по-малък модел на ученик да имитира поведението на по-голям учител и може да бъде по-добра дългосрочна възвръщаемост на инвестициите от екстремното квантуване. Ако искате по-малък модел, който се държи подобно и остава стабилен, дестилацията често е по-чистият път.

Как да се намалят разходите за извод и латентността чрез подобрения в обслужването

Обслужването е мястото, където оптимизацията става осезаема: пакетирането увеличава пропускателната способност, но може да навреди на латентността, ако се прекали с него, така че го настройвайте внимателно. Кеширането (бързо кеширане и повторно използване на KV-кеша) може да бъде огромно, когато контекстите се повтарят. Стриймингът на изход подобрява възприеманата скорост, дори ако общото време е сходно. Също така, обърнете внимание на разходите за всеки токен в стека си - малката работа за всеки токен се натрупва бързо.

Защо латентността на опашката е толкова важна при оптимизиране на AI модели

Средните стойности могат да изглеждат страхотно, докато p99 е катастрофа, а потребителите са склонни да живеят в „опашката“. Латентността на „опашката“ често се дължи на трептене: фрагментация на паметта, пикове на предварителна обработка на процесора, забавяне на токенизацията или лошо поведение при пакетиране. Ето защо ръководството набляга на процентилите и реалните натоварвания. Дори да оптимизирате само p50, все още можете да създадете изживяване, което „случайно се усеща бавно“

Референции

1. Amazon Web Services (AWS) - AWS CloudWatch процентили (статистически дефиниции) - docs.aws.amazon.com

2. Google - Опашката в мащаб (най-добра практика за латентност на опашката) - sre.google

3. Google - Цели за ниво на обслужване (Книга SRE) - процентили на латентност - sre.google

4. PyTorch - torch.compile - docs.pytorch.org

5. PyTorch - FullyShardedDataParallel (FSDP) - docs.pytorch.org

6. PyTorch - PyTorch Profiler - docs.pytorch.org

7. PyTorch - CUDA семантика: управление на паметта (бележки за CUDA разпределителя на памет) - docs.pytorch.org

8. PyTorch - Автоматична смесена прецизност (torch.amp / AMP) - docs.pytorch.org

9. PyTorch - torch.utils.checkpoint - docs.pytorch.org

10. PyTorch - Ръководство за оптимизация на производителността - docs.pytorch.org

11. PyTorch - Урок за подрязване - docs.pytorch.org

12. PyTorch - Разбиране на използването на CUDA памет в PyTorch - docs.pytorch.org

13. PyTorch - урок / общ преглед на torch.compile - docs.pytorch.org

14. ONNX Runtime - Документация за ONNX Runtime - onnxruntime.ai

15. NVIDIA - Документация за TensorRT - docs.nvidia.com

16. NVIDIA - Квантовани типове в TensorRT - docs.nvidia.com

17. NVIDIA - Nsight Systems - developer.nvidia.com

18. NVIDIA - Triton Inference Server - динамично пакетиране - docs.nvidia.com

19. DeepSpeed ​​- Документация за ZeRO Stage 3 - deepspeed.readthedocs.io

20. bitsandbytes (bitsandbytes-foundation) - bitsandbytes - github.com

21. Прегръщащо лице - Ускоряване: Ръководство за натрупване на градиент - huggingface.co

22. Документация за токенизатори на Hugging Face - huggingface.co

23. Прегръщащо лице - Трансформърс: Ръководство за PEFT - huggingface.co

24. Прегръщащо лице - Трансформърс: Обяснение на кеша на KV - huggingface.co

25. Hugging Face - Трансформърс: „Бързи“ токенизатори (класове токенизатори) - huggingface.co

26. arXiv - Дестилиране на знанието в невронна мрежа (Hinton et al., 2015) - arxiv.org

27. arXiv - LoRA: Нискорангова адаптация на големи езикови модели - arxiv.org

28. arXiv - FlashAttention: Бързо и ефективно откъм памет точно внимание с IO-Awareness - arxiv.org