TokenDagger – Un tokenizador más rápido que Tiktoken de OpenAI

• Un tokenizador de alto rendimiento 100% compatible con TikToken de OpenAI que ofrece más del doble de rendimiento y una tokenización de código 4 veces más rápida en el procesamiento de texto a gran escala
• Motor de parsing de expresiones regulares de alta velocidad basado en PCRE2 para maximizar la velocidad de coincidencia de patrones de tokens
• Algoritmo BPE simplificado para minimizar la degradación del rendimiento al manejar grandes volúmenes de tokens especiales
• En benchmarks reales, la tokenización de código es más de 4 veces más rápida, y puede usarse como reemplazo directo del código existente que utiliza TikToken
• Compatible con Python 3.8+, se puede instalar fácilmente desde PyPI con pip install tokendagger y tiene una dependencia de PCRE2

[GN⁺]

Comentarios de Hacker News

• Creo que a corto plazo todavía hay mucho margen de optimización de rendimiento en la infraestructura de AI/ML resolviendo cuellos de botella clave con C++, sin necesidad de reescribir todo en C++; estos trade-offs de ingeniería inteligentes muchas veces sí se traducen en mejoras reales de rendimiento, y me da la impresión de que los ingenieros chinos son particularmente buenos en este tipo de trabajo
  • Hay una perspectiva sobre desarrollo de software que me enseñó mi mentor: fase 1, que funcione; fase 2, que sea rápido; fase 3, que se vea bonito. Los transformers y los LLM ya llegaron a una etapa en la que funcionan bastante bien, así que siento que ahora estamos en el momento en que los mayores avances vienen por el lado del rendimiento
  • A largo plazo, creo que tendría sentido alejarse de un enfoque centrado en Python; si solo se usa porque los ingenieros de ML están acostumbrados, no parece muy orientado al futuro
  • En realidad, TikToken está escrito en Rust, así que me da curiosidad si esta mejora de verdad se debe a la migración a C++
  • En realidad, el tokenizing no es el mayor cuello de botella y la mayor parte del cómputo ocurre en la ejecución real de kernels de CUDA; el overhead de Python es muy pequeño (VLLM también está escrito principalmente en Python), y reescribirlo en C++ casi siempre significa reescribir los kernels de CUDA de forma más eficiente
• Me parece bastante hermoso crear un reemplazo drop-in para un sistema existente que mejore mucho el rendimiento; me hace pensar en ScyllaDB
  • De hecho, creo que si no fuera un sustituto de este tipo, nadie lo usaría
• Me pregunto qué tan importante es el tokenizer en el rendimiento general de un LLM; me interesa la optimización de tokenizers, pero todavía no la he medido en la práctica. Yo asumía que la mayor parte del costo venía de matmul, pero por las respuestas en los comentarios parece que el tokenizer sí importa
  • El tokenizing normalmente se procesa en CPU y rara vez se vuelve el cuello de botella en entrenamiento o inferencia; la mayor parte del tiempo se va en kernels de GPU, y solo los modelos muy pequeños son la excepción. La latencia del tokenizer también puede “ocultarse” mientras la CPU prepara el siguiente batch
  • El rendimiento del tokenizing es algo complejo, pero las organizaciones con verdadera capacidad y recursos suelen escribir sus propios tokenizers ultrarrápidos. SentencePiece y tiktoken son ejemplos representativos de herramientas elegidas aun aceptando la complejidad y la carga de despliegue. Los expertos reales revisan los cuellos de botella con flame graphs, y en entrenamientos a gran escala incluso se tokeniza por adelantado. También se siente cierta tensión en la industria por el resurgimiento de C++, en contraste con la narrativa de Rust; ojalá haya una razón o insight nuevo detrás de esto
  • Igual que en otros comentarios, en la práctica el tokenizer no es el cuello de botella; simplemente se trabajó primero en él porque es la primera etapa del pipeline de inferencia
  • El tokenizing de texto representa una fracción realmente mínima del cómputo total; aun así, al procesar datos a escala de petabytes, cualquier mejora de velocidad, por pequeña que sea, siempre ayuda
• Para alinearse con tiktoken hace falta convertir el formato del vocab, pero si ese requisito también desaparece, sería un reemplazo drop-in totalmente compatible aún mejor de usar; también sería bueno tener un ejemplo bidireccional que inicialice tiktoken y luego tokendagger para verificar que dan el mismo resultado
  • Desde la versión 0.1.1 ya se volvió un verdadero reemplazo drop-in, y planean agregar ejemplos pronto
  • Señalaste muy bien el punto, así que lo actualizaron de inmediato
• También me da curiosidad cómo se compara este proyecto con el crate BPE; la fortaleza de ese crate es la capacidad de retokenizar texto de manera incremental y es más rápido que tiktoken
  • La próxima vez planean agregar retokenización incremental y también hacer benchmarks contra ese crate
• Me pregunto cómo conseguir tokenizers locales para otros LLM; por ejemplo, Gemini solo expone una API remota. Me pregunto si eso es propietario o si habría alguna forma de inferir el mapeo de tokens haciendo llamadas masivas a la API
  • Gemini usa SentencePiece y comparte el mismo vocabulary de tokenizer que Gemma (referencia 1, referencia 2, referencia 3); entre los grandes labs, solo Anthropic, con Claude 3 o superior, no tiene tokenizer local
  • Los tokenizers por modelo en su mayoría comparten algoritmos base como SentencePiece o Byte-pair encoding (BPE), y solo difieren a nivel de wrapper en cosas como el manejo de tokens especiales. tiktoken y TokenDagger también son implementaciones de BPE. Si a nivel de librería se reflejan las particularidades de cada modelo, se puede obtener una pequeña mejora de rendimiento y una integración más sencilla. No es un trabajo grande, así que tampoco resulta pesado adaptarlo a modelos nuevos. Ejemplos de referencia: tokenizer.py de llama, tokenizer de Mistral
  • Yo también entendía que Gemini usa SentencePiece
• Antes intenté algo parecido: tokie. En la práctica, la mayor parte del costo de ejecución del tokenizer viene del pretokenizing (regex). Parece que encontraron una forma más rápida de hacer regex, pero me pregunto si también compararon el cambio de rendimiento dejando el BPE igual que en tiktoken y cambiando únicamente el motor de regex. Si es así, quizá incluso podría contribuirse upstream
  • Excelente proyecto; ya contactaron a la persona que mantiene tiktoken
• También estaría bien una comparación de rendimiento con Huggingface tokenizers; según el readme de tiktoken, el benchmark ya está demasiado desactualizado
  • Personalmente, tiktoken siempre me ha parecido más lento que huggingface tokenizers. Todavía no he investigado tiktoken a fondo para saber por qué, pero como usuario del tokenizer en Rust de HF, esa ha sido mi impresión
• También me gustaría ver bindings WASM de tiktoken, o saber si la mejora de rendimiento proveniente de "b" podría aplicarse también a una implementación pura en js
• Es un proyecto realmente genial; nosotros también usamos tiktoken, y si ofrece mejoras de rendimiento manteniendo compatibilidad drop-in, me interesa ver qué tanto impacto tendría. La elección de hacerlo drop-in es excelente