#Claude #Codex # J'ai essayé d'exécuter un LLM local sur un GPU Ryzen Zen3 (Comparaison et analyse des performances de Qwen3-8B Heretic entre CPU et GPU) Courage, AMD, courage Vulkan Je pensais que c'était juste une GPU pour jeux, et j'avais raison Apparemment, la bande passante mémoire est le goulot d'étranglement (petite VRAM, utilisation de la mémoire principale, attente du Mac M5 Studio) Le dernier CPU d'AMD est le Zen6, donc celui-ci est un processeur de trois générations précédentes (avec GPU intégré) ---- # Comparaison et analyse des performances de Qwen3-8B Heretic entre CPU et GPU Date de mesure : 2026-11-02 / Cible : Machine Ubuntu ## Conclusion - **Le GPU (GPU intégré Radeon) est environ 2,5 fois plus rapide que le CPU pour le chargement des invites.** - **La génération de texte n'est que 1,1 à 1,2 fois plus rapide avec le GPU.** La vitesse de génération est limitée par la vitesse de transfert mémoire ; le GPU intégré partage la même mémoire que le CPU. - Dans les utilisations comme OpenClaw, où des instructions longues sont envoyées à chaque fois, **le cache des invites** a un effet beaucoup plus important que le GPU ; à partir de la deuxième invite, le temps est réduit d'environ 7 minutes à environ 1 minute. ## Environnement de mesure | Élément | Détails | |---|---| | CPU | AMD Ryzen 7 7730U (8 cœurs, 16 threads, Zen 3) | | GPU | GPU intégré AMD Radeon Graphics (Barcelo, équivalent Vega 8) | | Mémoire | 30 Go (spécification : DDR4-3200 en double canal ; non vérifié sur l'appareil réel) | | Mémoire GPU | VRAM dédiée de 512 Mo + mémoire partagée (GTT) d'environ 15,4 Go. LM Studio peut utiliser 10,59 GiB | | OS / Pilotes | Ubuntu 24.04.5 LTS, Mesa 25.2.8 (RADV) | | LM Studio | Version headless (llmster), llama.cpp 2.66.0 | | Runtime CPU | `llama.cpp-linux-x86_64-avx2` | | Runtime GPU | `llama.cpp-linux-x86_64-vulkan-avx2` (toutes les couches sur le GPU, `--gpu max`) | | Modèle | DreamFast/qwen3-8b-heretic Q4_K_M (5,03 Go) | | Paramètres de chargement | Longueur de contexte : 32768, nombre de traitements simultanés : 1 | ## Méthode de mesure - J'ai envoyé la même invite à l'API de LM Studio (`/api/v0/chat/completions`) et comparé les performances entre CPU et GPU. - Chaque condition a été exécutée deux fois. Pour la deuxième exécution, l'invite traitée est réutilisée depuis le cache ; **la vitesse de chargement utilise donc les valeurs de la première exécution**. - La vitesse de génération est basée sur `tokens_per_second` retournée par LM Studio. - La réflexion préalable à la réponse a été désactivée avec `/no_think`, et `temperature` a été fixé à 0. - Après la mesure GPU, j'ai laissé refroidir pendant 2 minutes avant de mesurer le CPU. - Les scripts et enregistrements se trouvent dans `~/bench/bench.py`, `~/bench/run.sh` et `~/bench/result.log` sur la machine Ubuntu. ## Résultats ### Résumé des comparaisons | Contenu | Élément | CPU | GPU | Ratio | |---|---|---|---|---| | Question courte (24 tokens) générant 256 tokens | Vitesse de génération | 7,3 tokens/s | 8,2 tokens/s | 1,13x | | | Temps total | 35,7 s | 31,4 s | | | Invite de 921 tokens | Vitesse de chargement | 30,5 tokens/s | 76,3 tokens/s | **2,5x** | | | Temps jusqu'au premier caractère | 30,2 s | 12,1 s | | | | Vitesse de génération | 7,0 tokens/s | 8,0 tokens/s | 1,13x | | Invite de 3 621 tokens | Vitesse de chargement | 35,4 tokens/s | 87,5 tokens/s | **2,5x** | | | Temps jusqu'au premier caractère | 102,3 s | 41,4 s | | | | Vitesse de génération | 5,9 tokens/s | 7,2 tokens/s | 1,2x | ### Détails des mesures | Méthode | Contenu | Essai | Invite | Génération | Temps total | Temps jusqu'au premier caractère | Vitesse de génération | |---|---|---|---|---|---|---|---| | GPU | Question courte | 1 | 24 | 256 | 31,4 s | 0,50 s | 8,26 | | GPU | Question courte | 2 | 24 | 256 | 31,2 s | 0,12 s | 8,23 | | GPU | Invite environ 1 000 | 1 | 921 | 32 | 16,0 s | 12,07 s | 7,97 | | GPU | Invite environ 1 000 (cache) | 2 | 921 | 32 | 4,0 s | 0,14 s | 7,98 | | GPU | Invite environ 4 000 | 1 | 3 621 | 32 | 45,7 s | 41,38 s | 7,18 || GPU | Environ 4 000 tokens de prompt | 2 (cache) | 3 621 | 32 | 4,5 secondes | 0,14 seconde | 7,22 | | CPU | Question courte | 1 | 24 | 256 | 35,7 secondes | 0,73 seconde | 7,29 | | CPU | Question courte | 2 | 24 | 241 | 32,8 secondes | 0,14 seconde | 7,36 | | CPU | Environ 1 000 tokens de prompt | 1 | 921 | 32 | 34,7 secondes | 30,21 secondes | 7,03 | | CPU | Environ 1 000 tokens de prompt | 2 (cache) | 921 | 32 | 4,6 secondes | 0,15 seconde | 6,96 | | CPU | Environ 4 000 tokens de prompt | 1 | 3 621 | 32 | 107,5 secondes | 102,30 secondes | 5,94 | | CPU | Environ 4 000 tokens de prompt | 2 (cache) | 3 621 | 32 | 5,4 secondes | 0,17 seconde | 5,96 | Les unités de prompt et de génération sont des tokens ; l'unité de vitesse de génération est des tokens/seconde. ### Correction Lors de la première mesure simplifiée, nous avons indiqué que la vitesse de génération sur GPU était environ 2,2 fois plus rapide. Cependant, cette affirmation était erronée. La valeur de 3,86 tokens/seconde comparée correspond à un prompt d’environ 14 000 tokens traité sur bot2. Comme la génération ralentit avec des prompts plus longs, il était incorrect de comparer cette valeur à celle d’une question courte. En comparant dans les mêmes conditions, la différence de génération n’est que de 1,1 à 1,2 fois. ## Pourquoi l'utilisation d'un GPU ne permet pas d'être aussi rapide que prévu ### 1. La génération est limitée par la vitesse de transfert mémoire Chaque fois qu'un LLM génère un token, il doit lire intégralement les poids du modèle depuis la mémoire. La vitesse maximale de génération est déterminée approximativement par : « vitesse de transfert mémoire ÷ taille du modèle ». | Élément | Valeur | |---|---| | Vitesse de transfert mémoire (théorique) | Environ 51 Go/s en double canal DDR4-3200 | | Quantité lue par token généré | Environ 5 Go (modèle complet) | | Limite théorique de vitesse de génération | 51 ÷ 5,03 ≒ **environ 10 tokens/seconde** | | Mesure réelle (GPU) | 8,2 tokens/seconde (environ 80 % de la limite) | | Mesure réelle (CPU) | 7,3 tokens/seconde (environ 70 % de la limite) | Le GPU intégré partage la même mémoire principale que le CPU ; sa limite est donc pratiquement identique. Même avec un GPU, il ne reste qu’un espace d’amélioration de 10 à 20 % pour approcher cette limite. Les GPU externes disposent d’une mémoire dédiée et rapide, ce qui élève considérablement cette limite. | GPU | Vitesse de transfert mémoire | Rapport avec cet appareil Ubuntu | |---|---|---| | GPU intégré de cet appareil Ubuntu | Environ 51 Go/s (partagé avec le CPU) | 1x | | RTX 4060 | Environ 272 Go/s | Environ 5x | | RTX 4090 | Environ 1 008 Go/s | Environ 20x | ### 2. Le chargement du prompt dépend de la puissance de calcul, mais le GPU intégré est peu puissant Lors du chargement du prompt, plusieurs tokens sont traités simultanément ; la vitesse dépend donc davantage de la puissance de calcul que de la mémoire. C’est ici que le GPU apporte son avantage : en pratique, une accélération de 2,5 fois a été observée. Cependant, ce GPU présente les contraintes suivantes qui limitent cette accélération à un facteur de 2,5 : | Contrainte | Détails | |---|---| | Nombre réduit d’unités de calcul | Seulement 8 unités. Estimé à environ 2 TFLOPS en simple précision — quelques dizaines de fois moins qu’un GPU gaming | | Absence de circuits dédiés aux opérations matricielles | Pas de circuits spécialisés comme les Tensor Cores d’NVIDIA pour l’IA | | ROCm non pris en charge | La plateforme de calcul AMD ROCm ne prend pas officiellement en charge ce GPU intégré. Il fonctionne via Vulkan générique | Pour un modèle de 8 milliards de paramètres, environ 16 GFLOP sont nécessaires pour traiter un token. Avec une puissance théorique de ~2 TFLOPS, la limite théorique serait d’environ 120 tokens/seconde. Les mesures réelles (76 à 88 tokens/seconde) représentent environ 6 à 7 % de cette limite. ### 3. Plus le prompt est long, plus la vitesse diminue À mesure que le contexte s’allonge, chaque token doit référencer davantage de tokens précédents, ce qui ralentit à la fois le chargement et la génération. | Condition | Vitesse de chargement | Vitesse de génération | |---|---|---| | GPU, prompt d’environ 1 000 tokens | 76 tokens/seconde | 8,0 tokens/seconde | | GPU, prompt d’environ 3 600 tokens | 88 tokens/seconde | 7,2 tokens/seconde | | GPU, OpenClaw (15 686 tokens), premiers 2 048 tokens | 78,7 tokens/seconde | — | | GPU, OpenClaw (15 686 tokens), moyenne globale | 44,1 tokens/seconde | 5,1 tokens/seconde | | CPU, OpenClaw (14 021 tokens) | Environ 19,5 tokens/seconde | 3,86 tokens/seconde |Jusqu'à 3 600 jetons, le chargement s'est en fait accéléré grâce à la capacité accrue de traitement par lot. Au-delà de 15 000 jetons, le débit est tombé jusqu'à 46 jetons/seconde en fin de traitement. ## Vérification du cache sur OpenClaw (bot2 mei) J'ai envoyé deux messages consécutifs à une session de vérification en utilisant Qwen3 exécuté sur GPU. | Élément | Premier message | Deuxième message | |---|---|---| | Prompt envoyé par OpenClaw | 15 686 jetons | 15 744 jetons | | Jetons réellement chargés | 15 686 (tous) | **135 (uniquement les nouveaux)** | | Durée de chargement | 356,1 secondes | **6,1 secondes** | | Génération | 247 jetons, 48,1 secondes (5,11 jetons/seconde) | 249 jetons, 48,5 secondes (5,11 jetons/seconde) | | Total | **410 secondes** | **58 secondes** | - OpenClaw envoie systématiquement le même texte en début d'instruction ; le deuxième message a donc réutilisé directement la partie déjà traitée (98 %). - La majeure partie du délai du deuxième message provient de l'analyse d'environ 240 jetons. Même avec `--thinking off`, l'analyse n'a pas été désactivée. Si elle pouvait être arrêtée, le temps total devrait tomber à environ 10 secondes. - Le cache ne disparaît pas avec le temps. Il est supprimé uniquement lorsque le modèle est déchargé, lorsqu'une autre tâche intervient (limite de traitement simultané à 1), ou lorsque la conversation est compressée. ## Options pour accélérer Étant donné que la vitesse de transfert mémoire ne peut pas être modifiée, réduire la quantité chargée par jeton est la méthode la plus efficace. | Méthode | Effet attendu | Remarques | |---|---|---| | Utiliser le cache du prompt | Le chargement des deuxième et suivants messages prend quelques secondes (vérifié) | Peut être effacé par une interruption ou une compression | | Désactiver la réflexion de Qwen3 | Réduction d'environ 48 secondes par message | La qualité des réponses peut légèrement diminuer | | Passer à Qwen3-30B-A3B (type MoE) | Seuls environ 3 Go de poids sont utilisés par jeton ; la génération devrait être 2 à 3 fois plus rapide, avec une meilleure intelligence | Taille d'environ 18 Go ; ne tient pas dans les 10,6 GiB de la GPU ; une partie doit être traitée par le CPU. Version non censurée non confirmée | | Utiliser un modèle plus petit (Qwen3-4B) | Génération environ deux fois plus rapide | Intelligence réduite | | Utiliser la décodage spéculatif | Utiliser Qwen3-0.6B comme brouillon ; génération 1,3 à 2 fois plus rapide | Effet variable selon le contenu | | Appliquer une quantisation plus agressive (Q3, etc.) | Amélioration de 10 à 20 % | Précision réduite | | Raccourcir les instructions | Réduction du chargement du premier message et après effacement du cache | Suppression de certaines fonctionnalités | Les effets indiqués dans ce tableau, sauf pour le cache du prompt, sont des estimations et n'ont pas été mesurés expérimentalement. ## État actuel (au 2026-11-03) | Élément | État | |---|---| | LM Studio | Arrêté. Démarrage automatique désactivé | | Runtime sélectionné | Vulkan (GPU) | | bot2 (mei) | gpt-5.4-mini | | Port de transfert pour bot2 | Arrêté. Démarrage automatique désactivé | | Configuration bot2 pour Qwen3 | `~/.openclaw-bot2/openclaw.json.bak-qwen3-active-*` |