Présentation
Spinf‑serve est un serveur d’inférence dédié au scoring de classification et à la prise de décision en masse. Le projet, publié sous licence Apache 2.0, expose une API compatible avec le format OpenAI, ce qui facilite son intégration dans les pipelines existants. Le point central du service est la capacité à traiter un document une seule fois, puis à répondre à un nombre indéfini de requêtes de scoring sans recharger le contenu.
Architecture et flux de traitement
Le serveur s’appuie sur un unique GPU pour exécuter le modèle de langage. La lecture du texte source s’effectue en une passe initiale ; les représentations internes (embeddings ou états du modèle) sont conservées en mémoire. Chaque question ou requête de décision accède à ces représentations, ce qui évite la surcharge d’une lecture répétée du même texte. Le modèle, chargé une fois, reste actif pendant toute la session, garantissant que le coût d’inférence est amorti sur l’ensemble des requêtes.
Le protocole d’appel suit la spécification OpenAI, notamment les champs model, prompt et max_tokens. Cette compatibilité permet d’utiliser les outils de test et les bibliothèques client déjà disponibles pour les API OpenAI, sans adaptation supplémentaire. Le serveur orchestre les requêtes en mode batch interne, mais chaque question est évaluée séparément à partir du même état partagé, assurant une isolation logique tout en conservant les gains de performance.
Analyse des performances et limites
Le principal avantage mesurable réside dans la réduction du temps d’accès au disque ou au stockage cloud : le texte n’est chargé qu’une fois, ce qui diminue le facteur I/O. En outre, le coût GPU est partagé entre toutes les requêtes, ce qui augmente le débit global. Cette approche est particulièrement adaptée aux cas d’usage où un même document doit être interrogé par plusieurs modèles ou plusieurs variantes de prompt, comme la validation de conformité ou la génération de scores de risque.
La contrainte la plus visible est la dépendance à un seul GPU. La capacité mémoire du GPU fixe la taille maximale du document et le nombre de représentations simultanées que le serveur peut conserver. En l’absence de parallélisation multi‑GPU, la scalabilité horizontale repose sur le déploiement de plusieurs instances, chacune avec son propre GPU, ce qui augmente le coût d’infrastructure. De plus, la compatibilité OpenAI ne garantit pas la prise en charge de toutes les extensions propriétaires de l’API officielle, ce qui peut limiter l’usage dans des environnements très spécifiques.
