Los modelos especializados en un dominio o una tarea mediante fine-tuning de modelos generales de código abierto, como Qwen y Gemma, heredan un vocabulario construido para muchos dominios y aplicaciones generales.
En un calificador de redacciones que operamos en producción, ese vocabulario dividía en muchos tokens el texto que el modelo escribe con más frecuencia. Este artículo adelanta algunos resultados del artículo de VocabX, que publicaremos pronto: cómo especializamos el vocabulario en función del costo de cada token en lugar de su frecuencia, y redujimos el costo de inferencia medido en un 77% sin cambiar el modelo base.
El tokenizador suele tratarse como una propiedad fija del modelo base, heredada y que no se toca. Para un modelo especializado en un solo dominio, puede ser uno de los mayores palancas de costo, y se fija antes de cualquier paso de entrenamiento.
Uno de los sistemas que operamos en producción es un calificador automatizado de redacciones en portugués, construido sobre Qwen3-4B. Recibe la redacción, la consigna y los textos de apoyo, y devuelve una evaluación en JSON con una nota y un comentario para cada competencia.
El modelo ya era pequeño, de 4 mil millones de parámetros, y ya había sido entrenado para la tarea. Su tokenizador, sin embargo, seguía siendo el original de Qwen3-4B, construido para muchos idiomas y muchos tipos de texto. En el calificador, se usaba para un solo idioma, el portugués, y un único formato de respuesta. Eso tenía dos costos: el texto que el calificador escribe en cada solicitud consumía más tokens de los necesarios, y en cada token generado el modelo puntuaba un vocabulario de 151,669 entradas, incluyendo muchas que esta tarea casi nunca usa.
Reconstruimos ese vocabulario con un método que llamamos VocabX, manteniendo el mismo modelo base, los mismos datos y la misma receta de entrenamiento. Las cifras de este artículo provienen de la versión actual del artículo, aún bajo revisión, y pueden cambiar antes de su publicación.
Un vocabulario construido para todos
Los principales modelos de lenguaje leen y escriben en tokens, y el tokenizador decide cómo el texto se convierte en tokens. Los tokenizadores de los principales modelos de propósito general se entrenan con grandes colecciones de texto de muchos dominios e idiomas, desde código fuente hasta contratos y chino. Para un modelo de propósito general, esa elección tiene sentido.
Para un modelo usado en un solo dominio, genera dos tipos de desperdicio a la vez.
El primero es la fragmentación. El tokenizador divide en muchas piezas exactamente lo que el dominio más repite. En el calificador, cada respuesta comienza con el mismo sobre JSON, los mismos nombres de competencias, las mismas frases de evaluación. En los contratos, son las cláusulas de plantilla. En el código, los identificadores. Cada una de estas secuencias cuesta varios tokens donde bastaría uno, y el modelo paga por cada uno de ellos en cada solicitud.
El segundo es el exceso. El vocabulario carga decenas de miles de entradas que el dominio nunca usa, y el modelo calcula una puntuación para todas ellas en cada token que genera. Un modelo ajustado para calificar exámenes de biología de escuelas estadounidenses casi nunca escribirá en chino, y sin embargo calcula la probabilidad de cada token en chino en cada paso. El vocabulario divide en muchas piezas lo que el dominio más repite, y carga entradas que el dominio nunca usa.
Leer es barato, escribir es caro
La reacción natural es contar los tokens e intentar reducir el conteo. Pero el conteo no es la factura.
Para entender por qué un token generado cuesta más, ayuda ver cómo funciona la inferencia. Tiene dos fases. En prefill, el modelo procesa toda la entrada en una sola pasada por la red: cada peso leído de la memoria de GPU se reutiliza para cada token de entrada, y el límite es el cómputo. En decode, el modelo genera la respuesta un token a la vez, y cada token requiere una pasada completa. Cada peso leído se usa solo unas pocas veces, y la GPU pasa la mayor parte del tiempo esperando a que lleguen los datos desde la memoria: el límite pasa a ser el ancho de banda de memoria.
Este efecto es más fuerte exactamente donde operamos: modelos pequeños servidos con lotes moderados. Agrupar solicitudes en lotes distribuye las lecturas de pesos entre ellas y alivia el problema, pero no lo resuelve. En cada paso de decode, el modelo también lee la caché KV, la memoria de atención que guarda el contexto ya procesado y crece con él. En el caso que medimos, el calificador, un token generado cuesta 7.4 veces un token leído, pero la proporción varía según el hardware, el problema, el tamaño del lote, la longitud del contexto y otros factores, y puede ser mayor que esa. En general, la dirección se mantiene: generar cuesta más que leer.
Piense en una empresa de envíos que cobra por caja, pero cobra siete veces más por las cajas salientes que por las entrantes. Reducir el número total de cajas ayuda. Reducir las cajas salientes ayuda siete veces más. Un método que comprime entrada y salida por igual pierde la mayor parte del ahorro posible.
El tercer componente de la factura es el propio vocabulario. La última capa del modelo, el LM head, convierte el estado interno en una puntuación para cada token posible. Para hacerlo, contiene una fila de parámetros por cada entrada del vocabulario. En un modelo del tamaño de Qwen3-4B, esa matriz representa casi el 10% de los parámetros. Es una proporción que los modelos grandes absorben sin darse cuenta, pero que pesa sobre un modelo pequeño.
Y el costo no se paga una sola vez. La capa de entrada consulta únicamente la fila del token que se está leyendo, pero la cabeza del LM lee y multiplica la matriz completa por cada token generado. Dado que el decode ya está limitado por la memoria, cada fila adicional es más datos que mover en cada paso. Una entrada que el dominio nunca usa cuesta exactamente lo mismo que una frecuente. Por eso añadir tokens puede bajar el conteo y a la vez subir la factura. VocabX no incluye este término en su criterio de selección, pero controla el tamaño del vocabulario en dos pasos: la fusión de subpalabras reemplaza el vocabulario base por uno más pequeño y específico del dominio, y las macros entran bajo un presupuesto fijo. En el grader, la capa de salida pasó de unas 152,000 filas a unas 65,000.
Por Qué las Soluciones Existentes Se Quedaron Cortas
Adaptar el vocabulario de un modelo no es una idea nueva. Los métodos de referencia en la literatura, como la transferencia rápida de vocabulario (FVT), la tokenización multi-palabra (MWT) y el in-place tokenizer expansion de Liquid AI (in-place BPE), que continúa el entrenamiento de BPE a partir del vocabulario original, ya reducen la fragmentación. Cuando los probamos en nuestro problema, encontramos dos limitaciones.
Eligen tokens por frecuencia, no por costo. Una expresión que aparece con frecuencia en la entrada vale más para ellos que una que aparece con menos frecuencia en la respuesta, incluso si la segunda es la más cara de servir.
Trabajan en una sola capa. O ajustan cómo se cortan las palabras en piezas, o fusionan frases completas en un solo token. Ninguno de estos tres hace ambas cosas bajo el mismo criterio. Y el mayor desperdicio del grader estaba precisamente en tramos largos y repetidos, como el sobre de JSON, al que un método de subpalabras solo llega después de fusionar cada parte, una por una.
Cómo Lo Resolvimos
VocabX aborda ambas limitaciones, más un tercer problema que aparece en el camino obvio para resolver la primera.
Primero, cambiamos la pregunta. En lugar de preguntar cuántos tokens ahorra un candidato, preguntamos cuánto costo y tiempo ahorra. Cada token eliminado se multiplica por el precio del campo en el que aparece: prompt del sistema, mensaje del usuario o respuesta del modelo. En el caso que medimos, el grader, un token ahorrado en la respuesta vale 7.4 veces uno ahorrado en la entrada, y el vocabulario se construye en consecuencia.
Segundo, trabajamos en ambas capas a la vez. Volviendo a la empresa de envíos: puedes reducir cajas empacando mejor cada artículo, o reconociendo que el mismo kit de doce artículos se envía cada semana y mandando el kit en una sola caja. VocabX hace ambas cosas. En la capa de subpalabras, reconstruye cómo se cortan en piezas las palabras del dominio. En la capa multi-palabra, busca tramos completos que se repiten, desde expresiones cortas hasta líneas completas y sobres de JSON, y convierte cada uno en un solo token, al que llamamos token macro. Ambas capas se eligen bajo el mismo criterio de costo, cada una con su propio presupuesto.
Para encontrar estos tramos, usamos cinco mineros, búsquedas automáticas de tramos que se repiten en el corpus, cada uno especializado en un tipo de repetición: palabras largas, líneas completas, expresiones, oraciones completas y estructuras con puntuación como JSON y etiquetas. Promediado sobre ocho corpus, el último fue el que más contribuyó, y en código representó por sí solo 17.5 puntos. Sin los cinco mineros, la reducción de tokens en el grader caería 55.6 puntos.
Tercero, estimamos lo que la muestra no puede ver. Elegir tokens por costo requiere saber cuánto ahorra todavía cada candidato después de los ya elegidos. Medirlo con exactitud exigiría reprocesar todo el corpus después de cada elección, decenas de miles de veces. Una forma común de hacerlo a escala es medir sobre una muestra de documentos, y entonces un candidato ausente de la muestra recibe una ganancia de cero.
Una expresión que aparece 37 veces en 50,000 documentos aparece en una muestra de 400 documentos solo alrededor del 26% de las veces. En un corpus de contratos, solo el 16.6% de los candidatos aparecen en una muestra de 400 documentos; el resto nunca se evalúa.
La ganancia de un candidato tiene dos partes. Una es cuánto ahorra sobre todo el corpus, y eso se puede contar exactamente, sin muestra. La otra es cuánto de ese ahorro aún no está cubierto por los tokens ya elegidos, y solo esa parte necesita estimarse. Para los candidatos que la muestra no puede ver, usamos una estimación estadística basada en el comportamiento de los que sí puede ver, en lugar de cero. Un candidato que es raro en la muestra pero frecuente en el corpus vuelve a la contienda.
Ese cambio, por sí solo, con la misma muestra y el mismo presupuesto, elevó la reducción de tokens en un corpus de contratos de 44.7% a 52.8%.
Qué Cambió en el Grader
Para medir el efecto real, entrenamos siete versiones del grader con el mismo modelo base, los mismos datos, la misma receta y la misma semilla. La única diferencia entre ellas es el tokenizador. Todas ejecutaron las mismas 500 solicitudes en la misma máquina de prueba, con una GPU RTX 5090 y el servidor de inferencia vLLM, y el costo se calculó a partir del tiempo de ejecución medido.
La respuesta del modelo bajó de 350 a 101 tokens en promedio. El costo cayó 77.0%. La calidad, medida por el puntaje del bench, que combina la precisión de calificación y la precisión de descartar ensayos fuera de tema o que violan reglas, subió de 0.703 a 0.810.
Llegar ahí requirió una corrección de rumbo. La primera versión del vocabulario fusionaba la calificación de cada competencia con el JSON circundante en un solo token macro. Era la opción más compacta, pero la calidad cayó: su puntuación en el banco de pruebas fue 0.689, por debajo del 0.703 del calificador de producción. Con la calificación dentro del macro, cada combinación de calificación y estructura se convertía en una variante diferente del mismo token, y el modelo elegía ambos en un solo paso. Dar a la calificación su propio token costaba 2 tokens extra por respuesta, elevó la puntuación del banco de pruebas a 0.810 y, en la medición, resultó incluso más barato: una reducción del 77.0%, frente al 73.3% de la versión fusionada.
La lección se aplica más allá del calificador. La compresión tiene un costo cuando el tramo comprimido contiene la misma decisión que el modelo existe para tomar. El objetivo no es el vocabulario más barato posible, sino el más barato que preserve los tokens que importan.
Más allá del calificador
Para averiguar si la ganancia era específica de nuestro caso, comparamos VocabX con los tres métodos de referencia en cinco dominios públicos (contratos, artículos médicos, artículos científicos, noticias y código Python) y tres familias de modelos (Qwen3, Llama-3.1 y Gemma-3). Todos los métodos usaron los mismos documentos de minería y de prueba, y el mismo techo de vocabulario.
VocabX comprimió más que el método de referencia más fuerte en las quince combinaciones, por 1.2 a 9.3 puntos. En costo de inferencia estimado, la versión podada de VocabX también lideró en las quince, con márgenes promedio de 10.2 puntos en Qwen3, 7.5 en Llama-3.1 y 13.6 en Gemma-3. En contratos, la versión podada alcanzó una reducción de tokens del 62.6% con 113,426 entradas de vocabulario, frente al 61.8% de la mejor configuración BPE in situ, que usa 207,803.
Pagar solo por los tokens que importan
VocabX no hace que el modelo sea más inteligente. Hace que el modelo deje de pagar por texto que no necesita escribir pieza por pieza, y deje de puntuar un vocabulario que nunca usará. En nuestro calificador, ese recorte redujo el costo de inferencia medido en un 77%, con el mismo modelo base y la misma receta de entrenamiento.
La especialización suele comenzar con los datos y los pesos. También puede comenzar una capa antes, en el vocabulario.
El método completo, las tablas de cada experimento y las intervenciones descartadas estarán en el artículo de VocabX, que publicaremos pronto.
Fuentes
- Dharma-AI. "VocabX: Cost-Weighted Vocabulary Adaptation for Domain-Specific Language Models." En preparación (2026).
- Gee, Leonidas, et al. "Fast vocabulary transfer for language model compression." EMNLP Industry Track (2022).
- Gee, Leonidas, et al. "Tokenización de palabras múltiples para compresión de secuencias." EMNLP Industry Track (2023).
- Smith, Jimmy T.H., et al. "In-Place Tokenizer Expansion for Pre-trained LLMs." arXiv:2607.15232 (2026).
Lecturas adicionales
- Same Cluster, 33 Points More Utilization: What Changed Was the Order
- GPU Management: Why Idle GPUs Are the New Grounded Aircraft
- Why Specialization Is Inevitable
- La especialización vence a la escala: una variable estratégica que la mayoría de las decisiones de adquisición de IA pasan por alto
- Degeneración del texto: un modo de fallo en producción que la mayoría de los benchmarks no monitorean
Explorar Dharma AI en Hugging Face para probar nuestras demos, descargar nuestros modelos abiertos y ver cómo los sistemas de IA especializados superan a los modelos de propósito general en aplicaciones empresariales reales.