ONNX Runtime'ın 6 MB'lık WASM dosyası, tarayıcı yapay zekâ soğuk başlangıcında 44 MB'lık modeli geride bırakıyor

Küçük bir dosya en uzun bekleyen oldu

Tarayıcı tabanlı bir görüntü işleme hizmeti olan ImgIng'de model yükleme akışından sorumlu bir geliştirici, tarayıcı içi arka plan kaldırma özelliğine ait soğuk başlangıç sürelerini yayımladı. dev.to'da yazdığı yazıda, ilk ziyarette 5,95 MB'lık onnxruntime-web WebAssembly binary'sinin, çalıştırması gereken 44 MB'lık modelden yaklaşık dokuz saniye sonra indirilmeyi bitirdiğini ve dosya gelmeden inference'a başlanamadığını belirtiyor.

Test nasıl yapıldı

Ölçüm 28 Eylül 2026 akşamı, Chromium 149 çalışan ve 16 GB RAM'e sahip bir M4 Mac üzerinde, temiz bir tarayıcı bağlamında alındı. Yazar, arayüzde tıklamak yerine başlat düğmesinin çağırdığı iç segmentasyon fonksiyonunu çalıştırdı ve tüm ağ istekleri ile progress olaylarını kaydetti. Test görüntüsü sentetik bir şişeydi; model tüm girdileri 1024×1024 boyutuna yeniden ölçeklediğinden içeriği süreyi etkilemiyor. İki konfigürasyon ölçüldü: Metal üzerinde WebGPU ve kullanılabilir bir GPU adapter'ı olmayan (donanım hızlandırması kapatıldığında oluşan durum) bir Chromium örneği.

Zaman nereye gitti

WebGPU mevcutken runtime JavaScript 32 ms'de hazırdı. ModelScope CDN'inden gelen 44.279.201 baytlık model 4.188 ms'de indirilmeyi bitirdi ve SHA-256 doğrulaması 4.207 ms'de tamamlandı. Session kurulumu 4.250 ms'de başladı ve onnxruntime-web, ort-wasm-simd-threaded.asyncify.wasm dosyasını (gzip'li 5.955.745 bayt) tam olarak o anda ImgIng'in kendi origin'inden istedi. Bu indirme yaklaşık 13,2 saniyede tamamlandı; inference 13.725 ms'de başladı ve sonuç 14.594 ms'de geldi.

GPU adapter'ı olmadığında şekil aynıydı: WebGPU denemesi başarısız oldu, ORT 13.551 ms'de WASM'a geçiş mesajı kaydetti ve çalıştırma 16.015 ms'de tamamlandı.

İki yapısal detay öne çıkıyor. WASM dosyası yalnızca bir session oluşturulduğunda istendiği için model indirildikten sonra başlıyor ve iki aktarım hiç çakışmıyor. Ayrıca WebGPU yolu da bu dosyaya ihtiyaç duyuyor, çünkü ORT'nin WebGPU execution provider'ı aynı WASM binary'sinin içine derlenmiş durumda — donanım hızlandırması bir siteye bu dosyayı atlatma imkânı vermiyor.

Dosya boyutu sorun değildi

Aynı saatte yapılan dosya başına curl ölçümleri, runtime indirmesini iki denemede 9,19 ve 10,78 saniye, 552 ile 648 KB/s arasında gösterdi. ModelScope'tan gelen 44 MB'lık model ise 4,20 saniyede, yaklaşık 10,5 MB/s hızla indi — bayt başına kabaca 16 ila 19 kat daha hızlı. Yazar bunun sıradan bir ev bağlantısı olduğunu ve diğer bölgelerde ya da saatlerde geçerli olmayabileceğini belirtiyor. Sonraki bir soğuk çalıştırmada runtime +34,2 saniyede, model ise +4,3 saniyede geldi; ancak makine başka işlerle paylaşıldığından yalnızca sıralamaya güveniliyor.

Örüntü, daha ağır profesyonel katmanda da tekrarlanıyor (BEN2 FP16, 219.121.675 bayt): WebGPU ile model +20,5 saniyede, runtime +29,8 saniyede bitti ve çağrının tamamı 34,8 saniye sürdü.

Isınmış cache'ler sorunu ortadan kaldırıyor

Bu asimetri yalnızca ilk ziyarette sorun oluyor. Runtime, Cache-Control: max-age=31536000, immutable başlığıyla sunuluyor ve bir daha hiç istenmiyor; model ise Cache Storage'dan geliyor. Isınmış cache ile çağrının tamamı WebGPU'da 930 ms'de, adapter olmadan 2.643 ms'de tamamlandı.

Neden önemli

Altyapı çabası, maliyetle ters orantılı. Modele bir CDN, bir yedek alan adı ve hash doğrulaması veriliyor; runtime ise sitenin kendi origin'ine yapılan tek bir istek ve geç başlıyor. Yazarın tarayıcı içi inference yayımlayan herkese tavsiyesi somut: soğuk bir yükte Network şelalesini açın, en büyük dosyanın ötesine bakın, .wasm isteğinin ne zaman tetiklendiğini model indirmesiyle karşılaştırın ve kendi origin'inizin bu dosya için gerçekte sunduğu veri aktarım hızını ölçün. Rakamlar iki bariz kola işaret ediyor — runtime'ı model bitmeden önce indirmek ve ona ağırlıklarla karşılaştırılabilir bir CDN muamelesi yapmak — bu da iki sıralı indirmeyi tek indirmeye indirir ve ilk ziyaret cezasının çoğunu ortadan kaldırır.