Цена тысячи токенов на своём железе: с амортизацией и электричеством

MAATRIX

«Мы купили GPU за N рублей, теперь инференс бесплатный» — фраза, которую я слышал десятки раз и ни разу не видел, чтобы она была честной. Карточка не бесплатна ни в момент покупки, ни потом: она изнашивается, тянет киловатты из розетки и, если стоит не дома, а в стойке ЦОД, требует ещё и охлаждения. Сложите всё это и разделите на число обработанных токенов — получится конкретное число в рублях за тысячу токенов, которое можно честно сравнивать с ценником любого API.

Почему «GPU куплена, значит бесплатно» — ошибка расчёта

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

• Наивный расчёт: стоимость покупки выпадает из уравнения после дня оплаты. Себестоимость токена «после сегодня» = 0.
• Честный расчёт: стоимость покупки размазывается по всему сроку полезного использования (амортизация), плюс к каждому часу работы добавляется стоимость электричества, плюс — если железо стоит в арендованной стойке — доля расходов на охлаждение и инфраструктуру ЦОД.

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

Компонент 1: амортизация

Амортизация превращает единовременный платёж в равномерный поток расходов, привязанный к использованию. Если карта стоит P рублей и прослужит T часов, каждый час работы «стоит» P / T рублей амортизации — независимо от того, что деньги заплачены один раз.

Аморт_час = (Цена_покупки − Остаточная_стоимость) / Срок_службы_часов

• Цена_покупки — то, что реально заплатили за карту (или весь сервер, если считаете узел целиком).
• Остаточная_стоимость — сколько карту можно продать на вторичном рынке в конце срока службы.
• Срок_службы_часов — сколько часов карта реально проработает до списания или морального устаревания, а не абстрактный «срок жизни кремния».

Здесь есть методическая развилка. Бухгалтерский срок — фиксированный период (например, 3–5 лет) для налогового учёта, независимо от загрузки. Расчётный срок по факту использования — сколько часов карта проработает под реальной нагрузкой до выхода из строя или устаревания. Для себестоимости токена правильнее второй подход, но точный срок заранее неизвестен — разумно считать в диапазоне (консервативный и оптимистичный сценарий), а не одной точкой.

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

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

Компонент 2: электричество

Формула часовой стоимости электричества:

Электро_час = Потребляемая_мощность_кВт × Тариф_за_кВтч

Три нюанса, которые часто занижают итоговую цифру:

• Мощность под нагрузкой, а не паспортная. Указанный TDP — это максимум при полной нагрузке; реальное потребление зависит от типа задачи (батчинг ближе к максимуму, чем одиночные запросы с простоями). Не выдумывайте среднее — измерьте его для своей нагрузки, например через nvidia-smi или систему мониторинга сервера, и выведите честное среднее по логу за характерный период.
• Не только сама карта. Процессор, память, накопители, вентиляторы и потери на блоке питания (КПД никогда не 100%) тоже потребляют энергию — это часть себестоимости, а не бесплатное приложение к работе GPU.
• Простой тоже стоит денег. Даже без запросов сервер обычно не выключен полностью и потребляет базовую мощность — эти киловатт-часы тоже нужно куда-то отнести: либо повышающим коэффициентом в себестоимость токена, либо отдельной строкой как «стоимость готовности сервиса».

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

Компонент 3: охлаждение и инфраструктура ЦОД

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

Дата-центр тратит энергию не только на питание вашей стойки, но и на отвод тепла: кондиционирование, вентиляция, иногда жидкостное охлаждение для плотных GPU-стоек. Эта надбавка выражается метрикой PUE (Power Usage Effectiveness):

PUE = Полное_энергопотребление_ЦОД / Энергопотребление_IT_оборудования

PUE = 1.0 означал бы отсутствие накладных расходов на охлаждение — на практике такого не бывает. PUE 1.4, например, означает, что на каждый киловатт-час, потреблённый самим оборудованием, ЦОД тратит ещё 0.4 кВт·ч на охлаждение и вспомогательные системы. Значение сильно различается между площадками — точную цифру смотрите в договоре колокейшна или уточняйте у оператора, не берите из общих ориентиров.

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

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

Собираем формулу

Себестоимость_час = Аморт_час + Электро_час + Инфра_час

Где Инфра_час — либо доля PUE-надбавки к электричеству (для своего ЦОД), либо ноль отдельной строкой, если она уже включена в тариф колокейшна.

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

Цена_за_1000_токенов = (Себестоимость_час / Токенов_в_час) × 1000

Пропускная способность — самая изменчивая переменная во всей формуле: зависит от модели, квантования, длины контекста, размера батча, конкретной карты. Точных «токенов в секунду» я намеренно не привожу — это нужно измерить на своей связке, а не взять из чужого бенчмарка с другими параметрами теста.

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

Как утилизация меняет итоговую цифру

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

Практические выводы:

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

Это прямое продолжение вопроса о том, что выгоднее — свой инференс или API по токенам в зависимости от объёма: чем выше и стабильнее утилизация своего железа, тем ближе точка безубыточности к разумным объёмам, и наоборот.

Как честно сравнивать с ценой API

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

• Сравнивайте одинаковые единицы. API обычно тарифицирует входные и выходные токены раздельно и по разным ставкам, свой расчёт себестоимости обычно такого разделения не делает. Для точного сравнения считайте средневзвешенную цену API под ваше типичное соотношение входных/выходных токенов, а не берите меньшую из ставок.
• Учитывайте качество модели. Если ради низкой себестоимости пришлось взять модель меньшего размера или более грубое квантование, сравнение нечестное — если для задачи важно качество, которое даёт более крупная модель за API.
• Не забывайте про время инженера. Настройка, обновление, мониторинг и troubleshooting своей инфраструктуры — расход, просто не в токенах. В формулу выше он не входит, но должен быть в голове при принятии решения.
• Сравнивайте на реальной утилизации, а не на пиковой. Расчёт при 100% загрузке даёт минимально возможную себестоимость токена, недостижимую на практике для большинства нагрузок.

Более широкий взгляд на выбор между локальной моделью и облаком — в статье «локальная модель против облачного API».

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