Ming-3.0-audio-tiny vs Qwen-Audio 3.1: Ett fönster du kan räkna på, mot en katalog du inte kan

Här är en siffra som är lätt att kontrollera och svår att använda: textryggraden inuti Ming-3.0-audio-tiny är konfigurerad för 131 072 positioner, och ljudtornet framför den tar 3 000 ljudramar åt gången med 128 mel-bins. Qwen-Audio 3.1 publicerar däremot ingen kontextlängd alls – varken på modellindexet eller i de enradiga beskrivningarna som hör till dess tre modell-ID:n. Den ena sidan ger dig en siffra och lämnar tolkningen till dig; den andra ger dig tre produktnamn och lämnar hårdvaran till Alibaba. Den asymmetrin är hela jämförelsen, och det är inte en jämförelse om vilken modell som hör bättre. Det är en jämförelse om vilken du kan dimensionera innan du spenderar något. De dokumenterade AI-felen och agentincidenterna bakom utgåvor som den här samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omtvistad status.

Datum först, eftersom den här modellen har en besvärlig kronologi. Vikterna bakom Ming-3.0-audio-tiny landade på Hugging Face den 3 september 2026; repositoriet skapades kl. 11:45 UTC och de två safetensors-shardarna följde fyra minuter senare. Det som förändrades nyligen är inte checkpointen. Mellan den 16 och 19 oktober 2026 byggdes repositoriet om kring den – en konfiguration som äntligen beskrev en ljudmodell i stället för en video-språkmodell, en Talker för talutdata, två referensröstklipp med transkript, tre driftsättningsprofiler på GitHub och, den 19 oktober kl. 13:19 UTC, det första modellkortet som repositoriet någonsin har haft. Ingen annonserade det. Så den rimliga frågan är inte vad som levererades i september. Det är vad du nu kan räkna ut om att köra det, och vad Alibabas katalog låter dig räkna ut och inte räkna ut om alternativet.

Omvandla 131 072 tokens till minuter

Siffran är verklig och testbar, vilket är mer än vad som kan sägas om de flesta kontextpåståenden. Textkonfigurationen anger max_position_embeddings 131 072, en MLA-attention med en KV-latent på 512 dimensioner och en rotbas på 6 000 000. Men ett kontextfönster i tokens blir bara användbart när man vet hur många tokens en sekund ljud kostar, och det säger leverantören inte. Du kan härleda det från ljudtornets egna siffror.

• Encoder-indata — 3 000 ramar med 128 mel-bins, vilket är samma 30-sekundersfönster som Whisper använder vid ett hopp på 10 ms.

• Nedsamplare — kärna [3,3,3] med steg [2,2,2], så ett fönster krymper med en faktor åtta.

• Tokens per fönster — 3 000 delat med 8, dvs. 375 ljudtokens för ungefär 30 sekunder ljud.

• Vad det innebär — 131 072 dividerat med 375 är ungefär 349 fönster, eller lite mindre än tre timmar ljud, om pipelinen matar en enda kontinuerlig ström i stället för att buffra om mellan fönster.

Den sista bisatsen bär mycket och jag vill vara tydlig med det. Siffran tre timmar är en uträkning utifrån två publicerade konfigurationsvärden, inte ett leverantörspåstående, och den kommer att vara fel om processorn återställer positionen mellan klipp — vilket är precis vad ASR-reproduktionsprofilen antyder när den begränsar ljudet till ett klipp per prompt. Behandla den som en övre gräns att testa, inte som en specifikation att citera.

Det som inte är aritmetik är minneskonsekvensen. MLA lagrar KV-latenten i stället för nycklar och värden per huvud, vilket är anledningen till att ett fönster på 131K överhuvudtaget är försvarbart på ett enda kort. Referenstextprofilen reserverar 0,92 av en enda GPU med max_num_batched_tokens 32 768, vilket är en reservation dimensionerad för hela fönstret plus en stor batch, inte en miniminivå. Ta bort max_model_len så sjunker reservationen med den. The Thinkers shards uppgår sammanlagt till 17,74 GB, så ett 24 GB-kort rymmer vikterna med utrymme över.

Den andra sidan besvarar samma fråga med en produktuppdelning.

Alibabas Model Studio-index listar Qwen-Audio 3.1 som tre modell-ID:n i stället för en modell med ett kontextfält. qwen-audio-3.1-asr-flash-streaming och qwen-audio-3.1-asr-flash-filetrans ligger under taligenkänning; qwen-audio-3.1-realtime-plus ligger under tal-till-tal och beskrivs som end-to-end-röstkonversation utan separata ASR- och TTS-anrop. Inga vikter, inget parameterantal, ingen kontextlängd och inget pris på den sidan. Detaljdokumentationen för varje ID kunde inte läsas in när den kontrollerades.

Läs den uppdelningen som ett svar på problemet med långt ljud snarare än som en slump i paketeringen. En filtranskriptions-SKU är hur en leverantör säljer en timme ljud: du laddar upp det, tjänsten styckar upp det hur den vill, och kontextfönstret är någon annans ingenjörsproblem. En streaming-SKU är hur en leverantör säljer ett telefonsamtal. Ingen av SKU:erna exponerar den siffra som Ming exponerar, vilket innebär att du inte kan bygga en kapacitetsmodell för Qwen-Audio 3.1 på samma sätt som för Ming-3.0-audio-tiny. Du kan bara bygga en faktura, och även det kräver konsolen.

• Vad du kan granska — Ming: konfiguration, arkitektur, licens, fyra safetensors-filer, tre benchmarkbilder, distributions-YAML. Qwen: tre identifierare och en mening vardera.

• Vad du kan dimensionera – Ming: 17,74 GB vikter och en GPU för text, två för tal. Q​wen: okänt tills du läser en prislista som du inte kan se härifrån.

• Vad du kan cacha — Ming: din egen KV-cache, vid din egen max_model_len. Qwen: vad slutpunkten gör internt, osynligt.

• Felmod — Ming: en OOM som du orsakat och kan åtgärda. Q​wen: en kvot, en region eller en dokumentationssida som inte returnerar något.

• Licens — Ming: MIT, i kortets metadata och i GitHub-repositoriets LICENSE, men observera att Hugging Face-repositoriet inte innehåller någon egen LICENSE-fil. Qwen: Model Studios kommersiella villkor, eftersom det inte finns någon licens för vikterna att läsa.

Benchmarkfrågan som ingen kan besvara ärligt

Ming-3.0-audio-tiny levereras med tre utvärderingsbilder i assets/, och varje cell i dem är inclusionAI som mäter inclusionAI. Kortet markerar självutvärderade rader med en asterisk och medger att jämförelsemodellerna återskapades med dess egna prompter och avkodningsinställningar. Det är en normal redogörelse och den är värd att tas för vad den är: dessa är designmål, inte resultat.

I den här jämförelsen är siffrorna dubbelt besvärliga, eftersom de användbara kolumnerna inte är de som finns. Vid kinesisk igenkänning har den lilla modellen i genomsnitt 3,79 i teckenfel mot 3,45 för sitt större syskon, och för dialekter 10,29 mot 9,40. Inom ljudintelligens tappar den verklig mark — MMAU 75,90 mot 82,00, MMAU-Pro 56,42 mot 66,41, och en kollaps för talinteraktion på URO-Bench-Pro från 81,92 till 54,15. Allt det där är litet mot flash. Inget av det är litet mot Qwen-Audio 3.1, eftersom Qwen-Audio 3.1 inte har publicerat någon jämförbar poäng och det finns varken någon gemensam testmängd, någon gemensam avkodningskonfiguration eller någon tredje part som har kört båda.

Det finns en andra lucka som är värd att nämna eftersom den går att kontrollera på tio sekunder. Kortet säger att de gemensamma siffrorna omfattar resultat för båda Ming-varianterna. Det stämmer för igenkänningsbilden och ljudintelligensbilden. Textintelligensbilden har fyra kolumner och den lilla modellen är inte en av dem – dess kolumner är Ming-3.0-audio-flash, Qwen3.8-Omni Flash, Qwen3.5-Omni Plus och Qwen3.5-Omni Flash. Om din fråga är huruvida stommen med 2,7B aktiva parametrar kan föra ett resonerande samtal om ljud, har inclusionAI inte besvarat den i den bilden, oavsett vad meningen ovanför bilden säger.

Hur de två formerna misslyckas på olika sätt vid tre timmar

Det är med långt ljud som produktuppdelningen slutar vara kosmetisk. En enda checkpoint med ett fönster på 131K är ett löfte om att en modell läser hela inspelningen och minns de första tio minuterna när den når slutet. Det löftet har ett specifikt felbeteende: allt försämras tillsammans. Om ljudet överflödar fönstret delar du upp det i chunkar, och chunkning är där resonemang över chunkgränser tyst dör — talaren som introducerades vid minut två är återigen en främling vid minut fyrtio.

En SKU för filtranskribering döljer det problemet och ärver ett annat. Du kontrollerar inte chunkningen, så du kan inte återskapa en dålig transkription; du kan inte avgöra om tjänsten behöll kontexten mellan chunkar eller sydde ihop oberoende fönster; och när utdata ändras mellan två identiska uppladdningar har du ingen variabel att isolera. Streaming-SKU:n är ärlig om sin begränsning i namnet: den är byggd för att sända ut i takt med att ljudet anländer, vilket är rätt form för undertexter och fel form för en regelefterlevnadsgranskning av ett nittio minuter långt samtal.

Så beslutet är inte "vilket är mer korrekt" – ingen av sidorna har gett dig en siffra som skulle avgöra det. Det är "vilket fel kan jag felsöka". Om du behöver återge en transkription byte för byte, äg checkpointen. Om du behöver en transkription inom tjugo minuter och någon annans personsökare, hyr SKU:n.

Där en router gör nytta i den här pipelinen

OrcaRouter tillhandahåller inte Ming-3.0-audio-tiny. Det finns inte i vår katalog och vi kan inte ge dig en slutpunkt för det; inget här utgör ett erbjudande om att tillhandahålla det. Det som en router faktiskt kan hantera är den del av en pipeline för långt ljud som inte är ljudmodellen: att avgöra vilken inspelning som går till den lokala 2.7B-modellen och vilken som går till något större, att skriva sammanfattningen från transkriptionen, att extrahera åtgärdspunkterna, att tagga samtalet. Det är textanrop, och mer än 200 modeller bakom en enda nyckel är en kortare väg än fyra leverantörsavtal — till leverantörens listpris med 0 % påslag, så när en leverantör sänker ett pris ändras summan du betalar samma dag. Automatisk failover är viktigare än vanligt här: ett transkriberingsjobb som misslyckas vid minut åttio i en nittio minuter lång fil bör göra ett nytt försök på en andra väg, inte börja om från början.

Gränsen är värd att säga högt. En router dirigerar anrop. Den förvandlar inte en checkpoint på 17.74 GB till en hostad endpoint, och den berättar inte för dig om Mings 131K-fönster är verkligt. Det är bara din egen timme av ljud som gör det.

Experimentet som avgör saken

Ta en inspelning som du redan vet svaret på — ett möte med tre talare, varav en byter språk mitt i en mening — och kör den genom båda. För Ming-3.0-audio-tiny, ladda den med trust_remote_code=True, använd den ASR-prompt som kortet validerar (ange språket, tab, sedan transkriptionen — den tabben är din parser), och ställ in max_model_len på exakt den längd du behöver i stället för standardvärdet. För Qwen-Audio 3.1, kör samma fil genom både file-transcription-SKU:n och realtime-SKU:n, eftersom de är olika produkter och inte kommer att stämma överens.

{{1}}Jämför sedan tre saker, varav ingen är en benchmarkpoäng. Höll modellen talaridentiteterna genom hela filen? Klarade den språkväxlingen utan att translitterera? Och kunde du förklara resultatet tillräckligt väl för att ändra en variabel och köra det igen? Den sista frågan är den som avgör om du utvärderar en modell eller provar en leverantör, och det är den enda platsen där dessa två inte ligger nära varandra.{{/1}}