Le tokenizer BERT de Hugging Face accéléré d'un facteur 50 en évitant le travail inutile sur l'ASCII

Un tokenizer transforme une chaîne de caractères en nombres que le réseau de neurones peut ingérer. Dans la bibliothèque tokenizers de Hugging Face, cette étape était anormalement lente pour les modèles BERT. L'équipe a profilé le code, repéré le travail superflu et l'a supprimé. Le tokenizer BERT est désormais environ 50 fois plus rapide qu'en version 0.23. Ce chiffre combine deux étapes : une accélération de 8,6 fois obtenue lors de la préparation de la version v1.0.0, puis un gain supplémentaire de 5,7 fois grâce à un nouveau correctif. Ce correctif se trouve pour l'instant dans une pull request. En parallèle, les tokenizers BPE classiques, sur lesquels reposent la plupart des LLM, sont jusqu'à 30 fois plus rapides.

Pourquoi le vieux BERT reste important

BERT est sorti en 2018, mais ses descendants sont partout : embeddings, recherche, RAG, rerankers, classifieurs. Les trois modèles les plus téléchargés du Hugging Face Hub utilisent le normaliseur BERT :

• all-MiniLM-L6-v2 : 218 millions de téléchargements par mois ; • le cross-encoder ms-marco-MiniLM-L6-v2 : 79 millions ; • bge-small-en-v1.5 : 59 millions.

bert-base-uncased lui-même arrive à la sixième place, avec 34 millions. Parmi les 10 000 modèles les plus populaires, BPE totalise 842 millions de téléchargements par mois, contre 627 millions pour WordPiece (l'algorithme de BERT). Plus de la moitié des téléchargements BPE concernent des tokenizers avec normalisation Unicode, le plus souvent NFC, comme dans Qwen ou ModernBERT. Ces améliorations accélèrent aussi cette normalisation.

Où le temps se perdait

La normalisation ramène les différentes écritures d'un même caractère à une forme unique. Par exemple, « é » peut s'écrire avec un seul point de code, ou avec la lettre « e » suivie d'un accent séparé. Sans normalisation, le modèle obtiendrait des tokens différents pour ces deux écritures. BERT sans distinction de casse applique cinq étapes : nettoyage des caractères de contrôle et des espaces, ajout d'espaces autour des idéogrammes chinois, décomposition NFD, suppression des signes diacritiques et passage en minuscules.

Le flame graph (un graphique où la largeur d'un bloc indique la part de temps d'une fonction) est sans ambiguïté. Le normaliseur consommait 88% du temps, alors que WordPiece lui-même, qui choisit les tokens, n'en prenait que 8%. Environ les deux tiers du temps total partaient dans la fonction binary_search_by, qui vérifiait si un caractère était un signe combinant. Il s'agit d'une recherche dichotomique dans un tableau de 1567 caractères (6 Ko), soit environ 11 comparaisons avec des branchements imprévisibles pour le processeur. Cette recherche s'exécutait pour chaque caractère, y compris pour de simples « s », « l », « o » et « w » latins.

Trois astuces paresseuses

Le point de départ est l'étude des données. Les textes réels contiennent beaucoup d'ASCII, les caractères d'une même écriture se suivent, et l'essentiel du texte est déjà normalisé. D'où trois techniques.

• Saut de l'ASCII via SIMD. En UTF-8, un octet appartient à l'ASCII si son bit de poids fort vaut zéro. Le processeur charge 16 octets, rassemble leurs bits de poids fort en un nombre avec une seule instruction, puis compare ce nombre à zéro.

Si le résultat est nul, tout le bloc peut être ignoré : pas de décodage, pas de recherche dans les tables, pas même de copie. Sinon, le comptage des bits nuls permet de trouver le premier octet non latin. La conversion des majuscules ASCII en minuscules se fait elle aussi par bloc : une opération OU avec 0x20.

• Cache par blocs de points de code. Le cyrillique occupe 256 points de code consécutifs (U+0400–U+04FF). À la première rencontre d'un caractère du bloc, l'algorithme calcule d'emblée la réponse à la question « la normalisation peut-elle l'affecter ?

» pour les 256 positions. Ensuite, une seule lecture en mémoire suffit. Le bloc occupe quatre lignes de cache de 64 octets et reste dans le cache le plus rapide, au plus près du cœur.

• Copie paresseuse. Si le texte n'a pas changé, la chaîne d'origine est renvoyée sans allocation mémoire. À la première modification, la mémoire est allouée une seule fois, et les portions intactes sont copiées par gros morceaux.

Résultats et limites

Sur du texte anglais, la vitesse passe de 23 à 151 Mo/s par rapport à la branche main, et la part du normaliseur tombe de 88% à 13%. Les tokens sont identiques aux précédents sur tous les corpus de test. Plus un texte contient d'ASCII, plus le gain est important : l'anglais et le code source sont les plus accélérés. En russe, en grec et en arabe, l'ASCII représente environ 11%, mais le cache par blocs apporte une accélération de 2,2 à 3,2 fois. Pour ModernBERT avec NFC, l'anglais ne change presque pas (1,06 fois), car l'ASCII y était déjà sauté auparavant, tandis que le code, l'arabe et le russe sont environ deux fois plus rapides.

L'approche a ses points faibles :

• Le texte chinois n'a pas accéléré : il contient peu d'ASCII, et BERT insère de toute façon des espaces autour de chaque idéogramme. • Les chaînes jusqu'à 32 octets peuvent être traitées plus lentement, car le surcoût dépasse le gain. Dans le pire cas (StripAccents sur 8 octets de chinois), la vitesse tombe à 0,35 de la vitesse initiale. • Pour le normaliseur pris isolément, un ralentissement supérieur à la marge d'erreur apparaît dans 55 cas sur 320, dont 19 sur des entrées de 32 octets maximum. • BERT avec distinction de casse traite le chinois 8 à 15% plus lentement à partir de 64 octets en entrée.

La conclusion est simple pour les ingénieurs. Si vous faites passer des millions de documents dans MiniLM ou bge pour la recherche et le RAG, la tokenization sur CPU peut représenter un poste de coûts notable, et elle deviendra nettement moins chère après la sortie de la v1.0.0. Ceux dont le flux contient beaucoup de chaînes courtes ou chinoises devraient mesurer la vitesse sur leurs propres données.