title: "Warum nutzen Bild-APIs RPM statt QPS? Ein technischer Vergleich"
Anmerkung des Autors: Eine tiefgehende Analyse, warum Bild-APIs wie Nano Banana Pro und Nano Banana 2 auf RPM (Requests per Minute) statt auf QPS (Queries per Second) als Ratenbegrenzung setzen. Wir betrachten dabei die blockierenden Eigenschaften synchroner Aufrufe bei Gemini, um die Unterschiede in den Anwendungsszenarien zu verstehen.
Wenn Sie bereits mit APIs für Text-LLMs gearbeitet haben, sind Sie wahrscheinlich mit der Kennzahl QPS (Queries per Second) vertraut. Doch bei APIs zur Bilderzeugung wie Nano Banana Pro und Nano Banana 2 dreht sich in der offiziellen Dokumentation alles um RPM (Requests per Minute) – warum sprechen Bild-APIs nicht von QPS? Das ist keine Frage der Namenspräferenz, sondern liegt daran, dass das Modell der synchron blockierenden Aufrufe bei der Bilderzeugung QPS in diesem Szenario nahezu bedeutungslos macht. Dieser Artikel erläutert den technischen Hintergrund dieses Unterschieds.
Kernnutzen: Nach der Lektüre dieses Artikels verstehen Sie die grundlegenden Unterschiede zwischen RPM und QPS in verschiedenen API-Szenarien und warum das synchrone Aufrufmodell der Gemini-Bild-API QPS zu einem Scheinargument macht.
RPM vs. QPS: Die wichtigsten Punkte
Um es direkt vorwegzunehmen: Für APIs zur Bilderzeugung verwenden wir RPM statt QPS, da die Blockierzeit bei synchronen Aufrufen zu lang ist und QPS somit keine praktische Relevanz hat.
| Konzept | Definition | Anwendungsfall | Geeignet für Bild-API? |
|---|---|---|---|
| QPS | Queries Per Second (Anfragen pro Sekunde) | Hochfrequente Dienste mit Millisekunden-Antwortzeit | Nein |
| RPS | Requests Per Second (Anfragen pro Sekunde) | Im Wesentlichen äquivalent zu QPS | Nein |
| RPM | Requests Per Minute (Anfragen pro Minute) | Langsame Dienste mit Sekunden- bis Minuten-Antwortzeit | Ja |
| IPM | Images Per Minute (Bilder pro Minute) | Speziell für die Bilderzeugung | Am besten geeignet |
| RPD | Requests Per Day (Anfragen pro Tag) | Kontingentverwaltung | Ja |
Warum QPS bei Bild-APIs ein Trugschluss ist
Der Schlüssel zum Verständnis liegt in der synchronen Aufrufcharakteristik der Gemini-Bild-API.
Wenn Sie Nano Banana 2 zur Bilderzeugung aufrufen, ist die API synchron blockierend: Sobald Sie die Anfrage senden, bleibt die HTTP-Verbindung offen. Der Client wartet, bis das Bild fertig generiert wurde (13–170 Sekunden), bevor eine Antwort erfolgt. Während dieser gesamten Zeit passiert in der Verbindung nichts – sie wartet lediglich.
Ein Vergleich:
- Claude API (Text): Das erste Token wird innerhalb von 50–200 ms zurückgegeben; durch Streaming erhalten Sie innerhalb einer Sekunde nützliche Ergebnisse.
- Nano Banana 2 (1K-Bild): Es dauert mindestens 13 Sekunden bis zur Antwort, wobei die Verbindung währenddessen vollständig blockiert ist.
Daher ist die Frage „Wie viele Anfragen können pro Sekunde verarbeitet werden?“ (QPS) für Bild-APIs hinfällig, da eine einzige Anfrage bereits 13 Sekunden oder länger beanspruchen kann. RPM ist hier die einzig sinnvolle Maßeinheit.
🎯 Analogie: QPS ist wie die Messung, wie viele Fast-Food-Gerichte ein Restaurant pro Sekunde ausgeben kann. RPM ist wie die Messung, wie viele Tische ein gehobenes Restaurant pro Stunde bedienen kann. Sie würden die Effizienz eines Gourmet-Restaurants nicht in „Gerichten pro Sekunde“ messen, da die Zubereitung eines einzelnen Gangs bereits 30 Minuten dauert.
Über APIYI (apiyi.com) können Sie Nano Banana 2 aufrufen, wobei RPM nicht den offiziellen Beschränkungen unterliegt, was mehr parallele Anfragen ermöglicht.
Technische Details zu synchronen Aufrufen der Gemini-Bild-API
Dies ist die Grundlage, um den Unterschied zwischen RPM und QPS zu verstehen.
Der Blockierprozess bei synchronen Aufrufen von Nano Banana 2
Client sendet Anfrage
│
▼
TCP-Verbindung wird aufgebaut ──────────────────────────┐
│ │
▼ │
Server empfängt Eingabeaufforderung │ Verbindung bleibt offen
│ │ Client wartet blockiert
▼ │
Inferenz des Diffusionsmodells (13-170 Sekunden) │
│ │
▼ │
Bild wird als Base64 kodiert │
│ │
▼ │
Antwort wird gesendet (enthält Bilddaten) ──────────────┘
│
▼
Client empfängt Bild
Während dieses Prozesses ist der Thread/Prozess des Clients vollständig belegt. Bei einem synchronen Single-Thread-Aufruf können Sie pro Minute maximal 60 / Generierungszeit Anfragen senden – bei einem 1K-Bild mit 13 Sekunden Dauer liegt die QPS eines einzelnen Threads bei ca. 0,077 (0,077 Anfragen pro Sekunde), was umgerechnet nur 4,6 RPM entspricht.
Blockierzeiten von Nano Banana 2 nach Auflösung
| Auflösung | Typische Generierungszeit | RPM-Limit (Single-Thread) | "QPS" (Single-Thread) |
|---|---|---|---|
| 0.5K | ~8 Sekunden | ~7,5 RPM | 0,125 |
| 1K | ~13 Sekunden | ~4,6 RPM | 0,077 |
| 2K | ~30 Sekunden | ~2 RPM | 0,033 |
| 4K | ~90-170 Sekunden | ~0,4-0,7 RPM | 0,006-0,011 |
Sehen Sie? Bei einer 4K-Auflösung beträgt die "QPS" eines einzelnen Threads nur 0,006 – das bedeutet, dass im Durchschnitt alle 170 Sekunden eine Anfrage abgeschlossen wird. In diesem Bereich ist eine Diskussion über QPS völlig sinnlos; RPM ist die einzig effektive Metrik.
Einsatzgebiete von RPM und QPS
Einsatzgebiete für QPS
QPS (Queries Per Second) ist als Ratenindikator nur dann sinnvoll, wenn gilt: Die Antwortzeit einer einzelnen Anfrage liegt weit unter 1 Sekunde.
| Diensttyp | Typische Antwortzeit | QPS sinnvoll? | Grund |
|---|---|---|---|
| CDN / Caching | 1-10 ms | Sehr sinnvoll | Tausende Anfragen pro Sekunde möglich |
| Datenbankabfrage | 5-50 ms | Sinnvoll | Hunderte Anfragen pro Sekunde möglich |
| Text-LLM erstes Token | 50-200 ms | Sinnvoll | 5-20 Anfragen pro Sekunde startbar |
| Such-API | 100-500 ms | Sinnvoll | 2-10 Anfragen pro Sekunde abschließbar |
Einsatzgebiete für RPM
RPM (Requests Per Minute) ist als Ratenindikator in Szenarien sinnvoller, in denen: Die Antwortzeit einer einzelnen Anfrage im Sekunden- bis Minutenbereich liegt.
| Diensttyp | Typische Antwortzeit | Warum RPM? | Offizielle Gemini-Limits |
|---|---|---|---|
| Bilderzeugung | 8-170 Sek. | 1 Anfrage dauert länger als 1 Sek. | RPM + IPM |
| Videogenerierung | 30-300 Sek. | Anfrage belegt Minuten | RPM |
| Batch-Verarbeitung | Minutenbereich | Aufgaben-Granularität > 1 Sek. | RPM + RPD |
| Dateikonvertierung | 5-60 Sek. | Lange Verarbeitungsdauer | RPM |
Die vier Dimensionen der Ratenbegrenzung der Gemini-Bild-API
Google hat für die Gemini-Bild-API vier Ratenbegrenzungsdimensionen definiert. Wird eine davon überschritten, erfolgt eine Drosselung:
| Dimension | Bedeutung | Kostenlos-Tarif | Tier 1 (Bezahlt) |
|---|---|---|---|
| RPM | Anfragen pro Minute | 5-15 | 150-300 |
| TPM | Token pro Minute | Begrenzt | Höher |
| RPD | Anfragen pro Tag | 20-100 | 1.000+ |
| IPM | Bilder pro Minute | Begrenzt | Höher |
Beachten Sie IPM (Bilder pro Minute) – dies ist ein speziell für die Bilderzeugung entwickelter Indikator. Da eine Anfrage mehrere Bilder generieren kann, besteht zwischen RPM und IPM keine einfache 1-zu-1-Beziehung.
So steigern Sie den tatsächlichen Durchsatz Ihrer Bilderzeugungs-API
Nachdem wir das Wesen von RPM (Requests per Minute) verstanden haben, stellt sich die nächste Frage: Wie maximiert man die Effizienz der Bilderzeugung innerhalb der RPM-Limits?
Berechnung von Multithreading-Parallelität + RPM-Obergrenze
Angenommen, Sie müssen pro Minute 20 Bilder in 1K-Auflösung generieren:
RPM pro Thread = 60 Sekunden / 13 Sekunden ≈ 4,6 Bilder/Minute
Benötigte Threads = 20 / 4,6 ≈ 5 parallele Threads
Sie müssen jedoch sicherstellen, dass die gesamte RPM der 5 parallelen Threads (ca. 23 RPM) das Kontingent Ihres Kontos nicht überschreitet. Die kostenlose Stufe bietet nur 5-15 RPM, während Tier 1 (bezahlt) 150-300 RPM ermöglicht.
Optimierungsvorschläge für die Bilderzeugungs-API
| Optimierungsstrategie | Effekt | Anwendungsszenario |
|---|---|---|
| Multithreading/Coroutine-Parallelität | Lineare Steigerung (durch RPM begrenzt) | Echtzeit-Bilderzeugung |
| Batch API (asynchron) | Keine Blockierung + 50 % Rabatt | Batch-Szenarien mit tolerierbarer Latenz |
| Auflösung reduzieren | Kürzere Zeit pro Bild → Höhere RPM | Vorschaubilder, Thumbnails |
| APIYI API-Proxy-Dienst | Umgehung offizieller RPM-Limits | Hochverfügbare Produktionsumgebungen |
| Client-Timeout-Einstellungen | Vermeidung unnötiger Wartezeiten | Alle Szenarien (1K empfohlen: 300s, 4K: 600s) |
🎯 Praxistipp: Wenn Sie eine hohe Parallelität bei der Bilderzeugung benötigen, ist der Aufruf von Nano Banana 2 über APIYI (apiyi.com) die einfachste Lösung – Sie umgehen die offiziellen RPM-Limits, erhalten 28 % Rabatt und profitieren von einem Fixpreis von nur 0,045 $ für 4K.
Häufig gestellte Fragen
Q1: Wenn ich 10 Anfragen asynchron parallel sende, wie hoch ist die RPM?
Sie beträgt 10. Die RPM berechnet die Anzahl der Anfragen, die Sie innerhalb einer Minute absenden, unabhängig davon, ob diese bereits beantwortet wurden. Selbst wenn Sie 10 Anfragen gleichzeitig asynchron senden und diese nach jeweils 13 Sekunden nacheinander eintreffen, zählen alle 10 Anfragen zur RPM derselben Minute. Multithreading erhöht also den Durchsatz, kann aber das RPM-Kontingent nicht umgehen.
Q2: Ist die Gemini Batch API asynchron? Kann sie die RPM umgehen?
Ja. Die Gemini Batch API arbeitet im asynchronen Modus – Sie übermitteln einen Stapel von Anfragen und erhalten sofort eine Aufgaben-ID zurück, ohne den Client zu blockieren. Die Aufgaben werden im Hintergrund verarbeitet, und Sie werden benachrichtigt, sobald die Ergebnisse vorliegen. Die Batch API verfügt über ein separates Kontingent (basierend auf Token), belegt nicht das Echtzeit-RPM-Kontingent und ist zudem 50 % günstiger. Der Nachteil ist, dass keine Echtzeitgarantie besteht; sie eignet sich daher für Batch-Szenarien, bei denen es nicht auf jede Sekunde ankommt.
Q3: Ist OpenAIs chatgpt-image-latest ebenfalls synchron blockierend?
Ja. chatgpt-image-latest ist ebenfalls ein synchroner Aufruf mit einer Antwortzeit von etwa 44-60 Sekunden. Die Entwickler-Community berichtet häufig von Timeout-Problemen bei gpt-image-1; es wird empfohlen, ein Timeout von mindestens 300 Sekunden einzustellen. Daher verwendet auch die Bild-API von OpenAI die RPM als Ratenbegrenzungsindikator – die Logik ist dieselbe wie bei Gemini, da bei synchron blockierenden Aufrufen die QPS (Queries per Second) keine sinnvolle Metrik ist.
Q4: Wie umgeht APIYI die offiziellen RPM-Limits?
APIYI nutzt einen Polling-Mechanismus für einen Multi-Account-Pool. Die Plattform verwaltet mehrere Gemini-API-Konten, und die Anfragen der Clients werden automatisch auf verschiedene Konten verteilt, von denen jedes sein eigenes RPM-Kontingent besitzt. Für Entwickler bedeutet dies eine massive Steigerung der RPM, ohne dass mehrere API-Schlüssel selbst verwaltet werden müssen. Gleichzeitig profitieren Sie von 28 % Rabatt und einem Fixpreis von 0,045 $ für 4K-Bilder.
Zusammenfassung
Der Hauptgrund, warum die Nano Banana Bilderzeugungs-API auf RPM (Requests per Minute) statt auf QPS (Queries per Second) setzt:
- Synchrones Blockieren bestimmt die Maßeinheit: Die Gemini Bilderzeugungs-API ist ein synchroner Aufruf. Eine Anfrage blockiert zwischen 13 und 170 Sekunden – innerhalb einer Sekunde kann also nicht einmal eine vollständige Anfrage verarbeitet werden. QPS als Metrik auf Sekundenbasis ist hier sinnlos; RPM (pro Minute) ist die logische Messgröße.
- RPM für langsame Dienste, QPS für schnelle: Eine einfache Faustregel: Wenn die Antwortzeit unter 1 Sekunde liegt, nutzt man QPS, bei über 1 Sekunde RPM. Bilderzeugung, Videoverarbeitung und Dateikonvertierung fallen in die RPM-Kategorie.
- Durchsatzsteigerung durch Parallelität + Kontingente: Multithreading-Parallelität kann den Durchsatz linear steigern, wird jedoch durch das RPM-Kontingent begrenzt. Durch das Polling über einen APIYI-Multi-Account-Pool lässt sich das RPM-Limit eines einzelnen Accounts umgehen.
Wir empfehlen den Aufruf von Nano Banana 2 über APIYI (apiyi.com) – ohne offizielle RPM-Beschränkungen, mit 28 % Rabatt und einem Festpreis von 0,045 $ für 4K.
📚 Referenzen
-
Gemini API Rate Limits: Offizielle Dokumentation zu Ratenbegrenzungen
- Link:
ai.google.dev/gemini-api/docs/rate-limits - Beschreibung: Umfassende Erläuterung der vier Dimensionen RPM, TPM, RPD und IPM.
- Link:
-
Nano Banana Pro: Vergleich von synchroner vs. asynchroner API: Technische Unterschiede der beiden Aufrufmodi
- Link:
help.apiyi.com/en/nano-banana-pro-sync-async-api-comparison-en.html - Beschreibung: Beinhaltet Informationen zu Blockierzeiten, Timeout-Einstellungen und Durchsatzberechnungen.
- Link:
-
OpenAI Rate Limits: Dokumentation zu Ratenbegrenzungen bei OpenAI (RPM-System)
- Link:
developers.openai.com/api/docs/guides/rate-limits - Beschreibung: Vergleich der Design-Ansätze für Ratenbegrenzungen zwischen Gemini und OpenAI.
- Link:
-
APIYI Dokumentationszentrum: Integration der Bilderzeugungs-API zur Umgehung von RPM-Limits
- Link:
docs.apiyi.com - Beschreibung: Hochperformante Integration von Nano Banana 2 und Informationen zu Rabattpreisen.
- Link:
Autor: APIYI Technik-Team
Technischer Austausch: Diskutieren Sie gerne in den Kommentaren. Weitere Informationen finden Sie im APIYI Dokumentationszentrum unter docs.apiyi.com.
