Chaque article « Whisper vs Deepgram » que vous lirez est écrit par quelqu'un qui vend l'un des deux. La comparaison de Deepgram s'ouvre sur « plus de 90 % de précision en 300 ms ». C'est vrai, et c'est hors sujet. Si vous branchez la reconnaissance vocale sur un agent vocal temps réel qui répond au téléphone, la précision sur un extrait de podcast propre n'est pas le chiffre qui décide si votre agent paraît humain ou paraît cassé.
Chez Finn, nous construisons des agents vocaux pour centres de contact. Nous avons mis les deux moteurs en production. Voici la version neutre : celle ancrée dans de l'audio téléphonique 8 kHz, un vrai budget de latence et la facture d'exploitation que personne ne chiffre.
La vraie décision : le STT en streaming est un budget de latence, pas un classement de précision
Un agent vocal a une contrainte dure : la personne au téléphone attend une réponse dans à peu près le même tempo qu'un humain, disons 800 ms à 1,2 s à partir du moment où elle cesse de parler. Cet aller-retour total doit couvrir la finalisation du STT, l'inférence du LLM, le premier octet du TTS et le transport réseau/SIP. Le STT n'obtient pas tout le budget. Il en obtient peut-être 300 ms.
La question n'est donc pas « quel moteur a le taux d'erreur sur les mots le plus bas ». C'est « quel moteur me donne des transcriptions exploitables assez vite pour que les trois autres étapes tiennent encore ». Un modèle 2 % plus précis mais qui ajoute 400 ms de latence de finalisation est un moins bon moteur pour agent vocal, point final. Les benchmarks de précision en batch mesurent le mauvais axe pour ce travail.
Protocole de benchmark : audio de qualité téléphonique, WER et pourquoi les scores sur audio propre mentent
La plupart des chiffres de WER publiés viennent de LibriSpeech ou d'équivalents : parole lue, 16 kHz, propreté de studio. Les appels téléphoniques, c'est l'inverse : bande étroite 8 kHz (ou G.711 μ-law), artefacts de codec, bruit de fond, chevauchement de paroles, accents, et des appelants qui marmonnent leur numéro de compte.
Quand vous relancez les mêmes modèles sur de l'audio téléphonique, l'écart bouge :
- Whisper large-v3 sur du 16 kHz propre : ~5-8 % de WER. Sur du téléphonique bruité en 8 kHz : souvent 12-18 % de WER, et il hallucine du texte fluide mais faux sur le silence et le bruit — un mode de défaillance connu, dangereux quand la transcription alimente un LLM.
- Deepgram Nova-2/Nova-3, réglé pour l'audio téléphonique et le streaming : 8-13 % de WER sur le même jeu téléphonique, et la dégradation est plus douce — il a tendance à perdre des mots plutôt qu'à en inventer.
La leçon : faites le benchmark sur votre propre audio. Prenez 200 vrais appels enregistrés, annotez-les à la main et notez les deux moteurs sur ça. Le classement obtenu ne correspondra à aucun blog d'éditeur, y compris celui-ci. Si vous ne retenez qu'une chose, retenez celle-là.
Latence et endpointing : premier token, finalisation et barge-in
Trois chiffres de latence comptent, et un seul apparaît dans le marketing.
Latence du premier token — à quelle vitesse les transcriptions partielles commencent à revenir en streaming. Deepgram diffuse des résultats intermédiaires en ~100-200 ms. Whisper est un modèle batch ; les wrappers de streaming communautaires (whisper-streaming, WhisperLive) découpent l'audio et redécodent, ce qui veut dire que les partiels arrivent en 500 ms-1 s et plus, avec de la gigue sous charge.
Latence de finalisation — le temps qui s'écoule, après que l'appelant a cessé de parler, avant d'obtenir une transcription finale stable à passer au LLM. C'est piloté par l'endpointing (la détection d'activité vocale qui décide que le tour de parole est terminé). Deepgram fournit un endpointing réglable (endpointing=300). Avec Whisper, vous greffez votre propre VAD (Silero, WebRTC VAD) et vous le réglez vous-même — plus de contrôle, plus de corde pour vous pendre.
Barge-in — quand l'appelant coupe l'agent en pleine phrase, il faut détecter la parole et tuer le TTS en ~100-200 ms, sinon l'agent parle par-dessus lui. C'est un problème de partiels en streaming + VAD. Les moteurs à streaming natif rendent ça facile ; Whisper en batch en fait un projet.
Le réglage de l'endpointing est le levier de latence le plus rentable de toute la pile — trop agressif et vous coupez l'appelant au milieu d'un mot ; trop lâche et vous ajoutez 500 ms de blanc à chaque tour. Voyez notre démontage des moteurs vocaux à faible latence pour situer ça dans le pipeline.
Whisper auto-hébergé : coût GPU, batching et la charge d'exploitation que personne ne chiffre
« Whisper est gratuit » est la phrase la plus coûteuse de l'IA vocale. Les poids du modèle sont gratuits. Les faire tourner en temps réel à la concurrence d'un centre d'appels ne l'est pas.
Chiffres réels pour un déploiement auto-hébergé de faster-whisper (CTranslate2) large-v3 :
- GPU : une A10G ou une L4 encaisse environ 8-15 flux temps réel simultanés en large-v3 avant que la latence ne se dégrade. À 100 appels simultanés, il vous faut ~8-12 GPU. Une A10G cloud à la demande coûte ~$1.00-1.30/hr ; en réservé, c'est moins. Comptez $7,000-10,000/month de GPU pour tenir 100 flux simultanés, avant redondance.
- Compromis du batching : le batching augmente le débit par GPU mais ajoute de la latence — exactement ce que vous protégez. La voix temps réel plafonne le batching possible, donc votre taux d'utilisation GPU reste bas (souvent 30-50 %), et c'est de l'argent qui brûle.
- Charge d'exploitation : chargement du modèle, pools chauds pour éviter le démarrage à froid, autoscaling sur un trafic entrant en rafales, réglage du VAD, filtrage des hallucinations, maintenance des pilotes GPU/CUDA et astreinte 24/7 quand un nœud se bloque en plein appel. C'est 0,5-1 ETP d'ingénierie plateforme qui n'apparaît jamais dans une comparaison à la minute.
Amorti, Whisper auto-hébergé à 100 appels simultanés atterrit souvent autour de $0.006-0.012/min tout compris — compétitif sur le papier, mais seulement une fois payée l'ingénierie qui le rend fiable. En dessous d'un volume sérieux, ça n'en vaut presque jamais la peine. Notre pipeline ASR hybride sous 120 ms détaille en profondeur l'arbitrage batching/latence.
Deepgram / API managées : coût à la minute à l'échelle et routage régional
Le STT managé inverse l'arbitrage : coût marginal plus élevé, exploitation quasi nulle.
- Deepgram Nova en streaming est affiché autour de $0.0077/min (Nova au paiement à l'usage, streaming), avec des remises au volume ou à l'engagement qui font baisser ça à l'échelle.
- Pas de GPU, pas de pools chauds, pas de CUDA. Vous obtenez autoscaling, endpointing et streaming sans effort.
- Le routage régional compte plus que le prix affiché. Si votre média se termine à Bombay et que votre endpoint STT est en us-east, vous venez d'ajouter 200-300 ms d'aller-retour transatlantique à chaque partiel. Les éditeurs managés avec des endpoints régionaux (ou des déploiements entreprise auto-hébergés près de votre plan média) effacent ça. Pour les piles bi-marché États-Unis-Inde, c'est décisif — voyez notre architecture de latence transfrontalière.
La lecture honnête : pour la plupart des équipes sous ~50 appels simultanés, le managé gagne en coût total dès que vous chiffrez l'ingénieur. Au-delà, les calculs commencent à favoriser l'auto-hébergement — si vous avez l'équipe plateforme.
Comment le choix du STT se répercute sur la latence aller-retour totale
Voici un budget de tour de parole représentatif pour un appel entrant, cible < 1000ms de réponse perçue :
| Étape | Managé (Deepgram) | Whisper auto-hébergé (naïf) |
|---|---|---|
| Transport SIP/média | 80ms | 80ms |
| Finalisation STT (après endpoint) | 250ms | 700ms |
| Premier token du LLM | 350ms | 350ms |
| Premier octet du TTS | 150ms | 150ms |
| Réponse perçue | ~830ms | ~1280ms |
Même LLM, même TTS. Le seul choix du STT fait basculer l'expérience de l'appelant de part et d'autre de la ligne du « paraît humain ». Ces 450 ms font la différence entre un agent à qui les gens parlent et un agent à qui ils raccrochent au nez. La latence STT n'est pas une ligne de coût — c'est un multiplicateur sur tout ce qui suit. C'est pour ça que nous la traitons comme un budget, pas comme un benchmark. Plus sur le pipeline complet dans au-delà du wrapper.
Matrice de décision : choisissez selon le volume d'appels, le mix linguistique et le SLA de latence
- < 50 simultanés, forte dominante anglaise, SLA serré → Managé (Deepgram ou équivalent). Vous ne battrez pas le coût ajusté à l'effort, et le streaming/endpointing est déjà résolu.
- Gros volume (100+ simultanés), trafic stable, équipe plateforme en interne → Whisper auto-hébergé (faster-whisper) commence à gagner sur le coût marginal. Budgétez l'ETP honnêtement.
- Multilingue intensif / alternance codique → Testez les deux sur vos langues. L'étendue multilingue de Whisper est solide mais le WER varie énormément selon la langue ; les moteurs managés varient aussi. Ne supposez pas — mesurez. Voyez la taxe multilingue cachée.
- Réglementé / résidence des données (santé, DLT indien, UE) → Auto-hébergé ou déploiement managé régional, choisi selon l'endroit où votre média doit légalement rester.
- Sensible aux hallucinations (la transcription alimente un LLM qui agit dessus) → Pesez l'hallucination sur silence de Whisper face à la dégradation en douceur de Deepgram, et ajoutez des garde-fous dans tous les cas. Notre manuel pour stopper les hallucinations de l'IA vocale s'applique directement.
L'essentiel
Whisper vs Deepgram n'est pas un concours de précision — c'est une décision de budget de latence et de charge d'exploitation. Le managé gagne sur l'effort et le délai de mise en production ; Whisper auto-hébergé gagne sur le coût marginal uniquement à vraie échelle et uniquement avec une équipe plateforme derrière. Dans les deux cas : faites le benchmark sur votre propre audio téléphonique, réglez l'endpointing sérieusement et comptabilisez l'aller-retour complet. La transcription n'est que les 300 premières millisecondes d'une promesse d'une seconde faite à l'appelant.
FAQ
Whisper est-il plus précis que Deepgram en 2025 ? Sur de l'audio 16 kHz propre, Whisper large-v3 est très solide. Sur du téléphonique bruité en 8 kHz — l'audio qu'un agent vocal entend réellement — l'écart se resserre ou s'inverse, et l'hallucination sur silence de Whisper est un vrai risque. Faites le benchmark sur vos propres appels enregistrés avant de décider.
Combien coûte réellement l'auto-hébergement de Whisper ?
Pas gratuit. À 100 flux temps réel simultanés, comptez 8-12 GPU ($7-10k/month) plus 0,5-1 ETP d'ingénierie plateforme. Tout compris, ça atterrit autour de $0.006-0.012/min — compétitif face au managé seulement à l'échelle.
Whisper peut-il faire du streaming temps réel ? Pas nativement — c'est un modèle batch. Les wrappers communautaires (WhisperLive, faster-whisper + VAD) ajoutent le streaming, mais la latence du premier token (500 ms-1 s et plus) et la gigue sont pires que celles des API à streaming natif. Le barge-in et l'endpointing deviennent votre chantier.
Lequel est meilleur pour un agent vocal de centre de contact ? Pour la plupart des équipes sous ~50 appels simultanés, une API managée en streaming (Deepgram ou équivalent) avec endpointing réglé et endpoint régional. Au-delà, avec une équipe plateforme, Whisper auto-hébergé commence à gagner sur le coût. C'est le SLA, pas le WER, qui doit trancher.
Construisez un agent vocal qui tient le budget de latence
Finn livre des agents vocaux de centre de contact en production, avec le STT, l'endpointing et le routage régional déjà réglés pour l'aller-retour sous la seconde — vous vous épargnez ainsi les calculs de GPU et le bip à 3 h du matin. Découvrez comment Finn maintient les agents vocaux sous la ligne de latence →
À lire aussi : Déploiement d'agents IA : faire tourner des agents vocaux de façon fiable
À lire aussi : Suivi des appels pour agents vocaux IA : de l'attribution au chiffre d'affaires




