In diesem Abschnitt wird erläutert, wie Bereitgestellter 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 geringer Latenz. Dabei wird der Kontext über mehrere Runden hinweg im Sitzungsspeicher beibehalten. Weitere Funktionen und Sitzungslimits finden Sie in der Gemini Live API-Referenz.
Jede Sitzung muss entweder dem bereitgestellten Durchsatz oder Pay-as-you-go 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. Um unerwartete Nutzungsspitzen zu vermeiden, sollten Sie genügend GSUs kaufen, um die Spitzenlast zu bewältigen.
Der Spillover wird zwischen Sitzungen unterstützt. Beim Starten einer Sitzung wertet das System den Anfrageheader aus und prüft, ob das Kontingent für den bereitgestellten Durchsatz verfügbar ist. Wenn das Kontingent nicht ausreicht, wird für die neue Sitzung standardmäßig Pay-as-you-go verwendet.
Da der Sitzungsarbeitsspeicher die Ausgaben des vorherigen Turns als Eingaben für nachfolgende Anfragen übernimmt, wird das Kontingent bei Bereitgestellter Durchsatz sowohl auf Grundlage neuer eingehender Tokens als auch auf Grundlage der angesammelten 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 beim Schätzen des erforderlichen bereitgestellten Durchsatzes unbedingt die Sitzungsspeichertokens. Hinweis: Avatar-Tokens für die Ausgabe von Videos sind nicht im Sitzungsspeicher enthalten. Bisherige Pay-as-you-go-Trafficmuster können als hilfreiche Grundlage für die Berechnung Ihres GSU-Bedarfs dienen.
Die Zeiträume 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 Zeiträume 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
- 10 oder mehr GSUs: 5 Sekunden
Die aufgeführten Werte sind unabhängig von der Latenz der Anfrage. Die Zeit, die für die Bearbeitung Ihrer Anfrage benötigt wird, ist nicht mit dem Zeitraum für die Kontingentdurchsetzung identisch. Für die Verarbeitung von Anfragen im Zusammenhang mit Video-Avataren dieses Modells müssen mindestens 10 GSUs für den bereitgestellten Durchsatz erworben werden. Wenn weniger als 10 GSUs gekauft werden, wird die gesamte sitzungsbasierte Nutzung des Video-Avatars auf Pay-as-you-go übertragen.
Bei kleineren GSU-Beträgen sind die Durchsetzungszeiträume länger, damit kleinere Anfragen innerhalb des Zeitraums erfolgreich verarbeitet werden können. Wenn die Anzahl der GSUs für ein Modell steigt, sind längere Zeiträume für die Verarbeitung einer Anfrage nicht erforderlich. Wenn Sie Ausgaben häufiger mit bereitgestelltem Durchsatz verarbeiten müssen, empfehlen wir, die Anzahl der gekauften GSUs zu erhöhen und das entsprechende Erzwingungszeitfenster zu prüfen. Die Zeiträume 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ätztool eine Empfehlung für dieses Modell abgibt, die auch darüber informiert, wie Anfragen verarbeitet und Burndown-Raten angewendet werden. Ein Nutzer plant, die Live-API für einen Chatbot zu verwenden, bei dem 10 gleichzeitige Sitzungen erwartet werden. Die Dauer beträgt 5 Minuten (300 Sekunden). Es wird mit 30 Gesprächsrunden pro Sitzung gerechnet und der Nutzer gibt ein maximales Sitzungskontextfenster von 6.000 Trigger-Tokens an. Die Form der Anfragen ist 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 Avatar für die Videoausgabe aktiviert? | Ja |
Eingabetokens pro Runde:
Berechnen Sie das Summenprodukt der Eingabemodalitäten und ihrer jeweiligen Burndown-Raten:
Durchschnittliche Eingabetexttokens pro Runde × Rate für die Reduzierung des Eingabetextes = 20 × 1 = 20
Durchschnittliche Eingabeaudiotokens pro Runde × Rate für die Reduzierung der Eingabeaudioinhalte = 200 × 4 = 800
Durchschnittliche Eingabebild-/Videotokens pro Runde × Verbrauchsrate für Eingabebilder = 50 × 1,4 = 70
Insgesamt burndown-angepasste Eingabetokens pro Runde = 20 + 800 + 70 = 890
Ausgabetokens pro Runde:
Berechnen Sie das Summenprodukt der Ausgabemodalitäten und der entsprechenden Burndown-Raten. Die Ausgabevideo-Avatartokens entsprechen einer festen Anzahl von 6.192 Tokens pro 25 Audiotokens:
Durchschnittliche Ausgabetexttokens pro Turn × Burndown-Rate für Ausgabetext = 100 × 6 = 600
Durchschnittliche Audiotokens pro Antwort × Ausgabe-Burndown-Rate für Audio = 200 × 16 = 3.200
Ist der Avatar für die Videoausgabe aktiviert? Ja. Multipliziere die Ausgabe der Audio-Tokens mit (6.192/25) und wende die Token-Verbrauchsrate für die Ausgabe von Video-Avataren an: 200 * (6.192/25) * 1,4 = 69.350
Burn-Down-angepasste Gesamtzahl der Ausgabetokens pro Turn = 600 + 3.200 + 69.350 = 73.150
Kontextfenster-Tokens pro Runde:
Im Kontextfenster werden in jeder Runde Roh-Eingabe- und Ausgabetokens (ohne Ausgabevideo-Avatartokens) angesammelt, bis die maximale Länge des Kontextfensters erreicht ist und die Anzahl der Tokens nicht mehr zunimmt. Tokens werden als Roh-Tokens (ohne Anwendung von Burndown-Raten) auf das Kontextfensterlimit angerechnet. Wenn das Kontextfenster jedoch als Sitzungsspeicher in die Eingabeanfragen der nächsten Runde eingegeben wird, müssen die Tokens im Kontextfenster die entsprechenden Raten für den Input-Burndown basierend auf ihrer Modalität anwenden.
Fügen Sie die Gesamtzahl der Roh-Tokens in jeder Sitzung hinzu, ohne die Burndown-Raten zu berücksichtigen.
- Durchschnittliche Eingabetexttokens pro Turn + durchschnittliche Eingabeaudiotokens pro Turn + durchschnittliche Eingabe-Bild-/Videotokens pro Turn + durchschnittliche Ausgabetexttokens pro Turn + durchschnittliche Ausgabeaudiotokens pro Turn = 20 + 200 + 50 + 100 + 200 = 570
Berechnen Sie dann das Verhältnis jeder Roh-Token-Anzahl zur Gesamtzahl. Wir können Video-Avatar-Ausgabetokens bei der Berechnung des Kontextfensters ignorieren.
- Verhältnis des Eingabetexts = 20/570 = 0,035
- Verhältnis von Eingabeaudio = 200/570 = 0,351
- Verhältnis von Eingabebild zu Eingabevideo = 50/570 = 0,088
- Verhältnis von Ausgabetext = 100/570 = 0,175
- Ausgabe-Audioverhä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.
Verhältnis des Eingabetexts × maximale Kontextlänge × Burndown des Eingabetexts = 0,035 × 6.000 × 1 = 210
Verhältnis von Eingabeaudio × maximale Kontextlänge × Burndown von Eingabeaudio = 0,351 × 6.000 × 4 = 8.424
Eingabebild-/Videoverhältnis × maximale Kontextlänge × Eingabebild-/Video-Burndown = 0,088 × 6.000 × 1,4 = 739
Verhältnis von Ausgabetext × maximale Kontextlänge × Eingabetext-Burndown = 0,175 × 6.000 × 1 = 1.050
Ausgabe-Audioverhältnis × maximale Kontextlänge × Burndown des Eingabeaudios = 0,351 × 6.000 × 4 = 8.424
Bei der maximalen Kontextfenstergrenze von 6.000 Roh-Tokens beträgt die Gesamtzahl der pro Runde verarbeiteten, burndown-angepassten Kontextfenster-Tokens 210 + 8.424 + 739 + 1.050 + 8.424 = 18.847.
GSU-Berechnung:
(Eingabetokens pro Schritt + Ausgabetokens pro Schritt + Kontextfenster-Tokens pro Schritt) × durchschnittliche Anzahl der Schritte 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.
Anfragebearbeitung
Sehen wir uns ein Beispiel dafür an, wie Anfragen in Bezug auf den bereitgestellten Durchsatz für dieses Modell verarbeitet werden. Angenommen, 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 je nach Art der Anfrage empfangen werden: 100 Tokens
- Aktualisierter Sitzungsarbeitsspeicher = 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
- Sitzungsarbeitsspeicher nach Anfrage 1 = 2.930 Tokens
- Gesamtzahl der gesendeten Eingabetokens: Tokens, die in dieser Anfrage gesendet wurden + Sitzungsarbeitsspeicher aus Anfrage 1 = 1.000 + 2.930 = 3.930 Tokens
- Empfangene Ausgabeaudiotokens je nach Art der Anfrage: 200 Tokens
- Aktualisierter Sitzungsspeicher = 3.930 + 200 = 4.130 Tokens
Details zu Anfrage 3 – Audio- und Videoeingabe mit Sitzungsspeicher, Ausgabe von Avatarvideo 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: Tokens, die in dieser Anfrage gesendet wurden + Sitzungsarbeitsspeicher aus Anfrage 2 = 250 + 2.580 + 4.130 = 6.960 Tokens
- Empfangene Ausgabetokens für Video-Avatare basierend auf der Art der Anfrage: 61.920 Tokens
- Empfangene Audio-Ausgabetokens je nach Art der Anfrage: 250 Tokens
- Aktualisierter Sitzungsspeicher = 6.960 + 250 = 7.210 Tokens
Verarbeitete Tokens
Bei Anfrage 1 werden nur die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet, da sich keine zusätzlichen Tokens im Sitzungsspeicher befinden. Alle verarbeiteten Tokens bilden jetzt den Sitzungsspeicher.
Bei Anfrage 2 werden die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet. Außerdem wird der Sitzungsspeicher aus Anfrage 1 berücksichtigt. Für alle Tokens für das Sitzungsgedächtnis gilt die Burndown-Rate eines entsprechenden Eingabetokens.
Bei Anfrage 3 werden die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet. Außerdem wird der Sitzungsspeicher aus Anfrage 2 berücksichtigt. Für alle Tokens für das Sitzungsgedächtnis gilt die Burndown-Rate eines entsprechenden Eingabetokens.
Wenn die Verarbeitung von Anfrage 3 nach dem Senden genau 1 Sekunde gedauert hat, wären die auf das Kontingent für bereitgestellten Durchsatz für dieses Modell angewendeten, burndown-angepassten Tokens wie folgt:
Eingabeaudiotokens × Rate für das Herunterzählen von Eingabeaudio = 250 × 4 = 1.000
Eingabevideotokens × Rate für die Reduzierung von Eingabevideos = 2.580 × 1,4 = 3.612
Audio-Burndown-Rate für Sitzungsspeicher × Audio-Burndown-Rate für Eingabe = (250 + 100 + 1.000 + 200) × 4 = 6.200
Video für den Sitzungsarbeitsspeicher × Burndown-Rate für das Eingabevideo = 2.580 × 1,4 = 3.612
Ausgabevideo-Avatartokens × Burndown-Rate für Ausgabevideo-Avatare = 61.920 × 1,4 = 86.688
Ausgabeaudiotokens × Ausgabe-Burndown-Rate = 250 × 16 = 4.000
Wenn Sie die Summe hinzufügen,erhalten Sie 105.112 Tokens nach Burndown-Anpassung.
Gemini 2.5 Flash Live API Native Audio
Anfragebearbeitung
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 je nach Art der Anfrage empfangen werden: 100 Tokens
- Aktualisierter Sitzungsarbeitsspeicher = 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
Sitzungsarbeitsspeicher nach Anfrage 1 = 2.930 Tokens
Gesamtzahl der gesendeten Eingabetokens: Tokens, die in dieser Anfrage gesendet wurden + Sitzungsarbeitsspeicher aus Anfrage 1 = 1.000 + 2.930 = 3.930 Tokens
Empfangene Ausgabeaudiotokens je nach Art der Anfrage: 200 Tokens
Aktualisierter Sitzungsspeicher = 3.930 + 200 = 4.130 Tokens
Verarbeitete Tokens
Bei Anfrage 1 werden nur die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet, da sich keine zusätzlichen Tokens im Sitzungsspeicher befinden. Alle verarbeiteten Tokens bilden jetzt den Sitzungsspeicher.
Bei Anfrage 2 werden die Eingabe- und Ausgabetokens der laufenden Anfrage verarbeitet. Außerdem wird der Sitzungsspeicher aus Anfrage 1 berücksichtigt. Für alle Tokens für den Sitzungsspeicher gilt die Burndown-Rate eines entsprechenden Eingabetokens.
Wenn die Verarbeitung von Anfrage 2 nach dem Senden genau 1 Sekunde gedauert hat, wären die auf das Kontingent für bereitgestellten Durchsatz für dieses Modell angewendeten, durch Burndown angepassten Tokens wie folgt:
- Eingabeaudiotokens × Burndown-Rate für Eingabeaudio = 1.000 × 6 = 6.000
- Audio-Speicher für Sitzung * Abbaugeschwindigkeit für Eingabeaudio = (250 + 100) * 6 = 2.100
- Video für Sitzungsspeicher × Burndown-Rate für Eingabevideo = 2.580 × 6 = 15.480
- Ausgabeaudiotokens × Ausgabe-Burndown-Rate für Audio = 200 × 24 = 4.800
Wenn Sie die Summe bilden,erhalten Sie 28.380 Tokens (bereinigt um den Burn-down).