Как устроена латентность инференса
Между нажатием «отправить» и первым словом ответа проходит цепочка этапов, и задержка может родиться на каждом. Чтобы управлять скоростью, её раскладывают на составляющие — иначе оптимизируют не то место.
- Сеть и очередь. Запрос добирается до сервера и ждёт своей очереди; в часы пик именно очередь, а не модель, добавляет секунды.
- Обработка промпта. Модель читает весь контекст запроса — системную инструкцию, документы, историю; чем длиннее контекст, тем дольше чтение до начала ответа.
- Генерация. Ответ рождается токен за токеном: скорость генерации определяет, сколько ждёт пользователь длинного ответа.
- Доставка. Стриминг выводит токены по мере появления — человек начинает читать задолго до полного завершения ответа.
Какие метрики отслеживают
| Метрика | Что измеряет | Где критична |
|---|---|---|
| TTFT — время до первого токена | Задержку до начала ответа | Голосовые роботы, чаты: пауза ощущается как «зависание» |
| Скорость генерации (токенов/с) | Темп появления текста | Длинные ответы, стриминг, документы |
| Общее время ответа | Весь путь от запроса до последнего токена | Фоновые процессы, отчёты |
| Персентили (p95, p99) | Худшие случаи, а не средние | Соглашения об уровне сервиса, пики нагрузки |
Средняя латентность — обманчивая метрика: сервис со средней секундой и p99 в пятнадцать отдает пользователям ощущение «то летает, то мёртвая». Поэтому в требованиях фиксируют перцентили по классам запросов и проверяют их под нагрузкой, а не в демонстрационном режиме.
Где латентность встречается в бизнес-задачах
- Голосовые роботы и колл-центры. Реплика позже долей секунды — и клиент начинает переспрашивать, а диалог рассыпается; для ИИ-звонков скорость реакции — часть качества сервиса наряду с точностью распознавания.
- Чат-ассистенты на сайте. Первая строка ответа должна появляться быстро; дальше работает стриминг — чтение идёт параллельно генерации, и ожидание сглаживается.
- Операторы и кассиры. Подсказка модели, всплывающая в интерфейсе оператора, полезна только если приходит раньше, чем клиент закончил вопрос.
- Пакетная обработка. Здесь латентность отдельного запроса не важна — важна пропускная способность батч-инференса и укладывание в ночное окно.
Как снижают латентность
Компактные модели на типовых запросах. Квантизация и дистилляция уменьшают время чтения и генерации — простые вопросы уходят на быстрый маршрут через роутинг. Кэширование префикса. Постоянная часть промпта обрабатывается один раз — промпт-кэширование бережёт и время, и токены. Спекулятивное декодирование. Черновая модель угадывает продолжение, целевая проверяет — ответ того же качества приходит быстрее. Инфраструктура. Резерв GPU под пики, приоритет интерактивных запросов над фоновыми, размещение рядом с пользователями. Комбинация двух-трёх приёмов на типовом проекте даёт кратное ускорение; универсального рычага нет — выбирают по профилю задержки, которую показали замеры.
Сколько стоит (сентябрь 2026)
Замер латентности на реальном трафике с профилем узких мест — от 90 000 ₽; пилот оптимизации (кэш префикса, роутинг скорости, настройки serving-движка) с целевыми перцентилями — от 480 000 ₽; промышленная оптимизация со спекулятивным декодированием, автоскейлом и мониторингом SLA — от 690 000 ₽. Проверка устойчивости под пиковыми нагрузками — нагрузочное тестирование; serving-слой строится на vLLM и Kubernetes.
Как начать
Замерьте текущее время до первого токена и полное время ответа на реальных запросах — раздельно для простых и сложных. Профиль покажет, где рождается задержка: в очереди, в чтении длинного промпта или в генерации. Дальше решение почти механическое: длинный префикс — кэшировать, пики — резервировать, простые запросы — уводить на быстрый маршрут. Внедрение — LLM-интеграции; быстрые маршруты для типовых вопросов — LLM-роутинг.