> ## Documentation Index > Fetch the complete documentation index at: https://docs.flexinference.com/llms.txt > Use this file to discover all available pages before exploring further. # Routage par délai > Le champ start_within, la course flex et l'escalade automatique vers le standard. `start_within` est requis pour chaque requête FlexInference. Il définit la durée maximale pendant laquelle le routeur peut attendre le démarrage de la requête. Utilisez `default`, `priority` ou `auto` lorsque vous souhaitez un niveau de fournisseur directement. Utilisez une durée lorsque vous souhaitez que FlexInference essaie d'abord le niveau flex sur un modèle compatible flex, puis passe au niveau standard si flex ne peut pas démarrer à temps. Le champ se présente sous quatre formes. ## Les quatre formes ```json theme={null} { "start_within": "default" } ``` Route vers le niveau temps réel **standard** du fournisseur, au tarif standard : `default` d'OpenAI, `standard` de Gemini ou `standard_only` d'Anthropic. Fonctionne avec n'importe quel modèle. ```json theme={null} { "start_within": "priority" } ``` Route vers le niveau **priority** d'OpenAI pour le démarrage le plus rapide. Utilisez-le pour les chemins interactifs et critiques en termes de latence. Priority est le niveau le plus cher. Fonctionne avec n'importe quel modèle. Sur Anthropic, il s'agit d'un **effort maximal** (best-effort) car Claude n'a pas de niveau priority ; nous le mappons à l'`auto` d'Anthropic. ```json theme={null} { "start_within": "auto" } ``` Permet au fournisseur de choisir le niveau. Sur OpenAI, il s'agit de `service_tier: auto` ; sur Anthropic, il est mappé à l'`auto` d'Anthropic. Il s'agit du niveau auto du fournisseur, et non du routage auto de FlexInference. Fonctionne sur **OpenAI et Anthropic**. Gemini n'a pas de niveau auto, donc `auto` sur un modèle Gemini renvoie `400 auto_unsupported_for_gemini`. ```json theme={null} { "start_within": "00h-00m-30s" } ``` Demande la **course flex** (ci-dessous) sur chaque endpoint, y compris `/v1/responses`, `/v1/chat/completions`, `/v1/interactions` et `/v1/messages`. FlexInference essaie d'abord le niveau flex, moins cher, et ne passe au standard que si flex ne peut pas démarrer dans la fenêtre de temps. La durée est le temps d'attente maximum pour le démarrage de la requête, écrite sous la forme `HHh-MMm-SSs` avec deux chiffres par champ. Elle doit être comprise entre **5 secondes et 10 minutes** (`00h-00m-05s` et `00h-10m-00s`). `default`, `priority` et `auto` proxysent **n'importe quel** modèle à son fournisseur (OpenAI, Gemini ou Anthropic). Seule une durée demande la course flex. Si le modèle ne peut pas utiliser flex, une durée renvoie `400` (`flex_unsupported_for_anthropic` ou `flex_model_not_capable`) ; utilisez plutôt une valeur de niveau. La course flex n'est **pas disponible sur Claude** car Anthropic n'a pas de niveau flex. Une durée `start_within` sur un modèle `claude-*` renvoie `400 flex_unsupported_for_anthropic`. Anthropic fonctionne toujours avec les requêtes proxy de niveau `default`, `priority` et `auto`. Une durée `start_within` ne peut pas être combinée avec des paramètres de Chat Completions natifs uniquement, tels que `logprobs` ou `seed`. Supprimez ces paramètres, ou utilisez `default`, `priority` ou `auto` à la place. ## La course flex Avec une durée, FlexInference tente d'abord le niveau **flex** du fournisseur (OpenAI ou Gemini). flex est facturé à la moitié du tarif standard, mais la capacité est en mode "meilleur effort". Le routeur attend le démarrage de la requête en amont dans votre fenêtre de temps : FlexInference envoie votre requête au niveau flex et attend la confirmation du fournisseur qu'elle est en cours de traitement, le tout dans le délai que vous avez défini. Si le fournisseur démarre la requête à temps, FlexInference s'engage. Votre réponse est diffusée normalement, facturée aux tarifs flex. La réponse affiche `"service_tier": "flex"`. Si flex ne peut pas démarrer à temps, FlexInference l'annule et envoie la requête au niveau standard. Il s'agit d'une escalade du niveau flex moins cher vers le standard, et non d'une rétrogradation. La réponse affiche `"service_tier": "default"` (OpenAI) ou `"standard"` (Gemini). L'escalade vers le standard ne se produit qu'avant le démarrage de flex, lorsque flex renvoie un `429` (pas de capacité), un `5xx` quelconque, un échec avant le démarrage, ou aucun démarrage avant la date limite. Le passage de flex au standard est le **seul** changement de niveau effectué par FlexInference. Un fallback de fournisseur, où vous définissez un tableau `provider` optionnel et FlexInference essaie la route suivante après l'échec transitoire d'une route, modifie la route, jamais le niveau ou le modèle. Une clé manquante pour toute route que vous avez nommée est une erreur de configuration plutôt qu'un échec transitoire, elle renvoie donc un `400` au lieu de passer à la suivante. Voir [routage des fournisseurs](/fr/models). Choisissez la durée la plus longue que votre expérience utilisateur peut tolérer. Des fenêtres plus longues donnent plus de temps à flex pour réussir, augmentant la proportion de requêtes servies au tarif le plus bas. ## Lecture du résultat Les réponses `200` réussies incluent des en-têtes de résultat Flex sur chaque endpoint, pour les appels en streaming et non-streaming. Les réponses d'erreur utilisent le corps de l'erreur à la place. | En-tête | Signification | | :--------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `x-flexinference-flex-requested` | `true` lorsque l'appelant a envoyé une durée `start_within` ; `false` lorsque l'appelant a envoyé `default`, `priority` ou `auto`. | | `x-flexinference-flex-applied` | `true` uniquement lorsque flex a servi la réponse. | | `x-flexinference-flex-reason` | Le résultat lisible par machine. Voir les valeurs ci-dessous. | | `x-flexinference-provider-surface` | La surface du fournisseur sélectionnée par le planificateur. Les valeurs sont `openai.responses`, `openai.chat`, `gemini.interactions` et `anthropic.messages`. Cela peut différer de l'endpoint de l'appelant. Un appel `/v1/chat/completions` avec un modèle OpenAI signale `openai.responses` sauf si le passthrough natif de Chat est requis, auquel cas il signale `openai.chat`. | Les valeurs `x-flexinference-flex-reason` en direct sont : | Raison | Signification | | :--------------- | :------------------------------------------------------------------------------------------------------------------------------------- | | `not_requested` | La requête a utilisé `default`, `priority` ou `auto` ; aucune course flex n'a été demandée. | | `flex_committed` | La course flex s'est engagée. La réponse affiche `service_tier: "flex"` et `x-flexinference-flex-applied: true`. | | `flex_lost_race` | La requête a utilisé une durée sur un modèle compatible flex, mais flex n'a pas démarré à temps et la requête est revenue au standard. | Une durée qui ne peut pas exécuter une course flex renvoie `400` (`flex_unsupported_for_anthropic` sur un modèle `claude-*`, `flex_model_not_capable` sur un modèle OpenAI/Gemini non compatible flex) ; les raisons d'en-tête décrivent uniquement les requêtes qui ont exécuté flex ou ne l'ont pas demandé. ## Lorsque le pool flex est indisponible Le niveau flex utilise une capacité partagée, en mode "meilleur effort". Avant le démarrage d'une requête, flex peut renvoyer un `429` en cas d'absence de capacité, renvoyer un `5xx` quelconque, échouer avant le démarrage, ou manquer le délai. FlexInference envoie alors la requête au standard. Dans de rares cas, flex échoue *après* que la requête a été acceptée et que le streaming a commencé. FlexInference expose cet échec. Sur une requête en streaming, vous recevez un événement terminal `response.failed`. Sur une requête non-streaming, vous recevez un `502`. Il n'y a pas de nouvelle tentative après l'engagement, car cela pourrait masquer une requête incomplète. Si cela se produit, **réessayez**, ou utilisez `default`, `priority` ou `auto` pour ignorer flex. ## Nouvelle tentative de transport La course flex décide quel niveau sert votre requête. La nouvelle tentative de transport (transport retry) décide ce qui se passe lorsque ce niveau ne parvient pas à démarrer. Ajoutez un objet `retry` optionnel et FlexInference attend et relance le niveau établi en cas d'échec transitoire en amont, au lieu de vous renvoyer l'erreur. ```json theme={null} { "retry": { "count": 2 } } ``` | Champ | Requis | Valeurs | Signification | | :-------- | :----- | :----------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- | | `count` | yes | entier, de `1` à `5` | Nouvelles tentatives sur le niveau établi après l'échec de la première tentative. | | `backoff` | no | `"exponential"` (par défaut) ou `"linear"` | Le modèle d'attente entre les tentatives. Exponentiel commence à 0,5s et double jusqu'à 8s ; linéaire ajoute 0,5s à chaque fois, jusqu'à 8s. | | `jitter` | no | booléen (par défaut `true`) | Étale l'attente pour lisser les pics. Le jitter ne fait que raccourcir une attente, jamais l'allonger. | Une valeur `retry` invalide renvoie `400` [`invalid_retry`](/fr/errors#invalid_retry). FlexInference ne réessaie qu'un véritable échec de transport pré-engagement du niveau établi : un vrai `429`, un vrai `5xx`, ou une connexion qui n'a jamais été ouverte ([`upstream_unavailable`](/fr/errors#upstream_unavailable)). Il ne réessaie pas un `4xx` client, un échec d'authentification en amont ([`upstream_auth_failed`](/fr/errors#upstream_auth_failed)), un timeout en amont ([`upstream_timeout`](/fr/errors#upstream_timeout)), ou une requête annulée par le client. Ceux-ci échouent de la même manière lors d'une nouvelle tentative ou signifient que l'appelant est déjà parti. La nouvelle tentative relance le niveau qui a établi votre requête, et non la branche flex. Pour une requête `default`, `priority` ou `auto`, c'est le niveau que vous avez nommé. Pour une requête de durée qui perd la course flex, c'est le niveau standard vers lequel vous avez escaladé. La tentative flex et l'escalade sont le travail propre de la course flex et ne sont jamais comptées dans `count`. L'escalade d'un niveau et la nouvelle tentative sur le même niveau sont des étapes distinctes qui s'enchaînent : flex perd face au standard, puis le standard peut se relancer. Lorsque le fournisseur envoie un en-tête `Retry-After`, FlexInference attend cette durée au lieu du calendrier de backoff, limitée à 60 secondes afin qu'une mauvaise valeur ne puisse pas bloquer votre requête. La nouvelle tentative n'est effectuée qu'avant l'engagement. Elle s'arrête au moment où un niveau s'engage, c'est-à-dire la ligne de statut `200` pour les appels en streaming et non-streaming. Une fois que le premier octet est en route vers vous, FlexInference ne réessaie jamais, la même règle que la course flex suit après l'engagement. Un échec en cours de streaming, ou un `502` non-streaming après un `200` engagé, vous est transmis. La `retry` côté serveur est distincte de toute boucle de nouvelle tentative dans votre client, et les deux s'empilent. Les SDK FlexInference ne réessaient pas, mais un SDK OpenAI ou Anthropic standard réessaie deux fois par défaut. Un client qui réessaie deux fois en plus d'un `count` serveur de `3` entraîne jusqu'à six tentatives en amont, car chaque tentative client exécute un budget serveur complet. Lorsque vous définissez `retry`, FlexInference appose `x-flexinference-retries` sur la réponse avec le nombre de relances effectuées, afin que vous puissiez réduire le `max_retries` de votre client. ## Facturation Avec BYOK, FlexInference utilise votre clé de fournisseur chiffrée stockée côté serveur ; vous n'envoyez pas de clés de fournisseur par requête. Votre fournisseur facture votre compte au tarif du niveau qui a servi la requête. Vous payez les tarifs flex lorsque flex s'engage et les tarifs standard après l'escalade. Une tentative flex peut consommer quelques tokens avant d'échouer. Votre fournisseur facture cette utilisation de la même manière que si vous appeliez flex directement, et FlexInference l'inclut dans l'utilisation. FlexInference n'ajoute aucune majoration sur vos tokens. Il facture 20 % des économies qu'il vous fait réaliser, et ne facture rien en l'absence d'économies. ## Ce que FlexInference modifie FlexInference peut changer le niveau. Il ne modifie pas la signification de votre requête ni le résultat du fournisseur. Il ne réécrit jamais le statut ou le message d'un fournisseur. Il normalise uniquement l'enveloppe d'erreur : une erreur est renvoyée sous la forme de l'endpoint que vous avez appelé (OpenAI sur les réponses et le chat, Anthropic sur les messages, Google sur les interactions), portant le statut et le message du fournisseur, afin que votre SDK puisse l'analyser. Voir [Erreurs](/fr/errors). `start_within` est **requis**. Sans lui, la requête renvoie `400 missing_start_within`, y compris avec un SDK OpenAI simple pointant vers notre URL de base. Si vous envoyez une valeur que FlexInference ne peut pas lire, vous obtenez `invalid_start_within`. Les valeurs valides sont `"default"`, `"priority"`, `"auto"`, ou une durée telle que `"00h-00m-30s"`. Le mot `standard` était autrefois autorisé et ne l'est plus, envoyez donc `default` à la place. Voir [Erreurs](/fr/errors) pour la liste complète.