gpt-4o-realtime-preview est le modèle vocal en streaming pleine capacité d'OpenAI. Audio bidirectionnel sur connexion WebSocket. Gestion des tours de parole, gestion des interruptions, latence inférieure à la seconde entre la fin de la parole de l'utilisateur et le début de la réponse. Le modèle qui vous permet de construire des agents vocaux qui donnent l'impression d'un appel téléphonique plutôt qu'un relais transcrire-puis-réfléchir-puis-parler.
Il s'agit de la variante pleine capacité. La version mini-realtime est l'option économique pour les charges de travail où la marge de raisonnement n'est pas le facteur limitant.
Ce qu'exige réellement la voix en streaming
Construire un agent vocal qui ne semble pas cassé nécessite plus qu'un moteur TTS rapide collé à un moteur STT rapide. La preview realtime intègre les éléments dont le travail vocal en mode difficile a besoin :
- Le modèle commence le traitement avant que l'utilisateur ait fini de parler. Au moment où l'utilisateur cesse de parler, la réponse est déjà en formation.
- L'utilisateur peut interrompre le modèle en pleine réponse et le modèle gère cela avec élégance — il s'arrête, écoute, traite la nouvelle entrée, répond.
- Les silences et les sons de rétroaction conversationnelle (« mm-hmm », brèves pauses) sont interprétés comme des signaux conversationnels plutôt que des limites de tour de parole.
- La latence de bout en bout entre l'utilisateur-cesse-de-parler et le modèle-commence-à-parler est bien en dessous du seuil où un appel téléphonique semble retardé.
La preview Realtime est la réponse architecturale à cet ensemble d'exigences. La variante pleine capacité possède la capacité de raisonnement nécessaire pour gérer des agents vocaux qui doivent réfléchir attentivement à ce qui a été dit, pas seulement y réagir.
Où la version pleine capacité justifie son coût
Charges de travail où mini-realtime n'est pas adapté et où la capacité de raisonnement pleine capacité fait la différence.
Agents vocaux de service client complexes qui doivent gérer des interactions en plusieurs étapes — collecter des informations, consulter l'état du compte, raisonner sur des cas limites, répondre avec le bon niveau de détail. Mini-realtime peut router et classifier ; la version pleine capacité peut réellement mener la conversation.
Travail de connaissance piloté par la voix où l'utilisateur demande au modèle de penser à voix haute — conversations de diagnostic, accompagnements de dépannage, scénarios de coaching. La version pleine capacité peut maintenir le contexte sur des tours plus longs et raisonner sur des déclarations ambiguës de l'utilisateur.
Agents vocaux multilingues où le modèle doit changer de langue en cours de conversation et maintenir la qualité de raisonnement au fil du changement. Mini-realtime gère la couverture linguistique ; la version pleine capacité gère la qualité du raisonnement interlangues.
Interfaces vocales critiques où la qualité de sortie compte plus que le coût par minute — produits d'accessibilité dans des domaines critiques, assistants de consultation professionnelle, scénarios où une mauvaise réponse coûte beaucoup plus cher que le tarif par minute d'un modèle plus capable.
Notes architecturales
Architecture de la famille GPT-4o « omni », dimensionnement pleine capacité, acheminé via un transport WebSocket plutôt que l'API Chat Completions en requête/réponse.
La couche de streaming ajoute de la complexité opérationnelle :
- Une connexion persistante par conversation active.
- Sémantique d'événements pilotée par le serveur avec des événements explicites de début-de-tour, fin-de-tour, modèle-réfléchit, audio-en-flux.
- Une histoire d'intégration client plus complexe que le REST standard.
- Gestion de session avec état côté client et serveur.
OpenAI n'a pas publié les nombres de paramètres pleine capacité. Comportement observable : mêmes formats audio d'entrée que mini-realtime, mêmes options de voix prédéfinies fixes, plafond de raisonnement effectif plus large que la variante mini.
Où ça échoue
Charges de travail qui n'ont pas réellement besoin de streaming. Utilisez la ligne audio-preview — elle est plus simple à intégrer et moins chère par minute. Choisissez realtime pour l'exigence de streaming, pas pour la marque de la famille de modèles.
Déploiements sensibles aux coûts à volume élevé. La variante mini-realtime existe précisément pour les cas où l'économie par minute pleine capacité ne survit pas au volume.
Transcription pure. Les endpoints de transcription coûtent moins cher par minute pour texte-sorti-d'audio-entré.
Déploiement auto-hébergé. Connexion WebSocket à l'infrastructure OpenAI requise. Voir /usecases/local pour les options sur site.
Stabilité contractuelle de niveau production. Marqué preview. Épinglez l'instantané daté pour la prévisibilité comportementale pendant que la ligne est encore en flux.
Environnements clients mobiles complexes. Le protocole WebSocket et le modèle d'événements avec état ajoutent un coût d'ingénierie que les équipes mobiles en particulier doivent budgétiser.
Quand l'utiliser
Choisissez gpt-4o-realtime-preview quand :
- Vous construisez un agent vocal en direct et la charge de raisonnement derrière la voix est suffisamment lourde pour que mini-realtime devienne le goulot d'étranglement.
- Le produit peut absorber la complexité opérationnelle de l'intégration WebSocket.
- La qualité vocale et la qualité de raisonnement ensemble justifient l'économie par minute.
Évitez-le quand :
- L'application n'a pas réellement besoin de streaming — utilisez la ligne audio-preview.
- Le coût est la contrainte opérationnelle — utilisez mini-realtime.
- Le déploiement doit être sur site.
- La charge de travail est transcription uniquement — utilisez les endpoints de transcription.
Alternatives à comparer
Mini-realtime quand le coût compte plus que la capacité de raisonnement. La ligne audio-preview quand le streaming n'est pas requis. Les endpoints transcribe et TTS quand une direction de la boucle audio constitue la tâche entière. L'enquête plus large sur les modèles vocaux sur /usecases/voice couvre les fournisseurs realtime concurrents.
Notes de déploiement
API WebSocket, matériellement différente du reste du catalogue OpenAI. Attendez-vous à un investissement d'ingénierie dans la machine à états côté client, particulièrement pour les clients mobiles et embarqués.
Facturation par minute pour l'audio entrant et l'audio sortant, plus facturation par jeton pour l'équivalent texte circulant dans le modèle. La surcharge de streaming est intégrée dans le tarif par minute. La planification de capacité ressemble davantage à « appels actifs simultanés » qu'à « requêtes par seconde ».
La lecture pragmatique. La preview Realtime est le bon modèle quand la voix en direct compte et que la capacité de raisonnement compte. C'est le mauvais modèle quand le streaming n'est pas réellement requis, ou quand le dimensionnement approprié au niveau de coût signifie choisir mini-realtime à la place. Testez-le contre vos scénarios vocaux réels sur /live-test.
Dernière revue technique : 2026-05-22 — Tokonomix.ai
