Dimensionner la Box pour un cabinet

L'essentiel

• Dimensionner, c'est fixer trois choses : le modèle (donc le débit par utilisateur), le nombre de slots -np (donc le nombre de requêtes simultanées avant file d'attente) et le contexte total -c (donc la mémoire du KV cache).
• Le profil d'usage d'un cabinet mélange deux charges très différentes : requêtes courtes (quelques centaines de tokens, TTFT quasi nul) et analyses de dossiers (10 000 à 50 000 tokens de prefill, TTFT de plusieurs dizaines de secondes).
• Objectifs de confort proposés (hypothèses) : TTFT p95 sous 3 s pour une question courte, génération d'au moins 10 t/s par utilisateur, TTFT sous 60 s pour un dossier de 20 000 tokens.
• Trois scénarios sont esquissés ; aucun n'est validé par une mesure sur notre machine.

Profil d'usage d'un cabinet

Hypothèses de travail pour un cabinet de 5 à 10 personnes, à confronter au journal d'un POC :

Les chiffres de tokens sont des ordres de grandeur non sourcés (un feuillet juridique ≈ 400 à 600 tokens, hypothèse).

Calcul de charge

Latence d'une requête = TTFT + TPOT × tokens générés ¹.

TTFT ≈ tokens du prompt ÷ débit de prefill. Débits de prefill publiés sur Strix Halo (pp512, mono-séquence) : gpt-oss-120b 727 t/s en Vulkan ³ ; Qwen3-30B-A3B 1 115 à 1 345 t/s ⁴ ; Llama 70B environ 95 t/s ⁵. Le débit de prefill baisse quand le contexte se remplit (pp à profondeur 65k : 294 t/s pour gpt-oss-120b ³).

Estimations de TTFT pour un dossier de 20 000 tokens, utilisateur seul : gpt-oss-120b ≈ 30 à 70 s ; Qwen3-30B-A3B ≈ 15 à 20 s ; Llama 70B ≈ 3,5 min. Pendant ce prefill, les autres slots ralentissent (le prefill est compute-bound) : ampleur non mesurée.

Génération : débit par utilisateur = débit agrégé ÷ slots actifs, avec un agrégé qui croît de façon sous-linéaire (mesuré : 59 → 131 → 162 t/s à 1/4/8 slots sur un 35B-A3B ³). Réponse de 800 tokens à 20 t/s : 40 s ; à 10 t/s : 80 s.

Mémoire : poids + KV du contexte total + marge. Voir KV cache.

Marge : dimensionner pour la pointe plausible (3 utilisateurs actifs si 10 comptes, hypothèse Q-001), pas pour la moyenne, et prévoir -np supérieur au nombre d'actifs attendus pour absorber les rafales sans file d'attente.

Objectifs de service proposés

Scénarios

Scénario A : petit cabinet, usage conversationnel

5 comptes, 1 à 2 actifs, requêtes courtes et RAG, rares dossiers longs.

• Modèle : gpt-oss-120b (qualité) ; débit attendu 50 t/s seul, 35 à 45 t/s à deux (hypothèse).
• -np 4, -c 128k au total (32k par slot en moyenne), --kv-unified, KV q8_0 : ≈ 59 + 5 Go (estimation).
• Reste ≈ 30 à 40 Go pour embeddings, reranker, base vectorielle, interface.
• Risque : un dossier de 30 000 tokens fige les autres pendant son prefill (≈ 45 s à 727 t/s, estimation).

Scénario B : cabinet de 10, usage mixte

10 comptes, 2 à 3 actifs, dossiers longs quotidiens.

• Option B1 : gpt-oss-120b avec -np 8, contexte total 256k, KV q8_0 (≈ 59 + 10 Go, estimation). Débit par utilisateur à 3 actifs : hypothèse 30 à 40 t/s.
• Option B2 : Qwen3-30B-A3B ou Qwen3.5-35B-A3B si la qualité suffit : plus rapide (mesuré 20 t/s par utilisateur à 8 slots pleins), prefill 1,5 à 2 fois plus rapide, mémoire réduite.
• Choix entre B1 et B2 : par test de qualité en français sur les dossiers du cabinet, pas par les seuls débits.

Scénario C : deux modèles, deux instances

10 comptes, pointes à 5 actifs, ou besoin de protéger l'interactif des traitements longs.

• Instance 1 : modèle rapide (Qwen3-30B-A3B, ≈ 20 Go) pour le chat courant et le RAG, -np 8.
• Instance 2 : gpt-oss-120b (≈ 60 Go) pour les analyses de dossiers et les lots, -np 2, contexte long.
• Total ≈ 90 à 100 Go : à la limite de la mémoire allouable (Q-011) ; incompatible avec un gros modèle d'embeddings.
• Avantage : contourne l'absence de priorité de file dans llama-server ⁷. Alternative : évaluer vLLM si son ordonnanceur suffit avec une seule instance.

Ce qu'il faudra mesurer

1. Courbe -np 1, 2, 3, 5, 8, 10 pour gpt-oss-120b et Qwen3-30B-A3B : t/s par utilisateur, agrégé, TTFT p50/p95 (protocole dans Méthodologie).
2. Effet d'un prefill de 20 000 tokens sur le TTFT et le débit des autres slots.
3. Mémoire réellement allouée pour chaque scénario, avec et sans --kv-unified.
4. Journal d'un POC : nombre réel d'utilisateurs actifs par tranche de 5 minutes, distribution des longueurs de prompt.
5. Qualité française comparée gpt-oss-120b vs Qwen3-30B-A3B sur les dossiers du cabinet, pour arbitrer B1/B2.

• 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