MonsterHouse: la latenza di un agente vocale si progetta fuori dall’LLM

Un garage che risponde ai bambini con la voce di una nave pirata è un esperimento divertente. Un garage che resta muto mentre il bambino aspetta, invece, è soltanto una porta con un proiettore. La differenza non è necessariamente nel modello linguistico: spesso è nei millisecondi che il sistema perde prima, durante e dopo la generazione. Ed è questo il dettaglio più interessante di MonsterHouse, il progetto Halloween raccontato il 30 ottobre 2026 da Rick Grandy e Maryam Motamedi di NVIDIA.

Nella descrizione tecnica originale di MonsterHouse, il personaggio ascolta i visitatori, risponde con un carattere burbero e muove una bocca animata sul portone. Tutto gira su una workstation locale. Dietro la scena, però, non c’è un unico modello che “fa tutto”: ci sono riconoscimento vocale, generazione del testo, sintesi della voce, animazione, regole di conversazione e una console per intervenire. Il risultato dipende da come questi pezzi vengono coordinati.

Due numeri, e la domanda sbagliata

L’autore riporta una mediana di 1,70 secondi tra fine del parlato del visitatore e inizio dell’audio generato con Bolt Q4 e TTS. Per le risposte già registrate la mediana dichiarata scende a 0,72 secondi. Il rilevamento della fine della frase, nella configurazione descritta, attende 300 millisecondi di silenzio. Sono misure della sua installazione, sul suo hardware e con il suo flusso di test: non un benchmark indipendente, non un confronto controllato fra modelli e soprattutto non una promessa per qualsiasi PC.

La lettura superficiale sarebbe: “serve un LLM più veloce”. Quella utile è diversa: quanto tempo consuma ciascun confine fra la voce di chi parla e la prima sillaba che esce dagli altoparlanti? Il tempo percepito nasce dalla pipeline completa. Un modello capace di produrre token rapidamente può convivere con una pessima esperienza se il sistema aspetta troppo a capire che l’utente ha finito, se accumula il testo prima di inviarlo al sintetizzatore o se l’audio deve attendere un altro componente.

La pipeline non è una somma ingenua di tempi

Nel progetto, Nemotron Speech ASR trasforma la voce in testo; Nemotron 3.5 Bolt E4B, nella variante quantizzata da 4 GB, produce la risposta; Magpie TTS Zeroshot la rende parlata; Audio2Face-3D guida l’animazione dentro Unreal Engine 5. È una pipeline vocale a cascata, con rilevamento dell’attività vocale e della fine del turno. La componente visiva che interpreta i costumi, Nemotron 3 Nano Omni, è opzionale: non serve per ogni risposta.

Conviene distinguere almeno cinque orologi: quando viene riconosciuta la fine del turno, quando è disponibile una trascrizione utilizzabile, quando il modello produce il primo frammento pronunciabile, quando il TTS consegna audio riproducibile e quando l’animazione può accompagnarlo. A questi si aggiungono code, trasferimenti fra processi e attese imposte dall’interfaccia. Non tutti i tempi si sommano in sequenza: streaming e sovrapposizione dei lavori permettono di avviare una fase mentre quella precedente non è completamente conclusa.

Il punto è misurare gli eventi corretti, non soltanto i token al secondo. La pagina di presentazione di Bolt E4B spiega perché un modello orientato a risposte brevi e modalità conversazionale può essere adatto a un agente vocale. Ma il tempo al primo token non coincide con il tempo alla prima parola ascoltata. In mezzo c’è ancora software.

La prima ottimizzazione è evitare lavoro che non serve

MonsterHouse adotta due scorciatoie distinte. Una banca di testi preparati evita la generazione di nuove risposte per saluti e battute ricorrenti. Una banca di registrazioni evita anche il passaggio dal testo alla voce. Non sono la stessa cache: la prima conserva flessibilità nella resa vocale, la seconda offre un percorso più corto ma meno variabile. Il sistema può scegliere quale usare in base al contesto.

Questo significa che la cache non può essere un semplice dizionario di frasi. Una risposta pronta deve essere appropriata allo stato della conversazione: se il personaggio ha già ceduto alla richiesta del visitatore, non può tornare alla battuta iniziale come se non fosse successo nulla. La decisione su cosa sia riutilizzabile appartiene all’applicazione. Un prompt può suggerire il tono; non dovrebbe essere l’unico posto in cui si conserva il fatto che qualcuno abbia già detto “per favore”.

La latenza non si risolve chiedendo al modello di essere più veloce. Si risolve decidendo quali operazioni devono davvero aspettare il modello.

Anche la generazione incrementale conta. Il testo viene rilasciato al sintetizzatore quando è già pronunciabile, senza attendere necessariamente la risposta completa. È un compromesso: segmenti troppo piccoli possono creare pause innaturali; segmenti troppo grandi aumentano l’attesa. La metrica da osservare non è soltanto la rapidità della generazione, ma la continuità dell’audio che arriva a chi ascolta.

La voce del personaggio e la voce che muove la bocca non sono la stessa cosa

C’è un dettaglio tecnico che rischia di perdersi fra i nomi dei modelli. Per ottenere una voce teatrale, profonda e piena di effetti, l’autore non manda direttamente quella traccia alterata al sistema di animazione. Audio2Face-3D riceve una voce pulita, più adatta a pilotare il movimento; una seconda traccia aggiunge gli effetti per gli altoparlanti. È una separazione di responsabilità concreta: il segnale migliore per far capire qualcosa a un modello non coincide sempre con il segnale migliore per il pubblico.

L’autore riferisce anche una compensazione di 100 millisecondi per il buffering di Audio2Face-3D. Non è una soglia universale da copiare: è un aggiustamento della sua catena. Se audio e animazione non arrivano insieme, il personaggio perde credibilità anche quando la risposta è corretta. Il sincronismo diventa quindi un requisito misurabile, non un effetto estetico da sistemare alla fine.

Una workstation locale non significa hardware leggero

Il sistema descritto usa due GPU professionali: una NVIDIA RTX PRO 6000 Blackwell Max-Q per linguaggio e voce e una RTX PRO 4000 Blackwell per Unreal Engine e Audio2Face-3D. L’autore spiega che la separazione serve soprattutto a non far oscillare il carico di calcolo dell’animazione quando la pipeline AI è occupata. Non basta leggere “4 GB” nel nome di Bolt e dedurre che l’intera esperienza funzioni con quattro gigabyte di memoria o su qualunque portatile.

La scelta di eseguire tutto in locale può ridurre dipendenze di rete e offrire maggiore controllo sul flusso dei dati. Non elimina però i problemi di capacità, consumi, manutenzione, logging e gestione dei microfoni. Per capire se l’architettura è trasferibile a un chiosco, a una postazione aziendale o a un dispositivo embedded bisogna dimensionare l’intero percorso, non il solo LLM. È un tema vicino a quello già discusso parlando di modelli locali piccoli e affidabilità reale.

Stato e fallback: il tempo serve anche a sapere quando non rispondere

Il personaggio cambia atteggiamento se il visitatore insiste con gentilezza. L’autore descrive una sequenza di saluto, resistenza, concessione e commiato; l’applicazione conserva il progresso dell’incontro. È la parte meno vistosa e più utile per chi progetta interfacce vocali: l’LLM interpreta la frase, ma la regia deve sapere in quale fase si trova il dialogo e quali transizioni sono consentite.

MonsterHouse dispone inoltre di modalità di dimostrazione e di una modalità microfono con cui l’operatore può parlare attraverso la casa, saltando riconoscimento, generazione e sintesi. Non è un fallimento dell’AI. È un percorso alternativo che consente di far continuare l’esperienza quando un componente è lento, disconnesso o inadatto alla situazione. La stessa logica vale in sistemi più seri: fallback e override sono parte del progetto, non un bottone di emergenza aggiunto dopo.

Il problema dello stato applicativo ricorre anche nei workflow con agenti e orchestratori deterministici. Qui, però, c’è una difficoltà ulteriore: ogni transizione avviene mentre una persona sta aspettando una risposta, e il ritardo stesso modifica il significato dell’interazione.

Come collaudare un agente vocale prima di metterlo davanti a persone vere

Un test sensato non si esaurisce con la frase pronunciata bene in una stanza silenziosa. Occorre registrare timestamp e risultati per turni reali, separando almeno riconoscimento, decisione, sintesi, consegna dell’audio e sincronizzazione. Una mediana è utile per descrivere il comportamento tipico; per progettare il servizio servono anche la coda lenta della distribuzione, gli errori e i casi in cui non parte alcuna risposta.

• Interruzioni: una persona ricomincia a parlare mentre il personaggio sta rispondendo. Chi ferma l’audio e chi decide quale turno resta valido?
• Ambiguità di fine frase: una pausa breve non è necessariamente la fine del discorso. Ridurre troppo la soglia può rendere l’agente maleducato.
• Cache e stato: una risposta registrata è ancora corretta dopo un cambio di fase, un secondo visitatore o una domanda imprevista?
• Degrado controllato: cosa succede quando ASR, TTS, motore grafico o collegamento tra processi non rispondono?
• Metriche: misurare tempo alla prima sillaba, interruzioni, turni senza risposta, sincronismo e almeno p50/p95 su scenari ripetibili.

Nel racconto originale compare anche un test sintetico con cinque pecore travestite per il riconoscimento visivo dei costumi. L’autore chiarisce che non dimostra il successo con visitatori reali: gruppi, illuminazione notturna e costumi veri richiedono ancora prove. Lo stesso rigore deve valere per la voce. Una demo che funziona con input preparati dimostra una possibilità tecnica; un sistema affidabile richiede test nelle condizioni in cui verrà usato.

La lezione di MonsterHouse non è il modello

MonsterHouse è un esperimento personale, non un prodotto finito con prestazioni certificate. Il codice specifico del progetto non risulta distribuito come pacchetto pronto, anche se il blueprint vocale NVIDIA e i modelli di base sono disponibili. Proprio questa distinzione lo rende interessante: mostra decisioni di architettura, compromessi e scorciatoie che non si vedono nella classica demo di un chatbot che parla.

La domanda da portarsi a casa non è quale modello montare per far parlare un portone. È quale parte dell’esperienza deve essere generata, quale può essere preparata, quale deve restare deterministica e quale percorso rimane disponibile quando qualcosa si interrompe. Un’interfaccia vocale naturale non nasce dal modello più eloquente. Nasce da un sistema che sa quando ascoltare, quando iniziare a parlare e quando togliersi di mezzo.