GigaToken: acelera la tokenización de modelos de lenguaje unas 1,000 veces

 (github.com/marcelroed)
3 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Herramienta alternativa a Tiktoken y HuggingFace Tokenizers que soporta varios CPU y tokenizadores de uso común, y procesa texto en GB/s
  • Optimiza con SIMD la pretokenización que antes hacía el motor de expresiones regulares, reduce ramificaciones, comunicación entre hilos e interacción con Python, y cachea de forma eficiente el mapeo a tokens de palabras ya vistas
  • En el benchmark OpenWebText de 11.9 GB, el throughput de GPT-2 fue de 24.53 GB/s en AMD EPYC 9565, 8.79 GB/s en Apple M4 Max y 6.27 GB/s en Ryzen 7 9800X3D
  • Los modos compatibles con HuggingFace y Tiktoken permiten mantener casi intacto el código existente, pero el rendimiento baja por el costo de hacer coincidir la salida; la API de Gigatoken, donde Rust lee archivos directamente, ofrece el máximo paralelismo y la mayor velocidad
  • Aún no soporta WordPiece ni salida a archivos, y todavía le faltan optimizaciones para SentencePiece y validación en Windows, por lo que actualmente es más adecuado para tokenizadores BPE y entornos Linux, macOS o WSL

Alcance de soporte y forma de uso

  • Gigatoken es un tokenizador de alta velocidad para modelos de lenguaje, orientado a CPU x86 y ARM modernos y a casi todos los tokenizadores comunes
  • Se instala con pip install gigatoken y ofrece una API propia y modos compatibles con HuggingFace Tokenizers y Tiktoken
  • Los modos de compatibilidad envuelven un tokenizador existente y lo convierten con .as_hf() o .as_tiktoken(), respectivamente
    • Aplica bastante trabajo para que la salida coincida exactamente con HuggingFace Tokenizers
    • El manejo de compatibilidad tiene un costo de rendimiento difícil de ignorar, así que no alcanza la aceleración de unas 1,000 veces de la API propia, pero en general sigue siendo más rápido que las implementaciones existentes
  • La API propia recibe nombres de modelos de HuggingFace como "Qwen/Qwen3-8B" y TextFileSource, y codifica archivos directamente
    • La implementación en Rust lee los datos directamente, evita overhead innecesario y maximiza el paralelismo
    • Si se pasan estructuras de datos de Python, permanece el costo de leer los datos desde Python

Implementación para aumentar la velocidad

  • La mayor mejora suele venir de haber perfeccionado directamente con SIMD la pretokenización que normalmente se delega al motor de expresiones regulares
  • Minimiza ramificaciones y optimiza intensivamente la caché de mapeo de pretokens, que busca los tokens codificados de palabras ya vistas
    • La caché crece rápido y la distribución de pretokens tiene una cola larga, por lo que es difícil de manejar
  • Obtiene rendimiento adicional al reducir la interacción con Python y la comunicación entre hilos
  • No es una implementación ajustada a un único CPU o tokenizador específico: optimiza por separado combinaciones de CPU x86 y ARM modernos con varios tokenizadores, y los resultados son consistentes entre CPU y tokenizadores

Benchmark OpenWebText de 11.9 GB

  • En un entorno AMD EPYC 9565 de 144 núcleos, el throughput de GPT-2 fue de 24.53 GB/s, 989 veces más rápido que los 24.8 MB/s de HuggingFace Tokenizers y 681 veces más rápido que los 36.0 MB/s de Tiktoken
    • Las principales familias BPE registran, en general, alrededor de 15.49 a 24.00 GB/s
    • Los elementos basados en SentencePiece son relativamente más lentos, con alrededor de 2.51 a 4.82 GB/s
  • En Apple M4 Max de 16 núcleos, GPT-2 alcanza 8.79 GB/s, 1,268 veces más que HuggingFace y 140 veces más que Tiktoken
    • OLMo 2/3 registra 1,299 veces más que HuggingFace, y Qwen 2/2.5, 1,105 veces
  • En AMD Ryzen 7 9800X3D de 16 núcleos, GPT-2 alcanza 6.27 GB/s, 106 veces más que HuggingFace y 68 veces más que Tiktoken
    • Las principales familias BPE rondan 4.21 a 6.09 GB/s, y las familias relativamente menos optimizadas rondan 1.12 a 2.84 GB/s

Condiciones de medición e interpretación

  • OWT (OpenWebText) se eligió como dato de benchmark porque representa de forma aproximada el texto obtenido tras extraer documentos de Common Crawl
  • Gigatoken procesa sin dividir previamente el archivo completo, por lo que también realiza directamente la búsqueda de límites de partición y la paralelización automática
  • Las alternativas comparadas procesan datos ya divididos con base en <|endoftext|>
    • HuggingFace encode_batch_fast usa los primeros 100 MB
    • Tiktoken encode_ordinary_batch usa el primer 1 GB
    • Ninguna de las dos implementaciones usa caché, y la velocidad del proceso se mantiene en general constante, por eso se usan estas condiciones de comparación
  • Los resultados de Tiktoken solo se incluyen para tokenizadores con soporte oficial
  • Cada fila representa un tokenizador único con el mismo vocabulario, merges y pretokenizador
    • Varias versiones y modelos derivados de las familias Llama, Qwen, DeepSeek, GLM, Nemotron, Kimi, Phi y Gemma se agrupan en la misma fila de tokenizador
  • Los elementos más lentos son los tokenizadores basados en SentencePiece, que todavía no están suficientemente optimizados en Gigatoken

Verificación de soporte y procesamiento a gran escala

  • Sin instalar, se puede validar la tokenización de un repositorio de modelo de HuggingFace y medir el tiempo con el comando uvx --with tokenizers gigatoken bench
  • En el ejemplo de validación de GPT-2, la salida coincide en 20,401 documentos
    • En Apple M4 Max, procesó 11,920.51 MB en 1.432 segundos, a 8,327.05 MB/s, 1,353.13 veces más rápido que HuggingFace
    • En AMD EPYC 9565, procesó los mismos datos en 0.486 segundos, a 24,532.45 MB/s, 989.21 veces más rápido
  • Con el throughput de EPYC, se podría tokenizar todo Common Crawl, de 130 billones de tokens, en menos de 6.5 horas
  • El ejemplo usa la muestra OWT de Stanford CS336, y la CLI usa por defecto los primeros 100 MB del archivo para la validación y la comparación con HuggingFace
  • En macOS, la primera ejecución puede hacer que el código Rust vaya más lento por la revisión de seguridad, por lo que quizá sea necesario ejecutar el comando dos veces para obtener una medición precisa
  • Piden reportar casos de salida inconsistente o lentitud en GitHub Issue

Limitaciones conocidas

  • El procesamiento iterativo de Python se realiza en Rust, pero usa ABI3, que es más lento que las API específicas por versión interna de CPython
    • Planean especialización por versión de Python, y en experimentos iniciales los casos dominados por overhead se volvieron 2 veces más rápidos
  • La API de Gigatoken todavía no implementa sink de salida a archivo
  • No soporta WordPiece
  • La tokenización basada en SentencePiece tiene un nivel de optimización menor que el BPE común
    • Su prioridad actual también es baja porque la usan principalmente modelos de Google y la familia BERT
  • Como las pruebas en Windows no son suficientes, por ahora recomiendan usar WSL

Alcance del uso de IA

  • La mayor parte del código base fue escrita directamente sin IA, y eso puede verificarse en el historial de Git del proyecto
  • En la etapa final del proyecto se usó IA para las siguientes tareas
    • Implementación de la API para usuarios
    • Generalización e implementación portable del pretokenizador para más tokenizadores, y ampliación de compatibilidad
    • Soporte de padding, truncamiento y normalización Unicode
    • Implementación portable de estrategias SIMD entre AVX512, AVX2 y NEON
    • Última mejora de rendimiento de aproximadamente 4 veces mediante eliminación de ramificaciones y mejoras en las capas de la caché de pretokens
    • Refactorización y mejora de la reutilización de código

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios en Hacker News

  • Que diga “la mayor parte del código fue escrita directamente sin IA, y se puede comprobar en el historial de Git” le quita fuerza a la idea de que la programación humana se acabó

  • No optimizaron en exceso un solo CPU y un solo tokenizador, sino todo el conjunto de x86·ARM modernos y varias combinaciones de tokenizadores para obtener un rendimiento consistente
    Normalmente la pretokenización se deja al motor de expresiones regulares, pero aquí la optimizaron directamente con SIMD y minimizaron las bifurcaciones; además mejoraron el caché de mapeo de pretokens para encontrar rápido el resultado de codificación de palabras ya vistas. En este campo los cachés crecen rápido y la cola de la distribución es larga, así que son difíciles de manejar
    También minimizaron la interacción con Python y la comunicación entre hilos

  • Me recuerda a simdjson, que logra velocidades difíciles de creer con programación creativa. Si se usa ampliamente, podría reducir mucho el consumo eléctrico, los costos y las emisiones de carbono; estaría bien que también publiquen un crate de Rust, e incluso me gustaría ayudar si hace falta

    • Casi nunca la tokenización ha sido un cuello de botella significativo, y con la serialización JSON normalmente pasa lo mismo. Se gasta mucha más energía en entrada/salida y almacenamiento que en serialización y tokenización
      Si se piensa en economía y medio ambiente, agrupar solicitudes en lotes tiene mucho más impacto. El problema más caro es la baja utilización de GPU, y si adaptas el trabajo al procesamiento por lotes hoy mismo puedes ahorrar 50% incluso en OAI. Si no todas las respuestas tienen que ser inmediatas, algunas pueden esperar días; las llamadas a herramientas no expiran por tiempo y el propio LLM no tiene tiempo de reloj de pared

  • Cloné el repositorio para revisarlo, y reemplazar la regex de pretokenización junto con la optimización del caché son enfoques útiles en general. Es un trabajo tan bueno que toda la comunidad de tokenización va a querer aprender el secreto de esta mejora de velocidad

    • Pronto planean hacer una explicación técnica y un paper del proyecto, además de un video de presentación para compartirlo también en Discord
    • Tiene mucho valor no solo para inferencia, sino también para entrenamiento con datasets propietarios, y además impresiona que todo esto lo haya hecho una sola persona

  • Es un gran logro, pero normalmente la tokenización representa menos del 0.1% del tiempo total de inferencia. Aun así, será muy útil para aplicaciones donde la tokenización en sí es necesaria

    • Según la forma de inferencia, la proporción de tokenización puede volverse bastante relevante. En mediciones iniciales ejecutando 8B Qwen3 en una sola B200, al cambiar a gigatoken el tiempo hasta el primer token (TTFT) bajó en promedio 5.5% con longitud de entrada 2,048, 8.4% con 8,192 y 7.8% con 32,768
      El efecto es mayor cuanto más pequeño es el modelo o más rápida la GPU, aunque hace falta validación adicional antes de ponerlo en el README. El benchmark viene de fastokens
    • En plataformas de IA, hay que tokenizar rápido al inicio de la solicitud para decidir después cosas como enrutamiento y limitación de velocidad. Aunque represente poco del tiempo total de la solicitud, la eficiencia importa
    • La tokenización casi siempre se procesa en serie, así que si el prompt inicial es grande puede ocupar una parte importante del tiempo de procesamiento de entrada. Después de pasarlo a la inferencia del modelo, todos los tokens pueden procesarse en paralelo
    • Incluso 1/1,000 del cómputo de inferencia es difícil de ignorar a gran escala. Gartner estimó el gasto en inferencia para 2026 en unos 28 mil millones de dólares, así que aplicando esa suposición serían 28 millones de dólares al año
      Fuente: https://www.gartner.com/en/newsroom/press-releases/2026-07-2...
    • Sobre todo en modelos pequeños, puede reducir bastante la latencia hasta el primer token. Para proveedores de inferencia como Groq o Cerebras, la latencia importa tanto como el throughput total

  • Parece más útil para la preparación offline de datos de preentrenamiento que para el momento de la inferencia. Al tokenizar varios terabytes de texto para un corpus de entrenamiento, puede ahorrar tiempo y costo, y también acortar el ciclo iterativo de ajuste del dataset

  • Dedicar capacidad de ingeniería a hacer 1,000 veces más rápida una parte que ocupa 0.1% del tiempo total de ejecución es exactamente el comportamiento más típico de un desarrollador de software

    • Hice una nube de palabras de alta resolución en Rust en unos 100ms, y con optimización adicional la bajé hasta unos 16ms. El mundo no necesita un generador de nubes de palabras tan rápido, pero si lo vas a hacer, debería ser lo más rápido posible
    • “La búsqueda de la excelencia no necesita justificación”
      https://x.com/mitchellh/status/2074225453217505494
    • Depende del flujo de trabajo. También existen usos donde no metes el texto directamente al modelo y solo tokenizas
    • Incluso si es un subcomponente, una mejora de 1,000 veces permite funciones cualitativamente nuevas. Y que esa parte solo sea 0.1% del total muchas veces también es resultado de repetir en todo el proyecto la actitud de “si no afecta el rendimiento total, ¿para qué hacerlo bien?”
      Los LLM están mucho más cerca de su límite de mejora de 1,000 veces, pero incluso las operaciones base de PyTorch a menudo son 2 veces más lentas que una simple reescritura, y mejores algoritmos de scheduling a veces logran mejoras de 5 a 10 veces. Una tokenización rápida también podría abrir otras funciones que hasta ahora se ignoraban por ser inviables
    • Si tokenizas para ejecutar un modelo de lenguaje pequeño (SLM) ultraligero para enrutamiento, la proporción puede ser mucho mayor que 0.1%. Es la misma forma de pensar que decir “como una PC casi siempre está quieta en el escritorio, optimizar el driver de GPU no importa”

  • El rendimiento es tan difícil de creer que uno se queda mirando un buen rato los números de la gráfica para entenderlos

  • Es exactamente la función que ClickHouse necesita, así que planean probarla en https://github.com/ClickHouse/ClickHouse/issues/108247
    Estaría bien que el README destacara más el rendimiento por núcleo, y da curiosidad si el emparejamiento con tablas hash perfectas ayudaría en el algoritmo real

  • Entonces da curiosidad cuántas oportunidades de optimización de 1,000 veces seguirán quedando en otras partes del pipeline de inferencia

    • A diferencia de la capa de tokenización, en otros cambios de inferencia no es fácil decidir simplemente si son correctos o no
    • Hay muchas, y casi todos los componentes ya tienen equipos dedicados e investigación encima. Es muy probable que sigan apareciendo múltiples avances importantes
    • En las partes que ocupan una proporción mayor del tiempo de inferencia probablemente ya se ha invertido mucho más esfuerzo de optimización