In diesem Abschnitt wird erläutert, wie Bereitgestellter Durchsatz mit der Gemini Live API für die Tokenzählung und die Kontingentdurchsetzung funktioniert.
Die Gemini Live API unterstützt multimodale Interaktionen mit niedriger Latenz über Sitzungen. Sie verwendet einen Sitzungsspeicher, um Informationen aus Interaktionen innerhalb einer Sitzung zu speichern und abzurufen. So kann das Modell zuvor bereitgestellte oder besprochene Informationen abrufen. Bereitgestellter Durchsatz wird im Gemini 2.5 Flash Live API Native Audio-Modell 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 vollständig für Bereitgestellten Durchsatz oder für PayGo-Traffic reserviert sein. Ein Übertrag von Traffic zwischen Bereitgestelltem Durchsatz und PayGo innerhalb derselben Sitzung wird 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 bereitgestellten Durchsatz während einer aktiven Sitzung erreichen, werden keine Drosselung oder Fehler ausgelöst. Stattdessen lässt das System den Traffic für die Sitzung vorübergehend ansteigen, wobei die gesamte nachfolgende Nutzung auf Ihr Gesamtkontingent angerechnet wird. Dieser vorübergehende Anstieg kann dazu führen, dass in Ihren Monitoring-Dashboards die Nutzung des bereitgestellten Durchsatzes (dedizierter Traffic) über Ihrem Limit liegt. Um zu vermeiden, dass Sie Ihre zugewiesenen Limits während der Sitzung überschreiten, sollten Sie genügend GSUs kaufen, um Ihre erwartete Nutzung zu unterstützen.
Ein Übertrag von einer Sitzung zur nächsten wird unterstützt. Wenn Sie Ihr Bereitgestellter Durchsatz-Limit nach Beendigung einer Sitzung überschreiten, können Sie eine zusätzliche Sitzung mit PayGo starten. Ob eine Sitzung vollständig als Bereitgestellter Durchsatz oder PayGo verarbeitet wird, wird zu Beginn der Sitzung entschieden. Das System prüft den vom Nutzer gesendeten Header und verifiziert dann, ob genügend Bereitgestellter Durchsatz-Kontingent für die Sitzung vorhanden ist. Wenn das verfügbare Kontingent für bereitgestellten Durchsatz nicht ausreicht, um die gesamte Sitzung zu verarbeiten, wird stattdessen das PayGo-Kontingent verwendet.
Durchsatz für die Gemini Live API berechnen
Bei Verwendung der Gemini Live API können die im Sitzungsspeicher gespeicherten Tokens in nachfolgenden Anfragen an das Modell verwendet werden. Daher werden bei Bereitgestellter Durchsatz sowohl die eingehenden Tokens als auch die Tokens im 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, und enthält auch ein Metadatenfeld mit der Gesamtzahl der Tokens. Bei der Berechnung des Durchsatzes, der für die Bearbeitung 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 Trafficmuster und Sitzungstokens verwenden, um Ihren Bedarf an Bereitgestellter Durchsatz zu schätzen.
Beispiel für die Schätzung des Bedarfs an bereitgestelltem Durchsatz für die Gemini Live API
Während einer Sitzung wird der gesamte Traffic entweder als Bereitgestellter Durchsatz oder als Pay as you go 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/Frame pro Sekunde = 2.580 Tokens
Tokens insgesamt, die für Anfrage 1 verarbeitet wurden:
- Gesendete Tokens: Summe der gesendeten Audio- und Video-Tokens = 2.580 + 250 = 2.830 Tokens
- Empfangene Tokens: 100 (Audio)
Details zu Anfrage 2
Dauer: 40 Sekunden
Gesendete Tokens (Audio): 40 Sekunden × 25 Tokens/Sekunde = 1.000 Tokens
Tokens insgesamt, die für Anfrage 2 verarbeitet wurden:
- Gesendete Tokens: Tokens gesendet in Anfrage 2 + Tokens im Sitzungsspeicher aus Anfrage 1 = 2.830 Tokens + 1.000 Tokens = 3.830 Tokens
- Empfangene Tokens: 200 (Audio)
Anzahl der in den Anfragen verarbeiteten Tokens berechnen
Die Anzahl der Tokens, die während dieser Anfragen verarbeitet wurden, wird so berechnet:
Bei Anfrage 1 werden nur die Eingabe- und Ausgabetokens aus der laufenden Anfrage verarbeitet, da sich keine zusätzlichen Tokens im Sitzungsspeicher befinden.
Bei Anfrage 2 werden die Eingabe- und Ausgabetokens aus der laufenden Anfrage verarbeitet, aber auch die Eingabetokens aus dem Sitzungsspeicher, die aus den Eingabetokens aus der vorherigen Anfrage (Anfrage 1) im Sitzungsspeicher bestehen. Die Burndown-Rate für Tokens im Sitzungsspeicher ist dieselbe wie für Standard-Eingabetokens (1 Eingabetoken im Sitzungsspeicher = 1 Eingabetoken).
Wenn die Verarbeitung von Anfrage 2 genau 1 Sekunde gedauert hat, nachdem Sie sie gesendet haben, werden Ihre Tokens so verarbeitet und auf Ihr Kontingent für bereitgestellten Durchsatz angewendet:
Multiplizieren Sie Ihre Eingaben mit den Burndown-Raten, um die Gesamtzahl der Eingabetokens zu erhalten:
2.830 × (1 Token pro Token im Sitzungsspeicher) + 1.000 × (1 Token pro Eingabetext-Token) = 3.830 Burndown-bereinigte Eingabetokens pro Abfrage
Multiplizieren Sie Ihre Ausgaben mit den Burndown-Raten, um die Gesamtzahl der Ausgabetokens zu erhalten:
200 × (24 Tokens pro Audioausgabetoken) = 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