В этом материале
Трассировка SGLang помогает разобрать задержку конкретного запроса между workers, когда агрегированного TTFT недостаточно.
Трассировка SGLang помогает разобрать задержку конкретного запроса между workers, когда агрегированного TTFT недостаточно. Для этого нужны request identity, согласованная временная шкала и выбранный уровень детализации. Включение OpenTelemetry само по себе не локализует проблему. Сначала сформулируйте исследуемый интервал и убедитесь, что trace действительно охватывает нужные процессы, а не заканчивается на первом сетевом компоненте перед вычислительной стадией.
Выберите вопрос для trace
Например, требуется понять, где один длинный запрос ждет до начала decode. Руководство production request trace описывает включение tracing, OTLP endpoint и уровни детализации. Выбирайте уровень по диагностической задаче, а не сохраняйте максимальный объем событий без цели. Убедитесь, что collector принимает данные и связывает нужные spans. Пустой интерфейс наблюдения может означать ошибку экспорта, а не отсутствие работы на сервере или доказательство мгновенного прохождения исследуемой стадии.
Согласуйте идентификацию
Сохраните клиентский идентификатор, соответствующий trace и worker роли, доступные в выбранной версии. При нескольких процессах одинаковое время начала недостаточно для надежного сопоставления: запросы могут поступать почти одновременно. Проверьте, как контекст передается между стадиями, и явно отметьте отсутствующие связи. Не склеивайте spans вручную только потому, что их длительности складываются в ожидаемую общую задержку. Такой отчет способен создать убедительную, но неверную картину маршрута одного обращения при высокой конкурентной нагрузке.
Пример карточки медленного запроса
Запишите момент отправки, серверные этапы, первый token и завершение. Рядом укажите источник каждого времени: клиент, trace span или отдельный log. Это структура артефакта без выдуманных миллисекунд. Если большая пауза находится между двумя spans, проверьте, есть ли наблюдение этого интервала вообще. Отсутствующий span не равен отсутствующей работе. Сравните ту же операцию с коротким входом и найдите изменившийся этап, сохранив модель и output policy неизменными.
Дополните trace профилем
Руководство profiling SGLang описывает CPU/GPU инструменты для более низкого уровня. Request trace помогает выбрать участок, а профиль объясняет, что выполнялось внутри него. Не требуйте от trace доказательства конкретного kernel bottleneck, если он показывает только общую стадию. При distributed запуске соберите профиль нужных workers отдельно. Общий график GPU utilization без связи с запросом не заменяет эту проверку и способен скрыть ожидание одного обращения за полезной работой остальных.
Проверьте стоимость наблюдения
Повторите небольшую контрольную серию с tracing и без него, сохранив одинаковое расписание. Оцените объем событий и влияние на задержку, не предполагая нулевую стоимость. В итоговый пакет включите конфигурацию export, версии, схему workers и минимальную воспроизводимую последовательность. Не копируйте лишний пользовательский текст в учебные fixtures: для связи этапов достаточно идентификаторов и описанного тестового входа. Полезный вывод должен показывать непосредственно наблюдаемые границы и честно отделять их от предположений. При смене уровня tracing или runtime повторите проверку, потому что наличие новых spans меняет видимость, а не обязательно само исполнение. Так инструмент становится способом локализации конкретного ожидания, а не заменой измерения причин по красивой, но неполной диаграмме.
Связанные материалы
Мониторинг GPU без лишних графиков: пять уровней наблюдения; Скорость потока и задержка: как выбрать рабочий режим GPU.