Вопрос «сколько это будет стоить» на запуске проекта с языковыми моделями обычно получает ответ «копейки, там же тысячные доли за запрос». Через месяц приходит счёт, который эту оценку опровергает.
Проблема не в тарифах, а в том, что считают не то. Разберём, из чего складывается реальная стоимость, где она вырастает незаметно и как оценить окупаемость до, а не после запуска.
Из чего складывается цена запроса
Базовая единица это токен, примерно три до четырёх символов текста для латиницы и меньше для кириллицы. Русский текст расходует токенов заметно больше, чем английский той же длины, и это первый источник недооценки.
Оплачивается и вход, и выход, но по разным ставкам: выход обычно дороже входа в несколько раз.
Формула простая: стоимость запроса это входные токены умножить на входную ставку плюс выходные токены умножить на выходную. Сложности начинаются, когда считают, что входит во входные токены.
Что раздувает вход
Здесь теряется большинство бюджетов.
Системная инструкция. Передаётся с каждым запросом. Инструкция на три тысячи токенов при ста тысячах запросов в месяц это триста миллионов входных токенов только на неё.
История диалога. Растёт линейно, а суммарная стоимость диалога квадратично. Разговор из двадцати реплик стоит не в двадцать раз дороже одной, а в разы больше.
Найденные документы. В системах с поиском по базе в промпт подставляются фрагменты. Пять фрагментов по тысяче токенов это пять тысяч входных токенов на каждый запрос.
Описания инструментов. При работе с вызовом функций описания передаются каждый раз, и на каждом шаге цикла.
Примеры в промпте. Десять примеров по двести токенов это две тысячи на запрос.
Практика: посчитайте реальный размер типичного запроса токенизатором, а не на глаз. Расхождение с ожиданием обычно составляет разы.
Кэширование входа
Главный рычаг экономии, который часто не используют.
Если начало запроса повторяется от вызова к вызову, его можно закэшировать. Повторное чтение из кэша стоит существенно дешевле обычного входа, у разных поставщиков экономия достигает порядка.
Условие: неизменная часть должна быть в начале и совпадать побайтово. Отсюда правило проектирования промпта: сначала всё постоянное, потом всё меняющееся. Дата в начале системной инструкции обнуляет кэш на каждом запросе.
Кэш живёт ограниченное время, поэтому выигрыш зависит от частоты обращений. При редких запросах он может не сработать вовсе.
Выбор модели под задачу
Второй по значимости рычаг. Разница в цене между старшей и младшей моделью одного семейства это порядок и больше.
Практический подход: разложите систему на шаги и подберите модель каждому.
- Классификация, извлечение полей, маршрутизация. Младшая модель справляется. Это обычно самые частые вызовы.
- Написание текста, анализ, рассуждение. Старшая модель оправдана.
- Проверка результата. Часто хватает младшей.
Типичная ошибка: гнать весь поток через старшую модель, потому что «так надёжнее». Разделение шагов нередко снижает счёт в разы без потери качества.
Второй приём: каскад. Сначала младшая модель, при низкой уверенности повтор на старшей. Работает, когда сложные случаи составляют меньшинство.
Скрытые расходы
То, что не попадает в первую смету.
Повторы при ошибках. Неудачный разбор ответа, провал валидации, таймаут. Каждый повтор оплачивается. При десяти процентах повторов счёт растёт на десять процентов.
Тестирование. Прогон набора проверочных сценариев после каждого изменения промпта. При частых правках это заметная доля.
Многошаговые цепочки. Задача, решённая в пять шагов, стоит впятеро дороже одношаговой, а с ростом контекста ещё дороже.
Эмбеддинги. В системах с поиском по базе индексация документов стоит денег, а при изменении модели эмбеддингов индекс пересчитывается целиком.
Инфраструктура. Векторная база, очереди, логи, хранение истории.
Работа людей. Основная статья на старте. Разработка, отладка промптов, разметка данных для оценки. Обычно превышает расходы на сами вызовы в первые месяцы.
Порядок расчёта
Как оценить до запуска.
- Опишите один типичный сценарий по шагам: сколько вызовов, к какой модели.
- Измерьте токены на каждом шаге токенизатором, а не оценкой.
- Посчитайте стоимость одного сценария с учётом кэширования.
- Добавьте запас на повторы, пятнадцать до двадцати процентов.
- Умножьте на ожидаемый объём и возьмите верхнюю оценку объёма, а не среднюю.
- Прибавьте инфраструктуру и работу людей.
Сравнивать результат нужно не с нулём, а со стоимостью текущего способа решения задачи. Автоматизация, которая стоит сто рублей за операцию вместо человеческих трёхсот, выгодна, даже если сто рублей кажутся много.
Пример расчёта
Возьмём типовой сценарий: обработка обращений в поддержку. Цифры условные, но пропорции реальные.
Сценарий. Обращение классифицируется, по нему ищутся три фрагмента базы знаний, формируется черновик ответа, черновик проверяется на соответствие правилам.
Вход. Системная инструкция около полутора тысяч токенов, текст обращения примерно триста, найденные фрагменты около полутора тысяч. Итого порядка трёх тысяч трёхсот входных токенов на основной шаг.
Выход. Ответ примерно четыреста токенов.
Шаги. Классификация на младшей модели, генерация на старшей, проверка на младшей. Три вызова, из них дорогой один.
Кэширование. Системная инструкция неизменна и стоит первой, поэтому полторы тысячи входных токенов из трёх тысяч трёхсот оплачиваются по льготной ставке. Это снимает почти половину входных расходов основного шага.
Что видно из такого расчёта. Во-первых, доля дорогой модели в общем счёте определяется не числом шагов, а тем, на каком шаге лежит генерация длинного текста. Во-вторых, найденные фрагменты сопоставимы по весу с самой инструкцией, и сокращение их числа с пяти до трёх даёт ощутимую экономию. В-третьих, классификация и проверка вместе стоят меньше десятой части сценария, поэтому оптимизировать их бессмысленно.
Отсюда общее правило: сначала найдите самый дорогой шаг, потом занимайтесь им. Улучшение дешёвых шагов создаёт ощущение работы и не меняет счёт.
Когда не окупается
Честные признаки.
Низкий объём. При десятке операций в день экономия на автоматизации не покроет разработку и поддержку. Порог окупаемости обычно начинается с сотен операций в месяц.
Высокая цена ошибки. Если каждый результат всё равно проверяет человек, выигрыш только в скорости черновика, а не в замещении труда.
Задача решается правилами. Если условия детерминированы, обычный код надёжнее и бесплатен в работе.
Требования к точности выше достижимой. Модель с точностью девяносто пять процентов на задаче, где нужно девяносто девять и девять, не подходит ни за какие деньги.
Данные меняются быстрее, чем система успевает адаптироваться.
Локальные модели: считаем честно
Соблазн уйти от оплаты по токенам понятен, но расчёт нужен полный.
Расходы: железо либо аренда, электричество, администрирование, обновления, простой при отказе. И качество младших моделей, которые реально запускаются локально, ниже облачных старших.
Порог, за которым локальный запуск начинает выигрывать, это устойчиво высокий и предсказуемый объём. При неравномерной нагрузке облако выигрывает, потому что вы платите за использование, а не за простаивающее железо.
Отдельный довод в пользу локального запуска это требования к данным: если данные нельзя передавать наружу, вопрос стоимости вторичен. Требования к железу для таких задач мы разбирали в материале про питание рабочей станции, они близки к требованиям рендера.
Что делать, когда счёт уже большой
Порядок действий по убыванию отдачи.
- Найдите, куда уходит. Разбивка расходов по шагам обязательна. Обычно восемьдесят процентов приходится на один или два шага.
- Включите кэширование и переставьте промпт так, чтобы постоянная часть была в начале.
- Понизьте модель на шагах, где это возможно, и проверьте качество на отложенных данных.
- Сократите вход. Уберите из промпта то, что не влияет на результат. Проверяется экспериментом, а не мнением.
- Ограничьте историю в диалогах: последние несколько реплик плюс сжатая сводка старых.
- Сократите выход. Просьба отвечать кратко экономит на самой дорогой части.
- Уберите лишние шаги. Часто в цепочке есть вызовы, которые ничего не меняют.
Если после этого счёт всё ещё велик, рассмотрите дообучение младшей модели под конкретный шаг: методику разбирали в материале про дообучение LoRA.
Частые вопросы
Почему русский текст дороже английского?
Токенизаторы обучены преимущественно на английском, и кириллица дробится на большее число токенов. Разница может достигать полутора до двух раз при равной длине текста.
Как измерить токены заранее?
Библиотекой токенизатора соответствующего семейства моделей. Оценка по числу символов даёт ошибку, особенно на кириллице и на коде.
Стоит ли считать стоимость на этапе прототипа?
Считать нужно, оптимизировать нет. На прототипе важнее понять, решается ли задача вообще. Но порядок стоимости стоит прикинуть до того, как проект уйдёт в разработку.
Как контролировать расходы в работе?
Логируйте токены на каждый вызов с привязкой к шагу и сценарию. Без этого источник роста счёта не находится. Плюс лимиты на уровне ключа.
Даёт ли экономию сокращение числа вызовов функций?
Да, и заметную: каждый шаг цикла это полный запрос с растущей историей. Уменьшение числа шагов с пяти до трёх снижает стоимость сценария примерно вдвое. Как проектировать инструменты, чтобы шагов было меньше, разбирали в материале про вызов функций.