Tiling mi Hız mı? Jetson'da Ölçtük, Tasarımı Değiştirdik

Küçük nesne tespitinde bilinen bir çözüm var: dilimli çıkarım (tiling). Kareyi olduğu gibi modele vermek yerine örtüşen parçalara bölüp her parçayı ayrı ayrı işlersiniz. Böylece uzaktaki küçük hedef, parçanın içinde oransal olarak büyük görünür ve model onu yakalayabilir.

Bizde de tam olarak böyle çalıştı. Sonra Jetson’a taşıdık ve saniyede 1-3 kareye düştük.

Bu yazı, “işe yarayan çözüm” ile “sahada kullanılabilir çözüm” arasındaki farkın hikâyesi.

Tiling gerçekten işe yaradı

Önce kanıtı. Eski modelimizin hiçbir tespit üretmediği iki gerçek hava karesini aldık ve üzerinde yalnızca dilimli çıkarımı çalıştırdık — modelde, veride, eğitimde hiçbir değişiklik yapmadan.

Kare	Tam-kare çıkarım	Dilimli çıkarım
Kare 1	0 tespit	5 tespit (maks. güven 0.74)
Kare 2	0 tespit	1 tespit

Bu sonuç bizim için bir dönüm noktasıydı, çünkü sorunun nerede olmadığını gösterdi. Model o nesneleri tanıyabiliyordu; onları göremiyordu. Fark, nesnenin ağın önüne kaç piksel olarak geldiğiydi.

(Not: bu iki karede ground truth resmi olarak etiketlenmemişti, o yüzden bunu bir “recall ölçümü” değil, kurtarma sinyali olarak raporluyoruz. Aradaki farkı önemsiyoruz.)

Bu bulgu iki şeyi tetikledi: veri setini ve ölçek politikasını baştan kurmak (o yazı burada), ve dilimli çıkarımı uçuş yazılımına almak.

Jetson’a taşıdık: 1-3 FPS

Dilimli hattı Jetson Orin NX üzerinde çalıştırdığımızda ölçtüğümüz değer saniyede 1-3 kare oldu.

İlk tepkimiz “GPU yetmiyor” demek olurdu. Ama profil çıkardığımızda darboğazın GPU’da olmadığını gördük: zaman, her dilim için yapılan CPU tarafındaki ön ve son işlemede harcanıyordu. Kareyi dilimlere ayırmak, her dilimi modele uygun hale getirmek (letterbox, normalizasyon), sonra her dilimin çıktısını global koordinata geri taşıyıp birleştirmek (NMS) — bunların hepsi dilim sayısıyla çarpılıyordu.

Yani sorun “model ağır” değil, **“her kare için aynı işi N kez yapıyoruz”**du.

Bu ayrım önemli: eğer teşhisi “GPU yetersiz” koysaydık, çözüm olarak daha küçük model veya daha güçlü donanım ararsak yanlış yolda ilerlerdik.

Asıl soru: FPS bir gereksinim mi, tercih mi?

Burada durup şunu sorduk: bize gerçekten kaç FPS lazım?

Bu, atlanması çok kolay bir sorudur. “Gerçek zamanlı” ifadesi genelde sorgulanmadan 30 FPS demekmiş gibi kullanılır. Oysa gereksinim görevden çıkar:

• Bizim akışımızda uçak hedefi tespit ediyor, konumunu kaydediyor, sonra oraya gidip nesneyi ortalayarak bırakma yapıyor.
• Ortalama (centering) aşaması kapalı döngü bir kontrol: uçak görüntüye bakarak konumunu düzeltiyor.

Kapalı döngü kontrolde düşük kare hızı doğrudan gecikme demek. 2 FPS ile çalışan bir kontrol döngüsü, uçak hareket ettikçe 500 ms eski bilgiye göre karar verir — hedefin etrafında salınmaya başlar. Tarama aşaması için 2 FPS yeterli olabilirdi; ama ortalama aşaması için değildi.

Yani cevap: bizim senaryomuzda FPS gerçekten bir gereksinimdi.

Takas: çözünürlüğü hıza çevirdik

Uçuş konfigürasyonunu değiştirdik:

	Dilimli mod	Uçuş modu
Çıkarım	1280 px dilimler + tam kare	Tek tam-kare geçiş, 640 px
Kare hızı (Orin NX)	1-3 FPS	15-20 FPS
~20 m’de hedef boyutu	dilim içinde büyük	~32 px
~46 m’de hedef boyutu	dilim içinde makul	~14 px

Dikkat: hızlanmayı getiren şey daha küçük model ya da daha agresif optimizasyon değildi. Dilimli yapıyı kaldırmanın kendisiydi — dilim başına yapılan CPU işi ortadan kalkınca kare hızı bir anda 15-20’ye çıktı.

Bu takasın geçerli olduğu bir bant var: doğrulanmış çalışma irtifamız olan ~20 metrede manken, küçültmeden sonra hâlâ yaklaşık 32 piksel. Yeniden eğittiğimiz modelin ölçek politikası bu boyutu kapsıyor.

Takasın dürüst bedeli

Bu tür kararları anlatırken kolay olan, kazanılan tarafı yazıp bedeli geçiştirmektir. Bedel şu:

46 metrede (yarışmanın bırakma çiti) manken, 640 pikselik girişte yaklaşık 14 piksele düşüyor ve bu bandda tespit denememizi henüz yapmadık.

Bu, bilinen ve kabul edilmiş bir açık. Yedek planımız hazır: dilimli modu ve derlenmiş TensorRT FP16 motorunu kod tabanında kapalı seçenek olarak tutuyoruz. 46 m testinde tam-kare bütçesi yetmezse, dilimli modu geri açıp daha düşük kare hızını kabul edeceğiz — ve o zaman ortalama stratejisini de ona göre değiştirmemiz gerekecek.

Ama “hazır plan”, “ölçülmüş sonuç” değildir. Bunu böyle yazıyoruz.

Bir tasarım kararının iki kez değişmesi

Geriye dönüp bakınca ilginç olan şu: aynı test, tasarımı iki kez değiştirdi.

1. Dilimli çıkarım denemesi → tespit kaybının nedeninin ölçek olduğunu gösterdi → veri seti ve eğitim politikası yeniden kuruldu.
2. Aynı hattın Jetson profili → CPU darboğazını gösterdi → uçuş konfigürasyonu tam-kare moda geçti.

İyi bir test, “geçti/kaldı” demez; bir sonraki kararı belirler. Bizim durumumuzda tiling, uçuşta kullanmadığımız halde projenin en değerli deneylerinden biri oldu — çünkü sorunun nerede olduğunu ve nerede olmadığını gösterdi.

Çıkarılacak dersler

1. “Çalışıyor” ile “sahada çalışıyor” farklı şeylerdir. Bir çözümü hedef donanımda ölçmeden mimarinize almayın.

2. Optimize etmeden önce profil çıkarın. Bizim darboğazımız GPU değil CPU ön/son işlemeydi; yanlış teşhis yanlış çözüme götürürdü.

3. “Gerçek zamanlı” ifadesini sorgulayın. Kaç FPS gerektiğini görevin kendisi belirler; tarama ile kapalı döngü kontrol aynı şeyi istemez.

4. Takasın bedelini açıkça yazın. Kazandığınızı anlatıp kaybettiğinizi gizlemek, kendi ekibinizi de yanıltır.

5. Reddettiğiniz çözümü silmeyin. Dilimli mod bizde kapalı bir seçenek olarak duruyor; koşullar değişirse hazır.