Как снизить расходы на токены без потери качества

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

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

Сначала разложите счет по составляющим

Общая сумма за месяц не показывает, откуда берутся расходы. Для каждого вызова записывайте:

• входные токены отдельно: обычные, прочитанные из кеша и записанные в кеш;
• выходные токены;
• модель и режим обслуживания;
• тип задачи — классификация, ответ клиенту, резюме документа;
• вызовы на задачу, включая повторы;
• результат: выполнено, передано дальше или завершилось ошибкой.

Некоторые API показывают кешированные токены отдельно от общего объема входа, а на новых моделях можно отдельно увидеть и токены, записанные в кеш. Храните эти поля, а не только итоговое количество токенов.

После недели-двух учета часто становится заметно, что основная часть затрат приходится на один тип задач с длинным контекстом, повторы из-за нестабильного формата или слишком подробные ответы. Начинайте с самой крупной статьи.

Для каждой корректировки считайте стоимость задачи, принятой с нужным качеством: все расходы на вызовы за период, деленные на число успешно выполненных задач. Если отдельный вызов стал дешевле, а успешная задача — дороже, оптимизация не помогла.

Уберите лишний контекст

Не отправляйте модели информацию, которая ей не нужна. Частые источники лишних токенов:

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

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

Пример: вместо истории на 3 000 токенов передавать проверенное резюме на 800. Каждый вызов получает на 2 200 токенов меньше. При ставке $2 за миллион входных токенов экономия равна $0,0044 на вызов, или $440 на 100 000 вызовов в месяц. При ставке $0,10 экономия составит лишь $22. Возможно, инженерное время выгоднее направить на другую статью расходов. Приоритет определяется вашим счетом, а не списком модных оптимизаций.

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

Настройте кеширование

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

Для некоторых новых моделей условия, проверенные 11.10.2026, таковы: кеширование включено по умолчанию; для совпадения должен сохраняться весь отрендеренный префикс, а повторное использование ищет самое длинное совпадение. Для моделей начиная с GPT-5.6 минимальная длина кешируемого запроса — 1 024 видимых входных токена. Префикс остается доступным 30 минут после последней записи или использования. Чтение для этих моделей стоит 0,1 обычной ставки входа, для GPT-6.1 Sol — 0,05. Запись стоит 1,25 обычной ставки. У других моделей условия могут отличаться, поэтому проверяйте конкретную модель.

Практические правила:

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

Учебный расчет: разделяйте чтение и запись кеша

Пример: Standard, короткий контекст, 11.10.2026; gpt-6.1-sol — $2 за миллион обычных входных, $0,10 за чтение кеша, $2,50 за запись, $10 за миллион выходных. Запрос содержит 6 000 входных токенов, из них 4 000 — стабильный префикс, и 800 выходных.

Предположим, что каждый промах кеша создает новую запись. При 90% попаданий средняя стоимость равна 0,9 × $0,0124 + 0,1 × $0,022 = $0,01336 — примерно на треть меньше исходной. При 50% попаданий стоимость $0,0172, экономия лишь 14%. Если запросы приходят реже раза в 30 минут и каждый раз требуется новая запись, вызов стоит $0,022 — на 10% дороже варианта без кеша.

В отчете держите отдельные показатели прочитанных из кеша и всех входных токенов, а при платной записи — и записанных токенов. Стабильный текст в начале сам по себе не доказывает, что кеширован весь запрос.

Выберите задачи для пакетной обработки

Пакетный режим асинхронный: вы отправляете файл с запросами и получаете результаты позже. В условиях одного пакетного API, проверенных 11.10.2026, указаны скидка 50% относительно синхронного режима, окно выполнения до 24 часов, до 50 000 запросов и файл размером до 200 МБ. У такого режима отдельные лимиты. Проверяйте текущие условия выбранного API; эти параметры не универсальны.

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

Разметьте типы задач в журнале как «ответ нужен сейчас» или «можно подождать». Вторая группа — кандидаты для пакетной обработки.

Добавьте маршрутизацию между моделями

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

Учебная схема поддержки:

1. Короткий запрос известной категории обрабатывает более доступная модель.
2. Правила проверяют, разрешена ли категория для автоматического ответа, заполнены ли обязательные поля и нет ли признаков жалобы или юридического вопроса.
3. Если правило не выполнено, запрос передается более сильной модели.
4. Если данных все еще недостаточно, запрос получает сотрудник.

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

Учебный расчет маршрутизации

При тех же размерах (6 000 входных и 800 выходных токенов) один вызов gpt-6.1-sol стоит $0,02, а gpt-6-luna — $0,001. Для 1 000 обращений:

• все через сильную модель: 1 000 × $0,02 = $20;
• сначала дешевая модель, затем эскалация 20% запросов: $1 + 200 × $0,02 = $5;
• эскалация 60%: $1 + 600 × $0,02 = $13.

При эскалации оплачиваются оба вызова. По модельному счету маршрутизация теряет преимущество, когда $1 + доля эскалаций × $20 = $20, то есть при 95% эскалаций.

Но добавьте условное предположение: 1% ошибок дешевой модели проходит проверку незамеченным, а исправление каждой стоит бизнесу $2 рабочего времени. При 20% эскалаций дешевая модель отвечает на 800 запросов; восемь ошибок стоят $16. Итого $5 + $16 = $21 — дороже, чем направить все запросы сильной модели. Это вымышленный расчет, но он показывает, что цена незамеченной ошибки может перевесить экономию на токенах.

Проверьте, что экономия не ухудшила качество

Каждую оптимизацию проверяйте на неизменном наборе задач с эталонными результатами до и после изменения. Если менять набор вместе с системой, сравнение теряет смысл.

Следите одновременно за пятью показателями: долей отказов; долей ошибок по эталонам или правилам; задержкой, особенно при нескольких вызовах; стоимостью успешно выполненной задачи; долей передач человеку.

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

Вносите изменения по одному. Если одновременно сократить контекст, изменить промпт для кеша и добавить маршрутизатор, а качество упадет, будет непонятно, что именно повлияло.

Итог и первые шаги

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

1. Записывайте входные, кешированные, записанные и выходные токены, тип задачи и результат каждого вызова.
2. Найдите крупнейшую статью затрат и начните с нее.
3. Сохраните неизменный тестовый набор с эталонами.
4. Поместите стабильный текст в начало запроса, переменный — в конец и измерьте кешированные токены.
5. Перенесите в пакетный режим только задачи, которые могут ждать.
6. Для маршрутизации считайте обе оплаты при эскалации и возможный ущерб от незамеченных ошибок.
7. Меняйте по одному параметру и сравнивайте отказы, ошибки, задержку и стоимость принятой задачи.

Специалисты BotLabs могут обсудить ваши типы задач, текущие расходы и то, как измерить результат оптимизации на пилоте. Вывод зависит от ваших данных и критериев качества.

Часто задаваемые вопросы