Questa sezione spiega come funziona il throughput di cui è stato eseguito il provisioning con l'API Gemini Live per il conteggio dei token e l'applicazione delle quote.
L'API Gemini Live supporta interazioni multimodali a bassa latenza tramite sessioni. Utilizza una memoria di sessione per conservare e richiamare le informazioni dalle interazioni all'interno di una sessione. In questo modo, il modello può ricordare le informazioni fornite o discusse in precedenza. Il Throughput riservato supporta il modello Gemini 2.5 Flash con l'API Gemini Live. Per ulteriori informazioni sull'API Gemini Live, inclusi limiti di sessione e funzionalità, consulta i riferimenti dell'API Gemini Live.
L'API Gemini Live richiede che una sessione sia dedicata interamente al throughput riservato o al traffico PayGo. Non supporta il traffico di overflow tra la velocità effettiva di cui è stato eseguito il provisioning e PayGo all'interno della stessa sessione. Il tipo di traffico impostato all'inizio di una sessione continua per tutta la sua durata. Se raggiungi la quota di throughput di cui è stato eseguito il provisioning durante una sessione attiva, non si verificheranno limitazioni o errori. Il sistema consente invece al traffico di aumentare temporaneamente per consentire il proseguimento della sessione, con tutto l'utilizzo successivo registrato in base alla quota complessiva. Questo picco temporaneo può causare la visualizzazione dell'utilizzo del throughput di cui è stato eseguito il provisioning (traffico dedicato) al di sopra del limite nelle dashboard di monitoraggio. Per evitare di superare i limiti allocati a metà sessione, è importante acquistare GSU sufficienti a supportare l'utilizzo previsto.
Il rollover è supportato da una sessione all'altra. Se superi il limite di Provisioned Throughput al termine di una sessione, puoi avviarne un'altra utilizzando PayGo. Se una sessione viene elaborata interamente come Provisioned Throughput o PayGo viene deciso all'inizio della sessione. Il sistema controlla l'intestazione inviata dall'utente e verifica se è disponibile una quota di throughput di provisioning sufficiente per la sessione. Se la quota di throughput di cui è stato eseguito il provisioning disponibile non è sufficiente per elaborare l'intera sessione, viene utilizzata la quota Pay as you go.
Calcola il throughput per l'API Gemini Live
Quando utilizzi l'API Gemini Live, i token memorizzati nella memoria della sessione possono essere utilizzati nelle richieste successive al modello. Di conseguenza, il throughput di cui è stato eseguito il provisioning tiene conto dei token in entrata e dei token di memoria di sessione nella stessa richiesta. Ciò potrebbe comportare un numero di token elaborati per richiesta superiore a quello dei token inviati dall'utente nella richiesta in corso.
L'API Gemini Live ha un limite al numero totale di token che possono essere archiviati nella memoria della sessione e ha anche un campo di metadati contenente il numero totale di token. Quando calcoli la quantità di throughput necessaria per gestire le richieste, devi tenere conto dei token nella memoria della sessione. Se hai utilizzato l'API Gemini Live con il pagamento a consumo, puoi utilizzare questi pattern di traffico e token di sessione per stimare le tue esigenze di throughput riservato.
Esempio di come stimare i requisiti di velocità effettiva di provisioning per l'API Gemini Live
Durante una sessione, tutto il traffico viene elaborato come throughput di cui è stato eseguito il provisioning o con pagamento a consumo.
Lo stato della sessione, inclusa la memoria della sessione, sono disponibili finché la sessione è attiva.
Questo esempio illustra come vengono elaborate due richieste consecutive includendo i token della memoria della sessione.
Dettagli della richiesta n. 1
Durata: 10 secondi
Token inviati (audio): 10 secondi x 25 token/secondo = 250 token
Token inviati (video): 10 secondi x 258 token/frame al secondo = 2580 token
Token totali elaborati per la richiesta n. 1:
- Token inviati: somma dei token audio e video inviati = 2580 + 250 = 2830 token
- Token ricevuti: 100 (audio)
Dettagli della richiesta n. 2
Durata: 40 secondi
Token inviati (audio): 40 secondi x 25 token/secondo = 1000 token
Token totali elaborati per la richiesta n. 2:
- Token inviati: token inviati nella richiesta n. 2 + token di memoria di sessione della richiesta n. 1 = 2830 token + 1000 token = 3830 token
- Token ricevuti: 200 (audio)
Calcolare il numero di token elaborati nelle richieste
Il numero di token elaborati durante queste richieste viene calcolato come segue:
La richiesta n. 1 elabora solo i token di input e output della richiesta in corso, poiché non sono presenti token aggiuntivi nella memoria della sessione.
La richiesta n. 2 elabora i token di input e output della richiesta in corso, ma include anche i token di input della memoria della sessione, costituiti dai token di input della richiesta precedente (richiesta n. 1) della memoria della sessione. Il tasso di esaurimento dei token nella memoria della sessione è lo stesso dei token di input standard (1 token di memoria della sessione di input = 1 token di input).
Se l'elaborazione della richiesta n. 2 ha richiesto esattamente 1 secondo dopo l'invio, i token vengono elaborati e applicati alla quota di throughput di cui è stato eseguito il provisioning come segue:
Moltiplica gli input per i tassi di consumo per ottenere i token di input totali:
2830 x (1 token per token di memoria di sessione) + 1000 x (1 token per token di testo di input) = 3830 token di input con riduzione per query
Moltiplica gli output per i tassi di consumo per ottenere i token di output totali:
200 x (24 token per token di output audio) = 4800 token
Somma questi due totali per ottenere il numero totale di token elaborati:
3830 token + 4800 token = 8630 token