Optimisation des coûts

Utilisation et coûts de GPT-Live

GPT-Live sépare la conversation vocale du backend qui raisonne et exécute les outils. Estimez ces deux coûts séparément : le coût de la session vocale dépend de sa durée, tandis que les coûts du backend dépendent des modèles et des outils que vous utilisez.

Coûts des sessions vocales

Les sessions vocales GPT-Live sont facturées à la seconde au tarif actuel du modèle. La durée de la session n’est pas arrondie à la minute supérieure.

La durée d’activité de la session comprend les moments où l’utilisateur parle, où l’assistant parle, où les deux restent silencieux, ou encore où le backend travaille.

Pour vos estimations, comptez toute la durée d’activité de la session, du démarrage à la fermeture. Utilisez la durée indiquée par l’API au lieu de chronométrer uniquement l’audio que vous diffusez. Couper le microphone ne ferme pas la session. Une fois la conversation terminée, fermez la session et récupérez ses données d’utilisation finales.

Consultez les tarifs de l’API pour connaître les prix des modèles et des outils utilisés par le backend.

Frais d’initialisation WebRTC

Une requête POST /v1/live/sessions visant à créer une session WebRTC entraîne la facturation de 15 secondes de durée vocale pendant l’initialisation de la session. Ce montant est déduit des frais liés à la durée dès que la session démarre. N’ajoutez pas 15 secondes supplémentaires à la durée de la session en cours lorsque vous estimez son coût.

Par exemple, la session de 90 secondes ci-dessous inclut déjà les 15 secondes facturées à l’initialisation. Elle n’est pas facturée comme une session de 105 secondes. Tenez compte des frais de création de session lorsque vous évaluez les reconnexions ou les applications qui créent des sessions avant que l’utilisateur soit prêt à parler.

Coûts du backend

Les appels du backend sont facturés séparément de la session vocale, comme dans les applications sans fonctionnalités vocales. Incluez les tokens d’entrée et de sortie du modèle, les entrées mises en cache lorsqu’elles sont prises en charge, ainsi que les éventuels frais liés aux images ou aux outils. Si votre application fait appel à d’autres services, incluez également leurs coûts dans votre estimation.

Vous pouvez optimiser ces traitements indépendamment du frontend vocal. Consultez le guide général d’optimisation des coûts pour réduire le nombre de requêtes et l’utilisation de tokens. Utilisez la mise en cache des prompts pour les modèles backend compatibles en plaçant les instructions réutilisables, les définitions d’outils et les autres contenus stables au début du prompt.

Les choix concernant le backend peuvent aussi modifier la durée de la conversation. Comparez le coût total lorsqu’une optimisation allonge l’attente de l’utilisateur ou modifie la fiabilité avec laquelle l’assistant accomplit la tâche.

Estimez les coûts d’une conversation

Pour une conversation comportant une seule session vocale :

Coût total = (secondes vocales facturables ÷ 60 × tarif vocal par minute) + coûts du backend

Par exemple, avec un tarif vocal indicatif de 0,05 $ par minute, une session vocale de 90 secondes coûte 0,075 $. Si les coûts des modèles et des outils du backend s’élèvent à 0,02 $, la conversation coûte 0,095 $ :

Les tarifs et le coût du backend ci-dessus sont des exemples ; utilisez le tarif vocal actuel, l’utilisation mesurée de votre backend et les tarifs applicables aux modèles et aux outils. Si la tâche s’étend sur plusieurs sessions vocales, additionnez leurs durées et incluez les traitements effectués par le backend entre les sessions.

Stratégies d’optimisation

Cherchez avant tout à aider l’utilisateur à accomplir sa tâche en réduisant les échanges et l’attente inutiles. Conservez les confirmations et les vérifications nécessaires à la tâche.

Fournissez le contexte pertinent avant la session

Rassemblez les informations que votre application est déjà autorisée à utiliser avant de démarrer la session vocale. Par exemple, un assistant qui aide à gérer une commande peut disposer dès le départ du numéro de commande et de son état actuel, pour éviter à l’utilisateur de les répéter ou d’attendre une nouvelle recherche.

Gardez ce contexte à jour et centré sur la tâche. Fournissez au modèle vocal les informations nécessaires à la conversation ; conservez les données détaillées et les workflows dans le backend. Consultez la configuration des sessions et la section Délégation et outils.

Réduisez le temps d’attente des outils

Des temps d’attente plus courts peuvent améliorer l’expérience utilisateur et réduire le coût des sessions vocales. Supposons, par exemple, que votre backend utilise gpt-5.6-luna avec le mode Rapide et exécute les appels d’outils indépendants en parallèle. Si ces optimisations permettent à l’utilisateur de terminer sa tâche et de fermer la session vocale une minute plus tôt, vous économisez 0,05 $ de frais vocaux. Le coût total diminue si le surcoût du backend est inférieur à cette économie.

Vous pouvez également lancer une recherche spéculative à partir de fragments de transcription avant l’arrivée d’un événement de délégation. Incluez les traitements spéculatifs inutilisés dans vos mesures des coûts du backend.

Consultez Réduisez la latence du backend pour optimiser les modèles, les connexions, la diffusion en continu et les outils. Vérifiez le délai d’obtention d’une réponse vocale utile et la réussite des tâches à l’aide d’évaluations d’agents vocaux.

Fermez la session pendant les tâches longues

Le frontend vocal et le backend géré par votre application peuvent fonctionner indépendamment. Avec la délégation côté client, le processus de traitement de votre backend peut continuer à s’exécuter, que la session vocale soit ouverte ou fermée. Enregistrez l’état de la tâche et le contexte de la conversation avant de fermer la session vocale.

Pour un agent ambiant, fermez la session vocale pendant que le backend exécute une tâche de longue durée, comme la programmation en mode objectif. Proposez un bouton intitulé Reprendre la conversation pour démarrer une nouvelle session vocale au retour de l’utilisateur, ou utilisez un événement de fin de traitement du backend pour démarrer une nouvelle session et avertir l’utilisateur que le résultat est prêt.

Rétablissez la conversation en démarrant une nouvelle session avec le contexte enregistré et le résultat vérifié de la tâche dans input. Par exemple, envoyez cet événement de démarrage via une nouvelle connexion WebSocket :

1234567891011121314151617181920{
  "type": "session.start",
  "session": {
    "model": "gpt-live-1",
    "instructions": "Help the user review completed work and delegate follow-up tasks.",
    "input": [
      {
        "type": "message",
        "role": "developer",
        "content": [
          {
            "type": "input_text",
            "text": "Saved task: add CSV export. Result: code is ready for review."
          }
        ]
      }
    ],
    "delegation": { "type": "client" }
  }
}

Attendez session.started avant de diffuser l’audio en continu. Consultez Initialisez une session avec une conversation antérieure pour connaître le format d’historique pris en charge.

Si la session précédente a été enregistrée avec store: true, vous pouvez également forker cette session. Quelle que soit l’approche choisie, conservez dans votre application l’état vérifié de la tâche exécutée par le backend.

Fermer la session permet d’économiser 0,05 $ par minute d’inactivité vocale ; comparez cette économie aux coûts de reconnexion et à l’interruption de l’expérience utilisateur.

Choisissez le bon modèle pour le backend

Commencez par les modèles qui répondent aux exigences de précision et de fiabilité de la tâche. Comparez ensuite le coût total de la conversation, en incluant la durée vocale, l’utilisation des modèles, les appels d’outils et les nouvelles tentatives. Le guide de sélection du modèle explique comment trouver un équilibre entre ces critères.

Un modèle backend plus grand peut coûter moins cher au total s’il accomplit la tâche plus rapidement et si les économies sur la session vocale dépassent le surcoût de ses tokens. Un modèle moins cher peut coûter davantage au total s’il prend plus de temps, répète des appels d’outils ou échoue à accomplir la tâche.

Comparez le coût par tâche réussie, ainsi que le taux d’achèvement et le temps nécessaire pour terminer les tâches. Incluez les tentatives échouées et les nouvelles tentatives dans le total, afin qu’une configuration moins chère ne paraisse pas meilleure simplement parce qu’elle accomplit moins de travail. Utilisez le Cookbook sur l’évaluation des agents vocaux pour préparer votre comparaison.

Suivez l’utilisation réelle

Enregistrez séparément la durée vocale et l’utilisation du backend pour chaque session. GPT-Live indique la durée vocale cumulée en secondes :

123456{
  "type": "session.usage.updated",
  "event_id": "event_usage_1",
  "usage": { "seconds": 12 },
  "context_window": { "usage_ratio": 0.42 }
}

Chaque mise à jour remplace la valeur de durée précédente. N’additionnez pas ces valeurs. Après l’envoi de session.close, continuez à recevoir les événements jusqu’à session.closed et enregistrez une seule fois sa valeur finale de usage.seconds. Suivez la procédure de fermeture propre pour que votre application puisse récupérer les données d’utilisation finales avant de se déconnecter.

Pour la délégation à Responses, récupérez la valeur usage de la réponse du backend dans les événements imbriqués response.completed transmis via response.event. Comptabilisez chaque réponse du backend une seule fois, à l’aide de son identifiant de réponse, et conservez les détails des tokens d’entrée, de sortie et mis en cache nécessaires pour appliquer les tarifs de ce modèle. Pour les traitements du backend que votre application exécute indépendamment, récupérez également les données d’utilisation de ces requêtes.

Comparez les totaux estimés et réels sur des conversations représentatives. Distinguez les appels de modèles réservés à l’évaluation de l’utilisation par l’application, et examinez le coût en tenant compte de la réussite des tâches.

Coûts de Realtime API

Ce document explique la facturation de Realtime API et présente des stratégies pour optimiser les coûts. Les sessions d’agents vocaux consomment des tokens d’entrée et de sortie pour les modalités texte, audio et image. Les sessions de traduction et de transcription en continu sont facturées selon la durée de l’audio. Les tarifs varient selon le modèle et sont indiqués sur les pages correspondantes (par exemple, gpt-realtime-2, gpt-realtime-translate, gpt-realtime-whisper et gpt-realtime).

Les sessions conversationnelles de Realtime API se composent d’une série de tours : l’utilisateur ajoute une entrée qui déclenche une Response pour produire la sortie du modèle. Le serveur maintient une Conversation, une liste d’Items qui constituent l’entrée du tour suivant. Lorsqu’une Response est renvoyée, sa sortie est automatiquement ajoutée à la Conversation.

Les sessions de traduction et de transcription utilisent une architecture de diffusion en continu différente. Le client envoie l’audio en continu et reçoit de l’audio traduit, des mises à jour incrémentales de la transcription ou des événements de transcription à mesure que l’audio source arrive. Ces sessions ne suivent pas le cycle de vie habituel d’une Response. Estimez et suivez donc leurs coûts à l’aide des tarifs fondés sur la durée, plutôt qu’en fonction des tokens consommés par Response.

Coûts par Response

Realtime API génère des frais à la création d’une Response, en fonction du nombre de tokens d’entrée et de sortie (à l’exception des frais de transcription de l’entrée, voir ci-dessous). La bande passante réseau et les connexions ne sont actuellement pas facturées. Une Response peut être créée manuellement ou automatiquement si la détection de l’activité vocale (VAD) est activée. La VAD filtre les passages audio vides en entrée : ils ne sont donc pas comptabilisés comme tokens d’entrée, sauf si le client les ajoute manuellement à la conversation.

L’intégralité de la conversation est envoyée au modèle pour chaque Response. La sortie d’un tour est ajoutée sous forme d’Items à la Conversation sur le serveur et devient une partie de l’entrée des tours suivants. Les tours coûtent donc plus cher à mesure que la session avance.

Vous pouvez estimer les coûts des tokens de texte à l’aide de nos outils de tokenisation. Les messages utilisateur comptent 1 token audio pour 100 ms d’audio, contre 1 token pour 50 ms d’audio dans les messages de l’assistant. Le décompte comprend aussi des tokens spéciaux en plus du contenu du message, ce qui entraîne de légères variations. Par exemple, un message utilisateur dont le contenu représente 10 tokens de texte peut être comptabilisé comme 12 tokens.

Exemple

Voici un exemple simple pour illustrer les coûts des tokens au cours d’une session Realtime API comportant plusieurs tours.

Pour le premier tour de la conversation, nous avons ajouté 100 tokens d’instructions et un message utilisateur de 20 tokens audio (par exemple, ajouté par la VAD lorsque l’utilisateur parle), soit un total de 120 tokens d’entrée. La création d’une Response génère un message de sortie de l’assistant (20 tokens audio et 10 tokens de texte).

Nous créons ensuite un deuxième tour avec un autre message audio de l’utilisateur. Comment se répartissent les tokens du tour 2 ? À ce stade, la Conversation comprend les instructions initiales, le premier message utilisateur, le message de sortie de l’assistant du premier tour et le deuxième message utilisateur (25 tokens audio). Ce tour compte 110 tokens de texte et 64 tokens audio en entrée, auxquels s’ajoutent les tokens de sortie d’un nouveau message de l’assistant.

Les messages du premier tour seront probablement en cache pour le tour 2, ce qui réduit le coût de l’entrée. Consultez la section ci-dessous pour en savoir plus sur la mise en cache.

Le nombre de tokens utilisés pour une Response est indiqué dans l’événement response.done, qui se présente comme suit.

1234567891011121314151617181920212223242526{
  "type": "response.done",
  "response": {
    ...
    "usage": {
      "total_tokens": 253,
      "input_tokens": 132,
      "output_tokens": 121,
      "input_token_details": {
        "text_tokens": 119,
        "audio_tokens": 13,
        "image_tokens": 0,
        "cached_tokens": 64,
        "cached_tokens_details": {
          "text_tokens": 64,
          "audio_tokens": 0,
          "image_tokens": 0
        }
      },
      "output_token_details": {
        "text_tokens": 30,
        "audio_tokens": 91
      }
    }
  }
}

Coûts de transcription de l’entrée

En plus des Responses conversationnelles, Realtime API facture les transcriptions de l’entrée si elles sont activées. La transcription de l’entrée utilise un modèle différent du modèle speech2speech, comme whisper-1 ou gpt-4o-transcribe, et relève donc d’une autre grille tarifaire. La transcription a lieu lorsque l’audio est écrit dans le tampon audio d’entrée, puis validé, soit manuellement, soit par la VAD.

Le nombre de tokens de transcription de l’entrée est indiqué dans l’événement conversation.item.input_audio_transcription.completed, comme dans l’exemple suivant.

123456789101112131415{
  "type": "conversation.item.input_audio_transcription.completed",
  ...
  "transcript": "Hi, can you hear me?",
  "usage": {
    "type": "tokens",
    "total_tokens": 26,
    "input_tokens": 17,
    "input_token_details": {
      "text_tokens": 0,
      "audio_tokens": 17
    },
    "output_tokens": 9
  }
}

Mise en cache

Realtime API prend en charge la mise en cache des prompts. Elle s’applique automatiquement et peut réduire considérablement les coûts des tokens d’entrée lors des sessions comportant plusieurs tours. La mise en cache s’applique lorsque les tokens d’entrée d’une Response correspondent à ceux d’une Response précédente, dans la mesure du possible et sans garantie.

Pour maximiser le taux d’utilisation du cache, la meilleure stratégie consiste à conserver l’historique de la session sans le modifier. Supprimer ou modifier du contenu dans la conversation invalide le cache jusqu’au point de modification : l’entrée ne correspond plus autant qu’auparavant au contenu en cache. Les instructions et les définitions d’outils se trouvent au début de la conversation. Les modifier en cours de session réduit donc le taux d’utilisation du cache pour les tours suivants.

Troncature

Lorsque le nombre de tokens d’une conversation dépasse la limite de tokens d’entrée du modèle, la conversation est tronquée : des messages sont retirés de l’entrée de la Response, en commençant par les plus anciens. Un modèle doté d’une fenêtre de contexte de 32k et limité à 4 096 tokens de sortie ne peut inclure que 28 224 tokens dans le contexte avant qu’une troncature ait lieu.

Les clients peuvent définir une fenêtre de tokens inférieure au maximum du modèle, ce qui permet de maîtriser la consommation de tokens et les coûts. Utilisez pour cela le paramètre token_limits.post_instructions (si vous configurez la troncature avec le type retention_ratio, comme illustré ci-dessous). Comme son nom l’indique, ce paramètre fixe le nombre maximal de tokens d’entrée d’une Response, hors tokens d’instructions. Si vous définissez post_instructions sur 1 000, les éléments qui dépassent la limite de 1 000 tokens d’entrée ne sont pas envoyés au modèle pour la Response.

La troncature invalide le cache près du début de la conversation. Si elle a lieu à chaque tour, le taux d’utilisation du cache sera donc très faible. Pour atténuer ce problème, les clients peuvent configurer la troncature pour qu’elle retire plus de messages que nécessaire, ce qui laisse davantage de marge avant la prochaine troncature. Utilisez pour cela le paramètre session.truncation.retention_ratio. Par défaut, le serveur utilise la valeur 1.0, ce qui signifie que la troncature ne retire que les éléments nécessaires. Avec la valeur 0.8, une troncature conserve 80 % du maximum et retire donc 20 % supplémentaires.

Pour réduire le coût par session de Realtime API pour un modèle donné, nous vous recommandons de limiter le nombre de tokens et de définir retention_ratio sur une valeur inférieure à 1, comme dans l’exemple suivant. Gardez à l’esprit que cette réduction des coûts peut s’accompagner d’une diminution des informations que le modèle garde en mémoire pour un tour donné.

123456789101112{
  "event": "session.update",
  "session": {
    "truncation": {
      "type": "retention_ratio",
      "retention_ratio": 0.8,
      "token_limits": {
        "post_instructions": 8000
      }
    }
  }
}

Vous pouvez aussi désactiver complètement la troncature, comme illustré ci-dessous. Dans ce cas, une erreur est renvoyée si la Conversation est trop longue pour créer une Response. Cette option peut être utile si vous souhaitez gérer manuellement la taille de la Conversation.

123456{
  "event": "session.update",
  "session": {
    "truncation": "disabled"
  }
}

Autres stratégies d’optimisation

Utilisation d’un modèle mini

Les modèles Realtime speech2speech existent en taille « normale » et en taille mini, nettement moins chère. Le compromis porte généralement sur les capacités de suivi des instructions et d’appel de fonction, moins performantes avec le modèle mini. Nous vous recommandons de tester d’abord les applications avec le modèle le plus grand, d’affiner votre application et votre prompt, puis de tenter une optimisation avec le modèle mini.

Modification de la Conversation

La troncature s’effectue automatiquement sur le serveur, mais vous pouvez aussi maîtriser les coûts en modifiant manuellement la Conversation. L’un des principes de l’API est de donner au client le contrôle complet de la Conversation côté serveur, afin qu’il puisse ajouter et supprimer des éléments à sa guise.

1234{
  "type": "conversation.item.delete",
  "item_id": "item_CCXLecNJVIVR2HUy3ABLj"
}

Supprimer les anciens messages permet de réduire le nombre de tokens d’entrée et les coûts. Cela risque de retirer du contenu important ; une stratégie courante consiste donc à remplacer ces anciens messages par un résumé. Vous pouvez supprimer des Items de la Conversation avec un message conversation.item.delete, comme ci-dessus, et en ajouter avec un message conversation.item.create.

Estimation des coûts

La complexité de la consommation de tokens dans Realtime API peut rendre difficile l’estimation des coûts à l’avance. Une bonne approche consiste à utiliser le Realtime Playground avec les prompts et les fonctions prévus, puis à mesurer la consommation de tokens sur une session représentative. Vous trouverez la consommation de tokens d’une session dans l’onglet Journaux du Realtime Playground, à côté de l’identifiant de la session.