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

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

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

Руководство metrics определяет cumulative duration для обработки запроса, очереди и вычислительных подэтапов. Накопленное число не является latency одного свежего запроса. Для среднего за интервал нужны согласованные изменения соответствующих счетчиков и количества операций. При этом среднее не показывает хвосты. Сохраните временной диапазон и scope model/version. Смешивание версий или рестарт счетчика способно создать ошибочную интерпретацию, поэтому перед вычислением проверьте метки и непрерывность наблюдений, а не только форму графика.

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

Документация tracing описывает 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 без лишних графиков: пять уровней наблюдения; Скорость потока и задержка: как выбрать рабочий режим GPU.