Первый счёт от OpenAI я увидел и не сразу понял, что произошло. Написал небольшой инструмент для обработки документов, запустил на реальных данных — и за три дня потратил больше, чем планировал за месяц. Начал разбираться. Оказалось, проблема была не в том, что API дорогой, а в том, что я пользовался им как попало.
Вот что я с тех пор поменял.
Системный промпт — не место для романов
Первая и самая дорогая ошибка — огромные системные промпты. У меня был один на 1200 токенов: подробное описание задачи, куча примеров, объяснение контекста. И это всё отправлялось с каждым запросом.
Дело в том, что токены считаются за каждый вызов. Системный промпт на 1200 токенов при 500 запросах в день — это уже 600 000 токенов только на инструкцию. До пользовательского сообщения ещё не дошли.
Я сократил его до 200 токенов, убрав всё, что модель и так знает. Примеры перенёс в отдельный механизм — few-shot только там, где без них реально хуже результат. Разница в счёте оказалась ощутимой.
Хорошая проверка: если убрать предложение из промпта и качество ответа не меняется — оно там лишнее.
Выбор модели — не всегда GPT-4
Я долго по умолчанию использовал GPT-4 везде. Логика была простая: лучшая модель — лучший результат. Но это примерно как ехать за хлебом на такси бизнес-класса.
GPT-4o mini стоит в разы дешевле, и для большинства задач — классификация, извлечение данных, простые преобразования текста — справляется не хуже. Я переписал пайплайн так, чтобы дешёвая модель делала первый проход: отсеивала нерелевантные документы, классифицировала запросы, делала предварительную обработку. GPT-4o подключался только там, где нужна реальная сложность — анализ, синтез, работа с неоднозначным контекстом.
Итог: примерно 70% запросов ушло на дешёвую модель. Стоимость упала сильно, качество финального результата — почти не изменилось.
Кэширование — то, о чём не думаешь до первого счёта
Если одни и те же запросы повторяются — а в большинстве продуктов они повторяются — платить за них дважды просто обидно.
OpenAI сделал prompt caching: если начало промпта совпадает с предыдущим запросом (от 1024 токенов), повторная обработка стоит дешевле. Но это работает автоматически только при определённых условиях, и рассчитывать только на это не стоит.
Я добавил свой слой: хэш от запроса — ключ, ответ модели — значение, TTL в зависимости от типа данных. Для статичных запросов — справочная информация, шаблонные преобразования — кэш живёт сутки. Для динамических не кэширую вообще.
На одном из проектов это срезало количество реальных обращений к API примерно на 40%. Не потому что запросы были одинаковые — просто в типичном пользовательском поведении повторяемость выше, чем кажется.
Стриминг и max_tokens — мелочи, которые не мелочи
Два параметра, которые я настраивал в последнюю очередь, а стоило в первую.
С max_tokens всё просто: по умолчанию модель может генерировать длинный ответ, даже если задача этого не требует. Если нужна классификация из трёх вариантов — зачем разрешать 2000 токенов на ответ? Я выставляю лимит под конкретную задачу: для коротких ответов — 100-200, для развёрнутых — то, что реально нужно, без запаса.
Стриминг — отдельная история. Он не снижает стоимость напрямую, но помогает поймать ситуации, когда модель "разошлась" и генерирует лишнее. Можно прерывать генерацию, если нужный фрагмент уже получен. На длинных документах это иногда даёт реальную экономию.
Батчинг — когда задачи можно объединить
Это работает не всегда, но когда работает — эффект заметный.
Есть 50 коротких документов для классификации. Можно отправить 50 отдельных запросов. А можно — один запрос с инструкцией "вот список, классифицируй каждый пункт". Системный промпт и вводная часть платятся один раз. Токены на ответ тоже часто меньше в сумме, потому что модель не повторяет вводные конструкции в каждом ответе.
Минус: ошибка в одном документе может испортить весь батч, и логика обработки ответа усложняется. Я использую батчинг там, где задача однородная и где могу легко распарсить структурированный ответ. Для разнородных — не стоит.
Кстати, у OpenAI есть Batch API — асинхронная обработка с 50% скидкой. Если результат нужен не прямо сейчас, а в течение нескольких часов, это честный способ платить вдвое меньше за ту же работу. Я перевёл на него все офлайн-задачи: ночная обработка отчётов, массовая аннотация данных.
Мониторинг — без него всё остальное вслепую
Последнее, что я добавил, и без чего сейчас не запускаю ничего в продакшн.
Логировать нужно не только ошибки, но и токены: сколько входящих, сколько исходящих, какая модель, какой тип задачи. Иначе непонятно, где стоимость растёт и почему.
У меня простая табличка: тип запроса — средний размер — частота — стоимость за день. Когда что-то меняется неожиданно, я вижу это сразу, а не в конце месяца.
OpenAI показывает статистику в дашборде, но с задержкой и без разбивки по типам задач. Свой мониторинг — единственный способ понять, что именно съедает бюджет.
Всё это не rocket science, и большую часть я мог сделать с самого начала. Но почему-то первый инстинкт всегда — взять самую сильную модель, написать подробный промпт и не думать об остальном. Работает, но дорого.
Сейчас я трачу примерно в четыре раза меньше при том же объёме задач. Не потому что нашёл какой-то хак — просто перестал игнорировать то, что было очевидно с самого начала.
