Операционная экономика LLM: как считать стоимость до масштабирования
Почему токенные расходы на языковые модели нужно моделировать заранее и как не получить неожиданный счёт при росте нагрузки.
Большинство компаний, которые начинают строить продукты на языковых моделях, проходят один и тот же путь. Пилот работает, результаты хорошие, принимается решение масштабировать. И тут выясняется, что счёт за API в десять раз больше, чем ожидалось. Не потому что технология плохая - а потому что никто не считал операционную экономику.
Это не экзотическая проблема. Это вопрос, который стоит задать до того, как функция уходит в продакшн.
Из чего складывается стоимость
LLM API тарифицируется по токенам. Токен - это примерно 4 символа для английского текста, немного меньше для кириллицы из-за особенностей токенизации. Цена считается отдельно за входящие токены (запрос) и исходящие (ответ модели).
Для одного запроса стоимость ничтожная. Проблема появляется при масштабировании. Тысяча запросов в день - это уже другой порядок. Сто тысяч - ещё другой.
Несколько факторов, которые сильно влияют на итоговую сумму:
Длина контекста. Если к каждому запросу прикладывается большой системный промпт или история диалога - это сотни или тысячи токенов накладных расходов на каждый вызов. Умножается на количество запросов.
RAG-контекст. Если используется retrieval-augmented generation, каждый запрос несёт в себе извлечённые фрагменты документов. Несколько фрагментов по 500 токенов каждый - это дополнительные 1-2 тысячи токенов на запрос.
Длина ответа. Ответы модели стоят дороже входящих токенов у большинства провайдеров. Если задача предполагает развёрнутые ответы, это важный множитель.
Выбор модели. GPT-4 дороже GPT-3.5 в разы. Для задач, где качество GPT-3.5 достаточно - переплата за GPT-4 не оправдана.
Простая модель для оценки
Прежде чем запускать в продакшн, стоит сделать элементарный расчёт.
Возьмите типичный запрос и посчитайте его стоимость: системный промпт + контекст + запрос пользователя + ожидаемый ответ. Умножьте на ожидаемое количество запросов в день, в неделю, в месяц.
Это даст порядок цифр. Если порядок цифр неприятно удивляет - нужно оптимизировать до запуска, а не после.
Несколько рычагов оптимизации, которые реально работают: кэширование ответов на типовые запросы; сжатие системного промпта без потери смысла; использование более дешёвой модели там, где качество дорогой не нужно; ограничение длины ответа там, где короткий ответ достаточен.
О неожиданных сценариях
Реальное использование часто отличается от предполагаемого. Пользователи задают более длинные вопросы. Контекст диалога растёт. Кто-то из команды запускает экспериментальный скрипт, который делает тысячу вызовов.
Лимиты расходов на уровне ключа API - обязательный инструмент. Не из паранойи, а из базовой операционной культуры. Неожиданный счёт на несколько тысяч долларов - это неприятно. Неожиданный счёт на десятки тысяч - это уже инцидент.
Вопросы перед запуском
- Какова ожидаемая нагрузка - количество запросов в сутки при нормальном и пиковом использовании?
- Какова типичная длина одного обращения к модели с учётом всего контекста?
- Стоит ли качество выбранной модели разницы в цене для этой конкретной задачи?
- Есть ли механизм оповещения при превышении расходного порога?
- Есть ли ответ на вопрос "что если использование вырастет в 10 раз" - выдержит ли бюджет?
Ответы на эти вопросы не требуют сложного моделирования. Но их отсутствие регулярно приводит к неприятным разговорам с финансовым директором.