VibeVoice-ASR-Streaming-7B vs Gemini 3.5 Transcribe Live: En vecka, två typer av streamingbaserad tal-till-text

Den sista veckan i augusti och de första dagarna i september 2026 producerade två strömmande tal-till-text-system som ser ut som konkurrenter men som egentligen är olika svar på samma fråga. Den 26 augusti släppte Google Gemini 3.5 Transcribe Live i offentlig förhandsvisning: en värdbaserad, sluten tal-till-text-endpoint som returnerar en färdig transkription 0,40 sekunder efter att en talare slutat prata, med en uppmätt strömmande ord-felfrekvens på 4,0 % från Artificial Analysis och komplett lanseringsmaterial. Den 2 september laddade Microsoft Research upp VibeVoice-ASR-Streaming-7B till Hugging Face under microsoft-namnrymden: MIT-licensierade öppna vikter, inget pressmeddelande, ingen lanseringssida och en modellkort som inte publicerar någon ord-felfrekvens eller latenssiffra i läsbar text alls. Båda tar emot ljud medan det fortfarande strömmar in. Det är i stort sett det enda de har gemensamt.

Bevisningen på de två sidorna är inte symmetrisk, så den här jämförelsen är skriven som vad-vi-vet-hittills. Gemini 3.5 Transcribe Live är en Google-produkt med publicerade tokenpriser och tredjepartsmätningar, och dessa är märkta nedan. VibeVoice-ASR-Streaming-7B är en checkpoint vars alla påståenden är avlästa från själva arkivet: konfigurationsfilerna, modellkortet och Microsofts strömningsdokumentation i VibeVoice GitHub-arkivet. Inget om Microsoft-sidan har ännu blivit oberoende benchmarkat, och vi säger ifrån överallt där en siffra annars skulle verka göra arbetet.

Utgivningsspåret: en API-lansering och en tyst uppladdning.

{{1}}Google släppte Gemini 3.5 Transcribe Live på vanligt sätt.{{/1}} {{2}}Modellen ligger under Gemini Audio-bannern tillsammans med syskonmodellen Gemini 3.5 Transcribe (den förinspelade Interactions API-vägen),{{/2}} {{3}}prissättningen finns på modellsidan,{{/3}} {{4}}och oberoende leaderboards inkluderade Live-endpointen inom några dagar{{/4}} {{5}}— det är därifrån streaming-WER:et på 4,0 % och slutlatensen på 0,40 sekunder kommer.{{/5}} {{6}}Det finns en gratisnivå,{{/6}} {{7}}med det sedvanliga förbehållet att innehåll från gratisnivån kan användas för att förbättra Googles produkter.{{/7}}

Microsofts streaminglansering hade inget av det maskineriet. Hugging Face-repositoriet microsoft/VibeVoice-ASR-Streaming-7B skapades den 2 september 2026 kl. 15:46 UTC och ändrades senast tre minuter senare; det rymmer åtta safetensors-shards, en tokenizer och en preprocessorkonfiguration under MIT-licens. Den formella uppgiften är en rad i nyhetsloggen daterad 3 september i microsoft/VibeVoice-repositoriet som tillkännager ”en enhetlig strömmande ASR-modell som kontinuerligt transkriberar vem som sa vad när tal anländer, med stöd för anpassade hotwords och 10 språk”, med länkar till en demo på aka.ms/vibeasr och en teknisk rapport om streaming. När vi kontrollerade en dag efter uppladdningen visade checkpointen fortfarande noll nedladdningar, och ingen värdbaserad inferensleverantör listar den. Modellkortet säger mer än tillkännagivandet, och repositoriet är källan till nästan allt nedan.

Specifikationerna, sida vid sida

• Vad det är — VibeVoice-ASR-Streaming-7B: streaming-ASR med öppna vikter, självhostad vs Gemini 3.5 Transcribe Live: hostad streaming-API, stängda vikter.

• Strömmande form — levererar text i ungefär 2,9 sekunders block med cirka 0,5 sekunders framförhållning (härlett från checkpoint-konfigurationen) jämfört med en dubbelriktad WebSocket-session med kontinuerliga partiella transkriptioner och ett slutresultat 0,40 sekunder efter att talaren slutar.

• Noggrannhet i tryck — ingen WER- eller latenssiffra publicerad som text jämfört med 4,0 % streaming-WER och 2,6 % för den förinspelade modellen, enligt Artificial Analysis.

• Talare — sägs ha strömmande vem-sa-vad-attribuering, overifierad; Live-slutpunkten har ingen talardiarisering (tillgänglig på den förinspelade modellen, upp till tre talare).

• Språk — 10 (en, zh, es, pt, de, ja, ko, fr, ru, it) jämfört med automatisk detektering bland 85+ med byte mitt i strömmen.

• Sessionslängd — begränsas endast av ditt GPU och minne, jämfört med en hård gräns på 10 minuter per Live-session.

• Kostnad — $0 för vikterna, cirka 18 GB bf16 att self-hosta jämfört med ungefär $0,54 per ljudtimme på Live när textutdatatokens räknas.

Vad "streaming" betyder på varje sida

Ordet döljer en reell designskillnad, och det är värt att vara precis, eftersom de två systemen inte ens försöker producera samma rytm. Microsofts förprocessorkonfiguration gör VibeVoice-rytmen konkret: ljudet anländer vid 24 kHz och komprimeras 3 200× till en tokenström på ungefär 7,5 bildrutor per sekund. Därefter deklarerar konfigurationen ett segment på 22 bildrutor och en lookahead på 4 bildrutor — cirka 2,9 sekunders ljud per segment med ungefär en halv sekund framtida ljud för att förstärka det. Modellen genererar text en gång per löst segment, och kontext från tidigare segment bevaras genom KV-cachen, så en lång session räknas inte om från grunden. Den praktiska transkriptionen växer i ungefär tre sekunders steg.

Googles Live-endpunkt är byggd för en snabbare, mer interaktiv loop: ljud strömmas upp via en WebSocket i 16- eller 24 kHz PCM-block, partiella transkriptioner kommer kontinuerligt medan talaren pratar, och en slutgiltig formaterad transkription landar 0,40 sekunder efter att talet slutar – den siffran är Artificial Analysis mätning, citerad av Google. Avvägningarna är sessionsgränsen (tio minuters ljud, varefter din applikation måste återansluta och sy ihop), och de saknade extrafunktionerna: ingen talardiarisering och inga tidsstämplar på ordnivå i Live-sökvägen, vilka båda finns i den förinspelade Gemini 3.5 Transcribe. Så den ärliga sammanfattningen är att Googles strömmande modell är snabbare per yttrande, medan Microsofts strömmande checkpoint är långsammare per block men gör anspråk på talartilldelningen som Googles live-linje tappar, vid en sessionslängd som Google inte erbjuder.

Noggrannhet: uppmätt, jämfört med ett tomt utrymme

Den största klyftan i den här jämförelsen är en klyfta i bevisunderlag, inte nödvändigtvis i kvalitet. Artificial Analysis uppmätte Gemini 3.5 Transcribe Live till en genomsnittlig ordfelsfrekvens på 4,0 % vid strömning och 2,6 % för den icke-strömmande modellen, där den senare rankades som femma på dess WER-topplista vid lanseringen. Google anger i sin tur 5,50 % vid strömning och 5,04 % vid icke-strömning på den flerspråkiga FLEURS-uppsättningen. Läs dem så som de är märkta: Artificial Analysis är oberoende av Google, men siffrorna för ett en dag gammalt API är fortfarande tidiga, och strömningstillägget jämfört med batchmodellen – 4,0 % mot 2,6 % – är det vanliga priset för leverans i realtid.

VibeVoice-ASR-Streaming-7B har ingen jämförbar siffra någonstans. Modellkortet levererar en utvärderingsfigur som bild, och Microsofts tekniska rapport är en PDF, men ingen av dem erbjuder en klartextsiffra för strömmande WER eller latens som kan citeras eller oberoende kontrolleras. Det enda numeriska ankaret i hela familjen är modellkortet för batch-VibeVoice-ASR, som rapporterar ett leverantörskört genomsnitt på 7,77 % WER över åtta engelska testset och 2,20 % på LibriSpeech clean – siffror för den icke-strömmande modellen, inte denna, och strömmande modeller brukar vanligtvis byta lite noggrannhet mot vinsten i latens. Tills någon kör den strömmande kontrollpunkten genom en offentlig testmiljö är den rättvisa formuleringen att ena sidan av denna jämförelse är uppmätt och den andra inte är det.

Kostnad: ett förbrukningsbaserat API jämfört med en GPU du redan budgeterat.

Google prissätter Gemini 3.5 Transcribe Live per token och debiterar ljud med 25 tokens per sekund. Med de publicerade Live-priserna – 3,50 USD per 1M ljudtokens och 21 USD per 1M textutdatatokens – landar en blandad ljudtimme på cirka 0,54 USD, ungefär 9 USD per 1 000 ljudminuter, och den förinspelade modellen är ännu billigare, cirka 0,30 USD i timmen. Tystnad är bara gratis om din klient inte strömmar den: återanslutningar, duplicerat ljud och loggning lägger alla till uppmätta tokens på den faktiska fakturan.

Microsofts checkpoint prissätts istället i GPU-timmar. Bf16-vikterna ensamma uppgår till cirka 18 GB innan någon KV-cache tillkommer, de dokumenterade vägarna är Python-demoerna i microsoft/VibeVoice-repot och en vLLM-plugin som betjänar WebSocket- och OpenAI-kompatibla slutpunkter, och det finns inget prissatt värdalternativ eftersom ingen leverantör ännu hostar modellen — den finns inte på Azure AI Foundry på det sätt som batch-VibeVoice-ASR har gjort sedan mars. Att själv hosta en speech-LLM i 7B-klassen innebär att budgetera för ett GPU-kort i 24 GB-klassen och din egen driftstid; i gengäld får du obegränsad sessionslängd och vikter som är dina att behålla. De två modellerna utesluter inte varandra, vilket är poängen med det sista avsnittet.

Att hålla valet billigt

Vilken du väljer beror på om du behöver ett nummer eller en kod. Välj Gemini 3.5 Transcribe Live när du vill ha transkribering som fungerar idag med publicerad noggrannhet och utan GPU-krav — och när ditt ljudmaterial inte är begränsat till tio språk, eller när du är beredd att bygga talarmärkning själv eftersom Live-endpointen inte tillhandahåller den. Välj VibeVoice-ASR-Streaming-7B när du kör den i egen drift, när obegränsad sessionslängd eller den påstådda streamingutmatningen med talarattribuering spelar roll, och när du är villig att köra din egen utvärderingsgrind eftersom det inte finns något benchmark att luta sig mot.

Ingetdera valet behöver vara permanent, och det är där ett routningslager gör skäl för sig — för modellerna runt transkriptet, inte själva transkriberingen. OrcaRouter routar inte tal-till-text i dag, och ingen av modellerna på den här sidan finns i dess katalog; vad den gör är att via ett enda API ge tillgång till de 200+ språkmodeller som konsumerar ett live-transkript — sammanfattaren, extraktorn för åtgärdspunkter, röstagentens planerare — till leverantörslistpriser, som förs vidare utan påslag, med automatisk failover mellan leverantörer. En leverantörs prissänkning på valfri modell i den stacken träder i kraft samma dag, eftersom listpriserna förs vidare i stället för att förses med påslag. Transkriberingssteget förblir där du har placerat det; den stack som agerar på transkriptet är exakt det lager där en enda nyckel och en reservrutt förvandlar en veckogammal, obenchmarkad checkpoint från en chansning till ett testbart alternativ.