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 iş hacmi (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.

Kontrollü GPU Kıyaslamasını Üretim Kapasitesinden Ayırmak

NVIDIA L40S üzerinde CTranslate2/faster-whisper tabanlı konuşma tanıma çıkarımıyla çalışırken model kıyaslaması ile üretim kapasitesini özellikle ayrı tutuyorum. RTF bu ayrım için yararlı bir ölçüdür:

RTF = T_işleme / T_ses

Örneğin yalnız formülü göstermek amacıyla 60 dakikalık bir referans sesin ölçülen çıkarım aşamasında 3 dakikada işlendiğini varsayalım. Bu sentetik örnekte RTF = 180 / 3600 = 0.05 olur. Buradan 1/RTF = 20 hesaplanabilir; fakat bu değer yirmi eşzamanlı gerçek zamanlı akışın güvenle taşınabileceği anlamına gelmez. Örnek bir üretim metriği değil, RTF'nin neyi ölçtüğünü göstermek içindir.

Gerçek sistem kapasitesinde ses çözme ve yeniden örnekleme, VAD, segmentasyon, kuyruk beklemesi, GPU belleği ve eşzamanlılık politikası, batch/worker seçimi, G/Ç, yeniden deneme ve sonuç birleştirme ayrıca hesaba katılır. Bu yüzden inference-only RTF ile uçtan uca servis gecikmesini aynı grafikte bile ayrı seriler olarak tutmak daha doğru bir ölçüm disiplinidir.

Yeniden üretilebilir, kamuya açık bir kıyaslama en azından donanım modelini, runtime ve model ailesini, compute_type değerini, batch ve eşzamanlılık politikasını, warm-up sürecini, giriş süre dağılımını, segmentasyon yaklaşımını ve p50/p95/p99 değerlerini açıklamalıdır. Üretim iş yükünün gizli olduğu durumlarda gerçek geliş hızı veya operasyonel sayılar yerine kamuya açık ya da sentetik seslerle kontrollü test yayımlamak; hassas bir değeri başka bir kesin sayıyla maskelemekten daha doğru ve doğrulanabilir bir yöntemdir.

Ö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.

Bir kapasite deneyi, dosya adedini ses süresinin yerine kullanmamalıdır. Aynı sayıda dosyadan oluşan iki yükte kayıt süreleri, sessizlik oranları ve segment sayısı farklıysa modelin yaptığı iş de farklıdır. Bu nedenle ölçüm tablosu en azından dosya/saniye, ses saniyesi/saniye, segment/saniye, toplam kuyruk yaşı ve uçtan uca gecikme yüzdeliklerini birlikte tutmalıdır. Isınma, başarısız dosyalar, yeniden denemeler ve kuyrukta deney başlangıcında bekleyen işler açıkça ayrıştırılmadan sürdürülebilir kapasite ilan edilmemelidir.

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.

Sağlıklı bir optimizasyon sırası şöyledir:

ö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.

Kuyruk Kararlılığı ile Kapsam Ayrımı

Bu yazı segmentasyon, worker kapasitesi, CPU/GPU paylaşımı ve uçtan uca gecikme bütçesini birlikte ele alır. λ, μ, ρ ve servis süresi değişkenliğini kuyruk modeli açısından daha ayrıntılı inceleyen çalışma ASR Sistemlerinde Kuyruk Kararlılığı yazısıdır. Kanal/speaker segmentasyonunun zaman çizgisi tarafı ise Stereo Akışlarda Deterministik Konuşmacı Ayrımı içinde ayrıdır.

Uçtan Uca Kapasite Bütçesi ile Kuyruk Kararlılığının Ayrımı

Uçtan uca kapasite bütçesinde segmentasyon, kuyruk, CPU/GPU paylaşımı ve kullanıcıya görünen gecikme aynı hizmet zincirinin parçalarıdır. Geliş ve hizmet hızlarının uzun dönemli kuyruk kararlılığı üzerindeki etkisi ise ASR Sistemlerinde Kuyruk Kararlılığı kapsamında λ, μ, işçi sayısı ve kullanım oranı üzerinden ayrıca ele alınır.

Kaynakça

• Alec Radford; Jong Wook Kim; Tao Xu; Greg Brockman; Christine McLeavey; Ilya Sutskever. Robust Speech Recognition via Large-Scale Weak Supervision. arXiv, 2022. Kaynak

• John D. C. Little. A Proof for the Queuing Formula: L = λW. Operations Research, 1961. DOI

• Max Bain; Jaesung Huh; Tengda Han; Andrew Zisserman. WhisperX: Time-Accurate Speech Transcription of Long-Form Audio. arXiv, 2023. Kaynak

• OpenNMT / CTranslate2. CTranslate2 Performance Tips. CTranslate2. Kaynak

• NVIDIA. NVIDIA L40S GPU. Kaynak

• OpenNMT. CTranslate2 Quantization. Kaynak

• SYSTRAN. faster-whisper: Faster Whisper transcription with CTranslate2. Kaynak