YOLOv8

YOLOv8 is a family of one-stage computer vision models released by Ultralytics on January 10, 2023. It extended the company's YOLO implementations with a new C2f backbone block, an anchor-free split detection head, and a unified Python package and command-line interface. The launch package, ultralytics 8.0.0, provided pretrained model series for object detection, instance segmentation, and image classification. Pose and oriented-bounding-box variants were added later.^[1][2]

YOLOv8 has no conventional first-party research paper. Ultralytics' current documentation explicitly says that no formal paper was published and supplies a software citation for version 8.0.0 instead.^[1] A March 2023 company post said that a paper was planned, but that announcement did not become an archival architecture paper.^[9] Third-party papers that modify or evaluate YOLOv8 are therefore evidence about those experiments, not origin papers for the model.

The name also requires version care. YOLOv8 identifies a model and checkpoint family, while ultralytics is a software package that continued through later 8.x releases and incorporated new tasks, exporters, defaults, and later YOLO families. Current documentation can describe present support for a YOLOv8 checkpoint, but it is not an immutable record of the January 2023 release.^[1][14]

Release and scope

Ultralytics uploaded ultralytics 8.0.0 to PyPI on January 10, 2023. Its metadata required Python 3.7 or later and PyTorch 1.7 or later. The package introduced a yolo command and a Python YOLO class that loaded a checkpoint or model configuration, then exposed training, validation, prediction, and export operations.^[2]

At release, pretrained detection and segmentation checkpoints were associated with the COCO dataset, while classification checkpoints were associated with ImageNet. Each task used five nominal scales: nano, small, medium, large, and extra-large, written as n, s, m, l, and x in checkpoint names. These were scaled configurations of a family, not five independently designed architectures.^[2]

Scroll sideways for more →

The retrospective task list on the current YOLOv8 page includes detection, segmentation, classification, pose estimation, and oriented detection.^[1] It should not be read as the launch inventory. In particular, current task pages may foreground later package defaults, so a command copied from them can select a model family released after YOLOv8.

Architecture

The launch detector is a convolutional neural network organized into a backbone, a multi-scale feature path, and a detection head. Its YAML configuration sends an image through stride-2 convolutions and C2f blocks, followed by a spatial pyramid pooling-fast, or SPPF, block. The feature path upsamples and concatenates intermediate features, then predicts from three resolutions conventionally called P3/8, P4/16, and P5/32. The suffixes describe feature strides of 8, 16, and 32 relative to the input.^[2][3]

C2f blocks and model scaling

C2f is the principal repeated block in the YOLOv8 backbone and neck. In the 8.0.0 implementation, a convolution projects the input and splits its channels into two parts. One part passes through a sequence of bottlenecks. The untouched part, the initial processed part, and the output of each bottleneck are concatenated before a final projection. This gives later layers access to several intermediate feature paths while controlling channel width.^[2]

The five detector sizes use depth and width multipliers rather than separate layer topologies. Nano uses depth 0.33 and width 0.25; small uses 0.33 and 0.50; medium uses 0.67 and 0.75; large uses 1.00 and 1.00; and extra-large uses 1.00 and 1.25.^[2] Parameters and operations therefore rise sharply across the series, while the three detection strides remain the same.

Anchor-free split head

Earlier Ultralytics YOLOv5 releases used predefined anchor-box shapes, automatic anchor fitting, and a coupled prediction output containing box coordinates, objectness, and class scores.^[4][5] YOLOv8 instead predicts around grid points without a predefined set of anchor shapes. Some internal functions in the launch source still use the variable name anchors, but the generated references are points rather than anchor boxes.^[2]

The YOLOv8 head separates box-regression and class-prediction branches. It does not emit a distinct objectness logit. For each of four box sides, the regression branch predicts a categorical distribution over 16 distance bins. A distribution focal loss, or DFL, trains those distributions, and their expected values are decoded as distances from a grid point. The launch loss combines DFL, complete intersection-over-union loss for boxes, and binary cross-entropy for classes. A task-aligned assigner selects candidate predictions during training.^[2][3]

This design is often summarized as an anchor-free, decoupled head. Anchor-free does not mean that prediction is independent of a grid or reference point, and decoupled does not mean that classification and localization use unrelated features. The branches still receive feature maps produced by the same backbone and neck.

Segmentation and classification heads

The launch segmentation model retains the detection path and adds a prototype-mask module. The 8.0.0 configuration uses 32 mask prototypes. Predictions include coefficients that combine those prototypes into instance masks associated with detected objects.^[2] This is instance-level segmentation, not a semantic map that assigns one class to every pixel regardless of object identity.

Classification checkpoints use the shared family naming but replace the detector with a classification head and use 224-pixel benchmark input in the launch table. A classification checkpoint does not produce boxes or masks. Conversely, the class scores of a detector do not turn that detector into an image-level classifier under the ImageNet protocol.

Model sizes and launch benchmarks

Ultralytics reported the following detection results for single-model, single-scale inference on COCO val2017 at 640 pixels. AP50-95 is Average Precision averaged over intersection-over-union thresholds from 0.50 through 0.95. Parameters and floating-point operations are the vendor's model counts. They do not include every image-decoding, preprocessing, non-maximum-suppression, data-transfer, or runtime cost.^[2][6]

Scroll sideways for more →

The 8.0.0 table left speed fields blank. Current YOLOv8 documentation supplies ONNX CPU and TensorRT A100 timing measured under later tooling, but those values were not part of the launch table.^[1][2] Any latency comparison needs the hardware, runtime, precision, batch size, input size, preprocessing, and post-processing to be stated.

The corresponding launch segmentation table reports both box and mask AP on COCO val2017, again at 640 pixels and under single-model, single-scale evaluation.^[2]

Scroll sideways for more →

For classification, the launch table used ImageNet validation at 224 pixels. It called the metrics top-1 and top-5 accuracy, although an accompanying footnote incorrectly referred to them as mAP. The table also printed FLOP values beneath a header that mentioned 640 pixels despite specifying 224-pixel images. The accuracy, parameter, and input-size fields are less ambiguous than that FLOP label.^[2]

Scroll sideways for more →

These tables are vendor-reported evaluations, not measurements independently reproduced for this article. A larger checkpoint generally increases the published accuracy and compute within each launch series, but it does not guarantee better application-level performance under a fixed memory, energy, throughput, or latency budget.

Training and validation tooling

The package supported starting from a pretrained checkpoint or a YAML model definition. Loading pretrained weights made transfer learning the ordinary path for a custom dataset, while a YAML configuration allowed training from an initialized architecture.^[2] A typical launch-style command combined task, mode, model, and data assignments, such as yolo task=detect mode=train model=yolov8n.pt data=coco128.yaml.

The equivalent Python workflow created YOLO("yolov8n.pt"), then called methods for training, validation, prediction, or export. The wrapper reduced differences between tasks at the user-interface level, but datasets still required task-specific annotations. Detection needs class-labeled boxes, segmentation needs instance masks or polygons, pose needs keypoints, and classification needs image-level labels.

Initial configuration defaults included 100 epochs, batch size 16, 640-pixel images for detection, stochastic gradient descent, validation enabled, and deterministic execution requested. Loss weights were 7.5 for boxes, 0.5 for classification, and 1.5 for DFL. The augmentation configuration included mosaic composition, scale and translation changes, horizontal flipping, and color-space perturbations. Mosaic was scheduled to close for the final 10 epochs.^[2]

Those values were defaults, not a complete training prescription for every dataset. Annotation quality, class balance, image scale, train-validation separation, optimizer settings, random seed, checkpoint initialization, and data augmentation all affect an experiment. Later package versions changed or added arguments, so a reproducible report should record the exact package version and resolved configuration rather than only the model name.

Validation reused task-specific metrics. For detection and segmentation, confidence filtering and non-maximum suppression can change the final prediction set. Launch prediction defaults included an IoU threshold of 0.7 for NMS and a maximum of 300 detections per image.^[2] Threshold tuning on a test set can overstate generalization, so application evaluation normally separates validation choices from a held-out test set.

Inference and deployment

YOLOv8 can process images, video frames, directories, streams, and array-like inputs through the package interface, subject to version-specific support. In the launch detector, the network produces multi-scale candidates, decodes distance distributions into boxes, scores classes, and applies non-maximum suppression. The original model was therefore not an end-to-end NMS-free detector. NMS-free modes documented for later Ultralytics families should not be attributed to the January 2023 YOLOv8 implementation.

Practical latency includes more than the neural network. Image loading, resize and padding, host-to-device transfer, kernel selection, box decoding, NMS, mask reconstruction, rendering, and output transfer can dominate on different devices. Half precision or quantization can reduce some costs but can also change numerical results. Batch throughput does not imply the same latency for a single camera frame.

Export formats at release

The 8.0.0 exporter registry named PyTorch, TorchScript, ONNX, OpenVINO, TensorRT, CoreML, TensorFlow SavedModel, GraphDef, TensorFlow Lite, Edge TPU, TensorFlow.js, and Paddle formats. The implementation had direct paths for TorchScript, ONNX, OpenVINO, TensorRT, CoreML, and Paddle. Every TensorFlow-family branch raised NotImplementedError, and the launch README listed TensorFlow export as work in progress.^[2] The registry is therefore not evidence that all displayed formats worked at release.

The initial default export format was TorchScript, and the ONNX configuration used opset 17.^[2] Later ultralytics releases added and revised exporters, so current format matrices describe current package capabilities rather than 8.0.0.

An exported file still requires target-side verification. Unsupported operations may be rewritten, image padding and normalization may differ, static shapes can replace dynamic inputs, NMS can move outside the graph, and reduced precision can change borderline scores. A useful deployment comparison checks outputs on representative data and reports runtime version, execution provider, input shape, precision, batch size, and whether timing includes preprocessing and post-processing.

Independent evaluations

COCO measures performance on its own image distribution and annotation rules. It contains varied scenes and object categories, but a COCO score does not estimate accuracy for every camera, geography, object size, or labeling policy.^[6] Two peer-reviewed 2023 studies illustrate why YOLOv8 results must stay attached to their experimental context.

A turfgrass-weed study evaluated YOLO variants on a public dataset of 4,203 images with 11,385 annotations. The authors used five-fold cross-validation, 640-pixel crops, and an Nvidia Tesla K80. Among their YOLOv8 variants, YOLOv8l had the highest cross-validation AP50-95, 0.8043. After 100 epochs, the same variant obtained AP50-95 of 0.8123 on the public test set. On three external sets called Home Lawn, Baseball Field, and Manila Grass, the reported values fell to 0.4721, 0.4312, and 0.5296.^[12] The gap is evidence of dataset shift in that weed-detection setting, not a universal performance ratio for YOLOv8.

A separate small-object study trained a YOLOv8 baseline for 200 rounds on VisDrone, VOC2007, and TinyPerson before testing a modified detector. It reported baseline AP50-95 values of 23.2, 63.0, and 6.59, respectively.^[13] The low VisDrone and TinyPerson results under that protocol support the narrower observation that small and occluded targets remained difficult in those datasets. The modified detector in the paper is not part of original YOLOv8, and its results should not be used as official YOLOv8 benchmarks.

Neither study substitutes for controlled reproduction of the launch COCO table. Their data, classes, splits, hardware, training schedules, and purposes differ. They instead show that model ranking and absolute accuracy can change with object scale, domain, and evaluation protocol.

Licensing

Licensing changed after the initial release. The 8.0.0 package metadata and source identified GPL-3.0 and also referred to an Enterprise license option.^[2] An official repository commit dated April 14, 2023 changed the license file to AGPL-3.0.^[10] Current Ultralytics materials describe an AGPL-3.0 option and an Enterprise license.^[1][11]

These facts should not be collapsed into the statement that YOLOv8 always had one license. The license files and terms attached to the exact source, package, weights, service, and distribution being used need to be checked. Whether a particular product or deployment complies is a legal and factual question beyond an architectural description.

Differences from historical YOLOv5

YOLOv8 followed Ultralytics' YOLOv5 software line but changed both the network and the interface. Historical YOLOv5 configurations used C3 blocks and an anchor-based head. Its training pipeline could analyze a dataset and adjust predefined anchor shapes through AutoAnchor. Its coupled output included a separate objectness component.^[4][5]

YOLOv8 replaced C3 with C2f in its main paths, predicted from reference points without predefined anchor-box shapes, separated regression and classification branches, removed the distinct objectness output, and used distributional distance regression with DFL.^[2][3] Both families used multi-scale feature fusion and SPPF, so the change was not a replacement of every component.

The software workflow also shifted. YOLOv5 was commonly operated through scripts in a cloned standalone repository. YOLOv8 launched inside the pip-installable ultralytics package with one YOLO class and a task-mode command syntax.^[2][9] Current Ultralytics documentation also describes models named YOLOv5u that use an anchor-free split head derived from YOLOv8.^[3] YOLOv5u should not be used as evidence that historical YOLOv5 already had the YOLOv8 head.

More broadly, YOLO naming after the early Darknet releases is fragmented across organizations and research groups. A higher number does not by itself identify a single governed architecture lineage. Comparisons are clearest when they name the repository, checkpoint, package version, dataset, and evaluation protocol.

Limitations

YOLOv8 inherits several limits of finite-resolution one-stage detection and of learned visual systems generally.

• Small, crowded, and heavily occluded instances may occupy too few feature cells or compete during assignment and NMS. The independent VisDrone and TinyPerson results provide dataset-specific examples.^[13]
• NMS and confidence thresholds can suppress overlapping objects or retain duplicate and low-quality candidates. Their effect depends on class density and calibration.
• COCO and ImageNet scores do not establish robustness to new sensors, weather, lighting, geographic regions, label definitions, or adversarial inputs.^[6][12]
• Increasing checkpoint size raises parameter count and operations substantially. Device memory, thermal limits, energy use, and end-to-end latency can make a smaller model more useful even when its benchmark AP is lower.
• Export can introduce operator substitutions, shape restrictions, preprocessing differences, or precision loss. Successful conversion does not prove numerical or task-level equivalence.
• Results depend on data splits, annotations, seeds, augmentations, optimization, dependencies, and package version. The vendor tables do not provide confidence intervals or an independent reproduction.
• There is no first-party paper that fixes a canonical experimental method beyond the versioned code, package artifacts, and living documentation.^[1][2]

The model can also reproduce dataset bias or fail silently outside its training distribution. Application testing should include representative failure cases, subgroup or condition analysis where appropriate, and monitoring of input and output drift. Detection confidence is not a calibrated probability of safety or correctness.

Versioning and later development

The continuously updated package is a common source of ambiguity. A command using an unpinned ultralytics installation in 2026 does not necessarily execute the code, dependencies, defaults, or exporter used in January 2023. PyPI still uses the 8.x package series while distributing support for YOLOv8 and later model families.^[14] Package major version and model-family number are therefore not equivalent identifiers.

Later additions can still be called YOLOv8 when they use YOLOv8 checkpoint and configuration names. Pose support was publicly announced in April 2023.^[7] The oriented-detection integration was recorded in a January 2024 commit for ultralytics 8.0.235.^[8] Current YOLOv8 documentation legitimately presents both as members of the expanded family, but neither was in the launch source.^[1][2]

For reproducibility, a YOLOv8 result should record at least the ultralytics version, checkpoint filename or model YAML, task, weight provenance, dataset release and split, image size, precision, device, backend, batch size, and post-processing settings. An exported deployment should additionally preserve its preprocessing and runtime versions. These details distinguish a specific experiment from the broad and evolving label YOLOv8.

References

1. ^Ultralytics. "YOLOv8." *Ultralytics Documentation*. docs.ultralytics.com/...yolov8
2. ^Ultralytics. "ultralytics 8.0.0." *Python Package Index*, January 10, 2023. pypi.org/...8.0.0
3. ^Ultralytics. "A Guide on YOLO26 Model Architecture." *Ultralytics Documentation*. docs.ultralytics.com/...yolo-architecture
4. ^Ultralytics. "YOLOv5 Architecture." *Ultralytics Documentation*. docs.ultralytics.com/...architecture-description
5. ^Glenn Jocher et al. "YOLOv5 by Ultralytics." *GitHub repository*. github.com/...yolov5
6. ^Tsung-Yi Lin et al. "Microsoft COCO: Common Objects in Context." *European Conference on Computer Vision*, 2014. doi.org/...978-3-319-10602-1_48
7. ^Ultralytics. "YOLOv8 Pose Models." *GitHub issue 1915*, April 2023. github.com/...1915
8. ^Ultralytics. "ultralytics 8.0.235 YOLOv8 OBB train, val, predict and export." *GitHub commit*, January 5, 2024. github.com/...91bc78da3a6ebff5c2a84eed49cb4547d50b
9. ^Ultralytics. "Introducing Ultralytics YOLOv8." March 8, 2023. ultralytics.com/...introducing-ultralytics-yolov8
10. ^Ultralytics. "Update LICENSE to AGPL-3.0." *GitHub commit*, April 14, 2023. github.com/...c0a4443b9cf805ef17b1cfdd71a98693b4d4
11. ^Ultralytics. "Ultralytics License." ultralytics.com/license
12. ^Yeyin Shi et al. "Evaluation of YOLO Object Detectors for Weed Detection in Different Turfgrass Scenarios." *Applied Sciences* 13(14), 8502, 2023. doi.org/...app13148502
13. ^Hong Xuan et al. "DC-YOLOv8: Small-Size Object Detection Algorithm Based on Camera Sensor." *Electronics* 12(10), 2323, 2023. doi.org/...electronics12102323
14. ^Ultralytics. "ultralytics." *Python Package Index*. pypi.org/...ultralytics