RK3566 Can Run YOLOv8 INT8 — But Only Within These Limits

Running YOLOv8 INT8 on an RK3566 is not merely a model conversion task; it's a system-level alignment problem. This article explores how quantization, operator compatibility, and detection head design determine whether real-time inference is feasible on the RK3566 and under what strict conditions. Many edge AI projects consider the RK3566 a cost-effective platform that can handle AI tasks.

However, it was not designed for complex models with limited compute power. YOLOv8 Detection sits in a delicate position, being neither lightweight nor server-level, but rather a "just about doable" category for the RK3566. In practice, projects often run smoothly at the model stage but encounter performance issues when deployed on the RK3566.

The RK3566 is not a platform that brute-forces inference; its usability depends on having a clean execution path. Floating-point inference yields poor results on the RK3566 due to unsupported operators falling back to the CPU, causing low NPU coverage, constant data movement, and high scheduling overhead. This results in single-digit FPS with near-maxed system load.

INT8 isn't just about precision; it unlocks the most stable and fully supported execution path on the chip. Switching to INT8 reveals the RK3566's true nature, as operator mapping success rises, ops stay longer in the NPU, and the CPU acts more like a scheduler. However, INT8 isn't cost-free; detection models are sensitive to quantization, especially in the Head.

Poor quantization can lead to missed detections or box jitter. The real question isn't whether to use INT8 but how far YOLOv8 Detection can go on the RK3566 with INT8 and what the boundaries are. YOLOv8 Detection's structure determines RK3566 compatibility, with the Detection Head being the most prone to quantization distortion due to frequent resolution shifts, wide numerical ranges, and extreme precision demands.