«Сожгли двести баксов за выходные», — написал мне знакомый в понедельник. Два дня разработки фичи, а бюджет API ушёл как на настоящий продакшен. Я копнул глубже и понял: проблема не в объёме запросов. Дело в том, как он их делал.
Оптимизация расходов на GPT API — это не про то, чтобы экономить на качестве. Это про то, чтобы не платить за то, за что можно не платить. Ниже — конкретные приёмы, проверенные на моих проектах, а не абстрактные советы из документации.
Сначала проверь, куда уходят токены
Перед любой оптимизацией — диагностика. OpenAI даёт разбивку по токенам в каждом ответе API. Но если у тебя десятки эндпоинтов, удобнее собирать метрики в одном месте.
Я веду простую статистику: входные токены, выходные, количество запросов, средний размер контекста. Через неделю стало видно, что в одном воркфлоу я гоняю один и тот же промпт с почти идентичным контекстом сорок раз в день. Сорок раз. Одинаковый запрос. Каждый раз — полная оплата.
Кэширование — очевидно, но делают не все
Самый простой способ срезать расходы — не повторять одни и те же запросы. Но кэш на уровне LLM-запросов хитрее обычного HTTP-кэша. Контекст чуть меняется, промпт тот же, а кэш не срабатывает.
Я кэширую по хэшу системного промпта плюс хэшу основного контекста. Совпало — беру ответ из памяти, не трогаю API. Выигрыш зависит от задачи: в моём случае вышло закрыть 15–20% запросов кэшем без потери качества.
Не кэшируй всё подряд. Для задач со свежим контекстом — новости, цены, расписание — короткий TTL. Для статичных данных — длинный.
Системный промпт — место экономии, о котором забывают
Системный промпт летит с каждым запросом. Десять тысяч запросов в день, промпт на 300 токенов — три миллиона входных токенов ежедневно, которые ты оплачиваешь как обычный контекст.
Я вынес из промпта всё статичное. Оставил только то, что меняется. Промпт сократился с 350 до 90 токенов. На моём объёме — экономия ~25% входных токенов. Деньги, которых просто не было смысла тратить.
Ещё один приём: справочные данные — в отдельный запрос, а потом передавать краткую выжимку. Не гонять 500 токенов документации с каждым вызовом, а один раз получить от модели нужные выводы и закешировать.
Выбирай модель под задачу, а не под репутацию
GPT-4o стоит дорого. GPT-4o-mini — дешевле в десять раз. И для большинства задач — классификация, рерайт, простая аналитика — разницы в качестве нет. Я проверял на своём потоке: из 15 эндпоинтов только три реально требовали топ-модель. Остальные двенадцать прекрасно работали на mini.
Переключение не просит переобучения. Поставь условие: простая задача — mini, остальное — основная модель. У меня на это ушло пара часов, а экономия вышла ощутимой.
Batch API — недооценённый инструмент
OpenAI давно позволяет слать до 1000 запросов в одном батче за вдвое меньшую стоимость. Но есть нюанс: батч обрабатывается асинхронно, до 24 часов. Не подходит для real-time, зато отлично работает для фоновых задач — обработки документов, массовой категоризации, генерации описаний.
Я собираю все некритичные запросы в очередь и отправляю батчем раз в час. Экономия 50% на этих операциях. Latency вырос, но для фона это не критично.
Выходные токены — тоже деньги
Входные токены принято считать главной статьёй расходов, но выходные тоже кусаются. Модель генерирует простыню текста, а тебе нужен один тег — ты переплачиваешь.
Я ограничиваю max_tokens жёстко. Для задачи «верни JSON с одним полем» ставлю 50 токенов — больше просто не нужно. Модель не может разогнаться и нагенерировать лишнего. Иногда полезно попросить короче: «ответь в 2–3 предложениях» вместо «опиши подробно».
Итого
Все приёмы складываются. Мой типичный результат после оптимизации: расходы падают на 40–60% без ухудшения качества. Первым делом — кэширование и модельный роутинг. Потом — сокращение промптов и ограничение вывода.
И последнее. Следи за цифрами постоянно. Настроил и забыл — через месяц обнаружишь, что профиль нагрузки изменился и старые настройки уже не оптимальны. Оптимизация — это не проект, это процесс.
