Aller au contenu
Tag

#multi-utilisateurs

49 entrée(s) portent ce tag.

Pages

13

Architecture générale de la Box IAArchitecture · Vue simple et vue complète de la Box : couches, composants candidats, principes d'architecture et flux d'une requête, du navigateur à la réponse citée.Le laboratoire : lire et alimenter les benchmarksBenchmarks · Ce que la collection benchmarks enregistre, comment lire une fiche (TTFT, tok/s, pp, p50/p95), d'où viennent les données (nôtres ou publiées), comment en ajouter une et quelles séries de comparaison sont prévues.Méthodologie de benchmark reproductibleBenchmarks · Protocole du laboratoire : llama-bench, llama-batched-bench, vllm bench serve et autres outils de charge, métriques standard, prompts de référence, grille 1/2/3/5/10 utilisateurs, conditions à consigner et pièges.Identité : comptes, groupes, SSO, MFAIdentité · Comment les utilisateurs de la Box sont identifiés (SSO OIDC via Entra ID, Google Workspace, Authentik ou Keycloak), authentifiés (MFA, passkeys) et comment leurs groupes deviennent des rôles Box puis des ACL RAG.Inférence : panorama des moteursInférence · Comparaison des moteurs de serving (llama-server, Ollama, LM Studio, vLLM, SGLang, Lemonade) pour un Strix Halo sous Linux, et recommandation initiale prudente : llama-server d'abord, vLLM à évaluer.llama.cpp et llama-serverInférence · Le moteur de départ de la Box : slots, contexte partagé, KV cache quantifié, flash attention, métriques Prometheus, images Docker ROCm/Vulkan et flags connus pour gfx1151.Ollama, LM Studio, Lemonade : les moteurs « faciles »Inférence · Trois surcouches de llama.cpp orientées simplicité : variables de parallélisme d'Ollama, requêtes concurrentes de LM Studio, Lemonade porté par AMD ; limites pour un serveur multi-utilisateurs.vLLM et SGLang sur Strix HaloInférence · État du support gfx1151 (doc officielle vs images communautaires), avantages pour le multi-utilisateurs, coûts en mémoire et complexité, et critères pour basculer depuis llama-server.Interface IA : comparatif et choix initialInterface IA · Comparaison des interfaces de chat auto-hébergées (Open WebUI, LibreChat, AnythingLLM, Onyx, Lobe Chat, Dify, RAGFlow, Kotaemon, Khoj, Msty) sur la licence, le RAG, les permissions, le SSO et la maturité ; Open WebUI retenu pour le POC sous conditions.Dimensionner la Box pour un cabinetMulti-utilisateurs · Méthode pour passer d'un profil d'usage (requêtes courtes, analyses de dossiers longs) à un choix de modèle, de slots et de contexte, avec trois scénarios et la liste de ce qu'il faudra mesurer.Multi-utilisateurs : servir 5 à 10 personnes sur une seule machineMulti-utilisateurs · Pourquoi une machine à 256 Go/s est bornée en génération, ce que le batching et les MoE y changent, ce que les mesures publiées disent, et ce qu'il reste à mesurer avant de promettre un nombre d'utilisateurs.KV cache : calcul et dimensionnementMulti-utilisateurs · Formule du KV cache, effet de GQA et MLA, quantification q8_0/q4_0, tableau d'estimations pour gpt-oss-120b, Qwen3-30B-A3B et Llama 70B à 8k/32k/128k, et impact du nombre de slots sur la mémoire.Permissions et confidentialité dans le RAGRAG · Comment garantir qu'un utilisateur ne récupère jamais un passage d'un dossier auquel il n'a pas accès : ACL par chunk, filtre côté serveur, double barrière application + moteur, audit et tests.

Benchmarks

6

Qwen3.5-122B-A10B Q4_K_XL — llama.cpp b10333 ROCm 7.14 — 13,6 t/s, TTFT 1,78 s (Soothill)Benchmark · Côté llama.cpp du comparatif vLLM / SGLang / llama.cpp : 13,6 t/s à 1 client, 17,9 t/s agrégés à 2 clients, TTFT 1,775 s sur un MoE de 122 Md.Qwen3.5-122B-A10B GPTQ — vLLM 0.26.0 ROCm 7.14 — 10,3 t/s, TTFT 1,06 s (Soothill)Benchmark · Côté vLLM du comparatif : 10,3 t/s à 1 client, 16,2 t/s agrégés à 2 clients, TTFT 1,056 s ; plus lent en génération mais 40 % plus rapide au premier token que llama.cpp.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 1 — 59,2 t/s, TTFT 117 ms (hogeheer)Benchmark · Point de référence à 1 slot de la seule courbe de montée en charge publiée sur Strix Halo : 59,2 t/s et 117 ms de TTFT.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 16 — 10,4 t/s par utilisateur, 166 agrégés (hogeheer)Benchmark · À 16 slots, l'agrégé plafonne (166 t/s, +2,5 % par rapport à 8 slots) et chaque utilisateur tombe à 10,4 t/s avec 547 ms de TTFT.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 4 — 32,7 t/s par utilisateur, 130,8 agrégés (hogeheer)Benchmark · À 4 slots, chaque utilisateur reçoit 32,7 t/s (130,8 t/s agrégés, 2,2 fois le mono) avec un TTFT de 237 ms.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 8 — 20,3 t/s par utilisateur, 162 agrégés (hogeheer)Benchmark · À 8 slots, 20,3 t/s par utilisateur et 162 t/s agrégés (2,7 fois le mono), TTFT 307 ms : le point d'équilibre retenu par l'auteur.

Sources

10

Anyscale — How continuous batching enables 23x throughput in LLM inferenceSource · L'inférence LLM est bornée par les entrées-sorties mémoire ; continuous batching = ordonnancement par itération ; jusqu'à 23 fois le débit avec vLLM.Databricks — LLM Inference Performance Engineering: Best PracticesSource · Définitions TTFT, TPOT, latence = TTFT + TPOT × tokens ; débit = tokens de sortie par seconde tous utilisateurs ; MBU = bande passante atteinte / band.llama.cpp — README de llama-batched-benchSource · Outil de mesure multi-séquences : options -npp, -ntg, -npl, -pps ; deux modes (prompt partagé ou non) ; colonnes PP, TG, B, N_KV, T_PP, S_PP, T_TG, S_.Discussion llama.cpp #18308 — paramètres optimaux pour l'inférence parallèleSource · Un utilisateur (GPU NVIDIA) observe peu de gain au-delà de -np 4 ; les mainteneurs attribuent la sous-utilisation GPU à l'échantillonnage CPU et renvo.llama.cpp — README de llama-server (tools/server)Source · Documentation de référence de llama-server : options -np, -c, --kv-unified, -cb, --cache-type-k/v, -fa, --metrics, --slots ; endpoints /v1/chat/comple.LM Studio — Parallel RequestsSource · Requêtes parallèles via le continuous batching de llama.cpp ; « Max Concurrent Predictions » à 4 par défaut ; nécessite le runtime GGUF llama.cpp v2.0.NVIDIA — Mastering LLM Techniques: Inference OptimizationSource · Formule du KV cache par token = 2 × couches × (têtes × dim_tête) × octets ; exemple Llama 2 7B 4096 tokens environ 2 Go ; prefill = matrice-matrice (c.Ollama — FAQ officielleSource · Variables OLLAMA_NUM_PARALLEL (défaut 1), OLLAMA_MAX_LOADED_MODELS (3 par GPU), OLLAMA_MAX_QUEUE (512), OLLAMA_CONTEXT_LENGTH (4096 par défaut), OLLAM.Soothill — SGLang vs vLLM vs llama.cpp on Strix HaloSource · GMKtec EVO-X3, vLLM 0.26.0, SGLang 0.5.17, llama.cpp b10333, ROCm 7.14.0 : Qwen3.5-0.8B BF16 vLLM 86,6 (C=1), 246,5 (C=4), 311,6 t/s (C=8) ; llama.cpp.vLLM — commande vllm bench serveSource · Options --backend openai-chat, --dataset-name, --num-prompts, --max-concurrency, --request-rate, --percentile-metrics ttft,tpot,itl,e2el, --metric-per.

Glossaire

9

BatchingTerme · Regroupement de plusieurs requêtes ou de plusieurs tokens dans un même passage de calcul pour mieux utiliser le processeur graphique.Contexte partagé (prompt cache)Terme · Réutilisation, entre plusieurs requêtes, du KV cache déjà calculé pour un préfixe commun (consignes système, début de conversation), afin d'éviter de retraiter les mêmes tokens.Continuous batchingTerme · Technique de serveur d'inférence qui insère de nouvelles requêtes dans le lot en cours à chaque étape de génération, au lieu d'attendre que toutes les séquences du lot soient terminées.Fenêtre de contexteTerme · Nombre maximal de tokens qu'un modèle peut prendre en compte à la fois, prompt et réponse compris.KV cacheTerme · Mémoire dans laquelle le modèle conserve, pour chaque token déjà traité, les clés et valeurs de l'attention afin de ne pas les recalculer à chaque nouveau token généré.llama-serverTerme · Serveur HTTP de llama.cpp qui charge un modèle GGUF et expose une API compatible OpenAI (chat, complétions, embeddings, reranking) avec traitement parallèle par slots.Slot (llama-server)Terme · Dans llama-server, emplacement de traitement capable de servir une conversation à la fois ; le nombre de slots fixe le nombre de requêtes traitées en parallèle et partage la fenêtre de contexte totale entre elles.Tokens par secondeTerme · Vitesse à laquelle un modèle produit sa réponse, exprimée en nombre de tokens générés par seconde pour un utilisateur donné.TTFT (temps jusqu'au premier token)Terme · Délai entre l'envoi d'une requête et l'apparition du premier token de la réponse, qui correspond essentiellement au traitement du prompt.