В этом материале
Время между CUDA Events и длительность запроса сопоставляют только после явного описания границ и зависимостей измерения.
Назвать измеряемый интервал
Время HTTP-запроса включает клиент, сеть, очередь, подготовку данных, выполнение и передачу ответа. CUDA Events позволяют измерять выбранный интервал работы, связанный с событиями устройства. Эти числа могут различаться без какой-либо неисправности. До запуска формулируют вопрос: длительность kernel, цепочки операций, обработки на сервере или полного запроса? Нельзя подписывать все графики общим словом latency. Для каждого показателя указывают точку старта, точку окончания, единицы и условия завершения. Тогда маленький интервал device time не превращается в необоснованное заявление, что пользователь обязан получать ответ за такое же время независимо от очереди и транспортного пути.
Измерять host duration монотонно
Для длительности на одной машине выбирают подходящий монотонный источник времени, а календарные timestamps сохраняют отдельно для корреляции. Документация clock_gettime объясняет различия часов Linux. Интервал CPU вокруг отправки асинхронного вызова может измерять только submission, если завершение работы не включено в конечную границу. Поэтому контрольный пример явно отмечает, ожидает ли host готовность результата. Нельзя вычитать показания часов разных серверов и считать полученную разницу точной длительностью без дополнительных условий синхронизации. Даже общий request ID связывает события логически, но сам по себе не делает временные шкалы разных машин пригодными для точного арифметического сравнения.
Правильно расположить CUDA Events
CUDA Runtime Event API описывает запись событий, ожидание завершения и получение elapsed time. События ставят относительно конкретной работы и её зависимостей, а затем проверяют готовность результата измерения. Если событие конца находится в другом stream без нужной зависимости, интервал может не охватывать задуманную цепочку. Также следует учитывать разрешение и применимость метода к коротким операциям. Схема измерения должна показывать streams, события и ожидания, а не только два вызова таймера. Измеренный интервал не следует автоматически называть чистым временем арифметики kernel: между событиями может существовать другая работа или ожидание, зависящее от выбранного порядка исполнения.
Разобрать расхождение по фазам
Диагностический артефакт содержит временную схему: принятие запроса, постановка работы, события устройства, готовность результата и завершение отправки. Если device interval стабилен, а серверная длительность растёт, исследуют очередь и host-подготовку. Если меняется само устройство, проверяют конкурирующие операции и зависимости. Если расходится только внешний запрос, добавляют наблюдения сети и клиента. Нельзя механически считать host duration минус event duration точным временем CPU: интервалы могут перекрываться и охватывать разные части работы. Разложение полезно только при согласованных границах. Для streaming отдельно фиксируют первый содержательный ответ и полное завершение, поскольку это разные пользовательские события.
Представить сопоставимый результат
В отчёте сохраняют версии, размеры работы, прогрев, режим конкурентности и правила синхронизации. Полезны методика inference benchmark и vLLM bench serve. Для сравнения оптимизаций используют одинаковый пользовательский интервал и отдельно показывают изменившиеся внутренние фазы. Ни один event timing не доказывает end-to-end SLO, а удачный внешний ответ не показывает распределение времени внутри GPU. Результат должен оставлять читателю возможность понять, какое именно событие завершило каждую шкалу. Это защищает от ошибочного ускорения на графике, которое возникло только потому, что новый замер перестал ждать реально нужную работу.