Ces derniers jours, j’ai transformé un petit benchmark LLM maison en un outil beaucoup plus complet pour tester ma stack locale sur AMD Radeon Pro W7800 48 Go.
L’objectif de départ était simple : mesurer proprement un endpoint OpenAI-compatible sans dépendre de Python, Node ou d’une interface web. Le résultat est devenu un vrai outil Windows natif en Delphi/VCL, avec stockage SQLite, rapports PDF, télémétrie SSH et comparaison de backends.
Le logiciel mesure maintenant notamment :
- TTFT, TPOT et débit de génération en tokens/s ;
- performances en séquentiel et en concurrence ;
- évolution du prefill et du decode avec la taille du contexte ;
- cold start, warm start et cache de prompt ;
- jitter du streaming SSE ;
- déterminisme ;
- support tools / JSON / vision ;
- robustesse API ;
- stabilité sur plusieurs minutes ;
- précision en long contexte avec un test “needle in a haystack”.
Une des évolutions les plus importantes a été d’ajouter la collecte automatique de l’environnement distant via SSH. Le benchmark peut maintenant enregistrer avec chaque session :
- OS et kernel ;
- CPU et mémoire système ;
- GPU et VRAM ;
- ROCm / HIP ;
- Mesa et Vulkan ;
- CUDA / NVIDIA si la machine en utilise ;
- VBIOS ;
- paramètres kernel ;
- configuration réelle du service
llama-server; - options comme flash-attention, cache KV, batch, ubatch, parallel, etc.
En parallèle, une télémétrie matérielle est échantillonnée pendant les tests : charge GPU, température, puissance, fréquence, VRAM, charge Linux et RAM utilisée. Cela permet de corréler une baisse de performances avec un éventuel throttling ou un changement de comportement du backend.
J’ai également corrigé plusieurs pièges méthodologiques apparus pendant les premiers runs. Le plus important concernait les tests de contexte : certaines répétitions pouvaient bénéficier du cache de préfixe de llama.cpp, ce qui mélangeait mesures froides et chaudes. Le benchmark utilise maintenant des prompts différents dès le début pour garantir de vraies mesures “cold”, tandis que les comportements de cache sont testés séparément.
Autre correction intéressante : le test de précision en long contexte avait un budget de sortie trop faible pour un modèle “thinking”, ce qui produisait des faux échecs. Le budget a été augmenté et le test est maintenant plus représentatif.
Trois backends testés sur la même machine
J’ai ensuite lancé trois séries complètes sur la W7800 avec le même modèle Qwen 27B Q8 :
- configuration ROCm optimisée de départ ;
- ROCm 10 / Lemonade ;
- Vulkan / RADV.
Le résultat est assez intéressant : Vulkan est globalement le plus rapide en decode interactif, avec un avantage net sur les scénarios courts, les générations longues et le débit soutenu. ROCm 10 reste très compétitif sur certains gros contextes et semble particulièrement intéressant sur certains scénarios de prefill.
Par exemple, Vulkan atteint environ 46,9 tok/s en short chat et autour de 40 tok/s en génération soutenue, alors que la configuration ROCm de départ reste plutôt dans les 34–43 tok/s selon les scénarios. ROCm 10, de son côté, montre de bons résultats sur les gros prompts et certains niveaux de contexte.
Ce qui m’intéresse le plus n’est pas seulement “qui gagne”, mais le fait de pouvoir enfin comparer les stacks de manière reproductible : même GPU, même modèle, mêmes tests, même contexte, même télémétrie, et environnement logiciel enregistré avec le rapport.
Au final, ce petit projet est devenu un véritable outil de qualification et de non-régression pour LLM local. C’est particulièrement utile quand on teste de nouveaux drivers, des builds ROCm spécifiques, Vulkan, Lemonade ou différentes versions de llama.cpp.
