Inspiration
Modern detectors like YOLOv11 are strong in accuracy and size, but deploying them on edge DPU hardware is not drop-in. Ops, activations, and head design often break quantize/compile for Vitis AI + DPUCZDX8G.
We used a fixed vision task only as a workload, and focused on the real goal: make a newer YOLO family run efficiently on Kria KV260 and compare it to a known baseline.
What we optimized
| Stage | Model | Focus |
|---|---|---|
| Baseline | YOLOv4-Leaky INT8 | Measured reference on KV260 DPU |
| Optimization | YOLOv11n INT8 | Surgery → quant → compile → DPU runtime |
Same board (KV260), same DPU (DPUCZDX8G), same task framing—so differences come from model + deployment path, not from a new application story.
How we built the optimization path
- Baseline lock-in — YOLOv4 already quantized and running on KV260 (~11.17 FPS, ~95 ms latency, strong INT8 accuracy). This is the reference, not the product pitch.
- YOLOv11n train — Nano variant (~2.6M params) trained for the same 2-class head so the deploy path stays comparable.
- Model surgery for DPU — Replaced unsupported or fragile patterns (e.g. SiLU → Hardsigmoid, safer splits, head simplified for tracing) so Vitis AI 3.5 could quantize and compile.
- Quantize + compile — INT8 path to xmodel for DPUCZDX8G.
- On-board runner — VART load, correct fix_point dequant, multi-scale DFL decode, NMS; verified end-to-end on hardware.
Results (optimization view)
YOLOv4 baseline (KV260)
- End-to-end ~11.17 FPS, ~95 ms
- INT8 accuracy held up well after quant
YOLOv11n optimized path (KV260)
- DPU inference ~12.7 ms per frame
- Full train → surgery → INT8 → xmodel → board path working
- Detections on-device; confidence still softer than YOLOv4 after INT8 (expected next lever: calib/QAT)
So: baseline = proven full-stack INT8 deploy; optimization = newer, smaller detector brought onto the same DPU with explicit surgery and runtime fixes.
Challenges
- Graph compatibility — Stock YOLOv11 did not quantize cleanly; surgery was mandatory.
- Tracing / quant failures — Head and tensor layouts needed simplification before
vai_q/ compile succeeded. - Wrong post-process looks like model failure — DPU ran in ~12 ms with 0 boxes until dequant + DFL decode matched the 66-channel heads (
4×16 + 2). - INT8 score drop — YOLOv11 runs; calibration quality still limits confidence vs YOLOv4.
What we learned
- On Arm + DPU, optimization work is mostly deployment engineering: ops, quant, compile, and decode—not only training.
- A measured baseline on the same board makes claims honest.
- Model surgery is a first-class step for YOLO-class models on DPUCZDX8G.
- Sub-13 ms DPU time is achievable for YOLOv11n; closing the accuracy gap after INT8 is the next optimization target.
What’s next
- Stronger INT8 recovery (better calib set / QAT) for YOLOv11n
- Fair board-level FPS comparison (full pre/post included), not only pure DPU time
- Optional further graph trimming for DPU utilization
Bottom line: This project is about bringing YOLOv11n through Vitis AI surgery and INT8 onto KV260, using YOLOv4 as the on-hardware baseline—not about building a posture product narrative.
Log in or sign up for Devpost to join the conversation.