Gigatoken acelera la tokenización de texto hasta 989 veces frente a HuggingFace

Gigatoken es un nuevo tokenizador BPE escrito en Rust que promete reducir de forma drástica el tiempo necesario para preparar grandes volúmenes de texto destinados a modelos de lenguaje. En las pruebas publicadas por su creador, la herramienta alcanzó una velocidad de 24,53 GB por segundo sobre un servidor AMD EPYC de 144 núcleos, con una ventaja de hasta 989 veces frente a HuggingFace Tokenizers y de 681 veces frente a tiktoken. El proyecto, distribuido bajo licencia MIT y con enlaces para Python, concentra su innovación en la pretokenización y en el almacenamiento en caché, no en modificar el algoritmo central de combinación BPE.

La tokenización suele quedar fuera de los análisis de rendimiento de una infraestructura de inteligencia artificial. Sin embargo, antes de que un modelo pueda entrenar, clasificar, resumir o responder una consulta, el texto debe transformarse en una secuencia de identificadores numéricos. Cuando el volumen de información asciende a cientos de gigabytes o terabytes, esa etapa puede convertirse en un cuello de botella con costos concretos de tiempo, procesamiento y energía.

Según Fuente original, la información se basa en Meet Gigatoken: A Rust BPE Tokenizer that Encodes Text at 24.53 GB/s, up to 989x Faster than HuggingFace Tokenizers.

Gigatoken, creado por Marcel Rød, estudiante de doctorado de Stanford, propone una implementación alternativa para ese problema. El proyecto está escrito principalmente en Rust, ofrece enlaces para Python y puede instalarse desde PyPI con el paquete gigatoken. La versión mencionada en las pruebas es la 0.9.0, publicada el 21 de julio de 2026. Su licencia MIT permite estudiar, adaptar y reutilizar el código en proyectos comerciales y de investigación, siempre dentro de las condiciones de esa licencia.

La cifra más llamativa aparece en una prueba con el tokenizador de GPT-2 y el corpus owt_train.txt, de 11,9 GB. En un equipo de doble zócalo con un AMD EPYC 9565 de 144 núcleos, Gigatoken procesó el material a 24,53 GB por segundo. En la misma configuración, tiktoken registró 36 MB por segundo y HuggingFace Tokenizers llegó a 24,8 MB por segundo. La comparación representa una diferencia aproximada de 681 veces frente a tiktoken y de 989 veces frente a HuggingFace.

Gigatoken acelera tokenización texto hasta: Qué está acelerando Gigatoken antes de aplicar las reglas BPE

El byte pair encoding, conocido como BPE, divide el texto en unidades que luego pueden ser interpretadas por un modelo de lenguaje. El proceso no consiste solamente en recorrer una lista de palabras: primero es necesario identificar segmentos, separar límites y preparar las unidades que serán sometidas a las reglas del vocabulario correspondiente.

Según el registro de optimización del proyecto, el mayor salto de rendimiento no surgió de un bucle BPE más veloz. La mejora se concentró en dos tareas que muchas implementaciones consideran resueltas: la pretokenización y la reutilización de resultados previamente calculados.

Una pretokenización escrita a medida

Muchos tokenizadores delegan la pretokenización en motores de expresiones regulares. Gigatoken reemplaza esa estrategia por una implementación manual basada en operaciones SWAR, una técnica que permite procesar varios bytes dentro de una palabra de máquina y detectar transiciones con menos instrucciones individuales.

El registro del proyecto compara distintas etapas sobre 100 MB de OpenWebText. La versión optimizada de la pretokenización alcanzó una mejora de 2,27 veces frente a una línea de base basada en Winnow y NEON, y de 22,3 veces frente a la implementación con expresiones regulares. Esta diferencia resulta relevante porque la pretokenización se ejecuta antes de que el algoritmo BPE pueda aprovechar su propio vocabulario.

El enfoque también busca reducir decisiones condicionales y recorridos innecesarios. En lugar de tratar cada carácter como un caso aislado, el código intenta detectar patrones de bytes y límites de palabras en bloques. Ese diseño puede aprovechar mejor las capacidades de procesadores modernos, aunque su comportamiento depende del tipo de texto, de la arquitectura y de la distribución de caracteres del corpus.

Caché de palabras y menor interacción entre hilos

La segunda fuente de aceleración es una caché de pretokens. Si una palabra o segmento ya apareció, Gigatoken puede recuperar los tokens asociados en lugar de calcularlos desde cero. En corpus con repeticiones frecuentes, como documentos web, registros técnicos o conjuntos de datos con plantillas, esta reutilización puede evitar una cantidad importante de trabajo.

La caché no es una solución universal. El propio autor advierte que puede crecer con rapidez porque las distribuciones de pretokens suelen tener una cola larga: existen muchas unidades repetidas, pero también una gran cantidad de casos que aparecen pocas veces. El diseño debe equilibrar el costo de memoria, las búsquedas y el beneficio obtenido por cada entrada almacenada.

El proyecto también limita la interacción entre Python y Rust y procura que los hilos compartan la menor cantidad de información posible. Esa decisión reduce bloqueos y costos de coordinación en cargas paralelas. En una máquina con muchos núcleos, una parte importante del rendimiento no depende solamente de la velocidad de una función, sino de cuánto trabajo se pierde al mover datos, crear objetos o sincronizar procesos.

Resultados en servidores, computadoras personales y máquinas virtuales

La ventaja no se observó únicamente en el servidor AMD de 144 núcleos. En una Apple M4 Max de 16 núcleos, el mismo trabajo con GPT-2 alcanzó 8,79 GB por segundo. El resultado fue aproximadamente 1.268 veces superior al de HuggingFace Tokenizers y 140 veces mayor que el de tiktoken en las comparaciones indicadas.

En una computadora de consumo equipada con un AMD Ryzen 7 9800X3D, Gigatoken llegó a 6,27 GB por segundo. Allí la diferencia fue de unas 106 veces frente a HuggingFace y 68 veces frente a tiktoken. Estos datos sugieren que el comportamiento no depende exclusivamente de un servidor de alta gama, aunque no deben interpretarse como una garantía de idéntico rendimiento en cualquier equipo o corpus.

También existe una reproducción independiente realizada en KrabArena sobre una máquina virtual con cuatro vCPU Intel Xeon a 2,20 GHz. Con una muestra de 174 MB de OpenWebText, Gigatoken 0.9.0 obtuvo una mediana de 277,8 MB por segundo. tiktoken 0.13.0 alcanzó 10,62 MB por segundo y tokenizers 0.23.1 registró 3,33 MB por segundo. La prueba validó 35.356 documentos y mantuvo la tendencia de ventaja, aunque con cifras mucho menores que las del sistema de 144 núcleos.

La diferencia entre los resultados sirve para dimensionar el papel del hardware. La capacidad de paralelización, el ancho de banda de memoria, el tamaño de las cachés del procesador y la forma en que se leen los archivos influyen directamente. Por ese motivo, las cifras de Gigatoken deben tomarse como resultados de determinadas condiciones de prueba, no como una velocidad fija aplicable a todos los entornos.

Compatibilidad con modelos y costo de usar la interfaz de Python

Gigatoken publica benchmarks para 23 familias de tokenizadores. La lista incluye GPT-2, GPT-OSS, Llama 3 y Llama 4, Qwen 2 hasta Qwen 3.6, DeepSeek V3, R1 y V4, GLM 4 y 5, Kimi K2, Nemotron 3, Phi-4, OLMo 2 y 3, ModernBERT, Gemma y Mistral.

El alcance es importante porque un tokenizador no puede reemplazarse sin más por otro cuando se necesita conservar exactamente la entrada esperada por un modelo. Cambiar el vocabulario o las reglas de segmentación puede alterar la cantidad de tokens, los límites de contexto y el resultado de una aplicación. Por eso Gigatoken ofrece un modo de compatibilidad que envuelve tokenizadores existentes de HuggingFace o tiktoken y busca mantener la paridad exacta de salida.

Ese modo compatible tiene un costo de rendimiento. De acuerdo con declaraciones del autor en Hacker News, la velocidad puede situarse aproximadamente entre 200 y 300 veces, según el uso, porque todavía intervienen la creación de listas en Python y la conversión de cadenas a bytes. Los números máximos difundidos corresponden a la API nativa, en la que Rust puede leer archivos directamente y manejar el trabajo con menos capas intermedias.

Para un equipo que ya posee una canalización desarrollada en Python, la diferencia es decisiva. Una integración rápida mediante compatibilidad puede requerir pocos cambios, pero no necesariamente entregará el rendimiento anunciado en los benchmarks. En cambio, aprovechar la API nativa puede exigir revisar la forma de cargar archivos, administrar lotes, conservar documentos y transferir resultados al resto del sistema.

Por qué las cifras no son una comparación completamente equivalente

El repositorio reconoce diferencias metodológicas entre Gigatoken y las herramientas utilizadas como referencia. Gigatoken procesa archivos completos, detecta sus límites documentales y paraleliza automáticamente. HuggingFace Tokenizers fue medido con los primeros 100 MB y tiktoken con los primeros 1 GB; en ambos casos, el material había sido dividido previamente usando el marcador .

Además, las líneas de base no incorporan la misma estrategia de caché. Esto significa que Gigatoken puede beneficiarse de la repetición de segmentos que tiktoken y HuggingFace procesan nuevamente. La medición informó el mejor resultado de tres rondas intercaladas, con procesos nuevos y paralelismo habilitado. Son decisiones razonables para evaluar una implementación, pero impiden leer la diferencia como una comparación idéntica en cada etapa del flujo.

El tipo de vocabulario también modifica el resultado. Las familias basadas en SentencePiece están optimizadas de manera parcial y no alcanzan las cifras del BPE de GPT-2. En el servidor EPYC, Gemma 1 llegó a 2,51 GB por segundo, Gemma 3 a 3,43 GB por segundo y CodeLlama a 3,47 GB por segundo. Esas velocidades siguen siendo superiores a las de varias alternativas, pero el multiplicador es mucho menor que el titular de 989 veces.

Lo que revelan los intentos de optimización que no funcionaron

El registro técnico de Gigatoken también resulta útil porque documenta cambios descartados. Una separación entre rutas de código calientes y frías, acompañada por atributos de Rust como #[cold] y #[inline(never)], redujo el rendimiento hasta 580 MiB por segundo. La barrera de inserción impidió que LLVM optimizara en conjunto el recorrido que combinaba texto ASCII y Unicode, por lo que la modificación fue revertida.

Otro intento utilizó un búfer de clasificación en dos pasadas con conteo de transiciones SWAR. Aunque el algoritmo era correcto y reducía algunas ramas, el movimiento adicional de datos terminó siendo más costoso que el ahorro de decisiones. La velocidad bajó a 354 MiB por segundo. También se probó la optimización guiada por perfiles, pero no produjo un efecto medible, posiblemente porque el bucle interno ya era prácticamente libre de ramas y la decisión sobre los límites de palabras dependía de los datos.

Estos resultados muestran que acelerar software de infraestructura no consiste simplemente en agregar hilos o instrucciones vectoriales. Una técnica beneficiosa en una parte del recorrido puede perjudicar el acceso a memoria, la capacidad de optimización del compilador o la interacción entre rutas de código. Para empresas que evalúan una adopción, este historial es una señal de que el rendimiento depende de una implementación muy específica y de mediciones sobre datos reales.

Qué usos concretos puede tener un tokenizador de esta velocidad

La aplicación más directa está en la preparación de datos para entrenar o ajustar modelos de lenguaje. Equipos que procesan grandes repositorios de documentos, código fuente, conversaciones o archivos de soporte pueden reducir el tiempo previo al entrenamiento. En proyectos iterativos, donde el corpus se limpia y vuelve a procesar varias veces, una mejora en esta etapa puede acortar los ciclos de experimentación.

También puede resultar útil en evaluaciones masivas. Medir un modelo sobre millones de documentos, calcular longitudes de contexto o estimar costos de inferencia requiere tokenizar grandes cantidades de texto. En sistemas de recuperación aumentada, la indexación inicial de una base documental puede incluir millones de fragmentos que deben convertirse en tokens para calcular límites, particiones o estadísticas.

En el comercio electrónico, los catálogos y las fichas de productos se actualizan con frecuencia. Una infraestructura capaz de procesar cambios rápidamente puede facilitar controles de calidad, clasificación automática, generación de descripciones y análisis de consultas. Esto no significa que Gigatoken vaya a mejorar por sí solo la relevancia de un modelo ni el posicionamiento de una tienda: únicamente acelera una etapa técnica. La calidad del corpus, el modelo elegido y las reglas de negocio siguen siendo determinantes.

Los equipos que trabajan con inteligencia artificial y posicionamiento web también podrían evaluar el impacto en procesos de auditoría de contenido, agrupamiento semántico y análisis de grandes inventarios de páginas. En todos los casos, será necesario verificar que el tokenizador conserve la compatibilidad exigida por el modelo y que el consumo de memoria no desplace el cuello de botella hacia otra parte de la arquitectura.

Cómo puede cambiar la velocidad de tokenización el costo de proyectos de IA

Si una empresa procesa grandes volúmenes de texto de manera recurrente, la tokenización puede influir en el tiempo de entrega de datos, la ocupación de servidores y la planificación de trabajos. Una herramienta más rápida podría permitir procesar un corpus durante ventanas de mantenimiento más breves o reducir la cantidad de horas de cómputo dedicadas a tareas preparatorias.

La consecuencia para la visibilidad orgánica es indirecta pero concreta. Los equipos que combinan modelos de lenguaje con análisis de sitios pueden revisar más documentos en el mismo período, detectar duplicaciones, comparar estructuras y priorizar mejoras con mayor rapidez. No obstante, los buscadores no otorgan una posición superior porque un sitio utilice un tokenizador veloz. El beneficio aparece en la capacidad operativa para analizar información, producir diagnósticos y mantener actualizados los sistemas internos.

Antes de incorporarlo a una plataforma de producción, conviene medir cuatro aspectos: paridad exacta con el tokenizador original, memoria utilizada por la caché, rendimiento con el corpus propio y costo de transferir datos entre Rust y Python. También deben probarse textos multilingües, código, documentos con Unicode y archivos de gran tamaño. La velocidad máxima publicada puede no repetirse si los datos tienen baja repetición o si el flujo obliga a crear listas y objetos en Python.

La documentación y los benchmarks completos pueden consultarse en la publicación original de MarkTechPost. Gigatoken aparece así como una propuesta especialmente interesante para cargas intensivas, aunque su valor real deberá comprobarse con los modelos, vocabularios, arquitecturas y restricciones de cada proyecto. La mejora más importante no está solamente en alcanzar una cifra récord, sino en volver menos costosa y más previsible una etapa que durante años recibió poca atención en las pilas de lenguaje.