Срочность — это требование к мощности, а не к интерфейсу

Во многих проектах локального ИИ слово «онлайн» появляется автоматически. Письмо пришло — модель должна ответить сразу. Документ загрузили — поля нужны через секунду. База знаний обновилась — все embeddings следует пересчитать немедленно. На демонстрации это выглядит убедительно, но в смете превращается в постоянно готовый сервер, запас под пиковую нагрузку, круглосуточный мониторинг и дежурство.

Главный вопрос для руководителя звучит иначе: сколько бизнес теряет, если конкретный результат будет готов не сейчас, а через 10 минут, час или к началу следующего рабочего дня? Если измеримого ущерба нет, мгновенность — платная функция без подтверждённой ценности.

Пакетная обработка не означает «медленно и вручную». vLLM поддерживает offline inference для генерации, классификации, embeddings и reranking, а также асинхронную очередь. NVIDIA Triton умеет динамически объединять входящие запросы, задавать задержку формирования batch, приоритеты, лимит очереди и тайм-ауты. Это позволяет построить не два независимых контура, а один управляемый сервис с разными классами срочности.

Три класса SLA вместо одного «реального времени»

Полезно разделить задачи до выбора железа.

1. Интерактивные

Человек ждёт ответ в текущем окне и не может продолжить работу. Примеры: подсказка оператору, поиск по базе знаний, проверка короткой заявки перед отправкой клиенту. Здесь важны time to first token, end-to-end p95 и предсказуемый отказ при перегрузке.

2. Околореальные

Результат нужен в течение 5–60 минут, но никто не смотрит на индикатор загрузки. Это классификация входящих писем, краткие резюме звонков, подготовка карточек для CRM, проверка новых документов. Задача может подождать более крупную группу запросов и уступить приоритет интерактивной очереди.

3. Пакетные

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

Срочность следует назначать не всему продукту, а конкретной операции. В одной системе поиск по уже готовому индексу может быть интерактивным, новые документы — обрабатываться каждые 15 минут, а полная переиндексация — ночью.

Чем online batching отличается от ночного задания

Динамический batching держит сервис постоянно доступным, но на короткое время задерживает запрос, чтобы объединить его с соседними. Документация Triton рекомендует сначала измерить latency и throughput с настройками по умолчанию, затем увеличивать размер batch или задержку только пока система остаётся в бюджете latency. Там же предусмотрены очереди с приоритетами и тайм-аутами.

Offline batch работает с известным набором данных. Он может загрузить модель один раз, разбить массив на части, вести контрольные точки и записывать результаты по стабильным идентификаторам. Актуальная документация vLLM отдельно описывает offline API и интеграцию с Ray Data, где continuous batching используется для насыщения реплик, а sharding, балансировка и fault tolerance помогают длинным заданиям.

Это разные экономические инструменты:

  • online batching снижает цену интерактивного запроса, не отменяя плату за готовность сервиса;
  • offline batch убирает требование постоянной готовности для несрочной части потока;
  • гибрид оставляет небольшой срочный канал и переносит основную массу в окно дешёвой обработки.

Исследование Sarathi-Serve показывает саму природу компромисса: большие группы повышают serving capacity, но планировщик должен удерживать tail latency. Авторы получили прирост на конкретных моделях и GPU, однако эти числа нельзя переносить в бизнес-смету. Они подтверждают только необходимость измерять throughput и p95 вместе на собственном железе.

Архитектура общей очереди

Для малого бизнеса достаточно прозрачной схемы без тяжёлой платформы.

1. Приёмник создаёт задание со стабильным `job_id`, ссылкой на входные данные, классом SLA, дедлайном, версией модели и политикой доступа.
2. Маршрутизатор помещает его в одну из очередей: urgent, nearline или batch. Приоритет не должен храниться только в имени API-метода — он обязан быть видимым полем задания.
3. Один или несколько worker-процессов формируют batch с учётом дедлайна, длины входа и доступной памяти. Срочные задания могут обойти несрочные, но не должны бесконечно вытеснять их.
4. Результат записывается идемпотентно. Повторный запуск с тем же `job_id` обновляет статус или возвращает уже готовый результат, а не создаёт дубликат в CRM или ERP.
5. Ошибка попадает в ограниченную очередь повторов, затем — в dead-letter queue с краткой причиной. Бесконечный retry превращает экономию в скрытую нагрузку.
6. Критические поля проходят человеческое подтверждение. Метрика считается по принятому результату, а не по числу успешных HTTP-ответов модели.

Запускать пакет по расписанию можно простым системным планировщиком или Kubernetes CronJob. Документация Kubernetes предупреждает, что при некоторых условиях CronJob способен создать несколько одновременных Jobs. Поэтому нужны `concurrencyPolicy`, дедлайн старта и идемпотентная запись результата. Расписание само по себе не обеспечивает однократность выполнения.

Модельный расчёт: цена мгновенности

Ниже — не рыночный тариф и не универсальный benchmark. Это шаблон с явными допущениями.

Компания обрабатывает 3 600 несрочных текстовых заданий в день: классификация, краткое резюме и извлечение нескольких полей. На тестовом наборе одна и та же модель даёт одинаковую приемлемую точность в двух режимах.

Допущения:

  • latency-ориентированный режим обрабатывает 12 принятых результатов в минуту;
  • пакетный режим — 36 принятых результатов в минуту за счёт более плотной очереди;
  • интерактивный контур требует выделенной доступности 24×7;
  • batch запускается ежедневно и получает 20% резерва времени на повторы и колебания длины;
  • полная внутренняя стоимость GPU-часа, включая амортизацию, электричество и эксплуатацию, в модели равна 300 ₽.

Само вычисление в online-режиме заняло бы около 5 часов в день, но выделенный сервис резервирует 720 GPU-часов в месяц. Batch завершит дневной объём примерно за 100 минут; с резервом это около 60 GPU-часов в месяц.

Модельная инфраструктурная стоимость:

  • постоянно готовый выделенный контур: `720 × 300 = 216 000 ₽/мес.`;
  • ежедневный пакет на разделяемом GPU: `60 × 300 = 18 000 ₽/мес.`;
  • наценка за мгновенность: около `198 000 ₽/мес.`.

Эта разница исчезнет или уменьшится, если online-сервер полезно занят другими задачами, GPU уже оплачен и нет альтернативного применения мощности. Она увеличится, если для p95 нужен второй экземпляр, запас N+1 или ночное дежурство. Поэтому считать следует не покупную цену карты, а стоимость зарезервированной доли мощности.

Когда реальное время окупается

Срочный контур оправдан, когда ускорение меняет деньги или риск. Формула проста:

`ценность срочности = число действительно срочных событий × эффект ускорения одного события`.

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

Часто срочны только 1–5% событий. Тогда выгоднее:

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

Что включить в пилот

Пилот можно провести за две недели без покупки новой инфраструктуры.

  • Соберите почасовой профиль поступления задач и реальные дедлайны пользователей.
  • Разметьте каждую операцию как interactive, nearline или batch и назначьте цену просрочки.
  • На одном наборе и одной модели измерьте accepted results per minute, p50/p95, GPU-hours, долю повторов и время проверки человеком.
  • Проверьте три режима: запрос сразу, короткая динамическая задержка, фиксированное пакетное окно.
  • Введите лимит очереди, тайм-аут, idempotency key и контролируемый повтор до масштабирования.
  • Сравните стоимость принятого результата и стоимость зарезервированной доступности, а не только токены в секунду.

Что взять руководителю

Не покупайте «реальное время» для всей системы. Купите его только для операций, где задержка имеет измеримую цену. Остальные задачи объедините в nearline и batch, оставив общий журнал, единые модели и проверку качества.

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