# Оптимизация затрат на GPU начинается с характера нагрузки

> Оптимизация затрат на GPU для стартапов: считайте полезную работу, подбирайте память, безопасно используйте Spot и сравнивайте с API.

Оптимизация затрат на GPU не работает, когда стартап считает любой час ускорителя одинаковым. Дешевый час, после которого обучение приходится запускать заново, дорогая карта, простаивающая за тихой конечной точкой, и вызов API, снимающий с команды операционную нагрузку, относятся к разным статьям учета. Сравнивайте стоимость завершенной единицы работы, а не цену рядом с названием GPU.

Я видел, как основатели согласовывали неплохую облачную скидку и при этом не замечали куда больших потерь: ноутбуки работали всю ночь, реплики оставались рассчитанными на всплеск во время запуска, который больше не повторился, а учебные задания не переживали прерывание. Исправление начинается с характера нагрузки. Обучение, пакетный инференс и интерактивный инференс требуют разной емкости, разных способов восстановления и разных решений по задержке.

## Считайте цену каждого готового результата, а не часа GPU

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

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

Для измеренного периода используйте простое уравнение:

```text
fully_loaded_cost = gpu_compute + host_compute + storage + transfer + api_fees + operator_time
useful_unit_cost = fully_loaded_cost / accepted_units
```

Время операторов тоже учитывайте, если выбор меняет объем ручной работы. Если инженер тратит четыре часа в неделю на восстановление недоступной Spot-мощности, оцените этот труд по полной реальной ставке. Если API избавляет от обновления драйверов, настройки автомасштабирования и ночных вызовов, зачтите сэкономленные часы. Не объявляйте труд бесплатным только потому, что зарплаты проходят по другой бюджетной статье.

Помечайте расходы по нагрузке, среде, модели, владельцу и типу покупки. Общий узел с GPU без привязки к заданиям дает счет, а не доказательства. Как минимум передавайте идентификатор задания в планировщик, журналы приложения и экспорт затрат. Затем связывайте готовые результаты и ошибки с тем же идентификатором.

Месячная сумма также скрывает время. Отдельно записывайте время в очереди, время запуска, активные вычисления, сохранение контрольных точек и простой. Пакетная система может выглядеть занятой десять часов, хотя ядра исполнялись три часа. Интерактивная конечная точка может показывать высокую загрузку пять минут, а остаток дня пустовать. Обоим случаям нужна временная шкала, одного среднего недостаточно.

## Объем памяти и загрузка вычислений отвечают на разные вопросы

Подбор размера начинается с объема памяти, после чего команда проверяет пропускную способность. Часто 70 процентов занятой памяти принимают за 70 процентов загрузки GPU. Это неверно. Веса модели могут занимать почти всю память устройства, пока вычислительные блоки ждут запросов, предварительной обработки на CPU, чтения из хранилища или синхронизации между воркерами.

Собирайте данные при обычном трафике, а не во время специально подобранного теста. В документации NVIDIA указано, что показатель загрузки GPU в `nvidia-smi` измеряет долю недавнего интервала, в течение которой выполнялось хотя бы одно ядро. Загрузка памяти показывает время чтения или записи памяти устройства, а `memory.used` показывает выделенную кадровую память. Эти три числа описывают разные ограничения.

Эта команда дает понятный срез, который стартап может собрать перед сменой типа инстанса. Пример ответа сохраняет ту же иерархию полей, которую выводит утилита:

```bash
$ nvidia-smi -q -d MEMORY,UTILIZATION,POWER
GPU 00000000:01:00.0
    FB Memory Usage
        Total : 24564 MiB
        Used : 9180 MiB
    Utilization
        GPU : 37 %
        Memory : 21 %
    GPU Power Readings
        Average Power Draw : 118.42 W
```

Запускайте ее с интервалом в течение обычного окна нагрузки, а в сборщике добавляйте метку времени и идентификатор задания или реплики. Вывод разделяет устройство, общий и выделенный объем памяти, вычислительную активность, работу с памятью и мощность. Одна запись почти ничего не доказывает. Перцентили по полным заданиям показывают постоянную нагрузку, всплески и промежутки простоя.

Записывайте и метрики приложения: размер пакета, длину входа и выхода, число токенов или изображений в секунду, задержку запроса, глубину очереди, ошибки и завершенные единицы. Метрики GPU объясняют состояние машины. Метрики приложения показывают, получил ли клиент полезную работу. Для обоих наборов нужны общие временные метки.

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

Холодный запуск измеряйте отдельно. Загрузка весов, компиляция ядер, прогрев кэшей и скачивание файлов модели могут занимать большую часть короткого задания. Если пятиминутная задача две минуты готовится, более быстрый GPU может не помочь. Подготовленный образ, локальный кэш модели или объединение задач в более длинные задания иногда экономят больше, чем дешевый ускоритель.

## Сначала подберите размер модели, потом размер парка

Выберите самый маленький ускоритель, который вмещает модель, пиковую рабочую память и проверенный запас при нужном размере пакета. Затем протестируйте полный путь запроса. Сравнение каталожных характеристик по номинальной памяти и теоретической вычислительной мощности не учитывает узкие места хоста, поддержку ядер, особенности точности и архитектуру модели.

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

Сначала уменьшайте нагрузку и только потом покупайте более крупную карту. Квантизация может сократить расход памяти и поднять пропускную способность, но разрешить ее можно лишь после проверки качества результата. Более короткий контекст, меньшие изображения, меньшее число генерируемых вариантов и небольшая модель для простых запросов убирают работу, которую клиент не ценит. Такие изменения требуют продуктового решения, их нельзя незаметно спрятать в настройке инфраструктуры.

Пакетная обработка повышает эффективность вычислений, если нагрузка допускает ожидание. Задайте максимальный размер пакета и максимальную задержку в очереди. Без ограничения задержки тихий сервис может слишком долго ждать заполнения пакета. Без ограничения размера всплеск трафика может привести к нехватке памяти. После каждого изменения измеряйте и пропускную способность, и хвостовую задержку.

Kubernetes сам по себе не делает целый GPU экономичным. Официальная документация по планированию говорит, что ресурсы GPU обычно доступны как расширенные ресурсы, например `nvidia.com/gpu`, а ограничение pod одновременно становится его запросом. Pod, запросивший один GPU, резервирует одну планируемую единицу, даже если процесс использует лишь часть устройства. Дополнительные pod не устраняют фрагментацию, если плагин устройства и оборудование не поддерживают общий доступ.

Для совместимых серверных карт NVIDIA технология Multi-Instance GPU может разделить один физический GPU на изолированные экземпляры с назначенными вычислительными ресурсами и памятью. Разделение по времени тоже повышает параллелизм, но у него другая модель изоляции и производительности. Перед объединением производственных сервисов проверьте влияние соседней нагрузки, ограничения памяти, обработку сбоев и метки планировщика. Не называйте ни один из этих методов бесплатной мощностью. Вы меняете операционную сложность на более высокую занятость.

Разделяйте интерактивный и пакетный трафик по разным очередям, даже если в итоге они делят оборудование. Онлайн-запросам нужны ограниченное ожидание и запас мощности. Пакетные задания могут заполнять провалы и уступать место при росте спроса. Одна очередь в порядке поступления позволяет крупному фоновому заданию заблокировать клиентский трафик, и выигрыш в загрузке превращается в сбой продукта.

## Spot-мощность безопасна только для одноразовых воркеров

GPU в Spot подходят, когда воркер может исчезнуть, а задание можно недорого продолжить или запустить заново. Большая скидка в облачной консоли не делает их безопасными. Безопасность задает модель состояния. Храните долговечные входные данные, контрольные точки, владение очередью и фиксацию результата за пределами инстанса.

Предупреждения провайдеров короткие. Документация AWS EC2 говорит, что уведомление о прерывании Spot приходит за две минуты. Google Cloud описывает период штатного завершения по возможности длительностью до 30 секунд для обычной Spot VM. Azure сообщает об удалении с уведомлением не более чем за 30 секунд и без гарантии высокой доступности. Считайте каждое уведомление возможностью прибраться, а не основным способом восстановления. Процесс или хост может упасть без вежливого обратного отсчета.

Обучение работает на Spot, когда достаточно часто пишет пригодные контрольные точки. Нужный интервал определяет расчет затрат, а не привычка. Пусть `C` обозначает время записи контрольной точки, `I` интервал между точками, а `R` ожидаемое время повторных вычислений после потери. Частые точки повышают расходы на хранение и паузы, редкие увеличивают объем повторной работы. Измерьте длительность сохранения и историю прерываний для каждого пула мощности, затем выберите интервал с минимальной суммой накладных расходов и повторных вычислений.

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

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

Проверяйте поведение при прерывании намеренно. AWS советует инициировать прерывание Spot через Fault Injection Service, который во время теста отправляет такое же двухминутное уведомление. Смысл совета в принудительном сбое, а не в кнопке конкретного поставщика. Завершайте воркер во время загрузки модели, при отправке контрольной точки, после записи результата и до подтверждения очереди. Проверяйте и корректность, и итоговую стоимость.

## Возобновляемому воркеру нужен явный контракт

Система, устойчивая к прерываниям, определяет, что переживает сбой, кто повторяет работу и когда задание считается завершенным. Если ответы хранятся только в памяти инженера, следующее событие мощности обнаружит другое толкование. Запишите контракт в метаданных задания и в логике воркера.

Компактная запись задания может содержать нужное состояние:

```yaml
job_id: train-2026-08-09-017
input_version: corpus-42
model_revision: candidate-118
checkpoint_uri: object-store/checkpoints/train-2026-08-09-017/latest
checkpoint_every_steps: 800
max_attempts: 6
output_uri: object-store/results/train-2026-08-09-017
commit_marker: object-store/results/train-2026-08-09-017/COMPLETED
```

Сначала воркер проверяет маркер завершения. Если он существует и совпадает с ожидаемыми версиями входа и модели, воркер подтверждает элемент очереди без повторного запуска. В противном случае он загружает последнюю действительную контрольную точку, выполняет работу, пишет версионный результат, проверяет его, создает маркер завершения и только после этого подтверждает элемент. Маркер не дает повторной попытке принять частичную загрузку за готовый результат.

Не храните единственную контрольную точку на диске инстанса. Подключенный постоянный том может пережить некоторые остановки, но способен привязать восстановление к одной зоне или продолжить начислять плату за хранение после удаления инстанса. Объектное хранилище дает планировщику больше вариантов размещения. Отправляйте данные асинхронно лишь в том случае, если локальная контрольная точка остается действительной до подтверждения удаленной записи.

Разнообразие пула важнее хитрой максимальной ставки. Запрос, ограниченный одной моделью GPU в одной зоне, будет ждать всякий раз, когда иссякнет именно этот пул. Поддерживайте несколько классов ускорителей, зон и размеров пакета за общей меткой возможностей. В рекомендациях AWS по Spot прямо сказано о гибкости по типам инстансов и зонам доступности, а также о размещении с учетом доступной мощности. Для парков GPU этот совет особенно уместен, потому что отдельные пулы ускорителей бывают небольшими.

Сохраните запасной маршрут на мощность по требованию с потолком бюджета. Когда повторы на Spot превышают допустимую задержку или число попыток, перенесите задание на стабильную мощность, отложите его или явно завершите ошибкой. Бесконечные повторы способны стоить меньше в час, но больше за готовое задание. Показывайте стоимость повторов и возраст очереди, чтобы планировщик сделал выбор раньше, чем клиент спросит о результате.

## API выигрывают, когда продают недостижимую для вас загрузку

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

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

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

```text
api_monthly = accepted_units * api_cost_per_accepted_unit
self_hosted_monthly = gpu_hours * blended_hourly_cost + storage + transfer + operations
break_even_units = self_hosted_monthly / api_cost_per_accepted_unit
```

Уравнению нужны сценарии, потому что `gpu_hours` не всегда остается постоянным. Постройте как минимум сценарии низкого, ожидаемого и высокого спроса. При низком спросе учтите реплики, нужные для доступности, даже если трафик почти их не занимает. При высоком спросе включите рост очереди, дополнительные реплики и ограничения частоты API. Денежные расходы и сервисный риск сравнивайте отдельно, чтобы дешевый вариант не скрывал недопустимую зависимость.

Перед переходом прогоните теневую выборку. Отправьте фиксированный набор оценки через API и размещенную модель, затем сравните долю приемки, задержку и стоимость. Для субъективных результатов может понадобиться проверка человеком. Сохраните одинаковые подсказки, параметры выборки и постобработку. Сравнивать цены разных уровней качества бессмысленно.

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

Асинхронные режимы провайдера могут изменить сравнение. Например, официальная документация OpenAI Batch API описывает окно выполнения в 24 часа со скидкой 50 процентов. Конкретный сервис может подходить или не подходить вашей нагрузке, но общий принцип остается: не оценивайте задания, допускающие задержку, по интерактивному тарифу API. Узнайте у каждого провайдера о пакетной обработке, кэшированном входе, зарезервированной пропускной способности и минимальных обязательствах, затем моделируйте только те варианты, которые продукт действительно может использовать.

## Собственные GPU требуют постоянного спроса и плана выхода

Покупка оборудования может выиграть, если у стартапа есть стабильный спрос, высокая занятость, подходящее помещение и люди для обслуживания. Одной цены покупки для такого вывода недостаточно. Амортизируйте серверы, сеть, запасные детали, гарантии, место в стойке, электричество, охлаждение, установку и стоимость связанного капитала. Добавьте покрытие отказов и время сотрудников.

Рассчитайте эффективную почасовую стоимость по консервативному числу полезных часов:

```text
effective_owned_hour = (purchase + facility + power + support + operations - resale_value) / useful_gpu_hours
```

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

Облачные обязательства несут похожую ловушку. Скидка на один или три года экономит деньги лишь тогда, когда нагрузка потребляет выбранную мощность. Фиксируйте стабильную основу, а не прогноз запуска. Неопределенный рост оставляйте на гибкой мощности, пока измерения не покажут нижнюю границу. Скидка на простаивающее резервирование все равно остается потерей.

Собственное оборудование также меняет планирование отказов. Облачный регион может предложить другой инстанс после сбоя хоста, хотя дефицит GPU способен задержать запуск. В небольшом локальном кластере совместимой замены может не оказаться. Оцените хотя бы один домен отказа, срок замены, резервные копии и удаленный доступ. До покупки решите, может ли продукт ждать ремонта оборудования.

Притяжение данных может говорить в пользу покупки, когда крупные закрытые наборы уже находятся рядом с серверами, а многократная передача в облако или требования соответствия создают лишние трудности. Оно может говорить и в пользу облака или API, если клиентам нужны определенные регионы либо быстрое географическое расширение. Запишите ограничение прямо. Команды ошибаются, когда превращают нормативное требование в смутное предпочтение и покупают оборудование до подтверждения со стороны юристов или клиентов.

План выхода называет событие, которое меняет решение. Например, новая модель перестала помещаться в память, занятость два месяца держится ниже утвержденной границы, закончилась поддержка или стоимость единицы API упала ниже стоимости собственного оборудования. Заранее назначьте ответственного за проверку условия и определите судьбу оборудования. Остаточная стоимость должна попасть в первоначальное одобрение, а не в удивленный разговор через два года.

## Контроль затрат должен жить в планировщике и продукте

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

Показывайте продуктовым командам затраты в единицах, которыми они управляют. Разместите стоимость принятого изображения рядом с настройками генерации, стоимость готовой модели-кандидата рядом с конфигурацией эксперимента, а стоимость клиентского запроса рядом с маршрутом модели. Облачный счет приходит слишком поздно и скрывает причину в общей сумме. Ежедневная стоимость единицы обнаружит изменение длины контекста, размера пакета или ошибку повторов до закрытия месяца.

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

Для мощности разработки нужна отдельная политика. Инженерам важна быстрая итерация, но сессии в ноутбуке не нужен ускоритель во время обеда или ночью. Храните описание среды, программу и данные вне инстанса, предупреждайте перед выключением, затем автоматически останавливайте простаивающую мощность. Дайте разработчику простой способ запросить дополнительное время с причиной и новой датой окончания. Так работа не прерывается, а забытые машины становятся видимыми.

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

Переход между этапами эксперимента должен требовать доказательств. Небольшая выборка обнаружит сломанные данные, неподдерживаемый режим точности, резкий рост памяти или валидатор, который отклоняет все результаты. Только прошедшие выборку задания должны получать полный набор данных и увеличенный бюджет. Этот фильтр экономит вычисления и не мешает серьезным экспериментам, потому что убирает запуски без шанса дать принятого кандидата.

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

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

Удаляйте устаревшие артефакты так же внимательно, как останавливаете вычисления. Старые контрольные точки, дубликаты образов моделей, неподключенные диски, подробные журналы и кэшированные наборы данных могут остаться после исчезновения GPU. Определите срок хранения для каждого типа артефакта, а модели релиза и аудиторские записи защищайте явными запретами удаления. Хранилище кажется небольшим на фоне ускорителей, поэтому незаметно растет и позже ограничивает выбор размещения.

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

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

Основателям без надежной привязки расходов Team & AI Audit от oleg.is поможет сопоставить инженерные затраты и найти экономию до обязательств по парку. Заявленная цена работы составляет $5,000, срок равен пяти рабочим дням, а гарантия обещает не меньше $50,000 выявленной годовой экономии или возврат стоимости аудита. Такая проверка все равно должна дать измерения нагрузки и запись решения, описанные выше, потому что ни один советник не заменит данные производства.

Назначьте одного человека владельцем стоимости принятой единицы и дайте ему право менять политику очередей, выбор инстансов и маршрутизацию API в согласованных пределах. Затраты на GPU перестают расползаться, когда у каждого задания есть экономический контракт: сколько оно вправе потратить, как переживает сбой и когда выполнило достаточно полезной работы, чтобы попасть в учет.