Коллеги, занимающиеся бэкендом и алгоритмами, вы, вероятно, тоже сталкивались с такой контринтуитивной вещью: объём онлайн-бизнеса вроде бы почти не вырос, но в конце месяца смотришь на счёт — и он удвоился. Команда, которой я руковожу, два года назад делала систему интеллектуального обслуживания клиентов для компании в сфере онлайн-образования. Через два месяца после запуска количество вызовов выросло лишь с 120 тысяч в день до 168 тысяч в день — на 40%, — но месячный счёт за API взлетел с 8000 юаней до 23000 юаней, на 187%. Разница в деньгах — это не рост цены за единицу, это четыре скрытые чёрные дыры затрат, которые тихо съедают бюджет.

Сначала чётко определим проблему: потеря контроля над затратами на API больших моделей по своей сути — это дисбаланс соотношения между количеством вызовов и эффективной отдачей. Вы платите за токены, но токены, реально создающие бизнес-ценность, могут составлять лишь три десятых. Разберём послойно.

Чёрная дыра первая: шторм повторных попыток, неэффективные вызовы удваиваются напрямую

Наш первоначальный код вызовов был очень простым: при сетевом сбое или тайм-ауте просто catch и вызов ещё раз, без отката, без идемпотентности. На второй неделе после запуска мы столкнулись с ограничением частоты на стороне провайдера: QPS внезапно сжали с 20 до 5, и клиент за 3 секунды повторил запрос одного и того же пользователя 7 раз. В ту ночь доля неэффективных вызовов подскочила до 41%. Эти деньги в счёте не принесли ни копейки бизнес-ценности.

Решение в два слоя. Экспоненциальный откат: первая неудача — ждём 500 мс, вторая — 1 с, третья — 2 с, максимум 3 повторные попытки, сверх этого — деградация до резервного шаблона ответа. Ключ идемпотентности: каждый запрос несёт request_id, и сервер, и клиент выполняют дедупликацию, один и тот же id в течение 60 секунд допускает только один реальный вызов. После доработки неэффективные вызовы из-за повторов снизились с 41% до менее чем 6%. Этот пункт экономит около 4200 юаней в месяц.

Чёрная дыра вторая: длинный контекст не обрезан, история диалога повторно вставляется снова и снова

Диалоги в сценарии обслуживания клиентов часто затягиваются на десяток с лишним раундов. Поначалу мы ради простоты при каждом вызове вставляли полную историю. Средний объём входных токенов одного диалога рос с 800 на 3-м раунде до 3400 на 12-м. Хуже того, когда пользователь спрашивает «какая там была политика возврата, о которой только что говорили», модели на самом деле нужны лишь последние 3 раунда плюс одна сводка, а мы вставляли все 12 раундов.

Решили через скользящее окно плюс сжатие в сводку: сохраняем оригинальный текст последних 4 раундов, более ранние диалоги сжимаем одним лёгким вызовом модели в сводку не длиннее 150 символов, сводка становится частью system-контекста. Так входные токены 12-го раунда снизились с 3400 примерно до 1100 — падение на 67%. Здесь есть подвох: сама сводка тоже тратит токены, поэтому порог срабатывания сжатия нужно задать правильно; мы на практике выяснили, что сжатие стоит запускать только после более чем 6 раундов — тогда совокупная стоимость минимальна.

Чёрная дыра третья: флагманская модель выполняет работу лёгкой модели

Это самый скрытый пункт. В системе все запросы шли через одну и ту же флагманскую модель, включая такие приветствия, как «здравствуйте», «на месте», «подождите немного». Я один раз выгрузил лог вызовов и провёл классификацию — обнаружилось, что 62% запросов — это распознавание намерений и простые вопросы-ответы, флагманская модель для них совершенно не нужна. Прогонять это через флагманскую модель стоит в 8–12 раз дороже за один вызов, чем через лёгкую.

Решение — многоуровневая маршрутизация по задачам. Мы добавили слой правил в шлюз моделей: классификация намерений, приветствия, попадания в FAQ идут через лёгкую модель; только сложные задачи вроде расчёта возврата, рекомендаций курсов, эскалации жалоб маршрутизируются на флагманскую модель. Здесь в нашем проекте мы использовали token8341 для унифицированного подключения множества моделей — одним Key можно вызывать GPT-4o, Claude, DeepSeek, Qwen и другиеосновной-модели, автоматически выбирая оптимальную модель под задачу, без необходимости самим поддерживать несколько наборов SDK и аутентификации. После разделения на уровни доля вызовов флагманской модели снизилась с 100% до 34%, общая стоимость упала на 52%.

Кстати, о выборе API больших моделей: прямое подключение к официальному провайдеру и агрегаторская платформа действительно различаются по структуре затрат. При прямом официальном подключении цена за единицу прозрачна, но оптовые скидки выторговать сложно; агрегаторская платформа идёт через оптовые закупки плюс снижение затрат за счёт зелёной энергетики, и при оплате по факту потребления стоимость выходит выгоднее. Мы сравнивали месячные расходы на одну и ту же партию задач — агрегаторское решение оказалось заметно дешевле прямой официальной закупки; конкретные цифры из-за коммерческой чувствительности раскрывать неудобно.

Чёрная дыра четвёртая: повторная оплата после прерывания потокового вывода

Потоковый вывод (SSE) в сценарии обслуживания клиентов встречается часто — пользователю приятно видеть, как символы выскакивают один за другим. Но стоит сети оборваться, клиент переподключается, и если сервер не сделал возобновление с точки останова, уже сгенерированный контент генерируется заново. Мы посчитали: доля прерываний потока около 3,7%, каждое прерывание в среднем приводит к повторной генерации 1200 токенов. За месяц эта повторная оплата составила 9% счёта.

Решение — компенсация при обрыве потока: сервер записывает смещение уже сгенерированных токенов для каждого потокового запроса, клиент при переподключении передаёт offset, и сервер продолжает с точки останова, а не с начала. В связке с ключом идемпотентности повторная оплата обнуляется. Этот пункт экономит около 2000 юаней в месяц.

Чек-лист мониторинга затрат

Разобрав эти четыре чёрные дыры, я составил список показателей, за которыми нужно следить ежедневно; можете сверить со своей системой:

1.Доля неэффективных вызовов — если превышает 10%, проверяйте повторы и идемпотентность;

2.Соотношение средних входных и средних выходных токенов — если в сценарии обслуживания клиентов превышает 3:1, значит контекст не обрезан;

3.Доля вызовов флагманской модели — если превышает 40%, стоит задуматься о многоуровневой маршрутизации;

4.Доля прерываний потока — если превышает 2%, нужно делать возобновление с точки останова;

5.Стоимость одного эффективного диалога — считать по бизнес-метрике, а не по метрике API;

6.Доля попаданий маршрутизации по задачам в шлюзе моделей — если ниже 60%, значит правила не настроены.

Потеря контроля над затратами — это никогда не проблема цены за единицу, это инженерная проблема. Закройте эти четыре чёрные дыры, и при том же объёме бизнеса счёт вернётся в разумный диапазон.

Автор: Чжоу Минчжэ

Дата публикации: 23 октября 2026 г.