Triton и TensorRT-LLM: как понять, какой scheduler собирает batch

В Triton и TensorRT-LLM сначала выясните, какой компонент собирает batch в выбранном пути запуска. Общий Triton dynamic batching, настройки современного LLM API и старые inflight конфигурации нельзя считать взаимозаменяемыми. Наличие max_batch_size в файле не объясняет весь scheduler. Сохраните backend и model configuration, затем проверяйте фактическое объединение запросов и ожидание, не копируя параметры из соседнего примера без понимания их области действия.

Найдите конкретный deployment путь

Актуальный LLM guide использует LLM API/PyTorch и показывает triton_config в model.yaml. В описанном примере max_batch_size: 0 явно связан с обслуживанием без batching. Это свойство опубликованной конфигурации, а не универсальный запрет пакетной обработки в TensorRT-LLM. Сначала установите, используется ли именно этот путь, затем читайте соответствующие правила. Совпадение имени модели tensorrt_llm не доказывает, что два deployments имеют одинаковый backend, scheduler или схему входных tensors.

Разведите уровни scheduler

Руководство Triton batchers описывает dynamic batching для поддерживаемых stateless моделей и per-model настройки очереди. Внутренний executor LLM может иметь собственную логику scheduling. Поэтому нельзя просто добавить generic блок из примера другого backend и объявить включенным желаемый inflight режим. В карточке запуска укажите, кто принимает request, где формируется работа и какие ограничения относятся к каждой границе. Такой разбор нужен до выбора чисел batch size или queue delay.

Пример карты ответственности

Создайте таблицу с тремя строками: Triton frontend, model configuration и LLM execution. В столбцах укажите входную единицу, поддерживаемое объединение, параметры и источник наблюдения. Это схема инвентаризации, не утверждение о наличии всех уровней batching в любом deployment. Для legacy пути заведите отдельную карточку. Не переносите preferred_batch_size или старый scheduler policy между карточками автоматически: одинаковое название параметра или общая задача throughput не гарантируют одинаковую семантику и совместимость.

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

Подайте сохраненную серию одновременных запросов с известными длинами. Сопоставьте execution observations, queue time и response latency, доступные выбранному backend. Один клиентский parallelism не доказывает, что запросы объединились в batch: сервер может исполнять их иначе. Повторите серию с изолированным изменением поддерживаемого параметра. Если конфигурация остается без batching, не интерпретируйте отсутствие выигрыша как доказательство, что batching бесполезен вообще. Сначала подтвердите, что исследуемый механизм действительно был включен и обработал эти запросы.

Оформите границы вывода

В отчете сохраните точный repository layout, runtime version, config и команды запуска. Укажите, какие настройки относятся к Triton и какие к LLM API. Отдельно измеряйте стоимость ожидания пакета и вычислительный эффект; больший batch не обещает меньшую latency каждому запросу. При миграции legacy deployment перепроверьте карту ответственности вместо механического копирования старого config. Полезный итог позволяет оператору объяснить, где именно собирается работа и какие наблюдения это подтверждают. Он не сводит все варианты к одной универсальной формуле max batch size и не утверждает, что любой успешный многопоточный клиент автоматически получает continuous batching независимо от выбранного backend пути и его реальной конфигурации.

Связанные материалы

Continuous batching: почему несколько запросов меняют ценность GPU; Планирование GPU-пула: когда действительно нужен следующий сервер.