Your YOLOv8 training table shows validation mAP you would happily ship next to box, cls and dfl losses parked near 0.7 that refuse to fall further. Papers print losses close to zero, so the run looks wrong. It is not. The logged losses are unnormalized, gain-weighted sums whose scale changes with the YOLO version, the balance gains and the number of boxes in your images — not a 0-to-1 quality score. This guide gives you what the three numbers actually measure, the three checks that decide whether a model is done, a worked example on a 2,045-image defect set, and the cases where a high loss really does point at label errors.
Symptom: good validation mAP with box, cls and dfl losses parked near 0.7
You train a detection model — yolov8m.pt at imgsz 640 px, batch 16, 300 epochs, patience 50 — on a few thousand defect images. Validation mAP50 climbs toward 0.95 and the model looks ready to join your AI surface defect inspection line. Meanwhile box_loss, cls_loss and dfl_loss for both train and val descend for the first hundred or so epochs, then flatten near 0.7, 0.4 and 0.8, nowhere near the sub-0.1 values the papers print. The metric you deploy on says done; the loss columns say otherwise.
The tell that separates this from a real problem: train and val curves move together — both descend, both flatten in the same epochs — and validation mAP holds its level. A run in trouble shows one curve stuck near its starting value, validation losses rising while training losses keep falling, or mAP that never reaches the level you need.
What the logged loss actually measures
The three columns are terms of one weighted total, not three grades out of one:
Three properties follow from that construction. First, the losses are unnormalized: each term sums errors over the boxes and the prediction-to-ground-truth assignments in the batch, so the magnitude grows with the objects per image and the way assignments are counted — nothing rescales the sum into a 0-to-1 range. Second, the gains that balance the three terms against each other were retuned between versions, and the box term's gain moved fifteen-fold. Third, the box regression term itself was reworked: v8 scores box edges through Distribution Focal Loss, which shifts the scale again.
Read them the way you read camera exposure and gain raw values: a raw output of a defined calculation that means something only once you know the scale it was produced under. Absolute loss is not comparable across versions. Your own curves are.
Likely causes, in order of probability
- Version scale, not model quality — by far the most common. The losses are healthy; the ruler is different from the one the papers used. Test: train the identical dataset with a v5 trainer, and the box column reads below 0.001 where v8 reads 0.7 — a factor of 700 in reported magnitude (0.7 / 0.001) on the same images and labels. Fix: none. Stop comparing absolute values across versions.
- Dataset shape moved the baseline. Class count and boxes per image set where the plateau sits. A single-class defect model drives cls_loss toward zero, because there is little class confusion to pay for; a five-class set holds cls near 0.4; defect-dense images raise the box and dfl sums. Test: compare against your own earlier run of similar class count and box density, not a paper's table. Fix: recalibrate the expectation, not the model.
- Genuinely high loss — label errors or overfitting. Least likely when validation mAP is good, because mAP is computed on held-out images the training loss never saw. Test: the three checks in the next section. Fix: the label audit below, and only if a check fails.
The three checks that decide whether to worry
Trend. Both train and val curves for all three losses descend and then flatten, and the flattening lands in the same epochs for both. The plateau is convergence, not a stall: the optimizer has found the scale the gains ask for.
Metric. Validation mAP on the held-out split clears your acceptance bar. For defect/no-defect sorting, mAP50 at or above 0.90 is a workable starting bar before you tune the score threshold on the test split; set your own bar from the cost of a missed defect against a false reject.
Gap. Train and val losses sit in a stable band around each other. A val curve turning upward while train keeps descending is overfitting, and early stopping is the mechanism that catches it — patience 50 halts this configuration 50 epochs after the last improvement. The early stopping with high training loss guide covers the cousin case, where the loss itself stays high and training stalls.
Worked example: 2,045 defect images, YOLOv8m, 300 epochs, box loss 0.7
Inputs, taken from the training command and the final results table of the run being judged:
- 2,045 labeled defect images, split 0.7 / 0.2 / 0.1 into train, validation and test
- model yolov8m.pt, imgsz 640 px, batch 16, 300 epochs, patience 50, save_period 10
- final columns: box_loss 0.7, cls_loss 0.4, dfl_loss 0.8, on train and on val (losses are dimensionless)
- validation mAP50 = 0.95; acceptance bar for this example: mAP50 ≥ 0.90
Rule in words: count the splits, apply the version scale to see what the magnitudes mean, then pass the run through the three checks.
Arithmetic:
- Split counts: train = 0.7 × 2,045 = 1,431.5 → 1,431 images; validation = 0.2 × 2,045 = 409 images; test = 2,045 − 1,431 − 409 = 205 images. Check: 1,431 + 409 + 205 = 2,045.
- Version scale: 7.5 / 0.5 = 15, so the same box error enters the v8 total fifteen times heavier than in v5; identical data retrained on v5 logs box below 0.001, a reported ratio of at least 0.7 / 0.001 = 700 that carries no information about detection quality.
- Checks: mAP50 0.95 ≥ 0.90 bar → pass; curves descend then plateau with val tracking train → pass; no val rise in the tail → no overfitting flag.
Result: the model is converged, and the loss magnitudes are the v8 scale, not a defect. Decision: accept, and move to the 205-image test split for the release report. Retrain or audit labels only on a failed check — validation mAP50 below 0.90, or val losses rising over the final 50 or more epochs. With five classes, cls_loss 0.4 sits where a five-class set sits; a single-class model would sit near zero.
When a check fails: find the images behind the loss
If validation mAP misses your bar or val losses climb in the final third of the run, the aggregate losses have done their job — now work at image level. The training log sums over batches, so it cannot hand you a per-image value. Run the trained weights over the validation folder instead, and rank images by disagreement between predictions and labels: boxes the model misses entirely, boxes shifted along one edge, defects boxed twice.
Disagreements cluster where labels are wrong. Missing annotations punish the model for predicting real defects; inconsistent class names show up as cls_loss that will not settle; duplicate boxes distort the box assignment. Labeling rules such as those for background images in object detection training remove a whole class of these errors — a background image must carry no labels at all, so an image holding an unlabeled defect does not belong in that bucket. On a single-class set, a cls_loss that never approaches zero while box and dfl fall points at class-column label errors, not detection quality.
Prevention: rules for the next run
Compare like with like: losses against your own earlier curves from the same version, image size and gains; models against validation and test mAP. Record the YOLO version and the loss gains beside every saved run, because the same printed numbers mean different things under different versions. Judge a release on the test split, never on training loss.
Budget epochs honestly. With patience 50 and save_period 10, the 300-epoch run checkpoints every 10 epochs and stops itself 50 epochs after the last improvement, so a flat tail wastes wall-clock time without producing a worse model. And if the run dies before any of this matters — a segmentation fault mid-training rather than a strange number — the YOLO training segmentation fault guide walks the crash-side fixes.
Decision and next step
The decision: good validation mAP with losses parked near 0.7 is a converged model, not a broken one — read the trend, the mAP and the gap, and audit labels only when one of the three fails. When the model passes, hardware sets deployment speed. The smart cameras category runs inspection on the device with no PC; the camera finder filters by resolution, shutter and mount; multi-camera cells put shared inference on a vision controller. The systems topic page collects the rest of the training and integration guides, the configurator steps through camera, lens and light for a station, and contact us with your dataset size and cycle time if you want the hardware sized for you.
Questions
What loss values count as normal for a trained YOLOv8 detect model?
No single number is normal across versions: the logged losses are unnormalized, gain-weighted sums. A converged v8 detect run can legitimately log box near 0.7, cls near 0.4 and dfl near 0.8 with mAP50 around 0.95. A healthy signature is box falling under about 0.4, cls near zero and a dfl curve that flattens. A single-class model pushes cls toward zero on its own. Compare only with your own earlier runs on the same version and gains.
Why does the same dataset produce much smaller losses in YOLOv5?
Two changes stack. The box gain moved from 0.5 in v5 to 7.5 in v8, so the same box error weighs fifteen times more before any equation change, and the regression term itself was reworked between versions. An identical dataset retrained on v5 has logged box losses below 0.001 where v8 reads 0.7 — a reported difference of at least 700× on the same images and labels. The scale belongs to the version, not the model.
Can I print a loss value for each image to find outliers?
The training loop logs sums over each batch, so no per-image loss comes out of a training run. You do not need it: run the trained weights over the validation folder and rank images by disagreement between predictions and labels — missed boxes, boxes shifted along one edge, duplicates. The worst-ranked images are where noisy labels live, and reviewing the top of that list finds more label errors than any per-image loss would.
Should I lower the loss gains so the numbers look smaller?
No. The gains set how strongly box, class and dfl errors pull on training relative to each other, and the defaults are tuned so the three terms converge together. Scale them down and you have changed the effective learning rate and the balance of a configuration that was already tuned; the smaller printed numbers tell you nothing new and can cost mAP. If the values bother you, rescale them in your own plots and leave the training configuration alone.