Performance en production — Grok en production

Au-delà du cache : la performance globale

Le cache est un levier majeur de réduction des coûts, mais la performance en production englobe d’autres dimensions : la latence, le débit, la fiabilité et la gestion des erreurs. Cette leçon couvre les bonnes pratiques pour maintenir une qualité de service constante avec l’API Grok.

Streaming pour la latence perçue

Pour les applications interactives, le streaming SSE (Server-Sent Events) réduit considérablement la latence perçue par l’utilisateur. Au lieu d’attendre la réponse complète, votre application affiche les tokens au fur et à mesure de leur génération.

import requests
import json

def appel_streaming(messages, model="grok-4.20"):
    reponse = requests.post(
        "https://api.x.ai/v1/chat/completions",
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json"
        },
        json={
            "model": model,
            "messages": messages,
            "stream": True
        },
        stream=True
    )

    for ligne in reponse.iter_lines():
        if ligne and ligne.startswith(b"data: "):
            donnees = ligne[6:]
            if donnees == b"[DONE]":
                break
            chunk = json.loads(donnees)
            token = chunk["choices"][0]["delta"].get("content", "")
            yield token

Le streaming n’affecte pas le coût des tokens mais améliore l’expérience utilisateur en réduisant le “time to first token” (TTFT).

Choix du modèle selon la latence

La latence varie significativement entre les modèles :

grok-4-1-fast : latence la plus basse, adapté aux applications temps réel (chatbots, autocomplétion)
grok-4.20 non-reasoning : latence modérée, bon compromis qualité/vitesse
grok-4.20 reasoning : latence la plus élevée, réservé aux tâches nécessitant un raisonnement complexe

En production, il est courant de combiner plusieurs modèles : grok-4-1-fast pour le premier tri ou la classification, puis grok-4.20 pour les cas nécessitant une analyse approfondie.

Gestion des erreurs en production

Au-delà du code 429 (rate limit), préparez votre application à gérer d’autres codes d’erreur :

Erreurs récupérables

429 Too Many Requests : backoff exponentiel (vu en leçon 3)
500 Internal Server Error : retry avec backoff, l’erreur est côté serveur
502/503 Service Unavailable : retry après quelques secondes

Erreurs non récupérables

400 Bad Request : votre requête est malformée, corrigez le payload
401 Unauthorized : clé API invalide ou expirée
413 Payload Too Large : votre prompt dépasse la limite de contexte

def classifier_erreur(status_code):
    recuperable = {429, 500, 502, 503}
    return status_code in recuperable

Timeouts et résilience

Configurez des timeouts adaptés à votre modèle et à la longueur attendue de la réponse :

Connection timeout : 10 secondes
Read timeout (non-streaming) : 120 secondes pour grok-4.20, 60 secondes pour grok-4-1-fast
Read timeout (streaming) : 30 secondes entre deux chunks

Si un timeout expire, ne retentez pas automatiquement les requêtes de génération longue : le modèle a peut-être déjà consommé des tokens pour le raisonnement. Préférez un mécanisme d’idempotence ou de reprise.

Monitoring en production

Les métriques essentielles à surveiller :

TTFT (Time to First Token) : indique la latence initiale
Taux de succès : pourcentage de requêtes réussies (cible > 99,5 %)
Taux de cache : proportion de tokens cachés (cible > 50 %)
Coût par requête : moyenne glissante pour détecter les anomalies
P95 latence : latence au 95e percentile pour détecter les cas extrêmes

Points clés à retenir

Le streaming SSE réduit la latence perçue sans affecter le coût
Choisissez grok-4-1-fast pour les applications temps réel et grok-4.20 pour la qualité
Distinguez les erreurs récupérables (429, 500, 502/503) des erreurs définitives (400, 401)
Configurez des timeouts adaptés au modèle utilisé
Surveillez le TTFT, le taux de succès, le taux de cache et le coût moyen par requête