In diesem Abschnitt wird beschrieben, wie Provisioned Throughput mit der Live API für die Tokenzählung und die Kontingenterzwingung funktioniert.
Die 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. Provisioned Throughput unterstützt das Modell Gemini 2.5 Flash mit Live API. Weitere Informationen zur Live API, einschließlich Sitzungslimits und Funktionen, finden Sie in der Live API-Referenz.
Durchsatz für Live API berechnen
Bei Verwendung der 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 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 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 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 in Anfrage 2 + 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 bei diesen 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. Sie enthält aber auch die Eingabetokens aus dem Sitzungsspeicher, 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 Token für den Sitzungsarbeitsspeicher) + 1.000 × (1 Token pro Eingabetext-Token) = 3.830 Eingabetokens pro Anfrage (mit Burndown-Anpassung)
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.