# Triton latency: как отделить queue, input, inference и output

Задержку Triton нужно разбирать по queue, input processing, inference и output processing.

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

Задержку Triton нужно разбирать по queue, input processing, inference и output processing. Эти интервалы имеют разные границы, а cumulative counters требуют анализа за выбранный период. Один общий response time не показывает виновный этап. Сопоставьте метрики с trace конкретного запроса, особенно внутри ensemble. Тогда можно отличить ожидание scheduler от подготовки данных или GPU вычисления, не объясняя весь TTFT только utilization видеокарты.

## Уточните смысл счетчиков

[Руководство metrics](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/metrics.html) определяет cumulative duration для обработки запроса, очереди и вычислительных подэтапов. Накопленное число не является latency одного свежего запроса. Для среднего за интервал нужны согласованные изменения соответствующих счетчиков и количества операций. При этом среднее не показывает хвосты. Сохраните временной диапазон и scope model/version. Смешивание версий или рестарт счетчика способно создать ошибочную интерпретацию, поэтому перед вычислением проверьте метки и непрерывность наблюдений, а не только форму графика.

## Используйте trace для отдельного обращения

[Документация tracing](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/trace.html) описывает timestamps, request identity и parent связи. Это позволяет рассмотреть границы queue и compute для конкретного случая. Не вычитайте произвольные клиентские timestamps из серверных без проверки часов и определения событий. Если интервал отсутствует, обозначьте его как ненаблюдаемый. Факт большого остатка не доказывает, что он целиком относится к сети или tokenizer. Сначала составьте временную схему с источником каждой точки, затем делайте вывод о локализации задержки.

## Пример таблицы стадий

Для одного медленного запроса заведите строки frontend, queue, compute input, infer и compute output. В каждой укажите наблюдаемые начало/конец, источник и confidence интерпретации. Это предложенный артефакт, не выдуманные миллисекунды. Для ensemble добавьте модель и parent identity каждого шага, чтобы не сложить перекрывающиеся интервалы как строго последовательные. Сравните с коротким контрольным запросом. Если растет input stage при неизменном infer, исследуйте подготовку входа вместо немедленной замены GPU или изменения precision весов.

## Учитывайте особенности учета

Метрики cache hits и обычного исполнения могут иметь разные правила включения compute intervals, описанные в документации. Не сравнивайте серии с разным cache состоянием как полностью одинаковую работу. Аналогично количество requests и model executions не всегда совпадает при batching. Выбирайте знаменатель в соответствии с вопросом. Большое cumulative infer time может быть следствием большого объема полезной работы, а не замедления отдельной операции. Подтверждайте предполагаемую регрессию распределением или сопоставимым per-request наблюдением и сохраняйте условия нагрузки.

## Оформите локализованный вывод

В отчете укажите interval, labels, counter deltas, trace sample и конфигурацию batching. Отдельно сформулируйте, что подтверждено непосредственно и что требует дополнительного профиля. Если bottleneck внутри infer, trace уровня стадий еще не доказывает конкретную kernel причину. Если проблема в queue, более быстрый input tokenizer может не решить ее. Полезный результат связывает пользовательскую задержку с определенным этапом и следующей проверкой, не подменяя диагноз общим советом увеличить concurrency. После изменения повторите ту же серию и сравните оба уровня: aggregate counters и отдельные traces. Это помогает увидеть перенос ожидания между стадиями вместо ложного успеха, когда одна метрика уменьшилась, но полный ответ клиенту по-прежнему приходит с прежней задержкой.

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

[Мониторинг GPU без лишних графиков: пять уровней наблюдения](/ru/journal/gpu-monitoring-scorecard/); [Скорость потока и задержка: как выбрать рабочий режим GPU](/ru/journal/throughput-latency-tradeoff/).