Стоимость self-hosted LLM на миллион токенов: воспроизводимая модель затрат на GPU

Стоимость self-hosted LLM на миллион токенов: воспроизводимая модель затрат на GPU

Надёжный способ рассчитать стоимость self-hosted LLM на миллион токенов — разделить полную стоимость обслуживания на количество токенов, которые фактически принимает ваша рабочая нагрузка, а не на заявленную пиковую пропускную способность GPU.

Это различие имеет значение. GPU может показывать хорошие результаты в бенчмарках, но быть дорогим в продакшене, если оплачиваемое время простаивает, обрабатывает необычно длинные промпты, повторяет неудачные запросы или генерирует вывод, который отклоняет ваш продукт. В этом руководстве представлены повторяемая модель для расчёта стоимости self-hosted LLM на миллион токенов, рабочая таблица, практический пример и честный способ сравнить самостоятельно управляемый эндпоинт с управляемым API.

Обновлено 16 октября 2026 года. Все приведённые ниже суммы в долларах и показатели пропускной способности являются иллюстративными входными данными, а не котировками провайдеров или заявлениями о производительности.

Формула стоимости self-hosted LLM на миллион токенов

Для расчёта по выходным токенам используйте:

стоимость 1 млн принятых выходных токенов =
  полная почасовая стоимость обслуживания
  / (выходные токены/секунду в активном окне × 3,600 × использование оплачиваемого времени × доля успешных запросов × доля принятых результатов)
  × 1,000,000

Где:

Знаменатель — ключевой элемент. Стоимость self-hosted LLM на миллион токенов должна рассчитываться на полезную единицу, а не на результат GPU-бенчмарка.

Правило недопущения двойного учёта

Используйте один из двух путей измерения:

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

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

Копируемая рабочая таблица стоимости GPU на миллион токенов

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

Рабочая таблица делает расчёт стоимости self-hosted LLM на миллион токенов проверяемым: другой оператор должен иметь возможность заменить входные данные, повторно запустить окно измерения и воспроизвести результат.

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

Практический пример: почему использование меняет результат

Зафиксируем гипотетические полную почасовую стоимость эндпоинта $4.07 и 900 выходных токенов/секунду в активном окне. Небольшие изменения входных параметров существенно меняют удельную стоимость.

Вывод не в том, что нужно покупать определённый ускоритель. Дело в том, что стоимость self-hosted LLM определяется моделью эксплуатации и пропускной способности. Более высокая почасовая стоимость узла может привести к меньшей стоимости принятого результата, если у узла достаточно памяти, есть запас для пакетной обработки, а спрос позволяет поддерживать больший объём полезной работы. Более низкая почасовая ставка может оказаться невыгодной, если учесть простои мощностей и повторные попытки в знаменателе расчёта.

Разделяйте prefill и decode перед тестированием производительности

Обслуживание LLM — это не одна однородная нагрузка. Инференс включает этап обработки контекста (prefill) и этап генерации (decode); в руководстве NVIDIA по TensorRT-LLM они явно рассматриваются как отдельные этапы, а также подчёркивается важность настройки под конкретную нагрузку. Изучите руководство по настройке производительности TensorRT-LLM, прежде чем считать какой-либо широко рекламируемый показатель токенов в секунду репрезентативным.

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

Фиксируйте распределения длины промптов и выходных данных отдельно. Для ассистента с интенсивным использованием поиска, обрабатывающего 20 000 входных токенов и выдающего 300 выходных, расчёт стоимости только по выходным токенам может не выявить реальное узкое место. В сценарии разработки кода с 2 000 входных и 4 000 выходных токенов основную нагрузку может создавать decode.

Для корректного сравнения стоимости self-hosted LLM на миллион токенов используйте как минимум три следующих показателя:

Измеряйте знаменатель по телеметрии production-среды

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

Например, в документации vLLM описаны метрики Prometheus для токенов промптов, сгенерированных токенов, завершений запросов, отказов в приёме запросов, времени ожидания в очереди, времени prefill и decode, использования KV-кэша, времени до первого токена и задержки на один выходной токен. Этого достаточно, чтобы сформировать запись измерений, а не делать предположения на основе бенчмарка. Справочник метрик vLLM содержит актуальные названия метрик и их значения.

Для каждого запуска фиксируйте следующую запись:

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

Телеметрия оборудования полезна, но это средство диагностики, а не знаменатель для расчёта удельной стоимости. В документации NVIDIA по профилированию DCGM отмечается, что активность представляет собой среднее значение за интервал и её следует сопоставлять с пропускной способностью при репрезентативной нагрузке. Используйте метрики профилирования DCGM, чтобы выяснить, ограничивают ли выполнение вычислительные ресурсы, пропускная способность памяти или особенности межсоединения; не заменяйте показатель загрузки оплаченного времени единственным процентным показателем загрузки GPU.

Сформируйте числитель с учётом полных затрат

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

Для пилотного проекта укажите два показателя:

GPU-only cost per 1M tokens
Fully loaded cost per 1M accepted tokens

Разница между ними — не ошибка, а эксплуатационные затраты на self-hosted сервис. Ее учет позволяет проверить обоснованность решения о стоимости self-hosted LLM.

Учитывайте повторные попытки и отклоненные результаты

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

Используйте поправку на принятие результатов, которую ваша продуктовая команда сможет воспроизвести:

accepted output tokens =
  generated output tokens
  × execution-success rate
  × product-acceptance rate

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

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

Сравнивайте self-hosting с управляемым API в одинаковых единицах

При self-hosting вы покупаете мощности. При использовании управляемого API вы платите за использование. Сравнение возможно только тогда, когда совпадают числитель и знаменатель.

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

required active-window output tokens/second =
  fully loaded hourly serving cost × 1,000,000
  / (managed-API cost per 1M accepted output tokens × 3,600 × utilization × success rate × acceptance rate)

Прежде чем принимать решение, согласуйте следующие условия для обоих вариантов:

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

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

Более широкое сравнение вариантов закупки представлено в руководстве Flatkey по сравнению GPU-облака и API моделей и руководстве по ценам на аренду GPU. Когда прямой контроль над GPU не требуется, управляемый вариант служит полезным ориентиром: Flatkey предоставляет единый API для моделей и инструментов с общим балансом, поэтому команды могут сравнить управляемый вариант со своим расчетом self-hosting, не поддерживая отдельные ключи провайдеров. Начните базовое сравнение с Flatkey API, используя тот же тестовый набор и то же правило принятия результатов.

Проверка для закупки в семь шагов

Используйте эту методику расчета стоимости self-hosted LLM на миллион токенов как документ для принятия решения о закупке, а не только как инженерный бенчмарк. Она должна точно показывать, какие допущения о рабочей нагрузке, мощностях и качестве повлияли на результат.

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

Типичные ошибки в модели затрат на self-hosted LLM

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

Отождествление загрузки GPU с использованием мощностей. Загруженный GPU все равно может обслуживать конечную точку с избыточной мощностью относительно оплачиваемого спроса. Для расчета юнит-экономики используйте загрузку в оплачиваемое время, а для выяснения причин — телеметрию оборудования.

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

Игнорирование токенов промпта. Длинный контекст повышает нагрузку на prefill и KV-кэш, даже если продукт в основном тарифицирует выходные токены.

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

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

Полное руководство по принятию решения (когда self-hosting окупается, подбору объёма памяти GPU, инструментам и пошаговой настройке сервера) см. в нашем руководстве по self-hosted LLM.

Часто задаваемые вопросы

Как рассчитать стоимость self-hosted LLM на миллион токенов?

Разделите полную почасовую стоимость обслуживания на количество принятых токенов за оплачиваемый час, затем умножьте на 1 000 000. Используйте измеренную производительность, характерную для production-нагрузки, использование оплачиваемого времени, коэффициент успешности и коэффициент принятия, а не теоретический пиковый показатель GPU.

Совпадает ли стоимость GPU на миллион токенов со стоимостью инференса LLM на токен?

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

Следует использовать выходные токены или общее число токенов?

Используйте оба показателя, если у промпта и вывода разные узкие места. Выходные токены легко сравнивать для генеративных нагрузок; общее или взвешенное число токенов лучше отражает нагрузки retrieval с длинным контекстом. При сравнении self-hosting с API используйте одну и ту же единицу измерения.

Когда self-hosting экономит деньги?

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

Заключение

Обоснованный показатель стоимости self-hosted LLM на миллион токенов — это полная стоимость оплачиваемых мощностей, делённая на принятую пропускную способность. Измеряйте prefill и decode отдельно, учитывайте простой один раз, версионируйте правило принятия и сравнивайте с managed-базой в той же единице измерения. Это превращает коммерческое предложение по GPU в модель затрат, готовую для принятия решений.

Технические источники

• Справочник метрик vLLM
• Руководство NVIDIA по настройке производительности TensorRT-LLM
• Документация NVIDIA DCGM по профилированию