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

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

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

Две разные идеи под словом «батчинг»

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

Динамический или непрерывный батчинг — механизм сервера вывода. Он совмещает совместимые запросы при вычислении, чтобы повысить пропускную способность. Документация NVIDIA Triton говорит, что увеличение задержки формирования пакета может дать больший throughput ценой latency; параметры очереди и тайм-ауты настраиваются отдельно. Для генеративных моделей llama.cpp описывает непрерывный батчинг и число параллельных слотов. Исследование Orca объясняет, почему планирование по шагам генерации полезнее негибкого ожидания завершения целого набора запросов. Это инженерные возможности, но не обещание конкретной экономии на вашем оборудовании.

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

Архитектура для малого бизнеса

На входе разделите задачи по правилам, а не по догадке модели: срочные обращения — интерактивный контур, массовая подготовка — отложенная очередь. У каждого задания должны быть уникальный ID, источник, владелец, срок, версия шаблона и допустимый объём данных. Перед помещением в очередь удалите лишние персональные сведения; локальный сервер не отменяет внутренние правила доступа.

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

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

Как посчитать экономику честно

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

Модельный пример с явными допущениями: 6 000 однотипных заявок в 30-дневном месяце, то есть в среднем 200 в день. Пилот на ваших данных показал, что конкретная модель обрабатывает дневной пакет за два часа с проверками и запасом. Это 60 часов активной работы в месяц. Постоянно работающий узел доступен 720 часов за те же 30 дней. Если вычисления оплачиваются по часам и ресурс действительно можно выключить, сравните 60 × тариф с 720 × тарифом, добавив время запуска, хранение и поддержку. Разница в 660 оплачиваемых часов — только иллюстрация компонента инфраструктуры, не прогноз общей экономии.

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

Что измерить за неделю

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

Не переносите в пакет задачи только потому, что «ночью дешевле»: клиентское обещание и операционные последствия важнее загрузки GPU. Хороший первый шаг — обозначить две очереди и срок готовности для каждой, затем провести теневой пилот без автоматической отправки результатов. Если пакет укладывается в срок и снижает стоимость принятой задачи, расширяйте. Если нет, возможно, проблему решает обычная маршрутизация или шаблон, а не ещё один сервер. Робот-стажёр с радостью унесёт весь лоток писем разом; руководителю всё же стоит оставить красные срочные папки на столе.