VibeVoice-ASR-Streaming-7B vs Gemini 3.5 Transcribe Live: Jeden tydzień, dwa rodzaje strumieniowego rozpoznawania mowy

Ostatni tydzień sierpnia i pierwsze dni września 2026 roku przyniosły dwa strumieniowe systemy rozpoznawania mowy na tekst, które wyglądają na rywali, a w rzeczywistości są różnymi odpowiedziami na to samo pytanie. 26 sierpnia Google udostępnił w publicznej wersji zapoznawczej Gemini 3.5 Transcribe Live: hostowany, zamknięty endpoint rozpoznawania mowy, który zwraca gotowy transkrypt 0,40 sekundy po tym, jak mówca zamilknie, wspierany zmierzonym przez Artificial Analysis współczynnikiem błędów strumieniowych na poziomie 4,0% oraz pełnymi materiałami z premiery. 2 września Microsoft Research wgrało VibeVoice-ASR-Streaming-7B do Hugging Face w przestrzeni nazw microsoft: otwarte wagi na licencji MIT, bez komunikatu prasowego, bez strony startowej i z kartą modelu, która w czytelnym tekście nie podaje ani współczynnika błędów, ani wartości opóźnień. Oba systemy przyjmują dźwięk, gdy ten wciąż napływa. To niemal jedyna rzecz, która je łączy.

Dowody po obu stronach nie są symetryczne, dlatego to porównanie ma formę „tego, co wiemy na razie”. Gemini 3.5 Transcribe Live to produkt Google z opublikowanymi cenami tokenów i pomiarami zewnętrznymi, które są oznaczone poniżej. VibeVoice-ASR-Streaming-7B to checkpoint, którego każde twierdzenie pochodzi wprost z samego repozytorium: plików konfiguracyjnych, karty modelu oraz dokumentacji strumieniowej Microsoftu w repozytorium VibeVoice na GitHubie. Nic po stronie Microsoftu nie zostało jeszcze niezależnie przetestowane, i mówimy to wszędzie tam, gdzie liczba mogłaby w przeciwnym razie sprawiać wrażenie, że coś udowadnia.

Ślad wydania: premiera API i cichy upload

Google wypuściło Gemini 3.5 Transcribe Live w standardowy sposób. Model znajduje się pod szyldem Gemini Audio wraz ze swoim rodzeństwem Gemini 3.5 Transcribe (ścieżką Interactions API dla wcześniej nagranych plików), cennik jest na stronie modelu, a niezależne rankingi dodały endpoint Live w ciągu kilku dni — to właśnie z nich pochodzą 4,0% WER dla transmisji strumieniowej i 0,40-sekundowe opóźnienie końcowe. Istnieje też darmowy poziom, z typowym zastrzeżeniem, że treści z darmowego poziomu mogą być wykorzystywane do ulepszania produktów Google.

Wydanie strumieniowe Microsoftu nie miało żadnego z tego mechanizmu. Repozytorium Hugging Face microsoft/VibeVoice-ASR-Streaming-7B zostało utworzone 2 września 2026 o 15:46 UTC, a ostatnia modyfikacja nastąpiła trzy minuty później; zawiera osiem fragmentów safetensors, tokenizator i konfigurację preprocesora na licencji MIT. Formalnym zapisem jest wpis w dzienniku aktualności z 3 września w repozytorium microsoft/VibeVoice, ogłaszający „ujednolicony strumieniowy model ASR, który w sposób ciągły transkrybuje, kto co powiedział w miarę napływania mowy, z obsługą spersonalizowanych słów hotword i 10 języków", z linkami do demo na aka.ms/vibeasr oraz strumieniowego raportu technicznego. Gdy sprawdziliśmy dzień po przesłaniu, punkt kontrolny nadal wykazywał zero pobrań, a żaden dostawca hostowanego wnioskowania go nie wymienia. Karta modelu mówi więcej niż ogłoszenie, a repozytorium jest źródłem niemal wszystkiego poniżej.

Specyfikacje zestawione obok siebie

• Co to jest — VibeVoice-ASR-Streaming-7B: strumieniowy ASR o otwartych wagach, hostowany lokalnie vs Gemini 3.5 Transcribe Live: hostowane strumieniowe API, zamknięte wagi.

• Tryb strumieniowy — emituje tekst w porcjach trwających około 2,9 sekundy, z około 0,5 sekundy wyprzedzenia wynikającego z konfiguracji checkpointu, natomiast dwukierunkowa sesja WebSocket zapewnia ciągłe częściowe transkrypcje i wynik końcowy 0,40 sekundy po zakończeniu mówienia.

• Dokładność druku — brak opublikowanej wartości WER lub opóźnienia w tekście wobec 4,0% WER dla strumieniowania i 2,6% dla modelu wstępnie nagranego, według Artificial Analysis.

• Mówcy — deklarowane jest strumieniowe przypisywanie wypowiedzi do mówców („kto co powiedział”), niezweryfikowane; na endpoincie Live brak diarizacji mówców (dostępna jest w modelu dla wcześniej nagranych plików, maksymalnie dla trzech mówców).

• Języki — 10 (en, zh, es, pt, de, ja, ko, fr, ru, it) vs automatyczne wykrywanie wśród 85+ z przełączaniem w trakcie.

• Długość sesji — ograniczona wyłącznie przez GPU i pamięć, a nie twardym limitem 10 minut na sesję Live.

• Koszt — $0 za wagi, około 18 GB bf16 do samodzielnego hostowania, w porównaniu z mniej więcej $0.54 za godzinę audio na Live po zliczeniu tokenów wyjściowych tekstu.

Co oznacza „streaming” po każdej stronie?

To słowo ukrywa prawdziwą różnicę projektową i warto zachować precyzję, ponieważ te dwa systemy nawet nie próbują wytwarzać tego samego rytmu. Konfiguracja preprocesora Microsoftu nadaje rytmowi VibeVoice konkretny kształt: audio dociera z częstotliwością 24 kHz i jest kompresowane 3200-krotnie do strumienia tokenów z prędkością około 7,5 ramki na sekundę, a następnie konfiguracja deklaruje chunk o długości 22 ramek i lookahead wynoszący 4 ramki — to około 2,9 sekundy audio na chunk, z mniej więcej pół sekundy przyszłego audio, które go finalizuje. Model emituje tekst raz na każdy sfinalizowany chunk, a kontekst z wcześniejszych chunków jest zachowywany w pamięci podręcznej KV, więc długa sesja nie przelicza wszystkiego od zera. Praktyczny transkrypt rośnie w przyrostach co mniej więcej trzy sekundy.

Endpoint Live Google'a został zaprojektowany do szybszej, bardziej interaktywnej pętli: dźwięk jest przesyłany przez WebSocket w fragmentach PCM o częstotliwości 16 lub 24 kHz, częściowe transkrypcje wracają na bieżąco, gdy mówca mówi, a końcowa sformatowana transkrypcja pojawia się 0,40 sekundy po zakończeniu mowy — to pomiar Artificial Analysis, cytowany przez Google. Do minusów należą limit sesji (dziesięć minut dźwięku, po którym aplikacja musi ponownie nawiązać połączenie i scalić całość) oraz brak dodatków: w ścieżce Live nie ma diarizacji mówców ani znaczników czasowych na poziomie słów, choć obie te funkcje są dostępne w transkrypcji wcześniej nagranych plików Gemini 3.5 Transcribe. Uczciwe podsumowanie jest więc takie: model strumieniowy Google’a jest szybszy w przeliczeniu na wypowiedź, a checkpoint strumieniowy Microsoftu jest wolniejszy na fragment, ale zapewnia przypisywanie mówców, którego pozbawiona jest ścieżka na żywo Google’a, przy długości sesji, jakiej Google nie oferuje.

Dokładność: mierzona względem pustej przestrzeni.

Największa różnica w tym zestawieniu to różnica w dowodach, a niekoniecznie w jakości. Artificial Analysis zmierzyło Gemini 3.5 Transcribe Live na poziomie 4,0% średniego wskaźnika błędów słownych w trybie strumieniowym i 2,6% w modelu niestrumieniowym – ten drugi wynik zajął piąte miejsce na liście rankingowej WER w momencie premiery. Google osobno podaje 5,50% dla trybu strumieniowego i 5,04% dla niestrumieniowego na wielojęzycznym zestawie FLEURS. Należy je czytać tak, jak są oznaczone: Artificial Analysis jest niezależne od Google, ale liczby dla API, które ma zaledwie jeden dzień, są wciąż wstępne, a premia za tryb strumieniowy względem modelu wsadowego – 4,0% vs 2,6% – to zwykła cena dostarczania w czasie rzeczywistym.

VibeVoice-ASR-Streaming-7B nie ma nigdzie porównywalnych wyników liczbowych. Karta modelu zawiera wynik ewaluacji jako obraz, a raport techniczny Microsoftu to plik PDF, ale żadne z nich nie oferuje w formie zwykłego tekstu wartości WER ani opóźnienia dla trybu strumieniowego, które można by zacytować lub niezależnie zweryfikować. Jedynym liczbowym punktem odniesienia w całej rodzinie jest karta modelu wsadowego VibeVoice-ASR, która podaje wyliczoną przez dostawcę średnią 7,77% WER na ośmiu anglojęzycznych zestawach testowych oraz 2,20% na LibriSpeech clean — są to wyniki dla modelu niestrumieniowego, a nie dla tego modelu, a modele strumieniowe zwykle poświęcają nieco dokładności w zamian za niższe opóźnienie. Dopóki ktoś nie uruchomi strumieniowego punktu kontrolnego w publicznym środowisku testowym, uczciwe stwierdzenie jest takie: jedna strona tego porównania jest zmierzona, a druga nie.

Koszt: API rozliczane za użycie a GPU, który już masz w budżecie

Google wycenia Gemini 3.5 Transcribe Live za token i rozlicza audio według stawki 25 tokenów na sekundę. Przy opublikowanych stawkach Live — 3,50 USD za 1 mln tokenów audio i 21 USD za 1 mln tokenów tekstu na wyjściu — po zsumowaniu obu składników godzina audio to około 0,54 USD, czyli około 9 USD za 1000 minut audio, a model do gotowych nagrań jest jeszcze tańszy: około 0,30 USD za godzinę. Cisza jest darmowa tylko wtedy, gdy klient jej nie przesyła strumieniowo: ponowne połączenia, zduplikowane audio i logowanie doliczają płatne tokeny do rzeczywistego rachunku.

Punkt kontrolny Microsoftu jest natomiast wyceniany w GPU-godzinach. Same wagi bf16 zajmują około 18 GB, zanim uwzględni się jakąkolwiek pamięć podręczną KV; udokumentowane ścieżki dostępu to dema w Pythonie w repozytorium microsoft/VibeVoice oraz wtyczka vLLM obsługująca punkty końcowe zgodne z WebSocket i OpenAI. Nie ma też ceny hostowanej, bo żaden dostawca jeszcze tego modelu nie hostuje — nie ma go na Azure AI Foundry tak, jak wsadowego VibeVoice-ASR od marca. Samodzielne hostowanie modelu mowy LLM klasy 7B wymaga zaplanowania GPU klasy 24 GB i własnego czasu na operacje; w zamian otrzymujesz nieograniczoną długość sesji i wagi, które zostają twoją własnością. Te dwa modele nie wykluczają się wzajemnie — i właśnie o tym jest ostatnia sekcja.

Utrzymanie niskiej ceny wyboru

To, który z nich wybierzesz, zależy od tego, czy potrzebujesz liczby, czy kodu. Wybierz Gemini 3.5 Transcribe Live, gdy chcesz transkrypcji, która działa już dziś, ma opublikowaną dokładność i nie wymaga GPU — oraz gdy Twoje nagrania audio nie ograniczają się do dziesięciu języków albo gdy jesteś gotów samodzielnie zbudować etykietowanie mówców, bo endpoint Live go nie zapewnia. Wybierz VibeVoice-ASR-Streaming-7B, gdy hostujesz go samodzielnie, gdy liczy się nieograniczona długość sesji lub deklarowane strumieniowe wyjście z przypisaniem do mówców i gdy jesteś gotów uruchomić własną bramkę ewaluacyjną, bo nie ma benchmarku, na którym mógłbyś się oprzeć.

Żaden wybór nie musi być trwały i właśnie w tym miejscu warstwa routingu okazuje swoją przydatność — dla modeli pracujących na transkrypcie, a nie dla samej transkrypcji. OrcaRouter nie obsługuje dziś zamiany mowy na tekst i żaden z modeli na tej stronie nie znajduje się w jego katalogu; zamiast tego daje jeden interfejs API do ponad 200 modeli językowych korzystających z transkryptu na żywo — streszczacza, wyodrębniacza pozycji do zrobienia, planisty agenta głosowego — po cenach cennikowych dostawcy przekazywanych bez narzutu, z automatycznym przełączaniem między dostawcami w razie awarii. Jeśli dostawca obniży cenę dowolnego modelu w tym stosie, zmiana obowiązuje tego samego dnia, bo ceny cennikowe są przekazywane dalej, a nie zawyżane. Krok transkrypcji zostaje tam, gdzie go umieścisz; stos, który działa na transkrypcie, to dokładnie ta warstwa, w której jeden klucz i trasa zapasowa zamienia tygodniowy, nieprzetestowany punkt kontrolny z zakładu w możliwą do przetestowania opcję.