ailia-models : 419 scripts Python autour d'un runtime propriétaire

Un catalogue de 419 modèles, pas une bibliothèque

Le README annonce 419 modèles, répartis en catégories nommées : action recognition, anomaly detection, audio language model, audio processing, autonomous driving, background removal, crowd counting, deep fashion, depth estimation, et d'autres encore. Chaque catégorie correspond à un répertoire de premier niveau, et chaque modèle à un sous-répertoire contenant un script Python. Ce n'est donc pas une bibliothèque que l'on importe dans son propre code : c'est une collection d'exemples exécutables, un dossier par modèle, avec ses propres dépendances et ses propres poids. La question à laquelle le dépôt répond est celle du temps perdu à chercher un modèle, à écrire un script de conversion et à télécharger des poids. Ici, le script existe déjà et les poids se récupèrent au premier lancement. Le public visé est celui qui veut une démonstration fonctionnelle rapidement, ou qui a besoin d'intégrer un modèle précis dans une application via le SDK ailia plutôt que via PyTorch. Le revers de cette organisation apparaît dès qu'on cherche une vue d'ensemble : il n'y a pas d'API commune documentée dans le README, seulement une convention de lancement partagée.

Le contrat implicite : un script, zéro argument

Le README énonce la règle en une phrase : chaque modèle fonctionne de la même manière, sans argument, et les poids se téléchargent automatiquement. L'exemple donné est explicite, avec object_detection/yolox comme cas d'école. On installe le SDK, on clone le dépôt, on installe les dépendances, on entre dans le répertoire du modèle, on lance le script. Cette uniformité est le vrai apport du projet. Elle signifie qu'un modèle d'action recognition, un modèle de background removal et un modèle de synthèse vocale se lancent avec la même séquence de commandes, à ceci près que le nom du script et le nom du répertoire changent. Pour un lecteur qui a déjà passé une journée à déboguer des scripts d'inférence écrits par d'autres, la valeur est concrète. Mais cette convention a un coût : le comportement par défaut est figé. Si vous voulez changer le seuil de confiance d'un détecteur, la résolution d'entrée d'un modèle de profondeur ou le chemin de sortie, il faut ouvrir le script et le modifier. Le README ne documente pas de mécanisme d'options en ligne de commande, et rien dans le matériel fourni n'indique qu'il en existe un.

Ce que le dépôt ne dit pas sur le runtime

Le point le plus important est aussi le plus discret. Le paquet installé s'appelle ailia, et le dépôt se présente comme la collection de modèles pour le SDK ailia. Le runtime d'inférence n'est donc pas dans ce dépôt : il est dans le paquet pip, qui est un composant distinct, avec sa propre licence. L'identifiant de licence du dépôt lui-même est NOASSERTION, ce qui signifie que GitHub n'a pas su classer la licence à partir des fichiers présents. Ces deux éléments combinés empêchent de répondre, à partir du matériel fourni, à une question simple : sous quelles conditions peut-on redistribuer une application qui embarque ailia ? Le README mentionne une page ABOUT_AINYAN.md et une documentation sur docs.ailia.ai, sans en détailler le contenu. Si vous évaluez ce projet pour un produit commercial, c'est le premier document à lire, avant même de lancer le premier script. Un catalogue de 419 modèles sous licence permissive ne sert à rien si le runtime qui les exécute impose des contraintes incompatibles avec votre distribution.

La mise en route, commande par commande

La séquence du README tient en cinq lignes. pip3 install ailia installe le SDK. git clone https://github.com/ailia-ai/ailia-models récupère le dépôt. cd ailia-models puis pip3 install -r requirements.txt installe les dépendances Python listées à la racine. Enfin, on se place dans un répertoire de modèle, par exemple cd object_detection/yolox, et on lance python3 yolox.py. Les badges du README indiquent Python 3.9, 3.10, 3.11 et 3.12, et une prise en charge de Windows, macOS, Linux, iOS, Android, Jetson et Raspberry Pi. Deux réserves pratiques. D'abord, un requirements.txt unique à la racine d'un dépôt qui couvre détection d'objets, synthèse vocale, LLM et matting d'image ne peut pas être léger : c'est un point à vérifier avant d'installer, surtout dans un environnement virtuel partagé. Ensuite, la liste de plateformes est une liste de plateformes du SDK, pas nécessairement de chaque script : le README ne précise pas quels modèles sont validés sur quelles cibles, et les scripts Python de démonstration supposent un environnement de bureau.

Les cas où le dépôt ne convient pas

Trois situations rendent ailia-models inadapté. La première est la reproductibilité stricte. Les poids se téléchargent automatiquement au premier lancement, mais le dépôt ne publie pas de releases : le matériel fourni n'en liste aucune. Il n'y a donc pas de version figée du catalogue à épingler, et rien n'indique que les URL de poids soient stables ou versionnées. Pour un pipeline qui doit produire le même résultat dans six mois, c'est un problème de fond. La deuxième est la portabilité du runtime. Si votre contrainte est de tout exécuter sur ONNX Runtime ou sur un backend que vous contrôlez, chaque script devra être réécrit, car il appelle l'API ailia. La troisième est le besoin d'une bibliothèque et non d'exemples : si vous voulez importer un détecteur dans votre propre service avec une API stable, vous devrez extraire le code du script et le maintenir vous-même, sans garantie que la structure interne reste stable d'une mise à jour à l'autre. Le dépôt est un point de départ, pas une fondation.

ONNX Runtime comme point de comparaison

L'alternative la plus directe est ONNX Runtime, avec le Model Zoo ONNX comme source de modèles. La différence d'approche est nette. ONNX Runtime est une bibliothèque que vous intégrez : vous chargez un fichier .onnx, vous gérez vous-même le prétraitement, le post-traitement et le téléchargement des poids, et vous contrôlez la version exacte du modèle. ailia-models fait l'inverse : il fournit le script complet, prêt à lancer, avec le prétraitement et le post-traitement déjà écrits, mais vous laisse dépendant de son runtime et de ses conventions. Concrètement, pour une détection d'objets, ONNX Runtime vous donne un graphe et des tenseurs, ailia-models vous donne un script qui affiche des boîtes sur une image. Le premier demande plus de travail et offre plus de contrôle ; le second va plus vite et enferme davantage. Le choix dépend de ce que vous faites ensuite : une démonstration ou une intégration dans un produit existant.

Coût de maintenance et licence

Le dépôt n'est pas archivé et le dernier push indiqué est le 9 septembre 2026, ce qui suggère une maintenance active. Mais l'absence de releases publiées déplace le coût de mise à jour vers vous : vous suivez la branche master, et une modification dans un script partagé ou dans le requirements.txt peut casser votre environnement sans numéro de version pour vous en avertir. Le README pointe vers un historique de mises à jour sur le wiki GitHub, ce qui est le seul mécanisme de suivi mentionné. Sur la licence, le dépôt est marqué NOASSERTION et le paquet ailia a sa propre licence, non détaillée dans le matériel fourni. Il faut donc consulter la page du paquet sur PyPI et la documentation officielle avant tout usage en distribution. Je ne peux pas vous dire ici si cette licence autorise un usage commercial ou impose des conditions de redistribution : ce n'est pas dans les sources dont je dispose, et je préfère l'écrire plutôt que de le supposer.

Conclusion éditoriale

ailia-models convient à qui veut faire tourner rapidement un modèle précis (YOLOX, Whisper, un modèle de matting) sur Windows, macOS, Linux, iOS, Android, Jetson ou Raspberry Pi sans gérer soi-même la conversion et le téléchargement des poids. À éviter si votre contrainte est la portabilité totale du runtime, la reproductibilité par version de modèle, ou un déploiement sans composant binaire propriétaire. Avant d'adopter, vérifiez deux points précis : la licence exacte du paquet ailia installé par pip3 install ailia, et le contenu du requirements.txt à la racine, qui détermine si l'environnement reste gérable sur votre machine.

Sources officielles

1. ailia-ai/ailia-models on GitHub
2. Issues
3. README