Стоимость одного запроса к вашей LLM: считаем честно

MAATRIX

У облачного API есть прайс-лист: столько-то за миллион входных токенов, столько-то за миллион выходных — открыл страницу тарифов и узнал цену запроса заранее. У своей LLM на арендованном сервере такого прайс-листа нет, и вопрос «сколько стоит один запрос» ставит в тупик: сервер же оплачен целиком вперёд, при чём тут отдельный запрос? На самом деле цена есть, просто она не константа, а частное от деления — и меняется каждый месяц в зависимости от того, сколько вы этот сервер загрузили.

Почему цена запроса — это не то же самое, что тариф провайдера

Тариф облачного API — это цена за единицу работы (токен), назначенная провайдером один раз и не зависящая от того, сколько вы в итоге используете модель. Сделали вы 10 запросов в месяц или 10 000 — цена каждого токена одна и та же, разница только в итоговой сумме счёта.

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

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

Формула стоимости одного запроса на своём сервере

Формула простая и в этом её сила — она не требует знать токенайзер, кэш-скидки или курс валюты провайдера:

Цена одного запроса = Стоимость сервера в месяц / Число обработанных запросов за месяц

Два слагаемых, обе — ваши собственные цифры, а не цифры из чужого прайс-листа:

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

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

Разберём на условном примере — числа ниже иллюстративные, у вас будет другой сервер и другая нагрузка, ориентируйтесь только на саму методику:

Пусть аренда сервера под LLM стоит X условных единиц в месяц (подставьте свою реальную сумму счёта). Тогда:

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

Как загрузка меняет цену: от дорогого до почти бесплатного запроса

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

Низкая загрузка — дорогой запрос. Сервер простаивает большую часть месяца, но счёт за аренду от этого не уменьшается ни на копейку — вы платите за адрес, а не за визиты (эта аналогия подробнее разобрана в статье про то, сколько стоит держать локальную LLM в месяц). Если за весь месяц набежала пара сотен запросов, вся стоимость аренды делится на них — и цена одного запроса может оказаться выше, чем аналогичный запрос обошёлся бы через облачный API. Это классическая ловушка «завёл свою LLM для экономии» при объёме, который не оправдывает содержание отдельного сервера.

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

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

Зеркальная логика облака: фиксированная цена за токен

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

Здесь же лежит менее очевидный нюанс про сам облачный тариф — если вы уже считаете расходы на облачные вызовы по usage-полям из ответа API, а не прикидкой, эта методика разобрана отдельно: как считать стоимость LLM-запросов через реальные данные, а не оценку по символам.

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

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

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

Формула точки безубыточности в запросах:

N* = Стоимость сервера в месяц / (Средняя цена одного запроса в облаке)

Где «средняя цена одного запроса в облаке» — это то, во сколько вам обходится typичный вызов (с вашей типичной длиной промпта и ответа) при тарифах выбранного облачного провайдера — берите её из фактического счёта за облако или из расчёта по usage-полям, а не с потолка.

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

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

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

Как посчитать реальное число запросов в месяц

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

Access-лог реверс-прокси. Если ваш инференс-сервер стоит за nginx (обычная схема — TLS-терминация плюс единая точка входа для чат-интерфейса и API), число запросов за месяц по нужному эндпоинту считается одной командой:

awk '$4 ~ "01/Sep/2026" || $4 ~ "0[2-9]/Sep/2026" || $4 ~ "[12][0-9]/Sep/2026" || $4 ~ "3[01]/Sep/2026"' \
  /var/log/nginx/llm-access.log \
  | grep -c 'POST /v1/chat/completions'

Плюс способа — не требует изменений в самом инференс-сервере, работает с любым бэкендом (Ollama, vLLM, llama.cpp через любой API-обвес). Минус — считает HTTP-запросы, а не «логические» обращения пользователя, если ваш клиент иногда ретраит один и тот же запрос при обрыве соединения.

Встроенные метрики инференс-сервера. vLLM и большинство production-обвязок отдают Prometheus-метрики на /metrics, включая счётчики завершённых запросов по причине завершения (по лимиту токенов, по стоп-слову и так далее). Точные имена метрик меняются между версиями, так что перед тем как строить на них расчёт, откройте curl localhost:8000/metrics | grep request на своей текущей версии и берите актуальное имя counter'а, а не имя из чужого туториала.

Трейсинг через Langfuse или аналог. Если у вас уже стоит инструмент трассировки LLM-вызовов (для контроля стоимости, качества ответов или отладки промптов), он и так считает число запросов за период — обычно это готовый дашборд, без отдельной команды в терминале. Если такого инструмента ещё нет, но вы хотите не только знаменатель для этой формулы, а полноценный контроль над расходами — приглядитесь к статье о мониторинге нагрузки локальной LLM: помимо числа запросов там разобрано, что ещё стоит снимать с сервера, чтобы вовремя заметить приближение к потолку мощности, а не постфактум по жалобам пользователей на задержку.

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

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