Считаем стоимость обучения модели на своём железе

MAATRIX

Перед тем как запускать обучение или дообучение (fine-tuning) модели, разумно посчитать, во что это обойдётся — а не узнавать сумму по факту из счёта провайдера. Проблема в том, что большинство расчётов в интернете либо оперируют выдуманными «часами обучения», либо сравнивают только цену GPU в час, забыв про хранение датасета, чекпоинты и электричество. Ниже — методика, которая считает честно: как прикинуть время тренировки под вашу задачу, из каких статей реально складывается счёт и когда разовая аренда GPU выгоднее постоянного владения железом.

Из чего складывается полная стоимость обучения

Сумма в счёте за обучение — это не только «цена GPU в час умножить на часы». Полная стоимость (TCO конкретного обучающего прогона) собирается из четырёх статей, и пропуск любой из них искажает сравнение вариантов.

• Аренда вычислительной мощности. Стоимость GPU-сервера за время, пока идёт тренировка: от загрузки датасета и весов до сохранения финального чекпоинта.
• Хранение данных. Датасет (сырой и токенизированный), промежуточные и финальные чекпоинты, логи экспериментов — всё это занимает диск и часто продолжает копиться после того, как GPU уже выключен.
• Электричество и охлаждение — актуально только если речь о собственном физическом железе, а не об арендованном сервере. Провайдер включает эти расходы в тариф аренды, вы их отдельно не видите и не считаете.
• Время инженера на подготовку датасета, отладку конфигурации, перезапуски при сбоях — по-хорошему тоже статья расходов, но в этой статье мы сосредоточимся на прямых денежных затратах на железо и хранение, а трудозатраты оставим за скобками осознанно: они сильно зависят от опыта команды и не поддаются универсальной формуле.

Ключевая методическая ошибка — сравнивать только первую статью (аренду GPU) и забывать про хранение и электричество. При разовом обучении небольшой LoRA-адаптации это не критично: хранение копеечное, электричество не считается вовсе, потому что железо арендованное. Но при регулярном переобучении на своём сервере хранение датасетов и чекпоинтов за несколько циклов и электричество за месяцы работы могут набежать в заметную долю общего счёта.

Как прикинуть время обучения, не выдумывая цифр

Самая частая просьба — «сколько времени займёт обучение» — не имеет универсального ответа, потому что время зависит от слишком многих переменных: размера модели, объёма датасета, числа эпох, длины последовательности, батча, конкретной карты и версии библиотек. Любая цифра «обучение 7B-модели займёт 14 часов» без указания на конкретное железо и датасет — это выдумка, даже если она выглядит правдоподобно. Вместо готовой цифры — рабочая методика прикидки.

Шаг 1. Разложите объём работы на понятные множители.

объём_вычислений ≈ размер_датасета_в_токенах × число_эпох × коэффициент_метода

Где коэффициент метода отражает, что вы обучаете:

• полное дообучение (full fine-tuning) — обновляются все веса, обратный проход и шаг оптимизатора считаются по всей модели;
• LoRA / QLoRA — обучается только небольшой адаптер, прямой проход считается по полной модели, но обратный проход и обновление весов — по кратно меньшему числу параметров, отсюда заметно меньшая нагрузка на compute и на VRAM.

Число эпох для инструктивного дообучения на своих данных обычно небольшое (единицы), для адаптации к узкому домену или стилю — может быть больше. Точное число вы либо берёте из методических рекомендаций к конкретному методу обучения, либо подбираете экспериментально, отслеживая, когда loss на валидации перестаёт падать.

Шаг 2. Сделайте контрольный прогон вместо гадания.

Самый надёжный способ узнать реальное время — не считать по формулам производительности карты (эти цифры производителя редко достижимы на практике, а конкретную зависимость от версии CUDA, batch size и длины последовательности формула не учтёт), а измерить самостоятельно:

1. Возьмите 1-2% датасета (или фиксированное число шагов, например 200-500).
2. Запустите обучение на арендованном GPU с целевой конфигурацией
   (batch size, длина последовательности, precision).
3. Замерьте время на шаг/итерацию по логам обучающего фреймворка.
4. Экстраполируйте: полное_время ≈ (время_на_шаг × число_шагов_на_эпоху × число_эпох).

Это занимает 15-30 минут аренды GPU и даёт число, привязанное к вашему реальному датасету и железу, а не к чьему-то бенчмарку из статьи. Прибавьте запас 20-30% на время загрузки данных, валидационные проходы, чекпоинты и повторные попытки при сбое конфигурации — первый прогон почти никогда не проходит с первого раза без правок.

Шаг 3. Отдельно закладывайте время на эксперименты.

Итоговое обучение — не единственный расход времени GPU. Перед ним обычно идут прогоны на подбор learning rate, batch size, проверку, что пайплайн вообще работает на маленьком куске данных. Реалистичная оценка включает не только «финальный прогон», но и 2-4 коротких отладочных запуска до него.

Аренда GPU под конкретную задачу обучения

Когда время обучения прикинуто (по шагам выше), стоимость аренды считается как:

стоимость_аренды ≈ тариф_за_час_GPU × (время_обучения + запас_на_эксперименты)

Точный тариф за час конкретной карты у конкретного провайдера — величина изменчивая (она зависит от класса карты, объёма VRAM, региона и текущих условий провайдера), поэтому здесь мы её не подставляем: смотрите актуальный тариф на странице провайдера в момент расчёта, а не в статье полугодовой давности. Методика важнее конкретного числа: держите в голове, что окончательная сумма — это тариф, умноженный на реальное (измеренное на контрольном прогоне) время, плюс отладочные прогоны, а не только «чистое» время финальной тренировки.

Несколько практических моментов, которые снижают счёт:

• Останавливайте инстанс сразу после сохранения финального чекпоинта, а не оставляйте его висеть «на всякий случай» — почасовая аренда считает именно часы работы, не полезной нагрузки.
• Сохраняйте промежуточные чекпоинты на постоянное хранилище по ходу обучения, а не только в конце — сбой на 90% прогона без сохранённых чекпоинтов означает повторную оплату всего времени с нуля.
• Проверяйте конфигурацию на маленьком датасете перед полным прогоном — это дешевле, чем обнаружить ошибку в разметке данных или гиперпараметрах после нескольких часов аренды дорогой карты.
• Если задача — не полное обучение с нуля, а дообучение существующей модели, обычно достаточно карты меньшего класса и заметно меньше времени: сравните варианты в статье LoRA-дообучение своей модели на VPS, где разобрано, какие ресурсы нужны именно под LoRA.

Хранение датасета и чекпоинтов

Хранение — статья расходов, которая продолжает капать и после того, как GPU выключен, а её часто вообще не включают в расчёт.

Что именно занимает место:

• Сырой датасет — исходные файлы до обработки.
• Токенизированный/предобработанный датасет — часто больше сырого, потому что включает служебные структуры и может дублироваться под разные форматы или разбивки на train/val.
• Чекпоинты во время обучения — при полном дообучении чекпоинт включает не только веса модели, но и состояние оптимизатора (для Adam это дополнительные буферы на каждый параметр), поэтому один полный чекпоинт может быть в несколько раз больше, чем сама модель в инференс-формате. При LoRA-адаптации чекпоинт — это только веса адаптера, на порядки меньше: обычно десятки-сотни мегабайт против десятков гигабайт у полного дообучения крупной модели.
• Финальные веса — то, что останется нужным после обучения и что вы будете разворачивать для инференса.

Практическая рекомендация по хранению:

- Держите на быстром (NVMe) диске только то, что нужно во время активного обучения:
  текущий датасет и последние 1-2 чекпоинта.
- Старые промежуточные чекпоинты переносите на более дешёвое холодное хранилище
  сразу после того, как убедились, что более новый чекпоинт лучше.
- Сырой датасет после токенизации можно архивировать отдельно от рабочей копии —
  он нужен редко, только если понадобится пересобрать токенизацию другим методом.

Полную методику расчёта стоимости хранения на длинном горизонте (что дороже — облако, диск на арендованном сервере или свой) разбирает статья считаем стоимость хранения терабайта на пять лет — та же логика применима к датасетам и чекпоинтам, только горизонт обычно короче.

Электричество и охлаждение — если железо своё

Это статья расходов, которая существует только при обучении на собственном физическом сервере. При аренде GPU-сервера у провайдера электричество и охлаждение уже включены в тариф — вы платите за час аренды, и отдельно считать киловатты вам не нужно. Дальше речь именно про свою видеокарту или сервер дома/в своей стойке.

Методика расчёта:

стоимость_электричества ≈ (мощность_карты_в_кВт × коэффициент_загрузки)
                           × время_обучения_в_часах
                           × тариф_за_кВт·ч

Мощность карты (TDP) — паспортная характеристика производителя, её можно смело брать из спецификации, это не «выдуманный бенчмарк производительности», а заявленная граница энергопотребления. Коэффициент загрузки во время активного обучения обычно близок к максимальному — карта почти всё время выполняет вычисления, в отличие от инференса, где случаются простои между запросами.

К этому добавляется охлаждение: воздух, разогретый видеокартой под полной нагрузкой на протяжении всего обучения, нужно куда-то деть, и это дополнительная нагрузка на систему охлаждения помещения — учитывайте надбавку (ориентировочно, конкретная цифра зависит от вашей системы вентиляции и климата) поверх прямого энергопотребления карты, а не только саму карту.

Важный нюанс: обучение — это часы или сутки почти непрерывной полной нагрузки на карту, в отличие от разовой генерации или редких запросов инференса. Именно поэтому вопрос электричества при обучении на своём железе весомее, чем при простом инференсе — там же разбирается сравнение CPU или GPU для локальной LLM: что выгоднее применительно к энергопотреблению при разных сценариях нагрузки.

Разовая аренда против владения: когда выгодно что

Вопрос «арендовать GPU под обучение разово или купить/держать сервер постоянно» решается не вкусом, а частотой использования. Логика простая: у аренды нет постоянных издержек, но почасовая ставка выше в пересчёте на «чистый» час полезной работы; у владения есть постоянные издержки (амортизация железа, электричество даже в простое, обслуживание), но предельная стоимость каждого следующего обучения — почти только электричество.

Точка безубыточности считается по частоте обучающих прогонов в выбранный период (месяц, квартал), а не по абсолютной сумме:

точка_безубыточности (число прогонов в период) =
    постоянные_издержки_владения_за_период
    ÷ (стоимость_аренды_на_один_прогон − предельная_стоимость_прогона_при_владении)

Где «предельная стоимость прогона при владении» — это в основном электричество на этот конкретный прогон (железо уже куплено и простаивает независимо от того, используете вы его или нет). Если реальная частота ваших обучающих прогонов в периоде ниже расчётной точки — разовая аренда дешевле; выше — постоянное владение окупает себя.

На практике постоянное владение GPU-сервером под обучение оправдано в сценариях вроде регулярного дообучения модели на потоке свежих данных (еженедельно или чаще), непрерывных экспериментов исследовательской команды или частых A/B-прогонов с разными гиперпараметрами. Разовое дообучение под конкретный проект, редкая LoRA-адаптация под новый стиль или единичный эксперимент — почти всегда дешевле и проще закрыть разовой арендой, без обязательств по обслуживанию железа. Подробный разбор той же логики окупаемости — с готовой формулой под сравнение почасовой аренды и аренды выделенного сервера — в статье точка окупаемости GPU-сервера против аренды, а вопрос покупки видеокарты в собственность против любой аренды разобран в статье своя видеокарта против аренды GPU: что выгоднее и когда.

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

Частые вопросы