Questa sezione spiega come funziona il throughput riservato con l'API Gemini Live per il conteggio dei token e l'applicazione delle quote.
L'API Gemini Live consente interazioni multimodali a bassa latenza utilizzando la memoria della sessione per mantenere il contesto tra i turni. Per ulteriori funzionalità e limiti di sessione, consulta il riferimento API Gemini Live.
Ogni sessione deve essere dedicata interamente al Throughput riservato o a PayGo; il passaggio da un modello all'altro durante la sessione non è supportato. Se superi la quota di throughput riservato durante una sessione attiva, il sistema consente un bursting temporaneo per evitare errori, registrando l'eccedenza rispetto alla quota complessiva. Per evitare picchi di utilizzo imprevisti, acquista un numero sufficiente di GSU per supportare la domanda di picco.
Lo spillover è supportato tra le sessioni. All'avvio di una sessione, il sistema valuta l'intestazione della richiesta e verifica la disponibilità della quota di throughput riservato. Se la quota non è sufficiente, la nuova sessione viene impostata su PayGo per impostazione predefinita.
Poiché la memoria di sessione trasferisce gli output dei turni precedenti come input per le richieste successive, il throughput riservato calcola la quota in base sia ai nuovi token in entrata sia ai token di sessione accumulati. Di conseguenza, il totale dei token elaborati per richiesta aumenterà man mano che la sessione procede, fino a raggiungere il limite di sessione predefinito. Lo stato della sessione, inclusa la memoria della sessione, è disponibile finché la sessione è attiva.
Assicurati di tenere conto dei token di memoria della sessione quando stimi il throughput riservato richiesto. Tieni presente che i token degli avatar dei video di output non sono inclusi nella memoria della sessione. I pattern di traffico PayGo storici possono fungere da base utile per calcolare le tue esigenze di GSU.
Le finestre di applicazione delle quote variano in base al numero di GSU acquistate per il modello e sono soggette a modifiche.
API Gemini 3.8 Live
Finestre di applicazione delle quote
Di seguito sono riportate le finestre di applicazione delle quote per diverse dimensioni di GSU per il modello API Gemini 3.8 Live:
- 1-9 GSU: 45 secondi
- Oltre 10 GSU: 5 secondi
I valori elencati sono indipendenti dalla latenza della richiesta. Il tempo necessario per elaborare la tua richiesta non corrisponde alla finestra di applicazione della quota. Tieni presente che è necessario acquistare un minimo di 10 GSU per consentire al throughput riservato di elaborare le richieste relative agli avatar video di questo modello. Se vengono acquistate meno di 10 GSU, l'intera sessione basata su avatar video verrà trasferita a PayGo.
Le finestre di applicazione sono più ampie per quantità di GSU inferiori, per garantire che le richieste più piccole vengano elaborate correttamente entro la finestra. Man mano che il numero di GSU per un modello aumenta, non sono necessari tempi di finestra più lunghi per elaborare una richiesta. Se devi elaborare gli output più di frequente utilizzando il throughput riservato, ti consigliamo di aumentare la quantità di GSU acquistate e di controllare la finestra di applicazione corrispondente. Le finestre di applicazione dipendono dagli algoritmi di backend e sono soggette a modifiche.
Stima dei requisiti GSU
Esaminiamo un esempio di potenziale workload e cerchiamo di capire in che modo lo strumento di stima fornisce un suggerimento per questo modello, che indica anche come vengono elaborate le richieste e come vengono applicate le tariffe di burndown. Un utente prevede di utilizzare l'API Gemini Live per un chatbot in cui sono previste 10 sessioni simultanee e la durata è di 5 minuti (300 secondi). Si prevedono 30 turni di conversazione per sessione e l'utente specifica una finestra contestuale massima della sessione di 6000 token di attivazione. La forma delle richieste è riportata di seguito:
| Campo | Valore di esempio |
|---|---|
| Numero previsto di sessioni simultanee | 10 |
| Durata prevista (secondi) | 300 |
| Numero medio di turni per sessione | 30 |
| Lunghezza massima della finestra contestuale (token di attivazione) | 6000 |
| Media di token di testo di input per turno | 20 |
| Media di token audio di input per turno | 200 |
| Media di token di immagine/video di input per turno | 50 |
| Media di token di testo di output per turno | 100 |
| Media di token audio di output per turno | 200 |
| L'avatar video di output è abilitato? | Sì |
Token di input per turno:
Calcola la somma dei prodotti delle modalità di input e dei rispettivi tassi di consumo:
Media di token di testo di input per turno * Tasso di consumo del testo di input = 20 * 1 = 20
Media di token audio di input per turno * Frequenza di burndown dell'audio di input = 200 * 4 = 800
Media di token di immagine/video di input per turno * Tasso di consumo delle immagini di input = 50 * 1,4 = 70
Token di input totali per turno con burn down applicato = 20 + 800 + 70 = 890
Token di output per turno:
Calcola la somma dei prodotti delle modalità di output e dei rispettivi tassi di consumo. Tieni presente che i token avatar video di output rappresentano un numero fisso di 6192 token per 25 token audio:
Media di token di testo di output per turno * Tasso di burndown del testo di output = 100 * 6 = 600
Media di token audio per turno * Tasso di burndown dell'audio di output = 200 * 16 = 3200
L'avatar video di output è abilitato? Sì, quindi moltiplica l'output dei token audio per (6192/25) e applica il tasso di consumo dei token dell'avatar video di output: 200 * (6192/25) * 1,4 = 69.350
Token di output totali per turno con burn down: 600 + 3200 + 69.350 = 73.150
Token della finestra contestuale per turno:
La finestra contestuale accumula i token di input e output non elaborati (esclusi i token di output degli avatar video) in ogni turno fino a raggiungere la lunghezza massima della finestra contestuale e smette di aumentare. I token vengono conteggiati ai fini del limite della finestra di contesto come token non elaborati (senza applicare i tassi di consumo). Tuttavia, quando la finestra di contesto viene inserita nelle richieste di input del turno successivo come memoria della sessione, i token nella finestra di contesto devono applicare le tariffe di burndown di input corrispondenti in base alla loro modalità.
Somma i token non elaborati totali di ogni sessione senza tenere conto dei tassi di consumo.
- Media di token di testo di input per turno + media di token audio di input per turno + media di token di immagine/video di input per turno + media di token di testo di output per turno + media di token audio di output per turno = 20 + 200 + 50 + 100 + 200 = 570
Poi calcola il rapporto tra il conteggio di ogni token non elaborato e il totale. Possiamo ignorare i token di output dell'avatar video nel calcolo della finestra di contesto.
- Rapporto del testo di input = 20/570 = 0,035
- Rapporto audio di input = 200/570 = 0,351
- Rapporto immagini/video di input = 50/570 = 0,088
- Rapporto del testo di output = 100/570 = 0,175
- Rapporto audio di output = 200/570 = 0,351
Poi calcola la somma dei prodotti dei rapporti, della finestra contestuale massima e dei tassi di consumo come se fossero tutte modalità di input.
Rapporto del testo di input * lunghezza massima della finestra contestuale * burndown del testo di input = 0,035 * 6000 * 1 = 210
Rapporto audio di input * lunghezza massima della finestra contestuale * burndown audio di input = 0,351 * 6000 * 4 = 8424
Rapporto immagine/video di input * finestra contestuale massima * burndown immagine/video di input = 0,088 * 6000 * 1,4 = 739
Rapporto testo di output * lunghezza massima della finestra contestuale * burndown del testo di input = 0,175 * 6000 * 1 = 1050
Rapporto audio di output * lunghezza massima della finestra contestuale * burndown audio di input = 0,351 * 6000 * 4 = 8424
Al limite massimo della finestra contestuale di 6000 token non elaborati, il totale dei token della finestra contestuale elaborati per turno, con l'applicazione del tasso di consumo, è 210 + 8424 + 739 + 1050 + 8424 = 18.847.
Calcolo delle GSU:
(token di input per turno + token di output per turno + token della finestra di contesto per turno) * numero medio di turni per sessione * numero previsto di sessioni simultanee * (1/durata prevista) * (1 GSU/1350 TPS) = (890 + 73.150 + 18.847) * 30 * 10 * (1/300) * (1/1350) = 68,8, arrotondato per eccesso dà 69 GSU.
Elaborazione della richiesta
Vediamo un esempio di come vengono elaborate le richieste in relazione al throughput riservato per questo modello. Supponiamo che ci siano 3 richieste.
Dettagli della richiesta n. 1: audio e video di input, audio di output
- 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 audio di output ricevuti in base alla natura della richiesta: 100 token
- Memoria di sessione aggiornata = 250 + 2580 + 100 = 2930 token
Dettagli della richiesta n. 2: audio di input con memoria della sessione, audio di output
- Durata: 40 secondi
- Token inviati (audio): 40 secondi x 25 token/secondo = 1000 token
- Memoria di sessione dopo la Richiesta n. 1 = 2930 token
- Token di input totali inviati: token inviati in questa richiesta + memoria di sessione della Richiesta 1 = 1000 + 2930 = 3930 token
- Token audio di output ricevuti in base alla natura della richiesta: 200 token
- Memoria di sessione aggiornata = 3930 + 200 = 4130 token
Dettagli della richiesta n. 3: input audio e video con memoria della sessione, output audio e video dell'avatar
- 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
- Memoria di sessione dopo la Richiesta n. 2 = 4130 token
- Token di input totali inviati: token inviati in questa richiesta + memoria di sessione della richiesta n. 2 = 250 + 2580 + 4130 = 6960 token
- Token di avatar video di output ricevuti in base alla natura della richiesta: 61.920 token
- Token audio di output ricevuti in base alla natura della richiesta: 250 token
- Memoria della sessione aggiornata = 6960 + 250 = 7210 token
Informazioni sui token elaborati
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. Tutti i token elaborati ora costituiscono la memoria della sessione.
La richiesta n. 2 elabora i token di input e output della richiesta in corso, includendo anche la memoria della sessione della richiesta n. 1. Tutti i token di memoria della sessione applicano la frequenza di consumo di un token di input corrispondente.
La richiesta n. 3 elabora i token di input e output della richiesta in corso, includendo anche la memoria della sessione della richiesta n. 2. Tutti i token di memoria della sessione applicano la frequenza di consumo di un token di input corrispondente.
Se l'elaborazione della Richiesta n. 3 ha richiesto esattamente 1 secondo dopo l'invio, i token con burn down applicati alla quota di Throughput riservato per questo modello sarebbero i seguenti:
Token audio di input * tasso di consumo dell'audio di input = 250 * 4 = 1000
Token video di input * tasso di burndown video di input = 2580 * 1,4 = 3612
Audio della memoria della sessione * tasso di consumo dell'audio di input = (250 + 100 + 1000 + 200) * 4 = 6200
Video di memoria di sessione * tasso di consumo del video di input = 2580 * 1,4 = 3612
Token di avatar video di output * tasso di consumo di avatar video di output = 61.920 * 1,4 = 86.688
Token audio di output * frequenza di burndown dell'audio di output = 250 * 16 = 4000
Sommando il totale,si ottengono 105.112 token con burn-down.
Audio nativo dell'API Gemini 2.5 Flash Live
Elaborazione della richiesta
Dettagli della richiesta n. 1: audio e video di input, audio di output
- 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 audio di output ricevuti in base alla natura della richiesta: 100 token
- Memoria di sessione aggiornata = 250 + 2580 + 100 = 2930 token
Dettagli della richiesta n. 2: audio di input con memoria della sessione, audio di output
Durata: 40 secondi
Token inviati (audio): 40 secondi x 25 token/secondo = 1000 token
Memoria di sessione dopo la Richiesta n. 1 = 2930 token
Token di input totali inviati: token inviati in questa richiesta + memoria di sessione della Richiesta n. 1 = 1000 + 2930 = 3930 token
Token audio di output ricevuti in base alla natura della richiesta: 200 token
Memoria di sessione aggiornata = 3930 + 200 = 4130 token
Informazioni sui token elaborati
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. Tutti i token elaborati ora costituiscono la memoria della sessione.
La richiesta n. 2 elabora i token di input e output della richiesta in corso, includendo anche la memoria della sessione della richiesta n. 1. Tutti i token di memoria della sessione applicano la frequenza di consumo di un token di input corrispondente.
Se l'elaborazione della Richiesta n. 2 ha richiesto esattamente 1 secondo dopo l'invio, i token con burn down applicati alla quota di Throughput riservato per questo modello sarebbero i seguenti:
- Token audio di input * tasso di burndown dell'audio di input = 1000 * 6 = 6000
- Audio della memoria della sessione * tasso di consumo dell'audio di input = (250 + 100) * 6 = 2100
- Video della memoria di sessione * tasso di consumo del video di input = 2580 * 6 = 15.480
- Token audio di output * tasso di consumo dell'audio di output = 200 * 24 = 4800
Aggiungendo il totale,si ottengono 28.380 token con aggiustamento burndown.