Puede que tu idioma cueste más tokens que el mío

En la tokenización es donde la suposición inglés-primero deja de ser filosófica. Un tokenizador aprende a cortar el texto en trozos según lo que más ha visto. Entrenado con un corpus inclinado al latín, aprende trozos largos y eficientes para palabras inglesas y cortos e ineficientes para todo lo demás. El devanagari, el tailandés, el coreano y muchos otros acaban fragmentados en muchos más tokens para la misma frase.

Tres consecuencias, ninguna abstracta

• Coste: se factura por token, así que la misma petición cuesta más en algunos idiomas.
• Contexto: en una ventana de tamaño fijo cabe menos contenido real, y los documentos largos se cortan antes.
• Latencia: más tokens que generar significa respuesta más lenta, justo en las conexiones que ya son más lentas.

Lo incómodo es que a quien lo paga le resulta invisible. Nadie ve una línea que diga que pensar en su escritura sale más caro. Solo se experimenta una herramienta algo peor, sin poder decir por qué.

Qué se puede hacer de verdad

Parte de esto está en nuestra mano y parte no. No entrenamos los modelos de frontera, así que no podemos reescribir sus tokenizadores. Lo que sí podemos es no agravar el problema: mantener los prompts cortos en el idioma del usuario en vez de inflarlos con andamiaje inglés, cachear de forma agresiva a nivel de estructura para no rederivar el mismo diseño cada vez, y hacer en código el trabajo que no necesita modelo alguno.

También lo medimos. Para cada idioma soportado seguimos los tokens por construcción y el tiempo hasta el primer render, y miramos la distancia entre el mejor y el peor idioma en vez de la media. Una media es justo la forma en que una cola larga se vuelve invisible.

Si la diferencia en tu idioma parece equivocada, cuéntanos qué escribiste. Ese aviso vale más que un benchmark, porque llega con la frase que una persona real quería escribir de verdad.