YOLOE : Détection et segmentation en temps réel à vocabulaire ouvert#

Ultralytics YOLOE (Real-Time Seeing Anything) est un modèle de détection et de segmentation d’instances à vocabulaire ouvert : au lieu d’utiliser une liste de classes fixe au moment de l’entraînement, il prend les catégories que tu veux au moment de l’inférence, sous forme d’invite textuelle, d’exemple visuel ou d’un vocabulaire intégré de 4 585 noms. Basé sur les architectures Ultralytics YOLO — YOLOv8, YOLO11 et YOLO26 — et inspiré de YOLO-World, YOLOE atteint une précision zero-shot de pointe, à une vitesse proche de celle de YOLO à classes fermées.

Démarrage rapide#

Nomme les classes que tu veux et exécute le modèle. YOLOE-26 renvoie des boîtes et des masques de segmentation d’instances pour des catégories sur lesquelles il n’a jamais été entraîné.

from ultralytics import YOLOE

model = YOLOE("yoloe-26s-seg.pt")

# "double-decker bus" is not a COCO class; YOLOE resolves it from the words alone
model.set_classes(["double-decker bus", "person"])

results = model.predict("https://ultralytics.com/images/bus.jpg")
results[0].show()

Le premier appel à set_classes() télécharge un encodeur de texte ; consulte Installation et prérequis avant un déploiement sur une machine sans accès réseau.

Choisir un mode d’invite#

YOLOE prend en charge trois modes d’invite, et ce choix détermine le checkpoint que tu charges ainsi que la forme des étiquettes de classes. Choisis la ligne correspondant à ce que tu peux fournir au moment de l’inférence.

Installation et prérequis#

YOLOE est inclus dans le package principal Ultralytics :

pip install -U ultralytics

L’invite textuelle nécessite en plus un encodeur de texte, récupéré lors de la première utilisation plutôt qu’au moment de l’installation :

• Le premier appel à set_classes() installe ultralytics/CLIP depuis GitHub avec pip (qui fournit le tokenizer) et télécharge un encodeur de texte TorchScript dans le répertoire de travail actuel. YOLOE-26 récupère mobileclip2_b.ts, d’environ 254 Mo ; YOLOE-11 et YOLOE-v8 récupèrent mobileclip_blt.ts. Effectue le téléchargement une fois depuis le répertoire d’exécution, ou copie le fichier à cet endroit ; sinon, il sera téléchargé à nouveau.
• Les deux étapes nécessitent un accès réseau ; exécute donc une prédiction avec invite avant de déployer sur une machine hors ligne ou isolée du réseau.
• Les invites visuelles et les checkpoints sans invite n’ont besoin d’aucun encodeur de texte.

Les checkpoints YOLOE-26 nécessitent ultralytics 8.4.0 ou une version ultérieure ; les familles YOLOE-11 et YOLOE-v8 sont disponibles dans des versions antérieures. Une prédiction avec invite textuelle teste l’ensemble du chemin — téléchargement du checkpoint, installation de CLIP, encodeur de texte, inférence :

yolo predict model=yoloe-26s-seg.pt source="https://ultralytics.com/images/bus.jpg" classes="person"

Pour éviter complètement le téléchargement de l’encodeur de texte au moment de l’inférence, intègre une fois les invites dans les poids et réutilise-les — consulte Réutiliser les embeddings d’invite.

Vue d’ensemble de l’architecture#

YOLOE conserve la structure YOLO standard — un backbone convolutif pour l’extraction des caractéristiques, un neck pour la fusion multi-échelle et une tête découplée sans ancres qui prédit les classes et les boîtes — et ajoute trois modules, un par mode d’invite :

• Re-parameterizable Region-Text Alignment (RepRTA) affine les embeddings textuels de CLIP via un petit réseau auxiliaire. Ce réseau s’exécute une fois par appel set_classes() et est fusionné lors de l’exportation ; il ne coûte donc rien par image. En revanche, la comparaison des embeddings d’invite stockés avec les caractéristiques des régions s’exécute à chaque passe avant ; consulte Limitations pour connaître le coût associé à un grand ensemble d’invites.
• Semantic-Activated Visual Prompt Encoder (SAVPE) encode les caractéristiques sémantiques et d’activation d’une boîte d’exemple, afin de conditionner le modèle sur des objets qui lui ressemblent. C’est le chemin one-shot pour les cibles difficiles à nommer, comme un logo ou une partie précise.
• Lazy Region-Prompt Contrast (LRPC) compare les embeddings des régions à un vocabulaire intégré de 4 585 noms ; les checkpoints sans invite reconnaissent ainsi les objets sans invite externe ni encodeur de texte.

La segmentation d’instances provient d’une branche de masques sur la tête de détection, comme dans YOLOv8-Seg, et chaque prédiction contient un masque sur results[0].masks. Une fois le modèle exporté, les modules open-world sont reparamétrés en une tête YOLO standard ; le fichier exporté exécute donc le chemin classique de détection/segmentation.

Modèles disponibles#

Chaque checkpoint ci-dessous est un modèle de segmentation d’instances et prend en charge val, predict, export et track. Charge un fichier *-seg.pt pour les invites textuelles ou visuelles et un fichier *-seg-pf.pt pour l’inférence sans invite ; ils ne sont pas interchangeables, consulte Choisir un mode d’invite. Seuls les fichiers *-seg.pt prennent en charge train ; un checkpoint sans invite est produit à partir d’un modèle entraîné avec invite textuelle, consulte Entraîner les modèles officiels à partir de zéro.

Performances de YOLOE sur LVIS#

Résultats zero-shot sur le jeu minival de LVIS à 640 pixels, issus de l’article Ultralytics YOLO26.

Invites textuelles et visuelles#

Chaque cellule de précision et de paramètres se lit invite textuelle / invite visuelle ; les FLOPs sont indiqués une seule fois. Les paramètres et les FLOPs correspondent à la configuration de détection évaluée dans l’article. La précision est la valeur Non-E2E de l’article, le seul protocole qu’il rapporte pour chaque modèle de la comparaison ; la tête de bout en bout de YOLOE-26 lui est inférieure d’au plus 1.1 AP avec les invites textuelles et 2.6 AP avec les invites visuelles.

Sans invite#

Les checkpoints sans invite répondent à partir de leur vocabulaire intégré, sans invite fournie. Chaque cellule de précision se lit de bout en bout / Non-E2E, les deux protocoles selon lesquels l’article évalue YOLOE-26 ; la page YOLO26 cite la colonne Non-E2E.

Avec les invites textuelles et visuelles, les modèles YOLOE-26 devancent leurs équivalents YOLOE-11 et YOLOE-v8 à chaque échelle correspondante en mAP_50-95, tout en restant en dessous de la gamme v8 en nombre de paramètres et en FLOPs. Sur le même découpage, l’article rapporte YOLO-Worldv2 à 24.4 (S), 32.4 (M) et 35.5 (L), ainsi que les détecteurs basés sur un Transformer GLIP-T à 26.0, GDINO-T à 27.4 et DetCLIP-T à 34.4, chacun comptant de 155 à 232 M de paramètres. L’article original YOLOE ajoute deux résultats pour les modèles à l’échelle v8 qu’il a introduits. Sur LVIS, YOLOE-v8s devance YOLO-Worldv2-S de 3.5 AP, avec un tiers du coût d’entraînement et une vitesse d’inférence multipliée par 1.4. Transféré sur COCO, YOLOE-v8l gagne 0.6 box AP et 0.4 mask AP par rapport à YOLOv8-L à classes fermées, avec un temps d’entraînement presque 4 fois inférieur.

Exemples d’utilisation#

Chaque exemple YOLOE ci-dessous s’exécute depuis la Python API. La prédiction avec invite textuelle, la validation, l’exportation, le suivi et l’entraînement classique fonctionnent également depuis la CLI ; les recettes d’ajustement fin et l’invite visuelle transmettent une classe de trainer ou de predictor comme argument, ce que seule la Python API accepte.

Utilisation pour l’entraînement#

Ajuste finement n’importe quel checkpoint *-seg.pt distribué sur ton propre jeu de données YOLO. Cela suit en grande partie la procédure standard d’entraînement YOLO ; la différence concerne le trainer que tu transmets. YOLOEPESegTrainer fusionne tes noms de classes dans la tête et effectue l’ajustement fin à partir de là, ce qui convient à tes propres étiquettes ; le trainer par défaut n’est pas entraîné avec tes noms de classes.

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEPESegTrainer

model = YOLOE("yoloe-26s-seg.pt")

results = model.train(
    data="coco128-seg.yaml",
    epochs=80,
    patience=10,
    trainer=YOLOEPESegTrainer,  # <- Important: the fine-tuning trainer, not the default
)

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEPETrainer

model = YOLOE("yoloe-26s.yaml").load("yoloe-26s-seg.pt")

results = model.train(data="coco128.yaml", epochs=80, patience=10, trainer=YOLOEPETrainer)

Utilisation de Predict#

L'appel avec invite textuelle est celui présenté dans Démarrage rapide. Les deux autres modes nécessitent chacun un argument supplémentaire :

import numpy as np

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-26l-seg.pt")

# One example box per target, each with its own class ID
visual_prompts = {
    "bboxes": np.array([[221.52, 405.8, 344.98, 857.54], [120, 425, 160, 445]]),  # person, glasses
    "cls": np.array([0, 1]),
}

results = model.predict(
    "ultralytics/assets/bus.jpg",
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

import numpy as np

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-26l-seg.pt")

visual_prompts = {"bboxes": np.array([[221.52, 405.8, 344.98, 857.54]]), "cls": np.array([0])}  # person

results = model.predict(
    "ultralytics/assets/zidane.jpg",  # Target image
    refer_image="ultralytics/assets/bus.jpg",  # Where the example boxes live
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

# refer_image also sets the classes permanently, so later calls need no prompts at all
results = model("ultralytics/assets/bus.jpg")
model.export(format="onnx")  # And the export keeps them

import numpy as np
import torch

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-11l-seg.pt")

img_tensor = torch.rand(1, 3, 480, 480)  # (1, 3, H, W) float tensor in [0, 1]
visual_prompts = {"bboxes": np.array([[10, 10, 50, 50]]), "cls": np.array([0])}

results = model.predict(
    img_tensor,
    refer_image=img_tensor,
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
    imgsz=640,
)

import numpy as np

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOEVPSegPredictor

model = YOLOE("yoloe-26l-seg.pt")

visual_prompts = {
    "bboxes": [
        np.array([[221.52, 405.8, 344.98, 857.54], [120, 425, 160, 445]]),  # bus.jpg: person, glasses
        np.array([[150, 200, 1150, 700]]),  # zidane.jpg: person
    ],
    "cls": [np.array([0, 1]), np.array([0])],
}

results = model.predict(
    ["ultralytics/assets/bus.jpg", "ultralytics/assets/zidane.jpg"],
    visual_prompts=visual_prompts,
    predictor=YOLOEVPSegPredictor,
)
results[0].show()

Utilisation de Val#

La validation s'effectue comme pour tout autre modèle sur un jeu de données de segmentation :

from ultralytics import YOLOE

model = YOLOE("yoloe-26l-seg.pt")  # or yoloe-26s/m-seg.pt for other sizes

metrics = model.val(data="coco128-seg.yaml")

Deux variantes du même appel couvrent les autres modes d'invite :

• Invites visuelles — model.val(data="coco128-seg.yaml", load_vp=True) extrait un plongement visuel par catégorie à partir du jeu de données lui-même. Ajoute refer_data="coco.yaml" pour prendre les plongements d'un autre jeu de données, qui doit contenir exactement les mêmes catégories.
• Sans invite — charge un checkpoint *-seg-pf.pt et passe single_cls=True.

Utilisation de l'exportation#

Les plongements d'invite peuvent être enregistrés une fois, puis réutilisés lors de la production d'exportations statiques telles que ONNX, OpenVINO, TensorRT, CoreML, LiteRT et RKNN. Le profil NPZ est chargé par le modèle PyTorch d'origine avant l'exportation ; il ne constitue pas une entrée d'exécution supplémentaire, et le modèle exporté n'a pas besoin du fichier NPZ.

from ultralytics import YOLOE

model = YOLOE("yoloe-26n-seg.pt")
model.set_classes(["person", "bus"])
model.save_prompt_embeddings("person-bus.npz")

# The profile is bound to the source checkpoint and can be reused for later exports.
model = YOLOE("yoloe-26n-seg.pt")
model.load_prompt_embeddings("person-bus.npz")
model.export(format="onnx")

Le même profil d'invite peut également configurer un modèle limité à la détection, construit à partir de l'architecture YOLOE correspondante. Cela supprime la branche de masques tout en conservant les classes définies par l'invite :

from ultralytics import YOLOE

model = YOLOE("yoloe-26n.yaml").load("yoloe-26n-seg.pt")
model.load_prompt_embeddings("person-bus.npz")
model.export(format="rknn", name="rk3588", quantize=16)

Utilisation de Track#

Les classes définies par l'invite sont directement utilisables pour le suivi, ce qui te permet de suivre des objets sur lesquels le traceur n'a jamais été entraîné :

from ultralytics import YOLOE

model = YOLOE("yoloe-26s-seg.pt")
model.set_classes(["forklift", "pallet"])

# persist=True keeps track IDs stable across frames
for result in model.track("path/to/video.mp4", stream=True, persist=True):
    print(result.boxes.id)

Comparaison de YOLOE#

YOLOE se situe entre un détecteur à ensemble de classes fermé et un modèle à vocabulaire ouvert plus lourd. Trois comparaisons permettent de déterminer s'il constitue le bon choix :

• Face à un YOLO à ensemble fermé. Une fois les invites définies, YOLOE effectue les prédictions via le chemin ordinaire de détection/segmentation et s'exporte comme n'importe quel autre modèle. Ce qu'il apporte, c'est la possibilité de modifier la liste des classes au moment de l'inférence au lieu de réentraîner le modèle ; en contrepartie, sa précision zero-shot est nettement inférieure à celle d'un modèle entraîné sur tes propres classes.
• Face aux précédentes familles YOLOE. YOLOE-26 reprend la tête de bout en bout sans NMS de YOLO26 et couvre cinq échelles (n/s/m/l/x), contre trois auparavant (s/m/l), tout en étant en tête à chaque échelle correspondante dans Performances.
• Face aux détecteurs à vocabulaire ouvert fondés sur des Transformers. GLIP et OWL-ViT exécutent un Transformer vision-langage lors de l'inférence. YOLOE encode les invites une seule fois, puis les compare aux caractéristiques des régions dans une tête convolutionnelle.

Les alternatives les plus proches acceptent toutes une invite textuelle, mais seuls YOLOE et SAM 3 renvoient des masques, et les trois répondent à des questions différentes :

Tu viens de YOLO-World ? La forme de l'API est identique : remplace YOLOWorld par YOLOE, charge un checkpoint *-seg.pt et conserve ton appel set_classes() tel quel. Tu gagnes les masques et les invites visuelles ; la note sur l'exportation concernant les classes figées s'applique aux deux modèles.

Cas d'utilisation et applications#

La détection à vocabulaire ouvert supprime l'étape de réentraînement pour chaque classe, ce qui est particulièrement important lorsque la liste des cibles n'est pas connue à l'avance :

• Détection en monde ouvert — robotique et systèmes de sécurité confrontés à des objets que personne n'avait répertoriés lors de l'entraînement.
• Détection en one-shot à partir d'un exemple — les invites visuelles détectent une pièce, un logo ou un défaut spécifique à partir d'une seule boîte de référence, ce qui est utile pour l'inspection industrielle.
• Catalogage des longues traînes — le vocabulaire intégré de 4 585 noms est suffisamment large pour la surveillance de la biodiversité ou les inventaires de stocks de commerce de détail.
• Amorçage de jeu de données — préannote les images avec des boîtes et des masques avant la vérification humaine, puis entraîne un modèle rapide à ensemble de classes fermé sur le résultat.
• Segmentation de cibles arbitraires — les checkpoints *-seg.pt publiés renvoient un masque avec chaque prédiction ; l'imagerie médicale et l'analyse satellitaire obtiennent ainsi une sortie précise au pixel près sans second modèle.

Un schéma courant combine deux modes : exécuter une fois le mode sans invite pour découvrir ce qui est présent, puis passer aux invites textuelles pour les catégories qui t'intéressent.

Limites#

YOLOE échange de la précision contre la possibilité de modifier les classes au moment de l'inférence. Voici les conséquences à connaître avant de t'engager :

• La précision zero-shot est nettement inférieure à celle d'un modèle entraîné sur tes classes. Les checkpoints avec invite obtiennent environ 22 à 40 mAP sur LVIS minival ; un YOLO à ensemble de classes fermé entraîné sur tes propres données fera mieux sur ces classes. Choisis YOLOE pour couvrir des classes que tu ne peux pas entraîner, et non pour remplacer l'entraînement.
• Les catégories rares sont le point faible. La colonne mAP_r de Performances indique précisément la précision sur les classes rares de LVIS et, avec une invite textuelle, elle se situe sous les colonnes des classes communes et fréquentes à chaque ligne. Consulte-la plutôt que la mAP mise en avant lorsque tes cibles sont inhabituelles.
• Une invite décrit l'apparence, pas les relations. La détection compare les caractéristiques des régions au plongement de l'invite ; les invites dépendant de l'état, du contexte ou d'une comparaison — « endommagé », « le plus à gauche », « celui qui est porté » — ne fournissent aucun repère fiable auquel faire correspondre la cible. Privilégie une formulation proche des noms de catégories courants.
• Les grands ensembles d'invites augmentent la latence. Les plongements d'invite sont calculés une fois, mais comparés aux caractéristiques des régions à chaque passage avant. Mesuré sur CPU avec yoloe-26s-seg.pt, le temps d'un passage avant augmente d'environ 19 % entre 80 et 1 203 classes, et d'environ 89 % avec le vocabulaire complet de 4 585 noms. Les FLOPs indiqués ne changent pas du tout, car la similarité région-texte n'est pas comptabilisée ; le profil ne t'en avertira donc pas.
• Les noms de classes sont des valeurs provisoires tant que tu n'as pas défini d'invite. Un checkpoint *-seg.pt fraîchement chargé renvoie nc=80 avec des noms numériques ("0", "1", …) ; appelle donc set_classes() avant de lire les étiquettes. Les checkpoints sans invite sont déjà fournis avec le vocabulaire complet.

Notes de déploiement#

• Matériel. L'inférence nécessite un GPU NVIDIA disposant de 4 à 8 Go de VRAM ; les échelles n et s s'exécutent sur des GPU périphériques tels que Jetson ou sur CPU à résolution réduite. L'affinage nécessite un seul GPU.
• La NMS est agnostique par classe par défaut. YOLOE prédit avec agnostic_nms=True. Par défaut, cela supprime les boîtes superposées aux scores les plus bas entre différentes classes plutôt qu'uniquement au sein de la même classe, ce qui évite les doublons lorsqu'un objet correspond à plusieurs catégories. Avec nms=False, YOLOE-26 n'applique aucune suppression d'IoU ; le mode agnostique conserve uniquement la meilleure classe par ancre au lieu de laisser une seule ancre émettre plusieurs étiquettes de classe. Passe agnostic_nms=False pour surcharger.
• Traitement par lots. L'inférence par lots fonctionne directement, et les invites visuelles peuvent différer selon l'image au sein d'un même appel.

Entraîner les modèles officiels à partir de zéro#

La plupart des lecteurs n'en auront jamais besoin. Cette procédure reproduit les checkpoints à vocabulaire ouvert publiés à partir de Objects365, GQA et Flickr30k — environ 1,4 M d'échantillons d'entraînement sur 8× RTX 4090 — et n'a aucun rapport avec l'affinage sur tes propres données, qui est décrit plus haut dans Utilisation de l'entraînement.

L'entraînement nécessite des annotations de segments. Télécharge les fichiers traités ci-dessous ou génère les tiens avec le script fourni par l'équipe officielle, qui repose sur SAM 2.1. La validation utilise LVIS minival.

Le modèle à invite textuelle est entraîné en premier, et les deux autres modes d'invite en sont des améliorations :

from ultralytics import YOLOE
from ultralytics.models.yolo.yoloe import YOLOESegTrainerFromScratch

data = {
    "train": {
        "yolo_data": ["Objects365.yaml"],
        "grounding_data": [
            {
                "img_path": "flickr/full_images/",
                "json_file": "flickr/annotations/final_flickr_separateGT_train_segm.json",
            },
            {
                "img_path": "mixed_grounding/gqa/images",
                "json_file": "mixed_grounding/annotations/final_mixed_train_no_coco_segm.json",
            },
        ],
    },
    "val": {"yolo_data": ["lvis.yaml"]},
}

model = YOLOE("yoloe-26l-seg.yaml")
model.train(
    data=data,  # or the path to a YAML file holding the same structure
    batch=128,
    epochs=30,
    close_mosaic=2,
    optimizer="AdamW",
    lr0=2e-3,
    warmup_bias_lr=0.0,
    weight_decay=0.025,
    momentum=0.9,
    workers=4,
    trainer=YOLOESegTrainerFromScratch,
    device="0,1,2,3,4,5,6,7",
)

Les checkpoints à invite visuelle et sans invite partent de ce modèle entraîné avec invite textuelle et mettent chacun à jour un module. YOLOESegVPTrainer correspond à la recette d'invite visuelle et YOLOEPEFreeTrainer à celle sans invite, mais aucun des deux ne gèle quoi que ce soit de lui-même : l'entraînement sélectif provient de la liste freeze que tu passes avec lui, laquelle désigne chaque enfant de la tête à l'exception de savpe (respectivement, chaque tour de classification), et l'exécution sans invite nécessite en plus single_cls=True. Le dépôt YOLOE en amont contient les recettes complètes pour les modèles à l'échelle v8.

Une exécution sans invite terminée est reparamétrée en un checkpoint qui fournit ses noms sans invite lors de l'inférence, à l'aide de get_vocab et set_vocab :

from ultralytics import YOLOE

# Weights written by the prompt-free run and by the text-prompt run it started from. Each
# rerun creates a new directory (train-2, train-3, ...), so take the paths the runs printed.
model = YOLOE("runs/segment/train-2/weights/best.pt")  # prompt-free run, its head is already fused
text_model = YOLOE("runs/segment/train/weights/best.pt")  # text-prompt run, its head is still unfused

names = list(YOLOE("yoloe-26l-seg-pf.pt").model.names.values())  # the 4,585-name vocabulary, or your own list
vocab = text_model.get_vocab(names)

model.set_vocab(vocab, names)
model.save("yoloe-26l-seg-pf-custom.pt")  # never overwrite the released checkpoint

Citations et remerciements#

Si YOLOE a contribué à tes recherches ou à ton projet, cite l'article original par Ao Wang, Lihao Liu, Hui Chen, Zijia Lin, Jungong Han et Guiguang Ding de l'Université Tsinghua :

@misc{wang2025yoloerealtimeseeing,
      title={YOLOE: Real-Time Seeing Anything},
      author={Ao Wang and Lihao Liu and Hui Chen and Zijia Lin and Jungong Han and Guiguang Ding},
      year={2025},
      eprint={2503.07465},
      archivePrefix={arXiv},
      primaryClass={cs.CV},
      url={https://arxiv.org/abs/2503.07465},
}

Pour aller plus loin, l'article original sur YOLOE est disponible sur arXiv. Le code source du projet et des ressources supplémentaires sont accessibles via leur dépôt GitHub.

FAQ#