Comparaison des serveurs d'inférence : solutions open source pour les modèles d'IA

Ce que fait un serveur d'inférence

Un serveur d'inférence met à disposition un modèle d'IA déjà entraîné pour traiter les requêtes. Une application envoie des données d'entrée à un API, le serveur les transmet à un moteur de modèle qui les traite à l'aide des poids du modèle chargés. Le résultat est renvoyé à l'application via le serveur. Dans le cas d'un modèle linguistique, il peut s'agir d'une réponse textuelle ; selon l'interface, celle-ci peut également être restituée progressivement sous forme de flux de tokens.

Le serveur, le moteur d'exécution et le modèle sont des composants distincts. Les poids contiennent les paramètres appris ; le moteur d'exécution effectue les calculs sur le matériel disponible. Le serveur, quant à lui, organise l'accès aux requêtes et leur transmission. Changer de serveur ne remplace donc pas automatiquement le modèle, mais peut nécessiter un autre format ou un autre moteur d'exécution.

Une couche applicative supplémentaire est généralement nécessaire pour la gestion des utilisateurs et la logique métier. Elle détermine notamment quels utilisateurs sont autorisés à envoyer une requête, quelles données sont transmises au modèle et comment la réponse de ce dernier est intégrée dans un flux de travail. Une API de modèle accessible ne suffit pas à elle seule à refléter ces règles ; la protection des accès et la journalisation doivent également être intégrées dans la conception globale du système.

Un serveur LLM conçu pour la génération de texte ne constitue d'ailleurs pas automatiquement une plateforme pour la classification d'images ou d'autres types de modèles. Pour cela, il faut que l'architecture du modèle concerné et un environnement d'exécution adapté soient pris en charge. Triton adopte une approche plus large : il transmet les requêtes aux backends via des planificateurs spécifiques à chaque modèle. La possibilité d’y exécuter un modèle spécifique dépend toutefois du backend approprié.

Vérifier le modèle, le matériel et les droits

Commence ta sélection par la tâche à accomplir et un exemple concret Révision du modèle: Un modèle de chat, un modèle d'embedding et un classificateur d'images ont des exigences différentes. Notez également le format des poids utilisé et vérifiez si l'exécution souhaitée prend en charge précisément cette architecture et cette révision. Le nom d'un modèle connu ne suffit pas à lui seul pour garantir la compatibilité ou la cohérence des résultats.

• Indiquer l'objectif, la révision du modèle et le format de pondération disponible.
• Vérifier le processeur (CPU) ou le processeur graphique (GPU), la mémoire disponible, les pilotes et le backend requis.
• Préciser séparément les droits d'utilisation pour les serveurs, les poids des modèles et les composants supplémentaires.
• Documenter la longueur prévue des requêtes, le parallélisme et les exigences en matière de protection des accès.

Le choix du matériel ne se résume pas à savoir si un GPU est présent. Les poids doivent tenir dans la mémoire disponible, tout comme le code d'exécution et les données supplémentaires ; les pilotes et le backend doivent également être compatibles avec la plateforme. La documentation du backend de Triton indique que tous les backends ne sont pas pris en charge sur toutes les plateformes. Vérifie donc la combinaison de la version du serveur, du modèle, du backend et du matériel, plutôt que de te fier au nom du produit pour déterminer la prise en charge.

Le format peut également limiter le choix : selon la documentation du projet, llama.cpp nécessite des modèles au format Format GGUF. Le projet décrit une procédure de conversion pour d'autres formats ; cela ne signifie toutefois pas que chaque architecture ou chaque variante de modèle fonctionnera telle quelle. Le code source se trouve sur la branche de développement. Avant tout déploiement, tu devrais donc vérifier que ces informations correspondent bien à la version choisie.

Un serveur open source ne transfère pas sa licence aux poids de modèles. Vérifie séparément pour chacun d'entre eux si l'utilisation interne ou commerciale prévue est autorisée et quelles sont les conditions applicables. Le fait que les poids puissent être téléchargés ne constitue pas en soi une autorisation pour toute utilisation ou diffusion.

Comment les requêtes LLM mobilisent des ressources

Lors d'une requête textuelle, le modèle traite d'abord l'entrée. Cette phase s'appelle Preremplissage. Ensuite, lors de l'étape de décodage, il génère la réponse token par token. Une invite courte et une réponse longue font peser une part différente du travail sur la génération par rapport à un long extrait de document accompagné d'une réponse succincte. Ces deux cas doivent donc être pris en compte dans la planification des capacités.

Pendant la génération, le moteur d'exécution stocke des données intermédiaires dans le Cache KV afin que le contexte déjà traité puisse être réutilisé lors des étapes suivantes. Cet espace mémoire s'ajoute aux poids du modèle et varie en fonction de la longueur des séquences et du nombre de requêtes traitées simultanément. Le fait que le modèle tienne à lui seul dans la mémoire ne garantit pas pour autant que la charge prévue puisse également y tenir.

Le « Continuous Batching » regroupe de manière flexible les requêtes de génération en cours, au lieu d'attendre simplement qu'un lot commun fixe soit constitué. Le « PagedAttention » organise la mémoire du cache KV en blocs. Ces deux méthodes sont décrites pour les vLLM et peuvent améliorer l'utilisation des ressources. Cependant, leur efficacité dépend notamment de la taille des requêtes, du parallélisme et du matériel ; on ne peut donc pas en déduire qu'elles constituent un avantage pour toutes les charges de travail.

Triton, en revanche, décrit une architecture de serveur générale : un planificateur basé sur un modèle reçoit les requêtes et les transmet au backend compétent. Le traitement par lots dynamique peut être configuré pour un modèle donné. Cela ne signifie pas pour autant que chaque backend traite les requêtes LLM de la même manière en interne ou utilise les mêmes méthodes de stockage que vLLM. Pour établir une comparaison, c'est donc la combinaison concrète du backend et du modèle qui importe.

Pour un service de chat interne, un simple chiffre indiquant le nombre de jetons par seconde ne suffit donc pas. Outre la vitesse de sortie, le délai avant le premier jeton et les temps d'attente en cas de requêtes simultanées influencent l'expérience utilisateur. Compare les solutions candidates avec des longueurs d'entrée et de sortie représentatives ainsi qu'un même niveau de parallélisme avant de prendre une décision concernant le matériel.

Classer quatre solutions, noter SGLang comme alternative

Le tableau suivant classe vLLM, llama.cpp, Triton et TGI en fonction de leurs approches documentées. Il ne s'agit pas d'une comparaison des fonctionnalités ou des performances liée à une version spécifique. SGLang reste une alternative non évaluée : Hugging Face le recommande aux côtés de vLLM pour succéder à TGI, mais cela ne permet pas de déduire les formats de modèles, les interfaces ou la prise en charge matérielle d’une version spécifique de SGLang.

Le code source contient des pages de documentation provisoires et, pour llama.cpp, une branche de développement. Il n'existe donc aucune preuve d'une validation complète pour vLLM 0.10.2, llama.cpp b6000, Triton 25.10 ou TGI 3.3.7. Ces correspondances de versions ne sont donc pas utilisées comme base de comparaison. Avant tout déploiement, tu dois vérifier les caractéristiques requises pour la version du serveur et la révision du modèle effectivement choisies.

Le réel Charges d'exploitation Cela dépend, entre autres, de la mise à disposition des modèles, de la protection des accès et de la surveillance. Le tableau ne permet pas de comparer directement les efforts requis : une installation locale unique et une plateforme comportant plusieurs back-ends ont des exigences différentes. Vérifie donc d'abord quelles tâches l'installation doit réellement remplir.

Hugging Face dirige TGI dans le Mode maintenance et cite vLLM et SGLang comme alternatives. Une installation existante ne doit donc pas nécessairement être remplacée immédiatement. Pour les nouveaux projets, il convient toutefois de tenir compte de ces limitations dans la planification ; avant toute migration, il faut comparer séparément le comportement des API et la qualité des modèles.

Triton et vLLM ne s'excluent pas systématiquement : Triton peut utiliser un backend vLLM. Il convient toutefois de vérifier si un modèle donné fonctionne avec les versions sélectionnées et la plateforme disponible pour cette combinaison. L'architecture générale de Triton ne garantit pas à elle seule la prise en charge de tous les backends sur toutes les plateformes.

Préparer le prototype local

Pour créer un prototype local, commence par définir la tâche à accomplir et quelques entrées types. Choisis ensuite une version spécifique du modèle qui te semble adaptée à cet usage, puis vérifie ses conditions d'utilisation. La licence du serveur ne précise pas à elle seule si tu es autorisé à télécharger, modifier ou utiliser les poids du modèle pour l'usage que tu envisages.

llama.cpp utilise le format GGUF. Recherchez une variante GGUF adaptée ou vérifiez si le modèle source peut être converti à l'aide des outils documentés. La documentation du projet décrit ces conversions sur la branche de développement ; elle ne garantit pas que chaque version antérieure prenne en charge toutes les architectures ou toutes les options de conversion.

Avant le téléchargement, vérifie si la variante choisie est prise en charge par ton processeur ou ta carte graphique avec le backend prévu, et si la mémoire disponible est suffisante pour les poids et le code d'exécution. Une variante quantifiée peut réduire les besoins en mémoire des poids. Compare toutefois ses réponses à tes exigences de qualité, au lieu de conclure que les résultats sont inchangés simplement parce que le fichier est plus petit.

Pour le prototype, choisissez une version spécifique et vérifiez que l'installation ainsi que les options du serveur correspondent à sa documentation. Pour la version b6000 mentionnée précédemment, aucun test lié à la version n'est consigné ici ; elle n'est donc pas recommandée comme point de départ testé. La documentation du modèle disponible sur la branche de développement ne remplace ni la documentation du serveur de la version sélectionnée, ni son contrôle de compatibilité.

Commencez par déployer le service uniquement en local et envoyez plusieurs requêtes représentatives. Vérifiez non seulement si une réponse s'affiche, mais aussi si le format de saisie, le modèle et les paramètres de génération correspondent à l'application que vous prévoyez de mettre en place. Un appel unique réussi ne prouve ni la capacité du service à supporter une charge plus importante, ni la qualité de toutes les réponses.

Notez trois éléments distincts : la qualité du contenu à partir de vos cas de test, le temps de réponse perçu et l'effort nécessaire pour le téléchargement, la conversion et la mise à disposition. Vous pourrez ainsi déterminer, par exemple, si un modèle mis en place rapidement n'est pas adapté sur le plan technique. Pour la gestion séparée de l'hôte Linux, le Présentation de 1Panel pour la gestion des serveurs contexte complémentaire ; un panneau de configuration du serveur ne remplace pas la vérification de la durée d'exécution du modèle.

Planifier la charge et les besoins en mémoire

Dans le cadre d'un service de chat interne, les requêtes varient souvent considérablement : une question brève avec une réponse succincte mobilise des ressources différentes de celles nécessaires à un long extrait de document avec un résultat détaillé. Il convient donc de recenser les longueurs typiques et maximales des entrées et des sorties, ainsi que le nombre prévu d'utilisateurs simultanés. Un seul appel réussi ne suffit pas à décrire la situation en charge.

Les besoins en mémoire ne se limitent pas au poids des modèles. La durée d'exécution et les valeurs intermédiaires occupent également de l'espace ; de plus, avec les requêtes LLM parallèles, les besoins en Cache KV. Des contextes plus longs et un plus grand nombre de requêtes traitées simultanément peuvent donc pousser une configuration à ses limites, même si les poids tiennent à eux seuls dans la mémoire disponible.

Le « Continuous Batching » et le « PagedAttention » sont des approches documentées dans le domaine des vLLM pour la gestion des requêtes en cours et de la mémoire cache, respectivement. Elles ne vous dispensent toutefois pas de planifier vos capacités : la combinaison viable entre parallélisme et longueur de contexte dépend du modèle, du matériel et de la configuration choisie. On ne peut donc pas en déduire un gain de performances général pour chaque charge de travail.

Un simple calcul de quantité peut aider à se préparer : 100 demandes hypothétiques, chacune correspondant à 200 jetons de distribution, totalisent 20 000 jetons de distribution. Cela représente pas de mesure du débit. En l'absence de période, de longueurs de saisie, de parallélisme et d'autres données d'exploitation, cela ne permet pas de tirer de conclusion ni sur le nombre de jetons par seconde, ni sur les coûts.

Pour pouvoir effectuer une comparaison ultérieure, crée une matrice de test incluant le modèle et la révision, la quantification, la version du serveur, le matériel et la mémoire disponible. Fais varier de manière contrôlée la longueur des entrées et des sorties, ainsi que le parallélisme. Enregistre le temps nécessaire pour obtenir le premier token, la vitesse de sortie et le taux d'erreur ; évalue séparément la qualité de la réponse à l'aide des mêmes cas de test. Les paramètres de génération et le modèle de chat doivent également figurer dans le protocole afin que les différences restent traçables.

Exploiter l'API de manière sécurisée et traçable

Un accessible Serveur d'inférence Ce service n'est pas encore sécurisé. Limitez dans un premier temps l'accès au réseau aux seuls systèmes qui doivent envoyer des requêtes ou administrer le serveur. Pour les accès externes, mettez en place une protection d'accès en amont de l'API ; vérifiez tous les points de terminaison accessibles, et pas seulement le chemin menant à la génération de texte.

Avertissement : Selon la documentation, l'option « API Key » de vLLM ne protège pas tous les points de terminaison. La définition d'une clé ne remplace donc ni la séparation des réseaux, ni un contrôle d'accès en amont prenant également en compte les interfaces administratives et autres interfaces accessibles. Teste les règles à partir des réseaux concernés avant de mettre le service en production.

Les requêtes et les réponses peuvent contenir des informations confidentielles. Définis donc au préalable quelles données doivent être enregistrées, qui est autorisé à les consulter et quand elles doivent être supprimées. Pour le dépannage, des informations techniques telles que l'heure, la version du modèle, le type d'erreur et la durée de la requête suffisent souvent ; tu ne devrais enregistrer l'intégralité du contenu qu'en cas de besoin justifié.

Le Observabilité Il convient de mesurer séparément le temps d'attente, le temps jusqu'au premier jeton, la vitesse de sortie et les erreurs. Si, par exemple, le temps d’attente augmente en cas de requêtes simultanées, alors que les réponses individuelles s’exécutent rapidement une fois lancées, cela indique un goulot d’étranglement autre qu’une distribution lente des jetons. Évaluez ces indicateurs en tenant compte de la taille des requêtes et du parallélisme.

Pour l'exploitation des hôtes sous-jacents, les outils d'administration peuvent regrouper des tâches et des responsabilités. Pour sélectionner séparément ce niveau d'administration, le Comparaison entre ISPConfig et Froxlor contexte complémentaire. Le choix d'un panneau de serveurs relève d'une décision spécifique en matière d'infrastructure ; un tel panneau ne remplace ni la sécurisation de l'API du modèle, ni la surveillance du service d'inférence.

Identifier l'origine du problème et migrer TGI

Si un modèle ne démarre pas, vérifie d'abord que la révision du modèle et le format correspondent à l'environnement d'exécution sélectionné. Pour llama.cpp, le format requis est GGUF ; toutefois, une simple conversion ne suffit pas à garantir que l'architecture et la tâche en question fonctionnent correctement. Vérifie ensuite si le backend choisi et la combinaison matérielle sont pris en charge, et si la mémoire disponible est suffisante.

Si le serveur démarre mais renvoie des réponses inattendues dans le chat, vérifie ceci : Modèle de chat et les paramètres de génération fournis. Une interface compatible avec OpenAI ne signifie pas que chaque paramètre est implémenté de manière identique : la documentation vLLM mentionne également les paramètres non pris en charge ou ignorés. Comparez donc les paramètres réellement utilisés et pas seulement la forme de l'appel d'API.

Pour un service TGI existant, la migration commence par un état des lieux : cela inclut la révision du modèle, les appels API utilisés, les paramètres d'échantillonnage et les exigences en matière de qualité des réponses. Hugging Face maintient TGI en mode de maintenance et propose notamment vLLM et SGLang comme alternatives. Cela justifie d'envisager un changement, mais n'entraîne pas pour autant une interruption immédiate des installations existantes.

Construis la Installation cible Testez-les séparément et comparez les deux services en utilisant les mêmes données d'entrée représentatives, les mêmes longueurs de sortie et les mêmes conditions de charge. Outre la qualité des réponses et les erreurs, vérifie également si les clients s’adaptent bien à la nouvelle interface et à ses paramètres. Ne bascule le trafic que lorsque les résultats sont acceptables pour l’utilisation prévue et qu’un plan de repli est en place.

Le guide Hugging Faces consacré aux points de terminaison d'inférence recommande également de créer un nouveau point de terminaison et d'effectuer des appels de test avant la bascule. Il s'agit d'un modèle de procédure utile pour la planification, mais pas d'un guide étape par étape universel pour les installations gérées en interne : le réseau, le déploiement et la gestion du trafic peuvent y être organisés différemment.

Choisir l'architecture adaptée

Pour un prototype local le fichier llama.cpp constitue un point de contrôle évident lorsqu'un modèle GGUF adapté et une prise en charge matérielle appropriée sont disponibles. Cela n'implique toutefois aucune recommandation concernant une version spécifique. Ce qui est déterminant, ce n’est pas seulement de savoir si le serveur démarre : comparez également la qualité de la tâche souhaitée, le temps de réponse et l’effort nécessaire pour les poids du modèle. La prise en charge du modèle et du backend doit encore être vérifiée pour la combinaison concrète.

Pour un service de chat interne, vLLM peut être envisagé comme candidat à l'évaluation : la documentation évolutive décrit une interface de chat compatible avec OpenAI, avec le modèle de chat requis. Aucune évaluation n'a donc été effectuée pour la version 0.10.2. SGLang reste ici une alternative non évaluée issue de la documentation TGI ; en l'absence de test technique de la version, il n'est pas possible de le comparer à titre équivalent.

Une plateforme pour les modèles d'images et les modèles linguistiques présente des exigences différentes de celles d'un simple point de terminaison de chat. Triton constitue un cas de figure à examiner en raison de ses planificateurs et backends spécifiques aux modèles, bien que la version 25.10 n'ait pas encore été vérifiée dans ce contexte. Cette architecture rend la Assistance backend En ce qui concerne ce point crucial : tous les backends ne sont pas pris en charge sur toutes les plateformes, et chaque modèle requis doit être testé dans la combinaison concrète concernée.

Pour prendre votre décision, tenez compte de la révision du modèle, de la version du serveur, du matériel, du backend et des droits d'utilisation. Comparez ensuite la qualité, les temps de réponse sous la charge prévue et l'effort nécessaire pour la sécurisation, les mises à jour et le dépannage. Une solution qui suffit pour un essai local peut nécessiter une infrastructure supplémentaire en cas de multiplication des utilisateurs ou des types de modèles ; un classement général ne tiendrait pas compte de ces différences.