Разработчики бэкенда и AI-приложений, вероятно, все переживали такой момент: в конце месяца открываешь облачный счёт и обнаруживаешь, что расходы на API больших моделей втрое превышают бюджет. Это не атака, не взрывной рост бизнеса — просто та самая линейка диалоговых сервисов тихо сжигает деньги. В этой статье разберём с инженерной точки зрения, куда именно утекают деньги и как перекрыть эти утечки техническими средствами.
Ловушка первая: безудержное разрастание контекстного окна
Наиболее часто игнорируемый источник затрат в многоходовых диалогах — это полная передача истории сообщений. Предположим, сценарий службы поддержки: в среднем 800 токенов контекста на ход, и к двадцатому ходу пользователя вход одного запроса приближается к 16000 токенов. При цене ввода GPT-4o $2.5/1M токенов стоимость ввода одного запроса составляет около $0.04, а при 50 тысячах вызовов в день это уже $2000. Что действительно убивает — так это то, что 70% из этих 16000 токенов могут быть нерелевантной болтовнёй трёхходовой давности.
Подход к оптимизации — скользящее окно плюс сжатие через суммаризацию. Сохраняем последние N ходов в оригинале, более ранние диалоги сжимаем лёгкой моделью в резюме до 200 токенов. В нашем проекте после перехода с «полного объёма» на «последние 6 ходов + резюме» входные токены одного запроса снизились с 12000 до примерно 3500, а стоимость ввода упала сразу на семьдесят процентов. Учтите, что само резюмирование тоже должно идти через дешёвую модель — делать суммаризацию флагманской моделью означает не сэкономить ничего.
Ловушка вторая: флагманская модель на черновой работе
Это самая распространённая и самая обидная трата. Классификация намерений, определение тональности, суммаризация контента, преобразование форматов — все эти задачи DeepSeek-V3 или Qwen-Max выполняют с точностью выше 95%, но многие команды ради удобства гонят всё через Claude 4 Sonnet или GPT-4o. Насколько велика разница в цене? Цена ввода флагманской модели зачастую в 10–20 раз выше, чем у лёгкой.
Ядро многоуровневого вызова моделей — это маршрутизация. Задача приходит, автоматически определяется её сложность, классификация идёт на лёгкую модель, и только сложные рассуждения — на флагманскую. SiCore TokenWorks поддерживает автоматический выбор оптимальной модели по задаче, и по нашему проекту после переключения задач классификации на лёгкую модель стоимость заметно снизилась. Ценность таких платформ агрегации AI API именно в том, что вам не нужно поддерживать отдельный SDK и Key для каждой модели — один OpenAI-совместимый интерфейс позволяет переключаться. Ниже минимальный пример изменения:
from openai import OpenAI
client = OpenAI(
api_key="your-token8341-key",
base_url="https://api.token8341.com/v1" # меняем одну строку, совместимо с OpenAI SDK
)
# лёгкая задача идёт на дешёвую модель
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role": "user", "content": "Определи тональность этого отзыва: доставка быстрая, но упаковка повреждена"}],
max_tokens=16
)
print(resp.choices[0].message.content)Стратегию маршрутизации можно начать с правил: помечаем тип задачи, классификация/суммаризация/извлечение идут на лёгкую, генерация кода/сложные рассуждения — на флагманскую. Через некоторое время статистика фактического попадания по каждой модели покажет, что подкрутить, — не стоит сразу браться за сложную семантическую маршрутизацию, затраты на поддержку превысят сэкономленные деньги.
Ловушка третья: вышедший из-под контроля механизм повторов
Повтор по таймауту — это невидимый усилитель. Многие SDK по умолчанию повторяют 2–3 раза, и если порог таймаута выставлен слишком коротким (например, 10 секунд), а фактическая P99 задержка составляет 25 секунд, то масса запросов уйдёт на повтор после таймаута, и один вызов превратится в три. Хуже того, сами повторные запросы тоже занимают конкурентность, что может вызвать ограничение по скорости, а ограничение снова вызовет повторы — и получится лавина.
Мы один раз наступили на эти грабли: у некоего интерфейса P99 задержка 28 секунд, таймаут выставлен 15 секунд, повтор 3 раза — фактический объём вызовов составил 2.4 от бизнес-объёма. Потом мы выставили порог таймаута на 30% выше P99, повторы переделали на экспоненциальную задержку с максимум 1 разом — объём вызовов вернулся к 1.1. Кроме того, повторы нужно различать по типу ошибки: повторяем только 429 и 5xx, а повторять 400-ю ошибку параметров десять тысяч раз бессмысленно.
Ловушка четвёртая: отсутствие агрегации расхода и оповещений
Это самая глубинная проблема. Многие команды ведут грубый учёт по проектам или по Key, но не знают, какая именно функция, какой пользователь, какой Prompt жжёт деньги. И только когда приходит счёт, обнаруживается, что Key какого-то тестового окружения не выключили или что сверхдлинная сессия какого-то пользователя съела весь бюджет.
Подход — тегирование по измерениям: каждый вызов несёт три тега — team, feature, user_id — и уходит в логи или в базу временных рядов. Преимущество AI API-шлюза как единой точки входа именно здесь: все вызовы проходят через один слой прокси, теги и агрегация расхода выполняются на стороне шлюза, не нужно править код каждой бизнес-команды. Пороги оповещения рекомендуется ставить в два уровня: при достижении 60% бюджета суточного расхода — предупреждение, при 85% — включение деградации (например, автоматическое переключение некритичных функций на лёгкую модель).
Сравнение затрат и ориентир для выбора
После внедрения всех четырёх пунктов мы сравнили три способа подключения: прямое подключение к официальному API одной модели, собственный роутер, платформа агрегации. Прямое подключение — проще всего, но не позволяет делать многоуровневость моделей, затраты жёсткие; собственный роутер гибок, но требует поддержки множества Key, множества SDK, множества логик биллинга — от двух человеко-месяцев; платформа агрегации имеет готовые возможности по переключению моделей и агрегации расхода, оплата по факту, стоимость выгоднее. При выборе смотрите на три вещи: совместимость с OpenAI SDK (стоимость миграции), поддержку полного покрытия отечественных моделей (комплаенс и стоимость).
Оптимизация затрат — это не разовое действие, а процесс постоянного наблюдения и корректировки. Сначала наладьте агрегацию расхода, чтобы ясно видеть, куда уходят деньги, затем по пунктам оптимизируйте контекст, многоуровневость моделей, стратегию повторов. Не меняйте порядок, иначе вы полдня что-то оптимизируете, а оптимизируете, возможно, совсем не главную статью.
Автор: Чэнь Цзинсин
Дата публикации: 3 октября 2026 г.