В этом материале
Длительность измеряют в одной определённой области часов. Timestamp разных хостов нельзя вычитать без подтверждённых допущений о синхронизации.
У запроса есть отметки времени клиента, прокси и движка. Соблазнительно вычесть одну из другой и получить точное время очереди или сети. Но часы могут иметь разное начало, точность и коррекцию. Даже внутри процесса wall-clock способен измениться независимо от фактического выполнения. Для провайдера нужна схема измерений, которая отделяет длительность от календарной отметки и сохраняет границу каждого наблюдения.
Выберите часы для duration
Python time описывает perf_counter и монотонное измерение длительностей. Такой инструмент подходит для разницы между двумя событиями в согласованной области процесса. Его абсолютное значение не следует превращать в календарный timestamp или переносить как универсальную шкалу между машинами.
Запишите выбранный clock и единицу в измерительном коде. Если библиотека возвращает наносекунды, перевод в секунды выполняется явно. Ошибка единиц может давать правдоподобный график с неверным масштабом, поэтому небольшой fixture с известным ожиданием полезен ещё до запуска inference-нагрузки.
Сохраните wall-clock для корреляции
Календарная отметка помогает найти события в журналах и связать их с обновлением, но не заменяет монотонную duration. В записи полезны оба поля с разным назначением. Нельзя менять их смысл между версиями exporter, сохраняя прежнее имя метрики без пояснения.
OpenTelemetry context propagation описывает связь распределённых операций через контекст. Такая связь помогает найти относящиеся к запросу spans, но сама по себе не синхронизирует часы. Совпавший trace ID не разрешает считать любой межхостовый timestamp точным измерением передачи данных.
Определите события запроса
Назовите точки: запрос отправлен, принят локальным API, началась обработка, получено первое полезное событие, чтение завершено. Для каждой укажите место наблюдения. Клиентское время ожидания и серверное время выполнения отвечают на разные вопросы и могут иметь разный набор включённых этапов.
Рекомендации Prometheus подчёркивают согласованность счёта операций и измерения latency. Завершённые запросы удобнее сопоставлять с ошибками и длительностью, если их границы определены одинаково. Не смешивайте start-based count одной серии с end-based duration другой без понимания последствий для короткого окна.
Проверьте несопоставимые часы
Синтетический fixture может содержать две локальные duration и два wall-clock timestamps с намеренным смещением. Ожидаемый вывод должен сохранить правильные локальные интервалы и отказаться от неподтверждённого разложения общего времени. Это тест аналитики, который не требует менять системные часы настоящего сервера.
Если нужен межхостовый анализ, зафиксируйте допущения синхронизации и погрешность. Не показывайте десятичные знаки, создающие видимость точности выше доступного измерения. Неизвестный участок лучше оставить отдельным остатком, чем приписать его GPU на основе несовместимых временных шкал.
Версионируйте измерительную схему
После изменения клиента, proxy path или instrumentation повторите короткий контрольный запрос. Сравните определения метрик, а не только значения. Если момент first event теперь относится к headers вместо content, наблюдаемое улучшение может быть изменением смысла измерения, а не реальным ускорением модели.
Связанные материалы — методика бенчмарка и мониторинг GPU. Итогом служит явная схема clocks и событий, позволяющая честно сравнивать результаты без выдуманной точности и без заявлений о фактических задержках неизвестной инфраструктуры.