What are the key improvements in YOLO26?

DFL-free regression: Simplifies the detection head and export path; End-to-end NMS-free inference: Supports NMS-free inference with nms=False; Progressive Loss + STAL: Improves training alignment and small-object label coverage; MuSGD optimizer: Combines SGD with Muon-inspired optimization for stable training; Task-specific heads and losses: Improves segmentation, pose, and oriented detection support

What tasks does YOLO26 support?

YOLO26 is a unified model family, providing end-to-end support for multiple computer vision tasks: Object Detection; Instance Segmentation; Semantic Segmentation; Monocular Depth Estimation; Image Classification; Pose Estimation; Oriented Object Detection (OBB). Each size variant (n, s, m, l, x) supports all tasks, plus open-vocabulary versions via YOLOE-26.

Why is YOLO26 efficient for deployment?

YOLO26 improves deployment efficiency with: Optional native end-to-end inference without NMS (nms=False); DFL-free regression and a lighter detection head; Fused-model export that removes training-only auxiliary components; Up to 43% faster CPU ONNX inference for YOLO26n versus YOLO11n on an Intel Xeon CPU @ 2.00 GHz; Flexible export formats including TensorRT, ONNX, CoreML, LiteRT, and OpenVINO

How do I get started with YOLO26?

YOLO26 models are available for download through the ultralytics package. Install or update the package and load a model: See the Usage Examples section for training, validation, and export instructions.

Ultralytics YOLO26

YOLO26

ultralytics

Public26

Newest SOTA Ultralytics models, released January 2026. Smaller, faster, and more accurate than previous versions with native end-to-end inference.

7835 models1.5 GBAug 21, 2026

yolo26x-depthyolo26l-depthyolo26m-depth+32

Overview#

Ultralytics YOLO26 is a unified family of real-time vision models described in the Ultralytics YOLO26 paper. It introduces native end-to-end inference, a lighter detection head, an updated training recipe, and task-specific heads for detection, segmentation, classification, pose estimation, and oriented detection.

Across its five detection scales, YOLO26 reaches 40.9-57.5 mAP on COCO at 1.7-11.8 ms T4 TensorRT latency. The paper also reports up to 43% faster CPU ONNX inference for YOLO26n compared with YOLO11n on an Intel Xeon CPU @ 2.00 GHz.

See the unreleased YOLO27 preview for planned architecture, tasks, and preliminary benchmarks.

Ultralytics YOLO26 Comparison Plots

Watch: How to Train a YOLO26 model on Your Custom Dataset in Google Colab.

Quickstart

from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # load a pretrained YOLO26n model
results = model("path/to/bus.jpg")  # run inference

Try on Ultralytics Platform

Explore and run YOLO26 models directly on Ultralytics Platform.

The YOLO26 model family is built around four design areas:

Native end-to-end inference: The optional one-to-one detection head produces predictions without non-maximum suppression (NMS), simplifying deployment and reducing post-processing.
Lighter box regression: YOLO26 removes Distribution Focal Loss (DFL), reducing detection-head complexity while preserving an unconstrained regression range.
Training recipe updates: The training pipeline combines MuSGD (a hybrid Muon + SGD optimizer), Progressive Loss, and STAL (Small-Target-Aware Label Assignment) to improve optimization, shift supervision toward the inference-time head, and maintain positive label coverage for small objects. The full hyperparameters behind the released checkpoints are documented in the YOLO26 Training Recipe guide.
Task-specific heads and losses: YOLO26 adds targeted designs for instance segmentation, semantic segmentation variants, pose estimation, and oriented detection while keeping a single model pipeline across tasks.

Together, these updates improve the accuracy-latency tradeoff across model scales and deployment targets.

Key Features#

DFL-Free Regression YOLO26 removes Distribution Focal Loss (DFL), reducing detection-head complexity and simplifying export.
End-to-End NMS-Free Inference YOLO26 supports native end-to-end inference with nms=False, producing predictions without a separate NMS pass. The default one-to-many path uses NMS for accuracy.
Progressive Loss + STAL Progressive Loss shifts training emphasis toward the inference-time head, while STAL improves positive label coverage for small objects.
MuSGD Optimizer A hybrid optimizer that combines SGD with Muon, adapting optimization ideas from large language model training to computer vision.
Efficient Deployment The simplified head and optional NMS-free path reduce inference overhead across export targets and hardware profiles, including the paper's reported CPU ONNX speedup for YOLO26n versus YOLO11n.
Instance Segmentation Enhancements Introduces semantic segmentation loss to improve model convergence and an upgraded proto module that uses multi-scale information for better mask quality. The paper reports gains over YOLO11 of up to +2.5 box AP and +3.7 mask AP on COCO instance segmentation.
Precision Pose Estimation Integrates Residual Log-Likelihood Estimation (RLE) for more accurate keypoint localization and optimizes the decoding process for increased inference speed. The paper reports up to +7.2 AP over YOLO11 on COCO pose estimation.
Refined OBB Decoding Introduces a specialized angle loss to improve detection accuracy for square-shaped objects and optimizes OBB decoding to resolve boundary discontinuity issues. The paper reports up to +3.4 mAP over YOLO11 on DOTA-v1.0 oriented detection.

Ultralytics YOLO26 End-to-End Comparison Plots

Supported Tasks and Modes#

YOLO26 supports the standard Ultralytics task set across five model scales:

Model	Filenames	Task	Training	Validation	Inference	Export
YOLO26	`yolo26n.pt` `yolo26s.pt` `yolo26m.pt` `yolo26l.pt` `yolo26x.pt`	Detection	✅	✅	✅	✅
YOLO26-seg	`yolo26n-seg.pt` `yolo26s-seg.pt` `yolo26m-seg.pt` `yolo26l-seg.pt` `yolo26x-seg.pt`	Instance Segmentation	✅	✅	✅	✅
YOLO26-sem	`yolo26n-sem.pt` `yolo26s-sem.pt` `yolo26m-sem.pt` `yolo26l-sem.pt` `yolo26x-sem.pt`	Semantic Segmentation	✅	✅	✅	✅
YOLO26-depth	`yolo26n-depth.pt` `yolo26s-depth.pt` `yolo26m-depth.pt` `yolo26l-depth.pt` `yolo26x-depth.pt`	Depth Estimation	✅	✅	✅	✅
YOLO26-cls	`yolo26n-cls.pt` `yolo26s-cls.pt` `yolo26m-cls.pt` `yolo26l-cls.pt` `yolo26x-cls.pt`	Classification	✅	✅	✅	✅
YOLO26-pose	`yolo26n-pose.pt` `yolo26s-pose.pt` `yolo26m-pose.pt` `yolo26l-pose.pt` `yolo26x-pose.pt`	Pose/Keypoints	✅	✅	✅	✅
YOLO26-obb	`yolo26n-obb.pt` `yolo26s-obb.pt` `yolo26m-obb.pt` `yolo26l-obb.pt` `yolo26x-obb.pt`	Oriented Detection	✅	✅	✅	✅

This unified framework covers real-time detection, instance segmentation, semantic segmentation, monocular depth estimation, classification, pose estimation, and oriented object detection with training, validation, inference, and export support.

Architecture-only variants

yolo26-p2.yaml and yolo26-p6.yaml add a P2 (small-object) or P6 (large-input) detection head and are shipped as YAML architectures only. No scale-specific yolo26*-p2.pt or yolo26*-p6.pt weights are released. Instantiate a scaled config from YAML (for example, YOLO("yolo26n-p6.yaml")) and train or fine-tune it as needed.

Performance Metrics#

Performance

See Detection Docs for usage examples with these models trained on COCO, which include 80 pretrained classes.

Model	size ^(pixels)	mAP^val_50-95	mAP^val_50-95 (e2e)	Speed ^{CPU ONNX (ms)}	Speed ^{T4 TensorRT10 (ms)}	params ^(M)	FLOPs ^(B)
YOLO26n	640	40.9	40.1	38.9 ± 0.7	1.7 ± 0.0	2.4	5.5
YOLO26s	640	48.6	47.8	87.2 ± 0.9	2.5 ± 0.0	9.5	20.9
YOLO26m	640	53.1	52.5	220.0 ± 1.4	4.7 ± 0.1	20.4	68.4
YOLO26l	640	55.0	54.4	286.2 ± 2.0	6.2 ± 0.2	24.8	86.8
YOLO26x	640	57.5	56.9	525.8 ± 4.0	11.8 ± 0.2	55.7	194.4

Params and FLOPs values are for the fused model after Conv/BatchNorm folding and removal of the unused detection branch. Speed measurements select the NMS-free head with nms=False. Pretrained checkpoints retain the full training architecture and may show higher counts.

Usage Examples#

This section provides simple YOLO26 training and inference examples.

The example below trains a YOLO26 Detect model for object detection on the COCO8 example dataset.

Example

PyTorch pretrained *.pt models as well as configuration *.yaml files can be passed to the YOLO() class to create a model instance in Python:

from ultralytics import YOLO

# Load a COCO-pretrained YOLO26n model
model = YOLO("yolo26n.pt")

# Run inference with the YOLO26n model on the 'bus.jpg' image
results = model("path/to/bus.jpg")

# Train the model on the COCO8 example dataset for 100 epochs
results = model.train(data="coco8.yaml", epochs=100, imgsz=640)

Dual-Head Architecture

YOLO26 detection models use a dual-head architecture that provides flexibility for different deployment scenarios:

One-to-Many Head (Default): Generates traditional YOLO outputs requiring NMS post-processing, outputting (N, nc + 4, 8400) where nc is the number of classes. This head typically achieves slightly higher accuracy at the cost of additional processing.
One-to-One Head (nms=False): Produces end-to-end predictions without NMS, outputting (N, 300, 6) with a maximum of 300 detections per image. This head is optimized for fast inference and simplified deployment.

You can switch between heads during export, prediction, or validation:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")

# Use one-to-many head (default, Ultralytics applies NMS)
results = model.predict("image.jpg")  # inference
metrics = model.val(data="coco.yaml")  # validation
model.export(format="onnx")  # export

# Opt into the NMS-free one-to-one head
results = model.predict("image.jpg", nms=False)  # inference
metrics = model.val(data="coco.yaml", nms=False)  # validation
model.export(format="onnx", nms=False)  # export

Prediction and validation default to the one-to-many head for accuracy. Use nms=False for NMS-free inference, or nms=True to embed NMS in a supported export. Both heads are trained regardless of this choice. See the End-to-End Detection guide for output formats and export compatibility.

YOLOE-26: Open-Vocabulary Detection and Segmentation#

YOLO26 also powers YOLOE-26, an open-vocabulary variant that detects and segments object categories from text prompts, visual prompts, or a prompt-free mode instead of a fixed class list learned at training time. YOLOE-26 keeps YOLO26's optional NMS-free end-to-end (e2e) head, so open-vocabulary inference stays fast enough for dynamic environments where target categories change over time. YOLOE-26x reaches 40.6 AP on LVIS minival under text prompting, 38.5 AP under visual prompting and 31.1 AP prompt-free — the paper's Non-E2E figures, which its end-to-end head trails by 1.1, 2.3 and 1.2 AP.

See the YOLOE documentation for per-scale performance tables, prompt-free variants, and full usage examples.

Citations and Acknowledgments#

For a complete technical description of the YOLO26 architecture, training recipe, task heads, and YOLOE-26 open-vocabulary extension, read Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models. If you use YOLO26 in your research, please cite:

Citation

@misc{jocher2026ultralyticsyolo26unifiedrealtime,
  title = {Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models},
  author = {Glenn Jocher and Jing Qiu and Mengyu Liu and Shuai Lyu and Fatih Cagatay Akyon and Muhammet Esat Kalfaoglu},
  year = {2026},
  eprint = {2606.03748},
  archivePrefix = {arXiv},
  primaryClass = {cs.CV},
  doi = {10.48550/arXiv.2606.03748},
  url = {https://arxiv.org/abs/2606.03748},
}

YOLO26 code, models, and documentation are available in the Ultralytics GitHub repository and Ultralytics Docs under AGPL-3.0 and Enterprise licenses.

FAQ#

- DFL-free regression: Simplifies the detection head and export path
- End-to-end NMS-free inference: Supports NMS-free inference with nms=False
- Progressive Loss + STAL: Improves training alignment and small-object label coverage
- MuSGD optimizer: Combines SGD with Muon-inspired optimization for stable training
- Task-specific heads and losses: Improves segmentation, pose, and oriented detection support
YOLO26 is a unified model family, providing end-to-end support for multiple computer vision tasks:
Each size variant (n, s, m, l, x) supports all tasks, plus open-vocabulary versions via YOLOE-26.
YOLO26 improves deployment efficiency with:
- Optional native end-to-end inference without NMS (nms=False)
- DFL-free regression and a lighter detection head
- Fused-model export that removes training-only auxiliary components
- Up to 43% faster CPU ONNX inference for YOLO26n versus YOLO11n on an Intel Xeon CPU @ 2.00 GHz
- Flexible export formats including TensorRT, ONNX, CoreML, LiteRT, and OpenVINO
YOLO26 models are available for download through the ultralytics package. Install or update the package and load a model:
from ultralytics import YOLO # Load a pretrained YOLO26 nano model model = YOLO("yolo26n.pt") # Run inference on an image results = model("image.jpg")
See the Usage Examples section for training, validation, and export instructions.

Contributors

glenn-jocher¹⁷

raimbekovm¹¹

Laughing-q⁵

Y-T-G³

Created Sep 25, 2025Updated 4 days ago

Comments¹¹⁵

Ask a question, share your results, or help someone else.

hongzhuoxx Sep 26, 2025
除了监督模型，我还期待着ultralytics可以推出高效准确易用的非监督瑕疵检测模型！
4
Syedshajib55 Jan 31, 2026
How do I modify the architectural components (Head and Neck) of YOLOv26?

What is the process for inserting a Dropout layer at the end of the backbone in the YOLOv26 configuration?
2
1. Glenn JocherUltralyticsJan 31, 2026
  YOLO26 (no “v”) architecture edits are done in the model YAML, so start by copying ultralytics/cfg/models/26/yolo26.yaml into your project, modify the backbone: / head: layer lists (the “neck” is part of head:), and train from that YAML following the Model YAML Configuration Guide.
  
  # yolo26_custom.yaml backbone: # ... existing backbone layers ... - [-1, 1, nn.Dropout, [0.2]] # add dropout at end of backbone (train-time only) head: # ... existing head/neck layers ...
  
  yolo train model=yolo26_custom.yaml data=your_dataset.yaml imgsz=640
  
  If you share which task model you’re editing (detect / seg / pose / obb) and which variant (n/s/m/l/x), we can point you to the exact YAML to start from and where to insert the change in that graph.
  1
2. Syedshajib55 Feb 27, 2026
  Hi Glenn,
  
  Thank you for the quick response and guidance! To answer your question: I am focusing on the detect task, and I will be experimenting with both the s (small) and m (medium) variants.
  
  For context, I am working on a paper targeting a Q1 journal. My project focuses on Emotion Detection (5 classes: Angry, Happy, Sad, Neutral, Surprised) using the RAVDESS dataset. I have extracted peak emotion frames from the videos and augmented the dataset to roughly 21k images (640x640 resolution). My core research objective is to demonstrate that a customized YOLO26 architecture can outperform the standard baseline for detecting subtle facial micro-expressions. To achieve this, I want to modify the backbone—specifically by adding Batch Normalization and Dropout layers (potentially after the C2f blocks or may be after c3k2 blocks of that yolo26 architechtural images) to improve regularization and prevent overfitting on facial features.
  
  Could you help me with the following?
  
  Could you point me to the exact base YAML files for the yolo26s and yolo26m detection models to use as my starting point?
  
  From an architectural standpoint, where exactly in the backbone would you theoretically recommend inserting these Dropout/BN layers? (e.g., after which specific layer index or block) to maximize accuracy without degrading the spatial feature maps necessary for facial detection?
  
  Any insights on how to best structure this custom YAML would be incredibly helpful. Thanks again for your time!
3. Syedshajib55 Feb 27, 2026
  Baseline Reference: Finally, could you share the raw YAML configuration code that details the standard YOLO26 backbone and head? I would like to include this exact baseline structure in my paper’s methodology section to clearly contrast it with my proposed modifications.
hbzylilin Nov 10, 2025
延迟了10天了，还没动静
1
lwplw Oct 21, 2025
真不错，期待开源
1
1. Glenn JocherUltralyticsOct 21, 2025(edited)
  @etemical 感谢建议！目前未原生支持行为识别/多目标行为检测；建议先用 YOLO26 组合 detect + track 多目标跟踪与可选 pose 关键点作为上游信号，并在 GitHub 提交详细需求（数据标注格式与评测指标）为 Feature Request 模板便于评估；参考 Track 模式文档与 Pose 任务文档。
  
  yolo track model=yolo26n.pt source=your_video.mp4 tracker=bytetrack.yaml show=True yolo pose predict model=yolo26n-pose.pt source=your_video.mp4 show=True
  
  @lwplw 谢谢关注！YOLO26 现已发布，可阅读我们的 YOLO26 介绍博客了解功能。
cyberpunk-edgerunner Oct 10, 2026
maybe CIFAR-10-LT dataset can help. you do not need background images because our initial conversation started without that, for an image, there can be one to 15 object in one image The cause of the shared-memory increase will remain unconfirmed unless you run python train.py in your computer with an rtx gpu

On Sat, Oct 10, 2026 at 6:15 AM Paula Derrenger @.***> wrote:

Understood—you don’t need to interrupt your work for the batch=16 comparison. Could you name a public long-tailed dataset you consider representative and share your approximate class counts, background-image proportion, and typical/maximum objects per image? That would help define a reproduction using the configuration you already shared, without requiring your company’s data or another production run. The cause of the shared-memory increase remains unconfirmed.

— Reply to this email directly, view it on GitHub https://github.com/orgs/ultralytics/discussions/26446?email_source=notifications&email_token=BSIM7DUZ6A5KFG7YKF2H6KT5TGBBRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2DONBZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18844749, or unsubscribe https://github.com/notifications/unsubscribe-auth/BSIM7DTBK4XV3HXIPMFHVXT5TGBBRAVCNFSNUABIKJSXA33TNF2G64TZHM2TGNJTGYYDINBVHNCGS43DOVZXG2LPNY5TCMBZGE3TMNRUUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BSIM7DST66YNYHAKPWPY3PT5TGBBRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2DONBZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BSIM7DRDX2BJPHP7PHHKRG35TGBBRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGQ2DONBZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you commented.Message ID: @.*** com>
1. Paula DerrengerUltralyticsOct 10, 2026
  Thanks for clarifying the 1–15 objects per image; we can keep background-only images out of the reproduction. CIFAR-10-LT is a long-tailed classification benchmark, so it would not directly reproduce your multi-object detection setup. I can’t execute python train.py on an RTX GPU here, and I haven’t reproduced the shared-memory increase. Could you share a public-data version of the script, including dataset preparation, so someone with suitable hardware can run the same test without your company’s data?
cyberpunk-edgerunner Oct 9, 2026
I cannot run the same code with batch=16, reasons:
1. I work in a company and have my own KPI to meet and improve
2. I have added background image data in the dataset so it is no longer same.
3. I am planning to add more images in future.
I suggest you download a long tailed distributed dataset to mimic my experiment.

thank you

On Fri, Oct 9, 2026 at 5:15 AM Paula Derrenger @.***> wrote:

Thanks for clarifying that it was 15 GB of shared GPU memory and sharing the configuration; sorry for requesting the script again. To test whether batch-related memory pressure contributes, could you compare your batch=64 run with batch=16, keeping all other settings unchanged? See the batch-size guidance https://docs.ultralytics.com/guides/model-training-tips#batch-size-and-gpu-utilization. Please share epoch 2–3 text logs and dedicated/shared GPU memory readings from the comparison; this will help narrow down the cause without assuming the memory change is a bug.

— Reply to this email directly, view it on GitHub https://github.com/orgs/ultralytics/discussions/26446?email_source=notifications&email_token=BSIM7DWLJ3KRNTXM7Y6Q4O35TARKLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGI2TINRTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18825463, or unsubscribe https://github.com/notifications/unsubscribe-auth/BSIM7DQLZ4KWCGA6TEUDIS35TARKLAVCNFSNUABIKJSXA33TNF2G64TZHM2TGNJTGYYDINBVHNCGS43DOVZXG2LPNY5TCMBZGE3TMNRUUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BSIM7DV53PCZWPENVMYYNYT5TARKLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGI2TINRTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BSIM7DX2XUXERTKYLIDJ2C35TARKLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGI2TINRTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you commented.Message ID: @.*** com>
1. Paula DerrengerUltralyticsOct 10, 2026
  Understood—you don’t need to interrupt your work for the batch=16 comparison. Could you name a public long-tailed dataset you consider representative and share your approximate class counts, background-image proportion, and typical/maximum objects per image? That would help define a reproduction using the configuration you already shared, without requiring your company’s data or another production run. The cause of the shared-memory increase remains unconfirmed.
cyberpunk-edgerunner Oct 8, 2026
1. I have shared you exact code in this email thread(check my second reply) and the command to run it was `python .\det_yoloM_5-10.py' .
2. yes, it was 15GB of shared GPU
3. sorry, I do not have separate dedicated/shared memory readings at comparable batch positions in each epoch, but there was a steady consumption of about 15GB of shared memory throughout the training. however I can provide you argos.yaml
task: detect mode: train model: yolo26m.pt data: yoloDet_clsAgnostic_split/data.yaml epochs: 200 time: null patience: 20 batch: 64 imgsz: 640 save: true save_period: -1 cache: false device: '0' workers: 6 project: null name: train-2 exist_ok: false pretrained: true cls_remap: true optimizer: auto verbose: false seed: 0 deterministic: true single_cls: false rect: false cos_lr: false close_mosaic: 10 resume: false amp: true fraction: 1.0 profile: false freeze: null multi_scale: 0.0 compile: false channels_last: null overlap_mask: true mask_ratio: 4 dropout: 0.0 val: true split: val save_json: false conf: null iou: 0.7 max_det: 300 quantize: null dnn: false plots: true nms: null source: null vid_stride: 1 stream_buffer: false visualize: false augment: false agnostic_nms: false classes: null retina_masks: false embed: null show: false save_frames: false save_txt: false save_conf: false save_crop: false show_labels: true show_conf: true show_boxes: true line_width: null format: torchscript keras: false optimize: false dynamic: false simplify: true opset: null workspace: null lr0: 0.01 lrf: 0.01 momentum: 0.937 weight_decay: 0.0005 warmup_epochs: 3.0 warmup_momentum: 0.8 warmup_bias_lr: 0.1 distill_model: null dis: 6.0 box: 7.5 cls: 0.5 cls_pw: 0.0 dfl: 1.5 pose: 12.0 kobj: 1.0 rle: 1.0 angle: 1.0 dlog: 1.0 dgrad: 0.5 dlam: 1.0 nbs: 64 hsv_h: 0.015 hsv_s: 0.7 hsv_v: 0.4 degrees: 0.0 translate: 0.1 scale: 0.5 shear: 0.0 perspective: 0.0 flipud: 0.0 fliplr: 0.5 bgr: 0.0 mosaic: 1.0 mixup: 0.0 cutmix: 0.0 copy_paste: 0.0 copy_paste_mode: flip auto_augment: randaugment erasing: 0.4 cfg: null tracker: tracktrack.yaml save_dir: C:\Training9\runs\detect\train-2

On Thu, Oct 8, 2026 at 6:07 AM Paula Derrenger @.***> wrote:

Thanks for the complete checks and text logs. Epoch 2 is faster (14:27 versus 1:02:39), despite GPU_mem dropping from 28.6G to 17.4G, so these readings alone don’t establish GPU underutilization. Could you paste your exact training command or script, including the model and training settings? Also, does “around 15 epoch” mean 15 GB of shared GPU memory in both epochs? Please provide separate dedicated/shared memory readings at comparable batch positions in each epoch so we can investigate the discrepancy.

— Reply to this email directly, view it on GitHub https://github.com/orgs/ultralytics/discussions/26446?email_source=notifications&email_token=BSIM7DQKA3GIYQSCDVEWEJ35S3OWHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGAZTKNJWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18803556, or unsubscribe https://github.com/notifications/unsubscribe-auth/BSIM7DX34MSUWFFX5WDRXW35S3OWHAVCNFSNUABIKJSXA33TNF2G64TZHM2TGNJTGYYDINBVHNCGS43DOVZXG2LPNY5TCMBZGE3TMNRUUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BSIM7DSVPQ3LAONGDZOZWWD5S3OWHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGAZTKNJWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BSIM7DQHEDECXNLNQEWJLC35S3OWHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGAZTKNJWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you commented.Message ID: @.*** com>
1. Paula DerrengerUltralyticsOct 8, 2026
  Thanks for clarifying that it was 15 GB of shared GPU memory and sharing the configuration; sorry for requesting the script again. To test whether batch-related memory pressure contributes, could you compare your batch=64 run with batch=16, keeping all other settings unchanged? See the batch-size guidance. Please share epoch 2–3 text logs and dedicated/shared GPU memory readings from the comparison; this will help narrow down the cause without assuming the memory change is a bug.
cyberpunk-edgerunner Oct 6, 2026
here are my yolo checks yolo checks Ultralytics 8.4.155 Python-3.13.12 torch-2.12.0.dev20260408+cu128 CUDA:0 (NVIDIA GeForce RTX 5090, 32607MiB) Setup complete (24 CPUs, 63.5 GB RAM, 1738.9/1881.5 GB disk)

OS Windows-11-10.0.26200-SP0 Environment Windows Python 3.13.12 Install pip Path C:\Users\devth\miniconda3\Lib\site-packages\ultralytics RAM 63.46 GB Disk 1738.9/1881.5 GB CPU Intel Core Ultra 9 285K CPU count 24 GPU NVIDIA GeForce RTX 5090, 32607MiB GPU count 1 CUDA 12.8

cloudpickle 3.1.2>=3.1.1 filelock 3.29.0>=3.16.1 numpy 2.4.4>=1.23.0; platform_system != "Darwin" numpy 2.4.4!=2.0.,!=2.1.,!=2.2.*,!=2.3.0,!=2.3.1,!=2.3.2,!=2.3.3,!=2.3.4,>=1.23.0; platform_system == "Darwin" matplotlib 3.10.8>=3.3.0 opencv-python 4.13.0.92!=4.13.0.90,>=4.7.0 pillow 12.2.0>=7.1.2 pyyaml 6.0.3>=5.3.1 requests 2.32.5>=2.23.0 torch 2.12.0.dev20260408+cu128>=1.8.0 torch 2.12.0.dev20260408+cu128!=2.4.0,>=1.8.0; sys_platform == "win32" torchvision 0.27.0.dev20260407+cu128>=0.9.0 psutil 7.2.2>=5.8.0 polars 1.40.1>=0.20.0 nvidia-ml-py 13.610.43>=12.0.0 ultralytics-thop 2.1.6>=2.1.6 ultralytics-platform 0.1.48>=0.1.45; python_version >= "3.11"

(shared memory used in first and second epoch was around 15 epoch) these are the first two epoch details in Text
Epoch GPU_mem box_loss cls_loss l1_loss Instances Size 1/200 28.6G 1.174 1.891 0.01363 90
640: 33% ━━━╸──────── 1561/4702 1.1it/s 23:55<49:25libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.15 1.582 0.01327 91 640: 56% ━━━━━━╸───── 2674/4702 1.3it/s 40:45<26:43libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.144 1.475 0.01325 77 640: 72% ━━━━━━━━╸─── 3419/4702 1.3it/s 49:44<16:45libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.144 1.471 0.01325 84 640: 73% ━━━━━━━━╸─── 3451/4702 1.4it/s 50:07<14:41libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.146 1.395 0.01332 84 640: 92% ━━━━━━━━━━━─ 4370/4702 5.0it/s 1:01:16<1:07libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.146 1.373 0.01335 74 640: 100% ━━━━━━━━━━━━ 4702/4702 1.3it/s 1:02:39 Class Images Instances Box(P R mAP₅₀ mAP_50-95): 22% ━━╸───────── 57/256 2.5it/s 26.7s<1:19libpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 47% ━━━━━╸────── 122/256 2.3it/s 1:10<59.4slibpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 100% ━━━━━━━━━━━━ 256/256 1.9it/s 2:17 all 32677 47931 0.863 0.726 0.818 0.584
Epoch GPU_mem box_loss cls_loss l1_loss Instances
Size 2/200 17.4G 1.183 1.123 0.01413 74 640: 29% ━━━╸──────── 1380/4702 5.1it/s 4:16<10:45libpng warning: iCCP: known incorrect sRGB profile 2/200 17.4G 1.196 1.133 0.01441 107 640: 55% ━━━━━━╸───── 2615/4702 5.8it/s 8:09<6:02libpng warning: iCCP: known incorrect sRGB profile 2/200 17.4G 1.193 1.126 0.01434 99 640: 64% ━━━━━━━╸──── 3020/4702 5.5it/s 9:20<5:06libpng warning: iCCP: known incorrect sRGB profile 2/200 17.4G 1.193 1.125 0.01435 106 640: 67% ━━━━━━━━──── 3179/4702 5.6it/s 9:50<4:33libpng warning: iCCP: known incorrect sRGB profile 2/200 17.4G 1.192 1.121 0.01434 109 640: 81% ━━━━━━━━━╸── 3847/4702 5.5it/s 11:52<2:36libpng warning: iCCP: known incorrect sRGB profile 2/200 17.4G 1.195 1.12 0.01437 86 640: 100% ━━━━━━━━━━━━ 4702/4702 5.4it/s 14:27 Class Images Instances Box(P R mAP₅₀ mAP_50-95): 22% ━━╸───────── 57/256 2.5it/s 20.6s<1:21libpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 47% ━━━━━╸────── 122/256 2.1it/s 50.3s<1:04libpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 100% ━━━━━━━━━━━━ 256/256 2.3it/s 1:51 all 32677 47931 0.889 0.778 0.87 0.638

On Tue, Oct 6, 2026 at 10:29 AM Paula Derrenger @.***> wrote:

No—by “yolo checks output,” I mean the terminal’s software/hardware summary, not results.csv. Please activate the same Python environment used for training, run yolo checks in PowerShell, and paste its complete text output; it reports your Ultralytics, Python, PyTorch, and GPU details (environment checks reference https://docs.ultralytics.com/reference/utils/checks#ultralytics.utils.checks.check_yolo). (docs.ultralytics.com https://docs.ultralytics.com/reference/utils/checks) Thanks for sharing the driver information. Please also provide separate dedicated/shared GPU-memory readings at matching points in epochs 1 and 2, plus your training command or configuration, so we can investigate without assuming the memory drop indicates hardware underutilization.

— Reply to this email directly, view it on GitHub https://github.com/orgs/ultralytics/discussions/26446?email_source=notifications&email_token=BSIM7DSK7MKPVE56RJJGI435SR33BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXG4YDKNJSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18770552, or unsubscribe https://github.com/notifications/unsubscribe-auth/BSIM7DRBVYTDNBPWAZRUQXL5SR33BAVCNFSNUABIKJSXA33TNF2G64TZHM2TGNJTGYYDINBVHNCGS43DOVZXG2LPNY5TCMBZGE3TMNRUUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BSIM7DXMRZI3YZR75VFDAGT5SR33BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXG4YDKNJSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BSIM7DRXQCNW5JUZNGVDHU35SR33BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXG4YDKNJSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you commented.Message ID: @.*** com>
1. Paula DerrengerUltralyticsOct 8, 2026
  Thanks for the complete checks and text logs. Epoch 2 is faster (14:27 versus 1:02:39), despite GPU_mem dropping from 28.6G to 17.4G, so these readings alone don’t establish GPU underutilization. Could you paste your exact training command or script, including the model and training settings? Also, does “around 15 epoch” mean 15 GB of shared GPU memory in both epochs? Please provide separate dedicated/shared memory readings at comparable batch positions in each epoch so we can investigate the discrepancy.
cyberpunk-edgerunner Oct 6, 2026
pls explain what is yolo checks output? what do you mean by that ? are you referring to results.csv from runs folder??

here is my driver detail PS C:\Training9> nvidia-smi Tue Oct 6 09:22:05 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 610.60 KMD Version: 610.60 CUDA UMD Version: 13.3 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Driver-Model | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 5090 WDDM | 00000000:01:00.0 On | N/A | | 57% 73C P1 479W / 575W | 19362MiB / 32607MiB | 80% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+

PS C:\Training9> nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2025 NVIDIA Corporation Built on Wed_Jan_15_19:38:46_Pacific_Standard_Time_2025 Cuda compilation tools, release 12.8, V12.8.61 Build cuda_12.8.r12.8/compiler.35404655_0

epoch 1 vram usage(in terminal) = 28.6 GB and in task manager ~29.1 GB epoch 2 to epoch 73 vram usage (in terminal) = 17.4 GB and in task manager vram usage is 18.1 GB

73rd epoch
Epoch GPU_mem box_loss cls_loss l1_loss Instances
Size 73/200 17.4G 0.9935 0.7903 0.01002 86 640: 0% ──────────── 4/4702 4.4it/s 1.0s<17:51libpng warning: iCCP: known incorrect sRGB profile 73/200 17.4G 1.023 0.7368 0.01159 84 640: 9% ━─────────── 446/4702 5.8it/s 1:17<12:17libpng warning: iCCP: known incorrect sRGB profile 73/200 17.4G 1.024 0.7397 0.01152 93 640: 63% ━━━━━━━╸──── 2990/4702 5.6it/s 8:41<5:06libpng warning: iCCP: known incorrect sRGB profile 73/200 17.4G 1.024 0.7402 0.01151 119 640: 65% ━━━━━━━╸──── 3080/4702 5.3it/s 8:57<5:06libpng warning: iCCP: known incorrect sRGB profile 73/200 17.4G 1.026 0.7422 0.01152 113 640: 76% ━━━━━━━━━─── 3586/4702 5.6it/s 10:28<3:20libpng warning: iCCP: known incorrect sRGB profile 73/200 17.4G 1.029 0.7459 0.01156 78 640: 100% ━━━━━━━━━━━━ 4702/4702 5.7it/s 13:46 Class Images Instances Box(P R mAP₅₀ mAP_50-95): 22% ━━╸───────── 57/256 2.7it/s 20.9s<1:13libpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 47% ━━━━━╸────── 122/256 2.1it/s 48.9s<1:02libpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 100% ━━━━━━━━━━━━ 256/256 2.4it/s 1:47 all 32677 47931 0.927 0.855 0.93 0.724

since you are trying to replicate my detection code , I must tell you in my train folder I have around 150000 images with txt files, 32000 in val and 31000 in test

while you are at it, I need a change in the ultralytics package, since it can detect and restore corrupt JPG(and many more errors), would it possible for you to make this change permanent? since it a type of fix and everyone wants that and no one wants to ultralytics package to just internally fix the images i know it won't be implemented by of security reasons by just keep in future todo list

to be honest , in my view, the ultralytics package does not fully utilise the hardware. I have run barebone code that using just the pytorch and few more basic codes and they utilise

thank you in advance

On Mon, Oct 5, 2026 at 10:42 PM Paula Derrenger @.***> wrote:

Thanks for sharing the script. A plausible explanation for the drop from 28.6G to 17.4G is cache cleanup between epochs: the training loop https://docs.ultralytics.com/reference/engine/trainer#ultralytics.engine.trainer.BaseTrainer._do_train conditionally clears reserved memory before validation and at epoch end when usage exceeds 50% of device capacity. This could explain the drop, but does not establish why Windows reports shared-memory usage. ( docs.ultralytics.com https://docs.ultralytics.com/reference/engine/trainer) Please share yolo checks output, your NVIDIA driver version, and dedicated/shared GPU-memory readings as text at matching points in both epochs so we can check your installed version and distinguish the two observations.

— Reply to this email directly, view it on GitHub https://github.com/orgs/ultralytics/discussions/26446?email_source=notifications&email_token=BSIM7DSOVWTY24AP4M6GU5D5SPI7FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGYZTCOJVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18763195, or unsubscribe https://github.com/notifications/unsubscribe-auth/BSIM7DUUEOVQC4A4Q7SCGUL5SPI7FAVCNFSNUABIKJSXA33TNF2G64TZHM2TGNJTGYYDINBVHNCGS43DOVZXG2LPNY5TCMBZGE3TMNRUUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BSIM7DVWK73UY4PTSMIRTTL5SPI7FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGYZTCOJVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BSIM7DW6Q4F7VJMCOTRDMPD5SPI7FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGYZTCOJVUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you commented.Message ID: @.*** com>
1. Paula DerrengerUltralyticsOct 6, 2026
  No—by “yolo checks output,” I mean the terminal’s software/hardware summary, not results.csv. Please activate the same Python environment used for training, run yolo checks in PowerShell, and paste its complete text output; it reports your Ultralytics, Python, PyTorch, and GPU details (environment checks reference). (docs.ultralytics.com) Thanks for sharing the driver information. Please also provide separate dedicated/shared GPU-memory readings at matching points in epochs 1 and 2, plus your training command or configuration, so we can investigate without assuming the memory drop indicates hardware underutilization.
cyberpunk-edgerunner Oct 5, 2026
exact training command/code ` from multiprocessing import freeze_support import os os.environ['PYTORCH_ALLOC_CONF'] = 'expandable_segments:True' import torch

def main(): from ultralytics import YOLO
print("Clearing CUDA cache before training...\n") torch.cuda.empty_cache() model = YOLO("yolo26m.pt") model.train( data='yoloDet_clsAgnostic_split/data.yaml', epochs=200, batch=64, workers=6, device=0, # freeze=10, patience=20, verbose=False, save=True ) print("\nClearing CUDA cache after training...\n") torch.cuda.empty_cache()
if name == 'main': freeze_support() main() `

another question - how can there be a difference of 10GB in dedicated VRAM consumption in the second epoch??? ` Epoch GPU_mem box_loss cls_loss l1_loss Instances Size 1/200 28.6G 1.174 1.891 0.01363 90 640: 33% ━━━╸──────── 1561/4702 1.1it/s 23:55<49:25libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.15 1.582 0.01327 91 640: 56% ━━━━━━╸───── 2674/4702 1.3it/s 40:45<26:43libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.144 1.475 0.01325 77 640: 72% ━━━━━━━━╸─── 3419/4702 1.3it/s 49:44<16:45libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.144 1.471 0.01325 84 640: 73% ━━━━━━━━╸─── 3451/4702 1.4it/s 50:07<14:41libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.146 1.395 0.01332 84 640: 92% ━━━━━━━━━━━─ 4370/4702 5.0it/s 1:01:16<1:07libpng warning: iCCP: known incorrect sRGB profile 1/200 28.6G 1.146 1.373 0.01335 74 640: 100% ━━━━━━━━━━━━ 4702/4702 1.3it/s 1:02:39 Class Images Instances Box(P R mAP₅₀ mAP_50-95): 22% ━━╸───────── 57/256 2.5it/s 26.7s<1:19libpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 47% ━━━━━╸────── 122/256 2.3it/s 1:10<59.4slibpng warning: iCCP: known incorrect sRGB profile Class Images Instances Box(P R mAP₅₀ mAP_50-95): 100% ━━━━━━━━━━━━ 256/256 1.9it/s 2:17 all 32677 47931 0.863 0.726 0.818 0.584
Epoch GPU_mem box_loss cls_loss l1_loss Instances
Size 2/200 17.4G 1.178 1.12 0.01394 103 640: 19% ━━────────── 933/4702 5.4it/s 2:50<11:32 `

screenshot of task manage - just to show you a good amount of shared memory is being used - while the dedicated VRAM is free [image: image.png]

On Fri, Oct 2, 2026 at 3:09 AM Paula Derrenger @.***> wrote:

Thanks for the details. The training log’s GPU_mem https://docs.ultralytics.com/reference/engine/trainer#ultralytics.engine.trainer.BaseTrainer._get_memory reports PyTorch-reserved memory, not GPU compute utilization, so it is not directly comparable with Task Manager’s utilization percentage. augment=False https://docs.ultralytics.com/modes/predict#inference-arguments controls test-time augmentation; training transforms must be configured individually using the augmentation settings https://docs.ultralytics.com/guides/yolo-data-augmentation/#example-configurations, including separately handling Albumentations if installed. Please share your exact training command, Ultralytics version, text logs, and the Task Manager counters you are comparing so we can investigate the shared-memory concern. I can’t confirm an ultra-lite package plan or hiring availability here; please keep this discussion focused on technical support.

— Reply to this email directly, view it on GitHub https://github.com/orgs/ultralytics/discussions/26446?email_source=notifications&email_token=BSIM7DVSXI24DFQIPBYBHDL5R3FKFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGA2TONBUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18705744, or unsubscribe https://github.com/notifications/unsubscribe-auth/BSIM7DTZGZDHVIT5EFATHFT5R3FKFAVCNFSNUABIKJSXA33TNF2G64TZHM2TGNJTGYYDINBVHNCGS43DOVZXG2LPNY5TCMBZGE3TMNRUUF3AE . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS https://github.com/notifications/mobile/ios/BSIM7DV47KR5EZZNTCTSFN35R3FKFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGA2TONBUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ and Android https://github.com/notifications/mobile/android/BSIM7DVOS377VIUIQUFQDRD5R3FKFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBXGA2TONBUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ. Download it today! You are receiving this because you commented.Message ID: @.*** com>
1. Paula DerrengerUltralyticsOct 5, 2026
  Thanks for sharing the script. A plausible explanation for the drop from 28.6G to 17.4G is cache cleanup between epochs: the training loop conditionally clears reserved memory before validation and at epoch end when usage exceeds 50% of device capacity. This could explain the drop, but does not establish why Windows reports shared-memory usage. (docs.ultralytics.com) Please share yolo checks output, your NVIDIA driver version, and dedicated/shared GPU-memory readings as text at matching points in both epochs so we can check your installed version and distinguish the two observations.