Практика · vLLM

Зачем vLLM возвращает кеш диалога на узел обработки запроса

4 мин чтенияРазбор опубликован

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

Что это меняет для покупателя

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

Следующий вопрос приносит старый текст обратно

В публикации от 12 октября 2026 года vLLM разбирает двустороннюю передачу KV-кеша для многошаговых диалогов. Ключевое изменение: узел, который обрабатывает входной текст, может получить назад промежуточные данные, оставшиеся на узле генерации ответа. Для команды это интересно тем, что задержку продолжения разговора иногда стоит искать в повторной обработке истории, а не в размере модели.

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

Односторонний маршрут обслуживает только половину цикла

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

Обратный перенос замыкает эту цепочку: prefill повторно использует данные, которые decode сохранил после ответа. Поэтому ценность изменения проявляется именно в последовательности связанных запросов. Демонстрация на независимых коротких вопросах мало расскажет об этом преимуществе. И длина ответа сама по себе не объясняет задержку до первого нового фрагмента: сначала системе приходится разобраться с пришедшим контекстом.

Кеш едет мимо маршрутизатора

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

Для обоих направлений авторы используют механизм NIXL READ. Покупателю не обязательно изучать его программный интерфейс, однако инфраструктурное следствие понятно: важен путь между рабочими узлами. Ускорение вычислений на одном из них не отвечает на вопрос, насколько выгодна передача данных соседу. Поэтому описание такой поставки должно включать межсоединение, а не ограничиваться перечнем ускорителей.

Перевезти готовое или посчитать заново?

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

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

Для команды важен второй запрос

В опыте vLLM для Qwen3-32B при входе 24K время до первого токена сократилось с 778 до 460 мс. Использовались отдельные prefill- и decode-узлы: два EC2 p5en.48xlarge по восемь H200 с сетью EFA; Qwen работал в bfloat16 с tensor parallel 8 на каждом узле. Prefix caching на prefill был выключен, чтобы имитировать потерю кеша. Рецепт воспроизведения использует vLLM 0.29.0, NIXL 1.4.1 и патч передачи метаданных в потоковых ответах. Поэтому это результат конкретной многошаговой нагрузки, а не обещание такого ускорения на одном сервере. Для собственного кластера значение имеют межсоединение, паузы между ходами и сохранность кеша.

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

Что проверить до выбора системы

  • Как маршрутизатор узнаёт, на каком узле остались нужные блоки?
  • Какой порог повторного вычисления выбран для рабочей нагрузки команды?
  • Как продолжится запрос, если нужного сохранённого блока нет?
  • Как изменится ожидание продолжения при одновременной работе нескольких сессий?

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