Comparer Vulkan/RADV et ROCm/HIP dans llama.cpp
Mesurer sur nos modèles cibles et nos longueurs de prompt RAG le débit de prompt processing et de génération des deux backends GPU de llama.cpp, pour trancher Q-008.
- Statut du test
- À tester
- Priorité
- Haute
- Prévu pour
- Octobre 2026
- Hypothèse
- Vulkan/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.
- Procédure
- 1) Deux builds llama.cpp de même version : Vulkan (glslc 2026.3+) et HIP (GPU_TARGETS=gfx1151, GGML_HIP_NO_VMM=ON, GGML_HIP_ROCWMMA_FATTN=ON). 2) Modèles : gpt-oss-120b MXFP4, Qwen3 30B-A3B Q4_K_M ; options -fa 1, --no-mmap, -dio (HIP). 3) llama-bench pp512/tg128, puis pp4096, pp16384 avec tg128. 4) llama-server avec 1 puis 4 requêtes simultanées, prompts de 8k tokens : TTFT et t/s par utilisateur. 5) Relever dmesg et incidents. 6) Trois répétitions, médiane.
- Prochaine action
- Attend la machine et l'expérimentation mémoire GPU ; préparer les scripts de mesure et les prompts RAG représentatifs.
Pourquoi
Les sources publiées donnent l'avantage à Vulkan en génération et à ROCm en prompt processing long 1 2 3 ; une source le conteste 5. Aucune ne mesure sur nos modèles avec des prompts de type RAG. Le résultat conditionne aussi le choix de distribution (Q-007) : si Vulkan suffit, la matrice ROCm cesse de contraindre.
Plan de mesure
| Test | Backend | Modèle | Prompt | Sortie | Métriques |
|---|---|---|---|---|---|
| A | Vulkan, HIP | gpt-oss-120b MXFP4 | 512 | 128 | pp t/s, tg t/s |
| B | Vulkan, HIP | gpt-oss-120b MXFP4 | 4 096, 16 384 | 128 | pp t/s, TTFT |
| C | Vulkan, HIP | Qwen3 30B-A3B Q4_K_M | 512, 4 096, 16 384 | 128 | pp, tg, TTFT |
| D | Vulkan, HIP | gpt-oss-120b | 8 192 × 4 slots | 256 | t/s par utilisateur, agrégé, TTFT |
| E | les deux | — | — | — | incidents dmesg, plantages, consommation |
Les résultats seront publiés dans la collection Benchmarks avec origin: ours.
Critère de décision
Retenir le backend dont le temps de réponse total (TTFT + génération de 256 tokens) est le meilleur sur le test D, sauf si l'autre est nettement plus stable (test E). Si l'écart est inférieur à 10 %, retenir Vulkan/RADV (moins de dépendances) et documenter l'option ROCm.
Résultat
À venir.
Sources
- 1llama.cpp: Vulkan vs ROCm on Strix Halo (Soothill)BenchmarkFiabilité moyennesoothill.io · Darren Soothill · publié 2026-08-03 · consulté le 16 sept. 2026 · fiche source
- 2Strix Halo Wiki — llama.cpp Performance (kyuz0)BlogFiabilité moyennestrixhalo.wiki · kyuz0 · publié 2025–2026 · consulté le 16 sept. 2026 · fiche source
- 3llama.cpp discussion #20856 — Known-Good Strix Halo ROCm + llama.cpp StackGitHubFiabilité moyenneGitHub ggml-org (communauté) · realugbun · publié 2026-03-22 (màj 2026-07-23) · consulté le 16 sept. 2026 · fiche source
- 4strix-halo-guide (README + BENCHMARKS.md)GitHubFiabilité moyenneGitHub (communauté) · hogeheer499 · publié 2026-03 → 2026-08-30 · consulté le 16 sept. 2026 · fiche source
- 5I tuned llama.cpp on a Strix Halo mini-PC — why « Vulkan beats ROCm » is a myth (Medium)BlogFiabilité faibleMedium · Bkpaine · publié 2026-07 · consulté le 16 sept. 2026 · fiche source