Bilanciamento della latenza molto bassa e degli aspetti economici del cloud negli agenti vocali virtuali

Devin Reimer

Ti diamo il benvenuto nel corso Bilanciare latenza molto bassa ed economia del cloud negli agenti vocali virtuali.

Sono Devin Reimer.

Sono il fondatore e CEO di AstroBeam.

In precedenza, ero CEO e cofondatore di Owlchemy Labs, probabilmente più noto per Job Simulator.

Quindi, in AstroBeam, ci concentriamo sulla creazione di AI in tempo reale nei giochi.

In particolare, ci concentriamo molto sulla voce come input.

Finora abbiamo pubblicato due titoli: Stellar Cafe, disponibile per VR e PC,

È un gioco in cui parli con i robot nel bar di una stazione spaziale e li aiuti a risolvere i loro problemi.

È basato al 100% sulla voce.

Puoi giocare l'intero gioco, inclusi i menu e la navigazione, solo con la tua voce.

Il nostro prossimo gioco, che abbiamo appena annunciato oggi, Robo Detective, è stato creato per Android XR e, in particolare, per Project Aura di XREAL.

In questo gioco, interpreti un detective che lavora con un partner robot per intervistare i robot e risolvere i crimini dei robot. Anche in questo caso, il gioco è basato al 100% sulla voce.

Quindi, gli agenti vocali sono davvero difficili da creare e, nei giochi, lo sono ancora di più.

Il motivo è che i giochi sono prodotti a basso costo e un agente vocale rappresenta un nuovo costo da aggiungere alla pipeline.

Inoltre, non siamo in competizione con altri agenti vocali, ma con la qualità di ogni gioco mai realizzato, giusto?

Quindi, dobbiamo offrire una qualità molto elevata.

Questo non significa che non esistano casi d'uso specifici degli agenti vocali con sfide uniche o con una posta in gioco molto più alta, ma i giochi sono sicuramente molto impegnativi dal punto di vista tecnico in questo ambito.

Tuttavia, trattandosi di giochi, c'è molto spazio per sperimentare come risolvere alcuni di questi problemi difficili.

Quindi, credo che se gli agenti vocali possono funzionare nei giochi, possono funzionare quasi ovunque.

Quindi, le cose di cui parlo in questo intervento non si applicano solo ai giochi, ma a qualsiasi applicazione voice-first che vuoi creare.

Quindi, quando pensi agli agenti vocali, credo che ci siano tre sfide principali.

Quindi, abbiamo latenza, intelligenza e costi.

Tuttavia, voglio chiarire una cosa: quando parlo di agenti vocali, mi riferisco agli agenti vocali come conversazione, non come prompt.

Non sto parlando di un wrapper per microfono che invia qualcosa a un LLM e poi attende una risposta.

Sto parlando di uno scambio reale e in tempo reale, ed è proprio questo che diventa piuttosto difficile da creare.

Iniziamo con la latenza.

Quanto deve essere veloce?

A quanto pare, deve essere veloce, molto veloce, ma a seconda di ciò che hai letto, potrebbe non essere così veloce come pensi o potrebbe essere molto più veloce di quanto pensi.

Parliamo quindi di alcuni numeri che abbiamo scoperto in molti dei nostri test.

Quindi, quando parlo di latenza end-to-end, mi riferisco al tempo che intercorre tra l'ultimo enunciato dell'utente, l'ultimo suono emesso dall'utente, e il momento in cui l'utente sente l'audio di ritorno.

Dai nostri test è emerso che 1,5 secondi è il punto in cui, quando riceviamo feedback dai playtest degli utenti, questi ultimi smettono di menzionare la velocità o la lentezza o cose simili.

Sembra che sia questo il punto in cui le persone iniziano a sentirsi davvero a proprio agio.

Se i tempi si allungano, le persone spesso dicono: "È fantastico, ma…", quindi sembra che questo sia il punto di equilibrio.

Poi, man mano che la velocità aumenta, abbiamo scoperto che a circa 1,2 secondi inizia a verificarsi un'interazione ancora più naturale, come un botta e risposta.

Quindi, io dico qualcosa, in questo caso il robot, dirà qualcosa molto velocemente e si va avanti e indietro.

Sembra che ci sia un punto di equilibrio che si è sbloccato.

Detto questo, 1,2 secondi è un tempo piuttosto difficile da raggiungere all'interno di uno stack.

Un altro risultato interessante è che abbiamo eseguito molti test e, alla fine, abbiamo ottenuto alcuni scenari per raggiungere un tempo inferiore a un secondo.

E quindi potresti pensare: "Oh, sarà fantastico!"

A volte lo era, a volte era terribile, molto inquietante.

Quindi, potresti sentire persone che dicono che il tempo di risposta giusto è 800 millisecondi o 500.

Ho persino letto un sacco di articoli su 300, perché è lì che si colloca la percezione umana.

La realtà è che dipende molto dal contesto.

Ad esempio, se ti chiedo come ti chiami, ho un'aspettativa su quanto tempo impiegherai a rispondere.

Se ti chiedo qual è il significato della vita, mi aspetto un tempo di risposta molto diverso.

Quando abbiamo eseguito i test e chiesto alle persone di valutare se la risposta sembrava veloce o lenta, i numeri erano molto diversi.

Le risposte che richiedevano molto tempo venivano definite veloci e viceversa, perché si è scoperto che dipendeva molto dal contesto.

Inoltre, dove si trovavano nella conversazione.

In genere, le persone si aspettano che la prima risposta sia più rapida di quelle successive, perché c'è un tempo di riflessione.

Ma a volte si finisce per avere uno scambio di battute molto breve, quindi le aspettative aumentano.

Quindi, non è una scienza esatta in cui esiste un numero perfetto, ma abbiamo scoperto che circa 1,5, se sei in quel punto, stai andando abbastanza bene.

Quindi, una volta raggiunto questo punto di 1,5 secondi, inizi davvero a preoccuparti della coerenza, giusto?

Perché se questo accade il 90% delle volte, ma il 10% delle volte l'operazione richiede 3 secondi, l'esperienza sembrerà non funzionante, non negativa, ma non funzionante.

E così, finiamo per… Una volta che si raggiunge una velocità sufficiente, ci si preoccupa solo della coerenza, quindi della velocità costante, non della velocità nella maggior parte dei casi.

Devin Reimer

Ecco un'architettura di pipeline vocale standard.

Quindi, prendiamo la trascrizione vocale, la inviamo a un LLM e poi inviamo il risultato dell'LLM alla sintesi vocale.

In altre parole, con la trascrizione vocale inviamo l'audio al server e poi lo convertiamo in testo.

Sul lato LLM, prendiamo quel testo, quel dialogo di risposta, o lo convertiamo in un dialogo di risposta, e poi quali azioni verranno eseguite da quel personaggio.

Abbiamo accoppiato strettamente questi due aspetti perché riteniamo che sia molto importante.

Poi, per quanto riguarda la sintesi vocale, prendiamo il testo, lo inviamo alla nostra sintesi vocale e lo trasmettiamo all'utente, anche in questo caso in sincronia con le azioni che l'agente vuole eseguire.

Uno dei problemi è che l'esecuzione sequenziale può essere piuttosto lenta, perché devi esaminare ogni singolo elemento.

Una domanda comune che mi viene posta è: se questo processo è lento e richiede tre passaggi, perché non utilizzare un modello speech-to-speech?

Perché sarebbe più veloce, giusto?

E sì, nella maggior parte dei casi sarebbe più veloce perché esegui una sola cosa.

Tuttavia, presenta alcuni svantaggi significativi.

Quindi, anche se è veloce, ci sono alcuni aspetti che non ci convincono, il più importante dei quali è il costo.

In generale, abbiamo riscontrato che l'esecuzione di un modello Speech-to-Speech è da 3 a 5 volte più costosa rispetto a questo approccio parallelizzato.

Per noi, quindi, l'aspetto economico non funziona.

Per quanto riguarda la sicurezza, in realtà è un po' più complicato perché è più difficile convalidare la risposta che l'agente darà finché non la dice.

Nel frattempo, se hai un approccio in pipeline, puoi prendere la risposta dell'LLM e convalidarla ed eseguire un controllo di sicurezza prima ancora di avvicinarti all'invio di elementi a un utente.

Per quanto riguarda lo stile della voce, sei vincolato ai preset di quel modello Speech-to-Speech.

Non puoi dire: "Oh, sai una cosa?

Per questo caso, voglio davvero utilizzare questo tipo di voce".

Sei vincolato a quel particolare tipo.

Con l'approccio basato su pipeline, puoi dire: "Oh, cambierò le cose.

Sceglierò questo modello perché funziona molto bene per questo caso d'uso specifico."

E lo stesso vale per l'intelligenza, giusto?

Se hai un modello Speech-to-Speech davvero valido che produce una buona voce, ma l'intelligenza non è esattamente quella che desideri, non puoi semplicemente sostituirlo, giusto?

Sei un po' vincolato.

Nell'approccio in pipeline, dici: "Oh, per questo caso d'uso, voglio utilizzare un modello specifico".

Un'area in cui la funzionalità Speech-to-Speech è sicuramente vincente è la comprensione del tono dell'utente.

Ad esempio, il sarcasmo e cose del genere.

Al momento, le trascrizioni da voce a testo in genere non contengono molte di queste informazioni, ma penso che la situazione cambierà nel tempo.

Questo è sicuramente un punto a favore di Speech-to-Speech.

Quindi, Speech-to-Speech ha sicuramente un vantaggio in termini di velocità, ma presenta anche alcune sfide in termini di configurabilità e il costo elevato, in particolare per noi, è stato un fattore determinante.

Quindi, esiste un altro modo?

Sì.

Dovremmo fare del nostro meglio per parallelizzare la pipeline.

Per questo motivo, alcune delle cose che facciamo sono eseguire l'LLM prima che la trascrizione vocale sia completamente affidabile.

E per confidenza intendo la confidenza nelle parole generate nella trascrizione e poi la confidenza della fine del turno.

Quindi, non appena pensiamo che ci sia la possibilità che questo sia il momento in cui l'utente ha smesso di parlare e che questo sia ciò che ha detto, andiamo avanti.

Quindi, lo scenario peggiore è che ci sbagliamo, giusto?

L'utente continua a parlare.

Tuttavia, anche in questo scenario, tutto ciò che facciamo è annullare l'LLM e poi eseguirlo di nuovo.

E poiché il contesto sarà probabilmente memorizzato nella cache e non abbiamo generato molti token, non è un'operazione molto costosa e il vantaggio è che l'utente finisce per sentire le cose più velocemente di quanto farebbe se aspettasse la piena sicurezza.

Inoltre, non aspettiamo che l'LLM finisca di generare l'intera risposta prima di iniziare a inviarla a Text-to-Speech.

Quello che aspettiamo è una sorta di primo blocco di testo pronunciabile.

Nella maggior parte dei casi, si tratta di una frase.

A volte possono essere altre configurazioni, ma non appena abbiamo il primo blocco di frasi, lo inviamo alla nostra API Text-to-Speech.

E poi, se abbiamo un buon sistema di sintesi vocale che trasmette in streaming, non appena è pronto per lo streaming, può essere inviato all'utente.

Inoltre, prestiamo molta attenzione al numero di token da generare.

Quindi non utilizziamo elementi come wrapper JSON e simili che potrebbero aggiungere token aggiuntivi.

Cerchiamo di capire qual è la struttura più semplificata per ottenere la risposta più rapida possibile.

Utilizziamo anche elementi come la precompilazione dell'assistente se sappiamo in anticipo quale sarà il primo gruppo di token dell'agente.

Quindi, per la sintesi vocale, sono stati creati questi due blocchi, giusto?

In questo modo, il primo segmento di testo idoneo alla lettura viene elaborato e poi viene eseguito tutto il resto.

Tuttavia, poiché l'ascolto della riproduzione audio richiede più tempo della generazione, quasi sempre la riproduzione del primo chunk per l'utente sarà terminata quando il secondo chunk sarà pronto.

Quindi, in realtà, è invisibile all'utente.

Arriva il più velocemente possibile.

Quindi, quando pensi di scegliere servizi diversi, ecco alcune delle nostre regole generali.

Quando si tratta di scegliere un buon tipo di framework audio e di agenti, ciò che conta è la latenza più bassa in entrata e in uscita.

Quindi, quanto velocemente posso inviare e scaricare i dati?

Per quanto riguarda la conversione da voce a testo, ci interessa il tempo necessario per raggiungere la certezza.

Quindi, si tratta di affidabilità della trascrizione e affidabilità della fine del turno.

Quelli accoppiati, giusto?

Se non hai fiducia in uno, sarà lento come quello, giusto?

Quindi è veloce quanto il più lento al suo interno.

Per quanto riguarda gli LLM, ci interessa il tempo necessario per la prima frase, ovvero il primo blocco pronunciabile.

Quindi sono due parti, giusto?

È il tempo al primo token combinato con i token al secondo.

Quindi, se all'improvviso trovi un modello davvero valido che ti offre un tempo al primo token molto buono, ma è lento in termini di token al secondo, potrebbe essere peggiore dell'alternativa.

Quindi, trova la combinazione giusta per questo.

Per quanto riguarda la sintesi vocale, invece, è importante il tempo necessario per il primo audio.

Quindi è molto importante misurarla, perché a volte l'audio può tornare con un silenzio iniziale che l'utente non sentirà.

Quindi, devi effettivamente misurare fino al punto in cui l'utente sente i suoni.

Inoltre, come ho già detto, la priorità assoluta è la stabilità, non le velocità di picco o lo scenario migliore.

Qual è la latenza costante di questo intero stack?

Devin Reimer

Al momento, per i nostri framework di agenti audio, utilizziamo LiveKit.

Per la conversione da voce a testo, utilizziamo Deepgram.

Per gli LLM, utilizziamo Gemma 4 31B, che ospitiamo su LiveKit.

Per quanto riguarda la sintesi vocale, utilizziamo Inworld AI text-to-speech 2.

Inoltre, abbiamo creato l'intera infrastruttura agentica dell'agente AI AstroBeam che non solo unisce tutto questo, ma aggiunge tutti gli elementi necessari per avere un agente vocale davvero valido, in particolare uno altamente interattivo come il nostro per i giochi.

Una cosa di cui non ho parlato sono i modelli di sicurezza.

Quindi, tradizionalmente, i modelli di sicurezza fanno parte del passaggio dell'LLM, ma questo aggiunge latenza e un passaggio aggiuntivo.

E se invece gestissi il tuo?

Quindi, questo è l'aspetto del nostro stack.

Quindi, quando riceviamo il primo blocco di testo, il primo blocco pronunciabile che invieremo alla sintesi vocale, lo inviamo contemporaneamente al nostro modello di sicurezza.

Inoltre, poiché il modello di sicurezza è più piccolo e viene eseguito più velocemente rispetto alla trascrizione vocale, viene quasi sempre eseguito in anticipo.

Ciò significa che l'aggiunta di un modello di sicurezza non aggiunge latenza al nostro stack e, ancora meglio, si tratta di una parte abbastanza consistente da consentirci di eseguire un modello di sicurezza molto più grande di quello che la maggior parte delle persone pensa di eseguire.

Questo è molto importante per noi, soprattutto perché stiamo sviluppando giochi.

Ci sono molti aspetti di quel mondo che sono molto importanti.

Ad esempio, supponiamo che tu stia creando un gioco medievale e che un NPC in questo gioco medievale gridi "Carica!"

"Tagliategli la testa!", giusto?

Un modello di sicurezza tradizionale potrebbe dire: "Ehi, non va bene.

Non dovresti dirlo."

Ma nel contesto di questo gioco, ha perfettamente senso.

Per farlo, utilizziamo un modello di sicurezza un po' più solido, con un contesto molto più ampio di ciò che accade nel mondo, in modo da poterlo far funzionare.

Come puoi notare, il modello di sicurezza viene eseguito due volte: prima sul primo chunk e poi sull'intero contenuto, quando abbiamo il chunk finale.

Ancora una volta, dobbiamo eseguirlo due volte, ma non aggiunge latenza allo stack.

Quindi, ora siamo abbastanza veloci, ma purtroppo questo non ha importanza se non siamo abbastanza intelligenti.

Devin Reimer

Quindi, quanto deve essere smart?

Deve essere abbastanza smart per i tuoi utenti, ma soprattutto abbastanza smart per consentirti di sviluppare.

E questo è spesso un aspetto a cui le persone non pensano quando scelgono ciò di cui hanno bisogno per l'intelligence.

Lavoriamo sugli agenti vocali da circa tre anni e, ad esempio, nei primi tempi utilizzavamo alcuni dei primi modelli LLaMA e, sebbene fossimo in grado di farli funzionare per gli utenti, lo sviluppo era molto costoso perché tutto era molto fragile.

Non ci voleva molto perché i modelli generassero risposte indesiderate o cose che non avevano senso, quindi abbiamo dedicato molto impegno ingegneristico per far funzionare tutto.

Per questo motivo, diamo la priorità a questo aspetto, perché se non riusciamo a muoverci velocemente nella creazione di queste cose, non possiamo offrire i prodotti agli utenti.

Quindi, è molto importante pensare a entrambi.

Quindi, spesso quando le persone pensano all'intelligence, pensano all'LLM, giusto?

Ma questa è solo una parte.

Quando si parla di intelligence, dobbiamo pensare a ogni singolo elemento.

Parliamo ora dell'intelligence della conversione della voce in testo.

Quindi, ciò che ci interessa qui è un basso tasso di errore delle parole.

Inoltre, non è solo il tasso di errore a essere basso, ma quando si verifica, generiamo qualcosa di molto vicino alla realtà, perché se è molto vicino, l'LLM può spesso, con il contesto, fare un ottimo lavoro per capire di cosa si tratta.

Se il tasso di errore è basso, ma i passi falsi sono molto elevati, l'LLM farà molta più fatica a capire quale fosse l'intento effettivo.

Un altro aspetto da considerare è la piattaforma di destinazione.

Ad esempio, se sto creando un'applicazione per XR e ho dei microfoni molto vicini alla bocca dell'utente, avrò dati audio di ottima qualità, che potrebbero funzionare molto bene per determinati modelli.

Ma se all'improvviso creo un'app per uno smartphone che le persone useranno in una strada affollata, l'impatto è molto diverso e i vari modelli si comporteranno in modo diverso e saranno in grado di capire in modo intelligente ciò che viene detto in modi diversi.

Quindi devi pensarci e assicurarti di scegliere la piattaforma giusta per cui stai sviluppando.

Passiamo ora al lato della sintesi vocale dell'equazione dell'intelligence.

Sembra naturale, vero?

Il nostro obiettivo è comunicare all'utente cosa può capire.

Ma questa è solo una parte, giusto?

Anche l'espressività di questo agente è molto, molto importante perché l'espressività contiene informazioni e, inoltre, nei nostri test di gioco abbiamo scoperto che più i nostri agenti sono espressivi, più gli utenti li percepiscono come intelligenti, il che ha molto senso.

E poi, è abbastanza veloce?

Nella sezione precedente ho parlato di latenza, ma in realtà è importante anche qui per l'intelligenza percepita.

Gli utenti percepiscono la velocità di risposta come direttamente correlata alla sua effettiva intelligenza.

Se ho una risposta rapida, probabilmente sembra più intelligente.

Quindi, questi aspetti possono davvero fare la differenza per quanto riguarda il modo in cui l'utente percepisce l'esperienza e il suo livello di coinvolgimento.

Passiamo ora al lato LLM dell'intelligence.

Questo è di gran lunga l'aspetto più difficile da bilanciare, perché i requisiti sono molti, giusto?

Quindi abbiamo una sorta di comprensione del parlato, del contesto e del grounding.

Nei giochi, questo è molto difficile, perché devi basarti su un intero mondo e universo, giusto?

Non si tratta di una casella di testo in cui può inventare cose che stanno accadendo.

Se l'agente all'interno di un gioco dice "C'è una mela sul tavolo" e non c'è nessuna mela sul tavolo, l'esperienza dell'utente verrà interrotta.

Abbiamo anche bisogno di cose come un forte rispetto delle regole.

I giochi sono molto basati sulle regole.

L'LLM è in grado di gestire questa situazione?

Possiamo avere un tasso di allucinazione basso?

Possiamo avere personaggi coerenti quando interagisci con lo stesso agente più e più volte?

Ti sembra lo stesso agente?

Un altro aspetto che potrebbe metterti in difficoltà, perché non è un problema all'inizio dello sviluppo, è se il tuo modello è in grado di gestire l'aumento delle dimensioni del prompt.

Perché inevitabilmente, man mano che continui a sviluppare, inserirai più elementi nel prompt.

Ma poi, man mano che gli utenti continuano a giocare, la cronologia della chat in quel prompt aumenterà.

Quindi, il prompt gestirà questa crescita?

A volte, infatti, per alcuni modelli, man mano che il prompt cresce, la qualità della risposta diminuisce, quindi devi capire quali sono le tue effettive esigenze in termini di quantità di informazioni da inserire nel prompt ogni volta.

Ma questa è solo la punta dell'iceberg e dipende anche molto da ciò che stai creando.

Quindi devi riflettere attentamente su ciò che stai creando e su ciò che stai cercando di ottenere.

Ora siamo abbastanza veloci e intelligenti, ma tutto questo non ha importanza se i costi sono troppo elevati.

Devin Reimer

Quindi, quanto deve essere economico?

Purtroppo, è un po' più complicato di così.

Quindi dobbiamo pensare agli aspetti economici dell'applicazione o del gioco che stiamo creando, giusto?

Ecco alcune domande che devi porti.

Per quanto tempo l'utente interagirà con i tuoi agenti vocali?

Quanto guadagni per utente?

E quanto costa all'ora l'esecuzione di questo stack vocale?

Li mettiamo insieme per cercare di capire, per vedere se le cose hanno senso.

Ecco l'economia del nostro primo gioco, Stellar Cafe.

Quindi il tempo di gioco in Stellar Cafe è compreso tra 1 ora e mezza e 3 ore e mezza, quindi facciamo una media di circa 2 ore.

Il costo di gestione degli agenti vocali è di circa 1, 20 $l'ora per utente e gli utenti interagiscono con loro il 100% del tempo.

È un gioco controllato al 100% dalla voce.

Addebitiamo una tariffa fissa di 10 $per il gioco, che è un prezzo tradizionale.

Non offriamo abbonamenti perché sono molto difficili da gestire nei giochi e sono fermamente convinto che dobbiamo farli funzionare a un costo fisso, altrimenti non funzioneranno e non saranno scalabili.

In precedenza, addebitavamo 15 $, ma abbiamo lavorato per ridurre i costi dei server, quindi ora siamo scesi a 10 $.

E questo 1, 20 $è il punto in cui ci troviamo.

Non si tratta di un costo universale.

Ho visto che questi articoli hanno prezzi molto diversi e a volte sono molto più costosi.

Quindi, devi anche capire dove ti trovi in termini di costi.

Potremmo abbassare i prezzi, ma stiamo cercando di mantenere il nostro livello di qualità il più alto possibile.

Quindi, facendo un po' di calcoli, questo significa che per un tempo di gioco di 2 ore, il costo del nostro stack vocale è di circa 2,40 $per utente.

E così, dato che addebitiamo 10 $e lo store applica una commissione, guadagniamo circa 4, 59 $per utente, giusto?

Quindi, l'aspetto economico funziona, giusto?

La voce è il nostro gancio, è su questo che vogliamo spendere soldi, funziona.

Quindi, questo è un gioco davvero piccolo.

Parliamo di qualcosa di un po' più grande.

Parliamo di un gioco ipotetico, un gioco narrativo, che dura tra le 5 e le 9 ore, diciamo in media 7 ore.

In realtà, la maggior parte delle persone, molte persone non finiscono i giochi, giocano un po' e poi li abbandonano, ma voglio scegliere un valore un po' più alto per assicurarmi che l'economia funzioni ancora.

Quindi, manterremo la tariffa di 1,20 $l'ora, ma la modifica che apporteremo è che la componente vocale verrà utilizzata il 60% delle volte, perché un gioco più grande avrà molte più meccaniche oltre alla voce.

Quindi, sarà comunque un gioco molto basato sulla voce, ma avrà altri tipi di funzionalità al suo interno.

Quindi, se addebitiamo 20 $, rifacendo i calcoli, ci costerebbe circa 5 $per utente, il che significa che alla fine della giornata guadagniamo circa 9 $per utente.

Quindi, ancora una volta, con questo, l'economia funziona.

Questo non significa che l'economia funzionerà per tutto.

Ad esempio, una cosa da non fare è dire: "Voglio creare un gioco free-to-play e probabilmente gli utenti ci giocheranno da 1 ora a oltre 100 ore".

Quindi, facciamo una media di 10 ore.

È un gioco interamente vocale, ma supponiamo che sia un successo e che generi circa 3 $per utente, il che sarebbe fantastico per un gioco free-to-play.

Perderesti 10 $per utente.

Quindi, non funziona ancora per tutte queste cose e devi pensare a cosa stai creando al momento e se ha senso.

Non aspettare la fine per cercare di capire gli aspetti economici.

Devin Reimer

La domanda successiva è: "E i modelli locali?"

Se il costo è un problema così grande, i modelli locali non lo eliminerebbero?

Sì, lo sarebbe.

Tuttavia, dobbiamo considerare alcuni compromessi.

Quindi, per quanto riguarda i costi, sì, elimineremmo la fattura del server, il che sarebbe un enorme vantaggio e aprirebbe molte più opportunità.

Ma ci sono molte cose che al momento il cloud può risolvere e che invece sono difficili da gestire in locale.

Ad esempio, compute.

Spesso le persone dicono: "Guarda, ho trovato questo modello di conversione della voce in testo davvero valido e viene eseguito localmente su questo dispositivo, giusto?"

Ottimo, ma dobbiamo pensare che non sta eseguendo un solo modello, ma più modelli, giusto?

Nel nostro caso, quattro, potenzialmente contemporaneamente, quindi non è sufficiente che un'operazione venga eseguita una volta, ma deve essere eseguita più volte contemporaneamente.

E poi, se ci riesci, hai lasciato qualcosa per l'esecuzione del tuo gioco o della tua applicazione?

Se hai esaurito la GPU, non riuscirai a eseguire il rendering di un videogioco.

Supponiamo che tu abbia superato queste sfide.

Il prossimo è la velocità, giusto?

Spesso è possibile eseguirli, ma saranno molto lenti e l'esperienza sarà più simile a un prompt che a una vera e propria conversazione in tempo reale.

Quindi, in teoria, l'esecuzione locale offre un vantaggio futuro, perché non è necessario eseguire l'andata e ritorno da internet.

Al momento è difficile ottenere modelli che funzionino alla velocità giusta per far funzionare questa funzionalità.

Quindi, supponiamo che tu abbia conquistato il computing e la velocità, ora dobbiamo pensare alla qualità, giusto?

In genere, poiché l'esecuzione avviene su un dispositivo locale, utilizzi un LLM più piccolo, ad esempio una sintesi vocale più primitiva, il che può rappresentare alcune sfide in termini di contenuti che stai creando.

Come ho già detto, quando pensi all'LLM, non devi solo chiederti se è abbastanza buono per i tuoi utenti, ma anche se è abbastanza buono per lo sviluppo.

Quindi, se quel modello diventa piuttosto difficile da usare per creare qualcosa, è sicuramente un aspetto da considerare.

Quindi, supponiamo che tu abbia conquistato il computing, la velocità e la qualità, il prossimo passo è la portabilità.

Se hai vinto e hai seguito l'intero processo, e hai ottenuto questo risultato su, ad esempio, una RTX 5070, potrebbe essere l'unico posto in cui può essere eseguito.

Quindi, se si presenta l'opportunità di portarlo su una nuova piattaforma, potresti trovarti in difficoltà.

Per quanto riguarda il cloud, tutto ciò che serve è internet.

Quindi, questo è un grande passo avanti.

Consente di trasmettere su più piattaforme.

Ora parliamo di un approccio ibrido, giusto?

Quindi, eseguiamo alcune operazioni nel cloud e altre localmente.

In un certo senso, potrebbe funzionare?

Beh, non è una vittoria così grande come pensi.

Quindi, se ottieni un modello abbastanza piccolo da essere eseguito sulla maggior parte delle piattaforme locali, se lo esegui nel cloud, probabilmente ti costerà pochissimo.

Quindi, in genere, è solo quando hai risolto l'intero stack che ottieni i risultati migliori.

Poi, la domanda successiva è: cosa succede se invece lo esegui localmente, se è possibile?

Dispongono dell'hardware giusto e, se non lo hai, nel cloud, giusto?

Potresti eseguire un'operazione più potente nel cloud.

Questo comporta nuove sfide, giusto?

Se finisci per eseguire un modello diverso, questo potrebbe influire notevolmente sullo sviluppo.

Inoltre, finisci per dover dedicare molto tempo a lavorare sulle specifiche minime.

E potresti avere modelli che si comportano in modo molto diverso.

Quindi, a meno che non utilizzi esattamente gli stessi modelli, potresti finire per aggiungere molto tempo e costi di sviluppo.

Quindi, è importante pensare a cosa stai cercando di ottenere, perché supponiamo che tu abbia capito questo e abbia ottenuto un buon locale se necessario, cloud se non lo è, l'economia deve comunque funzionare per il modello cloud.

Perché se, all'improvviso, tutti i tuoi utenti sono sul lato cloud, perderai se non ci hai pensato, da un punto di vista economico.

Quindi, per quanto riguarda i modelli locali, si tratta sicuramente di un grande vantaggio economico, ma è ancora presto.

Per le applicazioni sensibili ai prezzi come i giochi, credo che alla fine probabilmente vincerà.

Oggi è un po' complicato al di fuori di casi d'uso più specifici, in particolare per quanto riguarda le cose basate sui comandi.

Quindi, oggi, vogliamo offrire la migliore esperienza possibile.

Ecco perché utilizziamo il cloud.

Tuttavia, questo è un settore in rapida evoluzione e le cose stanno cambiando molto velocemente.

Quindi, la parte successiva è pensare ai modelli che stiamo utilizzando, giusto?

La domanda successiva riguarda i pesi aperti rispetto ai pesi chiusi.

Cosa dovremmo fare qui?

Voglio concentrarmi sugli LLM quando ne parliamo, perché abbiamo scoperto che questa è l'area più interessata dalla questione open source rispetto a closed source.

Quindi, ci sono sicuramente dei pro e dei contro.

Quindi, quando si tratta di modelli chiusi e ponderati, si tratta generalmente di intelligence di frontiera, giusto?

Quindi, se hai bisogno di più intelligence, spesso è qui che devi andare.

Nel frattempo, sul lato aperto, sono spesso una generazione indietro.

Quindi, questo può essere un vero e proprio compromesso.

Per quanto riguarda la velocità, ho accennato al fatto che mi interessa molto il tempo necessario per la prima frase.

Abbiamo scoperto che nel corso del ciclo di vita dei modelli chiusi, la velocità spesso diminuisce.

I motivi possono essere molti.

Forse più persone utilizzano il modello, forse l'hardware è passato a un modello più recente.

Ma è un aspetto che abbiamo notato.

Quindi, devi fare attenzione perché può causare un problema per cui se spedisci qualcosa ed è fantastico, potrebbe, nel tempo, diventare inutilizzabile.

Poi abbiamo i picchi.

Questo tipo di coerenza è molto importante e, spesso, i modelli chiusi sono costruiti attorno al raggruppamento in batch di attività asincrone, non a latenze di tipo P99, mentre, sul lato aperto, puoi scegliere un provider che si preoccupi di quella cosa molto specifica che ti interessa, per darti il tipo di fiducia, velocità e latenza di cui hai bisogno.

Il secondo è la durata del modello stesso.

Quindi, i modelli chiusi vengono spesso ritirati dopo circa un anno.

Ciò significa che se sviluppi un modello per un anno e prevedi che rimanga in produzione per 3 anni, potresti dover apportare più di 3 modifiche al modello.

Inoltre, il fatto che un modello sia migliore non significa che funzionerà meglio per te.

Abbiamo apportato molte modifiche ai modelli negli ultimi 3 anni e spesso sono necessarie settimane, a volte mesi di lavoro per riorganizzare tutto, mentre, sul lato open, puoi continuare a eseguire quel modello finché qualcuno è disposto a ospitarlo o sei disposto a ospitarlo tu stesso.

Infine, il costo.

Spesso, con il passare del tempo, questi modelli chiusi, man mano che vengono rilasciate nuove versioni, sono più costosi di quelli precedenti.

Quindi, questo è un altro aspetto a cui prestare attenzione quando si parla di economia: ancora una volta, la tua economia potrebbe aver funzionato al momento del lancio e poi non funzionare più quando finisci per migrare i modelli.

Per quanto riguarda l'open source, hai la flessibilità di poterlo spostare e probabilmente non aumenterà drasticamente perché è esattamente lo stesso modello.

Quindi, utilizziamo Gemma 4 31B, che è stata una grande scoperta per noi perché rappresenta la migliore combinazione di velocità, intelligenza e costi.

Ci ha anche permesso di muoverci molto velocemente.

È molto più facile da sviluppare rispetto ad altri strumenti che abbiamo utilizzato in precedenza.

Ciò non significa che utilizziamo solo questo.

Utilizziamo molte combinazioni di diversi modelli aperti e chiusi.

Ad esempio, aspetti come la generazione della memoria, la sicurezza e la personalizzazione.

È solo molto importante scegliere il modello migliore per le tue esigenze specifiche in quell'attività.

Ma Gemma 4 31B è il nostro cavallo di battaglia quando si tratta di agenti vocali.

Quindi, per quanto riguarda questo tipo di differenze tra i due, i modelli aperti offrono sicuramente un maggiore controllo e ti consentono di conservare i modelli finché possono essere ospitati a un costo più prevedibile.

Inoltre, la dismissione di un modello non influisce sulla tua pianificazione.

Devin Reimer

Quindi, per riassumere, si tratta di trovare un equilibrio tra questi tre aspetti, giusto?

Per quanto riguarda la latenza, stiamo cercando di bilanciare l'aspetto dello streaming, l'aspetto parallelo, la velocità e la coerenza.

Per quanto riguarda l'intelligence, è abbastanza smart per gli utenti e per lo sviluppo.

Per quanto riguarda i costi, dobbiamo sapere quanto costerà per utente e quanto possiamo guadagnare per utente, in modo da assicurarci che l'aspetto economico funzioni.

Non creare prima il gioco per poi capire come monetizzarlo.

Pensaci fin dall'inizio.

Quindi, è ancora molto presto, ma l'economia qui sta iniziando a funzionare.

Quindi, i modelli più economici saranno sicuramente migliori, così come quelli più intelligenti.

Ma oggi, in questo momento, possiamo iniziare a lavorare sulle sfide davvero difficili che dobbiamo affrontare per rendere gli agenti vocali una realtà ovunque.

Per questo, sono davvero entusiasta di mettere la potenza degli agenti vocali a disposizione di tutti.

Grazie.