Как считать стоимость одного LLM-запроса на своём сервере

LLM на своём сервере кажется простой идеей: поставили модель, подняли API, отправили запрос - получили ответ. Но настоящая экономика начинается не в момент установки, а в тот день, когда нужно понять, сколько стоит один такой ответ. Один запрос может обходиться почти в копейки, а может незаметно съедать бюджет, если сервер простаивает, модель выбрана с запасом, а нагрузка идёт рывками.

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

Почему цена одного LLM-запроса не равна цене видеокарты

Главная ошибка в расчётах - смотреть только на GPU. Например: «сервер стоит 900 долларов в месяц, значит разделим 900 на количество запросов». Это уже лучше, чем ничего, но картина всё ещё неполная.

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

В стоимость одного запроса обычно входят:

аренда или амортизация сервера;

электричество и охлаждение;

сетевой трафик;

хранение моделей и логов;

лицензии и платные компоненты, если они есть;

работа инженеров и администрирование;

резерв на простой, обновления и аварии;

фактическая загрузка GPU;

размер входного и выходного текста.

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

Базовая формула: с чего начать

Самый простой способ считать стоимость одного LLM-запроса - сначала найти стоимость работы сервера за час, а потом разделить её на количество запросов, которые сервер реально обрабатывает за этот час.

Формула выглядит так:

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

Например, если вся инфраструктура обходится в 1,50 доллара в час, а сервер стабильно обрабатывает 3 000 запросов в час, то один запрос стоит:

1,50 / 3 000 = 0,0005 доллара

То есть половина десятой цента за запрос.

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

Шаг 1. Считаем стоимость сервера в час

Если вы арендуете выделенный сервер, всё относительно удобно: берёте месячную стоимость и делите на количество часов в месяце.

Стоимость сервера в час = месячная стоимость / 730

730 - это среднее количество часов в месяце. Для быстрой оценки этого достаточно.

Допустим, GPU-сервер стоит 1 200 долларов в месяц:

1 200 / 730 = 1,64 доллара в час

Но лучше сразу добавить сопутствующие расходы. Например:

сервер: 1 200 долларов в месяц;

дополнительное хранилище: 80 долларов;

резервное копирование и логи: 40 долларов;

мониторинг: 30 долларов;

запас на обслуживание: 150 долларов.

Итого:

1 500 / 730 = 2,05 доллара в час

Разница заметная. Если считать только аренду сервера, запрос будет казаться дешевле, чем есть на самом деле.

Мини-пример

Команда запускает внутреннего AI-ассистента для поддержки. Сервер стоит 900 долларов в месяц, но к нему добавили диски под логи, мониторинг, резервную машину для обновлений и немного ручной работы администратора. В таблице «сервер» всё ещё стоит 900 долларов, а в жизни инфраструктура уже тянет на 1 250-1 400 долларов. Если не учесть это заранее, экономика начнёт расходиться с реальностью уже в первый месяц.

Шаг 2. Учитываем амортизацию, если сервер куплен

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

Формула:

Амортизация в месяц = цена сервера / срок использования в месяцах

Допустим, сервер с GPU, памятью, дисками и сетью обошёлся в 24 000 долларов. Вы планируете использовать его 36 месяцев.

24 000 / 36 = 666,67 доллара в месяц

К этому нужно добавить:

размещение в дата-центре;

электричество;

охлаждение;

замену комплектующих;

удалённые руки или работу инженера;

резерв на поломки;

стоимость капитала, если оборудование куплено не из свободных денег.

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

Вопрос для проверки

Сервер куплен и стоит в стойке. Он простаивает 60% времени. Можно ли считать запросы только по электричеству? Нет. Деньги уже потрачены, и железо постепенно устаревает. Даже если запросов мало, амортизация продолжает тикать, как счётчик в такси.

Шаг 3. Считаем электричество и охлаждение

Для арендованного сервера электричество часто уже включено в цену. Для собственного оборудования в дата-центре или офисной серверной его нужно считать отдельно.

Базовая формула:

Стоимость электричества = мощность сервера в кВт × часы работы × цена 1 кВт·ч

Если сервер потребляет 1,2 кВт под нагрузкой, работает круглосуточно, а электричество стоит 0,15 доллара за кВт·ч:

1,2 × 730 × 0,15 = 131,40 доллара в месяц

Но у сервера есть ещё охлаждение. Для грубой оценки используют коэффициент PUE. Если PUE равен 1,4, значит на каждый 1 кВт, который потребляет сервер, инфраструктура дата-центра дополнительно тратит около 0,4 кВт на охлаждение и сопутствующие системы.

Тогда расчёт будет таким:

1,2 × 730 × 0,15 × 1,4 = 183,96 доллара в месяц

Это не самая большая статья расходов по сравнению с GPU, но её нельзя игнорировать. Особенно если серверов становится не один, а десять.

Живой пример

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

Шаг 4. Разделяем стоимость запроса и стоимость токена

LLM-запросы не одинаковые. Один пользователь спрашивает: «Составь тему письма», другой отправляет договор на 20 страниц и просит найти риски. Формально это оба «один запрос». По нагрузке - разные миры.

Поэтому правильнее считать не только стоимость запроса, но и стоимость токена.

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

Базовая формула:

Стоимость 1 000 токенов = стоимость сервера в час / количество токенов, обработанных за час × 1 000

А стоимость конкретного запроса:

Стоимость запроса = стоимость входных токенов + стоимость выходных токенов + накладные расходы

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

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

Мини-пример

Есть два запроса:

500 входных токенов и 100 выходных.

8 000 входных токенов и 1 500 выходных.

В отчёте продукта оба могут называться «один чат-запрос». Для сервера второй запрос может быть в десятки раз тяжелее. Если считать только количество запросов, вы не увидите, почему в одни дни GPU спокойно справляется, а в другие очередь растёт без видимой причины.

Шаг 5. Замеряем реальную пропускную способность

На бумаге GPU всегда выглядит бодро. В спецификациях много терафлопсов, гигабайтов памяти и красивых графиков. Но стоимость одного LLM-запроса зависит не от пиковых цифр, а от реального throughput - сколько токенов или запросов сервер выдаёт в вашем сценарии.

Измерять нужно именно вашу связку:

модель;

размер контекста;

среднюю длину ответа;

batch size;

движок инференса;

тип квантования;

ограничения по latency;

параллельные пользователи;

формат API;

логи, фильтры и дополнительные проверки.

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

Какие метрики снять

Для расчёта нужны хотя бы эти показатели:

requests per second - запросов в секунду;

input tokens per second - скорость чтения входного контекста;

output tokens per second - скорость генерации ответа;

p50/p95 latency - обычная и «плохая» задержка;

GPU utilization - загрузка GPU;

VRAM usage - расход видеопамяти;

error rate - доля ошибок;

queue time - время ожидания в очереди.

Если смотреть только на среднюю скорость, можно пропустить неприятный хвост. Например, 90% пользователей получают ответ за 2 секунды, а 10% ждут 25 секунд. Экономика вроде сходится, но продукт уже начинает раздражать людей.

Шаг 6. Учитываем загрузку GPU

Загрузка - один из главных факторов цены. Сервер стоит одинаково и в час пик, и ночью. Если GPU занят 80% времени, стоимость запроса снижается. Если 10% - растёт.

Формула с учётом загрузки:

Эффективная стоимость запроса = стоимость сервера в час / фактическое количество запросов в час

Формально она такая же, как базовая. Но смысл в слове «фактическое».

Допустим, сервер может обрабатывать 10 000 коротких запросов в час при хорошей загрузке. Но реальный продукт даёт только 1 500 запросов в час.

Если сервер стоит 2 доллара в час:

При 10 000 запросов: 2 / 10 000 = 0,0002 доллара. При 1 500 запросов: 2 / 1 500 = 0,00133 доллара

Разница почти в 7 раз. Железо не стало хуже. Просто оно простаивает.

Аналогия

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

Шаг 7. Не забываем про batching

Batching - это объединение нескольких запросов в одну «пачку» для более эффективной обработки. Для LLM это особенно важно: GPU любит параллелизм. Когда запросы идут по одному и с паузами, мощное железо может скучать.

Современные движки инференса используют continuous batching: новые запросы добавляются в обработку динамически, не дожидаясь, пока вся старая пачка завершится. Это помогает лучше загрузить GPU и снизить стоимость токена.

Но batching не бесплатен. Чем агрессивнее вы набиваете очередь, тем выше может быть задержка для отдельного пользователя. Экономика и UX здесь тянут канат в разные стороны.

Мини-пример

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

Шаг 8. Считаем разные типы запросов отдельно

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

Например:

Тип запроса Вход Выход Особенности Короткий чат 300-800 токенов 100-300 токенов быстрый ответ Поддержка с историей 2 000-6 000 токенов 300-800 токенов длинный контекст Анализ документа 10 000-60 000 токенов 500-2 000 токенов тяжёлый prompt processing Генерация отчёта 3 000-10 000 токенов 2 000-6 000 токенов дорогой output Агентный сценарий зависит от шагов зависит от шагов несколько вызовов модели

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

Стоимость короткого чата ≠ стоимость анализа договора

И это нормально. Важно не смешивать их в один показатель, если вы принимаете решения по тарифам, лимитам или инфраструктуре.

Шаг 9. Добавляем стоимость промптов, RAG и инструментов

В реальном продукте LLM редко получает только вопрос пользователя. Часто к запросу добавляются:

системный промпт;

инструкция по тону ответа;

история диалога;

результаты поиска по базе знаний;

фрагменты документов;

JSON-схемы;

tool definitions;

правила безопасности;

технические метаданные.

Пользователь написал одну строку, а модель получила 4 000 токенов контекста. Такое бывает постоянно.

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

Мини-пример

Пользователь спрашивает: «Как вернуть деньги?» Вопрос занимает 5-10 токенов. Но система добавляет политику возвратов, историю заказа, язык пользователя, правила эскалации и формат ответа. Итоговый prompt легко становится в 1 500-3 000 токенов. Для экономики важен не пользовательский текст, а полный запрос, который ушёл в модель.

Шаг 10. Считаем накладные расходы

LLM-сервер не живёт в вакууме. Вокруг него есть обвязка:

API gateway;

балансировщик;

база данных;

очередь задач;

векторная база;

объектное хранилище;

логирование;

observability;

rate limiting;

авторизация;

фильтры безопасности;

ретраи.

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

Простой способ учесть обвязку - добавить коэффициент накладных расходов.

Итоговая стоимость = стоимость инференса × 1,15

Коэффициент 1,15 означает, что вы добавляете 15% на инфраструктуру вокруг модели. Для сложных систем коэффициент может быть 1,3 или выше.

Практический совет

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

Шаг 11. Закладываем резерв на простои и обновления

Сервер не работает в идеальном мире. Нужно обновлять драйверы, перезапускать inference engine, менять модели, чистить диски, чинить сетевые проблемы, переносить нагрузку и переживать аварии.

Если у вас один сервер, любой простой означает ноль мощности. Если серверов несколько, появляется резервирование, но растёт стоимость.

Для расчёта можно добавить коэффициент доступности.

Стоимость с резервом = базовая стоимость / целевая утилизация

Например, вы хотите держать запас мощности 30%, чтобы выдерживать пики и обновления. Значит, плановая загрузка не должна быть 100%. Она может быть 70%.

Если без резерва запрос стоит 0,001 доллара, то с резервом:

0,001 / 0,7 = 0,00143 доллара

Это плата за спокойствие. И в продакшне она часто дешевле, чем авария в самый неудобный момент.

Шаг 12. Выбираем модель по задаче, а не по размеру

Большая модель не всегда выгоднее. Иногда она даёт лучшее качество, но увеличивает стоимость так сильно, что продуктовая экономика ломается. Иногда маленькая модель решает 80% задач, а большую можно оставить для сложных случаев.

Полезный подход:

Начать с минимальной модели, которая даёт приемлемое качество.

Проверить ошибки на реальных данных.

Отдельно выделить запросы, где нужна модель сильнее.

Построить маршрутизацию: лёгкие задачи - дешёвой модели, сложные - дорогой.

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

Мини-пример

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

Шаг 13. Учитываем квантование

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

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

Что стоит проверить:

качество ответов на ваших данных;

скорость генерации;

расход VRAM;

стабильность под нагрузкой;

поведение на длинных запросах;

совместимость с выбранным inference engine.

Мини-пример

Модель в 4-bit может отлично отвечать на типовые вопросы поддержки, но хуже справляться с задачами, где нужна точная логика. В таком случае экономия на GPU может обернуться ростом расходов на ручную проверку, повторные запросы и недовольных пользователей.

Шаг 14. Считаем повторные запросы и ошибки

Пользовательская экономика не заканчивается на первом ответе. Если модель ошиблась, пользователь задаёт уточнение. Если ответ слишком короткий, просит подробнее. Если система упала, запрос повторяется.

Поэтому полезно считать не только техническую стоимость одного API-вызова, но и стоимость завершённой пользовательской задачи.

Стоимость задачи = сумма всех LLM-вызовов, нужных для результата

Например:

классификация запроса - 1 вызов;

поиск по базе знаний - 1 вызов embedding-модели или поискового сервиса;

генерация ответа - 1 вызов;

проверка безопасности - 1 вызов;

уточнение от пользователя - ещё 1 вызов.

В интерфейсе это один диалог. На сервере - несколько операций.

Важная мысль

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

Шаг 15. Пример полного расчёта

Возьмём условный GPU-сервер для LLM-инференса.

Месячные расходы:

Статья Сумма Аренда GPU-сервера $1 200 Хранилище и логи $80 Мониторинг $30 Администрирование и резерв $190 Итого $1 500

Стоимость в час:

1 500 / 730 = 2,05 доллара в час

Теперь замеряем нагрузку.

Сценарий: модель обслуживает чат поддержки. Средний запрос содержит 2 000 входных токенов и 500 выходных токенов. Под реальной нагрузкой сервер обрабатывает 2 400 таких запросов в час с приемлемой задержкой.

Стоимость одного запроса:

2,05 / 2 400 = 0,00085 доллара

Добавим 20% на обвязку, логи, ретраи и резерв:

0,00085 × 1,2 = 0,00102 доллара

Итог: один запрос стоит примерно 0,001 доллара, то есть около одной десятой цента.

Но теперь посмотрим другой сценарий.

Сценарий: анализ длинных документов. Средний запрос содержит 25 000 входных токенов и 2 000 выходных токенов. Сервер обрабатывает только 180 таких запросов в час.

2,05 / 180 = 0,01139 доллара. 0,01139 × 1,2 = 0,01367 доллара

Итог: примерно 1,4 цента за запрос.

Один и тот же сервер. Одна и та же модель. Разница в цене - больше чем в 13 раз. Причина не в аренде, а в размере задачи.

Шаг 16. Считаем стоимость через токены

Теперь посчитаем иначе - через токены.

Допустим, сервер за час обрабатывает:

4 800 000 входных токенов;

1 200 000 выходных токенов;

всего 6 000 000 токенов.

Стоимость сервера в час - 2,05 доллара.

2,05 / 6 000 000 × 1 000 = 0,00034 доллара за 1 000 токенов

С учётом 20% накладных расходов:

0,00034 × 1,2 = 0,00041 доллара за 1 000 токенов

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

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

Шаг 17. Prefill и decode: почему токены бывают разными

В LLM-инференсе есть две важные фазы.

Prefill - модель читает входной контекст. Это похоже на то, как человек быстро просматривает документ перед ответом.

Decode - модель генерирует ответ токен за токеном. Это уже похоже на печать текста: следующий фрагмент зависит от предыдущего.

Длинный prompt нагружает prefill. Длинный ответ нагружает decode. Поэтому два запроса с одинаковым общим числом токенов могут стоить по-разному по времени и задержке.

Сравним:

Запрос Вход Выход Что тяжелее A 9 000 500 чтение контекста B 1 000 8 500 генерация

Оба запроса - по 9 500 токенов. Но запрос B может дольше удерживать GPU в фазе генерации и сильнее влиять на очередь.

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

input_tokens, output_tokens, total_latency

А ещё лучше:

time_to_first_token, tokens_per_second, queue_time

Тогда расчёт стоимости превращается не в гадание, а в управляемую систему.

Шаг 18. Что делать с пиковыми нагрузками

Средняя нагрузка почти всегда обманывает. В среднем сервер может быть загружен на 35%, но в пиковые часы очередь растёт, пользователи ждут, а команда срочно думает о втором GPU.

Поэтому для расчёта нужны два сценария:

Средний день.

Пиковый час.

Если считать только средний день, инфраструктура получится дешёвой, но хрупкой. Если считать только пик, она получится надёжной, но может простаивать большую часть времени.

Хорошая практика - проектировать под нормальный пик и отдельно решать, что делать с редкими всплесками.

Варианты:

ограничить длину prompt;

ввести rate limits;

поставить очередь;

использовать более лёгкую модель для простых задач;

временно подключать дополнительную мощность;

кэшировать повторяющиеся ответы;

делать тяжёлые задачи асинхронными.

Мини-пример

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

Шаг 19. Кэширование: самый недооценённый способ снизить цену

Не каждый LLM-запрос нужно считать заново. В продуктах часто повторяются:

одинаковые системные промпты;

типовые вопросы;

шаблонные инструкции;

результаты классификации;

ответы на FAQ;

промежуточные результаты RAG;

embedding-векторы документов.

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

Что можно кэшировать:

embedding для документов;

результаты поиска;

ответы на типовые запросы;

обработанные фрагменты длинных документов;

системный prompt, если движок поддерживает prefix caching;

результаты инструментов.

Осторожность

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

Шаг 20. Как сравнивать свой сервер с API

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

Условная логика такая:

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

Но цена - не единственный критерий. Свой сервер может быть нужен из-за:

контроля данных;

требований compliance;

предсказуемой latency;

кастомных моделей;

изоляции инфраструктуры;

отсутствия зависимости от внешних лимитов;

возможности оптимизировать под конкретную нагрузку.

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

Мини-пример

Стартап делает 20 000 коротких запросов в месяц. Собственный GPU-сервер почти наверняка будет простаивать. Другая компания обрабатывает миллионы однотипных запросов в месяц и может стабильно загрузить GPU. Там собственная инфраструктура уже может дать хорошую экономию.

Шаг 21. Простая таблица для расчёта

Для первого расчёта достаточно такой таблицы:

Показатель Значение Месячная стоимость сервера $1 200 Дополнительные расходы $300 Общая стоимость в месяц $1 500 Часов в месяце 730 Стоимость в час $2,05 Средних запросов в час 2 400 Базовая стоимость запроса $0,00085 Коэффициент накладных расходов 1,2 Итоговая стоимость запроса $0,00102

Эта таблица не заменяет мониторинг, но помогает быстро понять порядок цифр. А порядок цифр - уже половина решения.

Можно добавить второй лист для токенов:

Показатель Значение Input tokens per hour 4 800 000 Output tokens per hour 1 200 000 Total tokens per hour 6 000 000 Стоимость сервера в час $2,05 Стоимость 1 000 токенов $0,00034 С накладными расходами $0,00041

Так вы сможете оценивать не только «средний запрос», но и разные сценарии: чат, документ, отчёт, агент.

Шаг 22. Что обязательно логировать в продакшне

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

Минимальный набор:

model_name;

request_id;

user_id или tenant_id;

timestamp;

input_tokens;

output_tokens;

total_tokens;

latency;

time_to_first_token;

queue_time;

status;

error_type;

cache_hit;

route или сценарий;

server_id/GPU_id.

С этими данными можно строить отчёты:

стоимость по клиентам;

стоимость по функциям продукта;

стоимость по моделям;

стоимость ошибок;

стоимость длинных контекстов;

экономия от кэша;

загрузка GPU по часам.

Важный момент

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

Шаг 23. Где чаще всего ломается расчёт

Ошибки в расчёте стоимости LLM-запроса повторяются из проекта в проект. Вот самые частые.

Считают по теоретическому максимуму

Взяли красивый benchmark, разделили стоимость сервера на максимальный throughput и получили прекрасную цену. Потом пришли реальные пользователи с длинными запросами, очередями, пиками и неидеальными промптами. Цена выросла.

Лучше использовать benchmark только как ориентир, а решение принимать по собственным замерам.

Не учитывают простой

Если сервер загружен 15% времени, остальные 85% тоже стоят денег. Для низкой нагрузки API или shared-инфраструктура может быть выгоднее.

Смешивают короткие и длинные запросы

Среднее значение скрывает дорогие сценарии. Особенно если 5% запросов потребляют 50% GPU-времени.

Забывают про output

Длинные ответы могут быть дорогими. Иногда достаточно ограничить max_tokens, улучшить prompt или предложить пользователю «краткий» и «подробный» режим.

Не считают ретраи

Если система делает повторные запросы после таймаута, стоимость растёт. Пользователь видит один запрос, инфраструктура - два или три.

Не добавляют инженерное обслуживание

LLM-инфраструктура требует внимания: обновления, мониторинг, инциденты, тесты моделей, оптимизация. В маленькой команде это может быть скрытая, но заметная стоимость.

Шаг 24. Как снизить стоимость одного LLM-запроса

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

Сократить лишний контекст

Длинный prompt не всегда лучше. Уберите дубли, старую историю, слишком большие фрагменты RAG, лишние инструкции. Каждый токен должен работать.

Пример: если системный prompt занимает 2 000 токенов, а реально используется 600, вы платите за воздух при каждом запросе.

Ограничить длину ответа

Параметр max_tokens - не формальность. Он защищает бюджет. Пользователю часто не нужен ответ на 3 000 токенов, если задачу можно решить за 500.

Разделить модели по ролям

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

Использовать кэш

Кэшируйте всё, что безопасно и повторяется. Особенно embedding, системные префиксы, типовые ответы и результаты поиска.

Настроить batching

Правильный batching повышает загрузку GPU. Но не гонитесь за максимумом любой ценой: latency тоже часть продукта.

Перейти на асинхронные задачи

Не всё должно отвечать мгновенно. Анализ большого документа, генерация отчёта или пакетная обработка могут идти в фоне. Это позволяет использовать сервер ровнее.

Следить за p95, а не только за средним

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

Проверить квантование

Если качество сохраняется, квантование может снизить требования к VRAM и улучшить экономику. Но проверять нужно на реальных данных, а не на одном демо-запросе.

Шаг 25. Когда свой сервер действительно имеет смысл

Свой LLM-сервер особенно хорошо раскрывается, когда есть стабильная и понятная нагрузка. Например:

корпоративный ассистент с большим количеством сотрудников;

обработка обращений поддержки;

массовая классификация и разметка текстов;

анализ документов;

генерация отчётов;

RAG по внутренней базе знаний;

batch-задачи, которые можно выполнять ночью;

проекты с требованиями к изоляции данных.

В этих сценариях сервер можно загрузить предсказуемо. А значит, стоимость одного запроса будет снижаться по мере роста нагрузки.

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

Шаг 26. Быстрая методика расчёта перед запуском

Если нужно быстро оценить экономику, действуйте так:

Опишите 3-5 типовых сценариев запросов.

Для каждого оцените input_tokens и output_tokens.

Выберите модель и inference engine.

Проведите нагрузочный тест на похожих данных.

Замерьте requests/hour и tokens/hour.

Посчитайте полную стоимость сервера в час.

Разделите стоимость на реальную пропускную способность.

Добавьте 15-30% на накладные расходы и резерв.

Проверьте пиковую нагрузку отдельно.

Сравните стоимость не только запроса, но и завершённой задачи.

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

Контрольный чек-лист

Перед тем как говорить «один LLM-запрос стоит X», проверьте:

понятна ли стоимость завершённой пользовательской задачи. Если на все пункты есть ответ, у вас уже не «примерная догадка», а нормальная основа для инфраструктурного решения.

Итог

Стоимость одного LLM-запроса на своём сервере считается не одной кнопкой и не одной строкой в прайсе. Она складывается из цены железа, загрузки GPU, длины запросов, скорости генерации, накладной инфраструктуры и качества эксплуатации.

Самая полезная формула проста:

Стоимость запроса = полная стоимость инфраструктуры за период / количество успешных запросов за тот же период

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

Стоимость 1 000 токенов = стоимость инфраструктуры за период / количество обработанных токенов × 1 000

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

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