Perplexity: answer engine com mais de 20 modelos

01 · CONTEXTO

Um motor de respostas, muitos modelos

A Perplexity é um motor de busca com IA. Segundo o artigo da NVIDIA que serve de fonte principal, a equipe de inferência serve mais de 20 modelos ao mesmo tempo, incluindo variações do Llama 3.1 como 8B, 70B e 405B. O motor atende mais de 435 milhões de consultas por mês, e cada consulta gera várias requisições de inferência.

O caso reúne três perguntas de projeto: qual modelo atende cada pedido, como agrupar pedidos para aproveitar a GPU sem quebrar o prazo de resposta e quanto custa cada consulta. As seções seguintes seguem essa ordem.

02 · ROTEAMENTO POR INTENÇÃO

Classificar o pedido e escolher o pod

Para ligar cada pedido ao modelo certo, a Perplexity usa classificadores menores que ajudam a determinar a intenção do usuário. As tarefas detectadas, como completar texto, são roteadas para modelos específicos implantados em pods de GPU.

Cada pod tem uma ou mais GPUs H100 e é gerenciado por uma instância do Triton Inference Server. Os pods ficam num cluster Kubernetes e operam sob SLAs rígidos de custo e de interatividade. Há ainda um scheduler de front-end interno, que faz o balanceamento de carga roteando o tráfego ao pod adequado conforme carga e uso.

1. O usuário faz uma consulta; cada consulta gera várias requisições de inferência por trás.

2. Classificadores menores determinam a intenção do usuário, e a tarefa detectada define para qual modelo o pedido vai.

3. O scheduler de front-end, construído internamente, roteia o tráfego ao pod adequado conforme carga e uso.

4. Os pods hospedam modelos de tamanhos diferentes; cada pod tem uma ou mais GPUs e é gerenciado por uma instância do Triton.

5. O Triton fornece métricas de utilização de GPU ao scheduler, o que apoia aumentar ou reduzir implantações e GPUs conforme o volume de requisições.

A escolha do algoritmo do scheduler importa: ele pode afetar a latência entre tokens. A fonte mostra uma comparação entre round-robin, least requests e power of two random choices num benchmark interno com carga moderada de 16 QPS.

03 · BATCHING POR SLA

Cada caso de uso tem o seu prazo

Para definir o SLA de cada caso de uso, a equipe faz testes A/B abrangentes, avaliando configurações e o impacto na experiência do usuário. O objetivo é maximizar a utilização da GPU cumprindo o SLA-alvo de cada caso, e melhorar o batching dentro desses SLAs é o que otimiza o custo de servir.

Os modelos pequenos de embedding, usados na recuperação em tempo real, ficam em geral escondidos do usuário, dentro de um fluxo maior; o foco deles é a menor latência possível, e por isso as configurações têm lotes pequenos. Como ocupam pouca memória, vários rodam juntos numa mesma GPU H100 para manter alta utilização. Já nos modelos voltados ao usuário a equipe faz uma análise mais profunda, com métricas próprias.

04 · EMBEDDINGS: IVY, TULIP E ROSE

Uma pilha própria para a busca

Além dos LLMs, a busca depende de modelos de embedding e de ranking, que ajudam a identificar os resultados mais relevantes para uma consulta. A Perplexity descreve dois padrões de tráfego: o embedding em lote, para construir ou reindexar a base maximizando a vazão e reduzindo o custo, e o embedding online, que converte uma consulta curta em vetor minimizando a latência.

Como os modelos são pequenos, boa parte da implementação é compartilhada com o código de LLM: o embedding em lote lembra o prefill, limitado por computação, e o online, que roda poucos tokens, lembra o decode, limitado por memória. Segundo a Perplexity, isso rende vazão alta em lote com pouco trabalho adicional de engenharia e latência baixa no online.

1. Os serviços da Perplexity chamam o Ivy, um gateway HTTP escrito em Rust.

2. O Ivy faz templating da entrada e divisão em lotes e traduz o pedido para um protocolo gRPC próprio dos servidores a jusante.

3. Como os payloads variam, mandar cada pedido a uma só réplica pode desequilibrar a carga; por isso o Ivy divide pedidos grandes em pedaços e os balanceia entre réplicas.

4. O Tulip recebe as requisições gRPC, cuida de scheduling e batching, envia os lotes ao ROSE e devolve as respostas.

5. O ROSE roda nas GPUs: implementa os forward passes e o gerenciamento de CUDA graphs, reaproveitando código dos LLMs e sobrepondo trabalho de CPU e de GPU.

O scheduling do Tulip é simples: pedidos se acumulam enquanto ele despacha trabalho ou espera resultados, e as sequências são escolhidas por ordem de chegada. Nesses modelos pequenos, a latência é mais ou menos proporcional ao número de tokens, não ao de sequências. Depois que o lote satura a GPU, cerca de 512 tokens num modelo abaixo de um bilhão de parâmetros, juntar mais sequências não melhora a eficiência.

05 · PARALELISMO E CUSTO

Quanto custa servir uma consulta

Para os LLMs voltados ao usuário, os SLAs rígidos levaram a equipe a aumentar o paralelismo de tensor para quatro e oito GPUs, o que reduz o custo para pedidos muito sensíveis à latência dentro de um orçamento fixo de GPUs. O paralelismo de dados ou de pipeline foi útil para maximizar a vazão onde a latência é menos crítica. Num exemplo da fonte, dividir o Llama 8B entre quatro GPUs Hopper reduz o custo relativo por milhão de tokens em até 3x para pedidos sensíveis à latência.

A decisão de hospedar os modelos depende de servi-los a um custo menor, ainda dentro dos SLAs rígidos, do que usar APIs de provedores terceiros. Como exemplo, a equipe estimou economizar cerca de US$ 1 milhão por ano ao servir, em GPUs NVIDIA na nuvem, os modelos que alimentam o recurso Related-Questions.

No roteiro de evolução está o serving desagregado, que separa as fases de prefill e decode de um LLM em GPUs separadas. Segundo a fonte, a técnica aumenta a vazão do sistema dentro dos SLAs, o que se traduz em menor custo por token, e a Perplexity trabalha com a equipe de engenharia do Triton para implantá-la.