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

В Triton и TensorRT-LLM сначала выясните, какой компонент собирает batch в выбранном пути запуска.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/triton-llmapi-batching-boundaries/
Language: ru

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

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

[Актуальный LLM guide](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/getting_started/llm.html) использует LLM API/PyTorch и показывает `triton_config` в `model.yaml`. В описанном примере `max_batch_size: 0` явно связан с обслуживанием без batching. Это свойство опубликованной конфигурации, а не универсальный запрет пакетной обработки в TensorRT-LLM. Сначала установите, используется ли именно этот путь, затем читайте соответствующие правила. Совпадение имени модели `tensorrt_llm` не доказывает, что два deployments имеют одинаковый backend, scheduler или схему входных tensors.

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

[Руководство Triton batchers](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/batcher.html) описывает 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](/ru/journal/continuous-batching/); [Планирование GPU-пула: когда действительно нужен следующий сервер](/ru/journal/inference-capacity-planning/).