title: "Pourquoi les API de génération d'images utilisent le RPM plutôt que le QPS ?"
description: "Comprenez pourquoi le RPM est la norme pour les API de génération d'images comme Nano Banana Pro, face aux limites du QPS dans les modèles synchrones."
Note de l'auteur : Analyse approfondie des raisons pour lesquelles les API de génération d'images comme Nano Banana Pro et Nano Banana 2 utilisent le RPM (requêtes par minute) plutôt que le QPS (requêtes par seconde) comme indicateur de limitation de débit. En partant des caractéristiques de blocage des appels synchrones de Gemini, nous explorerons les différences d'utilisation entre ces deux indicateurs.
Si vous avez déjà utilisé des API de grands modèles de langage textuels, vous êtes probablement habitué au QPS (requêtes par seconde). Mais avec les API de génération d'images comme Nano Banana Pro et Nano Banana 2, la documentation officielle ne parle que de RPM (requêtes par minute) — pourquoi les API de génération d'images ne parlent-elles pas de QPS ? Ce n'est pas une question de préférence de nommage, mais plutôt le fait que le mode d'appel synchrone bloquant de la génération d'images rend le QPS pratiquement inutile dans ce contexte. Cet article explique clairement cette distinction sur le plan technique.
Valeur ajoutée : Après avoir lu cet article, vous comprendrez la différence fondamentale entre le RPM et le QPS dans divers scénarios d'API, et pourquoi le mode d'appel synchrone des API d'images de Gemini rend le QPS obsolète.
Points clés : RPM vs QPS
Répondons directement à la question : les API de génération d'images utilisent le RPM plutôt que le QPS, car le temps de blocage des appels synchrones est trop long, rendant le QPS dénué de sens.
| Concept | Définition | Cas d'usage | Adapté aux API d'images ? |
|---|---|---|---|
| QPS | Requêtes par seconde (Queries Per Second) | Services haute fréquence (réponse en ms) | Non |
| RPS | Requêtes par seconde (Requests Per Second) | Équivalent au QPS | Non |
| RPM | Requêtes par minute (Requests Per Minute) | Services lents (réponse en secondes/minutes) | Oui |
| IPM | Images par minute (Images Per Minute) | Spécifique à la génération d'images | Idéal |
| RPD | Requêtes par jour (Requests Per Day) | Gestion des quotas | Oui |
Pourquoi le QPS est une fausse bonne idée pour les API de génération d'images
La clé pour comprendre ce problème réside dans la nature synchrone de l'API de génération d'images de Gemini.
Lorsque vous appelez Nano Banana 2 pour générer une image, l'API est en blocage synchrone : une fois la requête envoyée, la connexion HTTP reste ouverte et le client attend que l'image soit entièrement générée (entre 13 et 170 secondes) avant de recevoir une réponse. Pendant toute cette durée, la connexion ne fait rien d'autre qu'attendre.
Comparons :
- API Claude (texte) : le premier jeton est renvoyé en 50-200 ms, avec un streaming permettant d'obtenir des résultats utiles en moins d'une seconde.
- Nano Banana 2 (image 1K) : il faut au minimum 13 secondes pour obtenir une réponse, avec une connexion bloquée tout du long.
Par conséquent, pour une API de génération d'images, la question "combien de requêtes traitées par seconde" (QPS) n'a aucun sens, car une seule requête peut monopoliser votre connexion pendant plus de 13 secondes. Le RPM est donc l'unité de mesure logique.
🎯 Analogie : Le QPS revient à mesurer combien de repas un fast-food peut servir par seconde. Le RPM ressemble davantage à la mesure du nombre de tables qu'un restaurant gastronomique peut servir par heure. Vous n'utiliseriez pas le "nombre de plats par seconde" pour mesurer l'efficacité d'un restaurant étoilé, car un seul plat nécessite déjà 30 minutes de préparation.
En utilisant APIYI (apiyi.com) pour appeler Nano Banana 2, le RPM n'est pas limité par les restrictions officielles, ce qui vous permet de lancer davantage de requêtes en parallèle.
Détails techniques des appels synchrones de l'API de génération d'images Gemini
C'est la base fondamentale pour comprendre le RPM vs QPS.
Le processus de blocage des appels synchrones de Nano Banana 2
Envoi de la requête par le client
│
▼
Établissement de la connexion TCP ─────────────────────────────┐
│ │
▼ │
Réception de l'invite par le serveur │ Connexion maintenue ouverte
│ │ Le client attend en bloquant
▼ │
Inférence du modèle de diffusion (13-170 secondes) │
│ │
▼ │
Encodage de l'image en base64 │
│ │
▼ │
Réponse renvoyée (contenant les données de l'image) ───────────┘
│
▼
Réception de l'image par le client
Durant ce processus, le thread ou le processus du client est totalement occupé. Si vous utilisez un appel synchrone monothread, vous ne pouvez envoyer au maximum que 60 / temps de génération requêtes par minute. Pour une image 1K prenant 13 secondes, le QPS monothread est d'environ 0,077 (0,077 requête par seconde), ce qui donne un RPM de 4,6.
Temps de blocage de Nano Banana 2 selon la résolution
| Résolution | Temps de génération typique | Limite RPM monothread | "QPS" monothread |
|---|---|---|---|
| 0.5K | ~8 secondes | ~7,5 RPM | 0,125 |
| 1K | ~13 secondes | ~4,6 RPM | 0,077 |
| 2K | ~30 secondes | ~2 RPM | 0,033 |
| 4K | ~90-170 secondes | ~0,4-0,7 RPM | 0,006-0,011 |
Vous voyez ? En résolution 4K, le "QPS" monothread n'est que de 0,006, ce qui signifie qu'il faut en moyenne 170 secondes pour terminer une seule requête. À ce niveau, discuter de QPS est inutile ; seul le RPM constitue une mesure efficace.
Dans quels cas utiliser RPM et QPS ?
Scénarios adaptés au QPS
Le QPS (requêtes par seconde) est un indicateur de débit pertinent uniquement si : le temps de réponse d'une requête unique est largement inférieur à 1 seconde.
| Type de service | Temps de réponse typique | QPS pertinent ? | Raison |
|---|---|---|---|
| CDN / Cache | 1-10 ms | Très pertinent | Peut traiter des milliers de requêtes par seconde |
| Requête base de données | 5-50 ms | Pertinent | Peut traiter des centaines de requêtes par seconde |
| Premier Token LLM texte | 50-200 ms | Pertinent | Peut lancer 5-20 requêtes par seconde |
| API de recherche | 100-500 ms | Pertinent | Peut terminer 2-10 requêtes par seconde |
Scénarios adaptés au RPM
Le RPM (requêtes par minute) est un indicateur de débit plus approprié lorsque : le temps de réponse d'une requête unique se situe entre la seconde et la minute.
| Type de service | Temps de réponse typique | Pourquoi utiliser le RPM | Limites officielles Gemini |
|---|---|---|---|
| Génération d'images | 8-170 s | Impossible de finir en 1 s | RPM + IPM |
| Génération vidéo | 30-300 s | Requête occupant plusieurs minutes | RPM |
| Traitement de données par lots | Niveau minute | Granularité de tâche > seconde | RPM + RPD |
| Conversion de fichiers | 5-60 s | Traitement long par requête | RPM |
Les quatre dimensions de limitation de débit de l'API de génération d'images Gemini
Google a conçu quatre dimensions de limitation de débit pour l'API de génération d'images Gemini. Dépasser l'une d'entre elles entraîne une limitation :
| Dimension | Signification | Niveau gratuit | Tier 1 (Payant) |
|---|---|---|---|
| RPM | Requêtes par minute | 5-15 | 150-300 |
| TPM | Tokens par minute | Limité | Élevé |
| RPD | Requêtes par jour | 20-100 | 1 000+ |
| IPM | Images par minute | Limité | Élevé |
Attention à l'IPM (images par minute) — cet indicateur est spécifiquement conçu pour la génération d'images. Comme une seule requête peut générer plusieurs images, il n'y a pas de relation simple de un pour un entre le RPM et l'IPM.
Comment optimiser le débit réel de votre API de génération d'images
Maintenant que vous avez saisi l'essence du RPM (requêtes par minute), la question suivante est : comment maximiser l'efficacité de génération tout en respectant ces limites ?
Calcul du multi-threading et du plafond de RPM
Imaginons que vous ayez besoin de générer 20 images 1K par minute :
RPM par thread unique = 60 secondes / 13 secondes ≈ 4,6 images/minute
Nombre de threads nécessaires = 20 / 4,6 ≈ 5 threads simultanés
Cependant, vous devez vous assurer que le total des RPM de ces 5 threads (environ 23 RPM) ne dépasse pas le quota de votre compte. Le niveau gratuit est limité à 5-15 RPM, tandis que le niveau payant (Tier 1) offre entre 150 et 300 RPM.
Conseils d'optimisation pour l'API de génération d'images
| Stratégie d'optimisation | Effet | Cas d'usage |
|---|---|---|
| Multi-threading/Coroutines | Augmentation linéaire (limité par le RPM) | Génération en temps réel |
| Batch API asynchrone | Non bloquant + 50 % de réduction | Traitement par lots tolérant la latence |
| Réduction de la résolution | Temps par image réduit → RPM augmenté | Prévisualisations, vignettes |
| Service proxy APIYI | Contourne les limites RPM officielles | Environnements de production à haute charge |
| Timeout client | Évite les attentes inutiles | Tous les cas (1K : 300s conseillé, 4K : 600s) |
🎯 Conseil pratique : Si vous avez besoin d'une génération à haut débit, passer par APIYI (apiyi.com) pour invoquer Nano Banana 2 est la solution la plus simple : vous n'êtes pas limité par les RPM officiels, vous bénéficiez d'une réduction de 28 % et d'un prix fixe de 0,045 $ pour la 4K.
Foire aux questions
Q1 : Si j’envoie 10 requêtes en concurrence asynchrone, quel est le RPM comptabilisé ?
Le résultat est 10. Le RPM calcule le nombre de requêtes émises en une minute, peu importe si elles ont déjà reçu une réponse. Même si vous envoyez 10 requêtes simultanément via une concurrence asynchrone, elles seront bloquées pendant 13 secondes chacune avant de revenir ; ces 10 requêtes comptent donc toutes dans le RPM de la même minute. Le multi-threading améliore le débit, mais ne permet pas de contourner le quota de RPM.
Q2 : L’API Batch de Gemini est-elle asynchrone ? Peut-elle contourner les RPM ?
Oui. L'API Batch de Gemini fonctionne en mode asynchrone : vous soumettez un lot de requêtes et recevez immédiatement un ID de tâche sans bloquer le client. La tâche est traitée en arrière-plan et vous êtes notifié une fois terminée. L'API Batch dispose de son propre quota (basé sur les jetons) et n'occupe pas le quota de RPM en temps réel, tout en étant 50 % moins chère. L'inconvénient est l'absence de garantie de temps réel, ce qui la rend idéale pour les traitements par lots "non urgents".
Q3 : L’API chatgpt-image-latest d’OpenAI est-elle aussi bloquante ?
Oui. chatgpt-image-latest est également un appel synchrone, avec un temps de réponse d'environ 44 à 60 secondes. La communauté des développeurs signale des problèmes de timeout fréquents avec gpt-image-1 ; il est conseillé de définir un délai d'attente d'au moins 300 secondes. L'API d'image d'OpenAI utilise donc aussi le RPM comme indicateur de limitation de débit, avec la même logique que Gemini : comme le temps de réponse bloquant est trop long, le QPS (requêtes par seconde) n'a pas de sens.
Q4 : Comment APIYI permet-il de dépasser les limites RPM officielles ?
APIYI utilise un mécanisme de rotation de pool multi-comptes : la plateforme gère plusieurs comptes API Gemini, et les requêtes des clients sont automatiquement réparties entre ces différents comptes, chacun possédant son propre quota de RPM. Pour le développeur, cela équivaut à une augmentation significative du RPM sans avoir à gérer soi-même plusieurs clés API. Vous profitez également d'une réduction de 28 % et d'un tarif fixe de 0,045 $ pour la 4K.
Résumé
La raison principale pour laquelle l'API de génération d'images Nano Banana utilise le RPM plutôt que le QPS :
- Le blocage synchrone dicte l'unité de mesure : L'API de génération d'images Gemini est un appel synchrone. Une seule requête bloque pendant 13 à 170 secondes, ce qui signifie qu'il est impossible d'en terminer ne serait-ce qu'une seule par seconde. L'indicateur QPS (par seconde) n'a donc aucun sens ici ; le RPM (par minute) est la mesure logique.
- Le RPM pour les services lents, le QPS pour les rapides : Une règle simple : si le temps de réponse est inférieur à 1 seconde, utilisez le QPS ; s'il est supérieur à 1 seconde, utilisez le RPM. La génération d'images, de vidéos et la conversion de fichiers relèvent toutes du scénario RPM.
- L'augmentation du débit repose sur la concurrence et les quotas : La concurrence multi-thread peut augmenter le débit de manière linéaire, mais elle est limitée par le quota RPM. L'utilisation d'un pool de comptes multiples via APIYI permet de contourner les limites RPM d'un compte unique.
Nous vous recommandons d'utiliser Nano Banana 2 via APIYI (apiyi.com) : vous ne serez pas limité par le RPM officiel, vous bénéficierez d'une réduction de 28 % et d'un tarif fixe de 0,045 $ pour la 4K.
📚 Références
-
Limites de débit de l'API Gemini : Documentation officielle sur les limites de débit
- Lien :
ai.google.dev/gemini-api/docs/rate-limits - Description : Comprend une explication complète des limites à quatre dimensions : RPM, TPM, RPD et IPM.
- Lien :
-
Comparaison des API synchrones et asynchrones de Nano Banana Pro : Différences techniques entre les deux modes d'appel
- Lien :
help.apiyi.com/en/nano-banana-pro-sync-async-api-comparison-en.html - Description : Inclut les temps de blocage, les paramètres de délai d'attente et le calcul du débit.
- Lien :
-
Limites de débit d'OpenAI : Documentation sur les limites de débit d'OpenAI (système RPM)
- Lien :
developers.openai.com/api/docs/guides/rate-limits - Description : Compare les approches de conception des limites de débit entre Gemini et OpenAI.
- Lien :
-
Centre de documentation APIYI : Accès à l'API de génération d'images pour contourner les limites RPM
- Lien :
docs.apiyi.com - Description : Accès à haute concurrence pour Nano Banana 2 et tarifs réduits.
- Lien :
Auteur : Équipe technique APIYI
Échanges techniques : N'hésitez pas à discuter dans la section commentaires. Pour plus d'informations, visitez le centre de documentation APIYI sur docs.apiyi.com.
