ASR Sistemlerinde Kuyruk Kararlılığı

ASR Sistemlerinde Kuyruk Kararlılığı

ASR sistemlerinde RTF değerinin neden tek başına kapasite ve gecikmeyi açıklamadığını inceler. Kuyruk kararlılığı, segment süresi, batch, heterojen sunucu yönlendirme, backpressure ve p99 ölçümleri ele alınır.

Bir otomatik konuşma tanıma sisteminin performansı çoğu zaman gerçek zaman katsayısı ile ifade edilir:

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

On saniyelik bir ses bir saniyede çözümleniyorsa:

RTF = 1 / 10 = 0,1

olur. Bu değer, modelin sesin gerçek akış hızından on kat daha hızlı çalıştığını gösterir. Ancak tek başına sistemin gerçek zamanlı, düşük gecikmeli veya yüksek trafikte kararlı olduğunu göstermez.

Bir ASR sunucusu aynı anda çok sayıda ses kaynağından veri alıyorsa temel problem yalnızca modelin ne kadar hızlı çıkarım yaptığı değildir. İşlerin hangi hızla geldiği, segmentlerin uzunluk dağılımı, batch politikası, CPU ve GPU kaynaklarının paylaşımı, kuyruk sırası ve hata sonrası yeniden işleme davranışı birlikte değerlendirilmelidir.

Model düzeyinde çok düşük görünen bir RTF, sistem düzeyinde saniyeler veya dakikalar süren kuyruk gecikmesiyle birlikte bulunabilir. Bunun nedeni, RTF'nin yalnızca servis süresini ölçmesi; işin servis başlamadan önce ne kadar beklediğini ölçmemesidir.

toplam gecikme = segmentin oluşma süresi + kuyrukta bekleme + ön işleme + model çıkarımı + son işleme + yayınlama

Gerçek zamanlı ASR kapasitesi, bu bileşenlerin tek tek hızından değil, bütün hattın kararlı çalışma bölgesinde kalmasından doğar.

Model hızı ile sistem kapasitesinin ayrılması

Bir ASR işinin ses süresi D, model servis süresi S olsun. RTF tanımı:

RTF = S / D

şeklindedir. Buradan teorik olarak tek bir worker'ın birim zamanda işleyebileceği ses süresi:

kapasite = 1 / RTF

olarak düşünülebilir.

Örneğin:

RTF = 0,2

ise bir saniyelik işlem süresinde yaklaşık beş saniyelik ses çözümlenebilir. Sistem kesintisiz biçimde aynı özellikte ses alıyor ve başka hiçbir maliyet bulunmuyorsa tek worker yaklaşık beş eşzamanlı gerçek zamanlı akışı taşıyabilir.

Fakat bu sonuç birkaç güçlü varsayıma dayanır:

Her işin RTF değeri aynıdır.

Ön işleme ve son işleme maliyeti yoktur.

Model yükleme veya ısınma gecikmesi bulunmaz.

Worker hiçbir zaman boş kalmaz.

İşler arasında context switch veya veri kopyalama maliyeti yoktur.

Segmentler hazır oldukları anda işlenebilir.

GPU veya CPU başka işlerle paylaşılmaz.

Bellek ve I/O darboğazı oluşmaz.

Gerçek sistemlerde servis süresi daha doğru biçimde şöyle modellenmelidir:

S = Sdecode + Sresample + Sfeature + Sinference + Spost

Burada:

Sdecode, medya çözme süresidir.

Sresample, örnekleme hızı veya kanal dönüşümüdür.

Sfeature, mel spektrogram gibi model girdilerinin hazırlanmasıdır.

Sinference, model çıkarımıdır.

Spost, zaman damgası, metin ve çıktı biçimlendirme maliyetidir.

Model RTF'si yalnızca Sinference / D üzerinden ölçülmüşse gerçek servis RTF'si daha yüksektir:

RTFsystem = S / D

Ayrıca segment süresi ile servis süresi her zaman doğrusal değildir. Üç saniyelik bir segment ile otuz saniyelik bir segment arasındaki çıkarım maliyeti tam olarak on kat olmayabilir. Sabit kurulum maliyetleri kısa segmentlerde baskın hâle gelir:

S(D) = A + B(D)

A, segment uzunluğundan bağımsız sabit maliyeti; B(D) ise ses süresine bağlı işlem maliyetini gösterir.

Bu nedenle kısa segmentlerde gözlenen RTF genellikle uzun segmentlerden daha kötü olabilir:

RTF(D) = A / D + B(D) / D

D küçüldükçe A / D büyür. Çok küçük segmentler düşük kullanıcı gecikmesi sağlıyor gibi görünse de toplam throughput'u düşürebilir.

Kuyruk kararlılığının temel koşulu

ASR işlerinin sisteme geliş hızı λ, bir worker'ın ortalama servis hızı μ olsun. Tek worker için kullanım oranı:

ρ = λ / μ

şeklindedir.

Sistem kararlılığı için temel koşul:

ρ < 1

olmalıdır.

ρ = 1, kapasitenin tam kullanıldığı anlamına gelir; fakat güvenli çalışma noktası değildir. Servis süreleri ve geliş aralıkları değişkense kısa süreli yoğunluklar kuyruk oluşturur. Ortalama kapasite talebe eşit olduğunda sistemin bu dalgalanmaları eritmek için boş kapasitesi kalmaz.

Çok worker bulunan bir yapıda yaklaşık kullanım oranı:

ρ = λ / (cμ)

olarak yazılabilir. Burada c, eşzamanlı worker sayısıdır.

ASR sisteminde λ yalnızca saniyedeki dosya sayısı olarak ele alınmamalıdır. Üç saniyelik ve otuz saniyelik segmentler aynı iş sayısını oluşturabilir, fakat aynı yükü üretmez. Daha anlamlı geliş yükü, birim zamanda gelen ses süresidir:

λaudio = gelen toplam ses süresi / zaman

Bir saniyede toplam sekiz saniyelik ses geliyorsa:

λaudio = 8

eşzamanlı gerçek zaman akışına denk bir yük vardır.

Bir worker'ın sürdürülebilir ses kapasitesi yaklaşık:

μaudio = 1 / RTFsystem

ise c worker için kararlılık koşulu:

λaudio × RTFsystem < c

şeklinde ifade edilebilir.

Ancak gerçek kapasite sınırında çalışmak doğru değildir. Örneğin:

λaudio × RTFsystem = 0,95c

ortalama kullanımın yüzde 95 olduğu anlamına gelir. Küçük bir RTF artışı, uzun segment yoğunluğu, disk gecikmesi veya yeniden deneme trafiği kuyruğu hızla büyütebilir.

Düşük gecikmeli kritik sistemlerde hedef kapasite, teorik maksimumun altında tutulmalıdır. Kesin güvenlik payı iş yüküne bağlıdır; evrensel bir yüzde yoktur. Belirleyici olan, ölçülen p95 ve p99 servis süreleri altında kuyruğun büyüyüp büyümediğidir.

Ortalama RTF neden yanıltıcıdır?

İki sistemin ortalama RTF değeri aynı olabilir, fakat gecikme davranışları bütünüyle farklı olabilir.

Birinci sistemin servis süreleri kararlı olsun:

0,09 0,10 0,10 0,11 0,10

İkinci sistemin değerleri ise:

0,02 0,03 0,04 0,06 0,55

olsun.

Her iki dağılımın ortalaması benzer olabilir. Ancak ikinci sistemde ara sıra oluşan yüksek servis süresi, arkasındaki bütün işleri bekletir. Tek worker ve FIFO kuyrukta uzun süren bir iş, kendisinden sonra gelen kısa segmentlerde head-of-line blocking oluşturur.

Kuyruk gecikmesi yalnızca ortalama servis süresine değil, servis süresinin değişkenliğine de duyarlıdır. Genel olarak servis sürelerinin varyansı büyüdükçe aynı ortalama yük altında bekleme süresi artar.

Bu nedenle ASR performansında yalnızca:

ortalama RTF

değil, en azından şu değerler izlenmelidir:

RTF p50 RTF p95 RTF p99 maksimum RTF segment süresi dağılımı kuyruk bekleme süresi p95 ve p99

RTF değerinin segment süresine göre gruplanması da önemlidir:

0-3 saniye 3-10 saniye 10-20 saniye 20-30 saniye

Aksi durumda uzun segmentlerin iyi RTF'si, kısa segmentlerdeki yüksek sabit maliyeti gizleyebilir.

Ortalama kuyruk uzunluğu ile ortalama bekleme süresi arasında Little yasası olarak bilinen ilişki bulunur:

L = λW

Burada:

L, sistemdeki ortalama iş sayısıdır.

λ, tamamlanan veya kararlı durumda gelen iş hızıdır.

W, bir işin sistemde geçirdiği ortalama süredir.

Örneğin saniyede iki segment gelen kararlı bir sistemde ortalama on segment bulunuyorsa:

W = L / λ = 10 / 2 = 5 saniye

olur.

Bu süre yalnızca model çıkarımı değildir; kuyrukta bekleme dâhil sistemde geçirilen toplam zamandır. RTF değeri çok düşük olsa bile kuyruk uzunluğu büyüyorsa uçtan uca gecikme yüksek kalır.

Segmentasyon politikası kapasiteyi nasıl değiştirir?

ASR modeli ham ve kesintisiz ses akışını değil, VAD veya başka bir yöntemle oluşturulmuş segmentleri işliyorsa kapasite segmentasyon politikasıyla doğrudan bağlantılıdır.

Çok kısa segmentlerin olumsuz etkileri şunlardır:

Her segment için sabit hazırlık maliyeti yeniden ödenir.

GPU kernel çağrı sayısı artar.

Kuyruk ve görev nesnesi sayısı büyür.

Dosya veya JSON çıktı sayısı artar.

ASR bağlamı parçalanır.

Kısa ve anlamsız sesler modele gönderilebilir.

Çok uzun segmentlerin etkileri ise farklıdır:

Tek işin servis süresi büyür.

Head-of-line blocking artar.

İlk metnin kullanıcıya ulaşması gecikir.

Hata durumunda daha fazla ses yeniden işlenir.

GPU bellek tüketimi ve ara tensor boyutları büyüyebilir.

Worker başına zaman dilimi tek iş tarafından uzun süre tutulur.

Bu nedenle hedef segment süresi ile sert üst sınır ayrı kavramlar olarak ele alınmalıdır. Hedef süre, doğal sessizlik bulunduğunda segmentin kapatılmak istendiği noktadır. Sert sınır ise konuşma kesintisiz sürse bile iş boyutunu belirli bir üst değerde tutar.

Örneğin yaklaşık 25 saniyelik hedef ve 29 saniyelik sert sınır kullanılan bir sistemde amaç bütün segmentleri 29 saniye yapmak değildir. Segmentler doğal konuşma sonlarında daha erken kapanabilir; fakat hiçbir işin sınırsız büyümesine izin verilmez.

Kuyruklama açısından sert üst sınır, maksimum servis süresine dolaylı bir sınır getirir:

Smax ≈ S(Dmax)

Bu ilişki kesin olmayabilir; donanım gecikmeleri ve model davranışı değişebilir. Yine de segment uzunluğunun sınırlandırılması, servis süresi dağılımının kuyruğunu daraltır ve p99 gecikmesini daha öngörülebilir hâle getirir.

Minimum segment süresi de benzer biçimde kapasite özelliğidir. Bir saniyeden kısa VAD etkinliklerinin elenmesi, gürültü kaynaklı binlerce küçük model çağrısını önleyebilir. Model en az üç saniyelik giriş gerektiriyorsa geçerli kısa konuşma sessizlikle tamamlanabilir; ancak padding süresi gerçek ses yükü gibi değerlendirilmemelidir.

Batch throughput'u artırırken gecikmeyi büyütebilir

GPU tabanlı çıkarımda birden fazla segmenti batch içinde işlemek toplam throughput'u artırabilir. Ancak batch oluşturmak için işlerin birikmesi gerekir.

Batch bekleme süresi Bwait, çıkarım süresi Binfer olsun:

Tbatch = Bwait + Binfer

Tek tek çıkarım:

Tsingle = Sinfer

değerinden daha yavaş görünse bile batch başına iş sayısı nedeniyle toplam throughput daha yüksek olabilir.

Buradaki temel karşıtlık şudur:

büyük batch → yüksek throughput küçük batch → düşük kuyruk gecikmesi

Gerçek zamanlı sistemlerde sabit batch boyutunun dolmasını sınırsız beklemek uygun değildir. Daha güvenli politika iki sınırı birlikte kullanır:

batch dolduğunda çalıştır veya maksimum bekleme süresi dolduğunda mevcut işleri çalıştır

Örneğin batch kapasitesi sekiz, maksimum bekleme süresi 20 milisaniye olabilir. Sekiz iş erken gelirse çıkarım hemen başlar; yeterli iş gelmezse 20 milisaniye sonunda daha küçük batch yürütülür.

Batch içindeki segment uzunlukları farklıysa padding maliyeti ortaya çıkabilir. Üç saniyelik ve otuz saniyelik segment aynı batch'e konulduğunda kısa segment, uzun segmentin şekline kadar dolduruluyorsa hesaplama verimliliği düşer:

waste = Σ(batchMaxDuration - segmentDuration)

Bu nedenle uzunluk sınıflarına göre sınırlı gruplama yapılabilir. Ancak aşırı katı gruplama da uygun batch'in oluşmasını geciktirir. Tasarım, padding israfı ile batch bekleme süresi arasında denge kurmalıdır.

CPU tabanlı çıkarımda batch'in etkisi farklı olabilir. Bellek bant genişliği, çekirdek paylaşımı ve nicemlenmiş matris işlemleri nedeniyle daha büyük batch her zaman daha düşük gecikme veya daha yüksek doğrusal throughput sağlamaz. Gerçek kapasite yalnızca benchmark ile belirlenebilir.

Heterojen sunucularda iş yönlendirme

Birden fazla ASR sunucusunun farklı RTF değerlerine sahip olduğu yapıda eşit sayıda iş dağıtmak dengeli yük oluşturmaz.

Sunucu i için ses işleme kapasitesi yaklaşık:

Cᵢ = 1 / RTFᵢ

olarak düşünülürse toplam kapasite:

Ctotal = ΣCᵢ

olur.

İdeal yük payı:

wᵢ = Cᵢ / Ctotal

şeklinde hesaplanabilir.

Örneğin güçlü bir GPU sunucusu bir CPU sunucusundan yirmi kat hızlıysa her ikisine eşit sayıda segment göndermek CPU kuyruğunun sürekli büyümesine, GPU'nun ise zaman zaman boş kalmasına neden olur.

Ancak yalnızca teorik RTF'ye dayalı sabit ağırlık da yeterli değildir. Sunucunun anlık durumu değişebilir:

aktif iş sayısı kuyrukta bekleyen toplam ses süresi son dönem p95 RTF GPU bellek durumu yeniden deneme sayısı hata oranı

Kuyruk uzunluğunu yalnızca iş sayısıyla ölçmek heterojen segmentlerde yanıltıcıdır. Otuz adet üç saniyelik segment ile otuz adet otuz saniyelik segment aynı kuyruk uzunluğuna sahiptir, fakat aynı yük değildir.

Daha anlamlı kuyruk ölçüsü:

queuedAudioSeconds = ΣsegmentDuration

olabilir.

Sunucunun tahminî kuyruk boşalma süresi:

drainTimeᵢ ≈ queuedAudioSecondsᵢ × RTFᵢ / workerCountᵢ

şeklinde hesaplanabilir.

Yeni iş, tahminî tamamlanma zamanı en düşük sunucuya yönlendirilebilir:

estimatedFinishᵢ = currentDrainTimeᵢ + newSegmentDuration × RTFᵢ

Bu değer yine yaklaşık bir tahmindir. Yine de yalnızca round-robin veya iş sayısına dayalı dağıtımdan daha anlamlıdır.

Deterministik davranış gereken sistemlerde tamamen dinamik yönlendirme yerine kapasite ağırlıklı sabit dağılım ve kontrollü taşma politikası kullanılabilir. Örneğin güçlü sunucu normal yükün çoğunu taşır; kuyruğu belirli eşiği geçtiğinde işler diğer sunuculara yönlendirilir.

Backpressure olmadan düşük RTF sistemi kurtaramaz

Giriş hızı kalıcı biçimde işleme kapasitesini aşıyorsa hiçbir kuyruk politikası sistemi kararlı tutamaz:

λaudio > Ctotal

Bu durumda kuyruk sürekli büyür:

dQ/dt > 0

Daha hızlı donanım eklemek bir çözüm olabilir; ancak kapasite artışı sağlanamıyorsa sistemin girişe backpressure uygulaması gerekir.

Backpressure şu biçimlerde gerçekleştirilebilir:

Yeni iş kabulünü geçici olarak durdurmak,

Kaynak tüketicinin okuma hızını azaltmak,

Kuyruk üst sınırına ulaşıldığında üreticiyi bekletmek,

Düşük öncelikli işleri geciktirmek,

Yeniden denemeleri ayrı ve sınırlı kuyruğa almak,

Gerçek zamanlı ve tarihsel işleri ayırmak.

Sınırsız kuyruk, yük aşımını çözmez; yalnızca hatayı geciktirir. Bellekte tutulan sınırsız ses veya görev nesnesi sonunda bellek baskısı, çöp toplama gecikmesi veya process çökmesi üretir. Disk tabanlı sınırsız kuyruk ise depolama tüketimini ve geri kazanım süresini büyütür.

Kuyruk kapasitesi zaman birimiyle tanımlanabilir:

maksimum bekleyen ses süresi = 30 dakika

Bu sınır, segment sayısına göre daha anlamlıdır. Maksimuma ulaşıldığında uygulanacak politika sistem gereksinimine göre açıkça belirlenmelidir. Kritik verinin düşürülmesi kabul edilemiyorsa üretici durdurulmalı veya kalıcı spool katmanına yönlendirilmelidir.

Gerçek zamanlı işlerle backfill işlerinin aynı FIFO kuyruğu paylaşması da risklidir. Uzun geçmiş iş yükü güncel segmentleri geciktirebilir. Ayrı kuyruklar ve ağırlıklı zamanlama kullanılabilir:

öncelik 1 → güncel gerçek zamanlı segmentler öncelik 2 → yeniden denemeler öncelik 3 → tarihsel backfill

Ancak düşük öncelikli kuyruğun sürekli aç bırakılmaması gerekir. Bunun için belirli sayıda gerçek zamanlı işten sonra bir backfill işi alınabilir veya backfill için sabit kapasite payı ayrılabilir.

Ölçülmesi gereken gerçek performans

ASR sisteminde yalnızca "model kaç kat hızlı?" sorusu operasyonel gerçeği açıklamaz. İzlenmesi gereken metrikler en az dört katmanda ayrılmalıdır.

Giriş katmanı

saniyedeki segment sayısı saniyedeki toplam ses süresi segment süresi p50, p95, p99 aktif kaynak sayısı

Kuyruk katmanı

kuyruktaki iş sayısı kuyruktaki toplam ses süresi en eski işin yaşı bekleme süresi p50, p95, p99

Servis katmanı

ön işleme süresi çıkarım süresi son işleme süresi uçtan uca servis süresi RTF p50, p95, p99

Kapasite ve güvenilirlik katmanı

worker kullanım oranı GPU ve CPU kullanımı bellek tüketimi hata oranı yeniden deneme oranı zaman aşımı sayısı düşürülen veya ertelenen iş sayısı

Kuyruğun zamana göre eğimi özellikle değerlidir:

Q(t₂) - Q(t₁)

Kuyruk gün içinde yükselip daha sonra düşüyorsa sistem geçici yoğunluğu emebiliyor olabilir. Sürekli yükseliyorsa kapasite yetersizdir. Sabit iş sayısına rağmen en eski işin yaşı artıyorsa kısa işler ilerlerken bazı uzun veya hatalı işler aç kalıyor olabilir.

RTF ölçümünün paydası gerçek ses süresi olmalıdır. Sessizlik padding'i, batch padding'i veya yeniden örnekleme sonrası yapay örnekler medya süresine eklenirse sonuç olduğundan iyi veya kötü görünebilir.

Aynı biçimde sıcak ve soğuk başlangıç ayrı ölçülmelidir. Model yükleme, CUDA context oluşturma veya ilk kernel derleme maliyeti sürekli servis RTF'sine karıştırılmamalıdır; fakat process yeniden başlatma sonrası ilk iş gecikmesi olarak ayrıca izlenmelidir.

Gerçek zamanlılık bir model özelliği değil, sistem durumudur

Bir modelin RTF < 1 olması, tek başına gerçek zamanlı bir sistem oluşturmaz. Bu yalnızca modelin belirli test koşullarında ses süresinden daha kısa zamanda çalıştığını gösterir.

Gerçek zamanlı ve kararlı bir ASR sistemi için daha güçlü koşul gerekir:

uzun dönem giriş yükü < uzun dönem sürdürülebilir servis kapasitesi

Buna ek olarak gecikme hedefi de sağlanmalıdır:

p99 uçtan uca gecikme < sistem sınırı

Bu iki koşul aynı değildir. Sistem kapasite açısından kararlı olabilir, fakat büyük batch veya uzun kuyruk politikası nedeniyle gecikme hedefini aşabilir. Tersine, düşük trafikte mükemmel gecikme gösteren sistem yoğun saatlerde kararsız hâle gelebilir.

RTF model seçimi için değerli bir metriktir; fakat kapasite planlamasında tek başına kullanıldığında eksiktir. Asıl mühendislik problemi; segment üretiminden sunucu yönlendirmesine, kuyruk sınırından backpressure politikasına kadar bütün hattın zaman davranışını kontrol etmektir.

Bir ASR sisteminin gerçek performansı, en hızlı işlediği örnekte değil, yoğunluk altında kuyruğunu eritme yeteneğinde görülür. Düşük ortalama RTF etkileyici olabilir; güvenilir üretim sistemi ise p99 gecikmesi, servis değişkenliği ve yük artışı altında kararlı kalabilen sistemdir.

Bu sayfanın QR kodu