Почему цена за миллион токенов вводит в заблуждение

У API счёт обычно растёт вместе с фактическим потреблением. У собственного сервера значительная часть расходов возникает и в часы, когда запросов нет: оборудование или аренда, администрирование, резервирование, мониторинг и обновления. Поэтому делить месячную стоимость GPU на его максимальную паспортную производительность — почти всегда плохая оценка для небольшого бизнеса.

В исследовании Chitral Patil, опубликованном в июне 2026 года, стоимость вывода оценивалась при разной интенсивности запросов, моделях и оборудовании. На одном и том же H100 автор получил большой разброс эффективной цены при разных уровнях загрузки. Это не универсальный прайс и не прогноз для российской компании: эксперимент показывает, почему расчёт при постоянной полной загрузке может существенно занизить стоимость своего контура. Авторы также повторили основную серию на A100 и отдельно отметили зависимость результатов от аппаратной платформы.

Для руководителя главный вопрос звучит иначе: сколько стоит **успешно закрытая бизнес-задача** при нашем реальном графике обращений? Токены полезны для технического учёта, но не показывают цену пустующего сервера, ручных исправлений и просроченного ответа клиенту.

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

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

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

В vLLM для такого измерения есть метрики очереди, числа выполняемых запросов, времени до первого токена, общей задержки и числа обработанных токенов. Его инструмент `bench serve` позволяет воспроизвести профиль нагрузки; тест на одной короткой подсказке не заменит реальные длины контекста и всплески одновременных запросов. Документация NVIDIA Triton также прямо связывает пакетирование с компромиссом между пропускной способностью и задержкой. Это инженерные инструменты, а не гарантия конкретной экономии на вашем оборудовании.

Модельный расчёт: где появляется точка безубыточности

Предположим, компания сравнивает два варианта для одной и той же проверенной задачи. Числа ниже **условные**, в рублях, не являются тарифами поставщиков или оценкой рынка:

  • собственный контур: 90 000 ₽ фиксированных расходов в месяц, включая амортизацию либо аренду, эксплуатацию и резерв; ещё 0,15 ₽ переменных расходов на обработанный запрос;
  • внешний API: 1,20 ₽ за запрос при фактической структуре входных и выходных токенов;
  • качество, доступность и доля ручных исправлений на первом шаге одинаковы; налоговые, валютные и договорные нюансы здесь не учтены.

Тогда собственный контур стоит `90 000 + 0,15 × N`, API — `1,20 × N`, где `N` — число запросов за месяц. Равенство наступает примерно при **85 700 запросах в месяц**. При 20 000 запросов модель даёт 93 000 ₽ против 24 000 ₽. При 100 000 — 105 000 ₽ против 120 000 ₽. Это арифметика допущений, а не обещание экономии: локальный вариант ещё должен выдержать именно пиковую нагрузку и заданную задержку.

Теперь предположим, что локальная модель на два процентных пункта чаще требует ручного исправления, а одно исправление обходится в 20 ₽. Дополнительная стоимость составит 0,40 ₽ на запрос. При прочих равных порог сдвинется примерно до **138 500 запросов в месяц**: `90 000 / (1,20 − 0,15 − 0,40)`. Даже небольшой разрыв в качестве может перевесить экономию на инференсе. Если знаменатель становится нулевым или отрицательным, в этой модели локальный вариант вообще не окупается ростом объёма.

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

Когда локальная модель оправданна без прямой экономии

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

В малой компании разумно рассмотреть промежуточный вариант: оставить чувствительные этапы внутри защищённого контура, а разрешённые и редкие задачи выполнять через API; либо использовать уже имеющуюся совместимую инфраструктуру вместо отдельного постоянно работающего GPU. Такое разделение требует проверить договоры, категории данных, маршрутизацию запросов и одинаковые критерии качества для обоих путей. Если данные нельзя передавать наружу, API не является допустимой альтернативой независимо от цены.

Как провести проверку без крупной закупки

1. Выберите один процесс с измеримым результатом — например, черновик ответа по базе знаний или разбор типового документа. Согласуйте эталонную выборку и стоимость ошибки.
2. Соберите временной профиль запросов и реальные длины контекста. Уберите персональные данные из тестового набора либо проводите испытание внутри разрешённого контура.
3. На сопоставимых данных измерьте API и локальный кандидат: долю принятых ответов, ручные исправления, p95 задержки в пик, очередь и фактическую пропускную способность.
4. Внесите в расчёт полный месячный фиксированный платёж: оборудование или аренду, электричество, администрирование, резервирование, мониторинг и срок обновления. Отдельно посчитайте переменные расходы и цену человеческой проверки.
5. Примите решение для наблюдаемого объёма и двух сценариев роста, а не для максимальной скорости из деморолика. После пилота пересчитывайте модель по фактическим метрикам.

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