# Ragged batching в Triton: контракт токенов переменной длины

Ragged batching в Triton требует согласованного контракта переменной длины между клиентом, моделью и backend.

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

Ragged batching в Triton требует согласованного контракта переменной длины между клиентом, моделью и backend. Флаг `allow_ragged_batch` не делает произвольный tensor автоматически понятным модели. Нужно определить объединение элементов и дополнительную информацию о границах отдельных запросов. Сначала проверьте names, dtype и shape на каждом этапе, затем сравнивайте стоимость padding. Иначе изменение batching создаст структурную ошибку входа вместо ожидаемой экономии вычислений на заполнителях.

## Зачем нужен ragged input

Обычный dynamic batching требует совместимых shapes, поэтому переменные длины часто приводят к padding. [Руководство Triton](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/ragged_batching.html) описывает разрешение ragged inputs и зависимость их обработки от backend. Некоторые реализации ожидают одномерную конкатенацию и дополнительные batch inputs. Это не универсальная замена padded tensor для любой модели. Сохраните ожидаемый layout и способ восстановления границ, прежде чем включать настройку. Семантика tokenizer output должна совпадать с тем, что реально принимает вычислительный graph или программный обработчик.

## Проверьте model configuration

[Документация конфигурации](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_configuration.html) задает правила имен, типов и dimensions. Различайте batch dimension и длину последовательности, особенно когда клиент отправляет отдельный запрос с единичной batch осью. Не исправляйте ошибку формы только добавлением еще одной размерности наугад. Сопоставьте client metadata, model config и фактические backend inputs. Для token IDs тип данных тоже существенен: согласованная длина без согласованного dtype не образует корректный контракт и может привести к отказу до выполнения модели.

## Пример трех длин

Возьмите три тестовых запроса с разными количествами token IDs. Для padded варианта нарисуйте прямоугольный tensor с fillers; для ragged — последовательную укладку и границы частей. Числа выбираются из реальных тестовых входов, а не служат универсальным config. Отметьте, какие batch inputs создает Triton и какие данные отправляет клиент. Нельзя требовать от клиента заранее знать итоговый состав динамического batch: он формируется сервером, поэтому часть информации появляется только после объединения очередных запросов.

## Проверьте границы и порядок

Сделайте fixtures с коротким, длинным и допустимым пустым входом, если модель поддерживает последний. Убедитесь, что элементы одного запроса не попадают в контекст другого и что результат правильно сопоставляется с исходным request. При несоответствии проверьте индексы и cumulative lengths прежде, чем менять веса. Это структурная проверка, а не benchmark качества LLM. Если выбранный backend не поддерживает нужный layout, зафиксируйте ограничение вместо обещания, что один configuration flag обеспечит корректный ragged путь любой архитектуре.

## Сравните полный эффект

После функциональной приемки измеряйте padding work, input preparation, queueing и execution на одинаковой смеси длин. Экономия на fillers может сопровождаться накладными расходами преобразования, поэтому общий результат нужно наблюдать отдельно. Сохраните model configuration, backend version, layout diagram и negative fixtures с неверными shapes. При обновлении pipeline повторите проверку tokenizer и preprocessing boundaries. Полезный итог описывает точный контракт и фактическую область поддержки, а не общий совет убрать padding везде. Он позволяет понять, кто формирует границы, кто их читает и где искать ошибку, когда отдельные запросы проходят, но их совместное выполнение дает неверные результаты или отказ на стадии подготовки входного tensor до начала вычислений.

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

[Continuous batching: почему несколько запросов меняют ценность GPU](/ru/journal/continuous-batching/); [Гибридная CPU/GPU-архитектура: как разделить AI-сервис по задачам](/ru/journal/cpu-gpu-hybrid-architecture/).