GenieX : exécuter des LLM et VLM sur Snapdragon via NPU, GPU ou CPU

Le problème : faire tourner un modèle sur le silicium déjà présent dans l'appareil

Un Snapdragon récent embarque un NPU Hexagon, un GPU Adreno et un CPU. Faire descendre un LLM jusque sur ces unités demande normalement de choisir un runtime, de gérer la quantification, de compiler ou de récupérer un modèle au format attendu, puis d'écrire une couche d'inférence par plateforme. GenieX se présente comme la couche qui absorbe ce travail : le README annonce que l'on apporte presque n'importe quel modèle GGUF depuis Hugging Face, ou un bundle précompilé depuis Qualcomm AI Hub, et qu'on l'exécute localement sur le NPU Hexagon, le GPU Adreno ou le CPU en quelques lignes de code. Le projet se décrit lui-même comme la version communautaire de Qualcomm GENIE.

Le public visé est étroit mais cohérent : développeurs d'applications Android, d'applications Windows ARM64 et de cibles Linux ARM64 de type IoT, qui veulent une inférence locale sans dépendre d'un service distant. Le tableau des plateformes cite Snapdragon X et X Elite pour Windows, Snapdragon 8 Elite et 8 Elite Gen 5 pour Android, et Dragonwing QCS9075 pour Linux. Aucune autre architecture n'apparaît. C'est un choix assumé, pas un oubli, et il conditionne tout le reste de l'évaluation.

Deux runtimes sous une seule interface

L'architecture décrite dans le README est un empilement : les interfaces (CLI, Python, Java, Docker, serveur compatible OpenAI) reposent sur un SDK GenieX unique, qui dispatche vers l'un de deux moteurs. Le premier est llama.cpp, avec ses noyaux GGML sur CPU, GPU et Hexagon HTP. Le second est Qualcomm AI Engine Direct, qui cible le NPU et consomme des bundles précompilés.

Cette séparation explique la syntaxe des exemples. Un identifiant de modèle Hugging Face, comme google/gemma-4-E4B-it-qat-q4_0-gguf ou unsloth/Qwen3.5-2B-GGUF, part vers llama.cpp. Un identifiant du type ai-hub-models/Qwen2.5-VL-7B-Instruct ou ai-hub-models/Qwen3-4B part vers AI Engine Direct. Le choix du moteur n'est donc pas un paramètre explicite dans les exemples fournis : il se déduit de la provenance du modèle. C'est élégant à l'usage, mais cela signifie aussi que la maîtrise du chemin d'exécution passe par le choix de l'artefact, pas par une option de configuration visible dans le README.

Le serveur compatible OpenAI écoute sur http://127.0.0.1:18181/v1. Le README affirme qu'on peut y pointer n'importe quel client OpenAI sans modification de code. C'est la partie la plus facile à intégrer dans un existant, parce qu'elle ne demande pas de réécrire la couche d'appel.

Installation : trois chemins selon la plateforme

Sur Windows ARM64, l'installation passe par un installeur téléchargé depuis la page des releases, suivi de l'ouverture d'un nouveau terminal. Sur Linux ARM64, une seule ligne, sans sudo :

curl -fsSL https://qaihub-public-assets.s3.us-west-2.amazonaws.com/qai-hub-geniex/install.sh | sh

Le côté Python est un simple pip install geniex. L'API imite volontairement transformers : AutoModelForCausalLM.from_pretrained() puis .generate(), avec un paramètre precision comme "Q4_0" et un appel model.close() en fin de vie. L'exemple de streaming itère sur model.generate(prompt, max_new_tokens=256, stream=True).

Pour le serveur, le CLI fournit deux commandes distinctes : geniex pull ai-hub-models/Qwen3-4B-Instruct-2507 pour récupérer le modèle, puis geniex serve pour l'exposer. L'appel curl correspondant envoie un JSON avec les clés model et messages vers /v1/chat/completions.

Côté Android, la dépendance Gradle est com.qualcomm.qti:geniex-android:0.3.1, ajoutée dans le bloc dependencies du module applicatif. Un détail mérite l'attention : la version publiée dans cet extrait, 0.3.1, ne correspond pas aux releases du dépôt, qui sont en 0.6.x. Le README est donc en retard sur les releases, ou les deux cycles de version sont indépendants. Dans les deux cas, c'est un point à vérifier avant de figer une dépendance.

Ce que le README ne dit pas

Le statut affiché est Developer Preview. Cela implique, par convention, que les API peuvent bouger entre versions mineures. Trois releases récentes sont listées, v0.5.0, v0.6.0 et v0.6.1, les deux dernières le même jour. Ce rythme indique un projet actif, pas un projet stabilisé.

Plusieurs zones restent floues dans le matériel fourni. La gestion mémoire n'est pas documentée : on ne sait pas comment un modèle est déchargé, ni ce qui se passe si deux modèles sont chargés dans le même processus. Le comportement en cas de repli, par exemple un modèle GGUF qui ne trouve pas de noyau NPU adapté et retombe sur le CPU, n'est pas décrit. La sélection du device n'apparaît nulle part dans les exemples : ni dans la commande geniex infer, ni dans from_pretrained().

Enfin, la liste des modèles supportés est suggérée par les topics du dépôt (gemma4, gpt-oss, granite4, llama3, qwen3, qwen3vl) mais le README ne publie pas de tableau de compatibilité par device. Pour un projet dont la promesse est « presque n'importe quel GGUF », c'est la première chose à tester soi-même sur le modèle que l'on vise, avant de bâtir quoi que ce soit dessus.

La vraie limite : Snapdragon uniquement

GenieX n'est pas un runtime portable. Le README est explicite : il tourne seulement sur Qualcomm Snapdragon. Pour une équipe qui livre une application desktop sur x86, un serveur Linux classique ou une application macOS, l'outil est simplement hors sujet. Ce n'est pas une limitation de maturité que l'on peut contourner avec du temps ou des contributions : c'est le périmètre du produit.

Même à l'intérieur de l'écosystème Snapdragon, le choix du moteur crée une asymétrie. Un bundle AI Hub est précompilé, donc lié à une cible précise. Un GGUF est plus souple, mais passe par llama.cpp, dont les noyaux Hexagon HTP sont une voie parmi d'autres. Le README ne permet pas de savoir quel chemin offre la meilleure couverture selon le modèle. Un développeur qui a besoin d'un modèle absent du catalogue AI Hub devra se rabattre sur GGUF, avec les compromis que cela implique sur l'exploitation du NPU.

Le recours à Qualcomm Device Cloud est proposé pour ceux qui n'ont pas d'appareil sous la main. C'est utile pour évaluer, mais cela ne remplace pas un test sur le parc réel, en particulier pour les questions thermiques et de consommation, qui ne figurent nulle part dans le matériel fourni.

Face à quoi on le compare

L'alternative la plus directe est llama.cpp utilisé seul. GenieX s'appuie dessus pour la voie GGUF, donc la différence ne se situe pas dans le moteur mais dans ce qui l'entoure : packaging multiplateforme, API Python calquée sur transformers, liaison Android, serveur HTTP, et surtout la voie Qualcomm AI Engine Direct pour le NPU, que llama.cpp seul n'expose pas de la même manière. Si votre cible est un Snapdragon et que vous voulez le NPU, GenieX apporte une couche que vous devriez sinon écrire.

Une autre option consiste à utiliser directement le SDK Qualcomm AI Hub et les bundles précompilés, sans passer par GenieX. Vous gardez le contrôle total sur la compilation et le déploiement, mais vous perdez les interfaces prêtes à l'emploi et la compatibilité GGUF. Le compromis est classique : plus de contrôle contre plus de code à maintenir.

Enfin, pour un usage serveur sur matériel non Snapdragon, la comparaison n'a pas lieu d'être. Les runtimes classiques sur x86 ou GPU NVIDIA couvrent ce terrain, et GenieX ne prétend pas y aller.

Coût de maintenance et licence

La licence du dépôt est BSD-3-Clause, une licence permissive qui autorise la redistribution et la modification, avec conservation du copyright et de la clause de non-approbation. Elle porte sur le code du runtime. Elle ne dit rien des poids de modèles que vous téléchargez depuis Hugging Face ou Qualcomm AI Hub : chaque modèle a sa propre licence, et c'est à vous de la vérifier. De même, les composants tiers embarqués (llama.cpp et ses dépendances) ont leurs propres conditions. Le README ne fournit pas de fichier de notices tierces, ce qui est un point à clarifier si vous distribuez un produit.

Le coût de maintenance réel vient du statut Developer Preview. Tant que les API bougent, une mise à jour de version peut demander des adaptations, en particulier côté Python où l'API imite transformers, et côté serveur où le contrat est censé rester compatible OpenAI. Le rythme des releases (v0.5.0 en août, v0.6.0 et v0.6.1 en septembre) suggère des changements fréquents. Prévoir une version épinglée et un test de non-régression sur votre modèle cible n'est pas du zèle : c'est le minimum face à un projet qui se déclare lui-même en preview.

Conclusion éditoriale

GenieX vise les équipes qui déploient déjà sur Snapdragon, que ce soit Windows ARM64, Android ou Linux ARM64, et qui acceptent de dépendre d'un runtime en Developer Preview : le README ne décrit pas de garantie de stabilité d'API. Les projets multi-architecture, x86 ou Apple Silicon, doivent passer leur chemin : le tableau des plateformes ne mentionne que Snapdragon. Avant de vous engager, vérifiez sur votre modèle précis que la variante GGUF ou le bundle AI Hub existe, que le chemin d'exécution choisi correspond bien à NPU, GPU ou CPU, et que la licence BSD-3-Clause du runtime couvre votre usage une fois les poids du modèle et les composants tiers pris en compte.

Sources officielles

1. License: BSD-3-Clause
2. Project website
3. qualcomm/GenieX on GitHub
4. README
5. Releases