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

No hay un único LLM más barato para texto multilingüe: medido sobre el mismo pasaje, GPT-5.5 factura menos tokens en idiomas europeos, hindi y coreano, Kimi K2.5 es el más ajustado en chino y DeepSeek en japonés. Claude Fable 5, Opus 4.8 y Sonnet 5 comparten un mismo tokenizer (recuentos idénticos en cada muestra que enviamos) y nunca son los más ajustados: el mismo párrafo en inglés factura 90 tokens en bruto en Claude frente a los 55 de DeepSeek, y el sobrecoste neto va de 1,3x en japonés a 2,2x en chino. El token es la unidad de facturación, así que dos cosas que rara vez ves en una página de precios deciden tu coste de entrada: cuánto significado empaqueta un idioma por carácter y cómo de bien comprimió ese script el tokenizer de cada modelo. Se multiplican, y el resultado no es lo que sugiere la vista por carácter.

TL;DR

• Claude Fable 5, Opus 4.8 y Sonnet 5 comparten un tokenizer y nunca son los más ajustados: 1,2-2,3x el recuento más barato en todas partes.
• 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, el CJK parece 3x peor, pero por significado el chino queda cerca de la paridad, mientras que japonés y coreano van a 1,5-2,4x.
• El coste es densidad del script por cobertura del tokenizer; una cobertura ausente lo multiplica (GLM factura el hindi a 4,9x su inglés).
• Localizar rara vez ahorra dinero; ajusta el modelo al idioma por tokens.

Los recuentos se midieron a través del gateway de Synthorai el 2026-07-08, usando siempre el recuento propio de cada proveedor, nunca un tokenizer local. Cada recuento fue idéntico entre repeticiones.

El token es la unidad de facturación, no el texto

Se te factura por token, pero un token no es un carácter ni una palabra. Cada modelo trae su propio tokenizer con su propio vocabulario, y la misma frase resuelve a un recuento de tokens distinto en cada uno. Ese recuento luego multiplica el precio por token, así que varían dos cosas a la vez: cuántos tokens acaba siendo tu texto y cuánto cuesta cada token.

La mayoría de las páginas de precios solo muestran el segundo número. Este post mide el primero. Enviamos tres pasajes semánticamente equivalentes 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 leímos lo que cada uno facturó como entrada.

Una narrativa informal (una historia de un mercado de sábado) existe en nueve idiomas; una explicación técnica (reintento con backoff exponencial) y un breve de noticias (una votación sobre el presupuesto municipal) existen en inglés, chino, japonés, coreano, alemán e hindi. Una función de Python y un blob JSON de tool-call completan el conjunto. Las versiones no inglesas son traducciones automáticas producidas con una instrucción de fidelidad y sin compresión, revisadas a mano por muestreo; la verbosidad de la traducción es un factor de confusión real, y la sección de registro más abajo lo acota en torno al 20%.

El recuento es siempre el del propio proveedor: la línea de Claude mediante una llamada real de Messages leyendo usage.input_tokens (el gateway no hace proxy de count_tokens por ahora), y los modelos compatibles con OpenAI mediante una llamada pequeña leyendo usage.prompt_tokens. Un tokenizer local que no coincide con la factura es exactamente el fallo que esto evita. Importa un control: cada petición lleva un envoltorio fijo (plantilla de chat, marcadores de rol) que vale un puñado de tokens, así que medimos una muestra base de dos caracteres y la restamos. Cada ratio de este post es neto de ese envoltorio y compara el texto, no el envoltorio.

El mismo texto, cinco tokenizadores

Este es el conteo bruto de tokens de entrada para el pasaje narrativo, por idioma y por tokenizador. Los tres modelos de Claude comparten columna porque devolvieron conteos idénticos en cada muestra (más sobre esto abajo). Los otros dos pasajes reproducen el mismo patrón y aparecen consolidados más adelante. La columna de caracteres es la longitud de la versión en cada idioma; cada escritura empaqueta el significado de forma distinta, y el chino dice en 77 caracteres lo mismo que el inglés necesita 254 para expresar.

Saltan a la vista dos cosas. La columna de Claude es un solo número para tres modelos porque Claude Fable 5, Opus 4.8 y Sonnet 5 devolvieron conteos idénticos en cada muestra, tanto en idiomas como en código y JSON: los tres usan el tokenizador que se introdujo con Opus 4.7, así que un conteo en uno vale para todos. Y esa columna es la más alta en cada fila salvo en hindi, donde los 192 de GLM son peores. Normalizado sobre conteos netos, de modo que el modelo más económico de cada idioma marque 1.00 (el envoltorio se resta primero, así que estas proporciones no coincidirán con una división directa de las celdas brutas de arriba):

El empate a cuatro bandas en la fila del inglés no es cuestión de redondeo: DeepSeek, GLM, GPT-5.5 y Kimi caen todos en exactamente 50 tokens netos para ese pasaje. Claude gasta entre 1.3x y 2.2x más que el tokenizador más económico en este pasaje, y entre 1.2x y 2.3x en los tres, una propiedad del vocabulario que se aplica a cada llamada durante toda la vida del modelo. Los pasajes técnico y de noticias reproducen el mismo orden: sumando ambos, Claude factura el chino a 212 tokens netos frente a los 114 de Kimi (1.9x) y el hindi a 477 frente a los 210 de GPT-5.5 (2.3x). Pero por debajo no hay un único ganador. La columna más económica cambia según el idioma:

• GPT-5.5 es el más económico en alemán, francés, español, italiano, hindi y coreano, y empata como el más económico en inglés (el empate y el orden fr/es/it valen solo para la narrativa). Su vocabulario está afinado hacia las escrituras latinas y aguanta bien en devanagari y hangul.
• Kimi K2.5 es el más económico en chino y competitivo en todo el CJK.
• DeepSeek-v4 es el más económico en japonés y va muy cerca en chino.
• GLM 5.2 queda a mitad de tabla en la mayoría de idiomas, pero registra las peores celdas de toda la matriz en hindi: 2.59x sobre el más económico en la narrativa (179 tokens netos donde GPT-5.5 necesita 69), aún peor en los pasajes formales, y la única columna que supera incluso a Claude.

La penalización no se limita a la prosa. En la función de Python, Claude gasta 1.61x más que el más económico, y en la llamada de herramienta JSON, 1.29x. La diferencia en JSON es más estrecha porque el texto estructurado es en su mayoría puntuación y claves ASCII cortas que todos los tokenizadores manejan de forma parecida. Para un agente de larga ejecución que reenvía un esquema de herramientas grande en cada turno, ese impuesto por turno se acumula, y ahí es donde el caching demuestra su valor. La serie sobre prompt caching cubre esos mecanismos.

La trampa del coste por carácter: el CJK parece peor de lo que factura

Las tablas anteriores comparaban modelos. Fija ahora el modelo y verás que el idioma también mueve el recuento, pero no como sugiere la vista en bruto de caracteres. El número de tokenizador que más se cita son los tokens por carácter, y ahí el CJK arrasa: en Claude, el chino ronda los 114 tokens netos por cada 100 caracteres, el coreano 106 y el japonés 94, frente a los 32 del inglés. Si miras solo esa columna, el CJK parece un impuesto del 3x, pero es la columna equivocada: pagas por significado, no por caracteres, y el pasaje alineado transporta el mismo significado en todos los idiomas. Aquí tienes ambas vistas en Claude, para el pasaje narrativo:

Las dos columnas de la derecha se contradicen, y el chino es el caso más extremo: la mayor densidad por carácter del conjunto, pero un sobrecoste por significado de apenas 1.07x el inglés en este pasaje. 77 caracteres cargan con lo que el inglés gasta en 254, así que una tarifa alta por carácter multiplica un recuento de caracteres minúsculo y casi se cancela. En los tres pasajes la cancelación se mantiene, pero no es magia: el chino promedia 1.17x sobre el propio inglés de Claude, y entre 0.95x y 1.32x según el modelo, más cerca de la paridad que del 3x que amenaza la columna por carácter.

El japonés y el coreano responden a la pregunta que salta enseguida: la misma ilusión, con una cancelación más débil. Ambos comparten la alta densidad por carácter, porque el hangul y los kana japoneses deletrean sonidos con más o menos un glifo por sílaba, en vez de meter una palabra entera en cada carácter como hace el hanzi chino. Por eso el coreano necesita 143 caracteres y el japonés 136 para el pasaje que el chino resuelve en 77. Más caracteres por una tarifa alta por carácter no se cancelan, se acumulan: en Claude, el coreano promedia 1.96x el inglés por significado en los tres pasajes y el japonés 1.56x, ambos realmente caros, aunque su columna por carácter se parezca mucho a la del chino.

El alemán es la imagen especular del chino: una tarifa baja por carácter (48, cerca del inglés) pero el mayor número de caracteres de todos los idiomas aquí (289, por sus palabras compuestas), lo que aun así suma 1.68x. El coste es el producto de los dos ejes, y leer uno solo despista.

Por qué se mueven los números: dos factores multiplicados

Detrás de todas las tablas anteriores hay una sola ecuación:

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

El primer factor es la densidad del sistema de escritura, una propiedad del idioma y no del modelo. Es un espectro, no una excepción china. El chino logográfico mete un morfema en cada carácter y se ubica en el extremo denso. El kana japonés y el Hangul coreano deletrean sonidos, así que son menos densos y necesitan más caracteres. El devanagari y los alfabetos latinos son aún menos densos. El significado por carácter va bajando de forma constante desde el chino hasta el inglés.

El segundo factor es cuántos tokens gasta el vocabulario del modelo por cada carácter de ese sistema de escritura, y depende por completo del modelo. Un tokenizador BPE aprende fusiones de varios caracteres a partir de su corpus de entrenamiento: los sistemas de escritura que vio con frecuencia obtienen tokens compactos, y los que apenas vio caen hacia una codificación carácter por carácter o incluso a nivel de byte, donde un solo carácter puede convertirse en dos o tres tokens. Los mismos tres idiomas, tokens netos por carácter:

La tabla explica tres cosas. El chino parece especial en los totales porque es extremo en el primer factor: ni siquiera la débil compresión del chino en Claude (1.14 tokens por carácter, que todavía parte algunos hanzi en dos) logra que el total sea grande cuando solo hay 77 caracteres, y los modelos entrenados en China lo comprimen lo bastante bien (entre 0.52 y 0.58) como para quedar casi a la par de su propio inglés. El sobrecosto del hindi es el segundo factor, no la densidad: GLM gasta 0.91 tokens por carácter devanagari, casi un token por carácter, porque su vocabulario apenas tiene fusiones de varios caracteres en devanagari, mientras que GPT-5.5 gasta 0.35 al cubrir grupos silábicos completos; una diferencia de cobertura sobre el mismo sistema de escritura. Y Claude está alto en todo porque su tasa por carácter es alta incluso en inglés (0.32 frente al 0.20 de DeepSeek), una base a nivel de modelo que se suma a lo que haga cada idioma.

Nada de esto es una rareza de nuestros siete modelos. La literatura de investigación llama a este fenómeno el token premium, y Petrov et al. (NeurIPS 2023) lo midieron en cientos de pares de idiomas, encontrando las mismas dos causas de raíz (el número de caracteres varía según el significado, y la cobertura del tokenizador varía según el sistema de escritura) y sobrecostos de hasta 15x para idiomas de pocos recursos, con las mismas consecuencias: más costo, más latencia y menos ventana de contexto aprovechable, ya que un idioma con alto sobrecosto llena el mismo presupuesto de contexto con menos significado. La brecha también se reduce a medida que los proveedores invierten: mediciones independientes ubican al chino en +182% de tokens frente al inglés en los vocabularios de la era GPT-3 y en +24% en el de GPT-4o, cerca del +32% que medimos en GPT-5.5 y de la paridad que medimos en los modelos entrenados en China. La cobertura se compra con espacios de vocabulario, y los proveedores siguen comprando.

¿Localizar ahorra dinero alguna vez?

Es fácil leer la sección de la trampa y concluir que “Claude es parejo entre idiomas, así que ignora la localización” y que “los modelos chinos son baratos en chino, así que localizar ahorra dinero”. Ambas conclusiones son falsas. Aquí está cada idioma frente al inglés de ese mismo modelo, promediado sobre los tres pasajes, para los cinco idiomas que tienen los tres:

Claude no es parejo: el coreano cuesta 1.96x su inglés y el hindi 2.40x. Que el chino ronde 1.17x es una coincidencia de un solo idioma, no una propiedad del modelo. Y los modelos chinos no superan la paridad en chino, apenas la alcanzan: la mejor celda de toda la tabla es el 0.95x de Kimi, un cinco por ciento por debajo de su propio inglés, y cualquier otra celda cuesta lo mismo o más. En hindi, japonés y coreano esos mismos modelos arrastran una penalización mayor que Claude, no menor, porque esos scripts están más lejos de su foco de entrenamiento. El patrón no es “el proveedor X es barato”; es que 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 mueve estos números. La narrativa informal es el caso más benévolo; los pasajes técnico y de noticias suben casi todos los multiplicadores, porque la terminología y los préstamos son justo lo que los vocabularios no latinos no tienen fusionados. En Claude, el alemán pasa de 1.68x (informal) a 2.29x (técnico), y el hindi de GLM llega a 5.98x su inglés en el pasaje de noticias. Un benchmark de un solo pasaje favorece al idioma que recibió la traducción más benévola, y por eso la narrativa por sí sola dejaba el chino en 0.80x con Kimi mientras que los tres pasajes lo sitúan en 0.95x.

De todos modos, comparar contra el propio inglés es la lente equivocada. Lo que pagas son tokens absolutos, y ahí Claude es el más caro en ocho de los nueve idiomas; la única columna peor es el hindi de GLM. El contenido en chino que resulta “barato respecto al inglés de Claude” sigue siendo 88 tokens netos en Claude frente a 40 en Kimi para la narrativa. Así que la jugada no es localizar para ahorrar, sino emparejar el modelo con el idioma: chino a Kimi o DeepSeek, hindi y coreano a GPT-5.5, japonés a DeepSeek. Claude nunca gana en coste de tokens en ningún idioma, aunque puede seguir ganando en calidad.

El conteo es solo la mitad de la factura

Un multiplicador de tokens solo importa junto al precio por token, y los dos se combinan. Claude Fable 5 cuesta 10 $ por millón de tokens de entrada, Opus 4.8 5 $, y Sonnet 5 3 $ una vez que termine su precio de lanzamiento; en chino, el tokenizer que comparten también cuenta el texto a 2,2x respecto al modelo más eficiente, así que ese sobrecosto de conteo multiplica cualquier diferencia de tarifa que el modelo ya arrastre frente a la alternativa a la que enrutarías. También puede pasar lo contrario: un modelo cuenta de forma ajustada y aun así cuesta más por llamada porque su tarifa es alta. Ninguno de los dos números por sí solo te dice cuál será la factura. No publicamos aquí las tarifas de los otros proveedores porque cambian más rápido que los tokenizers; los conteos de arriba son la mitad duradera del cálculo.

Lo práctico es dejar de comparar precios de etiqueta y comparar el costo efectivo de entrada: tu mezcla real de tráfico, contada en cada modelo candidato, multiplicada por la tarifa de entrada de ese modelo. En un producto con mucho chino o mucho coreano, ese cambio de orden puede invertir cuál modelo sale más barato, y la diferencia es un 1,5x a 2x sostenido, no un error de redondeo. Es la misma razón por la que, al cachear, el número que importa es el costo efectivo ponderado por la tasa de aciertos y no la tarifa titular, algo que desarrolla la comparación de proveedores. La versión de esta historia entre versiones, por qué Sonnet 5 cuenta un 41 % más que Sonnet 4.6 con el mismo inglés, está en el post del tokenizer de Sonnet 5.

En resumen

• El costo en tokens es densidad de escritura por cobertura del tokenizer. El idioma fija el primer factor, el modelo el segundo, y leer uno solo confunde.
• Claude Fable 5, Opus 4.8 y Sonnet 5 cuestan 1,2x a 2,3x más que el modelo más eficiente en todos los idiomas, porque su tarifa por carácter es alta incluso en inglés.
• El modelo más eficiente depende del idioma: GPT-5.5 para lenguas europeas, hindi y coreano, Kimi para chino, DeepSeek para japonés. GLM es el más flojo en hindi, con casi un token por carácter.
• El registro formal y técnico eleva el multiplicador en casi todos los idiomas; haz el benchmark en el registro que realmente vas a usar.
• No localices para ahorrar; ajusta el modelo al idioma según tokens absolutos y luego multiplica por la tarifa de cada modelo para comparar el costo efectivo.

Preguntas frecuentes

¿Qué tokenizador de LLM es el más barato? Depende del idioma. Al comparar siete modelos sobre los mismos pasajes alineados, GPT-5.5 fue el más económico en los idiomas europeos, hindi y coreano (empatado en inglés), Kimi K2.5 en chino y DeepSeek-v4 en japonés. La familia Claude (Fable 5, Opus 4.8, Sonnet 5) nunca fue la más económica: en todos los idiomas y registros gastó entre 1,2x y 2,3x más tokens que la opción más barata.

¿Claude Fable 5, Opus 4.8 y Sonnet 5 usan el mismo tokenizador? Sí. Los tres dieron recuentos de tokens idénticos en cada muestra, en todos los idiomas, en código y en JSON. Usan el tokenizador que se introdujo con Opus 4.7, así que un recuento hecho en uno sirve para los otros; la factura más alta de Fable 5 viene solo de su precio por token.

¿El chino sale más caro que el inglés en Claude? Un poco: 1,17x por significado, promediado sobre tres pasajes (y prácticamente igualado en los modelos entrenados en China). Por carácter la cosa pinta mucho peor (unos 114 tokens netos por cada 100 caracteres chinos frente a 32 en inglés), pero el chino transmite el mismo significado en cerca de un tercio de los caracteres, así que los totales casi se cancelan.

¿El japonés y el coreano se comportan como el chino? Solo a medias. Comparten con el chino la alta densidad por carácter, pero el hangul y los kana escriben los sonidos letra a letra, así que necesitan muchos más caracteres para el mismo pasaje (japonés 136, coreano 143, frente a los 77 del chino). La alta tasa por carácter ya no se cancela, así que por significado el japonés sale en torno a 1,6x el inglés en Claude y el coreano cerca de 2x, y entre 1,5x y 2,4x en los siete modelos.

¿Cómo mido esto para mis propios prompts? Envía unos cuantos prompts reales, en el registro que de verdad usas en producción, a cada modelo candidato y lee el recuento de tokens de entrada que reporta el propio proveedor en los campos de uso, en lugar de fiarte de un tokenizador local. Un solo pasaje favorable puede beneficiar a un idioma en torno a un 20%, así que usa varios. Luego multiplica cada recuento por el precio de entrada de ese modelo para obtener el coste efectivo sobre tu tráfico.

← Volver al blog