El "impuesto en chino" de los grandes modelos de IA: ¿Por qué el chino consume más tokens que el inglés?

Autor: Tang Yitao, Fuente: Geek Park

Durante los días posteriores a la publicación de Opus 4.7, en X se escucharon muchas quejas. Algunos dijeron que una sola conversación agotó su cuota de sesión, otros que el costo de ejecutar el mismo código se había duplicado respecto a la semana pasada; además, alguien compartió una captura de pantalla de su suscripción Max de 200 dólares alcanzando el límite en menos de dos horas.

El desarrollador independiente BridgeMind reconoce que Claude es el mejor modelo del mundo, pero también el más caro. Su suscripción Max se agotó en menos de dos horas, pero afortunadamente — compró dos.｜Fuente de la imagen: X@bridgemindai

El precio oficial de Anthropic no ha cambiado, sigue siendo 5 dólares por cada millón de tokens de entrada y 25 dólares por los de salida. Pero esta versión introdujo un nuevo tokenizador, y además Claude Code elevó el esfuerzo predeterminado de high a xhigh. La combinación de ambas cosas hizo que el consumo de tokens para la misma tarea aumentara entre 2 y 2.7 veces respecto a antes.

En estas discusiones vi dos afirmaciones relacionadas con el chino. Una es: que en el nuevo tokenizador, el chino casi no ha aumentado de costo, por lo que los usuarios chinos se han librado de este incremento. La otra, más interesante: el chino clásico usa menos tokens que el chino moderno, por lo que conversar en chino clásico con IA puede ahorrar costos.

La primera afirmación sugiere que Claude ha optimizado de alguna forma el manejo del chino, pero en la documentación oficial de Anthropic no se menciona ningún ajuste específico para el idioma chino.

La segunda afirmación es más difícil de explicar. El chino clásico claramente es más difícil de entender para los humanos que el chino moderno; si un texto es más complejo para las personas, ¿cómo puede ser más fácil para la IA?

Por eso hice una prueba con 22 textos paralelos (incluyendo noticias de negocios, documentos técnicos, textos clásicos, diálogos cotidianos, etc.), enviándolos simultáneamente a 5 tokenizadores (Claude 4.6 y 4.7, GPT-4o, Qwen 3.6, DeepSeek-V3), y midiendo el número de tokens que cada modelo consumía en cada texto, para compararlos lateralmente.

Textos de prueba:

1. Diálogos cotidianos en inglés y chino (viajes, ayuda en foros, solicitudes de escritura)

2. Documentos técnicos en inglés y chino (documentación de Python, documentación de Anthropic)

3. Noticias en inglés y chino (noticias políticas del NYT, noticias de negocios del NYT, declaraciones oficiales de Apple)

4. Fragmentos literarios en chino clásico y moderno (《出师表》《道德经》)

Tras las pruebas, ambas afirmaciones quedaron parcialmente confirmadas, aunque la realidad es más compleja que los rumores.

I. El “impuesto” al chino

Primero, la conclusión:

1. En Claude y GPT, el chino siempre ha sido más caro que el inglés

2. En Qwen y DeepSeek, el chino resulta ser más barato que el inglés

3. La actualización del tokenizador en Opus 4.7, que generó la conmoción, casi solo influyó en el inglés, mientras que el chino permaneció igual

Veamos los números específicos. Los modelos de la serie Claude antes de Opus 4.7 (incluyendo Opus 4.6, Sonnet, Haiku) usaban el mismo tokenizador. Bajo ese tokenizador, el consumo de tokens en chino siempre fue mayor que en inglés por la misma cantidad de contenido, con una relación cn/en entre 1.11× y 1.64×.

El escenario más extremo fue en noticias de negocios estilo NYT: en el mismo contenido, el chino consumió un 64% más de tokens, lo que equivale a pagar un 64% más.

Los modelos Claude anteriores a Opus 4.7 mostraron un consumo de tokens en chino claramente superior a otros modelos (marcado en rojo).

El escenario más extremo en noticias estilo NYT: en el mismo contenido, el chino usó un 64% más de tokens (marcado en verde).

El tokenizador o200k de GPT-4o es mejor: la relación cn/en en la mayoría de los casos está entre 1.0 y 1.35×, y en algunos escenarios incluso por debajo de 1. El chino sigue siendo generalmente más caro, pero la diferencia con Claude es mucho menor.

Por otro lado, los modelos nacionales Qwen 3.6 y DeepSeek-V3 muestran exactamente lo contrario. La relación cn/en en gran parte está por debajo de 1, lo que significa que, para el mismo contenido, el chino resulta en menor consumo de tokens que el inglés. DeepSeek llegó a un mínimo de 0.65×, es decir, en el mismo texto en chino se usan un tercio menos de tokens que en inglés.

La inflación del nuevo tokenizador en Opus 4.7 casi solo afectó al inglés. Los tokens en inglés aumentaron entre 1.24× y 1.63×, mientras que en chino se mantuvieron en torno a 1.000×, casi sin cambios. La factura de los desarrolladores en inglés, que sufrió la conmoción, no fue percibida por los usuarios chinos. La razón puede ser que en versiones anteriores, el chino ya se había segmentado a nivel de caracteres individuales, dejando poco espacio para dividir aún más.

Comparando Opus 4.7 con 4.6, el consumo de tokens en inglés aumentó, pero en chino permaneció igual.

Durante las pruebas, también noté otra cosa: la diferencia en consumo de tokens no solo afecta la factura, sino que también influye en el tamaño del espacio de trabajo. Con una ventana de contexto de aproximadamente 200k, usando el tokenizador antiguo en chino, se puede incluir entre un 40% y un 70% menos de contenido que en inglés.

Para tareas similares, como que la IA analice un documento largo o resuma una reunión, los usuarios chinos pueden proporcionar menos material, y el modelo tendrá un contexto más corto. El resultado: pagan más, pero obtienen un espacio de trabajo menor.

Al juntar los datos, surge una pregunta natural:

¿Por qué el mismo contenido en diferentes idiomas requiere diferentes cantidades de tokens? ¿Por qué en Claude y GPT el chino es más caro, y en Qwen y DeepSeek resulta más barato?

La respuesta está en el concepto de tokenizador (分词器) mencionado varias veces antes.

II. ¿Cuántas partes puede tener un carácter chino?

Antes de que el modelo lea cualquier texto, lo divide en tokens mediante el tokenizador. Puedes imaginar el tokenizador como una “máquina de cortar bloques” para IA. Introduces una frase, y se encarga de dividirla en bloques estandarizados (tokens). La IA no lee caracteres, solo reconoce los números de los tokens. Cuantos más bloques uses, más pagarás.

El corte en inglés es más intuitivo: por ejemplo, “intelligence” probablemente sea un solo token, “information” también, y cada palabra equivale a una unidad de facturación.

Pero en chino, esto ya complica las cosas. Si envías la misma frase “人工智能正在重塑全球的信息基础设施” a los tokenizadores cl100k de GPT-4 y Qwen 2.5, los resultados son completamente diferentes.

GPT-4 descompone cada carácter chino en un token; Qwen, en cambio, reconoce palabras completas como un solo token, por ejemplo, “人工智能” en cuatro caracteres cuenta como un solo token.

En una misma frase de 16 caracteres chinos, GPT-4 produce 19 tokens, Qwen solo 6.

¿por qué? La clave está en un algoritmo llamado BPE (Byte Pair Encoding).

BPE funciona analizando qué combinaciones de caracteres aparecen con mayor frecuencia en el corpus de entrenamiento, y fusiona esas combinaciones en un solo token, añadiéndolo a la lista de vocabulario.

En la era de GPT-2, la mayoría del corpus era en inglés. Las combinaciones de letras (th, ing, tion) se repetían mucho, y se fusionaban rápidamente en tokens. Los caracteres chinos, por su baja frecuencia en ese corpus, no entraban en la lista, y se trataban como bytes sin fusionar, ocupando 3 bytes por carácter, es decir, 3 tokens.

El proceso de BPE depende de la frecuencia de los caracteres en el corpus de entrenamiento. Bajo dominancia del inglés, los bytes UTF-8 chinos no se fusionan en caracteres completos.

Luego, GPT-4 amplió su vocabulario con cl100k, incluyendo muchos caracteres chinos comunes, reduciendo el número de tokens por carácter a 1 o 2 en promedio, pero aún menos eficiente que en inglés.

Con el vocabulario o200k de GPT-4o, la eficiencia del chino mejoró aún más. Esto explica por qué en los datos iniciales, la relación cn/en con GPT-4o es menor que con Claude.

Qwen y DeepSeek, como modelos nacionales, desde el principio incluyen en su vocabulario muchos caracteres chinos y frases frecuentes como unidades completas. Un carácter equivale a un token, lo que duplica o más la eficiencia.

Ilustración de cómo se dividen las frases en diferentes tokenizadores

Por eso, su relación cn/en puede ser menor que 1: los caracteres chinos, por su alta densidad de información, cuando no se dividen en bytes, muestran una ventaja natural.

La diferencia en los datos anteriores radica en que el tamaño del vocabulario y la segmentación en los tokenizadores afecta directamente el consumo de tokens, y por ende, el costo.

Claude y los primeros GPT usan vocabularios basados en inglés, en los que el chino se añadió después. Qwen y DeepSeek, desde el inicio, consideran el chino como idioma predeterminado. Esa diferencia inicial se transmite en el número de tokens, en la factura y en el tamaño de la ventana de contexto.

III. ¿Realmente el chino clásico es más barato?

Otra afirmación que surgió al principio: el chino clásico usa menos tokens que el chino moderno.

Los datos confirman esto. En las pruebas, los textos en chino clásico tienen una relación cn/en menor que 1 en todos los tokenizadores, y en todos los modelos. La misma frase en chino clásico requiere menos tokens que su traducción moderna.

En todos los modelos, el chino clásico consume menos tokens que el chino moderno, e incluso menos que el inglés.

La razón es sencilla: el chino clásico usa caracteres muy concisos. Por ejemplo, “学而不思则罔，思而不学则殆” (12 caracteres). La versión moderna sería “Solo estudiar sin pensar lleva a la confusión, solo pensar sin estudiar lleva al peligro”, que tiene el doble de palabras y, por tanto, más tokens.

Además, los caracteres frecuentes en chino clásico (“之”, “也”, “者”, “而”, “不”) son caracteres de alta frecuencia, y en cualquier vocabulario tienen su propia entrada, sin dividirse en bytes. Por eso, en codificación, el chino clásico es eficiente.

Pero hay una trampa.

El ahorro en tokens del chino clásico se da en la codificación, pero la carga de inferencia del modelo no disminuye. El carácter “罔”, por ejemplo, requiere que el modelo interprete si en ese contexto significa “confusión”, “engañar” o “no”. El chino moderno puede expresar esa idea con 26 caracteres, mientras que en chino clásico se comprime en menos caracteres, pero deja toda la carga de razonamiento al modelo. Es como un archivo comprimido: más pequeño, pero requiere más cálculo para descomprimir.

Menos tokens, pero mayor consumo en inferencia, y menor precisión en comprensión. Es una relación difícil de cuantificar.

Este ejemplo me hizo entender que el número de tokens por sí solo no dice mucho. Pero, siguiendo esa línea, hay otra cosa que no había considerado antes.

Como mencioné, en GPT-2, el tokenizador dividía “人” en 3 bytes UTF-8. Luego, en GPT-4, el vocabulario se amplió, y los caracteres comunes se convirtieron en un solo token. Qwen, aún más, fusiona varias palabras en un solo token.

Intuitivamente, esto parece una mejora continua: cuanto más se fusiona, más eficiente es, y mejor entiende el modelo.

Pero, ¿es realmente así? Pensemos en cómo aprendemos los caracteres chinos.

Los caracteres chinos son logogramas, en los que más del 80% son caracteres semántico-sonoros (形声字), compuestos por un radical que indica el significado y un componente que indica la pronunciación. Por ejemplo, “氵” en caracteres relacionados con líquidos, “木” en vegetales, “火” en calor.

El radical es la pista semántica más básica para aprender a leer: alguien que no conoce “焱” puede, viendo los tres “火”, deducir que tiene que ver con fuego.

El radical es la clave semántica básica en el proceso de reconocimiento. La gente primero infiere la categoría de significado por la estructura, y luego ajusta según el contexto.

Por ejemplo, “火花”, “火焰”, “光焰” en escritura y nombres, simbolizan luz y calor.

Pero en la lista de vocabulario del tokenizador, “焱” tiene un número, por ejemplo, 38721. Este número solo indica una posición en la lista, y el modelo, mediante ese índice, obtiene un vector numérico que representa “焱”.

El número en sí no lleva información sobre la estructura interna del carácter. La relación entre 38721 y 38722, para el modelo, es igual que entre 1 y 10,000. Así, la capa de información sobre la estructura del carácter queda encapsulada en ese número.

El modelo puede aprender indirectamente, mediante entrenamiento, que “焱”, “炎”, “灼” aparecen en contextos similares, pero esa vía es más indirecta que usar directamente la información del radical.

¿Podría el modelo, a partir de los bytes divididos, “ver” alguna pista de radicales o componentes, y luego recomponer esa información en etapas posteriores? Aunque esto aumente el número de tokens y el coste, ¿podría, en términos de comprensión semántica, ser más efectivo que simplemente aceptar un número opaco?

Un artículo publicado en 2025 en Computational Linguistics de MIT Press, titulado “Tokenization Changes Meaning in Large Language Models: Evidence from Chinese”, responde a esta pregunta.

IV. ¿Crecen radicales en fragmentos?

El autor, David Haslett, nota una coincidencia histórica.

En los años 90, Unicode asignó los códigos UTF-8 a los caracteres chinos agrupándolos por radical. Los caracteres que comparten radical tienen códigos cercanos. Por ejemplo, “茶” y “茎” contienen el radical “艹” (césped), y sus bytes UTF-8 comparten el mismo prefijo. Lo mismo con “河” y “海”, que contienen “氵”.

UTF-8 ordena los caracteres chinos por radical, y los caracteres con el mismo radical tienen códigos cercanos｜Fuente: Github

Esto significa que, cuando el tokenizador divide un carácter en 3 bytes UTF-8, los caracteres que comparten radical comparten el primer byte. Durante el entrenamiento, el modelo ve repetidamente estos patrones compartidos, y puede aprender que los caracteres con el mismo primer byte tienden a tener relación semántica, similar a cómo los humanos usan los radicales para inferir significado.

Haslett diseñó tres experimentos para verificar esto:

1. Preguntar a GPT-4, GPT-4o y Llama 3: “¿“茶” y “茎” comparten el mismo radical semántico?”

2. Pedir a los modelos que califiquen la similitud semántica entre dos caracteres.

3. Pedirles que identifiquen cuál de varios caracteres no pertenece a un grupo.

Cada experimento controló dos variables: si los caracteres compartían radical, y si en el tokenizador compartían el primer token. Este diseño 2×2 permite separar el efecto del radical del efecto del token.

Los resultados son consistentes: cuando los caracteres se dividen en múltiples tokens (como en el antiguo tokenizador de GPT-4, donde el 89% de los caracteres se dividen en más de un token), los modelos reconocen mejor los radicales compartidos; cuando los caracteres se codifican en un solo token (como en el nuevo tokenizador de GPT-4o, donde solo el 57% de los caracteres se dividen en múltiples tokens), la precisión disminuye.

En otras palabras, la hipótesis se confirma: dividir los caracteres en bytes aumenta el coste, pero también preserva rastros de radicales en la secuencia de bytes, y el modelo aprende a usarlos. Codificar los caracteres completos en un solo token reduce el coste, pero oculta esa información, que ya no puede ser extraída de la secuencia de bytes.

Es importante aclarar que esta conclusión se limita a tareas que involucran aspectos semántico-visual de los caracteres, y no implica que la comprensión general del chino, el razonamiento lógico o la generación de textos largos disminuya. Además, la comparación entre GPT-4 y GPT-4o, además del tokenizador, involucra cambios en arquitectura, datos de entrenamiento y parámetros, por lo que no se puede atribuir toda la diferencia solo a la granularidad del tokenizador.

Este hallazgo también ha sido validado en la práctica. En 2024, un estudio sobre GPT-4o encontró que, cuando el tokenizador fusionaba varios caracteres en un solo token largo, el modelo cometía errores de comprensión. Cuando los investigadores usaron un segmentador chino profesional para dividir esos tokens largos en caracteres individuales, la precisión se recuperó.

La tendencia actual en la industria de grandes modelos sigue siendo que los tokenizadores que optimizan la segmentación en palabras completas o caracteres completos, adaptados al idioma, mejoran significativamente el rendimiento general. Reducen el coste de tokens, aumentan la cantidad de información útil en la ventana de contexto, acortan secuencias, disminuyen la latencia y mejoran la estabilidad en textos largos. La ventaja en tareas específicas de segmentación no cubre toda la gama de beneficios en NLP en chino.

Pero esto revela un problema difícil de resolver en sistemas complejos: puedes optimizar la parte que diseñaste, pero no la parte que no sabes que tienes. La ordenación por radical en Unicode, y la división en bytes en BPE, son decisiones de ingeniería que, por coincidencia, crean canales semánticos no planificados en la red neuronal. Cuando los ingenieros intentan “mejorar” el tokenizador, fusionando caracteres en unidades completas, inadvertidamente cierran esas vías de comunicación semántica que no estaban previstas.

La historia no es una línea recta de evolución, sino un flujo que se moldea por múltiples restricciones y decisiones que a veces ocurren por azar.

Algunas capacidades son diseñadas, otras simplemente no se eliminan por accidente.

Fin de la traducción.