Tokens: Por qué cuestan dinero y cómo contarlos

Cada interacción con un LLM viene con un impuesto oculto. Envías «enviar» en un prompt, el modelo lo procesa, genera una respuesta y pagas por token. No por palabra. No por carácter. Por token, una unidad que no se mapea limpiamente a nada que puedas ver en tu pantalla.

La mayoría de las personas que construyen con LLMs en realidad no saben qué es un token. Ven un precio por token, lo multiplican y siguen adelante. Luego, sus costos se disparan por razones que no pueden explicar. O chocan con los límites de la ventana de contexto y se preguntan por qué su documento de 8.000 palabras se cortó a mitad del procesamiento.

La tokenización no es solo un detalle de facturación. Es la condición límite de todo lo que construyes con modelos de lenguaje. Entiéndelo y desbloquearás ganancias de eficiencia que se componen en cada sistema que ejecutas. Ignóralo y desperdiciarás dinero, alcanzarás límites en momentos frustrantes y crearás peores productos.

¿Qué es realmente un token?

Un token es la unidad más pequeña con la que trabaja un modelo de lenguaje. No es una palabra. No es un carácter. Es algo intermedio, y los límites exactos cambian dependiendo de qué modelo uses y qué tokenizador codifique tu texto.

Piénsalo así: un tokenizador es una tabla de búsqueda. El texto sin procesar entra por un lado. Por el otro sale una secuencia de enteros: IDs de token. El modelo ve esos enteros, los procesa y genera nuevos enteros de vuelta.

Esto es lo que sucede en la práctica:

• La palabra «hola» = 1 token
• La palabra «desafortunadamente» = 2 tokens (des + afortunadamente)
• El signo de puntuación «.» = 1 token
• Un espacio antes de una palabra = 1 token (generalmente)
• La secuencia «\n\n» (salto de párrafo) = 1 token

Las palabras cortas y comunes se comprimen en tokens individuales. Las palabras más largas o raras se dividen en varios tokens. Los caracteres especiales, números y espacios en blanco tienen sus propias reglas de codificación.

Diferentes modelos usan diferentes tokenizadores. Los modelos GPT de OpenAI (GPT-4o, GPT-4 Turbo) usan el tokenizador cl100k_base. Los modelos Claude de Anthropic usan un tokenizador diferente. Llama 3 70B usa otro más. Esto importa: la misma oración se tokeniza en diferentes longitudes dependiendo del modelo que la procese.

Por qué el recuento de tokens no es intuitivo

Escribes 500 palabras. Asumes que son aproximadamente 500 tokens, quizás 700 si cuentas el formato. Luego lo pasas por un tokenizador y obtienes 820 tokens. O 1.240. O algo completamente diferente.

La discrepancia ocurre porque los tokens no siguen los límites de las palabras. Aquí tienes un ejemplo real:

# Texto de entrada
"La API de ChatGPT no devuelve recuentos de tokens automáticamente." 

# Recuento de palabras: 9
# Recuento de tokens (OpenAI cl100k_base): 13

¿Por qué 13? Desglosémoslo:

• «La» = 1 token
• «ChatGPT» = 1 token
• » API» = 1 token (espacio + palabra)
• «no» = 1 token
• «devuelve» = 1 token
• » recuentos» = 1 token
• «de» = 1 token
• «tokens» = 1 token
• «automáticamente» = 1 token
• «.» = 1 token

Las contracciones se dividen. Los nombres de marca se comprimen. Los espacios en blanco cuentan. Tu suposición instintiva sobre la densidad de tokens no se mantiene.

Esto es importante en la práctica porque:

• No puedes presupuestar costos con precisión sin conocer tu densidad de tokens real
• No puedes diseñar prompts eficientes si adivinas los recuentos de tokens
• Alcanzarás límites de contexto inesperadamente si juzgas mal cuánta información cabe

Ventanas de contexto: Los límites duros

Cada LLM tiene una ventana de contexto: el número máximo de tokens que puede procesar en una sola interacción. Esto incluye tu prompt (tokens de entrada) más la respuesta del modelo (tokens de salida).

La ventana de 200.000 tokens de Claude 3.5 Sonnet es realmente grande. Eso son aproximadamente 150.000 palabras de entrada, un manual técnico completo o un año de correos electrónicos. GPT-4o con 128.000 tokens maneja la mayoría de las tareas a escala de documentos. Llama 3 70B, si lo ejecutas localmente, tiene un máximo de 8.192 tokens, aproximadamente 6.000 palabras.

La ventana de contexto es un techo absoluto. Si tu entrada + la salida deseada excede la ventana, el modelo trunca tu entrada (perdiendo información) o devuelve un error. Sin degradación elegante. Sin búfer de desbordamiento. Alcanzas el límite y tu solicitud falla.

Por eso el conteo de tokens importa antes de construir. Si estás procesando documentos y tu flujo de trabajo agrega prompts del sistema, contexto de recuperación, ejemplos de pocos disparos y el documento en sí, puedes exceder fácilmente la ventana.

Cómo medir tokens de manera eficiente

Tienes tres opciones: contar localmente, usar una llamada a la API o estimar.

Opción 1: Contar localmente usando bibliotecas de tokenizador

Para los modelos de OpenAI, usa el tokenizador oficial:

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4o")
text = "Tu prompt va aquí. Esto es una prueba."
tokens = enc.encode(text)
print(f"Recuento de tokens: {len(tokens)}")
# Salida: Recuento de tokens: 15

Para los modelos Claude de Anthropic, Anthropic proporciona un tokenizador:

import anthropic

client = anthropic.Anthropic()
text = "Tu prompt va aquí. Esto es una prueba."

response = client.messages.count_tokens(
    model="claude-3-5-sonnet-20241022",
    messages=[{"role": "user", "content": text}]
)
print(f"Recuento de tokens: {response.input_tokens}")
# Salida: Recuento de tokens: 15

Ambos enfoques son rápidos y precisos. Úsalos antes de construir cualquier cosa a escala.

Opción 2: Verificar tokens a través de la respuesta de la API

La mayoría de las llamadas a la API devuelven el uso de tokens en la respuesta. Los modelos GPT devuelven el uso de esta manera:

from openai import OpenAI

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hola, ¿cómo estás?"}]
)

print(f"Tokens de entrada: {response.usage.prompt_tokens}")
print(f"Tokens de salida: {response.usage.completion_tokens}")
print(f"Total: {response.usage.total_tokens}")

Claude devuelve la misma información en la respuesta del mensaje. Siempre captura estos datos cuando estés construyendo, es la verdad fundamental de tu uso real.

Opción 3: Estimar (cuando no puedes contar)

Si necesitas una estimación aproximada sin ejecutar código, la regla general es:

• Texto en inglés: 1 token ≈ 0.75 palabras (así que 100 palabras ≈ 133 tokens)
• Código: 1 token ≈ 0.5 palabras (el código se tokeniza de manera menos eficiente)
• JSON: similar al código (los caracteres estructurales agregan sobrecarga)

Esto es aproximado. Si la precisión importa, y debería hacerlo en producción, mide directamente en lugar de estimar.

Diseño de prompts eficientes bajo restricciones de tokens

Dado que los tokens son limitados y los recuentos de tokens no son intuitivos, ¿cómo diseñas prompts que se mantengan dentro del presupuesto y sigan siendo efectivos?

Técnica 1: Priorizar la entrada sobre la verbosidad

Tu prompt del sistema no necesita explicarlo todo. Dale las reglas que importan, elimina el resto.

Enfoque malo (148 tokens):

Eres un analista financiero experto con profundo conocimiento de
estrategias de inversión, tendencias del mercado y gestión de riesgos.
Tu función es analizar datos financieros cuidadosamente y proporcionar
ideas. Siempre debes ser exhaustivo, considerado y preciso
en tu análisis. Piensa paso a paso sobre los datos y proporciona
explicaciones completas para tus conclusiones.

Mejor enfoque (42 tokens):

Analiza datos financieros. Proporciona ideas específicas con evaluación de riesgos.
Sé preciso.

La segunda versión usa un 71% menos de tokens y, de hecho, restringe el modelo de manera más clara. Elimina adjetivos. Elimina reafirmaciones. Conserva instrucciones.

Técnica 2: Usar ejemplos de pocos disparos selectivamente

El prompting de pocos disparos (dar ejemplos) mejora la calidad de la salida, pero cuesta tokens por cada ejemplo que agregas. Úsalos estratégicamente:

• Omite pocos disparos para tareas simples (clasificación, extracción directa). El modelo conoce estos patrones.
• Agrega un ejemplo para tareas de complejidad media (lógica condicional, requisitos de formato). Un ejemplo ≈ 30-50 tokens dependiendo de la longitud.
• Agrega dos ejemplos solo para tareas complejas (casos extremos, patrones raros, requisitos de estilo específicos).

Pruébalo: ejecuta tu prompt sin ejemplos, mide la calidad de la salida. Si la calidad es aceptable, has ahorrado tokens. Agrega ejemplos solo si la salida se degrada notablemente.

Técnica 3: Comprimir el contexto antes de enviarlo

Si estás procesando documentos largos, extrae las partes relevantes antes de pasarlas al modelo. Aquí es donde RAG (Generación Aumentada por Recuperación) ahorra dinero: recuperas solo los pasajes relevantes, no el documento completo.

import anthropic

client = anthropic.Anthropic()

# En lugar de enviar un documento de 50.000 tokens
full_document = "... manual técnico completo ..."

# Extrae la sección relevante primero (tu propia lógica, no LLM)
relevant_section = extract_relevant_section(full_document, query)

# Envía solo la parte relevante
response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[{
        "role": "user",
        "content": f"Contexto: {relevant_section}\n\nPregunta: {query}"
    }]
)

print(response.content[0].text)

Esto funciona porque controlas lo que ve el modelo. La mayor parte del documento permanece en el disco. Solo se procesan los 500 tokens relevantes. Misma respuesta. Costo diferente.

Técnica 4: Reutilizar prompts del sistema en lotes

Si realizas múltiples llamadas a la API con el mismo prompt del sistema, está bien, se te cobrará por los tokens del prompt del sistema cada vez. Pero si tu prompt del sistema es grande, algunos modelos ofrecen «caché de prompts» (Claude con la API de Anthropic cobra un 10% por tokens cacheados en usos posteriores).

Para AlgoVesta, nos estandarizamos en prompts del sistema cortos y reutilizables. En lugar de un prompt de 300 tokens que se envía con cada solicitud, usamos un conjunto de instrucciones de 40 tokens. El ahorro en millones de inferencias es sustancial.

Costos de tokens entre modelos: La comparación

Los tokens son la moneda, pero el precio real por token varía enormemente. Aquí hay precios reales a marzo de 2025:

Claude 3.5 Sonnet es el más barato para la entrada. GPT-4o cuesta un 60% más por token de entrada. GPT-4 Turbo cuesta 3 veces más. Si ejecutas millones de inferencias, la eficiencia de tokens se traduce directamente en ahorros de costos.

Los modelos autoalojados (Llama 3 70B, Mistral, etc.) trasladan el costo a tu infraestructura. Sin facturación por token, pero pagas por el cómputo por adelantado. El punto de equilibrio depende de tu volumen y costos de infraestructura.

Errores comunes de límites de tokens y cómo evitarlos

Error 1: Olvidar que los tokens del prompt del sistema cuentan

Tu contexto disponible no es la ventana completa menos tu entrada. Es la ventana menos tu prompt del sistema menos tu entrada. Un prompt del sistema de 1.000 tokens no es gratis.

Con GPT-4o (ventana de 128.000 tokens), un prompt del sistema de 1.000 tokens + entrada de 2.000 tokens + salida deseada de 4.000 tokens = 7.000 tokens usados. Tienes 121.000 restantes para contenido real. Sigue siendo mucho, pero si usas estas matemáticas descuidadamente a través de muchas capas de prompts, pierdes búfer rápidamente.

Error 2: No tener en cuenta los tokens repetidos

Si estás construyendo un sistema donde un usuario hace varias preguntas seguidas, no asumas que puedes encajar N preguntas en la ventana de contexto. Cada mensaje agrega tokens de metadatos. Cada turno de conversación utiliza tokens para formato y estructura.

En la práctica, una conversación de 10 turnos con mensajes breves podría usar 2 veces más tokens que el texto sin formato solo debido a la sobrecarga de formato.

Error 3: Truncar entradas largas ingenuamente

Si alcanzas un límite de tokens, no cortes simplemente el texto en la posición N y esperes no haber perdido información crítica. Selecciona explícitamente las secciones que necesitas, o usa RAG para mostrar el contenido relevante.

El truncamiento ingenuo causa alucinaciones. El modelo intenta dar sentido a información parcial y fabrica el contexto faltante.

Error 4: Asumir que todos los espacios en blanco son gratuitos

Las líneas en blanco, la indentación y los espacios adicionales se tokenizan. Si estás formateando un prompt con muchos espacios en blanco para facilitar la lectura, estás quemando tokens en caracteres invisibles.

Para prompts dirigidos al usuario, la legibilidad importa. Para prompts internos del sistema, comprime: elimina saltos de línea adicionales, usa un solo espacio, mantén el formato al mínimo.

Flujo de trabajo práctico: Diseño de un sistema eficiente en tokens

Aquí está el enfoque paso a paso que utilizo al construir nuevas funciones de LLM:

Paso 1: Mide tu línea base. Escribe tu prompt de la manera que te parezca lógica. Mide el recuento de tokens. Anótalo.

Paso 2: Identifica qué tokens realmente importan. Prompt del sistema. Entrada. Ejemplos. ¿Qué cubo está consumiendo más? Si son ejemplos, elimínalos. Si es la entrada, necesitas una mejor selección de documentos. Si es el prompt del sistema, recorta las instrucciones.

Paso 3: Establece un presupuesto de tokens y respétalo. Decide la cantidad máxima de tokens que puedes permitirte (costo) o tolerar (latencia). Incluye un búfer para variaciones.

Paso 4: Prueba la calidad con el presupuesto. Ejecuta tu prompt con el límite de tokens y entradas reales. ¿La calidad de la salida se degrada? Si es así, estás cortando demasiado. Si no, corta más.

Paso 5: Monitorea en producción. Registra el uso real de tokens. Si el uso en el mundo real excede consistentemente tu estimación en un 20%, ajusta tu presupuesto. Si queda un 30% por debajo, tienes margen para agregar valor (más contexto, mejores ejemplos, instrucciones más claras).

Haz esto hoy

Elige un prompt o sistema que uses regularmente. Ejecuta el tokenizador oficial de tu modelo sobre él. Obtén el número real. Luego mide el recuento de palabras y calcula tu relación token-palabra. La mayoría de las personas se sorprenderán de que no sea 1:1. Comprender esa diferencia, cómo tu uso real diverge de tu suposición, es donde comienza la eficiencia.

Si estás construyendo un sistema de múltiples mensajes (chat, conversación, recuperación), mide una interacción completa de principio a fin. Observa cómo se ve la sobrecarga de formato en tu flujo de trabajo específico. Ese número no cambia: captúralo una vez, úsalo para cada estimación futura.