Задержка ответа языковых моделей: пять ключевых факторов латентности ИИ

Но задержка ответа языковых моделей зависит не от одной цифры и не сводится к размеру модели или скорости интернета пользователя. Для интерактивного сервиса она складывается из нескольких этапов, каждый из которых может стать узким местом: обработки промпта, генерации, работы с KV-кэшем, чтения данных из памяти GPU и ожидания в очереди. Именно сочетание этих факторов определяет латентность LLM API и скорость отклика чат-бота или AI-ассистента.

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

Анатомия инференса трансформеров: от фазы prefill до последовательной генерации токенов

Авторегрессионная языковая модель обрабатывает запрос в две принципиально разные фазы. Первая, prefill, охватывает входной промпт: модель обрабатывает его содержимое и строит KV-кэш. В этой структуре для каждого слоя и позиции в последовательности сохраняются ключи и значения, необходимые для дальнейшей генерации.

Затем начинается decode. Модель выдаёт выходные токены по одному, опираясь на предыдущие токены и накопленный KV-кэш. Между этими фазами есть важная разница: prefill работает сразу со всем входным контекстом, тогда как decode проходит последовательно, шаг за шагом. Поэтому ускорение одной стадии не обязательно заметно ускорит другую.

У каждой фазы свой характер нагрузки на GPU. Prefill часто ограничен вычислительной мощностью: модель обрабатывает много токенов параллельно, выполняя операции над слоями и контекстом. Decode обычно сильнее зависит от пропускной способности памяти. Для очередного шага нужно получить доступ к весам модели и данным KV-кэша. Если чтение этих данных занимает больше времени, чем сами вычисления, дополнительная вычислительная мощность не устраняет основное ограничение.

Для продуктовой команды это означает, что задержка складывается из отдельных участков, а не объясняется единственным параметром модели. Длинный промпт может увеличить время prefill, а длинный ответ растянет decode. Если же запросы долго стоят перед обработкой, ускорение GPU не решит проблему очереди.

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

Две фазы инференса отражаются в двух метриках, которые полезно отслеживать отдельно. TTFT (time to first token) показывает время до появления первого токена. В него входят ожидание обработки запроса и prefill. TPOT (time per output token) показывает, сколько в среднем проходит между последующими токенами. Для этого интервала также используют название ITL, или межтокеновая задержка.

Упрощённо полное время ответа можно представить так: TTFT + TPOT × число токенов после первого. Значит, короткий ответ может показаться быстрым даже при неидеальном TPOT, а длинная генерация накапливает задержку с каждым новым токеном.

Например, при TPOT в 30 мс генерация тысячи токенов займёт около 30 секунд. Если же обработка входного промпта занимает две секунды, это время в основном повлияет на ожидание первого токена, но не добавит ещё две секунды на каждом шаге генерации. Поэтому сервис, который формирует длинные отчёты, особенно чувствителен к межтокеновой задержке. Для коротких ответов важнее может оказаться TTFT: даже если модель быстро генерирует текст, долгое молчание перед первым токеном создаёт ощущение медленного отклика.

Скорость около 6 токенов в секунду можно использовать как ориентир для чтения текста по мере его генерации. Однако комфорт зависит от длины ответа и от того, как интерфейс показывает поток: непрерывно ли появляются токены, не прерывается ли выдача, быстро ли сервис начинает отвечать. Высокий суммарный throughput тоже не означает, что каждый пользователь получает быстрый ответ. Сервер может генерировать много токенов для большого числа запросов, но отдельный запрос всё равно будет ждать в очереди или получать токены с заметными паузами.

При оценке сервиса важны не только средние значения, но и перцентили задержки: P50, P90, P95 и P99. P50 описывает медианный запрос, а высокие перцентили показывают, насколько долго ждут пользователи в медленной части распределения. Если большинство ответов приходит быстро, но отдельные запросы регулярно задерживаются, среднее значение может скрыть проблему. Для пользователя же такие задержки не усредняются: именно они формируют впечатление о непредсказуемой работе продукта.

Среднее время ответа показывает общую картину, но не объясняет, что происходит с запросами, которые ждут дольше остальных.

Влияние длины входного контекста, размера KV-кэша и архитектурных параметров моделей

Чем длиннее входной контекст, тем больше данных нужно обработать на этапе prefill и тем больше памяти может занимать KV-кэш. Его размер зависит от количества слоёв, длины последовательности, архитектуры модели и числа одновременно обслуживаемых запросов. Когда несколько сессий используют длинный контекст, общий объём кэша растёт. Если доступная VRAM ограничена, серверу приходится выбирать между числом параллельных запросов и размером контекста, который можно обслуживать одновременно.

Увеличение контекста влияет и на время обработки входа, и на работу с кэшем во время генерации. Поэтому настройка только максимальной длины промпта не описывает реальную нагрузку. Важно учитывать, сколько запросов с таким контекстом приходит одновременно и насколько долго каждый из них генерирует ответ.

На расход памяти также влияют размер модели и способ хранения её весов. Квантование уменьшает точность представления весов и сокращает занимаемый ими объём. Более компактные веса требуют меньше памяти для хранения и передачи к вычислительным блокам, что может помочь на стадии decode. Эффект зависит от модели, оборудования и реализации: само по себе снижение разрядности не гарантирует ускорения во всех сценариях, особенно если меняются другие ограничения системы.

Для наглядности можно сравнить распространённые варианты представления весов. Таблица показывает порядок объёма для модели на 7 млрд параметров и общую направленность компромиссов, а не обещание одинакового эффекта на любом оборудовании.

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

Пропускная способность памяти GPU против вычислительной мощности в задачах декодирования

Различие между вычислительно насыщенным prefill и чувствительным к памяти decode полезно не как универсальный рецепт апгрейда, а как способ правильно поставить вопрос. Если время уходит на обработку длинного входа, ограничением могут быть вычисления. Если же генерация токенов идёт медленно, стоит проверить, не упирается ли система в передачу весов и данных KV-кэша.

В фазе decode модель выдаёт по одному токену за шаг. При этом значительный объём данных приходится считывать из памяти, а вычислений на отдельный шаг может быть недостаточно, чтобы полностью загрузить вычислительные блоки. В результате GPU способен простаивать, ожидая данные. В такой ситуации покупка устройства с большей вычислительной мощностью сама по себе может дать меньше эффекта, чем улучшение пропускной способности памяти или оптимизация работы с кэшем.

Для коротких запросов и небольших ответов картина может быть другой. Если основное время занимает обработка входного промпта, полезнее окажется ускорение вычислений на стадии prefill. У классификатора или суммаризатора с коротким ответом соотношение времени между фазами будет отличаться от сервиса, который регулярно генерирует длинные тексты.

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

Оптимизация начинается с измерения узкого места. Иначе можно ускорить этап, который почти не влияет на время ответа пользователя.

Организация очередей запросов и переход от статического батчинга к continuous batching

На воспринимаемую задержку влияют не только модель и GPU. Запрос может потратить заметное время в очереди, прежде чем начнётся инференс. Кроме того, серверу нужно решить, как объединять запросы для совместной обработки.

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

Continuous batching, или непрерывный батчинг, позволяет менять состав группы по ходу работы. Завершившие генерацию запросы освобождают слоты, а новые могут присоединиться, не дожидаясь завершения всех остальных. Это помогает эффективнее загружать GPU, особенно когда запросы различаются по длине. Однако рост суммарной пропускной способности не означает, что задержка каждого отдельного запроса автоматически снизится: результат зависит от очереди, ограничений на размер батча и настроек планировщика.

В системах инференса, включая решения на базе vLLM, и инструментах мониторинга для генеративных сервисов можно отдельно учитывать время ожидания и время генерации. Такое разделение помогает понять, на каком участке возникла проблема. Клиентская задержка включает передачу запроса по сети, ожидание в очереди, prefill и decode. Если серверная генерация занимает мало времени, а пользователь ждёт долго, причина может быть в очереди, сетевом пути или распределении нагрузки.

Для команды важно видеть весь маршрут запроса, а не только время работы модели. Например, рост P99 при стабильном времени генерации стоит рассматривать как сигнал проверить очередь и сетевую доставку. Если же растёт TPOT, внимание следует переключить на декодирование, память и работу с KV-кэшем. Так оптимизация работы языковых моделей опирается на фактическое поведение сервиса, а не на предположение, что любая задержка начинается внутри модели.

Задержка как задача всей системы

Задержка ответа языковой модели складывается из нескольких процессов: prefill, последовательного decode, работы с памятью, управления контекстом и организации очереди. Ускорение одного из них полезно только тогда, когда именно он ограничивает конкретный сценарий. Длинные промпты сильнее нагружают обработку входа, длинные ответы накапливают межтоковую задержку, а всплеск запросов может превратить очередь в главный источник ожидания.

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

Дальше будут развиваться и аппаратные решения, и алгоритмы работы с кэшем и генерацией. Но для пользователя важен не рекордный throughput сервера, а предсказуемое время ответа. Поэтому оптимизация начинается не с выбора самой большой модели или самого мощного GPU, а с понимания того, где именно теряется время в реальном запросе.