El impuesto del idioma: por qué diferentes lenguas consumen más tokens en los modelos
Los modelos de IA fragmentan texto en tokens. El español necesita más que el inglés para lo mismo. Te explico por qué y qué impacto tiene en tus proyectos.
Colaboradores: Manu Rubio
Imagina que llamas a un taxi con contador. El destino es el mismo para todos los pasajeros, pero el precio final varía según el idioma en que les das la dirección. Los que hablan inglés pagan 6 euros. Los que hablan español, 9. Y tú, como desarrollador de la aplicación, pagas la diferencia.
Eso es exactamente lo que pasa cuando construyes algo con IA para usuarios hispanohablantes. No porque los modelos discriminen idiomas, sino por cómo dividen el texto antes de procesarlo.
Prerrequisitos
Este post no asume conocimientos previos de IA. Si sabes qué es una API (un punto de conexión para enviar peticiones a un servicio), tienes suficiente. Si no, tampoco pasa nada: lo que importa aquí es entender el concepto, no implementarlo.
Qué es un token
Antes de hablar de ineficiencias, hay que entender qué es un token, porque es el concepto central de todo lo que viene.
Un modelo de IA no lee texto como tú lo lees. No ve la palabra “casa” como una unidad. Recibe una secuencia de caracteres, la rompe en piezas llamadas tokens, procesa cada pieza por separado, y después genera la respuesta. Piénsalo como un rompecabezas: el modelo desmonta el texto en piezas, trabaja con ellas, y construye la respuesta pieza a pieza también.
Esas piezas no siguen una regla fija. Una palabra corta y común puede ser 1 token: “casa”, “gato”, “the”, “cat”. Una palabra larga o infrecuente puede partirse en 2 o más: “anticonstitucional” podría convertirse en “anti” + “constitu” + “cional”. Los espacios, los signos de puntuación y los emojis también consumen tokens.
Como regla aproximada para el inglés: 1 token equivale a unas 4 letras, más o menos tres cuartas partes de una palabra promedio. Para otros idiomas, esa proporción cambia bastante.
Por qué el inglés tiene ventaja: el sesgo del BPE
El proceso de crear tokens no es manual. Hay un algoritmo llamado Byte-Pair Encoding (BPE) que aprende a dividir texto de forma automática a partir de grandes cantidades de texto real.
Funciona así: el algoritmo escanea millones de textos y busca las secuencias de caracteres que aparecen juntas con más frecuencia. Cuando encuentra que “c-a-t” aparece millones de veces, aprende que eso es una unidad completa y le asigna un token propio. Lo mismo con “house”, “computer”, “the”. El resultado es un vocabulario de tokens predefinidos que el modelo puede usar directamente, sin fragmentar.
El problema está en los datos de entrenamiento.
La gran mayoría del texto que usaron para entrenar estos algoritmos está en inglés. Así que el BPE aprendió muy bien el inglés: memorizó casi todas sus palabras comunes como tokens completos. Cuando llega al español, al alemán o al árabe, no reconoce las palabras con la misma frecuencia y se ve obligado a romperlas en sílabas o incluso en letras individuales. No es que no pueda leer español. Es que lo lee de forma menos eficiente porque no lo estudió tan a fondo.
La misma frase, distintos tokens
Para hacer esto concreto, mira este ejemplo. La misma idea en dos idiomas:
| Frase | Tokens aproximados |
|---|---|
| ”I love walking in the rain” | ~6 |
| ”Me encanta caminar bajo la lluvia” | ~9-11 |
“Encanta” y “caminar” tienden a dividirse porque el tokenizador no los reconoce como unidades completas tan frecuentemente como sus equivalentes en inglés.
El caso extremo son los idiomas con alfabetos no latinos: japonés, árabe, coreano. El tokenizador no tiene unidades predefinidas para muchos de esos caracteres y los procesa prácticamente uno a uno. Una frase que en inglés son 6 tokens puede convertirse en 15 o más. No es un bug. Es consecuencia directa de con qué datos se entrenó el sistema.
El coste real: dinero, memoria y velocidad
Esto no es solo un dato técnico curioso. Tiene efectos concretos cuando programas con IA.
El coste económico
Las APIs de los modelos (como las de Anthropic u OpenAI) cobran según los tokens procesados. Cada mensaje que envías y cada respuesta que recibes se cuentan en tokens. Si tu aplicación atiende usuarios en español y los mensajes promedio consumen bastante más tokens que en inglés, tu factura mensual reflejará esa diferencia. Para experimentos personales, el impacto es mínimo. En producción con miles de usuarios, empieza a ser relevante desde el primer mes.
La ventana de contexto
Los modelos tienen un límite de cuántos tokens pueden “recordar” en una sola conversación. Ese límite se llama ventana de contexto (si quieres entender cómo gestionarla bien, el post de ventana de contexto y buenas prácticas cubre eso en detalle).
Imagina que el modelo puede manejar 100.000 tokens en total. En inglés, eso podría equivaler a una conversación muy larga o a un documento extenso. En español, ese mismo límite se alcanza antes porque cada página de texto consume más tokens. El modelo no pierde capacidad, pero su “memoria disponible” para tu contenido se reduce.
La velocidad
El modelo genera texto token a token. Si para decir lo mismo en español necesita producir más tokens que en inglés, la respuesta tarda proporcionalmente más en aparecer. En aplicaciones donde la experiencia de usuario depende de la velocidad de respuesta, esto se nota.
Qué puedes hacer al respecto
Depende de qué parte del texto controles.
Si controlas las instrucciones que envías al modelo (el prompt o system prompt, que es el mensaje inicial que le dice al modelo cómo debe comportarse), puedes escribirlas en inglés aunque la respuesta final sea en español. Las instrucciones en inglés consumen menos tokens, y el modelo responde perfectamente en el idioma del usuario si se lo indicas. Añadir “respond in Spanish” al final de un system prompt en inglés funciona sin problema. El post de prompt engineering para desarrolladores explora más técnicas para optimizar cómo construyes esas instrucciones.
Si el contenido que procesa el modelo lo aportan los usuarios (mensajes, documentos, preguntas en español), no tienes control sobre el idioma. El impuesto simplemente existe y hay que presupuestarlo. Lo que sí puedes hacer es reducir el volumen total: resumir documentos antes de enviarlos al modelo, eliminar repeticiones, quitar boilerplate. Eso ayuda independientemente del idioma.
Lo que no tiene solución directa hoy es el gap estructural entre idiomas. Existe, y hay que diseñar con él en mente desde el principio.
Lo que está mejorando (y lo que no)
Los modelos más recientes han ampliado sus vocabularios de tokens para incluir más idiomas. Hay mejoras reales: el español de hoy se tokeniza mejor que hace dos años. El gap con el inglés ha disminuido.
Lo que no ha cambiado es la causa de fondo: los datos de entrenamiento siguen siendo mayoritariamente en inglés. Mientras eso no cambie a escala, el inglés seguirá siendo el idioma más eficiente para trabajar con estos modelos.
Para quienes construimos aplicaciones para usuarios hispanohablantes, esto no es un problema abstracto. Es un coste que hay que medir, anticipar en el diseño, y tener en cuenta al elegir arquitectura y límites de contexto desde el principio.
Un concepto nuevo cada semana
Checklist: lo que deberías tener claro ahora
- Un token no es una palabra: puede ser una palabra, una sílaba, o un carácter
- Los modelos procesan y generan texto token a token, no carácter a carácter ni palabra a palabra
- El español genera más tokens que el inglés para transmitir el mismo contenido
- La causa es el sesgo del corpus de entrenamiento del algoritmo BPE hacia el inglés
- Más tokens = mayor coste de API, ventana de contexto que se agota antes, respuestas más lentas
- Los prompts de sistema se pueden escribir en inglés para reducir el coste de las instrucciones
- Los modelos recientes han mejorado la eficiencia multilingüe, pero el inglés sigue siendo el más eficiente
Preguntas Frecuentes
¿Por qué los modelos no aprenden a leer palabras en español completas desde el principio?
Los modelos más recientes sí lo hacen mejor. El problema es heredado: los algoritmos de tokenización se entrenaron con datos que tienen mucho más inglés que cualquier otro idioma. Reentrenarlos con corpus más equilibrados requiere recursos considerables y lleva tiempo. Se está haciendo, pero el inglés lleva una ventaja de años.
Si escribo el prompt en inglés pero quiero la respuesta en español, ¿funciona bien?
Sí. Puedes escribir las instrucciones en inglés y añadir al final “respond in Spanish” o “responde en español”. El modelo sigue la instrucción sin problema. Las instrucciones en inglés consumen menos tokens, y la respuesta en español seguirá consumiendo los tokens que correspondan a ese idioma. No elimina el impuesto de la respuesta, pero sí el de las instrucciones.
¿Cuánto me afecta esto si estoy aprendiendo?
Casi nada económicamente: cuando experimentas con volúmenes pequeños, la diferencia en tokens es céntimos. Lo que importa es entender el concepto antes de llegar a producción. Cuando escales o proceses documentos largos, este factor se vuelve real y vale la pena haberlo previsto.
¿El japonés o el árabe pagan más tokens que el español?
Sí, bastante más. Los idiomas con alfabetos no latinos tienen peor eficiencia de tokenización que los idiomas europeos. En algunos casos el mismo contenido puede necesitar el doble o más tokens que en inglés. Es el mismo problema estructural, pero amplificado por la distancia entre el alfabeto y lo que el BPE aprendió.