Ming-3.0-audio-tiny vs VibeVoice-ASR-Streaming 1.5B: vijf streepjes tegen een stream met sprekerattributie

Open de herkenningsafbeelding in de Hugging Face-repository van Ming-3.0-audio-tiny en scrol naar beneden. Vijf rijen — sprekerdiarisatie en geconcateneerde minimum-permutatiefout voor AISHELL-4, AliMeeting en AMI — hebben een streepje in de tiny-kolom. Geen slecht getal. Een lege cel. De leverancier mat de grotere variant op alle vijf en weigerde de kleine te meten. Open nu de modelkaart voor VibeVoice-ASR-Streaming 1.5B en lees het eerste punt: het transcribeert wie wat zegt, continu, terwijl de spraak binnenkomt. Dat zijn dezelfde vijf rijen, omgekeerd. Het ene model publiceert bijna alles behalve sprekerattributie; het andere bestaat vooral om dat te publiceren. De gedocumenteerde AI-fouten en agent-incidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waar elk item zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistvlag bevat.

Geen van beide is onafhankelijk gescoord. Dat maakt hier minder uit dan gewoonlijk, omdat deze confrontatie wordt beslist door een ontwerpbeslissing en niet door een getal: wat er gebeurt wanneer de audio maar blijft binnenkomen. Ming-3.0-audio-tiny is een bestandsmodel met een groot venster en optionele spraakuitvoer. VibeVoice-ASR-Streaming 1.5B is een streammodel dat ongeveer elke drie seconden tekst uitzendt en elk segment van een sprekerlabel voorziet. Als je workload een opname is, concurreren ze. Als je workload een ruimte is, doet slechts één van hen een poging.

Wat "streaming" kost in de config

Microsofts repository is ongewoon duidelijk over zijn eigen latencybudget, waardoor de afweging controleerbaar is in plaats van marketing. De akoestische en semantische tokenizers zijn causaal en werken met 3.200× compressie op een invoer van 24 kHz, dus de tokenstroom is ongeveer 7,5 tokens per seconde audio. De streamingwrapper bundelt 22 tokenframes per chunk met 4 frames lookahead: 22 gedeeld door 7,5 is ongeveer 2,9 seconden per afgifte, en 4 gedeeld door 7,5 is ongeveer een halve seconde toekomstige audio die het model mag zien voordat het zich vastlegt.

• Uitzendcadans — ongeveer 2,9 seconden; de lookahead is het onderdeel dat nauwkeurigheid oplevert ten koste van latentie.

• Backbone — een decoder uit de Qwen2-familie, 28 lagen, 1.536 verborgen eenheden, 12 aandachtskoppen met 2 key-value-koppen, venster van 64.000 tokens.

• Grootte — drie safetensors-shards met een totale omvang van 5,63 GB. Dat zijn geen 1,5 miljard parameters; 5,63 GB bij bf16 komt eerder neer op ongeveer 2,8 miljard, en de 1,5B in de naam kun je het beste opvatten als de taalbackbone in plaats van de hele stack.

• Talen — tien: Chinees, Engels, Frans, Duits, Italiaans, Japans, Koreaans, Portugees, Russisch, Spaans.

• Extra's — aangepaste hotwords die als context worden doorgegeven, en een sprekerlabel dat aan elk geproduceerd segment wordt gekoppeld.

• Datering — repository aangemaakt op 2 september 2026 om 15:51 UTC, voor het laatst gewijzigd de volgende ochtend. Alleen aangekondigd via een nieuwsregel in de VibeVoice GitHub README, oftewel nauwelijks aangekondigd.

Dat venster van 64K is het getal dat je tegenover de 131.072 van Ming moet leggen. Het klinkt als de helft van de capaciteit, maar het is niet hetzelfde soort capaciteit. Een streamingmodel hoeft geen uur vast te houden, omdat het de afgelopen negenenvijftig minuten al heeft opgeschreven. Het venster is werkgeheugen voor het huidige chunk plus alle dialoogcontext die het model meeneemt. De 131K van Ming is de tegenovergestelde gok: alles live houden en erover redeneren.

Mings gok, en wat die oplevert

Het verkoopargument van het kleine model is niet de herkenningsnauwkeurigheid — in de eigen tabellen van inclusionAI staat het op Chinees 0,34 punt achter op zijn grotere broer (3,79 tegen 3,45 tekenfout) en op dialecten 0,89 achter (10,29 tegen 9,40). Het verkoopargument is dat één checkpoint herkenning, begrip, redeneren en spraak doet in dezelfde forward pass, over een venster dat lang genoeg is om de vraag "wat zei ze in de eerste tien minuten" te kunnen stellen.

De audio-intelligentiecijfers zijn respectabel voor de grootte en vormen de reden om het boven een pure transcriber te verkiezen: MMAU 75.90, MMAR 67.70, MMSU 73.06, BigBenchAudio 99.20, MuchoMusic 58.07 voor muziek. Die zijn allemaal door de leverancier uitgevoerd, met asterisken bij de zelfgeëvalueerde rijen, en de kaart vermeldt dat de vergelijkingsmodellen zijn gereproduceerd met inclusionAI's eigen prompts en decoding. Lees ze als een ontwerpopdracht.

Wat de tabellen je niet vertellen, is wie er sprak. Dat is het gat dat de vijf streepjes markeren, en het is structureel in plaats van toevallig. Een model dat vragen over een opname beantwoordt, heeft geen segmentatie per spreker nodig om ze te beantwoorden; een model dat een transcript voor een vergadering produceert, wel. Ming kan waarschijnlijk via prompting tot iets als sprekerlabels worden gebracht, en de uitgelichte vermelding op de kaart over "opnames met meerdere sprekers" suggereert dat het dicht bij het probleem is getraind. Maar "waarschijnlijk" doet het werk van vijf ongepubliceerde rijen.

Twee pijplijnen, eerlijk getekend

Stel je voor dat dezelfde opname van negentig minuten door elk ervan gaat.

Met VibeVoice-ASR-Streaming 1.5B komt audio binnen in blokken van ongeveer drie seconden en vertrekt tekst in hetzelfde ritme, waarbij elk segment een spreker meekrijgt. Je kunt het live weergeven. De prijs daarvan is dat elke beslissing min of meer lokaal is: het model keek een halve seconde vooruit en naar welke context het ook behoudt, dus een spreker die vier seconden pauzeert, kan terugkomen met een ander label, en een naam die op minuut twee wordt geïntroduceerd, is alleen terug te halen via het hotwords-mechanisme, dat jij aanlevert. Cross-chunk-consistentie is het ding om te testen en het ding dat de kaart niet kwantificeert.

Met Ming-3.0-audio-tiny komt het bestand binnen, staat het geheel in de context, en komt het antwoord wanneer het komt. Consistentie tussen chunks is geen risico, omdat er geen chunks zijn — tot aan het venster. De kosten zijn dat er niets beschikbaar is totdat het model klaar is, en de geheugenreservering is afgestemd op het volledige venster: het referentie-ASR-profiel houdt 0,92 van een kaart bezet met een batch van 32,768 tokens. Je kunt een lagere waarde instellen voor max_model_len; je kunt het niet laten streamen, omdat er geen streamingpad in de repository is.

• Latentieprofiel — VibeVoice: continu, ~3 s achter. Ming: één antwoord aan het einde.

• Naamsvermelding — VibeVoice: per segment, bewust. Ming: ongepubliceerd.

• Context — VibeVoice: een werkvenster van 64K plus zijn eigen transcript. Ming: 131.072 posities, ruwweg drie uur audio volgens de rekensom op de encoder, als de processor één continue stroom voedt.

• Uitvoer — VibeVoice: tekst. Ming: tekst, of tekst plus gesynthetiseerde spraak via een optionele Talker op een tweede GPU.

• Hardware — VibeVoice: een checkpoint van 5,63 GB, dus één gangbare kaart. Ming: 17,74 GB aan Thinker, één kaart voor tekst, twee voor spraak.

De licentie en het papierwerk zijn hetzelfde, en dat is ongewoon.

Beide zijn MIT. Beide zijn geruisloze releases. Beide zetten de gewichten online voordat de documentatie was bijgewerkt, en beide steunen op een GitHub-repository die niet naar het checkpoint is vernoemd: de deploymentprofielen van Ming staan in inclusionAI/Ming-3.0-audio-flash, en de gebruiksinstructies van VibeVoice staan in microsoft/VibeVoice naast het 7B-zusje.

De verschillen zitten in wat elke repository je vertelt. Microsoft levert een technisch rapport — arXiv 2609.02812 — en een resultatenfiguur in de kaart, dat een afbeelding is in plaats van een tabel, dus de cijfers zijn niet te extraheren en er wordt in de tekst geen foutpercentage per taal vermeld. inclusionAI levert drie benchmarkafbeeldingen, eveneens afbeeldingen, plus een kaart die zijn eigen zwakke punten slechts impliciet benoemt door cellen leeg te laten. Geen van beide leveranciers geeft je een getal dat je in een spreadsheet kunt plakken zonder het handmatig over te typen.

Eén asymmetrie is het vermelden waard voor iedereen die inkopen doet: de Hugging Face-repository van Ming bevat geen LICENSE-bestand, alleen een link in de metadata van de kaart naar een licentie in de andere repository. Op de kaart van VibeVoice staat MIT in de metadata en de repository bevat het licentiebestand. Beide beweringen zijn waar; slechts één ervan bevindt zich in het artefact.

Waarvoor een router hier wel en niet dient

OrcaRouter bedient geen van beide modellen. Ming-3.0-audio-tiny is een checkpoint en VibeVoice-ASR-Streaming 1.5B is een checkpoint; geen van beide staat in onze catalogus, en niets in dit stuk is een aanbod om ze te hosten. De plek van de router in een pipeline als deze is stroomafwaarts van de transcriptie en stroomopwaarts van de beslissing: de oproep samenvatten, de toezeggingen eruit halen, classificeren of het segment een mens nodig heeft, de delen vertalen die niet in de werktaal waren. Die aanroepen zijn tekst, en één endpoint voor meer dan 200 modellen tegen 0% opslag — de lijstprijs van de provider wordt doorgegeven, zodat een prijswijziging van een leverancier dezelfde dag bij ons terechtkomt — scheelt een contract per leverancier in de build. Automatische failover is precies de functie die ertoe doet wanneer een transcriptietaak van twee uur om 2 uur 's nachts de uitvoer ergens betrouwbaar moet afleveren.

Wat een router niet zal doen, is twee sprekerlabels die niet overeenkomen met elkaar verzoenen, of beslissen of Mings ontbrekende diarisatierijen een echte zwakte zijn of een ongemeten zwakte. Dat is een taak voor je eigen audio.

De test die hen in één middag scheidt

Neem twintig minuten op met drie personen, van wie er één twee keer door de anderen heen praat en één via een laptopmicrofoon spreekt. Haal het door VibeVoice-ASR-Streaming 1.5B met de hotwoordenlijst gevuld met de drie namen, want dat is precies het mechanisme dat het model hiervoor biedt. Haal hetzelfde bestand door Ming-3.0-audio-tiny met de gevalideerde prompt die vraagt om het taallabel, een tab, en dan de transcriptie — en vraag het daarna, in een tweede beurt, om elke zin aan een spreker toe te schrijven.

Scoor vier dingen: hoeveel sprekerwisselingen het eerste model goed had, of een sprekerlabel midden in de opname omklapte, of de toewijzing van het tweede model stabiel was over het hele bestand, en welke uitvoer je met de hand sneller zou kunnen corrigeren. De laatste is geen benchmark en zal je productie-ervaring beter voorspellen dan de cijfers van beide leveranciers.

En houd de streepjes in gedachten terwijl je dat doet. Een leverancier die een dialecttabel tot op twee decimalen publiceert en vijf diarisatiecellen leeg laat, heeft je iets specifieks verteld over waar zijn vertrouwen ophoudt. Microsoft heeft van zijn kant een cijfer in plaats van een tabel gepubliceerd en het aan jou overgelaten om het plaatje te lezen. Geen van beide heeft je een getal gegeven dat een buitenstaander heeft gecontroleerd.

Waar elk ervan eigenlijk thuishoort

Live ondertiteling, monitoring van callcenters, vergaderassistenten die bij elke regel een naam nodig hebben: VibeVoice-ASR-Streaming 1.5B is voor dat gebruik gebouwd, en met 5,63 GB draait het op hardware die je waarschijnlijk al hebt. Compliance-review van een archief, "vind elke vermelding van de schikking in deze veertig opnames", alles waarbij de vraag na de audio komt in plaats van tijdens het afspelen: het enkele grote venster en de begripscores van Ming-3.0-audio-tiny passen beter, en de ontbrekende diarisatieregels doen er niet meer toe als niemand heeft gevraagd wie er sprak.

De fout zou zijn om Ming te kiezen voor een streamingtaak omdat 131.072 het dubbele is van 64.000, of om VibeVoice te kiezen voor een redeneertaak omdat 1,5B goedkoper klinkt dan 9,3B. Beide getallen beschrijven iets anders dan wat de zin veronderstelt, en dat is het meest betrouwbare dat deze vergelijking heeft opgeleverd.