Почему прайс-лист врёт с первого взгляда
Когда вы выбираете LLM-провайдера для фичи, первое, на что смотрят — таблица "цена за миллион токенов". Она удобна тем, что даёт единое число, но это число обманчиво: оно сравнивает цену на входе (input) с ценой на выходе (output), но не учитывает, что структура вашего реального трафика может отличаться от этой пропорции в разы.
Типичная картина: output-токены стоят в 4-6 раз дороже input-токенов почти у всех провайдеров. Если ваша фича — это длинный system-промпт плюс короткий ответ (классификация, экстракция данных, модерация), вы платите в основном за input, и разница в input-цене между провайдерами определяет счёт. Если ваша фича — это генерация длинного текста, кода или отчёта из короткого запроса, всё наоборот: решает output-цена. Сравнивать провайдеров по номинальной "средней" цене без учёта своего реального соотношения input/output — это как сравнивать тарифы такси только по цене посадки, игнорируя цену километра.
Практический шаг: прежде чем сравнивать провайдеров, прогоните реальные логи вашей фичи (не тестовые запросы) через подсчёт токенов и получите фактическое соотношение input:output для вашего конкретного use case. Оно у разных фич отличается на порядок.
Контекст и кэширование — где прячется реальная экономия
Второй слой, который прайс-лист не показывает — это цена контекстного окна и работа кэширования промптов. Если ваша фича постоянно прогоняет один и тот же длинный system-промпт (инструкции, примеры, схему данных) с разным пользовательским вводом на конце, без кэширования вы каждый раз платите полную цену за этот статичный кусок.
Prompt caching — это механизм, при котором повторяющийся префикс промпта (system-инструкции, few-shot примеры, документы) сохраняется на стороне провайдера, и повторное обращение к нему стоит в разы дешевле полной цены — обычно порядка 10% от базовой ставки на чтение из кэша. Но у этого механизма есть подводные камни, которые ломают экономику, если о них не знать:
- **Кэш — это точное совпадение префикса.** Любое изменение в начале промпта (дата, ID запроса, переставленный порядок полей в JSON) обнуляет кэш для всего, что идёт после этой точки. Если вы вставляете текущую дату или уникальный ID в начало system-промпта — вы платите заново каждый раз.
- **Запись в кэш дороже обычного запроса** (обычно в 1.25-2 раза), а не дешевле. Кэш окупается только начиная со второго-третьего обращения к одному и тому же префиксу в течение времени жизни кэша (обычно 5 минут, у части провайдеров можно продлить до часа за дополнительную плату).
- **Минимальный размер кэшируемого префикса** — если ваш system-промпт короче нескольких сотен-тысячи токенов, кэш может тихо не сработать: ошибки не будет, просто экономии тоже не будет.
Практический чек-лист для аудита кэша в своей фиче: 1. Замерьте, какая доля токенов реально идёт из кэша (провайдеры возвращают это в usage-полях ответа) — если доля близка к нулю при повторяющихся промптах, ищите "невидимый инвалидатор" (таймстемп, несортированный JSON, разный порядок инструментов). 2. Разделите промпт на стабильную часть (инструкции, схема) и переменную (пользовательский ввод) — стабильная должна идти первой. 3. Не переключайте модель или набор инструментов посреди диалога без необходимости — это тоже сбрасывает кэш.
Батчинг и асинхронность — скидка за терпение
Третий инструмент экономии — батчинг: если фича не требует ответа за секунды (модерация контента постфактум, обогащение базы данных, ночная генерация дайджестов), большинство провайдеров дают скидку порядка 50% за асинхронную обработку с задержкой в пределах часов. Для продукта это означает разделение фич на два класса ещё на этапе архитектуры: real-time (чат, автодополнение) — обычный API, и batch-eligible (обработка больших объёмов без пользователя "на линии") — batch API.
Ошибка, которую часто допускают: тащить batch-eligible нагрузку через синхронный API просто потому, что так проще написать код. Если у вас есть фоновая задача, обрабатывающая тысячи записей раз в сутки, вынесение её в батч режет счёт пополам без потери качества.
Как считать unit-экономику фичи правильно
Сведите всё в простую формулу для каждой AI-фичи продукта:
**Стоимость на один вызов = (input-токены без кэша × цена input) + (input-токены из кэша × цена кэш-чтения) + (output-токены × цена output)**, умноженное на скидку батчинга, если применимо.
Дальше — практические шаги: - Посчитайте эту стоимость на реалистичном сэмпле из продакшена, а не на "hello world" примере. - Умножьте на ожидаемое количество вызовов на пользователя в месяц — так вы получите AI-cost per user, который нужно сравнивать с ARPU. - Заложите буфер 20-30% на рост длины контекста по мере развития фичи (пользователи со временем пишут более длинные запросы, история диалога растёт). - Пересчитывайте эту метрику при каждой смене модели или провайдера — разница в тарифах, в токенизаторе (одна и та же фраза может давать разное число токенов у разных моделей) и в работе кэша делает старые расчёты нерелевантными за один апдейт.
Итог: цена "за миллион токенов" — это витрина, а не чек. Настоящая юнит-экономика AI-фичи складывается из соотношения input/output в вашем трафике, из того, насколько эффективно вы используете кэширование, и из того, разделили ли вы нагрузку на real-time и batch. Разница между продуктом, который считает это на старте, и тем, который спохватывается после первого крупного счёта, — это разница между предсказуемой маржой и неприятным сюрпризом в конце месяца.
