Perplexity revela a pilha de GPUs por trás do pplx-embed: Ivy, Tulip e ROSE

Por dentro da engenharia que serve embeddings na Perplexity

A qualidade de busca em um produto de IA depende de duas coisas: quão boa é a modelo de embeddings e quão barato é rodá-la sobre um índice gigante. A Perplexity decidiu abrir a segunda parte. Em um post de engenharia publicado esta semana, a equipe detalhou a infraestrutura por trás do pplx-embed e dos modelos de ranqueamento usados na Busca, no Computer e na API Platform.

A decisão mais importante do design é que a Perplexity não construiu um motor de embeddings separado. Como os modelos de embedding são transformers pequenos, a equipe reutilizou os kernels de prefill e decode da sua própria pilha de LLMs. Embeddings em lote se comportam como prefill (limitado por computação), enquanto embeddings online — consultas curtas — se comportam como decode (limitado por memória).

Três serviços, um caminho de requisição em Rust

Três componentes processam cada chamada:

• Ivy — um gateway HTTP em Rust que faz o trabalho de CPU: parsing de JSON, tokenização, template de entrada e divisão de lotes. Também quebra requisições grandes em pedaços e distribui entre réplicas, corrigindo o desbalanceamento de carga quando os payloads variam de tamanho.
• Tulip — a interface do servidor de inferência, um servidor gRPC em Rust (tokio e tonic) que cuida de agendamento e batching antes de despachar para o motor.
• ROSE — o Runtime-Optimized Serving Engine, que executa a inferência com CUDA graphs e uma abstração assíncrona de rastreamento de resultados.

A equipe afirma que a inferência de embeddings no lado da GPU já convergiu entre os motores em hardware Hopper e Blackwell maduro. O que diferencia, segundo o texto, é o runtime e o “harness” ao redor do modelo.

Por que isso importa agora

Para quem trabalha com RAG, busca semântica ou recuperação em produção no Brasil, o recado é direto: a fronteira de custo dos embeddings já não está no modelo, e sim na camada de serviço. Reaproveitar kernels de LLM e escrever o caminho de requisição em Rust são escolhas que reduzem latência e custo sem trocar o modelo.

O post é um relato técnico da Perplexity, não um benchmark independente — os números de eficiência citados são os da própria empresa.