Optimisation de la latence

La latence : l’ennemi de la conversation naturelle

Dans une conversation humaine, le temps de réponse moyen tourne autour de 200 millisecondes. Au-delà de 500 ms, l’interlocuteur perçoit un délai ; au-delà de la seconde, il croit qu’on ne l’a pas entendu et il répète sa question. Pour qu’un assistant vocal passe pour naturel, le temps entre la fin de la question et le début de la réponse doit donc rester sous la seconde.

Voxtral annonce une latence modèle d’environ 90 ms, et c’est là que beaucoup d’équipes se trompent : ce chiffre ne décrit qu’un maillon d’une chaîne bien plus longue. Ce que l’utilisateur ressent, c’est la somme de tous les maillons. Optimiser suppose donc de savoir lequel coûte quoi.

Anatomie de la latence totale

Le trajet commence par le réseau aller, le temps d’acheminer votre requête jusqu’aux serveurs Mistral. Il dépend de votre localisation et de la qualité de votre lien : depuis l’Europe, comptez 20 à 80 ms. Vient ensuite la latence modèle, ces fameux 90 ms de traitement avant le premier fragment audio — la seule part sur laquelle vous n’avez aucune prise, puisqu’elle relève de l’infrastructure Mistral.

L’étape suivante est l’encodage, et c’est celle qui réserve les plus mauvaises surprises. Le PCM ne coûte rien, ou presque, parce qu’il n’y a rien à encoder. L’Opus ajoute 5 à 10 ms, ce qui reste négligeable. Le MP3, lui, réclame 200 à 500 ms : son codec doit accumuler suffisamment de données avant de produire la première trame. Autrement dit, un développeur qui laisse response_format="mp3" par habitude ajoute à lui seul plus de délai que le modèle entier.

Le retour réseau, enfin, pèse peu en streaming puisque les fragments sont petits. Reste le buffer côté client : votre application accumule généralement deux ou trois fragments avant de démarrer la lecture, pour éviter les micro-coupures. Ajoutez 50 à 150 ms — un coût assumé, qui achète la fluidité.

Streaming ou batch : l’écart chiffré

Passer du batch au streaming PCM divise la latence perçue par trois à quatre. Aucune autre optimisation de cette leçon n’aura un effet comparable : c’est la première chose à changer, avant même de mesurer.

Trois leviers côté serveur

Le premier levier est donc le format. Pour toute application conversationnelle, le PCM en streaming est le réglage de référence, et le passage se fait sans réécrire votre logique.

with client.audio.speech.complete(
    model="voxtral-mini-tts-2603",
    input=texte,
    voice_id=voice_id,
    response_format="pcm",  # Latence minimale
    stream=True,
) as stream:
    for event in stream:
        if event.event == "speech.audio.delta":
            jouer_audio(base64.b64decode(event.data.audio_data))

Le deuxième levier tient au choix entre voix sauvegardée et clonage à la volée. Un voice_id désigne une voix déjà traitée côté serveur, là où ref_audio impose de retraiter l’échantillon à chaque requête. Sur un agent qui répond cent fois par heure avec la même voix, ce détail vaut 50 à 100 ms gagnés à chaque tour de parole.

Le troisième levier consiste à raccourcir ce que vous demandez. Plus le texte est court, plus le premier fragment arrive vite : générer une réponse de cinq phrases d’un bloc revient à faire attendre l’utilisateur pour du contenu qu’il n’entendra que dans quinze secondes. Le générateur suivant découpe la réponse par phrases et produit l’audio de la première pendant que les suivantes patientent.

def generer_par_phrases(texte_complet, voice_id):
    """Génère l'audio phrase par phrase pour minimiser la latence."""
    phrases = texte_complet.split(". ")

    for phrase in phrases:
        phrase = phrase.strip()
        if not phrase:
            continue
        if not phrase.endswith("."):
            phrase += "."

        with client.audio.speech.complete(
            model="voxtral-mini-tts-2603",
            input=phrase,
            voice_id=voice_id,
            response_format="pcm",
            stream=True,
        ) as stream:
            for event in stream:
                if event.event == "speech.audio.delta":
                    yield base64.b64decode(event.data.audio_data)

Deux leviers côté client

Un buffer fixe est toujours un compromis mal placé : trop petit, il laisse passer les micro-coupures sur un réseau chargé ; trop grand, il ajoute du délai pour rien sur une bonne connexion. La classe ci-dessous démarre la lecture dès que deux fragments sont disponibles, puis laisse passer les suivants au fil de l’eau, sans jamais accumuler au-delà de cinq.

class BufferAdaptatif:
    def __init__(self):
        self.buffer = []
        self.seuil_min = 2   # chunks minimum avant lecture
        self.seuil_max = 5   # ne pas accumuler plus
        self.lecture_commencee = False

    def ajouter_chunk(self, chunk):
        self.buffer.append(chunk)

        if not self.lecture_commencee:
            if len(self.buffer) >= self.seuil_min:
                self.lecture_commencee = True
                return self.vider_buffer()
        else:
            return chunk
        return None

    def vider_buffer(self):
        data = b"".join(self.buffer)
        self.buffer = []
        return data

Le second levier ne coûte que quelques lignes : envoyez une requête de test au démarrage de votre application. Elle établit la connexion TCP et le handshake TLS une fois pour toutes, et le keep-alive HTTP fait profiter toutes les requêtes suivantes de ce travail déjà fait. Sans ce pré-chauffage, c’est votre premier utilisateur de la journée qui paie la facture.

Mesurer avant d’optimiser

Toutes ces estimations doivent être confrontées à votre installation réelle. La mesure minimale consiste à chronométrer le délai jusqu’au premier fragment reçu, puis à sortir de la boucle : c’est ce chiffre, et non la durée totale, qui correspond à ce que ressent l’utilisateur.

import time

t0 = time.perf_counter()

with client.audio.speech.complete(
    model="voxtral-mini-tts-2603",
    input="Test de latence.",
    voice_id=voice_id,
    response_format="pcm",
    stream=True,
) as stream:
    for event in stream:
        if event.event == "speech.audio.delta":
            t1 = time.perf_counter()
            print(f"Premier chunk reçu en {(t1 - t0)*1000:.0f} ms")
            break

Lancez cette mesure depuis votre serveur de production, pas depuis votre poste : la différence de réseau suffit souvent à expliquer l’écart entre une démo convaincante et une mise en service décevante.

Points clés à retenir

• La latence totale comprend le réseau, le modèle (~90 ms), l’encodage et le buffer client
• Le format PCM offre la latence la plus basse car il n’y a pas d’encodage
• Le streaming réduit la latence perçue d’un facteur 3 à 4 par rapport au batch
• Utilisez un voice_id plutôt que ref_audio pour gagner 50-100 ms
• Générez phrase par phrase pour minimiser le temps avant le premier son