Латентность инференса

Латентность инференса — это время от момента, когда система получила готовый запрос на предсказание, до момента, когда вернула результат. Важна не сама цифра, а граница измерения: только выполнение модели, серверная обработка без сети или полный путь end-to-end через очередь, сериализацию и транспорт. Метрика полезна не всегда: для пакетной офлайн-обработки, ночных пересчетов и задач, где важнее стоимость и пропускная способность, оптимизация латентности может дать мало пользы и даже ухудшить утилизацию ресурсов.

Простыми словами

Если пользователь нажал кнопку и ждет ответ модели, латентность показывает, сколько именно он ждет. Для практики это одна из главных метрик интерактивных ML-сервисов: поиска, рекомендаций, модерации, распознавания речи, чат-интерфейсов, ранжирования и генерации.

Проблема в том, что словом латентность часто называют разные вещи. Команда инфраструктуры может считать время от входа HTTP-запроса до отправки ответа. Команда ML — только время вызова модели на устройстве. Для LLM иногда отдельно считают время до первого токена и скорость генерации после старта. Поэтому без явной договоренности метрика легко становится бесполезной.

• Model latency — только выполнение модели.
• Server latency — модель плюс код сервиса, но без внешней сети.
• End-to-end latency — полный путь от клиента до клиента.

Для пользователя важна последняя версия, но для поиска узкого места нужны все три.

Как это работает

Латентность складывается из нескольких этапов. Даже если сама модель работает быстро, итоговое время ответа может расти из-за очередей, блокировок, преобразования данных или нестабильного транспорта.

Этап	Что входит	На что смотреть
Получение запроса	Сеть, балансировщик, TLS, десериализация	Размер запроса, ретраи, сетевые скачки
Очередь	Ожидание свободного воркера или устройства	Конкуренция, лимиты, автоскейлинг
Препроцессинг	Токенизация, ресайз, нормализация, feature extraction	CPU-нагрузка, копирование памяти
Инференс	Выполнение модели на CPU, GPU или другом ускорителе	Размер модели, тип чисел, оптимизация графа
Постпроцессинг	Декодирование, NMS, агрегация, форматирование ответа	Однопоточные участки, Python-overhead
Отправка ответа	Сериализация и сеть	Размер результата, стриминг, сжатие

На продакшене обычно смотрят не только среднее значение, а процентили: p50, p95, p99. Среднее хорошо описывает типичный случай, но почти ничего не говорит о хвостовых задержках. А именно хвост ломает пользовательский опыт и приводит к тайм-аутам в цепочке сервисов.

Что влияет на латентность сильнее всего

• Размер и архитектура модели. Более точная модель часто медленнее, но не всегда линейно.
• Аппаратная платформа. Один и тот же граф ведет себя по-разному на CPU, GPU и специализированных ускорителях.
• Размер входа. Длина промпта, разрешение изображения, число объектов в кадре напрямую меняют время выполнения.
• Параллелизм и очереди. При росте нагрузки латентность может расти не из-за модели, а из-за ожидания ресурса.
• Формат исполнения. Квантование, компиляция графа, fusion-операций и выбор рантайма часто дают больший эффект, чем локальная ручная оптимизация кода.

Как измерять корректно

1. Сначала зафиксируйте точку измерения: модель, сервер или end-to-end.
2. Разделите холодный старт и прогретое состояние. Иначе одна цифра смешает несовместимые режимы.
3. Используйте одинаковые входы и одинаковую конкуренцию запросов при сравнении моделей.
4. Смотрите процентили, а не только среднее.
5. Логируйте этапы пайплайна по отдельности, иначе не будет понятно, что именно ускорять.

Для LLM часто нужны дополнительные метрики: time to first token и задержка между токенами. Общая латентность завершения ответа не показывает, насколько быстро пользователь увидит начало генерации.

Зачем нужно

Латентность инференса нужна не ради красивой дашбордной цифры, а для управления системой.

• Контроль пользовательского опыта. В интерактивных сценариях задержка напрямую влияет на удержание и завершение действий.
• Управление надежностью. Если один сервис отвечает медленно, downstream-сервисы начинают ретраить, копить очереди и создавать каскадные сбои.
• Выбор архитектуры. Нельзя разумно сравнивать модели, рантаймы и ускорители без одинаково измеренной латентности.
• Планирование ресурсов. Автоскейлинг, лимиты конкуренции и стратегия батчинга опираются на профиль задержек, а не на среднюю загрузку CPU.
• Разделение SLA. Бизнесу обычно нужен ответ на вопрос, укладывается ли сервис в заданный бюджет времени на запрос.

Практически это означает одно: латентность — не только характеристика модели, но и характеристика всей системы обслуживания запроса.

Пример

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

1. Команда фиксирует три метрики: end-to-end, серверную латентность и чистое время инференса.
2. В код добавляют таймстемпы на этапах приема файла, декодирования изображения, препроцессинга, запуска модели, постпроцессинга и отправки JSON.
3. Дальше сравнивают процентили. Если время модели стабильно, а p95 полного запроса растет, проблема почти наверняка вне модели: очередь, загрузка CPU, сеть или сериализация.
4. Если растет именно время модели, проверяют размер входов, режим батчинга, конкуренцию на GPU и изменения в версии рантайма.
5. Для интерактивного маршрута отключают агрессивный батчинг, а для фоновой обработки оставляют его включенным, потому что там важнее throughput.

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

Заблуждения и ограничения

• Заблуждение: достаточно смотреть среднее время ответа. На практике среднее скрывает длинный хвост. Пользовательские жалобы и тайм-ауты чаще коррелируют с p95 и p99.
• Заблуждение: латентность равна времени вызова model.forward(). Для сервиса это часто лишь часть пути. Если сеть и очередь дают основную задержку, оптимизация модели почти не изменит опыт пользователя.
• Заблуждение: GPU всегда уменьшает задержку. При малых моделях, коротких запросах и дорогом копировании данных CPU может оказаться не хуже, а иногда и лучше.
• Заблуждение: батчинг всегда полезен. Он часто повышает утилизацию и throughput, но может ухудшить хвостовую латентность из-за ожидания набора батча.
• Заблуждение: одна цифра из бенчмарка переносится в продакшен. Реальная нагрузка зависит от распределения входов, конкуренции, прогрева, кэшей и топологии сети.

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

Частые вопросы

Чем latency отличается от throughput?

Latency показывает, сколько времени занимает один запрос. Throughput показывает, сколько запросов система обрабатывает за единицу времени. Эти метрики связаны, но оптимизация одной может ухудшить другую.

Что считать правильной точкой измерения?

Та, которая соответствует вашему решению. Для UX и SLA обычно нужна end-to-end латентность. Для сравнения моделей и рантаймов — чистое время инференса. Важно не смешивать эти уровни в одном графике без подписи.

Почему p95 часто важнее среднего?

Потому что пользователь и зависимые сервисы страдают от редких, но длинных задержек. Среднее может выглядеть приемлемо, даже когда хвост уже создает тайм-ауты.

Всегда ли стоит уменьшать размер модели ради скорости?

Нет. Если узкое место находится в сети, очереди или препроцессинге, уменьшение модели почти не поможет. Сначала нужна декомпозиция латентности по этапам, потом — оптимизация конкретного узкого места.

Как честно сравнивать две модели по латентности?

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

Связанные понятия

• Пропускная способность (throughput). Число запросов или токенов, обрабатываемых за единицу времени.
• Хвостовая латентность. Поведение верхних процентилей, например p95 и p99.
• Батчинг. Объединение нескольких запросов в один запуск ради лучшей утилизации устройства.
• Concurrency. Число одновременных запросов, конкурирующих за один и тот же ресурс.
• Cold start. Первый запуск после загрузки модели, инициализации контейнера или выделения ускорителя.
• TTFT и токенная скорость. Важные метрики для LLM, дополняющие общую латентность ответа.

Коротко: латентность инференса — это не просто скорость модели, а измеримый бюджет времени на весь путь запроса. Чтобы метрика была полезной, заранее фиксируйте границы измерения, разделяйте этапы пайплайна и смотрите процентили, а не одну усредненную цифру.