VibeVoice-ASR-Streaming-1.5B kontra Gemini 3.5 Transcribe: cichy strumieniowy ASR Microsoftu przeciwko nowemu API Google

Siedem dni i jeden filozoficzny podział dzielą dwa najnowsze systemy streamingowej zamiany mowy na tekst. 26 sierpnia 2026 roku Google udostępniło Gemini 3.5 Transcribe w publicznej wersji zapoznawczej: hostowany, zamknięty interfejs API do zamiany mowy na tekst, wyceniany za token audio, z osobnym punktem końcowym Live do sesji w czasie rzeczywistym. 2 września 2026 roku Microsoft Research wgrało VibeVoice-ASR-Streaming-1.5B do Hugging Face w przestrzeni nazw microsoft — wagi na licencji MIT, żadnego komunikatu prasowego, żadnego wpisu o premierze i w chwili pisania tego tekstu żadnych doniesień od zewnętrznych podmiotów. Oba transkrybują mowę, gdy ta wciąż dociera. Prawie wszystko inne na ich temat — kto może je uruchamiać, ile kosztują, jakie istnieją dowody, że działają — jest inne.

Ta strona porównuje oba rozwiązania takimi, jakie faktycznie są dziś, co oznacza, że dowody po obu stronach nie są symetryczne. Gemini 3.5 Transcribe to działający produkt Google z opublikowanymi cenami tokenów i danymi o dokładności od niezależnej firmy Artificial Analysis; to właśnie te wartości są poniżej oznaczone jako AA. VibeVoice-ASR-Streaming-1.5B to checkpoint, którego karta modelu nie publikuje w formie tekstowej żadnego współczynnika błędów słownych ani żadnej wartości opóźnienia — ewaluacja na karcie ma postać obrazu, a jedynym jak dotąd ogłoszeniem rodziny streamingowej jest wpis informacyjny z 3 września w repozytorium VibeVoice firmy Microsoft na GitHubie. Cała poniższa część dotycząca Microsoftu opiera się wyłącznie na informacjach z repozytorium: plikach konfiguracyjnych, karcie modelu i własnej dokumentacji streamowania Microsoftu. Nic w tym przypadku nie zostało jeszcze poddane niezależnym testom porównawczym.

Oba modele na pierwszy rzut oka

• Co to jest — VibeVoice-ASR-Streaming-1.5B: otwarty checkpoint, licencja MIT, self-hosted vs Gemini 3.5 Transcribe: hostowane API, zamknięte wagi.

• Premiera — wagi 2 września 2026, ogłoszenie w repozytorium 3 września vs publiczny podgląd 26 sierpnia 2026 z pełnymi materiałami premierowymi.

• Forma strumieniowania — emituje tekst w ~2,9-sekundowych fragmentach z ~0,5 s wyprzedzeniem, stan sesji przechowywany w pamięci podręcznej prefiksów; w porównaniu z sesją WebSocket Live rozliczaną za token audio i ograniczoną do 10 minut audio na sesję.

• Dokładność w materiałach drukowanych — brak opublikowanych wartości WER ani opóźnień w tekście; pomiary AA wykazały 2,6% WER dla punktu końcowego pre-recorded i 4,0% dla punktu końcowego Live.

• Wyjście mówcy — deklarowane strumieniowe przypisywanie wypowiedzi do mówców, kto co powiedział (niezweryfikowane), w porównaniu z brakiem diarizacji mówców i brakiem znaczników czasowych na poziomie słów w punkcie końcowym Live.

• Hotwords — obsługiwane, przez ten sam prompt kontekstowy co wsadowy VibeVoice-ASR, w przeciwieństwie do braku tej funkcji na liście możliwości endpointu Live.

• Koszt — $0 za wagi, ~5,6 GB do samodzielnego hostowania vs około $0,30 za godzinę audio w przypadku punktu końcowego dla nagrań i ~$0,54 w przypadku Live, według podanych przez Google cen tokenów.

Hostowane API i cichy upload, w odstępie siedmiu dni.

Gemini 3.5 Transcribe to nowej generacji model transkrypcji Google’a, dostępny jako dwa produkty. Endpoint do nagrań, obsługiwany przez Interactions API, przyjmuje cały plik audio i zwraca transkrypt z oczekiwanymi dodatkami. Endpoint Live, gemini-3.5-transcribe-live, działa przez dwukierunkowy WebSocket i to właśnie on rywalizuje z VibeVoice-ASR-Streaming-1.5B pod względem charakteru zadania: transkrypcji sesji w czasie jej trwania. Google ogłosił go w standardowym trybie — start publicznej wersji zapoznawczej 26 sierpnia, ceny na stronie modelu i zewnętrzne rankingi, które podchwyciły go w ciągu kilku dni.

Streamingowa premiera Microsoftu nie miała nic z tego. 2 września konto Microsoftu na Hugging Face utworzyło dwa checkpointy w tej samej minucie: VibeVoice-ASR-Streaming-7B i VibeVoice-ASR-Streaming-1.5B. Tabela modeli w repozytorium GitHub wymienia teraz VibeVoice-ASR-Streaming jako członka rodziny, a sekcja aktualności zawiera wpis z 3 września ogłaszający „ujednolicony streamingowy 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 kluczowych (hotwords) i 10 języków” — ale ogłoszenie to wymienia model 7B, a 1.5B to mniejszy brat, który został wydany razem z nim, bez bezpośredniego wyróżnienia. Gdy sprawdziliśmy dzień po udostępnieniu, oba checkpointy nadal pokazywały zero pobrań.

Co oznacza „streaming” po każdej stronie?

Słowo „streaming” ukrywa realną różnicę projektową. Konfiguracja preprocesora Microsoftu nadaje konkretny rytm VibeVoice: dźwięk dociera z częstotliwością 24 kHz i jest kompresowany 3200× do strumienia tokenów mowy o częstotliwości około 7,5 Hz (jeden token co ~133 ms). Ta konfiguracja deklaruje porcję 22 ramek i wyprzedzenie 4 ramek — około 2,9 sekundy dźwięku na porcję, przy czym mniej więcej pół sekundy przyszłego dźwięku jest wykorzystywane do utrwalenia bieżącego segmentu. Model generuje tekst raz na sfinalizowaną porcję, a dokumentacja Microsoftu wspomina, że kontekst z wcześniejszych porcji jest zachowywany przez pamięć podręczną KV, więc długa sesja nie przetwarza wszystkiego od zera. Arytmetyka jest w konfiguracji; praktyczną konsekwencją jest transkrypt, który rośnie w przybliżeniu w trzysekundowych przyrostach, a nie w cząstkowych wynikach dla pojedynczych słów.

Endpoint Google Live to inny model strumieniowania: dwukierunkowa sesja WebSocket, w której audio jest rozliczane stawką 25 tokenów audio na sekundę, zaprojektowana do interaktywnego użycia, ale ograniczona do 10 minut audio na sesję i — w przypadku samego endpointu Live — bez diarizacji mówców ani znaczników czasowych na poziomie słów. Dla każdego, kto porównuje oba rozwiązania jako silniki transkrypcji na żywo, istotne różnice to limit sesji (10 minut po stronie Google Live, po stronie Microsoftu ograniczony wyłącznie przez własne GPU i pamięć), częstotliwość emisji (fragmenty ~3-sekundowe wobec tego, co dostarcza sesja WebSocket) oraz dodatki wyjściowe (atrybucja mówcy i hotwords, deklarowane w karcie Microsoftu, a nieobecne na liście funkcji Google Live).

Dokładność: jedna strona ma liczby, druga obrazek

To największa luka w tym zestawieniu — i to luka w dowodach, niekoniecznie w jakości. Według Artificial Analysis Gemini 3.5 Transcribe osiąga współczynnik błędów słów na poziomie 2,6% na punkcie końcowym dla nagrań i 4,0% na punkcie końcowym na żywo — cena, jaką płacisz za przekaz w czasie rzeczywistym, znajduje odzwierciedlenie we współczynniku błędów, co jest powszechnym i uczciwym kompromisem w systemach streamingowych. To dane zewnętrzne z neutralnego rankingu, opublikowane kilka dni po premierze.

VibeVoice-ASR-Streaming-1.5B nie ma nigdzie żadnej porównywalnej wartości. Karta modelu zawiera wykres wyników ewaluacji jako obraz, ale nie podaje żadnych liczbowych wartości WER, RTF ani opóźnień w formie tekstowej — nic, co można by zacytować, i nic, co można by niezależnie zweryfikować. Microsoft nie opublikował liczbowych wskaźników dokładności strumieniowania w tekście ani dla wersji 7B, ani 1.5B. Jedyną liczbową kotwicą w całej rodzinie jest karta modelu wsadowego VibeVoice-ASR, która podaje średni WER 7,77% z testów przeprowadzonych przez dostawcę na ośmiu angielskich zestawach testowych oraz 2,20% na LibriSpeech clean — ale dotyczy to modelu niestrumieniowego, a modele strumieniowe zazwyczaj poświęcają odrobinę dokładności, by zyskać na opóźnieniu. Dopóki ktoś nie uruchomi punktu kontrolnego wersji strumieniowej w publicznym środowisku testowym, uczciwa ocena jest taka: model Google'a został zmierzony, a model Microsoftu nie.

Koszt: za godzinę audio w porównaniu z godziną GPU.

Google sprzedaje Gemini 3.5 Transcribe w modelu rozliczeniowym za tokeny, a cennik dzieli się wyraźnie między dwa endpointy. Endpoint dla nagrań wstępnych podaje 2 USD za 1 mln tokenów wejściowych audio i 12 USD za 1 mln tokenów wyjściowych tekstu, co daje łącznie około 0,30 USD za godzinę audio. Endpoint Live podaje 3,50 USD za 1 mln tokenów audio i 21 USD za 1 mln tokenów tekstu — to około 0,54 USD za godzinę audio łącznie, czyli o około 80% więcej niż w przypadku nagrań wstępnych, co jest ceną dostarczania w czasie rzeczywistym. Google rozlicza audio w wysokości 25 tokenów na sekundę, więc cisza jest darmowa tylko wtedy, gdy Twój klient jej nie strumieniuje; ponowne połączenia, zduplikowane audio i logowanie mogą zwiększyć rzeczywisty rachunek. Istnieje również warstwa darmowa, z zastrzeżeniem, że treści z warstwy darmowej mogą być wykorzystywane do ulepszania produktów Google.

Koszt modelu Microsoftu liczony jest natomiast w godzinach GPU. Punkt kontrolny 1.5B to mniej więcej 5,6 GB wag w formacie bf16 (szkielet językowy Qwen klasy 1.5B plus tokenizery audio i głowica dyfuzyjna — metadane safetensors sumują się do około 3B parametrów), a udokumentowane sposoby uruchomienia to własny hosting: dema w Pythonie z repozytorium microsoft/VibeVoice albo wtyczka do vLLM, którą Microsoft opisuje do serwowania endpointów zgodnych z OpenAI i WebSocket. Nie ma jeszcze ceny hostingu, bo żaden dostawca inferencji nie ma tego modelu w ofercie. Kwestia kosztów sprowadza się więc wyłącznie do tego, czy twój czas GPU jest tańszy niż godzinowa stawka Google — co przy regularnym wolumenie transkrypcji jest niemal na pewno prawdą — a kwestia licencji jest od niej oddzielna, bo wagi na licencji MIT możesz zatrzymać na własność, czego nie można powiedzieć o żadnej subskrypcji API.

Jedno nie wyklucza drugiego w stacku produkcyjnym. Pragmatyczny wzorzec dla zespołu, który już dziś potrzebuje transkrypcji na żywo, polega na utrzymaniu warstwy ASR za jednym endpointem, tak aby wybór pozostał odwracalny: API routingu, które udostępnia ponad 200 modeli w cenach katalogowych dostawców — bez narzutu, więc zmiana ceny u danego dostawcy wchodzi w życie tego samego dnia — z automatycznym przełączaniem awaryjnym, jest dokładnie tą warstwą, która pozwala mieć sprawdzone API Google jako domyślne, podczas gdy wycinek rzeczywistego ruchu testuje VibeVoice-ASR-Streaming-1.5B w momencie, gdy dostawca zacznie go hostować. Na tym właśnie polega model OrcaRouter: to niskoryzykowny sposób na wdrożenie checkpointu, którego dokładności nikt jeszcze nie zweryfikował.

Kto powinien wybrać, które

Wybierz Gemini 3.5 Transcribe, jeśli chcesz API do transkrypcji, które działa już dziś, ma opublikowaną dokładność, przewidywalną cenę za godzinę i nie wymaga pilnowania GPU — a zwłaszcza jeśli Twoje audio nie znajduje się wśród dziesięciu języków wymienionych przez Microsoft, albo jeśli do transkrypcji plików potrzebujesz diarizacji i znaczników czasowych na poziomie słów z endpointu pre-recorded. Limit 10 minut dla sesji na żywo to realne ograniczenie, które warto przetestować pod kątem Twojego przypadku użycia, zanim zdecydujesz się na niego do sesji na żywo.

Wybierz VibeVoice-ASR-Streaming-1.5B, jeśli hostujesz samodzielnie, jeśli chcesz mieć wagę i kontrolę nad danymi, którą daje licencja MIT, jeśli potrzebujesz nieograniczonej długości sesji, lub jeśli strumieniowe wyjście z przypisaniem wypowiedzi do mówcy i hotwords to funkcje, które konkretnie chcesz ocenić. Zaplanuj budżet na instalację ze źródeł, ~5,6 GB wag na GPU NVIDIA oraz własną bramę ewaluacyjną — nie ma benchmarku, na którym można się oprzeć, więc kwestię dokładności musisz rozstrzygnąć sam, używając własnego audio.

Werdykt po pierwszym tygodniu: Google wypuściło produkt wyważony, a Microsoft – ciekawy zakład. Gemini 3.5 Transcribe to bezpieczniejszy wybór domyślny, za którym stoją wyniki zewnętrznych testów; VibeVoice-ASR-Streaming-1.5B to otwarta, samodzielnie hostowana, całkowicie niezweryfikowana alternatywa. Wybór ten jest tani, bo nie musi być trwały — wystarczy utrzymywać wymienny endpoint ASR, a checkpoint bez ani jednego benchmarku może zyskać lub stracić ruch na podstawie dowodów z własnych transkryptów.