Cómo Cuentan Tokens los LLM: Guía para Desarrolladores

Cuando los desarrolladores comienzan a trabajar con APIs de grandes modelos de lenguaje, una pregunta surge casi de inmediato: «¿Qué longitud es demasiada?» Piensan en palabras, párrafos o caracteres —pero el modelo piensa en tokens. Entender qué son los tokens, cómo se cuentan y por qué importa el recuento es una de las cosas más útiles en la práctica que puedes aprender antes de construir algo serio sobre un LLM.

Puedes usar el Contador de Tokens de BrowseryTools —gratis, sin registro, todo se queda en tu navegador— para contar tokens de cualquier texto antes de enviarlo a una API.

¿Qué Es un Token? (No Es una Palabra, Ni un Carácter)

Un token es la unidad fundamental de texto que procesa un modelo de lenguaje. No es una palabra. No es un carácter. Es un fragmento de texto que el tokenizador del modelo ha aprendido a tratar como una unidad única —y ese fragmento puede ser desde un único carácter hasta un fragmento de palabra de varios caracteres o una palabra común completa.

Aquí tienes algunos ejemplos de cómo una oración podría dividirse en tokens por un tokenizador de la familia GPT:

"Hello, world!"
→ ["Hello", ",", " world", "!"]  — 4 tokens

"unbelievable"
→ ["un", "believ", "able"]  — 3 tokens

"ChatGPT"
→ ["Chat", "G", "PT"]  — 3 tokens

"2026-03-22"
→ ["2026", "-", "03", "-", "22"]  — 5 tokens

Observa cómo las palabras cortas comunes como «Hello» se mapean a un solo token, mientras que las palabras más largas o inusuales se dividen en múltiples tokens. La puntuación, los números y los caracteres especiales son a menudo sus propios tokens. El tokenizador no se divide simplemente en espacios o signos de puntuación —usa un vocabulario aprendido de unidades de sub-palabras para lograr el mejor equilibrio entre el tamaño del vocabulario y la eficiencia de representación.

Cómo Funcionan los Tokenizadores: Byte-Pair Encoding

La mayoría de los LLM modernos —GPT-4, Claude, Gemini, Llama— usan una variante de Byte-Pair Encoding (BPE) o un algoritmo estrechamente relacionado llamado SentencePiece. El BPE se desarrolló originalmente para compresión de datos; se adaptó para el PLN porque resuelve elegantemente el problema del vocabulario abierto.

El proceso de entrenamiento de BPE comienza con caracteres individuales (o bytes) como vocabulario base. Luego encuentra repetidamente el par de símbolos que co-ocurre con más frecuencia en el corpus de entrenamiento y los fusiona en un nuevo símbolo único. Después de miles de estas fusiones, el vocabulario resultante contiene palabras comunes como tokens únicos, prefijos y sufijos comunes como tokens, y palabras raras como secuencias de tokens más pequeños. El tamaño del vocabulario final es típicamente de 32.000 a 100.000 tokens.

Esto significa que la tokenización de cualquier texto dado depende enteramente del vocabulario específico con el que se entrenó ese modelo. GPT-4, Claude y Gemini usan tokenizadores diferentes —el mismo texto puede tokenizarse con recuentos distintos en cada modelo. Nunca asumas que un recuento de tokens medido para un modelo se aplica a otro.

La Regla Aproximada de «750 Palabras por 1000 Tokens»

A menudo verás la aproximación «1000 tokens ≈ 750 palabras» citada para texto en inglés. Esta es una heurística razonable para prosa típica —entradas de blog, artículos, documentación. Proviene de la observación de que en un corpus equilibrado en inglés, la longitud media del token es de unos 4-5 caracteres, y la palabra inglesa media tiene unos 5 caracteres más un espacio. Así que una palabra se mapea a aproximadamente 1,3 tokens de promedio.

Pero «regla aproximada» es el encuadre correcto —se rompe rápidamente en la práctica:

• El código tokeniza más densamente — Los lenguajes de programación usan muchas palabras clave cortas, operadores e identificadores que a menudo son tokens únicos. Un bloque de Python puede tokenizarse con menos tokens por carácter que la prosa en inglés.
• Las URLs y cadenas técnicas son costosas — Una URL larga como https://api.example.com/v2/users/84219/preferences?include=notifications puede tokenizarse en más de 20 tokens a pesar de parecer corta en pantalla.
• Los números son sorprendentemente caros — Cada dígito en un número largo es a menudo un token separado. El número «1738371600» puede convertirse en 5-7 tokens.
• Espacios en blanco repetidos y formato — JSON con sangría de impresión bonita, tablas en Markdown y código con anidamiento profundo añaden tokens del espacio en blanco.

Idiomas No Ingleses: Árabe, Chino y la Diferencia en el Costo de Tokens

La heurística de 750 palabras por 1000 tokens es una heurística para el inglés. Para otros idiomas, la proporción puede ser dramáticamente diferente —y esto tiene implicaciones reales de costo para las aplicaciones multilingües.

El árabe y el hebreo usan morfología de raíz y patrón, donde una sola raíz genera docenas de formas derivadas a través de prefijos, sufijos y cambios vocálicos internos. Palabras como «وسيستخدمونها» (ellos la usarán) son palabras ortográficas únicas pero pueden tokenizarse en 5-8 tokens porque el vocabulario de BPE se entrenó predominantemente con datos en inglés y no tiene estas formas árabes como tokens únicos.

El chino y el japonés tienen un desafío diferente. Los caracteres son logográficos —cada carácter es una unidad con significado— pero el vocabulario de tokens cubre caracteres únicos comunes y algunas palabras comunes de varios caracteres. El texto chino típicamente produce entre 1,5 y 2 veces más tokens por «equivalente de palabra» que el inglés. El japonés, con su mezcla de hiragana, katakana y kanji, puede ser aún más alto.

Una implicación práctica: si estás construyendo una aplicación para árabe, chino u otros idiomas con escritura no latina, tus estimaciones de costo derivadas de las pruebas en inglés infraestimará significativamente los costos reales de API. Mide siempre los recuentos de tokens con tu contenido real usando el Contador de Tokens de BrowseryTools o una biblioteca de tokenizadores antes de hacer proyecciones de presupuesto.

Límites de la Ventana de Contexto: Por Qué Superarlos Rompe Todo

Cada LLM tiene una ventana de contexto —el número máximo de tokens que puede procesar en una sola solicitud, contando tanto tu entrada como la salida del modelo. A principios de 2026:

• GPT-4o — 128 000 tokens
• Claude 3.5 Sonnet — 200 000 tokens
• Gemini 1.5 Pro — 1 000 000 tokens
• Llama 3.1 70B — 128 000 tokens

Si tu entrada supera el límite de la ventana de contexto, la API devolverá un error —la solicitud simplemente falla. No hay degradación gradual por defecto; debes manejar esto en la lógica de tu aplicación. De forma más sutil, incluso dentro de la ventana de contexto, existe un fenómeno llamado el problema de «perdido en el medio»: los modelos tienden a recordar mejor la información al principio y al final de su contexto que la información enterrada en el medio. Una ventana de contexto de 200 K no significa que cada token sea igualmente bien atendido.

Para las aplicaciones de chat, la ventana de contexto se llena a medida que las conversaciones crecen. Después de suficientes turnos, debes truncar los mensajes anteriores, resumirlos o alcanzar el límite y fallar. Conocer tu recuento de tokens en cada paso es lo que te permite tomar esa decisión de forma proactiva.

Implicaciones del Diseño de Prompts

La conciencia sobre los tokens cambia la forma en que escribes los prompts. Algunas implicaciones concretas:

• Los prompts de sistema se acumulan en cada solicitud — Un prompt de sistema de 500 tokens cuesta 500 × el número de solicitudes × el precio de entrada. Con 10 000 solicitudes diarias, reducir tu prompt de sistema de 500 a 300 tokens ahorra dinero real cada mes.
• Los ejemplos de few-shot son costosos pero efectivos — Incluir 3 ejemplos en tu prompt puede añadir 300-500 tokens. Mide si esa mejora de calidad vale el costo en comparación con ajustar el modelo una sola vez.
• La longitud de salida es controlable — Usa max_tokens para limitar la salida del modelo. Añade instrucciones explícitas en tu prompt: «Responde en menos de 100 palabras.» Los modelos generalmente siguen bien las instrucciones de longitud de salida, lo que reduce directamente los costos de tokens de salida.
• El formato JSON añade sobrecarga — Si usas salida estructurada (modo JSON), las comillas, corchetes y nombres de clave añaden tokens además de tus valores de datos reales. Una respuesta con 5 campos cortos puede tener fácilmente un 40% de tokens de formato en exceso.

Cuenta los Tokens Antes de Enviar

El mejor hábito que puedes desarrollar al trabajar con APIs de LLM es contar tus tokens antes de comprometerte con una arquitectura o ir a producción. Pega tu prompt de sistema, un mensaje de usuario representativo y cualquier contexto que planees incluir en el Contador de Tokens de BrowseryTools. Verás de inmediato si tu diseño está bien dentro de la ventana de contexto o peligrosamente cerca de ella —y tendrás los números necesarios para estimar los costos con precisión.