Skip to main content
Cette page présente la référence détaillée des paramètres de requête proposés par Phaseo. Consultez-la pour savoir :
  • le rôle d’un paramètre
  • le type attendu
  • la plage habituelle ou les valeurs acceptées
  • s’il modifie la qualité, le coût, la latence ou le routage
Pour obtenir des conseils de réglage plutôt que des définitions de champs, consultez Paramètres d’inférence et Échantillonnage et décodage. La prise en charge des paramètres varie toujours selon le point de terminaison, le modèle et le fournisseur. Le tableau de démarrage rapide du modèle regroupe la prise en charge des fournisseurs actifs pour une route donnée.

Consultation rapide

Notes sur les points de terminaison

service_tier est pris en charge sur les principaux points d’entrée de requête textuelle : Utilisez ultrafast, fast (ou priority lorsqu’il est pris en charge) et flex uniquement si la combinaison modèle/fournisseur les accepte. Ultrafast sélectionne le niveau compatible le plus rapide ; fast et priority utilisent le même routage et tarif Fast. standard est la valeur par défaut si service_tier est omis. Batch n’est pas une valeur de service_tier. Les requêtes par lot utilisent l’API Batch distincte. Pour les requêtes Messages compatibles avec Anthropic, les valeurs natives en amont d’Anthropic sont auto et standard_only. Phaseo peut les normaliser ou les mapper entre fournisseurs tout en préservant le comportement compatible avec Anthropic sur /v1/messages. Si vous utilisez un SDK officiel Anthropic avec une URL de base personnalisée pointant vers Phaseo, privilégiez les valeurs natives Anthropic sur /v1/messages. Pour les contrôles de niveau normalisés entre fournisseurs comme ultrafast, priority et flex, ou l’alias fast d’OpenAI, préférez les requêtes HTTP brutes ou les API textuelles natives de la passerelle ou de style OpenAI.

Référence des paramètres

model

Sélectionne l’identifiant du modèle de la passerelle pour la requête. Sauf si vous souhaitez délibérément utiliser un alias accepté, utilisez l’identifiant canonique indiqué dans le guide de démarrage rapide de chaque modèle. Les identifiants canoniques sont les plus sûrs pour les exemples, l’automatisation et les intégrations durables.

stream

Renvoie la sortie progressivement via Server-Sent Events au lieu d’attendre le corps d’une réponse finale. Activez cette option pour les interfaces de chat, l’affichage token par token ou les longues réponses dont la réception anticipée améliore l’expérience. Désactivez-la pour obtenir une réponse JSON complète, simplifier les nouvelles tentatives ou faciliter l’analyse structurée. Remarques :
  • La prise en charge du streaming varie selon le point de terminaison.
  • Le streaming est généralement un choix de transport, pas un réglage de qualité.
  • Les flux avec appels d’outils ou sorties structurées peuvent aussi être diffusés différemment selon le fournisseur.

temperature

Contrôle le degré d’aléatoire dans la sélection des tokens. Les valeurs faibles produisent des sorties plus prudentes et reproductibles. Les valeurs élevées augmentent la variété, ce qui peut aider pour le brainstorming ou l’écriture créative, mais aussi réduire la cohérence et le respect du schéma. Cas d’usage adaptés :
  • extraction
  • classification
  • sortie JSON ou conforme à un schéma
  • génération créative
Conseils pratiques :
  • Commencez par une valeur faible pour les tâches structurées.
  • Modifiez d’abord temperature ou top_p, mais pas les deux.
  • Une température élevée combinée à une quantification agressive peut amplifier l’instabilité.

top_p

Applique l’échantillonnage par noyau en limitant les candidats au plus petit ensemble de tokens dont la probabilité cumulée atteint top_p. Les valeurs faibles limitent la masse de probabilité dans laquelle le modèle choisit, ce qui produit généralement une sortie plus sûre et ciblée. Les valeurs élevées lui permettent d’envisager davantage de tokens. Remarques :
  • Réglez top_p pour élargir ou réduire l’espace de recherche sans modifier directement la température.
  • Pour la plupart des applications, une valeur modérée de temperature et un top_p proche de 1,0 constituent une base raisonnable.

top_k

Chez les fournisseurs qui le proposent, limite l’échantillonnage aux k tokens candidats les mieux classés à chaque étape. Les valeurs faibles de top_k restreignent les choix du modèle et peuvent rendre la sortie plus prévisible. Les valeurs élevées élargissent l’ensemble de candidats. Remarques :
  • top_k n’est pas disponible chez tous les fournisseurs.
  • Considérez-le comme une limite du pool de tokens plus explicite que top_p.

max_tokens

Limite la longueur de sortie sur les points de terminaison et chez les fournisseurs qui utilisent encore le champ max_tokens. Utilisez-le pour maîtriser le coût, la latence et le risque de troncature. Une valeur trop faible peut produire une sortie qui semble incomplète alors que le modèle a fonctionné correctement.

max_output_tokens

Limite la longueur de sortie sur les routes qui utilisent max_output_tokens plutôt que max_tokens. Ce contrôle est sémantiquement équivalent à max_tokens, mais vous devez envoyer le nom de champ attendu par le point de terminaison ou l’interface du SDK sélectionnés.

max_completion_tokens

Limite la longueur de sortie sur les API textuelles récentes de style OpenAI qui utilisent max_completion_tokens. Il s’agit d’un autre champ de limite de tokens de sortie. Utilisez le nom attendu par le point de terminaison plutôt que de mélanger des alias de longueur de sortie dans une même requête.

frequency_penalty

Pénalise les tokens répétés proportionnellement à leur fréquence d’apparition. Augmentez cette valeur si le modèle tourne en boucle, répète des phrases ou réutilise trop souvent les mêmes termes.

presence_penalty

Pénalise la réutilisation d’un token dès sa première apparition, ce qui peut aider le modèle à explorer de nouveaux sujets ou de nouvelles formulations. Contrairement à frequency_penalty, il s’agit généralement d’un contrôle plus large de la nouveauté, plutôt que d’un contrôle du nombre de répétitions.

repetition_penalty

Applique un comportement anti-répétition propre au fournisseur, en dehors des champs de pénalité classiques de style OpenAI. Son objectif est similaire à celui de frequency_penalty et presence_penalty, mais sa sémantique varie davantage selon le fournisseur. Considérez-le comme un comportement natif du fournisseur plutôt que comme un contrôle identique partout.

seed

Demande un échantillonnage déterministe lorsque le fournisseur en amont prend en charge la génération avec seed. Utilisez-le pour le débogage, les tests de régression et la reproduction du comportement dans la mesure permise par la plateforme en amont. La génération avec seed améliore la reproductibilité, mais ne garantit pas un déterminisme exact chez tous les fournisseurs ni après des changements d’infrastructure.

stop

Définit une ou plusieurs séquences qui interrompent la génération avant son terme. Utile lorsque vous avez besoin de limites de sortie strictes, par exemple pour arrêter avant un pied de page, un séparateur d’outil ou la section synthétique suivante.

logprobs

Demande des métadonnées de probabilité au niveau des tokens si elles sont disponibles. Cette option sert surtout à l’analyse, à l’évaluation, au classement, au débogage et aux flux de travail liés à la confiance. Elle est rarement nécessaire pour les réponses produit standard.

top_logprobs

Demande les principaux tokens candidats alternatifs pour chaque position de sortie, ainsi que leurs probabilités logarithmiques. Utilisez-le pour examiner les branches de tokens alternatives plutôt que le seul token de sortie choisi.

tools

Déclare des outils ou des fonctions appelables pour les flux de travail de modèles utilisant des outils. Sauf indication contraire dans la documentation du point de terminaison, utilisez le schéma d’outil de style OpenAI. Les déclarations indiquent ce que le modèle peut appeler, pas ce qu’il doit appeler.

tool_choice

Détermine si le modèle peut appeler des outils automatiquement, ne doit pas en appeler ou doit en utiliser un en particulier. Utilisez none pour obtenir uniquement du contenu, auto pour laisser le modèle décider, et des valeurs plus strictes si l’orchestration en aval exige un appel d’outil.

parallel_tool_calls

Autorise ou interdit les appels d’outils simultanés sur les API compatibles. Désactivez-le si les systèmes en aval exigent une exécution strictement séquentielle, des effets de bord ordonnés ou des traces d’agent plus simples.

response_format

Demande un format de sortie précis, comme du texte brut, du JSON ou des réponses contraintes par un schéma. Les structures acceptées dépendent du point de terminaison et de l’adaptateur fournisseur. Utilisez ce paramètre si vous souhaitez autre chose que du texte libre, notamment pour les réponses JSON et l’extraction structurée.

structured_outputs

Signale la prise en charge de réponses structurées fiables ou contraintes par schéma pour la route et l’ensemble de fournisseurs sélectionnés. Dans les tableaux de démarrage rapide, cette valeur indique si le point de terminaison et les fournisseurs actifs prennent en charge de manière fiable les sorties structurées. Il vaut mieux l’interpréter comme une métadonnée de prise en charge.

json_schema

Fournit le schéma JSON utilisé pour imposer une sortie structurée sur les modèles et points de terminaison compatibles. Utilisez-le si votre application exige des champs garantis, une extraction typée ou un contrat de réponse strict. Limitez les schémas à la tâche pour améliorer leur respect.

reasoning

Contient la configuration de raisonnement propre au fournisseur pour les API capables de raisonnement. Selon la route, cela peut inclure l’activation, l’effort, le budget de tokens, le niveau de détail ou le renvoi du contenu de raisonnement.

reasoning_effort

Demande un budget de raisonnement plus faible ou plus élevé lorsque le point de terminaison et le modèle proposent ce réglage. Un effort plus élevé peut améliorer les tâches de raisonnement difficiles, au prix d’une latence et d’une consommation de tokens accrues. Un effort plus faible convient souvent mieux aux requêtes rapides et moins coûteuses.

reasoning_tokens

Représente un champ de tokens dédié au raisonnement lorsqu’il est pris en charge. Selon la route, il peut s’agir d’un réglage de requête, d’une limite ou d’un champ de comptabilisation de la réponse, plutôt que d’un paramètre universellement pris en charge.

include_reasoning

Demande le contenu ou des résumés de raisonnement dans les réponses si cette option est prise en charge. Utilisez-le avec précaution. Les données de raisonnement peuvent être volumineuses, indisponibles sur certains modèles et peu adaptées aux réponses de production qui n’ont pas besoin de détails de diagnostic supplémentaires.

service_tier

Sélectionne un niveau de routage ou de tarification pris en charge sur les API textuelles compatibles. Utilisez ultrafast, fast (ou priority lorsqu’il est pris en charge) et flex uniquement si la combinaison modèle/fournisseur les accepte. Ultrafast sélectionne le niveau compatible le plus rapide ; fast et priority utilisent le même routage et tarif Fast. Omettez le champ pour conserver le niveau standard par défaut. Phaseo mappe en interne ces valeurs de niveau normalisées par la passerelle vers les contrôles natifs des fournisseurs. Les appelants peuvent ainsi utiliser les mêmes valeurs service_tier sur les interfaces textuelles prises en charge. Remarques :
  • Batch correspond à un flux d’API distinct, pas à une valeur de niveau de service.
  • La prise en charge varie selon le point de terminaison et le fournisseur.

prompt_cache_key

Fournit une clé d’affinité de cache stable pour le routage tenant compte du cache de prompts. Utilisez-le lorsque plusieurs requêtes partagent des préfixes de prompt stables et devraient privilégier le même fournisseur ou la même région en amont. Phaseo peut aussi déduire l’affinité de cache du contexte de la requête, mais une clé explicite convient mieux aux longues conversations, aux sessions d’agent et aux flux répétés.

prompt_cache_options

Transmet les contrôles du cache de prompts OpenAI sur les routes OpenAI compatibles. Pour GPT-6 Astra, utilisez {"mode":"explicit","ttl":"30m"} pour activer explicitement le cache des prompts. Phaseo conserve cet objet lors de la normalisation des requêtes et le transmet inchangé à OpenAI.

cache_control

Applique une politique de cache de prompts indépendante du fournisseur sur les interfaces de requête textuelle prises en charge. Utilisez cache_control au niveau supérieur des requêtes Chat Completions, Responses et Anthropic Messages pour transmettre la même indication de cache via le schéma commun de la passerelle. Vous pouvez également le placer sur des blocs de contenu compatibles pour définir des points de séparation explicites. Les valeurs TTL courantes sont 5m et 1h, selon la prise en charge du fournisseur et du modèle. Les alias propres aux fournisseurs, tels que provider_options.anthropic.cache_control et provider_options.google.cache_control, restent acceptés pour les intégrations natives.

prompt_cache_retention

Définit la politique de conservation du cache de prompts compatible avec OpenAI pour les requêtes prises en charge acheminées vers OpenAI. Utilisez-le pour transmettre les options de conservation du cache OpenAI sans les imbriquer dans les options propres au fournisseur. L’alias provider_options.openai.prompt_cache_retention reste accepté. Si les deux sont présents, la valeur de premier niveau prompt_cache_retention prévaut.

provider

Contient des contraintes de routage et des préférences de fournisseur. Utilisez-le pour définir les fournisseurs en amont autorisés à exécuter la requête, leur ordre de classement ou les exigences de conformité à respecter. Les champs courants incluent : quantizations suit le vocabulaire de routage des fournisseurs compatible avec OpenRouter et est accepté dans provider comme dans routing. La correspondance ne tient pas compte de la casse et ignore espaces, tirets et traits de soulignement ; les noms sans ambiguïté comme float8/FP8 et bfloat16/BF16 sont des alias. Les offres sans métadonnées de quantification sont exclues dès que ce filtre est présent. Si aucune offre admissible ne correspond, la passerelle renvoie une erreur indiquant les quantifications demandées et disponibles au lieu de router silencieusement vers une autre variante.

provider_options

Contient des paramètres de transmission propres au fournisseur qui ne doivent pas être normalisés dans la structure de requête commune de la passerelle. Exemples :
  • openai.context_management
  • openai.prompt_cache_retention
  • anthropic.cache_control
  • google.cache_control
  • google.cached_content
Utilisez-le pour bénéficier d’une fonctionnalité native du fournisseur tout en gardant le reste de la requête dans le schéma commun de la passerelle. Privilégiez cache_control au niveau supérieur pour les indications de cache courantes et prompt_cache_retention au niveau supérieur pour la conservation compatible avec OpenAI. Pour des exemples de cache de prompts par fournisseur dans Chat Completions, Responses et Anthropic Messages, consultez Cache de prompts.

meta

Demande des métadonnées supplémentaires dans la réponse si cette option est prise en charge. Utilisez-le pour ajouter des métadonnées de réponse non essentielles au débogage, à l’analyse ou à l’inspection en aval.

usage

Demande le détail de l’utilisation si cette option est prise en charge. Utile si vous souhaitez inclure explicitement le décompte des tokens ou de l’utilisation dans le corps de la réponse, plutôt que de vous fier uniquement aux en-têtes ou aux tableaux de bord.

debug

Active des diagnostics contrôlés des requêtes et du routage. Les champs de débogage pris en charge incluent : Les charges utiles de débogage peuvent contenir des éléments sensibles du contexte de la requête. Utilisez-les uniquement en développement ou dans des environnements strictement contrôlés.

Exemple de requête

Explications détaillées

Pour obtenir des conseils plus approfondis sur le réglage plutôt qu’une simple référence des champs, consultez :
  • Paramètres d’inférence pour des conseils pratiques sur temperature, top_p, top_k, les limites de tokens, les séquences d’arrêt et le réglage
  • Échantillonnage et décodage pour comprendre comment l’aléatoire, les pénalités et les contrôles de décodage influencent le modèle

Pages associées

Dernière modification le 2 octobre 2026