hipEngine: Fast Native Qwen 3.6 Inference for RDNA3 (Strix Halo, 7900 XTX)
En 3 ligneshipEngine est un moteur d'inférence LLM open source (AGPLv3) optimisé pour RDNA3 (RX 7900 XTX, W7900). Écrit en Python avec kernels HIP/C++, il exécute Qwen 3.6 MoE plus vite que llama.cpp en prefill (2718 tok/s à 512 tokens vs 2436 pour GGUF Q4_K_S). Support INT8 KVCache quasi sans perte permet 256K contexte en <24GB.
## hipEngine : un moteur d'inférence ROCm-natif qui dépasse llama.cpp sur RDNA3
### Ce qui se passe concrètement
hipEngine est un moteur d'inférence LLM open source (AGPLv3) écrit par le même développeur que FastDMS, ciblant exclusivement les GPU AMD RDNA3 — principalement RX 7900 XTX et Radeon Pro W7900 (gfx1100), avec un support initial pour Strix Halo (gfx1151, Ryzen AI MAX+ 395). L'architecture est Python en surface, mais tout le chemin critique passe par des kernels HIP/C++ personnalisés exploitant hipBLASLt, hipGraph et AOTriton. Aucune dépendance PyTorch lourde.
Le modèle cible initial est Qwen 3.6 35B-A3B (MoE), avec support du format GGUF (Q4_K_M, Q4_K_S) et du format ParoQuant (4.68bpw), ce dernier ayant été porté pour être compatible ROCm.
### Les chiffres qui comptent
**Prefill (gfx1100 — W7900/7900 XTX) :** - À 512 tokens : hipEngine PARO atteint **2718 tok/s** vs 2436 pour llama.cpp HIP (+11,6%) et 1817 pour llama.cpp Vulkan (+49,6%) - À 4K tokens : **2838 tok/s** vs 2177 pour llama.cpp HIP (+30,4%) - À 128K tokens : **1055 tok/s** vs 710 pour llama.cpp HIP (+48,5%)
L'avantage s'accentue avec la longueur de contexte — exactement là où les optimisations d'attention et de gestion mémoire font la différence.
**Decode :** La situation s'inverse partiellement. llama.cpp Vulkan surpasse hipEngine en decode à contexte court (127 tok/s vs 103 à 512 tokens). hipEngine GGUF Q4_K_S atteint 109 tok/s, légèrement au-dessus de hipEngine PARO (103). Ce n'est pas un détail : pour les usages interactifs où le prefill est court et le decode long, llama.cpp Vulkan reste compétitif.
**Mémoire :** À 128K contexte, hipEngine PARO consomme **22,1 GiB** contre 25,1 pour hipEngine GGUF et 23,6 pour llama.cpp. L'INT8 KVCache quasi sans perte (perte de ~1,4% en vitesse prefill : 1091 → 1076 tok/s) permet de faire tourner le contexte 256K complet de Qwen 3.6 en **21,96 GiB** sampled peak, soit sous les 24 GiB d'une 7900 XTX dédiée. À 256K/INT8 : 670 tok/s prefill, 40 tok/s decode.
**Strix Halo (gfx1151, iGPU) :** Sans optimisation dédiée, hipEngine PARO atteint déjà **1029 tok/s** à 4K tokens vs 1004 pour llama.cpp HIP et 595 pour Vulkan. En decode, hipEngine dépasse llama.cpp HIP à tous les contextes (63 vs 49 tok/s à 4K). C'est notable pour un APU partagé CPU/GPU.
### Pourquoi llama.cpp est structurellement désavantagé ici
llama.cpp est un moteur généraliste multi-backend (CUDA, Metal, Vulkan, ROCm, CPU). Ses kernels ROCm/HIP sont des portages, pas des implémentations natives. hipEngine écrit directement pour gfx1100 : 100+ kernels personnalisés documentés dans KERNELS.md, avec variantes fusionnées/non-fusionnées et oracles CPU de référence. L'auteur publie également ROOFLINE.md — analyse roofline par kernel — ce qui est rare dans les projets open source et signale une rigueur d'optimisation inhabituelle pour un "sidequest".
Le port de ParoQuant vers ROCm est un travail supplémentaire non trivial : la quantification ParoQuant (4.68bpw) prend plusieurs jours à exécuter, mais offre une densité supérieure au GGUF Q4_K_S standard tout en restant plus rapide en prefill.
### Les perdants potentiels
**llama.cpp sur AMD** : Pour les utilisateurs RDNA3 qui font du traitement de longs contextes (RAG, summarisation de documents), hipEngine offre un avantage mesurable. La communauté llama.cpp AMD pourrait perdre des contributeurs et des utilisateurs.
**Ollama/LM Studio sur AMD** : Ces frontends s'appuient sur llama.cpp. Ils n'héritent pas automatiquement des gains hipEngine.
**Les utilisateurs NVIDIA** : hipEngine ne supporte pas CUDA. C'est un outil explicitement AMD-first, ce qui limite son adoption mais concentre son optimisation.
### Limites et contexte
Le projet est décrit par son auteur comme un "fun sidequest" inspiré de DeepSeek-V4. Support actuel : Qwen 3.6 MoE et dense uniquement. GGUF est en état "good enough initial" — légèrement derrière ParoQuant en vitesse. L'auteur mentionne Gemma 4 et StepFun 3.5 comme prochaines architectures possibles. Pas de serveur HTTP intégré mentionné, pas d'API OpenAI-compatible documentée — c'est un moteur bas niveau, pas un service prêt à déployer.
La licence AGPLv3 impose des contraintes pour les usages commerciaux embarqués : toute modification doit être publiée si le service est exposé en réseau.
Pour les praticiens sur AMD RDNA3 travaillant avec Qwen 3.6 et des contextes longs, hipEngine est aujourd'hui l'option la plus rapide disponible en open source.
Résumé généré par Claude — vérifié par l'humain