
VibeVoice-ASR-Streaming-1.5B vs Gemini 3.5 Transcribe: Microsofts diskreta streaming-ASR mot Googles nya API
- AlibabaNYQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 per 1M tokens
- z-aiNYZ.ai: GLM 5.3 Flash2026-08-2658Intelligens72Kodning
- DeepSeekNYDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 per 1M tokens
- z-aiZ.ai: GLM 5.32026-08-1860Intelligens75Kodning
- obsidianQwen3.8 27B2026-08-1552Intelligens68Kodning
- qwenQwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1253Intelligens69Kodning
- grokSpaceXAI: Grok 4.62026-08-1261Intelligens77Kodning
- metaMeta: Muse Spark 1.22026-08-0557Intelligens72Kodning
- qwenQwen: Qwen3.8 Max2026-08-0358Intelligens72Kodning
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152Intelligens69Kodning
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 per 1M tokens
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463Intelligens78Kodning
- googleGoogle: Gemini 3.6 Flash2026-07-2152Intelligens69Kodning
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137Intelligens49Kodning
- metaMeta: Muse Spark 1.12026-07-1653Intelligens71Kodning
- kimiMoonshotAI: Kimi K32026-07-1560Intelligens76Kodning
- openaiOpenAI: GPT-5.6 Luna2026-07-0952Intelligens71Kodning
Sju dagar och en filosofisk klyfta skiljer de två senaste strömmande tal-till-text-systemen åt. Den 26 augusti 2026 släppte Google Gemini 3.5 Transcribe i publik förhandsvisning: ett värdbaserat, slutet tal-till-text-API prissatt per ljudtoken, med en separat Live-endpoint för realtidssessioner. Den 2 september 2026 laddade Microsoft Research upp VibeVoice-ASR-Streaming-1.5B till Hugging Face under namnrymden microsoft — MIT-licensierade vikter, inget pressmeddelande, inget lanseringsinlägg, och när detta skrivs ingen extern bevakning någonstans. Båda transkriberar tal medan det fortfarande anländer. Nästan allt annat med dem — vem som tillåts köra dem, vad de kostar, vilka bevis som finns för att de fungerar — skiljer sig åt.
Den här sidan jämför de två som de faktiskt existerar idag, vilket innebär att de två sidorna av bevisläget inte är symmetriska. Gemini 3.5 Transcribe är en levande Google-produkt med publicerade tokenpriser och tredjepartssiffror för noggrannhet från Artificial Analysis; det är de siffror som märkts AA nedan. VibeVoice-ASR-Streaming-1.5B är en checkpoint vars modellkort inte publicerar någon ord-felfrekvens och ingen latenssiffra i text överhuvudtaget — kortets utvärdering är en bild, och strömningsfamiljens enda tillkännagivande hittills är en nyhetsrad daterad den 3 september i Microsofts VibeVoice GitHub-repository. Allt på Microsoft-sidan nedan är vad som går att få veta från repositoryt: konfigurationsfilerna, modellkortet och Microsofts egen streamingdokumentation. Ingenting av det har ännu oberoende benchmarkats.
De två modellerna i korthet.
• Vad det är — VibeVoice-ASR-Streaming-1.5B: öppen checkpoint, MIT-licens, självhostad vs Gemini 3.5 Transcribe: värdbaserat API, stängda vikter.
• Lansering — vikter 2 september 2026, repots nyhetsrad 3 september, jämfört med offentlig förhandsvisning 26 augusti 2026 med fullständigt lanseringsmaterial.
• Strömmande form — avger text i block på ~2,9 sekunder med ~0,5 s framförhållning, sessionsstatus förs i en prefixcache jämfört med WebSocket Live-session som faktureras per ljudtoken, med max 10 minuter ljud per session.
• Noggrannhet i tryck — ingen WER- eller latenssiffra publicerad som text jämfört med AA-uppmätt 2,6 % WER på den förinspelade slutpunkten och 4,0 % på Live-slutpunkten.
• Talarutdata — hävdar strömmande vem-sa-vad-attribuering (overifierad) jämfört med ingen talardiarisering och inga tidsstämplar på ordnivå på Live-slutpunkten.
• Hotwords — stöds, via samma kontextprompt som batch-VibeVoice-ASR vs inte en listad funktion i Live-endpointen.
• Kostnad — $0 för vikterna, ~5,6 GB för att själv hosta jämfört med cirka $0,30 per ljudtimme blandat på den förinspelade slutpunkten och ~$0,54 på Live, enligt Googles angivna tokenpriser.

Ett hostat API och en tyst uppladdning, med sju dagars mellanrum.
Gemini 3.5 Transcribe är Googles transkriptionsmodell av ersättningsklass, och den levereras som två produkter. Den förinspelade endpointen, som tillhandahålls via Interactions API, tar emot en hel ljudfil och returnerar en transkription med de förväntade extrafunktionerna. Live-endpointen, gemini-3.5-transcribe-live, körs över en dubbelriktad WebSocket och är den som konkurrerar med VibeVoice-ASR-Streaming-1.5B när det gäller arbetsuppgiftens karaktär: att transkribera en session medan den pågår. Google tillkännagav det på sedvanligt manér: en offentlig förhandsversion lanserades den 26 augusti, prissättningen publicerades på modellsidan och tredjepartstopplistor tog upp den inom några dagar.
Microsofts streamingrelease hade inget av det. Den 2 september skapade Microsofts Hugging Face-konto två checkpoints inom samma minut: VibeVoice-ASR-Streaming-7B och VibeVoice-ASR-Streaming-1.5B. GitHub-förvarets modelltabell listar nu VibeVoice-ASR-Streaming som en familjemedlem, och dess nyhetssektion innehåller raden från den 3 september 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” — men det tillkännagivandet namnger 7B, och 1.5B är det mindre syskonet som släpptes tillsammans med den utan att lyftas fram. När vi kontrollerade en dag efter uppladdningen visade båda checkpoints fortfarande noll nedladdningar.

Vad "streaming" betyder på varje sida
Ordet streaming döljer en verklig designskillnad. Microsofts preprocessorkonfiguration gör VibeVoice-takten konkret: ljudet anländer vid 24 kHz och komprimeras 3 200× till en ström av taltokens med ungefär 7,5 Hz (en token var ~133 ms). Konfigurationen deklarerar sedan ett block på 22 frames och en lookahead på 4 frames — cirka 2,9 sekunder ljud per block, med ungefär en halv sekund framtida ljud som används för att stabilisera det aktuella segmentet. Modellen avger text en gång per upplöst block, och Microsofts dokumentation noterar att kontexten från tidigare block bevaras via KV-cachen, så en lång session behöver inte räknas om från grunden. Aritmetiken finns i konfigurationen; den praktiska konsekvensen är en transkription som växer i ungefär tre sekunders steg, inte i ordvisa delresultat.
Googles Live-endpoint är en annan strömningsform: en dubbelriktad WebSocket-session där ljud faktureras med 25 ljudtokens per sekund, konstruerad för interaktiv användning, men begränsad till 10 minuter ljud per session och – specifikt på Live-endpointen – utan diarisering av talare eller tidsstämplar på ordnivå. För den som jämför de två som direkttranskriberingsmotorer är de avgörande skillnaderna sessionsgränsen (10 minuter på Googles Live-sida, på Microsoft-sidan endast begränsad av din egen GPU och ditt minne), sändningstakten (~3-sekundersblock jämfört med vad WebSocket-sessionen levererar) och extrautdata (talartillskrivning och hotwords som utlovas på Microsoft-kortet, men saknas i Googles Live-funktionslista).
Noggrannhet: ena sidan har siffror, den andra har en bild.
Detta är den största skillnaden i jämförelsen, och det är en skillnad i bevisunderlag, inte nödvändigtvis i kvalitet. Artificial Analysis mäter Gemini 3.5 Transcribe till en ordfelsfrekvens på 2,6 % på den förinspelade slutpunkten och 4,0 % på Live-slutpunkten – det pris du betalar för realtidsleverans syns i felprocenten, vilket är en vanlig och ärlig avvägning för strömmande system. Det är tredjepartssiffror på en neutral topplista, publicerade dagar efter lanseringen.
VibeVoice-ASR-Streaming-1.5B saknar helt jämförbara siffror. Modellkortet innehåller en bild med utvärderingsresultat, men inga numeriska WER-, RTF- eller latenssiffror i löptext – inget som går att citera och inget som går att oberoende verifiera. Microsoft har inte publicerat streaming-accuracy-siffror i textform för vare sig 7B- eller 1.5B-modellen. Den enda numeriska referenspunkten i hela modellfamiljen är modellkortet för batch-modellen VibeVoice-ASR, som rapporterar ett leverantörsdrivet genomsnitt på 7,77 % WER över åtta engelska testset och 2,20 % på LibriSpeech clean – men det beskriver den icke-streamingmodell som inte strömmar, och streamingmodeller brukar typiskt offra lite accuracy för att vinna latens. Tills någon kör streaming-checkpointen genom en offentlig testmiljö är den ärliga slutsatsen att Googles modell är uppmätt och Microsofts inte är det.
Kostnad: per ljudtimme jämfört med per GPU-timme.
Google säljer Gemini 3.5 Transcribe per token, och prissättningen fördelas tydligt mellan de två endpoints. Den förinspelade endpointen listar $2 per 1M ljudinmatningstokens och $12 per 1M textutdatatokens, vilket motsvarar ungefär $0.30 per ljudtimme i genomsnitt. Live-endpointen listar $3.50 per 1M ljudtokens och $21 per 1M texttokens — ungefär $0.54 per ljudtimme i genomsnitt, eller cirka 80% mer än förinspelad, vilket är priset för realtidsleverans. Google fakturerar ljud till 25 tokens per sekund, så tystnad är bara gratis om din klient inte streamar den; återanslutningar, duplicerat ljud och loggning kan alla öka den faktiska räkningen. Det finns en gratisnivå, med förbehållet att innehåll på gratisnivån kan användas för att förbättra Googles produkter.

Microsofts modell prissätts istället i GPU-timmar. Checkpointen på 1,5B är ungefär 5,6 GB bf16-vikter (en Qwen-språkstomme av 1,5B-klass plus ljudtokeniserare och diffusionshuvud – safetensors-metadatan summerar till cirka 3B parametrar), och de dokumenterade sätten att köra den är självhostade: Python-demoerna i microsoft/VibeVoice-repot, eller vLLM-pluginet som Microsoft beskriver för att betjäna OpenAI-kompatibla och WebSocket-endpoints. Det finns ännu inget värdpris eftersom ingen inferensleverantör listar modellen ännu. Kostnadsfrågan handlar helt och hållet om huruvida din egen GPU-tid är billigare än Googles per-timme-pris, vilket den nästan säkert är för alla löpande transkriptionsvolymer – och licensfrågan är separat från kostnadsfrågan, eftersom MIT-vikter är dina att behålla på ett sätt som ingen API-prenumeration är.
De två utesluter inte varandra i en produktionsstack. Det pragmatiska mönstret för ett team som behöver realtidstranskribering idag är att hålla ASR-lagret bakom en slutpunkt så att valet förblir reversibelt: ett routing-API som frontar 200+ modeller till leverantörernas listpriser — utan påslag, så en prisändring från leverantören är live samma dag — med automatisk failover, är exakt det lager som låter dig köra Googles mätbaserade API som standard medan en del av riktig trafik testar VibeVoice-ASR-Streaming-1.5B i samma ögonblick som en leverantör hostar den. Det är OrcaRouters modell, och det är det lågrisksätt att anta en checkpoint vars noggrannhet ingen har verifierat ännu.
Vem ska välja vilken
Välj Gemini 3.5 Transcribe om du vill ha ett transkriptions-API som fungerar idag, med publicerad noggrannhet, förutsägbart pris per timme och ingen GPU att passa — och särskilt om ditt ljud inte finns bland de tio språk som Microsoft listar, eller om du behöver den förinspelade endpointens diarisering och ordnivå-tidsstämplar för filtranskription. Taket på 10 minuter för Live-sessioner är en verklig begränsning att testa mot ditt användningsfall innan du förbinder dig till det för livesessioner.
Välj VibeVoice-ASR-Streaming-1.5B om du själv hostar, om du vill ha vikterna och den datakontroll som MIT-licensen ger, om du behöver obegränsad sessionslängd, eller om strömningsutdata med vem-sa-vad och hotwords är funktioner du specifikt vill utvärdera. Budgetera för en installation från källkod, ~5,6 GB vikter på en NVIDIA GPU, och din egen utvärderingsgrind — det finns inget riktmärke att förlita sig på, så frågan om noggrannhet är din att besvara med ditt eget ljud.
En veckas dom: Google levererade den uppmätta produkten och Microsoft levererade det intressanta vadet. Gemini 3.5 Transcribe är det säkrare standardvalet och det med siffror från tredje part bakom sig; VibeVoice-ASR-Streaming-1.5B är det öppna, självhostade, helt overifierade alternativet. Det som gör valet billigt är att det inte behöver vara permanent – håll ASR-slutpunkten utbytbar, och en checkpoint som lanseras utan ett enda riktmärke kan förtjäna eller förlora din trafik baserat på bevisen från dina egna transkriptioner.
