APU 96 Go vs RTX 4080 : quel LLM local tourne sur quelle machine ?

$ git log --oneline | head -1
3313daf ai-bench: finitions + image ROCm

Trente-sept commits, deux machines de lab, six modèles, trois répétitions par mesure. Voilà ce qu’il nous a fallu pour répondre proprement à une question qu’on nous pose de plus en plus souvent : pour faire tourner un LLM en local, vaut-il mieux une carte graphique dédiée avec peu de VRAM, ou un APU avec beaucoup de mémoire unifiée ?

La réponse courte : ça dépend de la taille du modèle, et le point de bascule est très net. La réponse longue, c’est cet article, avec les chiffres, la méthode, et les endroits où nous nous sommes plantés.

Les deux machines

Deux machines de lab Datacampus, choisies parce qu’elles incarnent les deux philosophies du moment. D’un côté un mini-PC autour d’un AMD Ryzen AI MAX+ 395 (Strix Halo), dont les 128 Go de LPDDR5X sont partagés entre le processeur et le GPU intégré Radeon 8060S : nous en avons alloué 96 Go au GPU dans le BIOS. De l’autre, une tour classique avec un Intel Core i7-14700KF, 64 Go de RAM et une NVIDIA RTX 4080 à 16 Go de GDDR6X.

Un point méthodologique avant les chiffres, parce qu’il conditionne tout le reste : les deux machines ont fait tourner exactement les mêmes fichiers de modèle, vérifiés par empreinte SHA-256. Même quantification, mêmes prompts, même nombre de tokens générés (256), llama.cpp des deux côtés (build HIP natif sur l’APU, build CUDA sur la tour), lancé avec les mêmes options de base (-fa on -ngl 99 -ub 2048). Quand un modèle ne tenait pas dans les 16 Go de la 4080, nous l’avons laissé déborder en RAM, avec le meilleur réglage de déchargement que nous ayons trouvé, plutôt que de l’exclure. Montrer la limite fait partie du test.

Pourquoi la VRAM décide de tout

Voici le cœur du résultat : le débit de génération en flux unique, modèle déjà chargé et chaud, médiane de trois runs.

Le tableau se lit de haut en bas comme une frontière. En dessous de 16 Go, la carte dédiée écrase l’APU avec un facteur très stable, autour de 2,8. Sa bande passante mémoire (environ 720 Go/s de GDDR6X contre ~256 Go/s de LPDDR5X partagée) explique l’écart presque à elle seule : en génération, un LLM passe son temps à relire ses poids, et c’est la vitesse de lecture qui borne le débit.

Puis vient la ligne de 16 Go, et deux comportements très différents selon l’architecture du modèle.

Le débordement tue les modèles denses

Sur qwen3-32b, un modèle dense de 20 Go, la 4080 ne peut garder que 36 couches sur 64 en VRAM. Le reste vit en RAM et transite par le bus PCIe à chaque token. Résultat : 6,2 tok/s, environ six fois moins que ce que la carte ferait si le modèle tenait (par extrapolation du 27B, qui tient tout juste et sort 43 tok/s). L’APU, qui ne déborde jamais puisque tout est déjà dans la même mémoire, garde ses 10,7 tok/s. Ce n’est pas rapide, mais c’est lisible, et c’est 1,7 fois mieux.

Le débordement épargne les modèles MoE

Un modèle Mixture of Experts n’active qu’une fraction de ses poids à chaque token. qwen3-coder-30b-a3b pèse 30 milliards de paramètres mais n’en utilise que 3 milliards par token. Avec llama.cpp, l’option --n-cpu-moe permet de laisser les experts en RAM et de ne garder sur le GPU que l’attention et les couches partagées. Le trafic PCIe reste supportable, et la 4080 fait jeu égal avec l’APU : 77 contre 76 tok/s.

Sur gpt-oss-120b, même logique mais à une autre échelle : 60 Go de poids, 30 couches d’experts déchargées sur le CPU, 27 tok/s. C’est honorable pour une carte de 16 Go. Mais l’APU, qui charge les 60 Go en mémoire GPU sans broncher, sort 49 tok/s à 108 W. Sur ce modèle précis, le mini-PC est presque deux fois plus rapide qu’une tour qui consomme plus du double.

Concurrence : le GPU dédié monte en charge, l’APU sature

Un serveur d’inférence ne sert pas une personne à la fois. Nous avons donc mesuré le débit agrégé avec 1, 2, 4 puis 8 requêtes simultanées, sur les modèles qui tiennent dans les 16 Go de la 4080, plus qwen3-coder côté APU.

La 4080 multiplie son débit par 5,2 entre une et huit requêtes sur qwen3-8b. Le calcul par lot est exactement ce pour quoi un GPU dédié est construit, et il reste loin de la saturation. L’APU, lui, plafonne : ×3,1 sur gpt-oss-20b, ×3,4 sur qwen3-coder, et la courbe s’aplatit déjà entre k=4 et k=8.

Le thermique raconte la même histoire. Pendant ces rampes, la RTX 4080 n’a jamais dépassé 53 °C sur ces deux modèles, et 59 °C au pire sur qwen3-27b. Le mini-PC est monté de 67 à 81 °C en charge soutenue, et jusqu’à 85 °C sur les modèles denses. Nous n’avons pas observé de baisse de débit en cours de run, mais la marge est mince. Pour un usage multi-utilisateurs, la tour a une réserve que le mini-PC n’a pas.

Le plafond de contexte : 96 Go changent la nature du problème

Le contexte, c’est la mémoire de travail du modèle : le nombre de tokens qu’il peut tenir en tête (votre prompt, vos documents, la conversation). Chaque token en contexte occupe de la mémoire dans le cache KV, en plus des poids. Nous avons mesuré sur l’APU la mémoire GPU réellement occupée par chaque modèle à son contexte d’entraînement maximal, en cache f16 (référence) et en cache q8_0 (le compromis qualité/mémoire courant).

Un seul modèle de la matrice, le plus petit, tient dans 16 Go à son contexte maximal. Pour les autres, une carte de 16 Go impose de choisir entre garder le modèle en VRAM et lui donner de la mémoire de travail. L’APU fait tourner qwen3-coder avec ses 262 000 tokens de contexte, de quoi ingérer un dépôt de code entier, et il lui reste 50 Go. C’est là que les 96 Go cessent d’être un chiffre marketing.

Deux pièges de mesure que nous avons rencontrés ici, et qui valent pour vos propres tests. Un, démarrer llama-server avec un contexte géant ne prouve rien : il plafonne silencieusement au contexte d’entraînement du modèle, avec un simple avertissement dans les logs. Deux, l’option --parallel N divise le contexte par N slots. Un serveur configuré en 32k avec 4 slots ne donne que 8k à chaque requête, et une requête de 20k tokens renvoie une erreur HTTP 400 alors que la mémoire est loin d’être pleine. Nous avons perdu une matinée là-dessus.

L’énergie par tâche, pas les watts

Comparer 108 W à 260 W ne dit rien : une machine plus rapide finit plus tôt. La bonne métrique est l’énergie consommée pour accomplir une tâche identique, ici générer 256 tokens, que nous convertissons en tokens par wattheure.

La frontière des 16 Go réapparaît, cette fois sur la facture. Quand le modèle tient, la 4080 est légèrement plus sobre par token malgré sa puissance instantanée bien plus élevée, parce qu’elle finit trois fois plus vite. Quand le modèle déborde, la tour tourne longtemps à pleine puissance pour un débit médiocre : sur gpt-oss-120b, chaque token lui coûte trois fois plus d’énergie qu’à l’APU.

Caveat à lire en entier. Ces chiffres sont des mesures logicielles : rocm-smi pour la puissance socket de l’APU, nvidia-smi plus les compteurs RAPL du processeur Intel pour la tour. Ils excluent l’alimentation, la carte mère, la RAM hors socket et les ventilateurs. Ils ne sont pas comparables à une mesure à la prise, et nous nous sommes interdit d’en publier une pour une seule des deux machines : la méthode doit être symétrique, sinon la comparaison est truquée. La consommation au repos a été mesurée à part (environ 5 W pour l’APU) et n’a pas été soustraite.

Image : l’APU ne joue pas

Sur la RTX 4080, ComfyUI fait ce qu’on attend de lui. SDXL 1.0 en 1024×1024 et 20 pas sort une image en 4,5 s pour 0,34 Wh (7,8 Go de VRAM). FLUX.2 klein 4B en fp8, distillé en 4 pas, descend à 2,0 s par image et 0,10 Wh (10,9 Go). Presque dix images par wattheure.

Sur l’APU, nous avons installé PyTorch-ROCm 2.9.1, ComfyUI, le même checkpoint SDXL. PyTorch voit bien le GPU. Et puis :

RuntimeError: HIP error: invalid device function (hipErrorInvalidDeviceFunction)

Même un simple produit matriciel sur le GPU échoue. Les binaires PyTorch-ROCm publiés ciblent les architectures gfx1100 et gfx1030, pas le gfx1151 du Strix Halo : les noyaux de calcul n’existent tout simplement pas pour cette puce. llama.cpp fonctionne parce que nous l’avons compilé nous-mêmes pour gfx1151. Reconstruire PyTorch de la même façon est possible, mais ce n’est plus un TP, c’est un chantier.

Des chemins de contournement existent : AMD a ouvert le code de son application Amuse (Windows, ONNX Runtime + Vulkan) et, côté Linux, stable-diffusion.cpp propose des backends Vulkan et HIP. Nous ne les avons pas testés dans ce tour : le résultat ci-dessus vaut pour la pile PyTorch-ROCm standard, celle de ComfyUI.

Nous considérons cet échec comme un résultat à part entière. Il dit quelque chose de l’écart de maturité entre l’écosystème CUDA, où tout marche du premier coup, et ROCm sur les APU récents, où l’inférence LLM est excellente mais où la génération d’image reste réservée à ceux qui compilent. La vidéo (LTX) n’a pas été tentée sur l’APU pour la même raison.

Quel job pour quelle machine

Pas de vainqueur, deux métiers. Voici comment nous répartirions les charges aujourd’hui.

Si vous hésitez entre les deux pour un usage interne : demandez-vous d’abord quel est le plus gros modèle que vous voulez pouvoir faire tourner dans deux ans. Si la réponse tient en 16 Go, prenez la carte. Sinon, prenez la mémoire.

Annexe : comment nous avons mesuré

Le harnais est un projet Python d’environ 850 lignes, écrit en TDD, avec le même code de mesure (sonde, intégration, format de sortie) sur les deux machines. Voici ce qu’il fait, pour que vous puissiez reproduire ou contester.

1. Serveur dédié. Pour chaque modèle, le harnais lance son propre llama-server sur un port isolé, avec les options optimales pour la dimension testée, sans toucher au serveur de production. Sur la tour, le serveur tourne dans un conteneur Docker (ghcr.io/mostlygeek/llama-swap:cuda) pour ne pas modifier la configuration existante.
2. Trois profils. P1 débit crête (--parallel 1, contexte 8192), P2 concurrence (--parallel 8, rampe k=1, 2, 4, 8), P3 plafond de contexte (recherche du contexte maximal, en KV f16 puis q8_0).
3. Warm-up puis N=3. Un premier appel non mesuré charge le modèle et remplit les caches. Ensuite trois répétitions, on rapporte la médiane.
4. Sonde à 0,5 s. Un thread échantillonne sur le même tick la puissance, la température et la mémoire GPU. La puissance est intégrée par la méthode des trapèzes pour obtenir des wattheures par tâche.
5. Capture d’environnement. Chaque résultat JSON embarque le commit llama.cpp (8172e65 côté APU), la version ROCm ou du pilote, l’empreinte SHA-256 du GGUF et les options exactes du serveur.

$ llama-server -m gpt-oss-120b-MXFP4.gguf \
    -c 8192 -np 1 -ub 2048 -fa on -ngl 99 -ctk f16 -ctv f16 \
    --port 9099
# tour 16 Go, même modèle : ajouter --n-cpu-moe 30 (experts en RAM)
# dense qui déborde (qwen3-32b) : remplacer -ngl 99 par -ngl 36

Un résultat brut, tel qu’il sort du harnais :

{
  "gpt-oss-120b": {
    "ok": true,
    "gen_tok_s": 49.33,
    "energy_wh": 0.13,
    "peak_temp_c": 61.0,
    "peak_mem_mb": 63945.29,
    "parallel": 1,
    "ctx": 8192
  }
}

Trois erreurs que nous avons faites et que vous pouvez éviter. Mesurer le débit de prompt à partir du temps jusqu’au premier token est faux sur les modèles qui raisonnent : gpt-oss réfléchit avant de répondre, et ce temps s’ajoute à l’ingestion. Utilisez llama-bench pour cette métrique. Oublier le warm-up inclut le chargement du modèle dans le premier run et fausse tout k=1. Et sur ComfyUI, l’allocateur ne rend pas la VRAM après un OOM : redémarrez le conteneur avant chaque mesure.

Ce qui manque encore : une évaluation de la qualité des réponses (volontairement exclue, trop subjective pour ce tour), et la vidéo. Si vous refaites l’exercice sur un autre couple de machines, nous serons ravis de comparer nos JSON.

FAQ — APU ou GPU dédié pour un LLM local

Pour aller plus loin :
• llama.cpp · llama-swap · ComfyUI
• Sur datacampus.fr : Faire tourner un LLM sur votre propre machine, le TP · Un RAG sur vos propres documents · Héberger un LLM en local en France · Qu’est-ce que MCP ?