Коротка відповідь: щоб оптимізувати моделі ШІ, виберіть одне основне обмеження (затримка, вартість, пам'ять, якість, стабільність або пропускна здатність), а потім визначте надійний базовий рівень, перш ніж щось змінювати. Спочатку усуньте вузькі місця конвеєра, потім застосуйте низькоризикові переваги, такі як змішана точність та пакетна обробка; якщо якість зберігається, переходьте до інструментів компілятора/виконавчого середовища і лише потім зменшуйте розмір моделі за допомогою квантування або дистиляції, коли це необхідно.
Ключові висновки:
Обмеження : Виберіть один або два цільові показники; оптимізація — це ландшафт компромісів, а не безкоштовних перемог.
Вимірювання : Профілювання реальних робочих навантажень з p50/p95/p99, пропускною здатністю, використанням та піками пам'яті.
Конвеєр : Виправте токенізацію, завантажувачі даних, попередню обробку та пакетну обробки перед тим, як торкатися моделі.
Обслуговування : використовуйте кешування, навмисне пакетне виконання, налаштування паралельності та пильно стежте за затримкою хвоста.
Guardrails : Запускайте золоті підказки, метрики завдань та вибіркові перевірки після кожної зміни продуктивності.
🔗 Як ефективно оцінювати моделі ШІ.
Ключові критерії та кроки для справедливої та надійної оцінки моделей.
🔗 Як вимірювати продуктивність ШІ за допомогою реальних показників.
Використовуйте бенчмарки, сигнали затримки, вартості та якості для порівняння.
🔗 Як тестувати моделі ШІ перед виробництвом
Практичний робочий процес тестування: розділення даних, стресові випадки та моніторинг.
🔗 Як використовувати штучний інтелект для створення контенту.
Швидше перетворюйте ідеї на чернетки за допомогою структурованих підказок та ітерацій.
1) Що означає слово «Оптимізувати» на практиці (бо кожен використовує його по-різному) 🧠
Коли люди кажуть «оптимізувати модель штучного інтелекту», вони можуть мати на увазі:
-
Зробіть це швидшим (зменште затримку)
-
Зробити це дешевше (менше годин роботи графічного процесора, менші витрати на хмарні ресурси)
-
Зменшити (зайнятість пам'яті, розгортання на периферії)
-
Зробити його точнішим (покращення якості, менше галюцинацій)
-
Зробити його стабільнішим (менше відхилень, менше збоїв у виробництві)
-
Спростити обслуговування (пропускна здатність, пакетна обробка, передбачувана продуктивність)
Ось дещо прикра правда: ви не можете максимізувати все це одночасно. Оптимізація схожа на стиснення повітряної кульки – втиснете одну сторону всередину, а інша вискочить. Не завжди, але достатньо часто, щоб вам слід було планувати компроміси.
Тож, перш ніж щось торкатися, виберіть своє основне обмеження :
-
Якщо ви обслуговуєте користувачів у режимі реального часу, вас цікавить затримка p95 ( перцентилі AWS CloudWatch ) та продуктивність хвоста ( найкраща практика щодо «затримки хвоста» ) 📉
-
Якщо ви тренуєтесь, вас цікавить час, необхідний для досягнення якості , та використання графічного процесора 🔥
-
Якщо ви розгортаєте на пристроях, вам важливі оперативна пам'ять та живлення 🔋
2) Як виглядає хороша версія оптимізації моделі ШІ ✅
Гарний варіант оптимізації — це не просто «застосувати квантування та молитися». Це система. Найкращі налаштування зазвичай мають:
-
Базовий рівень, якому ви довіряєте.
Якщо ви не можете відтворити свої поточні результати, ви не можете знати, що щось покращили. Просто… але люди пропускають це. Потім вони заходять у спіраль. -
Чіткий цільовий показник
«Швидше» є розпливчастим. «Зменшити затримку p95 з 900 мс до 300 мс при тому ж показнику якості» – це реальна мета. -
Захисні бар'єри для якості.
Кожна перемога в продуктивності ризикує мовчазним зниженням якості. Вам потрібні тести, оцінювання або хоча б комплекс послуг з перевірки здорового глузду. -
Обізнаність з апаратним забезпеченням.
«Швидка» модель на одному графічному процесорі може повзати на іншому. Центральні процесори — це окремий особливий вид хаосу. -
Ітеративні зміни, а не раптове переписування.
Коли ви змінюєте п'ять речей одночасно, і продуктивність покращується, ви не знаєте чому. Що… тривожно.
Оптимізація має відчуватися як налаштування гітари — невеликі корективи, уважно слухайте, повторюйте 🎸. Якщо це схоже на жонглювання ножами, щось не так.
3) Таблиця порівняння: Популярні варіанти оптимізації моделей штучного інтелекту 📊
Нижче наведено коротку та дещо неохайну таблицю порівняння поширених інструментів/підходів до оптимізації. Ні, це не зовсім «справедливо» – реальне життя також не є таким.
| Інструмент / Опція | Аудиторія | Ціна | Чому це працює |
|---|---|---|---|
PyTorch torch.compile ( документація PyTorch ) |
Люди з PyTorch | Безкоштовно | Захоплення графів + хитрощі компілятора можуть скоротити накладні витрати… іноді це магія ✨ |
| ONNX Runtime ( документація ONNX Runtime ) | Команди розгортання | Вільний | Сильна оптимізація виводів, широка підтримка, добре підходить для стандартизованого обслуговування |
| TensorRT ( документація NVIDIA TensorRT ) | Розгортання NVIDIA | Платні вібрації (часто в комплекті) | Агресивне злиття ядер + точна обробка, дуже швидко, коли клацає |
| DeepSpeed ( документація ZeRO ) | Тренувальні команди | Безкоштовно | Оптимізація пам'яті + пропускної здатності (ZeRO тощо). Може відчуватися як реактивний двигун |
| FSDP (PyTorch) ( документація PyTorch FSDP ) | Тренувальні команди | Безкоштовно | Параметри/градієнти шардів, роблять великі моделі менш страшними |
| квантування біт-і-байтів ( bitsandbytes ) | майстри з LLM | Безкоштовно | Низька бітова вага, величезна економія пам'яті - якість залежить, але фух 😬 |
| Дистиляція ( Hinton et al., 2015 ) | Команди з розробки продуктів | «Витрати часу» | Модель меншого студента успадковує поведінку, зазвичай найкраща довгострокова рентабельність інвестицій |
| Обрізка ( посібник з обрізки PyTorch ) | Дослідження + виробництво | Безкоштовно | Усуває мертву вагу. Працює краще в поєднанні з перепідготовкою |
| Flash Attention / зрощені ядра ( папір FlashAttention ) | Фанати продуктивності | Безкоштовно | Швидша увага, краща пам'ять та поведінка. Справжня перемога для трансформерів |
| Сервер виводу Triton ( динамічне пакетування ) | Операції/інфраструктура | Безкоштовно | Обслуговування виробництва, пакетна обробка, багатомодельні конвеєри — відчувається як у підприємстві |
Зізнання щодо особливості форматування: «Ціна» — це неохайно, бо відкритий код все одно може коштувати вам вихідних налагодження, що є… ціною. 😵💫
4) Почніть з вимірювання: створюйте профіль так, як ви це маєте на увазі 🔍
Якщо ви робите лише одне з усього цього посібника, зробіть ось що: правильно виміряйте.
Згідно з моїм власним тестуванням, найбільші «прориви в оптимізації» сталися завдяки відкриттю чогось бентежно простого, як-от:
-
завантажувач даних, що перевантажує графічний процесор
-
Вузьке місце попередньої обробки процесора
-
крихітні розміри пакетів, що спричиняють накладні витрати на запуск ядра
-
повільна токенізація (токенізатори можуть бути тихими лиходіями)
-
фрагментація пам'яті ( примітки щодо розподільника пам'яті PyTorch CUDA )
-
одношарове домінування обчислень
Що вимірювати (мінімальний набір)
-
Латентність (p50, p95, p99) ( SRE за процентилями латентності )
-
Пропускна здатність (токени/сек, запити/сек)
-
Використання графічного процесора (обчислення + пам'ять)
-
Піки відеопам'яті / оперативної пам'яті
-
Вартість за 1 тис. токенів (або за висновок)
Практичний профільний менталітет
-
Опишіть один сценарій, який вас цікавить (не іграшкову підказку).
-
Записуйте все в маленький «щоденник ефективності».
Так, це нудно… але це позбавить вас від самозвинувачення пізніше.
(Якщо вам потрібен конкретний інструмент для початку: PyTorch Profiler ( документація torch.profiler ) та 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 Runtime )
-
Вибір ядра, налаштований відповідно до апаратного забезпечення
-
Захоплення графів для зменшення накладних витрат Python ( огляд
torch.compile)
Простіше кажучи: ваша модель може бути швидкою з математичного точки зору, але повільною з операційної точки зору. Компілятори частково виправляють це.
Практичні нотатки (також відомі як шрами)
-
Ці оптимізації можуть бути чутливими до змін форми моделі.
-
Деякі моделі сильно прискорюються, деякі ледве рухаються з місця.
-
Іноді трапляється прискорення та загадкова помилка — ніби гремлін вселився 🧌
Тим не менш, коли це працює, це одна з найчистіших перемог.
8) Квантування, обрізання, дистиляція: Менше без плачу (занадто багато) 🪓📉
Це саме той розділ, якого хочуть люди… бо звучить як безкоштовний виступ. Можливо, так воно і є, але до цього треба ставитися як до хірургічного втручання.
Квантування (ваги/активації з нижчою точністю)
-
Чудово підходить для швидкості логічного висновку та пам'яті
-
Ризик: падіння якості, особливо у крайніх випадках
-
Найкраща практика: оцінюйте на реальному тестовому наборі, а не на вібраціях
Поширені смаки, про які ви почуєте:
-
INT8 (часто твердотільний) ( квантовані типи TensorRT )
-
INT4 / низький біт (величезна економія, зростає ризик якості) ( bitsandbytes k-бітове квантування )
-
Змішана величина (не все потребує однакової точності)
Обрізка (видалення параметрів)
-
Видаляє «неважливі» ваги або структури ( посібник з обрізання PyTorch )
-
Зазвичай потрібна перепідготовка для відновлення якості
-
Працює краще, ніж люди думають… коли все зроблено обережно
Дистиляція (студент навчається у вчителя)
Це мій особистий улюблений довгостроковий важіль. Дистиляція може створити меншу модель, яка поводиться подібно, і вона часто стабільніша, ніж екстремальне квантування ( Дистиляція знань у нейронній мережі ).
Недосконала метафора: дистиляція — це як пролити складний суп через фільтр і отримати… менший суп. Суп працює не так, але ви зрозуміли 🍲.
9) Подача та висновок: справжня зона битви 🧯
Ви можете «оптимізувати» модель і все одно погано її обслуговувати. Саме обслуговування є тим етапом, де затримка та вартість стають реальними.
Подача перемагає, що має значення
-
Пакетна обробка
покращує пропускну здатність. Але збільшує затримку, якщо перестаратися. Збалансуйте її. ( Динамічне пакетне оброблення Triton ) -
Кешування.
Кешування запитів та повторне використання KV-кешу може бути масивним для повторюваних контекстів. ( Пояснення щодо KV-кешу ). -
Потоковий вихід.
Користувачі відчувають, що це швидше, навіть якщо загальний час схожий. Сприйняття має значення 🙂. -
Зменшення накладних витрат для кожного токена.
Деякі стеки виконують додаткову роботу на кожен токен. Зменште ці накладні витрати, і ви виграєте по-крупному.
Зверніть увагу на затримку хвоста
Ваш середній показник може виглядати чудово, тоді як ваш p99 — це катастрофа. На жаль, користувачі живуть у хвості. ( «Затримка хвоста» та чому середні показники брешуть )
10) Оптимізація з урахуванням апаратного забезпечення: підбирайте модель відповідно до машини 🧰🖥️
Оптимізація без усвідомлення апаратного забезпечення — це як налаштування гоночного автомобіля без перевірки шин. Звичайно, ви можете це зробити, але це трохи безглуздо.
Міркування щодо графічного процесора
-
Пропускна здатність пам'яті часто є обмежувальним фактором, а не необроблені обчислення
-
Більші розміри партій можуть допомогти, поки вони не перестануть
-
Злиття ядра та оптимізація уваги мають величезне значення для трансформерів ( FlashAttention: точна увага з урахуванням вводу-виводу )
Міркування щодо процесора
-
Потокоподібність, векторизація та локальність пам'яті мають велике значення
-
Накладні витрати на токенізацію можуть домінувати ( 🤗 «Швидкі» токенізатори )
-
Вам можуть знадобитися інші стратегії квантування, ніж на GPU
Міркування щодо периферійних/мобільних пристроїв
-
Обсяг пам'яті стає пріоритетом номер один
-
Варіація затримки має значення, оскільки пристрої… примхливі
-
Менші, спеціалізовані моделі часто перевершують великі універсальні моделі
11) Якісні бар'єри: Не «оптимізуйте» себе до стану помилки 🧪
Кожна перемога на швидкості має супроводжуватися перевіркою якості. Інакше ви будете святкувати, відправляти, а потім отримувати повідомлення на кшталт «чому асистент раптом почав говорити як пірат?» 🏴☠️
Прагматичні захисні огорожі:
-
Золоті підказки (фіксований набір підказок, які ви завжди перевіряєте)
-
Метрики завдання (точність, F1, BLEU, що завгодно)
-
Вибіркові перевірки людьми (так, серйозно)
-
Пороги регресії («допускається падіння не більше ніж на X%)
Також відстежуйте режими відмови:
-
зсув форматування
-
зміни в поведінці відмови
-
частота галюцинацій
-
інфляція довжини відповіді
Оптимізація може змінити поведінку дивовижним чином. Дивним чином. Дратівливо. Передбачувано, озираючись назад.
12) Контрольний список: Як оптимізувати моделі штучного інтелекту крок за кроком ✅🤖
Якщо вам потрібен чіткий порядок дій для оптимізації моделей штучного інтелекту , ось робочий процес, який допомагає людям залишатися здоровими:
-
Визначте успіх.
Виберіть 1-2 основні показники (затримка, вартість, пропускна здатність, якість). -
Вимірювання базового
профілю реальних робочих навантажень, запис p50/p95, пам'яті, вартості. ( PyTorch Profiler ) -
Виправлення вузьких місць конвеєра
Завантаження даних, токенізація, попередня обробка, пакетна обробка. -
Застосовуйте низькоризикові обчислювальні перемоги:
змішану точність, оптимізацію ядра, кращу пакетну обробку. -
Спробуйте оптимізацію компілятора/виконання:
захоплення графів, виконання виводів, об'єднання операторів ( підручникз torch.compile, документація з виконання ONNX ). -
Зменште вартість моделі.
Ретельно квантуйте, дистилюйте, якщо можливо, скоротіть, якщо доречно. -
Кешування обслуговування
налаштування, паралельність, тестування навантаження, виправлення затримки хвоста. -
Перевірка якості.
Проведення регресійних тестів та порівняння результатів пліч-о-пліч. -
Повторення.
Невеликі зміни, чіткі нотатки, повторення. Непоказно - ефективно.
І так, це все ще « Як оптимізувати моделі штучного інтелекту», навіть якщо це більше схоже на «Як перестати наступати на граблі». Те саме.
13) Поширені помилки (щоб ви їх не повторювали, як ми всі) 🙃
-
Оптимізація перед вимірюваннями.
Ви втратите час. А потім самовпевнено оптимізуватимете не те… -
Прагнення до єдиного еталону
. Еталони брешуть через упущення. Ваше робоче навантаження – це правда. -
Ігнорування пам'яті.
Проблеми з пам'яттю спричиняють уповільнення, збої та тремтіння. ( Розуміння використання пам'яті CUDA в PyTorch ) -
Надмірне квантування занадто рано.
Низькобітове квантування може бути дивовижним, але спочатку почніть з безпечніших кроків. -
Немає плану відкату.
Якщо ви не можете швидко повернутися до попереднього стану, кожне розгортання стає стресовим. Стрес породжує помилки.
Заключні нотатки: Людський спосіб оптимізації 😌⚡
Оптимізація моделей ШІ — це не одноразовий хак. Це багаторівневий процес: вимірювання, виправлення конвеєра, використання компіляторів та середовищ виконання, налаштування обслуговування, а потім стиснення моделі за допомогою квантування або дистиляції, якщо потрібно. Робіть це крок за кроком, дотримуйтесь правил якості та не довіряйте «відчуття швидшого» як метриці (ваші відчуття прекрасні, ваші почуття — це не профайлер).
Якщо ви хочете найкоротший винос:
-
Спочатку виміряй 🔍
-
Далі оптимізуйте конвеєр 🧵
-
Потім оптимізуйте модель 🧠
-
Тоді оптимізуйте показ 🏗️
-
Завжди перевіряйте якість ✅
І якщо це допоможе, нагадайте собі: мета не в «ідеальній моделі». Мета — модель, яка є швидкою, доступною та достатньо надійною, щоб ви могли спати вночі… майже щоночі 😴.
Найчастіші запитання
Що означає оптимізація моделі штучного інтелекту на практиці
«Оптимізація» зазвичай означає покращення одного основного обмеження: затримки, вартості, обсягу пам’яті, точності, стабільності або пропускної здатності. Найскладніше — це компроміси: просування однієї області може негативно вплинути на іншу. Практичний підхід полягає у виборі чіткої цілі (наприклад, затримки p95 або часу досягнення якості) та оптимізації відповідно до неї. Без цілі легко «покращити» і все одно програти.
Як оптимізувати моделі штучного інтелекту, не погіршуючи якість
Ставтеся до кожної зміни швидкості чи вартості як до потенційної тихої регресії. Використовуйте такі запобіжні заходи, як золоті підказки, показники завдань та швидкі вибіркові перевірки людиною. Встановіть чіткий поріг для прийнятного дрейфу якості та порівнюйте результати пліч-о-пліч. Це запобігає перетворенню «це швидше» на «чому це раптом стало дивним у продакшені?» після відправки.
Що потрібно виміряти перед початком оптимізації
Почніть із процентилів затримки (p50, p95, p99), пропускної здатності (токени/сек або запити/сек), використання графічного процесора та пікового обсягу відеопам'яті/оперативної пам'яті. Відстежуйте вартість на висновок або на 1000 токенів, якщо вартість є обмеженням. Профільуйте реальний сценарій, який ви обслуговуєте, а не іграшкову підказку. Ведення невеликого «щоденника продуктивності» допоможе вам уникнути здогадок та повторення помилок.
Швидкі перемоги з низьким рівнем ризику для покращення тренувальної продуктивності
Змішана точність (FP16/BF16) часто є найшвидшим першим важелем, але слідкуйте за числовими особливостями. Якщо розмір пакету обмежений, накопичення градієнта може стабілізувати оптимізацію без витрачання пам'яті. Контрольні точки градієнта обмінюють додаткові обчислення на менший обсяг пам'яті, що дозволяє використовувати більші контексти. Не ігноруйте токенізацію та налаштування завантажувача даних — вони можуть непомітно виснажити графічний процесор.
Коли використовувати torch.compile, ONNX Runtime або TensorRT
Ці інструменти спрямовані на операційні витрати: захоплення графів, об'єднання ядра та оптимізацію графів під час виконання. Вони можуть забезпечити чисте прискорення логічного висновку, але результати залежать від форми моделі та апаратного забезпечення. Деякі налаштування відчуваються як магія; інші ледве рухаються. Будьте готові до чутливості до змін форми та випадкових помилок "гремлінів" - виміряйте до та після на вашому реальному робочому навантаженні.
Чи варто квантувати, і як уникнути надмірного втручання
Квантування може скоротити обсяг пам'яті та пришвидшити логічний висновок, особливо з INT8, але якість може знижуватися в крайніх випадках. Варіанти з меншою розрядністю (наприклад, INT4/k-біт) забезпечують більшу економію з вищим ризиком. Найбезпечніша звичка — оцінювати на реальному тестовому наборі та порівнювати результати, а не інтуїцію. Почніть спочатку з безпечніших кроків, а потім переходьте до меншої точності лише за потреби.
Різниця між обрізанням та дистиляцією для зменшення розміру моделі
Обрізання видаляє параметри «мертвого навантаження» та часто потребує перенавчання для відновлення якості, особливо якщо це робиться агресивно. Дистиляція навчає меншу модель учня імітувати поведінку більшого вчителя, і це може бути кращою довгостроковою рентабельністю інвестицій, ніж екстремальне квантування. Якщо вам потрібна менша модель, яка поводиться подібно та залишається стабільною, дистиляція часто є чистішим шляхом.
Як зменшити вартість виводу та затримку шляхом покращення обслуговування
Обслуговування – це те, де оптимізація стає відчутною: пакетна обробка підвищує пропускну здатність, але може призвести до збільшення затримки, якщо її перестаратися, тому налаштовуйте її ретельно. Кешування (швидке кешування та повторне використання KV-кешу) може бути величезним, коли контексти повторюються. Потокове виведення покращує сприйняту швидкість, навіть якщо загальний час схожий. Також зверніть увагу на накладні витрати на кожен токен у вашому стеку – невелика робота на кожен токен швидко накопичується.
Чому хвостова затримка така важлива під час оптимізації моделей ШІ
Середні показники можуть виглядати чудово, тоді як 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 - Повністю Шардедовані ДаніПаралель (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 - Документація виконання ONNX - onnxruntime.ai
-
NVIDIA - Документація TensorRT - docs.nvidia.com
-
NVIDIA - Квантовані типи TensorRT - docs.nvidia.com
-
NVIDIA - Системи Nsight - developer.nvidia.com
-
NVIDIA - Сервер виводу Triton - динамічне пакетування - docs.nvidia.com
-
Документація DeepSpeed - - 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: Швидка та ефективна з точки зору пам'яті точна увага з усвідомленням вводу-виводу - arxiv.org