YOLO11_Opt: An Ultra-Lightweight Improved YOLO11n Algorithm for Low-Cost Embedded Devices for Accurate Plant Disease Detection—A Case Study on Bell Pepper

Abstract

The early and accurate detection of plant diseases is essential for crop management and agricultural loss control, especially under resource limitations. We propose an optimized YOLO11n architecture, designated as YOLO11_Opt, targeting real-time inference on low-cost embedded systems. The model is computationally efficient through the selective narrowing of its width and depth, while performing competitively in two-class object recognition tasks. Pepper leaves were chosen as the materials for study. Three methods of quantization (FP32, FP16, and INT8) were investigated. After running the experiments, the results showed that YOLO11_Opt greatly reduces the computational complexity: the complexity decreased from 6.3 GFLOPS and 2.58 million parameters in the typical YOLO11n model to a very small 0.5 GFLOPS and 0.33 million parameters, while maintaining competitive detection capabilities. The improved FP32 model has a mAP (0.5:0.95) of 0.913 and a precision of 0.991, while the old version has 0.961 mAP and 0.996 precision. Lastly, implementations on embedded hardware prove that the method is feasible: the detection accuracy of the system in live classification is around 92% with Raspberry Pi 4 and 94% with NVIDIA Jetson Nano, with inference times of as little as 1.9 ms on NVIDIA Jetson Nano and 8.3 ms on Raspberry Pi 4. Thus, YOLO11_Opt demonstrates significant potential as a reliable, high-performance, low-cost solution to identifying plant diseases on devices in precision agriculture.

1. Introduction

Over the last decade, artificial intelligence (AI) and deep learning have transformed pest diagnosis [1]. Disease symptoms such as leaf spots, necrosis, and discoloration are identified by object detection models and convolutional neural networks (CNNs) based on digital images [2,3]. Among these, the You Only Look Once (YOLO) family of models has progressed, representing a way to achieve faster and more accurate real-time detection. Currently, YOLO11 offers improvements by demonstrating enhanced inference, small model sizes, and high fidelity on embedded platforms. Optimized backbone models and more flexible feature fusion techniques can also realize superior performance [4,5]. These performance characteristics render YOLO11 suitable for precision agriculture tasks such as automatic disease sensing. However, implementing a detection model in the agricultural context requires embedded mechanisms capable of real-time inference, in accordance with stringent requirements for power use, bandwidth, and cost [6,7]. The deployment scale of these models is increasing, mainly through optimization techniques (compression, quantization, pruning) [2,8] specifically targeted towards hardware platforms ranging from Raspberry Pi to Jetson Nano and high-performance microcontrollers. Edge computing thus plays a decisive role in improving plant disease detection in this case. Instead of sending an image to a remote server, a connected device runs the machine learning model directly on-site. This reduces latency, network dependence, and energy consumption and protects agricultural data [9]. Implementing models in the field also allows swift decision-making, which is essential to prevent the spread of diseases. In recent studies, YOLO11 combined with edge computing was observed to achieve detection rates above 90% with latencies of 150 ms or less on Jetson Nano and Raspberry Pi 4 [10,11]. Furthermore, introducing edge processing in agricultural IoT networks helps to achieve an autonomous service model capable of collecting, processing, and transmitting relevant data. This hybrid model enables the creation of smart agriculture ecosystems—for example, in the field of phytosanitary monitoring—to which every edge point contributes, while transmitting only key information to the cloud for large-scale predictive analysis. Edge computing is not merely a technological solution but also a key example of the concept of decentralized intelligence, which is a significant prerequisite for sustainable and accessible digital farming and agriculture. However, implementing YOLO11 in embedded platforms poses many technical challenges. The optimal approach requires a trade-off between model accuracy and computational cost. A decrease in performance for diseases that display visually similar signs occurs when the network size is reduced or when quantization is aggressively applied. Moreover, augmentation and regularization-based approaches for the visual aspects of the agricultural environment (e.g., lighting, type of background, classes of pathogens) represented in the model are required to maximize its performance [2,6]. The recently released YOLO11 offers a new path towards object detection with high accuracy and superior feature extraction. While the earlier YOLOv5 and YOLOv8 models are widely used for plant disease detection, the application of YOLO11 in leaf disease detection remains nascent. Recent breakthroughs in this line of research show that although state-of-the-art YOLO architectures with near-perfect classification algorithms can work well with sophisticated GPUs, a major shortcoming remains, namely, standard models are prohibitively expensive for real-time deployment on the low-cost, resource-limited edge devices commonly used in smart agriculture applications. Therefore, the gap between YOLO11’s robust detection accuracy and the stringent memory and operational constraints of edge AI applications is a crucial unsolved problem in current precision agricultural studies. The target deployment constraints are specifically set in this work: inference latency below 100 ms, memory usage <1 GB RAM, and power usage <10 W; the main contributions are reported as follows:

• A hardware-aware scaled YOLO11n architecture that is optimized for edge AI deployment on limited resource systems.
• An analysis with a systematic depth–width ablation study with embedded restriction for architectural purposes.
• Research on Raspberry Pi 4 and Jetson Nano.
• The effects of INT8 quantization on accuracy and latency.
• Comparison of full pipeline inference performance with regards to latency, CPU consumption, and power.

To test the efficacy of the proposed edge AI framework, bell pepper (Capsicum annuum) and its associated bacterial spot pathology are used as a primary benchmark. This case study provides a perfect example of the rigorous model for evaluating YOLO11_Opt architecture’s ability to accurately sense complex, small-scale morphological lesions in a restricted computational bandwidth of extreme edge devices. The goal is to create and optimize an ultra-lightweight YOLO11 called YOLO11_Opt and ensure its efficiency on low-cost, low-energy embedded platforms. This would then provide small and medium-sized farms with a rapid, smart, and economical tool for plant health diagnostics and move the field of precision agriculture towards truly state-of-the-art decentralized agriculture.

2. Related Works

Over the past few years, numerous studies have examined the practical applications of the YOLO algorithm for identifying plant diseases. Consequently, several iterations of the YOLO model have been developed, incorporating various improvement methods to strike an optimal balance between detection accuracy and processing speed.

• Optimization of Earlier YOLO Versions (v5, v7, v8)

Early discussions looked to improve the performance of YOLOv5 and YOLOv8 to help balance speed and accuracy. A small YOLOv5 has been suggested using pruning and architectural simplification [12], but hardware verification was relatively scarce. ALAD-YOLO [13] and MGA-YOLO [14] similarly made structural changes, introducing “ghost modules” and attention mechanisms for apple leaf identification. Although these models have some promise, their validations were mainly limited to cloud-based systems [13] or were not adequately comparable with heterogeneous embedded hardware [14]. Using methodological analysis, for example, Nadozie et al. [15] demonstrated the significance of preprocessing and accelerator conversion (ONNX/TensorRT) for NVIDIA Jetson platforms. Backbone-level optimizations have also been extensively investigated; Xie et al. [16] used a MobileNet backbone and a C3-BiPC neck for eggplant lesions, while Ye et al. [17] introduced TG-YOLOv5 for rice diseases in heterogeneous field conditions. But these works were either validated on high-end devices such as the Jetson Orin [16] or only partially tested on entry-level embedded CPUs [17]. Though comparable works such as [18] have successfully implemented YOLOv8 on Raspberry Pi 4, a review of micro-scale scaling at ultra-light weight under severe CPU limitations lacks systematic investigation.

• Multi-Class and Edge-Oriented Performance

Beyond simple binary classification, complex models such as YOLO-JD [19] have achieved a high mAP (96.63%) for 10-class jute disease detection, but without reporting embedded latency or power consumption. Conversely, some studies have prioritized the user experience on low-cost hardware; SSE-YOLOv5s [20] was deployed on Raspberry Pi to evaluate peanut pod quality, focusing on video smoothness. To enhance performance on mid-range edge devices, Xu and Wang [21] optimized YOLOv8n with TensorRT for aphid detection on Jetson Xavier NX. While effective, the Xavier NX platform is relatively expensive and power-intensive compared with the entry-level devices required for small-scale decentralized farming.

• Recent Developments in YOLO11

With the emergence of YOLO11, several specialized studies have recently been published. YOLO11-AIU [22] introduced revised attention modules (C3k2_iAFF) and multi-branch downsampling for tomato blight, achieving 15.67 FPS on the Luban Cat5 platform. Simultaneously, TriPerceptNet and EDGE-MSE-YOLO11 [23] introduced lightweight spatial fusion mechanisms targeting low-power IoT sensors and microcontrollers.

YOLO11-RD [24] was deployed on Jetson Nano and Raspberry Pi 4B with TensorRT optimization, achieving 23.5 FPS. While other studies have applied YOLO11 to cotton [25] and tomato [26] diagnostics, they have primarily focused on software-level validation using datasets such as PlantVillage without comprehensive embedded benchmarking. Finally, RLDD-YOLO11n [27] embodied a “nano” approach for rice disease detection with optimized parameters, but the authors noted that more extensive embedded testing is still required to confirm its efficiency in real-world IoT scenarios.

• Summary of Existing Approaches

Table 1. Comparative analysis of the proposed YOLO11_Opt architecture and existing state-of-the-art models for agricultural disease detection.

Study	Model	Dataset	mAP@0.5:0.95 (%)	Platform	FPS	Hardware Validation
[12]	YOLOv5 (Light)	Leaf disease	~92.0	Not specified	~6	Limited
[13]	ALAD-YOLO	Apple leaves	90.2	Cloud platform	N/A	No edge
[14]	MGA-YOLO	Apple leaves	>90	Mobile device	Real-time	Partial
[16]	MobileNet-YOLO	Eggplant	91.5	Jetson Orin	35	High-end only
[18]	YOLOv8	Field + PlantDoc	94.0	Raspberry Pi 4	~15	Yes
[19]	YOLO-JD	Jute	96.6	Not specified	N/A	No latency
[21]	YOLOv8n	Cotton	92.4	Jetson Xavier NX	42	High power
[22]	YOLO11-AIU	Tomato	94.1	Luban Cat5	15.67	Limited
[24]	YOLO11-RD	Rice disease	93.0	Jetson Nano/RPi 4	23.5	Yes
[27]	RLDD-YOLO11n	Rice disease	91.8	IoT sensor	N/A	Software only
This work	YOLO11_Opt	Bell pepper	99.5	RPi 4/Jetson Nano	100	Full (CPU + GPU)

synthesizes the performance and hardware validation of the most relevant state-of-the-art models compared with our proposed work.

• Research Gap

This review highlighted a persistent gap in the literature: while YOLO-based models achieve high accuracy, comprehensive hardware-aware optimization under strict low-cost CPU constraints remains limited. Many studies rely on high-performance GPUs (Xavier/Orin) or lack detailed reporting of latency and resource utilization on entry-level devices. Our work addresses this gap by proposing YOLO11_Opt, a hardware-aware scaled architecture validated on heterogeneous platforms. Our approach achieves high-speed inference on CPU-based hardware without specialized accelerators, providing a reproducible “blueprint” for decentralized agricultural AI.

3. Model Architectures

3.1. YOLO11 Architecture

The YOLO11 model is depicted in Figure 1 and is the latest iteration of the You Only Look Once family that integrates certain notable architectural improvements to maximize speed, accuracy, and efficiency. Like its predecessors, YOLO11 has a backbone, neck, and head structure. Nonetheless, it has been redesigned to meet the stringent deployment demands of embedded devices and high-performance servers [28,29]. In the backbone, YOLO11 utilizes the C3k2 (Cross-Stage Partial with Kernel 2) module, which is an upgraded version of the C2f and C3 modules found in YOLOv8 and YOLOv10. This module helps in improving gradient flow and feature reuse while keeping the parameter count low [28]. For increased multi-scale feature extraction, the Spatial Pyramid Pooling-Fast (SPPF) block is retained. In addition, the C2PSA (Convolution with Parallel Spatial Attention) block is joined to it to consolidate multi-head parallel spatial attention to better detect small objects and partially occluded regions of the network [29,30]. The neck of YOLO11 incorporates a multi-scale feature aggregation algorithm based on the Path Aggregation Network (PAN). It employs a series of C3k2 blocks vertically connected to the backbone to support multi-dimensional stepwise information integration. A process for upsampling the backbone features [28] presents the optimal trading-off between speed and detection complexity [31]. Lastly, the head is an anchorless design inherited from modern YOLO versions. It further applies DWConv in its final layers to mitigate the computational demand without detrimental effects on the localization performance [29,30]. As a result, YOLO11 is especially adapted to edge platforms (e.g., Jetson Nano, Raspberry Pi, embedded FPGAs), achieving the same performance effects as in earlier systems [32]. Different versions of YOLO11 (n, s, m, l, x) are available for different scenarios comprising various network size, complexity, and generalization capabilities [28], where a specific deployment is required in terms of latency and resources. These modifications enhance YOLO11’s mAP compared with YOLOv10 and support a faster inference, making it a better fit for real-time computer vision, precision agriculture, and intelligent robotics [29,31,33].

The standard model architecture is designed for high-capacity feature extraction using a multi-branch Path Aggregation Network (PAN) as follows:

• Backbone (Layers 0–10): Processes an input of 640 × 640 × 3. It utilizes a depth factor of 0.50 and a width factor of 0.25. The spatial resolution is reduced through five stages: 320 × 320 (P1), 160 × 160 (P2), 80 × 80 (P3), 40 × 40 (P4), and 20 × 20 (P5).
• C3k2 blocks: Employs heavy repetitions of CSP-based kernels to maintain gradient flow.
• SPPF and C2PSA: These modules at the base provide spatial pyramid pooling and attention mechanisms to capture the global context before entering the neck.
• Neck (multi-branch): Uses a complex series of Upsample and Concat operations to fuse features across scales. This multi-path approach ensures high accuracy but increases memory synchronization overhead on embedded CPUs.
• Head: Three Detect modules process the fused features to predict bounding boxes and classes.

3.2. Proposed Architecture: YOLO11_Opt

In this article, we present a highly optimized architectural variant of YOLO11, called YOLO11_Opt, which was custom-designed for low-resource systems such as Raspberry Pi, Jetson Nano, and high-performance microcontrollers to achieve speed in detection, inference, energy-saving properties, and a low memory footprint. Because it remains anchorless like most proposed YOLO systems, a range of material structural modifications were made to the architecture, but only on a small scale, with insignificant performance penalties [28].

• Aggressive Model Scaling

As seen in the input scenario (see Figure 2), a custom scaling technique was employed for a substantial model size trade-off. The depth and width of the network were defined at 0.20, which is far lower than the ordinary YOLO11n. The optimal scale factors of depth = 0.20 and width = 0.20 are aggressive, selected carefully to ensure a tight trade-off between detection performance and the extreme hardware constraints of the embedded platforms. In the YOLO architecture, model complexity (parameter count and memory size) scales roughly equal to the size of {depth} and {width} are represented by this equation {depth × width²}. When both parameters were fixed at 0.20, our YOLO11_Opt was further reduced to the same size (just 0.33 million parameters, 1.3 MB). Expanding these scaling factors to 0.25 or 0.30 would produce a large model footprint. For example, a scaling factor of 0.25 would lead to a model size of almost 2 MB (around 0.423 million parameters), whereas a factor of 0.30 would raise it to 2.5 MB. Such increases would require much more constrained memory and greater computational resources of the embedded platforms in question, while only generating an insignificant increase in the mAP.

To quantitatively justify this selection, a sensitivity analysis was performed.

Table 2. Impact of depth and width scaling on model size.

Scaling Factor (d, w)	mAP@0.5:0.95	Precision	GFLOPS	Params (M)	Model Size (MB)
0.30	0.905	0.994	0.8	0.492	2.5
0.25	0.900	0.990	0.6	0.423	2
0.20	0.913	0.994	0.5	0.328	1.3
0.15	0.892	0.980	0.4	0.315	1

shows that the 0.20 scale offers the best precision with an optimal model size, Params, and GFLOPS, confirming 0.20 as the “sweet spot” for edge deployment.

Furthermore, to effectively implement this “depth = 0.20” architecture, specific structural modifications were applied: the number of C3k2 bottleneck blocks within the backbone stages was systematically reduced, and redundant expansion layers in the original network were bypassed to form the ultra-minimalist single-stream neck. This aggressive reduction is essentially responsible for the model’s very low parameter count and floating-point operations (FLOPs), hence being ultra-lightweight.

• Optimized Backbone

In the backbone, convolutional blocks and C3k2 (Cross-Stage Partial Kernel 2) are utilized to extract features efficiently, saving memory. By embedding the SPPF (Spatial Pyramid Pooling-Fast) module, multi-scale contextualization is improved drastically. In addition, this method is essentially designed to remove redundancy from the entire architecture [29]. This architectural choice provides the best combination of network flexibility and computational load; hence, it is well-suited to ARM-based processors and Internet of Things (IoT) applications.

• Streamlined Neck and Head

Instead of the typical architectures with elaborate feature pyramids, the neck of YOLO11_Opt employs an ultra-minimalist single-stream mode. As illustrated in Figure 2 (Layers 8, 9, and 10), features are processed sequentially to generate the three required levels: P3 (high-resolution features for detecting small objects), P4 (intermediate-level features for medium objects), and P5 (low-resolution features to capture the global context for large objects). These features are produced through compact convolutions and fed directly into the head. The Output Module (Detect) also alleviates some of this computational load, which is facilitated using the anchorless mode. This simplification is in accordance with recent works proposing more modular and deployment-friendly implementation of YOLO11 in embedded scenarios [30,31,32,33]. Figure 2 presents the whole model architecture of YOLO11_Opt. The overall detailed structural organization of all layers in the highly optimized architectural variant of YOLO11 called YOLO11_Opt is given in

Table 3. Detailed layer-wise configuration of the proposed YOLO11_Opt architecture.

Layer	Stage	Type	Kernel	Stride	Channels (I/O)	Output Dimensions
0	Backbone	Conv(stem)	3 × 3	2	3/16	320 × 320
1	Backbone	Conv	3 × 3	2	16/32	160 × 160
2	Backbone	C3k2 (×1)	_	1	32/32	160 × 160
3	Backbone	Conv	3 × 3	2	32/64	80 × 80
4	Backbone	C3k2 (×2)	_	1	64/64	80 × 80
5	Backbone	Conv	3 × 3	2	64/128	40 × 40
6	Backbone	C3k2 (×1)	_	1	128/128	40 × 40
7	Backbone	SPPF	5 × 5	1	128/128	20 × 20
8	Neck	Conv (P3)	1 × 1	1	128/128	80 × 80
9	Neck	Conv (P4)	3 × 3	2	128/256	40 × 40
10	Neck	Conv (P5)	3 × 3	1	256/512	20 × 20
11	Head	Detect	_	_	128/256/512	Detect classes

, including kernel sizes, strides, and output sizes.

The specific structural modifications and scaling constants that make the proposed YOLO11_Opt architecture fully reproducible are detailed in

Table 4. Architectural “blueprint” and scaling specification: YOLO11n vs. YOLO11_Opt.

Component	Parameter	YOLO11n (Standard)	YOLO11_Opt (Proposed)	Technical Justification
Model Scaling	Depth Factor (d)	0.50	0.20	Reduces sequential computation depth
	Width Factor (w)	0.25	0.20	Reduces filter redundancy and RAM usage
	Max Channels	1024	1024	Eliminates memory bandwidth bottlenecks
Backbone	C3k2 Repeats	[1, 2, 5, 2]	[1, 1, 2, 1]	Strategic pruning of feature extractors
	Stage Filters	[64, 128, 256, 512, 1204]	[16, 32, 64, 128, 256]	Optimized for small-scale lesion detection
Neck and Head	Feature Fusion	Multi-scale PAN	Streamlined PAN	Reduces branching and MAC operations
Complexity	Parameters	2.61 M	0.33 M	87.3% reduction
	GFLOPS	6.5	0.5	92.3% reduction

. This “blueprint” outlines the specific parameters used to facilitate the switchover from the standard YOLO11n to our optimized version.

Table 4 shows that the architectural simplification adheres to a strict hardware-aware design. Through a depth of d = 0.20 and 256 channels of width restrictions, we ensure that the feature maps remain efficient for budget CPUs such as the Broadcom BCM2711. This blueprint allows any researcher to reproduce the architecture accurately by implementing these constants in a standard YOLO YAML configuration.

This architecture is specifically tuned for edge deployment using a depth factor of 0.20 and a width factor of 0.20 as follows:

• Backbone (Layers 0–7):

  ○

  Layer 0–1 (Conv): Downsampling to 160 × 160 with filter counts of 16 and 32.

  ○

  Layer 2 (C3k2 x1): Minimalist block with 32 filters.

  ○

  Layer 3–4 (Conv and C3k2 x2): Processing at 80 × 80 with 64 filters (P3).

  ○

  Layer 5–6 (Conv and C3k2 x1): Processing at 40 × 40 with 128 filters (P4).

  ○

  Layer 7 (SPPF): Final context pooling at 20 × 20 with 128 filters.

• Neck (Single-Stream, Layers 8–10):

  ○

  Layer 8 (Conv): 1 × 1 convolution with 128 filters for P3 feature preparation.

  ○

  Layer 9 (Conv): 3 × 3 convolution, s2, increasing depth to 256 filters (P4).

  ○

  Layer 10 (Conv): 3 × 3 convolution, s1, reaching a maximum of 512 filters for deep semantic features (P5).

• Head (Layer 11):

  ○

  Detect: An anchorless module that integrates the streamlined outputs from Layers 8, 9, and 10 to perform real-time detection for two classes (healthy and bacterial spot).

4. Dataset Preparation

Experimental data were collected from the PlantVillage dataset [34]. This dataset is popularly used to benchmark machine learning algorithms in agriculture. The dataset consists of 54,306 images representing 14 crop species and 26 disease types that were visualized in a controlled environmental setting. Since the images come from various sources, the dataset provides plenty of variation to train reliable machine learning models. For this study, we focused on the bell pepper (Capsicum annuum) dataset. The selected dataset consists of 6475 images sorted into two classes:

• Healthy: 1478 images.
• Bacterial Spot: 4997 images.

Figure 3 shows representative samples of healthy and diseased leaves from the collection. Images are in RGB format and 256 × 256 pixels. We divided the dataset into training, validation, and test partitions using a stratification technique, aiming to maintain the initial distribution of classes across all segments. Specifically, 80% of the images were allocated to training, 10% to validation, and 10% to testing. The application of stratification ensures the proportional representation of minority classes in each subset, thereby minimizing the risk of potential bias due to class imbalance. The validation set was used to adjust the hyperparameters and implement early stopping, while the test set remained completely out of sight during the training phase to ensure a neutral evaluation of model performance at the end. Due to the significant class imbalance (approximately 1:3.4) and the uniform nature of the background in the source images, multiple preprocessing steps were employed, including data augmentation, contrast correction, and background suppression. To mitigate the risk of bias specifically arising from this imbalance, we implemented a targeted minority-class oversampling strategy during the preprocessing phase. For the “healthy” class, we applied a series of synthetic augmentations, including random rotations (up to 30°), horizontal flips, and brightness jittering, to artificially equalize the representation of both classes in the training set. Furthermore, we utilized Mosaic Augmentation during training, combined with Binary Cross-Entropy (BCE) with Logits Loss, which is inherently robust to class imbalances. These techniques ensured that the reported high precision and recall values reflect the model’s genuine discriminative power rather than a bias toward the majority class.

5. Results

To ensure a complete assessment of the efficiency of the models, all YOLO variants were trained, tested, and validated on the same dataset using the same hardware and hyperparameter conditions. We conducted experiments in a Google Colab environment with an NVIDIA Tesla T4 GPU (15.36 GB VRAM, Compute Capability 7.5). To ensure an impartial architecture comparison, all training hyperparameters were strictly defined as those used in the baseline YOLO11n and in the proposed YOLO11_Opt variant. Both models were trained with an initial learning rate of 0.01, batch size of 16, and weight decay of 0.0005 to keep the regularization consistent. A further warmup of three epochs for both models stabilized the gradients in the early phase of their training. Maintaining this uniform configuration meant that the performance trade-offs, namely, the drastic reduction in parameters and GFLOPS versus Mean Average Precision (mAP), were simply a by-product of structural scaling rather than a change in training dynamics.

5.1. Model Evaluation: Training Dynamics

The training and validation loss curves for both the baseline YOLO11n and the proposed YOLO11_Opt are reported in Figure 4. Informed by these metrics, the convergence behavior and learning stability of the models were of crucial interest. As seen in the graphs, the baseline YOLO11n (blue curve) displayed a quick initial convergence, particularly in the first 10 epochs, as illustrated in Figure 4. This was expected due to its higher complexity and the large number of parameters. It can fit such behavior quickly. However, the proposed YOLO11_Opt (red curve) had a different learning profile. Some volatility was seen at the beginning of training (the Validation Class Loss around epoch 10–20), but the model became exceptionally stable in the later stages of training (after 30 epochs). Specifically, despite the far fewer parameters, YOLO11_Opt in the end had lower loss values than the baseline, especially in the Train Box Loss with 0.017 for YOLO11n and 0.011 for YOLO11_Opt, and the Train Object Loss with 0.0068 for YOLO11n and 0.0038 for YOLO11_Opt. This indicates that the aggressive structural optimization (scaling depth/width at 0.20) did not compromise the model’s capacity to learn essential features. Instead, it suggests that the optimized architecture effectively mitigates overfitting, leading to better generalization on the validation set. The consistency of the box and object losses in the final epochs pointed to a robust implementation of the gradient flow. Furthermore, an early stopping mechanism was implemented to monitor validation metrics and prevent overfitting. Although the validation loss stabilized significantly after 30 epochs, the training naturally progressed to the full 70 epochs because the model maintained this stability without exhibiting any signs of degradation.

To sum up, YOLO11n converged a little faster, but YOLO11_Opt was a more efficient option. By compromising the initial convergence for a stable, high-quality final state, YOLO11_Opt is a much better candidate for embedded applications, where reliable long-term inference paired with energy-efficient implementations can outweigh the immediate training convergence.

5.2. Evaluation Metrics

We used multidimensional indicators to effectively evaluate the model performance. The terminology used throughout the manuscript is standardized: the term “accuracy” means standard classification accuracy and “precision” indicates positive predictive value, while “detection accuracy” refers explicitly to overall detection correctness. Their definitions and calculation procedures are described as follows:

• Precision measures the ratio of correctly identified positive detections among all positive predictions [35]. It is calculated using Equation (1):

$$Precision={\displaystyle \frac{TP}{TP+FP}}$$

(1)

• Recall (Sensitivity) [36] calculates the proportion of correctly predicted samples for each positive categorization. The equation is expressed as:

$$Recall\left(Sensitivity\right)={\displaystyle \frac{TP}{TP+FN}}$$

(2)

where TP (True Positive) is the number of positive cases correctly identified by the model, and TN (True Negative) represents accurately detected negative situations. Conversely, FP (False Positive) refers to negative instances that are incorrectly classified as positive, and FN (False Negative) refers to cases that are actually positive but incorrectly classified as negative by the model.

• Mean Average Precision (mAP): The Average Precision (AP) is determined as the area under the precision-recall curve. The mAP reflects the average of the AP values across all classes. Specifically, mAP@0.5 represents the average value when an Intersection over Union (IoU) threshold of 0.5 is set, while mAP@0.5:0.95 refers to the average value when IoU thresholds fluctuate between 0.5 and 0.95 with a step of 0.05. The calculation formula is established as follows [37]:

$$mAP={\displaystyle \frac{1}{N}}{\sum }_{i=1}^N{AP}_i$$

(3)

where N represents the number of classes (N = 2 in this study), and AP_i denotes the AP value for the i-th class.

5.3. Quantitative Analysis

The mAP@0.5:0.95 growth at training is presented in Figure 5. The respective learning behaviors of YOLO11n and YOLO11_Opt were divergent. High performance (~0.95) occurred quickly for the baseline YOLO11n. In contrast, YOLO11_Opt had the best upward trajectory, progressively increasing over time. The mAP started lower but gradually increased to a more competitive value, at 0.91. The YOLO11_Opt was smaller, but its convergence over time was continuous, which is a significant part of the learning process and good for stable and generalizable applications.

Variations within precision by training epochs are displayed for both models in Figure 6. In the first 0–20 steps, the instability of the YOLO11_Opt model was higher than the baseline, and sharp oscillations are reflected. This illustrates the slower convergence rate common to lightweight architectures. Nonetheless, after around 20 epochs, both models achieved a precision of around 0.94. At about 35 epochs, the optimized model achieved precision stabilization near optimal levels. As a result, the final precision of our optimized model was nearly the same as our reference model. This tells us that the aggressive structural optimizations hardly affected the final accuracy and allowed for much more adaptability on embedded systems.

We also analyzed the accuracy and performance of the models using computational complexity metrics, including GFLOPS (Giga Floating-Point Operations Per Second), number of parameters, and model size. These metrics correlate with the hardware resources needed to implement the model. Table 1 provides a comparison of YOLO11n and YOLO11_Opt in FP32, FP16, and integer quantization formats. The comparison shows a drastic reduction in computational cost for the optimized form.

• Performance baseline: YOLO11n (FP32) had excellent metrics of 0.961 mAP and 0.996 accuracy, but it demanded computational complexity: 6.3 GFLOPS, more than 2.58 million parameters, and a model size of 10 MB. The inference time of only 5 ms or less was notable.
• Optimized performance: On the other hand, YOLO11_Opt (FP32) had slightly lower 0.913 mAP and 0.991 accuracy rates, along with a significant reduction in resource consumption, using 0.5 GFLOPS complexity (~92% reduction) and only ~0.33 million parameters (~87% decrease). The model size was reduced to 1.3 MB, providing a significantly faster inference time of 1.4 ms.

This trend persisted with FP16 and integer versions. While quantization slightly affected the metrics, YOLOv11_Opt remained significantly lighter (0.7 vs. 5.1 MB for FP16) and faster. Hence, the results suggest that YOLOv11_Opt offers a solid compromise between accuracy and efficiency, which is particularly attractive for embedded systems that need to run quickly and have small memory footprints. In addition, inference latency was associated with hardware resource utilization to validate the embedded-system claims. Building on aggressive architectural scalability and the optimized 128 × 128 RGB input resolution, the INT8 quantized YOLOv11_Opt model achieved a surprisingly low CPU load of 15% to 20% on Raspberry Pi 4. Likewise, on NVIDIA Jetson Nano, the FP16 model utilized only 10–15% of the GPU via TensorRT and functioned well in its lowest 5 W power mode. These low utilization scores prove that the above optimizations not only realize high throughput and prohibit thermal throttling but also allow for substantial computing space in parallel edge workloads.

This performance profile was influenced by the constraints of general-purpose cloud environments versus specialized edge hardware. In the specific Colab setup with a T4 GPU, FP32 ran faster because it avoided the extra work of quantization and dequantization. While FP32 took a direct route, FP16 and INT8 added extra conversion steps that slowed calculations down in the TFLite and Pytorch runtime, which is primarily optimized for mobile devices, microcontrollers, and single-board computers such as the Raspberry Pi 4. It should be noted that Colab inference times are indicative and serve only for relative comparison; actual edge deployment performance times may differ depending on the target hardware.

Although it is possible to run NVIDIA TensorRT in Colab to achieve faster INT8/FP16 performance, this framework is typically reserved for final deployment on dedicated hardware to fully unlock the GPU’s acceleration. Actual edge deployment performance is detailed in

Table 5. Comparative validation performance and average inference time per object across the two evaluated models.

Model	Type	mAP 0.5:0.95	Precision	Recall	GFLOPS	Params	Model Size (MB)	Inference (ms)
YOLO11n	FP32	0.961 ± 0.002	0.996 ± 0.002	0.991 ± 0.001	6.3	2,582,542	10	5 ± 0.2
	FP16	0.960 ± 0.003	0.996 ± 0.002	0.991 ± 0.002			5.1	5.1 ± 0.3
	Integer	0.944 ± 0.002	0.995 ± 0.003	0.988 ± 0.001			3.1	5.9 ± 0.3
YOLO11-Opt	FP32	0.913 ± 0.001	0.994 ± 0.001	0.986 ± 0.002	0.5	328,223	1.3	1.3 ± 0.1
	FP16	0.911 ± 0.002	0.993 ± 0.002	0.986 ± 0.002			0.7	1.5 ± 0.3
	Integer	0.910 ± 0.002	0.991 ± 0.002	0.983 ±0.001			0.38	1.7 ± 0.2

.

Table 5 details the performance metrics with standard deviations across multiple runs. While YOLO11_Opt showed a marginal numerical variation in precision (0.994 ± 0.001 vs. 0.996 ± 0.002), the overlapping standard deviations confirmed that this difference was statistically negligible. Importantly, the optimized architecture achieved an 87% reduction in parameters and a significant decrease in GFLOPS. Furthermore, the training phase demonstrated high stability across independent trials, with negligible variance in validation performance, confirming the robustness and consistency of the optimization process.

The integer (INT8) models were obtained through Post-Training Static Quantization (PTQ). To guarantee better fidelity during the bit-precision reduction, a representative calibration dataset of 100 images was randomly sampled from the training set. This allowed for the accurate estimation of scale and zero-point parameters for each layer using asymmetric quantization for activations. The TFLite backend was optimized for INT8 for the Raspberry Pi 4 (CPU) deployment according to ARM NEON SIMD instructions, which explains the large speedup we observed. In contrast, FP16 became prioritized for NVIDIA Jetson Nano, in conformity with TensorRT optimization for Maxwell GPU architectures, which are inherently efficient for half-precision floating-point operations.

5.4. Confusion Matrix Analysis and Failure Assessment

The confusion matrix is one of the most important diagnostic tools that distinguishes between the actual vs. predicted labels; it does this by determining explicitly which categories contain most of the class errors [38]. In Figure 7, the new confusion matrix contains explicit numerical counts with a high-contrast normalized scale to illustrate the model’s ability to differentiate the main classes of interest.

• Class separation performance: The healthy class did well; 309 classifications were correctly identified, with negligible misclassification. This demonstrated the stability of both the models and the intraclass variability. The prediction rate of the bacterial spot class was high, with 183 correct predictions out of 186 genuine instances. Furthermore, there was very little confusion between the pathological (bacterial) and physiological (healthy) states, with only three misclassified events. This implies that the diseased leaves can be distinguished from the healthy leaves, which is a prerequisite condition for the automated diagnostic system.
• Ambiguity of background and false alarm rates: We observed from the analysis results that an issue existed regarding the background class, and 186 samples were misclassified as healthy. This pattern indicated that some background objects had similar surfaces to healthy leaves, resulting in false positives. Quantitatively, against this background, 5.4% of real-world cases would display false alarms. This is a well-known problem in unstructured feature environments; the specific lighting or background colors can confuse feature extraction layers.
• Analyzing failure and agricultural impact: Given the false negatives, it was established that missed infections will lead to delayed intervention and crop yield loss. This danger is mitigated by the high recall of YOLO11_Opt (0.984 for the bacterial class), which guarantees that almost all the diseased leaves are flagged. There is a 5.4% false alarm rate (background as healthy), which is “safe” because it does not activate false disease alarms or harmful chemical treatments.
• Conclusion of robustness: In conclusion, the confusion matrix confirmed that YOLO11_Opt performed effectively in distinguishing a healthy leaf from one with bacterial infections. While background ambiguity remains a challenge, it does not interfere with the system’s ability to detect disease presence when a leaf is present. These findings confirm that the model can be effectively integrated into automated systems for plant health monitoring.

6. System Implementation

6.1. Hardware Architecture

The proposed system was optimized for real-time edge inference in plant disease detection. To analyze all the recordings, the edge AI model ran on the core processing unit and detected the diagnosis immediately. The Raspberry Pi 4 Model B and NVIDIA Jetson Nano embedded platforms, which are CPU-based and GPU-based edge computing paradigms, respectively, assessed the scalability and extensibility of our solution.

• The Raspberry Pi 4 (RPi4): This single-board computer has a quad-core Broadcom BCM2711 (Cortex-A72) CPU running at 1.5 GHz. The model was chosen for its general availability, low price (~$70), and enough FP32 (about 32 GFLOPS) performance to support lightweight models [39]. Studies [40] have shown it can efficiently process advanced neural networks without support from cloud infrastructure. During long-duration inference on Raspberry Pi 4, throttling may occur due to thermal constraints. System monitoring was performed, and appropriate cooling or workload scheduling and low CPU load can mitigate this effect.
• NVIDIA Jetson Nano: Built specifically for edge AI, this module combines a quad-core ARM Cortex-A57 CPU with a 128-core Maxwell GPU. With low power consumption (5–10 W), it offers 472 GFLOPS of computing power, including parallel processing using CUDA cores and optimizing TensorRT [41,42]. The Jetson Nano Developer Kit can cost 250 USD. The price may vary depending on the country and distributor.

Both systems employ the Raspberry Pi Camera Module 3 with a 12 MP Sony IMX477R sensor for acquisition of images. This sensor was selected due to its high resolution and good low-light performance that guaranteed the quality of input data for the model [43]. The technical specifications of the experimental hardware are illustrated in

Table 6. Comparison of RPi4 and NVIDIA Jetson Nano.

	RPi4B	Jetson Nano
Processor type	CPU	GPU
Processor	BCM2711 ARM Cortex A72	4-core ARM A57 1.43 GHz CPU and 128-core Maxwell GPU
RAM	4 GB LPDDR4	4 GB LPDDR4
Storage	microSD	microSD
Networking	Wi-Fi 5 ac, Bluetooth 5.0, Gigabit Ethernet	1 × Gigabit Ethernet
GPIO pin	40	40
Power input	USB-C (5 V, 5 A)	USB-C (5 V, 4 A)
Idle power	3.2 W	2 to 3 W
Use	AI, ML, high-speed computing	Robotics, IoT, ML, DL, edge computing
Price	70 USD	250 USD

.

While direct power measurements were not conducted, YOLO11_Opt’s energy efficiency was evidenced by its 92% reduction in GFLOPS, which drastically lowered the electrical draw. On the Raspberry Pi 4 (power envelope: 3 W idle to 6 W max), the model’s minimal 15–20% CPU utilization keeps power consumption remarkably close to the idle baseline. Similarly, it utilizes only 10–15% of the Jetson Nano’s GPU, operating comfortably within its strict 5 W mode. By requiring significantly fewer processing cycles per frame, the model avoids peak power limits and thermal throttling, confirming its viability for low-cost, low-energy agricultural systems.

6.2. Model Deployment and Performance Analysis

To evaluate the potential for actual deployment, some in-depth live inference experiments were carried out on two distinct edge devices, Raspberry Pi 4 (CPU) and NVIDIA Jetson Nano (GPU). To enable cross-device portability, the trained YOLO11_Opt model was first exported in the ONNX framework. It was then transformed to TensorFlow Lite (TFLite) for Raspberry Pi 4 and TensorRT for NVIDIA Jetson Nano, using the hardware-specific, accuracy-aware optimization. To facilitate a systematic assessment, the reported throughput (FPS) and latency statistics covered the complete processing pipeline from image pre-processing and model inference to post-processing. These metrics did not include hardware-dependent camera I/O latency as a sole measure of the architecture’s computational capacity. To validate these values, three different numerical precision formats (FP32, FP16, and INT8) were checked in a series of independent runs. The mean values along with their standard deviations are reported in

Table 7. Inference performance of YOLO11n and YOLO11_Opt on RPi4 and NVIDIA Jetson Nano.

Platform	Model	Class	Inference Type	FPS	Precision (%)	Inference (ms)
Raspberry Pi 4	YOLO11n	Healthy	FP32	26.87 ± 0.87	92.4 ± 1.3	37.24 ± 1.11
			FP16	25.74 ± 0.92	90.5 ± 1.7	38.91 ± 1.44
			Integer	29.17 ± 1.11	91.6 ± 1.12	34.33 ± 1.31
		Bacterial	FP32	25.89 ± 0.83	93.8 ± 0.28	38.67 ± 1.24
			FP16	25.99 ± 0.75	89.1 ± 1.02	38.51 ± 1.1
			Integer	30.06 ± 0.96	86.75 ± 2.11	33.29 ± 1.08
	YOLO11_Opt	Healthy	FP32	93.17 ± 13.53	93.4 ± 0.18	10.97 ± 1.68
			FP16	102.56 ± 10.52	91.3 ±1.59	9.75 ± 1.07
			Integer	94.66 ± 11.26	85.5 ± 1.95	11.6 ± 1.52
		Bacterial	FP32	97.18 ± 11.57	91.8 ± 0.18	10.44 ± 1.28
			FP16	102.56 ± 10.52	91.58 ± 0.42	10.15 ± 0.99
			Integer	99.83 ± 8.35	86.3 ± 2.31	12.35 ± 1.26
NVIDIA Jetson Nano	YOLO11n	Healthy	FP32	142 ± 37.1	95.4 ± 1.21	5.1 ± 0.8
			FP16	224 ± 27.5	93.8 ± 1.4	4.1 ± 0.7
			Integer	179.3 ± 68.5	91.2 ± 2.07	5.5 ± 1.8
		Bacterial	FP32	184.3 ± 18.2	94.6 ± 1.13	4.5 ± 0.6
			FP16	178.5 ± 66.1	92.1 ± 0.62	4.4 ± 1.1
			Integer	244.6 ± 58.5	87.4 ± 1.34	3.6 ± 1.2
	YOLO11_Opt	Healthy	FP32	325.7 ± 46.2	93.9 ± 1.11	2.5 ± 0.7
			FP16	338.5 ± 92.7	90.7 ± 1.84	2.6 ± 1.3
			Integer	341.2 ± 62.6	90.1 ± 1.8	2.8 ± 0.9
		Bacterial	FP32	326.8 ± 53.86	93.2 ± 0.78	2.5 ± 0.7
			FP16	305.2 ± 108.3	91.7 ± 0.93	2.7 ± 1.2
			Integer	355.8 ± 95.5	88.6 ± 1.72	3.8 ± 1.2

, indicating consistency of performance.

• CPU-Based Inference (Raspberry Pi 4)

The YOLO11_Opt model was shown to achieve high efficiency on the Raspberry Pi 4 with ARM Cortex-A72. In the case of the FP32 format, the model received a peak throughput of 93.17 ± 13.53 FPS, along with a very low latency of 10.97 ± 1.68 ms, and the FP32 formatted result surpassed the INT8 quantized version (94.66 ± 11.26 FPS). This result was due to the optimization of NEON floating-point instructions in the Cortex-A72 and the computational burden associated with de-quantization in the absence of a dedicated Neural Processing Unit (NPU). Such hardware constraints notwithstanding, all inference times were markedly below 11 ms, and the negligible standard deviations visible here correspond to the stability achieved in the training phase, allowing the model to represent a practical, real-time solution for cost-effective, CPU-only devices.

• GPU-Based Inference (NVIDIA Jetson Nano)

Jetson Nano combined GPU acceleration and TensorRT optimization, which greatly increased the throughput. YOLO11_Opt peaked at 338.5 ± 92.7 FPS in FP16 and 325.7 ± 46.2 FPS in FP32, with only an average latency of 2.5 ± 0.7 ms, a noticeable performance improvement over the baseline YOLO11n, which achieved around 142 FPS. Moreover, the model remained very stable in the INT8 format with precision exceeding the competitive range (>88%). Close to zero jitter in inferencing on multiple tests demonstrated the deterministic potential of the optimized model with GPU hardware.

• Synthesis and Scalability

These performance verifications demonstrate YOLO11_Opt’s ability to scale quite well across different architectures. The small variance across many runs means that the observed trends in this area are statistically significant and not transitory figures. Deployed on a restricted CPU-based or fully leveraging edge GPU acceleration, this extensible approach offers a high-performance framework for smart agricultural monitoring in real-time contexts.

The FPS and latency metrics represent the peak computation throughput, i.e., pre-processing, model inference, and model post-processing (Non-Maximum Suppression/NMS), excluding hardware-dependent camera I/O latency. Although the precision and recall of “healthy” samples differed from those of “bacterial” samples due to differences within classes, the FPS stayed almost constant. This is because the basic inference takes a fixed and deterministic count of operations on each image. The modest changes in speed result only from the NMS process and vary slightly with the number of candidate detections. This performance overhead confirms the model’s capacity to handle multiple camera streams or operate with high energy efficiency in real-time deployment.

6.3. Live Classification Validation

These live classification experiments test the model in real-time operational application, verify practical applicability, and ensure its robustness. This is critical to ensure that the theoretical work in the validation is relevant in real time to the actual area, correctly diagnosing the diseases, which is key to good crop management. System Workflow: The full end-to-end processing pipeline employed in this study is shown in Figure 8. The first step is the Sensor Node, in which the Raspberry Pi Camera Module 3 takes high-resolution pictures of the leaf samples. This raw data is fed into the Edge Processing Unit (either Raspberry Pi 4 or NVIDIA Jetson Nano) where the inference can be generated by the YOLO11_Opt model. After that, the captured data, such as bounding boxes, class labels, and confidence ratings, is displayed in the Monitoring Station (IHM), allowing the user immediate feedback.

6.3.1. Raspberry Pi 4 Results (CPU Inference)

Figure 9 shows representative detection data on Raspberry Pi 4 for the three selected quantization methods, FP32, FP16, and INT8.

• FP32 (baseline): The model has a confidence score of 0.92 for “bacterial spot” and 0.86 for “healthy”.
• FP16: The detection is consistent with the confidence scores obtained for bacterial samples: 0.91, and healthy samples: 0.88.
• INT8: Similar to integer quantization, the model exhibits robust detection ability, delivering 0.88 (bacterial) and 0.86 (healthy) scores. Such results confirm that quantization on the CPU provides the lowest degradation of detection confidence scores and the best performance in memory usage.

6.3.2. NVIDIA Jetson Nano Results (GPU Inference)

The assessment was solely of the INT8 format for NVIDIA Jetson Nano (Figure 10). This setup, of course, was selected for the high hardware acceleration of the Maxwell GPU through TensorRT. In edge AI deployment, INT8 is an industry standard resulting in the smallest latency and memory footprint while maximizing throughput. Despite its lower precision values, the YOLO11_Opt model managed to produce strong classification outcomes:

• Healthy class: Detected with a confidence score of 0.93.
• Bacterial class: Detected with a confidence score of 0.88.

These observations suggest that INT8 quantization offers a good trade-off between computational cost and accuracy. Indeed, the model’s predicted classes of pathological and physiological states were also recognized with high confidence scores, which proves YOLO11_Opt is a good value solution in resource-limited smart agriculture cases.

7. Conclusions

The main objective of this work was to develop and validate a cost-effective autonomous plant disease detection tool based on computer vision and embedded artificial intelligence. This system is expected to replace or strengthen conventional manual inspection methods for small- and medium-sized farms and empower small and medium farms with available crop protection tools. Consequently, we developed YOLO11_Opt, a novel, ultra-lightweight YOLO11-type architecture adapted for use on resource-constrained edge devices such as the Raspberry Pi 4 and NVIDIA Jetson Nano.

7.1. Overall Contributions and Results

Our analysis fully confirmed the technical and functional practicality of the solution. Extreme architectural scaling (0.20 minimum depth, 0.20 minimum width) and structural simplifying of the neck, which drastically reduce the computation cost of YOLO11_Opt, led to our conclusion. More specifically, the number of parameters decreased by 87% (reducing the parameter count from 2.58 million to 0.33 million) and the number of operations decreased by 92% (reducing the model complexity from 6.3 to 0.5 GFLOPS) versus the baseline YOLO11n. Despite this drastic compression, the model retained excellent detection capabilities, achieving a Mean Average Precision (mAP@0.5:0.95) of 0.913 and a precision of 0.991. Moreover, the real-time application deployment tests validated the appropriateness of the system: inference latencies as low as 8.3 ms (approx. 120 FPS) were observed on Raspberry Pi 4 and 1.9 ms (approx. +526 FPS), demonstrating that effective phytosanitary monitoring on low-end hardware is not dependent on cloud infrastructure.

7.2. Limitations

This study has some limitations. First, it was primarily based on a design validation using the PlantVillage dataset, although this dataset contains images acquired in controlled laboratories. Therefore, we expect some of the model’s robustness to decrease as we encounter the highly variable nature of open-field habitats (dynamic lighting, occlusions, and various backgrounds), which appear as the background confusion in our failure analysis. Second, although CPU inference on Raspberry Pi 4 is possible, it can be limited within the hardware for high-resolution streams and may be more complicated for the scalable application within multi-camera configurations.

7.3. Future Work

These challenges will be pursued in future research to increase the statistical robustness and generalizability of the solution. Key directions include the following:

• Expansion of training data: Encompassing “in-the-wild” field images to enhance the model’s generalized performance in the context of diverse images.
• Hardware acceleration: Exploring the possibility of adding dedicated Neural Processing Units (NPUs) or migrating to next-generation platforms such as Raspberry Pi 5 for additional efficiency and speed.
• Multi-crop generalization: The YOLO11_Opt architecture can be extended for the detection of diseases among a wider variety of crop species at once to move toward a universal diagnostic tool for smart farming.
• Real-world deployment: Future research will focus on evaluating the YOLO11_Opt architecture using diverse, field-captured datasets to assess its robustness under varying illumination and complex environmental backgrounds, building upon the optimization foundation established in this study.