Bu belge, Dörtgöz'ün ölçülmüş kapasitesini ve daha büyük kuruluma geçerken
karşılaşılacak ihtiyaçları kaydeder. Rakamlar ölçüm sonuçlarıdır. Ölçüm düzeneği
ve tam tablolar BENCHMARK_REPORT.md içindedir.
UCF-Crime resmî test bölmesi, 290 klip, 10,30 saat video, 1.380 pencere.
⚠ Aşağıda iki farklı yapılandırma vardır. Benimsenen üretim yolu r3'tür: giriş genişliği 540 ve yerel algı GPU'da (§4.2).
| Ölçüt | r1 (720, algı CPU'da) | r4 (540, algı GPU'da) — benimsenen |
|---|---|---|
| Duvar süresi (dört eşzamanlı iş) | 84,7 dk | 54,8 dk |
| Toplam akış hızı | 7,30× | 11,29× gerçek zaman |
| Toplam iş süresi | 18.699 sn | 12.099 sn |
| Uzak model (EVREN) | 15.016 sn | 11.385 sn |
| Yerel algı (SigLIP + D-FINE) | 3.497 sn (%18,7) | 304 sn (%2,5) |
| Tek akış eşdeğeri | 1,98× | 3,07× gerçek zaman |
| Ortanca klip işleme | 36,4 sn | 24,0 sn |
| p95 klip işleme | 185,1 sn | 130,5 sn |
| Terminal hata | — | 0/290 |
Her iki duvar süresi de ölçüldü. r1'den r4'e duvar süresi %35 azaldı. İki bağımsız kazanç birleşti: giriş genişliği 720→540 ve yerel algının GPU'ya taşınması (yerel ayak 3.497→304 sn).
Bir sunucu, dört eşzamanlı iş ile saatte yaklaşık 11,3 saat video işler.
| Kamera sayısı | Düşürülen video | Gecikme (ortanca / en yüksek) |
|---|---|---|
| 25 | 900 sn | 152 sn / 330 sn |
| 9 | 0 | ≤ 18 sn |
Dokuz kamera üretim listesidir. Az kamera daha çok işlenmiş video saati verir. Kapasitenin üstüne çıkmak toplam verimi düşürür, çünkü düşürülen segmentler hiç analiz edilmez.
⚠ Kamera listesi config/live_feeds.json dosyasındadır ve Git'e girmez. Dosya
yoksa sistem config/live_feeds.example.json örneğine düşer. Örnek liste 25
kamera içerir ve yukarıdaki düşürme davranışını yeniden üretir. Kendi
listenizi kapasitenize göre kısaltın.
Benimsenen yapılandırmada (r4: 540, yerel algı GPU'da) 290 klip için toplam iş süresi 12.099 saniyedir.
| Bileşen | Süre | Pay |
|---|---|---|
| Uzak model çağrıları (EVREN) | 11.385 sn | %94,3 |
| D-FINE dedektör (yerel, GPU) | 219 sn | %1,8 |
| SigLIP-2 screening (yerel, GPU) | 85 sn | %0,7 |
| Diğerleri (klip kodlama, hareket profili) | ~388 sn | %3,2 |
vlm çağrısı başına ortalama 6,25 saniyedir (1.821 çağrı).
Yerel algı artık ölçülebilir bir maliyet değildir. GPU taşımasından önce yerel ayak toplamın %18,7'siydi; şimdi %2,5'tir.
Sonuç: darboğaz artık tamamen uzak modeldir. Yerel taraftan alınabilecek en büyük kazanç toplamın %3'üdür. Bundan sonraki her hız işi EVREN çağrılarını azaltmak veya kısaltmak zorundadır.
CPU döneminde (r1) primary:vlm tek başına toplamın %63,3'üydü; GPU taşımasından
sonra uzak çağrıların toplam payı %94'e çıktı.
Rol bazında ortalama çağrı süresi:
| Rol | Çağrı | Ortalama |
|---|---|---|
vlm birincil |
1.329 | 8,90 sn |
llm-large olay-geneli denetim |
164 | 10,16 sn |
llm-fast sınıf hakemi |
120 | 5,29 sn |
llm-large tırmandırma |
91 | 4,76 sn |
llm-large ikinci görüş |
114 | 4,04 sn |
| Ölçüt | Değer |
|---|---|
| Prompt token (toplam) | 17.616.342 |
| Tamamlama token (toplam) | 429.845 |
| Ortalama prompt | 11.976 token/çağrı |
| Ortalama tamamlama | 292 token/çağrı |
| Etkin tamamlama hızı | ~32 token/sn |
Prompt token sayısı tamamlama token sayısının kırk katıdır. Maliyet modeli kurarken bu oran belirleyicidir. Etkin hız video kodlama ve paylaşımlı kuyruk süresini içerir; saf üretim hızı değildir.
max_inflight değeri 4'ten 8'e çıkarıldığında koşu %20 yavaşladı. Sebep
istemci tarafında değildir: uç, tüm takımlar arasında paylaşımlı bir FIFO kuyruk
kullanır. Daha çok eşzamanlı istek kuyrukta daha uzun beklemek demektir.
Sonuç. Eşzamanlılığı artırmak bu mimaride kapasite artırmaz. Kapasite artışı ya ayrılmış (dedicated) uç ya da daha az çağrı ister.
İhtiyaç. Çok kuruluma geçilecekse her kurulum kendi çıkarım kotasına sahip olmalıdır. Ortak kuyruk üstünde kurulum sayısı doğrusal ölçeklenmez.
Olaysız pencere kısa çıktı üretir ve ucuzdur. Olaylı pencere uzun çıktı üretir. İki uç ölçüldü:
| Kayıt tipi | Maliyet | Gerçek zaman katı |
|---|---|---|
| UCF-Crime (%100 olaylı, en kötü durum) | 27 GPU-sn/dk | 2,2× |
| Gerçekçi gözetim kaydı (%84 ölü görüntü) | 4,8 GPU-sn/dk | 12,2× |
Sonuç. Kapasite planı sahnenin olay yoğunluğuna göre yapılmalıdır. Sakin bir sahada bir sunucu çok daha fazla kamera taşır.
SigLIP ve D-FINE aynı makinede çalışır. Eşzamanlı yerel çıkarım
DORTGOZ_LOCAL_INFERENCE_LIMIT ile sınırlıdır (varsayılan 2). Bu sınır
kaldırılırsa CPU doygunluğu uzak çağrıların hazırlanmasını da geciktirir.
| Kalem | Ölçü |
|---|---|
| Canlı segment (ortanca) | ~1,7 MB |
| Dokuz kamera segment üretimi | ~480 segment/saat |
| Kaba segment akışı | ~0,8 GB/saat |
Segmentler saklanmaz. Tampon yalnız üç segment (yaklaşık 90 saniye) tutar. Olay açılınca kanıt klibi ayrıca kesilir ve saklanır. Bu karar bilinçlidir: tüm segmentleri saklamak saatler içinde gigabaytlara çıkar, kanıt klibi ise yalnız olay süresi kadardır.
İhtiyaç. Uzun süreli saklama isteniyorsa ayrı bir nesne deposu ve saklama politikası gerekir. Bugünkü tasarım kanıt saklar, ham akış saklamaz.
Olay deposu SQLite'tır. Tek yazıcı süreç varsayımıyla çalışır. Çok sunuculu kuruluma geçilirse bu bileşen değişmelidir.
Yerel VLM artık üretim yolu değildir. Aşağıdaki değerler yerel bir kuruluma dönülürse geçerlidir.
- 16 GB kartta gerçek sınır GTT taşma uçurumudur: ~16.050-16.100 MiB toplam.
- Aşımda çökme olmaz, prompt işleme %79 düşer.
- Pratik bütçe ~15.400 MiB'dir.
Yerel algı katmanı MIGraphX 2.15 (ROCm 7.2.3, gfx1201, MIT lisans) ile GPU'ya
taşındı. ONNX Runtime'da ROCm sağlayıcı wheel'i yoktur; çözüm libmigraphx_c.so
üzerine bir ctypes sarıcıdır (pipeline/migraphx_ep.py). EVREN çağrıları
değişmedi.
| Aşama | CPU | GPU | Kazanç | Sayısal denklik |
|---|---|---|---|---|
| SigLIP fp16, batch 16 | 1.936 ms | 9,7 ms | 202× | kosinüs 0,999988 |
| D-FINE fp32, batch 4 | 172 ms/kare | 12,3 ms/kare | 14× | 0,40 eşiğinde tespitler birebir |
Boru hattı içinde ölçülen gerçek kazanç (31 klip × 3 tekrar):
| Bileşen | CPU | GPU | Kazanç |
|---|---|---|---|
| SigLIP | 142,0 sn | 16,1 sn | 8,8× |
| D-FINE | 69,3 sn | 21,2 sn | 3,3× |
Tam bölmede (290 klip) kazanç daha da büyüktür, çünkü batch-16 fp16 daha uzun korpusta daha iyi amorti olur:
| Bileşen | r1 (CPU) | r4 (GPU) | Kazanç |
|---|---|---|---|
| SigLIP | 2.613,5 sn | 85,2 sn | 30,7× |
| D-FINE | 883,5 sn | 219,1 sn | 4,0× |
| Yerel toplam | 3.497,0 sn | 304,3 sn | 11,5× |
Bu değerler benimsenen üretim yapılandırmasının içindedir. §1'deki r4 sütunu GPU yolunu zaten kullanır.
⚠ Yalıtılmış çekirdek hızından boru hattı kazancı çıkarmayın. 202× mikro ölçüm boru hattında 8,8× olur, çünkü sayacın içinde ffmpeg kare çıkarma da vardır. Bu taşımadan sonra yerel algının tabanı ffmpeg'dir, model değildir.
D-FINE fp16 reddedildi. Aynı karede 0,40 eşiğinde 11 yerine 12 tespit üretti.
Kalite bandı. CPU üç tekrar 22/22/22 yakalama. GPU üç tekrar 21/22/22. Her iki kolda 0/5 yanlış alarm ve aynı sabit kaçırma çekirdeği. Fark, belgelenmiş EVREN örnekleme varyansı (±3 klip) içindedir. Bantlar örtüşür; özdeşlik iddia edilmez.
Kurulum. Derleme tek seferliktir (D-FINE ~5,6 dk, SigLIP ~1,5 dk) ve .mxr
olarak diske yazılır. scripts/build_migraphx.sh yeniden üretir. Artifact'lar
~/.cache/dortgoz/migraphx/ altındadır (94-416 MB, repo dışı).
Adım adım açma yordamı ve ayar değişkenleri: SETUP.md §3.4.
Bütünlük. Manifest kaynak ONNX'in SHA-256 değerini tutar. Kaynak değişirse GPU
yolu kapanır ve sistem CPU'ya döner. DORTGOZ_MIGRAPHX_DIR boşsa GPU yolu
kapalıdır, böylece GPU'suz makineler etkilenmez.
NVIDIA tarafı (ayrı yol). Dizüstünde DORTGOZ_ONNX_PROVIDERS=CUDAExecutionProvider
kullanılabilir. Bu yolun uçtan uca kazancı yalnız %7-10'dur ve MIGraphX yolunun
yerini tutmaz. GPU sağlayıcısı açıkken backend yaklaşık 2,3 GB VRAM tutar.
Algı katmanı CPU/ONNX üzerinde çalışır. Operatör konsolunu çalıştıran makinede GPU gerekmez. Bu, ekip üyelerinin GPU'suz dizüstülerde tam sistemi koşabilmesini sağlar.
Aşağıdaki liste, bugünkü tek sunuculu kurulumdan daha büyük bir kuruluma geçmek için gereken işleri önem sırasıyla verir.
- Ayrılmış çıkarım kapasitesi. Paylaşımlı kuyruk üstünde eşzamanlılık artırmak ters teper. Her kurulum kendi kotasına sahip olmalıdır.
- Olay deposunun değişmesi. SQLite tek yazıcı varsayar. Çok sunuculu kurulumda PostgreSQL veya eşdeğeri gerekir. Depo katmanı protokol arkasında olduğu için değişim yalıtılmıştır.
- Nöbet kuyruğunun kalıcı olması. Bugün kuyruk bellektedir. Backend yeniden başlayınca karar verilmemiş kayıtlar silinir. Karara bağlanmış kayıtlar canonical deftere yazıldığı için korunur.
- Kamera başına kapasite planı. Sahnenin olay yoğunluğu maliyeti dört kattan fazla değiştirir. Kamera sayısı ölçülerek belirlenmelidir, varsayılarak değil.
- Saklama politikası. Kanıt klibi saklanır, ham segment saklanmaz. Daha uzun saklama isteniyorsa ayrı depo ve silme politikası gerekir.
- Kamera başına kalibrasyon verisi. Güven kalibrasyonu için kamera başına yaklaşık 20 etiket gerekir. Bu veri bugün yalnız toplam düzeyde vardır.
Dürüstlük için: aşağıdaki konular ölçülmemiştir ve rakam verilemez.
- Yüzden fazla kameralı kurulum hiç denenmedi.
- Çok sunuculu koordinasyon hiç denenmedi.
- Uzun süreli (günlerce) kesintisiz canlı koşu hiç denenmedi. En uzun ölçülen canlı koşu saatler mertebesindedir.
- Ağ kesintisi altında uzak uç davranışı ölçülmedi.