Yapay zeka iyileştirme ne kadar büyütmeli? Sınırlı bir tasarım

Süper çözünürlük modelleri karesel çalışır: giriş kenarını ikiye katla, işi ve bekleme süresini dörde katlarsın. Birini insanların yüklediği her şey üzerinde naif biçimde çalıştır, 40 megapiksellik bir tarama dakikalar sürerken bir telefon karesi saniyeler sürer. İyileştirme aşamamız bunun yerine her işi, ne gelirse gelsin modelin iş yükü aynı sınırlı boyutta olacak biçimde planlar. Bu not planlama kuralını veriyor ve bu revizyonda yeni olarak, iki taşıyıcı iddiasının arkasındaki ölçümleri: sınırlandıktan sonra maliyetin doğrusal olduğu (kıyaslama makinesinde giriş megapikseli başına ~15.6 s, r² > 0.999) ve karolu çıkarımın görsel olarak dikişsiz olmasının yalnızca her karonun 8 px bağlam taşımasından kaynaklandığı; bu bağlam, sıfır dolgunun geride bıraktığı dikiş enerjisinin %87'sini kaldırıyor.

Bu nottaki her sayı üretim hattının kodunda ölçüldü: aynı modeller, aynı matematik. Görüntü başına ham kayıtlar: e6_tiles.json.

1 · Planlama kuralı

Aşama, 4× süper çözünürlük modeli^[1] kullanarak uzun kenarda en fazla 2560 px'lik bir çıktı hedefler. Geriye doğru gidersek modelin hiçbir zaman 2560 ÷ 4 = 640 px'ten uzun bir girişe ihtiyacı yoktur; bu yüzden planlayıcı, model çalışmadan önce ne gelirse gelsin onu bu sınıra ön küçültür ve yükleme 1 MP de olsa 40 MP de olsa modelin girişini yaklaşık 0.41 megapiksel ile sınırlar. Biçimsel olarak, uzun kenarı L olan bir yükleme için:

Kuralı üç koruma tamamlıyor: çıktı asla orijinal çözünürlüğün altına düşmez (iyileştirme sana asla piksel kaybettirmemeli), hedefe yakın ya da üstünde olan girişler geçişi tamamen atlar (1.3× minimum kazanç maddesi; çünkü bunun altında yeniden örnekleme ve model gidiş dönüşü keskinleştirdiği kadar bulanıklaştırır) ve yüzler geçişten sonra restore edilir; böylece yüz kırpmaları yüz modeline iyileştirilmiş çözünürlükte girer.

2 · Neden bir sınır: maliyet doğrusaldır, sen öyle yaptıktan sonra

Tüm tasarımı motive eden iddia ölçülebilir, biz de ölçtük: üretim büyütme yolu (192 px karolar, 8 px dolgu, ONNX Runtime CPU^[3]) 2 vCPU'lu konteyner sınıfı donanımda 0.04 ile 0.39 megapiksel arasındaki girişler üzerinde çalıştırıldı:

Aynı taramadan ikinci bir mühendislik gerçeği çıkıyor: toplam çalışma süresi karo boyutundan neredeyse bağımsız (96 → 384 px arasındaki tüm değerler birbirinin %8'i içinde): iş piksel başınadır ve 8 px'teki dolgu yükü gürültü düzeyindedir. Dolayısıyla karo boyutu hız için değil, bellek için seçilir: 192 px, tepe tensörü tarayıcı yedek motorunun WASM yığını için yeterince küçük tutar.

3 · Dikiş vergisi ve 8 px bağlamın onu neden ödediği

Karolamanın makalelerin nadiren üzerinde durduğu bir hata biçimi var: evrişimlerin alıcı alanları vardır, dolayısıyla çevresinde bağlam olmadan kesilmiş bir karo kenarı boyunca yanlıştır ve yeniden birleştirilen mozaik bir ızgara gösterir. Bunu bir dikiş indeksiyle ölçüyoruz: karo sınırı piksel sütunları boyunca ortalama luma gradyanı bölü başka yerlerdeki ortalama gradyan; 1.0, sınırların istatistiksel olarak görünmez olduğu anlamına gelir:

O eğrinin şekli tasarım argümanının minyatürü: ilk iki piksel bağlam iyileşmenin yarısını satın alıyor, sekiz azalan getiri satın alıyor ve sekizin ötesinde hiçbir izleyicinin bulamayacağı dikiş enerjisi için karesele yakın dolgu yükü ödüyorsun. (İyileştirilmiş piksellerin kendilerinin klasik interpolasyonu yenip yenmediği ölçülmüş yanıtı olan ayrı bir soru; modelin Lanczos-3'e 1.07 dB PSNR verip kenar enerjisinin 3.1 katını geri getirdiği 28 görüntülük kıyaslamaya bak^[2].)

4 · Ölçülen süreler, uçtan uca

Kıyaslama: 821×1024'lük siyah beyaz bir tarama, 2052×2560'a restore edilmiş, renklendirilmiş, bir yüz, sıcak bir örnekte.

Aynı fotoğrafta üretimde uçtan uca: soğuk başlatmada (model ağırlıkları yüklenirken) 68 s, sıcakta 32 s. Ölçek için: hiçbir şeyi büyütmeyen ve yalnızca yüzlere dokunan önceki hat sıcakta 23–34 s sürüyordu; sınırlı tüm görüntü geçişi duvar saatine neredeyse hiçbir şey eklemiyor, çünkü girişi yapısı gereği küçük. Aynı iş tarayıcının içinde çalıştığında ise (otomatik yedek), 1000×1223'lük bir tarama WebGPU'lu Apple silikon bir masaüstünde 340.8 s sürdü (aynı sınırlı plan, kabaca 10× duvar saati). Sınır, bu en kötü durumu bile sınırsız değil, kullanılabilir tutan şeydir.

5 · Reddedilenler

Difüzyon tabanlı süper çözünürlük (yığınımızda etkileşimli bir araç için fazlasıyla yavaş), varsayılan olarak daha büyük yüz başına restorasyon modelleri (grup fotoğraflarında yüz başına süre şişer) ve fotoğrafları harici GPU çıkarım API'lerine göndermek: fotoğraflar altyapımızdan çıkardı, ki gizlilik sözü bunu dışlar. Sınırlı plan, kalite kazanımlarını izleyicinin gerçekten algıladığı yerde, ekran boyutunda bir görüntüde tutar; kimsenin göremeyeceği pikseller için karesel ödeme yapmak yerine.

6 · Sınırlamalar

2560 px hedefi bir optimum değil, ürün kararı: baskılar daha fazla çözünürlükten yararlanır ve gelecekteki ücretli bir katman sınırı yükseltebilir. Yukarıdaki süreler yaygın durum: yüzlerle dolu fotoğraflar orantılı olarak daha fazla süreyi iyileştirme sınırının kapsamadığı yüz aşamasında geçirir. Dikiş indeksi de istatistiksel bir enstrüman: sınırların ortalamada sessiz olduğunu belgeler, hiçbir düşmanca dokunun bir tanesini asla ortaya çıkaramayacağını değil.