Gerçek Zamanlı Konuşma Tanımada Kapasite Mühendisliği

Gerçek zamanlı konuşma tanıma sistemlerinde modelin tek başına hızlı olması yeterli değildir. Kullanıcıya görünen gecikme; sesin alınması, konuşma başlangıç/bitiş kararının verilmesi, ön işleme, kuyrukta bekleme, model çıkarımı, sonuç birleştirme ve kalıcılaştırma adımlarının toplamıdır. Kapasite mühendisliği bu zincirin hangi yük altında ne kadar işi sürdürülebilir biçimde tamamlayabildiğini ölçer.

Bu yazı model mimarisini anlatan Whisper notumun tamamlayıcısıdır. Buradaki konu modelin iç yapısından çok RTF, segmentasyon, kuyruk, backpressure, CPU/GPU paylaşımı ve uçtan uca gecikme arasındaki ilişkidir. Örnekler geneldir; kurum içi kapasite, topoloji veya operasyonel veri içermez.

Önce Gecikmeyi Parçalara Ayırmak

Bir konuşma parçasının kullanıcıya sonuç olarak dönmesine kadar geçen süreyi tek sayı olarak ölçmek, darboğazı açıklamaya yetmez. Daha kullanışlı bir ayrım:

L_total =
    L_capture
  + L_endpoint
  + L_preprocess
  + L_queue
  + L_inference
  + L_postprocess
  + L_persist

şeklindedir.

L_endpoint, konuşmanın bittiğine karar vermek için bilerek beklenen süreyi içerir. Model inference'ı 200 ms hızlandırmak, endpointing tarafında 800 ms bekleniyorsa kullanıcı açısından beklenen kazancı üretmeyebilir.

Aynı şekilde L_queue yük arttıkça diğer bileşenlerden çok daha hızlı büyüyebilir. Boş sistemde ölçülen inference süresi ile doygunluğa yaklaşan sistemdeki uçtan uca latency aynı metriği anlatmaz.

RTF Neyi Ölçer?

Real-Time Factor (RTF), medya süresi ile işlem süresini karşılaştırmak için yararlı bir ölçüdür:

RTF = işlem süresi / ses süresi

30 saniyelik ses 3 saniyede işleniyorsa RTF yaklaşık 0.1 olur. Bu, ilgili işin medya süresinden hızlı işlendiğini gösterir.

Ancak şu sonucu vermez:

"Bu makine aynı anda 10 akışı kesin olarak taşır."

Çünkü eşzamanlı yükte CPU ön işleme, GPU belleği, batch davranışı, kuyruklar, disk/ağ I/O ve model worker'ları aynı kaynakları paylaşır. Tek işte ölçülen RTF kapasite için gerekli bir girdidir; kapasitenin kendisi değildir.

Throughput ve Latency Aynı Hedef Değildir

Bir sistemin saniyede kaç saniyelik ses işleyebildiği throughput sorusudur. Tek bir konuşma segmentinin ne kadar sürede sonuçlandığı latency sorusudur.

Batch size büyütmek GPU'nun doluluk oranını artırabilir ve toplam throughput'u yükseltebilir. Buna karşılık ilk öğenin batch'in tamamlanmasını beklemesi gerekiyorsa tek istek gecikmesi büyür.

Offline transkripsiyon sistemi için bu takas kabul edilebilir olabilir. Etkileşimli veya near-real-time bir sistemde aynı ayar kullanıcı deneyimini bozabilir.

Bu nedenle "en hızlı ayar" yerine önce hedef belirlenmelidir:

• minimum tek-segment latency,
• maksimum sürdürülebilir throughput,
• belirli üst yüzdelik gecikme,
• belirli donanımda maksimum eşzamanlı iş.

Segment Uzunluğu Bir Model Parametresi Değil, Sistem Parametresidir

Konuşmayı modele hangi büyüklükte parçalar halinde verdiğiniz kalite ve kapasiteyi birlikte etkiler.

Çok kısa segment:

• daha sık model çağrısı,
• daha fazla scheduling/queue overhead,
• daha az dilsel bağlam,
• kelime sınırlarında kesilme riski

üretebilir.

Çok uzun segment ise:

• kullanıcının sonuç için daha uzun beklemesi,
• daha yüksek geçici bellek,
• batch esnekliğinin azalması,
• hata durumunda daha büyük işin tekrar edilmesi

gibi sonuçlar doğurabilir.

Bu nedenle segmentasyon yalnız ASR doğruluğuna göre ayarlanmamalıdır. Model davranışı, endpoint latency, worker kapasitesi ve kullanıcı beklentisi ortak optimizasyon problemidir.

VAD ve Endpointing Kapasiteyi Nasıl Etkiler?

VAD, modelin konuşma dışı alanlara gereksiz hesaplama harcamasını azaltabilir; fakat agresif kesme transcript kalitesini bozabilir.

Konuşma sonunu doğrulamak için kullanılan hangover süresi arttıkça kelime sonlarını koruma olasılığı yükselir, ancak L_endpoint büyür. Kısa sessizlikleri birleştirmek model çağrı sayısını azaltırken segmentleri uzatabilir.

Bu nedenle VAD ayarlarını yalnız precision/recall ile değil:

• ortalama segment süresi,
• segment/saat oranı,
• endpoint latency,
• ASR kalite metriği,
• model çağrısı sayısı

ile birlikte ölçmek gerekir.

Kendi VAD kütüphanesi geliştirme notumda algoritmik katmanı; burada ise bu kararların sistem kapasitesine etkisini ele alıyorum.

Kuyruk, Little Yasası ve Görünmeyen Gecikme

Kararlı bir sistemde Little yasası:

L = λW

ilişkisini kurar.

Burada L sistemdeki ortalama iş sayısı, λ geliş hızı ve W sistemde geçirilen ortalama süredir. Bu ifade tek başına performans modeli değildir; fakat kuyruk davranışını düşünmek için güçlü bir kontrol sağlar.

Örneğin geliş hızı yükselirken worker kapasitesi aynı kalıyorsa kuyruk derinliğinin ve bekleme süresinin birlikte büyümesi beklenir.

En kritik sınır:

uzun dönem geliş hızı > uzun dönem servis kapasitesi

durumudur. Bu koşul sürdükçe hiçbir queue boyutu sistemi kurtarmaz; yalnız doygunluğu geciktirir.

Kuyruk teorisi, geri basınç ve üst yüzdelik gecikme bu nedenle ASR servisinin modelden bağımsız temel kavramlarıdır.

Backpressure Neden Gerekir?

Kuyruk sınırsız bırakıldığında sistem bir süre "istek kaybetmiyor" gibi görünebilir. Gerçekte:

• bellek kullanımı artar,
• eski işler giderek yaşlanır,
• tail latency büyür,
• timeout alan üst sistem tekrar deneme üretmeye başlayabilir.

Bu durumda kapasite problemi retry fırtınasına dönüşebilir.

Daha güvenli tasarımda kuyruk sınırlandırılır ve doygunluk davranışı açıkça seçilir. İhtiyaca göre üreticinin bekletilmesi, yeni işin reddedilmesi veya düşük öncelikli yükün bırakılması değerlendirilebilir.

Backpressure kapasite üretmez. Sistemin kapasitesinin üstünde yük geldiğini dürüst biçimde görünür hale getirir.

CPU ve GPU Arasındaki Gerçek İş Bölümü

ASR pipeline'ında GPU inference çok hızlı olsa bile bütün iş GPU'da değildir.

CPU tarafında sıklıkla:

• decode,
• resampling,
• kanal işlemleri,
• VAD,
• segment oluşturma,
• sonuç birleştirme,
• serileştirme

çalışır.

GPU'yu hızlandırıp CPU ön işleme aynı kalırsa bir noktadan sonra GPU yeni iş bekleyebilir. Tersi durumda CPU hızlı üretir fakat GPU kuyruğu büyür.

Bu nedenle CPU ve GPU kullanım oranını ayrı ayrı izlemek yeterli değildir. İki katman arasındaki kuyruk ve zaman dağılımı da ölçülmelidir.

CTranslate2, Thread ve Batch Kararları

CTranslate2 gibi inference çalışma zamanları CPU thread'leri, worker sayısı, batch büyüklüğü ve compute_type gibi farklı performans düğmeleri sunar. Bunların etkisi donanıma ve iş yüküne bağlıdır.

CPU'da inter_threads ve intra_threads toplamını fiziksel çekirdek sayısından bağımsız büyütmek contention oluşturabilir. GPU'da daha büyük batch throughput'u artırabilir; ancak latency hedefi varsa her zaman doğru değildir.

Aynı nedenle int8, float16 veya bfloat16 seçimini yalnız model dosya boyutuyla değerlendirmemek gerekir. Donanımın ilgili hesaplama türünü gerçekten verimli yürütmesi, bellek kullanımı ve kalite etkisi birlikte ölçülmelidir.

Worker Sayısı Nasıl Belirlenir?

Worker sayısını CPU çekirdeği veya GPU belleği izin verdiği kadar artırmak güvenilir bir kapasite stratejisi değildir.

Her worker:

• model belleği,
• çalışma alanı,
• input/output buffer,
• thread,
• queue

maliyeti oluşturabilir.

Daha fazla worker ilk aşamada throughput'u artırırken bir noktadan sonra bellek baskısı, context switching veya GPU scheduling nedeniyle kazanç azalabilir.

Doğru nokta deneysel olarak bulunmalıdır. Ölçüm sırasında worker sayısı dışındaki değişkenler sabit tutulmalı ve her adımda:

• throughput,
• p50/p95/p99 latency,
• queue depth,
• CPU/GPU kullanımı,
• bellek,
• hata/timeout

birlikte izlenmelidir.

Ortalama Gecikme Yeterli Değildir

Gerçek zamanlı sistemlerde kullanıcı deneyimini çoğu zaman ortalama değil tail latency bozar.

Örneğin:

p50 = 400 ms
p95 = 900 ms
p99 = 4.5 s

olan sistemin ortalaması makul görünebilir; fakat her yüz işten birinde birkaç saniyelik gecikme oluşması gerçek kullanımda belirgin olabilir.

Bu nedenle performans raporunda yalnız ortalama ve maksimum vermek yerine percentile dağılımı ve ilgili örnek sayısı gösterilmelidir.

Deterministik Zaman Ekseni

Ses işleme pipeline'ında zaman bilgisini her katmanda yeniden kayan noktalı saniyeye dönüştürmek, uzun dosyalarda küçük yuvarlama farklarını biriktirebilir.

Mümkün olduğunda örnek konumu veya integer zaman tabanı ana referans olarak tutulmalı; milisaniye/saniye gösterimi sunum katmanında üretilmelidir.

VAD segmenti, ASR segmenti ve transcript timestamp'leri farklı zaman eksenlerine sahipse dönüştürme noktaları açık olmalıdır. Özellikle stereo kanallar veya resampling içeren sistemlerde bu ayrım önem kazanır.

Hata ve Retry Kapasite Modelinin Parçasıdır

Inference sırasında geçici hata oluştuğunda işi tekrar kuyruğa koymak kolay görünür. Fakat doygunluk nedeniyle oluşan timeout'u tekrar denemek yükü daha da artırabilir.

Retry kararı:

• hatanın geçici olup olmadığı,
• işin idempotentliği,
• toplam zaman bütçesi,
• kuyruk yaşı,
• kalan kullanıcı SLA'sı

ile birlikte verilmelidir.

Bu konu Kritik Sistemlerde Güvenli Retry Tasarımı ile doğrudan ilişkilidir.

Ölçüm Protokolü

Bir ASR kapasite testinde en azından şu koşulları kayıt altına alırım:

1. donanım ve işletim sistemi,
2. model ve çalışma zamanı sürümü,
3. compute_type,
4. worker/thread/batch ayarları,
5. test seslerinin süre dağılımı,
6. segmentasyon/VAD politikası,
7. warm-up uygulanıp uygulanmadığı,
8. test süresi ve örnek sayısı,
9. latency percentile'ları,
10. sürdürülebilir throughput ve queue davranışı.

Bu bilgiler olmadan "RTF 0.05" veya "saniyede 20 istek" gibi tek sayıların başka bir sisteme taşınması zordur.

Sonuç

Gerçek zamanlı ASR kapasitesi model benchmark'ı değildir. Model, segmentasyon, VAD, kuyruk, CPU/GPU paylaşımı, batch, worker sayısı ve failure policy aynı sistemin parçalarıdır.

En sağlıklı optimizasyon sırası benim için değişmiyor:

ölç
→ darboğazı kanıtla
→ tek değişkeni değiştir
→ yeniden ölç
→ yük altında davranışı doğrula

Model daha hızlı hale geldiğinde kazanımın L_total üzerinde gerçekten görünmesi gerekir. Aksi halde yapılan işlem yalnız darboğazı başka bir katmana taşımış olabilir.