Belajar YOLO - Memilih Model Size (Nano s/d Extra Large)

#Pendahuluan

Setelah episode lalu kita menguasai multi-task detect/segment/classify, ada keputusan teknis lain yang akan kalian ambil di setiap project: memilih ukuran model. yolo26n? yolo26s? Atau langsung yolo26x?

Kesalahan umum pemula adalah mengambil keputusan ini dengan perasaan: "pakai yang besar biar akurat" atau "yang nano biar cepat". Keduanya bisa salah total. Ukuran model menentukan cost infrastruktur, latency aplikasi, dan batas atas akurasi kalian — jadi ini keputusan engineering, bukan selera. Episode ini memberi kerangka berpikirnya plus cara benchmark yang benar.

#Anatomi Skala: Satu Arsitektur, Lima Kapasitas

Ingat episode 3: file yolo26.yaml punya parameter scales (depth & width multiplier). Dari satu arsitektur itu lahir lima varian:

*Angka resmi COCO; performa di dataset kalian pasti berbeda — itulah gunanya benchmark sendiri.

Dua multiplier yang bekerja:

• Width — jumlah channel tiap layer (otot per layer).
• Depth — jumlah blok berulang (panjang jaringan).

Analogi restoran: width = jumlah komisaris dapur per station, depth = jumlah station. Nano adalah warung satu orang; XL adalah dapur hotel bintang lima. Masakan (arsitektur) sama, kapasitas produksinya beda jauh.

#Trade-off: Kecepatan vs Akurasi

Grafik hubungan keduanya selalu berbentuk kurva yang flattening:

mAP %
58 |                                        x (X)
56 |
52 |                          m (M)   l (L)
48 |            s (S)
41 |   n (N)
   +----------------------------------------
      cepat                              lambat
      murah                              mahal

Tiga fakta penting dari pola tersebut:

1. Lonjakan n→s/m signifikan, s→l/x makin tipis — akurasi tambahan tidak linear terhadap biaya.
2. Latency & VRAM naik hampir linear terhadap ukuran — berdampak langsung ke tagihan cloud.
3. Dataset kecil jarang memanfaatkan model besar. Kapasitas raksasa tanpa data secukupnya hanya menghasilkan overfitting lebih cepat.

#Kerangka Keputusan

Aturan emasnya: mulai dari nano/small, naikkan hanya jika metrik validasi stagnan dan data mendukung. Ini kebalikan insting kebanyakan orang — tapi inilah cara engineer senior bekerja.

#Praktik: Benchmark Beberapa Size di Dataset yang Sama

Teori tanpa angka di dataset sendiri tidak berarti. Mari bangun skrip benchmark kecil:

from ultralytics import YOLO
 
IMG = "samples/street.jpg"
 
for size in ["yolo26n", "yolo26s", "yolo26m"]:
    model = YOLO(f"{size}.pt")
 
    # 1) ukur latency (warm-up dulu agar adil)
    for _ in range(3):
        model(IMG, verbose=False)
    import time
    t0 = time.perf_counter()
    for _ in range(20):
        r = model(IMG, verbose=False)[0]
    dt = (time.perf_counter() - t0) / 20 * 1000
 
    # 2) hitung kapasitas
    params = sum(p.numel() for p in model.model.parameters()) / 1e6
    print(f"{size:>8} | {params:5.1f}M params | {dt:6.1f} ms/img | {len(r.boxes)} deteksi")

Contoh output di laptop CPU:

 yolo26n |   2.4M params |   38.2 ms/img | 5 deteksi
 yolo26s |   9.4M params |   91.7 ms/img | 6 deteksi
 yolo26m |  19.9M params |  198.3 ms/img | 6 deteksi

Perhatikan dua insight dari tabel semacam ini:

• Latency naik lebih cepat daripada parameter — bukan hanya komputasi bertambah, bandwidth memori juga.
• Jumlah deteksi hampir sama pada gambar mudah — keunggulan model besar baru kelihatan di kasus sulit (objek kecil, crowd). Uji dengan gambar yang menantang!

Untuk benchmark akurasi yang sebenarnya, bandingkan val mAP setiap ukuran setelah fine-tuning singkat di dataset kalian (prosedur training lengkap di episode 9–10).

#Common Pitfalls Memilih Ukuran

• "Model besar = selalu lebih baik": pada dataset < 1.000 gambar, x sering kalah dari s yang fine-tuned benar — overfitting datang lebih dulu daripada keuntungan kapasitas.
• Melupakan biaya inference: model x di API berarti tagihan GPU bulanan berlipat dibanding n. Hitung cost per 1.000 request.
• Membandingkan FPS lintas resolusi: n pada imgsz=320 vs x pada imgsz=1280 bukan perbandingan yang sah — samakan dulu semua variabel.
• Lupa task: ukuran optimal untuk detection belum tentu untuk segmentation — mask head lebih berat, jadi budget latencinya lebih sempit.

#Penutup

Rangkuman episode ini:

• Satu arsitektur, lima ukuran via depth/width scaling: n → s → m → l → x.
• Lonjakan akurasi terbesar ada di n→s/m; s→x mahal dengan gain makin tipis.
• Dataset kecil jarang sanggup memanfaatkan model besar — mulai nano/small, scale-up saat validasi stagnan.
• Selalu benchmark latency & akurasi di device target dengan resolusi seragam.
• Biaya inference adalah bagian dari keputusan — bukan hanya mAP.

Di episode 8 kita masuk fase persiapan data: format dataset YOLO — struktur folder images/labels, anatomi file txt normalized, dan data.yaml — plus tur tools annotation seperti Roboflow, CVAT, Label Studio, dan trik auto-labeling. Inilah bahan bakar untuk training di episode 9–10. Sampai jumpa!