YOLO11 Explained in Depth — What Did C3k2 and C2PSA Change from YOLOv8?

The YOLO family has remained one of the most widely used approaches to practical object detection, and development has continued since YOLOv8 in 2023. Released by Ultralytics on September 10, 2024, YOLO11 keeps the same “backbone → neck → head” outline as YOLOv8 while redesigning the blocks inside it. This article verifies what YOLO11 changed and what it kept, using primary information from the official documentation and model-definition YAML files, with equations and diagrams.

This article is based on the Ultralytics official documentation (docs.ultralytics.com), configuration files in the official GitHub repository, and the preprint “YOLOv11 Demystified” (arXiv:2604.03349).

0. What you will learn

• What YOLO11 specifically changed from YOLOv8, including C3k2 and C2PSA
• How the anchor-free detection head predicts coordinates, including DFL
• The loss functions and augmentation methods used for training
• How accuracy, parameter count, and speed change across the five sizes n/s/m/l/x, using official measurements
• When to choose YOLO11 and when to consider another option

1. What is YOLO11?

YOLO11 is a generation of real-time object-detection models developed and released by Ultralytics. It keeps the three-stage “backbone, neck, and head” design of YOLOv8, replaces its feature-extraction blocks with the newly designed C3k2, and adds the C2PSA spatial-attention block at the end of the backbone. The same general architecture covers detection, segmentation, pose estimation, classification, oriented bounding boxes (OBB), and tracking within one framework.

2. Why was this redesign needed?

At the time, YOLOv8 was widely used as a one-stage detector with a strong accuracy–speed balance, but two areas still had room for improvement. The first was parameter efficiency. If the same accuracy can be achieved with fewer parameters and FLOPs, deployment on edge devices and battery-powered robots becomes more practical. The second was the lack of an explicit mechanism for learning where to focus in a feature map. YOLOv8’s backbone builds features with convolutions, but has no dedicated mechanism for separating important regions from the background. C3k2 and C2PSA address these two issues respectively.

3. What is the input?

As with many other YOLO detectors, YOLO11 takes a resized and padded RGB image of a fixed size (640 × 640 pixels by default). During both training and inference, the input is handled as a batched [B, 3, H, W] tensor. No special preprocessing such as proprietary normalization or patch splitting is required: images after standard augmentations such as Mosaic are passed directly to the backbone.

4. What does it predict?

For each object in the image, the output contains a class, bounding-box coordinates, and a confidence score. YOLO11 uses a decoupled head that separates the classification and box-regression branches. It is also anchor-free, so it directly regresses coordinates without predefined anchor boxes. The idea of predicting the distance from each grid location to the object boundary connects YOLO11 to the FCOS family of anchor-free detectors. Removing predefined boxes for several aspect ratios and scales reduces hyperparameter tuning and can improve generalization to objects with extreme aspect ratios.

5. Basic architecture

Like YOLOv8, YOLO11 follows the three-stage “backbone → neck → head” structure. The change is in the contents of those stages.

Figure 1 — YOLO11’s backbone, neck, and head. The blue emphasized boxes are the parts changed from YOLOv8. C3k2 replaces the basic block in both the backbone and neck, while C2PSA is added at the end of the backbone, immediately after SPPF.

The backbone outputs feature maps at three resolutions, P3, P4, and P5. The neck (PAN-FPN: Path Aggregation Network + Feature Pyramid Network) fuses high- and low-resolution features in both directions, allowing the same network to detect small and large objects. This multi-scale fusion skeleton is unchanged from YOLOv8. What changed is that C2f was replaced by C3k2 as the basic block, and C2PSA was inserted at the backbone output.

6. Technical details of the components

C3k2 — a generalization of C2f

YOLOv8 used the C2f block, which has a CSP (Cross Stage Partial) structure, as its basic unit. C2f splits the input channels into two paths, sends one through several Bottleneck blocks, leaves the other as a shortcut, then concatenates both outputs and the intermediate outputs from each Bottleneck before merging them with a 1 × 1 convolution.

YOLO11 keeps the idea of repeating internal blocks, but makes the internal block type configurable. In the official model definition (YAML), each block inside C3k2 can be one of the following, depending on constructor flags:

1. A normal Bottleneck (used by the small n model)
2. A C3k block (a C3 structure with configurable kernel size, used with c3k=True in the medium and larger m/l/x models)
3. A Bottleneck + PSABlock pair (used inside C2PSA at the end of the backbone)

In other words, C3k2 is a generalized block: it keeps the C2f idea while allowing its internal Bottlenecks to range from lightweight blocks to attention-equipped blocks according to model size and placement. An implementation detail is that one YAML configuration covers all five sizes, n/s/m/l/x, by switching these internal components.

C2PSA — adding spatial attention to the backbone

C2PSA (Cross Stage Partial with Spatial Attention) is a new YOLO11 block inserted immediately after SPPF (Spatial Pyramid Pooling - Fast, a module that expands the receptive field with multiple pooling sizes). C2PSA also follows a CSP structure: one path goes through several PSABlocks. Each PSABlock combines multi-head self-attention (MHSA) and a two-layer feed-forward network (FFN), connected with residual paths.

Here x is the input feature, \text{MHSA} is multi-head self-attention, and \text{FFN} is the two-layer feed-forward network. Compared with YOLOv8’s convolution-only backbone, C2PSA uses self-attention to learn relationships between distant positions in a feature map directly. It complements convolution’s local receptive field and helps concentrate weight on important regions of the image.

Anchor-free detection head and DFL

YOLO11’s detection head separates classification and box regression into decoupled branches. It does not use predefined anchor boxes; instead, each grid point on the feature map directly predicts the distance to the object boundary. For each of the four directions, the box-regression branch outputs a probability distribution over \text{reg\_max}=16 discrete bins and uses its expected value as the continuous distance. This is the idea behind Distribution Focal Loss (DFL), inherited from YOLOv8 and proposed by Li et al. in “Generalized Focal Loss” (NeurIPS 2020).

Rather than directly regressing a single real value for the distance to a boundary, the model learns a discrete distribution over likely bins. This makes training more stable while allowing the distribution to express uncertainty for objects with ambiguous or occluded contours. YOLO11 also changes the classification branch to use depthwise-separable convolution, reducing parameter count and computation compared with ordinary convolution.

Loss functions and training recipe

YOLO11’s training loss is a weighted sum of CIoU (Complete IoU) loss for box regression, DFL loss for the coordinate distribution, and BCE (binary cross-entropy) loss for classification.

CIoU loss evaluates not only IoU (overlap ratio), but also the distance between box centers and how closely their aspect ratios match.

\rho(b, b^{gt}) is the Euclidean distance between the predicted and ground-truth box centers, c is the diagonal length of the smallest rectangle enclosing both boxes, v represents the aspect-ratio mismatch, and \alpha is a coefficient that gives v more weight as IoU increases. Optimizing IoU alone provides almost no gradient when boxes do not overlap; the center-distance and aspect-ratio terms mitigate this problem.

Training uses augmentations including Mosaic, which joins several images; MixUp, which blends two images; Copy-Paste, which pastes an object region into another image; RandAugment, which automatically selects random transformations; and Erasing, which removes a random rectangular region. These details follow the description in “YOLOv11 Demystified” (arXiv:2604.03349).

7. Comparing model variants

YOLO11 is available in five sizes with different parameter counts and compute requirements: n (nano), s (small), m (medium), l (large), and x (extra-large). The following are benchmark values reported in the Ultralytics official documentation on COCO val2017 with a 640 px input.

Source: Ultralytics YOLO11 official documentation. CPU ONNX inference uses ONNX Runtime; T4 TensorRT inference is FP16 on an NVIDIA T4 GPU.

Two practical points stand out. First, the parameter count grows by about 22× from n to x, while mAP50-95 rises only about 15 points, from 39.5 to 54.7: accuracy and model size are not linearly related. Second, consider the gap between m and l. Parameters rise only from 20.1M to 25.3M, while mAP increases from 51.5 to 53.4 and GPU inference time from 4.7 ms to 6.2 ms. The return on moving from m to l is therefore somewhat smaller than at the n → s → m steps. These numbers support n/s for edge deployment and l/x for fixed systems where accuracy has priority.

Quantitative comparison with YOLOv8

Putting the YOLOv8 values reported in the same Ultralytics documentation beside YOLO11 makes the generational change more concrete.

Source: YOLOv8 official documentation and YOLO11 official documentation (COCO val2017, 640 px, CPU ONNX inference for both).

For the l size, parameter count falls from 43.7M to 25.3M, almost by half, while mAP improves slightly. This is where the parameter-efficiency effect of C3k2 and C2PSA is most visible. For x, parameters and FLOPs fall substantially, but CPU inference time improves only slightly, suggesting that the self-attention computation in C2PSA can become a bottleneck for large models.

In one sentence, YOLO11 shifts toward achieving at least comparable mAP with fewer parameters and FLOPs than YOLOv8. That does not mean it always beats YOLOv8: depending on the task and dataset, the older generation can still report higher absolute accuracy. The object detection trends article discusses this point as well.

Extending YOLO11 beyond detection

YOLO11 is not limited to object detection. By replacing only the head while keeping the same backbone and neck, the framework covers instance segmentation (YOLO11-seg), pose estimation (YOLO11-pose, which regresses keypoint coordinates), classification (YOLO11-cls), oriented bounding-box detection (YOLO11-obb, which also regresses the orientation of tilted objects), and tracking across multiple frames. Because C3k2 and C2PSA improve the backbone, their benefits are shared across these tasks. This also shows that YOLO11 is designed as a common visual-recognition foundation rather than only a detection model.

8. What it struggles with

YOLO11 retains weaknesses common to the YOLO family. Small and distant objects remain difficult. Since the backbone gradually reduces resolution, an object only a few pixels across can lose nearly all of its distinctive features by the time it reaches deeper layers. C2PSA partially alleviates this, but does not solve it fundamentally.

Dense scenes with many similar objects are also challenging. DFL and CIoU improve boundary regression, but neighboring objects whose boundaries overlap, such as a crowd or densely packed fruit in an orchard, can still produce false detections and misses.

Sensitivity to domain shift is a general issue for CNN-based detectors. Accuracy can fall sharply under lighting, weather, or camera angles that differ substantially from the training data. C2PSA does not provide as broad a receptive field as the Transformer-based DETR family, so YOLO11 may be less robust in this respect.

YOLO11 is also released under the AGPL-3.0 license. If a commercial deployment requires keeping source code private, the Ultralytics Enterprise License is required. This is not a technical weakness, but it is a practical constraint that is easy to overlook.

9. How to choose it in practice

For edge devices and battery-powered robots, inference speed and parameter count are usually constraints, making YOLO11n/s the first candidates. The n model’s roughly 56 ms CPU inference can make operation on Raspberry Pi-class embedded hardware realistic, depending on the rest of the system.

For aerial inspection from drones and other moving platforms, small-object detection is central. Instead of simply choosing a larger YOLO11 model, increase input resolution or use tiled inference. Some reports give deformable-attention DETR variants an advantage in this area, so RT-DETR and other families are reasonable comparisons when accuracy is the priority.

For inspection with fixed warehouse or factory cameras, YOLO11l/x are options when GPU resources are available and accuracy is the priority. Even here, Transformer-based detectors such as RF-DETR have reported more than 60 mAP on COCO, so YOLO is no longer the only choice. See the object detection trends article for details.

For research and prototyping, the maturity of Ultralytics’ Python package is a practical reason to choose YOLO11: training, inference, and export can be expressed in a few lines. Where its licensing constraints are acceptable, the speed of getting a working baseline remains a major strength.

10. Three-line recap

• YOLO11 keeps YOLOv8’s backbone–neck–head outline, replaces its basic blocks with C3k2, and adds spatial attention through C2PSA.
• Its anchor-free head predicts boundary distances as the expected value of DFL distributions, while CIoU jointly optimizes overlap, center distance, and aspect ratio.
• Parameter efficiency improves from n to x, but small objects, dense scenes, and domain shift remain common challenges for YOLO-family detectors.

For a more fundamental introduction to object detection and semantic segmentation, see Object Detection and Semantic Segmentation: An Introduction. For current trends across the YOLO family, including NMS-free approaches and competition from DETR models, see the object detection trends article.

References

• Ultralytics YOLO11 official documentation
• Ultralytics: YOLO architecture guide
• Ultralytics: Benefits of YOLO11 as an anchor-free detector
• YOLO11 official model configuration (GitHub)
• YOLOv11 Demystified: A Practical Guide to High-Performance Object Detection (arXiv:2604.03349)
• Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection (NeurIPS 2020, arXiv:2006.04388)
• Ultralytics licensing