Comparatif des modèles Whisper pour les sous-titres : tiny, small, turbo et large-v3

Le plus gros modèle Whisper n’est pas automatiquement le meilleur pour les sous-titres. large-v3-turbo a environ moitié moins de paramètres que large-v3 et tourne environ huit fois plus vite ; sur des images ordinaires, l’écart dans le fichier de sous-titres final est assez faible pour que la vitesse tranche. Il existe aussi de vrais cas où un modèle plus petit produit une meilleure transcription qu’un plus gros.

Voici les chiffres, ce qu’ils signifient concrètement pour le sous-titrage, et les cas où un modèle paraît pire qu’il ne l’est réellement.

Les modèles, côte à côte

Les paramètres et la vitesse relative viennent de la fiche modèle Whisper d’OpenAI ; les tailles sont les totaux réels des versions CTranslate2 que Sablate télécharge, pas des estimations arrondies.

La ligne qui casse la logique, c’est turbo. Il a plus de paramètres que medium et tourne quand même environ quatre fois plus vite, ce que le nombre de paramètres seul ne laissait pas prévoir.

Pourquoi turbo change la recommandation

Turbo n’est pas un modèle plus petit entraîné de zéro. C’est large-v3 dont le décodeur a été élagué de 32 à 4 couches, puis affiné sur deux époques supplémentaires avec les mêmes données de transcription multilingue. Whisper passe le plus clair de son temps dans le décodeur, donc le réduire aussi radicalement offre un gain de vitesse très important, alors que l’encodeur — la partie qui écoute réellement — reste intact.

Deux réserves l’accompagnent, et les deux sont documentées par OpenAI, pas issues du folklore d’internet :

• Il a été affiné sans données de traduction. Turbo est un modèle de transcription. Si vous voulez la tâche de traduction voix-vers-anglais de Whisper, turbo n’est pas le bon outil ; transcrivez dans la langue source et traduisez le texte ensuite, ce qui est de toute façon le meilleur flux de travail.
• Certaines langues se dégradent plus que d’autres. Turbo suit large-v2 sur la plupart des langues, mais perd sensiblement plus en thaï et en cantonais. Si vous travaillez dans ces langues, testez avant de vous engager.

Pour tout le reste, turbo est le choix par défaut raisonnable pour les sous-titres : une qualité proche de large à une vitesse qui rend un enregistrement de deux heures gérable dans la pratique.

Le plus gros modèle donne-t-il les meilleurs sous-titres ?

Pas toujours, et l’exception vaut la peine d’être connue, car elle ressemble à un bug quand on la rencontre.

Nous avons mesuré cela sur un extrait turc de 101 secondes, sur une RTX 3060 Ti en float16, via le chemin de transcription de l’application elle-même. Classé selon la part de parole réellement captée par chaque modèle, medium arrive en tête. large-v3 a sauté des passages que medium avait correctement transcrits — les premiers mots de l’extrait et plusieurs courtes interjections n’apparaissaient tout simplement pas. Aucun des leviers habituels ne les a fait revenir : désactiver le filtre de détection d’activité vocale, relever le seuil de non-détection de parole, retirer le seuil de log-probabilité, figer la température. Retirer le seuil de log-probabilité a rendu les choses bien pires, faisant passer la transcription d’environ 1 110 caractères à 429.

Nous avons aussi testé ce conseil répété partout dans la communauté : utiliser large-v2 à la place de large-v3. Sur cet extrait, c’était le pire du lot : il a fait disparaître entièrement une plage continue de 30 secondes de parole, de 28,7 s à 58,7 s, produisant 106 mots là où medium en produisait 178.

Un seul extrait n’est pas un banc d’essai, et celui-ci était court, turc et conversationnel. Retenez la méthode plutôt que le classement : transcrivez le même fichier avec deux modèles, regardez ce qui manque plutôt que ce qui est mal orthographié, et choisissez celui qui a tout entendu. Dans des sous-titres, une omission coûte bien plus cher qu’une faute de frappe, car un spectateur peut lire au-delà d’un mot faux, mais ne peut pas lire une ligne qui n’existe pas.

Quand un bon modèle a l’air mauvais

Trois causes d’échec produisent des plaintes du type « le gros modèle est moins bon », alors qu’elles n’ont rien à voir avec le modèle.

1. Les égalités dans le minutage par mot cassent le découpage des lignes. Whisper fournit un minutage pour chaque mot, et des mots adjacents partagent fréquemment une limite exactement identique — dans l’extrait examiné, 172 des 177 écarts entre mots valaient exactement 0,000 seconde. Un découpage qui coupe une longue réplique au plus grand écart trouve alors tous les candidats à égalité, prend le premier, puis recommence récursivement — en détachant un mot à la fois. Le symptôme est une transcription réduite en miettes de sous-titres d’un seul mot, et cela s’aggrave avec le modèle qui produit le plus de mots. Corriger la règle de départage pour privilégier le point médian temporel a fait passer un extrait de 90 sous-titres (dont 78 d’un seul mot) à 28 sous-titres avec une seule ligne d’un mot. Le modèle, lui, n’a jamais changé.

2. Le modèle sélectionné n’est pas celui qui a réellement tourné. Les dépôts de modèles sont nommés différemment selon les registres de téléchargement et les bibliothèques d’inférence. Un modèle téléchargé et présent sur le disque sous un nom de dépôt, alors que le chargeur en cherche un autre, produit soit un repli silencieux vers un autre modèle, soit une erreur qui ressemble à un problème réseau — alors que 1,6 Go du bon modèle sont déjà là.

3. Une retranscription échouée laisse l’ancienne transcription à l’écran. Si une nouvelle tentative échoue et que l’application annule la tâche mais conserve le nom du modèle demandé, vous regardez alors la sortie du modèle précédent étiquetée comme la nouvelle. Toute comparaison faite dans cet état est fausse. Si vous comparez des modèles, vérifiez que le texte a réellement changé avant d’en tirer une conclusion — une sortie identique entre deux modèles différents est un signal d’alarme, pas un résultat.

VRAM, disque et ce que votre machine peut faire tourner

Les tailles de téléchargement du tableau ci-dessus sont aussi un bon indicateur de la pression sur la mémoire pendant la transcription. En pratique :

• 4 Go de VRAM ou moins, ou aucun GPU dédié — small est le point d’équilibre. tiny est fait pour un premier jet et pour vérifier le minutage, pas pour la livraison finale.
• 6 à 8 Go de VRAM — large-v3-turbo sans souci. C’est la configuration sur laquelle la plupart des gens devraient rester.
• 10 Go de VRAM ou plus — large-v3 si l’audio en a vraiment besoin : accents marqués, locuteurs qui se chevauchent, microphones de mauvaise qualité.
• CPU uniquement — small pour tout ce dont vous avez besoin aujourd’hui, turbo si vous pouvez le laisser tourner.

La précision compte ici presque autant que la taille du modèle. Les versions CTranslate2 sur lesquelles tourne Whisper prennent en charge float16 et int8, et réduire la précision diminue nettement la mémoire utilisée, pour un coût de qualité faible en int8 et généralement invisible en float16 sur GPU.

Sur GPU, attendez-vous à un gain de vitesse d’environ cinq à dix fois par rapport à la même machine sur CPU. Dans Sablate sous Windows, le runtime NVIDIA CUDA se télécharge la première fois qu’une exécution GPU a lieu plutôt que d’être inclus dans l’installeur, ce qui garde le téléchargement léger pour les personnes qui ne s’en serviront jamais.

Quel modèle choisir, concrètement ?

Cette dernière ligne est celle qui change tout le calcul. Quand une transcription sert de base à huit traductions, une erreur n’est pas une seule erreur — elle en fait huit. Le flux de travail multilingue explique pourquoi la transcription source mérite le modèle le plus lent et la relecture la plus soignée.

Dans Sablate, Fast et Balanced (tiny et small) tournent sur la formule gratuite ; Accurate et Best font partie de Pro, pour un paiement unique de $29 détaillé sur la page des tarifs. Quel que soit le modèle utilisé, le résultat arrive dans le même éditeur et s’exporte dans les mêmes formats — SRT, VTT et ASS — si bien que le choix du modèle porte sur la quantité de corrections à faire après coup, pas sur ce que vous pouvez produire.

Comment tester cela sur vos propres images

Cinq minutes de méthode valent mieux que n’importe quel banc d’essai publié, celui-ci compris :

1. Prenez un extrait de 60 à 120 secondes qui soit représentatif — votre pire microphone, vos accents habituels, votre pièce réelle.
2. Transcrivez-le avec deux modèles candidats, sans rien changer d’autre.
3. Comparez d’abord les omissions, les fautes d’orthographe ensuite.
4. Comptez les sous-titres d’un seul mot. Un tas de ce genre pointe vers la segmentation, pas vers le modèle.
5. Ce n’est qu’à ce moment que vous comparez le temps réel d’exécution, et que vous décidez ce que ce temps vaut pour vous.

Le modèle qui entend tout sur vos propres images est le meilleur modèle pour vous, et ce ne sera pas forcément le plus gros.