Serveur d’IA local : comment calculer la concurrence réelle avant de promettre un assistant privé à toute l’équipe

Le chiffre de la démonstration n’est pas la capacité du service

Un modèle qui génère rapidement du texte pour une seule personne n’a pas, pour cette seule raison, démontré sa capacité à servir une équipe. La démonstration isolée repose souvent sur une requête courte, sans file d’attente, avec le cache et le processus déjà chauds, et sans autres conversations qui retiennent de la mémoire. Un service partagé fonctionne dans d’autres conditions : les requêtes arrivent à des rythmes irréguliers, leurs entrées et sorties sont hétérogènes, elles se disputent la mémoire du GPU et attendent lorsque le système ne peut pas les exécuter immédiatement.

La capacité utile ne devrait pas être communiquée comme un unique chiffre de jetons par seconde. Il est préférable de l’exprimer comme un engagement conditionnel : pour des scénarios d’entrée et de sortie définis, une concurrence donnée maintient des objectifs de délai avant le premier jeton, de temps total de réponse et de taux de rejet ou d’attente. Cette formulation permet de confronter une promesse interne à un essai reproductible et évite d’extrapoler à partir d’une démonstration favorable.

Dans le serving de modèles génératifs, des métriques distinctes existent pour le temps en file, le temps jusqu’au premier jeton, le temps de génération, la latence entre les jetons et la latence de bout en bout. Cette séparation est importante, car deux configurations ayant le même rendement moyen peuvent offrir des expériences très différentes : l’une peut commencer à répondre rapidement mais terminer lentement ; l’autre peut retarder le démarrage à cause d’une accumulation de travail. Les guides sur les modèles locaux et les comparaisons de runtimes doivent traiter ces dimensions séparément avant de recommander une configuration.

La question opérationnelle n’est pas non plus simplement « combien de personnes compte l’entreprise ? ». Elle est : « combien de requêtes actives, de quelle taille et avec quel objectif de latence doivent être soutenues en même temps ? ». Trente personnes dont l’usage est occasionnel peuvent impliquer une faible concurrence. À l’inverse, quelques automatisations qui joignent de longs documents ou produisent de longues réponses peuvent saturer le même serveur. La mesure doit représenter ces charges, et non une notion abstraite d’utilisateur.

Définissez le service avant de choisir ou d’étendre le matériel

Commencez par décrire la demande attendue dans des unités que le serveur peut observer. Consignez le nombre de requêtes actives, et pas seulement les utilisateurs enregistrés ; la distribution des jetons d’entrée ; le maximum autorisé en sortie ; le type de tâche ; le taux d’arrivée ; ainsi que les objectifs de disponibilité et de latence. S’il n’existe pas d’historique de trafic, formulez des hypothèses explicites et testez des scénarios prudents. Une estimation ne devient pas un fait parce qu’elle est exprimée avec une précision numérique.

Séparez au moins trois catégories de travail. Le chat bref comporte généralement peu d’entrées et des sorties modérées. Une requête avec récupération augmentée peut inclure des fragments de documents et avoir une entrée importante même si la réponse est courte. La rédaction, l’extraction ou la génération de code peut exiger de longues sorties et maintenir la conversation active plus longtemps. Les mélanger dans une moyenne unique masque les cas qui consomment le plus de mémoire ou bloquent la file.

Pour chaque catégorie, définissez un budget : jetons d’entrée typiques et maximaux, jetons de sortie typiques et maximaux, requêtes simultanées prévues et limites d’expérience. L’objectif de latence doit inclure au minimum le temps jusqu’au premier jeton et le temps jusqu’à la fin. Vous devez aussi décider si un utilisateur peut annuler une génération, ce qui se produit lorsqu’il atteint une limite et s’il existe des catégories prioritaires. Sans ces règles, la capacité dépend de décisions implicites prises par le runtime sous pression.

La comparaison entre modèles locaux n’est utile qu’après avoir fixé ce contrat de service. Un modèle plus petit peut permettre une plus grande concurrence ou des réponses plus prévisibles avec le même matériel ; un autre modèle peut se justifier par sa qualité pour une charge précise, mais exiger des limites plus strictes. Il n’existe pas de configuration universellement suffisante : la décision doit relier la qualité requise aux résultats mesurés sous votre propre profil d’usage.

Construisez un budget mémoire, sans le confondre avec une garantie

La mémoire disponible pour servir un modèle ne se résume pas à la taille publiée de ses poids. Elle doit coexister avec les poids chargés, le cache de clés et de valeurs des conversations actives, les tampons et l’espace temporaire d’exécution, les structures du runtime et une réserve pour les variations et la récupération. La répartition exacte dépend du modèle, de la quantification, du runtime, du matériel et de la configuration ; une formule générique ne doit donc pas être présentée comme une mesure universelle.

Le cache KV est déterminant pour la concurrence. Il conserve l’état d’attention nécessaire à la poursuite d’une séquence et croît avec les jetons traités. Dans un service, son occupation varie selon les requêtes : une longue conversation, une entrée récupérée de grande taille ou une longue sortie peuvent retenir une part importante de la mémoire plus longtemps qu’une question courte. Les travaux sur PagedAttention identifient la gestion de ce cache, y compris la fragmentation et la duplication dans certains profils, comme un élément qui conditionne la taille effective du lot.

Il est raisonnable d’utiliser un budget de travail pour planifier, à condition de l’étiqueter comme une estimation. Mesurez d’abord la mémoire de base avec le modèle déjà chargé et sans trafic. Observez ensuite son évolution en exécutant chaque scénario avec des longueurs contrôlées et une concurrence croissante. Réservez une capacité qui ne sera pas attribuée à la charge nominale. Enfin, validez que la politique d’admission évite de dépasser la limite pendant une rafale. Le résultat pertinent est le comportement observé dans la configuration précise, et non un calcul isolé.

Les métriques du runtime peuvent exposer l’utilisation du cache KV, les requêtes en cours et celles qui attendent, ainsi que des mesures de prefill et de décodage. Ces observations permettent d’attribuer un incident avec davantage de prudence : elles ne prouvent pas à elles seules une cause physique unique, mais elles aident à distinguer une file croissante d’une pression soutenue sur le cache ou d’une génération lente. Conservez la configuration qui a produit chaque série temporelle afin que l’analyse soit reproductible.

Prefill et décodage : deux phases, deux goulots d’étranglement possibles

La requête ne consomme pas les ressources de la même manière tout au long de son cycle de vie. Lors du prefill, le système traite l’entrée afin de construire l’état qu’utilisera la génération. Lors du décodage, il produit des jetons successifs et met à jour cet état. Une requête contenant un long document peut démarrer lentement alors que sa réponse est brève ; une longue réponse peut commencer rapidement tout en retenant des ressources longtemps. Ne mesurer que la durée totale efface cette différence.

Le temps jusqu’au premier jeton est un signal utile pour l’utilisateur et reflète souvent à la fois l’attente en file et le travail préalable nécessaire au démarrage de la génération. La latence entre les jetons, le temps par jeton de sortie et le temps total apportent une autre perspective sur la phase de génération. Il est également utile de consigner la taille réelle de l’entrée et de la sortie, car une variation de ces longueurs peut expliquer une variation apparente de latence sans changement du matériel.

Le batching continu peut améliorer l’utilisation en mélangeant le travail de différentes requêtes, mais il ne supprime pas les limites de mémoire ni ne garantit l’équité entre les charges. Une charge à contexte large peut concurrencer les chats brefs ; les décisions du planificateur influent sur les requêtes qui démarrent plus tôt et celles qui restent en file. Un essai représentatif doit donc inclure des lots homogènes et un mélange contrôlé de scénarios, rapportés séparément.

N’interprétez pas une baisse du rendement moyen comme un diagnostic automatique. Elle peut provenir d’arrivées plus rapides que la capacité de service, d’entrées plus longues, d’un maximum de sortie élevé, d’une pression mémoire ou d’une politique de planification. L’instrumentation doit fournir assez de contexte pour identifier des corrélations et, si la cause ne peut être attribuée, l’incertitude doit être déclarée.

De la VRAM à une concurrence opérationnelle

La concurrence opérationnelle est le plus grand nombre de requêtes que le service peut admettre pour un scénario défini sans manquer ses objectifs. Elle ne doit pas être déduite directement de la mémoire libre ni d’un maximum théorique de contexte. La mémoire peut suffire alors que la file ou la latence dépasse le budget. À l’inverse, un résultat acceptable à une concurrence donnée ne valide pas une charge aux entrées ou sorties plus grandes.

Construisez une matrice d’essai. Dans une dimension, définissez les catégories de charge et leurs longueurs d’entrée et de sortie. Dans l’autre, augmentez les requêtes simultanées. Pour chaque cellule, répétez le test après échauffement et relevez les percentiles d’attente, de TTFT, de latence de génération et de temps de bout en bout. Notez les jetons réellement traités, l’utilisation du cache, les requêtes actives et en file, les annulations, les rejets et les erreurs. Les moyennes peuvent être ajoutées, mais ne doivent pas remplacer les percentiles.

La capacité doit être définie par le pire résultat qui reste acceptable, et non par le maximum qui parvient à terminer une exécution. Si le p95 de démarrage dépasse l’objectif, si la file croît durablement ou si des erreurs mémoire apparaissent, cette concurrence n’est pas une capacité opérationnelle pour ce scénario. Elle peut être conservée comme point de défaillance étudié, utile pour ajuster les limites, mais pas comme promesse à l’utilisateur.

Il est également important de tester la récupération après une pression. Après une rafale, observez si la file revient à des niveaux normaux, si la mémoire se libère comme prévu et si les nouvelles requêtes retrouvent leur latence habituelle. Un système qui termine un essai bref mais ne récupère pas rapidement peut être fragile pour une API interne.

Utilisez des files et une admission explicite avant la défaillance

La file d’attente n’est pas nécessairement une erreur : elle peut être une décision contrôlée pour protéger les requêtes déjà démarrées. Le problème survient lorsqu’elle n’a pas de limite, lorsque l’utilisateur ignore qu’il attend ou lorsque le système continue d’accepter un travail qui ne pourra pas respecter le budget. Une politique d’admission doit décider, avant d’allouer des ressources, si une requête peut entrer, attendre, recevoir une limite inférieure ou être rejetée avec une réponse claire.

Les contrôles habituels comprennent des limites par utilisateur ou identifiant, un maximum de jetons d’entrée, un maximum de sortie, un nombre maximal de requêtes actives, une longueur maximale de file et un temps maximal d’attente. L’annulation doit libérer le travail et la mémoire de manière vérifiable. S’il existe des catégories prioritaires, documentez-les : une priorité ne crée pas de capacité, elle répartit autrement une capacité limitée.

La dégradation doit être explicite et compatible avec le cas d’usage. Une interface peut, par exemple, demander à l’utilisateur de réduire les documents joints, appliquer une limite de sortie annoncée ou reporter une tâche non interactive. Il n’est pas approprié de tronquer silencieusement une information critique ni de changer de modèle sans en informer l’utilisateur lorsque cela modifie le résultat attendu. La politique doit déterminer ce qui se produit avant que le runtime n’atteigne une erreur de mémoire insuffisante.

Les compteurs de requêtes en attente et en cours, associés aux métriques de travail de prefill et de décodage, permettent d’évaluer si les règles protègent le service. Testez délibérément une charge supérieure à la charge admise : vérifiez que le nouveau travail est limité et que la latence des requêtes en cours ne se détériore pas de manière incontrôlée. Cet essai de surcharge est aussi important que le test nominal.

Protocole reproductible sur votre propre matériel

Un essai utile doit pouvoir être reproduit. Figez et consignez l’identité disponible du modèle, sa quantification, le runtime, la version du pilote, le type et la quantité de GPU, les limites de contexte et de sortie, les paramètres de batching et la politique d’admission. Si l’une de ces variables change, considérez le résultat comme une nouvelle mesure, et non comme la continuation automatique de la précédente.

Préparez une charge synthétique fondée sur les scénarios définis, sans utiliser de conversations réelles sauf autorisation spécifique et contrôles appropriés. La charge doit fixer ou consigner les longueurs d’entrée et de sortie. Exécutez un échauffement distinct de la mesure, réalisez plusieurs répétitions et conservez une période d’observation suffisante pour détecter les files qui augmentent. Rapportez p50, p95 et p99 lorsque le volume d’échantillons permet de les interpréter ; indiquez à leurs côtés le nombre de requêtes et l’intervalle de test.

La documentation de benchmark de vLLM prévoit des métriques telles que le TTFT, le temps par jeton de sortie et la latence entre jetons, et avertit que le cache de préfixes peut améliorer les résultats si son effet n’est pas contrôlé. Si vous utilisez un cache de préfixes en production, testez-le de façon représentative et déclarez si les prompts se répètent ; s’il ne représente pas la charge attendue, désactivez-le ou isolez-le dans un autre scénario. Un résultat qui dépend d’une réutilisation irréaliste n’est pas une estimation prudente de capacité.

Il ne suffit pas de conserver un tableau de bord. Gardez un résumé de la configuration, le générateur de charge, les paramètres, les résultats agrégés et les critères d’acceptation. La reproductibilité permet de comparer une mise à jour du modèle ou du runtime et de découvrir les régressions. Elle évite aussi qu’une décision d’achat ou de déploiement dépende de souvenirs relatifs à une démonstration antérieure.

Décider avec des preuves : limites, changement de modèle ou matériel supplémentaire

À partir des résultats collectés, décidez par rapport au besoin, et non à l’intuition. Conservez la configuration si elle satisfait les scénarios prioritaires avec une marge et récupère après les pics. Réduisez le contexte ou le maximum de sortie lorsque le produit peut le faire explicitement et que les essais montrent que cette mesure rétablit les objectifs. Limitez la concurrence si le profil de demande tolère une attente contrôlée. Séparer les charges peut être préférable lorsque les tâches sur de longs documents interfèrent avec le chat interactif.

Ajouter un GPU ou changer d’architecture est raisonnable seulement après avoir identifié quelle contrainte doit être levée. Si la pression du cache domine, le budget mémoire et la distribution de contexte sont centraux. Si le prefill des longues entrées manque l’objectif de TTFT, évaluez cette phase séparément. Si la qualité du modèle ne satisfait pas la tâche, davantage de concurrence ne résout pas le problème. Les preuves d’un essai ne permettent pas de déduire automatiquement laquelle de ces alternatives sera optimale sans la mesurer.

Changer de modèle exige aussi de répéter la matrice. Deux modèles dont la taille annoncée semble proche peuvent utiliser des configurations de contexte, des quantifications et des runtimes différents. Le changement peut modifier la mémoire de base comme le comportement de génération. Dans une comparaison interne, communiquez les conditions complètes et n’attribuez pas au seul volume des poids une causalité qui n’a pas été isolée.

S’il n’existe aucune configuration qui remplisse le besoin avec des limites acceptables, la décision honnête peut être de ne pas encore déployer le service partagé. Il vaut mieux proposer un pilote limité, avec un périmètre clairement défini, que promettre un assistant privé généraliste sans budget de capacité. L’inventaire des modèles locaux et les comparaisons doivent présenter cette conclusion comme une possibilité opérationnelle, non comme un échec.

Confidentialité, télémétrie et checklist de déploiement

L’instrumentation de capacité ne doit pas créer un dépôt parallèle de conversations. Les spécifications de télémétrie pour l’IA générative avertissent que les messages d’entrée, de sortie, les instructions et les arguments peuvent contenir des informations sensibles ou des données personnelles. Pour mesurer la concurrence, il n’est généralement pas nécessaire de stocker le texte intégral : longueurs en jetons, horodatages, identifiants pseudonymisés, résultat d’admission et métriques de latence suffisent habituellement.

Avant d’activer des traces détaillées, définissez les champs collectés, leur finalité de diagnostic, les personnes qui y accèdent, leur durée de conservation et leur suppression. Si des prompts ou réponses sont conservés pour le débogage, l’exception doit être justifiée, protégée par des contrôles d’accès et limitée dans le temps. Vérifiez également si des attributs apparemment inoffensifs, tels que les noms d’outils ou leurs arguments, peuvent révéler des informations métier.

Les preuves minimales d’un déploiement interne comprennent le contrat de service, les scénarios, l’environnement technique, la méthode de charge, les percentiles par scénario, le comportement au dépassement de limite, la politique d’admission et le traitement de la télémétrie. Distinguez toujours ce qui est mesuré, estimé et encore non testé. Cette discipline permet d’ajuster le service sans transformer un chiffre de démonstration en garantie non étayée.

La capacité n’est pas permanente. Des changements de modèle, de quantification, de pilote, de runtime, de paramètres de contexte, de cache ou de politique de planification peuvent invalider les résultats antérieurs. Planifiez une répétition du test lorsque des éléments matériels changent et surveillez en production que les distributions réelles d’entrée, de sortie et d’attente ne s’éloignent pas des scénarios approuvés.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.