Коротко
Счёт за LLM почти никогда не растёт от числа запросов — он растёт от объёма контекста в каждом из них. Отсюда и все работающие приёмы: они уменьшают не количество обращений, а то, сколько токенов уезжает в каждом.
Три приёма дают больше, чем все остальные вместе:
- Модель под задачу. Разница между сильной и лёгкой моделью — до шести раз. На массовой обработке это сотни долларов.
- Короткий системный промпт. Он уходит в каждый запрос, поэтому лишняя тысяча токенов умножается на объём.
- Обрезанная история. В длинных диалогах вы платите за всю переписку заново на каждом шаге.
Ниже — все десять, с расчётами и с оговорками там, где приём работает не всегда.
1. Взять модель под задачу, а не самую сильную
Самый крупный рычаг, и его чаще всего игнорируют.
Возьмём реальную задачу: классифицировать 100 000 обращений в поддержку. На каждое — 500 входных токенов и 50 выходных.
| Модель | Цена задачи | Итого |
|---|---|---|
| Claude Haiku 4.5 | $0.00059 | $58.60 |
| Claude Opus 4.8 | $0.00338 | $337.50 |
Разница — $279 на одной работе. При этом на «определи категорию из списка» сильная модель не даст заметно лучшего результата: задача не требует рассуждений, она требует аккуратности.
Правило: чем формальнее задача, тем легче модель. Классификация, извлечение полей, нормализация, перевод коротких строк — лёгкая. Архитектурное решение, разбор запутанного бага, длинный текст — сильная.
2. Сократить системный промпт
Системный промпт уходит в каждый запрос. Это кажется мелочью, пока не умножишь.
Промпт на 1 000 токенов × 100 000 запросов = 100M входных токенов. На GPT-5.6 это $212 — только за инструкцию, которую вы написали один раз.
Сократили вдвое — сэкономили $106. И это обычно возможно: в системных промптах много вежливости, повторов и объяснений очевидного.
Оговорка: резать до потери смысла нельзя. Плохо сформулированная инструкция даёт ответы, которые придётся переделывать, и переделка стоит дороже сэкономленных токенов.
3. Обрезать историю диалога
В чат-сценарии каждый следующий запрос везёт с собой всю переписку. Двадцатое сообщение в диалоге стоит в разы дороже первого, хотя выглядит так же.
Что работает:
- Скользящее окно — последние N сообщений плюс системный промпт.
- Сжатие старого — раз в N шагов заменить начало диалога кратким резюме.
- Сброс контекста между задачами. Если пользователь перешёл к другому вопросу, старая переписка не помогает, а только стоит денег.
4. Ограничить max_tokens
Выходные токены дороже входных в 5–6 раз почти у всех моделей. Модель, которой не сказали «короче», охотно пишет три абзаца там, где хватило бы строки.
У нас запрос без явного max_tokens ограничивается значением 4096. Это защита от сценария, где забытый параметр съедает баланс за ночь. Но 4096 — это потолок, а не цель: если вам нужен ответ в одно предложение, ставьте max_tokens по задаче.
5. Выключить рассуждение там, где оно не нужно
У рассуждающих моделей часть выходных токенов уходит на внутренние размышления. Вы их не видите, но оплачиваете по цене выходных — самых дорогих.
На задачах, где думать нечего — классификация, форматирование, извлечение, — рассуждение просто дорожает ответ. У нас оно выведено отдельным переключателем; выключите его там, где выигрыша от него нет.
6. Объединять однотипные запросы
Если вы обрабатываете элементы по одному, системный промпт оплачивается столько раз, сколько элементов.
Передайте десять элементов одним запросом — и инструкция оплатится один раз вместо десяти. На больших объёмах это самый дешёвый способ срезать входные токены без потери качества.
Оговорка: пачка не должна быть слишком большой. Модель начинает терять аккуратность на длинных списках, а один неверный элемент в ответе заставляет переделывать всю пачку. На практике 5–20 элементов — рабочий диапазон, точное число подбирается замером.
7. Просить структуру, а не рассказ
«Верни JSON с полями category и confidence» стоит дешевле, чем «объясни свой ход мысли и в конце дай JSON». Второй вариант вы всё равно распарсите и объяснение выбросите — но заплатите за него по цене выходных токенов.
Побочная выгода: структурированный ответ не надо чинить регулярками.
8. Следить за изображениями
Картинки превращаются в токены, и их количество зависит от разрешения. Фотография с телефона в оригинале может стоить как несколько страниц текста.
Уменьшайте перед отправкой до того размера, на котором задача ещё решается. Для «что изображено» хватает небольшой стороны; полное разрешение нужно, только если надо прочитать мелкий текст на картинке.
9. Отменять то, что уже не нужно
В интерфейсах со стримингом пользователь часто уходит, не дочитав. Если запрос не отменён, модель продолжает генерировать — и вы платите за текст, которого никто не увидел.
Отмена по уходу пользователя — редко реализованная и почти бесплатная экономия.
10. Найти свои дорогие вызовы
Все приёмы выше — общие. Ваша экономия конкретна, и она видна в логах.
Откройте расход по вызовам, отсортируйте по стоимости и посмотрите на верхние строки. Почти всегда обнаруживается одно из трёх:
- один сценарий, который тратит больше всех остальных вместе;
- запросы с контекстом, который туда попал случайно;
- ретраи, которые никто не считал.
Одна такая проверка обычно даёт больше, чем неделя микрооптимизаций. У нас это журнал вызовов с суммой по каждому запросу.
Чего мы пока не умеем
Честно, потому что это заметный приём, и вы могли о нём слышать.
Кэширования промптов у нас сейчас нет. У вендоров есть механика, при которой неизменная часть запроса — большой системный промпт, документ, кодовая база — оплачивается по сниженной ставке при повторных обращениях. Через наш шлюз она не проходит: параметры кэширования мы не транслируем.
Практический вывод: если ваш сценарий — это один огромный неизменный контекст и много коротких вопросов к нему, прямой доступ к вендору будет дешевле. Если контекст каждый раз разный — разницы нет.
Что ещё стоит сделать, хотя это не про экономию
Поставьте лимит расхода на ключ. Это не снижает счёт, но ограничивает ущерб, когда ключ утекает или скрипт зацикливается. Лимит на день и на месяц ставится в кабинете, отдельно на каждый ключ.
Разделите ключи по сценариям. Тогда в логах видно, какой продукт сколько тратит, и разговор об оптимизации становится предметным.
Цены всех моделей — на витрине. В агентской работе с кодом основные деньги тоже уходят во входные токены: агент читает намного больше, чем пишет.
FAQ
От чего сильнее всего зависит счёт за LLM?
От объёма контекста в каждом запросе, а не от их количества. Системный промпт, история диалога и приложенные файлы уезжают на сервер заново при каждом обращении, поэтому длинный диалог дорожает с каждым шагом, даже если сами вопросы короткие.
Насколько дешевле лёгкая модель?
На массовых формальных задачах — в разы. Классификация 100 000 обращений обойдётся примерно в $58 на Claude Haiku 4.5 против $337 на Claude Opus 4.8. На задачах, требующих рассуждения, экономия обманчива: переделка неверного результата стоит дороже разницы в цене.
Стоит ли объединять запросы в пачки?
Да, если элементы однотипные: системный промпт тогда оплачивается один раз вместо десяти. Но пачка не должна быть большой — на длинных списках модель теряет аккуратность, а ошибка в одном элементе заставляет переделывать всю пачку. Рабочий диапазон обычно 5–20 элементов.
Почему выходные токены дороже входных?
Их генерация требует заметно больше вычислений, чем чтение входных, и это отражено в цене — разница обычно в 5–6 раз. Поэтому ограничение длины ответа и отказ от лишних объяснений в выводе экономят больше, чем сокращение вопроса.
Работает ли кэширование промптов через ваш шлюз?
Сейчас нет: параметры кэширования мы не транслируем. Если ваш сценарий — один большой неизменный контекст и много коротких вопросов к нему, прямой доступ к вендору выйдет дешевле. При каждый раз разном контексте разницы не будет.
Как понять, на чём именно я переплачиваю?
Посмотреть журнал вызовов, отсортированный по стоимости. Обычно обнаруживается один сценарий, который тратит больше всех остальных вместе, случайно попавший в запросы лишний контекст или неучтённые повторы. Это даёт больше, чем неделя мелких оптимизаций.