Чат-боты работают в человеческом масштабе времени. Человек читает ответ, обдумывает его и печатает следующий запрос, что занимает от нескольких секунд до нескольких минут на один ход диалога. Агенты работают в компьютерном масштабе времени. Агент читает стопку документов, вызывает инструмент, читает результат и отправляет следующий запрос в течение нескольких секунд. Этот цикл повторяется десятки раз за задачу с тем, что со стороны выглядит как сверхчеловеческая скорость.

Человеческий масштаб времени простителен для сервера инференса; компьютерный — нет. Когда человеку требуется две минуты на ответ, двухсекундная пересборка кэша его беседы кажется незначительной. Для агента, работающего на том же сервере, каждая пересборка беседы может суммарно вылиться более чем в две минуты ожидания за задачу из 60 ходов. Чат-боты могли обходиться без надежной стратегии кэширования, потому что паузы людей скрывали стоимость пересборки. Агенты же, напротив, эти паузы убирают. Останутся ли ваши агенты быстрыми, зависит от того, можно ли будет повторно использовать эту работу, когда агент вернется.

Корпоративный сервер инференса должен обслуживать десятки или сотни таких бесед одновременно на одном узле. Память GPU не может вместить KV-кэш для всех них. Когда память заполнена, движок вытесняет кэши бесед, которые не используются активно, начиная с наименее используемых (LRU). Когда вытесненный агент возвращается, сервер должен пересобирать его кэш с нуля. При наличии нескольких агентов пересборки происходят редко, но при нескольких десятках они случаются почти на каждом ходу. В этот момент задержка перестает быть издержкой для одного запроса и распространяется на каждого агента на сервере.

Мы измерили это на одной конечной точке Gemma-4 26B, обслуживающей 40 агентов. Мы отслеживали время до первого токена (сколько времени требуется модели для начала ответа) при каждом возвращении:

Без уровня кэширования ниже памяти GPU возвращающиеся запросы начинали отвечать примерно через 0,1 секунды, пока активно работало примерно 22 агента.
В течение следующих 30 секунд это медианное значение подскочило до 17 секунд, а к концу теста выросло примерно до 45 секунд.
С решением Pure Key-Value Accelerator (KVA), удерживающим вытесненные кэши в памяти хоста и на хранилище NFS, медиана оставалась в диапазоне от 0,11 до 0,30 секунды для всех 40 агентов на том же самом оборудовании.
Для достижения задержки Pure KVA без второго уровня потребовалось бы примерно в 1,8 раза больше памяти GPU, что на практике означает почти вдвое больше графических процессоров.

Что Pure KVA делает с вытесненным кэшем

Pure KVA сохраняет вытесненные кэши вместо того, чтобы отбрасывать их. Это бэкенд KV-кэша для движков инференса, состоящий из плагина в движке, службы, работающей рядом с ним, и корпоративного хранилища под ними. Pure KVA уже доступен и управляет кэшем каждой беседы на трех уровнях:

GPU HBM (высокопропускная память на плате GPU) хранит беседы, которые движок обслуживает в данный момент. Ход, кэш которого все еще находится здесь, вообще не нуждается в пересборке. HBM также является самым маленьким и наиболее конкурентным уровнем.
Память хоста — это DRAM на том же сервере. Когда движок вытесняет беседу из HBM, Pure KVA сохраняет ее кэш здесь, в одном прыжке от GPU, для максимально быстрого восстановления.
Хранилище NFS вмещает гораздо больше, чем память любого отдельного сервера. Оно общее для всего пула, поэтому кэш, записанный на одном узле, может быть восстановлен на другом. Pure KVA также поддерживает объектное хранилище S3.

Вытеснение по-прежнему происходит при использовании Pure KVA. Память HBM имеет тот же размер, и движок по-прежнему освобождает место, вытесняя наименее используемые беседы. Меняется стоимость возвращения. Кэш возвращающегося агента считывается обратно из памяти хоста или хранилища, а не пересобирается на GPU. В наших тестах восстановление из NFS было до 32 раз быстрее пересборки и не добавляло никакой работы по пересборке в очередь GPU. Для восстановления по-прежнему требуется место в HBM, поэтому оно вытесняет другую беседу, но эта беседа также может вернуться с помощью чтения.

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

Мы хотели посмотреть, что происходит с единственным сервером инференса по мере того, как на него накапливаются агенты, поэтому мы создали нагрузочный тест, добавляющий их по одному. Мы обслуживали Gemma-4 26B с одной конечной точки и запускали нового агента каждые 15 секунд. Ни один агент не отключался после присоединения, поэтому к 10-й минуте все 40 агентов работали одновременно.

Каждый агент ведет себя так, как вел бы себя реальный агент. На своем первом ходу он загружает 10 документов, что дает ему начальный промпт объемом от 22 тыс. до 33 тыс. токенов. Модель отвечает, и агент ждет около 15 секунд перед отправкой следующего хода. Эта пауза имитирует вызовы инструментов и другую работу, которую агент выполняет между ходами. Агент никогда не отправляет новый ход до тех пор, пока не придет предыдущий ответ, и каждый новый ход отправляет всю беседу целиком на данный момент.

Мы выполнили этот точный план дважды. В первом запуске использовался vLLM с Pure KVA, а во втором — тот же движок без него, который мы называем «No KVA» на графиках ниже. В обоих запусках использовалось одно и то же начальное значение генератора случайных чисел (seed), поэтому агенты появлялись в одни и те же моменты времени, загружали одни и те же документы и делали паузы одинаковой продолжительности. Каждый запуск длился 750 секунд (12,5 минут), а в Приложении А ниже приведены полные правила, если вы захотите воспроизвести тест.

Метрика, которую мы отслеживали, — это время до первого токена при возвращающихся ходах, то есть сколько времени агент ждет, пока модель начнет отвечать при своем возвращении. Первые ходы здесь мало о чем говорят. Ни у одной конечной точки нет кэша для повторного использования на первом ходу агента, поэтому обе вычисляют его с нуля, с медианой в 2,1 секунды с Pure KVA и 2,3 секунды без него. Две конечные точки начинают различаться только тогда, когда агенты возвращаются. На рисунке 1 ниже показан результат в виде скользящей медианы, то есть медианы времени ожидания по скользящему окну последних возвращающихся ходов.

Рисунок 1: Скользящая медиана времени до первого токена для возвращающихся ходов, Pure KVA против No KVA, за период 750-секундного запуска.

Первые пять с половиной минут различить две версии невозможно. Обе отвечают возвращающимся агентам примерно за 0,1 секунды. Каждая активная беседа все еще помещается в HBM, поэтому ничего не нужно пересобирать, и Pure KVA ничего не добавляет в цепочку обработки, поскольку ее первый уровень — это та же самая HBM.

Затем, драматическим образом, задержка для агентов, не использующих Pure KVA, возрастает на два порядка. На отметке 5,6 минуты, при работающих примерно 22 агентах, конфигурация No KVA ответила на свой последний возвращающийся ход менее чем за полсекунды. Тридцать секунд спустя медианное время ожидания составило 17 секунд, что превышает 15-секундную паузу, которую агенты делают между ходами. Другими словами, теперь агенты тратили больше времени на ожидание сервера, чем на выполнение собственной работы. Ожидание продолжало расти: до 31 секунды на восьмой минуте и примерно до 45 секунд к концу, и оно так никогда и не снизилось.

Pure KVA держался на стабильном уровне на протяжении всего процесса. Как только первые несколько агентов завершили свои первые ходы, медианное время ожидания оставалось в диапазоне от 0.11 до 0.30 секунды до конца теста. Единственный скачок до 0.30 секунды произошел на 10-й минуте, когда прибыли последние агенты и вычислили свои первые ходы. Медиана вернулась к 0.12 секунды в течение минуты. Самый медленный ход за весь тест Pure KVA занял 4.6 секунды, и это был один из тех самых первых ходов.

Справедливый вопрос заключается в том, замедлились ли агенты без KVA из-за того, что их промпты увеличивались по ходу теста. Они практически не увеличивались. Все входные данные оставались в диапазоне от 21.8K до 34.1K токенов от начала и до конца, поэтому отвечать ни на один из запросов не стало сложнее. Скачок был вызван исключительно тем, что в HBM закончилось свободное место. Как только HBM заполнился, каждому возвращающемуся агенту потребовалось пересоздание, и пересоздания накапливались быстрее, чем GPU успевал их обрабатывать.

Во что вытеснение обходится агентам, GPU и командам, которые от них зависят

Скачок на Рисунке 1 проявляется в трех аспектах: сколько времени каждый агент ждет, сколько полезной работы выполняет GPU и сколько времени требуется на завершение работы, построенной поверх агентов.

Начнем с самих агентов. Самая сложная часть этого скачка заключается в том, насколько внезапно он происходит. Без KVA система работала со скоростью около 0.1 секунды в течение пяти с половиной минут без каких-либо признаков проблем, а затем преодолела отметку в 17 секунд менее чем за полминуты. Плавное замедление дает время заметить проблему и добавить мощности, а внезапное — нет. Это также означает, что пилотный запуск может ввести вас в заблуждение. Развертывание, которое выглядит идеальным с 15 агентами, при 40 агентах может работать более чем в 100 раз медленнее.

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

Масштаб этого эффекта можно увидеть с помощью простых вычислений на основе измеренных нами медиан. Агент, который делает паузу в 15 секунд и ждет ответа 0.1 секунды, выполняет около четырех ходов в минуту. Тот же агент, ожидающий 45 секунд, выполняет около одного. Тот же агент, тот же GPU, но только четверть от объема вывода.

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

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

Почему HBM переполняется, а пересоздания накапливаются

Задержка системы без KVA возросла по двум причинам. Разговоры агентов настолько велики, что всего несколько десятков из них забивают память GPU, а пересоздание вытесненного разговора обходится гораздо дороже, чем его чтение обратно. Сложите эти два факта вместе на загруженном сервере, и каждое замедление вызовет лавинообразный эффект для последующих.

Начнем с размера. Когда модель читает промпт (этот этап называется префилом), она вычисляет ключ и значение для каждого токена на каждом слое, и эти ключи и значения образуют KV-кэш. Размер кэша зависит от архитектуры модели и длины разговора:

KV байты = 2 × слои × kv_heads × head_dim × токены × байты_dtype

Чтобы дать представление о масштабе, модель с 32 млрд параметров, 64 слоями, 8 KV-головами и размерностью головы 128, сохраненная в формате fp8, требует около 131 КБ на токен. Один разговор на 28K токенов (примерно размер промптов наших агентов) составляет около 3.7 ГБ, а 40 таких разговоров требуют около 150 ГБ. Веса модели занимают фиксированный объем HBM независимо от того, сколько разговоров выполняется, и кэш каждого разговора должен помещаться в оставшееся пространство. У GPU достаточно вычислительной мощности, чтобы обслуживать гораздо больше агентов, чем может одновременно вместить его память, поэтому движок выполняет вытеснение.

Рисунок 2: Как усугубляется вытеснение, упрощенно для HBM с местом для двух разговоров. Слева: Без уровня ниже HBM кэш возвращающегося агента пересоздается с полным префилом, а освобождение места для него вытесняет другого агента. Справа: С Pure KVA вытесненный кэш перемещается в память хоста или NFS, и возвращающийся агент восстанавливает его посредством чтения, а не пересоздания.

Далее — стоимость. Пересоздание вытесненного разговора означает повторный запуск префила для всего разговора. Время префила определяется механизмом внимания (attention), который растет как O(n²) с длиной контекста n, поэтому удвоение длины разговора примерно в четыре раза увеличивает объем работы механизма внимания. Чтение сохраненного кэша растет как O(n) в соответствии с количеством байтов. Разрыв между ними неизбежно увеличивается по мере роста разговоров.

Мы измерили, насколько велик этот разрыв. На в остальном простаивающем сервере мы взяли 40 промптов размером от 5.5K до 118K токенов и запустили каждый дважды: один раз с нуля, а второй раз после удаления его кэша и предоставления Pure KVA возможности восстановить его из NFS. При тех длинах контекста, которые используют наши агенты, восстановление было примерно в 10 раз быстрее пересоздания. При 118K токенах оно оказалось быстрее в 32 раза.

Рисунок 3: Время до первого токена для одного и того же промпта на Gemma-4 26B: пересоздание с нуля против восстановления из NFS на выборке из 40 промптов.

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

Как только HBM заполняется, пересозданному кэшу требуется место, поэтому движок вытесняет другой разговор, чтобы освободить его. Этому агенту теперь требуется пересоздание по возвращении, что приводит к вытеснению третьего. Между тем каждое пересоздание занимает GPU, поэтому агенты, стоящие за ним, ждут в очереди. Как только пересоздания начинают поступать быстрее, чем GPU успевает их завершать, очередь растет с каждым ходом вместо того, чтобы уменьшаться, именно поэтому текст без KVA так и не восстановился. С Pure KVA вытесненный агент возвращается посредством чтения, а не пересоздания, поэтому цепочка останавливается после первого шага и очередь никогда не формируется.

Планируйте вытеснение до того, как ваши агенты перерастут HBM

Обычно KV-кэширование применяется для увеличения скорости. Тесты, которые мы провели, демонстрируют нечто более полезное для всех, кто запускает агентов локально (on-prem). При наличии уровня кэширования ниже HBM стоимость возвращающегося разговора больше не зависит от того, насколько заполнен GPU. Без такого уровня следующий ход агента будет быстрым только в том случае, если в HBM случайно оказалось место для его разговора, пока агента не было. Как только в HBM заканчивается свободное место, агент вынужден ждать завершения префила, прежде чем выполнять какую-либо полезную работу. С Pure KVA ваши агенты могут сосредоточиться на выполнении работы вместо того, чтобы стоять в очереди.

Именно эта предсказуемость облегчает планирование локального развертывания. Без уровня кэширования ниже HBM у вас есть два варианта. Вы можете рассчитать размер развертывания так, чтобы количество ваших агентов никогда не превышало точку переполнения HBM (в нашем тесте это было около 22 агентов). Или вы можете смириться с тем, что время ожидания после этого увеличится более чем в 100 раз.

Обслуживание 40 наших агентов с задержкой, достигаемой с помощью Pure KVA, без внешнего уровня кэширования потребовало бы столько HBM, чтобы вместить все разговоры одновременно. Это примерно в 1,8 раза больше HBM в нашем тестовом сервере, что на практике означает почти вдвое большее количество GPU. Pure KVA позволила преодолеть порог в 40 агентов на том же оборудовании. Учитывая дефицит GPU и соответствующие цены, этот запас производительности является практическим преимуществом. Pure KVA позволяет делать больше с помощью той же инфраструктуры.

Pure KVA обеспечила двукратное увеличение параллелизма, избавив от необходимости дополнительного выделения ресурсов.

Время планировать вытеснение — это этап проектирования развертывания, а не момент, когда ваши агенты выстраиваются в очередь и рабочие нагрузки останавливаются. Pure KVA уже доступна. В Приложении А ниже подробно описаны оба теста.

Приложение А: Методология тестирования

Оба теста выполнялись на Gemma-4 26B с использованием Pure KVA 1.2 поверх NFSv4.1. Тест с агентами воспроизводит идентичный план для обоих эндпоинтов, по одному запуску для каждого, с одинаковым сидом, графиком поступления, документами и временем на размышления (think-time).

А.1 Классический прогон производительности

Детерминированная лестница из 40 промптов размером от 5,5 тыс. до 118 тыс. входных токенов создается путем добавления документов из фиксированного корпуса. Каждый промпт запускается один раз на в остальном простаивающем сервере через NFSv4.1 с использованием nconnect. Для каждого промпта:

Холодный префилл: отправка промпта без какого-либо кэширования и запись времени до первого токена.
Сброс: вытеснение KV-кэша промпта из HBM.
Восстановление: повторная отправка того же промпта, в то время как Pure KVA восстанавливает его KV-кэш из NFS.

А.2 Комплекс агентской нагрузки

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

Рисунок 4: Слева: Промпт, отправляемый агентом на каждом ходу. Справа: Жизненный цикл агентов во времени. Ход 1 загружает 10 документов агента и требует префилла с нуля. Каждый последующий ход повторно отправляет весь разговор вместе с предыдущим ответом размером 64 токена и новым вопросом — от 37 до 94 дополнительных токенов, медиана ≈ 55. Агенты присоединяются по одному каждые 15,4 секунды, пока все 40 не окажутся активными на отметке 10:00 минут; комплекс прекращает планирование на отметке 12:30 минут.

Модель: Gemma-4 26B
Поступления: 40 агентов, по одному каждые 15 секунд (40 волн за 600 секунд)
Документы: 10 различных документов на агента, загружаются на 1-м ходу, выбираются в количестве 400 документов из корпуса в 6 119 документов
Промпт 1-го хода: от 21,8 тыс. до 32,8 тыс. токенов, медиана 27,6 тыс.
Последующие ходы: полная история, предыдущий ответ и новый вопрос, добавляющие от 37 до 94 токенов за ход
Вывод: 64 токена за ход
Время на размышления: выбирается для каждого хода из нормального распределения со средним значением 15 секунд и разбросом 10 секунд с нижним пределом 0 (наблюдаемое среднее 14,7 секунды, медиана 14,3 секунды)
Цикл: замкнутый, поэтому следующий ход планируется только после получения предыдущего ответа
Ходов на агента: 60 запланированных, 2 400 всего
Клиентские воркеры: 50, что больше количества агентов, поэтому ни один запрос никогда не ждет в комплексе
Правило остановки: ограничение в 750 секунд, текущие ходы завершаются, повторный запуск не производится
Сид: 51909, который фиксирует поступления, наборы документов и выборку времени на размышления
Эндпоинты: Pure KVA — это vLLM с Pure KVA 1.2, уровнем хост-памяти 32 ГБ и хранилищем NFSv4.1. Без KVA — это vLLM только с HBM.
Запуски: один запуск на эндпоинт, выполняемый отдельно по одному и тому же плану
Записывается для каждого хода: время отправки, ожидание в очереди, время до первого токена (TTFT), общее время, входные и выходные токены, запросы в обработке
Телеметрия каждые 3 секунды: коэффициент попаданий в префикс-кэш vLLM и использование KV, байты хост-памяти Pure KVA и записи в хранилище