Сразу к выводу: рост расходов на API больших моделей в восьми случаях из десяти вызван не атакой, а несколькими незаметными привычками в коде, которые тихо сжигают деньги. В одном проекте интеллектуальной службы поддержки месячный счёт вырос с 8000 до 30 000, и первая реакция руководителя была — «нас обчистили». Я два дня участвовал в разборе и обнаружил, что количество запросов вовсе не изменилось — изменилось число Token, переносимых в каждом раунде диалога. Ниже разберу эти четыре ловушки по порядку, и для каждой дам готовое к внедрению решение.
1. История диалога полностью пересылается каждый раунд, входные Token растут линейно
Это самая скрытая ловушка. Многие команды, реализуя многораундовый диалог, по привычке вставляют полную историю сообщений в массив messages каждого запроса. В первом раунде отправляется 100 Token, в десятом — уже 1000 Token, а в тридцатом, возможно, три-четыре тысячи. Чем дольше общается пользователь, тем дороже каждый вызов, к тому же большая часть этой истории — пустые фразы вроде «хорошо» и «принято».
Оптимизация — это обрезка окна диалога плюс сжатие через резюме. Сохраняйте оригинальный текст последних N раундов, а более ранние сжимайте в один абзац резюме через дешёвый вызов модели, после чего вставляйте резюме в system prompt. В нашем проекте по факту замеров переход от полного окна к схеме «последние 6 раундов + резюме» снизил входные Token на 60–70%, при этом качество ответов в сценарии поддержки почти не изменилось. Ещё не забывайте дедуплицировать историю сообщений — повторяющиеся приветствия просто выбрасывайте.
2. Флагманская модель используется для черновой работы, даже классификация интентов идёт на топовой конфигурации
Ещё одна крупная статья расходов — использование GPT-4o или Claude 4 Sonnet для задач классификации интентов, определения эмоций, извлечения ключевых слов. Эти задачи логически просты, вывод короткий, и применять для них флагманскую модель — всё равно что стрелять из пушки по воробьям. Мы тогда посчитали: за одним запросом в поддержку в среднем стоит 3 вызова классификации, и все выполняются на флагманской модели.
Решение — многоуровневая маршрутизация моделей. Черновую работу отдавайте дешёвым моделям вроде DeepSeek-V3, облегчённой версии Qwen или API большой модели Doubao, и только на финальной генерации ответа задействуйте флагманскую модель. Именно этим и должен заниматься шлюз моделей: автоматически выбирать модель по типу задачи. В нашем проекте мы сравнивали прямую покупку у вендоров и платформу агрегации AI API — SiCore TokenWorks (token8341) с оплатой по факту использования, оптовыми закупками и снижением затрат за счёт зелёной энергетики даёт лучшую стоимость при той же комбинации вызовов, а один Key позволяет обращаться к GPT-4o, Claude, DeepSeek, Qwen, Doubao и другим популярным моделям, избавляя от возни с интеграцией пяти SDK. Ключевое слово здесь — структура затрат API больших моделей: дорого или нет зависит от того, какую работу вы кому поручаете.
3. Таймаут потокового ответа и повторные попытки без идемпотентного контроля
Эта ловушка проявляется не напрямую в числе Token, а в количестве вызовов. Если потоковый интерфейс обрывается по таймауту на клиенте, многие реализации кода бездумно повторяют запрос, но сервер на самом деле уже сгенерировал часть контента, и Token всё равно списываются. Три повторные попытки — тройная стоимость, хотя пользователь, возможно, увидел лишь один ответ. Хуже того, фронтенд-поллинг вместе с бэкенд-ретраями может отправить один и тот же запрос пять-шесть раз.
Есть два практических действия. Первое — снабжать каждый запрос идемпотентным Key, чтобы сервер при обнаружении дублирующего запроса сразу возвращал кэшированный результат без повторного инференса. Второе — заменить стратегию ретраев с «фиксированно 3 попытки» на «экспоненциальная задержка + максимум 1 попытка», причём повторять только при неудаче установления соединения, а если первый Token уже получен — ни в коем случае не переотправлять. После добавления этих двух пунктов аномальное число вызовов в нашем проекте упало почти вдвое.
4. Тестирование и продакшен используют общий Key, расходы смешиваются и не поддаются разбору
Самое мучительное при разборе — на самом деле вот это. Тестовая среда гоняет нагрузочные тесты и регрессию, используя тот же API Key, что и продакшен, и по счёту совершенно невозможно понять, какой расход создан реальными пользователями. К моменту обнаружения аномалии прошло уже несколько недель, и логи не сходятся.
Решение прямое: разделяйте API Key по средам и бизнес-линиям, и смотрите расход по каждому Key отдельно. Платформы агрегации AI API, как правило, поддерживают управление несколькими Key и панели расхода — если управление API Key настроено тщательно, сразу видно, кто жжёт деньги. Заодно поставьте тестовому Key дневной лимит, и ситуация, когда скрипт нагрузочного теста по ошибке подключается к продакшен-Key, будет исключена в корне.
Резюме в одну фразу
Потеря контроля над счётом за API больших моделей — обычно не вопрос цены за единицу, а вопрос манеры вызовов. Обрежьте окно диалога, понизьте уровень для черновой работы, обуздайте ретраи, разделите Key — после выполнения этих четырёх дел вернуть затраты в разумный диапазон совсем не сложно. Если хотите дальше разобраться, как устроены унифицированное подключение множества моделей и расчёт оплаты по факту использования, поищите материалы в направлениях «агрегация AI API» и «маршрутизация моделей».