Multi-utilisateurs : servir 5 à 10 personnes sur une seule machine

L'essentiel

• La Box vise 5 à 10 comptes, dont 1 à 3 actifs au même instant (Q-001, hypothèse à vérifier chez le client).
• En génération, une machine à mémoire unifiée est bornée par sa bande passante : environ 256 Go/s théoriques, 212 Go/s mesurés. Le débit maximal d'un utilisateur seul ≈ bande passante ÷ octets de poids lus par token.
• Servir plusieurs utilisateurs coûte moins que N fois une requête : les poids sont lus une fois par pas pour tous les slots. Le débit agrégé monte, le débit par utilisateur baisse.
• Les MoE (peu de paramètres actifs) sont dix fois plus rapides qu'un dense de taille comparable sur cette machine : c'est le levier principal.
• Une seule courbe de montée en charge est publiée sur cette puce (Qwen3.6-35B-A3B : 59 t/s à 1 slot, 162 t/s agrégés à 8). Rien sur gpt-oss-120b ni sur un 70B dense. Tout le reste est à mesurer.

Le problème posé

Un cabinet de 5 à 10 personnes partage une machine. À un instant donné, une à trois personnes attendent une réponse : une question courte (« résume cette clause »), une analyse de dossier de 50 pages, un brouillon de courrier. Chacune veut voir le premier mot arriver vite (TTFT) puis le texte défiler à une vitesse de lecture confortable (environ 10 à 15 tokens par seconde suffisent à un lecteur humain ; hypothèse de confort, non sourcée). Le serveur, lui, doit maximiser le débit total sans laisser un utilisateur bloqué derrière un long traitement.

Notions

Pourquoi une machine à 256 Go/s est bornée en génération

À chaque token généré, le GPU doit relire l'ensemble des poids actifs du modèle depuis la mémoire, plus le KV cache. Databricks formalise cela par le MBU : bande passante atteinte = (taille des poids + KV) ÷ TPOT ³. En inversant, pour un utilisateur seul :

débit max (t/s) ≈ bande passante (Go/s) ÷ octets lus par token (Go)

Applications numériques avec 212 Go/s mesurés ⁷ (la valeur AMD de 256 Go/s est théorique ⁶). Toutes les lignes sont des estimations (poids seuls, sans KV) comparées aux mesures publiées.

Le dense de 70 Md est exactement à son plafond. Les MoE sont en dessous du leur : d'autres facteurs (calcul de l'attention, routage des experts, échantillonnage CPU ¹⁵) interviennent. Retenir : sur cette machine, le nombre de paramètres actifs commande la vitesse, pas le nombre total.

L'avantage des MoE

gpt-oss-120b et Llama 3.3 70B occupent une mémoire comparable (59 vs 42,5 Go). Le premier génère dix fois plus vite parce qu'il n'active que 5,1 Md de paramètres par token. Pour le multi-utilisateurs, cela signifie qu'un MoE de 120 Md laisse de la marge de débit à partager entre les slots, là où un dense de 70 Md n'en a aucune : à 5 t/s par utilisateur au mieux, il est inutilisable en conversation.

Effet du nombre de slots

En génération memory-bound, ajouter des slots coûte peu : les poids sont lus une fois par pas pour toutes les séquences ; seul le KV cache de chaque slot s'ajoute. Le débit agrégé monte donc presque linéairement au début, puis sature quand le calcul (ou l'échantillonnage) devient le goulot. Le prefill, lui, est compute-bound : un long dossier soumis par un utilisateur occupe le GPU et allonge le TTFT de tous.

Mesures publiées sur Strix Halo :

llama-server, Qwen3.6-35B-A3B UD-Q4_K_M, Vulkan RADV b9010 ¹¹ (communauté, Beelink GTR9 Pro) :

L'auteur retient -np 8 comme point d'équilibre (2,7 fois le débit mono). Au-delà, l'agrégé ne monte plus et chaque utilisateur descend sous 10 t/s.

Autres points : environ 45 t/s mono et environ 168 t/s agrégés sur 16 slots en HIP (mars 2026, modèle non précisé dans le résumé) ¹² ; Vulkan +6,7 % en agrégé à 2 clients sur des modèles 122B ¹⁴ ; vLLM 86,6 → 246,5 → 311,6 t/s agrégés à 1/4/8 clients sur un 0,8B, contre 81,7 → 138,0 → 207,1 pour llama.cpp ¹³.

Matrice de capacité

La matrice ci-dessous est alimentée uniquement par la collection benchmarks : chaque cellule affiche la meilleure mesure enregistrée pour ce nombre d'utilisateurs simultanés et cette classe de modèle, avec son origine (indépendant, communauté, nôtre). Les cellules « à tester » ne sont pas inventées : elles signalent l'absence de mesure. Les colonnes 2, 3, 5 et 10 utilisateurs resteront vides tant que nos propres mesures ne seront pas faites ; les publications utilisent 1, 4, 8 et 16 slots.

Hypothèses de dimensionnement

Hypothèse de fond pour gpt-oss-120b : avec 5,1 Md actifs, sa courbe devrait ressembler à celle du 35B-A3B (3 Md actifs) décalée vers le bas ; c'est précisément ce que doit vérifier l'expérimentation de montée en charge. Le TTFT sur longs prompts n'apparaît pas dans ce tableau : il dépend du prefill (300 à 1 400 t/s selon modèle et backend) et de la longueur du dossier, voir Dimensionnement.

Questions ouvertes

• Q-001Combien d'utilisateurs simultanés la Box peut-elle réellement servir ?HauteOuverte

Ce qu'il reste à tester

• Montée en charge de 1 à 10 utilisateurs : gpt-oss-120b et Qwen3-30B-A3BAvec llama-server -np 8 --kv-unified et KV q8_0, gpt-oss-120b sert 3 utilisateurs simultanés à plus de 25 t/s chacun avec un TTFT p95 inférieur à 3 s sur prompts courts ; à 10 utilisateurs, le débit par utilisateur reste au-dessus de 10 t/s. Le comportement suit la courbe publiée pour Qwen3.6-35B-A3B (59 → 20 t/s par utilisateur de 1 à 8 slots) décalée vers le bas.À tester
• Évaluer vLLM sur ROCm gfx1151En septembre 2026, l'image officielle vllm/vllm-openai-rocm démarre sur gfx1151 avec ROCm 7.x sans patch, sert un MoE de taille moyenne, et donne un TTFT p95 inférieur à celui de llama-server à 5 clients ; mais elle ne sert pas gpt-oss-120b en MXFP4 sans conversion, et réserve plus de mémoire que llama-server pour un même contexte.À tester