Throughput riservato per i modelli Gemini Omni

Questa sezione spiega come funziona il throughput riservato per i modelli Gemini Omni, incluso il comportamento di applicazione delle quote e gli incrementi di acquisto minimi delle unità di scalabilità dell'AI generativa (GSU).

Per i modelli Gemini Omni, le finestre di applicazione delle quote variano in base al numero di GSU acquistate per il modello e sono soggette a modifiche. Le sezioni seguenti elencano le finestre di applicazione delle quote per le diverse dimensioni di GSU.

Anteprima di Gemini Omni Flash: finestre di applicazione delle quote

Di seguito sono riportate le finestre di applicazione delle quote per le diverse dimensioni di GSU per l'anteprima di Gemini Omni Flash:

  • 1-9 GSU: 2000 secondi
  • 10-19 GSU: 200 secondi
  • 20-39 GSU: 100 secondi
  • 40-66 GSU: 50 secondi
  • Più di 67 GSU: 30 secondi

I valori elencati sono indipendenti dalla latenza della richiesta. Il tempo di elaborazione della richiesta non è lo stesso della finestra di applicazione della quota.

Le finestre di applicazione sono più grandi per importi GSU inferiori per garantire che le richieste più piccole vengano elaborate correttamente all'interno della 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 su Omni Flash più spesso utilizzando Throughput riservato, ti consigliamo di aumentare il numero di GSU acquistate e controllare la finestra di applicazione corrispondente.

Ad esempio, considera una situazione in cui hai acquistato 1 GSU di Omni Flash Preview per un workload che richiede la generazione di un singolo video a 1080p di 10 secondi. In questo caso, di solito puoi generare questo video entro 60 secondi e il traffico viene elaborato come Throughput riservato. Tuttavia, se vuoi generare un altro video della stessa durata, devi attendere la fine della finestra di applicazione della quota (2000 secondi per 1 GSU). L'ora di questa finestra di applicazione è determinata dall'ora dell'orologio di Gemini Enterprise Agent Platform e non dal momento in cui viene effettuata la richiesta. Le finestre di applicazione dipendono dagli algoritmi di backend e sono soggette a modifiche.

Ti consigliamo di impostare i parametri API di durata e risoluzione quando effettui una richiesta. Se fornito, il throughput riservato può offrire un'esperienza più accurata. Se questi parametri non vengono forniti, la stima delle dimensioni della richiesta di Throughput riservato presuppone la durata e la risoluzione massime, il che potrebbe portare a un rollover prematuro ed evitabile al modello pagamento a consumo e ridurre l'utilizzo del Throughput riservato acquistato.

Stima dei requisiti GSU

Ti consigliamo di utilizzare lo strumento di stima nella pagina Throughput riservato per stimare il numero di GSU richieste per il tuo carico di lavoro. Lo strumento richiede l'input dei token di input totali e la stima dei token di output per una finestra di frequenza specifica. Per ulteriori informazioni sull'utilizzo dello strumento di stima, consulta Effettuare un ordine di throughput riservato standard.

Per stimare il numero di token, utilizza i seguenti metodi:

  • Token di testo di input: utilizza il tokenizzatore SDK o l'API countTokens.
  • Token di input di altre modalità: utilizza le stime basate sui presupposti nella pagina dei prezzi.
  • Carichi di lavoro esistenti: somma l'utilizzo dei token dalle risposte generate in un intervallo di tempo specifico.

Ad esempio, considera un carico di lavoro che genera cinque video a 720p di 10 secondi e cinque video a 1080p di 10 secondi ogni 30 secondi (10 richieste in totale). Supponiamo che ogni richiesta abbia 20 token di testo di input, un'immagine (1120 token) e 100 token di pensiero di risposta. Gli input per lo strumento di stima GSU sono i seguenti:

  • Frequenza: 30 secondi
  • Token di testo di input totali: 20 × 10 (richieste) = 200
  • Token di immagine totali: 1120 × 10 (richieste) = 11.200
  • Token di ragionamento di output totali: 100 × 10 (richieste) = 1000
  • Token di video di output totali: 10 s (durata) × 5792 (token/s) × 5 video (720p) + 10 s (durata) × 8688 (token/s) × 5 video (1080p) = 724.000
  • GSU stimate: 434

Scenari di alta risoluzione e durata

Una singola richiesta di grandi dimensioni non può essere suddivisa in due finestre di applicazione. Se una richiesta richiede più di quanto può contenere la finestra di applicazione, viene erogata con pagamento a consumo ogni volta, indipendentemente dalla frequenza con cui la invii e dalla quantità di quota di Throughput riservato inutilizzata che potrebbe essere presente nelle finestre successive.

Questo avviso riguarda solo i video in 4K di durata pari o superiore a 7 secondi. A 360p, 720p e 1080p, ogni durata supportata rientra in una finestra di qualsiasi dimensione di acquisto, così come i video in 4K di 6 secondi o meno (supponendo che i token di input e di ragionamento tipici siano inferiori a 88.000 token).

Se generi video in 4K di durata pari o superiore a 7 secondi, confronta il risultato dello strumento di stima con la tabella seguente e ordina il numero più grande:

Video 4K più lungo 1-9 GSU 10-19 GSU 20-39 GSU 40-66 GSU Più di 67 GSU
7 secondi 2 12 23 46 76
8 secondi 2 13 26 52 87
9 secondi 2 15 29 58 97
10 secondi 2 17 33 65 107

Leggi la colonna corrispondente al numero stimato di GSU. Ad esempio, supponi di generare sei video in 4K da 10 secondi ogni 2000 secondi. Lo strumento di stima restituisce 10 GSU, sufficienti per la velocità effettiva media. Tuttavia, con 10 GSU, la finestra di applicazione è di 200 secondi e nessuno dei tuoi video di 10 secondi rientra in una singola finestra. Spaziare ulteriormente le sei richieste non risolve questo problema. Per elaborare correttamente le richieste senza spillover con pagamento a consumo, ordina 17 GSU.

Queste cifre si basano su token di prompt e ragionamento tipici: un prompt di testo o immagine oppure un video di massimo 10 secondi da modificare.

Passaggi successivi