Почему агент дольше
начинает отвечать

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

19 октября AWS опубликовала способ сократить такое повторное вычисление в архитектуре vLLM с раздельными узлами подготовки контекста и генерации ответа. Документация vLLM отдельно описывает механизм и его настройки. Решение подходит не каждому проекту, но хорошо показывает, как разбирать задержку агента по частям.

Где возникает повторная работа

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

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

Что меняет двунаправленный перенос

В описанной реализации decode временно сохраняет KV-блоки после завершения ответа. Прокси связывает их с conversation_id и на следующем шаге передаёт prefill метаданные блоков. Prefill забирает сохранённое состояние и вычисляет только новые токены.

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

Передача кэша тоже имеет цену

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

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

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

Что показал опубликованный тест

AWS проверила механизм на схеме с одним prefill- и одним decode-узлом, на инстансах EC2 P5en с EFA. Prefix caching на prefill специально отключили, чтобы воспроизвести локальное вытеснение кэша или выбор другого prefill-узла. Для Qwen3-32B на контексте 24 тысячи токенов снижение TTFT составило до 1,6 раза, для GLM-5-FP8 на 20 тысячах токенов до 3,3 раза.

Это результаты стороннего теста на конкретной инфраструктуре. Они не являются показателем Novera и не прогнозируют эффект для произвольного корпоративного агента.

Когда стоит проверять такую архитектуру

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

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

• распределение TTFT по длине контекста;
• долю повторно обрабатываемых токенов;
• паузу между шагами одной сессии;
• стоимость переноса KV по сравнению с локальным prefill.

После этого две конфигурации проверяют на одинаковом наборе диалогов. Помимо средней задержки нужны P95/P99, использование памяти, доля попаданий в кэш и поведение после истечения TTL. Отдельный тест должен подтвердить корректный откат к обычному prefill, если состояние потеряно или устарело.

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