¿Qué son los tokens en los LLM? Explicación sencilla

Un token es la unidad básica de texto que lee y produce un gran modelo de lenguaje (LLM). Antes de que el modelo vea tu prompt, el texto se divide en tokens: las palabras comunes suelen ser un solo token, las más largas o raras se dividen en varias piezas, y los espacios, la puntuación y los números también son tokens o partes de tokens. En inglés corriente, un token equivale a unos cuatro caracteres o tres cuartas partes de una palabra. Los tokens importan en la práctica porque determinan lo que cuesta una solicitud, cuánto texto cabe en la ventana de contexto del modelo y cuánto tarda en generarse una respuesta.

Por qué los modelos usan tokens y no palabras o letras

Un modelo necesita un vocabulario fijo de unidades que pueda representar internamente. Usar palabras enteras exigiría un vocabulario enorme y seguiría fallando con palabras nuevas, nombres y erratas. Usar caracteres sueltos convertiría los textos en secuencias larguísimas y lo ralentizaría todo.

Los tokens son el término medio. Un tokenizador aprende, a partir de grandes cantidades de texto, qué secuencias de caracteres aparecen a menudo y las convierte en entradas del vocabulario. Las palabras frecuentes pasan a ser un solo token. Las menos frecuentes se forman con piezas más pequeñas. Así, el modelo puede representar cualquier texto, incluso palabras inventadas, manteniendo compacto el texto habitual.

Cada familia de modelos tiene su propio tokenizador, así que la misma frase puede dar un número de tokens distinto según el modelo. Por eso los recuentos exactos deben salir siempre del tokenizador del modelo que realmente usas.

Cómo es la tokenización

La división exacta depende del tokenizador, pero un patrón típico es este (ilustrativo, no la salida de un modelo concreto):

Texto	Tokens posibles	Número
The invoice is due	The invoice is due	4
Unbelievably	Un believ ably	3
2026-10-04	202 6 - 10 - 04	6
Kundenzufriedenheit	K unden zuf ried enheit	5

Fíjate en algunos patrones:

• El espacio previo suele formar parte del token. «invoice» precedido de espacio es un token distinto de «invoice» al principio de una línea.
• Las palabras largas se dividen en piezas. Es especialmente habitual en idiomas con palabras compuestas.
• Los números y las fechas pueden salir sorprendentemente caros. Los dígitos suelen agruparse en bloques pequeños.

Reglas generales para estimar tokens

Para una estimación rápida, estas reglas aproximadas sirven para planificar:

Contenido	Estimación aproximada
Prosa en inglés	1 token ≈ 4 caracteres ≈ 0,75 palabras
1.000 palabras en inglés	unos 1.300–1.400 tokens
Una página de texto en inglés (unas 500 palabras)	unos 650–700 tokens
Alemán, francés, español	a menudo bastantes más tokens que el mismo contenido en inglés
Código fuente, JSON, tablas	a menudo más tokens por carácter que la prosa, por los símbolos y espacios
Idiomas con escrituras no latinas	pueden ser muchos más, según el tokenizador

Son solo estimaciones. Para presupuestos, mide con muestras reales. La calculadora de coste de API de LLM incluye un estimador rápido: pega un prompt o una respuesta típicos y te dará un recuento aproximado de tokens que puedes trasladar al cálculo de costes.

Tokens de entrada y tokens de salida

Cada solicitud tiene dos recuentos:

• Tokens de entrada: todo lo que envías. Incluye el prompt de sistema, los turnos anteriores de la conversación, los documentos insertados, las definiciones de herramientas y el mensaje del usuario.
• Tokens de salida: todo lo que genera el modelo como respuesta. Algunos modelos generan además tokens de razonamiento internos antes de la respuesta visible, que pueden cobrarse como salida.

La distinción importa porque la mayoría de proveedores les pone precios distintos, y la salida suele ser más cara por token. La guía sobre los precios de las API de LLM explica con un ejemplo cómo ambos se suman en tu factura.

La ventana de contexto: los tokens como capacidad

La ventana de contexto es el número máximo de tokens que un modelo puede tener en cuenta en una solicitud, entrada y salida juntas. Si un modelo tiene, por ejemplo, una ventana de 128.000 tokens, tu prompt y la respuesta deben caber en ella.

Qué significa en la práctica:

• Los documentos largos pueden no caber. Una gran colección de contratos o un hilo de correos largo puede superar la ventana.
• Los chats tienen un límite de memoria. En una conversación larga, los turnos antiguos acaban teniendo que eliminarse o resumirse.
• Una ventana mayor no sale gratis. Cada token que envías cuesta dinero y tiempo. Enviar un manual entero cuando solo importa una sección es un despilfarro.
• Más contexto no siempre es mejor. Los modelos pueden pasar por alto detalles enterrados en entradas muy largas. Un contexto enfocado suele dar respuestas más fiables.

Cuando los documentos son demasiado grandes o numerosos, la solución habitual es la recuperación: buscar primero los pasajes relevantes y enviar solo esos. Nuestra comparativa RAG o fine-tuning explica cómo funciona.

Tokens y velocidad

Los modelos generan la salida token a token. De ahí se derivan dos consecuencias prácticas:

1. Las respuestas largas tardan más. Si los usuarios esperan, pedir respuestas concisas mejora la experiencia.
2. Las entradas largas también añaden retraso. Procesar un prompt muy largo lleva tiempo antes de que aparezca el primer token de salida, aunque normalmente menos por token que la generación.

Si tu aplicación parece lenta, revisa los recuentos de tokens antes de cambiar de proveedor.

Por qué el mismo contenido puede costar más en otros idiomas

Los tokenizadores se entrenan con grandes colecciones de textos en las que el inglés suele estar bien representado. Por eso el texto en inglés se tokeniza a menudo de forma eficiente, mientras que otros idiomas pueden necesitar más tokens para el mismo significado. Los idiomas con muchas palabras compuestas, como el alemán, o con una flexión rica pueden resultar bastante más caros por frase.

Para una empresa que trabaja en varios idiomas, esto tiene dos implicaciones:

• Presupuesta por idioma. Un asistente de soporte que responde en español puede usar más tokens por conversación que el mismo asistente en inglés.
• Prueba con contenido local real. No extrapoles a partir de muestras en inglés.

Ejemplo práctico: de palabras a coste

Supón un asistente interno que resume informes. Todas las cifras son supuestos de ejemplo.

• Longitud del informe: 3.000 palabras en inglés, es decir, unos 4.000 tokens.
• Instrucciones: 300 tokens.
• Resumen: 250 palabras, es decir, unos 330 tokens.
• Volumen: 400 informes al mes.

Entrada por solicitud: unos 4.300 tokens. Salida: unos 330 tokens.

Con precios de ejemplo de 1,00 € por millón de tokens de entrada y 4,00 € por millón de tokens de salida:

• Entrada: 4.300 × 1,00 € ÷ 1.000.000 = 0,0043 €
• Salida: 330 × 4,00 € ÷ 1.000.000 = 0,00132 €
• Por informe: unos 0,0056 €
• Al mes: unos 2,25 €

Aquí el coste es pequeño, pero el mismo cálculo aplicado a un chat de clientes con mucho volumen, o a un agente que hace muchas llamadas por tarea, llega rápido a cantidades mayores. Por eso merece la pena medir los tokens pronto. Para reducir el recuento, consulta cómo reducir los costes de API de LLM.

Cómo contar los tokens con precisión

• Herramientas del proveedor: la mayoría ofrece un tokenizador, un endpoint de recuento de tokens o un entorno de pruebas que muestra los recuentos.
• Respuestas de la API: cada respuesta suele incluir los tokens de entrada y salida usados. Registrarlos es la forma más fiable de conocer tu consumo real.
• Bibliotecas de tokenizadores de código abierto: para algunas familias de modelos, el tokenizador está disponible como biblioteca que puedes ejecutar en local.

Para planificar bastan las reglas generales. Para presupuestar y supervisar, usa recuentos reales.

Ideas equivocadas habituales

• «Un token es una palabra». A menudo, pero no siempre. Muchas palabras son varios tokens, y los espacios y la puntuación cuentan.
• «Solo cuenta mi pregunta». Los prompts de sistema, el historial y los documentos cuentan como entrada en cada solicitud.
• «Una ventana de contexto mayor lo resuelve todo». Aumenta la capacidad, no el enfoque, y encarece el uso.
• «Los recuentos de tokens son iguales en todos los modelos». Cada tokenizador es distinto.
• «Los prompts más cortos siempre son mejores». Quitar contexto necesario ahorra tokens, pero puede costar más en malos resultados y correcciones.

Lo esencial

Los tokens son la moneda de los LLM: fijan el precio, la capacidad y la velocidad. Estima con reglas generales, mide con muestras reales y recuerda que la entrada incluye todo lo que envías, no solo las palabras del usuario. Para ver cuánto costarían tus propios volúmenes, prueba la calculadora de coste de API de LLM, y lee la guía sobre los precios de las API de LLM para ver el panorama completo de cómo facturan los proveedores.