Skip to main content
локальные LLMtool callingAI automation

Petits LLM et Agents Locaux : Est-ce déjà possible ?

Un benchmark récent a testé des modèles open source de 3B-9B sur le code, le web scraping vers JSON et le 'tool calling'. C'est crucial pour les entreprises, clarifiant où l'automatisation par IA est viable avec 4 Go de VRAM et où il ne faut pas lésiner. Cela montre les limites pratiques.

Contexte Technique

J'apprécie ce genre de tests non pas pour les jolis graphiques, mais pour la question pragmatique qu'ils posent : peut-on mettre en place une véritable automatisation par IA en local, sans acheter un serveur dédié pour chaque petite tâche ? Ici, ils ont justement testé de petits modèles ouverts de 3B-9B sur trois tâches que l'on pourrait confier sans hésiter à un vrai développeur.

Les scénarios étaient pertinents : ajouter de petites fonctionnalités au frontend et au backend, trouver des données sur internet, les filtrer et les enregistrer en JSON, puis tester séparément le 'tool calling'. Et c'est sur ce troisième point que les discussions sur les "agents locaux à bas coût" s'effondrent généralement.

Concernant la VRAM, le tableau est encourageant : il est ressorti que certains de ces modèles tiennent dans environ 4 Go maximum, surtout avec une quantification 4 bits. Pour les modèles 3B, c'est déjà une plage de travail viable si l'on n'augmente pas trop le contexte et qu'on n'ajoute pas une lourde boucle agentique avec une multitude d'outils.

Côté modèles, je me tournerais vers des familles comme SmolLM3-3B, Gemma 3 4B et certaines variantes 7B-9B uniquement si vous gérez la mémoire méticuleusement. Pour du code simple et du traitement de données, les petits modèles ne font plus figure de jouets. Cependant, leur 'tool calling' reste capricieux : ils s'en sortent avec des outils simples, mais commencent vite à halluciner le parcours dans une logique à plusieurs étapes.

C'est précisément là que je ne confondrais pas "sait appeler une fonction" et "sait fonctionner de manière stable dans un workflow agentique". Ce sont deux niveaux d'exigence très différents.

Impact sur l'Entreprise et l'Automatisation

La première conclusion est simple : l'intégration de l'IA en local est devenue plus réaliste pour des tâches ciblées. Si vous avez besoin de parser des données, de les filtrer, de les convertir en JSON, d'effectuer de petites opérations de développement ou de créer des utilitaires internes, un petit modèle de moins de 4 Go de VRAM peut déjà être plus économique et pratique que le cloud.

Le deuxième point est moins réjouissant : si votre processus dépend d'un 'tool calling' fiable, en particulier avec plusieurs étapes et une vérification des résultats, déployer de petits modèles sans filet de sécurité est risqué. J'ajouterais des validateurs stricts, une logique de relance et un routage vers un modèle plus puissant en cas d'échec.

Les équipes qui ont besoin d'un fonctionnement sur appareil, de confidentialité et de faibles coûts d'exploitation sont gagnantes. Celles qui espèrent remplacer un agent de production par un unique modèle "léger" sans un encadrement d'ingénierie solide seront perdantes.

Chez Nahornyi AI Lab, nous résolvons précisément ces problèmes limites pour nos clients : déterminer où un modèle local suffit et où une architecture IA appropriée avec un routage hybride est nécessaire. Si vos processus sont ralentis par des routines manuelles ou des appels API coûteux, mon équipe et moi pouvons vous aider à élaborer un développement de solution IA sans poudre aux yeux et avec une économie claire.

Alors que nous explorons les capacités des petits modèles dans les flux de travail agentiques et l'utilisation d'outils, il est crucial de considérer leurs défis de sécurité inhérents. Nous avons déjà expliqué comment les homoglyphes Unicode peuvent tromper les agents IA pour du phishing ou l'exécution de commandes malveillantes, un guide de sécurité essentiel pour une automatisation IA robuste et la mise en œuvre de l'utilisation d'outils.

Partager cet article