michaelfeil/infinity : servir des embeddings et des rerankers derrière une API REST

Le problème : un modèle d'embedding ne devient pas un service tout seul

Charger un modèle sentence-transformers dans un script Python est une chose. Le mettre derrière un point d'entrée HTTP qui tient la charge en est une autre : il faut une tokenisation qui ne bloque pas la boucle d'inférence, un regroupement dynamique des requêtes entrantes, une gestion de plusieurs modèles sur le même GPU, et une réponse dont le format ne change pas à chaque mise à jour du modèle. Infinity prend en charge cette partie. Le README le présente comme un serveur REST à haut débit et faible latence pour les modèles d'embeddings, de reranking, CLIP, CLAP et ColPali. La cible est donc l'équipe qui doit exposer ces modèles à d'autres services (recherche sémantique, RAG, déduplication, classement de résultats) et qui ne veut pas maintenir elle-même le serveur. Le périmètre est volontairement étroit : Infinity ne génère pas de texte, il produit des vecteurs et des scores.

Ce que fait réellement le moteur entre la requête et le vecteur

D'après le README, le serveur repose sur FastAPI et s'appuie sur PyTorch, sur optimum (ONNX et TensorRT) et sur CTranslate2 comme moteurs d'inférence, avec FlashAttention pour exploiter CUDA, ROCm, CPU, AWS INF2 ou Apple MPS. Deux détails d'architecture méritent l'attention. Le premier est que la tokenisation et le regroupement dynamique des requêtes (dynamic batching) sont délégués à des threads dédiés : la tokenisation ne s'exécute donc pas dans la boucle qui sert les requêtes HTTP. Le second est que plusieurs modèles peuvent coexister et qu'Infinity les orchestre. C'est la partie qui distingue le projet d'un simple wrapper autour d'un pipeline HuggingFace : la question n'est pas seulement d'exécuter un modèle vite, mais de faire cohabiter un modèle d'embeddings et un reranker, par exemple, sans multiplier les processus et sans dupliquer la couche HTTP. Le README mentionne aussi le support expérimental de l'int8 sur CPU et CUDA et du fp8 sur H100 et MI300, ainsi que le support Blackwell dans les notes de version de juillet 2025. Ces éléments sont annoncés comme expérimentaux, ce qui veut dire qu'il faut les traiter comme tels.

Installation et lancement : les commandes telles quelles

Deux chemins sont documentés. Par pip, avec l'extra qui installe l'ensemble des dépendances :

pip install infinity-emb[all]

Ensuite, dans un environnement virtuel actif, la CLI se lance directement :

infinity_emb v2 --model-id BAAI/bge-small-en-v1.5

La commande infinity_emb v2 --help liste l'ensemble des paramètres. La seconde voie, présentée comme recommandée dans le README, passe par l'image Docker michaelf34/infinity, à condition de monter l'accélérateur, par exemple en installant nvidia-docker. Le README indique également que la CLI v2 accepte tous ses arguments par variable d'environnement ou par argument de ligne de commande, et qu'une clé d'API peut être définie avec --api-key depuis la version 0.0.75. Un client Python séparé existe depuis octobre 2024 : pip install infinity_client. Pour un déploiement, l'ordre logique est donc : choisir l'image Docker correspondant à l'accélérateur, monter le GPU, passer le modèle cible en --model-id, puis vérifier la réponse sur le point d'entrée d'embeddings avant de brancher un client.

Version 0.0.x : ce que le numéro de version implique pour vos mises à jour

Le projet est en 0.0.77, publiée le 22 août 2025, après 0.0.76 en mars 2025 et 0.0.75 en janvier 2025. Le rythme de publication est irrégulier : environ deux mois entre janvier et mars, cinq mois entre mars et août. Le schéma 0.0.x signifie que rien ne garantit la compatibilité ascendante entre deux versions mineures. Pour une équipe qui épingle ses dépendances, c'est un coût de maintenance réel : chaque montée de version demande de relire les notes de version et de retester les points d'entrée utilisés. Le README cite par ailleurs des évolutions structurantes récentes (support Blackwell en juillet 2025, images Docker AMD, CPU et ONNX en novembre 2024, CLI v2 en mai 2024), ce qui confirme que l'outillage de déploiement bouge encore. Le dépôt n'est pas archivé et la dernière poussée datée du 24 mars 2026 indique une activité de développement continue. La licence est MIT, ce qui autorise l'usage commercial et la modification, à condition de conserver l'avis de copyright et le texte de la licence. Cette description ne constitue pas un avis juridique : si vous redistribuez Infinity dans un produit, faites vérifier les obligations de conservation de licence, en gardant à l'esprit que les poids des modèles que vous servez ont leurs propres licences, distinctes de celle du serveur.

Le cas où Infinity n'est pas le bon outil

Infinity est un serveur. Si votre besoin est d'appeler encode() sur un lot de phrases à l'intérieur d'un script Python, ajouter un processus HTTP, un port et une couche de sérialisation n'apporte rien : un pipeline sentence-transformers chargé en mémoire fait le travail avec moins de pièces mobiles. Le projet est également mal adapté si vous devez servir un modèle de génération de texte : ce n'est pas son périmètre, et le README ne mentionne aucune capacité de ce type. Autre limite à connaître : la compatibilité avec les spécifications OpenAI est présentée comme un alignement, pas comme une conformité stricte et garantie. Le README écrit que l'OpenAPI est « aligned to OpenAI's API specs », ce qui laisse la porte ouverte à des écarts de champs ou de valeurs par défaut selon les versions. Un client qui analyse la réponse de manière rigide peut casser après une mise à jour. Enfin, le support int8 et fp8 est explicitement qualifié d'expérimental : ne construisez pas une chaîne de production dessus sans validation sur vos propres données.

Face à un simple pipeline HuggingFace, la différence est la couche de service

L'alternative la plus directe n'est pas un autre serveur, c'est l'absence de serveur : un script qui instancie un pipeline HuggingFace et expose lui-même une route FastAPI. La différence n'est pas dans le moteur d'inférence, puisque Infinity s'appuie lui aussi sur PyTorch et optimum. Elle est dans ce qui entoure le modèle : regroupement dynamique des requêtes, tokenisation hors de la boucle HTTP, orchestration de plusieurs modèles, arguments de lancement par variable d'environnement, clé d'API, images Docker par accélérateur. Écrire cette couche soi-même est faisable, mais c'est du code à tester et à maintenir, et c'est précisément ce qu'Infinity fournit. L'arbitrage est donc clair : si vous n'avez qu'un seul modèle, un trafic faible et aucune contrainte de latence, la couche maison reste défendable. Dès que vous servez plusieurs modèles ou que la tokenisation devient un goulot d'étranglement, la couche de service devient le vrai sujet, et c'est là qu'Infinity se justifie.

Ce qu'il faut vérifier avant de s'engager

Trois vérifications concrètes, toutes traçables dans la documentation. Premièrement, l'accélérateur : le README liste CUDA, ROCm, CPU, AWS INF2 et Apple MPS, mais le chemin d'installation diffère (pip avec l'extra all, ou image Docker avec l'accélérateur monté). Vérifiez que la combinaison image et matériel est bien celle annoncée pour votre version. Deuxièmement, le contrat d'API : lancez infinity_emb v2 --help et comparez les paramètres exposés avec ce que votre client envoie réellement, notamment le champ model. Troisièmement, la version : épinglez 0.0.77 ou une version antérieure précise plutôt que de laisser pip résoudre la dernière, puisque le schéma 0.0.x n'offre pas de garantie de compatibilité. Le README renvoie à la documentation en ligne à l'adresse michaelfeil.github.io/infinity pour les détails de démarrage. Si l'un de ces trois points ne peut pas être confirmé dans votre environnement, mieux vaut le tester sur un déploiement jetable avant de le mettre derrière du trafic réel.

Conclusion éditoriale

Adoptez Infinity si vous devez servir plusieurs modèles d'embeddings ou de reranking sur un même accélérateur et que vous voulez une API alignée sur les spécifications OpenAI sans écrire votre propre couche FastAPI. Passez votre chemin si vous cherchez une bibliothèque d'inférence à intégrer dans un processus Python existant : Infinity est un serveur, pas un composant enfichable. Avant de vous engager, vérifiez deux points précis dans votre environnement : que la version 0.0.77 installée par pip ou l'image michaelf34/infinity correspond bien à l'accélérateur visé (CUDA, ROCm, CPU, AWS INF2 ou Apple MPS), et que votre client tolère le champ model tel qu'Infinity le renvoie, puisque l'alignement annoncé porte sur les spécifications OpenAI et non sur un contrat figé.

Sources officielles

1. License: MIT
2. michaelfeil/infinity on GitHub
3. Project website
4. README
5. Releases