Compatibilité des fournisseurs LLM

​

Détection du fournisseur

1. Fournisseur explicite (champ DB ModelConfig.provider) — priorité la plus élevée. Si le fournisseur correspond à un domaine connu dans l’URL, aucun api_base n’est renvoyé (LiteLLM achemine nativement). Sinon, api_base est défini sur l’URL de relais.
2. Correspondance de domaine par rapport à KNOWN_DOMAINS — les points de terminaison API officiels sont reconnus par nom d’hôte.
3. Indice de chemin d’URL par rapport à PATH_PROVIDER_HINTS — courant sur les plateformes de relais comme UniAPI où /claude ou /anthropic dans le chemin indique le protocole en amont.
4. Secours — préfixe openai/ (générique OpenAI-compatible).

​

tool_choice — les quatre modes

​

Où tool_choice est utilisé

​

Moteur ReAct — tool_choice=“auto”

​

structured_llm_call — tool_choice=forced

​

Sortie structurée : les quatre niveaux de garantie

​

T1 et T2 ne sont pas interchangeables

​

Ce que coûte T2

• Un sous-ensemble de schémas. Le mode strict d’OpenAI exige additionalProperties: false pour chaque objet, ainsi que la présence de chaque propriété dans required ; l’optionalité s’exprime par une union avec null plutôt que par l’omission de required. La racine doit être un objet. Des limites s’appliquent au nombre total de propriétés et à la profondeur d’imbrication. La plupart des schémas écrits manuellement doivent être modifiés avant de pouvoir être utilisés.
• La compilation de la grammaire. La première requête utilisant un nouveau schéma entraîne une latence de compilation ponctuelle côté fournisseur. La réutilisation d’un schéma stable permet d’amortir ce coût ; générer un nouveau schéma pour chaque requête ne le permet pas.
• Une nouvelle source d’échec. Lorsqu’un modèle refuse de répondre, il renvoie un refus plutôt qu’un objet conforme au schéma ; l’appelant doit donc prévoir une branche pour ce cas.

​

Ce qu’aucun niveau ne garantit

​

Où se situe FIM One

1. La chaîne ne dispose d’aucun niveau avec validation du schéma vers lequel se replier. Lorsque le niveau 1 échoue, le niveau inférieur suivant est json_object, qui garantit uniquement que le texte peut être analysé. Il n’existe aucune étape intermédiaire qui continue d’imposer les champs.
2. La garantie du niveau 1 est plus faible que son nom ne le laisse penser. Sans strict, l’appel de fonction natif repose sur la variante non stricte antérieure à 2024 : le modèle respecte généralement le schéma, mais rien ne l’empêche d’omettre un champ obligatoire, d’inventer une clé ou de renvoyer une chaîne là où un nombre a été déclaré.
3. Sur les routes anthropic/, le niveau 2 n’est pas réellement T3. L’Anthropic Messages API ne possède pas de response_format, si bien que LiteLLM émule le mode JSON en injectant un préremplissage assistant. Il s’agit d’un mécanisme au niveau du prompt, ce qui place la garantie effective entre T4 et T3, plutôt qu’au niveau T3. Le piège du préremplissage Bedrock décrit ci-dessous correspond à l’échec manifeste de cette émulation ; le coût plus discret est que la garantie n’a jamais été celle que le nom du paramètre laissait entendre.
4. Le résultat n’est jamais validé ensuite par rapport au schéma. jsonschema n’est pas une dépendance. Les vérifications éventuelles sont effectuées par site d’appel, dans la fonction facultative parse_fn, et leur rigueur varie selon le site d’appel.
5. L’échec est absorbé au lieu d’être signalé. Presque tous les appelants transmettent default_value, si bien qu’une chaîne épuisée renvoie un objet d’apparence plausible au lieu de lever une exception. StructuredCallResult.level_used enregistre le niveau qui a produit la valeur, mais aucun site d’appel ne le lit ; de plus, sur le chemin default_value, il indique plain_text pour une chaîne qui, en réalité, n’a rien produit.

structured_llm_call: fn=classify_mode level=native_fc attempt=first calls=1
structured_llm_call: fn=annotate_tables level=json_mode attempt=reformat_retry calls=3

​

Prise en charge des fournisseurs pour chaque niveau

​

Le piège du prefill Bedrock

{"role": "assistant", "content": "{"}

ValidationException: This model does not support assistant message prefill.
The conversation must end with a user message.

1. Le modèle est résolu avec le préfixe anthropic/ (via correspondance de domaine ou indice de chemin URL).
2. response_format={"type":"json_object"} est transmis (le chemin de code json_mode dans structured_llm_call).
3. Le backend réel est AWS Bedrock (qui rejette le prefill).

​

Le correctif : json_mode_enabled

• Modèles configurés dans la DB : activez ou désactivez l’option dans Admin → Modèles → Paramètres avancés. L’indicateur est stocké dans ModelProviderModel.json_mode_enabled (TRUE par défaut).
• Modèles configurés via ENV : définissez LLM_JSON_MODE_ENABLED=false dans votre environnement.
• Effet : lorsqu’il est désactivé, abilities["json_mode"] renvoie False → response_format n’est jamais transmis → aucun préremplissage → Bedrock fonctionne. La chaîne de dégradation devient native_fc → plain_text, en ignorant entièrement l’appel json_mode voué à l’échec.
• Coût de cette désactivation : en pratique, le modèle renvoie toujours un JSON valide, car l’invite système le lui demande et extract_json() analyse de manière fiable le contenu libre des modèles modernes. Ce qui est perdu, ce n’est pas le résultat, mais la garantie : la chaîne s’arrête désormais à T4, où seul le prompt contraint le résultat. Sur une route anthropic/, cette perte est moins importante qu’il n’y paraît, puisque le mode JSON émulé n’offrait déjà pas de garantie au niveau du décodeur.

​

Modèles de raisonnement + tool_choice forcé

tool_choice 'specified' is incompatible with thinking enabled

​

Le correctif : tool_choice_enabled

• Modèles configurés en BD : basculer dans Admin → Models → Advanced → “Native Function Calling”. Le drapeau est stocké sur ModelProviderModel.tool_choice_enabled (par défaut TRUE).
• Modèles configurés par ENV : définissez LLM_TOOL_CHOICE_ENABLED=false dans votre environnement.
• Effet : lorsque désactivé, abilities["tool_choice"] retourne False → la chaîne de dégradation commence au Niveau 2 (json_mode) ou Niveau 3 (plain_text), en ignorant complètement native_fc. Cela élimine la pénalité d’~10s par appel structuré pour les modèles incompatibles.
• Agent ReAct non affecté : tool_choice_enabled contrôle uniquement la sélection d’outil forcée dans structured_llm_call. Le moteur ReAct utilise tool_choice="auto" (le modèle décide librement), qui fonctionne avec tous les modèles indépendamment de ce paramètre.

​

Matrice des capacités des fournisseurs

​

Tableau A : Routage des protocoles

• store=false maintient la conversation sans état côté fournisseur, et include=["reasoning.encrypted_content"] demande que la charge utile chiffrée soit renvoyée. Sans cet élément dans include, les éléments de raisonnement sont vides et leur rejeu ne produit silencieusement aucun effet.
• L’id côté serveur doit être supprimé d’un élément de raisonnement rejoué. Avec store=false, rien n’est enregistré côté fournisseur ; renvoyer l’identifiant provoque donc l’erreur Item with id 'rs_...' not found. Items are not persisted when 'store' is set to false. Le bloc encrypted_content contient à lui seul l’état ; supprimer l’identifiant n’entraîne donc aucune perte (sanitize_reasoning_item).

​

Table B: Conflits et solutions de contournement

​

Table C: Protocole de réflexion

​

Relay/proxy gotchas

​

Configuration recommandée par modèle

# Disable native_fc globally (for thinking-model-only deployments)
LLM_TOOL_CHOICE_ENABLED=false

# Disable json_mode globally (for Bedrock relay deployments)
LLM_JSON_MODE_ENABLED=false

​

Configuration de l’effort de raisonnement et de la réflexion

1. La température est gérée pour vous. Sur une route anthropic/ avec réflexion active, _build_request_kwargs épingle temperature à 1.0, ce que Bedrock exige. Les modèles qui rejettent complètement les paramètres d’échantillonnage (Opus 4.7 et 4.8, Fable 5, Mythos 5) ont temperature supprimé de la requête entièrement, réflexion ou non. Ne définissez pas LLM_TEMPERATURE=1 manuellement pour cela.
2. GPT-5.x maintient les outils et le raisonnement ensemble autant que possible. FIM One sonde d’abord le pont Responses pour GPT-5.x, car c’est la seule surface où les deux se combinent. Un endpoint sans route /v1/responses utilisable bascule vers les complétions de chat, le verdict est mis en cache par endpoint, et sur ce chemin une requête portant tools envoie un reasoning_effort explicite de none. Omettre le champ n’est pas équivalent, car la valeur par défaut du serveur n’est pas none.

​

Analyse défensive pour la sortie structurée

1. Objet unique au lieu de tableau. Certains modèles retournent {"steps": {"id": "1", "task": "..."}} (un objet d’étape unique) au lieu de {"steps": [{"id": "1", "task": "..."}]} (un tableau). L’analyseur détecte cela en vérifiant la présence de clés id ou task et enveloppe l’objet dans une liste.
2. Chaîne JSON double-encodée. Lorsque la sortie structurée revient à json_mode (qui manque d’application de schéma), certains fournisseurs retournent la valeur steps comme chaîne JSON plutôt que comme tableau natif — par exemple, {"steps": "[{\"id\": \"1\", ...}]"}. Cette chaîne peut également contenir des sauts de ligne littéraux (du formatage du modèle) qui cassent le json.loads standard. L’analyseur utilise extract_json_value() (qui inclut _repair_json_strings) pour gérer :
   • Les sauts de ligne littéraux à l’intérieur des valeurs de chaîne JSON
   • Les séquences d’échappement invalides (courantes avec le contenu LaTeX ou de code)
   • Autres particularités de sérialisation des couches de compatibilité
3. Enveloppe steps manquante. Le modèle peut retourner une seule étape comme objet de niveau supérieur sans la clé d’enveloppe steps. L’analyseur détecte id et task au niveau racine et enveloppe en conséquence.

​

Mise en cache des prompts (multi-fournisseur)

​

Architecture

• PromptSection — un fragment nommé avec soit un content: str statique, soit un content: Callable dynamique
• PromptRegistry — un magasin mémoïsé (les sections statiques se rendent une fois, les sections dynamiques se re-rendent par appel)
• DYNAMIC_BOUNDARY — un marqueur sentinel que le registre insère entre la dernière section statique et la première dynamique, afin que les appelants puissent diviser le prompt rendu au point de rupture du cache

• Préfixe statique (~95% du prompt) — identité, directives principales, descriptions d’outils
• Suffixe dynamique — date/heure actuelle, directive de langue par requête, contexte de transfert

​

Détection des capacités

​

Prise en charge de plusieurs fournisseurs

​

Observabilité

"cache": {
  "read_tokens": 1067,
  "creation_tokens": 0
}

​

ROI du cache multi-tour

​

Politique de relecture du raisonnement (exactitude sans modèle)

​

Quatre politiques

• anthropic_thinking — Famille Claude (y compris anthropic/, bedrock/anthropic, vertex_ai/claude). Les blocs de réflexion DOIVENT être relus avec signature attachée ; Anthropic rejette les tours suivants si la signature est manquante ou modifiée.
• informational_only — modèles qui émettent CoT mais n’ATTENDENT PAS de relecture : mode raisonnement DeepSeek (deepseek-reasoner sur V3.2, et les anciens ids deepseek-r1 et R1-Distill que la table de fragments correspond toujours), Qwen QwQ, Gemini flash-thinking, OpenAI o1 / o3 / o4. Leur documentation dit explicitement « n’envoyez pas reasoning_content dans l’historique des messages ». L’envoyer quand même :
  • Viole le contrat du fournisseur (peut commencer à rejeter dans les versions futures)
  • Invalide silencieusement leur cache de préfixe automatique — les octets du message mutent à chaque tour, cassant le hash
• openai_responses — GPT-5.x, appariés sur le fragment gpt-5. Son état de raisonnement n’est pas du texte mais une séquence d’éléments opaques portant des charges utiles chiffrées, et seul /v1/responses dispose d’un emplacement pour eux. Sur ce protocole, les éléments sont relus verbatim, ce qui maintient la chaîne de pensée du modèle vivante entre les tours d’outils. Le résumé lisible est toujours supprimé des requêtes sortantes, donc sur le fallback chat-completions, cela se comporte exactement comme informational_only. Vérifié avant les fragments informationnels, dont l’entrée générique reasoning engloutirait autrement les ids GPT-5 avec proxy-tag.
• unsupported — le fourre-tout : modèles sans capacité de raisonnement (GPT-4o, Gemini 1.5, Mistral, Llama), et modèles de raisonnement dont l’id ne correspond à aucun fragment (GLM, MiniMax, Kimi, Doubao). Aucun champ ne doit être relu dans les deux sens, donc cette politique place les mêmes octets sur le fil que informational_only. C’est aussi le défaut sûr pour les ids de modèle inconnus.

​

Application

​

Pour les utilisateurs

• Si vous basculez entre les agents Claude et DeepSeek dans la même conversation, l’historique est stocké avec les blocs de réflexion intacts ; au tour suivant, la forme du message sortant s’adapte selon le modèle actuel.
• Si vous utilisez un proxy / une sous-classe BaseLLM personnalisée, assurez-vous que son identifiant de modèle est reconnaissable (contient l’un des fragments) ou la politique unsupported par défaut s’appliquera — ce qui est sûr mais signifie que Claude derrière un proxy inhabituel pourrait perdre la relecture de la réflexion. Ajoutez le fragment d’identifiant de modèle à _CACHE_CAPABLE_MODEL_FRAGMENTS (dans core/prompt/caching.py) et/ou à la recherche de politique de réflexion.

​

Dépannage