Liquid AI s’attaque aux dernières millisecondes de l’inférence

Liquid AI présente RIPL, un moteur d’inférence destiné aux recherches, recommandations et décisions en temps réel, avec des latences mesurées en millisecondes.

Une recherche de produit, une autorisation de paiement ou la sélection d'une publicité se joue en quelques millisecondes. Ces opérations s'appuient sur des systèmes capables de traiter de nombreuses requêtes simultanément, avec très peu de temps pour produire une réponse. Les modèles de langage y trouvent difficilement leur place lorsque leur exécution prend plusieurs centaines de millisecondes, voire plusieurs secondes. Liquid AI propose de réduire cet écart avec RIPL (Real-time Inference Pipeline), un moteur d'inférence conçu pour exécuter ses modèles LFM directement dans le parcours d'une requête. L'entreprise annonce des réponses complètes en moins de 50 millisecondes pour certaines tâches courtes, et jusqu'à 28,4 fois moins de latence au 95e percentile que des configurations concurrentes reposant sur Qwen3.5 et vLLM. La technologie vise notamment la recherche, le commerce électronique, la publicité, les services financiers et les outils de classification. Faire entrer les modèles génératifs dans les systèmes transactionnels

L'infrastructure d'inférence des grands modèles de langage a principalement été développée pour des applications conversationnelles ou agentiques. Ces systèmes peuvent accepter un délai de plusieurs secondes lorsqu'il s'agit de rédiger une réponse, d'analyser un document ou d'exécuter une série d'opérations complexes. Les moteurs d'inférence cherchent alors à optimiser le débit, l'utilisation des accélérateurs et la gestion de plusieurs générations longues.

Les contraintes sont différentes lorsqu'un modèle intervient pendant le fonctionnement ordinaire d'un site marchand ou d'un service financier. Un moteur de recherche doit identifier l'intention d'une requête avant d'afficher ses résultats. Une plateforme publicitaire doit sélectionner des annonces dans le temps imparti à la réponse d'une page. Un système de paiement peut devoir examiner des signaux de risque avant d'autoriser une transaction. Dans ces situations, le modèle partage un budget de latence avec d'autres services, et chaque milliseconde supplémentaire peut retarder l'opération entière.

Pour ces usages, les entreprises privilégient traditionnellement des classificateurs spécialisés, des modèles d'arbres de décision ou des représentations vectorielles compactes. Leur exécution est relativement rapide, mais leur comportement est généralement limité aux tâches pour lesquelles ils ont été construits.

RIPL cherche à rendre possible l'utilisation de petits modèles génératifs dans ce même chemin critique. Le logiciel est optimisé pour produire rapidement des sorties courtes ou structurées, y compris lorsque les requêtes arrivent de manière continue. Les modèles peuvent ainsi être employés pour reformuler une recherche, extraire une catégorie ou interpréter un contexte plus varié sans imposer systématiquement le temps de réponse d'un grand modèle conversationnel. Mesurer la réponse complète plutôt que le premier token

Liquid met l'accent sur la latence de bout en bout, mesurée depuis l'arrivée d'une requête jusqu'à la production de sa réponse complète. Cette distinction est importante : un modèle peut commencer à générer rapidement, puis nécessiter un délai supplémentaire pour terminer une sortie de plusieurs dizaines de tokens.

RIPL optimise l'ensemble de ce parcours, et non uniquement la vitesse de génération après le premier token. Le moteur cible également les performances sous charge continue, lorsque plusieurs centaines ou milliers de demandes peuvent arriver chaque seconde.

Pour évaluer ces conditions, Liquid utilise notamment la latence p95, qui désigne le temps dans lequel 95 % des requêtes sont terminées. Une moyenne faible peut masquer des ralentissements importants sur les demandes les plus lentes. Le p95 permet de mieux observer ces situations, particulièrement problématiques dans les systèmes transactionnels où une petite proportion de réponses tardives peut affecter les utilisateurs.

Les résultats publiés concernent différents modèles, volumes d'entrée et longueurs de sortie. Ils ne montrent pas que chaque requête traitée par RIPL se termine systématiquement en moins de 50 millisecondes. Les tâches courtes sont les plus favorables ; les demandes nécessitant davantage de contexte ou de génération peuvent dépasser largement ce seuil. Des écarts de latence importants face à vLLM

Sur un GPU NVIDIA B200, Liquid indique que LFM2.5-1.2B exécuté avec RIPL atteint une latence p95 de 34,6 millisecondes pour une requête de 32 tokens d'entrée et 32 tokens de sortie, avec un trafic de 1 000 requêtes par seconde. Dans la configuration de comparaison, Qwen3.5-0.8B sur vLLM atteint 498 millisecondes, soit un rapport de 14,4.

L'écart augmente sur une tâche plus longue, comportant 256 tokens d'entrée et 128 tokens de sortie. À 400 requêtes par seconde, Liquid rapporte 155,8 millisecondes avec RIPL, contre 4 431 millisecondes avec Qwen3.5 sur vLLM, soit une latence 28,4 fois inférieure.

Pour LFM2.5-2.6B, comparé à Qwen3.5-2B, les gains annoncés sont plus modérés mais restent importants : entre 5,6 et 7,7 fois moins de latence p95 selon la charge et la forme des requêtes. Les mesures portent sur des configurations sélectionnées pour des charges transactionnelles, et non sur un ensemble représentatif de toutes les utilisations possibles des modèles.

Ces chiffres comparent à la fois des modèles différents et des moteurs d'inférence différents. Ils ne permettent donc pas d'attribuer intégralement les gains à RIPL. L'architecture des modèles LFM, leur taille, leur traitement des tokens et les paramètres du serveur peuvent aussi contribuer aux résultats. Liquid publie également des comparaisons de certains LFM exécutés avec RIPL ou vLLM, mais sans détailler publiquement l'ensemble des optimisations internes de son moteur.

Les benchmarks sont réalisés par l'entreprise. Ils ne constituent pas, à ce stade, une évaluation indépendante de RIPL face à des configurations concurrentes optimisées pour les mêmes contraintes. Recherche,