Combien d’utilisateurs simultanés un seul modèle d’IA domestique peut-il servir avant que la latence ne devienne instable ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Un modèle d’IA domestique peut servir de manière fiable un à plusieurs utilisateurs interactifs, mais la limite stable dépend de la demande en tokens, du traitement par lots et des objectifs de latence.

Un modèle produisant 30 tokens par seconde peut sembler rapide pour une courte conversation, mais ralentir lorsque quatre personnes envoient simultanément de longues requêtes. La concurrence consomme de la mémoire de cache KV, partage la capacité de décodage et provoque des pics de mise en file d’attente. La limite correcte correspond à la charge offerte maximale qui respecte toujours une cible définie de latence p95 avant le premier token et de débit en tokens pendant une utilisation familiale normale.

La concurrence transforme le débit en temps d’attente

Une estimation approximative de la capacité consiste à diviser le débit de génération soutenu par le nombre moyen de tokens demandés par seconde sur l’ensemble des sessions actives. Lorsque la demande approche de la capacité de service, de petits pics créent de longues files d’attente. Les utilisateurs ne sont pas des unités identiques : une réponse de 50 tokens et une réponse de 2 000 tokens sollicitent le serveur différemment.

Une analyse de la latence et du débit explique que le traitement par lots améliore le débit global, tout en se faisant souvent au détriment de la latence de réponse individuelle. Cette tension détermine si l’ajout de sessions reste stable.

Le préremplissage des requêtes peut également bloquer le décodage, selon l’ordonnanceur. Deux utilisateurs qui collent de longs documents peuvent davantage pénaliser tout le monde que six utilisateurs posant de courtes questions. Un nombre d’utilisateurs sans distribution des tailles de requêtes et de sorties n’est donc pas transposable.

Le cache KV et l’ordonnancement créent une seconde limite

Chaque séquence active stocke les clés et les valeurs d’attention de son contexte. Des historiques plus longs et des lots plus importants augmentent l’utilisation du cache KV jusqu’à ce que les requêtes soient refusées, échangées ou retardées. Le traitement par lots continu peut accepter de nouvelles tâches entre les itérations de décodage, améliorant ainsi l’utilisation, mais il ne crée pas de mémoire supplémentaire.

Une explication technique du traitement par lots continu montre comment l’ordonnancement au niveau des itérations remplit les emplacements de lots autrement inutilisés. Le bénéfice dépend de la charge de travail et peut légèrement accroître la concurrence entre les requêtes.

La latence devient instable à l’approche de la saturation, car la longueur de la file d’attente réagit fortement aux variations des arrivées. La latence moyenne peut augmenter progressivement, tandis que la latence p95 et la latence maximale bondissent. La capacité stable doit se situer sous ce point critique, plutôt qu’au niveau maximal de tokens par seconde observé lors du test de performance.

Quand le nombre d’utilisateurs cesse de prédire l’expérience

Le même serveur peut prendre en charge davantage d’utilisateurs pour la saisie prédictive que pour le RAG, l’utilisation d’outils ou la génération de textes longs. Les démarrages à froid, la limitation thermique, la recherche d’informations et la synthèse vocale ajoutent des étapes extérieures au service du modèle. Un chiffre de concurrence limité au modèle ne peut pas garantir la réactivité de l’application complète.

Un guide de service consacré à la mémoire de service décrit la mémoire, le contexte, le traitement par lots et le parallélisme comme des contraintes interdépendantes. Modifier l’un de ces éléments peut déplacer le point critique de capacité.

La prévision échoue également si les requêtes familiales arrivent par pics synchronisés plutôt qu’indépendamment. Quatre utilisateurs qui se chevauchent rarement peuvent être faciles à gérer, tandis que deux agents automatisés peuvent saturer le modèle en continu. Mesurez la charge offerte, et non le nombre de comptes enregistrés.

Identifiez le point critique de concurrence avec un test de charge

Rejouez des requêtes réalistes courtes, moyennes et longues avec une, deux, quatre, puis huit sessions simultanées. Gardez le modèle, la quantification, la limite de contexte et l’échantillonnage constants. Mesurez le temps d’attente en file, la latence avant le premier token, la latence intertokens, le taux de complétion, l’utilisation du cache KV, ainsi que les valeurs p50, p95 et maximales.

Utilisez l’architecture des sessions partageant un même modèle comme contexte de test lorsque plusieurs sessions du foyer utilisent un seul modèle. Gardez les étapes RAG et les outils désactivées, ou mesurez-les séparément.

Déclarez comme limite stable la concurrence maximale pour laquelle la latence p95 avant le premier token reste dans la cible du foyer, sans tendance à l’allongement de la file d’attente ni erreurs de mémoire. Conservez une marge de débit de 20 à 30 % pour absorber les pics. Recommencez le test chaque fois que la longueur du contexte, le modèle ou l’ordonnanceur change.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.