Ming-3.0-audio-tiny vs. Qwen-Audio 3.1: een venster waarop je kunt rekenen, tegenover een catalogus waarmee dat niet kan

Hier is een getal dat gemakkelijk te controleren en moeilijk te gebruiken is: de tekstbackbone in Ming-3.0-audio-tiny is geconfigureerd voor 131.072 posities, en de audiotoren ervoor neemt 3.000 frames per keer met 128 mel-bins. Qwen-Audio 3.1 publiceert daarentegen helemaal geen contextlengte — niet in de modelindex, niet in de éénregelbeschrijvingen bij de drie model-ID's. De ene kant geeft je een getal en laat de interpretatie aan jou over; de andere kant geeft je drie productnamen en laat de hardware aan Alibaba over. Die asymmetrie is de hele vergelijking, en het is geen vergelijking over welk model beter hoort. Het is een vergelijking over van welke je de omvang kunt bepalen voordat je ook maar iets uitgeeft. De gedocumenteerde AI-fouten en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waarbij elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistmarkering bevat.

Eerst de data, want dit model heeft een lastige chronologie. De gewichten achter Ming-3.0-audio-tiny verschenen op 3 september 2026 op Hugging Face; de repository werd aangemaakt om 11:45 UTC en de twee safetensors-shards volgden vier minuten later. Wat recentelijk is veranderd, is niet de checkpoint. Tussen 16 en 19 oktober 2026 werd de repository eromheen herschreven — een configuratie die eindelijk een audiomodel beschreef in plaats van een video-taal-model, een Talker voor spraakuitvoer, twee referentiestemfragmenten met transcripties, drie deploymentprofielen op GitHub, en, op 19 oktober om 13:19 UTC, de eerste modelkaart die de repository ooit heeft gehad. Niemand kondigde het aan. De terechte vraag is dus niet wat er in september is uitgebracht. Het is wat je nu kunt berekenen over het draaien ervan, en wat A​libaba's catalogus je wel en niet laat berekenen over het alternatief.

131,072 tokens omzetten naar minuten

Het getal is echt en het is testbaar, wat je van de meeste contextclaims niet kunt zeggen. De tekstconfiguratie declareert max_position_embeddings 131,072, een MLA-attentie met een 512 brede KV-latent en een rotary-basis van 6,000,000. Maar een contextvenster in tokens wordt pas nuttig als je weet hoeveel tokens één seconde audio kost, en de leverancier vermeldt dat niet. Je kunt het afleiden uit de eigen cijfers van de audiotoren.

• Encoder-invoer — 3.000 frames van 128 mel-bins, hetzelfde venster van 30 seconden dat Whisper bij een hop van 10 ms gebruikt.

• Downsampler — kernel [3,3,3] met stride [2,2,2], zodat één venster met een factor acht inkrimpt.

• Tokens per venster — 3.000 gedeeld door 8, d.w.z. 375 audiotokens voor ongeveer 30 seconden geluid.

• Wat dat impliceert — 131.072 gedeeld door 375 is ongeveer 349 vensters, of iets minder dan drie uur audio, als de pijplijn één enkele doorlopende stream levert in plaats van opnieuw te bufferen tussen vensters.

Die laatste clausule draagt veel gewicht, en ik wil er expliciet over zijn. Het cijfer van drie uur is rekenwerk op twee gepubliceerde configuratiewaarden, geen claim van de leverancier, en het zal onjuist zijn als de processor de positie tussen clips reset — wat precies is wat het ASR-reproductieprofiel impliceert wanneer het audio beperkt tot één clip per prompt. Behandel het als een bovengrens om te testen, niet als een specificatie om te citeren.

Wat geen kwestie van rekenkracht is, is het gevolg voor het geheugen. MLA slaat de KV-latent op in plaats van sleutels en waarden per head, wat de reden is dat een venster van 131K überhaupt verdedigbaar is op één kaart. Het referentietekstprofiel reserveert 0,92 van één GPU met max_num_batched_tokens 32.768, een reservering die is afgestemd op het volledige venster plus een grote batch, geen ondergrens. Verlaag je max_model_len, dan daalt de reservering mee. De shards van de Thinker zijn samen 17,74 GB, dus een kaart van 24 GB bevat de gewichten met ruimte over.

De andere kant beantwoordt dezelfde vraag met een productopsplitsing.

De index van Alibaba's Model Studio vermeldt Qwen-Audio 3.1 als drie model-ID's in plaats van als één model met een contextveld. qwen-audio-3.1-asr-flash-streaming en qwen-audio-3.1-asr-flash-filetrans vallen onder spraakherkenning; qwen-audio-3.1-realtime-plus valt onder spraak-naar-spraak en wordt beschreven als end-to-end spraakgesprek zonder afzonderlijke ASR- en TTS-aanroepen. Geen gewichten, geen parameteraantal, geen contextlengte, geen prijs op die pagina. De detaildocumentatie voor elke ID kon bij controle niet worden opgelost.

Lees die opsplitsing als een antwoord op het lange-audio-probleem en niet als een toeval van verpakking. Een SKU voor bestandstranscriptie is hoe een provider een uur audio verkoopt: je uploadt het, de service deelt het naar believen op, en het contextvenster is een engineeringprobleem van iemand anders. Een streaming-SKU is hoe een provider een telefoongesprek verkoopt. Geen van beide SKU's maakt het getal bekend dat Ming bekendmaakt, wat betekent dat je voor Qwen-Audio 3.1 geen capaciteitsmodel kunt bouwen zoals je dat voor Ming-3.0-audio-tiny kunt. Je kunt alleen een rekening opstellen, en zelfs dat vereist de console.

• Wat je kunt inspecteren — Ming: configuratie, architectuur, licentie, vier safetensors-bestanden, drie benchmarkafbeeldingen, deployment-YAML. Qwen: drie identificatoren en elk één zin.

• Wat je kunt inschatten — Ming: 17,74 GB aan gewichten en één GPU voor tekst, twee voor spraak. Qwen: onbekend tot je een tariefkaart leest die je vanaf hier niet kunt zien.

• Wat je kunt cachen — Ming: je eigen KV-cache, bij je eigen max_model_len. Q​wen: wat de endpoint ook intern doet, onzichtbaar.

• Faalmodus — Ming: een OOM die je zelf hebt veroorzaakt en kunt oplossen. Q​wen: een quotum, een regio, of een documentatiepagina die niets teruggeeft.

• Licentie — Ming: MIT, in de metadata van de modelkaart en in de LICENSE van de GitHub-repository, maar let op: de Hugging Face-repository bevat geen eigen LICENSE-bestand. Q​wen: de commerciële voorwaarden van Model Studio, omdat er geen licentie voor de gewichten is om te lezen.

De benchmarkvraag die niemand eerlijk kan beantwoorden

Ming-3.0-audio-tiny wordt geleverd met drie evaluatieafbeeldingen in assets/, en elke cel daarin is inclusionAI die inclusionAI meet. De kaart markeert zelfgeëvalueerde rijen met een asterisk en geeft toe dat vergelijkingsmodellen zijn gereproduceerd met zijn eigen prompts en decoding-instellingen. Dat is een normale mededeling, en het loont om die letterlijk te nemen: dit zijn ontwerpdoelen, geen resultaten.

Voor deze vergelijking zijn de cijfers dubbel ongemakkelijk, omdat de nuttige kolommen niet de kolommen zijn die erin staan. Bij Chinese herkenning scoort het kleine model gemiddeld 3,79 karakterfout tegenover 3,45 voor zijn grotere broer, en bij dialecten 10,29 tegenover 9,40. Op het gebied van audio-intelligentie levert het echt terrein in — MMAU 75,90 tegenover 82,00, MMAU-Pro 56,42 tegenover 66,41, en een ineenstorting van de gesproken interactie op URO-Bench-Pro van 81,92 naar 54,15. Dat alles is minuscuul tegenover flash. Niets daarvan is minuscuul tegenover Qwen-Audio 3.1, omdat Qwen-Audio 3.1 geen vergelijkbare score heeft gepubliceerd en er geen gedeelde testset, geen gedeelde decoderingsconfiguratie en geen derde partij is die beide heeft uitgevoerd.

Er is een tweede gat dat het benoemen waard is, omdat je het in tien seconden kunt controleren. De kaart zegt dat de gedeelde cijfers resultaten bevatten voor beide Ming-varianten. Dat geldt voor de herkenningsafbeelding en de audio-intelligentieafbeelding. De tekstintelligentieafbeelding heeft vier kolommen en het kleine model staat er niet bij — de kolommen zijn Ming-3.0-audio-flash, Qwen3.8-Omni Flash, Qwen3.5-Omni Plus en Qwen3.5-Omni Flash. Als uw vraag is of de 2,7B-actieve backbone een redeneergesprek over audio kan voeren, heeft inclusionAI die vraag in die afbeelding niet beantwoord, ongeacht wat de zin boven de afbeelding zegt.

Hoe de twee vormen op drie uur op verschillende manieren falen

Lange audio is waar de productopsplitsing ophoudt cosmetisch te zijn. Een enkel checkpoint met een 131K-venster is de belofte dat één model de hele opname leest en zich de eerste tien minuten herinnert wanneer het de laatste bereikt. Die belofte heeft een specifieke faalmodus: alles gaat samen achteruit. Als de audio het venster overschrijdt, splits je op in chunks, en juist bij dat opsplitsen sterft het redeneren over chunks heen stilletjes — de spreker die op minuut twee werd geïntroduceerd, is op minuut veertig weer een vreemde.

Een file-transcriptie-SKU verbergt dat probleem en erft een ander probleem. Je hebt geen controle over de chunking, dus je kunt een slecht transcript niet reproduceren; je kunt niet vaststellen of de dienst context over chunks heen heeft behouden of onafhankelijke vensters aan elkaar heeft genaaid; en wanneer de output verandert tussen twee identieke uploads, heb je geen variabele om te isoleren. De streaming-SKU is eerlijk over zijn beperking in de naam: hij is gebouwd om uitvoer te produceren zodra de audio binnenkomt, wat de juiste vorm is voor ondertitels en de verkeerde vorm voor een compliancebeoordeling van een gesprek van negentig minuten.

Dus de beslissing is niet "welke is nauwkeuriger" — geen van beide kanten heeft je een getal gegeven dat dat zou beslechten. Het is "welke fout kan ik debuggen". Als je een transcript byte voor byte moet reproduceren, beheer dan zelf de checkpoint. Als je binnen twintig minuten een transcript nodig hebt en de pager van iemand anders, huur dan de SKU.

Waar een router zijn waarde bewijst in deze pijplijn

OrcaRouter levert Ming-3.0-audio-tiny niet. Het staat niet in onze catalogus en we kunnen je er geen endpoint voor geven; niets hier is een aanbieding daartoe. Wat een router wél bereikt, is het deel van een lange-audiopipeline dat niet het audiomodel is: bepalen welke opname naar het lokale 2.7B-model gaat en welke naar iets groters, de samenvatting uit het transcript schrijven, de actiepunten eruit halen, het gesprek taggen. Dat zijn tekstcalls, en meer dan 200 modellen achter één sleutel is een kortere weg dan vier leverancierscontracten — tegen de lijstprijs van de provider met 0% opslag, dus wanneer een leverancier een prijs verlaagt, beweegt het bedrag dat je betaalt dezelfde dag mee. Automatische failover is hier belangrijker dan gebruikelijk: een transcriptietaak die mislukt op minuut tachtig van een bestand van negentig minuten zou het via een tweede pad opnieuw moeten proberen, niet helemaal opnieuw moeten beginnen.

Het is de moeite waard om de grens hardop te benoemen. Een router routeert oproepen. Hij verandert een checkpoint van 17.74 GB niet in een gehoste endpoint, en hij vertelt je niet of Mings 131K-venster echt is. Alleen je eigen uur aan audio doet dat.

Het experiment dat uitsluitsel geeft

Neem één opname waarvan je het antwoord al kent — een vergadering met drie sprekers, van wie er één midden in een zin van taal wisselt — en laat die door beide gaan. Laad hem voor Ming-3.0-audio-tiny met trust_remote_code=True, gebruik de ASR-prompt die de modelkaart valideert (noem de taal, tab, en dan de transcriptie — die tab is je parser), en stel max_model_len in op precies de lengte die je nodig hebt in plaats van de standaardwaarde. Voer voor Qwen-Audio 3.1 hetzelfde bestand uit via zowel de SKU voor bestandstranscriptie als de realtime-SKU, omdat het verschillende producten zijn die niet dezelfde uitkomst zullen geven.

Vergelijk dan drie dingen, waarvan geen enkele een benchmarkscore is. Hield het model de sprekeridentiteiten over het hele bestand vast? Doorstond het de taalwissel zonder te translitereren? En kon je het resultaat goed genoeg uitleggen om één variabele te wijzigen en het opnieuw te draaien? De laatste vraag bepaalt of je een model evalueert of een leverancier aan het uitproberen bent, en het is de enige plek waar deze twee niet dicht bij elkaar liggen.