Пакетная обработка LLM-задач ночью без лишней нагрузки

Где онлайн-контур начинает тормозить

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

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

Первые признаки довольно типичны:

• растет p95 или p99 на простых запросах;
• очередь фоновых задач не успевает опустеть к вечеру;
• таймауты и ретраи появляются там, где раньше все проходило спокойно;
• дневной пик ломает SLA для сценариев, где ответ нужен сразу.

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

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

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

Какие задачи переносить на ночь

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

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

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

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

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

То же самое касается переобработки архива после обновления промпта или модели. Старые записи часто нужно прогнать заново, чтобы сравнить качество, выровнять метки или обновить summaries. Это тяжелая, но спокойная работа. Ей не стоит спорить за ресурсы с чатом, саппортом и поиском днем.

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

Если у вас уже есть единый OpenAI-совместимый слой, ночные джобы удобно вести через него же. Например, в RU LLM для этого можно использовать те же SDK и клиентский код, а логи, биллинг и хранение данных остаются внутри РФ. Для команд с требованиями по 152-ФЗ это часто важнее, чем сама экономия ночного окна.

Что должно остаться в реальном времени

В онлайне нужно держать все, что влияет на действие прямо сейчас. Если человек ждет ответ в чате, заполняет форму или разговаривает с оператором, задержка даже в 20-30 секунд уже заметна. Час ожидания тут просто ломает сценарий.

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

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

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

Есть простой тест. Если результат потеряет смысл через час, оставляйте задачу в онлайне. Если сотрудник может спокойно получить итог утром и ничего не сломается, это кандидат на batch.

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

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

Как собрать ночной конвейер

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

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

Что хранить в задании

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

• идентификатор исходной записи;
• тип задачи, например summary или classification;
• версия промпта и модель;
• статус, число попыток и текст ошибки;
• срок готовности и приоритет.

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

Как запускать и возвращать результат

Ночной запуск должен идти в фиксированное окно и с явным лимитом. Например, с 23:00 до 06:00 воркер берет не больше 50 тысяч задач, держит потолок по расходам и не забирает всю пропускную способность у дневных сервисов. Если очередь растет, вы увидите это утром, а не в разгар рабочего дня.

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

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

Как настроить очереди и приоритеты

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

Самый практичный вариант - дать каждому типу задач свой лимит. Например, классификация обращений может брать 20 параллельных воркеров, суммаризация звонков - 8, а разметка больших документов - 2. Тогда тяжелый поток не съест весь ночной слот и не остановит более короткие задания.

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

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

Приоритеты тоже лучше задавать жестко. Обычно хватает трех уровней:

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

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

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

Если вы уже гоняете задания через OpenAI-совместимый слой вроде RU LLM, сами правила не меняются. Меняется только дисциплина запуска: отдельные очереди, понятные лимиты и повторный запуск без дублей. Именно это и делает ночь рабочим окном, а не временной заплаткой.

Как измерить эффект

Смысл переноса виден не по ощущениям, а по нескольким цифрам. Первая - дневная p95 задержка. Сравнивайте ее по одному и тому же окну, например с 10:00 до 18:00, и по одним и тем же типам запросов. Если до переноса p95 по онлайн-ответам держалась на уровне 4,2 секунды, а после стала 2,6, разгрузка уже дала результат.

Вторая метрика - сколько токенов ушло из рабочего окна. Считать только число задач мало. Одна ночная суммаризация на 20 тысяч токенов снимает больше нагрузки, чем десять коротких классификаций. Поэтому удобнее смотреть долю токенов, которые раньше проходили днем, а теперь уходят после 22:00.

Что проверять каждое утро

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

Для ежедневного контроля обычно хватает пяти чисел:

• p95 задержки днем до и после переноса;
• объем токенов, вынесенный из дневного окна;
• процент ночных задач, не закрытых к утру;
• цена одной записи или одного документа;
• доля ошибок модели отдельно от ошибок очереди.

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

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

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

Пример для потока обращений

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

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

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

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

Ошибки, которые ломают batch-режим

Самая частая ошибка проста: в ночь уводят задачу, ответ по которой нужен человеку сразу. Если оператор колл-центра ждет подсказку во время разговора, batch только мешает. Если менеджеру нужен итог по всем диалогам за день к 8 утра, ночь подходит отлично. Граница проходит не по типу задачи, а по сроку ответа.

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

Минимальное разделение обычно выглядит так:

• realtime - то, что влияет на экран, звонок или диалог прямо сейчас;
• high priority batch - то, что нужно к началу рабочего дня;
• low priority batch - суммаризация архивов, переоценка старых данных, массовая разметка;
• retry queue - только для неудачных заданий.

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

Часто batch ломают и ретраи. Несколько задач упали из-за таймаута, а система перезапускает весь пакет на 200 тысяч записей. Это бьет по бюджету и растягивает окно обработки. Намного проще помечать статус каждой записи отдельно: queued, processing, done, failed. Тогда вы добиваете только хвост, а не повторяете весь прогон.

Есть и скучная, но дорогая ошибка: ночной конвейер не учитывает окна выгрузки из CRM, DWH и брокеров очередей. В 01:00 batch стартует, а данные из CRM доезжают только к 02:30. В итоге часть набора пустая, часть дублится, часть приезжает позже и выпадает из отчета. Ночной процесс должен жить по календарю источников, а не по красивому cron.

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

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

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

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

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

В-третьих, результат должен автоматически возвращаться туда, где им пользуются днем. Если оператор или аналитик потом вручную переносит метки в CRM, таблицу или хранилище, вы просто меняете одно узкое место на другое.

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

И наконец, команда должна знать, что делать в 06:30, если пакет не успел. Нужен простой план: кто получает сигнал, кто решает, запускать ли повтор, можно ли временно уменьшить объем, перейти на более быструю модель или оставить вчерашнюю разметку для части потока. Без этого утро начинается с ручного разбора.

Если вы используете единый OpenAI-совместимый шлюз, пилот обычно можно собрать без переписывания клиентского кода. В RU LLM это особенно удобно для команд, которым нужно держать данные, логи и бэкапы внутри РФ и при этом не менять привычный SDK. Для первого запуска достаточно одного потока и трех ночей наблюдения: этого хватает, чтобы увидеть, успевают ли результаты появляться к нужному часу.

С чего начать на этой неделе

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

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

Минимальный план на 5 дней

• Выберите один поток с понятным объемом. Хороший кандидат - обращения за день, которым нужна метка темы и короткое резюме.
• Возьмите историю за последнюю неделю и прогоните ее как ночную очередь в тесте. Сравните дневную нагрузку до и после: число запросов, задержку, таймауты, расход токенов.
• Сразу отделите лимит для ночных задач от дневного. Иначе batch начнет съедать бюджет утром, когда очередь еще не успела остыть.
• Если ваш стек совместим с OpenAI API, вынесите ночной поток на отдельный маршрут или отдельный контур, не меняя клиентскую логику.
• Если у вас есть требования по 152-ФЗ, проверьте не только модель, но и весь след данных: где лежат логи, бэкапы и аудит ночных запусков.

Этого достаточно, чтобы за неделю увидеть эффект без большой переделки. Команды часто ошибаются в одном месте: смотрят только на среднюю задержку и не считают хвост очереди к утру. Если ночью накопилось 200 тысяч задач, а к 9:00 осталось 40 тысяч, перенос сделан плохо, даже если средняя задержка чуть улучшилась.

Полезно заранее задать порог успеха. Например: днем стало на 25% меньше LLM-вызовов, средняя задержка в онлайн-контуре упала на 300-500 мс, а ночной бюджет не вышел за заданный лимит. Такие цифры легко проверить и спокойно обсудить с командой.

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