Dharma-AI recortó el vocabulario de Qwen3-4B y redujo el coste de inferencia un 77%

El equipo brasileño Dharma-AI ha mostrado cuánto se puede ahorrar al tocar una pieza que suele darse por inmutable en un modelo: el tokenizador. En un sistema de producción que corrige redacciones en portugués con Qwen3-4B, el nuevo vocabulario redujo la respuesta media de 350 a 101 tokens. El coste de inferencia medido bajó un 77,0% y la puntuación en el benchmark subió de 0,703 a 0,810. El modelo base, los datos y la receta de entrenamiento no cambiaron. El método se llama VocabX. El artículo completo aún no se ha publicado, y las cifras proceden de la versión actual del preprint, que está en proceso de revisión por pares.

Dónde pagaba de más el modelo corrector

El corrector recibe la redacción, el tema y textos de apoyo, y devuelve un JSON con una nota y un comentario por cada competencia. El tokenizador seguía siendo el original de Qwen3-4B, es decir, uno diseñado para muchos idiomas y tipos de texto. Dividía en decenas de fragmentos justo lo que el modelo escribe en cada respuesta: la misma envoltura JSON, los nombres de las competencias y las fórmulas habituales de valoración. Además, en cada paso de generación el modelo calculaba probabilidades para 151 669 entradas del vocabulario, la mayoría de las cuales casi no aparecen en esta tarea.

El coste es asimétrico. En el prefill, el modelo procesa toda la entrada en una sola pasada y el límite lo ponen los cálculos. En el decode, cada token exige una pasada completa, la GPU pasa la mayor parte del tiempo esperando datos de la memoria y, además de los pesos, hay que leer el KV-cache.

En el caso medido, un token generado cuesta 7,4 veces más que uno leído. Esta proporción depende del hardware, del tamaño del lote y de la longitud del contexto, y puede ser mayor. En un modelo del tamaño de Qwen3-4B, la matriz de la LM head ocupa casi el 10% de los parámetros y se lee entera en cada token generado.

Una fila superflua del vocabulario cuesta lo mismo que una frecuente.

Tokens por coste, no por frecuencia

Los métodos existentes, como fast vocabulary transfer (FVT), multi-word tokenization (MWT) y el in-place BPE de Liquid AI, eligen candidatos por frecuencia y trabajan en un solo nivel. VocabX cambia el criterio: cada token ahorrado se multiplica por el precio del campo en el que aparece (prompt de sistema, mensaje del usuario o respuesta del modelo). En este caso, un token ahorrado en la respuesta pesa 7,4 veces más que uno ahorrado en la entrada. El trabajo se hace en dos capas a la vez: la de subpalabras y la multipalabra, en la que los fragmentos repetidos se convierten en un único macro-token. Para encontrar esos fragmentos se usan cinco minadores:

• palabras largas;
• líneas completas;
• expresiones;
• frases completas;
• estructuras con puntuación, como JSON y etiquetas.

El último minador es el que más contribuyó: en promedio en ocho corpus, y en código aportó por sí solo 17,5 puntos. Sin los cinco, la reducción de tokens en el corrector habría caído 55,6 puntos.

Otro problema está en estimar el beneficio a partir de una muestra de documentos. Una expresión que aparece 37 veces en 50 000 documentos entra en una muestra de 400 documentos solo en el 26% de los casos. En un corpus de contratos, solo el 16,6% de los candidatos entra en esa muestra, y el resto recibe un beneficio nulo. El equipo calcula con exactitud la parte de la ganancia que se puede calcular sobre todo el corpus y estima estadísticamente la parte restante. En contratos, esto elevó la reducción de tokens del 44,7% al 52,8% con la misma muestra y el mismo presupuesto.

El macro que se tragó la decisión del modelo

Para la medición se entrenaron siete versiones del corrector con la misma base, los mismos datos, la misma receta y el mismo seed. Solo cambiaba el tokenizador. Todas ejecutaron las mismas 500 solicitudes en una RTX 5090 con vLLM, y el coste se calculó a partir del tiempo medido.

La primera versión fusionó la nota de cada competencia con el JSON circundante en un único macro-token. Fue la más compacta (un 73,3% menos de coste), pero la calidad cayó a 0,689, frente a 0,703 de la versión de producción. La nota dentro del macro convertía cada combinación de nota y estructura en una variante distinta de token, y el modelo elegía todo en un solo paso.

Un token propio para la nota costó dos tokens extra por respuesta, pero subió la puntuación a 0,810 y la reducción de coste llegó al 77,0%.

La prueba con material más amplio dio este resultado: cinco dominios (contratos, artículos médicos, artículos científicos, noticias y código en Python) y tres familias de modelos (Qwen3, Llama-3.1, Gemma-3). VocabX comprimió más que la mejor referencia en las 15 combinaciones, entre 1,2 y 9,3 puntos. En la estimación del coste de inferencia, la versión recortada también ganó en todos los casos: en promedio 10,2 puntos en Qwen3, 7,5 en Llama-3.1 y 13,6 en Gemma-3. En contratos logró un 62,6% de reducción con 113 426 entradas de vocabulario, mientras que la mejor variante de in-place BPE obtuvo un 61,8% con 207 803.

Cuándo conviene tocar el tokenizador

El enfoque encaja con modelos de producción estrechos y con una estructura de respuesta repetitiva: evaluadores, extractores, generadores de JSON y asistentes jurídicos o de código. Cuanta más plantilla haya en la respuesta y más limitado esté el decode por la memoria, más notable será el efecto. La ganancia se compone de tres partes: respuesta más corta, matriz de la LM head más pequeña y menos lecturas en cada paso.

Hay también una advertencia. Si el fragmento que se comprime contiene la decisión para la que existe el modelo (aquí, la nota), no se debe esconder en un macro-token. La tarea consiste en obtener el vocabulario más barato que conserve los tokens significativos. Sin ello, se puede ahorrar coste y perder calidad.