Fiabilité, nouvelles tentatives et délais d’attente

Chaque requête est surveillée du début jusqu’au premier token. Si une voie d’accès au modèle se bloque ou échoue, la requête bascule vers une autre avant que quoi que ce soit ne vous parvienne.

Rétablissement automatique

• La plupart des modèles sont accessibles par plusieurs voies. Une requête commence par celle qui fonctionne le mieux.
• Une voie qui renvoie une erreur ou reste inaccessible est écartée pour cette requête, qui est retentée ailleurs. Si une voie fonctionne, nous attendons sa réponse, même si une requête volumineuse prend du temps ; si elle reste totalement silencieuse pendant 3 minutes (5 avec un effort de raisonnement élevé), elle est considérée comme défaillante.
• Les voies qui échouent à répétition deviennent moins prioritaires pour tout le monde. Une voie qui reste silencieuse sur au moins un cinquième de ses requêtes passe derrière une voie qui répond sans erreur. Chacune est réessayée une fois rétablie.
• Rien ne vous est envoyé avant l’arrivée d’un véritable token. Tout cela est donc invisible pour vous : vous obtenez une réponse un peu plus lente, pas une erreur.

La page des modèles affiche l’état de chaque modèle en temps réel (opérationnel, dégradé ou indisponible), d’après les requêtes réelles et nos propres contrôles : chaque modèle de chat est testé au moins toutes les 10 minutes.

Délais d’expiration

Sans premier token, un flux n’envoie rien pendant les 20 premières secondes, puis s’ouvre avec des commentaires de maintien de connexion jusqu’au début de la réponse. Une requête sans streaming n’envoie rien avant d’être terminée : le streaming convient donc aux clients qui abandonnent lorsque les en-têtes tardent à arriver (le fetch de Node les attend pendant 5 minutes). Réglez le délai d’expiration de votre client sur au moins 10 minutes pour les raisonnements longs, les longues réponses et les images. Les SDK OpenAI utilisent 10 minutes par défaut ; certains clients HTTP utilisent 30 ou 60 secondes.

Limites de débit

Votre compte n’a aucune limite de débit globale : les clés ne sont limitées que si vous leur fixez une limite. Un espace de travail peut exécuter 32 requêtes en parallèle ; toute requête supplémentaire reçoit 429 concurrency_limit_exceeded avec retry-after. Si un modèle est surchargé, la requête est retentée sur ses autres voies ; si aucune ne répond, vous recevez 503 model_unavailable avec retry-after. Patientez avant de réessayer, ou activez le routage intelligent.

Lorsqu’un modèle est indisponible

Il arrive rarement que toutes les voies d’accès à un modèle échouent. Sans routage intelligent, la requête se termine avec 503 model_unavailable et retry-after. Si les voies renvoient des erreurs alors que le modèle répond encore à d’autres requêtes, il s’agit généralement d’un incident passager qui se résout en quelques secondes : nous continuons donc les tentatives pendant un maximum de 2 minutes avant de renvoyer l’erreur. Si le modèle est indisponible pour tout le monde, l’erreur est immédiate ; si les voies restent silencieuses, elle arrive dans les 10 minutes. Avec le routage intelligent, un modèle similaire répond à sa place.