Який GPU коштує найменше за однакового результату ML?

Визначити, що вважатиметься прийнятним результатом

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

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

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

Технічні джерела: MLCommons — сценарії, метрики та цільові показники якості

Підготувати вхідні дані, еталон і маніфест

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

Надайте кожному вхідному елементу стабільний ідентифікатор. Збережіть відбиток корпусу, порядок проходження, ревізію моделі та токенізатора, версії коду й залежностей. Маніфест також описує використані GPU, точність, квантизацію, компіляцію, бекенд уваги, політику padding і максимальну довжину. Інше обрізання змінило б роботу, яку потрібно порівнювати.

Зафіксуйте драйвер і бекенд, які фактично встановлені. Для варіанта AMD перевірте комбінацію системи, GPU, ROCm і фреймворку в офіційній матриці. Переглянута документація чи назва карти не доводять, що це середовище справді встановлено. Якщо програмні стеки відрізняються між двома запусками, висновок стосуватиметься повних протестованих конфігурацій.

Технічні джерела: AMD — матриця сумісності ROCm

Приклад: класифікувати ті самі 1000 текстів

Ось експеримент, який варто побудувати на ваших даних, без будь-яких припущень щодо продуктивності. Ви хочете класифікувати 1000 текстів за категоріями вашого проєкту. Відведіть 600 коротких записів, 300 середніх і 100 довгих; визначте межі за допомогою обраного токенізатора та збережіть репрезентативний розподіл класів. Цей поділ є прикладом протоколу, а не наданим корпусом чи універсальною рекомендацією щодо пропорцій.

Порівняйте батчі розміром 1, 4 і 8 з тією самою моделлю, тією самою точністю, тим самим порядком і тим самим правилом padding. Єдина змінна цієї першої серії — розмір батчу. Друга серія може змінити точність або обладнання, зберігши всі інші вибори явно зафіксованими. Групування за довжиною — це новий варіант, який потрібно задекларувати, оскільки воно змінює організацію роботи.

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

Розділіть запуск, прогрів і вимірюваний прохід

Фіксуйте необхідне завантаження, встановлення, завантаження в пам’ять і компіляцію окремо від стабілізованої обробки. Їх можна виключити з секундоміра проходу, хоча вони все одно займають частину часу оренди. Встановіть однакове правило прогріву для всіх варіантів: охоплені входи, кількість проходів і обробка перекомпіляцій. Не коригуйте це правило після того, як побачили, якому варіанту воно вигідне.

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

Операції CUDA є асинхронними: секундомір на хості має доти доти, доки не завершаться попередні операції, і зупинитися після завершення вимірюваної роботи. Події CUDA підходять для коректно визначеної області GPU. Для ізольованої операції torch.utils.benchmark.Timer підтримує прогрів і синхронізацію. Зберігайте однакові межі вимірювання між варіантами.

Технічні джерела: PyTorch 2.14 — асинхронне виконання CUDA · PyTorch — вимірювання за допомогою torch.utils.benchmark

Повторюйте та зберігайте невдалі запуски

Передбачте п’ять повних проходів на кожен варіант для цього першого порівняння. Чергуйте їхній порядок, наприклад 1–4–8, потім 4–8–1, потім 8–1–4, щоб один варіант не завжди був першим. Зберігайте політику щодо процесів, кешів і прогріву. Ці п’ять проходів описують вашу малу серію; самі по собі вони не доводять стабільність протягом тривалого періоду.

Один рядок необробленої таблиці представляє одну спробу проходження, включно із зупинкою. Він пов'язує варіант і корпус із параметрами, тривалістю та вердиктом якості. Поля expected_ids та observed_ids фіксують кількість записів; ids_match підтверджує рівність наборів, перевірену у файлах прогнозів, що зберігаються окремо. corpus_accepted містить вердикт проходження. Записуйте помилки та шлях вихідних даних у notes. Якщо якесь вимірювання відсутнє, залиште його комірку порожньою та вкажіть причину. Відсутність GPU не є вимірюванням нульових секунд чи нульових байтів.

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

Читати тривалості, не перебільшуючи значення п'яти спроб

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

Не подавайте p95, обчислений на п'яти прогонах, як надійну оцінку повільних випадків. Щоб дослідити затримку запитів, зберіть відповідний набір окремих часів разом зі сценарієм надходження та рівнем конкурентності. П'ять тривалостей корпусу й затримки 1 000 запитів — це не одна й та сама сукупність.

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

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

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

Зберігайте використані зерна (сід-значення) та детерміновані опції. PyTorch не гарантує повної відтворюваності між версіями, платформами чи запусками на CPU та GPU, навіть за однакового зерна. Тож уточніть, що саме ви прагнете відтворити: ідентичні виходи, обмежене числове відхилення чи прийнятну прикладну якість. Для стохастичного протоколу передбачте кілька спільних зерен і зберігайте їхні результати окремо.

Технічні джерела: PyTorch 2.14 — межі та обмеження відтворюваності

Використовуйте пам’ять як критерій здійсненності

Варіант має обробити весь корпус разом із його довгими входами, перш ніж порівнювати його вартість. Фіксуйте пік пам’яті на кожному пристрої та межі охоплення лічильника. У PyTorch memory_allocated відстежує тензори, а memory_reserved — пам’ять, якою керує алокатор: ці значення не додаються. Відповідні піки можуть виникати в різні моменти.

Ноутбук із теки про пам’ять допомагає розрізняти оцінку та спостереження. Його вправа не замінює вимірювання вашої моделі: завантажте ваше середовище, збережіть параметри та повторно виконайте ваше навантаження. Заявлена ємність на карту та ціна за пакет не дають змоги вивести пропускну здатність, з’єднання чи автоматичний розподіл моделі між кількома GPU.

Технічні джерела: PyTorch 2.14 — лічильники та алокатор пам’яті

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

Необхідна тривалість — це не лише сума часу роботи ядер GPU. Побудуйте вікно доступу від підготовки на орендованому ресурсі до отримання результатів: встановлення, перевірки, прогрів, порівняння, передбачені повторні запуски, оцінювання та експорт. Додайте періоди очікування, протягом яких вам усе ще потрібно зберігати оренду. Коли завдання перекриваються в часі, міркуйте в межах реального календарного графіка, а не додавайте їхню тривалість двічі.

Приклад розкладу, без припущення щодо швидкості: ви хочете зберегти доступ з понеділка, 9:00, до п’ятниці, 9:00, у тому самому часовому поясі та без переходу на літній час. Це вікно охоплює 96 годин. Воно перевищує 72 години пакета на 3 дні й уміщується в 168 годин пакета на 7 днів. Це не доводить, що ваші обчислення завершаться вчасно: їхню тривалість ще потрібно виміряти.

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

Розрахуйте понесені витрати за нашими пакетами

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

Наведені нижче ціни походять з нашого каталогу, версія від 24 вересня 2026 року. Вони ілюструють правило розрахунку, не встановлюючи, який GPU завершить ваше завдання найшвидше. Лот B200 уже містить дві карти: множити його ціну вдруге на два означало б рахувати ці карти двічі. Два лоти RTX 4090 на 7 днів коштують таким чином 220 USD; один лот із двох B200 на 7 днів коштує 2 071 USD.

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

Технічні джерела: IteraGPU — пакети з каталогу

Рахуйте корисні результати, а не повторення вимірювань

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

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

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

Завантажити протокол і зберегти багаторазовий доказ

Набір IteraGPU Lab v1 збирає матеріали цього порівняння та вимірювання пам'яті. Почніть із README і протоколу якості, потім доповніть необроблену таблицю своїми проходженнями. Клітинки продуктивності залишаються порожніми до виконання; тарифи є даними каталогу, відокремленими від вимірювань.

Щоб розрахувати вартість двох пакетів RTX 4090 на 7 днів, розмістіть calcul_forfaits.py і tarifs-forfaits.csv в одній теці, відкрийте термінал у цій теці та виконайте наведену нижче команду за допомогою Python 3.10 або новішої версії. Вона показує фіксовану ціну 220,00 USD за два GPU. Необов’язковий параметр --accepted-results приймає вашу цілу кількість окремих завершених і затверджених корисних корпусів. Пропустіть його, доки такого підтвердження немає: тоді скрипт обчислює лише фіксовану ціну, не вигадуючи вартість за результат.

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

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

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — повний набір ↓

  Архів скриптів, ноутбука, таблиць та інструкцій.

• Протокол якості ↓

  Входи, критерії прийняття та правила порівняння, які слід зафіксувати перед спробами.

• Таблиця необроблених результатів ↓

  Порожній аркуш для збереження параметрів, вимірювань, вердиктів і невдач.

• Розрахунок фіксованих цін ↓

  Розрахунок бюджету з ціною за пакет, тривалістю 3, 7 і 30 днів та затвердженими корпусами.

• Тарифи фіксованих цін ↓

  Знімок цін нашого каталогу, використаних у наданому розрахунку.

• Ноутбук для вимірювання пам’яті ↓

  Обчислення та вправа з вимірювання, які слід тлумачити разом із набором про пам’ять.

• Скрипт для вимірювання пам’яті ↓

  Версія вправи на Python із перевіркою середовища.

• Інструкції та передумови ↓

  Обсяг інструментів і процедура їх запуску та збереження виводів.

• Ліцензія на ресурси ↓

  Умови повторного використання оригінальних ресурсів набору.