Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-сервис научили продолжать запросы при нехватке памяти GPU, не дожидаясь полного восстановления KV-кэша. В работе University of Melbourne и Maincode среднее время до первого токена под высокой нагрузкой сократилось примерно вчетверо относительно vLLM, хотя препринт не проходил рецензирование и числа получили сами авторы. Подход меняет роль точности кэша: рантайм может временно снижать её вместо остановки запросов.
Точная копия KV-кэша больше не блокирует запрос
KV-кэш хранит промежуточные состояния внимания для уже обработанных токенов. Он позволяет модели не пересчитывать весь контекст при генерации каждого следующего токена, но растёт вместе с контекстом и числом одновременных запросов.
Обычный рантайм считает запрос готовым к продолжению, только если его KV-кэш находится на GPU в настроенном формате. Когда памяти не хватает, запрос ждёт, прерывается или позже пересчитывает контекст. Поэтому небольшое увеличение нагрузки возле предела памяти может резко поднять задержку.
ElasticKV добавляет промежуточное состояние BASE. Обычный TARGET хранит KV в 16-битном виде, а BASE оставляет старшие 8 бит и занимает вдвое меньше места. Механизм внимания умеет читать оба состояния, поэтому модель продолжает генерацию с сокращённым кэшем, а затем восстанавливает исходное представление, когда память освобождается.
Это отличается от постоянного перевода всего кэша в пониженную точность. TARGET остаётся предпочтительным состоянием, а BASE включается для отдельных частей кэша только под давлением на память. Начальные и недавние токены сохраняются с полной точностью; сокращать можно среднюю часть контекста.
Освободившаяся половина блока возвращается рантайму
Сократить данные недостаточно: страничный распределитель vLLM выдаёт память целыми физическими блоками. Если внутри блока занята только половина, GPU всё равно не может использовать остаток для другого запроса.
ElasticKV объединяет два логических блока в пару. В состоянии TARGET пара занимает два физических блока. После перехода в BASE сокращённые представления помещаются в один блок, а второй целиком возвращается в свободный пул. Логическая разбивка не меняется, поэтому обычный путь выполнения продолжает работать с исходной схемой страниц.
Перед каждым выделением памяти контроллер проверяет, сколько блоков понадобится планировщику. При ожидаемом дефиците он заранее переводит подходящие пары в BASE. В первую очередь исключаются части кэша, которые защищает политика рантайма, и блоки без копии, пригодной для точного восстановления.
Обратный переход устроен осторожнее. Восстановление TARGET требует дополнительного блока, поэтому ElasticKV запускает его асинхронно и только при запасе памяти. BASE остаётся доступным для вычислений до завершения операции. Такой резерв не даёт системе сразу занять только что освобождённую память и попасть в цикл постоянного сокращения и восстановления кэша.
Изменения затрагивают сразу распределитель памяти, планировщик и ядра внимания. Это не отдельный алгоритм сжатия и не параметр конфигурации: для переноса идеи в другой серверный стек понадобятся аналогичные точки интеграции.
Планы стоит менять сервисам, которые упираются в границу памяти
Главный выигрыш проявился возле предельной нагрузки. Среднее время до первого токена оказалось в 3,8–4 раза ниже, чем у стандартного vLLM, а задержка, быстрее которой обслуживаются 90% запросов, — в 9,1 раза ниже. ElasticKV избегал прерываний запросов, из-за которых у базовых вариантов резко рос хвост задержки.
На воспроизведённой производственной трассе очередь ожидания сократилась в среднем на 36%. При этом дополнительная работа на критическом пути занимала 4,37 мс на шаг: сюда вошли контроль памяти, метаданные и синхронный переход в BASE. Восстановление TARGET выполнялось асинхронно и в эту величину не входило.
Качество проверяли на LongBench; при ограниченном использовании BASE оно в основном сохранилось. Это существенная деталь архитектуры: пониженная точность действует как кратковременный запас ёмкости, а не как постоянный режим для всех запросов.
Проверки охватили Llama-3.1-8B-Instruct и Qwen3-8B на NVIDIA A100, а также Llama-3.1-70B-Instruct на кластере AMD MI355X. Нагрузку создавали синтетические запросы, ShareGPT и трассы Mooncake; ElasticKV сравнивали с обычным хранением на GPU и точной выгрузкой кэша. Реализация построена поверх vLLM и использует собственные ядра Triton.
Для сервиса с достаточным запасом памяти подход почти ничего не меняет: все варианты показывали сопоставимую задержку. Пересматривать архитектуру имеет смысл там, где длинные контексты или всплески параллельности регулярно вызывают прерывания и пересчёт. Работа предлагает добавить между «точный кэш доступен» и «запрос остановлен» ещё одно исполняемое состояние — ценой усложнения рантайма и небольших постоянных накладных расходов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
