Prestazioni, concorrenza e capacity planning per la voice AI

Nota sull'ambito. Un risultato di capacità vale solo per il carico di lavoro, il modello, la voce, l'hardware, il software e la configurazione di serving testati. Questa guida fornisce un metodo per produrre un risultato, non un numero universale di chiamate per GPU.

Punti chiave

• Misurate l'intervallo dalla fine del turno al primo audio riproducibile per l'esperienza utente, e conservate i timestamp dei singoli componenti per la diagnosi.
• Guidate i test con arrivi, comportamento di sessione, testi e durate audio realistici. Un ciclo a concorrenza fissa non sostituisce un modello degli arrivi.
• Definite la capacità utilizzabile come il carico più alto testato che soddisfa ancora tutti gli obiettivi di latenza, errore, coda e ripristino.
• Trattate p99, real-time factor e utilizzo della GPU come evidenze con un ambito dichiarato, non come dichiarazioni di capacità a sé stanti.
• Quotate la capacità utilizzabile testata, incluso il lavoro fallito e annullato, invece di dividere il costo per il throughput di picco teorico.

Ultimo aggiornamento: agosto 2026. Qui non viene dichiarato alcun risultato di capacità o latenza dell'hardware KugelAudio.

Quale latenza percepisce davvero l'utente di un sistema di voice AI?

L'utente percepisce l'intervallo tra la fine del proprio turno e l'inizio di una riproduzione utile. A seconda dell'applicazione, questo comprende il rilevamento di fine turno, la trascrizione, la logica applicativa, l'output del modello linguistico, la normalizzazione del testo, il TTS, il trasferimento di rete, la decodifica e un buffer di riproduzione. Il solo tempo di inferenza del modello non descrive quell'esperienza.

Strumentate una traccia con timestamp monotoni su questi confini:

user turn end
-> transcript ready
-> first stable text sent to TTS
-> TTS request admitted
-> synthesis starts
-> first audio byte received
-> enough valid audio is decoded and buffered
-> playback starts
-> synthesis completes or is cancelled

Date alla metrica il nome dei suoi estremi. Per esempio, il time to first audio (TTFA) del TTS può andare dall'ammissione della richiesta al primo chunk audio, mentre il primo audio riproducibile percepito dall'utente va dalla fine del turno all'inizio della riproduzione. Il primo byte di rete può essere un header o un frame parziale, quindi non è automaticamente audio riproducibile. Registrate insieme al risultato la regione del client, il riuso della connessione, il codec, la frequenza di campionamento e la regola del buffer di riproduzione.

La guida allo streaming e al chunking di KugelAudio documenta come il chunking lato server e il comportamento di flush del client incidano sul TTFA. Non elimina la necessità di misurare l'intero percorso applicativo.

In pratica: eseguite questi test come scenari distinti. Combinare avvii a freddo, picchi e traffico costante in un unico aggregato nasconde la causa di un percentile lento.

Come deve modellare il carico di produzione un test di capacità?

Partite da un manifest del carico di lavoro versionato, non da un conteggio generico di richieste. Includete:

• tasso di arrivo delle sessioni e distribuzione dei picchi;
• chiamate in corso, turni per sessione e tempo di riflessione tra i turni;
• mix di lunghezza del testo, lingua, voce e normalizzazione;
• durata, formato e frequenza di campionamento dell'audio generato;
• comportamento di chunking e flush nello streaming;
• riuso delle connessioni, riconnessioni, deadline e retry;
• interruzioni, tempistica degli annullamenti e sessioni abbandonate;
• traffico rumoroso o batch che condivide le stesse dipendenze.

Usate distribuzioni di produzione anonimizzate quando sono disponibili. Altrimenti pubblicate il corpus di testo o il generatore deterministico, il seed casuale e i parametri della distribuzione. Calcolate l'hash del corpus e registrate la revisione del generatore di carico, così che un'esecuzione successiva usi lo stesso lavoro.

Scegliete il modello del generatore di carico con consapevolezza. Un generatore closed-loop attende una risposta prima di inviare la richiesta successiva; quando il servizio rallenta, invia meno lavoro e può nascondere il sovraccarico. Resta comunque utile quando è proprio la concorrenza attiva fissa la condizione di produzione. Un generatore open-loop pianifica gli arrivi indipendentemente dal completamento delle risposte. Le linee guida di Google Cloud sui test di carico spiegano questa distinzione. Per un prodotto di chiamata, modellate l'avvio delle sessioni come arrivi e preservate la tempistica dei turni all'interno della sessione. Riportate sia il lavoro pianificato sia quello effettivamente inviato, perché un generatore di carico saturo invalida l'esecuzione.

Eseguite gli esperimenti a freddo e a caldo separatamente. Definite "a freddo" in modo preciso, per esempio una nuova replica con il modello non caricato, e registrate ogni fase di avvio. Per un'esecuzione a caldo, completate il warm-up dichiarato e iniziate a misurare solo dopo che throughput, coda e segnali di risorsa soddisfano una regola di stabilità dichiarata in anticipo. Non mescolate la prima richiesta in un percentile a caldo e non scartatela senza riportare il risultato a freddo.

Come si combinano concorrenza, legge di Little e real-time factor?

"Chiamate concorrenti" può significare socket aperti, sessioni attive, turni in attesa in coda o stream che stanno generando audio. Pubblicate ciascun valore separatamente. Il lavoro attivo consuma risorse di inferenza, il lavoro in coda aggiunge attesa e occupa risorse di servizio, e i chiamanti inattivi contano comunque per connessioni e memoria.

In un sistema stabile, la legge di Little mette in relazione le medie di lungo periodo:

L = lambda * W

L       average work in the measured system
lambda  effective throughput per second
W       average time each item spends in that system, in seconds

Usatela come verifica di coerenza e come stima iniziale del carico di lavoro. Non predice la latenza di coda, il throughput massimo o il margine necessario. Definite lo stesso confine per tutti e tre i termini, contate il lavoro completato invece di usare tacitamente quello offerto, e non applicate la relazione di stato stazionario a una finestra in cui la coda sta ancora crescendo.

Il real-time factor (RTF) risponde a una domanda diversa:

RTF  = synthesis elapsed time / generated audio duration
RTFx = generated audio duration / synthesis elapsed time = 1 / RTF

Un RTF più basso è più veloce; un RTFx più alto è più veloce. La documentazione NVIDIA sulle prestazioni TTS usa RTFx e pubblica i propri input di test, gli stream paralleli e le iterazioni. Dichiarate quale convenzione e quale confine temporale usate. Un RTF di solo calcolo esclude coda e rete; un RTF end-to-end no. Nessuno dei due cattura il primo audio riproducibile, quindi riportate TTFA e interruzioni tra i chunk separatamente. Un RTF su singolo stream inferiore a uno non dimostra nemmeno che un servizio interattivo possa accettare lavoro parallelo illimitato.

Quante evidenze servono a sostenere un percentile di latenza?

Riportate accanto a ogni percentile il numero di osservazioni, la durata del test, il numero di ripetizioni, il metodo di calcolo dei quantili e i bucket dell'istogramma. Con sole 100 osservazioni riuscite, il p99 è determinato da circa una singola osservazione di coda, a seconda dello stimatore. È la descrizione di un campione piccolo, non un impegno stabile. Anche Google Cloud avverte, nelle sue linee guida sulle metriche di latenza, che un p99 calcolato su pochi dati può semplicemente coincidere con la richiesta più lenta.

Non esiste un numero universale di campioni utile. Definite in anticipo l'incertezza accettabile, poi scegliete durata e ripetizioni indipendenti in base alla variabilità del traffico. Se l'esecuzione non regge una stima di coda, riportate un percentile più basso oppure la quota di richieste che rispetta una soglia di latenza dichiarata. Definite esplicitamente la popolazione del percentile. Riportate timeout, rifiuti e annullamenti come esiti e includeteli nel denominatore di qualsiasi tasso di successo calcolato su tutti i tentativi.

Conservate gli eventi grezzi quando è possibile e mantenete istogrammi aggregabili per le operations. Il modello dati delle metriche di OpenTelemetry descrive l'aggregazione degli istogrammi. Posizionate i confini dei bucket attorno alle soglie decisionali dell'applicazione. Non calcolate la media di percentili precalcolati per istanza; Prometheus spiega perché non è valido nella sua guida agli istogrammi.

Come deve comportarsi un servizio vocale in sovraccarico?

Il sovraccarico deve essere limitato e visibile. Definite i limiti di ammissione a partire dalla deadline dell'interazione e dalla capacità di servizio testata. Quando il lavoro non può iniziare in tempo, rifiutatelo o instradatelo esplicitamente invece di accettare una coda illimitata. Un picco breve non deve trasformarsi in minuti di parlato ormai obsoleto né consumare memoria fino al collasso del servizio.

Testate il ciclo completo:

1. stabilite una baseline stabile a un tasso offerto noto;
2. applicate un picco versionato oppure rimuovete una replica;
3. osservate ammissioni, rifiuti, età della coda, latenza e lavoro attivo;
4. annullate alcuni stream e verificate che il relativo calcolo si interrompa;
5. rimuovete il guasto o il picco;
6. verificate che la coda si svuoti e che tutti i segnali rientrino nell'intervallo di baseline;
7. controllate che gli stream accettati non siano stati mescolati, duplicati o troncati.

Ritentate solo quando la deadline residua dell'utente rende utile un altro tentativo. Limitate i tentativi e usate un backoff con jitter; retry sincronizzati possono diventare nuovo carico. Le indicazioni di Google sui guasti a cascata collegano test di capacità realistici, code piccole, rifiuto anticipato e controllo dei retry. Il fallback può essere un messaggio preapprovato, un servizio dedicato separato o il passaggio a un operatore umano, ma va provato sotto carico.

Come si testano autoscaling e telemetria GPU?

L'autoscaling parte dopo che la domanda è già cambiata. Misurate il ritardo completo di scale-up: raccolta della metrica, decisione, scheduling, disponibilità dell'immagine, caricamento del modello, health check e warm-up. Il controllo di ammissione e la capacità di riserva devono proteggere le richieste durante quel ritardo. Testate anche lo scale-down, il draining delle connessioni, i rolling update e le oscillazioni, non solo lo scale-up.

Kubernetes documenta metriche custom ed esterne e il comportamento di stabilizzazione nella sua guida all'horizontal pod autoscaling. Un target generico sulla CPU non è automaticamente adatto a un TTS su GPU. Età della coda, lavoro attivo ammesso e un segnale di saturazione possono reagire in modo più diretto, ma usate solo metriche tempestive, limitate e validate rispetto alla latenza percepita dall'utente.

Utilizzo della GPU, memoria, temperatura, potenza e contatori di errori hardware spiegano perché un risultato è cambiato; non definiscono la capacità utilizzabile. Correlateli con l'attesa in coda, il tempo di sintesi, il primo audio riproducibile, il completamento e i guasti. La documentazione di NVIDIA Data Center GPU Manager descrive le funzionalità disponibili di health e telemetria. Registrate il nome della metrica, l'intervallo di campionamento, l'hardware e la versione dell'exporter invece di riportare un solitario grafico di "percentuale GPU".

Come si passa dai risultati al numero di repliche e ai costi?

Per ogni modello e mix di carico, aumentate il carico offerto a gradini e ripetete le esecuzioni al limite. La capacità utilizzabile per replica è il tasso più alto testato al quale superano tutti i gate dichiarati in anticipo su latenza, errori, stabilità della coda e ripristino. Validate poi più repliche: routing, affinità di connessione, normalizzazione condivisa, storage e dipendenze dal control plane possono impedire uno scaling lineare.

Una prima stima di pianificazione è:

replicas = ceiling(forecast peak offered rate / validated per-replica rate)

Non è il numero finale di deployment. Aggiungete capacità per lo scenario di guasto scelto, la manutenzione, l'errore di previsione e il ritardo di avvio, poi rieseguite il test su quella topologia. Il margine è una decisione di business e affidabilità, non una percentuale universale. Google SRE raccomanda la previsione della domanda e test di carico regolari per collegare le risorse grezze alla capacità di servizio nelle sue linee guida sul capacity planning.

Confrontate l'economia solo a parità di obiettivi superati:

cost per delivered audio hour =
  total deployment cost during the window / successful playable audio hours

cost per 1,000 completed interactions =
  total deployment cost during the window / completed interactions * 1,000

Includete calcolo, repliche inattive, orchestrazione, licenze e costi di rete attribuibili. Il lavoro fallito, rifiutato e annullato resta al numeratore, così lo spreco non viene nascosto. Pubblicate l'utilizzo e la data dei prezzi. Un risultato di saturazione più economico che manca l'obiettivo di latenza non è un sistema utilizzabile più economico.

Che cosa deve contenere un report di capacità riproducibile?

Un report deve fornire il manifest del carico di lavoro e l'hash del corpus; la revisione e la topologia del generatore di carico; le regioni di client e server; la sorgente di clock; le versioni di modello, voce, normalizzazione e serving; hardware, driver e modalità di alimentazione; la configurazione di repliche, batching e code; le finestre di warm-up e di misurazione; distribuzioni di latenza grezze o aggregabili; il lavoro offerto, ammesso, rifiutato e completato; la durata dell'audio prodotto; ogni classe di guasto e di annullamento; le tracce delle risorse; e la cronologia di sovraccarico e ripristino.

Chiudete con decisioni, non con aggettivi: il carico superato, il gate fallito, il numero di repliche scelto, la riserva per i guasti, i limiti di autoscaling e il trigger di riesecuzione. Le indicazioni SRE di Google sugli obiettivi di livello di servizio sono un framework utile per derivare quei gate dalle aspettative degli utenti.

Per KugelAudio operato dal cliente, la guida al deployment self-hosted documenta la distribuzione su Kubernetes tramite un Helm chart. Non pubblica una garanzia che leghi hardware e concorrenza. Dimensionate il modello, l'hardware e il carico scelti con il metodo descritto sopra.

Quali sono i limiti di questa guida?

Questo articolo non effettua benchmark su una GPU, un modello, una voce o un deployment specifici. Non prescrive nemmeno un obiettivo di latenza conversazionale, una dimensione di coda o un margine di sicurezza. Quelle decisioni dipendono dal flusso di chiamata, dalle aspettative degli utenti, dalla variabilità del traffico, dalla politica sui guasti e dalle evidenze prodotte dal sistema reale.

FAQ

Il time to first byte coincide con il tempo al primo audio riproducibile?

No. Il primo byte può essere un header o un frame parziale. Il primo audio riproducibile è il momento in cui il client dispone di audio decodificato valido e di buffer sufficiente per iniziare la riproduzione secondo la politica dichiarata del player.

Perché la latenza media non basta?

Una media nasconde la distribuzione e non dice nulla sugli errori. Riportate il numero di osservazioni, i percentili selezionati, la quota entro soglia, gli errori, i timeout, i rifiuti e gli annullamenti per la stessa finestra di misurazione.

Quante chiamate può gestire una GPU?

Solo un benchmark corrispondente può rispondere. Modello, hardware, build di serving, testo e durata audio, comportamento di streaming, mix di carico e obiettivo di latenza cambiano tutti la concorrenza utilizzabile.

Un RTF inferiore a uno basta per un agente vocale in tempo reale?

No. Mostra che l'intervallo di sintesi misurato è stato più breve della durata dell'audio generato. Non stabilisce il primo audio riproducibile, il ritardo in coda, la latenza di coda, il comportamento in caso di annullamento o la capacità multi-stream.

L'utilizzo della GPU deve attivare l'autoscaling?

Solo se i test dimostrano che anticipa la pressione sugli utenti con sufficiente margine. Confrontatelo con l'età della coda, la generazione attiva, il tasso di ammissione, la latenza percepita dall'utente e il tempo effettivo necessario perché una nuova replica sia pronta.

Che cosa deve succedere quando la capacità è esaurita?

Smettete di ammettere lavoro che non può rispettare la propria deadline, emettete un esito esplicito di sovraccarico e attivate il fallback testato. Non nascondete la domanda in eccesso in una coda illimitata o in un ciclo di retry immediati.

Ogni quanto vanno ripetuti i test di capacità?

Ripeteteli dopo modifiche sostanziali a modello, runtime, driver, hardware, normalizzazione, routing, politica di autoscaling o carico di lavoro. Rieseguiteli anche prima di assumere o rinnovare un impegno di capacità in produzione.