Guide de l'utilisateur

Architecture de fiabilité

Architecture de fiabilité de l'IA LMU AI : routage multi-sources, sondes de santé et basculement automatique à trois niveaux ; objectif de disponibilité de 99,5 % sur les offres Standard et Enterprise.

Nous considérons la « stabilité » comme la fonctionnalité numéro un du produit. Cette page explique comment nous y parvenons et ce qui se passe quand quelque chose tourne mal.

Pourquoi la fiabilité est-elle si difficile ?

Les développeurs qui se connectent directement à l'API officielle rencontrent des problèmes tels que :

  • Limitation de débit régionale / indisponibilité
  • Un unique canal de paiement ou compte se faisant bannir
  • Problèmes de compatibilité lors des changements de version de modèle
  • File d'attente aux heures de pointe et pics de latence du premier jeton

Si un service de relais n'est qu'un simple proxy, ces problèmes sont transmis tels quels aux utilisateurs, voire aggravés. Notre approche consiste à concevoir le système sur le postulat que « les amonts sont instables », plutôt que de traiter cela comme une exception.

Notre architecture de routage multi-sources

Pour chaque appel d'API, la requête est traitée selon le chemin suivant :

Mécanismes fondamentaux :

  • Pool multi-amonts : plusieurs canaux indépendants se trouvent derrière le même modèle, évitant les points de défaillance uniques
  • Sondage de santé : nous surveillons en continu le taux de réussite, la latence du premier jeton et le taux de limitation de débit de chaque amont, et les canaux défaillants sont automatiquement déclassés ou retirés
  • Basculement automatique : lorsque le canal principal renvoie des erreurs 5xx / une limitation de débit / des délais d'attente, la requête bascule vers un canal de secours en quelques millisecondes, généralement sans impact de votre côté
  • Reconnexion en cas d'interruption de flux : lorsqu'une réponse en streaming est coupée en cours de route, nous tentons de la reprendre sur les protocoles qui le prennent en charge

Niveau de service (SLA)

Nos engagements externes reposent sur « ce que nous pouvons réellement offrir » — nous ne faisons pas de promesses en l'air.

NiveauObjectif de disponibilitéRapport mensuelContrat professionnel
EconomyAu mieux (best-effort)Non applicable
Standard99,5 %Non applicable
Enterprise99,5 %FourniSLA supérieur et clauses de compensation disponibles

Le niveau Economy s'adresse aux développeurs individuels qui recherchent le meilleur rapport qualité-prix et qui peuvent tolérer des fluctuations occasionnelles ; si votre activité a des exigences strictes de fiabilité, choisissez le niveau Enterprise ou contactez notre équipe commerciale pour un plan sur mesure.

Comment la disponibilité est mesurée :

  • Nous ne comptons que le taux de réussite des requêtes « du côté de LMU AI », en excluant les problèmes de réseau côté utilisateur, les erreurs de paramètres et les refus de contenu du modèle amont lui-même
  • Une panne unique de moins de 60 secondes n'est pas comptabilisée
  • Le rapport mensuel inclut les taux de réussite et la latence P95 ventilés par modèle et par période

Que se passe-t-il lors d'un incident

Variations brèves (< 5 minutes)

  • La couche de routage bascule automatiquement d'amont, sans annonce
  • La page de statut enregistre l'événement

Panne d'un seul amont (< 1 heure)

  • La couche de routage effectue le basculement ; si cela est visible pour certains utilisateurs/modèles, nous le publions sur la page de statut
  • Les utilisateurs Standard et Enterprise sont notifiés par e-mail

Impact régional ou simultané sur plusieurs amonts

  • L'événement est épinglé sur la page de statut avec des mises à jour périodiques
  • Les utilisateurs Enterprise reçoivent des mises à jour de progression par e-mail en temps réel
  • Un rapport post-mortem est publié dans les 48 heures suivant la fin de l'événement

Ce que nous ne faisons pas

Pour éviter d'induire les utilisateurs en erreur, nous ne promettons actuellement pas ce qui suit :

  • Basculement sans latence ni interruption : le basculement introduit une latence supplémentaire de l'ordre de la milliseconde à la seconde, il ne sera donc jamais totalement transparent
  • Compensation de compatibilité inter-modèles : si un modèle amont lui-même est retiré (par exemple, si une version de modèle est abandonnée par le fournisseur), nous l'annonçons plutôt que de basculer silencieusement vers un autre modèle
  • Nouvelles tentatives illimitées : les requêtes échouées sont retentées un nombre limité de fois selon la politique en vigueur, de sorte que vous ne payez pas pour des appels répétés inattendus

FAQ

Pourquoi est-ce que je rencontre encore parfois des échecs ?

Aucun système n'est disponible à 100 %. Notre objectif est de maintenir la disponibilité globale au-dessus de 99,5 % et de récupérer rapidement en cas de panne. Si vous rencontrez des échecs persistants (par exemple, le même type de requête qui échoue plusieurs fois en moins de 5 minutes), veuillez contacter le support avec votre request ID et nous prioriserons l'investigation.

Comment demander le niveau Enterprise ?

Consultez la page Offres Enterprise, ou contactez directement l'équipe commerciale :

Dernière mise à jour :

Sur cette page