MAI-Transcribe-2-Streaming vs Gemini 3.5 Transcribe Live: Samma $9, olika avvägning

MAI-Transcribe-2-Streaming och Gemini 3.5 Transcribe Live kostar lika mycket och bygger på motsatta teorier om vad en strömmande transkriberare är till för. Båda landar på ungefär 9,00 USD per 1 000 minuter strömmat ljud. Microsofts modell, som släpptes den 1 oktober 2026, är ett precisionsinstrument: en uppgiven strömmande ordfelsfrekvens på 2,5 % vid 0,13 sekunder till slutlig transkription, först i noggrannhet för både slutliga och partiella transkriptioner enligt Microsofts egen uppgift, mätt enligt Artificial Analysis metodik för strömning men ännu inte plottad som en rad på den resultattavlan. Den andra modellen, i offentlig förhandsversion sedan den 26 augusti 2026 och som tillhandahålls via Live API, är ett täckningsinstrument: 85+ språk med växling mitt i strömmen, en gratisnivå och en strömmande ordfelsfrekvens på 4,00 % vid 0,40 sekunder, siffran som Artificial Analysis mäter för den. Ingen av dem är det självklara valet, och anledningen är att de egentligen inte konkurrerar om samma arbetsbelastning.

Här är direktjämförelsen så som siffrorna faktiskt lyder — leverantörsrapporterade siffror märkta, tracker-siffror med angiven källa, och de delar där en modell vinner på en dimension som den andra inte ens konkurrerar i.

Enradsversionen

• Noggrannhet och latens – MAI-Transcribe-2-Streaming, enligt de publicerade siffrorna. Microsoft hävdar 2,5 % streaming-WER vid 0,13 sekunder till slutlig transkription, först i noggrannhet för både slutliga och partiella transkriptioner, och 2,5 % på den första partiella vid 0,12 sekunder. Mot detta har Artificial Analysis Gemini 3.5 Transcribe Live på 4,00 % vid 0,40 sekunder. Microsofts påstådda försprång är 1,5 punkter och ungefär tre gånger snabbare att nå ett slutligt resultat. Haken är att trackern ännu inte har plottat MAI-Transcribe-2-Streaming själv – brädets nuvarande ledare är Grok Voice Transcribe 2.0 på 2,73 % och 0,49 sekunder, med Muse Voice Transcribe på 3,06 % och 0,16 sekunder – så 2,5 % är en leverantörssiffra som läses mot ett fält som trackern faktiskt mäter. Det är inte jämnt på den axel som båda modellerna publicerar, men bara en sida av den är oberoende publicerad.

• Språkbredd — Gemini 3.5 Transcribe Live. 85+ språk med automatisk identifiering och möjligheten att byta språk mitt i en pågående strömning utan att starta om sessionen, vilket är Googles främsta säljargument för Live API. MAI-Transcribe-2-Streaming täcker 60 språk med automatisk kontinuerlig språkidentifiering. Microsofts golv är högre; Googles tak är bredare, och gapet på 25 språk ligger mest i språk där en enspråkig streamingmodell inte går att använda alls.

• Sessionsform — Gemini 3.5 Transcribe Live, och den här har både för- och nackdelar. Live API är en WebSocket-session begränsad till 10 minuter, vilket passar bra för en tur med en röstagent men är besvärligt för ett timslångt möte; Microsoft publicerar ingen motsvarande sessionsgräns för sin strömmande modell, vilket spelar roll om din arbetsenhet är ett samtal, inte en konversationstur.

• Ingångskostnad — Gemini 3.5 Transcribe Live. Det finns en gratisnivå, och Googles sammanvägda pris landar på cirka 0,009 USD per minut med den tokenbaserade prismodellen. Microsofts 0,54 USD per ljudtimme är ett introduktionspris som Microsoft säger gäller till slutet av året, utan att något standardpris har offentliggjorts — samma struktur som dess batchlansering i september.

Varför noggrannhetsgapet är större än det ser ut

Ett gap på 1,5 punkter i ordfelsfrekvens låter som en avrundningsskillnad tills man räknar på det. Vid 4,00 % strömmande WER får Gemini 3.5 Transcribe Live ungefär 40 ord fel per 1 000; vid Microsofts påstådda 2,5 % får MAI-Transcribe-2-Streaming 25. I de volymer en realtidspipeline producerar – en supportorganisation som hanterar 5 000 timmars samtal i månaden är 300 000 minuter, över 45 miljoner ord i samtalstempo – är den spridningen miljontals felaktiga ord årligen, koncentrerade till de entiteter som nedströms system är beroende av: kontonamn, ärendenummer, doseringar, adresser.

Latensskillnaden är den svårare att sälja. 0,13 sekunder kontra 0,40 sekunder efter avslutat tal är märkbar i en ström för direkttextning – under omkring 0,2 sekunder uppfattas som samtidigt, och en tredjedels sekund uppfattas som att transkriptionen jagar talaren – men den är inte märkbar i en agentstödspanel som uppdateras i mänsklig tidsskala. Om din konsument är en person som läser med, är Microsofts latensförsprång produkten. Om din konsument är en modell som får den slutliga transkriptionen när turen avslutas, är det en siffra.

Båda siffrorna har samma förbehåll, och det är värt att säga en gång: detta är siffror från en enda körning från en tracking-tavla som är 37 modeller djup, och gapet mellan första och tredje plats på den tavlan är under en poäng. En ny körning kan kasta om toppen av streaming-topplistan på ett sätt som ett tvåpoängsavstånd på batch-tavlan inte kan. Inte heller finns Microsofts 2,5 % ens med på tavlan ännu – det är ett leverantörspåstående mätt enligt trackerns metodik, vilket är en annan sak än en rad som trackern publicerar.

Gränserna är där beslutet faktiskt bor

Funktionsbegränsningar skiljer dessa två åt snabbare än prestandatester gör, och de går i motsatta riktningar.

Gemini 3.5 Transcribe Live har tre dokumenterade begränsningar: en sessionsgräns på 10 minuter för Live API, ingen talardiarisering och inga tidsstämplar på ordnivå. Den första är arkitektonisk — strömning över en WebSocket-session har en inbyggd gräns — och det innebär att långformig live-transkribering måste sammanfogas över sessioner, med hanteringen av skarvarna lämnad till dig. De två andra är absoluta: om din produkt behöver tillskriva tal till en talare, eller placera ett ord vid en tidsstämpel för sökning eller undertextsynkronisering, gör Gemini 3.5 Transcribe Live det inte till något pris.

MAI-Transcribe-2-Streamings begränsningar är mindre dokumenterade, vilket i sig är information. Microsoft gör inget diariseringsanspråk för streamingmodellen och inte heller något anspråk på ordtidsstämplar; batchversionen av MAI-Transcribe-2 inkluderar diarisering och returnerar tidsstämplar på ordnivå, men det är batchprodukten, och att anta att streaming-SKU:n ärver dem är exakt den typ av slutledning som lanseringsmaterial finns för att förhindra. Vad Microsoft däremot gör anspråk på är 60 språk med kontinuerlig språkidentifiering och placering på Pareto-fronten avseende noggrannhet kontra latens — båda leverantörsutsagor som trackerns data stämmer överens med.

Så den ärliga funktionsbedömningen är: ingen av strömningsmodellerna publicerar diarisering eller ordtidsstämplar. Gemini 3.5 Transcribe Live har en publicerad sessionsgräns och en gratisnivå; MAI-Transcribe-2-Streaming har ett publicerat antal språk och ingen publicerad gräns. Om dina krav omfattar diarisering är ingendera av dessa svaret, och då tittar du på batchtranskribering med ett strömningslager påmonterat framför.

Vad prispariteten egentligen säger dig

Att två leverantörer når samma 9 $ per 1 000 minuter från motsatta håll är det mest intressanta faktumet i den här jämförelsen. Google kom dit genom tokenbaserad prissättning i en Live API-session: ljud in till 3,50 $ per miljon tokens, text ut till 21 $ per miljon, och en ungefärlig förbrukning på 175 texttokens per minut, vilket sammanvägt blir cirka 0,009 $ per minut. Microsoft kom dit genom att ange ett fast pris på 0,54 $ per ljudtimme för en modell i en familj vars batchsyskon ligger på 0,10 $. Den ena är en mätbaserad realtidssession; den andra är ett fast minutpris med en introduktionsrabatt.

De strukturerna beter sig olika när du skalar. En fast avgift är förutsägbar och enkel att budgetera; en tokenmätt session förändras med hur mycket modellen svarar och hur länge sessionen ligger öppen inaktiv. För en pipeline med hög volym är den fasta avgiften den vänligare fakturan; för en prototyp eller en funktion med låg volym är gratisnivån och fakturering per token den vänligare ingången.

Det som ingen av strukturerna förändrar är lagret ovanför transkriptet. Vilken modell som än producerar det, är en livetranskription indata till sammanfattning, klassificering, redigering och routning, och dessa steg har sina egna kostnads- och kvalitetskurvor – vanligtvis körs de över flera modeller snarare än en. Det är lagret som OrcaRouter täcker: ett API över 200+ modeller, leverantörers listpriser vidarebefordrade med 0 % påslag, automatisk redundansväxling, och en routnings-DSL som kan skicka ett transkript genom olika modeller per arbetsbelastning. Varken MAI-Transcribe-2-Streaming eller Gemini 3.5 Transcribe Live finns med i den listan – de tillhandahålls via Microsofts respektive Googles egna talstackar – och poängen är inte att routa dem, utan att hålla allt nedströms dem portabelt.

Vilken ska man välja?

Välj MAI-Transcribe-2-Streaming när noggrannhet och tid till slutligt resultat är produkten: direkttextning som en människa läser, realtidsbedömning av efterlevnad eller kvalitet där en felhörd entitet medför en kostnad, eller långa sessioner som Geminis tak på 10 minuter skulle tvinga dig att skarva ihop. Välj Gemini 3.5 Transcribe Live när täckning är produkten: en global driftsättning över språk du inte kan räkna upp i förväg, språkbyte mitt i en ström, eller en prototyp där gratisnivån och fakturering per token tar bort bindningen. Team som behöver båda är inte låsta – de två är olika API:er med olika sessionsmodeller, och den ärliga arkitekturen är att routa efter arbetsbelastning i stället för att standardisera på en enda.

Det påstående som är värt att ta med sig från den här jämförelsen är inte att Microsoft vann. Det är att strömmande transkribering nu har två trovärdiga alternativ i framkant med identiskt pris, vilket innebär att beslutet har flyttats från "vad som är tillgängligt" till "vad just den här specifika arbetsbelastningen behöver." Det är ett bättre problem att ha.