¿Qué LLM es más barato para tu idioma? Costes medidos por tokenizer

No existe un único LLM que sea el más barato para texto multilingüe. Al medir el mismo pasaje, GPT-5.5 factura menos tokens en idiomas europeos, hindi y coreano; Kimi K2.5 es el más eficiente en chino y DeepSeek, en japonés. Claude Fable 5, Opus 4.8 y Sonnet 5 comparten tokenizer, devolvieron recuentos idénticos en todas las muestras, y nunca son los más eficientes: el mismo párrafo en inglés suma 90 tokens brutos en Claude frente a 55 en DeepSeek, y el sobrecoste neto va desde 1.3x en japonés hasta 2.2x en chino. La unidad de facturación es el token, así que el coste de entrada depende de dos factores que rara vez aparecen en las páginas de precios: cuánta información concentra un idioma en cada carácter y hasta qué punto el tokenizer de cada modelo comprime ese sistema de escritura. Ambos factores se multiplican, y el resultado no es el que sugiere una comparación por carácter.

TL;DR

• Claude Fable 5, Opus 4.8 y Sonnet 5 comparten tokenizer y nunca son los más eficientes: en todos los casos generan entre 1.2 y 2.3 veces el recuento mínimo.
• El tokenizer más barato cambia según el idioma: GPT-5.5 en idiomas europeos, hindi y coreano; Kimi en chino; DeepSeek en japonés.
• Por carácter, CJK parece costar 3x más. Por significado, el chino queda cerca de la paridad, mientras que japonés y coreano cuestan entre 1.5 y 2.4 veces más.
• El coste es el producto de la densidad del sistema de escritura y la cobertura del tokenizer. Una cobertura deficiente amplifica el coste: GLM factura 4.9x más tokens en hindi que en inglés.
• Localizar rara vez ahorra dinero; hay que elegir el modelo según los tokens que consume en cada idioma.

Los recuentos se midieron mediante el gateway de Synthorai el 2026-07-08. Siempre usamos el recuento del propio proveedor, nunca un tokenizer local. Todas las repeticiones devolvieron exactamente los mismos valores.

La unidad de facturación es el token, no el texto

La factura se calcula por token, pero un token no equivale ni a un carácter ni a una palabra. Cada modelo incluye su propio tokenizer y su propio vocabulario, por lo que una misma frase se convierte en un número distinto de tokens según el modelo. Ese recuento se multiplica después por el precio por token. Por tanto, cambian dos variables a la vez: cuántos tokens genera el texto y cuánto cuesta cada uno.

La mayoría de las páginas de precios solo muestran la segunda cifra. Este artículo mide la primera. Enviamos tres pasajes con el mismo significado a siete modelos (claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5) y registramos los tokens de entrada que facturó cada uno.

El conjunto incluye un texto narrativo informal, una historia sobre un mercado de sábado, en nueve idiomas. También contiene una explicación técnica, reintentos con backoff exponencial, y una noticia breve, una votación sobre el presupuesto municipal, en inglés, chino, japonés, coreano, alemán e hindi. Completamos las muestras con una función de Python y un bloque JSON de llamada a una herramienta. Las versiones en otros idiomas son traducciones automáticas generadas con instrucciones de fidelidad y sin condensar el contenido, y después revisadas manualmente. La verbosidad de una traducción introduce una distorsión real; la sección sobre el registro la acota en torno al 20%.

El recuento siempre procede del proveedor. Para Claude usamos una llamada real a Messages y leemos usage.input_tokens, ya que el gateway todavía no actúa como proxy de count_tokens. En los modelos compatibles con OpenAI hacemos una llamada pequeña y leemos usage.prompt_tokens. Así evitamos precisamente el problema de usar un tokenizer local cuyo resultado no coincide con la factura. Hay además una variable de control: cada solicitud incluye unos pocos tokens de estructura fija, plantilla de chat y marcadores de rol. Para descontarlos, medimos una muestra base de dos caracteres y restamos su coste. Todos los ratios de este artículo excluyen esa envoltura y comparan únicamente el texto.

El mismo texto, cinco tokenizers

Esta tabla muestra el recuento bruto de tokens de entrada del pasaje narrativo por idioma y tokenizer. Los tres modelos Claude comparten columna porque devolvieron valores idénticos en todas las muestras; lo explicamos más adelante. Los otros dos pasajes reproducen el mismo patrón y se incorporan al análisis posterior. La columna de caracteres indica la longitud de cada versión. Los sistemas de escritura no concentran la información de la misma manera: el chino expresa en 77 caracteres lo que el inglés necesita 254 para decir.

Hay dos datos claros. La columna de Claude tiene un único valor para tres modelos porque Claude Fable 5, Opus 4.8 y Sonnet 5 devolvieron recuentos idénticos en todas las muestras, tanto en idiomas naturales como en código y JSON. Los tres usan el tokenizer introducido con Opus 4.7, de modo que medir uno equivale a medirlos todos. Esa columna registra además el valor más alto en todas las filas salvo en hindi, donde los 192 tokens de GLM son aún peores. Si normalizamos los recuentos netos para que el modelo más eficiente de cada idioma sea 1.00, restando antes la envoltura, por lo que estos ratios no coinciden con una división directa de las celdas anteriores, el resultado es:

El empate a cuatro de la fila inglesa no se debe al redondeo: DeepSeek, GLM, GPT-5.5 y Kimi generan exactamente 50 tokens netos para ese pasaje. En esta muestra, Claude consume entre 1.3x y 2.2x los tokens del tokenizer más eficiente; en el conjunto de los tres pasajes, entre 1.2x y 2.3x. Es una propiedad del vocabulario y afecta a todas las llamadas durante toda la vida del modelo. Los textos técnico y periodístico mantienen la misma clasificación. Sumando ambos, Claude factura 212 tokens netos en chino frente a 114 de Kimi (1.9x), y 477 en hindi frente a 210 de GPT-5.5 (2.3x). Sin embargo, ningún modelo gana en todos los casos. La columna más eficiente cambia con el idioma:

• GPT-5.5 es el más eficiente en alemán, francés, español, italiano, hindi y coreano, y empata en inglés. El empate y los resultados de fr/es/it solo se mantienen en el pasaje narrativo. Su vocabulario está optimizado para alfabetos latinos y mantiene buenos resultados con devanagari y hangul.
• Kimi K2.5 es el más eficiente en chino y competitivo en todo CJK.
• DeepSeek-v4 es el más eficiente en japonés y queda cerca del mejor en chino.
• GLM 5.2 se sitúa en la zona media en la mayoría de los idiomas, pero obtiene los peores resultados de toda la matriz en hindi: 2.59x el mínimo en el texto narrativo, 179 tokens netos frente a los 69 de GPT-5.5, aún peor en los pasajes formales, y es la única columna que supera incluso a Claude.

La penalización no se limita a la prosa. En la función de Python, Claude consume 1.61x los tokens del modelo más eficiente; en la llamada a herramienta en JSON, 1.29x. La diferencia se reduce en JSON porque el texto estructurado se compone sobre todo de signos de puntuación y claves ASCII cortas, que todos los tokenizers manejan de forma parecida. En un agente de larga duración que reenvía un esquema de herramientas grande en cada turno, ese sobrecoste se acumula. Ahí es donde el cache aporta valor. La serie sobre prompt caching explica cómo funciona.

La trampa del coste por carácter: CJK parece más caro de lo que se factura

Las tablas anteriores comparaban modelos. Si fijamos el modelo, el idioma sigue alterando el recuento, pero no como sugiere una comparación directa por caracteres. La métrica de tokenizer que más se cita es el número de tokens por carácter, y CJK domina esa tabla: en Claude, el chino genera unos 114 tokens netos por cada 100 caracteres, el coreano 106 y el japonés 94, frente a 32 del inglés. Si solo miramos esa columna, CJK parece imponer un sobrecoste de 3x. Pero esa no es la métrica correcta: se paga por transmitir significado, no por escribir caracteres, y el pasaje contiene el mismo significado en todos los idiomas. Estas son ambas perspectivas para el texto narrativo en Claude:

Las dos columnas de la derecha cuentan historias distintas. El chino es el caso más extremo: tiene la mayor densidad de tokens por carácter del conjunto, pero solo cuesta 1.07x más que el inglés para expresar el mismo significado en este pasaje. Sus 77 caracteres transmiten lo mismo que 254 caracteres ingleses, por lo que el elevado coste por carácter se multiplica por un número de caracteres muy pequeño y casi se compensa. El efecto se mantiene en los tres pasajes, aunque no elimina por completo la diferencia: el chino promedia 1.17x el coste del inglés en Claude y entre 0.95x y 1.32x según el modelo. Está cerca de la paridad, no del 3x que parece indicar la métrica por carácter.

El japonés y el coreano muestran el siguiente matiz: sufren la misma distorsión visual, pero la compensación es menor. Ambos tienen una alta densidad de tokens por carácter porque el hangul coreano y los kana japoneses representan sonidos, aproximadamente un glifo por sílaba, en lugar de concentrar una palabra completa en cada carácter como los hanzi chinos. Por eso el coreano necesita 143 caracteres y el japonés 136 para expresar lo que el chino dice en 77. Al multiplicar más caracteres por una tasa alta de tokens por carácter, el efecto no se compensa, sino que se acumula. En Claude, el coreano promedia 1.96x el inglés por significado en los tres pasajes, y el japonés 1.56x. Ambos son realmente caros, aunque su columna de tokens por carácter se parezca a la del chino.

El alemán es el reflejo opuesto del chino: tiene una tasa baja por carácter, 48, cercana a la inglesa, pero es el idioma con más caracteres del conjunto, 289, por sus palabras compuestas, por lo que el total sigue siendo 1.68x. El coste es el producto de dos ejes; mirar solo uno lleva a conclusiones erróneas.

Por qué cambian las cifras: dos factores que se multiplican

Todas las tablas anteriores responden a una misma ecuación:

tokens de un pasaje = (caracteres necesarios para expresar el significado) x (tokens por carácter)

El primer factor es la densidad del sistema de escritura, una propiedad del idioma, no del modelo. Es un continuo, no una excepción exclusiva del chino. El chino logográfico concentra un morfema en cada carácter y ocupa el extremo de mayor densidad. Los kana japoneses y el hangul coreano representan sonidos, por lo que son menos densos y requieren más caracteres. El devanagari y los alfabetos latinos son todavía menos densos. La cantidad de significado por carácter disminuye de forma progresiva desde el chino hasta el inglés.

El segundo factor indica cuántos tokens del vocabulario consume el modelo por cada carácter de ese sistema de escritura, y depende por completo del modelo. Un tokenizer BPE aprende combinaciones de varios caracteres a partir de su corpus de entrenamiento. Los sistemas de escritura que aparecen con frecuencia obtienen tokens compactos; los menos representados tienden a codificarse carácter por carácter o incluso byte a byte, de forma que un solo carácter puede convertirse en dos o tres tokens. Estos son los tokens netos por carácter para los mismos tres idiomas:

La tabla explica tres resultados. El chino destaca en los totales porque se encuentra en el extremo del primer factor. Ni siquiera la baja eficiencia de Claude en chino, 1.14 tokens por carácter, que todavía divide algunos hanzi en dos, produce un total grande cuando solo hay 77 caracteres. Los modelos entrenados en China lo comprimen lo bastante bien, entre 0.52 y 0.58, para acercarse a su propio coste en inglés. El sobrecoste del hindi procede del segundo factor, no de la densidad: GLM consume 0.91 tokens por carácter devanagari, casi uno por carácter, porque su vocabulario apenas contiene combinaciones de varios caracteres en ese sistema de escritura. GPT-5.5 consume 0.35 al cubrir grupos silábicos completos. Es una diferencia de cobertura sobre el mismo sistema de escritura. Claude, por su parte, registra valores altos en todos los idiomas porque su tasa por carácter ya es elevada en inglés, 0.32 frente a 0.20 de DeepSeek. Ese coste base del modelo se suma al efecto propio de cada idioma.

Este fenómeno no es exclusivo de nuestros siete modelos. La literatura académica lo denomina token premium. Petrov et al. (NeurIPS 2023) lo midieron en cientos de pares de idiomas y encontraron las mismas dos causas principales: la cantidad de caracteres necesaria para expresar un significado cambia entre idiomas, y la cobertura del tokenizer varía según el sistema de escritura. Detectaron sobrecostes de hasta 15x en idiomas con pocos recursos, con las mismas consecuencias: mayor coste, más latencia y menos context window útil, porque un idioma con una penalización alta llena el mismo presupuesto de contexto con menos significado. La diferencia también se reduce a medida que los proveedores invierten. Mediciones independientes sitúan el chino en un +182% de tokens frente al inglés con vocabularios de la época de GPT-3 y en un +24% con el de GPT-4o. Esto se aproxima al +32% que medimos en GPT-5.5 y a la paridad de los modelos entrenados en China. La cobertura requiere espacio en el vocabulario, y los proveedores siguen ampliándola.

¿Localizar permite ahorrar dinero?

La sección anterior podría llevar a dos conclusiones equivocadas: «Claude apenas varía entre idiomas, así que la localización da igual» y «los modelos chinos son baratos en chino, así que localizar reduce costes». Ninguna es cierta. Esta tabla compara cada idioma con el inglés del mismo modelo, promediando los tres pasajes para los cinco idiomas presentes en todos ellos:

Claude no mantiene un coste constante: el coreano cuesta 1.96x su inglés y el hindi, 2.40x. Que el chino se quede cerca de 1.17x es una coincidencia limitada a ese idioma, no una propiedad general del modelo. Los modelos chinos tampoco reducen claramente el coste del chino por debajo del inglés; más bien alcanzan la paridad. El mejor valor de toda la tabla es el 0.95x de Kimi, un cinco por ciento menos que su propio inglés. Todas las demás celdas cuestan igual o más. En hindi, japonés y coreano, esos mismos modelos tienen una penalización superior a la de Claude, no inferior, porque esos sistemas de escritura quedan más lejos del foco de sus datos de entrenamiento. El patrón no es «el proveedor X es barato». Cada modelo es más eficiente, respecto a su propio inglés, en los idiomas más cercanos a sus datos de entrenamiento.

El registro también modifica las cifras. El texto narrativo informal es el caso más favorable. Los pasajes técnico y periodístico elevan casi todos los multiplicadores porque los vocabularios de sistemas no latinos carecen precisamente de combinaciones para terminología y préstamos lingüísticos. En Claude, el alemán pasa de 1.68x en el texto informal a 2.29x en el técnico, y el hindi de GLM alcanza 5.98x su inglés en la noticia. Un benchmark basado en un solo pasaje favorece al idioma cuya traducción haya resultado más sencilla. Por eso Kimi situaba el chino en 0.80x con el texto narrativo, pero en 0.95x al considerar los tres.

Comparar cada modelo con su propio inglés tampoco responde a la pregunta del coste real. La factura depende del número absoluto de tokens. Desde esa perspectiva, Claude es la opción más cara en ocho de los nueve idiomas; el hindi de GLM es el único caso aún peor. Un contenido chino «barato respecto al inglés de Claude» sigue generando 88 tokens netos en Claude frente a 40 en Kimi para el pasaje narrativo. La estrategia no consiste en localizar para ahorrar, sino en elegir el modelo según el idioma: Kimi o DeepSeek para chino, GPT-5.5 para hindi y coreano, y DeepSeek para japonés. Claude nunca gana en coste por tokens, aunque podría hacerlo en calidad.

El recuento solo explica la mitad de la factura

Un multiplicador de tokens solo cobra sentido junto al precio por token; ambos factores se combinan. Claude Fable 5 tiene un precio publicado de $10 por millón de tokens de entrada, Opus 4.8 de $5 y Sonnet 5 de $3 cuando termine su precio de lanzamiento. En chino, el tokenizer que comparten también cuenta 2.2x más tokens que el modelo más eficiente. Por tanto, el sobrecoste del recuento se multiplica por cualquier diferencia de tarifa respecto a la alternativa a la que se enrutaría el tráfico. También puede ocurrir lo contrario: un modelo puede generar pocos tokens y, aun así, costar más por llamada debido a una tarifa elevada. Ninguna de las dos cifras basta por sí sola para calcular la factura. No incluimos aquí las tarifas de los demás proveedores porque cambian más rápido que los tokenizers. Los recuentos anteriores son la parte más estable del cálculo.

La comparación útil no se hace con los precios de catálogo, sino con el coste efectivo de entrada: la distribución real del tráfico, contada en cada modelo candidato y multiplicada por su tarifa de entrada. En un producto con mucho tráfico en chino o coreano, ese cálculo puede cambiar por completo qué modelo resulta más barato. La diferencia sostenida puede ser de 1.5x a 2x, no un error de redondeo. Por el mismo motivo, al usar cache importa el coste efectivo ponderado por la tasa de aciertos, no la tarifa publicada. La comparativa de proveedores desarrolla ese cálculo. El análisis entre versiones, por qué Sonnet 5 cuenta un 41% más que Sonnet 4.6 para el mismo texto en inglés, está en el artículo sobre el tokenizer de Sonnet 5.

Conclusión

• El coste en tokens es el producto de la densidad del sistema de escritura y la cobertura del tokenizer. El idioma determina el primer factor y el modelo, el segundo. Mirar cualquiera de ellos por separado lleva a conclusiones erróneas.
• Claude Fable 5, Opus 4.8 y Sonnet 5 consumen entre 1.2x y 2.3x los tokens del modelo más eficiente en todos los idiomas, porque su tasa por carácter es alta incluso en inglés.
• El modelo más eficiente depende del idioma: GPT-5.5 para idiomas europeos, hindi y coreano; Kimi para chino; DeepSeek para japonés. GLM obtiene su peor resultado en hindi, con casi un token por carácter.
• Los registros formal y técnico elevan el multiplicador en casi todos los idiomas. El benchmark debe usar el mismo registro que el producto real.
• No localices para ahorrar. Elige el modelo según los tokens absolutos que consume en cada idioma y multiplícalos después por su tarifa para comparar el coste efectivo.

Preguntas frecuentes

¿Qué tokenizer de LLM es el más barato? Depende del idioma. En siete modelos y usando pasajes equivalentes, GPT-5.5 fue el más eficiente en los idiomas europeos, hindi y coreano, y empató en inglés, Kimi K2.5 en chino y DeepSeek-v4 en japonés. La familia Claude, Fable 5, Opus 4.8 y Sonnet 5, nunca fue la más eficiente: en todos los idiomas y registros generó entre 1.2x y 2.3x el recuento mínimo.

¿Claude Fable 5, Opus 4.8 y Sonnet 5 usan el mismo tokenizer? Sí. Los tres produjeron recuentos de tokens idénticos para todas las muestras, en todos los idiomas, así como en código y JSON. Usan el tokenizer introducido con Opus 4.7, por lo que el recuento de uno se puede aplicar a los demás. La factura más alta de Fable 5 se debe por completo a su precio por token.

¿El chino es más caro que el inglés en Claude? Ligeramente: 1.17x por significado como promedio de los tres pasajes, y aproximadamente igual en los modelos entrenados en China. Por carácter parece mucho peor: unos 114 tokens netos por cada 100 caracteres chinos frente a 32 en inglés. Sin embargo, el chino transmite el mismo significado con aproximadamente un tercio de los caracteres, por lo que los totales casi se compensan.

¿El japonés y el coreano se comportan como el chino? Solo en parte. Comparten la alta densidad de tokens por carácter del chino, pero el hangul y los kana representan sonidos, por lo que necesitan muchos más caracteres para el mismo pasaje: 136 en japonés y 143 en coreano, frente a 77 en chino. La elevada tasa por carácter deja de compensarse. Por significado, el japonés consume alrededor de 1.6x los tokens del inglés en Claude y el coreano cerca de 2x; en los siete modelos, la diferencia va de 1.5x a 2.4x.

¿Cómo puedo medirlo con mis propios prompts? Envía varios prompts reales, con el mismo registro que usas en producción, a cada modelo candidato. Lee el recuento de tokens de entrada que devuelve el proveedor en los campos de uso, en lugar de confiar en un tokenizer local. Un único pasaje sencillo puede favorecer a un idioma en torno a un 20%, así que conviene usar varios. Después, multiplica cada recuento por el precio de entrada del modelo para calcular el coste efectivo con tu tráfico.

← Volver al blog