In diesem Abschnitt wird beschrieben, wie Provisioned Throughput 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. Dabei wird ein Sitzungsspeicher verwendet, 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.
Die Gemini Live API unterstützt keinen Überlauf von Traffic von „Bereitgestellter Durchsatz“ zu „Pay as you go“-Traffic in derselben Sitzung. Wenn Sie eine Sitzung mit bereitgestelltem Durchsatz starten, können Sie während dieser Sitzung nicht auch Pay-as-you-go-Traffic verwenden und umgekehrt. Wenn Sie das Kontingent für den bereitgestellten Durchsatz während einer Sitzung erreichen, erhalten Sie die folgende Fehlermeldung:
Quota exceeded. Please retry later.
Um diesen Fehler zu vermeiden, müssen Sie genügend GSU für den bereitgestellten Durchsatz erwerben, um Ihren Verbrauch zu decken. Wenn Sie diese Fehlermeldung erhalten, können Sie wieder Anfragen an die Gemini Live API senden, sobald Ihre Nutzung wieder innerhalb des gekauften Kontingents liegt. Der Sitzungsstatus, einschließlich des Sitzungsspeichers, ist verfügbar, solange die Sitzung aktiv ist.
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 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 „Provisioned Throughput“ oder „Pay-as-you-go“ verarbeitet. Wenn Sie Ihr „Provisioned Throughput“-Kontingent während einer Sitzung erreichen, erhalten Sie eine Fehlermeldung mit der Aufforderung, es später noch einmal zu versuchen. Sobald Sie Ihr Kontingent wieder unterschreiten, können Sie wieder Anfragen senden. 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
- Empfangene 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 Eingabesitzungsspeicher-Token = 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 × (6 Tokens pro Audio-Ausgabetoken) = 1.200 Tokens
Addieren Sie diese beiden Summen, um die Gesamtzahl der verarbeiteten Tokens zu erhalten:
3.830 Tokens + 1.200 Tokens = 5.030 Tokens
Wenn Ihr Kontingent für Provisioned Throughput mehr als 5.030 Tokens pro Sekunde beträgt, kann diese Anfrage sofort verarbeitet werden. Wenn es weniger ist, werden die Tokens im Laufe der Zeit mit der Rate verarbeitet, die Sie für Ihr Kontingent festgelegt haben.