Perplexity lança TransferEngine e pplx garden para você rodar modelos de linguagem com trilhões de parâmetros no seu cluster de GPUs sem trocar hardware

Ouça este artigo

Você quer rodar modelos de linguagem com parâmetros gigantes em clusters de GPUs mistos sem comprar hardware novo ou ficar preso a um único provedor. O time de pesquisa da Perplexity lançou TransferEngine e o pplx garden como infraestrutura open source para isso. A ideia é uma camada RDMA portátil que assume redes confiáveis sem exigir ordem rígida. Ela oferece operações de escrita unilateral e sinais de completude, uma API enxuta em Rust e extensão em Python. O foco é alto desempenho, streaming de KvCache, troca direta de pesos ponto a ponto e suporte a kernels de Mixture of Experts. Se você cuida da sua infra de LLMs, este artigo mostra como essa ferramenta pode escalar modelos enormes de forma prática e sem travas de fornecedor.

• Permite rodar modelos com trilhões de parâmetros em clusters mistos

• Evita ficar preso a um único fornecedor de nuvem ou hardware

• Mantém alta largura de banda em diferentes redes sem perder desempenho

• Suporta streaming de KvCache e transferência direta de pesos entre GPUs

• Código aberto pronto para uso em produção para modelos MoE

TransferEngine e pplx garden: como você pode rodar modelos de 1 trilhão de parâmetros em clusters GPU mistos

Você agora pode usar um novo conjunto de ferramentas open source para executar modelos de linguagem gigantes sem trocar todo o seu hardware ou ficar preso a um único provedor. A equipe de pesquisa da Perplexity liberou TransferEngine e o repositório pplx garden sob licença MIT, oferecendo um caminho para servir modelos de até 1 trilhão de parâmetros em clusters com GPUs e interfaces de rede heterogêneas — veja o anúncio da Perplexity sobre TransferEngine e pplx garden para uma visão resumida do lançamento: anúncio da Perplexity sobre TransferEngine e pplx garden.

Principais pontos — o que você precisa saber primeiro

• TransferEngine permite operar modelos gigantes em clusters mistos sem exigir hardware GB200 novo.

• A solução atinge picos reportados de 400 Gbps em placas ConnectX‑7 e em agregações de AWS EFA, segundo a equipe.

• Código disponível no GitHub como parte do pplx garden (MIT).

• Casos de uso práticos: streaming de KvCache para inferência desagregada, transferência de pesos ponto a ponto para ajuste fino assíncrono e kernels MoE ponto a ponto (veja como o streaming de KvCache pode acelerar respostas iniciais).

Por que isso muda o jogo

Modelos MoE modernos (por exemplo com 671B ou 1T de parâmetros) não cabem mais em um único servidor de 8 GPUs; o gargalo é a rede entre GPUs. O mercado de interconexão é fragmentado: diferentes NICs e transportes oferecem garantias distintas de ordenação e confiabilidade. Segundo a equipe, antes não havia uma solução portátil viável entre provedores para inferência de LLMs em escala.

Como o TransferEngine funciona

A abordagem foca na interseção das garantias oferecidas por várias interfaces RDMA. Parte do pressuposto de que o transporte é confiável, mas não exige ordenamento. A camada expõe primitivas para escritas one‑sided com notificação de conclusão.

Principais primitivas (API em Rust):

• Send / Recv — mensagens de controle duas‑lados.

• submitsinglewrite — escrita one‑sided simples.

• submitpagedwrites — escrita paginada para KvCache.

• submit_scatter — escrita scatter para sincronização.

• submit_barrier — barreira entre pares.

• WriteImm e ImmCounter — para notificação de conclusão.

• allocuvmwatcher — observa progresso CPU/GPU em pipelines avançados.

Internamente, cada GPU tem um thread trabalhador. O sistema constrói um DomainGroup por GPU que coordena entre 1 a 4 NICs RDMA. A lógica de sharding conhece cada NIC e pode dividir uma transferência para aproveitar múltiplos enlaces, permitindo alcançar picos de 400 Gbps em diferentes backends.

Comparação de interconexões

Hardware | Transporte típico | Como atinge 400 Gbps

• — | —: | —

NVIDIA ConnectX‑7 | Transporte com entrega ordenada | Single NIC de 400 Gbps
AWS EFA | Transporte confiável, fora de ordem | Agregação (ex.: 4×100 Gbps ou 2×200 Gbps)

Repositório e requisitos

O código está no repositório pplx garden. Estrutura principal:

• fabric‑lib — biblioteca RDMA TransferEngine.

• p2p‑all‑to‑all — kernel MoE all‑to‑all.

• python‑ext — extensão Python do núcleo em Rust.

• python/pplx_garden — pacote Python.

Requisitos mínimos recomendados:

• Linux kernel 5.12 (DMA BUF).

• CUDA 12.8.

• libfabric, libibverbs, GDRCopy.

• GPUDirect RDMA habilitado no tecido RDMA.

• Cada GPU com ao menos uma NIC RDMA dedicada.

Para clonar e acompanhar o projeto e exemplos práticos, confira o anúncio técnico e a cobertura inicial em anúncio e guia da Perplexity.

Casos de uso em produção — como isso ajuda sua equipe

Desagregação de inferência

• Você pode pré‑preencher (prefill) e decodificar em clusters distintos.

• O TransferEngine faz streaming da KvCache camada a camada com o allocuvmwatcher, evitando coletores estritos e permitindo escrita paginada por camada — mecanismo próximo ao discutido em como compartilhar KvCache entre GPUs.

Ajuste fino assíncrono por reforço (RL)

• Em vez de reunir parâmetros em um único rank e retransmitir, cada GPU de treino escreve sua fatia de peso diretamente nos GPUs de inferência.

• Processo pipelineado: estágio por estágio do tensor — cópia host→device, reconstrução/quantização opcional, transferência RDMA e barreira via scatter ImmCounter. Para estratégias de quantização e otimização ponta a ponta veja práticas consolidadas com ferramentas como Hugging Face e ONNX Runtime: otimização e quantização ponta a ponta.

• Em produção, transferências de modelos como Kimi K2 (1T) e DeepSeek V3 (671B) foram reportadas em cerca de 1,3 segundos de 256 GPUs de treino para 128 GPUs de inferência.

Kernel MoE ponto a ponto (dispatch/combine)

• Usa NVLink dentro do nó e RDMA entre nós.

• Envia rotas, calcula offsets contíguos, escreve tokens em buffers privados reutilizáveis e sobrepõe comunicação com cálculo para manter throughput. Para pipelines de treinamento que evitam paradas e mantêm throughput contínuo, há abordagens complementares como a extensão do DeepSpeed que reduz pausas em estágios pipeline: ZenFlow, extensão do DeepSpeed.

Resultados e impacto

• Throughput de pico consistente reportado em 400 Gbps tanto em ConnectX‑7 quanto em EFA, indicando que a abstração não sacrifica desempenho substancial.

• Decodificação MoE: desempenho competitivo em ConnectX‑7 e latências práticas viáveis em EFA.

• Redução da necessidade de atualizações dispendiosas de fabric e menor dependência de um único fornecedor de rede — uma vantagem na hora de comparar com outras estratégias de escala, como as apresentadas por projetos de escalonamento de modelos tipo DeepSpeed: escala de modelos com menos memória (DeepSpeed).

Conclusão

Você agora tem uma ponte prática para rodar LLMs gigantes sem precisar trocar todo o hardware ou ficar refém de um único provedor. O TransferEngine e o pplx garden entregam uma camada RDMA portátil que aposta em operações one‑sided, notificações de completude e streaming de KvCache — tudo pensado para manter o desempenho e reduzir o vendor lock‑in.

Na prática isso significa atingir picos reais de 400 Gbps, fazer transferência direta de pesos entre GPUs e suportar kernels MoE ponto a ponto. Se você cuida da infraestrutura de LLMs, espere ganhos palpáveis: escala para modelos de 1 trilhão de parâmetros, menos atualização cara de fabric e fluxos de trabalho (prefill → decode, ajuste fino assíncrono) mais eficientes. Para acompanhar a publicação original, o repositório e a cobertura técnica inicial, veja também o guia e cobertura sobre o lançamento.

Perguntas Frequentes

Q: O que é o TransferEngine e o pplx garden?
A: TransferEngine é a biblioteca RDMA em Rust; pplx garden é o toolkit ao redor. Tudo open source (MIT) para LLMs trilionários em clusters mistos.

Q: Como isso permite rodar modelos com trilhões de parâmetros sem trocar hardware?
A: Usa operações one‑sided, ImmCounter e agrega múltiplas NICs por GPU para dividir tráfego, alcançando alta largura de banda sem depender de um só fornecedor.

Q: Quais os requisitos mínimos de hardware e software?
A: Linux 5.12, CUDA 12.8, libfabric/libibverbs, GDRCopy e GPUDirect RDMA. Cada GPU precisa de pelo menos 1 NIC RDMA dedicada (ex.: ConnectX‑7 400G; EFA via agregação).

Q: Como funciona o streaming de KvCache entre prefill e decode?
A: O allocuvmwatcher acompanha progresso por camada; o sistema envia páginas do KvCache por layer com submitpagedwrites e um write final, permitindo streaming sem collectives rígidos.

Q: Que ganhos reais posso esperar em produção?
A: Throughput de 400 Gbps em backends suportados, transferência de peso de ~1,3 s em cenários reportados (256 train → 128 infer) e latências de MoE competitivas em ConnectX‑7 e viáveis em EFA.

Quer acompanhar o código e os benchmarks? Consulte o repositório pplx garden e a cobertura técnica inicial em anúncio e guia da Perplexity.