El tokenizador de BERT en Hugging Face es 50 veces más rápido tras eliminar el trabajo innecesario con ASCII

Un tokenizador convierte una cadena de texto en los números que acepta la red neuronal. En la biblioteca tokenizers de Hugging Face, esta etapa funcionaba con una lentitud injustificada para los modelos BERT. El equipo perfiló el código, encontró trabajo superfluo y lo eliminó. El tokenizador de BERT es ahora unas 50 veces más rápido que en la versión 0.23. La cifra sale de dos pasos: una aceleración de 8,6 veces, lograda al preparar el lanzamiento de la v1.0.0, y otras 5,7 veces gracias a un nuevo cambio. Ese cambio todavía está en un pull request. Al mismo tiempo, los tokenizadores BPE clásicos, en los que se apoya la mayoría de los LLM, se aceleraron hasta 30 veces.

Por qué el viejo BERT sigue importando

BERT salió en 2018, pero sus descendientes siguen presentes en todas partes: embeddings, búsqueda, RAG, rerankers, clasificadores. Los tres modelos más descargados de Hugging Face Hub usan el normalizador de BERT:

• all-MiniLM-L6-v2: 218 millones de descargas al mes; • el cross-encoder ms-marco-MiniLM-L6-v2: 79 millones; • bge-small-en-v1.5: 59 millones.

El propio bert-base-uncased ocupa el sexto lugar, con 34 millones. Entre los 10 000 modelos más populares, BPE suma 842 millones de descargas al mes y WordPiece (el algoritmo de BERT), 627 millones. Más de la mitad de las descargas de BPE corresponde a tokenizadores con normalización Unicode, casi siempre NFC, como en Qwen o ModernBERT. Estas mejoras aceleran también esa normalización.

Dónde se perdía el tiempo

La normalización lleva a una forma única las distintas representaciones de un mismo carácter. Por ejemplo, «é» puede escribirse como un único punto de código o como la letra «e» más un acento independiente. Sin normalización, el modelo recibiría tokens distintos para cada variante. BERT sin distinción de mayúsculas y minúsculas aplica cinco pasos: limpieza de caracteres de control y de espacio, espacios alrededor de los caracteres chinos, descomposición NFD, eliminación de diacríticos y conversión a minúsculas.

El flamegraph (un gráfico en el que el ancho del bloque indica la proporción de tiempo de cada función) dejó una imagen inequívoca. El normalizador consumía el 88% del tiempo, mientras que el propio WordPiece, que elige los tokens, solo el 8%. Cerca de dos tercios del tiempo total se iban en la función binary_search_by, que comprobaba si un carácter era una marca combinable. Se trata de una búsqueda binaria en un array de 1567 caracteres (6 KB), con unas 11 comparaciones y bifurcaciones impredecibles para el procesador. La búsqueda se ejecutaba para cada carácter, incluidas las letras latinas corrientes «s», «l», «o» y «w».

Tres trucos perezosos

El punto de partida fue estudiar los datos. En los textos reales abunda el ASCII, los caracteres de una misma escritura aparecen juntos y la mayor parte del texto ya está normalizada. De ahí salen tres técnicas.

• Salto del ASCII con SIMD. En UTF-8, un byte pertenece a ASCII si su bit más significativo es cero. El procesador carga 16 bytes, reúne con una sola instrucción los bits más significativos en un número y lo compara con cero.

Si es cero, el bloque entero se puede saltar sin decodificarlo, sin consultar tablas e incluso sin copiarlo. Si no lo es, el conteo de bits cero localiza el primer byte no latino. La conversión de mayúsculas ASCII a minúsculas también se hace por bloques: una operación OR con 0x20.

• Caché por bloques de puntos de código. El cirílico ocupa 256 puntos de código consecutivos (U+0400–U+04FF). Cuando el algoritmo ve por primera vez un carácter del bloque, calcula de inmediato la respuesta a «¿puede afectarle la normalización?»

para las 256 posiciones. Después basta una sola lectura de memoria. El bloque ocupa cuatro líneas de caché de 64 bytes y permanece en la caché más rápida, junto al núcleo.

• Copia perezosa. Si el texto no cambia, se devuelve la cadena original sin reservar memoria. En la primera modificación, la memoria se reserva una sola vez y los tramos intactos se copian en bloques grandes.

Qué se consiguió y dónde no ayudó

Con texto en inglés, la velocidad pasó de 23 a 151 MB/s respecto a la rama main, y el peso del normalizador bajó del 88% al 13%. Los tokens coinciden con los anteriores en todos los corpus de prueba. Cuanto más ASCII hay en el texto, mayor es la ganancia: el inglés y el código fuente fueron los que más se aceleraron. En ruso, griego y árabe el ASCII ronda el 11%, pero la caché por bloques logró una aceleración de 2,2 a 3,2 veces. En ModernBERT con NFC, el inglés apenas cambió (1,06 veces), porque allí el ASCII ya se saltaba antes, mientras que el código, el árabe y el ruso se volvieron aproximadamente el doble de rápidos.

El enfoque tiene puntos débiles:

• El texto chino no se aceleró: contiene poco ASCII y BERT, de todos modos, pone espacios alrededor de cada carácter chino. • Las cadenas de hasta 32 bytes pueden procesarse más despacio, porque la sobrecarga supera a la ganancia. En el peor caso (StripAccents con 8 bytes de chino), la velocidad cae a 0,35 de la anterior. • Para el normalizador por separado, se observó una ralentización superior al margen de error en 55 de 320 casos, 19 de ellos con entradas de hasta 32 bytes. • BERT con distinción de mayúsculas y minúsculas procesa el chino entre un 8% y un 15% más lento con entradas de 64 bytes o más.

Para los ingenieros, la conclusión es sencilla. Si procesas millones de documentos con MiniLM o bge para búsqueda y RAG, la tokenización en CPU puede ser una partida de coste apreciable, y con el lanzamiento de la v1.0.0 se abaratará mucho. Quienes tengan en su flujo muchas cadenas cortas o en chino deberían medir la velocidad con sus propios datos.