DuoLM accélère de 60 fois les recommandations par LLM : 26 400 évaluations par seconde sur un seul H100

Les systèmes de recommandation à base de grands modèles de langage butent sur l'arithmétique. Pour évaluer des centaines de candidats pour un seul utilisateur, il faut faire passer dans le modèle les textes complets des descriptions, avec l'historique, et le débit des serveurs s'épuise vite. Les auteurs de DuoLM — Jiang Wu, Yutong Song, Hongbo Wang, Guanghe Cao et Jeff Lei Liang — proposent de supprimer entièrement ce travail répété. Sur une seule carte H100, leur système calcule environ 26 400 évaluations de candidats par seconde. C'est environ 60 fois plus vite que le modèle enseignant déployé sur vLLM avec automatic prefix caching, pour une qualité de recommandation comparable.

Deux modèles plutôt qu'un seul long prompt

Un ranker LLM classique reçoit tout en entrée : le texte de l'objet, l'historique de l'utilisateur, ses réactions. Pour chaque paire « utilisateur — candidat », le texte doit être retraité, alors que la description d'un produit ou d'une vidéo ne dépend pas de l'utilisateur.

DuoLM découpe la tâche en deux. Le premier élément est un encodeur basé sur un LLM. Il lit la description de l'objet et la comprime en une représentation compacte. Ce calcul se fait hors ligne, le résultat est mis en cache et sert pour n'importe quel nombre d'utilisateurs. Le second élément est un ranker personnalisé, lui aussi un LLM. Il reçoit les représentations toutes prêtes des candidats, l'historique de l'utilisateur et son retour, puis produit la recommandation.

Les deux modèles sont entraînés conjointement, end to end, avec deux signaux : les labels de recommandation et la distillation depuis un « expert », un modèle enseignant qui voit le texte complet. L'encodeur apprend à comprimer les descriptions pour que la perte d'information ne dégrade pas le classement final, et le ranker apprend à travailler à partir d'une entrée comprimée.

Runtime : tokens virtuels et CUDA Graphs

Un modèle censé économiser du calcul en théorie perd facilement son avantage en pratique à cause des surcoûts. Les auteurs décrivent donc non seulement l'architecture, mais aussi la partie serveur. Elle fonctionne ainsi :

• les représentations des objets sont stockées directement sur le GPU et injectées dans le modèle via des token ID virtuels : le ranker accède aux embeddings comme à des tokens ordinaires, sans copies superflues ;
• plusieurs candidats au sein d'une même requête partagent le calcul de l'historique de l'utilisateur : son préfixe est calculé une seule fois, et non pour chaque candidat ;
• CUDA Graph replay réduit le surcoût de lancement des kernels, ce qui compte lorsque les calculs eux-mêmes sont courts.

Ensemble, le modèle et le runtime réduisent le travail répété à chaque étape du pipeline de recommandation.

Ce que représentent 26 400 évaluations par seconde

Les principaux paramètres du travail :

• architecture : un encodeur LLM pour les représentations compactes des objets et un ranker LLM personnalisé ;
• entraînement : end to end, avec annotations de recommandation et distillation depuis un modèle enseignant full-text ;
• inférence : token ID virtuels, calcul partagé de l'historique, CUDA Graph replay ;
• matériel : un seul GPU H100 ;
• débit : environ 26 400 évaluations de candidats par seconde ;
• accélération : environ 60 fois par rapport au modèle enseignant sur vLLM avec automatic prefix caching ;
• qualité : comparable à celle du modèle expert enseignant.

La comparaison est intéressante parce que la référence n'est pas un lancement naïf, mais vLLM avec prefix caching, c'est-à-dire une pile déjà optimisée. Même celle-ci perd d'un ordre de grandeur, car elle met en cache les préfixes sans remplacer les longs textes d'objets par de courts vecteurs.

Pour les équipes qui bâtissent des recommandations sur des LLM, la conclusion est pratique. Si le catalogue évolue plus lentement que le trafic ne croît (produits, articles, vidéos, annonces), il est raisonnable de convertir les descriptions à l'avance en représentations pouvant être mises en cache. La partie en ligne se réduit alors au traitement de l'historique de l'utilisateur, et le coût de classement d'un candidat chute de plusieurs fois. Cela allège aussi la charge sur le parc de GPU : les mêmes requêtes sont servies avec moins de cartes.

Les limites sont également claires. Le gain dépend de la part d'objets réutilisés et de la capacité de la représentation comprimée à conserver les détails. La qualité annoncée a été mesurée sur des benchmarks par rapport au modèle enseignant, et non lors d'un test A/B en direct sur du trafic de production. Mais le schéma « encodeur hors ligne, ranker en ligne et runtime serveur adapté » paraît reproductible : le code du projet est publié sur GitHub, et l'on peut vérifier l'écart de 60 fois sur ses propres données sans réécrire toute l'infrastructure.