Choisir la taille d’un modèle Ultralytics YOLO
Compare les tailles n, s, m, l et x de YOLO26, évalue-les sur le matériel cible et choisis la plus petite taille qui respecte ton budget de latence.
Choisis un modèle trop grand et une application pour caméra à 30 FPS tourne à 12 FPS ; choisis-en un trop petit et tu sacrifies la précision qu’un modèle plus grand pourrait offrir gratuitement sur un GPU. Comme la taille choisie pour l’entraînement est aussi celle que tu déploies, cette décision précède le long entraînement.
YOLO26 existe en cinq tailles — n, s, m, l et x — pour les sept tâches : détection, segmentation, segmentation sémantique, classification, pose, OBB et profondeur. Dans cette leçon, tu vas convertir une fréquence d’images en budget de millisecondes, mesurer deux tailles sur ta machine avec le mode Benchmark, puis faire ton choix.
Pratique
Découvrir la gamme#
Voici les chiffres officiels de détection sur COCO tirés de la documentation YOLO26, tous pour une résolution de 640 pixels :
| Modèle | Paramètres (M) | FLOPs (B) | mAP50-95 | Latence CPU ONNX (ms) | Latence T4 TensorRT10 (ms) |
|---|---|---|---|---|---|
yolo26n | 2.4 | 5.5 | 40.9 | 38.9 | 1.7 |
yolo26s | 9.5 | 20.9 | 48.6 | 87.2 | 2.5 |
yolo26m | 20.4 | 68.4 | 53.1 | 220.0 | 4.7 |
yolo26l | 24.8 | 86.8 | 55.0 | 286.2 | 6.2 |
yolo26x | 55.7 | 194.4 | 57.5 | 525.8 | 11.8 |
Chaque taille existe pour chaque tâche : il suffit de changer le suffixe, comme dans yolo26s-seg.pt, yolo26s-sem.pt, yolo26s-depth.pt, yolo26s-cls.pt, yolo26s-pose.pt ou yolo26s-obb.pt. Tu migres un ancien projet ? La comparaison entre YOLO11 et YOLO26 présente les changements.
Lis le tableau en te demandant : « Quel est le coût de la taille suivante ? »
| Étape | Gain de mAP | FLOPs supplémentaires (FLOPs) | Multiplicateur de latence CPU |
|---|---|---|---|
| n → s | +7.7 | ×3.8 | ×2.2 |
| s → m | +4.5 | ×3.3 | ×2.5 |
| m → l | +1.9 | ×1.3 | ×1.3 |
| l → x | +2.5 | ×2.2 | ×1.8 |
La première progression est la plus avantageuse ; après m, chaque point de précision sur COCO coûte cher. Et COCO, avec ses 80 classes variées, est plus difficile que la plupart des projets réels : pour une tâche ciblée, comme détecter un seul produit sur un convoyeur, n et s obtiennent souvent un résultat à un point près de m.
Partir du budget#
Ton budget de latence d’inférence est de 1000 ms ÷ la fréquence d’images cible, et le modèle doit le partager avec le décodage, le dessin et ta propre logique. Voici des points de départ typiques :
| Objectif | Commencer par |
|---|---|
| Téléphone, Raspberry Pi, navigateur ou autre petit appareil d’IA en périphérie | n |
| CPU d’ordinateur portable ou de bureau, 10–30 FPS | n, puis s s’il reste de la marge |
| Un seul GPU, vidéo en temps réel | s ou m |
| Traitement par lots hors ligne, priorité à la précision | l ou x |
Exemple pratique : mesurer deux tailles#
Le mode benchmark exporte le modèle, le valide sur coco8 et mesure le temps d’inférence sur ta machine. format=onnx limite l’exécution à un seul format pour qu’elle se termine en quelques secondes ; omets-le pour comparer tous les formats d’export.
yolo benchmark model=yolo26n.pt imgsz=640 format=onnx
yolo benchmark model=yolo26s.pt imgsz=640 format=onnxRésultats réels sur le processeur d’un ordinateur portable Apple M5 Pro :
| Format Status❔ Size (MB) metrics/mAP50-95(B) Inference time (ms/im) FPS |
| 1 ONNX ✅ 9.5 0.6693 13.87 72.08 | <- yolo26n
| 1 ONNX ✅ 36.5 0.6654 30.87 32.39 | <- yolo26sInterprétons-les avec un budget de 30 FPS (33 ms) :
yolo26n, 13.87 ms : ça passe, avec 19 ms de marge pour le décodage et le dessin.yolo26s, 30.87 ms : ça passe techniquement, mais il ne reste aucune marge pour autre chose. Le même benchmark a pris 60 ms alors que d’autres tâches s’exécutaient sur la machine.Size (MB): la taille du fichier ONNX, importante pour les téléchargements de l’application et la mémoire mobile.metrics/mAP50-95(B): ignore-la ici.coco8contient quatre images de validation : assez pour vérifier que l’export fonctionne, mais beaucoup trop peu pour classer la précision.
Décision : entraîne d’abord yolo26n et garde yolo26s à une valeur imgsz inférieure comme solution de repli.
Éviter ces erreurs#
Symptôme : un modèle qui tournait à 70 FPS sur ton ordinateur portable tourne à 8 FPS sur l'appareil périphérique. Solution : évalue les performances sur l'appareil qui exécutera le modèle, dans des conditions de charge réalistes — autres processus, décodage de la caméra et format d'exécution réel.
Symptôme : dans tes notes, « s était plus rapide que n ». Cause : une exécution utilisait imgsz=480 ou un format différent. Solution : compare les tailles avec le même imgsz, le même format et le même batch, et ne change qu'une variable à la fois.
Ne t'entraîne pas avec x en prévoyant de le réduire plus tard à n grâce à l'élagage du modèle ou à la quantification : une architecture plus petite nécessite un nouvel entraînement. Choisis d'abord la taille ; considère la quantification comme un gain de vitesse supplémentaire venant s'ajouter à la taille adaptée, et non comme un substitut.
L’analyse plus approfondie de la latence — traitement par lots, quantification et choix du moteur d’exécution — est abordée dans Optimisation des coûts et de la latence du cours sur la mise en production, et le guide des métriques de performance explique chaque mesure de précision.
Afficher la solution
Budget: 30 FPS on a laptop CPU -> 33 ms per frame, shared with decode and drawing
Measured: ONNX at 640 -> yolo26n 13.9 ms (19 ms headroom), yolo26s 30.9 ms (none; 60 ms under load)
Decision: train yolo26n first. If accuracy on our val set falls short,
try yolo26s at imgsz=480 and re-benchmark before committing.