Ile nagrań audio dziennie może transkrybować serwer domowy?
Serwer domowy może dokonywać transkrypcji od mniej niż jednej do setek godzin nagrań audio dziennie, zależnie od zmierzonego współczynnika czasu rzeczywistego i dostępnego cyklu pracy.
Współczynnik czasu rzeczywistego równy 0,25 oznacza, że godzina nagrania audio zajmuje 15 minut, czyli w ciągu godziny przetwarzania można obsłużyć cztery godziny nagrania. Jeśli transkrypcja może działać przez 20 godzin zegarowych, teoretyczna dzienna przepustowość wynosi 80 godzin nagrań, przed uwzględnieniem ponownych prób i narzutu związanego z pobieraniem danych. Same nazwy podzespołów nie pozwalają wiarygodnie określić tej wartości w całym planowanym nocnym oknie przetwarzania.
Współczynnik czasu rzeczywistego przelicza szybkość na dzienną przepustowość
Współczynnik czasu rzeczywistego to czas przetwarzania podzielony przez długość nagrania. Wartość RTF równa 1,0 oznacza działanie w czasie rzeczywistym; 0,5 oznacza przetwarzanie dwóch godzin nagrania w ciągu jednej godziny zegarowej; 0,1 — dziesięciu. Dzienna przepustowość jest równa liczbie zaplanowanych godzin przetwarzania podzielonej przez RTF.
Opublikowane testy przepustowości Whisper pokazują, że model, procesor graficzny, długość nagrania i przetwarzanie wsadowe mogą znacząco zmienić przepustowość. Zmierzona konfiguracja musi odpowiadać obciążeniu występującemu w domu.
Te obliczenia uwzględniają długość źródłowego nagrania audio, a nie czas upływający przy przetwarzaniu plików. Usuwanie ciszy może zmniejszyć ilość pracy, natomiast diarizacja, wyrównywanie, tłumaczenie i formatowanie napisów dodają kolejne etapy. 24-godzinne nagranie może zawierać zaledwie kilka godzin mowy, ale nadal wymagać dekodowania i segmentacji.
Model i rozmiar partii kształtują kompromis między szybkością a dokładnością
Mniejsze lub destylowane modele zwykle przetwarzają dane szybciej i zużywają mniej pamięci, podczas gdy większe modele wielojęzyczne mogą poprawiać dokładność w przypadku trudnych języków. Przetwarzanie wsadowe może zwiększyć wykorzystanie procesora graficznego przy wielu plikach, ale wydłuża oczekiwanie na pojedynczy pilny klip.
Zbiór pomiarów czasu działania wykonanych przez społeczność wskazuje, że teoretyczna moc obliczeniowa nie przekłada się liniowo na szybkość transkrypcji, jeśli nie uwzględni się przetwarzania wsadowego i wykorzystania całego potoku.
Krótkie klipy mają proporcjonalnie większy narzut związany z konfiguracją, otwieraniem plików i planowaniem niż długie nagrania. Wykrywanie języka i wyszukiwanie wiązkowe również mogą zmieniać czas działania. Większa liczba godzin audio dziennie nie jest automatycznie lepsza, jeśli liczba błędów słownych sprawia, że transkrypcje stają się nieużyteczne.
Gdzie wzór na przepustowość przestaje obowiązywać
RTF zmierzony dla czystej mowy mono może nie sprawdzić się w przypadku spotkań stereo, zaszumionych nagrań, wielu języków lub długich plików powodujących inne zachowanie pamięci. Dławienie termiczne i równoległe zadania NAS zmniejszają dostępną moc obliczeniową w ciągu całego dnia.
Praktyczny współczynnik czasu rzeczywistego pokazuje znaczne różnice między urządzeniami i potwierdza, że należy mierzyć rzeczywisty model, zamiast wyciągać wnioski o przepustowości wyłącznie na podstawie klasy procesora graficznego.
Wzór nie sprawdza się również w przypadku transkrypcji na żywo, jeśli opóźnienie musi pozostać krótsze niż napływ strumienia. Przetwarzanie offline może korzystać z partii i przyszłego kontekstu, z których nie może korzystać asystent działający w czasie rzeczywistym. Dzienna przepustowość i opóźnienie interaktywne to odrębne wyniki.
Przelicz zmierzony RTF na zakres dziennej przepustowości
Wybierz reprezentatywny zestaw krótkich notatek głosowych, długich spotkań, języków, poziomów hałasu i liczby kanałów. Zmierz czas przetwarzania kompleksowego, długość nagrania, liczbę błędów słownych na oznaczonym podzbiorze, szczytowe zużycie pamięci oraz energię przez co najmniej trzy godziny. Jeśli wymaga tego środowisko produkcyjne, uwzględnij diarizację lub wyrównywanie.
Uruchom test obok planowanych usług lokalnych obciążeń związanych z mową, aby zobaczyć rzeczywisty cykl pracy serwera. Zimne uruchomienia mierz oddzielnie od przepustowości po rozgrzaniu.
Oblicz dzienną przepustowość, dzieląc użyteczną liczbę godzin przetwarzania przez medianę RTF, a następnie do planowania zastosuj wolniejszy RTF p95 i 20-procentową rezerwę operacyjną. Jeśli dokładność nie osiąga celu, przejdź na mocniejszy model i wykonaj obliczenia ponownie, zamiast promować szybszy, lecz nieużyteczny wynik.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Jak mierzyć jakość lokalnego wyszukiwania RAG oraz interpretować kompletność przywołań, precyzję i pokrycie cytowaniami
Zbuduj lokalny zestaw testowy RAG, oblicz podstawowe metryki wyszukiwania, zinterpretuj kompromisy między nimi i sprawdź, czy twierdzenia zawarte w odpowiedziach są poparte przytoczonymi dowodami.
Dlaczego obliczenia funkcji inteligentnego domu stają się ważniejsze wraz ze wzrostem liczby czujników przy tej samej częstotliwości próbkowania?
Śledź obliczenia dla poszczególnych czujników i między czujnikami wraz ze wzrostem liczby urządzeń, identyfikuj nieliniowe koszty fuzji danych i porównaj wydajność potoku cech, zanim...
Dlaczego koszt oceny RAG rośnie przy tej samej liczbie zapytań wraz z rozbudową biblioteki dokumentów?
Zrozum, dlaczego rozrost korpusu zwiększa nakład pracy na ocenę RAG bez zwiększania liczby zapytań użytkowników oraz jak testy warstwowe utrzymują koszty proporcjonalne do ryzyka.
