Passer au contenu principal
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

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.
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 :
1

Lancement de flex

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.
2

Engagement sur flex

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".
3

Escalade vers le standard

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.
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. Les valeurs x-flexinference-flex-reason en direct sont :
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.
Une valeur retry invalide renvoie 400 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). Il ne réessaie pas un 4xx client, un échec d’authentification en amont (upstream_auth_failed), un timeout en amont (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.
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 pour la liste complète.