GPU для досліджень ML · Оплата криптою без KYC
IteraGPU
Метод / Точність і компроміси

Обирайте квантизацію за результатами, а не за бітами.

Квантизація корисна, якщо вона зберігає вашу якість і водночас покращує реальне обмеження: пам'ять, затримку чи витрати. Порівняйте її з еталоном на тих самих вхідних даних, а потім окремо зафіксуйте формат ваг, точність обчислень і кеш. Файл, заявлений як чотирибітний, не означає, що все виконання використовує чотири біти, ані що воно буде швидшим. Рішення має залишатися прив'язаним до виміряного навантаження.

01 /

Описуйте варіант поза межами кількості бітів

Назвіть метод, його реалізацію, версію та точну ревізію артефакту. Два чотирибітні варіанти можуть використовувати різні представлення, групи, метадані та ядра. Відокремте формат зберігання ваг від формату операцій обчислення. Також занотуйте модулі, збережені з іншою точністю, і будь-яке перенесення на CPU.

У bitsandbytes квантизовані лінійні шари замінюють деякі звичайні шари; інші модулі дотримуються налаштованого dtype. Тож ця поведінка сама по собі не описує пік процесу. Прочитайте фактичну конфігурацію після завантаження, а потім переконайтеся, що варіант справді виконує очікувану обробку, а не інший програмний відкат.

Мінімальний маніфест для порівняння двох квантизованих артефактів
ПолеЩо потрібно зберегтиЯкої плутанини вдається уникнути
ПоходженняМодель, ревізія, токенізатор, метод і версіїПорівнювати дві різні моделі під однією назвою
ВагиФормат, біти, групи та виключені модуліОтотожнювати чотири біти з єдиним рецептом
ОбчисленняDtype, ядра та пристрої, які фактично використовуютьсяПлутати зберігання й виконання
ГенераціяКеш, контекст, обмеження виводу та паралелізмПриписувати вагам ефект, що походить від кешу
ВиготовленняМожливе калібрування та перевірка данихЗабувати, як було створено артефакт

Технічні джерела: Hugging Face Transformers 5.17 — квантовані шари та інші dtypes

02 /

Відокремлюйте калібрування від оцінювання

Деякі методи використовують приклади для підготовки квантизації. Зокрема, задокументована в Transformers процедура GPTQ вимагає набору для калібрування та токенізатора. Цей набір бере участь у створенні артефакту: він не є незалежним доказом якості. Інші методи йдуть іншим шляхом; не припускайте, що той самий протокол калібрування застосовний до всіх форматів.

Відведіть приклади для калібрування з дозволених даних для підготовки моделі, а потім зафіксуйте ідентифікатори, походження, довжини та застосоване перетворення. Залиште валідацію для вибору налаштувань, а фінальний тест — для підтвердження. Якщо ви обираєте кілька наборів для калібрування після порівняння їхніх балів, це дослідження є частиною розробки і має бути внесене до звіту.

Технічні джерела: Hugging Face Transformers 5.17 — калібрування квантизації GPTQ · Будуйте розділи за їхньою роллю

03 /

Обчисліть межу ваги, не подаючи її як пік

Візьмімо вигадану модель на три мільярди параметрів, усі збережені з однаковою кількістю бітів. Брутто-обсяг обчислюється як параметри × біти / 8. За 16 бітів отримуємо 6 мільярдів байтів; за 8 бітів — 3 мільярди; за 4 біти — 1,5 мільярда. Ці числа — ілюстративна арифметика, а не спостережувані розміри артефакту чи потреби запущеної моделі.

Брутто-різниця між 16 і 4 бітами становить 4,5 ГБ, тобто приблизно 4,191 ГіБ. Вона не враховує масштаби, метадані, неквантовані модулі, кеш і тимчасові файли. Вона дає змогу сформулювати гіпотезу щодо пам'яті, яку слід перевірити, не передбачаючи зменшення піку вчетверо. Розділ про пам'ять пояснює, як розділяти фази та інтерпретувати лічильники.

Обсяг у байтах = параметри × біти / 8. Обсяг у ГіБ = байти / 2³⁰.
Ілюстративний розрахунок для 3 мільярдів параметрів, рівномірно збережених — без додаткових витрат
Припущений форматБайтиДесяткові ГБПриблизні ГіБ
16 біт6 000 000 00065,588
8 біт3 000 000 00032,794
4 біти1 500 000 0001,51,397

Технічні джерела: NIST — двійкові та десяткові префікси · IteraGPU — оцінки та піки пам'яті

04 /

Змінюйте ваги перед зміною кешу

Почніть з базового варіанта, поведінка якого вам відома. Потім порівнюйте варіанти ваг з тим самим кешем, тими самими довжинами, тим самим батчем або тією самою конкурентністю. Якщо ви також змінюєте ці параметри, ви порівнюєте повні конфігурації: заявіть про це й не приписуйте всю різницю квантуванню ваг.

KV-кеш можна квантувати й сам, коли це дозволяють модель і рушій. Це окремий вибір. Документація Transformers, зокрема, зазначає, що квантований кеш може погіршити затримку для коротких контекстів, коли ще залишається достатньо пам'яті. Перевіряйте цю другу зміну в окремій серії; більше зекономленої пам'яті не гарантує кращої затримки.

Технічні джерела: Hugging Face Transformers 5.17 — квантований KV-кеш і компроміс щодо затримки

05 /

Приклад правила якості: невелике падіння може залишатися неприйнятним

Ось ілюстрація рішення, без запуску моделі. Проєкт оцінює 200 документів і визначає перед випробуваннями максимальну втрату в один відсотковий пункт щодо еталона. Він також вимагає щонайменше 90 % успішності на 20 критичних документах, включених до цих 200. Документ приймається лише тоді, коли всі його обов'язкові поля правильні.

Наведені нижче вигадані значення роблять A прийнятним за обома правилами: 94 % замість 95 %, і 18/20 на критичній групі. B не проходить обидва. A ще не можна оголосити переможцем: ні пік пам'яті, ні тривалість не наведені. До того ж підсумки не показують, які документи змінилися; перегляньте зіставлені помилки, щоб виявити нові важливі регресії.

Втрата A = 95 − 94 = 1 пункт; втрата B = 95 − 92 = 3 пункти. Один відсотковий пункт — це не відносне падіння на 1 %.
Вигадані показники якості для пояснення порогів; жодної виміряної продуктивності GPU
ВаріантПрийняті документиЗагальний показникПрийняті критичні випадкиВердикт за цими правилами
Еталон190 / 20095 %19 / 20 = 95 %Точка порівняння
A188 / 20094 %18 / 20 = 90 %Прийнятний за якістю
B184 / 20092 %16 / 20 = 80 %Відхилено

Технічні джерела: Розгляньте помилки, а не лише підсумок

06 /

Виконати порівняння, розбіжності якого можна пояснити

Спершу підготуйте контракт порівняння, потім файли результатів. Наведений протокол слід виконати на вашому навантаженні; попередні цифри його не замінюють. Якщо варіант не завантажується або не має потрібних операторів, збережіть цю невдачу як інформацію про сумісність.

  • Зафіксуйте корпус, еталони, модель, токенізатор, промпт і правила виводу; збережіть довгі та складні випадки ідентифікованими.
  • Зафіксуйте калібрування, експортований артефакт і чинну конфігурацію. Перевірте використані пристрої та можливі передачі CPU/GPU.
  • Відокремте створення, завантаження, прогрів і стабілізовану обробку. Використовуйте ті самі межі вимірювання та зберігайте необроблені повтори.
  • Фіксуйте пік для кожного пристрою та кожної фази; тримайте allocated і reserved окремо. Не додавайте ці лічильники й не віднімайте їхні незалежні максимуми.
  • Оцініть формат, вміст і узгоджені підгрупи, а потім зіставте помилки за ідентифікатором.
  • Перезавантажте обраний артефакт у новому процесі та повторіть визначену перевірку. Результат, отриманий до експорту, не підтверджує автоматично перезавантаження.

Технічні джерела: Правильно вимірювати пам'ять · Визначити повтори та хронометраж

07 /

Пов'язати компроміс із понесеними витратами

Економія пам'яті може розширити можливі конфігурації, дозволити більший паралелізм або просто залишити запас. Вона не зменшує витрати автоматично. Якщо період, зарезервовані партії та прийняті результати залишаються тими самими, вартість пакета залишається тією самою, навіть якщо один прохід швидший.

Включіть у графік можливе калібрування, квантування, оцінювання, відхилені спроби та перезавантаження. Потім порівняйте повні пакети на 3, 7 або 30 днів між варіантами, що задовольняють ваші критерії. Співвідношення на корисний корпус обчислюється лише за фактично завершеними й прийнятими корпусами; повтори хронометражу не створюють нових результатів.

Якщо один орендований ресурс слугує для порівняння кількох варіантів, його сума є спільною витратою кампанії. Не нараховуйте подумки весь пакет кожному варіанту й потім не додавайте ці суми як окремі реальні витрати. Щоб виділити аналітичну частку, оголосіть домовленість; вона не змінює загальну понесену суму.

Технічні джерела: IteraGPU — повний пакет і вартість експерименту

08 /

Підсумувати конфігурацією та її обмеженнями

Фінальне рішення називає артефакт, середовище, охоплене навантаження, досягнутий критерій якості та покращене обмеження. Якщо варіанти близькі, збережіть цю невизначеність і віддайте перевагу вибору, який ви вмієте перезавантажити й пояснити. Кількість бітів сама собою не є порядком переваги.

Висновок на короткому корпусі не поширюється автоматично на довгі контексти, іншу мову чи більшу кількість одночасних запитів. Квантування, обране для інференсу, також не визначає параметри, які можна навчати під час fine-tuning. Тримайте ці питання окремо й підтверджуйте обраний варіант на відкладеному тесті.

Практичні питання

Чи завжди чотири біти споживають учетверо менше пам'яті, ніж шістнадцять?

Обсяг необроблених ваг за однакового зберігання відповідає цьому співвідношенню. Повний пік також охоплює метадані, модулі в інших форматах, кеш і тимчасові дані. Виміряйте реальне виконання, перш ніж оголошувати загальний виграш.

Чи можу я калібрувати квантування на своєму фінальному тесті?

Тоді цей тест долучився б до створення артефакту й перестав би бути незалежним оцінюванням. Готуйте калібрування з набором, дозволеним для розробки, а потім збережіть окреме підтвердження на відкладеному наборі.

Чи завжди менший варіант дешевший в експлуатації?

Ні. Бюджет залежить від періоду та задіяних партій, від підготовки та прийнятних корисних результатів. Зменшення пам'яті без зміни цих елементів може поліпшити маржу, не зменшуючи суму оренди.