You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actuellement l'API audio est accessible par une requête http POST : le fichier audio est transmis par le client, il est passé au modèle speech2text (Whisper) et le texte généré par la transcription audio est retourné dans la réponse au POST.
Cependant, un fichier audio suffisamment long (au delà de 4' pour un podcast provenant de France Inter) n'aura pas le temps d'être traité par le modèle avant le timeout http, mesuré à environ 30", de Gunicorn ou du reverse proxy devant Gunicorn (nginx ?).
Première proposition immédiate : augmenter la durée du timeout actuel à une durée pertinente pour l'utilisateur et pour les ressources système de l'infrastructure Albert : 200-230" pourraient être raisonnables pour traiter des fichiers audio de plusieurs dizaines de minutes.
Proposition suivante : rendre l'API audio asynchrone. On conserve les paramètres en entrée du POST, mais la requête génére une URL temporaire qui sera le texte de sa réponse. Le fichier audio est passé au modèle pour transcription de façon asynchrone et quand le fichier texte transcrit est disponible, il devient alors accessible via un GET authentifié (api key) temporairement sur l'URL temporaire. C'est au client d'aller récupérer le fichier texte transcrit de façon asynchrone sur l'URL récupérée durant le temps de validité de cette dernière.
Cordialement
--
Jérôme
The text was updated successfully, but these errors were encountered:
Actuellement l'API audio est accessible par une requête http POST : le fichier audio est transmis par le client, il est passé au modèle speech2text (Whisper) et le texte généré par la transcription audio est retourné dans la réponse au POST.
Cependant, un fichier audio suffisamment long (au delà de 4' pour un podcast provenant de France Inter) n'aura pas le temps d'être traité par le modèle avant le timeout http, mesuré à environ 30", de Gunicorn ou du reverse proxy devant Gunicorn (nginx ?).
Première proposition immédiate : augmenter la durée du timeout actuel à une durée pertinente pour l'utilisateur et pour les ressources système de l'infrastructure Albert : 200-230" pourraient être raisonnables pour traiter des fichiers audio de plusieurs dizaines de minutes.
Proposition suivante : rendre l'API audio asynchrone. On conserve les paramètres en entrée du POST, mais la requête génére une URL temporaire qui sera le texte de sa réponse. Le fichier audio est passé au modèle pour transcription de façon asynchrone et quand le fichier texte transcrit est disponible, il devient alors accessible via un GET authentifié (api key) temporairement sur l'URL temporaire. C'est au client d'aller récupérer le fichier texte transcrit de façon asynchrone sur l'URL récupérée durant le temps de validité de cette dernière.
Cordialement
--
Jérôme
The text was updated successfully, but these errors were encountered: