Как рассчитывается стоимость использования LLM: полный разбор затрат и оптимизации

Из чего складывается стоимость LLM

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

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

Токены как единица измерения

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

Почему это важно? Потому что провайдеры (OpenAI, Anthropic, Google, DeepSeek и другие) рассчитывают стоимость именно через токены, а не через количество слов или запросов. Запрос из 100 русских слов может обойтись дороже англоязычного запроса из 100 слов, хотя семантического содержания одинаково.

Каждый запрос LLM разделяется на две составляющие:

• Входящие токены (input tokens) — это текст, который вы отправляете в модель
• Исходящие токены (output tokens) — это ответ, который модель генерирует

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

Пример: если вы используете OpenAI GPT-4o и отправляете запрос из 1000 входящих токенов, а модель возвращает 200 исходящих токенов, стоимость будет рассчитана как (1000 × цена входящего токена) + (200 × цена исходящего токена). На момент 2025 года это примерно $0,005 + $0,015 = $0,020.

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

Размер модели и контекстное окно

Не все LLM стоят одинаково. Размер модели — количество параметров, которые она содержит, — прямо влияет на стоимость использования. Маленькие легкие модели (как Claude Haiku или Mistral 7B) дешевле. Крупные и мощные (GPT-4o, Claude 3.5 Sonnet) стоят в несколько раз дороже.

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

Второй фактор, связанный с размером, — это контекстное окно (context window). Это максимальный объем информации, который модель может "помнить" в одном запросе. Современные модели имеют контекстные окна от 4 тысяч токенов (базовые модели) до 200 тысяч и даже 1 миллиона токенов (расширенные версии).

Более большое контекстное окно позволяет вам:

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

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

Облачный API или локальное развертывание

Это базовое разделение, которое определяет всю модель затрат. Облачный API — это когда вы используете готовое решение от провайдера (OpenAI, Anthropic, Google). Локальное развертывание — когда вы устанавливаете модель на свой сервер или даже на локальную машину.

В облачном API вы платите за каждый использованный токен. Формула простая и прозрачная: количество токенов × цена за токен = ваш счет. Провайдер отвечает за инфраструктуру, масштабирование, надежность. Вы платите только за то, что используете.

В локальном развертывании вы платите один раз за оборудование (GPU-сервер, CPU, память), потом за электричество и содержание этого оборудования. После первоначальных инвестиций каждый дополнительный запрос практически ничего не стоит — только электричество и амортизация оборудования.

Выбор между этими подходами зависит от объема трафика:

• До 10 тысяч запросов в месяц — облачный API почти всегда дешевле
• От 100 тысяч до миллиона запросов в месяц — начинает появляться точка, где локальное развертывание становится конкурентоспособным
• Свыше нескольких миллионов запросов в месяц — локальное развертывание часто экономнее

Но эти цифры зависят от многих факторов, о которых поговорим дальше.

Скрытые расходы, которые ломают бюджет

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

Один запрос пользователя редко равен одному запросу к LLM. Часто один пользовательский запрос генерирует пять-десять вызовов модели в фоне.

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

Эмбеддинги и векторные базы данных

Если ваше приложение использует RAG (retrieval-augmented generation) — технологию, когда система сначала ищет релевантные документы, а потом передает их в LLM вместе с вопросом, — то вы платите дважды.

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

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

Дальше вы платите за хранение этих эмбеддингов в векторной базе данных (Pinecone, Weaviate, Milvus). Это может быть облачный сервис (тогда платите за месячный тариф плюс за объем хранения) или локальное решение (тогда платите за оборудование и его содержание).

На практике эмбеддинги часто составляют 20-30% от общей стоимости LLM-системы, а некоторые компании эту статью вообще упускают из расчетов на начальном этапе.

Логирование, мониторинг и оценка качества

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

Если вы отправляете логи в облачный сервис (DataDog, Grafana, ELK Stack), вы платите за передачу и хранение каждого бита информации. При масштабировании это может быть заметная статья расходов.

Потом встает вопрос качества. Вы не можете просто запустить LLM в production и забыть про неё. Нужно регулярно оценивать, насколько хорошо она работает. Это либо ручная проверка (дорого по времени, но бесплатно), либо использование других LLM для оценки ответов первой модели (платно, но автоматизировано).

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

Модерация и фильтрация данных

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

Модерация может быть нескольких типов:

• Фильтрация на основе ключевых слов (дешево, но неточно)
• Использование специализированных моделей для выявления вредоноса контента (платно, точнее)
• Использование самой LLM для анализа безопасности входящих запросов (дорого, но очень точно)

Каждый из этих подходов — это дополнительные вызовы, дополнительные токены, дополнительная стоимость.

Reasoning-модели и невидимые вычисления

Новое поколение моделей (OpenAI о1, Claude Opus 5) может "думать" перед ответом. Это означает, что модель делает множество внутренних вычислений, которые не видны пользователю, но за которые вы платите полностью.

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

Это не мелкий штраф — если модель использует 50 тысяч токенов на размышления перед генерацией ответа из 1000 токенов, вы платите за 51 тысячу, и половина счета уходит на невидимые процессы.

Ловушки в расчете стоимости

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

Один пользовательский запрос — много вызовов модели

Когда менеджер проекта говорит "в месяц будет 10 тысяч пользовательских запросов", это не означает 10 тысяч вызовов LLM. За кулисами может происходить гораздо больше.

Типичный сценарий выглядит так:

1. Пользователь задает вопрос
2. Система проверяет, есть ли похожий вопрос в кеше или в истории (может быть дополнительный вызов к поисковой модели)
3. Система формирует запрос с контекстом и отправляет его в LLM (первый полноценный вызов)
4. LLM возвращает ответ, но система видит, что он неполный или содержит ошибку
5. Система рефакторит запрос и отправляет его еще раз (второй вызов)
6. Если нужно, система может отправить запрос к другой, более мощной модели для проверки (третий вызов)
7. Потом система оценивает качество ответа с помощью другой модели (четвертый вызов)

Один пользовательский запрос легко превращается в 4-5 вызовов LLM в фоне. Если вы планировали 10 тысяч запросов в месяц и смету исходя из этого, реальные расходы будут в 4-5 раз выше.

Парадокс активного пользователя

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

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

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

Остаточная ручная работа

LLM редко дает идеальный ответ с первой попытки. Часто результат требует редактирования, проверки, доработки. Эта ручная работа не отражается в счетах от провайдера, но она добавляет стоимость к проекту в целом.

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

Формулы для расчета затрат

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

Стоимость одного активного пользователя (CPMAU)

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

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

CPMAU = (Стоимость входящих токенов + Стоимость исходящих токенов + Прочие расходы) / Количество активных пользователей в месяц

Давайте разберем на конкретном примере. Допустим, у вас есть чат-бот на базе Claude 3.5 Sonnet. Параметры:

• 1000 активных пользователей в месяц
• Каждый пользователь в среднем делает 10 запросов
• Средний входящий запрос: 500 токенов
• Средний ответ: 300 токенов
• Цена входящего токена Claude Sonnet: $0,003 за 1000 токенов
• Цена исходящего токена: $0,015 за 1000 токенов
• Прочие расходы (логирование, эмбеддинги): $500 в месяц

Расчет:

• Всего входящих токенов: 1000 пользователей × 10 запросов × 500 токенов = 5 000 000 токенов
• Стоимость входящих: 5 000 000 × $0,000003 = $15
• Всего исходящих токенов: 1000 × 10 × 300 = 3 000 000 токенов
• Стоимость исходящих: 3 000 000 × $0,000015 = $45
• Общие токен-расходы: $15 + $45 = $60
• С прочими расходами: $60 + $500 = $560
• CPMAU = $560 / 1000 = $0,56 на пользователя в месяц

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

CPMAU полезна для сравнения разных моделей или разных стратегий. Если вы рассчитали CPMAU для облачного API, а потом CPMAU для on-premise решения, вы можете сравнить, какой подход дешевле при вашем текущем масштабе.

Точка окупаемости между облаком и собственным сервером

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

Формула для точки окупаемости:

Точка окупаемости (месяцев) = Начальная стоимость оборудования / (Разница в месячных расходах между облаком и локалью)

Пример расчета. Вы хотите развернуть LLM 13B локально. Параметры:

• GPU-сервер NVIDIA A100 (можно взять в аренду или купить): примерно 200 000 рублей за покупку или 30 000 рублей в месяц в аренду
• Дополнительное оборудование (CPU, RAM, хранилище): 50 000 рублей
• Установка и настройка: 20 000 рублей работ
• Итого начальная инвестиция: 270 000 рублей (если покупать) или можно считать, что это месячная аренда 30 000 + настройка

Облачные расходы при 1 млн запросов в месяц (примерно 5 млн входящих + 3 млн исходящих токенов):

• Облачный API (например, DeepSeek): примерно 500 рублей в месяц
• Локальный сервер (аренда A100): 30 000 рублей в месяц, плюс электричество (примерно 5000 рублей), плюс обслуживание (3000 рублей) = 38 000 рублей

Разница: 500 - 38 000 = -37 500 рублей (локальный сервер дороже). При таком объеме облако выигрывает.

Теперь представьте 100 млн токенов в месяц (100 млн входящих + 50 млн исходящих):

• Облачный API: примерно 50 000 рублей
• Локальный сервер: всё еще 38 000 рублей (объем не влияет на расходы)

Разница: 50 000 - 38 000 = 12 000 рублей (облако теперь дороже). Точка окупаемости где-то между 1 млн и 100 млн токенов.

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

Прогноз расходов при масштабировании

Одна из самых распространенных ошибок в планировании — линейный прогноз. Менеджеры часто думают: "Если сейчас 1000 пользователей стоят нам $1000, то 10 000 пользователей будут стоить $10 000". На самом деле стоимость растет нелинейно.

Почему? Потому что при масштабировании происходит несколько вещей одновременно:

• Количество запросов растет (прямолинейное увеличение стоимости)
• Разнообразие запросов растет (это может требовать более мощных моделей, которые дороже)
• Инфраструктурные расходы растут нелинейно (нужны более мощные серверы, резервирование, redundancy)
• Скрытые расходы проявляются (логирование, мониторинг, модерация становятся критичными)

Более реалистичная формула для прогноза:

Прогнозная стоимость = Текущая стоимость × (Рост трафика в раз) × Коэффициент инфляции расходов

Коэффициент инфляции расходов обычно находится в диапазоне 1,2 - 1,5 для облачных решений. Это означает, что если вы масштабируете в 10 раз, расходы растут не в 10 раз, а в 12-15 раз из-за необходимости использовать более мощные модели, лучше обслуживать систему, добавлять redundancy.

Пример. Сейчас у вас 100 000 запросов в месяц, стоимость $1000. Вы планируете рост в 10 раз (до 1 млн запросов). Прогнозная стоимость:

• Линейный прогноз: $1000 × 10 = $10 000
• С коэффициентом 1,3: $1000 × 10 × 1,3 = $13 000

Разница может показаться небольшой, но это $3000 в месяц, или $36 000 в год, которые вы не учли в бюджете.

Стоимость одного готового результата

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

Формула:

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

Если ваша система при первой попытке дает корректный ответ в 70% случаев, а остальные 30% требуют переделки или ручного исправления, то стоимость одного успешного результата выше, чем стоимость одного вызова LLM.

Расчет. LLM-запрос стоит $0,01. При 1000 запросов в месяц:

• 700 успешных результатов с первой попытки: $0,01 × 700 = $7
• 300 требуют переделки (еще $0,01 за попытку): $0,01 × 300 = $3
• 200 из переделанных всё еще не подходят (третья попытка): $0,01 × 200 = $2
• 100 требуют ручной работы (стоимость труда): примерно $100
• Всего расходов: $7 + $3 + $2 + $100 = $112
• Успешных результатов: 700 + 100 + 100 = 900 (из 1000 исходных)
• Стоимость одного результата: $112 / 900 = $0,124

Прямая стоимость была $0,01 за запрос, но с учетом всей цепочки — $0,124 за результат. Это более чем в 10 раз выше. Такие метрики помогают понять, стоит ли инвестировать в улучшение качества моделей или в автоматизацию переделок.

Сравнение цен между провайдерами

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

OpenAI: премиум-ценообразование с демократизацией

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

На 2025 год типичные тарифы OpenAI:

• GPT-4o (основная модель): $0,005 за 1000 входящих токенов, $0,015 за 1000 исходящих
• GPT-4 Turbo: примерно в 2 раза дешевле GPT-4o, но медленнее
• GPT-3.5 Turbo: примерно в 10 раз дешевле GPT-4o
• Reasoning-модель о1: значительно дороже, потому что платите за токены мышления

OpenAI также предлагает подписку за $20 в месяц (ChatGPT Plus) для конечных пользователей, но это не актуально для компаний, которые используют API.

Anthropic Claude: этичность как конкурентное преимущество

Anthropic позиционирует Claude как модель, которая лучше работает с контекстом, безопаснее и понятнее в своих рассуждениях. Ценообразование немного другое:

• Claude 3.5 Sonnet: $0,003 за входящий токен, $0,015 за исходящий (дешевле, чем GPT-4o на входящих)
• Claude 3 Opus: примерно в 2 раза дороже Sonnet
• Claude 3 Haiku: примерно в 5 раз дешевле Sonnet (самая дешевая опция у Anthropic)

Особенность Claude — система подписок. При годовом контракте с Anthropic вы можете получить скидки, если гарантируете большой объем использования.

Google Gemini: стратегия завоевания рынка

Google использует агрессивное ценообразование, чтобы завоевать долю рынка у OpenAI и Anthropic. Их стратегия — предложить конкурентные цены и щедрые условия для новых пользователей.

• Gemini 2.0 Flash: примерно $0,001 за входящий токен, $0,004 за исходящий (значительно дешевле конкурентов)
• Бесплатный уровень: 60 запросов в минуту для экспериментов
• Предложения для корпоративных клиентов: агрессивные скидки при контрактах

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

DeepSeek: геополитическое давление на цены

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

• DeepSeek V3: примерно $0,00014 за входящий токен, $0,00028 за исходящий (в 30-50 раз дешевле, чем OpenAI)
• Минимальный платеж: часто нет, платите только за использование

Парадокс DeepSeek в том, что при такой низкой цене модель показывает результаты, сопоставимые с более дорогими конкурентами. Это вызвало давление на весь рынок — все провайдеры пересмотрели ценовую политику.

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

Mistral AI и Cohere: борьба за нишевые сегменты

Mistral фокусируется на European market и предлагает модели, которые хорошо работают на европейских языках. Их ценообразование находится между бюджетным (DeepSeek) и премиумом (OpenAI).

Cohere специализируется на корпоративном сегменте с фокусом на мультиязычность и кастомизацию. Их ценовые модели обычно предполагают контракты, а не pay-as-you-go.

Локальная LLM on-premise: полная смета

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

Выбор GPU-сервера под размер модели

Размер модели определяет всю остальную архитектуру. Маленькие модели (7B параметров) можно запустить на потребительском GPU, средние (13B) требуют более мощного оборудования, крупные (70B и выше) требуют мощных серверных GPU или даже несколько GPU одновременно.

Типичные конфигурации и примерные стоимости (на российском рынке, 2025 год):

• LLM 7B (например, Mistral 7B, Llama 2 7B): GPU RTX 4090 или RTX 5090 (80-100 тыс. рублей за GPU), итого сервер примерно 200-250 тыс. рублей
• LLM 13B (Llama 2 13B, Mistral Nemo): GPU A100 (в аренде 20-30 тыс. в месяц) или A6000 (600-800 тыс. рублей за покупку)
• LLM 70B (Llama 2 70B, Mixtral): два-три GPU A100 (60-90 тыс. в месяц в аренде) или покупка за 2-3 млн рублей

Ключевой выбор: покупать оборудование или брать в аренду? Покупка требует большого капитала, но дешевле при длительном использовании (ROI через 6-12 месяцев). Аренда дорже в месяц, но не требует капитальных вложений и проще масштабировать.

Помимо GPU, нужно оборудование общего назначения:

• CPU: 16-32 ядер (30-50 тыс. рублей)
• RAM: 128-256 GB (100-200 тыс. рублей)
• Хранилище: SSD 2-4 TB (50-100 тыс. рублей)
• Сетевое оборудование, кейс, блоки питания (50-100 тыс. рублей)

Итого для сервера 13B: если покупать, то 500-800 тыс. рублей в единовременных инвестициях. Если арендовать через облачного провайдера, то 20-40 тыс. рублей в месяц.

Лицензии, open-source стек и инструменты

Хорошая новость: большинство популярных LLM распространяются под открытыми лицензиями (Apache 2.0, LLAMA 2, или аналогичными). Это означает, что вы не платите за саму модель.

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

Типичный open-source стек:

• Сама модель (LLaMA, Mistral, Qwen): бесплатно
• Фреймворк для развертывания (vLLM, Text Generation WebUI): бесплатно
• Система управления контекстом и памятью (LangChain, LlamaIndex): бесплатно
• Векторная база данных (Weaviate, Milvus, Qdrant): open-source версия бесплатна, но может потребовать платные расширения при масштабировании
• Мониторинг и логирование (Prometheus, Grafana): бесплатно

Но есть платные компоненты, которые часто нужны в production:

• Коммерческая поддержка фреймворков (опционально, но рекомендуется)
• Расширенные функции в векторных БД при большом масштабе
• Профессиональные решения для балансировки нагрузки (например, NGINX Plus вместо open-source NGINX)
• Платные инструменты для мониторинга и alerting (DataDog, New Relic) вместо бесплатного Prometheus

На практике, если у вас достаточно квалифицированная команда, весь open-source стек можно развернуть практически бесплатно, потратив только деньги на конфигурацию и установку (примерно 100-300 тыс. рублей работ).

Операционные расходы на содержание

После того как сервер развернут, начинаются текущие расходы. Это главное, что часто недооценивают при планировании on-premise решения.

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

• Электричество: GPU A100 потребляет примерно 300 Вт под нагрузкой. При постоянной работе это примерно 2200 кВтч в месяц (при цене 5-6 рублей за кВтч) = примерно 12 тыс. рублей
• Охлаждение: серверные помещения требуют активного охлаждения, это примерно 30-50% от стоимости электричества = 4-6 тыс. рублей
• Локация и физическая инфраструктура: аренда стойки в датацентре примерно 5-10 тыс. рублей в месяц, или если свой офис — это часть общих расходов на здание
• Интернет: скоростной канал с гарантией uptime примерно 10-20 тыс. рублей в месяц
• Техническое обслуживание и мониторинг: зарплата инженера на 0,5-1 ставку (это минимум) примерно 100-150 тыс. рублей в месяц
• Резерв оборудования и запасные части: примерно 5-10% от стоимости оборудования в год

Итого месячные расходы на содержание одного сервера 13B: примерно 140-200 тыс. рублей. Плюс амортизация оборудования (если покупали), которая может быть еще 30-50 тыс. рублей в месяц при 3-4 летнем сроке жизни оборудования.

При таких расходах on-premise решение имеет смысл только если вы делаете миллионы запросов в месяц. При среднем объеме использования облачный API будет значительно дешевле.

Способы сократить расходы

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

Маршрутизация запросов между моделями

Ключевая идея: не все запросы нуждаются в самой мощной модели. Если у вас есть простой вопрос, зачем отправлять его в GPT-4o, когда Claude Haiku справится за четверть цены?

Маршрутизация работает в несколько этапов:

1. Входящий запрос анализируется классификатором (может быть простой на основе ключевых слов или более сложный с помощью более дешевой LLM)
2. На основе сложности запроса он отправляется в соответствующую модель: простые — в Haiku/Sonnet, сложные — в Sonnet/Opus
3. Если первый ответ неудовлетворительный, система может повторно отправить запрос в более мощную модель

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

Пример. У вас 100 тыс. запросов в месяц. Без маршрутизации все идут в Claude 3.5 Sonnet ($0,018 за средний запрос) = $1800 в месяц. С маршрутизацией:

• 60% простых запросов в Claude Haiku ($0,0006 за средний) = $36
• 35% средних в Sonnet ($0,018) = $630
• 5% сложных в Opus ($0,036) = $180
• Итого: $846 (экономия 53%)

Кэширование: точное и семантическое

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

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

Семантическое кэширование смотрит на смысл запроса. Если два разных по формулировке запроса означают одно и то же, система использует кэшированный ответ. Это требует вычисления семантического сходства (обычно через эмбеддинги), но может дать экономию 20-40% на запросах, которые похожи, но не идентичны.

Некоторые провайдеры (например, Anthropic) предлагают встроенное кэширование запросов на уровне API. Если вы отправляете один и тот же контекст несколько раз подряд, система кэширует его и разрывает расходы на последующие запросы.

Батчинг и асинхронная обработка

Не все запросы требуют ответа в режиме реального времени. Если у вас есть задачи, которые можно обрабатывать асинхронно (например, анализ больших объемов текста ночью), можно отправить их батчами.

Батчинг позволяет провайдерам оптимизировать использование оборудования. OpenAI и другие провайдеры предлагают batch API с пониженной стоимостью (примерно 50% скидка) за счет того, что обработка может задержаться на несколько часов.

На практике, если 30% ваших запросов некритичны по времени, вы можете отправить их через batch API и сэкономить 15% на общих расходах.

Сокращение количества токенов в запросе

Каждый лишний токен — это лишние деньги. Есть несколько способов сократить количество токенов:

• Минимизация системных подсказок (prompts): вместо длинной инструкции из 1000 токенов использовать короткую из 100
• Сжатие контекста: вместо передачи всего документа передавать только релевантные части
• Использование специализированных форматов: например, для некоторых задач JSON компактнее, чем прозаический текст
• Кэширование системных подсказок: если одна и та же система промпт используется много раз, провайдеры позволяют ее кэшировать

Сокращение токенов на 20% может снизить расходы на 15-20%, потому что экономятся как входящие, так и исходящие токены.

Метрики и инструменты контроля

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

Единая точка маршрутизации (LLM Gateway)

LLM Gateway — это программное обеспечение (или архитектурный паттерн), которое находится между вашим приложением и провайдерами LLM. Все запросы идут через Gateway, который может:

• Логировать каждый запрос и его стоимость
• Маршрутизировать запросы между моделями и провайдерами
• Применять retry-логику и fallback'и
• Кэшировать ответы
• Ограничивать расходы по квотам или budgets

Примеры ready-made решений: LiteLLM, LangChain Hub, собственные разработки крупных компаний. Если у вас нет готового решения, можно написать простой Gateway на Python в несколько сотен строк кода.

Gateway — это инвестиция в начало проекта, которая окупается очень быстро через оптимизацию расходов.

Бюджет: допуск до вызова, а не отчет после

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

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

На уровне кода это может выглядеть так:

• У каждого юзера/проекта/отдела есть месячный бюджет
• Перед каждым вызовом система оценивает ожидаемую стоимость (на основе длины запроса, выбранной модели)
• Если после вызова бюджет будет превышен, система либо отклоняет вызов, либо перенаправляет в более дешевую модель
• После вызова фактическая стоимость записывается в счет

Это предотвращает неконтролируемый рост расходов и заставляет пользователей быть разумнее в использовании.

Наблюдаемость затрат в реальном времени

Вы должны видеть в реальном времени, сколько вы тратите. Это означает дашборды, которые показывают:

• Текущие расходы за день, неделю, месяц
• Расходы по моделям (какая модель потребляет больше всего денег)
• Расходы по пользователям или проектам
• Тренды: растут расходы или падают, почему
• Cost per request: средняя стоимость одного запроса
• Аномалии: когда расходы резко выросли

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

Даже простой дашборд на основе CSV с расходами по дням может спасти вас от неприятных сюрпризов.

Частые ошибки при расчете стоимости

После анализа десятков проектов видны паттерны ошибок, которые компании делают систематически. Они не фатальны, но стоят денег.

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

Вторая ошибка — забывают про скрытые расходы. На начальном этапе проекта все внимание на самой LLM. Но потом обнаруживаются эмбеддинги, векторные БД, логирование, мониторинг. Каждое из них может добавить 10-30% к счету.

Третья ошибка — недооценивают качество. Дешевая модель дает плохие результаты, что требует дополнительных попыток или ручной переделки. Сэкономив на цене модели на 20%, вы потратите 50% на переделки. Иногда дороже использовать сразу правильную модель.

Четвертая ошибка — не включают в расчеты стоимость жизненного цикла. Модель нужно постоянно переобучать на новых данных, обновлять, адаптировать к новым требованиям. Это текущие расходы, которые часто забывают при первоначальном планировании.

Пятая ошибка — не рассчитывают ROI. Компания внедрила LLM, но никто не проверил, действительно ли она принесла пользу. Может быть, деньги были потрачены впустую, или наоборот, потенциал недоиспользован. Без понимания ROI невозможно принять решение о расширении.

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