Как сравнить LLM API и GPU-кластер по полной стоимости

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

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

Считайте стоимость полезного ответа

Единица сравнения должна быть одинаковой для обоих вариантов: один ответ, который прошел проверку качества и уложился в SLO. Сравнение «рублей за миллион токенов» с «рублями за GPU-час» смешивает две разные величины. Токен может прийти из модели, которая не проходит ваш порог качества, а оплаченный GPU-час может состоять из ожидания трафика.

Начните с четырех чисел за месяц:

• количество принятых ответов;
• стоимость всех попыток, включая повторы и аварийный маршрут;
• доля ответов, уложившихся в целевую задержку;
• доля ответов, прошедших продуктовую или автоматическую проверку качества.

Базовая метрика выглядит так:

стоимость полезного ответа =
  полная месячная стоимость пути /
  число ответов, прошедших качество и SLO

Если продукт не умеет автоматически решить, принят ли ответ, используйте устойчивый заменитель: успешное завершение пользовательского действия, долю эскалаций человеку, точность на размеченной выборке или результат парного сравнения. Выберите один критерий до финансового расчета. Иначе локальная модель почти всегда «дешевле» на бумаге, потому что цена исправлений остается в бюджете поддержки, а не LLM.

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

Так же отделяйте себестоимость от денежного потока. Купленный сервер создает крупный платеж сейчас и расход через амортизацию позже. API превращает тот же риск в переменный счет. Для CTO важны обе картины: P&L показывает экономику периода, cash flow показывает, сколько денег компания заморозит до появления нагрузки.

Снимите профиль API-нагрузки до расчета

Для расчета API нужны фактические входные и выходные токены по моделям, часы пиков, повторы, кэш и доля запросов с длинным контекстом. Месячная сумма из счета годится для бухгалтерии, но плохо объясняет, что произойдет после смены модели или роста продукта.

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

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

API-стоимость за месяц считайте по каждой модели отдельно:

C_api =
  Σ(V_in × P_in + V_out × P_out + V_cache_write × P_cache_write
    + V_cache_read × P_cache_read)
  + C_retry + C_fallback + C_network + C_support

Здесь объемы V выражены в миллионах токенов, а цены P взяты в рублях за миллион. C_retry нельзя оценивать процентом «на глаз»: посчитайте токены всех попыток с тем же идентификатором операции. C_fallback включает запросы, которые после тайм-аута ушли во вторую модель. Сетевой расход часто мал относительно инференса, но его следует оставить отдельной строкой, чтобы сравнение не потеряло симметрию.

Prompt caching уменьшает счет только при реальном попадании. Повторяющийся системный промпт еще не гарантирует кэш: версию могут менять инструменты, порядок сообщений, региональный маршрут или срок жизни записи. Берите оплаченные cached input tokens из детализации провайдера. Если таких данных нет, поставьте скидку в ноль и проведите отдельный тест.

Для RU LLM в этой части можно подставлять ставки провайдеров без наценки на API и рублевый счет, а запросы отправлять через единый OpenAI-совместимый эндпоинт. Это не отменяет разбивку по моделям: единый шлюз упрощает сбор данных, но дорогая модель остается дорогой.

В TCO кластера входит больше ускорителей

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

Разложите TCO на постоянную и переменную части:

C_cluster =
  C_capital + C_facility + C_energy + C_people + C_software
  + C_spares + C_network + C_model_change + C_risk

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

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

C_energy = средняя мощность узлов, кВт × часы × PUE × тариф, руб/кВт·ч

PUE уже учитывает накладные расходы площадки на охлаждение и распределение энергии. Если счет ЦОДа включает электричество и охлаждение в стойко-место, не добавляйте их второй раз. И наоборот, домашняя оценка «TDP × тариф» забывает CPU, память, вентиляторы, блоки питания и сетевое оборудование.

C_people содержит не всю зарплату ML-команды, а долю времени на инфраструктуру: сборку образов, драйверы, планировщик, развертывание, наблюдаемость, безопасность, емкостное планирование и инциденты. Умножьте фактические часы по ролям на полную стоимость часа. Отдельно внесите дежурства и компенсации: редкие аварии дороги именно потому, что требуют готовности, даже когда ничего не сломалось.

C_model_change покрывает работу, которую удобно объявить исследованием и забыть в TCO. Новая версия модели требует получить веса, проверить лицензию, собрать движок, подобрать квантование, прогнать evaluation, нагрузочный тест и постепенное развертывание. Если обновление ломает шаблон сообщений или формат tool calling, продуктовая команда тоже тратит время. Делите фактическую стоимость цикла на число месяцев между обновлениями.

C_risk не должен быть произвольной надбавкой. Внесите конкретные ожидаемые потери: вероятность отказа вне гарантии, срок поставки замены, штраф за нарушение SLO, стоимость аварийной аренды или API-маршрута. Если риск невозможно оценить, покажите сценарии с нулем и с худшим приемлемым последствием, а решение принимайте по диапазону.

Резерв под пик чаще всего решает исход

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

Для интерактивного сервиса возьмите часовой профиль входящего потока и воспроизведите его на выбранной модели с реальными длинами контекста. Измерьте, сколько реплик держит SLO на 95-м и 99-м перцентилях. Затем уберите один узел или один домен отказа и повторите тест. Число GPU после этого теста, а не результат идеального бенчмарка, идет в строку покупки.

Резерв состоит из разных частей, и складывать их одним процентом опасно:

• запас на обычный пик спроса;
• мощность для отказа узла, стойки или сетевого пути;
• место для обновления без остановки;
• буфер против фрагментации памяти и несовместимых размеров реплик;
• аварийный маршрут при исчерпании локальной емкости.

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

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

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

Загрузка GPU требует трех измерений

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

Документация NVIDIA DCGM определяет SM Activity как долю времени, когда на потоковом мультипроцессоре активен хотя бы один warp, усредненную по всем SM. В ней прямо оговорено, что активный warp может ждать память, а высокая occupancy не всегда означает эффективную работу. Я согласен с этим ограничением и делаю из него финансовый вывод: нельзя умножить процент SM Activity на число часов и назвать результат «полезными GPU-часами».

Собирайте три слоя телеметрии:

• аппаратный: SM Activity, Tensor Activity, DRAM Activity, занятая память, мощность и аппаратные ошибки;
• серверный: токены в секунду, длина очереди, размер батча, время до первого токена и завершенные запросы;
• продуктовый: принятые ответы, ошибки инструментов, повторы и оценка качества.

Для короткой проверки DCGM умеет выводить профильные поля с секундным интервалом:

dcgmi dmon -e 1002,1004,1005 -d 1000

# Entity  GRACT  SMACT  TENSO  DRAMA
# Idx       %      %      %      %
  GPU 0    74     61     38     52

Форма вывода зависит от версии DCGM и выбранных полей, поэтому перед автоматическим разбором сохраните заголовок со своей системы. Поля 1002, 1004 и 1005 соответствуют активности SM, тензорных блоков и памяти в документации DCGM. Команда показывает активность, а счетчик ответов и токенов добавьте из inference-сервера.

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

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

Калькулятор должен показывать точку безубыточности

Рабочий калькулятор хранит исходные допущения отдельно от формул и выводит не одну сумму, а три сценария. Скопируйте следующую таблицу в электронную таблицу. В колонке B находятся входные данные, в колонке C указаны формулы; все суммы заданы в рублях за месяц.

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

Разберем учебный сценарий, числа в нем не являются рыночной котировкой. Сервис обрабатывает 140 млн входных и 35 млн выходных токенов в месяц. В таблицу занесли условные ставки 400 и 1200 рублей за миллион, еще 14 000 рублей ушло на повторы и резервный маршрут. API стоит 112 000 рублей: 140 × 400 + 35 × 1200 + 14 000.

Локальный вариант требует двух узлов по 4 800 000 рублей, 36 месяцев амортизации и условной остаточной стоимости 960 000 рублей за оба узла. Площадка с энергией стоит 180 000 рублей в месяц, работа и дежурства 310 000, ПО, запас и обновления 90 000. Месячный TCO равен 820 000 рублей: (9 600 000 - 960 000) / 36 + 180 000 + 310 000 + 90 000.

При 800 000 полезных ответов через API цена ответа равна 0,14 рубля. Если локальная модель проходит тот же порог качества для 720 000 ответов, ее цена равна примерно 1,14 рубля. Разница возникла не из-за «дорогого железа вообще», а из-за малого объема относительно постоянной базы и меньшего числа принятых ответов.

Теперь увеличим только трафик в восемь раз и предположим, что те же два узла выдерживают его без нарушения SLO. API-счет растет почти линейно до 896 000 рублей при прежней структуре повторов, а TCO кластера остается 820 000. Граница появилась рядом, но вывод еще нельзя утверждать: нужно проверить, выдержат ли узлы восемь потоков, не понадобится ли третья реплика и сохранится ли качество локальной модели.

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

Собственный кластер выигрывает при устойчивой базе

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

Сильные признаки в пользу своего кластера таковы: ежедневная пакетная очередь может заполнять ночной провал; интерактивный поток имеет узкий диапазон; выбранные модели и контекст помещаются на понятной топологии; задержка до внешнего API неприемлема; данные по внутренней политике нельзя передавать внешнему обработчику; платформа GPU уже обслуживается той же командой.

Последний пункт легко исказить. Наличие Kubernetes и нескольких ML-инженеров не означает готовности к инференсу под SLO. Нужны опыт с драйверами, CUDA, inference-движком, планированием VRAM, деградацией качества после квантования, наблюдаемостью и заменой узлов. Если эти навыки придется нанимать, включите время поиска и период обучения в сценарий запуска.

Собственная инфраструктура особенно убедительна для стабильной модели с длинным сроком жизни. Если бизнес-задача меняет модель каждый месяц, ускоритель может оставаться совместимым, но оптимизированный движок, профили памяти и evaluation придется переделывать. Цена обновления тогда становится регулярной операцией, а не разовым проектом.

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

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

Гибридная схема снижает цену ошибки

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

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

RU LLM подходит для такого внешнего пути там, где команде нужны модели разных провайдеров через OpenAI-совместимый интерфейс, рублевый B2B-инвойсинг, хранение логов и бэкапов в РФ, маскирование PII и аудит-трейлы. Для полностью локальной части платформа также хостит open-weight модели на собственной GPU-инфраструктуре в российских ЦОДах, но границы обработки и ответственности все равно следует зафиксировать в архитектуре.

У гибрида есть цена: два пути надо тестировать, наблюдать и защищать от расхождения поведения. Одинаковый API-формат не гарантирует одинаковые ответы, tool calling или лимиты контекста. Храните версию маршрутизатора вместе с версией промпта, пишите выбранный путь в аудит-трейл и прогоняйте evaluation для каждого разрешенного маршрута.

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

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

Решение принимайте после месячного параллельного теста

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

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

Перед решением зафиксируйте:

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

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

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

Самая честная итоговая строка калькулятора называется не «API» и не «кластер». Она называется «стоимость полезного ответа при выполненном SLO». Если команда не может заполнить эту строку измерениями, ей пока рано покупать GPU ради экономии.