Video Analitik için GPU Sunucu Boyutlandırma: Akış, FPS ve Model

Sunucu tabanlı video analitikte en pahalı hata, GPU kapasitesini broşürdeki “sunucu başına N kamera” değerine göre almaktır. Gerçek kapasiteyi akış sayısı, çözünürlük, codec, analiz kare hızı, model karmaşıklığı ve aynı sunucuda çalışan diğer servisler birlikte belirler. Broşür bunların hiçbirini sizin sahanıza göre bilmez. GPU sunucu video analitik boyutlandırmasında hangi değişkenlere baktığımızı, örnek bir hesabı, pilotla ölçüm yöntemini ve yedekli tasarımı aşağıda sırayla veriyoruz.

Edge mi sunucu mu kararı burada konu dışı; o karşılaştırma edge analitik mi sunucu tabanlı analitik mi yazısında. Aşağıdaki her şey sunucu tabanlı mimarinin seçildiğini varsayar.

Kapasiteyi belirleyen değişkenler

Analitik sunucusunda her kamera akışı şu zincirden geçer: RTSP alımı ve ayrıştırma, video çözme (decode), ölçekleme ve renk dönüşümü, model çıkarımı (inference), izleme (tracking), kural değerlendirme ve meta veri ile olay yazımı. Darboğaz bu halkalardan herhangi birinde oluşabilir. En zayıf halka kapasiteyi belirler.

Değişken	Etkilediği kaynak	Not
Akış sayısı	Tümü	Doğrusal artış varsayımı pilotla doğrulanmalı
Çözünürlük ve codec	Donanım çözücü, GPU belleği	H.265 desteği GPU nesline bağlıdır
Kamera kare hızı	Donanım çözücü	Analiz hızından bağımsız olarak çözülür
Analiz kare hızı	GPU hesaplama	Kural türüne göre belirlenir
Model ve giriş boyutu	GPU hesaplama, bellek	Birden çok model zinciri yükü çarpar
İzleme ve kurallar	CPU	Kalabalık sahnede artar
Meta veri ve olay yazımı	Disk, veritabanı	Nitelik araması açıksa belirgin

Video çözme yükü

Boyutlandırma çalışmalarının çoğu model çıkarımına odaklanır ve video çözmeyi atlar. Oysa kalabalık kurulumlarda ilk dolan kaynak çoğu zaman donanım video çözücüsüdür. NVIDIA GPU’larda bu iş, hesaplama çekirdeklerinden ayrı NVDEC birimleriyle yapılır; NVDEC sayısı ve desteklenen codec’ler GPU modeline göre değişir. Güncel bilgi için NVIDIA’nın video encode/decode GPU destek matrisi kontrol edilmelidir.

Decode yükü kabaca saniyede çözülen piksel sayısıyla orantılıdır. Örnek hesap (64 kamera):

• Ana akış 1920 × 1080, 25 kare/s: 64 × 1920 × 1080 × 25 ≈ 3,3 milyar piksel/s.
• Alt akış 1280 × 720, 10 kare/s: 64 × 1280 × 720 × 10 ≈ 0,59 milyar piksel/s.

Fark beş kattan fazla. Model girişi zaten küçükse (örneğin 640 piksel genişlik), ana akışı çözüp küçültmek kapasiteyi boşa harcar. Analitik için ayrı bir akış profili tanımlamak çoğu projede en etkili optimizasyondur; profil kurgusunu kamera çoklu akış ve stream profilleri yazısında anlattık. Bir sınır var: alt akış çözünürlüğü, uzak hedeflerin piksel boyutunu analitik için yetersiz bırakmamalı.

Sahada sık atlanan bir ayrıntı daha: H.264 ve H.265’te ara kareler önceki karelere referans verir. Analiz saniyede 5 kare kullansa bile çözücü genellikle akıştaki tüm kareleri çözmek zorundadır. Decode hesabına analiz kare hızını değil, kameranın gönderdiği kare hızını yazın. Codec farklarının işlem yüküne etkisi H.265 ve H.264 kayıt performansı yazısında.

Analiz FPS’i ve model karmaşıklığı

Çıkarım yükü, saniyedeki toplam çıkarım sayısı ile model başına maliyetin çarpımıdır. 64 kamera, kamera başına 5 analiz karesiyle saniyede 320 çıkarım eder. Bu değeri büyüten üç etken vardır:

• Model zinciri: Önce kişi tespiti, ardından her kişi için baret/yelek sınıflandırması yapan bir KKD analitiğinde ikinci modelin yükü sahnedeki kişi sayısıyla artar. Boş sahnede hafif, vardiya değişiminde ağır çalışan bir sistemi ortalamaya göre değil, en yoğun ana göre boyutlandırın.
• Giriş boyutu: Uzak hedefler için giriş boyutunu büyütmek veya görüntüyü karolara bölmek, çıkarım maliyetini kabaca piksel sayısıyla orantılı artırır.
• Analiz hızı: Sanal çit gibi yavaş olaylar düşük analiz hızıyla çalışır; hızlı araçlar ve yakınlık uyarıları daha yüksek hız ister. Tüm kameralara aynı analiz hızını vermek yerine kural türüne göre profil tanımlayın.

GPU belleği ayrı bir sınırdır: Her akış için çözücü tamponları, model ağırlıkları ve toplu işleme tamponları bellekte yer tutar. Hesaplama kapasitesi yeterken bellek dolarsa yeni akış eklenemez. Kullanım grafiği yeşil görünür, akış yine de açılmaz.

Örnek boyutlandırma hesabı

Aşağıdaki değerler yöntemi göstermek için kurgulanmıştır; gerçek değerler kullanılan GPU, model ve yazılımla pilotta ölçülmelidir. Hedef: 64 kamera, alt akış 1280 × 720 / 10 kare/s, analiz hızı 5 kare/s, kişi ve araç tespiti.

1. Pilot ölçümü: Tek GPU’lu sunucuda gerçek kameralardan 16 akış çalıştırılır. Yoğun saatte ölçülen değerler: GPU hesaplama kullanımı ortalama %45, NVDEC kullanımı %30, GPU belleği 24 GB’ın 9 GB’ı.
2. Hedef kullanım: Ani yükler ve büyüme için her kaynakta en fazla %70 kullanım hedeflenir.
3. Kaynak başına tahmini akış sınırı (doğrusal varsayım): hesaplama 16 × 70 / 45 ≈ 24; çözücü 16 × 70 / 30 ≈ 37; bellek 16 × (0,7 × 24) / 9 ≈ 29. Darboğaz hesaplama, GPU başına yaklaşık 24 akış.
4. GPU sayısı: 64 / 24 ≈ 2,7, yani en az 3 GPU.
5. Doğrulama: Doğrusal varsayım, toplu işleme ve bellek davranışı nedeniyle her zaman tutmaz. 24 akışla ikinci bir ölçüm yapılır ve tahmin doğrulanır.

Ağ tarafını da hesaba katın: Alt akış başına örneğin 1,5 Mbit/s varsayılırsa 64 akış yaklaşık 96 Mbit/s sürekli alım demektir. Analitik sunucusu kayıt sunucusundan ayrıysa her kamera aynı anda iki istemciye akış gönderir. Bazı kameralar eşzamanlı akış sayısını sınırlar; ikinci bağlantı reddedilir veya mevcut akışın ayarları değişir. Kamera tarafındaki bu sınırı ve ağ yükünü kurulumdan önce kontrol edin.

Pilot ile ölçüm yöntemi

Pilotu, gerçek sahadan seçilmiş ve sahne çeşitliliğini temsil eden kameralarla, üretimde kullanılacak yazılım sürümü ve kural setiyle yapın. Ölçüm en az bir tam gün sürmeli ve yoğun saatleri içermelidir. NVIDIA GPU’larda temel ölçümler nvidia-smi ile alınır:

# GPU hesaplama (sm), bellek, encoder ve decoder kullanımı; 5 sn aralıkla
nvidia-smi dmon -s u -d 5

# Bellek ve sıcaklık; CSV olarak kayda alınabilir
nvidia-smi --query-gpu=timestamp,index,utilization.gpu,memory.used,memory.total,temperature.gpu \
  --format=csv -l 5 >> gpu_pilot.csv

Tek bir akışın donanımla çözülüp çözülemediğini ve gerçek kare hızını FFmpeg ile hızlıca deneyebilirsiniz (FFmpeg’in CUDA desteğiyle derlenmiş olması gerekir; RTSP yolu üreticiye göre değişir):

ffmpeg -hide_banner -hwaccel cuda -rtsp_transport tcp \
  -i "rtsp://kullanici:parola@10.20.30.11:554/<alt-akis-yolu>" \
  -t 60 -f null -

Ölçüm sırasında yalnız GPU’ya bakmayın. Şunları da kaydedin: CPU kullanımı, analitik yazılımının raporladığı işlenen kare hızı ve atlanan kareler, olay üretim gecikmesi (olay anı ile alarmın VMS’e düşmesi arasındaki süre), meta veri veritabanının disk yazma hızı. GPU kullanımı düşükken kare atlanıyorsa darboğaz CPU’da, ağda veya yazılımın kuyruk ayarlarındadır. Konsolda ilk bakılacak yer atlanan kare sayacıdır.

Ölçeklenme ve yedeklilik

Kurumsal video analitik sistemlerinde analitik sunucusu arızalandığında kayıt devam eder, alarmlar durur. Kimse fark etmeyebilir. Çevre güvenliği veya iş güvenliği uyarısı gibi senaryolarda bu kabul edilemez. Yedeklilik kararını tek soruyla verin: bir sunucu kaybedilince kalan kapasite tüm kameralara yetiyor mu? Yukarıdaki örnekte GPU başına 24 akış kabul edilirse:

Tasarım	Toplam kapasite	Bir sunucu kaybında	64 kamera için
2 sunucu × 2 GPU	96 akış	48 akış	Yetersiz
2 sunucu × 3 GPU	144 akış	72 akış	Yeterli
3 sunucu × 2 GPU	144 akış	96 akış	Yeterli, büyüme payı var

Arıza anında akışların hangi sunucuya taşınacağı analitik yazılımının yeteneğine bağlıdır: Bazı platformlar otomatik yeniden dağıtım yapar, bazılarında yedek sunucuya manuel atama gerekir. Kural ve bölge yapılandırmalarının yedek sunucuda da güncel olduğunu düzenli olarak doğrulayın; eski kural setiyle ayağa kalkan yedek, yanlış alarm üretir. VMS tarafındaki failover kurgusu VMS yüksek erişilebilirlik ve N+1 tasarımı yazısında; analitik sunucularını bu kurguya dahil edin. NVIDIA ekosistemi kullanılıyorsa DeepStream geliştirici kılavuzu toplu işleme ve çoklu akış ayarları için birincil kaynaktır.

Sık yapılan hatalar

• Ana akışla analiz: Model girişi küçükken 4K veya 1080p ana akışı çözmek, decode kapasitesini gereksiz tüketir.
• Ortalama yükle boyutlandırma: Gece boş sahnede ölçülen değerle yapılan hesap, vardiya değişiminde kare atlamasına yol açar.
• Belleği unutmak: Hesaplama kapasitesi yeterli görünürken GPU belleği dolar ve yeni akış eklenemez.
• Tüketici GPU’larını veri merkezi ürünü gibi değerlendirmek: Sürekli çalışma, soğutma, sürücü lisans koşulları ve sanallaştırma desteği açısından üreticinin koşullarını kontrol edin.
• Termal sınırlar: Yoğun GPU’lar kabinde ısı üretir; sıcaklık nedeniyle saat hızı düşerse kapasite pilot değerinin altına iner. Kışın yapılan pilot, yazın yanıltır.
• Büyüme payı bırakmamak: Yeni kural, ek model veya kamera eklendiğinde kapasite yetersiz kalır; yüzde 70 civarı hedef kullanım bu payı bırakır.

Sunucu boyutlandırması, analitik yazılımı seçimi ve kural kurulumu AI video analitik kurulumu kapsamında; analitiğin VMS ile entegrasyonu ve sunucu mimarisi ise kurumsal VMS platformları çalışmasıyla birlikte planlanabilir.

Sık sorulan sorular

Üretici benchmark’ındaki akış sayısı neden sahada tutmaz?

Benchmark genellikle belirli bir model, giriş boyutu, toplu işleme (batch) ayarı ve çoğu zaman yerel dosyadan okunan video ile ölçülür. Sahada RTSP alımı, farklı codec ve çözünürlükler, izleyici ve kural motoru, meta veri yazımı ve diğer servisler aynı kaynağı paylaşır. Benchmark’ı kaba bir üst sınır olarak kullanın; boyutlandırmayı pilot ölçümüyle yapın.

Analizi saniyede 5 kareye düşürmek decode yükünü de azaltır mı?

Genellikle doğrudan azaltmaz. H.264 ve H.265 akışlarında ara kareler önceki karelere bağlıdır; analiz yalnız bazı kareleri kullansa da çözücü çoğu durumda tüm kareleri çözmek zorundadır. Decode yükünü düşürmenin yolu, kameradan daha düşük çözünürlüklü ve daha düşük kare hızlı bir alt akış almaktır.

GPU yerine CPU ile video analitik yapılabilir mi?

Az sayıda kamerada ve hafif modellerde mümkündür. Hem video çözme hem çıkarım CPU’da yapıldığında akış başına maliyet hızla artar. CPU tabanlı bir tasarım düşünüyorsanız aynı pilot ölçüm yöntemini CPU kullanımı ve gecikme üzerinden uygulayın.

GPU sunucusu VMS kayıt sunucusuyla aynı makine olabilir mi?

Küçük kurulumlarda olabilir. Ancak analitik yükündeki ani artışların kayıt sürekliliğini etkilememesi için kaynakları ayırmak tercih edilir. Kayıt ve analitik aynı sunucudaysa kayıt servisine öncelik verin ve yük testinde disk yazma performansını da izleyin.