Ming-3.0-audio-tiny vs Qwen-Audio 3.1: una finestra su cui puoi fare calcoli, contro un catalogo su cui non puoi

Ecco un numero facile da verificare e difficile da usare: il backbone testuale all'interno di Ming-3.0-audio-tiny è configurato per 131.072 posizioni, e la torre audio che lo precede accetta 3.000 frame alla volta con 128 bin mel. Qwen-Audio 3.1, al contrario, non pubblica alcuna lunghezza di contesto — non sull'indice del modello, non nelle descrizioni di una riga allegate ai suoi tre ID modello. Una parte ti consegna un numero e lascia a te l'interpretazione; l'altra ti consegna tre nomi di prodotto e lascia l'hardware ad Alibaba. Questa asimmetria è l'intero confronto, e non è un confronto su quale modello senta meglio. È un confronto su quale puoi dimensionare prima di spendere qualcosa. I fallimenti documentati dell'IA e gli incidenti degli agenti dietro rilasci come questo sono raccolti in the OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, gravità, grado di confidenza e flag di contestazione.

Prima le date, perché questo modello ha una cronologia bizzarra. I pesi dietro Ming-3.0-audio-tiny sono arrivati su Hugging Face il 3 settembre 2026; il repository è stato creato alle 11:45 UTC e i due shard safetensors sono arrivati quattro minuti dopo. Ciò che è cambiato di recente non è il checkpoint. Tra il 16 e il 19 ottobre 2026 il repository è stato riscritto attorno a esso — una configurazione che finalmente descriveva un modello audio invece di uno video-linguistico, un Talker per l'output vocale, due clip vocali di riferimento con trascrizioni, tre profili di deployment su GitHub e, il 19 ottobre alle 13:19 UTC, la prima model card che il repository abbia mai avuto. Nessuno l'ha annunciato. Quindi la domanda giusta non è cosa sia stato rilasciato a settembre. È ciò che ora puoi calcolare riguardo al suo funzionamento, e ciò che il catalogo di A​libaba ti consente e non ti consente di calcolare riguardo all'alternativa.

Convertire 131.072 token in minuti

Il numero è reale ed è verificabile, cosa che non si può dire della maggior parte delle affermazioni sul contesto. La configurazione testuale dichiara max_position_embeddings 131.072, un'attenzione MLA con un latente KV di ampiezza 512 e una base rotatoria di 6.000.000. Ma una finestra di contesto in token diventa utile solo quando si sa quanti token costa un secondo di audio, e il fornitore non lo dice. Puoi ricavarlo dai numeri della torre audio stessa.

• Input dell'encoder — 3.000 frame di 128 bin mel, che corrispondono alla stessa finestra di 30 secondi utilizzata da Whisper con un hop di 10 ms.

• Downsampler — kernel [3,3,3] con stride [2,2,2], quindi una finestra si riduce di un fattore otto.

• Token per finestra — 3.000 diviso 8, ovvero 375 token audio per circa 30 secondi di audio.

• Ciò che implica: 131.072 diviso 375 fa circa 349 finestre, ovvero poco meno di tre ore di audio, se la pipeline alimenta un unico flusso continuo anziché rifare il buffering tra una finestra e l'altra.

Quell'ultima clausola ha molto peso e voglio essere esplicito al riguardo. La cifra delle tre ore è frutto di un calcolo aritmetico su due valori di configurazione pubblicati, non una dichiarazione del fornitore, e sarà errata se il processore reimposta la posizione tra una clip e l'altra — che è esattamente ciò che implica il profilo di riproduzione ASR quando limita l'audio a una clip per prompt. Considerala un limite superiore da testare, non una specifica da citare.

Il punto non è l’aritmetica, ma la conseguenza sulla memoria. MLA memorizza il latente KV anziché chiavi e valori per testa, ed è per questo che una finestra da 131K è sostenibile su una singola scheda. Il profilo di testo di riferimento riserva 0,92 di una singola GPU con max_num_batched_tokens 32,768, una riserva dimensionata per la finestra completa più un batch grande, non un minimo. Riduci max_model_len e anche la riserva si riduce. Gli shard di Thinker totalizzano 17,74 GB, quindi una scheda da 24 GB contiene i pesi con spazio avanzato.

L'altro lato risponde alla stessa domanda con una suddivisione del prodotto

L'indice di Model Studio di Alibaba elenca Qwen-Audio 3.1 come tre ID modello anziché come un unico modello con un campo contesto. qwen-audio-3.1-asr-flash-streaming e qwen-audio-3.1-asr-flash-filetrans si trovano sotto il riconoscimento vocale; qwen-audio-3.1-realtime-plus si trova sotto speech-to-speech ed è descritto come conversazione vocale end-to-end senza chiamate ASR e TTS separate. Nessun peso, nessun conteggio dei parametri, nessuna lunghezza del contesto, nessun prezzo su quella pagina. La documentazione dettagliata per ciascun ID non si è risolta durante la verifica.

Leggi quella suddivisione come una risposta al problema dell'audio lungo anziché come un incidente di packaging. Uno SKU di trascrizione file è il modo in cui un provider vende un'ora di audio: lo carichi, il servizio lo suddivide in chunk come preferisce, e la finestra di contesto è un problema di ingegneria di qualcun altro. Uno SKU in streaming è il modo in cui un provider vende una chiamata telefonica. Nessuno dei due SKU espone il numero che espone Ming, il che significa che non puoi costruire un modello di capacità per Qwen-Audio 3.1 come puoi fare per Ming-3.0-audio-tiny. Puoi solo costruire una bolletta, e anche per quella serve la console.

• Cosa puoi ispezionare — Ming: configurazione, architettura, licenza, quattro file safetensors, tre immagini di benchmark, YAML di deployment. Q​wen: tre identificatori e una frase ciascuno.

• Cosa puoi dimensionare — Ming: 17,74 GB di pesi e una GPU per il testo, due per la voce. Q​wen: sconosciuto finché non leggi un listino prezzi che non puoi vedere da qui.

• Cosa puoi mettere in cache — Ming: la tua cache KV, con il tuo max_model_len. Q​wen: qualunque cosa l'endpoint faccia internamente, in modo invisibile.

• Modalità di errore — Ming: un OOM che hai causato e che puoi risolvere. Q​wen: una quota, una regione o una pagina di documentazione che non restituisce nulla.

• Licenza — Ming: MIT, nei metadati della scheda e nel file LICENSE del repository GitHub, anche se va notato che il repository Hugging Face non contiene un proprio file LICENSE. Qwen: i termini commerciali di Model Studio, perché non c'è alcuna licenza dei pesi da leggere.

La domanda benchmark a cui nessuno può rispondere onestamente

Ming-3.0-audio-tiny include tre immagini di valutazione in assets/, e ogni cella al loro interno è inclusionAI che misura inclusionAI. La scheda contrassegna con un asterisco le righe autovalutate e ammette che i modelli di confronto sono stati riprodotti con i propri prompt e le proprie impostazioni di decodifica. È un'informativa normale e vale la pena prenderla per quello che è: questi sono obiettivi di progetto, non risultati.

Per questo confronto i numeri sono doppiamente scomodi, perché le colonne utili non sono quelle presenti. Sul riconoscimento del cinese il modello tiny registra una media di 3,79 di errore sui caratteri contro 3,45 del suo fratello maggiore, e sui dialetti 10,29 contro 9,40. Sull'intelligenza audio perde davvero terreno — MMAU 75,90 contro 82,00, MMAU-Pro 56,42 contro 66,41, e un crollo dell'interazione vocale su URO-Bench-Pro da 81,92 a 54,15. Tutto questo è minuscolo rispetto a flash. Niente di tutto ciò è minuscolo rispetto a Qwen-Audio 3.1, perché Qwen-Audio 3.1 non ha pubblicato alcun punteggio comparabile e non esistono un set di test condiviso, una configurazione di decodifica condivisa, né una terza parte che abbia eseguito entrambi.

C'è un secondo vuoto che vale la pena nominare perché è verificabile in dieci secondi. La scheda dice che le cifre condivise includono i risultati per entrambe le varianti Ming. Questo è vero per l'immagine di riconoscimento e per l'immagine di intelligenza audio. L'immagine di intelligenza testuale ha quattro colonne e il modello tiny non è una di queste — le sue colonne sono Ming-3.0-audio-flash, Qwen3.8-Omni Flash, Qwen3.5-Omni Plus e Qwen3.5-Omni Flash. Se la tua domanda è se il backbone attivo da 2.7B possa sostenere una conversazione di ragionamento sull'audio, inclusionAI non ha risposto in quell'immagine, qualunque cosa dica la frase sopra l'immagine.

Come le due forme falliscono diversamente a tre ore

L'audio lungo è il punto in cui la divisione del prodotto smette di essere cosmetica. Un singolo checkpoint con una finestra da 131K è la promessa che un solo modello legga l'intera registrazione e ricordi i primi dieci minuti quando arriva alla fine. Quella promessa ha una modalità di errore specifica: tutto peggiora insieme. Se l'audio supera la finestra, si esegue il chunking, ed è nel chunking che il ragionamento tra chunk muore silenziosamente — l'interlocutore introdotto al minuto due è di nuovo uno sconosciuto al minuto quaranta.

Uno SKU per la trascrizione di file nasconde quel problema e ne eredita un altro. Non controlli il chunking, quindi non puoi riprodurre una trascrizione scadente; non puoi sapere se il servizio ha mantenuto il contesto tra i chunk o ha unito finestre indipendenti; e quando l'output cambia tra due caricamenti identici non hai alcuna variabile da isolare. Lo SKU in streaming è onesto riguardo al proprio vincolo già nel nome: è costruito per emettere man mano che l'audio arriva, che è la forma giusta per i sottotitoli e quella sbagliata per una revisione di conformità di una chiamata di novanta minuti.

Quindi la decisione non è «quale sia più preciso» — nessuna delle due parti ti ha dato un numero che la risolva. È «quale guasto posso diagnosticare». Se devi riprodurre una trascrizione byte per byte, prenditi il checkpoint. Se ti serve una trascrizione in venti minuti e il cercapersone di qualcun altro, noleggia lo SKU.

Dove un router dimostra il proprio valore in questa pipeline

OrcaRouter non serve Ming-3.0-audio-tiny. Non è nel nostro catalogo e non possiamo fornirti un endpoint per esso; nulla di quanto segue costituisce un'offerta in tal senso. Ciò che un router raggiunge è la parte di una pipeline per audio lungo che non è il modello audio: decidere quale registrazione va al modello locale 2.7B e quale a qualcosa di più grande, scrivere il riassunto dalla trascrizione, estrarre le attività da fare, etichettare la chiamata. Quelle sono chiamate di testo, e oltre 200 modelli dietro un'unica chiave è un percorso più breve di quattro contratti con fornitori — al prezzo di listino del provider con 0% di ricarico, quindi quando un fornitore taglia un prezzo l'importo che paghi cambia lo stesso giorno. Failover automatico conta più del solito qui: un lavoro di trascrizione che fallisce al minuto ottanta di un file di novanta minuti dovrebbe riprovare su un secondo percorso, non ricominciare da capo.

Vale la pena dirlo ad alta voce, dov'è il confine. Un router instrada le chiamate. Non trasforma un checkpoint da 17.74 GB in un endpoint ospitato, e non ti dice se la finestra da 131K di Ming è reale. Solo la tua ora di audio può dirlo.

L’esperimento che risolve la questione

Prendi una registrazione di cui conosci già la risposta — una riunione con tre relatori, uno dei quali cambia lingua a metà frase — e falla passare attraverso entrambi. Per Ming-3.0-audio-tiny, caricala con trust_remote_code=True, usa il prompt ASR che la card convalida (indica la lingua, tab, poi la trascrizione — quel tab è il tuo parser), e imposta max_model_len esattamente alla lunghezza che ti serve anziché il valore predefinito. Per Qwen-Audio 3.1, esegui lo stesso file sia tramite lo SKU di trascrizione file sia tramite lo SKU in tempo reale, perché sono prodotti diversi e non concorderanno.

Poi confronta tre cose, nessuna delle quali è un punteggio di benchmark. Il modello ha mantenuto le identità dei parlanti per tutto il file? Ha superato il cambio di lingua senza traslitterare? E sapresti spiegare il risultato abbastanza bene da cambiare una variabile e rieseguirlo? L'ultima domanda è quella che decide se stai valutando un modello o facendo un provino a un fornitore, ed è l'unico punto in cui questi due non sono vicini.