Микробатчинг LLM-вызовов: как снизить цену без срыва SLA

Почему одиночные вызовы быстро дорожают

У каждого LLM-вызова есть не только цена за токены ответа. Почти всегда вы платите и за служебную часть: системный промпт, формат сообщений, проверку лимитов, логирование, сетевой проход, а иногда и маскирование PII. Если сама задача короткая, этот постоянный расход начинает занимать слишком большую долю в счете.

Представьте внутренний сервис, который ставит теги к заявкам. Один текст на 2-3 строки, один короткий ответ. Полезной работы мало, а обвязка вокруг запроса почти такая же, как у более длинной задачи. Когда таких мелких вызовов тысячи в день, бюджет уходит не на смысл, а на повтор одного и того же служебного слоя.

В рабочие часы проблема растет быстрее. В 10 утра сотрудники одновременно запускают суммаризацию писем, разбор встреч, классификацию документов и проверку карточек в CRM. Многие из этих задач не срочные, но система обрабатывает их как срочные, потому что они приходят по одной и сразу. Очередь распухает, растет конкуренция за rate limits, потом приходят 429, таймауты и новые попытки.

Для внутренних процессов это особенно обидно, потому что часть задач спокойно терпит задержку в 2-10 секунд. Пользователь не ждет ответ в чате. Он открывает отчет, переключается на другую вкладку или запускает пакетную проверку. Но приложение все равно шлет каждый запрос отдельно, как будто счет идет на сотые доли секунды.

Где деньги теряются незаметно

Чаще всего бюджет съедают не большие диалоги, а мелкие повторы. Один и тот же системный контекст уходит в каждом коротком вызове, каждая мелкая задача занимает отдельное место в очереди, один таймаут запускает повторную отправку того же промпта, а ретраи дублируют историю и служебные поля.

Поэтому одиночные вызовы быстро дорожают. Цена складывается не только из ответа модели, но и из формы, в которой вы отправляете работу. Когда запросы маленькие и частые, форма начинает стоить слишком много.

Где маленькие пачки дают эффект

Маленькие пачки лучше всего работают там, где человек не ждет ответ в ту же секунду. Если задача живет во внутренней очереди, а лишние 2-10 секунд ничего не ломают, микробатчинг часто дает заметный выигрыш в цене. Особенно это видно на коротких и похожих запросах.

Хороший пример - разбор отзывов, тикетов и внутренних обращений по мере поступления. Допустим, за 3 секунды в очередь поддержки прилетает 12 новых сообщений. Вместо 12 отдельных вызовов система собирает их в одну маленькую пачку, просит модель проставить тему, срочность и короткую сводку, а потом раскладывает ответы обратно по карточкам. Сотрудник открывает тикет уже после этого, поэтому лишняя задержка почти незаметна.

Массовые краткие сводки по письмам и документам тоже хорошо ложатся в такой режим. Утром отдел продаж или закупок получает десятки похожих писем: запрос цены, уточнение срока, вложенный договор, повторный контакт. Если промпт у всех один и ответ нужен короткий, модель обычно отрабатывает это ровно. Особенно помогает одинаковый формат результата, например 2-3 строки текста или фиксированный JSON.

Часто окупается и классификация заявок, лидов и обращений. Это рутинная работа с понятным набором меток: "новый лид", "повторный", "жалоба", "нужен звонок", "спам". Когда у задачи мало вариантов ответа и не нужен длинный текст, пачки снижают цену без заметного ущерба для внутренних SLA.

Еще один удачный случай - перепроверка ответа перед показом сотруднику. Например, первая модель уже подготовила черновик ответа клиенту, а вторая должна быстро проверить тон, наличие персональных данных или нарушение внутренних правил. Если эта проверка идет в фоне и укладывается в пару секунд, оператор просто видит более чистый черновик. Для банков, телекома и здравоохранения это часто полезнее, чем гнаться за самым быстрым одиночным вызовом.

Фоновое извлечение полей из форм тоже почти идеально подходит. Заявки на кредит, анкеты, страховые обращения и внутренние служебные формы обычно похожи по структуре. Нужно вытащить имя, ИИН, номер договора, дату и тип обращения. Работа однотипная, ответ короткий, а ошибки легко отправить на повторную обработку.

Обычно это задачи с похожими запросами, коротким формальным ответом, обработкой через очередь, а не через живой чат, и терпимостью к небольшой задержке. Маленькие пачки любят скучную, повторяемую работу. В этом их главная сила.

Когда лучше оставить одиночный режим

Микробатчинг помогает не везде. Если человек ждет ответ прямо сейчас, лишние 300-800 мс на сбор пачки часто стоят дороже, чем экономия на токенах. Для внутренних задач это особенно заметно там, где модель работает в живом интерфейсе.

Первый пример - чат оператора в реальном диалоге. Оператор пишет клиенту, смотрит на подсказку и сразу отвечает. Если система подождет еще несколько соседних запросов, диалог начнет "плыть": оператор делает паузу, клиент замечает задержку, темп падает. В такой точке лучше оставить одиночный режим и резать цену другими способами: сокращать контекст, выбирать более дешевую модель или кэшировать повторы.

То же относится к подсказкам во время звонка. Когда сотрудник колл-центра спрашивает модель: "как ответить на возражение" или "какой следующий вопрос задать", ответ нужен почти мгновенно. Даже маленькая очередь тут мешает. На звонке каждая секунда слышна, и недовольство команды появляется очень быстро.

Осторожно стоит относиться и к шагам, где ответ модели сразу запускает следующее действие. Например, модель проверяет текст заявки, после чего система либо открывает форму на доработку, либо отправляет ее дальше по процессу. Если добавить ожидание ради пачки, растянется вся цепочка. Чем больше зависимых шагов подряд, тем хуже тут работает пакетная логика.

Еще один плохой кандидат - редкие запросы с очень длинным контекстом. Их мало, поэтому собирать пачку просто не из чего. К тому же такой запрос сам по себе тяжелый: он занимает память, дольше считается и может тормозить соседние задачи, если смешать их в один батч.

Одиночный режим обычно лучше оставить там, где человек смотрит на экран или говорит с клиентом, следующий шаг стартует сразу после ответа модели, запросы приходят редко и не образуют стабильную очередь, или один запрос уже слишком дорог по времени из-за длинного контекста. Простое правило работает хорошо: если задержку замечает человек или от нее стопорится следующий шаг, этот участок лучше не трогать.

Как запустить микробатчинг

Микробатчинг лучше запускать не на всем трафике сразу, а на одном спокойном сценарии. Подойдут внутренние задачи, где лишняя секунда не ломает процесс: разбор обращений, теги для документов, короткие сводки, проверка карточек товаров. Если начать с чата для клиента, жалобы прилетят очень быстро.

Сначала разделите поток на две части. Срочные запросы отправляйте по одному, без очереди. Все, что терпит небольшую паузу, складывайте в отдельную очередь. Это простое правило снимает большую часть риска еще до первых тестов.

1. Задайте предел ожидания для очереди. Часто хватает 1-3 секунд. Если за это время пачка не собралась полностью, отправляйте то, что уже есть.
2. Начните с маленьких пачек по 4-8 запросов. Этого обычно достаточно, чтобы снизить цену и не растянуть ответ до неприятных значений.
3. Складывайте вместе похожие задачи. Лучше всего работает группировка по длине текста, типу промпта и ожидаемому размеру ответа. Если смешать короткие и очень длинные запросы, вся пачка начнет ждать самый тяжелый.
4. Держите отдельные правила для ошибок. Если один запрос в пачке падает по таймауту или лимиту, не блокируйте остальные. Повторяйте только неудачные элементы.
5. Сравнивайте не только среднюю цену. Смотрите на стоимость одного полезного ответа, p50, p95 и долю ошибок. Именно p95 обычно показывает, стало лучше или проблема просто уехала в хвост задержек.

Если у вас уже есть OpenAI-совместимый шлюз вроде AI Router на airouter.kz, такую схему удобно ставить перед выбором модели. Тогда вы сначала собираете подходящие пачки, а потом решаете, куда их отправить, не меняя основной код и SDK.

Нормальный старт выглядит скучно, и это хорошо: одна очередь, один тип задачи, батч 4, таймер 2 секунды и замер на несколько дней. Если p95 держится в норме, а цена на задачу падает, пробуйте батч 6 или 8. Если очередь растет к началу часа или после обеда, уменьшайте размер пачки, а не ждите, пока SLA начнет проседать.

Как не сорвать SLA

SLA обычно ломается не из-за самой пачки, а из-за того, что в нее кладут все подряд и ждут слишком долго. Если запросу нужно ответить за 2-3 секунды, ему не место в той же очереди, где спокойно живут задачи на 20-30 секунд.

Первое правило простое: срочные запросы держите отдельно. Поиск по базе знаний для сотрудника, подсказка оператору и проверка короткого текста на лету должны идти своим потоком. А суммаризацию писем, разметку архивов, извлечение полей из документов и ночные отчеты можно спокойно собирать в маленькие пачки.

Микробатчинг обычно работает без боли, если вы ставите два жестких лимита сразу: максимальный размер пачки и максимальное время ожидания. Например, до 8 запросов или до 150 мс, что наступит раньше. Тогда очередь не раздувается, а пользователи не чувствуют, что система "задумалась" ради экономии.

Отдельная ловушка - смешивать короткие и очень длинные промпты. Один тяжелый запрос тянет за собой всю пачку, и p95 растет быстрее, чем счет за API падает. Лучше разбить трафик хотя бы на два класса: легкие запросы и длинные. Это грубое правило, но оно часто спасает SLA лучше тонкой настройки.

Есть и второй источник срывов: ретраи и лимиты провайдера. Если провайдер вернул 429 или временную ошибку, пачка поедет на повтор, а время ответа сразу вырастет. Поэтому закладывайте запас не только на обычную задержку модели, но и на повторные попытки, паузы между ними и ограничения по RPM или TPM. Без этого расчеты на бумаге выглядят красиво, а в рабочее время очередь внезапно "цементируется".

Практический минимум такой: не смешивать срочные и фоновые задачи, ограничивать и размер пачки, и время ожидания, разделять короткие и длинные промпты, считать SLA с учетом ретраев и rate limits и выключать пачки, если p95 растет быстрее экономии. Если экономия 8%, а p95 вырос на 40%, для этого сценария пачки лучше отключить.

Что мерить до и после

Если смотреть только на цену токена, легко сделать ложный вывод. Для бизнеса важнее цена одной завершенной задачи: сколько стоит одна классификация обращения, одно краткое резюме письма или один ответ для сотрудника поддержки. Микробатчинг может снизить цену на бумаге, но если часть задач уходит в таймаут или требует повторной отправки, экономия быстро тает.

Считайте метрики на уровне задачи, а не только на уровне запроса к модели. Тогда видно, что дешевые токены иногда дают дорогой результат из-за задержек, пустых прогонов и ретраев.

Полезно держать перед глазами несколько чисел:

• цена одной успешно завершенной задачи
• среднее время до ответа и p95
• доля запросов, которые попали в полные или почти полные пачки
• процент ретраев, таймаутов и отмен
• разбивка по типам задач и по часам дня

Среднее время само по себе мало что говорит. Пользователь или внутренний сервис страдает не от среднего, а от длинного хвоста. Если среднее упало с 2,1 до 1,8 секунды, а p95 вырос с 4 до 11 секунд, режим стал хуже, даже если цена немного снизилась.

Отдельно смотрите на наполняемость пачек. Если вы настроили батч на 8 задач, а по факту чаще собираете 2 или 3, то платите ожиданием, но не получаете полной выгоды. В рабочие часы картина часто меняется: утром поток плотный, после обеда рваный, вечером пачки снова собираются быстрее.

Не смешивайте разные задачи в один отчет. Короткая модерация, извлечение полей из документа и генерация развернутого ответа ведут себя по-разному. Для одной группы микробатчинг полезен, для другой только растит задержку.

Если трафик идет через AI Router, аудит-логи и лимиты по ключам помогают быстро увидеть, где экономия реальна, а где ее съели таймауты, повторные вызовы или слишком маленький поток. Хороший ориентир простой: стоимость одной полезной задачи должна падать, а p95 - оставаться в пределах SLA.

Пример для внутренней очереди

У отдела качества редко есть смысл отправлять каждый диалог в LLM по одному. Если команда проверяет около 600 диалогов в день, а для каждого нужен короткий разбор по одному и тому же шаблону, одиночные вызовы просто повторяют одну и ту же инструкцию сотни раз.

Обычно людям не нужен ответ за секунду. Им нужен готовый итог в интерфейсе в течение 5 минут, чтобы проверить смену, отметить ошибки и передать спорные случаи руководителю. Это удобный режим для микробатчинга: окно ожидания есть, шаблон один, а результат короткий и предсказуемый.

Рабочая схема тут простая. Очередь собирает новые задания, воркер ждет либо 6 диалогов, либо 30-45 секунд, и отправляет их одной пачкой. В промпте общая инструкция пишется один раз, а дальше идут шесть диалогов с одинаковой структурой ответа.

Цена падает по двум причинам. Длинная служебная часть больше не дублируется в каждом запросе, и система делает меньше сетевых вызовов. На практике часто хватает нескольких простых правил: обычные проверки идут в общую очередь, размер пачки ограничен шестью диалогами, у пачки есть таймер, а модель возвращает ответ в одном и том же формате для каждого диалога.

При таком режиме команда обычно не жалуется на скорость. Если раньше один диалог уходил в обработку сразу, а теперь ждет до 45 секунд внутри очереди, пользователь этого часто даже не замечает. Его интересует итог в пределах SLA, а не момент старта запроса.

Срочные проверки лучше вынести отдельно. Жалоба клиента, разбор инцидента или запрос от руководителя не должны стоять в общей пачке вместе с рутиной. Для них делают вторую очередь без микробатчинга или с пачкой из одного запроса.

Этот пример хорош тем, что не требует сложной перестройки процесса. Вы не меняете сам шаблон оценки, не учите сотрудников новой логике и не обещаете мгновенный ответ. Вы просто даете системе 30-45 секунд на сбор маленькой пачки и получаете заметное снижение стоимости LLM без срыва срока в 5 минут.

Частые ошибки

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

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

Не меньше проблем дает настройка размера пачки "по максимуму". На стенде пачка из 32 запросов может выглядеть дешево. В рабочее время она часто набирается слишком долго. Для внутренних задач почти всегда нужны два ограничения сразу: сколько запросов можно собрать и сколько миллисекунд они могут ждать. Иначе система гонится за полной пачкой и теряет SLA.

Еще одна ловушка - смотреть только на среднюю задержку. Среднее число почти всегда успокаивает, но люди чувствуют p95, а не среднее. Если 80% запросов проходят быстро, а остальные висят 4-6 секунд, отчет выглядит нормальным, а сотрудники уже обходят систему вручную. Поэтому нужно смотреть не только на latency, но и на возраст очереди, размер пачек и долю просроченных запросов.

Часто забывают и про отдельный маршрут для срочных задач. Проверка подозрительной операции, подсказка оператору в чате или короткий ответ для службы поддержки не должны стоять в одной линии с ночной суммаризацией отчетов. У срочных запросов должен быть свой путь: одиночный режим или совсем маленькие пачки.

Последняя ошибка кажется мелкой, но бьет больно: команда переносит выводы с одного набора данных на все процессы. На тикетах поддержки микробатчинг может дать хороший результат, а на юридических документах или медкартах - совсем другой. Длина промптов, размер ответа и всплески нагрузки там другие. Поэтому каждый поток проверяют отдельно, а не по аналогии.

Проверка перед запуском

Микробатчинг не стоит включать по привычке. Он хорошо работает там, где задача может подождать 2-5 секунд и пользователь этого не замечает. Для внутренней разметки, суммаризации писем, генерации черновиков ответов и ночных проверок это часто нормально. Для чата с оператором в реальном времени - уже спорно.

Перед запуском полезно проверить четыре вещи. Задержка в несколько секунд не должна ломать процесс. Промпты должны быть похожи по форме и объему, иначе пачки быстро начинают вести себя неровно. Команда должна заранее назвать допустимый p95 без размытых формулировок вроде "быстро". И одиночный режим нужно уметь вернуть за минуту одним флагом или правилом маршрутизации.

Есть еще один практичный тест. Возьмите 100-200 реальных запросов за обычный рабочий час и посмотрите на разброс длины. Если часть промптов занимает 300 токенов, а часть 10 000, одна общая пачка быстро станет неудобной. В таком случае лучше сначала разделить поток по типам задач.

Хороший старт выглядит скучно, и это плюс. Одна внутренняя очередь, маленький размер пачки, жесткий лимит ожидания и простой откат. Например, команда батчит только суммаризацию обращений сотрудников с окном 1-2 секунды. Если p95 уходит выше согласованного порога или растут ошибки, трафик сразу возвращается в одиночный режим. Такой запуск дает честный ответ: есть ли снижение стоимости LLM без риска для SLA.

Что сделать на следующей неделе

Не начинайте с самого заметного сценария. Для первого пилота лучше взять один внутренний процесс с простым и понятным SLA: разбор тикетов, сводки по звонкам, черновики ответов для саппорта или классификацию документов. Если задача терпит задержку в 10-60 секунд и не влияет на клиента в реальном времени, она подходит лучше всего.

Хороший пилот не должен тянуться месяц. Пяти-десяти рабочих дней обычно хватает, чтобы увидеть разницу в цене, задержке и числе обработанных задач. За это время команда успевает понять, мешает ли ожидание людям или его никто не замечает, пока система собирает запросы небольшими пачками.

Сразу разделите трафик на два маршрута. Срочные вызовы отправляйте по одному, без ожидания в очереди. Фоновые задачи складывайте в короткую очередь и собирайте в маленькие пачки по размеру или по таймеру. Такой подход легко объяснить бизнесу: вы не трогаете то, что должно отвечать сразу, и экономите там, где люди все равно не сидят у экрана с секундомером.

План на следующую неделю может быть совсем простым. В первый день выберите один внутренний процесс и зафиксируйте для него SLA, текущую цену и среднее время ответа. На второй день заведите отдельные маршруты для срочных и фоновых запросов. На третий день включите микробатчинг только для фонового потока с очень скромными настройками. В следующие несколько дней смотрите на цену, задержку, ошибки и жалобы команды. В конце пилота сравните цифры с исходными и решите, где режим пачек стоит оставить.

Если выигрыш заметен, оставьте пачки в одном-двух внутренних потоках и не тащите их дальше раньше времени. Если выгода почти не видна, не усложняйте архитектуру без причины. Нормальный итог первого пилота выглядит приземленно: один поток перевели на пачки, срочные запросы оставили как есть, команда поняла границы метода. Этого для первой недели вполне достаточно.