Avant-Propos
Cet article est une republication de celui que j’ai rédigé sur le blog d’AlphaEdge.
Je les remercie de m’avoir permis de travailler sur ce sujet.
Le trimming étant particulièrement intéressant pour le multilinguisme, ce travail a été l’occasion d’une collaboration avec différents Hugging Face Fellows pour évaluer cette approche sur d’autres langues que le français ou l’anglais. À savoir Tom AARSEN (anglais/néerlandais), Bram VANROY (néerlandais), Christopher AKIKI (arabe/allemand), Woojun JUNG (coréen), Manuel ROMERO (espagnol) et Prithiv SAKTHI (Tamil).
Je tiens finalement à indiquer que l’estimation du temps de lecture est fortement surestimée du fait de nombreux tableaux de résultats (en html plutôt qu’en image), de références ou d’exemples de textes pour montrer les sorties obtenues avec les modèles trimmés (ainsi que potentiellement leur traduction en français quand ces exemples portent sur une autre langue)
Introduction
Dans cet article de blog, nous procédons à une introduction à la technique du trimming. Cette méthode simple, ne nécessitant pas de réentraînement et s’exécutant sur un simple CPU, permet d’obtenir un modèle plus léger que l’original tout en maintenant ses performances.
Dans la partie Pratique 👨💻 où nous avons effectué des expérimentations, nous listons les points essentiels dans des encadrés 🧠 À retenir. Une synthèse de tous les avantages de cette approche est également trouvable dans la conclusion.
Pour accompagner nos propos, nous dévoilons 5526 modèles issus de l’application de cette technique.
Théorie 👨🏫
Le trimming peut être vu comme un sous-ensemble du pruning. En effet, comme pour ce dernier, le but de la technique est de modifier/supprimer des poids du modèle pour le rendre in fine plus léger (que ce soit le nombre de paramètres ou sa taille mémoire).
Néanmoins la spécificité de cette méthode est que nous nous focalisons uniquement sur les parties de l’architecture en lien avec le vocabulaire, là où dans le cadre du pruning nous modifions généralement plutôt les poids/couches du reste de l’architecture (i.e. le backbone).
Ainsi, pour le trimming, nous supprimons des tokens dans le vocabulaire original du modèle (et par conséquent devons par la même occasion actualiser le tokenizer) mais modifions également la couche d’embedding finale gérant la distribution de probabilité du vocabulaire du modèle (de même pour la couche d’entrée si les embeddings sont partagés).
À quoi sert le trimming ?
Considérons un modèle avec une taille de vocabulaire donnée.
Cette taille peut ne pas être pertinente pour deux raisons principales :
1) Si notre modèle est multilingue ;
En effet, toutes les langues ne nous intéressent pas forcément. Il est alors possible de supprimer celles qui sont inutiles pour notre cas d’usage.
2) Si la taille du vocabulaire n’est pas un multiple de 8 ou de 64.
En effet, pour optimiser l’usage de ses GPU, ces multiples sont à privilégier (lire notamment ici et ici).
Cette préconisation simple permet d’accélérer facilement l’entraînement d’un modèle (de 25% d’après les observations de Karpathy). Notons que depuis 2023-2024, c’est un usage qui s’est répandu et les modèles utilisent ainsi généralement de base un multiple de 8 ou de 64 pour le vocabulaire. Cependant pour des modèles plus anciens, il peut être intéressant de modifier la taille (nous verrons ci-dessous dans la partie Pratique 👨💻 que 7 des 16 modèles testés ont ce problème).
Cette réduction de la taille du vocabulaire (aux langues d’intérêt et à un multiple de 8 ou 64) permet de réduire la taille du modèle (que ce soit le nombre de paramètres ou in fine sa taille mémoire). Illustrons ce point à travers un exemple simple : le GPT2-small de RADFORD, WU et al. (2019).
Ce modèle permet de comprendre facilement le cas 2) décrit à l’instant mais est aussi un exemple que le trimming fonctionne également sur des modèles monolingues (alors que dans la partie Pratique 👨💻 la plupart des exemples portent sur des modèles multilingues).
Calculons alors le nombre de paramètres du GPT2-small :
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("gpt2")
for name, param in model.named_parameters():
print(f"{name:50s} {str(param.shape):25s} {param.numel():>12,}")
Sortie complète :
# Sortie :
# transformer.wte.weight torch.Size([50257, 768]) 38,597,376
# transformer.wpe.weight torch.Size([1024, 768]) 786,432
# transformer.h.0.ln_1.weight torch.Size([768]) 768
# transformer.h.0.ln_1.bias torch.Size([768]) 768
# transformer.h.0.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.0.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.0.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.0.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.0.ln_2.weight torch.Size([768]) 768
# transformer.h.0.ln_2.bias torch.Size([768]) 768
# transformer.h.0.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.0.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.0.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.0.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.1.ln_1.weight torch.Size([768]) 768
# transformer.h.1.ln_1.bias torch.Size([768]) 768
# transformer.h.1.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.1.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.1.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.1.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.1.ln_2.weight torch.Size([768]) 768
# transformer.h.1.ln_2.bias torch.Size([768]) 768
# transformer.h.1.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.1.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.1.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.1.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.2.ln_1.weight torch.Size([768]) 768
# transformer.h.2.ln_1.bias torch.Size([768]) 768
# transformer.h.2.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.2.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.2.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.2.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.2.ln_2.weight torch.Size([768]) 768
# transformer.h.2.ln_2.bias torch.Size([768]) 768
# transformer.h.2.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.2.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.2.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.2.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.3.ln_1.weight torch.Size([768]) 768
# transformer.h.3.ln_1.bias torch.Size([768]) 768
# transformer.h.3.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.3.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.3.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.3.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.3.ln_2.weight torch.Size([768]) 768
# transformer.h.3.ln_2.bias torch.Size([768]) 768
# transformer.h.3.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.3.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.3.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.3.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.4.ln_1.weight torch.Size([768]) 768
# transformer.h.4.ln_1.bias torch.Size([768]) 768
# transformer.h.4.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.4.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.4.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.4.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.4.ln_2.weight torch.Size([768]) 768
# transformer.h.4.ln_2.bias torch.Size([768]) 768
# transformer.h.4.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.4.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.4.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.4.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.5.ln_1.weight torch.Size([768]) 768
# transformer.h.5.ln_1.bias torch.Size([768]) 768
# transformer.h.5.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.5.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.5.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.5.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.5.ln_2.weight torch.Size([768]) 768
# transformer.h.5.ln_2.bias torch.Size([768]) 768
# transformer.h.5.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.5.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.5.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.5.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.6.ln_1.weight torch.Size([768]) 768
# transformer.h.6.ln_1.bias torch.Size([768]) 768
# transformer.h.6.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.6.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.6.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.6.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.6.ln_2.weight torch.Size([768]) 768
# transformer.h.6.ln_2.bias torch.Size([768]) 768
# transformer.h.6.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.6.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.6.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.6.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.7.ln_1.weight torch.Size([768]) 768
# transformer.h.7.ln_1.bias torch.Size([768]) 768
# transformer.h.7.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.7.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.7.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.7.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.7.ln_2.weight torch.Size([768]) 768
# transformer.h.7.ln_2.bias torch.Size([768]) 768
# transformer.h.7.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.7.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.7.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.7.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.8.ln_1.weight torch.Size([768]) 768
# transformer.h.8.ln_1.bias torch.Size([768]) 768
# transformer.h.8.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.8.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.8.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.8.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.8.ln_2.weight torch.Size([768]) 768
# transformer.h.8.ln_2.bias torch.Size([768]) 768
# transformer.h.8.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.8.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.8.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.8.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.9.ln_1.weight torch.Size([768]) 768
# transformer.h.9.ln_1.bias torch.Size([768]) 768
# transformer.h.9.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.9.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.9.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.9.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.9.ln_2.weight torch.Size([768]) 768
# transformer.h.9.ln_2.bias torch.Size([768]) 768
# transformer.h.9.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.9.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.9.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.9.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.10.ln_1.weight torch.Size([768]) 768
# transformer.h.10.ln_1.bias torch.Size([768]) 768
# transformer.h.10.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.10.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.10.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.10.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.10.ln_2.weight torch.Size([768]) 768
# transformer.h.10.ln_2.bias torch.Size([768]) 768
# transformer.h.10.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.10.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.10.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.10.mlp.c_proj.bias torch.Size([768]) 768
# transformer.h.11.ln_1.weight torch.Size([768]) 768
# transformer.h.11.ln_1.bias torch.Size([768]) 768
# transformer.h.11.attn.c_attn.weight torch.Size([768, 2304]) 1,769,472
# transformer.h.11.attn.c_attn.bias torch.Size([2304]) 2,304
# transformer.h.11.attn.c_proj.weight torch.Size([768, 768]) 589,824
# transformer.h.11.attn.c_proj.bias torch.Size([768]) 768
# transformer.h.11.ln_2.weight torch.Size([768]) 768
# transformer.h.11.ln_2.bias torch.Size([768]) 768
# transformer.h.11.mlp.c_fc.weight torch.Size([768, 3072]) 2,359,296
# transformer.h.11.mlp.c_fc.bias torch.Size([3072]) 3,072
# transformer.h.11.mlp.c_proj.weight torch.Size([3072, 768]) 2,359,296
# transformer.h.11.mlp.c_proj.bias torch.Size([768]) 768
# transformer.ln_f.weight torch.Size([768]) 768
# transformer.ln_f.bias torch.Size([768]) 768
# ─────────────────────────────────────────────────────────────────────────────
# Total unique : 124,439,808
Sortie groupée par composant :
# ── Embeddings ──────────────────────────────
# wte.weight 38,597,376
# Sous-total : 39,383,808
# ── Encodage positionnel ────────────────────
# wpe.weight 786,432
# Sous-total : 786,432
# ── Blocs transformer (×12) ─────────────────
# Par bloc :
# ln_1.weight 768
# ln_1.bias 768
# attn.c_attn.weight 1,769,472
# attn.c_attn.bias 2,304
# attn.c_proj.weight 589,824
# attn.c_proj.bias 768
# ln_2.weight 768
# ln_2.bias 768
# mlp.c_fc.weight 2,359,296
# mlp.c_fc.bias 3,072
# mlp.c_proj.weight 2,359,296
# mlp.c_proj.bias 768
# Sous-total 1 bloc : 7,087,872
# Sous-total 12 blocs : 85,054,464
# ── LayerNorm finale ─────────────────────────
# ln_f.weight 768
# ln_f.bias 768
# Sous-total : 1,536
# ══════════════════════════════════════════════════
# Total unique : 124,439,808
Vue graphique :
Les 85 056 000 paramètres (les 12 blocs transformer + la LayerNorm finale) ne sont pas modifiés dans le cadre du trimming (il faudrait faire du pruning pour réduire cette partie), de même que les 786 432 paramètres de l’encodage positionnel (wpe.weight).
Par contre, avec cette technique, nous pouvons modifier les 38 597 376 paramètres de la couche d’embedding (wte.weight). Dans la sortie détaillée, nous pouvons voir que cette couche est de taille [50257, 768] soit un vocabulaire de taille 50 257 où chaque token est représenté sur 768 dimensions.
📝 Note
Cette information est également trouvable sur le Hub d'Hugging Face sans avoir à télécharger le modèle. Il faut consulter le widget "Files infos" qui est disponible pour tous les modèles du Hub dont les poids ont été poussés au format safetensors. Par exemple pour le GPT2, nous pouvons consulter cette page. En passant votre curseur sur la ligne wpe.weight vous verrez même l'information indiquant que cette couche représente 28,17% de la taille totale du modèle.
Nous pouvons constater que la taille du vocabulaire n’est pas un multiple de 64 ! Appliquer du trimming sur ce modèle pourrait être pertinent.
Prenons un exemple théorique. Si nous ramenons la taille de vocabulaire de 50 257 à 32 768 (512 × 64), les 38 597 376 paramètres sont alors réduits à 32 768 × 768 = 25 165 824. Soit 13 431 552 de paramètres en moins.
Le nombre de paramètres total passe alors de 124 439 808 à 111 008 256. C’est une réduction de 10,79 %.
Nous verrons dans la section suivante que pour certains modèles, cette réduction peut être beaucoup plus importante.
Une question que nous pouvons alors nous poser est : quel est l’impact de cette réduction de paramètres sur les performances du modèle ?
Pour y répondre, nous avons analysé 16 modèles portant sur des architectures et des modalités différentes : encodeurs textuels, encodeur-décodeur textuels, décodeurs textuels, modèles d’embeddings textuels, modèle d’embeddings visuels, encodeur-décodeur textuels/visuels (VLM).
Pratique 👨💻
Comment faire du trimming en pratique ?
Plusieurs auteurs se sont intéressés au problème ces dernières années, et parmi ceux qui ont partagé leur code voire proposé une librairie dédiée au sujet, nous pouvons lister :
smaller-transformersde Geotrend permettant de trimmer un mBERT, la version multilingue du BERT de DEVLIN et al. (2018). Une publication est disponible ici par ABDAOUI et al. (2021), de même qu’un répertoire GitHub et certains modèles bilingues/n-lingues sur leur compte Hugging Face. Mais leur approche se limite à ce modèle et les vocabulaires sont de tailles différentes en fonction de la langue considérée et jamais un multiple de 64.- David DALE dans un article Medium (2021) montre comment trimmer un mT5 pour ne garder que l’anglais et le russe. Une approche manuelle pour un contrôle total, mais encore une fois, cela se limite à un modèle particulier.
- Aditya SRIVASTAVA a développé la librairie
hf-trim(2022) où il annonce prendre en compte le mT5 et mBART mais il y a plusieurs limitations en pratique. La plus grande est qu’il n’est pas possible de contrôler la taille finale du vocabulaire souhaitée. Il devrait être possible de résoudre cela en modifiant le code source. lm-vocab-trimmer(2023) par USHIO, ZHOU et CAMACHO-COLLADOS gère le mT5, mBART et XLM-RoBERTa. Cette librairie est probablement la plus aboutie sur le sujet mais a quelques faiblesses, comme le fait que l’argumenttarget_vocab_sizene donne pas le résultat attendu (si vous voulez un multiple de 64). Il n’est pas possible de réduire à n langues (un modèle bilingue, par exemple). Finalement tous les modèles gérés reposent sur un tokenizer sentencepiece de KUDO et RICHARDSON (2018).- Antoine LOUIS via ce Space (2024), propose de trimmer des modèles d’embeddings déjà finetunés (en utilisant un tokenizer sentencepiece) comme le mE5, le BGE ou le GTE. Il n’est pas possible de sélectionner le nombre souhaité de tokens dans le vocabulaire final, et il ne prend en charge que 6 langues.
L’ensemble de ces outils se focalisent uniquement sur des modèles basés sur un tokenizer sentencepiece, des encodeurs ou encodeurs-décodeurs, et permettent très difficilement ou sinon pas du tout de gérer la taille du vocabulaire souhaitée.
Ainsi, dans le cadre de cette introduction au trimming, nous avons voulu traiter des modèles basés sur d’autres tokenizers (notamment le BPE de SENNRICH, HADDOW et BIRCH (2015), sur d’autres architectures, sur d’autres modalités, et être capable de choisir la taille du nouveau vocabulaire.
Dans ce qui suit, nous testons l’ensemble des modèles sur une diversité de langue afin d’évaluer la robustesse de la méthode par des évaluateurs indépendants et dont la langue n’utilise pas forcément l’alphabet latin (coréen, tamoul, arabe entre autres).
Modèles d’embeddings textuels
Observons l’impact du trimming sur les performances de différents types de modèles en commençant avec les modèles d’embedding textuels.
Modèles et benchmarks sélectionnés
Dans cette section, nous focalisons notamment sur :
- Les granite embedding de Granite Team (2025) disponibles en 107M et 278M de paramètres ;
- Les multilingual-e5 de WANG et al. (2024) disponibles en taille
small,base,largeetinstruct; - L’embeddinggemma-300m de SCHECHTER VERA, DUA et al. (2025) ;
- Le bge-m3 de CHEN, XIAO et al. (2024) ;
- Le Qwen3-Embedding-0.6B de ZHANG, LI, LONG, ZHANG et al. (2025).
Concernant les benchmarks, nous évaluons les modèles sur de l’anglais et du néerlandais via :
- Le MTEB de MUENNIGHOFF et al. (2022)
- Le MTEB-NL de BANAR, LOTFI et al. (2025). Nous avons choisi cette langue car avec ce benchmark, ces auteurs ont également introduit les modèles e5-NL qui ont été construit en utilisant la technique du trimming.
Réductions de paramètres observées
| Modèle | Taille du vocabulaire (original) | Taille du vocabulaire (trimmé) | % Réduction vocabulaire | Paramètres (original) | Paramètres (trimmé) | % Réduction paramètres |
|---|---|---|---|---|---|---|
| granite-embedding-107m-multilingual | 250 002 | 16 384 | - 93,45% | 107,0M | 17,3M | - 83,84% |
| granite-embedding-107m-multilingual | 250 002 | 32 768 | - 86,89% | 107,0M | 23,6M | - 77,96% |
| granite-embedding-278m-multilingual | 250 002 | 16 384 | - 93,45% | 278,0M | 98,6M | - 64,53% |
| granite-embedding-278m-multilingual | 250 002 | 32 768 | - 86,89% | 278,0M | 111,2M | - 60,00% |
| multilingual-e5-small | 250 037 | 16 384 | - 93,45% | 117,7M | 27,9M | - 76,26% |
| multilingual-e5-small | 250 037 | 32 768 | - 86,89% | 117,7M | 34,2M | - 70,91% |
| multilingual-e5-base | 250 037 | 16 384 | - 93,45% | 278,0M | 98,6M | - 64,53% |
| multilingual-e5-base | 250 037 | 32 768 | - 86,89% | 278,0M | 111,2M | - 60,00% |
| multilingual-e5-large | 250 037 | 16 384 | - 93,45% | 559,9M | 320,7M | - 42,7% |
| multilingual-e5-large | 250 037 | 32 768 | - 86,89% | 559,9M | 337,4M | - 39,7% |
| embeddinggemma-300m | 262 144 | 16 384 | - 93,75% | 307,6M | 118,8M | - 61,36% |
| embeddinggemma-300m | 262 144 | 32 768 | - 87,50% | 307,6M | 131,4M | - 57,27% |
| bge-m3 | 250 002 | 16 384 | - 93,45% | 567,8M | 328,5M | - 42,14% |
| bge-m3 | 250 002 | 32 768 | - 86,89% | 567,8M | 345,3M | - 39,18% |
| Qwen3-Embedding-0.6B | 151 669 | 16 384 | - 89,20% | 595,8M | 457,2M | - 23,25% |
| Qwen3-Embedding-0.6B | 151 669 | 32 768 | - 78,40% | 595,8M | 474,0M | - 20,44% |
📝 Note
Les granite-embedding, mE5, BGE-M3 et Qwen3-Embedding ayant une taille de vocabulaire n'étant pas un multiple de 64, le trimming semble particulièrement adapté même dans le cas où nous ne souhaitons pas spécifiquement créer un modèle monolingue/n-lingue.
Dans le tableau ci-dessus, et pour l’ensemble de l’article, nous donnons des chiffres pour des vocabulaires de taille 16 384 et 32 768 tokens. Nous revenons dans la section de l’article, Questions ouvertes❓, sur ce choix et plus généralement sur le défi du nombre de tokens à conserver dans le vocabulaire du modèle trimmé.
Résultats
Anglais
| Modèle | # | Mean (Task) |
Mean (Task Type) |
Cla | Clu | Pai | Rer | Ret | STS | Sum |
|---|---|---|---|---|---|---|---|---|---|---|
| granite-embedding-107m-multilingual | 107,0M | 58,81 | 55,59 | 68,77 | 42,61 | 80,46 | 46,10 | 47,92 | 75,53 | 27,77 |
| granite-embedding-107m-eng-32768 | 23,6M | 58,91 | 55,59 | 68,78 | 43,06 | 80,37 | 46,11 | 48,11 | 75,43 | 27,27 |
| granite-embedding-107m-eng-16384 | 17,3M | 58,52 | 54,94 | 68,54 | 42,39 | 79,78 | 45,75 | 47,79 | 75,34 | 24,98 |
| granite-embedding-278m-multilingual | 278,0M | 60,37 | 56,96 | 69,81 | 43,29 | 81,37 | 46,46 | 51,44 | 76,56 | 29,78 |
| granite-embedding-278m-eng-32768 | 111,2M | 60,40 | 59,91 | 69,81 | 43,62 | 81,31 | 46,47 | 51,45 | 76,49 | 29,22 |
| granite-embedding-278m-eng-16384 | 98,6M | 60,07 | 56,65 | 69,56 | 42,76 | 80,76 | 46,07 | 51,27 | 76,39 | 29,72 |
| multilingual-e5-small | 117,7M | 58,90 | 55,72 | 70,51 | 41,65 | 83,85 | 43,59 | 41,35 | 79,85 | 29,23 |
| multilingual-e5-small-eng-32768 | 34,2M | 58,77 | 55,89 | 70,51 | 40,70 | 83,86 | 43,58 | 43,34 | 79,83 | 29,42 |
| multilingual-e5-small-eng-16384 | 27,9M | 58,58 | 55,61 | 70,68 | 40,79 | 83,08 | 42,99 | 42,88 | 79,67 | 29,18 |
| multilingual-e5-base | 278,0M | 59,48 | 55,77 | 73,84 | 42,09 | 83,74 | 43,87 | 40,27 | 80,49 | 26,08 |
| multilingual-e5-base-eng-32768 | 124,4M | 59,66 | 56,02 | 73,81 | 41,66 | 83,69 | 43,85 | 43,38 | 80,49 | 25,22 |
| multilingual-e5-base-eng-16384 | 98,6M | 59,31 | 55,70 | 73,44 | 41,50 | 82,83 | 43,32 | 42,89 | 80,27 | 25,66 |
| multilingual-e5-large | 559,9M | 60,52 | 56,62 | 74,89 | 41,62 | 84,33 | 44,32 | 43,38 | 81,12 | 26,67 |
| multilingual-e5-large-eng-32768 | 337,4M | 60,85 | 57,09 | 74,90 | 41,82 | 84,33 | 44,33 | 46,25 | 81,12 | 26,92 |
| multilingual-e5-large-eng-16384 | 320,7M | 60,53 | 56,72 | 74,67 | 41,32 | 84,10 | 43,70 | 45,79 | 81,07 | 26,40 |
| embeddinggemma | 307,6M | 68,13 | 63,58 | 87,51 | 53,39 | 84,83 | 46,93 | 51,75 | 82,91 | 37,77 |
| embeddinggemma-eng-32768 | 131,4M | 65,46 | 61,18 | 86,32 | 49,43 | 81,37 | 45,17 | 50,80 | 80,05 | 35,08 |
| embeddinggemma-eng-16384 | 118,8M | 62,63 | 58,60 | 84,00 | 46,53 | 79,81 | 44,28 | 47,66 | 76,39 | 31,55 |
| bge-m3 | 567,8M | 62,17 | 59,12 | 77,37 | 40,71 | 84,48 | 45,99 | 49,61 | 80,91 | 34,79 |
| bge-m3-eng-32768 | 345,3M | 62,29 | 59,28 | 77,38 | 40,99 | 84,50 | 46,00 | 49,80 | 80,91 | 35,38 |
| bge-m3-eng-16384 | 328,5M | 62,19 | 59,20 | 77,39 | 40,86 | 84,22 | 45,36 | 49,70 | 80,81 | 36,07 |
| Qwen3-Embedding-0.6B | 595,8M | 65,28 | 59,78 | 74,62 | 47,55 | 80,16 | 46,16 | 60,64 | 81,33 | 28,02 |
| Qwen3-Embedding-eng-32768 | 474,0M | 65,14 | 59,82 | 74,69 | 47,27 | 79,88 | 46,05 | 60,34 | 81,19 | 29,29 |
| Qwen3-Embedding-eng-16384 | 457,2M | 65,06 | 59,45 | 74,80 | 47,05 | 79,51 | 45,55 | 60,04 | 80,92 | 28,25 |
Nous pouvons constater que globalement le trimming permet de maintenir les performances du modèle original tout en ayant des modèles plus petits. Dans 5 cas sur 8, nous avons même un modèle de 32 768 tokens qui est légèrement meilleur que le modèle original. Notre hypothèse est que la suppression de tokens parasites bénéficie au modèle.
Notons un problème néanmoins, la détérioration des performances de l’embeddinggemma. Nous pensions initialement avoir fait une erreur dans notre code, mais avons exclu cette possibilité lorsque nous nous sommes intéressés au gemma-3 (voir les parties sur les décodeurs et les VLM) qui utilise le même tokenizer et où nous n’observons pas de baisse de performances (il s’agit même probablement d’un des modèles les plus robustes au trimming).
L’explication que nous avançons, et nous avons donc laissé ce modèle pour illustrer ce phénomène, est que le trimming ne fonctionne que si la couche d’embedding est la dernière couche du réseau (ou également la première en cas d’embeddings partagés). Là où cette couche d’embedding est bien la dernière (hors pooling) pour tous les autres modèles présentés, pour l’embeddinggemma, il y a deux couches denses supplémentaires.
Pour cette même raison, nous présentons ici uniquement des modèles bi-encodeurs. En effet, nos expérimentations sur des rerankers ont toutes échoué du fait de la couche de classification située au-dessus de celle d’embedding dans ces types de modèles.
Avec l’embeddinggemma, nous souhaitions illustrer la seule limite que nous avons identifiée à la méthode du trimming.
📝 Note
Nous avons choisi de tout de même proposer des versions monolingues de l'embeddinggemma pour deux raisons :
1) Pour l'anglais, la version 32 768 reste meilleure que le Qwen3-Embedding (original ou trimmé) même avec cette dégradation.
2) La dégradation de 2,5 à 5,5 points (en fonction de la configuration retenue) est probablement la plus extrême du fait que le modèle est principalement entraîné sur de l'anglais. Sur d'autres langues testées, la dégradation est ramenée à 1,7 pour le français (65,13 en 32 768 vs. 66,87 pour l'original) et à 0,6 point pour le néerlandais (cf. paragraphe suivant).
Néerlandais
Dans le tableau ci-dessous, les modèles ayant le suffixe -trm correspondent aux modèles trimmés par les auteurs des e5-NL. Ils utilisent pour leur part 50 002 tokens (qui n’est pas un multiple de 64). Les modèles ayant le suffixe -trm-nl sont les modèles trimmés évoqués à l’instant sur lesquels les auteurs ont appliqué un finetuning sur 950 000 données (réelles et synthétiques) supplémentaires.
À noter que les résultats diffèrent légèrement de ceux disponibles sur le leaderboard car nous n’avons pu obtenir des résultats que pour 39 des 40 jeux de données constituant le MTEB-NL. Plus précisément, il n’a pas été possible d’évaluer sur BelebeleRetrieval du fait d’une erreur de configuration de la langue dans l’API de MTEB. La colonne Ret ci-dessous est donc un peu sous-évaluée par rapport au leaderboard.
Ainsi, nous avons également relancé MTEB-NL sur les modèles originaux pour que l’ensemble des modèles soient comparés sur 39 jeux de données.
| Modèle | # | Mean (Task) |
Mean (Task Type) |
Cla | Clu | Mul | Pai | Rer | Ret | STS |
|---|---|---|---|---|---|---|---|---|---|---|
| granite-embedding-107m-multilingual | 107,0M | 48,07 | 55,43 | 54,95 | 29,57 | 33,30 | 70,07 | 84,66 | 47,02 | 68,41 |
| granite-embedding-107m-nld-32768 | 23,6M | 48,11 | 55,47 | 54,97 | 29,68 | 33,28 | 70,07 | 84,78 | 47,05 | 68,45 |
| granite-embedding-278m-multilingual | 278,0M | 49,29 | 56,49 | 55,64 | 30,59 | 34,38 | 71,03 | 85,66 | 49,19 | 68,91 |
| granite-embedding-278m-nld-32768 | 111,2M | 49,30 | 56,47 | 55,64 | 30,73 | 34,19 | 71,02 | 85,54 | 49,21 | 68,93 |
| multilingual-e5-small | 117,7M | 49,10 | 57,84 | 56,96 | 27,75 | 34,79 | 76,46 | 87,85 | 46,92 | 74,18 |
| multilingual-e5-small-nld-32768 | 34,2M | 49,17 | 57,90 | 56,96 | 27,94 | 34,80 | 76,46 | 87,93 | 46,99 | 74,22 |
| e5-small-trm | 40,8M | 49,79 | 58,13 | 56,99 | 27,66 | 34,81 | 76,46 | 87,33 | 49,43 | 74,20 |
| e5-small-trm-nl | 40,8M | 52,35 | 59,61 | 58,74 | 32,81 | 35,48 | 76,01 | 86,96 | 52,69 | 74,60 |
| multilingual-e5-base | 278,0M | 50,96 | 59,09 | 58,76 | 28,19 | 34,82 | 76,75 | 89,30 | 50,90 | 74,90 |
| multilingual-e5-base-nld-32768 | 111,2M | 50,91 | 59,05 | 58,66 | 28,15 | 34,77 | 76,76 | 89,25 | 50,85 | 74,91 |
| e5-base-trm | 124,4M | 51,38 | 59,21 | 58,75 | 28,27 | 34,82 | 76,75 | 88,58 | 52,40 | 74,90 |
| e5-base-trm-nl | 124,4M | 53,48 | 60,77 | 60,12 | 34,46 | 35,94 | 78,43 | 87,49 | 53,16 | 75,77 |
| multilingual-e5-large | 559,9M | 53,15 | 61,44 | 60,76 | 29,01 | 35,70 | 80,31 | 91,38 | 54,07 | 78,83 |
| multilingual-e5-large-nld-32768 | 337,4M | 53,23 | 61,52 | 60,76 | 29,27 | 35,86 | 80,33 | 91,43 | 54,12 | 78,85 |
| e5-large-trm | 355,1M | 53,67 | 61,59 | 60,73 | 29,40 | 35,73 | 80,31 | 90,34 | 55,74 | 78,84 |
| e5-large-trm-nl | 355,1M | 55,48 | 62,59 | 62,71 | 35,80 | 37,87 | 81,42 | 87,18 | 54,96 | 78,19 |
| embeddinggemma | 307,6M | 56,77 | 63,22 | 64,53 | 34,56 | 36,89 | 78,31 | 89,65 | 58,78 | 79,80 |
| embeddinggemma-nld-32768 | 131,4M | 56,17 | 62,69 | 63,94 | 34,95 | 36,88 | 77,99 | 89,26 | 57,33 | 78,51 |
| bge-m3 | 567,8M | 53,88 | 61,11 | 61,40 | 28,74 | 35,56 | 78,30 | 88,73 | 56,96 | 78,09 |
| bge-m3-nld-32768 | 345,3M | 53,88 | 61,12 | 61,41 | 28,75 | 35,64 | 78,30 | 88,77 | 56,91 | 78,10 |
| Qwen3-Embedding-0.6B | 595,8M | 51,50 | 57,91 | 58,41 | 29,46 | 34,64 | 71,24 | 85,91 | 54,26 | 71,43 |
| Qwen3-Embedding-nld-32768 | 474,0M | 51,40 | 57,87 | 58,36 | 29,35 | 34,73 | 71,27 | 85,97 | 54,02 | 71,37 |
Comme pour l’anglais, nous pouvons constater que le trimming matche voire permet un très léger gain (généralement inférieur à 0,1 point) de performance lorsque nous gardons 32 768 tokens.
Un résultat encore plus intéressant est que si l’on conserve davantage de tokens (50 002 par les auteurs du MTEB-NL, mais nous pouvons penser que 50 048 serait un nombre plus pertinent vis-à-vis du matériel), le gain monte entre 0,4 et 0,6 point pour les mE5. Sans aucun réentraînement.
Si en plus, nous finetunons le modèle trimmé, nous pouvons constater que le gain monte alors de 2,5 à 3,1 points par rapport au modèle original.
📝 Note
Nous voyons que garder 50 002 tokens semble plus intéressant que d'en garder 32 768.
Suite à ces résultats, nous nous sommes questionnés sur le fait de savoir si nous devions ou non proposer des modèles avec un vocabulaire de 50 048 tokens. Nous ne l'avons finalement pas fait. D'une part parce que dans le cadre de cet article de blog, notre objectif est de proposer une simple introduction à la méthode du trimming et non pas les meilleurs modèles possibles pour illustrer nos propos. D'autre part parce que cette question de savoir quel est le nombre de tokens optimal pour un tokenizer n'est pas évidente.
Nous revenons sur ce dernier point dans une partie dédiée dans la dernière section de cet article de blog portant sur les Questions ouvertes❓.
🧠 À retenir
Pour les modèles d'embeddings textuels, le trimming permet d'obtenir un modèle monolingue léger par rapport à un modèle multilingue plus gros.
Nous pouvons notamment constater que les performances sont conservées voire légèrement améliorées.
Si vous observez une légère baisse, il est conseillé d'effectuer un finetuning pour retrouver les performances originales, voire les surpasser.
Ce gain de performance via finetuning s'avère même rapide à obtenir car le modèle trimmé étant plus petit que l'original, le temps d'entraînement est accéléré. À budget de calcul équivalent, cela ouvre alors la possibilité de montrer davantage de données au modèle trimmé qu'à un modèle original qu'on finetunerait (nous menons cette expérience plus bas dans la partie sur les encodeurs-décodeurs).
À noter que les avantages listés ci-dessus ne sont applicables qu'à des modèles où la couche d'embedding est la dernière du réseau. Le trimming ne fonctionnera pas s'il y a des couches positionnées au-dessus de celle d'embedding.
Collections
Nous nous sommes concentrés sur l’anglais et le néerlandais dans le cadre de cet article de blog. Néanmoins, pour chacun des 5 modèles listés ci-dessus, nous avons généré l’ensemble des modèles monolingues possibles à partir des langues gérées par chacun des modèles originaux.
Pour chaque, nous les fournissons en versions 16 384 tokens et 32 768 tokens, ainsi que dans l’ensemble des tailles disponibles.
Certains acteurs ne fournissant pas la liste complète des langues gérées par leur modèle, nous avons généré du mieux que nous pouvions à partir de l’analyse des caractères unicode trouvés dans le tokenizer du modèle original.
🎁 Important
La collection rassemblant les 48 modèles (12 langues différentes) trimmés à partir des granite-embedding est disponible ici.
La collection rassemblant les 948 modèles (119 langues différentes) trimmés à partir des multilingual-e5 est disponible ici.
La collection rassemblant les 243 modèles (122 langues différentes) trimmés à partir de l'embeddinggemma est disponible ici.
La collection rassemblant les 178 modèles (89 langues différentes) trimmés à partir du bge-m3 est disponible ici.
La collection rassemblant les 166 modèles (83 langues différentes) trimmés à partir du qwen3-embedding est disponible ici.
Modèles encodeur
Continuons d’analyser l’impact du trimming sur les performances de différents types de modèles en passant à présent aux modèles encodeur.
Modèles et benchmarks sélectionnés
Dans cette section, nous nous focalisons sur le mmBERT de MARONE, WELLER et al. (2025) et plus particulièrement la version small et la version base, mais aussi la version 32k de vLLM Semantic Router Team (2026).
Nous évaluons l’ensemble de ces modèles sur du français, et plus particulièrement sur la tâche de reconnaissance d’entités nommées et le jeu de données frenchNER_3entities de BOURDOIS (2024) portant sur les entités Personnes, Lieux et Organisations. L’idée ici est de se concentrer sur un seul jeu de données mais de mener plusieurs expériences dessus pour déterminer :
- L’impact de l’ordre du trimming (faut-il le faire avant ou après le finetuning ?);
- L’impact de la base de données ayant servi à miner les tokens;
- L’impact du nombre de données vues lors du minage des tokens;
- Une comparaison avec un modèle en français entraîné de zéro ayant la même architecture (i.e. le modernBERT de WARNER, CHAFFIN, CLAVIÉ et al. (2024));
- Une comparaison du trimming avec la méthode de la distillation.
Nous évaluons ce dernier point également sur de l’anglais en comparant un mmBERT small trimmé sur de l’anglais avec le DistilBERT de SANH et al. (2019) sur le benchmark GLUE de WANG et al. (2018). L’idée étant ici à l’inverse de se concentrer sur un seul modèle mais l’évaluer sur plusieurs tâches.
Réductions de paramètres observées
| Modèle | Taille du vocabulaire (original) | Taille du vocabulaire (trimmé) | % Réduction vocabulaire | Paramètres (original) | Paramètres (trimmé) | % Réduction paramètres |
|---|---|---|---|---|---|---|
| mmBERT-small | 256 000 | 16 384 | - 93,60% | 140,5M | 48,5M | - 65,49% |
| mmBERT-small | 256 000 | 32 768 | - 87,20% | 140,5M | 54,8M | - 61,01% |
| mmBERT-base | 256 000 | 16 384 | - 93,60% | 306,9M | 122,9M | - 59,96% |
| mmBERT-base | 256 000 | 32 768 | - 87,20% | 306,9M | 135,5M | - 55,86% |
| mmbert-32k-yarn | 256 000 | 16 384 | - 93,60% | 306,9M | 122,9M | - 59,96% |
| mmbert-32k-yarn | 256 000 | 32 768 | - 87,20% | 306,9M | 135,5M | - 55,86% |
Résultats
Français
• Ordre du trimming :
| Modèle | Paramètres | Ordre | Contexte | Personnes | Lieux | Organisations | ||||
|---|---|---|---|---|---|---|---|---|---|---|
| mmBERT-base | 306,9M | modèle original non trimmé, seulement finetuné | 8 192 | 0,964 | 0,939 | 0,878 | ||||
| mmBERT-base (32768) | 135,5M | modèle original finetuné (i.e le modèle de la ligne ci-dessus) puis trimmé | 8 192 | 0,354 | 0,047 | 0,292 | ||||
| mmBERT-base-fra-32768 | 135,5M | modèle original trimmé puis finetuné | 8 192 | 0,964 | 0,940 | 0,874 | ||||
| mmBERT-base (16384) | 135,5M | modèle original finetuné (i.e le modèle de la 1ère ligne du tableau) puis trimmé | 8 192 | 0,000 | 0,257 | 0,055 | ||||
| mmBERT-base-fra-16384 | 122,9M | modèle original trimmé puis finetuné | 8 192 | 0,963 | 0,938 | 0,871 | ||||
| mmbert-32k-yarn | 306,9M | modèle original non trimmé, seulement finetuné | 32 768 | 0,960 | 0,934 | 0,865 | ||||
| mmBERT-base-32k-yarn-fra-32768 | 135,5M | modèle original finetuné (i.e le modèle de la ligne ci-dessus) puis trimmé | 32 768 | 0,283 | 0,127 | 0,000 | ||||
| mmBERT-base-32k-yarn-fra-32768 | 135,5M | modèle original trimmé puis finetuné | 32 768 | 0,960 | 0,933 | 0,860 | ||||
D’après ces expérimentations, dans le cadre du mmBERT, il est impératif de trimmer le modèle original puis finetuner le modèle résultant plutôt que de finetuner le modèle original puis de le trimmer.
Au-delà d’éviter un effondrement des performances, finetuner un modèle trimmé est aussi plus rapide que de finetuner un modèle original car le modèle est plus petit.
📝 Note
Nous revenons sur ce point de l'ordre du trimming dans une partie dédiée dans la dernière section de l'article portant sur less Questions ouvertes❓.
Nous pouvons noter que comme pour les modèles d’embeddings textuels, garder 32 768 tokens donne des résultats semblables au modèle d’origine (petite baisse sur l’entité Organisations à souligner), et qu’en garder 16 384 fait légèrement moins bien.
Enfin le modèle YaRN apparaît comme moins performant que le modèle original non trimmé, que le modèle original trimmé à 32 768 ou 16 384 tokens.
• Impact de la base de données de textes de minage :
Ayant découvert le trimming il y a quelques années via l’article Medium de David DALE, nous utilisons comme lui le Leipzig Corpora de GOLDHAHN et al. (2012) pour le minage des tokens.
À l’occasion de cet article de blog, nous nous sommes intéressés à explorer l’impact des données de minage sur les performances des modèles. Dans cette partie, nous comparons donc le Leipzig Corpora à Fineweb 2 de PENEDO et al. (2025) publié il y a quelques mois. Pour Leipzig Corpora nous avons utilisé les 200 000 premières données du jeu de données fra_wikipedia_2021 et pour Fineweb 2 les 200 000 premières données du split fra_Latn.
| Modèle | Paramètres | Jeu de données | Contexte | Personnes | Lieux | Organisations |
|---|---|---|---|---|---|---|
| mmBERT-base | 306,9M | Fineweb 2 | 8 192 | 0,964 | 0,939 | 0,878 |
| mmBERT-base-fra-32768 | 136M | Fineweb 2 | 8 192 | 0,964 | 0,940 | 0,874 |
| mmBERT-base-fra-32768 | 136M | Liepzig | 8 192 | 0,963 | 0,939 | 0,875 |
| mmBERT-base-fra-16384 | 124M | Fineweb 2 | 8 192 | 0,963 | 0,938 | 0,871 |
| mmBERT-base-fra-16384 | 124M | Liepzig | 8 192 | 0,963 | 0,937 | 0,871 |
Nous pouvons observer des résultats similaires entre les deux corpus, quel que soit le nombre de tokens gardé dans le vocabulaire.
Pour notre part, et ceci pour l’ensemble des résultats présentés dans cet article ainsi que pour les 5526 modèles générés, nous avons utilisé Fineweb 2.
Ce choix s’est imposé uniquement d’un point de vue pratique. En effet, Fineweb 2 est disponible directement sur le Hub d’Hugging Face regroupant toutes les langues et fichiers en un unique endroit requêtable de manière automatisée. Là où pour le Leipzig Corpora, il est nécessaire de télécharger les corpus manuellement.
• Impact du nombre de textes lors du minage :
Nous venons de voir que la source utilisée pour miner les tokens n’avait pas une grande importance sur les performances. Qu’en est-il du nombre de textes utilisés ?
| Modèle | Paramètres | Nombre de textes | Contexte | Personnes | Lieux | Organisations |
|---|---|---|---|---|---|---|
| mmBERT-base | 308M | 8 192 | 0,964 | 0,939 | 0,878 | |
| mmBERT-base-fra-32768 | 136M | 2 000 000 | 8 192 | 0,963 | 0,941 | 0,875 |
| mmBERT-base-fra-32768 | 136M | 200 000 | 8 192 | 0,964 | 0,940 | 0,874 |
| mmBERT-base-fra-32768 | 136M | 20 000 | 8192 | 0,964 | 0,940 | 0,875 |
Il s’avère que le nombre de textes n’a pas non plus une grande importance sur les performances.
Le nombre choisi a cependant un impact sur le temps d’exécution du minage. En effet, obtenir la version trimmée sur 20 000 textes a pris 2 min 04s sur un CPU Intel(R) Core(TM) Ultra 7 255H (2.00 GHz) pour l’ensemble du processus (minage des tokens, modification des fichiers de vocabulaire et des couches de l’architecture, pousser le modèle sur le Hub). La version trimmée sur 200 000 textes a pris 8 min 56s. Enfin la version trimmée sur 2 000 000 textes a pris 2h 26min 21s.
⚠️ Vigilance
Nous avons choisi pour notre part de miner l'ensemble des modèles présentés dans cet article de blog sur 200 000 textes au lieu de 20 000 (moins si Fineweb 2 ne propose pas 200 000 textes pour la langue en question).
En effet, nous voulions sécuriser les choses vis-à-vis de deux points que nous n'avons pas pu tester :
1) Nous avons miné jusqu'à 32 768 tokens dans le cadre de cet article de blog, mais est-ce que 20 000 textes suffisent si nous souhaitons garder par exemple 65 536 tokens ?
2) Bien que nous ayons voulu tester le trimming sur plusieurs langues portant sur divers alphabets, nous avons évalué exclusivement des langues richement dotées en ressources. C'est-à-dire des langues avec un nombre suffisamment de tokens dans le modèle original qui, in fine, impacte les performances du modèle trimmé, et qui disposent également de jeux de données d'évaluation pour plusieurs tâches.
Nous n'avons pas pu vérifier l'impact du nombre de textes sur les langues peu dotées en ressources. Une observation qui nous a invité à rédiger cet encart est que pour les mmBERT nous avons pu par exemple générer un modèle en tchétchène en 16 384 tokens mais pas en 32 768 par manque de tokens (unique langue néanmoins où ce phénomène s'est produit).
📝 Note
Le jeu de données Fineweb 2 étant lourd (540GB pour les 360M lignes en français par exemple et plus de 8,67 TB au total), et comme nous venons de le voir, le nombre de lignes vues lors du minage n'influençant pas les performances, nous avons créé un sous-ensemble de Fineweb 2 pour 124 langues disponible ici (seulement 44GB). Ces 124 langues correspondent à l'intersection des langues proposées par le mBERT et le XLM-RoBERTa.
📝 Note
Nous nous focalisions ici sur des textes génériques issus de Fineweb 2. Nous n'avons pas eu le temps d'effectuer l'expérience, mais le fait que seuls 20 000 textes soient nécessaires pour le trimming ouvre la porte à un minage sur des données spécialisées sur un domaine donné (médecine, banque, industrie, etc.) qui sont généralement moins nombreuses que les généralistes. Cela permettrait de ne garder que les tokens indispensables au domaine et qu'ils soient alignés avec le jeu de données nécessaire pour réaliser l'adaptation au domaine via un pré-entraînement supplémentaire.
• Comparaison avec un modèle entraîné de zéro :
Pour cette comparaison d’un modèle monolingue entraîné de zéro vs. un modèle multilingue trimmé, il nous semblait important de comparer des modèles partageant exactement la même architecture à savoir celle du modernBERT (plutôt qu’un modernBERT trimmé vs. un BERT/RoBERTa/DeBERTa entraîné de zéro par exemple).
Pour le français, il existe une version entraînée de zéro du modernBERT : le ModernCamemBERT d’ANTOUN et al. (2025).
| Modèle | Paramètres | Contexte | Personnes | Lieux | Organisations |
|---|---|---|---|---|---|
| mmBERT-base | 306,9M | 8 192 | 0,964 | 0,939 | 0,878 |
| mmBERT-base-fra-32768 | 135,5M | 8 192 | 0,964 | 0,940 | 0,874 |
| Moderncamembert_3entities | 135,5M | 8 192 | 0,969 | 0,944 | 0,881 |
Nous pouvons clairement voir que le modèle monolingue entraîné de zéro surpasse le modèle multilingue original ainsi que sa version trimmée.
Dès lors, lorsqu’il existe une version monolingue d’un modèle dans votre langue, nous conseillons de l’utiliser. Dans le cas contraire, une version trimmée peut être une alternative simple en attendant un modèle monolingue entraîné de zéro.
Accessoirement, vous profiterez également d’une optimisation du nombre de tokens par mot (1,42 pour moderncamembert contre 1,58 pour la version trimmée).
• Comparaison avec la distillation :
Pour comparer un modèle trimmé à un modèle obtenu par distillation, utilisons le distilCamemBERT de DELESTRE et AMAR (2022) distillé à partir du CamemBERT base de MARTIN, MULLER, ORTIZ SUÁREZ, et al. (2019). Pour cela, en plus des options en 16 384 et 32 768 tokens, nous avons également généré un modèle de 67 476 tokens pour avoir une version trimmée possédant le même nombre de paramètres que distilCamemBERT à savoir 67,5M.
| Modèle | Paramètres | Contexte | Personnes | Lieux | Organisations |
|---|---|---|---|---|---|
| mmBERT-small | 140,5M | 8192 | 0,960 | 0,935 | 0,871 |
| mmBERT-small-fra-32768 | 54,8M | 8192 | 0,958 | 0,931 | 0,868 |
| mmBERT-small-fra-16384 | 48,5M | 8192 | 0,959 | 0,932 | 0,861 |
| mmBERT-small-fra-67456 | 67,5M | 8192 | 0,961 | 0,936 | 0,869 |
| distilcamembert-base | 67,5M | 512 | 0,961 | 0,935 | 0,866 |
Nous pouvons remarquer que le modèle distillé fait presque jeu égal avec le modèle mmBERT original. Cela va dans le sens du point précédent qu’un modèle monolingue entraîné de zéro est supérieur à un modèle multilingue.
Une autre observation est que le modèle trimmé à 67 476 tokens, ayant le même nombre de paramètres que la version distillée, performe de manière équivalente à la distillation.
La différence fondamentale est le temps nécessaire pour obtenir les deux modèles. Pour la version distillée, les auteurs indiquent que le modèle a tourné 18j sur un GPU Titan RTX.
De notre côté, nous avons obtenu la version trimmée en 8 min 56s sur un CPU Intel(R) Core(TM) Ultra 7 255H (2.00 GHz) pour l’ensemble du processus.
Accessoirement le modèle trimmé gère une taille de contexte 16 fois plus longue.
🧠 À retenir
À l'issue de ces différentes expérimentations sur le mmBERT, nous retenons que :
- Il faut trimmer un modèle puis le finetuner plutôt que l'inverse.
- Il faut un nombre suffisant de données pour le minage des tokens mais celui-ci est en réalité relativement faible (20 000 textes généralistes pouvant suffire pour les langues richement dotées) et la source des textes n'a pas un grand impact sur les performances.
- Un modèle monolingue entraîné de zéro fera mieux qu'un modèle multilingue trimmé mais ce dernier peut être une alternative en attendant la conception d'un tel modèle.
- Le trimming peut être plus intéressant que la distillation. Nous conseillons de le préférer à cette dernière lorsque le nombre de paramètres à réduire souhaités est équivalent.
Anglais
Comparaison avec la distillation :
Pour l’anglais, nous nous focalisons sur un seul modèle mais faisons une comparaison incluant plusieurs tâches (à savoir 8 tâches du benchmark GLUE).
Précisons ici que pour le finetuning, l’entraînement est effectué sur l’échantillon train et le test sur l’échantillon dev et non sur celui de test. Nous procédons de la sorte surtout pour pouvoir nous comparer au DistilBERT qui a suivi cette méthodologie.
Nous reprenons ainsi les chiffres que les auteurs indiquent dans leur publication.
| Modèle | # | MNLI | QQP | QNLI | SST-2 | CoLA | STS-B | MRPC | RTE | Moyenne |
|---|---|---|---|---|---|---|---|---|---|---|
| distilbert-base-uncased | 67M | 82,2 | 88,5 | 89,2 | 91,3 | 51,3 | 85,8 | 87,5 | 59,9 | 79,5 |
| mmBERT-small-eng-32768 | 54,8M | 84,1 | 88,0 | 90,1 | 91,7 | 50,3 | 88,0 | 89,9 | 69,7 | 81,5 |
Nous pouvons noter qu’à l’exécution des tâches QQP et CoLA, les résultats du mmBERT small trimmé sont supérieurs au DistilBERT.
Cela s’explique sûrement par le fait que le mmBERT small non trimmé score à 84,7 sur ce benchmark.
🎁 Important
Pour l'anglais, le mmBERT small trimmé de 54,8M de paramètres se présente comme une alternative au DistilBERT tout en étant 18,2% plus petit, capable de gérer 8192 tokens au lieu de 512, et de proposer des résultats plus performants.
À nouveau, comme pour ce que nous avons observé sur le français, un atout important du trimming porte sur le temps nécessaire pour obtenir ces versions plus petites des modèles originaux (du mmBERT small donc pour la version trimmé, et du BERT base pour le DistilBERT). Le DistilBERT a nécessité environ 90h de calcul sur 8 GPU V100 16GB contre 9 min 01s sur un CPU Intel(R) Core(TM) Ultra 7 255H (2.00 GHz) pour l’ensemble du processus.
🧠 À retenir
À l'issue de ces différentes expérimentations sur le mmBERT, nous retenons que :
- Il faut trimmer un modèle puis le finetuner plutôt que l'inverse.
- Il faut un nombre suffisant de données pour le minage des tokens mais celui-ci est en réalité relativement faible (20 000 textes généralistes pouvant suffire pour les langues richement dotées) et la source des textes n'a pas un grand impact sur les performances.
- Un modèle monolingue entraîné de zéro fera mieux qu'un modèle multilingue trimmé mais ce dernier peut être une alternative en attendant la conception d'un tel modèle.
- Le trimming peut être plus intéressant que la distillation. Nous conseillons de le préférer à cette dernière lorsque le nombre de paramètres à réduire souhaités est équivalent.
Collections
🎁 Important
La collection rassemblant les 514 modèles (124 langues différentes) trimmés à partir des mmBERT est disponible ici.
Modèles encodeur-décodeur
Intéressons-nous à présent aux modèles encodeur-décodeur.
Modèles et benchmarks sélectionnés
Pour les modèles encodeur-décodeur, nous nous concentrons sur :
- Le mT5 de XUE, CONSTANT, ROBERTS et al. (2021) et plus particulièrement la version small et la version base;
- Le mBART de LIU, GU, GOYAL et al. (2020).
Nous effectuons les évaluations de ces modèles sur du coréen et plus précisément sur la tâche de génération de question via le benchmark qg_koquad de USHIO et al. (2022).
Nous les évaluons également sur de l’arabe et de l’allemand dans le cadre d’une tâche de traduction. En effet, jusqu’ici nous avons montré des usages du trimming pour générer des modèles monolingues à partir d’un modèle multilingue. Notre souhait est de montrer que la méthode peut s’appliquer aussi pour générer des modèles n-lingues à partir d’un modèle multilingue. Le jeu de données retenu pour la traduction est la partie ar-de de MultiUN d’EISELE et CHEN (2010) où nous avons gardé les 100 000 premiers échantillons que nous avons divisé en 90% train, 5% éval et 5% test.
Réductions de paramètres observées
| Modèle | Taille du vocabulaire (original) | Taille du vocabulaire (trimmé) | % Réduction vocabulaire | Paramètres (original) | Paramètres (trimmé) | % Réduction paramètres |
|---|---|---|---|---|---|---|
| mt5-small | 250 112 | 16 384 | - 93,45% | 300,2M | 60,8M | - 79,73% |
| mt5-small | 250 112 | 32 768 | - 86,90% | 300,2M | 77,6M | - 74,14% |
| mt5-base | 250 112 | 16 384 | - 93,45% | 582,4M | 223,4M | - 61,64% |
| mt5-base | 250 112 | 32 768 | - 86,90% | 582,4M | 248,6M | - 57,32% |
| mbart-large-50 | 250 054 | 16 384 | - 93,45% | 610,9M | 371,6M | - 39,17% |
| mbart-large-50 | 250 054 | 32 768 | - 86,90% | 610,9M | 388,4M | - 36,42% |
📝 Note
Le mBART ayant une taille de vocabulaire n'étant pas un multiple de 64, le trimming semble particulièrement adapté même dans le cas où nous ne souhaitons pas spécifiquement créer un modèle monolingue/n-lingue.
📝 Note
Nous pensions initialement proposer également la version large du mt5 (réduction du nombre de paramètres de 1,230B à 784,5M soit -36,20%) mais y avons finalement renoncé pour proposer à la place des modèles décodeurs plus récents (voir la section suivante).
Résultats
Coréen
| Modèle | Paramètres | BLEU | ROUGE-L | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| mt5-small | 300,2M | 13,71 | 16,92 | |||||||
| mt5-small-kor-32768 | 77,6M | 13,78 | 16,61 | |||||||
| mt5-small-kor-16384 | 60,8M | 13,87 | 16,61 | |||||||
| mt5-base | 582,4M | 16,16 | 18,49 | |||||||
| mt5-base-kor-32768 | 248,6M | 16,29 | 18,67 | |||||||
| mt5-base-kor-16384 | 223,4M | 16,10 | 18,56 | |||||||
| mbart-large-50 | 610,9M | 15,76 | 17,75 | |||||||
| mbart-large-50-kor-32768 | 388,4M | 15,04 | 17,32 | |||||||
| mbart-large-50-kor-16384 | 371,6M | 15,15 | 17,29 | |||||||
Pour le mT5 small, nous pouvons voir une légère amélioration sur la métrique BLEU et une légère dégradation sur la métrique ROUGE-L.
Pour le mt5 base, la version 32 768 donne les meilleurs résultats tout modèle (originaux ou trimmés) confondu.
Le mBART se comporte moins bien que le mT5 puisque nous pouvons constater une dégradation des résultats.
Arabe-Allemand
| Modèle | Paramètres | BLEU | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| mt5-small | 300,2M | 40,24 | ||||||||
| mT5-small-arb-deu-32768 | 77,6M | 40,02 | ||||||||
| mT5-small-arb-deu-16384 | 60,8M | 39,55 | ||||||||
| mt5-base | 582,4M | 49,49 | ||||||||
| mt5-base-arb-deu-32768 | 248,6M | 49,54 | ||||||||
| mt5-base-arb-deu-16384 | 223,4M | 49,49 | ||||||||
| mbart-large-50 | 610,9M | 58,77 | ||||||||
| mbart-large-50-arb-deu-32768 | 388,4M | 58,45 | ||||||||
| mbart-large-50-arb-deu-32768 | 388,4M | 60,53 | ||||||||
Pour les mT5, nous pouvons observer une légère dégradation pour la version small (surtout en version 16 384 tokens) et un match voire une légère amélioration pour la version base.
Pour le mBART, au lieu de générer la version 16 384 tokens, nous avons choisi de réaliser une autre expérience. Profitant du fait que le modèle trimmé est plus petit que l’original et que le finetuning s’exécute alors plus rapidement, nous avons poursuivi l’entraînement. Cela permet alors de ne pas faire une comparaison à nombre d’epochs équivalentes (5 pour chaque modèle pour 58,45 vs 58,77), mais à temps d’exécution équivalent (50 min pour chaque). Nous pouvons alors observer un gain de 1,76 point de BLEU à budget temps similaire.
🧠 À retenir
Pour les encodeurs-décodeurs, le trimming permet d'avoir des résultats plus ou moins équivalents au modèle original. Profiter du fait que les modèles trimmés soient plus petits pour les entraîner plus longtemps permet un gain important par rapport au modèle original.
Collections
🎁 Important
Une collection rassemblant 392 modèles (98 langues différentes) trimmés à partir des mt5 est disponible ici.
Une collection rassemblant 104 modèles (52 langues différentes) trimmés à partir du mbart est disponible ici.
Modèles décodeur
Poursuivons nos expérimentations avec les modèles décodeur.
Modèles et benchmarks sélectionnés
Nous nous intéressons ici à quatre familles de décodeurs :
- Les Granite 4.0 d’IBM Research (2025) dans ses tailles
350met1b(que ce soit en version attention ou hybride) ; - Les Qwen 3 de Qwen Team (2025) dans ses tailles
0.6Bet1.7B; - Les Gemma 3 de Google DeepMind (2025) dans ses tailles
270met1b; - Le SmolLM3 d’Hugging Face (2025).
Nous évaluons ces modèles sur le néerlandais et le coréen.
Pour le néerlandais, nous utilisons l’échantillon portant sur cette langue du leaderboard EuroEval de NIELSEN et al. (2024). Nous faisons notamment un focus sur les tâches génératives proposées par ce benchmark et laissons de côté les tâches de type classification sur lesquelles les encodeurs sont plus efficaces.
Pour le coréen, nous appliquons les modèles sur le benchmark KoBEST de KIM et al. (2022) où nous avons procédé à une configuration 5-shots.
Réductions de paramètres observées
| Modèle | Taille du vocabulaire (original) | Taille du vocabulaire (trimmé) | % Réduction vocabulaire | Paramètres (original) | Paramètres (trimmé) | % Réduction paramètres |
|---|---|---|---|---|---|---|
| granite-4.0-350m | 100 352 | 16 384 | - 83,67% | 352,4M | 266,4M | - 24,40% |
| granite-4.0-350m | 100 352 | 32 768 | - 67,35% | 352,4M | 283,2M | - 19,64% |
| granite-4.0-h-350m | 100 352 | 16 384 | - 83,67% | 340,3M | 275,8M | - 18,95% |
| granite-4.0-h-350m | 100 352 | 32 768 | - 67,35% | 340,3M | 288,4M | - 15,25% |
| granite-4.0-1b | 100 352 | 16 384 | - 83,67% | 1,632B | 1,460B | - 10,54% |
| granite-4.0-1b | 100 352 | 32 768 | - 67,35% | 1,632B | 1,493B | - 8,48% |
| granite-4.0-h-1b | 100 352 | 16 384 | - 83,67% | 1,462B | 1,333B | - 8,82% |
| granite-4.0-h-1b | 100 352 | 32 768 | - 67,35% | 1,462B | 1,358B | - 7,10% |
| Qwen3-0.6B | 151 936 | 16 384 | - 89,22% | 751,6M | 507,6M | - 36,93% |
| Qwen3-0.6B | 151 936 | 32 768 | - 78,43% | 751,6M | 474,0M | - 32,47% |
| Qwen3-1.7B | 151 936 | 16 384 | - 89,22% | 2,032B | 1,543B | - 27,33% |
| Qwen3-1.7B | 151 936 | 32 768 | - 78,43% | 2,032B | 1,476B | - 24,02% |
| gemma-3-270m-it | 262 144 | 16 384 | - 93,75% | 268,1M | 60,8M | - 58,67% |
| gemma-3-270m-it | 262 144 | 32 768 | - 87,50% | 268,1M | 77,6M | - 54,76% |
| gemma-3-1b-it | 262 144 | 16 384 | - 93,75% | 999,9M | 716,7M | - 28,31% |
| gemma-3-1b-it | 262 144 | 32 768 | - 87,50% | 999,9M | 735,6M | - 26,43% |
| SmolLM3-3B | 128 256 | 16 384 | - 87,23% | 3,075B | 2,845B | - 7,45% |
| SmolLM3-3B | 128 256 | 32 768 | - 74,45% | 3,075B | 2,880B | - 6,36% |
Résultats
Néerlandais
EuroEval proposant des intervalles de confiance, dans le tableau ci-dessous les moyennes en bleu indiquent que les intervalles des modèles originaux/trimmés se chevauchent. S’ils ne se chevauchent pas le meilleur modèle est indiqué en vert et le moins bon en orange.
Nous donnons également les chiffres des exécutions effectuées par les équipes d’EuroEval quand elles existent.
| Modèle | Moyenne | duidelijke-taal (Simplification) meteor / sari |
hellaswag (Sens commun) mcc / accuracy |
mmlu (Connaissance) mcc / accuracy |
scala (Acceptabilité) mcc / macro_f1 |
wiki-lingua (Résumé) chr_f3pp / chr_f4pp |
||||
|---|---|---|---|---|---|---|---|---|---|---|
| granite-4.0-350m | 25.21 ± 0.75 | 41.87 ± 1.50 62.80 ± 1.53 |
0.61 ± 1.96 25.55 ± 1.73 |
1.90 ± 1.53 26.05 ± 1.33 |
1.14 ± 3.22 39.96 ± 3.72 |
25.05 ± 2.67 27.13 ± 3.11 |
||||
| granite-4.0-350m-nld-32768 | 26.02 ± 1.04 | 42.09 ± 1.18 63.76 ± 1.44 |
2.83 ± 2.66 25.98 ± 2.34 |
1.99 ± 3.77 27.34 ± 2.95 |
0.47 ± 6.16 42.30 ± 5.05 |
25.41 ± 1.68 28.04 ± 1.92 |
||||
| granite-4.0-h-350m | 25.02 ± 0.68 | 41.62 ± 1.72 63.05 ± 1.45 |
0.68 ± 3.29 25.90 ± 2.10 |
2.82 ± 2.20 23.67 ± 2.12 |
3.27 ± 2.66 33.73 ± 1.07 |
26.94 ± 1.98 28.56 ± 2.25 |
||||
| granite-4.0-h-350m-nld-32768 | 24.72 ± 0.71 | 40.79 ± 1.79 63.47 ± 1.17 |
1.59 ± 3.52 27.38 ± 1.62 |
3.25 ± 3.76 23.79 ± 2.93 |
-0.87 ± 1.44 33.16 ± 1.00 |
26.56 ± 1.59 28.04 ± 1.79 |
||||
| granite-4.0-1b | 38.62 ± 0.74 | 43.83 ± 1.94 64.39 ± 1.18 |
24.21 ± 2.82 43.05 ± 1.65 |
26.57 ± 3.42 45.12 ± 2.61 |
19.73 ± 3.75 59.30 ± 1.81 |
29.24 ± 1.29 30.72 ± 1.39 |
||||
| granite-4.0-1b-nld-32768 | 37.96 ± 0.92 | 41.49 ± 1.59 63.47 ± 1.01 |
25.60 ± 2.43 43.87 ± 1.69 |
28.01 ± 3.99 45.98 ± 3.10 |
18.41 ± 5.46 58.78 ± 2.92 |
26.44 ± 1.94 27.55 ± 2.06 |
||||
| granite-4.0-h-1b | 38.60 ± 0.90 | 48.22 ± 0.86 66.02 ± 0.84 |
26.92 ± 2.50 43.98 ± 2.05 |
34.04 ± 3.05 50.51 ± 2.27 |
8.12 ± 6.00 39.92 ± 4.30 |
33.16 ± 0.58 35.15 ± 0.64 |
||||
| granite-4.0-h-1b-nld-32768 | 37.54 ± 0.56 | 47.71 ± 1.15 65.86 ± 0.75 |
27.95 ± 1.98 44.49 ± 1.63 |
32.60 ± 1.97 49.26 ± 1.47 |
3.77 ± 2.88 35.79 ± 2.74 |
32.86 ± 0.53 35.14 ± 0.63 |
||||
| Qwen3-0.6B | 33.73 ± 0.82 | 35.28 ± 2.03 60.24 ± 1.40 |
8.78 ± 3.49 32.07 ± 2.60 |
28.10 ± 2.74 45.90 ± 2.07 |
10.59 ± 4.58 49.57 ± 2.88 |
32.03 ± 0.54 34.75 ± 0.56 |
||||
| Qwen3-0.6B-nld-32768 | 31.33 ± 0.92 | 34.01 ± 2.32 59.42 ± 1.57 |
9.79 ± 3.32 32.54 ± 2.23 |
18.16 ± 2.62 38.20 ± 2.00 |
7.52 ± 5.85 47.83 ± 3.86 |
31.50 ± 0.34 34.34 ± 0.35 |
||||
| Qwen/Qwen3-0.6B (EuroEval Dutch run) | 28.71 ± 0.57 | 39.86 ± 1.64 63.37 ± 1.26 |
5.10 ± 1.76 27.41 ± 1.27 |
10.98 ± 1.24 32.49 ± 0.93 |
1.23 ± 2.74 38.12 ± 3.63 |
32.71 ± 0.44 35.82 ± 0.54 |
||||
| Qwen3-1.7B | 46.22 ± 0.91 | 42.80 ± 1.43 64.35 ± 0.84 |
27.01 ± 3.00 45.43 ± 2.16 |
55.24 ± 2.04 66.02 ± 1.67 |
28.56 ± 6.89 63.76 ± 3.50 |
32.47 ± 0.48 36.56 ± 0.40 |
||||
| Qwen3-1.7B-nld-32768 | 44.40 ± 0.90 | 43.97 ± 1.80 64.91 ± 1.23 |
26.69 ± 2.41 45.00 ± 1.80 |
48.80 ± 4.11 61.17 ± 3.28 |
26.17 ± 5.50 61.64 ± 2.62 |
30.87 ± 0.84 34.81 ± 0.93 |
||||
| Qwen/Qwen3-1.7B (EuroEval Dutch run) | 42.41 ± 0.65 | 50.22 ± 1.22 66.69 ± 1.30 |
24.98 ± 1.89 42.31 ± 2.28 |
29.27 ± 0.92 46.66 ± 0.80 |
31.21 ± 2.84 60.79 ± 4.46 |
34.18 ± 0.40 37.74 ± 0.32 |
||||
| gemma-3-270m-it | 25.02 ± 0.89 | 37.63 ± 2.56 61.13 ± 1.68 |
-2.46 ± 4.30 25.70 ± 2.04 |
3.46 ± 3.16 27.97 ± 2.67 |
1.79 ± 1.80 40.69 ± 4.54 |
25.78 ± 1.58 28.50 ± 1.93 |
||||
| gemma-3-270m-it-nld-32768 | 24.79 ± 0.91 | 37.86 ± 2.87 61.32 ± 1.74 |
-2.69 ± 3.51 25.39 ± 1.61 |
3.70 ± 3.10 28.01 ± 2.62 |
0.44 ± 3.54 40.45 ± 4.61 |
25.42 ± 1.63 28.02 ± 1.98 |
||||
| gemma-3-1b-it | 31.77 ± 0.79 | 40.46 ± 1.21 63.47 ± 0.90 |
12.15 ± 2.66 33.16 ± 1.77 |
7.93 ± 3.26 31.48 ± 1.22 |
11.85 ± 4.39 50.30 ± 4.21 |
31.81 ± 0.35 35.04 ± 0.42 |
||||
| gemma-3-1b-it-nld-32768 | 31.51 ± 0.89 | 40.14 ± 0.98 63.40 ± 0.95 |
11.09 ± 3.26 32.38 ± 2.51 |
8.09 ± 3.29 31.64 ± 1.03 |
11.19 ± 5.08 50.56 ± 4.73 |
31.71 ± 0.43 34.91 ± 0.53 |
||||
| gemma-3-1b-it (EuroEval Dutch run) | 23.92 ± 0.40 | 23.27 ± 0.61 39.34 ± 0.30 |
9.71 ± 0.86 31.53 ± 0.45 |
12.97 ± 0.65 0.00 ± 0.00 |
6.77 ± 1.87 48.20 ± 3.20 |
32.14 ± 0.25 35.22 ± 0.32 |
||||
Nous pouvons constater que les modèles trimmés font légèrement moins bien que les originaux mais restent dans l’intervalle de confiance à l’exception des Qwen3 où le modèle trimmé fait systématiquement moins bien.
En analysant de plus près, cela semble dû à la tâche MMLU où nous observons une dégradation, contrairement aux autres où les modèles originaux et trimmés continuent de se chevaucher.
Nous pouvons également observer que nos exécutions semblent nettement meilleures que celles rapportées sur le leaderboard. Cela illustre le problème de réplication des évaluations des modèles génératifs.
Notez que pour vérifier le Qwen3, nous avons effectué un peu de vibechecking pour nous faire une idée des capacités qualitatives des modèles. Nous en avons profité pour en faire avec l’ensemble des modèles. Vous pouvez déplier ci-dessous les sorties que nous obtenons avec le prompt Geef me een korte introductie over grote taalmodellen. (Donne moi une courte introduction aux modèles de langage.) :
granite-4.0-350m : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Graag! Hier is een kort introductie over grote taalmodellen:
Grote taalmodellen zijn machine learning modelle met grote hoeveelheden data die ze kunnen leren om taal te begrijpen en te genereren. Ze zijn ontworpen door grote datasets om taalvaardigheid te verbeteren. Bien sûr ! Voici une brève présentation des grands modèles de langage : Les grands modèles de langage sont des modèles d'apprentissage automatique qui, grâce à d'énormes quantités de données, sont capables d'apprendre à comprendre et à générer du langage. Ils sont conçus à partir de vastes ensembles de données afin d'améliorer leurs compétences linguistiques. |
Het is een grote taalmodell, die ontworpen werd door een onderzoeker bij een onderzoeksinstelling. Het is een computerprogramma dat kan begrijpen en schrijven in een taal die door mensen kan worden geïntroduceerd. Het is gebaseerd op de principes van natuurlijke taalverwerking en machine learning. Het is een krachtig hulpmiddel dat kan helpen bij het genereren van textuele inhoud, zoals boeken, artikelen en andere documenten. Het is een belangrijk onderdeel van de toekomst van de technologie en kan een veelzijdigere manier bieden om taal te begrijpen en te genereren. Il s'agit d'un grand modèle de langage, conçu par un chercheur au sein d'un institut de recherche. C'est un programme informatique capable de comprendre et de produire du texte à partir d'entrées fournies par des humains. Il repose sur les principes du traitement du langage naturel et de l'apprentissage automatique. C'est un outil puissant qui peut aider à générer du contenu textuel, tel que des livres, des articles et d'autres documents. Il constitue un élément important de l'avenir de la technologie et peut offrir une approche plus polyvalente pour comprendre et générer du langage. |
granite-4.0-h-350m : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Grote taalmodellen, ook bekend als machine learning modellen, zijn een klasse van kunstmatige intelligentie die zich specialiseert in het proces van leren van grote hoeveelheden tekstgegevens. Deze modellen worden ontworpen om patronen, contexten en betekenis in de taal te herkennen en te begrijpen, wat leidt tot verbeterde natuurlijke taalverwerking, zoals tekstgeneratie, tekstanalyse en tekstcompressie. Ze zijn gebruikt in verschillende toepassingen, zoals chatbots, virtuele assistenten, tekstgeneratie, natuurlijke taalverwerking en zelfs in de AI zelf. Les grands modèles de langage, également appelés modèles d'apprentissage automatique, constituent une catégorie d'intelligence artificielle spécialisée dans l'apprentissage à partir de vastes quantités de données textuelles. Ces modèles sont conçus pour reconnaître et comprendre les schémas, les contextes et le sens du langage, ce qui permet d'améliorer le traitement du langage naturel, notamment la génération, l'analyse et la compression de textes. Ils sont utilisés dans diverses applications, telles que les chatbots, les assistants virtuels, la génération de textes, le traitement du langage naturel et même l'IA elle-même. |
Grote taalmodellen zijn een klasse van kunstmatige intelligentie die zich specialiseert in het procesen van menselijke taal. Ze zijn ontworpen om de complexiteiten en nuances van de taal te begrijpen en te genereren, waardoor ze in staat zijn om menselijke taal te verwerken en te interpreteren. Deze modellen worden vaak gebruikt in verschillende toepassingen, zoals chatbots, virtuele assistenten, tekstgeneratie, natuurlijke taalverwerking en meer. Les grands modèles de langage sont une catégorie d'intelligence artificielle spécialisée dans le traitement du langage humain. Ils sont conçus pour comprendre et reproduire les complexités et les nuances du langage, ce qui leur permet de traiter et d'interpréter le langage humain. Ces modèles sont souvent utilisés dans diverses applications, telles que les chatbots, les assistants virtuels, la génération de texte, le traitement du langage naturel, etc. |
granite-4.0-1b : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Grote taalmodellen, ook wel bekend als GPT (Generative Pre-trained Transformer) modellen, zijn een type van machine learning model dat is ontworpen om menselijke taal te begrijpen en te genereren. Deze modellen worden getraind op enorme hoeveelheden tekstgegevens uit verschillende bronnen, waardoor ze een breed scala aan taalstijlen, onderwerpen en contexten kunnen begrijpen en reproduceren.
De belangrijkste kenmerken van grote taalmodellen zijn:
1. **Grootte**: Deze modellen bestaan uit miljoenen van parameters, waardoor ze zeer geavanceerde taalverwerking kunnen uitvoeren. Hun grootte maakt het mogelijk om complexe taalpatronen en contexten te begrijpen en te genereren.
2. **Pre-training**: Vooraf getraind op grote hoeveelheden tekstgegevens, kunnen deze modellen een breed scala aan informatie en taalstijlen leren. Dit maakt ze zeer flexibel en aanpasbaar aan verschillende taakken.
3. **Generatie**: Met behulp van hun getrainde kennis, kunnen grote taalmodellen tekst genereren op basis van de invoer die ze ontvangen. Dit maakt ze nuttig voor een breed scala aan toepassingen, zoals tekstgeneratie, vertaling, antwoorden op vragen en meer.
4. **Contextbegrip**: Deze modellen zijn uitstekend in het begrijpen van context en het genereren van geschikte en relevante antwoorden of tekst op basis van de gegeven context.
Grote taalmodellen hebben een significante invloed gehad op de manier waarop we interageren met technologie en hebben het potentieel om de manier waarop we communiceren en informatie consumeren te revolutioneren. Ze worden gebruikt in verschillende toepassingen, van chatbots en virtuele assistenten tot contentgeneratie en taalvertaling. Les grands modèles de langage, également connus sous le nom de modèles GPT (Generative Pre-trained Transformer), constituent un type de modèle d'apprentissage automatique conçu pour comprendre et générer le langage humain. Ces modèles sont entraînés sur d'énormes quantités de données textuelles provenant de diverses sources, ce qui leur permet de comprendre et de reproduire un large éventail de styles linguistiques, de sujets et de contextes. Les principales caractéristiques des grands modèles de langage sont les suivantes : 1. **Taille** : Ces modèles comportent des millions de paramètres, ce qui leur permet d'effectuer des traitements linguistiques très sophistiqués. Leur taille leur permet de comprendre et de générer des schémas linguistiques et des contextes complexes. 2. **Pré-entraînement** : Pré-entraînés sur de vastes quantités de données textuelles, ces modèles peuvent assimiler un large éventail d'informations et de styles linguistiques. Cela les rend très flexibles et adaptables à différentes tâches. 3. **Génération** : Grâce à leurs connaissances acquises lors de l'entraînement, les grands modèles de langage peuvent générer du texte à partir des données d'entrée qu'ils reçoivent. Cela les rend utiles pour un large éventail d'applications, telles que la génération de texte, la traduction, la réponse à des questions et bien plus encore. 4. **Compréhension du contexte** : ces modèles excellent dans la compréhension du contexte et la génération de réponses ou de textes appropriés et pertinents en fonction du contexte donné. Les grands modèles de langage ont eu un impact significatif sur la manière dont nous interagissons avec la technologie et ont le potentiel de révolutionner la façon dont nous communiquons et consommons l'information. Ils sont utilisés dans diverses applications, des chatbots et assistants virtuels à la génération de contenu et à la traduction. |
Grote taalmodellen zijn een type kunstmatige intelligentie die is ontworpen om menselijke taal te begrijpen en te genereren. Ze zijn ontwikkeld met behulp van machine learning technieken, met name die gebaseerd op diepe neurale netwerken. Deze modellen zijn getraind op enorme hoeveelheden tekstdata, waardoor ze een breed scala aan woorden, grammatica en context kunnen begrijpen en gebruiken. Ze kunnen vragen beantwoorden, verhalen genereren, tekst corrigeren en zelfs helpen bij het schrijven van artikelen of het begrijpen van complexe concepten. Les grands modèles de langage sont un type d'intelligence artificielle conçu pour comprendre et générer le langage humain. Ils ont été développés à l'aide de techniques d'apprentissage automatique, notamment celles basées sur les réseaux de neurones profonds. Ces modèles ont été entraînés sur d'énormes quantités de données textuelles, ce qui leur permet de comprendre et d'utiliser un large éventail de mots, de structures grammaticales et de contextes. Ils peuvent répondre à des questions, générer des récits, corriger des textes et même aider à rédiger des articles ou à comprendre des concepts complexes. |
granite-4.0-h-1b : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Grote taalmodellen, ook wel bekend als transformatormodellen, zijn een soort kunstmatige intelligentie die is ontwikkeld om menselijke taal te begrijpen, genereren en te manipuleren. Deze modellen zijn gebaseerd op een type neurale netwerk dat in staat is om grote hoeveelheden tekstgegevens te verwerken en patronen te herkennen. Ze zijn in staat om complexe taalbehoudingen te begrijpen, zoals context, betekenis en syntaxis, en kunnen daarmee een breed scala aan taakken uitvoeren, zoals tekstgeneratie, vertaling, antwoordgeven op vragen en taalvertaling. Grote taalmodellen zijn steeds meer geavanceerd en worden steeds vaker gebruikt in verschillende toepassingen, zoals chatbots, virtuele assistenten, contentgeneratie en taalonderwijs. Les grands modèles de langage, également appelés modèles de transformateurs, constituent un type d'intelligence artificielle conçu pour comprendre, générer et manipuler le langage humain. Ces modèles s'appuient sur un type de réseau neuronal capable de traiter de grandes quantités de données textuelles et d'identifier des schémas récurrents. Ils sont capables de comprendre des aspects linguistiques complexes, tels que le contexte, le sens et la syntaxe, et peuvent ainsi effectuer un large éventail de tâches, telles que la génération de texte, la traduction, la réponse à des questions et la traduction linguistique. Les grands modèles de langage sont de plus en plus sophistiqués et sont de plus en plus utilisés dans diverses applications, telles que les chatbots, les assistants virtuels, la génération de contenu et l'enseignement des langues. |
Grote taalmodellen zijn geavanceerde kunstmatige intelligentie systemen die zijn ontworpen om menselijke taal te begrijpen en te genereren. Ze zijn gebaseerd op diepgaande leermodellen, zoals die gebruikt worden in transformator-architecturen, die in staat zijn om patronen in grote hoeveelheden tekstgegevens te leren. Deze modellen kunnen een breed scala aan taakken uitvoeren, zoals tekstgeneratie, vertaling, antwoorden op vragen en antwoordgeneratie. Ze zijn in staat om complexe contexten te begrijpen en passende antwoorden te genereren op basis van de gegeven context. Grote taalmodellen hebben een groot aantal parameters, vaak in de miljoenen tot miljarden bereik, wat hen in staat stelt om een zeer grote hoeveelheid informatie te verwerken en te genereren. Ze zijn steeds meer geavanceerder en worden steeds vaker gebruikt in verschillende toepassingen, zoals chatbots, virtuele assistenten en contentgeneratie. Les grands modèles de langage sont des systèmes d'intelligence artificielle avancés conçus pour comprendre et générer le langage humain. Ils s'appuient sur des modèles d'apprentissage profond, tels que ceux utilisés dans les architectures de transformateurs, capables d'apprendre des schémas récurrents à partir de vastes quantités de données textuelles. Ces modèles peuvent accomplir un large éventail de tâches, telles que la génération de texte, la traduction, la réponse à des questions et la génération de réponses. Ils sont capables de comprendre des contextes complexes et de générer des réponses appropriées en fonction du contexte donné. Les grands modèles de langage ont un grand nombre de paramètres, souvent de l'ordre de millions à milliards, ce qui leur permet de traiter et de générer une très grande quantité d'informations. Ils sont de plus en plus sophistiqués et sont de plus en plus utilisés dans diverses applications, telles que les chatbots, les assistants virtuels et la génération de contenu. |
Qwen3-0.6B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Grote taalmodellen zijn grote, complexe modelle die grote hoeveelheden tekst aanpassen, zoals in de Nederlandse taal. Ze zijn ontwikkeld met de behulp van grote datasetten, zoals millions of woorden, en worden geschikt voor verschillende taalgebruiktes, zoals het antwoorden van vragen of het schrijven van teksten. Ze kunnen ook complexe taalfuncties uitvoeren, zoals het onderluiden van stijl of het ontwerpen van stories. Les grands modèles de langage sont des modèles volumineux et complexes capables de traiter de grandes quantités de texte, notamment en néerlandais. Ils sont développés à partir d'énormes bases de données, comprenant des millions de mots, et sont adaptés à diverses applications linguistiques, telles que la réponse à des questions ou la rédaction de textes. Ils peuvent également effectuer des tâches linguistiques complexes, comme l'adaptation du style ou la création d'histoires. |
**Intro over grote taalmodellen** – grote taalmodellen zijn AI-technologieën die kunnen leren te weten te spelen met taal, zowel in tekst als in andere medium. Ze zijn ontwikkeld met grote gegevens en kunnen kwalitatief en kwalificeel onderzoek, samen met het verwerken van tekst, uitvoeren. Deze modellen zijn gebruikt in verschillende sectoren om interactieve en luidere communicatie te versterken, samen met hun capaciteit om complexe taalgebruik te ondersteunen. **Introduction aux grands modèles de langage** – Les grands modèles de langage sont des technologies d'IA capables d'apprendre à manipuler le langage, tant dans le texte que dans d'autres supports. Développés à partir de vastes ensembles de données, ils permettent d'effectuer des analyses qualitatives et quantitatives, ainsi que le traitement de texte. Ces modèles sont utilisés dans divers secteurs pour améliorer la communication interactive et plus fluide, grâce à leur capacité à prendre en charge un langage complexe. |
Qwen3-1.7B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Grote taalmodellen zijn machine learning-roboten die op basis van veel tekstgegevens worden gemaakt. Ze kunnen vaak honderden van duizenden boeken, artikelen of internetinformatie oefenen. Deze modellen gebruiken een specifieke architectuur, zoals de transformer, om lange teksten en context te begrijpen. Ze worden gebruikt voor taalverwijzing, coderen, en inhoudsgeneratie. Hoewel ze veel potentieel bieden, hebben ze ook problemen met bias, ethieken, en het gebruik van rijke resourcebenodigingen. Les grands modèles de langage sont des robots d'apprentissage automatique créés à partir d'une grande quantité de données textuelles. Ils peuvent souvent être entraînés sur des centaines de milliers de livres, d'articles ou d'informations provenant d'Internet. Ces modèles utilisent une architecture spécifique, telle que le transformer, pour comprendre les textes longs et le contexte. Ils sont utilisés pour la recherche linguistique, le codage et la génération de contenu. Bien qu'ils offrent un grand potentiel, ils posent également des problèmes liés aux biais, à l'éthique et à l'utilisation de ressources importantes. |
Grote taalmodellen (zoals GPT, BERT, en andere modellen) zijn AI-modellen met een grote hoeveelheid parameters (parameters zijn de hoeveelheid informatie die het model leert). Ze worden geïntraineerd op miljarden van de tekstopzoeken om te leren zinnetjes te genereren, te begrijpen en te converseren. Deze modellen zijn van toepassing op veel NLP-taken, zoals het genereren van tekst, het analyseren van taal, en het beantigen van vragen. Zij zijn een belangrijk stap voorwaarts in de AI-ontwikkeling, omdat ze de mogelijkheid bieden om complexe taalproblemen op te lossen en gebruikers ervaring te geven die duidelijk en relevant is. Les grands modèles de langage (tels que GPT, BERT et d'autres modèles) sont des modèles d'IA dotés d'un nombre considérable de paramètres (les paramètres correspondent à la quantité d'informations que le modèle apprend). Ils sont entraînés sur des milliards de requêtes textuelles afin d'apprendre à générer des phrases, à comprendre et à converser. Ces modèles s'appliquent à de nombreuses tâches de traitement du langage naturel (NLP), telles que la génération de texte, l'analyse linguistique et la réponse aux questions. Ils constituent une avancée majeure dans le développement de l'IA, car ils permettent de résoudre des problèmes linguistiques complexes et d'offrir aux utilisateurs une expérience claire et pertinente. |
gemma-3-270m-it : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Een grote taalmodel (LLM) is een objectief model dat de taal kan begrijpen en genereren. Het is ontworpen om een brede kennis van de wereld te behouden en te verwerken, wat resulteert in een betere en meer intelligentere menselijke interactie met de taal. Un grand modèle de langage (LLM) est un modèle capable de comprendre et de générer du langage. Il est conçu pour stocker et traiter une vaste connaissance du monde, ce qui se traduit par une interaction humaine avec le langage à la fois plus efficace et plus intelligente. |
Zeker! Hier is een korte introductie over grote taalmodellen:
Grote taalmodellen (LLM's) zijn een vorm van machine learning die toegang heeft tot enorme hoeveelheden tekstdata. Ze kunnen een breed scala aan taken uitvoeren, zoals tekstgeneratie, verwerking, vraag-antwoord en zelfs tekst-analyse. Deze modellen worden vaak gebruikt voor verschillende toepassingen, van spraakherkenning tot het genereren van content. Bien sûr ! Voici une brèveintroduction aux grands modèles de langage : Les grands modèles de langage (LLM) constituent une forme d'apprentissage automatique qui exploite d'énormes quantités de données textuelles. Ils sont capables d'effectuer un large éventail de tâches, telles que la génération de texte, le traitement de texte, les systèmes de questions-réponses et même l'analyse de texte. Ces modèles sont souvent utilisés pour diverses applications, allant de la reconnaissance vocale à la génération de contenu. |
gemma-3-1b-it : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Oké, hier is een korte introductie over grote taalmodellen (LLM's):
*Grote taalmodellen (LLM's) zijn een nieuw soort AI-technologie die zich steeds meer richten op het begrijpen en genereren van menselijke taal.* Het zijn complexe computersystemen die zijn getraind op enorme hoeveelheden tekst en code, waardoor ze in staat zijn om:
* *Tekst te begrijpen:* Ze kunnen complexe vragen beantwoorden, samenvattingen maken en de betekenis van tekst analyseren.
* *Tekst te genereren:* Ze kunnen nieuwsartikelen, gedichten, code, scripts, muziekstukken, e-mails, brieven, enzovoort, op basis van een prompt.
* *Tekst te vertalen:* Ze kunnen teksten van de ene taal naar de andere vertalen.
* *Chatten:* Ze kunnen interactieve gesprekken voeren.
*Denk aan ze als enorme 'boeken' die geleerd hebben hoe taal te gebruiken.* Ze zijn niet echt 'denkend' zoals mensen, maar ze simuleren intelligente redenering op basis van de patronen die ze in hun training hebben opgevangen.
*Voorbeelden van populaire LLM's zijn:* GPT-3, LaMDA, Bard, en Llama 2.
*Wil je dat ik je verder uitleg, of specifiekere informatie geeft over een bepaald aspect van LLM's?* Bijvoorbeeld, wil je weten hoe ze werken, hoe ze worden gebruikt, of wat hun beperkingen zijn? Bon, voici une brève introduction aux grands modèles de langage (LLM) : *Les grands modèles de langage (LLM) constituent un nouveau type de technologie d'IA qui se concentre de plus en plus sur la compréhension et la génération du langage humain.* Il s'agit de systèmes informatiques complexes qui ont été entraînés sur d'énormes quantités de texte et de code, ce qui leur permet de : * *Comprendre du texte :* ils peuvent répondre à des questions complexes, rédiger des résumés et analyser le sens d'un texte. * *Générer du texte :* ils peuvent créer des articles d'actualité, des poèmes, du code, des scripts, des morceaux de musique, des e-mails, des lettres, etc., à partir d'une consigne. * *Traduire du texte :* Ils peuvent traduire des textes d'une langue à une autre. * *Discuter :* Ils peuvent mener des conversations interactives. *Considérez-les comme d'énormes « livres » qui ont appris à utiliser le langage.* Ils ne « pensent » pas vraiment comme les humains, mais ils simulent un raisonnement intelligent en se basant sur les schémas qu'ils ont captés lors de leur entraînement. *Parmi les LLM populaires, on peut citer :* GPT-3, LaMDA, Bard et Llama 2. *Souhaitez-vous que je vous donne plus d'explications ou des informations plus précises sur un aspect particulier des LLM ?* Par exemple, souhaitez-vous savoir comment ils fonctionnent, comment ils sont utilisés ou quelles sont leurs limites ? |
Oké, hier is een korte introductie over grote taalmodellen (LLM's):
*Grote Taalmodellen (LLM's) zijn een nieuwe klasse van AI-modellen die op enorme hoeveelheden tekstgegevens zijn getraind. Ze kunnen bijvoorbeeld vragen beantwoorden, teksten genereren, vertalen, samenvattingen maken en zelfs code schrijven!*
*Hier zijn de belangrijkste punten om het te begrijpen, zonder te ingewikkeld te worden (maar het is toch belangrijk):*
* *Getraind op enorme datasets van tekst en code van het internet, boeken en meer…* Ze eten heel veel tekst!
* *Gebruiken "neurale netwerken" (een soort intelligentie-circuit) om patronen in de data te leren en te voorspellen wat er volgend zal komen in een tekst.*
* *Ze kunnen "attenderen" op specifieke delen van een tekst om te beantwoorden, of te genereren, en te reageren op je input. Dit noemen we "context begrijpen".*
*Voorbeelden van bekende LLM's zijn Google's LaMDA, Meta's LLaMA, en de modellen van Microsoft (bijv. Copype).*
*Wil je dat ik je iets specifieks over LLM's uitleg? Misschien wil je weten hoe ze werken, of welke toepassingen ze hebben?*. Ok, voici une brève introduction aux grands modèles de langage (LLM) : *Les grands modèles de langage (LLM) constituent une nouvelle catégorie de modèles d'IA entraînés sur d'énormes quantités de données textuelles. Ils peuvent, par exemple, répondre à des questions, générer des textes, traduire, rédiger des résumés et même écrire du code !* *Voici les points essentiels pour comprendre ce concept, sans entrer dans les détails (mais c'est tout de même important) :* * *Entraînés sur d'énormes ensembles de données textuelles et de code provenant d'Internet, de livres et bien plus encore…* Ils avalent des tonnes de texte ! * *Ils utilisent des « réseaux neuronaux » (une sorte de circuit intelligent) pour apprendre des modèles dans les données et prédire ce qui va suivre dans un texte.* * *Ils peuvent « se concentrer » sur des parties spécifiques d’un texte pour répondre, générer du contenu ou réagir à votre saisie. C’est ce qu’on appelle « comprendre le contexte ».* *Parmi les LLM connus, on peut citer LaMDA de Google, LLaMA de Meta et les modèles de Microsoft (par exemple Copype).* *Souhaitez-vous que je vous explique quelque chose de précis sur les LLM ? Peut-être souhaitez-vous savoir comment ils fonctionnent ou quelles sont leurs applications ?* |
Sur la forme, les textes issus des modèles trimmés ne sont jamais sortis du sujet et sont donc semblables aux originaux.
Sur le fond, que ce soit les modèles trimmés ou originaux, les sorties générées ont tendance à traduire des termes techniques en lien avec les LLM/l’IA de l’anglais vers le néerlandais mais le font mal. Nous avons aussi observé que les modèles ont du mal avec le pluriel de certains mots. Concrètement, nos évaluateurs indiquent que les textes originaux ou trimmés ressemblent à des rédactions d’enfants pouvant parfois ici ou là utiliser quelques termes sophistiqués.
Sur ce point du fond, notez que les modèles montrés ici servent à illustrer le principe du trimming. En pratique, ces différents modèles datent un peu à présent et ne sont sûrement pas les plus utiles. Au moment où nous écrivons ces lignes, le granite 4.1, le gemma 4 et le qwen 3.6 viennent de sortir et seront probablement meilleurs (dans la section suivante nous pouvons déjà voir que le 3.5 est meilleur que le 3).
⚠️ Vigilance
Nos expériences de vibechecking ont également porté sur les traces et les prompts systèmes.
Nous observons que lorsqu'un modèle passe sous la barre des 300M de paramètres une fois trimmé, il a tendance à répondre en anglais par défaut (le Gemma 3 270M non trimmé a ainsi également ce comportement) ou bien pas dans la bonne langue. Il faut alors spécifier dans le prompt système la langue qu'il doit utiliser pour forcer la génération dans celle-ci. Là où pour les modèles plus grands que 300M de paramètres, il n'est pas nécessaire de modifier leur prompt original.
Concernant les traces, pour les modèles trimmés pour lesquels il est possible d'activer / désactiver le mode thinking, à savoir les Qwen 3 et le SmolLM3, les comportements sont variables. Le SmolLM3 générera systématiquement sa trace en anglais. Pour le Qwen 3, nous avons un comportement variable. Le modèle peut ne plus en générer, en générer en anglais ou bien en générer dans la langue trimmée. Ce dernier point nous semblait intéressant pour pouvoir par exemple générer directement des traces dans une langue d'intérêt (au lieu de devoir en générer en anglais puis les traduire). Cependant ce comportement ne semble pas se produire sur toutes les langues. Nous pouvons l'observer par exemple sur du français qui est proche de l'anglais mais nous n'avons pas réussi à observer ce phénomène sur des alphabets non latins testés comme le coréen, l'arabe ou le tamil. Cela semble aussi dépendre de la difficulté de la tâche.
Coréen
| Modèle | Moyenne macro / micro |
boolq (Questions-réponses booléennes) précision |
copa (Raisonnement causal) précision |
hellaswag (Sens commun) précision |
sentineg (Analyse de sentiment) précision |
wic (Désambiguïsation) précision |
|---|---|---|---|---|---|---|
| granite-4.0-350m | 49,08 49,09 |
50,21 | 50,30 | 33,60 | 62,47 | 48,81 |
| granite-4.0-350m-kor-32768 | 48,25 48,52 |
50,21 | 49,10 | 31,40 | 61,71 | 48,81 |
| granite-4.0-h-350m | 52,94 51,59 |
50,21 | 50,60 | 34,20 | 76,83 | 52,86 |
| granite-4.0-h-350m-kor-32768 | 52,83 51,41 |
50,21 | 50,40 | 33,00 | 78,09 | 52,46 |
| granite-4.0-1b | 56,19 53,26 |
50,36 | 54,00 | 38,00 | 87,41 | 51,19 |
| granite-4.0-1b-kor-32768 | 55,50 52,73 |
50,21 | 52,60 | 37,00 | 86,40 | 51,27 |
| granite-4.0-h-1b | 58,79 57,05 |
62,39 | 53,90 | 37,40 | 88,92 | 51,35 |
| granite-4.0-h-1b-kor-32768 | 55,88 52,99 |
50,50 | 53,00 | 36,80 | 87,91 | 51,19 |
| Qwen3-0.6B | 54,52 52,09 |
50,21 | 53,50 | 35,60 | 83,63 | 49,68 |
| Qwen3-0.6B-kor-32768 | 54,69 52,27 |
50,21 | 53,50 | 35,60 | 83,88 | 50,24 |
| Qwen3-1.7B | 58,09 55,38 |
50,21 | 56,30 | 37,60 | 89,67 | 56,67 |
| Qwen3-1.7B-kor-32768 | 58,03 55,36 |
50,28 | 56,20 | 37,60 | 89,42 | 56,67 |
| gemma-3-270m-it | 53,24 50,93 |
50,36 | 50,70 | 31,20 | 85,14 | 48,81 |
| gemma-3-270m-it-kor-32768 | 53,20 50,87 |
50,14 | 50,70 | 31,20 | 85,14 | 48,81 |
| gemma-3-1b-it | 60,26 58,21 |
63,25 | 60,10 | 36,60 | 92,44 | 48,89 |
| gemma-3-1b-it-kor-32768 | 60,30 58,25 |
63,11 | 60,60 | 36,20 | 92,70 | 48,89 |
Pour le coréen, nous observons que nous obtenons des résultats similaires aux modèles originaux à une exception : le granite 4.0-h où nous avons une dégradation de 3 points (ce que nous n’avons pas sur le néerlandais). Nous pouvons voir que c’est dû au jeu de données boolq sur lequel nous perdons 12 points. En analysant les résultats, il s’avère que le modèle trimmé s’effondre sur cette tâche sans que nous réussissions à modifier ce comportement (via le prompt, un changement des labels à trouver, ou encore de nombre de shots).
De toutes nos expériences (environ 90 modèles trimmés testés), c’est le seul modèle où nous observons une dégradation non attendue. C’est donc un cas isolé mais pouvant illustrer un cas limite du trimming.
🧠 À retenir
Le trimming fonctionne également sur les décodeurs, mais nous invitons les utilisateurs à être vigilants vis-à-vis de potentiels cas limites rares.
Collections
🎁 Important
Une collection rassemblant 96 modèles (12 langues différentes) trimmés à partir des granite 4.0 est disponible ici.
Une collection rassemblant 332 modèles (83 langues différentes) trimmés à partir des Qwen 3 est disponible ici.
Une collection rassemblant 486 modèles (122 langues différentes) trimmés à partir des Gemma 3 est disponible ici.
Une collection rassemblant 16 modèles (8 langues différentes) trimmés à partir du smolLM3 est disponible ici.
Modèles multimodaux (VLM)
Observons à présent l’impact du trimming sur les performances des VLM.
Modèles et benchmarks sélectionnés
Nous nous sommes dirigés sur deux VLM pour cette section :
- Les Qwen 3.5 de Qwen Team (2026) en taille
0.8B,2Bet4B; - Le Gemma 3 4B de Google DeepMind (2025).
Ne disposant pas de benchmarks pour évaluer ces modèles dans d’autres langues que l’anglais, nous nous sommes limités dans cette section à du vibechecking en soumettant des images au modèle et en lui demandant de nous les décrire.
Pour une question de place, nous exposons un exemple pour le français et un pour l’espagnol.
Réductions de paramètres observées
| Modèle | Taille du vocabulaire (original) | Taille du vocabulaire (trimmé) | % Réduction vocabulaire | Paramètres (original) | Paramètres (trimmé) | % Réduction paramètres |
|---|---|---|---|---|---|---|
| Qwen3.5-0.8B | 248 320 | 16 384 | - 93,40% | 853,0M | 615,5M | - 27,84% |
| Qwen3.5-0.8B | 248 320 | 32 768 | - 86,80% | 853,0M | 632,3M | - 25,88% |
| Qwen3.5-2B | 248 320 | 16 384 | - 93,40% | 2,213B | 1,738B | - 21,46% |
| Qwen3.5-2B | 248 320 | 32 768 | - 86,80% | 2,213B | 1,772B | - 19,95% |
| Qwen3.5-4B | 248 320 | 16 384 | - 93,40% | 4,539B | 3,946B | - 13,08% |
| Qwen3.5-4B | 248 320 | 32 768 | - 86,80% | 4,539B | 3,987B | - 12,16% |
| gemma-3-4b-it | 262 208 | 16 384 | - 93,75% | 4,300B | 3,671B | - 14,63% |
| gemma-3-4b-it | 262 208 | 32 768 | - 87,50% | 4,300B | 3,713B | - 13,66% |
Résultats
Français
Prompt utilisé pour tous les modèles : « Décris cette image en détail. »
Qwen3.5 0.8B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Cette image montre une collection de fleurs de cosmos en rose, avec une bumblebee au centre de la composition. La bumblebee, avec ses taches noires et blanches, est assise sur la fleur principale, qui est l'objet central de l'image. Les autres fleurs de cosmos, de différentes couleurs (rose, rouge, blanche), sont dispersées autour de la fleur principale, certaines étant en fleurs et d'autres en fleurs mortes. Le fond est composé de feuilles vertes et de fleurs de cosmos en fleurs mortes, créant un arrière-plan naturel et coloré. | L'image montre une scène de nature avec des fleurs de cosmos en violet pâle, une bumblebee au centre de la composition, et d'autres fleurs de cosmos et de gerberas en arrière-plan. La bumblebee, avec ses taches noires et blanches, est assise sur la fleur principale, probablement en quête de nourriture. Les autres fleurs, certaines encore en fleurs et d'autres déjà séchées, ajoutent de la couleur et de la texture à l'arrière-plan. Le fond est rempli de feuilles vertes et de branches, créant un cadre naturel pour cette image de fleurs et d'insectes. |
Qwen3.5 2B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Cette image capture une scène de jardin florale vibrante, centrée sur une grande fleur rose pâle en pleine floraison. Une abeille noire et jaune est visible au centre de la fleur, collectant du pollen. Autour d'elle, d'autres fleurs colorées — rouges, violettes et blanches — s'ouvrent également, tandis que des tiges et des feuilles vertes forment un arrière-plan naturel et luxuriant. L'ensemble de l'image évoque la vie et la beauté du jardin, avec une composition équilibrée et une ambiance apaisante. | Cette image capture une scène de jardin en pleine vie, centrée sur une fleur de cosmos rose vif qui attire l’attention. Au centre, une abeille noire et jaune est en train de collecter du pollen sur le centre de la fleur, ses ailes translucides légèrement déployées. La fleur principale, avec ses pétales larges et douces, contraste avec d’autres fleurs autour : des roses plus pâles, des fleurs rouges éclatantes en arrière-plan, et des tiges de plantes séchées ou en fleurs blanches, suggérant une saison printanière ou estivale. Le fond est flou, mettant en valeur la profondeur de champ et la netteté du sujet. Des feuilles vertes et des tiges fines complètent le cadre naturel, créant une ambiance apaisante et vivante. |
Qwen3.5 4B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Cette image montre une fleur rose vif, probablement un cosmos, au centre de l’encadrement, avec un bourdon noir et blanc en train de butiner son pollen jaune. Autour d’elle, d’autres fleurs roses sont visibles — certaines encore fraîches, d’autres déjà fanées ou séchées, montrant des tiges brunes et des pétales effilochés. En bas à droite, une petite fleur rouge vive contraste avec les tons roses dominants. Le fond est flou, mais on devine des feuilles vertes et d’autres éléments floraux, créant une ambiance naturelle et paisible. L’ensemble évoque un jardin en pleine saison, où la vie et la décomposition coexistent harmonieusement. | Cette image présente une fleur rose vif, probablement un cosmos, au centre de l’encadrement, avec un grand bourdon noir et blanc en train de butiner son pollen jaune. Autour d’elle, d’autres fleurs roses sont visibles — certaines encore fraîches, d’autres déjà fanées et séchées, montrant le cycle naturel de la vie végétale. En bas à droite, une petite fleur rouge écarlate ajoute un contraste vibrant, tandis que des feuilles vertes floues forment un fond doux qui met en valeur les sujets principaux. La composition évoque une scène paisible dans un jardin ou un massif floral, où la nature se déploie avec harmonie et simplicité. |
Qwen3.5 4B (thinking) : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
|
<think> The user wants a detailed description of the image in French. **Image Analysis:** - **Main Subject:** A large, light pink cosmos flower (Cosmos bipinnatus) in the center. - **Action:** A bumblebee is on the center of the flower, collecting pollen. - **Surroundings:** - To the left: Another pink cosmos flower, slightly out of focus. - Background: Green foliage, some dried brown flower heads (seed pods). - Bottom right: A small red geranium flower. - Top right: Some wilting pink flowers. - **Lighting/Color:** Natural daylight, soft focus background (bokeh), vibrant pinks and greens. **Drafting the description (internal monologue/rough notes):** - Une grande fleur rose, un cosmos, est au centre. - Une abeille bourdonne dessus, elle est noire et blanche. - Il y a d'autres fleurs roses autour, mais floues. - En bas à droite, une petite fleur rouge. - Il y a des tiges sèches et des feuilles vertes en arrière-plan. **Refining into French:** 1. Au centre de l'image, une grande fleur cosmos rose pâle s'épanouit avec élégance. 2. Une abeille bourdonne activement au cœur de cette fleur, recueillant le pollen jaune. 3. À gauche, une autre fleur rose est visible, bien que légèrement floue, tandis que des tiges séchées et des graines brunes parsèment le champ. 4. En arrière-plan, on distingue des feuilles vertes et quelques fleurs roses fanées qui ajoutent de la texture à la scène. 5. En bas à droite, une petite fleur rouge vif contraste avec les tons dominants de rose et de vert. 6. L'ensemble de la composition capture un instant paisible de la nature, mettant en valeur l'interaction entre l'insecte et la plante. **Final Polish:** Au centre de l'image, une grande fleur cosmos rose pâle s'épanouit avec élégance, attirant l'attention par sa couleur douce. Une abeille bourdonne activement au cœur de cette fleur, recueillant le pollen jaune qui contraste avec ses ailes noires et blanches. À gauche, une autre fleur rose est visible, bien que légèrement floue, tandis que des tiges séchées et des graines brunes parsèment le champ. En arrière-plan, on distingue des feuilles vertes et quelques fleurs roses fanées qui ajoutent de la texture à la scène. En bas à droite, une petite fleur rouge vif contraste avec les tons dominants de rose et de vert. L'ensemble de la composition capture un instant paisible de la nature, mettant en valeur l'interaction entre l'insecte et la plante. Wait, let's make it slightly tighter to ensure it feels natural. Let's go with a 5-sentence version to be safe on the "detailed" part. 1. Au centre de l'image, une grande fleur cosmos rose pâle s'épanouit avec élégance, attirant l'attention par sa couleur douce. 2. Une abeille bourdonne activement au cœur de cette fleur, recueillant le pollen jaune qui contraste avec ses ailes noires et blanches. 3. À gauche, une autre fleur rose est visible, bien que légèrement floue, tandis que des tiges séchées et des graines brunes parsèment le champ. 4. En arrière-plan, on distingue des feuilles vertes et quelques fleurs roses fanées qui ajoutent de la texture à la scène. 5. En bas à droite, une petite fleur rouge vif contraste avec les tons dominants de rose et de vert. This is good. I will use this. </think> Au centre de l'image, une grande fleur cosmos rose pâle s'épanouit avec élégance, attirant l'attention par sa couleur douce. Une abeille bourdonne activement au cœur de cette fleur, recueillant le pollen jaune qui contraste avec ses ailes noires et blanches. À gauche, une autre fleur rose est visible, bien que légèrement floue, tandis que des tiges séchées et des graines brunes parsèment le champ. En arrière-plan, on distingue des feuilles vertes et quelques fleurs roses fanées qui ajoutent de la texture à la scène. En bas à droite, une petite fleur rouge vif contraste avec les tons dominants de rose et de vert. |
<think> The user has provided an image and asked for a description in French. The image shows a close-up of a garden scene. Key elements: - A large, vibrant light-pink cosmos (or similar dahlia-like) in the center. - A bumblebee is on the center of this main bloom, pollination is visible. - To the left, another similar light-pink cosmos is visible, but cut off. - There are several withered, brown, dead florets around the main bloom. - In the background, there are other plants: a large green lily pad or similar large green shape at the top, and some red geraniums (pelargoniums) at the bottom right. - There are also some wilting, purplish-pink cosmos in the background. - The focus is very deep on the central bloom and the bumblebee. Structure of the description (4-6 sentences): 1. Start with the main subject: the central light-pink cosmos and the bumblebee. 2. Mention the action: the bumblebee is pollination. 3. Mention the context/surrouding: other cosmos, dead florets. 4. Mention the background elements: red geraniums, greenery. 5. Convey the general feeling: natural, garden scene. Let's draft the French sentences: 1. Cette image présente un plan rapproché d'une fleur rose pâle, probablement un cosmos, au centre de l'encadrement. 2. Une bourdon, aux couleurs noires et blanches, est perche sur le cœur jaune de la fleur, en train de butiner le pollen. 3. Autour de cette floraison principale, on observe plusieurs autres tiges portant des fleurs roses, certaines en pleine fleur et d'autres déjà fanées et brunes. 4. En arrière-plan, on devine des feuilles vertes floues et quelques fleurs rouges, semblables à des géraniums, qui ajoutent de la couleur à la scène. 5. L'ensemble dépeint une scène de jardin naturelle et vivante, mettant en valeur l'interaction entre l'insecte et la plante. Refining for flow and detail: - "Cette image capture une scène de jardin en gros plan, centrée sur une magnifique fleur rose pâle, vraisemblablement un cosmos." - "Une bourdon, avec son corps noir et blanc caractéristique, est posée au centre de la fleur, occupant le cœur jaune et récoltant le pollen." - "Autour de cette floraison principale, plusieurs autres tiges portent des fleurs roses, certaines en pleine beauté tandis que d'autres sont déjà fanées et brunes." - "En arrière-plan, on distingue des feuilles vertes floues et quelques fleurs rouges, probablement des géraniums, qui encadrent la composition." - "L'ensemble offre une vue détaillée et apaisante de la nature, mettant en évidence l'activité de pollinisation dans un environnement floral varié." This looks good. It's descriptive, in French, and within the sentence limit. </think> Cette image capture une scène de jardin en gros plan, centrée sur une magnifique fleur rose pâle, vraisemblablement un cosmos. Une bourdon, avec son corps noir et blanc caractéristique, est posée au centre de la fleur, occupant le cœur jaune et récoltant le pollen. Autour de cette floraison principale, plusieurs autres tiges portent des fleurs roses, certaines en pleine beauté tandis que d'autres sont déjà fanées et brunes. En arrière-plan, on distingue des feuilles vertes floues et quelques fleurs rouges, probablement des géraniums, qui encadrent la composition. L'ensemble offre une vue détaillée et apaisante de la nature, mettant en évidence l'activité de pollinisation dans un environnement floral varié. |
Gemma3 4B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| L'image présente une scène de jardin fleuri, dominée par des cosmos roses vifs. Une grosse abeille noire et jaune est en train de se nourrir sur l'une des fleurs, illustrant l'importance des pollinisateurs dans cet écosystème. Au premier plan, un cosmos particulièrement beau attire l'attention grâce à sa couleur saturée et sa forme élégante. En arrière-plan, on aperçoit d'autres fleurs, dont une rouge, ainsi que des feuilles vertes luxuriantes, créant un tableau coloré et naturel. L'ensemble dégage une impression de calme et de vitalité, typique d'un jardin en pleine floraison. | L'image montre un champ de cosmos roses en pleine floraison. Une abeille noire et jaune est activement en train de butiner une des fleurs centrales. On observe également quelques fleurs fanées environnantes, de couleur rose et rouge, et des feuilles vertes en arrière-plan. Le tout est entouré d'un fond de végétation dense et luxuriante. La lumière semble douce et diffuse, créant une atmosphère paisible et naturelle. |
Nous pouvons voir que les réponses des modèles trimmés restent semblables aux modèles originaux.
Pour le modèle 0.8B, la sortie évoque bien le cosmos dans les deux cas (un rose, l’autre violet pâle), l’insecte bumblebee (la vraie réponse attendue étant un bourdon mais nous avons donc une consistance entre les deux modèles) et les fleurs (mortes pour l’un, séchées pour l’autre) en arrière-plan.
Pour le 2B, nous avons à nouveau le cosmos (rose pâle pour l’un, rose vif pour l’autre), une abeille à la place de bumblebee. Le modèle trimmé est un peu plus verbeux.
Pour le 4B (non thinking), nous avons bien le cosmos (rose vif pour tous les deux), le bourdon (le bon animal pour tous les deux) et une description sur le fond variant légèrement entre les deux modèles mais se retrouvant sur le fond.
Pour le 4B (thinking), nous pouvons observer que la trace (en anglais dans les 2 cas) du modèle original est plus long. Ce qui n’indique pas forcément de meilleurs résultats puisque le modèle nous parle d’abeille au lieu de bourdon (le modèle trimmé utilisant cependant « une » bourdon au lieu de « un » bourdon).
Pour le gemma-3, le modèle original est un peu plus verbeux (ajoute davantage d’adjectifs que le modèle trimmé qui rapporte surtout l’essentiel). Les deux modèles nous parlent d’abeilles au lieu de bourdon.
Espagnol
Prompt utilisé pour tous les modèles : « Esto es lo que tengo en mi mano. Si como un caramelo de cada color, ¿cuántos caramelos me quedarán al final? » (Voici ce que j’ai dans ma main. Si je mange un bonbon de chaque couleur, combien me restera t’il de bonbon à la fin ?)
Qwen3.5 0.8B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Tengo 4 caramelos, 2 de cada color. Si me los da un caramelo de cada color, me quedarán 2 caramelos. J'ai 4 bonbons, 2 de chaque couleur. S'il m'en donne un de chaque couleur, il m'en restera 2. |
Tengo 4 caramelos de colores diferentes. Si me los come uno por uno, me quedarán 3 caramelos. J'ai 4 bonbons de couleurs différentes. Si je les mange un par un, il m'en restera 3. |
Qwen3.5 2B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Tienes 4 caramelos en total: 2 verdes, 2 naranjas y 1 verde. Si los comes todos, quedarán 0 caramelos. Tu as 4 bonbons au total : 2 verts, 2 orange et 1 vert. Si tu les manges tous, il ne restera plus aucun bonbon. |
Si comes un caramelo de cada color, tendrás 4 caramelos en total. Los caramelos de colores verde, naranja y azul están en tu mano, y el naranja también está visible. Al comer uno de cada color, quedarán 4 caramelos en tu mano. Si tu manges un bonbon de chaque couleur, tu auras 4 bonbons au total. Les bonbons verts, orange et bleus sont dans ta main, et le bonbon orange est également visible. En mangeant un de chaque couleur, il te restera 4 bonbons dans la main. |
Qwen3.5 4B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| Tienes 5 caramelos en total: 2 azules, 2 naranjas y 1 verde. Si comes uno de cada color, comerás 3 caramelos. 5 menos 3 es igual a 2. Por lo tanto, te quedarán 2 caramelos al final. Tu as 5 bonbons au total : 2 bleus, 2 orange et 1 vert. Si tu manges un bonbon de chaque couleur, tu en auras mangé 3. 5 moins 3, ça fait 2. Il te restera donc 2 bonbons à la fin. |
Tienes 5 caramelos en total: 2 azules, 2 naranjas y 1 verde. Si comes uno de cada color, comerás 3 caramelos (uno azul, uno naranja y uno verde). 5 menos 3 es igual a 2. Al final te quedarán 2 caramelos. Tu as 5 bonbons au total : 2 bleus, 2 orange et 1 vert. Si tu manges un bonbon de chaque couleur, tu en auras mangé 3 (un bleu, un orange et un vert). 5 moins 3, ça fait 2. Il te restera donc 2 bonbons. |
Qwen3.5 4B (thinking) : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
|
<think> The user wants to know how many candies are left if they eat one of each color. 1. **Count the candies:** I need to look at the image and count the total number of candies. * There's a teal one at the top. * There's a teal one below it with a leaf symbol. * There's an orange one below that. * There's an orange one with a symbol. * There's a green one at the bottom. * Total count: 5 candies. 2. **Identify the colors:** * Teal (2 candies) * Orange (2 candies) * Green (1 candy) 3. **Analyze the condition:** "Si como un caramelo de cada color" (If I eat one candy of each color). * Colors present: Teal, Orange, Green. * Action: Eat one of each. 4. **Calculate the remaining candies:** * Start with 5. * Eat 1 Teal -> 4 left. * Eat 1 Orange -> 3 left. * Eat 1 Green -> 2 left. * Alternatively: Total (5) - Colors (3) = 2 remaining. 5. **Formulate the answer:** * State the total number of candies (5). * State the number of colors (3: teal, orange, green). * Explain the subtraction (5 - 3 = 2). * Conclude with the final number. 6. **Refine the Spanish response:** * "En la imagen hay un total de 5 caramelos." * "Están en tres colores distintos: dos azules turquesa, dos naranjas y uno verde." * "Si comes uno de cada color (azul, naranja y verde), restas 3 caramelos del total." * "Por lo tanto, te quedarán 2 caramelos al final." 7. **Final Polish:** Ensure natural flow. "En la imagen se pueden contar un total de 5 caramelos en la palma de la mano. Estos caramelos están distribuidos en tres colores diferentes: dos de color turquesa, dos de color naranja y uno de color verde. Si decides comer un caramelo de cada uno de los tres colores presentes, estarás comiendo 3 caramelos en total. Al restar esos 3 caramelos del total inicial de 5, te quedarán exactamente 2 dulces." Wait, let me double check the count. - Top teal - Teal with leaf - Orange - Orange with symbol - Green Yes, 5 total. 3 colors. 5 - 3 = 2. Correct. Let's try to make it slightly more conversational but still formal enough. "En la foto se observan un total de 5 caramelos sostenidos en la mano. Estos se dividen en tres colores distintos: dos son de color turquesa, dos son naranjas y uno es verde. Si comes un caramelo de cada color, estarás consumiendo 3 dulces en total. Por lo tanto, al restar esos 3 del total inicial, te quedarán 2 caramelos al final." This looks good. 4 sentences. </think> En la foto se observan un total de 5 caramelos sostenidos en la mano. Estos se dividen en tres colores distintos: dos son de color turquesa, dos son naranjas y uno es verde. Si comes un caramelo de cada color, estarás consumiendo 3 dulces en total. Por lo tanto, al restar esos 3 del total inicial, te quedarán 2 caramelos al final. Sur la photo, on voit au total 5 bonbons tenus dans la main. Ils se répartissent en trois couleurs différentes : deux sont turquoise, deux sont orange et un est vert. Si tu manges un bonbon de chaque couleur, tu en auras consommé 3 au total. Par conséquent, en soustrayant ces 3 bonbons du nombre initial, il t'en restera 2 à la fin. |
<think>
El usuario quiere saber cuántos caramelos le quedan si come uno de cada color.
Primero, debo contar los caramelos en la imagen.
Veo:
- 2 caramelos azules/verdes (turquesa).
- 2 caramelos naranjas.
- 1 caramelo verde brillante.
Total: 2 + 2 + 1 = 5 caramelos.
Ahora, la pregunta es: "Si me como un caramelo de cada color, ¿cuántos caramelos me quedarán al final?"
Esto es un poco ambiguo. ¿Significa que come un caramelo de *cada* color disponible (azul, naranja, verde)?
Si come un caramelo de cada color:
- Come 1 azul.
- Come 1 naranja.
- Come 1 verde.
Total comido: 3 caramelos.
Caramelos restantes: 5 (totales) - 3 (comidos) = 2 caramelos.
Otra interpretación: ¿Significa que come un caramelo de *cada* color que ve? Sí, eso es lo mismo.
Hay 3 colores: azul, naranja, verde.
Si come uno de cada uno, come 3 caramelos.
Le quedan 2.
Voy a responder directamente.
1. Contar los caramelos: Hay 5 caramelos en total (2 azules, 2 naranjas y 1 verde).
2. Calcular el consumo: Si comes un caramelo de cada color (azul, naranja y verde), comerás 3 caramelos.
3. Calcular el resto: 5 menos 3 son 2.
4. Especificar qué te quedaría: Te quedarían 2 caramelos (probablemente uno azul y uno naranja, o dos naranjas si el azul se come primero, pero la cantidad es 2).
Respuesta final:
Tienes 5 caramelos en total (2 azules, 2 naranjas y 1 verde). Si comes un caramelo de cada color, comerás 3 caramelos en total. Por lo tanto, te quedarán 2 caramelos al final.
</think>
Tienes 5 caramelos en total (2 azules, 2 naranjas y 1 verde). Si comes un caramelo de cada color, comerás 3 caramelos en total. Por lo tanto, te quedarán 2 caramelos al final.
Tu as 5 bonbons au total (2 bleus, 2 orange et 1 vert). Si tu manges un bonbon de chaque couleur, tu en auras mangé 3 au total. Il t'en restera donc 2 à la fin. |
Gemma3 4B : Voir la comparaison original / trimmé
| Original | Trimmé |
|---|---|
| En tu mano hay tres caramelos: uno naranja, uno azul y uno verde. Si comes uno de cada color, consumirás tres caramelos en total. Después de comerlos, te quedará cero caramelos en tu mano. ¡Te los has comido todos! Tu as trois bonbons dans la main : un orange, un bleu et un vert. Si tu manges un bonbon de chaque couleur, tu auras mangé trois bonbons au total. Une fois que tu les auras mangés, il ne te restera plus aucun bonbon dans la main. Tu les auras tous mangés ! |
Hay tres caramelos en tu mano: uno naranja, uno turquesa y uno verde. Si comes un caramelo de cada color, consumirás tres caramelos en total. Al final, te quedará cero caramelos. ¡Todo se ha ido! Tu as trois bonbons dans la main : un orange, un turquoise et un vert. Si tu manges un bonbon de chaque couleur, tu en auras mangé trois au total. À la fin, il ne te restera plus aucun bonbon. Il n'en reste plus un seul ! |
Comme pour le français, nous pouvons constater que les réponses des modèles trimmés restent semblables aux modèles originaux.
Sur le fond du problème à résoudre, les Qwen 0.8B et 2B qu’ils soient trimmés ou pas n’y arrivent pas. De même que le gemma3 4b.
Le Qwen3.5 4B est capable de donner la bonne réponse que nous activions ou pas le mode thinking.
Une observation intéressante se situe au niveau de la trace. Celle du modèle trimmé est plus courte, mais surtout a été générée en espagnol plutôt qu’en anglais.
C’est le phénomène que nous décrivions dans la section précédente pour les Qwen3.
Notons que la trace de l’exemple du Qwen 3.5 4B en français a été générée en anglais et non en français. Ainsi, comme pour les décodeurs, il apparaît comme possible de générer des traces dans la langue du modèle trimmé mais que la consistance de cette génération n’est pas acquise. Nous aurions souhaité pouvoir mener des expériences plus poussées sur le sujet en faisant varier les langues, les types de questions et les tailles de modèles pour savoir si, par exemple, à partir d’une certaine taille, ce phénomène deviendrait possible de manière systématique.
⚠️ Vigilance
Nous sommes gênés de ne pas disposer de benchmark pour cette partie et de devoir ainsi nous limiter à du vibechecking. Nous invitons fortement le lecteur à effectuer des tests par lui-même de son côté.
Notamment être vigilant sur les langues peu dotées ou utilisant un autre alphabet que le latin, sur lesquelles nous n'avons pas pu effectuer de tests.
🧠 À retenir
Il semblerait que dans le cadre des VLM, le trimming permet de maintenir des sorties équivalentes aux modèles originaux (à minima pour les langues à alphabet latin et fortement dotée en ressources).
Comme pour les modèles décodeurs, il est possible de générer des traces dans la langue d'intérêt mais la manière d'obtenir ceci méthodiquement reste encore incertaine.
Collections
🎁 Important
Une collection rassemblant 498 modèles (83 langues différentes) trimmés à partir du Qwen 3.5 est disponible ici.
Une collection rassemblant 243 modèles (122 langues différentes) trimmés à partir du Gemma 3 multimodal est disponible ici.
Modèles d’embeddings visuels (CLIP)
Concluons nos expériences en nous intéressant aux modèles d’embeddings visuels.
Modèles et benchmarks sélectionnés
Dans cette section de l’article, nous analysons les modèles suivants :
- Le clip-ViT-B-32-multilingual-v1 de REIMERS et GUREVYCH (2021) ;
- Le MetaCLIP2 de Meta (2025) en taille
s16,m16,b16,l14,hugeetgiant.
Concernant l’évaluation, les benchmarks non anglais étant rares, nous avons fait le choix de proposer plutôt des notebooks d’utilisation des modèles avec la librairie Sentence Transformers puisque la version 5.4 sortie en avril 2026 permet d’utiliser facilement ce type de modèles.
Nous nous focalisons notamment sur la recherche d’images et la classification d’image en 0-shot.
Réductions de paramètres observées
| Modèle | Taille du vocabulaire (original) | Taille du vocabulaire (trimmé) | % Réduction vocabulaire | Paramètres (original) | Paramètres (trimmé) | % Réduction paramètres |
|---|---|---|---|---|---|---|
| clip-ViT-B-32-multilingual-v1 (encodeur visuel inclus) | 119 547 | 16 384 | - 86,30% | 223,0M | 143,7M | - 35,53% |
| clip-ViT-B-32-multilingual-v1 (encodeur visuel inclus) | 119 547 | 32 768 | - 72,59% | 223,0M | 156,3M | - 29,89% |
| clip-ViT-B-32-multilingual-v1 (encodeur visuel exclus) | 119 547 | 16 384 | - 86,30% | 135,1M | 55,9M | - 58,63% |
| clip-ViT-B-32-multilingual-v1 (encodeur visuel exclus) | 119 547 | 32 768 | - 72,59% | 135,1M | 68,5M | - 49,32% |
| metaclip-2-worldwide-s16-384 | 901 629 | 16 384 | - 98,18% | 389,7M | 49,7M | - 87,24% |
| metaclip-2-worldwide-s16-384 | 901 629 | 32 768 | - 96,37% | 389,7M | 56,0M | - 85,62% |
| metaclip-2-worldwide-m16-384 | 901 629 | 16 384 | - 98,18% | 538,5M | 85,3M | - 84,16% |
| metaclip-2-worldwide-m16-384 | 901 629 | 32 768 | - 96,37% | 538,5M | 93,7M | - 82,60% |
| metaclip-2-worldwide-b16-384 | 901 629 | 16 384 | - 98,18% | 586,2M | 133,0M | - 77,31% |
| metaclip-2-worldwide-b16-384 | 901 629 | 32 768 | - 96,37% | 586,2M | 141,4M | - 75,88% |
| metaclip-2-worldwide-l14 | 901 629 | 16 384 | - 98,18% | 1,082B | 402,3M | - 62,83% |
| metaclip-2-worldwide-l14 | 901 629 | 32 768 | - 96,37% | 1,082B | 414,8M | - 61,66% |
| metaclip-2-worldwide-huge-378 | 901 629 | 16 384 | - 98,18% | 1,859B | 952,9M | - 48,75% |
| metaclip-2-worldwide-huge-378 | 901 629 | 32 768 | - 96,37% | 1,859B | 969,7M | - 47,85% |
| metaclip-2-worldwide-giant-378 | 901 629 | 16 384 | - 98,18% | 3,631B | 2,519B | - 31,20% |
| metaclip-2-worldwide-giant-378 | 901 629 | 32 768 | - 96,37% | 3,631B | 2,498B | - 30,63% |
📝 Note
Le clip-ViT-B-32-multilingual-v1 et le MetaCLIP-2 ayant une taille de vocabulaire n'étant pas un multiple de 64, le trimming semble particulièrement adapté même dans le cas où nous ne souhaitons pas spécifiquement créer un modèle monolingue/n-lingue.
Résultats
Recherche d’images
Pour la tâche de recherche d’images, vous pouvez consulter les deux notebooks suivants qui ont été réalisé pour la documentation de Sentence Transformers : la version monolingue anglais et la version multilingue.
Dans le premier, nous comparons une recherche effectuée via un CLIP de RADFORD, KIM et al. (2021) avec un MetaCLIP-2 original et trimmé. Nous pouvons constater aucune perte entre les deux versions (les résultats sont identiques).
Dans le second, nous appliquons le clip-ViT-B-32-multilingual-v1.
Classification d’images en 0-shot
Pour cette tâche, nous vous invitons à consulter le notebook suivant.
Une alternative est d’utiliser ce Space qui permet de comparer, pour toutes les langues utilisées dans cet article de blog, un modèle original à ses versions trimmées en 32 768 et 16 384 tokens.
Le notebook portant surtout sur comment effectuer de la classification d’images en 0-shot plutôt que sur les modèles trimmés, nous n’avons pas listé dans celui-ci deux observations intéressantes que nous détaillons donc ci-dessous.
La première est que même si un modèle est trimmé sur une langue donnée, il peut conserver des capacités dans d’autres langues. C’est particulièrement le cas pour les langues proches partageant un même alphabet.
Par exemple, si nous utilisons le clip-ViT-B-32-multilingual-v1 avec les classes “Hund” (chien en allemand), “gato” (chat en espagnol), “Paris de jour” et “Paris at night” (Paris de nuit) sur 4 images différentes, nous obtenons :
Et si nous refaisons le même test mais avec à la place la version trimmée du modèle sur un corpus d’espagnol pour être optimisé dans cette langue, nous constatons que les résultats sont identiques.
Refaisons la même expérience sur des langues utilisant un alphabet différent avec toujours le clip-ViT-B-32-multilingual-v1 mais avec les classes “Hund” (chien en allemand), “gato” (chat en espagnol), “파리” (Paris en coréen) et “باريس ليلا” (Paris de nuit en arabe) sur les 4 images précédentes, nous obtenons :
En appliquant, à nouveau le modèle trimmé sur l’espagnol, nous pouvons constater que les performances se dégradent fortement sur les langues n’utilisant pas l’alphabet latin (- 18% pour la première image, et la réponse de la deuxième devient fausse) :
La seconde observation porte sur la quantification. En effet, nous avons vu plus haut que le trimming peut être une alternative à la distillation. Qu’en est-il de la quantification ?
Prenons un exemple consistant à faire de la classification 0-shot sur l’image suivante :
Faisons un test sur le tamoul avec les classes பூனைகள் (Chats), சிங்கங்கள் (Lions) et புலிகள் (Tigres), et le modèle metaclip-2-worldwide-s16-384. Les résultats sont les suivants :
| Configuration | பூனைகள் (Chats) | சிங்கங்கள் (Lions) | புலிகள் (Tigres) | Taille |
|---|---|---|---|---|
| Original FP32 | 0,992750883102417 | 0,005200702231377363 | 0,002048447960987687 | 1486,42 MB |
| Original BF16 | 0,9921875 | 0,005218505859375 | 0,002166748046875 | 743,21 MB |
| Trimming 32768 FP32 | 0,992750883102417 | 0,005200702231377363 | 0,002048447960987687 | 213,68 MB |
| Trimming 32768 BF16 | 0,9921875 | 0,005218505859375 | 0,002166748046875 | 106,84 MB |
| Trimming 16384 FP32 | 0,992750883102417 | 0,005200702231377363 | 0,002048447960987687 | 189,68 MB |
| Trimming 16384 BF16 | 0,9921875 | 0,005218505859375 | 0,002166748046875 | 94,84 MB |
Nous avons laissé délibérément tous les chiffres pour illustrer que le trimming est extrêmement robuste sur les embeddings visuels.
Nous pouvons voir qu’il n’y a aucune dégradation entre modèle original (FP32) et ses variantes trimmées en 32 768 et 16 384 tokens. Le passage en BF16 dégrade très légèrement les résultats mais pas de quoi remettre en cause les conclusions de la classification.
Si l’on compare le trimming à la quantification, il apparaît que pour ces types de modèles, le trimming est plus intéressant. En effet, nous passons de 1486,42 MB à 189,68 MB pour le trimming soit 87,24% de réduction de la taille mémoire, contre une réduction de 50% pour le BF16 (passage de 1486,42 MB à 743.21 MB).
Mais en combinant les deux approches, trimming et quantification permettent de se ramener à seulement 94,84 MB soit 93,62% de réduction !
Cet exemple laisse supposer que le trimming sur les CLIP donne des résultats identiques au modèle original. C’est un exemple extrême avec le tamoul qui nécessite peu de tokens minés pour cette tâche (voir la partie Nombre de tokens à conserver ci-après). En recommençant la même chose mais cette fois avec le français, nous obtenons :
| Configuration | Chats | Lions | Tigres | Taille |
|---|---|---|---|---|
| Original FP32 | 0,9781160354614258 | 0,0006950251990929246 | 0,021188927814364433 | 1486,42 MB |
| Original BF16 | 0,98046875 | 0,000789642333984375 | 0,020263671875 | 743,21 MB |
| Trimming 32768 FP32 | 0,9983513355255127 | 0,0007094039465300739 | 0,0009392466163262725 | 213,68 MB |
| Trimming 32768 BF16 | 0,98046875 | 0,000789642333984375 | 0,020263671875 | 106,84 MB |
| Trimming 16384 FP32 | 0,9984958171844482 | 0,0013454135041683912 | 0,00015876817633397877 | 189,68 MB |
| Trimming 16384 BF16 | 0,998419761657715 | 0,001411437988281 | 0,000168800354004 | 94,84 MB |
Nous avons cette fois des modèles trimmés faisant mieux que l’original, et la version BF16 faisant mieux que la FP32 pour le modèle original. À nouveau, la combinaison du trimming et de la quantification apparaît comme très pertinente.
📝 Note
Deux autres notebooks sont disponibles. L'un sur de la déduplication d'images exactes ou similaires et l'autre sur du clustering d'images.
🧠 À retenir
Sur des modèles d'embeddings visuels de type CLIP, le trimming permet d'obtenir des performances identiques au modèle original plus de 15 chiffres après la virgule.
Les modèles trimmés obtenus sont très légers (c'est sur eux que nous observons les plus grandes réductions du nombre de paramètres de tous les modèles présentés dans cet article) et restent plus performants que des modèles obtenus par quantification BF16. L'association de ces deux méthodes apparaît comme très compétitive.
Nous pouvons aussi constater que même si nous transformons un modèle multilingue en un modèle monolingue, il est possible de garder des capacités multilingues, notamment sur des langues partageant un même alphabet.
Collections
🎁 Important
Une collection rassemblant 98 modèles (49 langues différentes) trimmés à partir du clip-ViT-B-32-multilingual-v1 est disponible ici.
Une collection rassemblant 1 152 modèles (97 langues différentes) trimmés à partir des MetaCLIP2 est disponible ici.
Questions ouvertes❓
Nombre de tokens à conserver
La question s’est posée de savoir quelle est la meilleure taille de modèle pour le vocabulaire du modèle trimmé. Il s’avère que plus nous avons creusé la question, plus nous remettions en cause notre compréhension des tokenizers. En effet, il semble que la taille à conserver dépend de beaucoup de facteurs :
1) Le modèle original
Sur ce graphique, nous pouvons constater que sur les 200 000 textes issus de Fineweb-2 ayant servi au minage (mais également à l’entraînement du mmBERT), 25 908 tokens permettent de couvrir 95% des tokens vus dans la base de données de minage. Ce sont 66 002 tokens pour 99% et 154 270 tokens pour 100%. Sur les 256 000 tokens d’origine, nous pouvons passer de 101 730 tokens qui n’apparaissent jamais dans des textes anglais soit une réduction de 39M de paramètres (-27,8%) du nombre de paramètres assurés. Mais devons-nous réellement garder la longue queue de 88 268 tokens représentant le dernier pourcent soit une réduction potentielle de 33,9M de paramètres supplémentaires (- 24,13 %). Et pourquoi s’arrêter à 99% et non pas 98 ou 97 ?
Les choses se corsent quand nous analysons les 14 autres architectures :
| Architectures | Tokens pour couvrir 95% de la base de minage | Tokens pour couvrir 99% de la base de minage | Tokens pour couvrir 100% de la base de minage |
|---|---|---|---|
| granite-embedding | 10 357 | 20 201 | 62 161 |
| bge-m3 | 10 357 | 20 201 | 62 161 |
| multilingual-e5 | 10 365 | 20 213 | 62 184 |
| mbart-large-50 | 10 365 | 20 213 | 62 184 |
| Clip multilingual | 10 676 | 19 407 | 52 631 |
| mt5 | 13 660 | 34 704 | 105 572 |
| Granite 4.0 | 21 374 | 40 613 | 69 276 |
| Qwen3-embedding et Qwen 3 | 21 764 | 41 643 | 82 820 |
| Qwen 3.5 | 22 207 | 43 869 | 103 980 |
| SmolLM | 22 956 | 43 122 | 85 099 |
| Metaclip-2 | 25 351 | 57 687 | 168 441 |
| embeddinggemma et gemma 3 | 26 146 | 62 304 | 131 478 |
Nous pouvons voir que pour une langue donnée nous n’avons donc pas un nombre de tokens universel à conserver qui ferait l’affaire pour toutes les architectures. Mais vous pouvez constater que le 32 768 est à chaque fois compris entre 95% et 99%. À noter que pour les autres langues utilisant l’alphabet latin que nous avons évaluées dans cet article, nous constatons qu’à l’exception des gemmas, 32 768 tokens suffisent pour être situé entre 99% et 100%. Notre hypothèse étant que l’anglais étant le cas limite puisqu’est la langue la plus dotée en ressources.
2) La langue
En s’intéressant aux langues n’utilisant pas l’alphabet latin, nous pouvons constater des tailles de vocabulaires nettement plus basses. Par exemple si nous reprenons le mmBERT mais cette fois-ci en faisant un focus sur le coréen plutôt que l’anglais :
Le nombre de tokens pour couvrir 99% de la base de données est de 5859 (3 956 pour l’arabe et à peine 471 pour le tamil). Cependant la queue du dernier pourcent est très importante avec 143 161 tokens supplémentaires nécessaires pour atteindre les 100% (108 697 pour l’arabe et 113 391 pour le tamil).
3) La tâche
Au-delà du nombre de tokens dans le vocabulaire nécessaire à couvrir la base de minage, c’est la tâche en aval finale qui doit être la plus déterminante. Dans la section de 3.1.4 du papier SAM3-LiteText de ZENG et al. (2026), les auteurs observent qu’uniquement 17 300 tokens du vocabulaire de l’encodeur textuel sont en réalité pertinents, puisque les autres n’apparaissent jamais dans les jeux de données communs de segmentation d’objets. C’est cette observation qui nous a poussé à proposer également des versions des modèles en 16 384 tokens.
Cette combinaison langue / modèle / tâche en aval apparaît envisageable pour un cas d’usage précis, auquel cas nous pouvons avoir un modèle avec un vocabulaire personnalisé. Si l’on souhaite un modèle généraliste, cela semble plus compliqué car nous ne connaissons pas forcément toutes les tâches en aval.
Dans le cas de modèles n-lingues et non pas monolingues, l’interaction entre les différentes langues peut aussi être délicat. Il faut s’assurer d’avoir un équilibre entre les langues pour qu’une ne prenne pas le pas sur les autres, anticiper que des tokens seront en commun entre n langues, etc.
Enfin pour conclure ce point, une piste que nous aimerions explorer sont les tokenizers des modèles d’ASR. En effet, le Whisper de RADFORD, KIM et al. (2022) gère 99 langues pour un tokenizer de 51 866 tokens soit en moyenne 524 tokens par langue. Les auteurs de vocabtrimmer observent de leur côté (et nous avons pu le répliquer) qu’en dessous de 10 000 tokens les performances des modèles sur les tâches en aval s’écroulent.
Comment se fait-il que les modèles d’ASR fonctionnent avec si peu de tokens et pas les modèles de textes alors que le texte est simplement une forme écrite de la parole ?
Modèles incluant du code
Dans le cadre de cet article nous nous sommes focalisés exclusivement sur des modèles trimmés portant sur des langues.
Un cas d’usage fréquent des décodeurs / VLM étant la génération de code, il faudrait mener des vérifications que le trimming fonctionne bien avec les langages informatiques pour pouvoir construire des modèles langue de l’utilisateur / langage(s) informatique(s) spécifique à un utilisateur travaillant dans l’informatique dans un pays donné.
Ordre du trimming
Dans la section sur les encodeurs nous trouvons qu’il vaut mieux faire du VT (vocabulary trimming) puis du FT (finetuning) pour éviter un effondrement des performances (i.e. des modèles ne marchant plus du tout). Il s’avère que nous avons observé les mêmes résultats pour des encodeurs-décodeurs, des décodeurs et des VLM (les performances ne s’effondrant pas forcément au point que le modèle ne soit plus utilisable mais avec de grosses pertes de performances de l’ordre de 10 à 20 points en fonction de la tâche).
Le gain de performances des auteurs du MTEB-NL sur les modèles d’embeddings trimmés puis finetunés que nous avons également reproduits, semble aussi aller dans le sens d’adopter cet ordre opératoire.
Enfin, en considérant le fait qu’un modèle trimmé se finetune plus rapidement que le modèle original car plus petit, nous conseillons, et ceci n’engage que nous, de toujours trimmer un modèle puis de le finetuner.
⚠️ Vigilance
Néanmoins, nous devons signaler que les auteurs de vocabtrimmer (dans les tableaux 1 et 2 de leur papier) trouvent des résultats contradictoires en fonction de la tâche ou de la langue considérée, mais aussi du modèle (tests sur un mT5, mBART et XLM-RoBERTa).
Notons cependant que toutes ces comparaisons ne sont pas effectuées avec le même nombre de tokens par langue et par modèle.
Impact du trimming sur les biais
Dans leur papier, les auteurs de vocabtrimmer (voir la section 6 notamment) constatent qu’un modèle anglais issu d’un modèle multilingue trimmé semble présenter moins de préjugés sociaux (notamment raciaux) qu’un modèle anglais entraîné de zéro. Ce résultat va dans le sens de travaux antérieurs (AHN et OH (2021). L’intuition des auteurs est qu’un modèle entraîné avec davantage de langues est alors exposé à une plus grande diversité culturelle et ainsi que des points de vue divergents se compensent mutuellement.
À noter que cette observation n’a pas été vérifiée pour d’autres langues que l’anglais, et ne porte que sur un seul type de modèle, à savoir un encodeur (un XLM-RoBERTa trimmé vs. un RoBERTa).
Il faudrait alors tester cette hypothèse sur d’autres langues (la question de l’existence de benchmarks se pose alors) et inclure plus de modèles.
Le code pour trimmer
Nous avons présenté dans cet article de blog plus de 16 modèles différents. Nous proposons les versions monolingues de chacun d’eux via 5526 modèles disponibles ici.
Néanmoins, comment faire si de votre côté vous souhaitez construire votre propre modèle trimmé portant sur l langues de votre choix conservant t tokens de votre choix ?
Nous réfléchissons actuellement à la conception d’une librairie permettant de faire ceci facilement. Un point préalable à résoudre est la gestion de ces modèles sur Hugging Face et via la librairie transformers. En effet, actuellement nous proposons 5526 modèles différents représentant au total environ 10TB de stockage. Cette approche n’est absolument pas efficiente. Elle duplique inutilement les poids du backbone alors qu’entre le modèle original et le modèle trimmé, seules les couches d’embeddings de sortie (et éventuellement d’entrée) sont modifiées, ainsi que les fichiers de vocabulaire.
Pour limiter le stockage, il suffirait alors de charger d’un côté le backbone du modèle original et de l’autre les fichiers de config permettant d’appliquer le trimming souhaité.
Il serait aussi probablement nécessaire de revoir un peu notre code actuel afin de proposer, en plus de l’option du nombre de tokens fixés par l’utilisateur, l’option de trouver automatiquement la puissance de 64 la plus proche d’un seuil de recouvrement fixé par l’utilisateur. Comme évoqué plus haut dans cette section, le seuil de recouvrement (par exemple 95% ou 99%) étant le nombre de tokens dans le vocabulaire pour recouvrir x % des tokens de la base de minage. Cela permettrait ainsi d’avoir des tailles de vocabulaire plus spécifiques à chacune des langues.
En attendant de converger vers une solution, vous pouvez effectuer des demandes particulières ici où, à l’instar de ce qui se fait pour la quantification (avec mradermacher par exemple), nous pourrons répondre aux requêtes populaires.
Conclusion
Nous avons effectué un tour d’horizon de la méthode du trimming permettant de réduire très simplement la taille d’un modèle que ce soit en termes de nombre de paramètres ou de tailles mémoires.
Cette méthode, fonctionnant uniquement si la couche d’embedding est la dernière du réseau, a de nombreux avantages :
- Elle ne nécessite pas de réentraînement donc pas de GPU. L’ensemble des modèles trimmés que nous avons obtenus l’ont été sur CPU.
- Nous observons des performances équivalentes voire une amélioration possiblement dû à la suppression de tokens parasites.
- En cas de légère dégradation des résultats, il suffit de finetuner le modèle trimmé.
- À budget de calculs équivalents, il vaut d’ailleurs même mieux trimmer un modèle puis le finetuner afin de bénéficier de l’accélération de l’entraînement que l’on obtient du fait de la réduction du modèle.
- La méthode est compétitive face à la distillation au point que nous conseillons de préférer le trimming à cette dernière lorsque le nombre de paramètres à réduire souhaités est équivalent.
- De la même manière, le trimming peut être plus pertinent que la quantification et les deux méthodes se complètent bien.
- Un comportement intéressant que nous observons mais que nous n’arrivons pas actuellement à répliquer de manière automatique, est qu’il apparaît qu’un modèle trimmé dans une langue donnée peut générer des traces de raisonnement dans cette langue ciblée, évitant ainsi d’avoir à les générer en anglais puis à les traduire.
- Enfin, bien que nous trimmons un modèle sur une langue donnée, en fonction de la tâche en aval finale, le modèle peut toujours fonctionner dans d’autres langues.
Des questions restent ouvertes comme le nombre de tokens à garder pour une langue donnée / modalité donnée / tâche donnée, l’ordre du trimming ou encore l’impact sur les biais.
Nous travaillons à faciliter l’usage de cette méthode via un outil. En attendant, nous vous invitons à explorer les 5526 modèles disponibles via ce Space.
Références
- Language Models are Unsupervised Multitask Learners de Alec RADFORD, Jeffrey WU, Rewon CHILD, David LUAN, Dario AMODEI et Ilya SUTSKEVER (2019)
- BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding de Jacob DEVLIN, Ming-Wei CHANG, Kenton LEE et Kristina TOUTANOVA (2018)
- Load What You Need: Smaller Versions of Multilingual BERT d’Amine ABDAOUI, Camille PRADEL et Grégoire SIGEL (2020)
- How to adapt a multilingual T5 model for a single language de David DALE (2021)
- hf-trim d’Aditya SRIVASTAVA (2022)
- An Efficient Multilingual Language Model Compression through Vocabulary Trimmin de Asahi USHIO, Yi ZHOU et Jose CAMACHO-COLLADOS (2023)
- Multilingual Text Embedding Model Pruner d’Antoine LOUIS (2024)
- SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing de Taku KUDO et John RICHARDSON (2018)
- Neural Machine Translation of Rare Words with Subword Units de Rico SENNRICH, Barry HADDOW et Alexandra BIRCH (2015)
- Granite Embedding Models de Granite Team (2025)
- Multilingual E5 Text Embeddings: A Technical Report de Liang WANG, Nan YANG, Xiaolong HUANG, Linjun YANG, Rangan MAJUMDER et Furu WEI (2024)
- EmbeddingGemma: Powerful and Lightweight Text Representations de SCHECHTER VERA, DUA et al. (2025)
- M3-Embedding: Multi-Linguality, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation de Jianlv CHEN, Shitao XIAO, Peitian ZHANG, Kun LUO, Defu LIAN et Zheng LIU (2024)
- Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models de Yanzhao ZHANG, Mingxin LI, Dingkun LONG, Xin ZHANG, Huan LIN, Baosong YANG, Pengjun XIE, An YANG, Dayiheng LIU, Junyang LIN, Fei HUANG et Jingren ZHOU (2025)
- MTEB: Massive Text Embedding Benchmark de Niklas MUENNIGHOFF, Nouamane TAZI, Loïc MAGNE et Nils REIMERS (2022)
- MTEB-NL and E5-NL: Embedding Benchmark and Models for Dutch de Nikolay BANAR, Ehsan LOTFI, Jens VAN NOOTEN, Cristina ARHILIUC, Marija KLIOCAITE et Walter DAELEMANS (2025)
- mmBERT: A Modern Multilingual Encoder with Annealed Language Learning de Marc MARONE, Orion WELLER, William FLESHMAN, Eugene YANG, Dawn LAWRIE et Benjamin VAN DURME (2025)
- mmBERT-32K-YaRN: Extended Context Modern Multilingual BERT de vLLM Semantic Router Team (2026)
- frenchNER_3entities de Loïck BOURDOIS (2024)
- Smarter, Better, Faster, Longer: A Modern Bidirectional Encoder for Fast, Memory Efficient, and Long Context Finetuning and Inference de Benjamin WARNER, Antoine CHAFFIN, Benjamin CLAVIÉ, Orion WELLER, Oskar HALLSTRÖM, Said TAGHADOUINI, Alexis GALLAGHER, Raja BISWAS, Faisal LADHAK, Tom AARSEN, Nathan COOPER, Griffin ADAMS, Jeremy HOWARD et Iacopo POLI (2024)
- Building Large Monolingual Dictionaries at the Leipzig Corpora Collection: From 100 to 200 Languages de Dirk GOLDHAHN, Thomas ECKART et Uwe QUASTHOFF (2012)
- FineWeb2: One Pipeline to Scale Them All – Adapting Pre-Training Data Processing to Every Language de Guilherme PENEDO, Hynek KYDLÍČEK, Vinko SABOLČEC, Bettina MESSMER, Negar FOROUTAN, Amir Hossein KARGARAN, Colin RAFFEL, Martin JAGGI, Leandro VON WERRA et Thomas WOLF (2025)
- ModernBERT or DeBERTaV3? Examining Architecture and Data Influence on Transformer Encoder Models Performance de Wissam ANTOUN, Benoît SAGOT et Djamé SEDDAH (2025)
- DistilCamemBERT : une distillation du modèle français CamemBERT de Cyrile DELESTRE et Abibatou AMAR (2022)
- CamemBERT: a Tasty French Language Model de Louis MARTIN, Benjamin MULLER, Pedro Javier ORTIZ SUÁREZ, Yoann DUPONT, Laurent ROMARY, Éric VILLEMONTE DE LA CLERGERIE, Djamé SEDDAH, Benoît SAGOT (2019)
- DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter de Victor SANH, Lysandre DEBUT, Julien CHAUMOND et Thomas WOLF (2019)
- GLUE: A Multi-Task Benchmark and Analysis Platform for Natural Language Understanding de Alex WANG, Amanpreet SINGH, Julian MICHAEL, Felix HILL, Omer LEVY et Samuel R. BOWMAN (2018)
- mT5: A Massively Multilingual Pre-trained Text-to-Text Transformer de Linting XUE, Noah CONSTANT, Adam ROBERTS, Mihir KALE, Rami AL-RFOU, Aditya SIDDHANT, Aditya BARUA et Colin RAFFEL (2021)
- Multilingual Denoising Pre-training for Neural Machine Translation de Yinhan LIU, Jiatao GU, Naman GOYAL, Xian LI, Sergey EDUNOV, Marjan GHAZVININEJAD, Mike LEWIS et Luke ZETTLEMOYER (2020)
- Generative Language Models for Paragraph-Level Question Generation de Asahi USHIO, Fernando ALVA-MANCHEGO et Jose CALACHO-COLLADOS (2022)
- MultiUN: A Multilingual Corpus from United Nation Documents d’Andreas EISELE et Yu CHEN (2010)
- Encoder vs Decoder: Comparative Analysis of Encoder and Decoder Language Models on Multilingual NLU Tasks de Dan Saattrup NIELSEN, Kenneth ENEVOLDSEN et Peter SCHNEIDER-KAMP (2024)
- KOBEST: Korean Balanced Evaluation of Significant Tasks de Dohyeong KIM, Myeongjun JANG, Deuk Sin KWON et Eric DAVIS (2022)
- Granite 4.0 Language Models d’IBM Research (2025)
- Qwen3 Technical Report de Qwen Team (2025)
- Gemma 3 Technical Report de Gemma Team, Google DeepMind (2025)
- SmolLM3: smol, multilingual, long-context reasoner de Elie BAKOUCH, Loubna BEN ALLAL, Anton LOZHKOV, Nouamane TAZI, Lewis TUNSTALL, Carlos Miguel PATIÑO, Edward BEECHING, Aymeric ROUCHER, Aksel Joonas REEDI, Quentin GALLOUÉDEC, Kashif RASUL, Nathan HABIB, Clémentine FOURRIER, Hynek KYDLÍČEK, Guilherme PENEDO, Hugo LARCHER, Mathieu MORLON, Vaibhav SRIVASTAV, Joshua LOCHNER, Xuan-Son NGUYEN, Colin RAFFEL, Leandro VON WERRA et Thomas WOLF (2025)
- Qwen3.5: Accelerating Productivity with Native Multimodal Agents de Qwen Team (2026)
- clip-ViT-B-32-multilingual-v1 de REIMERS et GUREVYCH (2021)
- Meta CLIP 2: A Worldwide Scaling Recipe de Yung-Sung CHUANG, Yang LI, Dong WANG, Ching-Feng YEH, Kehan LYU, Ramya RAGHAVENDRA, James GLASS, Lifei HUANG, Jason WESTON, Luke ZETTLEMOYER, Xinlei CHEN, Zhuang LIU, Saining XIE, Wen-tau YIH, Shang-Wen LI et Hu XU (2025)
- Learning Transferable Visual Models From Natural Language Supervision d’Alec RADFORD, Jong Wook KIM, Chris HALLACY, Aditya RAMESH, Gabriel GOH, Sandhini AGARWAL, Girish SASTRY, Amanda ASKELL, Pamela MISHKIN, Jack CLARK, Gretchen KRUEGER et Ilya SUTSKEVER (2021)
- Microsoft COCO: Common Objects in Context de Tsung-Yi LIN, Michael MAIRE, Serge BELONGIE, Lubomir BOURDEV, Ross GIRSHICK, James HAYS, Pietro PERONA, Deva RAMANAN, C. Lawrence ZITNICK et Piotr DOLLÁR (2014)
- SAM3-LiteText: An Anatomical Study of the SAM3 Text Encoder for Efficient Vision-Language Segmentation de Chengxi ZENG, Yuxuan JIANG, Ge GAO, Shuai WANG, Duolikun DANIER, Bin ZHU, Stevan RUDINAC, David BULL et Fan ZHANG (2026)
- Robust Speech Recognition via Large-Scale Weak Supervision d’Alec RADFORD, Jong Wook KIM, Tao XU, Greg BROCKMAN, Christine MCLEAVEY, Ilya SUTSKEVER (2022)
- Mitigating Language-Dependent Ethnic Bias in BERT de Jaimeen AHN et Alice OH (2021)
Citation
@misc{hf_blogpost_trimming,
title={Introduction to Trimming},
author={Loïck BOURDOIS and Tom AARSEN and Bram VANROY and Christopher AKIKI and Woojun JUNG and Manuel ROMERO and Prithiv SAKTHI},
year={2026},
url={https://huggingface.co/blog/lbourdois/introduction-to-trimming},
}
