# Монотонные часы для измерения задержек inference API

Как измерять задержки inference API монотонными часами: duration внутри процесса, wall-clock для корреляции, границы хостов и схема событий.

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

У запроса есть отметки времени клиента, прокси и движка. Соблазнительно вычесть одну из другой и получить точное время очереди или сети. Но часы могут иметь разное начало, точность и коррекцию. Даже внутри процесса wall-clock способен измениться независимо от фактического выполнения. Для провайдера нужна схема измерений, которая отделяет длительность от календарной отметки и сохраняет границу каждого наблюдения.

## Выберите часы для duration

[Python time](https://docs.python.org/3/library/time.html) описывает perf_counter и монотонное измерение длительностей. Такой инструмент подходит для разницы между двумя событиями в согласованной области процесса. Его абсолютное значение не следует превращать в календарный timestamp или переносить как универсальную шкалу между машинами.

Запишите выбранный clock и единицу в измерительном коде. Если библиотека возвращает наносекунды, перевод в секунды выполняется явно. Ошибка единиц может давать правдоподобный график с неверным масштабом, поэтому небольшой fixture с известным ожиданием полезен ещё до запуска inference-нагрузки.

## Сохраните wall-clock для корреляции

Календарная отметка помогает найти события в журналах и связать их с обновлением, но не заменяет монотонную duration. В записи полезны оба поля с разным назначением. Нельзя менять их смысл между версиями exporter, сохраняя прежнее имя метрики без пояснения.

[OpenTelemetry context propagation](https://opentelemetry.io/docs/concepts/context-propagation/) описывает связь распределённых операций через контекст. Такая связь помогает найти относящиеся к запросу spans, но сама по себе не синхронизирует часы. Совпавший trace ID не разрешает считать любой межхостовый timestamp точным измерением передачи данных.

## Определите события запроса

Назовите точки: запрос отправлен, принят локальным API, началась обработка, получено первое полезное событие, чтение завершено. Для каждой укажите место наблюдения. Клиентское время ожидания и серверное время выполнения отвечают на разные вопросы и могут иметь разный набор включённых этапов.

[Рекомендации Prometheus](https://prometheus.io/docs/practices/instrumentation/) подчёркивают согласованность счёта операций и измерения latency. Завершённые запросы удобнее сопоставлять с ошибками и длительностью, если их границы определены одинаково. Не смешивайте start-based count одной серии с end-based duration другой без понимания последствий для короткого окна.

## Проверьте несопоставимые часы

Синтетический fixture может содержать две локальные duration и два wall-clock timestamps с намеренным смещением. Ожидаемый вывод должен сохранить правильные локальные интервалы и отказаться от неподтверждённого разложения общего времени. Это тест аналитики, который не требует менять системные часы настоящего сервера.

Если нужен межхостовый анализ, зафиксируйте допущения синхронизации и погрешность. Не показывайте десятичные знаки, создающие видимость точности выше доступного измерения. Неизвестный участок лучше оставить отдельным остатком, чем приписать его GPU на основе несовместимых временных шкал.

## Версионируйте измерительную схему

После изменения клиента, proxy path или instrumentation повторите короткий контрольный запрос. Сравните определения метрик, а не только значения. Если момент first event теперь относится к headers вместо content, наблюдаемое улучшение может быть изменением смысла измерения, а не реальным ускорением модели.

Связанные материалы — [методика бенчмарка](/ru/journal/inference-benchmark-method/) и [мониторинг GPU](/ru/journal/gpu-monitoring-scorecard/). Итогом служит явная схема clocks и событий, позволяющая честно сравнивать результаты без выдуманной точности и без заявлений о фактических задержках неизвестной инфраструктуры.