Perplexity dévoile son infrastructure GPU d'embeddings : Ivy, Tulip et ROSE au service de pplx-embed
Perplexity a publié cette semaine, via son équipe d'ingénierie, un billet technique intitulé « Fast Embeddings on GPUs », détaillant l'infrastructure qui fait tourner pplx-embed ainsi que les modèles de ranking utilisés dans Perplexity Search, Computer et l'API Platform. L'équipe constate que l'inférence d'embeddings sur GPU a largement convergé entre moteurs concurrents sur du matériel Hopper et Blackwell mature, les gains résiduels se logeant désormais dans le runtime : gestion des CUDA graphs, suivi asynchrone des résultats et un chemin de requêtes écrit en Rust. Le système repose sur trois services : Ivy, une passerelle HTTP en Rust qui gère le tokenizing et répartit la charge entre répliques ; Tulip, un serveur d'inférence gRPC construit avec Rust, tokio et tonic, chargé de l'ordonnancement ; et ROSE (Runtime-Optimized Serving Engine), principalement en Python, qui exécute les kernels et gère les CUDA graphs. Perplexity a choisi de ne pas construire de moteur d'embeddings dédié, réutilisant à la place les kernels de prefill et décodé de sa pile LLM existante, car les modèles d'embeddings sont de petits Transformers dont le comportement ressemble à ces deux régimes de calcul.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
Cette architecture importe parce qu'elle conditionne directement le coût et la latence d'un moteur de recherche IA à grande échelle : la qualité de la recherche dépend autant de la pertinence du modèle d'embedding que du prix de son exécution sur l'ensemble d'un index. En optimisant l'infrastructure plutôt que le modèle lui-même, Perplexity peut réduire ses coûts d'indexation par lots tout en gardant des requêtes utilisateur rapides en temps réel, deux contraintes habituellement contradictoires. La démonstration que l'attention devient négligeable face au coût des couches denses pour ces petits modèles permet à l'entreprise de garder un ordonnanceur volontairement simple, premier arrivé premier servi, sans perte d'efficacité une fois le GPU saturé autour de 512 tokens. C'est un signal pour l'industrie que l'optimisation du serving, et non seulement l'entraînement de meilleurs modèles, devient un axe de différenciation concurrentielle pour les entreprises d'IA appliquée.
Le contexte plus large est celui d'une course à l'efficacité d'inférence à mesure que les produits de recherche et d'assistance IA passent à l'échelle, chaque requête embeddée ou rerankée ayant un coût GPU direct. Perplexity a dû résoudre des problèmes concrets comme la lenteur du lancement de kernels sur petits batches, en capturant des graphes CUDA complets par modèle, une opération coûteuse en temps qu'elle a rendue paresseuse pour étaler la charge de capture sur plusieurs heures plutôt que plusieurs minutes au démarrage. L'entreprise a aussi contribué en amont à la bibliothèque FlashInfer pour permettre cette capture de graphes complets, illustrant une dynamique où les acteurs de la recherche IA améliorent des outils open source partagés par toute l'industrie. Cette publication technique s'inscrit dans une tendance des laboratoires à documenter publiquement leur pile d'inférence, à la fois pour attirer des talents en ingénierie et pour asseoir leur crédibilité technique face à des concurrents comme Google ou OpenAI sur le terrain de la recherche augmentée par IA.
Pas d'impact direct sur la France/UE