---
title: "Tokenización en LLMs: por qué el español y el código te cuestan más dinero"
description: "Un LLM no lee texto, lee números. Cómo se hace esa conversión define tu factura, tu latencia y hasta tus bugs raros. Y el español paga un plus real."
pubDate: "2026-06-01"
category: "programacion"
language: "es"
tags: ["llm", "ia", "fundamentos", "tokens", "tokenizacion", "costes", "desarrollo"]
---
En la [primera lección de esta serie](/blog/como-funciona-un-llm/) quedó una frase grabada: un LLM no hace más que **predecir el siguiente token**. Toda la IA que usas se construye sobre ese bucle. Pero ahí dejé una palabra sin abrir, y resulta que es la que te toca el bolsillo: *token*. ¿Qué es exactamente un token? ¿Por qué la palabra *"tokenización"* se parte en varios? ¿Y por qué escribir en español te sale más caro que en inglés? Esto último casi nadie lo cuenta.

La respuesta vive en una pieza minúscula y aburrida que casi nadie mira: el **tokenizador**. Es lo primero que toca tu texto antes de que el modelo lo vea, y es donde **empieza tu factura**. Si construyes con APIs de LLM y nunca te has parado a mirar cómo trocea tu texto, hay una probabilidad alta de que estés pagando entre un 30 % y un 50 % de más sin saberlo. Este artículo es la lección 1.2 del curso de IA que estoy preparando, y va de eso: del mecanismo, del dato real medido con código, y de qué hacer con él.


## El modelo no lee texto. Lee números.

Empezamos por lo que más cuesta tragar: **un LLM no entiende caracteres ni palabras**. Por dentro maneja **enteros** (IDs de tokens). El tokenizador es la pieza que traduce el texto que tú escribes a esa secuencia de números, y la que hace el camino de vuelta cuando el modelo genera. Es **determinista, está pre-entrenado y es fijo** para cada modelo: no cambia entre llamadas, no aprende de ti, no improvisa.

La pregunta natural de cualquier dev es: *¿y por qué no usar caracteres como unidad?* Son finitos, los hay en todos los idiomas, no hay que aprenderlos. Tiene sentido. El problema es la **longitud de la secuencia**. Si cada carácter fuese un token, el prompt *"escribe una función en Python"* serían unos 30 tokens, y la ventana de contexto es un recurso finito (volveremos a eso en otra lección). Gastar tokens en letras sueltas es derrochar la RAM del modelo.

Lo correcto es verlo como un **trade-off**. Cuantos más símbolos metes en el vocabulario, más cortas son las secuencias, pero cada token cuesta más memoria interna. Cuantos menos símbolos, secuencias más largas pero representación más compacta. Andrej Karpathy lo explica como una escalera:

- **Bits puros** (2 símbolos): secuencias larguísimas. No vale.
- **Bytes** (256 símbolos): mejor, secuencias ×8 más cortas. Tampoco.
- **BPE** (~100.000 símbolos): el punto dulce que usa toda la industria.

Ese tercer escalón es donde está casi toda la industria: GPT, Claude, Mistral, Qwen, DeepSeek. Y entender cómo se construye explica por qué tu español paga más.


## BPE: cómo se fabrica un vocabulario

**BPE** (*Byte Pair Encoding*) parte de los 256 bytes posibles y va **fusionando los pares más frecuentes** hasta llegar al tamaño de vocabulario deseado. La regla es de una sola línea: busca los dos símbolos consecutivos más comunes en el corpus de entrenamiento, únelos en un símbolo nuevo, reescribe el corpus y repite.

Como lo cuenta Karpathy: *"la secuencia '116 32' aparece muchísimo (una 't' seguida de un espacio, en mil contextos). La fusionamos en un símbolo nuevo con el ID 256, reescribimos el corpus y seguimos"*. Después de unas cien mil fusiones tienes un vocabulario de ~100k tokens que **codifica de forma eficiente el corpus que vio**. Y bastante peor cualquier cosa que ese corpus no contenía.

GPT-4 usa exactamente **100.277 tokens**. Claude, Mistral o DeepSeek rondan cifras parecidas. El número exacto da igual; lo que importa son dos consecuencias que vas a notar en la factura:

1. **Lo que el modelo vio mucho se codifica en un solo token. Lo raro se fragmenta.** Una palabra inglesa común cabe en un token; un tecnicismo en español que apenas aparecía en el corpus se parte en cuatro trozos.
2. **Cada modelo tiene su propio tokenizador.** Las cuentas que hagas con uno no valen para otro. Esto importa más de lo que parece.

Y aquí es donde el inglés, que dominaba el corpus de entrenamiento, salió ganando por diseño.


## El dato: cuánto cuesta el español de verdad

Esto se repite como mito ("el español gasta más tokens") y casi nunca con números. Vamos a medirlo de verdad, con `tiktoken`, contra dos tokenizadores: `cl100k_base` (el de GPT-4) y `o200k_base` (el de GPT-4o). Pares de prosa técnica equivalente en inglés y español:

| Frase (prosa técnica) | EN | ES | Ratio `cl100k_base` | Ratio `o200k_base` |
|---|---:|---:|---:|---:|
| *"The transformer architecture revolutionized…"* (vs ES) | 26 | 47 | **1,81×** | 1,23× |
| *"Unfortunately we would have to reconfigure…"* (vs ES) | 21 | 32 | **1,52×** | 1,33× |
| *"Decentralization and federation are recurring themes…"* (vs ES) | 13 | 21 | **1,62×** | 1,46× |
| **Total** | **60** | **100** | **1,67×** | **~1,3×** |

La conclusión es contundente y a la vez tiene matices que conviene no saltarse:

**1. Sí, el español cuesta más. No es mito.** Con el tokenizador de GPT-4, prosa técnica real paga **~1,67× más tokens** que su equivalente en inglés. Sobre miles de millones de tokens al mes, eso es dinero contante. No es un detalle estético.

**2. Los tokenizadores modernos han recortado la brecha, pero no la han cerrado.** `o200k_base` (GPT-4o), con 200k de vocabulario, baja el ratio a **~1,3×**. Gemini, Mistral o el Claude actual juegan en órdenes parecidos. Mejor que la era `cl100k_base`, pero el plus sigue ahí.

**3. De dónde sale el plus.** Tres causas que se suman:
- **Acentos y diéresis que se fragmentan**: *"murciélago"* en `cl100k_base` son cuatro trozos (`mur`, `ci`, `él`, `ago`).
- **Conjugaciones ricas** que el BPE no aprendió como pieza: *"reconfiguraríamos"* es un solo verbo en español; el tokenizador lo parte en 3-5 piezas.
- **Pronombres enclíticos**: *"decírtelo"*, *"habérselo"*, *"explicárnoslo"* (únicos del español, baja frecuencia en el corpus, fragmentación garantizada).

**4. Cuidado con las frases cortas: engañan.** Palabras muy frecuentes (*"Madrid"*, *"café"*, *"hola"*) y frases sencillas (*"El sol sale por el este"*) pueden empatar con el inglés, porque BPE las aprendió como pieza única. Pero en cuanto el texto se vuelve **prosa real con vocabulario técnico, conjugaciones y acentos**, el ratio se dispara. Lo que cuenta es el **promedio sobre tu contenido real**, no una palabra de muestra.


## El código paga aparte (y en cualquier idioma)

El idioma es solo un frente. El otro, si tu app procesa código, es igual de caro y mucho más silencioso. Identificadores en `snake_case`, símbolos, mayúsculas en posiciones que el tokenizador no esperaba: todo eso fragmenta. Mira:

| Texto | `cl100k_base` |
|---|---|
| `"tokenization"` | 2 tokens: `["token", "ization"]` |
| `"murciélago"` | 4 tokens: `["mur", "ci", "él", "ago"]` |
| `"console.log('hola')"` | 6 tokens |
| `"def funcion_con_nombre_largo(param1, param2):"` | 12 tokens |

Una sola línea de Python con un nombre de función descriptivo ya son 12 tokens. Multiplica eso por un fichero entero que mandas a revisar a un agente y entenderás por qué **tu factura de tokens es 2-3× lo que estimaste contando palabras**. Detalle fino que descoloca a todo el mundo: `console.log("hola")` con comillas dobles puede tokenizar distinto que con comillas simples. El tokenizador no sabe de sintaxis; sabe de frecuencias.


## Lo que esto significa para tu margen

Aquí está la consecuencia de negocio que casi nadie dice en voz alta: **si vendes un SaaS de IA a hispanohablantes y pagas tokens, tu margen es ~25-50 % peor que el de un competidor anglosajón equivalente.** Mismo producto, mismo modelo, misma calidad de respuesta. Y pagas más por cada llamada solo porque tu idioma y tu código fragmentan más. Es un hecho del paradigma, no un fallo tuyo.

No se elimina, pero se mitiga, y hay cuatro palancas concretas:

1. **Elige modelo con tokenizador moderno.** GPT-4o (`o200k_base`), Gemini, Mistral, Claude 3.5+ tienen ratios bastante mejores que la generación `cl100k_base`. El tokenizador es un criterio de selección de modelo, no solo el *benchmark* de turno.
2. **Cachea todo lo que se repita.** El *prompt caching* (otra lección) puede ahorrarte hasta el 90 % del coste de la parte estable del prompt. Lo que no cambia entre llamadas no debería pagarse entero cada vez.
3. **Pide respuestas concisas.** El output es lo caro (lo vimos en la [lección 1.1](/blog/como-funciona-un-llm/): cada token de salida es un *forward pass* completo). Acotar la longitud de respuesta ahorra más que recortar el prompt.
4. **Separa idioma de sistema y de contenido.** Instrucciones, *system prompts* y andamiaje en inglés; español solo para el contenido del usuario. Reduces tokens donde no afecta a la experiencia.

Esto enlaza directo con lo que cuento en [optimización de tokens](/blog/token-optimization/): casi todo el ahorro real de una operación con LLMs empieza por entender qué se está tokenizando y cuánto.


## Cómo medirlo tú mismo

La regla de oro: **no afirmes "este prompt tiene X tokens" sin medirlo.** Tienes dos formas, una visual y una programática.

La visual es [TickTokenizer](https://tiktokenizer.vercel.app/): pegas cualquier texto, eliges el modelo y ves al instante cómo lo trocea, token a token y con colores. Es la forma más rápida de pillarle el ojo a por qué tu código o tu español se fragmentan.

La programática, en cinco líneas:

```python
import tiktoken

enc = tiktoken.get_encoding("cl100k_base")  # GPT-4; usa "o200k_base" para GPT-4o
texto = "def funcion_con_nombre_largo(param1, param2):"
tokens = enc.encode(texto)
print(len(tokens), tokens)   # -> 12  (seguido de la lista de IDs)
```

Y cuando inspeccionas una llamada a la API en bruto, lo que te factura el proveedor está en el desglose de `usage`:

```json
"usage": {
  "input_tokens": 1284,
  "output_tokens": 312,
  "cache_read_input_tokens": 982
}
```

Cada uno de esos enteros se traduce en dinero según el modelo. Fíjate en `cache_read_input_tokens`: esos 982 tokens leídos de caché cuestan una fracción de los de entrada normal: son la palanca 2 de la sección anterior, hecha número.


## Tres preguntas para ver si lo tienes

Antes de cerrar, contéstate estas. Si las tienes claras, has interiorizado la lección.

1. **Sin ejecutar nada: ¿cuántos tokens dirías que tiene `"murciélago"` en GPT-4? ¿Y `"hello"`?** Si te equivocas mucho, ¿qué intuición estabas usando (letras, sílabas, palabras)?
2. **¿El inglés es *siempre* más barato que el español?** Razónalo antes de responder. (Pista: las frases muy frecuentes empatan; el plus aparece con prosa técnica real.)
3. **¿Por qué `console.log('hola')` puede costar distintos tokens que `console.log("hola")`?** Si sabes explicar esto, has entendido que el tokenizador no sabe de sintaxis, solo de frecuencias.

Si una se te resiste, vuelve arriba. Si las tres son obvias, ya tienes la pieza que conecta el modelo con tu factura.


## Lo que viene después

Esto ha sido la lección 1.2 del curso *Agentes e IA: Zero to Hero*. Ya sabes que el modelo convierte tu texto en una secuencia de enteros y por qué esa conversión te cuesta dinero. La siguiente pregunta es inevitable: vale, el token es un número… **¿pero cómo captura el modelo el *significado* de ese número?**

- **1.3 Embeddings**: cómo cada token se transforma en un vector y por qué la "cercanía semántica" se mide, literalmente, con **geometría**. Es la base de todo lo que luego llamamos RAG.
- **1.4 La arquitectura Transformer de un vistazo**, sin matemáticas demostradas, con criterio de ingeniero.
- **1.5 El mecanismo de atención**, la pieza que hizo posible el contexto largo.

¿Quieres ir más al fondo? Byte-level BPE vs SentencePiece, *fertility* por idioma, los tokens especiales como vector de ataque: todo eso entra en la versión completa de la lección dentro del curso. Ahí van también las referencias primarias (Sennrich 2015 para BPE, Rust et al. 2021 para el estudio de *fertility* por idioma).

Si esto te interesa y quieres acceso anticipado y descuento de lanzamiento cuando salga, déjame tu email en la [lista de espera de **Agentes e IA: Zero to Hero**](/curso-agentes-ia/). Cada lección está escrita al nivel de la que acabas de leer: operativa, sin paja, con el dato medido.

Y la pregunta para ti, que da forma al curso final: ¿ya habías medido cuántos tokens te cuesta de verdad tu contenido en producción, o lo estabas estimando por palabras? Cuéntamelo en respuesta a la newsletter o en redes.

---

*Para seguir el hilo: [cómo funciona un LLM](/blog/como-funciona-un-llm/) es la lección anterior y el cimiento de esta, y [optimización de tokens](/blog/token-optimization/) baja a producción mucho de lo que aquí queda en concepto.*

**P.D.**: Si quieres que profundice en alguna pieza concreta del tokenizador antes de la próxima lección, me encuentras en Twitter como [@lm_martinbar](https://x.com/lm_martinbar).