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

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

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

Обычный dynamic batching требует совместимых shapes, поэтому переменные длины часто приводят к padding. Руководство Triton описывает разрешение ragged inputs и зависимость их обработки от backend. Некоторые реализации ожидают одномерную конкатенацию и дополнительные batch inputs. Это не универсальная замена padded tensor для любой модели. Сохраните ожидаемый layout и способ восстановления границ, прежде чем включать настройку. Семантика tokenizer output должна совпадать с тем, что реально принимает вычислительный graph или программный обработчик.

Проверьте model configuration

Документация конфигурации задает правила имен, типов и 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; Гибридная CPU/GPU-архитектура: как разделить AI-сервис по задачам.