vLLM научил decode-узлы возвращать KV-кэш и ускорил TTFT до 3,3 раза

Команда vLLM добавила в разнесённый инференс двунаправленную передачу KV-кэша. Prefill-узлы теперь могут забирать у decode-узлов уже посчитанный кэш предыдущих реплик диалога и не пересчитывать весь контекст на каждом ходе. На длинных многоходовых промптах время до первого токена (TTFT) снижается до 3,3 раза.

Где терялось время

В схеме disaggregated serving фазы prefill и decode работают на разных пулах GPU. Prefill обрабатывает промпт и строит KV-кэш, затем отдаёт его decode-узлу, а тот генерирует ответ токен за токеном. Разделение понятно: prefill упирается в вычисления, decode в память и пропускную способность, и каждый пул можно настраивать под свою нагрузку.

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

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

Как работает обратный канал

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

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

Ключевые цифры из анонса:

• ускорение TTFT: до 3,3x;
• сценарий: длинные многоходовые промпты;
• что экономится: повторный prefill-компьют по уже обработанной истории;
• направление передачи: decode → prefill в дополнение к prefill → decode;
• платформа: vLLM в конфигурации с разнесёнными prefill- и decode-узлами.

Значение 3,3x обозначено как верхняя граница. Это лучший случай на длинных диалогах, а не гарантированный средний результат. В короткой переписке с небольшим префиксом разница будет заметно скромнее.

Что остаётся за кадром

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

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

Кому это пригодится на практике

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

Перед внедрением стоит проверить на собственном трафике:

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

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