In questa sezione viene spiegato come funziona il Throughput riservato 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 le 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ò richiamare le informazioni fornite o discusse in precedenza. Il Throughput riservato supporta il modello Gemini 2.5 Flash con l'API Gemini Live. Per saperne di più sull'API Gemini Live, inclusi i limiti e le funzionalità delle sessioni, consulta la documentazione di riferimento dell'API Gemini Live.
L'API Gemini Live richiede che una sessione sia dedicata interamente al traffico di Throughput riservato o di pagamento a consumo. Non supporta il traffico di overflow tra il Throughput riservato e il pagamento a consumo 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 riservato durante una sessione attiva, non si verificheranno limitazioni o errori. Il sistema consente invece al traffico di aumentare temporaneamente per consentire alla sessione di continuare, con tutto l'utilizzo successivo registrato rispetto alla quota complessiva. Questo aumento temporaneo può far sì che le dashboard di monitoraggio mostrino l'utilizzo del Throughput riservato (traffico dedicato) al di sopra del limite. Per evitare di superare i limiti allocati a metà sessione, è importante acquistare GSU sufficienti per supportare l'utilizzo previsto.
L'overflow è supportato da una sessione all'altra. Se superi il limite di Throughput riservato al termine di una sessione, puoi avviare una sessione aggiuntiva utilizzando il pagamento a consumo. Se una sessione viene elaborata interamente come Throughput riservato o pagamento a consumo, viene deciso all'inizio della sessione. Il sistema controlla l'intestazione inviata dall'utente e verifica se è presente una quota di Throughput riservato sufficiente per la sessione. Se la quota di Throughput riservato disponibile non è sufficiente per elaborare l'intera sessione, viene utilizzata la quota di pagamento a consumo.
Calcolare il throughput per l'API Gemini Live
Quando utilizzi l'API Gemini Live, i token archiviati nella memoria di sessione possono essere utilizzati nelle richieste successive al modello. Di conseguenza, il Throughput riservato tiene conto sia dei token in entrata sia dei token della memoria di sessione nella stessa richiesta. Di conseguenza, il numero di token elaborati per richiesta potrebbe essere maggiore dei token inviati dall'utente nella richiesta in corso.
L'API Gemini Live ha un limite per il numero totale di token che possono essere archiviati nella memoria di 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 di 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 Throughput riservato per l'API Gemini Live
Durante una sessione, tutto il traffico viene elaborato come Throughput riservato o pagamento a consumo.
Lo stato della sessione, inclusa la memoria di sessione, è disponibile finché la sessione è attiva.
Questo esempio illustra come vengono elaborate due richieste consecutive includendo i token della memoria di 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 della memoria di sessione dalla 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 di 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 di sessione, costituiti dai token di input della richiesta precedente (richiesta n. 1) dalla memoria di sessione. Il tasso di riduzione dei token nella memoria di sessione è lo stesso dei token di input standard (1 token di memoria di 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 riservato come segue:
Moltiplica gli input per i tassi di riduzione 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 riduzione per ottenere i token di output totali:
200 x (24 token per token di uscita audio) = 4800 token
Somma questi due totali per ottenere il numero totale di token elaborati:
3830 token + 4800 token = 8630 token