In diesem Abschnitt wird beschrieben, wie Provisioned Throughput mit der Gemini Live API für die Tokenzählung und die Kontingenterzwingung funktioniert.
Die Gemini Live API unterstützt multimodale Interaktionen mit geringer Latenz über Sitzungen. Gemini verwendet einen Sitzungsspeicher, um Informationen aus Interaktionen innerhalb einer Sitzung zu speichern und abzurufen. So kann das Modell sich an zuvor bereitgestellte oder besprochene Informationen erinnern. „Bereitgestellter Durchsatz“ wird für das Modell „Gemini 2.5 Flash mit Gemini Live API“ unterstützt. Weitere Informationen zur Gemini Live API, einschließlich Sitzungslimits und Funktionen, finden Sie in der Gemini Live API-Referenz.
Für die Gemini Live API muss eine Sitzung entweder ausschließlich für Traffic mit bereitgestelltem Durchsatz oder für PayGo-Traffic verwendet werden. Überlauf-Traffic zwischen Provisioned Throughput und PayGo wird innerhalb derselben Sitzung nicht unterstützt. Der zu Beginn einer Sitzung festgelegte Traffictyp bleibt für die gesamte Dauer der Sitzung bestehen. Wenn Sie Ihr Kontingent für den bereitgestellten Durchsatz während einer aktiven Sitzung erreichen, kommt es nicht zu einer Drosselung oder zu Fehlern. Stattdessen lässt das System den Traffic für die Sitzung vorübergehend ansteigen, damit sie fortgesetzt werden kann. Die gesamte nachfolgende Nutzung wird auf Ihr Gesamtkontingent angerechnet. Dieser vorübergehende Anstieg kann dazu führen, dass in Ihren Monitoring-Dashboards die Nutzung des bereitgestellten Durchsatzes (dedizierter Traffic) über Ihrem Limit angezeigt wird. Damit Sie Ihre zugewiesenen Limits nicht während einer Sitzung überschreiten, ist es wichtig, dass Sie genügend GSUs kaufen, um Ihren erwarteten Verbrauch zu decken.
Spillover wird von einer Sitzung zur nächsten unterstützt. Wenn Sie das Limit für den bereitgestellten Durchsatz nach einer Sitzung überschreiten, können Sie eine zusätzliche Sitzung mit PayGo starten. Ob eine Sitzung vollständig als bereitgestellter Durchsatz oder Pay-as-you-go verarbeitet wird, wird zu Beginn der Sitzung entschieden. Das System prüft den vom Nutzer gesendeten Header und stellt dann fest, ob für die Sitzung ein ausreichendes Kontingent für den bereitgestellten Durchsatz vorhanden ist. Wenn das verfügbare Kontingent für den bereitgestellten Durchsatz nicht ausreicht, um die gesamte Sitzung zu verarbeiten, wird stattdessen das Pay-as-you-go-Kontingent verwendet.
Durchsatz für die Gemini Live API berechnen
Wenn Sie die Gemini Live API verwenden, können die im Sitzungsspeicher gespeicherten Tokens in nachfolgenden Anfragen an das Modell verwendet werden. Daher wird bei „Provisioned Throughput“ sowohl die Anzahl der eingehenden Tokens als auch die Anzahl der Tokens für den Sitzungsspeicher in derselben Anfrage berücksichtigt. Dies kann dazu führen, dass die Anzahl der Tokens, die pro Anfrage verarbeitet werden, größer ist als die Anzahl der Tokens, die vom Nutzer in der laufenden Anfrage gesendet werden.
Die Gemini Live API hat ein Limit für die Gesamtzahl der Tokens, die im Sitzungsspeicher gespeichert werden können. Außerdem gibt es ein Metadatenfeld, das die Gesamtzahl der Tokens enthält. Bei der Berechnung des Durchsatzes, der zum Bearbeiten Ihrer Anfragen erforderlich ist, müssen Sie die Tokens im Sitzungsspeicher berücksichtigen. Wenn Sie die Gemini Live API mit Pay-as-you-go (PayGo) verwendet haben, können Sie diese Traffic-Muster und Sitzungstokens verwenden, um den benötigten bereitgestellten Durchsatz zu schätzen.
Beispiel für die Schätzung Ihrer Anforderungen an Provisioned Throughput für die Gemini Live API
Während einer Sitzung wird der gesamte Traffic entweder als bereitgestellter Durchsatz oder als nutzungsabhängige Abrechnung verarbeitet.
Der Sitzungsstatus, einschließlich des Sitzungsspeichers, ist verfügbar, solange die Sitzung aktiv ist.
In diesem Beispiel wird veranschaulicht, wie zwei aufeinanderfolgende Anfragen verarbeitet werden, indem die Tokens aus dem Sitzungsspeicher einbezogen werden.
Details zu Anfrage 1
Dauer: 10 Sekunden
Gesendete Tokens (Audio): 10 Sekunden × 25 Tokens/Sekunde = 250 Tokens
Gesendete Tokens (Video): 10 Sekunden × 258 Tokens/Bild pro Sekunde = 2.580 Tokens
Insgesamt verarbeitete Tokens für Anfrage 1:
- Gesendete Tokens: Summe der gesendeten Audio- und Video-Tokens = 2.580 + 250 = 2.830 Tokens
- Erhaltene Tokens: 100 (Audio)
Details zu Anfrage 2
Dauer: 40 Sekunden
Gesendete Tokens (Audio): 40 Sekunden × 25 Tokens/Sekunde = 1.000 Tokens
Insgesamt verarbeitete Tokens für Anfrage 2:
- Gesendete Tokens: Tokens, die in Anfrage 2 gesendet wurden + Tokens für den Sitzungsarbeitsspeicher aus Anfrage 1 = 2.830 Tokens + 1.000 Tokens = 3.830 Tokens
- Erhaltene Tokens: 200 (Audio)
Anzahl der in den Anfragen verarbeiteten Tokens berechnen
Die Anzahl der Tokens, die während dieser Anfragen verarbeitet werden, wird so berechnet:
Bei Anfrage 1 werden nur die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet, da sich keine zusätzlichen Tokens im Sitzungsspeicher befinden.
Bei Anfrage 2 werden die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet. Außerdem werden die Eingabetokens aus dem Sitzungsspeicher einbezogen, die aus den Eingabetokens der vorherigen Anfrage (Anfrage 1) stammen. Die Burndown-Rate für Tokens im Sitzungsspeicher ist dieselbe wie für Standard-Eingabetokens (1 Eingabesitzungsspeichertoken = 1 Eingabetoken).
Wenn die Verarbeitung von Anfrage 2 nach dem Senden genau 1 Sekunde gedauert hat, werden Ihre Tokens so verarbeitet und auf Ihr Provisioned Throughput-Kontingent angewendet:
Multiplizieren Sie die Eingaben mit den Burndown-Raten, um die Gesamtzahl der Eingabetokens zu erhalten:
2.830 × (1 Token pro Sitzungsspeicher-Token) + 1.000 × (1 Token pro Eingabetext-Token) = 3.830 durch Burndown angepasste Eingabetokens pro Anfrage
Multiplizieren Sie die Ausgaben mit den Burndown-Raten, um die Gesamtzahl der Ausgabetokens zu erhalten:
200 × (24 Tokens pro Audio-Ausgabetoken) = 4.800 Tokens
Addieren Sie diese beiden Summen, um die Gesamtzahl der verarbeiteten Tokens zu erhalten:
3.830 Tokens + 4.800 Tokens = 8.630 Tokens