Как снизить расходы на ИИ-модели
при больших контекстах

Исследование и статья подготовлены 4 октября 2026 года. Цены, скидки, лимиты и доступность функций быстро меняются: перед расчётом бюджета и запуском пилота перепроверьте условия на страницах первоисточников.

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

В проектах с длинными документами, историей диалога и многошаговыми агентами счёт растёт не только из-за тарифа модели. Его увеличивают повторная передача одного и того же контекста, лишние вызовы, проверки, повторные попытки, embeddings, reranking, ручная доработка и работа инфраструктуры. Поэтому правильный объект оптимизации — не цена токена, а стоимость одной принятой и проверенной бизнес-операции.

Вызовы моделей

Вход, генерация, reasoning и обработка кэшированного контекста.

Подготовка и повторы

Retrieval, embeddings, reranking, проверки и повторные попытки.

Инфраструктура

Вычисления, хранение, шлюз, лицензии и сопровождение.

Работа человека

Проверка результата и ручная доработка до принятия.

Сумма всех расходов ÷ число операций, прошедших критерии качества= стоимость одной принятой операции

Это структура расчёта, а не доли расходов: их нужно измерить в конкретном процессе.

Сократить контекст до полезного

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

Практичный первый шаг: сравнить простой retrieve-then-read с полным документом на одинаковых задачах. В работе EMNLP 2025 о сильных базовых подходах к RAG метод DOS RAG сохранял исходный порядок выбранных фрагментов. В англоязычных задачах вопросов и ответов по одному документу (single-document QA) на GPT-4o/mini он часто был сопоставим с RAPTOR/ReadAgent или лучше, но не при каждом бюджете; на QuALITY/GPT-4o полный документ оказался лучше. Полная стоимость embeddings и предварительной обработки не измерялась. Это аргумент включить простой вариант в сравнение, а не универсальная победа RAG над длинным контекстом или доказательство экономии в многодокументных задачах. Максимальный бюджет извлечения и средний фактический расход токенов нужно различать.

1. Архив документовИсходники и их версии

→

2. Поиск под задачуОтбор; при необходимости — reranking

→

3. Проверяемые фрагментыИсточник, версия, точная цитата

→

4. Запрос моделиЗадача + правила + нужный контекст

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

Что нельзя потерять при сжатии

Компрессия промпта, например LLMLingua, может уменьшить объём входа, но сам компрессор тоже стоит денег и может удалить числа, исключения или оговорки. Для договоров, регламентов и инженерных допусков безопаснее сначала извлекать оригинальные фрагменты с источником. Если применяется сжатие, его нужно проверять отдельным набором критичных фактов.

Наконец, длинный контекст сам по себе не гарантирует равномерное использование информации. Исследование Lost in the Middle показало зависимость качества от позиции релевантного факта в изученных QA и key-value задачах 2023 года. Это не универсальный закон для всех современных моделей: на своей модели нужно тестировать не только размер контекста, но и расположение доказательства при неизменных вопросах.

Убрать агентные накладные расходы

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

• Каталог инструментов. Отложенная загрузка схем может уменьшить контекст без отключения доступных функций. Например, OpenAI Tool search документирован для Responses API и GPT-5.4 и позднее, а не для любого MCP-клиента. Поиск добавляет собственный шаг; проверять нужно размер схем, полноту обнаружения нужных инструментов, задержку и стоимость принятой задачи. Авторизация остаётся отдельной проверкой.
• Результаты инструментов. Вместо сырой таблицы полезно возвращать нужные поля, агрегаты и ограниченную выборку с версией источника, общим числом записей, признаком усечения и способом дочитать. В паттерне Anthropic Code execution with MCP промежуточные данные обрабатываются кодом до передачи модели. Полные суммы и поиск исключений нужно считать по полным данным, а не по первым строкам. Измерять размер результатов, повторные чтения и пропущенные факты; учитывать цену вычислений и границы доступа среды исполнения.
• Передача задачи другому агенту. Краткий контракт должен сохранять цель, границы, известные факты, источники, запреты, формат результата и условие остановки. Отдельное окно не означает бесплатную работу: субагенты Claude Code делают собственные запросы. В OpenAI Agents SDK handoff по умолчанию передаёт историю; короткий input_type сам её не сокращает. Сравнивать нужно весь расход координатора, исполнителей и интеграции, а также дубли поисков и переделки.
• Пустые циклы и повторы. Известную арифметику, форматирование и ожидание события лучше выполнять кодом или планировщиком, а не новым рассуждением модели; это соответствует принципу не обращаться к LLM по умолчанию. Число шагов и повторных попыток ограничивают. Если ошибка повторяется, а условия её возникновения не изменились, дальнейшие попытки прекращают. Повтор записи требует идемпотентности. Измерять число физических вызовов, успешное восстановление и остановки по лимиту; остановка с частичным результатом не равна успеху.

Краткость ответа, reasoning и жёсткий лимит являются разными рычагами. В OpenAI Responses max_output_tokens включает рассуждение, видимый ответ и невидимое форматирование. Слишком малый лимит может дать оплаченный incomplete ещё до появления ответа. Просьба «кратко» не ограничивает скрытое рассуждение, а поддержка reasoning effort зависит от модели. Проверять контракт ответа, effort и лимит следует раздельно: по полному output, качеству, доле незавершённых ответов, повторам и времени до полезного результата.

Кэшировать промпт и ответ с учётом прав

Prompt cache

Повторно используется обработка стабильного начала запроса.

Постоянный префиксИнструкции · инструменты · правила проекта

Переменная частьДанные текущей задачи · вопрос

Модель всё ещё генерирует ответ

Semantic cache

Для подходящего похожего запроса используется уже готовый ответ.

Вопрос + область доступаАрендатор · проект · права · версия знаний

Проверка совпадения и свежестиПорог сходства · TTL · инвалидация

При допустимом попадании генерация не нужна

При промахе семантического кэша запрос идёт в модель. Сходство формулировок не заменяет проверку прав и области действия ответа.

Кэш префикса

Если длинная начальная часть запроса неизменна — системные инструкции, описание инструментов, правила проекта или справочный материал, — её можно повторно использовать через prompt caching. Практический шаблон прост: постоянный блок в начале, переменные данные и вопрос — в конце. Условия совпадения, срок жизни и тариф зависят от API; изменение ранней части может сделать последующий префикс некэшируемым. Это экономит обработку входа, но не генерацию ответа.

Проверять нужно не ощущение «мы используем тот же сеанс», а реальные счётчики cached tokens, hit ratio, время жизни и стоимость записи/чтения. Документация OpenAI, Anthropic, Google и AWS описывает разные варианты этой механики.

Когда сжатие истории мешает кэшу

Pruning удаляет старые результаты, compaction заменяет накопленную историю компактным состоянием. Изменение раннего текста может нарушить совпадение префикса и увеличить стоимость следующих обращений. Однако, как отмечает документация OpenAI, меньший вход способен экономить деньги и при падении hit rate. Сравнивать нужно несколько следующих ходов вместе со стоимостью summary, новой записи кэша и восстановления забытых фактов, а не один размер окна. Отключать compaction ради кэша без другого управления контекстом не стоит.

При сжатии сохраняют цель, обязательные ограничения, принятые решения, открытые вопросы, уже выполненные действия и ссылки на доказательства. Активный цикл вызова инструмента нельзя разрывать. Контракт конкретного API важнее общего совета: OpenAI Compaction запрещает ручное прореживание истории при chaining через previous_response_id и обрезку непрозрачного результата /responses/compact. Это не эквивалент произвольного текстового пересказа.

Проверка должна различать холодный кэш (cold), прогретый (warm) и состояние после сжатия. Оплата записи, чтения, хранения и промахов зависит от API и поколения модели. Проверенная на дату обзора страница Gemini описывала Interactions API: её счётчики нельзя автоматически переносить на generateContent или Vertex AI.

Семантический кэш

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

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

Маршрутизировать задачи между моделями

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

1. Определить класс и риск →

Типовые низкорисковые задачи можно направить в каскад. Высокорисковые — сразу в усиленный контур.

2. Вызвать достаточную модель →

Извлечение, классификация или форматирование — по заранее проверенным правилам маршрутизации.

3. Проверить результат

Применить критерии качества. Решение о принятии не должно опираться только на цену вызова.

Проверка пройдена → принять результат.

Проверка не пройдена → эскалировать сильной модели; для предусмотренных рискованных случаев — человеку.

Высокий риск: сильная модель и предусмотренная проверка человеком без предварительной попытки дешёвой модели. Fallback после сбоя — отдельная механика доступности.

Как читать заявления об экономии

В эксперименте FrugalGPT 2023 года реализован каскад: на HEADLINES опубликовано 98,3% экономии относительно GPT-4 при сопоставимой accuracy; на OVERRULING и COQA эффект был меньше. «До 98%» является округлённым максимумом, не средним результатом и не сокращением токенов. Это исторические модели и цены; каскаду нужны размеченные примеры сходного распределения, а полная стоимость владения и задержка этим числом не доказаны. RouterBench полезен как напоминание сравнивать стратегии на одном наборе запросов, а не на удобных для каждой модели примерах.

Облачные поставщики предлагают управляемые варианты. AWS заявляет до 30% для Intelligent Prompt Routing, но продуктовая страница не раскрывает экспериментальный baseline. User guide указывает оптимизацию только для английских промптов и выбор ровно двух поддерживаемых моделей одного семейства. Это не запрет другого языка, но перенос эффекта на русский контур не установлен. Microsoft Foundry Model Router разделяет режимы Cost, Balanced и Quality; активная версия может обновляться без смены ID. Для воспроизводимости нужны дата, состав доступных моделей и их версии, а не только имя роутера.

С чего безопаснее начать

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

Перенести фоновые задачи в Batch

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

В документации OpenAI Batch API, проверенной 04.10.2026, указана скидка 50% относительно синхронных API для поддерживаемых моделей и endpoints. 24 часа являются окном завершения, а не гарантией выполнения всего пакета. Возможен статус expired: незавершённые запросы отменяются, готовые результаты выдаются и оплачиваются. Их сопоставляют по custom_id, не по порядку строк; повторы тоже входят в стоимость. Это скидка тарифа, не 50% полной стоимости процесса.

У Gemini и AWS Bedrock собственные пакетные режимы и ограничения, включая применимость к многошаговому обмену и инструментам. AWS отдельно указывает, что prompt caching не поддерживается с batch inference API. Скидки разных механизмов нельзя автоматически перемножать.

Перед переводом в Batch зафиксировать SLA ожидания, порядок повторной обработки ошибок, идемпотентность и правила публикации результата. Интерактивные запросы, аварийные решения и операции с жёстким временем ответа в этот контур не относятся.

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

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

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

LiteLLM Proxy показывает учёт по ключам, пользователям, командам, клиентам, моделям и тегам, но возможности зависят от конфигурации и редакции. Для описанного постоянного хранения расходов нужна база данных; у Custom Tags и custom metadata указаны Virtual Keys и база. Generate Spend Reports и custom spend-log metadata отмечены как Enterprise, доступность tag-функций нужно сверять с лицензией и версией. Это не требования ко всякому SDK-вызову. Langfuse различает переданные usage/cost и расчётные значения; переданные имеют приоритет. Оба инструмента помогают измерять, но не обеспечивают экономию автоматически: нужны актуальные тарифы и сверка со счётом поставщика.

Шлюз добавляет собственные риски. Перед выбором проверить место обработки данных, хранение журналов и кэша, ролевой доступ, tenant isolation, экспорт трассировок, комиссии и перечень поддерживаемых моделей. Материалы OpenRouter и Kong полезны как примеры таких функций, но не заменяют проверку конкретного договора и контура данных.

Учёт без двойного счёта и экономика решения

Разделяйте две оси: что передано (инструкции, схемы, результаты инструментов, история) и как оплачено (обычный вход, чтение/запись кэша, выход). Кэшированный системный текст принадлежит обеим осям, их итоги не складываются. В проверенной схеме OpenAI Responses полный input уже включает cache read/write: обычный вход равен input − read − write. В Bedrock Converse обычный inputTokens, напротив, исключает эти категории. Если reasoning входит в output, добавлять его стоимость поверх полного output нельзя. Неизвестный счётчик или тариф не равен нулю; скрытое рассуждение нельзя восстановить по видимому ответу.

Один физический запрос учитывают один раз по provider/account/request ID, даже если о нём сообщили SDK и шлюз. Новый retry остаётся новым расходом при том же тексте. Итоговый накопительный счётчик streaming нельзя складывать с уже включёнными частями. У родительского агента нужно различать собственную стоимость и сумму всего поддерева: итог parent, уже включающий workers, не прибавляют к стоимости этих workers ещё раз. Реальные вызовы координатора и интеграции при этом не теряются.

Для неизменного префикса длиной L при n обращениях сравните n × L × u без кэша и L × w + (n − 1) × L × r + S с кэшем. Здесь u, w, r обозначают цену токена обычного входа, полной записи и чтения, S обозначает хранение и обслуживание. Это упрощённая модель: первое обращение записывает префикс, остальные попадают в кэш, выход одинаков. TTL, промахи и изменения префикса требуют пересчёта. Аналогично сжатие выгодно, только если снижение последующих расходов перекрывает вычисление, проверку сжатия и дополнительные повторы, а качество проходит приёмку.

Оценить локальный инференс и квантизацию

Локальное, или self-hosted, размещение может быть экономически оправдано при устойчиво высокой загрузке, требованиях к приватности и локальности данных, необходимости низкой задержки или наличии уже доступных GPU. Но самостоятельное размещение не гарантирует экономию: его нужно сравнивать с API при фактической загрузке и целевом уровне сервиса.

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

Квантизация снижает точность представления весов и может уменьшить требуемую память. Документация vLLM описывает разные форматы и аппаратную совместимость; экономический эффект зависит от пропускной способности, оборудования и качества на целевой нагрузке. Меньшая память сама по себе не доказывает меньший счёт: нужно измерить скорость генерации, throughput, качество, длину контекста и устойчивость под нагрузкой.

У страницы vLLM latest на дату проверки стоит пометка developer preview. Она не заменяет спецификацию установленного stable release: для воспроизводимой оценки фиксируют release или commit, GPU, backend/kernel и конкретный checkpoint модели.

Провести корпоративный пилот

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

Сравнение на одинаковых задачах и независимая проверка

Предлагаемая методика начинается с критериев приёмки, допустимого ухудшения качества, критических ошибок и предельной задержки, согласованных до опыта. Зафиксируйте модель/API, промпты, корпус, инструменты, тарифы, retry/cache/compaction policy. Набор для настройки отделите от отложенного проверочного набора (holdout) по независимым группам задач или документов, чтобы близкие дубликаты не попали в обе части. Вариант замораживают до раскрытия holdout; исправление по его результатам требует нового независимого подтверждения.

В парном сравнении (paired comparison) baseline и новый вариант получают одну задачу и одинаковое исходное состояние, но работают в раздельных sandbox без реальных писем, платежей и записей. Порядок запусков чередуют случайно; повторы одной задачи не считают независимыми задачами. Записанный ответ инструмента допустим только при совпадении запроса и состояния: другая цепочка требует симулятора, а не «похожего» ответа. Такой replay не доказывает реальную сетевую задержку production.

Для контекста полезна матрица «исходный / сокращённый × cold / warm». Холодный кэш подтверждают счётчиками, не новым сеансом; в прогретом учитывают оплату прогрева и записи, TTL и интервалы. Одна ветка не должна случайно прогревать другую. Ненаблюдаемый режим отмечают как неизвестный; итоговые доли cold/warm берут из целевой нагрузки, а не выбирают ради лучшего результата. После отдельных опытов проверяют сочетания: их проценты не складываются.

Качество проверяют объективными тестами и слепой экспертной оценкой; модель-судью сначала калибруют по экспертам. Для неухудшения нижняя односторонняя доверительная граница разницы «вариант минус baseline» должна быть выше заранее принятого отрицательного допуска. Просто статистически незначимая разница не доказывает сохранение качества. Экономию оценивают с доверительным интервалом, сохраняя парность, группы повторов и неуспешные ветки. Критическая ошибка блокирует допуск независимо от среднего балла; отсутствие найденных ошибок не доказывает нулевой риск.

При сопоставимом качестве сравнивают стоимость принятого результата; при равном денежном бюджете сравнивают долю принятых задач. Это разные вопросы, и лучший результат в том же бюджете не следует называть денежной экономией. Порог времени до первого видимого токена (TTFT) задают как верхний предел, отдельно измеряют время до полезного вывода и до приёмки, включая очереди, инструменты, повторы и ручную работу. Новые модели, шлюзы, retrieval-цепочки и состав агентов требуют отдельного согласования данных и полномочий.

Метрики приёмки

Вывод

Для больших контекстов самый устойчивый путь — не одна «магическая» платформа, а связка независимых механизмов:

1. считать полную стоимость принятого результата;
2. передавать модели только нужные и проверяемые фрагменты;
3. ограничивать агентные результаты, передачи и циклы, сохраняя обязательные проверки и полный учёт всех исполнителей;
4. кэшировать стабильный префикс и повторные ответы только с учётом прав, свежести и арендатора;
5. маршрутизировать типовые задачи и эскалировать трудные;
6. переносить допустимую фоновую работу в пакетный режим;
7. сравнивать self-hosted и API по полной стоимости владения, а квантизацию — по стоимости, пропускной способности и качеству;
8. вводить каждое изменение через качество, безопасность и контрольную группу.

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