Задержка (Latency)

Задержка (latency) в контексте AI-систем — это время, прошедшее между отправкой запроса модели (вызов API или запрос локального инференса) и получением ответа — обычно разбивается на время до первого токена (TTFT, time-to-first-token — сколько времени проходит до появления хоть какого-то вывода) и общее время генерации (сколько времени проходит до завершения полного ответа). Задержка — одно из самых значимых и недостаточно обсуждаемых ограничений в продакшн AI-продуктах, потому что она напрямую определяет, какие паттерны UX вообще жизнеспособны: функция с задержкой 200 мс может ощущаться мгновенной и запускаться на каждое нажатие клавиши (как автодополнение), тогда как функция с задержкой 8 секунд нуждается в состоянии загрузки, не может выполняться синхронно в критическом пользовательском потоке и, возможно, должна быть перенесена в асинхронную/фоновую задачу. Задержка определяется несколькими накапливающимися факторами: размером модели (более крупные модели дольше генерируют каждый токен), длиной вывода (больше токенов для генерации означает больше времени, поскольку большинство LLM генерируют токены по одному авторегрессивно), временем сетевого round-trip до провайдера API, нагрузкой на сервер/очередями у провайдера, а также тем, используется ли потоковая передача (streaming отправляет токены по мере их генерации, а не ожидает полного ответа, что резко улучшает воспринимаемую задержку, даже если общее время генерации не меняется). Конкретный пример: функция автодополнения кода на базе AI в редакторе кода имеет жёсткий бюджет задержки примерно 200-300 мс, чтобы ощущаться отзывчивой во время набора текста — это исключает крупные топовые модели для этой конкретной функции (вызов уровня Claude Opus может занять 1-3+ секунды) и подталкивает разработчиков к маленьким, быстрым, часто локально запускаемым или развёрнутым на edge-устройствах моделям, специально оптимизированным под этот бюджет задержки, даже принимая несколько более низкое качество вывода в качестве компромисса. Сравните это с функцией "сгенерировать мой квартальный отчёт", где пользователи ожидают подождать, и ответ за 10-15 секунд с индикатором прогресса вполне приемлем, что позволяет разработчику использовать гораздо более крупную, качественную модель. Разработчики управляют задержкой через выбор модели (меньшие/дистиллированные модели для критичных к задержке путей), потоковую передачу ответов для улучшения воспринимаемой скорости, кэширование промптов (пропуск повторных вычислений для повторяющегося контекста) и архитектурные решения вроде асинхронного запуска толерантных к задержке задач (пакетная суммаризация, генерация отчётов) вместо блокировки UI. Задержка также накапливается вдоль многошагового AI-пайплайна способами, которые легко недооценить: RAG-функция, включающая вызов эмбеддинга, запрос к векторной базе данных, вызов реранкинга и, наконец, вызов генерации LLM, имеет четыре последовательных источника задержки, а не один — и наивная реализация, которая строго последовательно выполняет эти шаги, может создать заметно медлительный пользовательский опыт, даже если каждый отдельный шаг достаточно быстр. Продакшн-системы RAG и агентные системы обычно распараллеливают независимые шаги (например, выполняют несколько запросов извлечения одновременно) и агрессивно используют потоковую передачу, чтобы совокупная задержка ощущалась приемлемой, поскольку воспринимаемая задержка (когда пользователь впервые видит, что что-то происходит) так же важна для UX, как и общее время завершения.