VibeVoice-ASR-Streaming-7B vs Gemini 3.5 Transcribe Live: Una settimana, due tipi di trascrizione vocale in streaming

L'ultima settimana di agosto e i primi giorni di settembre 2026 hanno prodotto due sistemi di trascrizione vocale in streaming che sembrano rivali e sono in realtà risposte molto diverse alla stessa domanda. Il 26 agosto Google ha messo Gemini 3.5 Transcribe Live in anteprima pubblica: un endpoint di trascrizione vocale hosted e chiuso che restituisce una trascrizione completa 0,40 secondi dopo che chi parla smette di parlare, supportato da un tasso di errore su parole in streaming misurato al 4,0% da Artificial Analysis e materiali di lancio completi. Il 2 settembre Microsoft Research ha caricato VibeVoice-ASR-Streaming-7B su Hugging Face nel namespace microsoft: pesi open con licenza MIT, nessun comunicato stampa, nessuna pagina di lancio e una scheda del modello che non pubblica alcun tasso di errore su parole né alcuna cifra di latenza in testo leggibile. Entrambi accettano l'audio mentre sta ancora arrivando. Questa è quasi l'unica cosa che condividono.

Le prove sui due lati non sono simmetriche, quindi questo confronto è scritto come ciò che sappiamo finora. Gemini 3.5 Transcribe Live è un prodotto Google con prezzi dei token pubblicati e misurazioni di terze parti, e questi sono etichettati di seguito. VibeVoice-ASR-Streaming-7B è un checkpoint le cui affermazioni sono lette interamente dal repository stesso: i file di configurazione, la scheda del modello e la documentazione di streaming di Microsoft nel repository GitHub di VibeVoice. Nessun aspetto del lato Microsoft è stato ancora benchmarkato in modo indipendente, e lo diciamo ogni volta che un numero potrebbe altrimenti sembrare fare lavoro.

Il percorso di rilascio: un lancio API e un upload silenzioso

Google ha pubblicato Gemini 3.5 Transcribe Live nel modo standard. Il modello si colloca sotto il marchio Gemini Audio insieme al suo gemello Gemini 3.5 Transcribe (il percorso API Interactions per l'audio pre-registrato), i prezzi sono indicati nella pagina del modello e le classifiche indipendenti hanno incluso l'endpoint Live entro pochi giorni — ed è da lì che provengono il 4,0% di WER in streaming e la latenza finale di 0,40 secondi. Esiste un livello gratuito, con la solita avvertenza che i contenuti del livello gratuito possono essere utilizzati per migliorare i prodotti Google.

Il rilascio streaming di Microsoft non aveva nulla di quell'apparato. Il repository Hugging Face microsoft/VibeVoice-ASR-Streaming-7B è stato creato il 2026-09-02 alle 15:46 UTC e modificato l'ultima volta tre minuti dopo; contiene otto shard safetensors, un tokenizer e una configurazione del preprocessore sotto licenza MIT. Il documento formale è una riga di news-log datata 3 settembre nel repository microsoft/VibeVoice che annuncia "un modello ASR streaming unificato che trascrive ininterrottamente chi ha detto cosa mentre il parlato arriva, con supporto per hotword personalizzate e 10 lingue", con link a una demo su aka.ms/vibeasr e a un report tecnico sullo streaming. Quando abbiamo controllato un giorno dopo il caricamento, il checkpoint mostrava ancora zero download e nessun provider di inferenza hosted lo elenca. La model card dice più dell'annuncio, e il repository è la fonte di quasi tutto ciò che segue.

Le specifiche, affiancate

• Cos'è — VibeVoice-ASR-Streaming-7B: ASR in streaming a pesi aperti, auto-ospitato; vs Gemini 3.5 Transcribe Live: API di streaming ospitata, pesi chiusi.

• Forma dello streaming — emette testo in blocchi di circa 2,9 secondi, con circa 0,5 secondi di lookahead (derivati dalla configurazione del checkpoint), rispetto a una sessione WebSocket bidirezionale con trascrizioni parziali continue e un risultato finale 0,40 secondi dopo che chi parla si ferma.

• Accuratezza dichiarata — nessun dato di WER o latenza pubblicato per iscritto rispetto al 4,0% di WER in streaming e al 2,6% sul modello preregistrato, secondo Artificial Analysis.

• Parlanti — attribuzione in streaming “chi ha detto cosa” dichiarata, non verificata; nessuna diarizzazione dei parlanti sull’endpoint Live (disponibile sul modello pre-registrato, fino a tre parlanti).

• Lingue — 10 (en, zh, es, pt, de, ja, ko, fr, ru, it) vs rilevamento automatico su oltre 85 lingue con commutazione a metà flusso.

• Durata della sessione — limitata solo dalla tua GPU e memoria, rispetto a un tetto massimo fisso di 10 minuti per sessione Live.

• Costo — $0 per i pesi, circa 18 GB di bf16 per l'auto-hosting rispetto a circa $0.54 per ora audio su Live una volta contati i token di output del testo.

Cosa significa "streaming" da ogni lato

La parola nasconde una reale differenza di progettazione, e vale la pena essere precisi perché i due sistemi non stanno nemmeno cercando di produrre la stessa cadenza. La configurazione del preprocessore di Microsoft rende concreto il ritmo di VibeVoice: l'audio arriva a 24 kHz e viene compresso 3.200× in un flusso di token a circa 7,5 frame al secondo; poi la configurazione dichiara un blocco di 22 frame e un lookahead di 4 frame — circa 2,9 secondi di audio per blocco, con all'incirca mezzo secondo di audio futuro per consolidarlo. Il modello emette testo una volta per ogni blocco risolto, e il contesto dei blocchi precedenti viene preservato tramite la cache KV, quindi una sessione lunga non ricalcola da zero. La trascrizione pratica cresce con incrementi di circa tre secondi.

L'endpoint Live di Google è pensato per un ciclo più rapido e interattivo: l'audio viene trasmesso tramite WebSocket in chunk PCM da 16 o 24 kHz, le trascrizioni parziali arrivano in continuazione mentre chi parla è in corso, e una trascrizione finale formattata arriva 0,40 secondi dopo la fine del discorso — quel numero è la misurazione di Artificial Analysis, citata da Google. I compromessi sono il limite di sessione (dieci minuti di audio, dopo i quali l'applicazione deve riconnettersi e ricucire) e le funzioni mancanti: niente diarizzazione dei parlanti e niente timestamp a livello di parola sul percorso Live, entrambi presenti nella trascrizione pre-registrata Gemini 3.5 Transcribe. Quindi il riepilogo onesto è che il modello di streaming di Google è più veloce per singolo enunciato, mentre il checkpoint di streaming di Microsoft è più lento per chunk ma offre l'attribuzione dei parlanti che il canale live di Google perde, con una durata di sessione che Google non offre.

Precisione: misurata, rispetto a uno spazio vuoto

Il divario più ampio in questo confronto è un divario di prove, non necessariamente di qualità. Artificial Analysis ha misurato Gemini 3.5 Transcribe Live con un tasso medio di errore sulle parole del 4,0% in streaming e del 2,6% sul modello non in streaming, quest'ultimo classificato quinto nella sua classifica WER al lancio; Google cita separatamente il 5,50% in streaming e il 5,04% non in streaming sul set multilingue FLEURS. Leggete questi dati per quello che dicono: Artificial Analysis è indipendente da Google, ma i numeri di un'API vecchia di un giorno sono ancora preliminari, e il sovrapprezzo dello streaming rispetto al modello batch — 4,0% contro 2,6% — è il prezzo abituale della consegna in tempo reale.

VibeVoice-ASR-Streaming-7B non ha alcuna cifra comparabile in nessun contesto. La model card include una metrica di valutazione come immagine, e il report tecnico di Microsoft è un PDF, ma nessuno dei due offre un WER in streaming o una latenza in testo semplice che possa essere citata o verificata in modo indipendente. L'unico riferimento numerico dell'intera famiglia è la model card del modello batch VibeVoice-ASR, che riporta un WER medio del 7,77% calcolato dal fornitore su otto set di test in inglese e del 2,20% su LibriSpeech clean — valori che si riferiscono al modello non in streaming, non a questo; e i modelli in streaming in genere sacrificano un po' di accuratezza in cambio del guadagno in latenza. Fino a quando qualcuno non eseguirà il checkpoint in streaming su una piattaforma di valutazione pubblica, l'affermazione corretta è che un lato di questo confronto è misurato e l'altro no.

Costo: un'API a consumo rispetto a una GPU già preventivata

Google addebita Gemini 3.5 Transcribe Live in base al token e conteggia l'audio a 25 token al secondo. In base alle tariffe Live pubblicate — $3,50 per un milione di token audio e $21 per un milione di token di testo in output — un'ora audio complessiva costa circa $0,54, ovvero circa $9 per 1.000 minuti audio, e il modello pre-registrato è ancora più economico, a circa $0,30 l'ora. Il silenzio è gratuito solo se il client non lo trasmette in streaming: riconnessioni, audio duplicato e logging aggiungono token conteggiati alla fattura effettiva.

Il checkpoint di Microsoft è invece prezzato in ore-GPU. I soli pesi bf16 ammontano a circa 18 GB già prima di qualsiasi cache KV. I percorsi documentati sono le demo Python nel repository microsoft/VibeVoice e un plugin vLLM che espone endpoint WebSocket e compatibili con OpenAI. Non è previsto alcun prezzo per l'hosting: nessun provider ospita ancora il modello, che non è su Azure AI Foundry come il batch VibeVoice-ASR lo è da marzo. Ospitare autonomamente un LLM vocale di classe 7B significa dover mettere in conto una GPU di classe 24 GB e il proprio tempo di gestione; in cambio si ottengono una durata della sessione illimitata e la piena proprietà dei pesi. I due modelli non si escludono a vicenda, ed è proprio questo il punto dell'ultima sezione.

Mantenere la scelta economica

La scelta dipende dal fatto che serva un numero o un codice. Scegli Gemini 3.5 Transcribe Live se vuoi una trascrizione che funziona già oggi, con accuratezza pubblicata e senza dover eseguire una GPU — e se l'audio non è limitato a dieci lingue o se sei disposto a costruire da solo l'etichettatura dei parlanti, dato che l'endpoint Live non la fornisce. Scegli VibeVoice-ASR-Streaming-7B se fai self-hosting, se la durata illimitata della sessione o il rivendicato output in streaming con attribuzione ai parlanti è ciò che conta, e se sei disposto a gestire il tuo gate di valutazione perché non c'è alcun benchmark su cui fare affidamento.

Nessuna delle due scelte deve essere permanente, ed è lì che un livello di routing dimostra il suo valore — per i modelli che lavorano attorno alla trascrizione, non per la trascrizione in sé. Oggi OrcaRouter non instrada il riconoscimento vocale e nessuno dei modelli in questa pagina è nel suo catalogo; ciò che fa è offrire un’unica API ai 200+ modelli linguistici che consumano una trascrizione in tempo reale — il riassuntore, l’estrattore degli elementi d’azione, il pianificatore dell’agente vocale — ai prezzi di listino dei provider, trasferiti senza ricarico, con failover automatico tra i provider. Un taglio di prezzo da parte di un fornitore su qualsiasi modello in quello stack diventa attivo lo stesso giorno, perché i prezzi di listino vengono trasferiti e non maggiorati. La fase di trascrizione resta dove l’hai collocata; lo stack che agisce sulla trascrizione è esattamente il livello in cui un’unica chiave e un percorso di fallback trasformano un checkpoint di una settimana fa, non benchmarkato, da una scommessa in un’opzione testabile.