Payer GPT-4o ou Claude Opus à chaque étape d'un agent, c'est rentable pour un prototype. Pour un agent qui boucle 10 à 30 fois par tâche en production, ça fait exploser la facture. Le fine-tuning function calling sur un SLM (petit modèle de langage) change l'équation : on spécialise un modèle de 7B ou 14B paramètres pour qu'il appelle les bons outils, au bon format JSON, de façon fiable — et on le fait tourner en local ou sur un GPU dédié pour 10 à 50 fois moins cher.
Cet article explique pourquoi le function calling est le cas d'usage le plus rentable du fine-tuning sur un petit modèle, comment construire le dataset de traces, quels modèles (Qwen2.5, Ministral, Hermes) partent le mieux, et comment éviter les quatre pièges qui font échouer ce type de projet.
Pourquoi un agent multiplie les coûts — et comment un SLM résout le problème
Un agent IA n'est pas un chatbot qui répond en un seul appel. C'est une boucle : l'agent reçoit une tâche, décide quel outil appeler, interprète le résultat, décide du prochain outil, et ainsi de suite jusqu'à la réponse finale.
Sur une tâche de complexité moyenne, ça donne facilement 8 à 15 appels de modèle. Avec GPT-4o à 15 $/million de tokens en entrée, une tâche qui mobilise 2 000 tokens par appel sur 10 étapes coûte 0,30 $ par exécution. Multipliez par 1 000 exécutions par jour : 90 000 $/an. Et la latence s'accumule : chaque appel prend 1 à 3 secondes, soit 10 à 30 secondes d'attente sur l'ensemble de la boucle.
La plupart des étapes d'un agent sont pourtant routinières. Décider quel outil appeler parmi 10 fonctions définies, extraire les paramètres depuis une instruction, formater la réponse en JSON conforme au schéma : ce n'est pas du raisonnement complexe. C'est de la reconnaissance de pattern, précise et répétitive.
Un SLM fine-tuné pour cette tâche précise tourne en 200 à 500 ms sur un GPU A10 ou L4, pour un coût d'inférence 10 à 50 fois inférieur. La clé, c'est le mot "fine-tuné" : un SLM généraliste fait n'importe quoi avec des appels d'outils. Un SLM fine-tuné sur vos traces d'appels devient fiable sur votre périmètre.
Quel dataset pour entraîner un SLM au function calling
Le point de départ, c'est les traces. Chaque exemple du dataset est un triplet :
- Le contexte système : la liste des outils disponibles et leurs schémas JSON (nom, description, paramètres requis et optionnels, types).
- L'instruction utilisateur : ce que l'utilisateur ou l'orchestrateur demande, formulé de façons variées.
- L'appel d'outil attendu : le JSON exact que le modèle doit produire, avec le nom de la fonction et les arguments correctement extraits.
Sur 5 à 20 outils, 500 à 2 000 traces de qualité suffisent pour un fine-tuning LoRA. La qualité prime : chaque instruction doit exister en plusieurs formulations (formelle, abrégée, avec fautes de frappe, avec contexte implicite). Un dataset trop uniforme produit un modèle qui hallucine dès qu'une instruction sort du patron vu à l'entraînement.
Pour démarrer, deux datasets publics évitent de tout annoter à la main :
- ToolACE (arXiv 2409.00920) : 26 000 traces sur 400 domaines, format compatible avec les principaux frameworks.
- xLAM (Salesforce) : 60 000 exemples multi-tours avec gestion des erreurs d'outils, idéal pour les agents réactifs.
On complète ensuite avec les traces propres à votre périmètre d'outils : quelques centaines d'exemples annotés par l'équipe qui connaît le métier. C'est ce mélange — base publique + traces maison — qui donne les meilleurs résultats en pratique.
Pour une méthode détaillée de construction de dataset, consultez notre guide sur la préparation d'un dataset de fine-tuning LLM.
Qwen2.5, Ministral, Hermes : les SLM qui partent le mieux
Tous les modèles de 7B à 14B ne se valent pas pour le function calling. Voici l'état du terrain en 2026 :
| Modèle | Taille | Force function calling | Format natif | Licence |
|---|---|---|---|---|
| Qwen2.5-7B-Instruct | 7B | Excellent — pré-entraîné sur fort signal tool-use | OpenAI tools + ToolACE | Apache 2.0 |
| Qwen2.5-14B-Instruct | 14B | Très bon — meilleur sur les schémas complexes | OpenAI tools + ToolACE | Apache 2.0 |
| Ministral-8B-Instruct | 8B | Bon — compact, faible latence | Mistral tool_calls | MRL 0.1 |
| Hermes-3-Llama-3.1-8B | 8B | Très bon — entraîné spécifiquement sur tool use | Nous-Hermes tool calls | Llama 3.1 |
| Hermes-3-Llama-3.1-70B | 70B | Excellent — mais nécessite plus de GPU | Nous-Hermes tool calls | Llama 3.1 |
Qwen2.5 est notre point de départ par défaut pour les périmètres d'outils complexes. Alibaba a inclus un signal tool-use massif dans le pré-entraînement, ce qui se traduit par un taux d'appels valides élevé même avant fine-tuning — le fine-tuning n'a donc qu'à ajuster à votre périmètre précis, pas à apprendre le concept depuis zéro.
Ministral 8B est notre choix quand la contrainte principale est la latence : il tourne vite sur un GPU L4 ou A10, avec une empreinte mémoire raisonnable, et Mistral AI maintient activement son support du format function calling.
Hermes 3 (NousResearch) se distingue par son dataset d'entraînement public et sa communauté active. C'est le modèle le plus documenté sur les cas d'usage d'agents multi-outils, avec des exemples explicites de gestion des appels en parallèle et des appels imbriqués.
Pour une comparaison plus large des SLM disponibles, voir notre article dédié aux SLM pour l'entreprise.
Grammaires contraintes et JSON mode : garantir un JSON valide
Le fine-tuning réduit drastiquement le taux de JSON invalide. Il ne le descend pas à zéro — surtout sur des instructions inhabituelles ou des schémas avec des types complexes (unions, tableaux imbriqués, propriétés optionnelles multiples).
Pour les cas où un JSON invalide est bloquant (l'agent ne peut pas parser la réponse et boucle en erreur), on ajoute une couche de décodage contraint :
outlines — décodage contraint par schéma JSON
outlines (bibliothèque Python, dépôt dottxt-ai/outlines) intercepte la génération token par token et masque les tokens incompatibles avec le schéma JSON cible. Le modèle ne peut littéralement pas produire un JSON invalide : chaque token généré est contraint par l'état courant du parseur. On passe le schéma Pydantic ou JSON Schema de la fonction cible, et outlines fait le reste.
Résultat mesuré sur des tâches de function calling : le taux de JSON invalide tombe à 0 % sur le périmètre couvert par le schéma, quelle que soit la qualité du modèle de base.
vLLM guided decoding et grammaires GBNF
vLLM intègre un mode guided_json depuis la version 0.4 : on passe le schéma JSON dans le paramètre de la requête et vLLM applique le décodage contraint côté serveur. Idéal quand on sert le SLM via une API compatible OpenAI, car le client ne change pas.
Pour les déploiements avec llama.cpp, les grammaires GBNF remplissent le même rôle : on définit la grammaire de la sortie attendue (un objet JSON avec tel nom de champ de tel type) et llama.cpp contraint la génération.
Ces trois outils (outlines, vLLM guided decoding, llama.cpp grammars) sont complémentaires au fine-tuning, pas en opposition. Le fine-tuning apprend au modèle à choisir le bon outil et les bons arguments ; le décodage contraint garantit que le format est valide même sur les cas limites.
Gros LLM vs SLM fine-tuné : le vrai tableau comparatif pour un agent
Voici les ordres de grandeur constatés en production, sur un agent avec 12 outils disponibles, 10 appels de modèle par tâche en moyenne :
| Critère | GPT-4o (API) | SLM 7-8B fine-tuné | SLM 14B fine-tuné |
|---|---|---|---|
| Coût par tâche (10 appels) | 0,20 – 0,40 $ | 0,01 – 0,03 $ | 0,02 – 0,06 $ |
| Latence par appel | 1 000 – 3 000 ms | 200 – 500 ms | 350 – 700 ms |
| Taux d'appels JSON valides (périmètre ciblé) | 95 – 99 % | 90 – 97 % (98 – 100 % avec décodage contraint) | 93 – 98 % (98 – 100 % avec décodage contraint) |
| Gestion des schémas complexes | Excellente | Correcte après fine-tuning | Bonne après fine-tuning |
| Raisonnement hors périmètre d'outils | Excellent | Limité | Moyen |
| Données envoyées à un tiers | Oui (OpenAI) | Non (hébergement local) | Non (hébergement local) |
| Mise à jour du périmètre d'outils | Immédiate (prompt) | Réentraînement nécessaire | Réentraînement nécessaire |
La conclusion est sans surprise : sur les étapes routinières d'un agent à périmètre d'outils stable, le SLM fine-tuné gagne sur le coût et la latence, avec une fiabilité équivalente quand on ajoute le décodage contraint. Pour l'orchestration de haut niveau et les décisions de planification complexes, le gros LLM reste utile.
L'architecture hybride la plus courante en production : un SLM fine-tuné pour les étapes d'exécution (sélection d'outil, extraction de paramètres, formatage de réponse), et un modèle plus puissant pour le plan initial et l'interprétation des résultats ambigus. Les frameworks d'agents comme ceux comparés dans notre article sur les frameworks agents IA permettent de mixer les modèles par étape.
Si vous cherchez à déployer cette architecture sur votre infrastructure, notre page expert en fine-tuning LLM et agents détaille notre approche et les étapes d'accompagnement.
Les pièges à éviter absolument
Quatre problèmes reviennent systématiquement sur les projets de fine-tuning pour le function calling :
JSON invalide malgré le fine-tuning
Cause la plus fréquente : un dataset trop homogène. Si toutes vos traces suivent exactement le même patron d'instruction, le modèle mémorise le patron sans généraliser. Remède : inclure des exemples avec des reformulations, des instructions ambiguës, et — c'est contre-intuitif — quelques exemples d'erreurs corrigées (l'instruction difficile + le bon appel d'outil). Et ajouter le décodage contraint pour les cas critiques.
Hallucination d'outils inexistants
Le modèle invente un nom de fonction absent du schéma fourni. Ça arrive quand le prompt système ne liste pas explicitement les outils disponibles, ou quand le dataset contenait des traces avec des outils que le modèle a mémorisés. Remède : toujours inclure la liste exhaustive des outils dans le prompt système à l'inférence, et vérifier que le dataset de fine-tuning ne contient que des outils présents dans ce référentiel.
Sur-spécialisation sur un périmètre figé
Le fine-tuning fige le modèle sur le périmètre d'outils vu à l'entraînement. Dès qu'on ajoute une fonction ou qu'on modifie un schéma, les performances chutent. Si votre périmètre d'outils évolue régulièrement (tous les mois), le coût de réentraînement récurrent peut annuler les économies sur l'inférence. Dans ce cas, un gros LLM avec prompt engineering reste plus flexible.
Oubli de l'évaluation end-to-end
On voit souvent des projets qui affichent un taux de JSON valides de 95 % sur le dataset de test et un taux de complétion de tâches de 60 % en production. L'explication : les 5 % d'erreurs se concentrent sur les cas les plus fréquents ou les plus critiques. L'évaluation end-to-end sur des scénarios réels est non négociable avant de passer en production. Notre guide sur l'évaluation d'un modèle fine-tuné détaille la méthode.
Pour aller plus loin
- SLM pour l'entreprise : quel petit modèle choisir — panorama des modèles 1B à 14B disponibles et leurs cas d'usage.
- Préparer un dataset de fine-tuning LLM — méthode complète pour annoter des traces de qualité.
- Frameworks agents IA : comparatif 2026 — LangGraph, AutoGen, CrewAI, Haystack : lequel choisir pour votre architecture.
- LoRA et QLoRA : guide complet du fine-tuning efficace — paramètres d'entraînement, rank, alpha, choix des couches cibles.
- Déployer un LLM en production — vLLM, Triton, infrastructure GPU, monitoring et scalabilité.
- Évaluer un modèle fine-tuné et détecter l'overfitting — métriques, dataset de test, signaux d'alerte.
- Notre expertise fine-tuning LLM et agents — accompagnement de bout en bout sur vos projets SLM.
- ToolACE (arXiv 2409.00920) — dataset public de 26 000 traces function calling, référence pour le fine-tuning tool use.
- outlines (dottxt-ai) — librairie Python de décodage contraint par schéma JSON, la plus utilisée en production.
Vous hésitez encore ?
30 minutes pour évaluer si un SLM fine-tuné peut remplacer le gros LLM dans votre agent.
En résumé : le function calling est le meilleur ROI du fine-tuning sur SLM
Le raisonnement est simple. Un agent boucle. Chaque boucle coûte. Sur les étapes routinières — sélection d'outil, extraction de paramètres, formatage JSON — un SLM de 7B ou 14B bien entraîné fait le travail pour 10 à 50 fois moins cher et 5 fois plus vite qu'un gros LLM.
La condition : un dataset de traces propres, des modèles qui partent avec un bon signal tool-use (Qwen2.5, Ministral, Hermes), et un décodage contraint avec outlines ou vLLM pour les cas critiques.
Soyons honnêtes : ce n'est pas une solution universelle. Si votre périmètre d'outils change souvent, le réentraînement récurrent annule les économies. Si votre agent doit gérer des tâches de planification complexe, le SLM atteint ses limites. Mais pour un agent de traitement métier avec un périmètre d'outils stable, c'est l'approche la plus rentable qu'on connaisse aujourd'hui.
