Modèle / jeu de données
NVlabs/Eagle avatar
NVlabs/Eagle

Eagle de NVlabs : quatre modèles, deux licences, une seule base de code

Eagle: Frontier Vision-Language Models with Data-Centric Strategies

3 568 étoiles352 forksPythonApache-2.0

En bref

De quoi s’agit-il ?
La famille Eagle couvre la compréhension d'images, la vidéo longue et le grounding généraliste. Le point délicat n'est pas le choix du modèle mais la séparation entre le code Apache-2.0 et les poids sous licence NVIDIA.
À qui s’adresse-t-il ?
Eagle s'adresse aux équipes qui ont déjà une pile d'entraînement multimodale et cherchent une base de recherche modifiable : le code est sous Apache-2.0, les scripts LoRA et le runtime FlashAttention de LocateAnything sont fournis, et les poids sont sur Hugging Face.
Puis-je l’utiliser commercialement ?
Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
Est-il encore maintenu ?
Oui. Les derniers commits datent d’il y a 83 jours.
En quel langage est-il écrit ?
Principalement Python, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Ce que le dépôt contient réellement

Eagle n'est pas un paquet. C'est un dépôt qui héberge quatre projets distincts, chacun avec son dossier, son README et son rapport PDF. LocateAnything, dans Embodied/, est un modèle de grounding généraliste : détection d'objets dense, compréhension de documents, GUI grounding, OCR. Eagle 2.5, dans Eagle2_5/, vise la compréhension d'images et de vidéos en contexte long. Eagle 2 et Eagle occupent tous deux le dossier Eagle/ et documentent respectivement les stratégies de données en post-entraînement et la conception d'encodeurs visuels en mélange. Le README racine présente cette famille comme un terrain d'expérimentation sur les stratégies centrées sur les données, et mentionne que le travail a servi de base à plusieurs efforts NVIDIA : Llama-Nemotron Nano VLM, les Nemotron VLMs, NeMo Retriever, Isaac GR00T N1, N1.5 et N1.6, ainsi que Cosmos. Ce sont des affirmations du dépôt lui-même, pas des résultats que j'ai pu reproduire. Le public visé est donc précis : des équipes de recherche qui veulent lire du code d'entraînement et l'adapter, pas des développeurs qui cherchent un client d'inférence prêt à l'emploi.

Parallel Box Decoding : ce que le README en dit

Le seul mécanisme d'inférence décrit en détail dans le matériel fourni concerne LocateAnything. Le README le nomme Parallel Box Decoding (PBD) et le présente comme une alternative au Quantized Coordinate Decoding. La différence annoncée tient au décodage : PBD prédit chaque boîte englobante de façon atomique en une seule passe avant, là où le décodage par coordonnées quantifiées produit les coordonnées de manière séquentielle. Le dépôt associe à cette approche une vitesse de décodage plus élevée et une sortie de meilleure qualité, et la note de version de juin 2026 ajoute un mode d'inférence par lots avec un runtime FlashAttention pur, présenté comme efficace sur A100, RTX 4090 et d'autres GPU non Hopper et non Blackwell. Je n'ai pas exécuté cette comparaison et le matériel ne fournit aucun chiffre de débit : la revendication de rapidité reste donc à vérifier sur votre propre matériel avant de dimensionner quoi que ce soit. Le point intéressant pour un lecteur francophone est ailleurs : le support des GPU non Hopper et non Blackwell est explicitement mis en avant, ce qui suggère que le reste de la pile suppose des générations plus récentes. C'est une contrainte de parc matériel, pas un détail.

Mise en route : trois chemins, pas un

Il n'existe pas de point d'entrée unique. Le README racine oriente vers trois documents selon le modèle : Embodied/README.md pour LocateAnything, Eagle2_5/document/0.onboarding.md pour Eagle 2.5, et Eagle/README.md pour Eagle et Eagle 2. Les poids sont publiés dans une collection Hugging Face sous l'organisation nvidia, avec une page de démonstration distincte pour LocateAnything. Pour le fine-tuning, le dépôt fournit un script shell nommé Embodied/shell/locate-anything-lora-visual-prompt.sh, décrit comme un script de fine-tuning par prompt visuel avec LoRA. C'est l'élément le plus concret du matériel : un fichier exécutable, dans un chemin identifié, pour une tâche identifiée. Le reste des instructions d'installation se trouve dans les README de sous-dossiers que je n'ai pas sous les yeux, et je ne peux donc pas citer de commande pip ou de clé de configuration avec certitude. Si vous évaluez le projet, commencez par ces trois fichiers et par le script LoRA : ce sont eux qui déterminent si l'intégration tient en une journée ou en une semaine.

Deux licences, et la frontière passe au milieu du projet

Le badge de licence du README racine indique Apache-2.0 pour le code, et un second badge pointe vers Eagle2_5/LICENSE_MODEL sous NVIDIA License pour les modèles. Cette séparation est fréquente chez les éditeurs de modèles, mais elle a une conséquence pratique qu'on oublie souvent : le droit d'utiliser, de redistribuer ou de servir les poids n'est pas régi par l'Apache-2.0 qui couvre les scripts. Un produit construit autour d'Eagle 2.5 doit donc être évalué sur deux textes, pas un. Le dépôt indique aussi qu'Eagle 2 est pris en charge dans Torch-TRT, ce qui ouvre une voie de compilation sans changer de licence. Je ne donne pas d'avis juridique : la seule chose que je peux affirmer, c'est que le fichier de licence des modèles existe à un chemin précis et qu'il faut le lire avant de bâtir une offre commerciale sur ces poids.

Le coût de suivi que le dépôt laisse deviner

Aucune release n'a été récupérée pour ce dépôt, et la branche par défaut est main. Il n'y a donc pas de version épinglée à laquelle se raccrocher : le suivi se fait au commit. Le journal des mises à jour montre un rythme soutenu sur dix-huit mois, avec des ajouts fonctionnels (LocateAnything en mai 2026, son fine-tuning LoRA et son inférence par lots en juin 2026) et des acceptations en conférence qui n'ont pas d'effet sur le code. La conséquence est directe : une intégration qui fonctionne aujourd'hui peut nécessiter une relecture du script LoRA ou du runtime FlashAttention après une mise à jour. Pour un projet de recherche, c'est acceptable. Pour un service en production, cela signifie figer un commit et surveiller les écarts soi-même, puisque rien dans le dépôt ne signale de compatibilité ascendante. Le fait que le même dossier Eagle/ héberge Eagle et Eagle 2, deux générations documentées séparément, illustre cette absence de contrat de stabilité.

Ce qui manque dans le matériel fourni

Le README est un document de vitrine : des badges, un tableau de modèles, des vidéos de démonstration, un journal de versions. Il ne contient ni commande d'installation, ni exemple d'appel d'API, ni tableau de compatibilité des versions de bibliothèques, ni description des formats de données d'entraînement. Les rapports PDF liés depuis l'en-tête contiennent probablement ces éléments, mais ils ne font pas partie du matériel que j'ai pu consulter. Toute affirmation sur les performances comparées à d'autres modèles, sur le nombre de tokens de contexte réellement supportés ou sur la taille mémoire nécessaire à l'inférence serait donc une invention de ma part. Un lecteur qui a besoin de ces chiffres doit ouvrir les PDF et les README de sous-dossiers, pas se fier à la page racine. C'est la limite la plus gênante du dépôt pour un évaluateur : la vitrine est soignée, la documentation opérationnelle est ailleurs.

L'alternative : une bibliothèque d'inférence plutôt qu'un dépôt de recherche

La comparaison la plus utile n'est pas entre Eagle et un autre modèle, mais entre Eagle et une bibliothèque d'inférence multimodale générique, du type de celles qui exposent un chargeur de modèle et un pipeline unifiés. La différence d'approche est nette. Une bibliothèque de ce genre fournit une API stable, des versions publiées et une compatibilité testée entre modèles ; elle ne vous donne pas les scripts d'entraînement ni les stratégies de données. Eagle fait l'inverse : il expose le code d'entraînement, les scripts de fine-tuning LoRA et les rapports qui expliquent les choix de données, mais aucun contrat de version. Si votre besoin est de servir un VLM en production sans toucher aux poids, la bibliothèque générique est le bon outil et Eagle est un détour. Si votre besoin est de comprendre comment une stratégie de données produit un comportement donné, ou d'adapter un encodeur visuel, la bibliothèque ne vous servira à rien et Eagle est le seul des deux à montrer le mécanisme. Le choix se fait donc sur la question posée, pas sur la qualité relative des deux.

Conclusion éditoriale

Eagle s'adresse aux équipes qui ont déjà une pile d'entraînement multimodale et cherchent une base de recherche modifiable : le code est sous Apache-2.0, les scripts LoRA et le runtime FlashAttention de LocateAnything sont fournis, et les poids sont sur Hugging Face. Il ne convient pas à qui veut une bibliothèque installable en une commande avec une API stable : il n'y a aucune release publiée, la documentation est répartie entre trois README et des rapports PDF, et les poids relèvent de la NVIDIA License, pas de l'Apache-2.0. Avant tout engagement, ouvrez Eagle2_5/LICENSE_MODEL et vérifiez que vos cas d'usage y figurent, puis confirmez la version de transformers et de flash-attn attendue par le script de fine-tuning visuel que vous comptez lancer.

Sources officielles

  1. Issues
  2. License: Apache-2.0
  3. NVlabs/Eagle on GitHub
  4. Project website
  5. README
Notes de la communauté

Notes de la communauté