Grok Voice Transcribe 2.0 mot Granite Speech 5.0 470M TurboCTC: 12 600× realtid möter en halv sekund

Granite Speech 5.0 470M TurboCTC transkriberar ungefär 3,5 timmars ljud varje sekund på en enda H200, och Grok Voice Transcribe 2.0 returnerar en första deltranskription 0,49 sekunder efter att du slutat prata. Dessa två siffror ställs sida vid sida i jämförelseinlägg som om de vore samma sorts mätning, och de är inte på långa vägar samma sorts mätning — den ena är en genomströmningssiffra för batchade datacenter utan någon kopplad latens, den andra är en latenssiffra för en modell vars genomströmning ingen har publicerat. IBM släppte Granite Speech 5.0 470M TurboCTC den 25 augusti 2026 under Apache 2.0, genom att helt ta bort språkmodellens avkodare och avkoda med ett enda icke-autoregressivt CTC-pass. SpaceXAI släppte Grok Voice Transcribe 2.0 den 18 september 2026 som ett hanterat API till $0,10 per ljudtimme för batch och $0,20 per timme för strömning. De är båda utmärkta transkriberingsmodeller som löser motsatta halvor av samma problem, och att välja mellan dem är enklare när man slutar jämföra siffrorna direkt.

12 600× realtid, och de ord som modifierar det

Granite-siffran är 12 600 RTFx, uppmätt på en enda NVIDIA H200 med batchad inferens – IBMs siffra, rapporterad vid lanseringen och som inte har oberoende reproducerats sedan dess. RTFx är ett förhållande mellan ljudlängd och bearbetningstid, så 12 600 innebär ungefär 3,5 timmars ljud per sekund i väggklockstid. IBMs egen formulering är att detta är mer än 20 gånger genomströmningen hos tidigare utgåvor av Granite Speech, vilket är påståendet som faktiskt spelar roll här: snabbhetsvinsten kom från att ta bort arbete, inte från att lägga till hårdvara.

Vad det inte är är ett latensvärde. Ett batchat jobb som gör klart 3,5 timmar ljud per sekund kan ändå ta lång tid på sig att returnera den första token i vilken enskild fil som helst, beroende på hur batchen sätts samman och hur mycket ljud du matar den med innan den startar. IBM publicerar inga latenssiffror alls för TurboCTC. På far-field-topplistan är de två checkpointarna de två snabbaste posterna, men genomströmningen där mättes på en enda NVIDIA L4, vilket är en datacenternära accelerator och inte en telefon.

Anledningen till att detta spelar roll är att modellen uttryckligen är positionerad för bärbara datorer, telefoner och edge-enheter – IBMs egen formulering – och ingen har publicerat prestanda för en enskild ström på någon av dessa. Tills någon gör det bör du betrakta "12 600×" som ett påstående om hur billigt du kan beta av en backfill på hyrda GPU:er, vilket är ett genuint värdefullt och välunderbyggt påstående, och inte som ett påstående om hur snabbt en användare får tillbaka en mening.

Vad IBM tog bort, och vad det kostar dig

TurboCTC är en design med enbart encoder: en 16-lagers Conformer-akustisk encoder tränad med CTC, som avkodas girigt i en enda icke-autoregressiv genomkörning, med ett delordsutdataskikt på 16 384 enheter. Det finns ingen språkmodell i loopen. Det är där hastigheten kommer ifrån, och det är också där kapacitetsnedskärningarna kommer ifrån, och de är inte små. Jämfört med tidigare Granite Speech-modeller tar TurboCTC bort talöversättning, tar bort nyckelordsbiasering och levereras utan tidsstämplar eller interpunktionverktyg.

Ställ det mot vad den hanterade modellen inkluderar till dess listpris, och affärens utformning blir konkret:

• Biasering av nyckeltermer — Granite Speech 5.0 470M TurboCTC har ingen sådan funktion, jämfört med upp till 100 nyckeltermer per begäran i Grok Voice Transcribe 2.0

• Tidsstämplar på ordnivå — medföljer inte TurboCTC kontra ingår med konfidenspoäng

• Talöversättning — fanns i tidigare Granite Speech-modeller, borttagen här kontra inte erbjuden i något av fallen

• Språktäckning — endast engelska vs automatisk identifiering över en brett flerspråkig indatamängd med formateringsstöd på 25 språk

• Diarisering — ett separat problem du löser själv vs inkluderat i förfrågningspriset

• Kanaler – en ström per genomgång jämfört med upp till åtta ljudkanaler i en förfrågan

• Textnormalisering – ingen kontra invers textnormalisering som omvandlar talade datum, valutor och telefonnummer till skriftlig form

• Driftsättning — vikter du laddar ner och kör mot en hanterad slutpunkt i us-east-1

Läs den listan som en beskrivning av två olika produkter snarare än ett poängkort. Att ta bort diarisering, biasering och normalisering är vad som köpte genomströmningen. En batchåterfyllning av 40 000 samtalsinspelningar till ett sökindex behöver inte tidsstämplar eller talarturer – den behöver vara billig och den behöver bli klar – och för det jobbet är de saknade funktionerna inte saknade, de är borttagen vikt.

Det omvända gäller för allt som är live. Om du bygger en röstagent är en lista med nyckeltermer hur du får "Kubernetes", "Granola" och kundnamn stavade korrekt, och en transkriberare utan biasmekanism kommer att få dem fel varje gång, utan något sätt att åtgärda det annat än finjustering, vilket är ett annat projekt med en annan budget. Att just den funktionen saknas diskvalificerar TurboCTC från vissa arbetsbelastningar och är irrelevant för andra, vilket är anledningen till att modelljämförelsen är mindre användbar än en arbetsbelastningsjämförelse.

Noggrannhetsjämförelsen som inte kan göras på ett tillfredsställande sätt

IBM rapporterar en aggregerad ordfelsfrekvens på 5,00 % för Apache 2.0-checkpointen och 4,85 % för det icke-kommersiella syskonet på Open ASR Leaderboard, över offentliga engelska kortformatiga set. Det är batch-siffror på en leaderboard vars utvärderingar omfattar AMI och Earnings22 samt långformatiga konversationsset, och de är leverantörsrapporterade – körda genom leaderboardens verktyg men ännu inte införlivade i den officiella tabellen, som även omfattar privata testset. Den publicerade uppdelningen per set på modellkortet är värd att läsa, eftersom genomsnittet döljer mycket: LS Clean 1,42 %, LS Other 2,66 %, SPGISpeech 3,18 %, Voxpopuli-Cleaned-AA 4,88 %, Earnings22-Cleaned-AA-chunked 6,69 %, AMI-Cleaned 7,52 % och Gigaspeech-Cleaned 8,67 %, med ett genomsnitt på exakt 5,00 %. Samma kort anger ett genomsnittligt RTFx på 13 042,98 uppmätt på en H200 – högre än siffran 12 600 som IBMs lanseringsinlägg använde, och båda siffrorna är företagets egna, från samma vecka, på samma hårdvara.

Grok Voice Transcribe 2.0:s siffra på 2,7 % för slutlig transkription är inte ett jämförbart mått. Den kommer från AA-WER Streaming-resultattavlan från Artificial Analysis, en viktad sammansättning av AA-AgentTalk med 50 %, VoxPopuli med 25 % och Earnings22 med 25 % – ungefär åtta timmar agentviktat engelskt samtalsljud, mätt via ett streaminggränssnitt. Olika dataset, olika viktning, olika driftläge. Att ställa 2,7 % bredvid 5,00 % och dra slutsatsen att den hanterade modellen är ungefär dubbelt så träffsäker är det enskilt vanligaste misstaget man kan göra i den här jämförelsen.

Det som kan sägas ärligt är snävare och fortfarande användbart. Båda modellerna är starka på det ljud som var och en mättes på. Grok Voice Transcribe 2.0 leder en oberoende resultattavla för streaming som även andra modeller mäts på, vilket gör dess placering kontrollerbar även om dess exakta värde inte är överförbart. Granite Speech 5.0 470M TurboCTC har ett aggregerat WER på de standardöppna ASR-setten och, separat, ett fjärrfältsresultat där den icke-kommersiella checkpointen rankas som femma i noggrannhet och Apache-versionen som nia – mätt på brusigt och efterklangsrikt tal, vilket är det svåraste villkoret i uppsättningen och möjligen det mest ärliga i någon av modellernas siffror.

Om ditt ljud är rent uppläst engelskt tal är noggrannhetsskillnaden mellan dessa två troligen mindre än placeringarna på resultattavlan antyder. Om det är brusigt, präglat av brytning, telefoniskt eller icke-engelskt säger ingen av tavlorna dig särskilt mycket, och din egen testmängd är det enda instrument som gör det.

Fria vikter mot $1,67 i timmen

Kostnadsjämförelsen är det enda stället där dessa två modeller verkligen är lätta att skilja åt, och siffran som folk vanligtvis anger är fel åt båda hållen.

• Batchtranskribering — Grok Voice Transcribe 2.0 för 0,10 USD per ljudtimme, eller cirka 1,67 USD per 1 000 minuter jämfört med Granite Speech 5.0 470M TurboCTC utan licenskostnad, plus GPU-tid

• Streaming — 0,20 USD per ljudtimme, cirka 3,33 USD per 1 000 minuter jämfört med att IBM inte har publicerat någon hostad streamingväg

• Licens — ett kommersiellt API utan vikter vs. Apache 2.0 för huvudcheckpointen och CC-BY-NC-SA-4.0 för den mer exakta icke-kommersiella varianten

”Gratis” gör en hel del arbete i den första raden. En encoder-only-modell på 470M är tillräckligt liten för att köras på blygsam hårdvara — det är själva poängen med designen, och anledningen till att IBM tränade den i tio dagar på åtta H100:or och släppte den mot `transformers>=5.16.0` med en WebGPU-demo — men någon betalar fortfarande för GPU:n, serving-stacken, autoskalningen, omförsöken och jourrotationen. Vid små volymer är priset för den hanterade tjänsten oftast lägre än ingenjörstiden. Vid stora, stabila volymer vinner vägen med hyrd hårdvara, och brytpunkten är en funktion av din utnyttjandegrad snarare än mängden ljud: en GPU som du håller sysselsatt är billig per timme, och en som du håller varm för trafiktoppar är det inte.

En licensdetalj är värd att påpeka innan någon bygger arkitekturen runt den. Den mer exakta av de två checkpointarna, den vid 4,85 % WER, är den icke-kommersiella under CC-BY-NC-SA-4.0. Apache 2.0-checkpointen är den vid 5,00 %, och det är den du får leverera i en produkt. Det är en noggrannhetsskillnad på 0,15 punkter som man byter bort mot rätten att överhuvudtaget använda modellen, och det innebär också att varje jämförelse som anger 4,85 % för "Granite Speech 5.0" och sedan diskuterar kommersiell driftsättning anger fel checkpoint.

Beslutsregeln

Tre frågor skiljer dessa två modeller åt snabbare än någon benchmark-tabell.

Används transkriptionen live, medan talaren fortfarande talar? Om ja är TurboCTC inte kandidaten — inte för att den är långsam, utan för att den saknar streaminggränssnitt och partiell utdata, och en partiell transkription är ett annat arkitektoniskt åtagande än en snabb batchavkodning. Om nej blir genomströmningsfördelen hela historien, och IBM:s modell är mycket svår att slå när det gäller kostnad per timme bearbetat ljud.

Behöver arbetet domänvokabulär? Om ja vinner en modell med biasning som standard, och avsaknaden av biasning av nyckeltermer i TurboCTC är diskvalificerande snarare än bara besvärande. Om nej betalar du för en funktion som du inte kommer att använda på den hanterade sidan.

Är ljudet engelskt inläst tal på hyfsad hårdvara? Om ja, är båda starka och valet handlar om drift. Om nej, är båda korten oinformativa och bara din egen utvärdering spelar roll.

Hur det än landar är driftlagret där det här beslutet blir billigt. OrcaRouter lägger 200+ modeller bakom en enda OpenAI-kompatibel nyckel med automatisk failover mellan leverantörer, så att en hanterad talendpoint i en enda region som har en dålig eftermiddag inte längre blir ditt avbrott, och leverantörslistpriset förs vidare med 0 % påslag — vilket innebär att en leverantörsprisändring eller en ny checkpoint är live på vår sida samma dag. För en arbetsbelastning där rätt svar verkligen är oklart tar det bort kostnaden för att ha fel: benchmarka båda mot ditt eget ljud bakom en enda endpoint, behåll den som vinner och ändra modellsträngen när nästa släpps.

Kortversionen: Granite Speech 5.0 470M TurboCTC är det bättre svaret på "transkribera allt vi någonsin har spelat in, billigt, på hårdvara vi kontrollerar", och Grok Voice Transcribe 2.0 är det bättre svaret på "transkribera detta i takt med att det händer, korrekt, utan att vi kör serveringsstacken". 12 600×-rubriken och 0,49-sekundersrubriken är båda sanna och ingen av dem är bevis för den andra.