hipEngine : Inférence native rapide de Qwen 3.6 pour RDNA3 (Strix Halo, 7900 XTX)

Un nouveau moteur d'inférence natif ROCm pour les modèles Qwen 3.6 MoE et denses a fait son apparition : hipEngine, développé par le créateur de FastDMS et ParoQuant. Il est basé sur Python avec des chemins chauds en HIP/C++, utilisant des bibliothèques AMD natives comme hipBLASLt, hipGraph et AOTriton. Pas de dépendance lourde à PyTorch.
Matériel cible
gfx1100— Radeon RX 7900 XTX / Radeon Pro W7900 (RDNA3). Strix Halo également supporté.
Benchmarks vs llama.cpp
Sur Qwen 3.6 35B MoE (avec ParoQuant 4.68 bpw et GGUF Q4_K_S), hipEngine égale ou dépasse llama.cpp HIP et Vulkan à toutes les longueurs de contexte testées (512–128K). Chiffres clés (tok/s en préremplissage, 512 prompt / 128 génération) :
- hipEngine PARO : 2718,497 tok/s
- hipEngine GGUF Q4_K_S : 2258,847 tok/s
- llama.cpp HIP : 2436,049 tok/s
- llama.cpp Vulkan : 1816,927 tok/s
À 128K de contexte, le préremplissage de hipEngine PARO atteint 1055 tok/s contre 710 tok/s pour llama.cpp HIP — soit une amélioration de 48 %. Les tok/s en décodage sont comparables (plage de 60–127 tok/s).
Efficacité mémoire
hipEngine utilise un cache KV INT8 quasi sans perte et sans presque aucun impact sur la vitesse. Cela permet d'exécuter la fenêtre de contexte complète de 256K de Qwen 3.6 en moins de 24 Go sur une seule 7900 XTX :
- Contexte 128K, KV BF16 : pic échantillonné à 21,04 Gio, préremplissage 1091,9 tok/s, décodage 62,2 tok/s
- Contexte 128K, KV INT8 : pic échantillonné à 19,80 Gio, préremplissage 1076,5 tok/s, décodage 60,0 tok/s
- Mémoire maximale à 128K (hipEngine PARO) : 22,122 Gio contre 23,605 Gio pour llama.cpp HIP
Fonctionnalités
- Open source sous AGPLv3
- Natif ROCm, sans dépendance à PyTorch dans le chemin chaud
- Utilise hipBLASLt, hipGraph, AOTriton
- ParoQuant porté vers ROCm
- Cache KV INT8 (quasi sans perte, impact minime sur la vitesse)
- Prend en charge les modèles Qwen 3.6 MoE et denses
Si vous exécutez Qwen 3.6 sur du matériel RDNA3, hipEngine mérite le détour — en particulier pour les cas d'utilisation de contexte 256K limités en mémoire.
📖 Lire la source complète : r/LocalLLaMA
👀 See Also

Claude Cowork contre OpenClaw : Où le récit du remplacement tient et où il se brise
Claude Cowork propose des sessions de bureau persistantes avec une faible friction, tandis qu'OpenClaw conserve ses avantages en matière d'automatisation au niveau système, d'écosystèmes de compétences et de contrôle des flux de travail.

Code source : CLI open source pour compresser les grands monorepos Java/Spring pour Claude
sourcecode CLI réduit un monorepo Java/Spring d'environ 4k fichiers de ~3M tokens à 1.7k tokens (mode compact). Actuellement, il se concentre sur la compression de contexte, la détection de points chauds git et la recherche de symboles.

Fullerenes : Couche mémoire persistante open source pour agents de codage réduit les tokens de 64% sur SWE-bench
Fullerenes utilise un graphe de connaissances local SQLite construit via Tree-sitter pour donner aux agents de codage comme Claude Code une mémoire persistante, réduisant l'utilisation de tokens de 64 % sur SWE-bench et jusqu'à 96,6 % sur des benchmarks internes.

Statespace : Créez des applications Web interactives pour les agents OpenClaw avec Markdown
Statespace est un framework gratuit et open-source pour créer et partager des applications web conviviales pour l'IA, que les agents OpenClaw peuvent naviguer et avec lesquelles ils peuvent interagir en utilisant du Markdown pur. Il vous permet de définir des outils, des composants et des instructions dans des fichiers Markdown auxquels les agents accèdent via HTTP.