Cette section explique le fonctionnement du débit provisionné avec l'API Gemini Live pour le décompte des jetons et l'application des quotas.
L'API Gemini Live prend en charge les interactions multimodales à faible latence via des sessions. Elle utilise une mémoire de session pour conserver et rappeler les informations issues des interactions au sein d'une session. Cela permet au modèle de rappeler les informations fournies ou discutées précédemment. Le débit provisionné est compatible avec le modèle Gemini 2.5 Flash avec l'API Gemini Live. Pour en savoir plus sur l'API Gemini Live, y compris sur les limites et les fonctionnalités des sessions, consultez la documentation de référence de l'API Gemini Live.
L'API Gemini Live nécessite qu'une session soit entièrement dédiée au trafic de débit provisionné ou au trafic à la carte. Elle n'est pas compatible avec le trafic de débordement entre le débit provisionné et le trafic à la carte au sein d'une même session. Le type de trafic défini au début d'une session se poursuit pendant toute sa durée. Si vous atteignez votre quota de débit provisionné au cours d'une session active, vous ne subirez aucune limitation ni aucune erreur. Au lieu de cela, le système permet au trafic d'exploser temporairement pour que la session se poursuive, et toute utilisation ultérieure est enregistrée par rapport à votre quota global. Cette explosion temporaire peut entraîner l'affichage de l'utilisation du débit provisionné (trafic dédié) au-dessus de votre limite dans vos tableaux de bord de surveillance. Pour éviter de dépasser vos limites allouées en milieu de session, il est important d'acheter suffisamment d'unités de service Gemini pour prendre en charge votre utilisation prévue.
Le débordement est accepté d'une session à l'autre. Si vous dépassez votre limite de débit provisionné après la fin d'une session, vous pouvez démarrer une session supplémentaire à l'aide du trafic à la carte. Le traitement d'une session entièrement en tant que débit provisionné ou trafic à la carte est décidé au début de la session. Le système vérifie l'en-tête envoyé par l'utilisateur, puis vérifie si le quota de débit provisionné est suffisant pour la session. Si le quota de débit provisionné disponible est insuffisant pour traiter l'ensemble de la session, le quota de trafic à la carte est utilisé à la place.
Calculer le débit pour l'API Gemini Live
Lorsque vous utilisez l'API Gemini Live, les jetons stockés dans la mémoire de session peuvent être utilisés dans les requêtes ultérieures adressées au modèle. Par conséquent, le débit provisionné prend en compte les jetons entrants ainsi que les jetons de mémoire de session dans la même requête. Cela peut entraîner un nombre de jetons traités par requête supérieur à celui envoyé par l'utilisateur dans la requête en cours.
L'API Gemini Live est limitée au nombre total de jetons pouvant être stockés dans la mémoire de session. Elle comporte également un champ de métadonnées contenant le nombre total de jetons. Lorsque vous calculez le débit nécessaire pour traiter vos requêtes, vous devez tenir compte des jetons dans la mémoire de session. Si vous avez utilisé l'API Gemini Live avec le paiement à l'usage, vous pouvez utiliser ces modèles de trafic et ces jetons de session pour estimer vos besoins en débit provisionné.
Exemple d'estimation de vos besoins en débit provisionné pour l'API Gemini Live
Au cours d'une session, tout le trafic est traité en tant que débit provisionné ou paiement à l'usage.
L'état de la session, y compris la mémoire de session, est disponible tant que la session est active.
Cet exemple illustre le traitement de deux requêtes consécutives en incluant les jetons de la mémoire de session.
Détails de la requête 1
Durée : 10 secondes
Jetons envoyés (audio) : 10 secondes x 25 jetons/seconde = 250 jetons
Jetons envoyés (vidéo) : 10 secondes x 258 jetons/image par seconde = 2 580 jetons
Nombre total de jetons traités pour la requête 1 :
- Jetons envoyés : somme des jetons audio et vidéo envoyés = 2 580 + 250 = 2 830 jetons
- Jetons reçus : 100 (audio)
Détails de la requête 2
Durée : 40 secondes
Jetons envoyés (audio) : 40 secondes x 25 jetons/seconde = 1 000 jetons
Nombre total de jetons traités pour la requête 2 :
- Jetons envoyés : Jetons envoyés dans la requête 2 + jetons de mémoire de session de la requête 1 = 2 830 jetons + 1 000 jetons = 3 830 jetons
- Jetons reçus : 200 (audio)
Calculer le nombre de jetons traités dans les requêtes
Le nombre de jetons traités lors de ces requêtes est calculé comme suit :
La requête 1 ne traite que les jetons d'entrée et de sortie de la requête en cours, car il n'y a pas de jetons supplémentaires dans la mémoire de session.
La requête 2 traite les jetons d'entrée et de sortie de la requête en cours, mais inclut également les jetons d'entrée de la mémoire de session, qui sont constitués des jetons d'entrée de la requête précédente (requête 1) de la mémoire de session. Le taux d'épuisement des jetons dans la mémoire de session est le même que celui des jetons d'entrée standards (1 jeton de mémoire de session d'entrée = 1 jeton d'entrée).
Si le traitement de la requête 2 a pris exactement une seconde après son envoi, vos jetons sont traités et appliqués à votre quota de débit provisionné comme suit :
Multipliez vos entrées par les taux d'épuisement pour obtenir le nombre total de jetons d'entrée :
2 830 x (1 jeton par jeton de mémoire de session) + 1 000 x (1 jeton par jeton de texte d'entrée) = 3 830 jetons d'entrée ajustés par épuisement par requête
Multipliez vos sorties par les taux d'épuisement pour obtenir le nombre total de jetons de sortie :
200 x (24 jetons par jeton de sortie audio) = 4 800 jetons
Ajoutez ces deux totaux pour obtenir le nombre total de jetons traités :
3 830 jetons + 4 800 jetons = 8 630 jetons