Porównanie modeli Whisper do napisów: Tiny, Small, Turbo i Large-v3

Największy model Whisper nie jest automatycznie najlepszym wyborem do napisów. large-v3-turbo ma około połowy parametrów large-v3 i działa około osiem razy szybciej, a w zwyczajnym materiale różnica w gotowym pliku z napisami jest tak niewielka, że o wyborze decyduje szybkość. Zdarzają się też realne przypadki, w których mniejszy model daje lepszy transkrypt niż większy.

Poniżej liczby, co znaczą konkretnie dla pracy z napisami, oraz błędy, które sprawiają, że model wygląda gorzej, niż jest w rzeczywistości.

Modele w jednym zestawieniu

Parametry i względna szybkość pochodzą z karty modelu Whisper od OpenAI; rozmiary to rzeczywiste wielkości wersji CTranslate2, które pobiera Sablate — nie zaokrąglone szacunki.

Wiersz, który wymyka się temu wzorcowi, to turbo. Ma więcej parametrów niż medium, a mimo to działa około cztery razy szybciej, czego sama liczba parametrów by nie przewidziała.

Dlaczego turbo zmienia rekomendację

Turbo to nie mniejszy model wytrenowany od zera. To large-v3, w którym dekoder przycięto z 32 warstw do 4, a potem douczono go przez kolejne dwie epoki na tych samych wielojęzycznych danych transkrypcyjnych. Whisper spędza większość czasu właśnie w dekoderze, więc takie drastyczne przycięcie daje bardzo duży zysk szybkości, podczas gdy enkoder — część, która faktycznie słucha — zostaje nietknięty.

Towarzyszą mu dwa zastrzeżenia, i oba są opisane przez OpenAI, a nie są tylko plotką ze społeczności:

• Douczono go bez danych do tłumaczenia. Turbo to model transkrypcyjny. Jeśli chcesz zadania Whisper polegającego na tłumaczeniu mowy na angielski, turbo jest niewłaściwym narzędziem — transkrybuj w języku źródłowym i przetłumacz tekst później, co i tak jest lepszym procesem.
• Niektóre języki tracą więcej niż inne. Turbo trzyma poziom large-v2 w większości języków, ale zauważalnie więcej gubi w tajskim i kantońskim. Jeśli pracujesz w tych językach, przetestuj to, zanim się zdecydujesz.

Poza tym turbo jest rozsądnym domyślnym wyborem do napisów: jakość bliska large przy szybkości, która sprawia, że dwugodzinne nagranie staje się realnym zadaniem.

Czy największy model daje najlepsze napisy?

Nie zawsze, a wyjątek warto znać, bo kiedy się na niego trafi, wygląda jak błąd.

Zmierzyliśmy to na 101-sekundowym tureckim klipie, na RTX 3060 Ti z float16, przechodząc przez własną ścieżkę transkrypcji aplikacji. Licząc, jak dużą część mowy każdy model faktycznie wychwycił, na czele był medium. large-v3 pomijał fragmenty mowy, które medium rozpoznał poprawnie — pierwsze słowa klipu i kilka krótkich wykrzyknień po prostu się nie pojawiły. Żaden ze standardowych przełączników nie przywrócił ich: wyłączenie filtra aktywności głosowej, podniesienie progu braku mowy, usunięcie progu log-probability, ustawienie na sztywno temperatury. Usunięcie progu log-probability pogorszyło sytuację drastycznie, skracając transkrypt z około 1110 znaków do 429.

Przetestowaliśmy też szeroko powtarzaną w społeczności radę, by używać large-v2 zamiast large-v3. Na tym klipie wypadł najgorzej z całego zestawu: całkowicie zgubił nieprzerwany 30-sekundowy fragment mowy, od 28,7 do 58,7 sekundy, produkując 106 słów, gdzie medium wyprodukował 178.

Jeden klip to nie benchmark, a ten był krótki, turecki i konwersacyjny. Weź z tego metodę, nie ranking: transkrybuj ten sam plik dwoma modelami, sprawdzaj, czego brakuje, a nie co jest błędnie zapisane, i wybierz ten, który usłyszał wszystko. Braki kosztują w napisach znacznie więcej niż literówki, bo widz przeczyta błędne słowo dalej, ale nie przeczyta linijki, której nie ma.

Kiedy dobry model wygląda jak zły

Trzy rodzaje błędów wywołują narzekania „duży model jest gorszy”, które nie mają nic wspólnego z samym modelem.

1. Remisy w znacznikach czasu słów rozbijają podział na linijki. Whisper zwraca znaczniki czasu dla każdego słowa, a sąsiadujące słowa często mają dokładnie tę samą granicę — w klipie, który sprawdzaliśmy, 172 z 177 odstępów między słowami wynosiło równo 0,000 sekundy. Mechanizm dzielący długi napis w miejscu największego odstępu w takiej sytuacji trafia na remis wszystkich kandydatów, bierze pierwszy z nich i powtarza to rekurencyjnie — odrywając po jednym słowie na raz. Objawem jest transkrypt rozdrobniony na jednowyrazowe napisy, a problem narasta z modelem, który produkuje najwięcej słów. Poprawienie rozstrzygania remisu na korzyść środka czasowego odstępu sprowadziło jeden klip z 90 napisów (78 z nich jednowyrazowych) do 28 napisów z jedną jednowyrazową linijką. Model się nie zmienił.

2. Wybrany model to nie ten model, który faktycznie się uruchomił. Repozytoria modeli mają niekonsekwentne nazwy między rejestrami do pobierania a bibliotekami wnioskowania. Pobrany model leżący na dysku pod jedną nazwą repozytorium, podczas gdy loader szuka innej, kończy się albo cichym powrotem do innego modelu, albo błędem, który wygląda jak problem z siecią — mimo że 1,6 GB właściwego modelu już tam jest.

3. Nieudana ponowna transkrypcja zostawia na ekranie stary transkrypt. Jeśli ponowne uruchomienie się nie powiedzie, a aplikacja wycofa zadanie, ale zachowa nazwę żądanego modelu, patrzysz teraz na wynik poprzedniego modelu oznaczony jako nowy. Każde porównanie zrobione w tym stanie jest błędne. Jeśli robisz benchmark, sprawdź, czy tekst faktycznie się zmienił, zanim wyciągniesz wnioski — identyczny wynik z dwóch różnych modeli to sygnał ostrzegawczy, nie odkrycie.

VRAM, dysk i możliwości twojego komputera

Rozmiary pobierania z tabeli powyżej są też dobrym wskaźnikiem obciążenia pamięci podczas transkrypcji. Praktyczne wskazówki:

• 4 GB VRAM lub mniej, albo brak dedykowanego GPU — small to złoty środek. tiny jest do szkiców i sprawdzania czasowania, nie do finalnej dostawy.
• 6–8 GB VRAM — large-v3-turbo bez problemu. To konfiguracja, na której powinna być większość ludzi.
• 10 GB VRAM lub więcej — large-v3, jeśli audio tego naprawdę wymaga: silny akcent, nakładający się mówcy, słabe mikrofony.
• Tylko CPU — small do wszystkiego, co potrzebujesz od razu, turbo, jeśli możesz zostawić je do działania na dłużej.

Precyzja ma tu równie duże znaczenie, co rozmiar modelu. Wersje CTranslate2, na których działa Whisper, wspierają float16 i int8, a zmniejszenie precyzji znacznie redukuje zużycie pamięci przy koszcie jakości, który jest niewielki dla int8 i zwykle niezauważalny dla float16 na GPU.

Na GPU licz na przyspieszenie o pięć do dziesięciu razy względem tego samego komputera na CPU. W Sablate na Windows środowisko NVIDIA CUDA pobiera się przy pierwszym zadaniu na GPU, a nie jest dołączone do instalatora, co utrzymuje mały rozmiar pobierania dla osób, które nigdy go nie użyją.

Który model naprawdę wybrać?

Ten ostatni wiersz zmienia całe wyliczenie. Kiedy transkrypt jest wejściem dla ośmiu tłumaczeń, błąd to nie jeden błąd — to osiem błędów. Proces pracy z wieloma językami wyjaśnia, czemu transkrypt źródłowy zasługuje na wolny model i uważną korektę.

W Sablate Fast i Balanced (tiny i small) działają w planie Darmowym; Accurate i Best są częścią Pro — jednej płatności $29, opisanej na stronie cennika. Niezależnie od tego, który model uruchomisz, wynik trafia do tego samego edytora i eksportuje się do tych samych formatów — SRT, VTT i ASS — więc wybór modelu decyduje o tym, ile potem poprawiasz, a nie o tym, co jesteś w stanie stworzyć.

Jak to przetestować na własnym materiale

Pięć minut metody bije każdy opublikowany benchmark, także ten:

1. Weź klip długości 60 do 120 sekund, który jest reprezentatywny — twój najgorszy mikrofon, twoje typowe akcenty, twój prawdziwy pokój.
2. Transkrybuj go dwoma kandydującymi modelami, nie zmieniając niczego innego.
3. Porównaj najpierw pod kątem braków, potem błędnie zapisanych słów.
4. Policz jednowyrazowe napisy. Ich duża liczba wskazuje na segmentację, nie na model.
5. Tylko wtedy porównaj rzeczywisty czas działania i zdecyduj, ile ten czas dla ciebie znaczy.

Model, który usłyszy wszystko w twoim materiale, jest dla ciebie najlepszym modelem — i niekoniecznie będzie tym największym.