PegaFlow Внешний KV-кэш для vLLM

Запуск в 2,15 раза быстрее — это ключевая цифра из совместной статьи vLLM и Novita AI PegaFlow, но более глубокая идея — архитектурная: производственное LLM-обслуживание требует владения KV-кэшем вне одного процесса движка вывода. PegaFlow делает KV-кэш самостоятельным сервисом, чтобы развёртывания vLLM могли сохранять, разделять и масштабировать кэш при перезапусках, локальных экземплярах и удалённых узлах.

В этом посте даётся перспектива Novita AI: зачем мы создали PegaFlow, что показывает публичная интеграция с vLLM, какие утверждения уже подтверждены исходным кодом и как разработчики могут изучить open-source реализацию уже сегодня.

Изучите репозиторий PegaFlow на GitHub или прочитайте совместную статью vLLM x Novita AI для полного технического описания.

Какую проблему решает PegaFlow для vLLM-обслуживания?

PegaFlow решает проблему хрупкости локального для процесса KV-кэша в высокопроизводительном LLM-инференсе. Когда KV-кэш живёт только внутри одного процесса движка vLLM, полезное состояние кэша может исчезать при перезапусках, оставаться запертым внутри одного экземпляра или неэффективно перемещаться между узлами.

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

PegaFlow меняет эту границу. Он работает как внешний сервис KV-кэша, реализованный с ядром на Rust, и подключается к vLLM через механизм внешнего KV-коннектора, а не через долгоживущий форк.

Как PegaFlow интегрируется с vLLM?

PegaFlow интегрируется с vLLM через kv_transfer_config, PegaKVConnector и kv_connector_module_path. В опубликованной статье коннектор позволяет PegaFlow перехватывать ключевые операции с KV-кэшем во время выполнения, пока vLLM продолжает заниматься планированием, выполнением модели, пакетированием и путём обслуживания, совместимым с OpenAI.

Публичный репозиторий в настоящее время указывает vLLM как готовый в таблице интеграции фреймворков и показывает такую конфигурацию коннектора в быстром старте:

vllm serve Qwen/Qwen3-0.6B \
  --kv-transfer-config '{"kv_connector": "PegaKVConnector", "kv_role": "kv_both", "kv_connector_module_path": "pegaflow.connector"}'

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

Что добавляет архитектура Novita AI?

Цель дизайна Novita AI — сделать KV-кэш похожим на производственную инфраструктуру обслуживания, а не на временную память процесса. Это означает, что PegaFlow спроектирован вокруг независимой границы сервиса, пути данных на Rust, общих пулов кэша и многоуровневого хранения.

Выбор архитектуры	Почему это важно для разработчиков	Публичный источник
Независимый sidecar-сервис	KV-кэш может пережить перезапуски движка инференса и масштабироваться отдельно от процесса vLLM.	PegaFlow README
Ядро на Rust без GIL	Горячий путь кэша избегает накладных расходов Python и позволяет потокам движка инференса сосредоточиться на обслуживании.	PegaFlow README
Заблокированная память хоста, удалённая память RDMA и SSD-кэш	Кэш может охватывать более быструю локальную память, память удалённых узлов и ёмкость на SSD большего объёма.	Статья vLLM
Метрики Prometheus и экспорт OTLP	Операторы могут наблюдать поведение кэша, вместо того чтобы считать повторное использование KV скрытой деталью движка.	PegaFlow README

Последняя проверка: 2026-05-20. Эти детали взяты из совместной статьи vLLM и публичного README репозитория novitalabs/pegaflow.

Какие результаты производительности являются публичными?

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

Сценарий	Сообщённый результат	Источник
Запуск vLLM с предварительно заполненным хост-пулом KV объёмом 500 GiB	Запуск в 2,15 раза быстрее	Совместная статья vLLM
Восемь экземпляров Qwen3-8B, использующих один хост-кэш	Пропускная способность на 56% выше	Совместная статья vLLM
DeepSeek-V3.2 MLA с TP8	Пропускная способность на 72% выше	Совместная статья vLLM
Внутренний кластер RDMA: удалённые чтения	Средняя пропускная способность удалённого чтения 194 ГБ/с	Совместная статья vLLM
Эталонный тест H800, Llama-3.1-8B, тёплый vs холодный кэш	Среднее TTFT снижено с 572,5 мс до 61,5 мс; P99 TTFT снижено с 1113,7 мс до 77,0 мс	PegaFlow README

Последняя проверка: 2026-05-20. Показатель RDMA описан в исходной статье как результат внутреннего кластера, поэтому его следует рассматривать как данные оценки, а не как универсальное обещание пропускной способности.

Когда внешний KV-кэш наиболее полезен?

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

• Частые перезапуски: хранение кэша вне движка может уменьшить штрафы за перезапуск, когда состояние кэша остаётся полезным.
• Обслуживание с несколькими экземплярами: совместное использование хост-кэша может уменьшить дублирующую работу префилла между локальными экземплярами vLLM.
• Многоузловые развёртывания: удалённый кэш на базе RDMA может сделать полезные KV-блоки доступными за пределами одной машины.
• Разделение префилла и декода: внешний кэш может дать системе обслуживания более чёткую точку передачи между этапами.

Для Novita AI это часть более широкого инфраструктурного принципа: производственные AI-системы нуждаются в том, чтобы движок обслуживания, уровень памяти, уровень маршрутизации и уровень наблюдаемости эволюционировали независимо, когда шаблоны трафика становятся сложными.

Как разработчики могут изучить PegaFlow сегодня?

Разработчики могут изучить публичный репозиторий GitHub и установить опубликованные пакеты, на которые ссылается README. В репозитории документированы пакет для CUDA 12, пакет для CUDA 13, пример коннектора для vLLM, конфигурация сервера, настройка P2P RDMA, маршрутизация префилла/декода, метрики и цели проекта.

uv pip install pegaflow-llm        # CUDA 12
uv pip install pegaflow-llm-cu13   # CUDA 13

Самая простая команда локального сервера из README:

pegaflow-server

Для производственной оценки начните с собственного профиля повторного использования промптов, целевой модели, топологии GPU, объёма памяти и предположений об RDMA или SSD. PegaFlow — это инфраструктура для повторного использования кэша; рабочая нагрузка определяет, сколько ценности можно извлечь.

Что должны проверить команды платформы перед внедрением?

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

1. Измерьте повторное использование промптов и ожидаемый коэффициент попаданий в KV-кэш при реальной маршрутизации.
2. Сравните поведение при перезапуске с внешним KV-кэшем и без него.
3. Протестируйте совместное использование несколькими экземплярами на одном узле, прежде чем переходить к RDMA.
4. Проверьте наблюдаемость: попадания в кэш, промахи, задержка передачи, давление на память и поведение SSD.
5. Подтвердите совместимость версий с путём коннектора vLLM, используемым в вашем развёртывании.

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

Часто задаваемые вопросы

Что такое PegaFlow?

PegaFlow — это open-source движок хранения KV-кэша для LLM-инференса от Novita AI. Он работает как независимый сервис и подключается к vLLM через путь внешнего KV-коннектора.

Требует ли PegaFlow форка vLLM?

Нет. В опубликованной статье vLLM описывается подключение PegaFlow через kv_transfer_config и PegaKVConnector, при этом внешние пакеты загружаются через kv_connector_module_path.

Какие результаты производительности являются публичными?

Совместная статья vLLM сообщает о запуске в 2,15 раза быстрее, пропускной способности на 56% выше в конфигурации с общим хост-кэшем, пропускной способности на 72% выше для конфигурации DeepSeek-V3.2 MLA и средней пропускной способности удалённого чтения 194 ГБ/с во внутреннем кластере RDMA. README также сообщает о снижении TTFT на H800 для эталонного теста с тёплым кэшем.

Где разработчики могут попробовать PegaFlow?

Разработчики могут изучить публичный репозиторий novitalabs/pegaflow, установить pegaflow-llm для CUDA 12 или pegaflow-llm-cu13 для CUDA 13 и следовать быстрому старту из репозитория.

Заключение

PegaFlow — это работа Novita AI по внешнему KV-кэшу для производственного LLM-инференса с vLLM: самостоятельный сервис кэша, путь данных на Rust, общие пулы кэша и граница коннектора, которая избегает форка vLLM. Ключевой вывод прост: когда KV-кэш становится инфраструктурой, а не локальным состоянием процесса, команды обслуживания получают больше контроля над перезапусками, разделением, масштабированием и наблюдаемостью. Изучите репозиторий PegaFlow, сравните публичные результаты со своей рабочей нагрузкой и используйте более широкую инфраструктуру разработчика Novita AI, когда вам понадобятся API моделей, выполнение агентов или GPU-рабочие процессы вокруг этого стека обслуживания.

Рекомендуемые статьи

• Top Inference API Providers for Open-Source Models in 2026
• Qwen 3.5 Medium Series VRAM Requirements: 27B, 35B, 122B GPU Deployment Guide
• Can You Run Qwen3.5-397B-A17B Locally? GPU Guide 2026