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

​

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 via BD : basculer dans Admin → Models → Advanced settings. L’indicateur est stocké sur ModelProviderModel.json_mode_enabled (par défaut TRUE).
• Modèles configurés via ENV : définir LLM_JSON_MODE_ENABLED=false dans votre environnement.
• Effet : lorsque désactivé, abilities["json_mode"] retourne False → response_format n’est jamais passé → pas de prefill → Bedrock fonctionne. La chaîne de dégradation devient native_fc → plain_text, en ignorant entièrement l’appel json_mode voué à l’échec.
• Aucune perte de qualité : le modèle retourne toujours du JSON valide car le system prompt l’impose. Le niveau plain_text utilise extract_json() pour analyser le JSON à partir de contenu libre, ce qui fonctionne de manière fiable avec les modèles modernes.

​

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

​

Table A: Routage des protocoles

• store=false garde la conversation sans état en amont, et include=["reasoning.encrypted_content"] demande que la charge utile chiffrée soit retournée. Sans l’include, les éléments de raisonnement arrivent vides et la relecture devient silencieusement un non-opération.
• Un élément de raisonnement rejoué doit avoir son id côté serveur supprimé. Avec store=false rien n’est persisté en amont, donc renvoyer l’id en arrière gagne Item with id 'rs_...' not found. Items are not persisted when 'store' is set to false. La charge utile encrypted_content porte l’état par elle-même, donc supprimer l’id ne coûte rien (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

​

Couverture multi-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