Perplexity revela cómo acelera los embeddings y el ranking de su buscador con GPU

Perplexity ha detallado la infraestructura que utiliza para ejecutar los modelos de embeddings y ranking que sostienen productos como Search, Computer y su API Platform. El sistema combina componentes escritos en Rust y Python, reutiliza parte de la tecnología desarrollada para servir grandes modelos de lenguaje y está diseñado para resolver dos exigencias diferentes: procesar enormes volúmenes de documentos durante la indexación y responder con baja latencia cuando un usuario realiza una búsqueda.

Los embeddings tienen dos cargas de trabajo muy diferentes

Los modelos de embeddings convierten documentos y consultas en representaciones vectoriales que permiten localizar contenido semánticamente relacionado. Perplexity utiliza modelos propios como pplx-embed dentro de una infraestructura que también gestiona modelos de ranking encargados de ordenar los candidatos recuperados.

Durante la construcción o actualización del índice, el objetivo principal es maximizar el rendimiento procesando documentos en grandes lotes. En una búsqueda en tiempo real ocurre lo contrario: normalmente se procesa una consulta breve y la prioridad es devolver su embedding con la menor latencia posible.

Ivy, Tulip y ROSE dividen el trabajo de inferencia

Perplexity organiza el servicio alrededor de tres componentes principales. Ivy funciona como puerta de entrada HTTP y está escrito en Rust. Se ocupa del trabajo realizado en CPU, como analizar JSON, tokenizar el texto, aplicar las plantillas de entrada y dividir solicitudes grandes en lotes más pequeños.

Después, Ivy transforma las peticiones a un protocolo gRPC propio y las envía a Tulip. Este segundo componente también está desarrollado en Rust, utilizando Tokio y Tonic, y se encarga de programar y agrupar las solicitudes que terminarán ejecutándose en las GPU.

La inferencia propiamente dicha recae en ROSE, siglas de Runtime-Optimized Serving Engine. Este motor está desarrollado principalmente en Python y contiene los kernels, capas, definiciones de modelos y mecanismos de gestión de CUDA utilizados para ejecutar las operaciones sobre los aceleradores.

Perplexity reutiliza su infraestructura de LLM

Una de las decisiones de diseño consiste en compartir gran parte del código entre los modelos de embeddings y los grandes modelos de lenguaje. Según Perplexity, los embeddings por lotes tienen características computacionales similares a la fase de prefill de un LLM, mientras que las consultas pequeñas en tiempo real se parecen más a cargas de decode limitadas por el acceso a memoria.

ROSE reutiliza por ello kernels optimizados de prefill y decode. La compañía señala que incluso pplx-embed y el proceso de decodificación de determinados LLM pueden pasar por los mismos kernels, reduciendo el trabajo necesario para llevar nuevos modelos de embeddings desde la experimentación hasta producción.

Los CUDA Graphs reducen el trabajo de la CPU

En peticiones pequeñas, el tiempo empleado por la CPU en preparar y lanzar numerosos kernels puede convertirse en una parte significativa de la latencia. Perplexity utiliza CUDA Graphs para capturar las operaciones necesarias en el forward pass y volver a ejecutarlas con menos llamadas desde el host.

La compañía explica que, en sus modelos de embeddings pequeños, una carga de alrededor de 512 tokens puede ser suficiente para saturar la GPU en determinadas configuraciones con menos de 1.000 millones de parámetros. A partir de ese punto, introducir más secuencias en el mismo lote no proporciona necesariamente una mejora proporcional de eficiencia.

LazyTensor permite solapar el trabajo de CPU y GPU

Perplexity desarrolló además una abstracción denominada LazyTensor. En lugar de obligar al servidor a esperar a que la GPU termine completamente una operación antes de preparar la siguiente, LazyTensor permite seguir de forma asíncrona el estado de los resultados.

De esta manera, Tulip y ROSE pueden preparar y poner en cola nuevos lotes mientras una operación anterior continúa ejecutándose en el acelerador. El objetivo es mantener tanto CPU como GPU ocupadas y aumentar el rendimiento sin perjudicar las peticiones que necesitan baja latencia.

Los CUDA Graphs se capturan de forma progresiva

Las cargas de embeddings pueden presentar muchas combinaciones distintas de número de secuencias y tokens. Capturar por adelantado todos los CUDA Graphs necesarios puede tardar varios minutos, por lo que Perplexity utiliza una estrategia de captura diferida.

Cuando aparece una nueva configuración, el sistema realiza primero una ejecución de calentamiento. En una aparición posterior captura el gráfico y las siguientes peticiones equivalentes pueden reutilizarlo. Con esta estrategia, el coste inicial se distribuye durante las primeras horas de funcionamiento del servidor en lugar de retrasar significativamente su arranque.

Ivy también reparte los grandes lotes entre varias réplicas

La capa HTTP no se limita a preparar las solicitudes. Ivy puede dividir peticiones con lotes grandes y distribuir el trabajo entre distintas réplicas de los servidores de inferencia para evitar desequilibrios de carga.

Perplexity también ha integrado en Ivy su implementación propia de tokenización unigram, con el objetivo de reducir el tiempo empleado en CPU antes de que las solicitudes lleguen a los aceleradores.

FlashAttention y FlashInfer se eligen según la carga

ROSE mantiene soporte para diferentes implementaciones de atención, entre ellas FlashAttention 4, FlashInfer 2 y FlashInfer 3. Perplexity indica que no existe un único kernel óptimo para todas las configuraciones.

En sus pruebas, FlashAttention 4 ofrece generalmente mejor rendimiento, mientras que FlashInfer 3 puede resultar más rápido con determinados modelos basados en Qwen y secuencias especialmente largas. Por ese motivo, la infraestructura conserva varios backends y selecciona la configuración según el modelo y la carga.

Perplexity compara su motor con vLLM

La compañía ha evaluado su infraestructura frente a vLLM 0.22.0 utilizando pesos reales de sus modelos, precisión BF16 y entradas derivadas de conjuntos de evaluación. Las pruebas cubren escenarios de embeddings con baja latencia, ranking, procesamiento de alto rendimiento y múltiples solicitudes concurrentes.

Perplexity no reduce su conclusión a una única cifra de velocidad, ya que el resultado cambia según el tamaño de los lotes, la longitud de las secuencias y la concurrencia. La empresa sostiene que la combinación de Ivy, Tulip y ROSE consigue menor latencia y mayor rendimiento para sus propias cargas que las soluciones genéricas evaluadas. Se trata de benchmarks realizados por la propia compañía y no de una evaluación independiente.

La arquitectura trabaja sobre un índice a escala de exabytes

Perplexity afirma que estos sistemas participan en la infraestructura que alimenta su índice de búsqueda a escala de exabytes. Los mismos servicios de embeddings y ranking se utilizan para seleccionar información relevante antes de que otros modelos generen una respuesta.

La compañía publicó los detalles técnicos el 4 de septiembre de 2026. El diseño muestra cómo Perplexity intenta tratar la recuperación de información como una carga de inferencia especializada, reutilizando componentes de su infraestructura de LLM pero optimizando de manera independiente la preparación de solicitudes, el batching, la ejecución en GPU y el movimiento de resultados.