Контекстное окно LLM: почему растет стоимость обработки запросов
Стоимость вызова LLM зависит не только от числа обращений к API. На неё влияют длина входного контекста, объём генерации, повторная обработка истории и правила тарификации конкретной модели.
Поэтому при росте расходов полезно смотреть не только на общий счёт, но и на состав каждого запроса.
Вопрос «как проверить почему растет стоимость обработки запросов» начинается с простого разреза: сколько токенов уходит на вход и выход, какая часть входа попадает в кэш и что именно добавляет контекст на каждом шаге пайплайна. Без этих данных длинная история, разросшаяся RAG-выдача и повторные вызовы выглядят одинаково: как внезапно подорожавший API.
Математика внимания: почему длинный контекст обходится дороже
В Transformer механизм self-attention помогает модели связывать токены между собой. В классическом варианте при обработке последовательности растёт число взаимодействий между её позициями, поэтому вычисления внимания могут увеличиваться примерно квадратично относительно длины последовательности. Это характеристика части вычислений модели, но её не следует напрямую переводить в такую же формулу для счёта за API.
Для пользователя тарификация обычно привязана к количеству входных и выходных токенов, а условия зависят от модели и провайдера. Если вход удвоился, оплата за входные токены при неизменной ставке тоже увеличится примерно вдвое. При этом нагрузка на инфраструктуру может измениться иначе: на неё влияют архитектура модели, реализация внимания, параллелизм и доступность памяти. Одно не даёт универсальной формулы для другого.
Длинный контекст может обходиться дороже и без пересечения какого-либо тарифного порога. Если к запросу добавили историю переписки или больше фрагментов из базы знаний, вырос объём входных токенов. Порог важен там, где тариф действительно меняется после определённой длины контекста; до него стоимость всё равно может расти вслед за числом токенов.
Есть и менее очевидный источник расходов: в последовательных шагах диалога приложение может снова передавать предыдущую историю. Для пользователя это всё ещё один разговор, но для API каждый такой вызов становится отдельной обработкой входа. Если в запрос каждый раз включается весь накопленный контекст, токены прошлых реплик повторно участвуют в тарификации, если их чтение не покрывает кэширование на условиях конкретного сервиса.
Длинная история становится расходом не сама по себе, а тогда, когда приложение снова отправляет её модели.
Поэтому при разборе затрат стоит отделять число вызовов от их состава. Два пайплайна с одинаковым количеством обращений могут иметь разный профиль расходов: один отправляет короткие инструкции и компактные документы, другой каждый раз прикладывает длинную историю и объёмную RAG-выдачу.
KV-кэш и нагрузка на видеопамять: скрытые расходы инфраструктуры
Во время обработки последовательности модель формирует промежуточные представления Key и Value. Их сохраняют в KV-кэше, чтобы при генерации следующих токенов не пересчитывать уже обработанные позиции. Для длинного контекста такой кэш занимает больше памяти; его объём зависит также от архитектуры модели, точности хранения и числа запросов, которые обслуживаются одновременно.
Это важно для инфраструктуры, но не означает, что каждый провайдер обязательно выставит отдельную строку счёта за KV-кэш или автоматически применит повышенную ставку. Провайдер может учитывать нагрузку иначе: через общую структуру тарифа, ограничения доступности или выбор модели. Поэтому KV-кэш помогает понять, почему длинные запросы требовательны к ресурсам, но сам по себе не объясняет изменение конкретного счета.
Для продуктовой команды практический вопрос звучит иначе: какой контекст система передаёт модели и зачем? В RAG-пайплайне полезно проверять размер и состав выдачи. В чат-продукте стоит выяснить, отправляется ли вся история или только необходимая её часть. В агентном сценарии нужно учитывать повторные вызовы и обращения к инструментам: каждый следующий шаг может получить новый или заново собранный контекст.
Показатель среднего размера запроса здесь малоинформативен, если длинные вызовы смешаны с короткими. Полезнее смотреть распределение входных токенов по типам задач, маршрутам приложения и моделям. Тогда становится видно, например, что увеличение расходов связано с конкретным сценарием поиска, а не с общей нагрузкой продукта.
Тарифные ловушки: как пороги контекста меняют стоимость запроса
У разных моделей и провайдеров отличаются ставки за входные и выходные токены, правила для кэшированных токенов и условия тарификации длинного контекста. Некоторые тарифы могут менять ставку после указанного порога. Но сам факт наличия порога не означает, что ниже него запросы стоят одинаково: если оплачивается каждый токен, увеличение входа способно увеличить стоимость и внутри одного тарифного диапазона.
Универсальной таблицы цен для OpenAI, Anthropic или Google Gemini здесь не будет: ставки привязаны к конкретным моделям и могут меняться. Сравнивать провайдеров только по одной цене за миллион токенов тоже рискованно. Для нагрузки с большим объёмом генерации важна стоимость выхода; для RAG-системы с длинными документами особенно заметна стоимость входа; при повторяющихся префиксах значение могут иметь условия кэширования.
Вместо общей таблицы тарифов удобнее вести для своего приложения небольшой профиль затрат:
| Что сравнивать | Что это показывает |
|---|---|
| Входные токены | Сколько текста приложение отправляет модели |
| Выходные токены | Сколько модель генерирует и по какой ставке это тарифицируется |
| Кэшированные токены | Какая часть входа обслужена через кэш и как она учитывается в тарифе |
| Длина контекста и тарифный диапазон | Пересёк ли вызов порог, если у выбранной модели он есть |
| Модель и сценарий | Как распределяются затраты между задачами и конфигурациями |
Проверять условия нужно по актуальной документации выбранной модели. Название провайдера само по себе недостаточно: у одного поставщика тарифы и доступные механизмы могут различаться между моделями. Если в системе несколько маршрутов, храните идентификатор фактически вызванной модели, а не только название модели, заданной по умолчанию. Иначе переход на другой маршрут может изменить стоимость, оставаясь незаметным в агрегированном отчёте.
При анализе порогов важно считать контекст в том виде, в каком его видит API. В него могут входить системные инструкции, история, RAG-фрагменты, описания инструментов и другие служебные блоки. Отдельно учитывайте, что условия порога и расчёт его применимости определяются документацией конкретной модели. Полагаться на приблизительный размер документа или число сообщений недостаточно: текст переводится в токены не один к одному.
Prompt Caching: где теряется экономия на кэшированных токенах
Prompt Caching позволяет повторно использовать обработанный префикс, если запросы подходят под условия кэширования провайдера. Это может быть полезно для системной инструкции или другого стабильного блока, который регулярно отправляется в модель. Условия, минимальная длина кэшируемого блока, срок хранения и цена чтения или записи различаются. Их стоит проверять отдельно для используемой модели.
Кэш не отменяет оплату за весь запрос: динамическая часть по-прежнему обрабатывается, а прочитанные из кэша токены учитываются по специальному тарифу. Экономию нужно оценивать по фактическим ценам записи, чтения и обычной обработки. Например, в фактуре для Anthropic запись указана с коэффициентом 1,25 к базовой цене входа, а чтение стоит примерно 10% базовой цены. При таких условиях даже одно чтение может оказаться дешевле повторной обработки того же блока без кэша, если сравнивать только эти операции. Итог зависит от того, будет ли кэш прочитан до истечения срока действия и какие ещё условия тарифа применяются.
Стабильность префикса остаётся важной. Если в начало запроса попадают меняющиеся значения, например timestamp или идентификатор сессии, они могут мешать повторному использованию общего блока. В зависимости от правил конкретного кэша любое изменение способно повлиять на совпадение префикса и на то, какая его часть доступна для повторного использования. Практический приём простой: отделять общие инструкции от данных, которые меняются от запроса к запросу, и проверять результат по метрикам кэширования провайдера.
Не стоит заранее считать, что кэш сработал только потому, что промпт кажется одинаковым. Проверьте фактическое число кэшированных токенов в ответе API и сопоставьте его с объёмом повторяемого блока. Если при неизменной структуре кэшированных токенов нет, причина может быть в ограничениях модели, размере префикса, сроке действия кэша или изменении запроса. Одного общего показателя экономии по аккаунту для такой диагностики недостаточно.
Инструментарий observability для контроля затрат на инференс
Чтобы понять, как проверить почему растет стоимость обработки запросов, полезно связать каждое обращение к модели с его задачей и этапом пайплайна. Агрегированный биллинг показывает итоговую сумму, но редко объясняет, что именно изменилось. Для этого нужна трассировка вызовов с метриками токенов и признаками сценария.
На каждом вызове, где это доступно, стоит сохранять:
- идентификатор запроса, сервиса и сценария, чтобы связать расход с продуктовой функцией;
- модель и маршрут, по которым фактически прошёл вызов;
- число входных и выходных токенов;
- число токенов, прочитанных из кэша, и другие доступные показатели кэширования;
- сведения о длительности и результате вызова, включая ошибки и повторные попытки;
- объём RAG-выдачи или число добавленных фрагментов;
- число шагов агента и обращений к инструментам;
- оценку стоимости по актуальным условиям тарифа на момент вызова.
Если провайдер возвращает дополнительные показатели, например отдельно тарифицируемые токены рассуждений, их тоже нужно учитывать. Не каждому полю соответствует универсальный параметр для всех API, поэтому список следует адаптировать под выбранного поставщика. Полезно хранить исходные данные ответа API: это позволит пересчитать стоимость, если тариф изменится, и сверить внутреннюю оценку с биллингом.
При анализе сначала сравните входные токены, выходные токены и кэшированные токены на уровне конкретных сценариев. Рост входа при стабильном числе вызовов может указывать на увеличение истории или RAG-контекста. Рост выходных токенов может быть связан с настройками генерации или характером задач. Увеличение числа повторных попыток и шагов агента означает, что на один пользовательский запрос приходится больше обращений к модели. Каждая версия требует проверки по трассам, а не только по итоговой сумме.
Отдельно полезно следить за изменениями в составе запроса. Например, сравнивать объём системных инструкций, число RAG-фрагментов и размер передаваемой истории между релизами. Если после изменения логики поиска резко увеличился входной контекст, связь с расходами будет заметна сразу. Если изменился тариф или фактически вызываемая модель, это тоже станет отдельной гипотезой, а не объяснением наугад.
Без данных о составе вызова спор о причинах роста счёта быстро превращается в подбор оптимизаций вслепую.
Диагностику удобно проводить последовательно: проверить, изменилось ли число вызовов; сравнить средний и распределённый по сценариям размер входа; отдельно посмотреть выход и кэширование; затем проверить повторные попытки, выбранные модели и тарифные условия. Такой порядок не обещает мгновенного решения, зато помогает не сокращать контекст там, где проблема, например, в лишнем шаге агента или ошибочном маршруте.
Стоимость обработки запроса зависит от того, что приложение отправляет модели, сколько раз оно это делает и как выбранная модель тарифицирует вход, выход и кэш. Длина контекста влияет на расход через количество токенов; устройство модели и инфраструктуры объясняет техническую нагрузку, но не заменяет проверку биллинга. Пороговые тарифы могут добавлять ещё один фактор, если конкретная модель их использует.
Поэтому начинать стоит с трассировки: связать вызовы с задачами, измерить состав контекста и проверить фактические условия модели. Тогда сокращение истории, настройка RAG, изменение структуры промпта или переход на другую модель становятся ответами на наблюдаемую проблему, а не универсальными советами.