Por qué las lenguas indias cuestan más tokens en los LLM y cómo se arreglan los tokenizadores

Di la misma frase corta en cinco idiomas y cuenta cuánto tiene que procesar un LLM. Los resultados no se parecen ni de lejos, y la dificultad del idioma tiene poco que ver.

Una frase, cinco precios

Las mediciones de una sola frase corta:

Idioma	Caracteres	Bytes	Palabras	Tokens
Inglés	18	18	4	5
Hindi	12	30	3	13
Telugu	17	45	3	20
Canarés	16	44	2	22
Tamil	30	84	3	34

El significado es idéntico. Lo que importa es la última columna. Los tokens son los pequeños trozos que un modelo lee de verdad: a veces una palabra entera, a veces un fragmento, a veces solo unos pocos caracteres. El inglés necesitó más o menos un token por palabra. El tamil, casi once.

No es porque el tamil sea más difícil de entender. La brecha viene de una decisión tomada mucho antes de que nadie escribiera un prompt: cómo se construyó el tokenizador del modelo. Y las consecuencias son reales. Las conversaciones en lenguas indias llenan antes la ventana de contexto, cuestan más y tardan más en responder, incluso cuando dicen exactamente lo mismo que alguien en inglés dice por menos.

A continuación: por qué existe la brecha, qué muestra un pequeño experimento sobre cómo reducirla y qué hace falta para arreglar el tokenizador de un modelo ya entrenado.

Qué hace un tokenizador

Antes de que un modelo procese una frase, un tokenizador la corta en tokens, las piezas básicas de construcción, un poco como bloques de Lego. Todo lo que viene después, incluida la memoria del modelo sobre el chat, el cómputo consumido y la velocidad de respuesta, se cuenta en tokens, no en palabras ni letras. La tabla de arriba es una lectura directa de lo eficientemente que se troceó cada idioma.

Nadie diseña ese troceado a mano. Se aprende de una montaña de texto mediante BPE a nivel de bytes, abreviatura de Byte Pair Encoding. La receta es sencilla: empezar con bytes en bruto, encontrar el par que aparece junto con más frecuencia en el texto de entrenamiento y fusionarlo en un token nuevo. Repetir. Los primeros pasos son así:

t h  →  th
th e →  the

Tras miles de rondas, el resultado es un vocabulario en el que cada entrada se ha ganado su sitio por frecuencia. Piezas como «the», «-ing» y «-tion» acaban siendo tokens únicos y baratos en un corpus dominado por el inglés, porque aparecen constantemente.

Por qué los bytes son una pista falsa

Las letras inglesas ocupan un byte cada una. La mayoría de las escrituras indias, como el devanagari, el telugu, el tamil y el canarés, ocupan tres bytes por carácter, porque sus conjuntos de caracteres son mucho mayores. Es tentador concluir que tres bytes equivalen a tres tokens, pero no es así. Un tokenizador a nivel de bytes puede fusionar varios bytes en un solo token, así que un carácter de tres bytes no cuesta tres automáticamente. Lo que cuesta depende de si el tokenizador aprendió una buena fusión para esa secuencia de bytes, y eso a su vez depende de cuánto texto en ese idioma vio.

La verdadera explicación, entonces, son los datos de entrenamiento, no la complejidad de la escritura. Entrena con un 90% de inglés y un 10% de todo lo demás, y los patrones ingleses tendrán miles de ocasiones para ganarse fusiones eficientes de un solo token. Los indios tendrán muchas menos y se quedarán en trozos pequeños y caros. El algoritmo no está sesgado en ningún sentido moral. La frecuencia es simplemente lo único que optimiza BPE.

Un experimento: ¿ayuda reequilibrar los datos?

Para comprobarlo, se entrenaron desde cero tres tokenizadores pequeños, cambiando entre ellos solo la mezcla de idiomas:

• Tokenizador A: 90% inglés y 10% lenguas indias, como se construyen muchos tokenizadores reales, ya que la mayor parte del texto web está en inglés
• Tokenizador B: un reparto equitativo 50/50 entre texto inglés e indio
• Tokenizador C: partes iguales de inglés, hindi, telugu, tamil y canarés

Una advertencia. El corpus era pequeño y se armó a mano para aislar una sola variable. No es escala de producción, así que la dirección y el tamaño relativo de los cambios importan más que las cifras absolutas.

Tokens por palabra en frases de prueba reservadas:

Idioma	A (90% inglés)	B (50/50)	C (equilibrado)
Inglés	3.05	3.08	3.60
Hindi	5.34	4.32	4.34
Telugu	7.79	6.36	6.36
Tamil	10.75	8.47	7.84
Canarés	8.86	7.34	7.07

Pasar de A a B, lo que da a las lenguas indias una parte más justa, redujo el coste del hindi en torno a un 19%, del telugu en torno a un 18% y del tamil en torno a un 21%, mientras el inglés apenas se movió. Durante un tramo, reequilibrar rinde muy bien.

El paso siguiente a una mezcla totalmente equilibrada dio rendimientos decrecientes para las lenguas indias y le quitó un mordisco al inglés (de 3.08 a 3.60). Así que más equilibrio no siempre es mejor. Hay un punto óptimo, no una línea recta.

¿Lo arreglaría un vocabulario más grande?

Con el mismo corpus equilibrado se varió el tamaño del vocabulario. Tokens por palabra:

Idioma	300	800	1,500	3,000
Inglés	5.28	3.70	3.70	3.70
Hindi	6.75	3.55	3.55	3.55
Telugu	9.64	6.42	6.42	6.42
Tamil	10.72	7.78	7.78	7.78
Canarés	10.17	7.17	7.17	7.17

Pasar de 300 a 800 ayudó mucho a todos los idiomas. Después no cambió nada, porque al diminuto corpus se le acabaron los patrones frecuentes que merecía la pena convertir en tokens nuevos. A escala de producción cabe esperar una curva con la misma forma por una razón emparentada: cada hueco adicional captura patrones cada vez más raros, así que las ganancias se reducen. En cualquier caso, un vocabulario más grande no es mejor automáticamente. Agranda la tabla de embeddings y la capa de salida, así que es un coste real y no una mejora gratuita.

Ninguna de las dos palancas, ni reequilibrar ni ampliar el vocabulario, es una solución limpia por sí sola. Eso lleva a la pregunta más difícil: qué hacer con un modelo ya entrenado que tiene un tokenizador malo y sesgado hacia el inglés, cuando empezar de cero no es una opción.

Por qué no basta con cambiar el tokenizador

Sustituir el tokenizador antiguo por uno multilingüe mejor es la idea obvia, y fracasa porque el tokenizador está profundamente integrado en el modelo.

El entrenamiento da a cada token su propio embedding, un vector que representa el significado de ese token, y el resto de las capas trabajan con esos vectores. Supongamos que el ID 1234 corresponde al embedding de «hello». Si un tokenizador nuevo asigna el 1234 a un saludo en hindi, el embedding en esa posición sigue significando «hello». Nada le dice al transformer que el significado ha cambiado. La salida se vuelve incoherente, porque el conocimiento aprendido del modelo sigue atado a los ID antiguos y esa conexión se ha roto en silencio.

Cómo añaden idiomas los equipos a posteriori: ampliar el vocabulario, congelar los pesos

La técnica que se usa en toda la industria es la ampliación del vocabulario, y se hace con cuidado para evitar justo esa rotura. A grandes rasgos:

1. Dejar intacto el vocabulario existente. No se reasigna ningún ID de token actual, porque la reasignación es lo que provoca el desajuste.
2. Añadir tokens nuevos para los idiomas objetivo. Un conjunto nuevo de fusiones, a menudo entrenado con un corpus multilingüe o específico del idioma, se agrega como ID nuevos a continuación de los existentes, así que no se sustituye nada. Un vocabulario de 32K puede crecer por encima de 100K.
3. Inicializar los embeddings nuevos. Los valores aleatorios funcionan, pero promediar embeddings relacionados da un arranque más cálido, porque un vector puramente aleatorio no le dice nada a un token recién creado.
4. Bloquear los pesos originales y entrenar primero solo los embeddings nuevos. Todo el enfoque descansa en este paso. Todo lo que el modelo ya sabe sobre inglés, razonamiento y código queda bloqueado. Solo pueden cambiar las filas nuevas de embeddings y, a menudo, las filas nuevas de la capa de salida. El modelo aprende qué significan los tokens nuevos sin arriesgarse al olvido catastrófico, el fallo conocido en el que el aprendizaje nuevo sobrescribe el conocimiento anterior.
5. Continuar el preentrenamiento con texto en los idiomas nuevos, manteniendo aún congelada la mayor parte del modelo, hasta que los embeddings nuevos tengan suficiente significado para que las capas congeladas puedan aprovecharlos.
6. Descongelar poco a poco. A veces primero las capas superiores, a veces todo, y el entrenamiento continúa para que toda la red se adapte al vocabulario ampliado.

Piénsalo como añadir habitaciones nuevas a una casa en lugar de derribarla y reconstruirla. El conocimiento existente queda intacto en las primeras fases mientras las habitaciones nuevas se amueblan por separado, y solo después toda la casa se reorganiza a su alrededor.

Esto también muestra por qué los cambios de vocabulario no afectan solo a la entrada. El modelo tiene que leer los tokens nuevos, tarea de los embeddings de entrada, y también producirlos en las respuestas. De eso se encarga la capa de salida, a veces llamada LM head, que puntúa cada entrada del vocabulario como posible siguiente token. El entrenamiento debe cubrir ambos extremos, y que esas dos capas compartan pesos depende de la arquitectura.

Una nota sobre precisión: las recetas de producción exactas, es decir, los calendarios de congelación, los tamaños de vocabulario elegidos y la duración de cada fase, son propietarias y específicas de cada equipo, así que no conviene atribuir ninguna a una empresa concreta sin una fuente pública. El patrón por etapas de ampliar, calentar y descongelar gradualmente es el enfoque general documentado; las cifras concretas no se publican.

Lo que esto no demuestra

La eficiencia de tokens no es lo mismo que la calidad del modelo. Un número bajo de tokens por palabra no demuestra que un modelo entienda el idioma, razone con claridad en él o traduzca bien desde él. Una tokenización barata puede convivir con un modelado débil, y una cara con una comprensión sólida. Todo esto trata de la capa económica, es decir, coste, latencia y consumo de contexto, no de la comprensión.

La cadena completa

Las distintas escrituras reciben representaciones en bytes distintas. BPE aprende fusiones según la frecuencia en los datos de entrenamiento. Los idiomas infrarrepresentados reciben menos fusiones eficientes. Por eso esos idiomas necesitan más tokens para decir lo mismo, lo que supone menos contexto útil, respuestas más lentas y facturas más altas por conversaciones idénticas.

Reequilibrar los datos y ampliar el vocabulario ayudan, pero ambos se estancan y ambos tienen costes reales. La ampliación del vocabulario con pesos congelados, hecha con cuidado para evitar el olvido catastrófico, es más compleja que cualquiera de las dos palancas por separado. Precisamente por eso los equipos recurren a ella en lugar de reentrenar desde cero un tokenizador más grande y equilibrado.

En los LLM multilingües, el tokenizador no es un paso de preprocesamiento secundario. Forma parte de la economía del idioma, y arreglarlo bien después del entrenamiento exige ingeniería de verdad, no solo mejores datos. Ten en cuenta que las cifras anteriores proceden de una configuración BPE de juguete diseñada para variar una sola cosa cada vez, y no dicen nada sobre el rendimiento de ningún tokenizador en producción.