IBM Granite 4.1 : l'effet de la langue, testé sur GPU local

Hier soir, je suis rentré d'une conférence à Osaka. Un événement European Night avec des dizaines de chercheurs en IA et robotique — des profils solides, habitués à lire des papiers, à manipuler des modèles, à suivre l'état de l'art.

J'ai présenté quelque chose que je creuse depuis plusieurs mois : la langue dans laquelle vous interrogez un LLM ou SLM n'est pas neutre. Plus précisément, utiliser la langue native d'entraînement d'un petit modèle peut faire exploser ses performances.

La réaction dans la salle m'a surpris. Personne ne connaissait ce principe. Des chercheurs confirmés, habitués aux benchmarks, qui n'avaient pas investigué cet angle. Ce sont ces moments qui confirment qu'une découverte mérite d'être documentée sérieusement.

Ce soir, je vous la documente — avec les chiffres que j'ai présentés, et un nouveau modèle qui m'a lui-même surpris : IBM Granite 4.1, et ses performances en allemand.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Ce que j'ai expliqué aux chercheurs

Si vous suivez ce blog, vous savez que je travaille sur une commande /deliberate qui enregistre les nœuds de raisonnement d'un LLM en base de données, clusterise ces nœuds par similarité sémantique, et mesure les convergences entre plusieurs traits cognitifs indépendants.

J'ai d'abord découvert cet effet sur Claude : la langue modifie structurellement le raisonnement. Le turc force le marquage épistémique. Le japonais impose une ontologie hiérarchique. Ce ne sont pas des anecdotes — ce sont des patterns mesurables, enregistrés en base.

Puis j'ai testé sur qwen3:4b, mon modèle local. Résultat identique : le chinois, langue majoritaire dans ses données d'entraînement, produit autant de convergences sémantiques que Claude Haiku en anglais. Un modèle de 4 milliards de paramètres, dans la bonne langue, rivalise avec un modèle commercial.

Ce que j'ai présenté à Osaka est la généralisation de ce principe :

Pour les SLMs, la langue d'entraînement n'est pas un paramètre neutre. C'est un levier de performance.

La raison intuitive : les petits modèles ont une capacité limitée. Quand vous les interrogez dans une langue qu'ils ont vue massivement à l'entraînement, ils accèdent à leurs connaissances via les chemins les plus denses de leur graphe de poids. Dans une langue sous-représentée, ils font de la traduction interne — et perdent de la précision sur la tâche principale.

Les chercheurs dans la salle travaillaient principalement avec des modèles 7B+ en anglais. Ce principe — choisir délibérément la langue selon le modèle, pas selon votre propre confort — n'avait jamais été leur angle d'attaque.

IBM Granite 4.1 — ce que c'est

Pour illustrer concrètement ce principe, j'avais un exemple frais : IBM Granite 4.1, sorti sous licence Apache 2.0.

Quelques caractéristiques techniques qui le distinguent :

Trois points qui expliquent mon intérêt :

1. 2 586 MB de VRAM — sur un GPU de 6 Go comme mon RTX 3050, c'est très compact. Presque deux fois moins consommateur que qwen3:4b (4 100 MB).
2. 91 tokens/seconde — 1,5 fois plus rapide que qwen3:4b sur la même machine.
3. 12 langues officielles, dont l'allemand en première position.

IBM déclare l'avoir optimisé pour le RAG et le tool calling. Ce sont précisément les cas d'usage qui m'intéressent dans mon infrastructure.

L'expérience qui m'a surpris

J'avais testé granite4.1:3b avec mon pipeline /deliberate — cinq cas de raisonnement abstractif, juge externe Gemini 2.5 Flash, en faisant varier uniquement la langue.

Voici les résultats :

L'allemand dépasse l'anglais de 20 points de score. Le français et le chinois décrochent nettement. Le japonais est catastrophique.

Même constat sur une suite plus difficile — deliberate-math-5b, cinq cas de niveau avancé, tous en allemand :

Un modèle de 3 milliards de paramètres, en allemand, qui comprend l'argument diagonal de Cantor, le sure-thing principle d'Ellsberg, et la régularisation implicite dans le double descent. C'est surprenant pour un modèle de cette taille.

La raison est probablement celle-ci : l'allemand est très présent dans les données d'entraînement IBM — le corpus incluant une large proportion de textes scientifiques et techniques en allemand, notamment issus de la recherche européenne.

Granite4.1 vs qwen3:4b — à leur meilleur

La comparaison honnête : chaque modèle dans sa langue optimale, sur les cinq cas les plus difficiles (deliberate-math-6, niveau GPQA / HLE).

qwen3:4b domine sur le score global. Mais les deux modèles réussissent des cas différents — ils sont complémentaires, pas substituables.

Granite4.1 gagne sur deux dimensions pratiques majeures : la vitesse (1,5× plus rapide) et l'empreinte VRAM (−37 %). Sur un GPU de 6 Go, c'est décisif pour les architectures agents où plusieurs modèles doivent cohabiter.

Ce que ça change dans la pratique

À Osaka, j'ai synthétisé le principe en une recommandation concrète pour les équipes présentes :

Avant de choisir un modèle, identifiez ses langues d'entraînement dominantes. Puis adaptez votre prompt en conséquence — même si ce n'est pas votre langue de travail habituelle.

Ce n'est pas du prompt engineering exotique. C'est de la physique du modèle.

Pour Granite 4.1 : utilisez l'allemand pour les tâches de raisonnement abstractif, l'anglais ou l'allemand pour les pipelines RAG et tool calling.

Pour qwen3:4b : le chinois pour les tâches deliberate, l'anglais reste correct pour les tâches FORMAT/SEMANTIC.

Un corollaire moins évident : évitez de mélanger les langues dans un même pipeline. Un agent qui reçoit ses instructions en français, traite des données en anglais, et produit une réponse en allemand divise les ressources du modèle entre trois sous-espaces de poids. La cohérence linguistique est un levier d'optimisation sous-estimé.

VRAM, vitesse, et cas d'usage recommandés

Pour ceux qui gèrent des GPU contraints — 6 à 8 Go de VRAM — voici un résumé pratique :

Avec seulement 2,6 Go de VRAM, granite4.1:3b laisse de la marge pour un second modèle dédié aux embeddings. C'est une configuration que je vais tester dans les prochaines semaines.

Pour aller plus loin

Granite 4.1 est disponible sur Ollama : ollama pull granite4.1:3b.

Les questions que j'explore maintenant :

1. L'effet langue est-il linéaire avec la taille ? Un granite4.1:8B en allemand garde-t-il le même avantage relatif, ou l'effet s'efface-t-il à mesure que le modèle grandit ?
2. L'arabe et le coréen sont dans les 12 langues officielles — je n'ai pas encore testé ces deux langues sur les tâches deliberate. L'arabe classique, notamment, a des propriétés grammaticales qui pourraient révéler des dimensions inattendues.
3. Un duo granite4.1 + qwen3:4b dans un pipeline hybride — granite pour les tâches rapides, qwen3 pour le raisonnement profond — tient dans 6 Go si on alterne via KEEP_ALIVE Ollama.

La prochaine fois que vous benchmarkez un SLM, ne changez pas seulement le prompt — changez la langue. Vous risquez d'être surpris.

Pour aller plus loin dans la série : Japonais et IA — 5 concepts qui révèlent l'architecture cachée des LLM et qwen3:4b résout des problèmes GPQA Diamond. 

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.