Кратък отговор: За да оптимизирате моделите с изкуствен интелект, изберете едно основно ограничение (латентност, цена, памет, качество, стабилност или пропускателна способност), след което определете надеждна базова линия, преди да промените каквото и да било. Първо премахнете пречките в конвейера, след това приложете нискорискови подобрения, като смесена прецизност и пакетна обработка; ако качеството се запази, преминете към инструменти за компилиране/изпълнение и едва след това намалете размера на модела чрез квантуване или дестилация, когато е необходимо.
Ключови изводи:
Ограничение : Изберете една или две целеви показатели; оптимизацията е пейзаж от компромиси, а не безплатни победи.
Измерване : Профилирайте реални натоварвания с 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-2 основни показателя (латентност, цена, пропускателна способност, качество). -
Измерване на базовия
профил на реалните натоварвания, записване на p50/p95, памет, разходи. ( PyTorch Profiler ) -
Отстраняване на затруднения в конвейера:
Зареждане на данни, токенизация, предварителна обработка, пакетиране. -
Прилагане на нискорискови изчислителни решения
със смесена прецизност, оптимизации на ядрото, по-добро пакетиране. -
Опитайте оптимизации на компилатор/runtime:
заснемане на графи, runtime за извод, сливане на оператори. ( уроциза torch.compile, документация за ONNX Runtime ). -
Намалете разходите за модел.
Квантифицирайте внимателно, дестилирайте, ако е възможно, подрежете, ако е уместно. -
Кеширане на обслужването на
тунинг, паралелизъм, тестване на натоварването, корекции на забавянето на опашката. -
Валидиране на качеството.
Изпълнявайте регресионни тестове и сравнявайте резултатите един до друг. -
Повторете.
Малки промени, ясни бележки, повторете. Ненатрапчиво - ефективно.
И да, това все още е „ Как да оптимизираме AI модели“, дори и да звучи по-скоро като „Как да спрем да стъпваме по гребла“. Същото е.
13) Често срещани грешки (за да не ги повтаряте като останалите от нас) 🙃
-
Оптимизиране преди измерване
Ще загубите време. И след това ще оптимизирате грешното нещо самоуверено… -
Преследване на един-единствен бенчмарк.
Бенчмарковете лъжат чрез пропускане. Вашето работно натоварване е истината. -
Игнориране на паметта
Проблемите с паметта причиняват забавяния, сривове и трептене. ( Разбиране на използването на CUDA памет в PyTorch ) -
Прекалено ранното квантуване.
Нискобитовото квантуване може да бъде невероятно, но първо започнете с по-безопасни стъпки. -
Няма план за връщане към предишните настройки.
Ако не можете да се върнете бързо, всяко внедряване става стресиращо. Стресът създава грешки.
Заключителни бележки: Човешкият начин за оптимизиране 😌⚡
Как да оптимизирате AI модели не е еднократна хакване. Това е многопластов процес: измерване, коригиране на конвейера, използване на компилатори и среди за изпълнение, настройване на обслужването, след което свиване на модела с квантуване или дестилация, ако е необходимо. Правете го стъпка по стъпка, спазвайте ограничения за качество и не се доверявайте на „усеща се по-бързо“ като показател (чувствата ви са прекрасни, чувствата ви не са профилировач).
Ако искате най-краткото хранене за вкъщи:
-
Първо измерете 🔍
-
Следващата стъпка е оптимизирането на тръбопровода 🧵
-
След това оптимизирайте модела 🧠
-
След това оптимизирайте сервирането 🏗️
-
Винаги проверявайте качеството ✅
И ако това ви помага, напомнете си: целта не е „перфектен модел“. Целта е модел, който е бърз, достъпен и достатъчно надежден, за да можете да спите през нощта... през повечето нощи 😴.
ЧЗВ
Какво означава на практика оптимизирането на AI модел
„Оптимизиране“ обикновено означава подобряване на едно основно ограничение: латентност, цена, обем на паметта, точност, стабилност или пропускателна способност. Трудната част са компромисите - натискането на една област може да повлияе на друга. Практически подход е да се избере ясна цел (като латентност на p95 или време за постигане на качество) и да се оптимизира спрямо нея. Без цел е лесно да се „подобри“ и все пак да се загуби.
Как да оптимизираме AI моделите, без тихо да навредим на качеството
Отнасяйте се към всяка промяна в скоростта или цената като към потенциална тиха регресия. Използвайте предпазни мерки като златни подсказки, показатели за задачи и бързи човешки проверки на място. Задайте ясен праг за приемливо отклонение в качеството и сравнявайте резултатите един до друг. Това предотвратява превръщането на „по-бързо е“ в „защо изведнъж стана странно в продукцията?“, след като пуснете продукта.
Какво да измерите, преди да започнете оптимизацията
Започнете с процентили на латентност (p50, p95, p99), пропускателна способност (токени/сек или заявки/сек), използване на графичния процесор и пикова VRAM/RAM. Проследявайте разходите за извод или за 1k токени, ако цената е ограничение. Направете профил на реален сценарий, който обслужвате, а не на зададена играчка. Воденето на малък „дневник на производителността“ ви помага да избегнете догадки и повтаряне на грешки.
Бързи победи с нисък риск за постиженията в тренировките
Смесената прецизност (FP16/BF16) често е най-бързият първи лост, но внимавайте за числови особености. Ако размерът на партидата е ограничен, натрупването на градиент може да стабилизира оптимизацията, без да изразходва памет. Контролните точки с градиент заменят допълнителни изчисления с по-малко памет, което позволява по-големи контексти. Не пренебрегвайте токенизацията и настройката на зареждащия механизъм за данни - те могат тихомълком да изтощят графичния процесор.
Кога да използвате torch.compile, ONNX Runtime или TensorRT
Тези инструменти са насочени към оперативни разходи: заснемане на графи, сливане на ядра и оптимизации на графи по време на изпълнение. Те могат да осигурят чисто ускорение на извода, но резултатите варират в зависимост от формата на модела и хардуера. Някои настройки се усещат като магия; други едва се движат. Очаквайте чувствителност към промени във формата и случайни грешки „гремлини“ - измерете преди и след реалното си натоварване.
Дали квантизацията си струва и как да се избегне прекаляването
Квантирането може да намали паметта и да ускори извода, особено с INT8, но качеството може да се влоши в гранични случаи. Опциите с по-ниски битове (като INT4/k-bit) носят по-големи спестявания с по-висок риск. Най-безопасният навик е да се оценява върху реален тестов набор и да се сравняват резултатите, а не интуицията. Започнете първо с по-безопасни стъпки, след което преминете към по-ниска точност само ако е необходимо.
Разликата между подрязване и дестилация за намаляване на размера на модела
Подрязването премахва параметрите на „мъртвото тегло“ и често се нуждае от преобучение, за да се възстанови качеството, особено когато се прави агресивно. Дестилацията обучава по-малък модел на ученик да имитира поведението на по-голям учител и може да бъде по-добра дългосрочна възвръщаемост на инвестициите от екстремното квантуване. Ако искате по-малък модел, който се държи подобно и остава стабилен, дестилацията често е по-чистият път.
Как да се намалят разходите за извод и латентността чрез подобрения в обслужването
Обслужването е мястото, където оптимизацията става осезаема: пакетирането увеличава пропускателната способност, но може да навреди на латентността, ако се прекали с него, така че го настройвайте внимателно. Кеширането (бързо кеширане и повторно използване на KV-кеша) може да бъде огромно, когато контекстите се повтарят. Стриймингът на изход подобрява възприеманата скорост, дори ако общото време е сходно. Също така, обърнете внимание на разходите за всеки токен в стека си - малката работа за всеки токен се натрупва бързо.
Защо латентността на опашката е толкова важна при оптимизиране на AI модели
Средните стойности могат да изглеждат страхотно, докато p99 е катастрофа, а потребителите са склонни да живеят в „опашката“. Латентността на „опашката“ често се дължи на трептене: фрагментация на паметта, пикове на предварителна обработка на процесора, забавяне на токенизацията или лошо поведение при пакетиране. Ето защо ръководството набляга на процентилите и реалните натоварвания. Дори да оптимизирате само p50, все още можете да създадете изживяване, което „случайно се усеща бавно“
Референции
-
Amazon Web Services (AWS) - AWS CloudWatch процентили (статистически дефиниции) - docs.aws.amazon.com
-
Google - Опашката в мащаб (най-добра практика за латентност на опашката) - sre.google
-
Google - Цели за ниво на обслужване (Книга SRE) - процентили на латентност - sre.google
-
PyTorch - torch.compile - docs.pytorch.org
-
PyTorch - FullyShardedDataParallel (FSDP) - docs.pytorch.org
-
PyTorch - PyTorch Profiler - docs.pytorch.org
-
PyTorch - CUDA семантика: управление на паметта (бележки за CUDA разпределителя на памет) - docs.pytorch.org
-
PyTorch - Автоматична смесена прецизност (torch.amp / AMP) - docs.pytorch.org
-
PyTorch - torch.utils.checkpoint - docs.pytorch.org
-
PyTorch - Ръководство за оптимизация на производителността - docs.pytorch.org
-
PyTorch - Урок за подрязване - docs.pytorch.org
-
PyTorch - Разбиране на използването на CUDA памет в PyTorch - docs.pytorch.org
-
PyTorch - урок / общ преглед на torch.compile - docs.pytorch.org
-
ONNX Runtime - Документация за ONNX Runtime - onnxruntime.ai
-
NVIDIA - Документация за TensorRT - docs.nvidia.com
-
NVIDIA - Квантовани типове в TensorRT - docs.nvidia.com
-
NVIDIA - Nsight Systems - developer.nvidia.com
-
NVIDIA - Triton Inference Server - динамично пакетиране - docs.nvidia.com
-
DeepSpeed - Документация за ZeRO Stage 3 - deepspeed.readthedocs.io
-
bitsandbytes (bitsandbytes-foundation) - bitsandbytes - github.com
-
Прегръщащо лице - Ускоряване: Ръководство за натрупване на градиент - huggingface.co
-
Документация за токенизатори на Hugging Face - huggingface.co
-
Прегръщащо лице - Трансформърс: Ръководство за PEFT - huggingface.co
-
Прегръщащо лице - Трансформърс: Обяснение на кеша на KV - huggingface.co
-
Hugging Face - Трансформърс: „Бързи“ токенизатори (класове токенизатори) - huggingface.co
-
arXiv - Дестилиране на знанието в невронна мрежа (Hinton et al., 2015) - arxiv.org
-
arXiv - LoRA: Нискорангова адаптация на големи езикови модели - arxiv.org
-
arXiv - FlashAttention: Бързо и ефективно откъм памет точно внимание с IO-Awareness - arxiv.org