Combien d’audio un serveur domestique peut-il transcrire par jour ?
Un serveur domestique peut transcrire de moins d’une heure à plusieurs centaines d’heures audio par jour, selon son facteur temps réel mesuré et son cycle d’utilisation disponible.
Un facteur temps réel de 0,25 signifie qu’une heure audio nécessite 15 minutes, soit quatre heures audio par heure de traitement. Si la transcription peut fonctionner pendant 20 heures, la capacité théorique quotidienne est de 80 heures audio, avant les nouvelles tentatives et la surcharge d’ingestion. Les seuls noms des composants matériels ne permettent pas d’obtenir ce chiffre de manière fiable sur la fenêtre de traitement nocturne prévue.
Le facteur temps réel convertit la vitesse en capacité quotidienne
Le facteur temps réel correspond au temps de traitement divisé par la durée audio. Un RTF de 1,0 fonctionne en temps réel ; 0,5 traite deux heures audio par heure réelle ; 0,1 en traite dix. La capacité quotidienne équivaut au nombre d’heures de traitement planifiées divisé par le RTF.
Les benchmarks de débit de Whisper publiés montrent que le modèle, le GPU, la durée audio et le traitement par lots peuvent faire varier considérablement le débit. La configuration mesurée doit correspondre à la charge de travail domestique.
Ce calcul comptabilise la durée de l’audio source, et non le temps écoulé des fichiers. La suppression des silences peut réduire le travail, tandis que la diarisation, l’alignement, la traduction et le formatage des sous-titres ajoutent des étapes. Un enregistrement de 24 heures peut ne contenir que quelques heures de parole, tout en nécessitant un décodage et une segmentation.
Le modèle et le traitement par lots déterminent le compromis vitesse–précision
Les modèles plus petits ou distillés sont généralement plus rapides et utilisent moins de mémoire, tandis que les modèles multilingues plus volumineux peuvent améliorer la précision pour les langues difficiles. Le traitement par lots peut accroître l’utilisation du GPU pour de nombreux fichiers, mais il augmente le temps d’attente pour un seul extrait urgent.
Une compilation de mesures d’exécution réalisées par la communauté souligne que la puissance de calcul théorique ne se traduit pas linéairement par une vitesse de transcription accrue, sauf si le traitement par lots et l’utilisation du pipeline sont pris en compte.
Les extraits courts supportent proportionnellement davantage de surcharge liée à l’initialisation, à l’ouverture des fichiers et à la planification que les longs enregistrements. La détection de la langue et la recherche en faisceau peuvent également modifier la durée d’exécution. Une plus grande quantité d’audio par jour n’est pas automatiquement préférable si le taux d’erreur des mots rend les transcriptions inutilisables.
Quand la formule de capacité cesse de s’appliquer
Un RTF mesuré sur une parole mono propre peut ne pas être représentatif pour des réunions en stéréo, des enregistrements bruyants, plusieurs langues ou de longs fichiers entraînant un comportement mémoire différent. La réduction de fréquence thermique et les tâches NAS simultanées diminuent la puissance de calcul disponible sur une journée entière.
Un facteur temps réel pratique montre d’importantes variations entre les appareils et confirme qu’il faut mesurer le modèle utilisé plutôt que déduire le débit de la seule catégorie du GPU.
La formule ne s’applique pas non plus à la transcription en direct si la latence doit rester inférieure au flux entrant. Le débit hors ligne peut utiliser le traitement par lots et le contexte futur, ce qu’un assistant en temps réel ne peut pas faire. La capacité quotidienne et le délai interactif sont deux résultats distincts.
Convertir le RTF mesuré en une plage de capacité quotidienne
Sélectionnez un ensemble représentatif de notes vocales courtes, de longues réunions, de langues, de niveaux de bruit et de nombres de canaux. Mesurez le temps de traitement de bout en bout, la durée audio, le taux d’erreur des mots sur un sous-ensemble annoté, la mémoire maximale et la consommation énergétique pendant au moins trois heures. Incluez la diarisation ou l’alignement si la production l’exige.
Effectuez le test parallèlement aux services de traitement vocal local prévus, afin de rendre visible le cycle d’utilisation réel du serveur. Enregistrez séparément les démarrages à froid et le débit à chaud.
Calculez la capacité quotidienne en divisant le nombre d’heures de traitement utilisables par le RTF médian, puis appliquez le RTF p95, plus lent, ainsi qu’une réserve opérationnelle de 20 % pour la planification. Si la précision n’atteint pas l’objectif, passez à un modèle plus performant et recalculez au lieu de promouvoir le résultat plus rapide, mais inutilisable.
Produits recommandés
Centre Tech & IA
Plus à lire
Comment mesurer la qualité de la récupération RAG locale et interpréter le rappel, la précision et la couverture des citations
Créez un jeu de test RAG local, calculez les principales métriques de récupération, interprétez leurs compromis et vérifiez si les affirmations des réponses sont...
Pourquoi le calcul des fonctionnalités de la maison intelligente devient-il plus important lorsque le nombre de capteurs augmente à fréquence d’échantillonnage constante ?
Suivez les calculs par capteur et intercapteurs à mesure que le nombre d’appareils augmente, identifiez les coûts de fusion non linéaires et évaluez les...
Pourquoi le coût de l’évaluation du RAG devient-il plus important à mesure que la bibliothèque de documents s’agrandit, pour un même volume de requêtes ?
Comprenez pourquoi l’augmentation du corpus accroît l’effort d’évaluation du RAG sans augmenter le nombre de requêtes des utilisateurs, et comment les tests stratifiés maintiennent...
