In diesem Abschnitt wird erläutert, wie der bereitgestellte Durchsatz mit der Gemini Live API für die Tokenzählung und die Durchsetzung von Kontingenten funktioniert.
Die Gemini Live API ermöglicht multimodale Interaktionen mit niedriger Latenz und nutzt den Sitzungsspeicher, um den Kontext über mehrere Turns hinweg beizubehalten. Weitere Funktionen und Sitzungslimits finden Sie in der Gemini Live API-Referenz.
Jede Sitzung muss vollständig entweder dem bereitgestellten Durchsatz oder PayGo gewidmet sein. Ein Übertrag während der Sitzung wird nicht unterstützt. Wenn Sie Ihr Kontingent für den bereitgestellten Durchsatz während einer aktiven Sitzung überschreiten, lässt das System vorübergehende Spitzen zu, um Fehler zu vermeiden. Die Überschreitung wird auf Ihr Gesamtkontingent angerechnet. Kaufen Sie genügend GSUs, um unerwartete Nutzungsspitzen zu vermeiden und die Spitzennachfrage zu decken.
Überlauf wird zwischen Sitzungen unterstützt. Beim Starten einer Sitzung wertet das System den Anfrageheader aus und prüft die Verfügbarkeit des Kontingents für den bereitgestellten Durchsatz. Wenn das Kontingent nicht ausreicht, wird für die neue Sitzung standardmäßig PayGo verwendet.
Da der Sitzungsspeicher die Ausgaben vorheriger Turns als Eingaben für nachfolgende Anfragen übernimmt, wird das Kontingent für den bereitgestellten Durchsatz sowohl auf Grundlage neuer eingehender Tokens als auch akkumulierter Sitzungstokens berechnet. Daher steigt die Gesamtzahl der verarbeiteten Tokens pro Anfrage im Laufe der Sitzung, bis das vordefinierte Sitzungslimit erreicht ist. Der Sitzungsstatus, einschließlich des Sitzungsspeichers, ist verfügbar, solange die Sitzung aktiv ist.
Berücksichtigen Sie bei der Schätzung des erforderlichen bereitgestellten Durchsatzes die Tokens für den Sitzungsspeicher. Beachten Sie, dass die Tokens für den Ausgabe-Video-Avatar nicht im Sitzungsspeicher enthalten sind. Frühere PayGo-Traffic-Muster können als hilfreiche Grundlage für die Berechnung Ihres GSU-Bedarfs dienen.
Die Zeitfenster für die Kontingentdurchsetzung variieren je nach Anzahl der GSUs, die Sie für das Modell erwerben, und können sich ändern.
Gemini 3.8 Live API
Zeitfenster für die Kontingenterzwingung
Im Folgenden sind die Zeitfenster für die Kontingentdurchsetzung für verschiedene GSU-Größen für das Gemini 3.8 Live API-Modell aufgeführt:
- 1–9 GSUs: 45 Sekunden
- Ab 10 GSUs: 5 Sekunden
Die aufgeführten Werte sind unabhängig von der Anfragelatenz. Die Zeit, die für die Bearbeitung Ihrer Anfrage benötigt wird, ist nicht mit dem Zeitfenster für die Kontingentdurchsetzung identisch. Beachten Sie, dass mindestens 10 GSUs für den bereitgestellten Durchsatz erworben werden müssen, damit die Video-Avatar-Anfragen dieses Modells verarbeitet werden können. Wenn weniger als 10 GSUs gekauft werden, wird die gesamte Video-Avatar-basierte Sitzung auf PayGo übertragen.
Die Zeitfenster für die Durchsetzung sind bei kleineren GSU-Mengen größer, damit kleinere Anfragen innerhalb des Zeitfensters erfolgreich verarbeitet werden können. Wenn die Anzahl der GSUs für ein Modell steigt, sind keine längeren Zeitfenster für die Verarbeitung einer Anfrage erforderlich. Wenn Sie Ausgaben häufiger mit dem bereitgestellten Durchsatz verarbeiten müssen, empfehlen wir, die Anzahl der gekauften GSUs zu erhöhen und das entsprechende Erzwingungsfenster zu prüfen. Die Zeitfenster für die Durchsetzung hängen von Backend-Algorithmen ab und können sich ändern.
GSU-Anforderungen schätzen
Sehen wir uns ein Beispiel für eine potenzielle Arbeitslast an und wie das Schätzungstool eine Empfehlung für dieses Modell liefert. Außerdem erfahren Sie, wie Anfragen verarbeitet und Burndown-Raten angewendet werden. Ein Nutzer plant, die Gemini Live API für einen Chatbot zu verwenden, bei dem 10 gleichzeitige Sitzungen mit einer Dauer von 5 Minuten (300 Sekunden) erwartet werden. Es werden 30 Unterhaltungsrunden pro Sitzung erwartet und der Nutzer gibt ein maximales Sitzungskontextfenster von 6.000 Trigger-Tokens an. Die Form der Anfragen wird unten dargestellt:
| Feld | Beispielwert |
|---|---|
| Erwartete Anzahl gleichzeitiger Sitzungen | 10 |
| Erwartete Dauer (Sekunden) | 300 |
| Durchschnittliche Anzahl der Runden pro Sitzung | 30 |
| Maximale Kontextlänge (Trigger-Tokens) | 6.000 |
| Durchschnittliche Eingabetexttokens pro Runde | 20 |
| Durchschnittliche Eingabeaudiotokens pro Runde | 200 |
| Durchschnittliche Eingabebild-/-videotokens pro Runde | 50 |
| Durchschnittliche Ausgabetexttokens pro Runde | 100 |
| Durchschnittliche Ausgabeaudiotokens pro Runde | 200 |
| Ist der Ausgabevideo-Avatar aktiviert? | Ja |
Eingabetokens pro Runde:
Berechnen Sie das Summenprodukt der Eingabemodalitäten und ihrer jeweiligen Burndown-Raten:
Durchschnittliche Eingabetexttokens pro Runde * Burndown-Rate für Eingabetext = 20 * 1 = 20
Durchschnittliche Eingabeaudiotokens pro Runde * Burndown-Rate für Eingabeaudio = 200 * 4 = 800
Durchschnittliche Eingabebild-/-videotokens pro Runde * Burndown-Rate für Eingabebilder = 50 * 1,4 = 70
Burndown-angepasste Eingabetokens insgesamt pro Runde = 20 + 800 + 70 = 890
Ausgabetokens pro Runde:
Berechnen Sie das Summenprodukt der Ausgabemodalitäten und ihrer jeweiligen Burndown-Raten. Beachten Sie,dass Ausgabevideo-Avatar-Tokens feste 6.192 Tokens pro 25 Audio-Tokens darstellen:
Durchschnittliche Ausgabetexttokens pro Runde * Burndown-Rate für Ausgabetext = 100 * 6 = 600
Durchschnittliche Audiotokens pro Runde * Burndown-Rate für Audioausgabe = 200 * 16 = 3.200
Ist der Ausgabevideo-Avatar aktiviert? Ja, multiplizieren Sie also die Audio-Token-Ausgabe mit (6.192/25) und wenden Sie die Burndown-Rate für Ausgabe-Video-Avatar-Token an: 200 * (6.192/25) * 1,4 = 69.350.
Abnahmebereinigte Ausgabetokens insgesamt pro Runde = 600 + 3.200 + 69.350 = 73.150
Kontextfenster-Tokens pro Runde:
Im Kontextfenster werden in jeder Runde Roh-Eingabe- und -Ausgabetokens (ohne Ausgabe-Video-Avatar-Tokens) akkumuliert, bis die maximale Länge des Kontextfensters erreicht ist und es nicht mehr größer wird. Tokens werden als Raw-Tokens auf das Limit des Kontextfensters angerechnet (ohne Anwendung von Burndown-Raten). Wenn das Kontextfenster jedoch als Sitzungsspeicher in die Eingabeanfragen der nächsten Runde eingespeist wird, müssen die Tokens im Kontextfenster die entsprechenden Eingabe-Burndown-Raten basierend auf ihrer Modalität anwenden.
Addieren Sie die Gesamtzahl der Raw-Tokens in jeder Sitzung, ohne die Burndown-Raten zu berücksichtigen.
- Durchschnittliche Eingabetexttokens pro Runde + durchschnittliche Eingabeaudiotokens pro Runde + durchschnittliche Eingabebild-/-videotokens pro Runde + durchschnittliche Ausgabetexttokens pro Runde + durchschnittliche Ausgabeaudiotokens pro Runde = 20 + 200 + 50 + 100 + 200 = 570
Berechnen Sie dann das Verhältnis der einzelnen Raw-Token-Anzahlen zur Gesamtzahl. Wir können die Ausgabe-Tokens für Video-Avatare bei der Berechnung des Kontextfensters ignorieren.
- Eingabetextverhältnis = 20 ÷ 570 = 0,035
- Eingabeaudioverhältnis = 200 ÷ 570 = 0,351
- Verhältnis von Eingabebild zu Eingabevideo = 50 ÷ 570 = 0,088
- Ausgabetextverhältnis = 100/570 = 0,175
- Audioausgabeverhältnis = 200/570 = 0,351
Berechnen Sie dann das Summenprodukt der Verhältnisse, der maximalen Kontextlänge und der Burndown-Raten, als wären sie alle Eingabemodalitäten.
Eingabetextverhältnis * maximale Kontextlänge * Eingabetext-Burndown = 0,035 * 6.000 * 1 = 210
Eingabeaudioverhältnis * maximale Kontextlänge * Eingabeaudio-Burndown = 0,351 * 6.000 * 4 = 8.424
Verhältnis von Eingabebild/-video * maximale Kontextlänge * Burndown von Eingabebild/-video = 0,088 * 6.000 * 1,4 = 739
Verhältnis von Ausgabetext * maximale Kontextlänge * Burndown des Eingabetexts = 0,175 * 6.000 * 1 = 1.050
Audioausgabeverhältnis * maximale Kontextlänge * Audioeingabe-Burndown = 0,351 * 6.000 * 4 = 8.424
Bei der maximalen Kontextfenstergrenze von 6.000 Raw-Tokens beträgt die Gesamtzahl der pro Runde verarbeiteten Kontextfenster-Tokens nach Anpassung des Burndowns 210 + 8.424 + 739 + 1.050 + 8.424 = 18.847.
GSU-Berechnung:
(Eingabetokens pro Runde + Ausgabetokens pro Runde + Kontextfenstertokens pro Runde) * durchschnittliche Anzahl von Runden pro Sitzung * erwartete Anzahl gleichzeitiger Sitzungen * (1 / erwartete Dauer) * (1 GSU / 1.350 TPS) = (890 + 73.150 + 18.847) * 30 * 10 * (1 / 300) * (1 / 1.350) = 68,8, aufgerundet 69 GSUs.
Anfrage wird verarbeitet
Sehen wir uns ein Beispiel dafür an, wie Anfragen im Hinblick auf den bereitgestellten Durchsatz für dieses Modell verarbeitet werden. Nehmen wir an, es gibt drei Anfragen.
Details zu Anfrage 1 – Audio- und Videoeingabe, Audioausgabe
- 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
- Ausgabeaudiotokens, die basierend auf der Art der Anfrage empfangen wurden: 100 Tokens
- Aktualisierter Sitzungsspeicher = 250 + 2.580 + 100 = 2.930 Tokens
Details zu Anfrage 2 – Audioeingabe mit Sitzungsspeicher, Audioausgabe
- Dauer: 40 Sekunden
- Gesendete Tokens (Audio): 40 Sekunden × 25 Tokens/Sekunde = 1.000 Tokens
- Sitzungsspeicher nach Anfrage 1 = 2.930 Tokens
- Gesendete Eingabetokens insgesamt: in dieser Anfrage gesendete Tokens + Sitzungsspeicher aus Anfrage 1 = 1.000 + 2.930 = 3.930 Tokens
- Ausgabeaudiotokens, die basierend auf der Art der Anfrage empfangen wurden: 200 Tokens
- Aktualisierter Sitzungsspeicher = 3.930 + 200 = 4.130 Tokens
Details zu Anfrage 3 – Eingabe von Audio und Video mit Sitzungsspeicher, Ausgabe von Avatar-Video und ‑Audio
- 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
- Sitzungsarbeitsspeicher nach Anfrage 2 = 4.130 Tokens
- Gesamtzahl der gesendeten Eingabetokens: In dieser Anfrage gesendete Tokens + Sitzungsspeicher aus Anfrage 2 = 250 + 2.580 + 4.130 = 6.960 Tokens
- Ausgabe-Video-Avatar-Tokens,die basierend auf der Art der Anfrage empfangen wurden: 61.920 Tokens
- Ausgabeaudiotokens, die basierend auf der Art der Anfrage empfangen wurden: 250 Tokens
- Aktualisierter Sitzungsspeicher = 6.960 + 250 = 7.210 Tokens
Informationen zu verarbeiteten Tokens
Anfrage 1 verarbeitet nur die Eingabe- und Ausgabetokens der laufenden Anfrage, da sich keine zusätzlichen Tokens im Sitzungsspeicher befinden. Alle verarbeiteten Tokens bilden jetzt den Sitzungsspeicher.
Anfrage 2 verarbeitet die Eingabe- und Ausgabetokens aus der laufenden Anfrage und bezieht auch den Sitzungsspeicher aus Anfrage 1 ein. Für alle Sitzungsspeicher-Tokens gilt die Burndown-Rate eines entsprechenden Eingabe-Tokens.
Anfrage 3 verarbeitet die Eingabe- und Ausgabetokens aus der laufenden Anfrage und bezieht auch den Sitzungsspeicher aus Anfrage 2 ein. Für alle Sitzungsspeicher-Tokens gilt die Burndown-Rate eines entsprechenden Eingabe-Tokens.
Wenn die Verarbeitung von Anfrage 3 nach dem Senden genau 1 Sekunde gedauert hat, würden die an das Burndown angepassten Tokens, die auf das Kontingent für den bereitgestellten Durchsatz für dieses Modell angewendet werden, so aussehen:
Eingabeaudiotokens × Burndown-Rate für Eingabeaudio = 250 × 4 = 1.000
Eingabevideotokens * Burndown-Rate für Eingabevideos = 2.580 * 1,4 = 3.612
Sitzungsspeicher-Audio * Eingabeaudio-Burndown-Rate = (250 + 100 + 1.000 + 200) * 4 = 6.200
Video im Sitzungsarbeitsspeicher * Burndown-Rate für Eingabevideo = 2.580 * 1,4 = 3.612
Ausgabevideo-Avatar-Tokens * Ausgabevideo-Avatar-Burndown-Rate = 61.920 * 1,4 = 86.688
Ausgabeaudiotokens × Burndown-Rate für Ausgabeaudio = 250 × 16 = 4.000
Wenn Sie die Gesamtzahl addieren,erhalten Sie 105.112 Tokens (angepasst an die Burn-Down-Rate).
Gemini 2.5 Flash Live API Native Audio
Anfrage wird verarbeitet
Details zu Anfrage 1 – Audio- und Videoeingabe, Audioausgabe
- 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
- Ausgabeaudiotokens, die basierend auf der Art der Anfrage empfangen wurden: 100 Tokens
- Aktualisierter Sitzungsspeicher = 250 + 2.580 + 100 = 2.930 Tokens
Details zu Anfrage 2 – Audioeingabe mit Sitzungsspeicher, Audioausgabe
Dauer: 40 Sekunden
Gesendete Tokens (Audio): 40 Sekunden × 25 Tokens/Sekunde = 1.000 Tokens
Sitzungsspeicher nach Anfrage 1 = 2.930 Tokens
Gesamtzahl der gesendeten Eingabetokens: Tokens, die in dieser Anfrage gesendet wurden + Sitzungsspeicher aus Anfrage 1 = 1.000 + 2.930 = 3.930 Tokens
Ausgabeaudiotokens, die basierend auf der Art der Anfrage empfangen wurden: 200 Tokens
Aktualisierter Sitzungsspeicher = 3.930 + 200 = 4.130 Tokens
Informationen zu verarbeiteten Tokens
Anfrage 1 verarbeitet nur die Eingabe- und Ausgabetokens der laufenden Anfrage, da sich keine zusätzlichen Tokens im Sitzungsspeicher befinden. Alle verarbeiteten Tokens bilden jetzt den Sitzungsspeicher.
Anfrage 2 verarbeitet die Eingabe- und Ausgabetokens aus der laufenden Anfrage und bezieht auch den Sitzungsspeicher aus Anfrage 1 ein. Für alle Sitzungsspeicher-Tokens gilt die Burndown-Rate eines entsprechenden Eingabe-Tokens.
Wenn die Verarbeitung von Anfrage 2 nach dem Senden genau 1 Sekunde gedauert hat, würden die auf das Kontingent für den bereitgestellten Durchsatz für dieses Modell angewendeten, an den Burndown angepassten Tokens so aussehen:
- Eingabeaudiotokens * Burndown-Rate für Eingabeaudio = 1.000 * 6 = 6.000
- Sitzungsspeicher-Audio * Eingabeaudio-Burndown-Rate = (250 + 100) * 6 = 2.100
- Sitzungsspeicher-Video * Eingabevideo-Burndown-Rate = 2.580 * 6 = 15.480
- Ausgabeaudiotokens × Burndown-Rate für Ausgabeaudio = 200 × 24 = 4.800
Wenn Sie die Gesamtzahl addieren, erhalten Sie 28.380 Tokens, angepasst an den Burndown.