автор команда XIMTRX

Bare metal или cloud GPU: реальность cost-per-token

Для валидаторов мы почти всегда садимся на железо. Для GPU-инференса расклад другой. Разбираем, где cloud GPU честно выигрывает, где bare metal рвёт по cost-per-token и какие косты облака не видны в прайсе.

#ai #llm #gpu #infrastructure #cost-per-token

Для валидаторов мы почти всегда приходим к железу: latency-хвост и slashing-экспозиция перевешивают всё остальное. Для GPU-инференса расклад другой, и здесь мы делим клиентскую нагрузку между bare metal и облаком гораздо ровнее. Дальше разбираем, почему GPU-задача считается иначе, где облако выигрывает честно и где железо рвёт его по cost-per-token.

Почему GPU считается не так, как валидатор

У валидатора нагрузка ровная и предсказуемая: он подписывает круглосуточно с почти постоянным профилем. GPU-инференс почти никогда не бывает ровным. Дневной трафик скачет, ночью часть карт простаивает, запуск новой фичи может удвоить нагрузку за неделю. А сама карта это самая дорогая единица в стойке, и каждый час её простоя это деньги, выкинутые в cost-per-token.

Поэтому ключевой вопрос для GPU не «cloud дороже железа за час» (дороже, всегда), а «какая доля оплаченного GPU-времени реально перешла в токены». Карта, занятая на 80 процентов на своём железе, и карта, занятая на 30 процентов в облаке, дают совершенно разный cost-per-token, даже если облачная почасово выглядит сопоставимо.

Cloud GPU: где он честно выигрывает

Облако в GPU-задачах решает то, что железо не закрывает:

  • Доступность нужной карты прямо сейчас. Когда клиенту нужен H100 на этой неделе, а не через квартал поставки, on-demand в облаке поднимает его за минуты. На пике спроса на конкретную карту это иногда единственный способ вообще стартовать.
  • Burst под неровный трафик. Если нагрузка скачет в разы между днём и ночью, держать пиковое число карт на железе круглосуточно расточительно. Облако позволяет добирать карты на пик и гасить в провал, платя за реально занятое время.
  • Короткие окна: эксперименты, файнтюн, оценка модели. Прогнать новую модель пару недель и снять выводы дешевле в облаке, чем покупать карты под задачу с горизонтом меньше года.
  • Спот под прерываемую работу. Батч-инференс и офлайн-обработку, которые переживают прерывание, спот-инстансы делают радикально дешевле, если правильно обработать вытеснение.

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

Bare metal GPU: где рвёт по cost-per-token

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

Сверх цены за час у железа есть ещё два рычага. Первый это контроль над топологией: NVLink между картами, локальный NVMe под веса и кэш, отсутствие виртуализационного слоя между моделью и GPU. Второй это egress: на железе исходящий трафик не тарифицируется поминутно, а на тяжёлом инференсе с длинными ответами облачный egress собирается в заметную строку. Базовый serving-воркфлоу с постоянным трафиком почти всегда дешевле держать на железе, и тем дешевле, чем выше утилизация карт.

Скрытые косты облака

Почасовой прайс облака это не вся стоимость. В cost-per-token прилетает то, что не стоит крупно на калькуляторе провайдера:

  • Простой зарезервированной карты. Reserved-инстанс вы платите целиком, занят он или нет. Если утилизация низкая, фиксированный платёж размазывается на меньшее число токенов, и cost-per-token растёт, как на железе, только дороже.
  • Egress на длинных ответах. Генеративный трафик уходит наружу, и на объёме это ощутимая строка, которой на железе нет.
  • Надбавка за дефицит. В пик спроса на конкретную карту on-demand цена ползёт вверх, и планировать бюджет на квартал становится гаданием.

Облако в GPU это инструмент для неровного, дефицитного и короткоживущего. Для ровной базовой нагрузки оно почти всегда проигрывает железу по cost-per-token, просто проигрыш приходит не в почасовом прайсе, а в утилизации и egress.

Как мы выбираем под клиента

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

Если вам нужно понять, во что реально обойдётся ваш инференс, а не сравнивать почасовые ценники, это то, что мы держим в ai/llm и закрываем через deploy и scale. Хотите посчитать cost-per-token под вашу нагрузку на железе и в облаке: напишите нам.

← Все статьи