Requesty : Le Router Intelligent de Modèles AI
Maximise la fiabilité et la performance avec failover automatique et load balancing sur 500+ modèles LLM. Jamais offline. Toujours une réponse.
Politiques de Failover Automatique
Assure 99,9% de disponibilité pour tes applications AI. Quand un modèle échoue (timeout, erreur, rate limit), Requesty route automatiquement vers tes modèles de secours en quelques millisecondes—aucune intervention manuelle nécessaire.
Comment ça marche
Ton modèle primaire reçoit la requête.
S'il échoue (timeout, erreur, etc.), le router essaye immédiatement le modèle suivant.
Ça continue jusqu'à ce qu'un modèle livre les résultats dont t'as besoin.
Pourquoi le Routing Fallback Est Important
99,9% de Disponibilité
Élimine les points de défaillance uniques. Si OpenAI tombe, bascule instantanément vers Anthropic, Google ou AWS Bedrock
Gestion des Rate Limits
Route automatiquement le trafic excédentaire vers des modèles alternatifs quand tu atteins les limites des providers
Optimisation des Coûts
Commence avec des modèles moins chers, bascule vers les modèles premium seulement si nécessaire
Questions Fréquemment Posées
Qu'est-ce qu'une fallback policy et comment fonctionne-t-elle ?
Une fallback policy est un mécanisme de re-routing automatique. Quand ton modèle primaire échoue (timeout, erreur, rate limit), Requesty route immédiatement la requête vers le modèle suivant dans ta chaîne. Ça continue jusqu'à ce qu'un modèle réponde avec succès. Tu payes seulement pour la requête réussie.
Comment le load balancing maintient-il la cohérence conversationnelle ?
Requesty maintient la cohérence du routing par trace_id. Ça signifie que le même utilisateur ou conversation atteint toujours le même modèle, assurant des interactions multi-tours cohérentes. Configure ta distribution (ex: 50% Model A, 30% Model B, 20% Model C) et chaque trace_id est routé de manière cohérente basé sur ces poids.
Puis-je utiliser les fallback policies pour l'A/B testing ?
Oui. Combine les fallback policies avec le load balancing pour l'A/B testing. Route 90% vers ton modèle de production et 10% vers un modèle expérimental, puis mesure qualité, latence et coût en parallèle. Si le modèle expérimental échoue, il bascule automatiquement vers ton modèle de production.
Que se passe-t-il si tous les modèles de ma chaîne fallback échouent ?
Si tous les modèles de ta chaîne fallback échouent, Requesty retourne une réponse d'erreur avec les détails de chaque tentative. Tu peux configurer le nombre maximum de tentatives de retry et les seuils de timeout par modèle dans tes paramètres de policy.
Comment le routing basé sur la latence détermine-t-il quel modèle est le plus rapide ?
Requesty track les latences P50, P90 et P99 sur tous les modèles en temps réel. Basé sur les performances réelles observées (pas des promesses marketing), le système recommande les modèles les plus rapides pour ta charge de travail spécifique et bascule automatiquement le trafic vers les options à plus faible latence.
Puis-je combiner fallback, load balancing et routing régional ?
Oui. Tu peux créer des policies qui combinent plusieurs stratégies de routing. Par exemple : load balance entre des modèles EU-seulement (routing régional) avec fallback automatique vers des modèles EU secondaires si le primaire échoue. Ça te donne conformité géographique avec fiabilité maximale.
Comment assurer la compatibilité des modèles dans ma chaîne fallback ?
Assure-toi que chaque modèle dans ta chaîne fallback supporte les mêmes paramètres (temperature, max_tokens, response_format, etc.). Requesty valide la compatibilité quand tu crées des policies et te prévient si les modèles ne correspondent pas à tes paramètres de requête.
Est-ce que l'auto-caching fonctionne avec les fallback policies ?
Oui. Tu peux contrôler le comportement de caching par requête avec le flag auto_cache. Définis auto_cache: true pour cacher les réponses, ou auto_cache: false pour toujours récupérer des réponses fraîches. Le caching fonctionne sur toute ta chaîne fallback, servant potentiellement des réponses cachées de n'importe quel modèle de la chaîne.
À quelle vitesse le failover se produit-il ?
Le failover se produit en millisecondes. Quand un modèle échoue (timeout, erreur ou rate limit), Requesty route immédiatement vers le modèle suivant dans ta chaîne—aucune intervention manuelle nécessaire. Ça assure 99,9% de disponibilité pour tes applications AI.
Puis-je router basé sur la complexité de la requête ?
Oui. Utilise le load balancing pour router les requêtes simples vers des modèles rapides et économiques (GPT-3.5, Gemini Flash) et les requêtes complexes vers des modèles premium (GPT-4, Claude Sonnet). Tu peux aussi implémenter une logique de routing personnalisée basée sur la longueur du prompt, le tier utilisateur, ou toute métadonnée que tu envoies.