PegaFlow Cache KV Externo para vLLM

Inicialização 2,15x mais rápida é o número principal do artigo conjunto da vLLM e Novita AI PegaFlow, mas o ponto mais profundo é arquitetural: o serving de LLM em produção precisa da propriedade do cache KV fora de um único processo do motor de inferência. O PegaFlow torna o cache KV um serviço independente, para que implantações vLLM possam preservar, compartilhar e escalar o cache entre reinicializações, instâncias locais e nós remotos.

Esta postagem oferece a perspectiva da Novita AI sobre por que construímos o PegaFlow, o que a integração pública com vLLM mostra, quais afirmações já têm suporte no código-fonte e como os desenvolvedores podem inspecionar a implementação open-source hoje.

Explore o repositório PegaFlow no GitHub ou leia o artigo conjunto vLLM x Novita AI para a explicação técnica completa.

Que problema o PegaFlow resolve para serving vLLM?

O PegaFlow aborda a fragilidade do cache KV local ao processo na inferência LLM de alta taxa de transferência. Quando o cache KV vive apenas dentro de um processo do motor vLLM, estados úteis de cache podem desaparecer durante reinicializações, ficar presos dentro de uma instância ou não conseguir se mover eficientemente entre nós.

Isso se torna caro quando as cargas de trabalho reutilizam prompts longos, roteiam requisições semelhantes entre réplicas ou separam o trabalho de prefill e decode. O cache pode já conter trabalho que o sistema não deveria recomputar, mas a topologia de serving nem sempre consegue reutilizá-lo.

O PegaFlow muda esse limite. Ele é executado como um serviço externo de cache KV, implementado com um núcleo Rust, e se conecta ao vLLM através do mecanismo de conector KV externo, em vez de um fork de longa duração.

Como o PegaFlow se integra com o vLLM?

O PegaFlow se integra com o vLLM através de kv_transfer_config, PegaKVConnector e kv_connector_module_path. No artigo publicado, o conector permite que o PegaFlow assuma operações-chave de cache KV em tempo de execução, enquanto o vLLM continua a lidar com escalonamento, execução de modelos, loteamento e o caminho de serving compatível com OpenAI.

O repositório público atualmente lista o vLLM como pronto em sua tabela de integração de frameworks e mostra esta configuração de conector no início rápido:

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

O benefício prático é um modelo de propriedade mais limpo: o vLLM permanece como o motor de serving, enquanto o PegaFlow detém o armazenamento, transferência, compartilhamento e observabilidade relacionados ao cache KV externo.

O que a arquitetura da Novita AI adiciona?

O objetivo de design da Novita AI é fazer com que o cache KV se comporte como infraestrutura de serving de produção, não como memória temporária de processo. Isso significa que o PegaFlow é projetado em torno de um limite de serviço independente, um caminho de dados em Rust, pools de cache compartilhados e armazenamento em múltiplas camadas.

Escolha arquitetural	Por que é importante para desenvolvedores	Fonte pública
Serviço sidecar independente	O cache KV pode sobreviver a reinicializações do motor de inferência e escalar separadamente do processo vLLM.	README do PegaFlow
Núcleo Rust sem GIL	O caminho do cache evita a sobrecarga do Python e mantém os threads do motor de inferência focados no serving.	README do PegaFlow
Memória host fixada, memória remota RDMA e cache SSD	O cache pode abranger memória local mais rápida, memória remota de nós e capacidade maior baseada em SSD.	Artigo vLLM
Métricas Prometheus e exportação OTLP	Operadores podem observar o comportamento do cache, em vez de tratar a reutilização KV como um detalhe oculto do motor.	README do PegaFlow

Última verificação: 2026-05-20. Esses detalhes vêm do artigo conjunto vLLM e do README público de novitalabs/pegaflow.

Quais resultados de desempenho são públicos?

As afirmações públicas de desempenho devem ser lidas como resultados de avaliação do PegaFlow do artigo conjunto vLLM e do benchmark do repositório, não como garantias genéricas para toda carga de trabalho. Taxa de acerto do cache, reutilização de prompts, formato do modelo, hardware, topologia de rede e roteamento de requisições afetam implantações reais.

Cenário	Resultado relatado	Fonte
Inicialização vLLM com pool KV host pré-alocado de 500 GiB	Inicialização 2,15x mais rápida	Artigo conjunto vLLM
Oito instâncias Qwen3-8B compartilhando um cache host	56% maior taxa de transferência	Artigo conjunto vLLM
DeepSeek-V3.2 MLA com TP8	72% maior taxa de transferência	Artigo conjunto vLLM
Leituras remotas em cluster RDMA interno	194 GB/s de taxa de transferência média de leitura remota	Artigo conjunto vLLM
Benchmark de referência H800, Llama-3.1-8B, cache quente vs. frio	TTFT médio reduzido de 572,5 ms para 61,5 ms; P99 TTFT reduzido de 1113,7 ms para 77,0 ms	README do PegaFlow

Última verificação: 2026-05-20. O número de RDMA é descrito na fonte como um resultado de cluster interno, portanto deve ser enquadrado como dado de avaliação relatado, não como uma promessa universal de taxa de transferência.

Quando o cache KV externo é mais útil?

O cache KV externo é mais útil quando a reutilização de prompts é alta o suficiente para que a recomputação se torne visível na latência, taxa de transferência ou utilização da GPU. É menos útil para cargas de trabalho onde quase toda requisição é única e a reutilização do cache é naturalmente baixa.

• Reinicializações frequentes: manter o cache fora do motor pode reduzir penalidades de reinicialização quando o estado do cache permanece útil.
• Serving multi-instância: compartilhar o cache host pode reduzir trabalho de prefill duplicado entre instâncias vLLM locais.
• Implantações multinó: cache remoto com RDMA pode disponibilizar blocos KV úteis além de uma única máquina.
• Desagregação prefill/decode: o cache externo pode dar ao sistema de serving um ponto de handoff mais claro entre estágios.

Para a Novita AI, isso faz parte de um princípio de infraestrutura mais amplo: sistemas de IA em produção precisam que o motor de serving, a camada de memória, a camada de roteamento e a camada de observabilidade evoluam de forma independente quando os padrões de tráfego se tornam complexos.

Como os desenvolvedores podem inspecionar o PegaFlow hoje?

Os desenvolvedores podem inspecionar o repositório público no GitHub e instalar os pacotes publicados referenciados pelo README. O repositório documenta um pacote CUDA 12, um pacote CUDA 13, um exemplo de conector vLLM, configuração de servidor, configuração RDMA P2P, roteamento prefill/decode, métricas e objetivos do projeto.

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

O comando de servidor local mais simples no README é:

pegaflow-server

Para avaliação em produção, comece com seu próprio perfil de reutilização de prompts, modelo alvo, topologia de GPU, capacidade de memória e suposições de RDMA ou SSD. O PegaFlow é infraestrutura para reutilização de cache; a carga de trabalho determina quanto valor há para capturar.

O que as equipes de plataforma devem verificar antes de adotá-lo?

As equipes de plataforma devem validar o PegaFlow contra sua própria topologia de serving antes de tratar números de benchmark públicos como entradas de planejamento. O teste correto não é apenas cache frio versus quente, mas se a reutilização do cache aparece no padrão de tráfego que realmente impulsiona custo ou latência.

1. Meça a reutilização de prompts e a taxa esperada de acerto do cache KV sob roteamento real.
2. Compare o comportamento de reinicialização com e sem cache KV de propriedade externa.
3. Teste o compartilhamento multi-instância em um único nó antes de expandir para RDMA.
4. Verifique a observabilidade: acertos de cache, erros, latência de transferência, pressão de memória e comportamento SSD.
5. Confirme a compatibilidade de versão com o caminho do conector vLLM usado em sua implantação.

Esta é também a razão pela qual o limite open-source é importante. Os desenvolvedores podem inspecionar o conector, a configuração do servidor, as métricas e a configuração do benchmark, em vez de depender de um serviço de cache em caixa-preta.

FAQ

O que é o PegaFlow?

O PegaFlow é um motor de armazenamento de cache KV open-source para inferência LLM da Novita AI. Ele é executado como um serviço independente e se conecta ao vLLM através do caminho do conector KV externo.

O PegaFlow requer um fork do vLLM?

Não. O artigo vLLM publicado descreve o PegaFlow conectando-se através de kv_transfer_config e PegaKVConnector, com pacotes externos carregados através de kv_connector_module_path.

Quais resultados de desempenho são públicos?

O artigo conjunto vLLM relata inicialização 2,15x mais rápida, taxa de transferência 56% maior em uma configuração de cache host compartilhado, taxa de transferência 72% maior para uma configuração DeepSeek-V3.2 MLA e 194 GB/s de taxa de transferência média de leitura remota em um cluster RDMA interno. O README também relata reduções de TTFT em H800 para um benchmark de referência com cache quente.

Onde os desenvolvedores podem experimentar o PegaFlow?

Os desenvolvedores podem revisar o repositório público novitalabs/pegaflow, instalar pegaflow-llm para CUDA 12 ou pegaflow-llm-cu13 para CUDA 13, e seguir o início rápido do repositório.

Conclusão

O PegaFlow é o trabalho da Novita AI em cache KV externo para inferência LLM de produção com vLLM: um serviço de cache independente, um caminho de dados em Rust, pools de cache compartilhados e um limite de conector que evita um fork do vLLM. A conclusão principal é simples: quando o cache KV se torna infraestrutura em vez de estado local ao processo, as equipes de serving ganham mais controle sobre reinicializações, compartilhamento, escalabilidade e observabilidade. Revise o repositório PegaFlow, compare os resultados públicos com sua própria carga de trabalho e use a infraestrutura de desenvolvedor mais ampla da Novita AI quando precisar de APIs de modelo, execução de agentes ou fluxos de trabalho GPU em torno dessa stack de serving.

Artigos recomendados

• Principais Provedores de API de Inferência para Modelos Open-Source em 2026
• Série Qwen 3.5 Medium: Requisitos de VRAM para 27B, 35B, 122B - Guia de Implantação GPU
• Você Consegue Executar Qwen3.5-397B-A17B Localmente? Guia GPU 2026