Сначала вывод: рост счёта в восьми случаях из десяти вызван не ростом объёма. У меня был проект интеллектуальной службы поддержки: в первой половине прошлого года месячный счёт стабильно держался около 8000 юаней, а к четвёртому кварталу подскочил до 23000 юаней, при этом объём вызовов за тот же период вырос лишь на 40%. Куда ушли лишние деньги? Я выгрузил логи вызовов за три месяца и агрегировал их по четырём измерениям — тип задачи, длина входа, длина выхода, число повторных попыток — и картина стала ясна: четыре скрытые дыры в затратах одновременно обескровливали бюджет.

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

Дыра первая: флагманская модель выполняет черновую работу

Это самая дорогая статья. В той системе поддержки было три типа задач: классификация тикетов, разметка эмоций и распознавание намерений, примерно 120 тысяч вызовов в день. Тогда ради простоты всё шло через одну и ту же флагманскую модель. Но насколько сложны эти три типа задач? Дайте мне двухсотсимвольное сообщение пользователя и определите, это «запрос по логистике» или «возврат после продажи» — такую работу небольшая модель делает даже стабильнее большой, потому что пространство меток совсем невелико.

Я заново прогнал оценку по задачам: для задач классификации заменил модель на среднюю по размеру, точность упала с 96,2% до 95,7% — разница в 0,5 процентного пункта, а цена за единицу отличается на порядок. Только этот пункт способен срезать сорок процентов счёта.

Дыра вторая: полная повторная вставка истории контекста

Поддержка — это многораундовый диалог, в среднем 7,3 раунда. Разработчики ради простоты вставляли полную историю в каждый раунд. В первом раунде вход 800 токенов, к седьмому раунду вход становится 4200 токенов, и каждый раунд вы снова платите за предыдущие шесть. Эта кривая затрат квадратичная, и при росте объёма она взрывается.

Что ещё хуже, большая часть содержимого истории не имеет никакой ценности для текущего раунда. Пользователь в третьем раунде сказал «я хочу вернуть товар», а в седьмом спрашивает «кто оплачивает доставку» — вся та болтовня и описание товара в начале — чистые мусорные токены.

Дыра третья: усиление при неудачных повторных попытках

Эта самая скрытая. При ограничении скорости на стороне вышестоящего сервиса или тайм-ауте SDK по умолчанию повторяет попытку три раза. Проблема в том, что запросы при повторных попытках часто заново отправляют тот же длинный контекст целиком. Я подсчитал: около 11% токенов в счёте приходят от неудачных повторных попыток, и при этом шесть из десяти таких вызовов в итоге всё равно завершаются неудачей — чистое сжигание денег. Если при повторных попытках не настроены откат и идемпотентный контроль, один сбой может раздуть вам тройной объём недействительного расхода.

Дыра четвёртая: необрезанный потоковый вывод

Выходные токены обычно дороже входных. Тогда в ответах поддержки не был задан max_tokens, и модель иногда «разгулялась»: вместо разъяснения о возврате в два предложения она писала целый пронумерованный пошаговый регламент. В распределении длины вывода P99 более чем в шесть раз превышает P50. Эти лишние слова пользователь вообще не читает, а деньги платятся.

Пять действий по остановке кровотечения

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

Второе — скользящее окно контекста плюс суммаризация. Сохраняем дословно последние три раунда, более ранние диалоги сжимаем в резюме не длиннее ста символов. На практике средняя длина входа упала с 3200 токенов до 1400, связность контекста поддержки не пострадала.

Третье — идемпотентные повторные попытки. Каждому запросу присваивается уникальный ID, шлюз распознаёт повторные запросы и сразу переиспользует результат, при повторной попытке отправляется только неудавшийся фрагмент, а не весь контекст. Этот пункт снизил недействительные токены от повторных попыток с 11% до менее чем 3%.

Четвёртое — ограничение длины вывода. По типу задачи задаём верхний предел max_tokens; для фиксированных сценариев вроде разъяснения о возврате сразу даём шаблон, и модель только подставляет переменные. Выходные токены сократились примерно на треть.

Пятое — выбирать модель по задаче, а не по привычке. Звучит как банальность, но многие команды просто ленятся: одна модель на всё. Позже мы на платформе агрегации API больших моделей token8341 провели сравнительные тесты отечественных и зарубежных моделей в рамках одного набора интерфейсов: на одном и том же корпусе поддержки DeepSeek и Qwen показали вполне достаточный результат в сценариях работы с китайским языком, а цена больше подходит для массовых нагрузок. Преимущество единого подключения множества моделей именно в этом: для смены модели не нужно менять SDK, достаточно изменить одну строку base_url.

Предпосылка оплаты по факту использования — правильная маршрутизация

Фраза «оплата по факту использования — затраты оптимальнее» сама по себе верна, но у неё есть предпосылка: ваша стратегия маршрутизации должна быть правильной. Оплата по факту использования лишь гарантирует, что вы не платите за простаивающие мощности, но не гарантирует, что вы не платите за ошибочный выбор модели. Счёт вернулся с 23000 юаней к чуть более 9000, при этом объём вырос — и добились мы этого не сменой на дешёвую платформу, а тем, что правильно сделали две вещи: маршрутизацию и контекст.

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

Автор: Ли Юньлун

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