Lab
Benchmarks
Laboratoire : mesures enregistrées et comparables.
L'essentiel
- La collection benchmarks est la mémoire chiffrée du projet : chaque fiche est une mesure (une machine, un runtime, un modèle, une charge, un résultat), jamais une opinion.
- Les fiches ont deux origines :
ours(mesuré par nous, reproductible avec le protocole) et publiées (independent,community,vendor), avecsourceUrlobligatoire. - Les composants
<Benchmarks />et<CapacityMatrix />lisent cette collection : une cellule vide signifie « pas de mesure », jamais « impossible ». - Au 16 septembre 2026, toutes les fiches sont des mesures publiées par des tiers, sur des machines Strix Halo équivalentes mais pas toujours un Framework Desktop. Aucune mesure
oursn'existe encore.
Ce qu'on enregistre
Chaque fiche décrit une mesure unique avec, dans son frontmatter : la date, la machine (hardware), le système et le noyau, le runtime et sa version, le modèle (model, slug de la collection modèles) et sa quantification, la taille de contexte, le type de prompt, le nombre d'utilisateurs simultanés, les tokens générés, le TTFT, les tokens par seconde en génération et en prompt processing, la mémoire, la puissance et la température si disponibles, le résultat (ok, degraded, failed), l'origine et la série. Le corps précise les conditions exactes, les écarts par rapport au protocole et la lecture qu'on en fait. Le gabarit commenté est content/benchmarks/_template.md (ignoré par le site).
Comment lire un benchmark
| Champ | Signification | Piège |
|---|---|---|
promptTokensPerSecond (pp) | vitesse de lecture du prompt (prefill) ; pp512 = mesure sur 512 tokens 3 | dépend fortement du backend et de la profondeur de contexte |
tokensPerSecond (tg) | vitesse de génération ; par utilisateur si concurrentUsers est supérieur à 1 | l'agrégé (somme des slots) est donné dans le corps, pas dans ce champ |
ttftMs | délai avant le premier token 2 | llama-bench ne le mesure pas ; il vient d'un test de charge HTTP |
concurrentUsers | slots ou clients actifs pendant la mesure | 1 par défaut ; les publications utilisent souvent 4, 8, 16 |
contextSize | contexte configuré, pas forcément rempli | une mesure à contexte vide (d0) est plus rapide qu'à 32k remplis |
| p50 / p95 | médiane et 95e percentile d'une latence sur N requêtes 1 | une moyenne cache les requêtes lentes ; ne promettre que des p95 |
origin | ours, independent, community, vendor, estimate | ne jamais comparer une estimation à une mesure |
Deux mesures ne se comparent que si machine, modèle, quantification, contexte, nombre d'utilisateurs et méthode sont identiques. Le champ series regroupe les fiches conçues pour être comparées.
Origine des données
ours: mesuré sur notre machine avec le protocole publié ; c'est le seul niveau qui autorise un engagement envers un client.independent: benchmark publié par un tiers avec conditions détaillées (Level1Techs, Soothill, visorcraft…).community: retour de forum, guide GitHub, blog personnel ; conditions souvent partielles.vendor: chiffre constructeur ou éditeur.estimate: calcul (formule bande passante ÷ poids) ; jamais dans la matrice de capacité.
Quand la machine source n'est pas un Framework Desktop mais un autre Strix Halo 128 Go (Beelink GTR9 Pro, GMKtec EVO-X2/X3), la fiche utilise le slug framework-desktop-ryzen-ai-max-395 et le précise dans son corps : même puce, même mémoire, mais refroidissement et BIOS différents.
Comment ajouter un benchmark
- Copier
content/benchmarks/_template.mdsous le nomAAAA-MM-JJ-<modele>-<runtime>-<source>.md. - Remplir tous les champs connus ; laisser vides les inconnus plutôt que d'inventer.
origin: oursseulement si le protocole de la méthodologie a été suivi ; sinonsourceUrlobligatoire.- Rattacher à une
seriesexistante si la mesure est comparable ; sinon en créer une et la documenter ci-dessous. npm run check:contentpuis relire la fiche modèle liée : mettre à jour sa section « Performances publiées » si nécessaire.
Détails de syntaxe et champs dans le CONTENT-GUIDE du dépôt.
Séries de comparaison
| Série | Question | Fiches |
|---|---|---|
strix-halo-gpt-oss-120b | débit de gpt-oss-120b selon runtime et backend | filtre « Série » = strix-halo-gpt-oss-120b |
strix-halo-multi-user | montée en charge de 1 à 16 slots sur un MoE moyen | filtre « Série » = strix-halo-multi-user |
strix-halo-dense-70b | plafond d'un dense de 70 Md | filtre « Série » = strix-halo-dense-70b |
strix-halo-qwen3-30b-a3b | Vulkan vs ROCm sur un MoE 30B-A3B | filtre « Série » = strix-halo-qwen3-30b-a3b |
strix-halo-vllm-vs-llamacpp | vLLM contre llama.cpp à charge égale | filtre « Série » = strix-halo-vllm-vs-llamacpp |
strix-halo-large-moe | très gros MoE fortement quantifiés | filtre « Série » = strix-halo-large-moe |
Le tableau complet, filtrable par série, modèle, machine et runtime, est affiché sous cette introduction. Deux séries méritent un coup d'œil graphique :
Couleur = origine de la donnée (bleu foncé : mesuré par nous ; vert : indépendant ; bleu : constructeur ; gris : communauté ; ambre : estimation).
Couleur = origine de la donnée (bleu foncé : mesuré par nous ; vert : indépendant ; bleu : constructeur ; gris : communauté ; ambre : estimation).
Séries prévues quand nos mesures existeront : framework-ours-baseline (llama-bench sur 4 modèles × 2 backends), framework-ours-multi-user (1/2/3/5/10 clients HTTP), framework-ours-long-context (pp à profondeur 4k/32k/64k).
Ce qu'il reste à mesurer
- Benchmark gpt-oss-120b à 1 utilisateur : Vulkan vs ROCm, contexte court et longSur le Framework Desktop, gpt-oss-120b MXFP4 atteint au moins 50 t/s en tg128 avec l'un des deux backends, et le prefill pp512 dépasse 500 t/s ; la génération baisse de moins de 20 % à 32k de profondeur.À 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
- Comparer les modèles d'embeddings sur du français juridiqueSur des questions juridiques en français, bge-m3 et multilingual-e5-large atteignent un recall@10 comparable ; le reranker bge-reranker-v2-m3 apporte un gain de MRR supérieur à celui du changement de modèle d'embeddings ; la recherche hybride (BM25 + vecteurs, RRF) bat chacune des deux recherches seules.À tester
- Comparer la qualité en français des modèles candidatsgpt-oss-120b et Mistral Small 4 produisent un français juridique jugé acceptable par un avocat dans plus de 80 % des cas ; Qwen3-30B-A3B est nettement en retrait sur la rédaction mais équivalent sur la synthèse avec passages fournis ; les modèles de 7 à 22 Md (Lucie, EuroLLM) ne suffisent pas pour l'assistant principal. Le taux d'hallucination de citations est le critère discriminant.À tester
- Comparer Vulkan/RADV et ROCm/HIP dans llama.cppVulkan/RADV est plus rapide en génération (+15 à +30 %) et ROCm/HIP plus rapide en prompt processing au-delà de quelques milliers de tokens ; pour les prompts RAG de la Box (4k à 16k tokens), la différence de temps de réponse total est inférieure à 20 % et la stabilité départage les deux.À 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
- Mesurer la consommation et le bruit en inférenceAu repos le système consomme 10 à 15 W ; en inférence gpt-oss-120b mono-utilisateur 100 à 130 W ; sous 4 slots 120 à 150 W. Le bruit reste sous 42 dBA à 1 m en charge avec le ventilateur Noctua, ce qui autorise une installation dans un bureau.À tester
- Mesurer la mémoire GPU allouable sur le Framework DesktopAvec BIOS 3.06, UMA à 512 Mo, noyau 6.18.4+ et ttm.pages_limit fixé via amd-ttm, le GPU peut allouer au moins 100 Go de façon stable ; gpt-oss-120b MXFP4 se charge avec 32k tokens de contexte pour 4 slots.À tester
Couleur = origine de la donnée (bleu foncé : mesuré par nous ; vert : indépendant ; bleu : constructeur ; gris : communauté ; ambre : estimation).
17 / 17
| 16 sept. 2026 | gpt-oss-120b MXFP4 — llama.cpp ROCm 7.2.0 (fork Lychee b8182) — 51,1 t/s (Pellegrini) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp fork Lychee-Technology b8182, ROCm 7.2.0 | 1 | 51,1 |
| 09 sept. 2026 | DeepSeek-R1-Distill-Qwen-32B Q4_K_M — llama.cpp HIP — 11,2 t/s (praveentechworld) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp HIP, ROCm 6.3+ (build non relevé) | 1 | 11,2 |
| 09 sept. 2026 | Llama 3.3 70B Q4_K_M — llama.cpp HIP ROCm 6.3+ — 5,1 t/s, contexte 64k (praveentechworld) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp HIP, ROCm 6.3+ (build non relevé) | 1 | 5,1 |
| 30 août 2026 | Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 1 — 59,2 t/s, TTFT 117 ms (hogeheer) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama-server b9010 (Vulkan RADV) | 1 | 59,2 |
| 30 août 2026 | Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 16 — 10,4 t/s par utilisateur, 166 agrégés (hogeheer) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama-server b9010 (Vulkan RADV) | 16 | 10,4 |
| 30 août 2026 | Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 4 — 32,7 t/s par utilisateur, 130,8 agrégés (hogeheer) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama-server b9010 (Vulkan RADV) | 4 | 32,7 |
| 30 août 2026 | Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 8 — 20,3 t/s par utilisateur, 162 agrégés (hogeheer) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama-server b9010 (Vulkan RADV) | 8 | 20,3 |
| 10 août 2026 | Qwen3.5-122B-A10B Q4_K_XL — llama.cpp b10333 ROCm 7.14 — 13,6 t/s, TTFT 1,78 s (Soothill) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp b10333, ROCm 7.14.0 | 1 | 13,6 |
| 10 août 2026 | Qwen3.5-122B-A10B GPTQ — vLLM 0.26.0 ROCm 7.14 — 10,3 t/s, TTFT 1,06 s (Soothill) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · vLLM 0.26.0, ROCm 7.14.0 | 1 | 10,3 |
| 03 août 2026 | Qwen3-Coder-30B-A3B Q4_K_S — llama.cpp ROCm — 73,7 t/s, pp 1 345 t/s (Soothill) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp b10085 / b10216 (ROCm) | 1 | 73,7 |
| 03 août 2026 | Qwen3-Coder-30B-A3B Q4_K_S — llama.cpp Vulkan — 97,7 t/s (Soothill) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp b10085 / b10216 (Vulkan) | 1 | 97,7 |
| 21 juil. 2026 | gpt-oss-120b — LM Studio (runtime ROCm llama.cpp) — environ 30 t/s (MindStudio) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · LM Studio runtime llama.cpp ROCm (version non relevée) | 1 | 30 |
| 07 mai 2026 | gpt-oss-120b MXFP4 — llama.cpp Vulkan RADV b9049 — 55,6 t/s (hogeheer) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp b9049 (Vulkan RADV) | 1 | 55,6 |
| 16 févr. 2026 | gpt-oss-120b Q4_K_M — llama-server ROCm — 53,4 t/s (visorcraft) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama-server ROCm (version non relevée) | 1 | 53,4 |
| 16 févr. 2026 | Qwen3-235B-A22B Q3_K_M — llama.cpp ROCm — 17,2 t/s, pp 101 t/s (visorcraft) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp ROCm (build non relevé) | 1 | 17,2 |
| 22 juil. 2025 | Llama 3.3 70B (Shisa V2) Q4_K_M — llama.cpp b5863 — 5,0 t/s (lhl, Framework Desktop) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp b5863 (TheRock 7.0 nightlies) | 1 | 5 |
| 22 juil. 2025 | Qwen3-30B-A3B Q4 — llama.cpp b5863 — 72,0 t/s (lhl, Framework Desktop) Framework Desktop (Ryzen AI Max+ 395, 128 Go) · llama.cpp b5863 | 1 | 72 |
Ajouter un(e) benchmark : créer un fichier dans content/benchmarks/ (voir README).