Какой 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, рассчитанный по пяти прогонам, как устойчивую оценку медленных случаев. Чтобы изучать задержку запросов, соберите подходящий набор отдельных времён со сценарием поступления и уровнем параллелизма. Пять длительностей корпуса и задержки 1000 запросов — это не одна и та же популяция.

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

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

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

Фиксируйте использованные seed и детерминированные опции. PyTorch не гарантирует полную воспроизводимость между версиями, платформами или запусками на CPU и GPU, даже при одном и том же seed. Поэтому уточните, что именно вы хотите воспроизвести: идентичные выходы, ограниченное числовое расхождение или приемлемое прикладное качество. Для стохастического протокола предусмотрите несколько общих seed и сохраняйте их результаты отдельно.

Технические источники: 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 с проверкой окружения.

• Инструкции и требования ↓

  Область применения инструментов и процедура их запуска и сохранения результатов.

• Лицензия ресурсов ↓

  Условия повторного использования оригинальных ресурсов папки.