Expérimentation
Montée en charge de 1 à 10 utilisateurs : gpt-oss-120b et Qwen3-30B-A3B
Mesurer le débit par utilisateur, l'agrégé et le TTFT p95 à 1, 2, 3, 5 et 10 clients simultanés avec des prompts français courts, RAG et dossiers, pour remplir la matrice de capacité.
Brouillon#benchmark#multi-utilisateurs#kv-cache#llama-cpp#gpt-oss#qwen#strix-haloPublié le 16 sept. 2026Mis à jour le 16 sept. 2026
- Statut du test
- À tester
- Priorité
- Haute
- Prévu pour
- Novembre 2026
- Hypothèse
- Avec 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.
- Procédure
- 1) llama-batched-bench -npl 1,2,3,5,8,10 -npp 512,2048,8192 -ntg 256, avec et sans -pps, pour les deux modèles ; noter la mémoire KV. 2) Lancer llama-server -np 8 --kv-unified -fa on -ctk q8_0 -ctv q8_0 --metrics avec -c dimensionné d'après l'étape 1. 3) vllm bench serve --backend openai-chat contre llama-server avec le jeu de prompts FR (60 % courts, 30 % RAG, 10 % dossier), --max-concurrency 1,2,3,5,10, 30 requêtes minimum par niveau, --percentile-metrics ttft,tpot,itl,e2el --metric-percentiles 50,95,99. 4) Répéter avec un dossier de 20 000 tokens injecté pendant que 2 clients courts tournent : mesurer leur dégradation. 5) Une fiche benchmark ours par (modèle, concurrence), série framework-ours-multi-user.
- Prochaine action
- Constituer le jeu de prompts FR de référence (anonymisé) ; dépend du benchmark 1 utilisateur pour le choix du backend.
Pourquoi
La matrice de capacité de la page Multi-utilisateurs est vide pour 2, 3, 5 et 10 utilisateurs, et rien n'est publié sur gpt-oss-120b en multi-slots. La seule courbe existante concerne un MoE de 35 Md à 3 Md actifs 4. Sans ces mesures, aucun engagement de nombre d'utilisateurs n'est possible envers un cabinet.
Protocole
Niveaux 2 et 3 de la méthodologie : llama-batched-bench 1 pour dimensionner -np et -c, puis vllm bench serve 2 contre llama-server --metrics 3 avec les prompts français. Relever en parallèle llamacpp:requests_processing et /slots.
Critères de succès
- Courbes débit par utilisateur / agrégé / TTFT p95 pour 1 à 10 clients, deux modèles.
- Mesure de l'effet d'un prefill long sur les autres slots.
- Mémoire KV réelle comparée aux estimations de la page KV cache.
- Réponse chiffrée à Q-001 côté serveur (le côté usage réel viendra du POC).
Résultat
À venir.
Sources
- 1llama.cpp — README de llama-batched-benchGitHubFiabilité hauteggml-org · publié 2026 (master) · consulté le 16 sept. 2026 · fiche source
- 2vLLM — commande vllm bench serveDocumentation officielleFiabilité hautevLLM · publié 2026 · consulté le 16 sept. 2026 · fiche source
- 3llama.cpp — README de llama-server (tools/server)GitHubFiabilité hauteggml-org · publié 2026 (master) · consulté le 16 sept. 2026 · fiche source
- 4strix-halo-guide (README + BENCHMARKS.md)GitHubFiabilité moyenneGitHub (communauté) · hogeheer499 · publié 2026-03 → 2026-08-30 · consulté le 16 sept. 2026 · fiche source