Comment FIM One utilise les modèles
FIM One a trois rôles de modèle :
Fast et Reasoning reviennent à General s’ils ne sont pas configurés. Pour les déploiements en production, la division en au moins deux modèles (General + Fast) offre le meilleur équilibre coût/qualité.
Ces rôles peuvent être configurés via des variables d’environnement ou via la fonctionnalité Model Groups de l’interface d’administration, qui permet de basculer en un clic entre des ensembles de modèles. Consultez Gestion des modèles pour le guide complet de l’interface d’administration.
Matrice de Sélection Rapide
Ce tableau énumère les combinaisons que nous recommandons, pas l’ensemble complet des fournisseurs que FIM One supporte. xAI (Grok), ByteDance Doubao, Mistral et tout relais compatible OpenAI fonctionnent ; consultez la Matrice de Capacités des Fournisseurs pour la liste complète et la façon dont chacun est routé.
Compatibilité de la sortie structurée
Le planificateur DAG de FIM One nécessite que le modèle retourne du JSON structuré valide. En interne, il essaie trois niveaux d’extraction dans l’ordre :- Appel de fonction natif — force le modèle à produire du JSON correspondant à un schéma via l’API d’appel d’outil. Le plus fiable.
- Mode JSON — demande
response_format: json_object. Garantit du JSON valide, mais n’impose pas la conformité au schéma. - Extraction en texte brut — analyse le JSON à partir de texte libre en dernier recours.
tool_choice forcé) offrent la meilleure fiabilité de planification. Si un modèle n’atteint que le niveau 2, la qualité de sa sortie dépend de la façon dont il suit les instructions du prompt — les modèles plus faibles peuvent produire du JSON valide qui ne correspond pas à la structure attendue.
Ce tableau est une aide à la sélection. La version faisant autorité, ancrée dans le code, incluant les états
tool_choice que chaque fournisseur accepte et ce que FIM One fait quand l’un d’eux est rejeté, se trouve dans la Matrice des capacités des fournisseurs.
Compatibilité de la réflexion / du raisonnement
Les différents fournisseurs implémentent la « réflexion » (raisonnement en chaîne de pensée) de manières fondamentalement différentes. Cela importe car le mode de réflexion peut entrer en conflit avec l’appel d’outils, et la sortie apparaît à différents endroits selon le fournisseur. FIM One gère tout cela de manière transparente — ce tableau vous aide à comprendre ce qui se passe sous le capot.Concepts clés
- Opt-in — la réflexion est désactivée par défaut ; vous l’activez via un paramètre API (par exemple,
reasoning_effort). Peut être désactivée sélectivement par appel. - Always-on — le modèle réfléchit toujours ; aucun paramètre API pour le désactiver. Vous devriez basculer vers une variante de modèle sans réflexion pour l’éviter.
- Au niveau du modèle — la réflexion est déterminée par l’ID de modèle que vous choisissez (par exemple,
deepseek-reasonervsdeepseek-chat), et non par un paramètre.
Matrice de compatibilité
Les détails par fournisseur derrière ce tableau, y compris la façon dont chaque niveau d’
effort est traduit et si la réflexion est rejouée aux tours suivants, se trouvent dans le tableau C de la matrice de capacités des fournisseurs LLM.
Comment FIM One gère chaque cas
reasoning_content au niveau de l’API (Claude, DeepSeek) : Le champ reasoning est lu directement de la réponse API et affiché dans le panneau Reasoning de l’interface utilisateur. Aucun post-traitement nécessaire.
Balises <think> dans le contenu (MiniMax, Qwen, QwQ et autres dérivés open-source) : FIM One supprime automatiquement les balises <think>...</think> du champ content et réachemine le texte de réflexion vers le panneau Reasoning. Cela fonctionne pour les réponses en streaming et non-streaming.
Les conflits entre FC forcé et thinking sont spécifiques à chaque fournisseur, et non une propriété des modèles pensants en général. Claude rejette la combinaison mais son thinking est optionnel, donc FIM One désactive le thinking pour cet appel en passant reasoning_effort=None et l’appel de fonction natif procède normalement. Kimi le rejette aussi, et son thinking est sélectionné par l’identifiant du modèle plutôt que par un paramètre, donc la solution est de désactiver Native Function Calling pour les modèles pensants. MiniMax pense à chaque appel et accepte quand même l’appel de fonction forcé, c’est pourquoi aucune solution de contournement ne s’applique à lui.
Chaîne de secours : Si l’appel de fonction forcé échoue pour une raison quelconque, FIM One bascule automatiquement : FC natif → mode JSON → extraction de texte brut. Cette approche à trois niveaux garantit que la planification fonctionne même avec les fournisseurs qui ont un support d’outils partiel.
Si vous utilisez un modèle qui pense toujours (MiniMax M2.7,
deepseek-reasoner) comme votre LLM principal, la sortie de réflexion apparaîtra dans le panneau Reasoning de chaque itération d’agent. C’est normal — cela n’affecte pas la fonctionnalité, et vous pouvez voir le processus de raisonnement du modèle.Détails du fournisseur
OpenAI
L’option la plus éprouvée. Les modèles OpenAI offrent le meilleur support natif des appels de fonction (tool-calling), ce qui impacte directement la fiabilité des agents. La famille GPT-5 (août 2025+) représente un saut générationnel majeur par rapport à GPT-4. Modèles recommandés :- Principal :
gpt-5.4(dernier flagship, mars 2026 — contexte 1M+, computer use) ouo3(meilleure précision de raisonnement) - Rapide :
gpt-5.4-mini(4.50 par MTok) ougpt-5.4-nano(le moins cher à 1.25 par MTok) - Budget Rapide :
gpt-5-mini(2.00) etgpt-5-nano(0.40) restent disponibles à des prix plus bas - Hérité :
gpt-4.1(toujours dans l’API, contexte 1M, bon pour le coding)
LLM_REASONING_EFFORT=medium — fonctionne nativement avec les modèles o-series et GPT-5.x. GPT-5.4 supporte reasoning_effort avec les niveaux none, low, medium, high, xhigh. La série o-series nécessite max_completion_tokens au lieu de max_tokens, que LiteLLM gère automatiquement. Remarque : /v1/chat/completions rejette les requêtes GPT-5.x qui combinent tools et raisonnement, donc FIM One utilise directement l’API Responses pour GPT-5.x, où les deux fonctionnent ensemble. Ce chemin porte également le raisonnement chiffré de chaque tour au suivant, de sorte qu’un agent construisant une réponse multi-étapes conserve ce qu’il a déjà élaboré au lieu de le redériver à chaque appel d’outil. Les endpoints sans route /v1/responses reviennent à chat completions avec un reasoning_effort: "none" explicite lors des étapes tool-use de l’agent, et FIM_GPT5_RESPONSES_MODE peut forcer l’un ou l’autre fallback manuellement. Les autres familles de modèles sur des endpoints compatibles OpenAI restent sur chat completions : elles ne gagnent rien avec Responses, et les shims proxy pour cela peuvent mal mettre en buffer le streaming. GPT-5.4 nécessite temperature=1, que FIM One gère automatiquement via le filtrage de paramètres de LiteLLM (drop_params).
Anthropic (Claude)
Claude excels at nuanced reasoning and complex multi-step tasks. FIM One connects via LiteLLM, which routes Anthropic models through their native API automatically. The current generation is Claude 4.6 (February 2026). Modèles recommandés :- Main:
claude-sonnet-4-6(best balance of capability and cost — 15 per MTok) - Fast:
claude-haiku-4-5(fast and cheap — 5 per MTok) - Premium:
claude-opus-4-6(most capable, 128K max output — 25 per MTok)
https://api.anthropic.com/v1/
Opus 4.6 and Sonnet 4.6 have a 1M context window (GA since March 13, 2026 — no beta header needed). Haiku 4.5 has a 200K context window.
Reasoning : Set LLM_REASONING_EFFORT=medium. LiteLLM routes Anthropic models through the native API, so reasoning_content (extended thinking) is fully returned and visible in the UI “thinking” step. Claude 4.6 and newer use Adaptive Thinking (thinking: {type: "adaptive"} plus output_config.effort) in place of a manual budget_tokens, which FIM One emits directly rather than relying on LiteLLM’s mapping. Anthropic requires temperature=1 while thinking is active, and the system enforces that for you: the request builder pins the value on Anthropic routes, and on models that reject sampling parameters outright it removes temperature altogether. Do not set LLM_TEMPERATURE=1 by hand. See Extended Thinking for details.
Google Gemini
Les modèles Gemini offrent des performances solides à des prix compétitifs via le point de terminaison compatible OpenAI de Google. La génération 3.x (fin 2025+) est un grand bond en avant — Gemini 3 Flash surpasse 2.5 Pro tout en étant 3 fois plus rapide. Remarque :gemini-3-pro-preview a été arrêté le 9 mars 2026 — utilisez gemini-3.1-pro-preview à la place.
Modèles recommandés :
- Stable (GA) :
gemini-2.5-pro(principal) +gemini-2.5-flash(rapide) — prêt pour la production - Dernier (Aperçu) :
gemini-3.1-pro-preview(principal) +gemini-3-flash-preview(rapide) +gemini-3.1-flash-lite-preview(rapide économique) — meilleures performances, mais en statut d’aperçu
https://generativelanguage.googleapis.com/v1beta/openai/
Raisonnement : reasoning_effort est pris en charge sur le point de terminaison de compatibilité — définissez LLM_REASONING_EFFORT=medium et cela fonctionne immédiatement.
DeepSeek
DeepSeek offre le meilleur rapport coût/performance du marché. V3.2 (décembre 2025) a unifié les lignées de chat et de raisonnement en un seul modèle, avec une tarification incroyablement basse. ID de modèles (tous deux soutenus par V3.2) :deepseek-chat— usage général (mode non-thinking)deepseek-reasoner— mode de raisonnement chaîne de pensée, retournereasoning_content
https://api.deepseek.com
Tarification : 0.42 par MTok (cache hit : $0.028) — de loin l’API frontier-class la moins chère.
Limites de sortie : la sortie maximale de deepseek-chat est de 8K tokens (doit être défini explicitement via max_tokens). La sortie maximale de deepseek-reasoner est de 64K tokens (inclut la chaîne de pensée).
V4 attendue avril 2026 : modèle multimodal avec paramètres en trillions et fenêtre de contexte de 1M. Attendez-vous à de nouveaux ID de modèles lors de son lancement.
Modèles nationaux chinois
Tous les principaux fournisseurs de modèles chinois exposent des points de terminaison compatibles avec OpenAI. Ceux-ci sont particulièrement performants pour les tâches en langue chinoise et offrent des tarifs locaux compétitifs.Qwen / 通义千问 (Alibaba Cloud)
Qwen 3.5 (février 2026) est la dernière génération — le flagship MoE 397B surpasse GPT-5.2 sur MMLU-Pro. Support de la langue chinoise le plus fort et tarification de classe frontière la moins chère (~$0.11/MTok en entrée).- URL de base (Chine) :
https://dashscope.aliyuncs.com/compatible-mode/v1 - URL de base (Global) :
https://dashscope-intl.aliyuncs.com/compatible-mode/v1 - Principal :
qwen3.5-plus(flagship, contexte 1M, 0.66 par MTok) ouqwen3-max(256K, le plus puissant) - Rapide :
qwen3.5-flash(0.22 par MTok) ouqwen-turbo(0.08 par MTok) - Raisonnement :
qwen3-maxavec paramètreenable_thinking: true(il n’y a pas d’ID de modèleqwen3-max-thinkingséparé)
ChatGLM / 智谱
GLM-4.7 et GLM-5 (2026) sont les derniers modèles. GLM-5 est le flagship MoE 745B approchant le niveau Claude Opus sur les tâches de codage/agent.- URL de base (Domestique) :
https://open.bigmodel.cn/api/paas/v4 - URL de base (Z.AI International) :
https://api.z.ai/api/paas/v4 - Principal :
glm-4.7(codage puissant, 2.20 sur Z.AI) - Rapide :
glm-4.7-flash(niveau gratuit !) ouglm-4.7-flashx(0.40, débit plus élevé) - Raisonnement :
glm-5(flagship MoE 745B, 3.20)
tool_choice forcé n’est pas supporté — seul "auto" fonctionne.
MiniMax
MiniMax M2.7 (18 mars 2026) est le dernier modèle, open-weight et obtient 80,2% sur SWE-Bench. M2.5 reste disponible comme option rapide/économique. MiniMax fournit deux points de terminaison API distincts pour différentes régions :- URL de base (Global/海外版) :
https://api.minimax.io/v1— pour les utilisateurs en dehors de la Chine continentale - URL de base (China/国内版) :
https://api.minimaxi.com/v1— pour les utilisateurs en Chine continentale (notez leisupplémentaire dansminimaxi) - Principal :
MiniMax-M2.7 - Rapide :
MiniMax-M2.5 - Vitesse :
MiniMax-M2.7-highspeed(coût 2x, latence inférieure)
Kimi / 月之暗面 (Moonshot)
Kimi K2.5 (janvier 2026) dispose d’un contexte de 256K et de performances de codage solides (76,8% SWE-Bench parmi les modèles open-source).- URL de base (Global) :
https://api.moonshot.ai/v1 - URL de base (Chine) :
https://api.moonshot.cn/v1 - Principal :
kimi-k2.5 - Rapide :
kimi-k2(sans réflexion, l’appel de fonction fonctionne) - Raisonnement :
kimi-k2-thinking(2.00 par MTok)
tool_choice ne fonctionne que lorsque le mode de réflexion est désactivé. Lorsque la réflexion est activée, seul "auto" est supporté.
Modèles locaux (Ollama)
Exécutez des modèles entièrement sur votre propre matériel — aucune clé API nécessaire, entièrement hors ligne. Ollama expose un point de terminaison compatible OpenAI prêt à l’emploi. Le paysage open-source a changé de manière spectaculaire — Qwen 3.5, Llama 4 et GPT-OSS (les premiers modèles à poids ouvert d’OpenAI) sont tous disponibles. URL de base :http://localhost:11434/v1
Modèles recommandés par VRAM :
Meilleur pour l’appel d’outils : Qwen 3/3.5 (32B+), GLM-4.7, GPT-OSS, Mistral — ces modèles ont un entraînement explicite pour l’appel de fonctions. Les modèles avec 14B+ paramètres sont le minimum pour un appel d’outils fiable ; 32B+ est fortement recommandé.
Plateformes de relais tiers
De nombreux utilisateurs accèdent à plusieurs fournisseurs de modèles via un seul service de relais (proxy). FIM One détecte automatiquement le protocole API correct en fonction des modèles de chemin d’URL — il suffit de remplirLLM_BASE_URL et cela fonctionne.
Fonctionnement
Lorsque votre URL de base pointe vers un relais tiers, FIM One inspecte le chemin d’accès de l’URL pour déterminer le protocole à utiliser :
Ordre de résolution : Champ de fournisseur DB explicite > correspondance de domaine (API officielles) > indice de chemin d’accès URL (plateformes de relais) > secours compatible OpenAI.
Exemple : Un relais, trois protocoles
Avec un seul compte relais, vous pouvez accéder à différents fournisseurs en changeant simplement le chemin d’URL de base :Étape par étape : Comment fonctionne la détection de chemin
Voici un exemple concret montrant ce qui se passe en interne lorsque vous configurez un relais :- FIM One détecte
/claudedans le chemin URL → détecte le protocole natif Anthropic - Le modèle est préfixé comme
anthropic/claude-sonnet-4-6pour le routage LiteLLM - Les requêtes utilisent le format
/v1/messagesd’Anthropic avec l’en-tête d’authentificationx-api-key reasoning_effort=mediumest traduit en paramètre natif Anthropicthinking(pas lereasoning_effortd’OpenAI)
Pourquoi cela importe
- Point de terminaison natif Anthropic vous donne un support approprié de
reasoning_content(extended thinking visible dans l’interface utilisateur), un format correct d’appel d’outils, et une authentificationx-api-key— des fonctionnalités perdues lors de l’utilisation de la traduction compatible OpenAI. - Point de terminaison natif Google vous donne des paramètres Gemini natifs et une authentification
x-goog-api-key. - Compatible OpenAI est le recours universel et fonctionne avec n’importe quel relais, mais les fonctionnalités spécifiques au fournisseur (comme la sortie extended thinking) peuvent ne pas être disponibles.
Si votre plateforme de relais utilise des conventions de chemin non standard (par exemple, pas de
/claude ou /anthropic dans l’URL), FIM One revient au protocole compatible OpenAI — qui fonctionne pour la plupart des cas d’usage. Pour un support complet du protocole natif, vous pouvez définir explicitement le champ provider via l’interface utilisateur de configuration du modèle admin.Les relais sont au mieux des efforts. Le comportement documenté de FIM One est garanti pour les points de terminaison de première partie, c’est-à-dire OpenAI, Anthropic, Google et d’autres fournisseurs servant directement leurs propres modèles. Les relais fonctionnent et sont largement utilisés, y compris pour les modèles qui ne sont accessibles que de cette façon, mais ce qu’un relais fait à une requête échappe à notre contrôle, donc ils ne portent aucune garantie. Rien n’est bloqué par nom d’hôte : la capacité est sondée par point de terminaison, et le comportement non supporté revient de lui-même. Avant de signaler un bug au niveau du modèle, reproduisez-le par rapport au point de terminaison de première partie.
Stratégie de Configuration
Principal vs Rapide : Quand diviser
- Diviser quand votre modèle principal est coûteux ou lent (par exemple,
gpt-5.4+gpt-5.4-nano). Le mode DAG exécute de nombreuses étapes en parallèle — utiliser un modèle rapide moins cher permet d’économiser des coûts significatifs. - Même modèle quand votre modèle est déjà bon marché (par exemple,
deepseek-chatpour les deux). La surcharge de gestion de deux modèles n’en vaut pas la peine.
Quand activer le raisonnement
- Activer pour les tâches analytiques complexes, la planification multi-étapes et les tâches nécessitant un jugement prudent
- Désactiver (par défaut) pour les tâches de routine, les Q&R simples et les déploiements sensibles aux coûts
- Le raisonnement augmente généralement le coût de 2 à 5 fois par requête — l’effort
mediumest un bon point de départ
Dimensionnement de la fenêtre de contexte
DéfinissezLLM_CONTEXT_SIZE pour correspondre à la fenêtre réelle de votre modèle :
Pour les modèles locaux, définissez explicitement
LLM_CONTEXT_SIZE et LLM_MAX_OUTPUT_TOKENS — les valeurs par défaut supposent des fenêtres de contexte à l’échelle du cloud que les modèles locaux ne peuvent pas supporter.