Glosario de tokens de IA

Un token es la unidad más pequeña que un modelo de lenguaje lee y genera. En lugar de procesar caracteres individuales o palabras completas, los LLM modernos dividen el texto en fragmentos de subpalabra y asignan a cada fragmento un ID entero. El modelo opera después por completo sobre esos ID.

En inglés, un token equivale aproximadamente a 4 caracteres o a unas tres cuartas partes de una palabra. Palabras cortas y comunes como “the”, “is” e “in” suelen ser un único token cada una. Las palabras más largas o poco frecuentes se dividen en dos o más fragmentos. La puntuación, los espacios en blanco y los números se cuentan cada uno por separado, y el código o las escrituras no latinas pueden tokenizarse de forma más costosa que la prosa en inglés.

Los proveedores de API facturan por token tanto la entrada (lo que envías) como la salida (lo que genera el modelo). Esto significa que un texto más largo cuesta más y usa más de la ventana de contexto del modelo. Entender los tokens es el primer paso para predecir y controlar los costos de la API.

Un tokenizador es el algoritmo o programa encargado de convertir texto sin procesar en una secuencia de tokens (y viceversa). Construye un vocabulario fijo de fragmentos de subpalabra durante el entrenamiento y, en el momento de la inferencia, divide cada nueva entrada según ese vocabulario y asigna a cada fragmento un ID entero único.

Cada familia de modelos incluye su propio tokenizador y su propio vocabulario. Esto importa porque el mismo texto puede producir distintos conteos de tokens según el modelo que uses. Una frase que se tokeniza en 50 tokens con GPT-4o podría producir 47 o 55 tokens con Claude o Gemini. La diferencia proviene del tamaño del vocabulario, las reglas de fusión aprendidas durante el entrenamiento y cómo el tokenizador maneja los espacios en blanco y los caracteres especiales.

En textos en inglés, los conteos entre los principales proveedores suelen situarse dentro de un 5 % a un 15 % entre sí. La diferencia se amplía en código, escrituras no latinas y contenido muy formateado. Por eso las calculadoras de tokens orientadas a modelos que no son de OpenAI suelen usar un factor de escala estimado en lugar del tokenizador exacto del modelo.

La codificación por pares de bytes (BPE, por sus siglas en inglés) es un algoritmo inspirado en la compresión que construye un vocabulario de subpalabras fusionando de forma iterativa el par adyacente de unidades más frecuente. El proceso parte de bytes o caracteres individuales y aplica miles de operaciones de fusión hasta que el vocabulario alcanza un tamaño objetivo (por ejemplo, 50 000 o 100 000 entradas).

El resultado es un vocabulario en el que las palabras y fragmentos de palabra comunes en inglés obtienen cada uno su propio token, mientras que las palabras raras se dividen en fragmentos más pequeños que igual aparecen en el vocabulario. Esto equilibra dos objetivos en tensión: un vocabulario pequeño es eficiente, pero dividir cada palabra en caracteres hace que las secuencias sean muy largas y costosas. BPE se sitúa en un punto intermedio, manteniendo las secuencias manejables mientras maneja cualquier palabra, incluso una que nunca apareció en el entrenamiento.

Los modelos GPT de OpenAI usan BPE a través de su biblioteca tiktoken. Muchos otros modelos también usan variantes de BPE, incluidos algunos modelos Llama y Mistral. Las reglas de fusión y el vocabulario específicos varían entre implementaciones, razón por la cual un mismo texto produce distintos conteos en distintos modelos aunque ambos usen BPE.

SentencePiece es una biblioteca de tokenización desarrollada por Google que adopta un enfoque distinto al de BPE al estilo tiktoken. En lugar de requerir un paso de pretokenización específico del idioma (como dividir por espacios antes de aplicar las reglas de fusión), SentencePiece trata toda la entrada como un flujo sin procesar de caracteres Unicode, incluidos los espacios. Los espacios se representan mediante un marcador especial similar a un guion bajo que puedes ver en la salida tokenizada (a menudo mostrado como el carácter “_” o un símbolo Unicode especial).

Este diseño hace que SentencePiece sea independiente del idioma. Maneja el japonés, el chino, el árabe y otras escrituras que no usan espacios como límites de palabra con la misma naturalidad que el inglés. Admite dos algoritmos principales por debajo: BPE y tokenización por modelo de lenguaje unigrama.

Modelos como Gemini, Llama, T5 y muchos modelos multilingües usan SentencePiece. Como maneja los espacios en blanco de forma distinta, la misma frase en inglés puede tokenizarse con un conteo ligeramente diferente al que tendría con BPE de tiktoken, incluso con un tamaño de vocabulario similar. Esta es una de las razones principales por las que los conteos de tokens no son intercambiables entre proveedores.

tiktoken es la biblioteca de tokenizador BPE rápida y de código abierto publicada por OpenAI. Es lo que usa la propia API de OpenAI para contar tokens a efectos de facturación, así que usar tiktoken en una calculadora produce conteos exactos para los modelos de OpenAI en lugar de estimaciones.

tiktoken incluye varias codificaciones con nombre que corresponden a distintas generaciones de modelos. Las dos más importantes son cl100k_base, que cubre GPT-3.5 Turbo y los modelos de la serie GPT-4, y o200k_base, que cubre GPT-4o, GPT-5 y los modelos de razonamiento de la serie o. El número en el nombre se refiere al tamaño aproximado del vocabulario: 100 000 y 200 000 tokens respectivamente. El vocabulario más grande permite que la codificación más nueva represente más elementos en un solo token, lo que suele producir conteos de tokens ligeramente más bajos para el mismo texto.

Esta calculadora de tokens ejecuta codificaciones compatibles con tiktoken directamente en tu navegador mediante una compilación WebAssembly, de modo que tu texto nunca sale de tu dispositivo y los conteos para los modelos de OpenAI son exactos.

La ventana de contexto es el número máximo de tokens que un modelo puede mantener en su “memoria de trabajo” a la vez. Cubre todo lo que hay en una sola solicitud: el mensaje de sistema, el historial de la conversación, cualquier documento que adjuntes, el mensaje del usuario y la salida del modelo. Si el total supera la ventana, debes acortar la entrada o la API devuelve un error.

El tamaño de las ventanas de contexto ha crecido rápidamente entre generaciones. El primer GPT-3 tenía una ventana de 4096 tokens. Los modelos de vanguardia actuales admiten ventanas medidas en cientos de miles o incluso millones de tokens, lo que hace viable pasar bases de código o libros enteros en una sola solicitud.

Una ventana de contexto más grande te permite pasar más documentos, mantener conversaciones más largas y dar al modelo más ejemplos con los que trabajar. La contrapartida es el costo: más tokens de entrada significan una factura más alta. También hay evidencia de que los contextos muy largos pueden reducir la calidad de la atención a la información situada en medio de un prompt, un fenómeno a veces llamado “perdido en el medio”. Mantener los prompts tan concisos como sea necesario suele ser una buena práctica tanto para el costo como para la calidad de la salida.

Los proveedores de API dividen la facturación de tokens en dos categorías. Los tokens de entrada (también llamados tokens de prompt) son todo lo que envías al modelo en una solicitud: el mensaje de sistema, todo el historial de la conversación, cualquier documento o contexto que adjuntes y el mensaje más reciente del usuario. Los tokens de salida (también llamados tokens de finalización) son los tokens que el modelo genera en su respuesta.

Se cobran por separado porque generar tokens es computacionalmente más costoso que leerlos. Los tokens de salida suelen costar varias veces más por millón que los de entrada, aunque la proporción exacta varía según el proveedor y el modelo.

La fórmula del costo de una solicitud es sencilla:

Costo total = (tokens de entrada / 1,000,000) x precio de entrada por millón + (tokens de salida / 1,000,000) x precio de salida por millón

Al estimar los costos de una aplicación, debes tener en cuenta ambos lados. Los costos de entrada predominan en aplicaciones con mensajes de sistema largos o grandes contextos recuperados. Los costos de salida predominan en tareas que producen respuestas extensas, como la redacción de documentos o la generación de código. La calculadora de tokens te permite establecer por separado las longitudes esperadas de entrada y salida para poder modelar ambas.

La caché de prompts es una función que ofrecen varios proveedores (incluidos Anthropic y OpenAI) que te permite marcar una parte de tu prompt como almacenable en caché. Cuando la API vuelve a ver el mismo prefijo en caché en una solicitud posterior, cobra un precio significativamente reducido por esos tokens en lugar de procesarlos a costo completo. Los aciertos de caché suelen costar una fracción del precio normal de entrada, a menudo entre un 10 % y un 25 % de la tarifa estándar, según el proveedor.

Algunos proveedores cobran un pequeño recargo por escribir una nueva entrada en la caché (ya que almacenar el estado clave-valor tiene un costo), pero este costo de escritura suele recuperarse rápidamente si reutilizas el prefijo más de una o dos veces.

La caché de prompts es más valiosa cuando un prefijo grande y estático aparece en muchas solicitudes: un mensaje de sistema largo, un documento de referencia, un archivo de código o un conjunto de ejemplos de few-shot. Si tu aplicación siempre antepone un documento de 10 000 tokens antes de cada pregunta del usuario, almacenar ese documento en caché puede reducir sustancialmente los costos de entrada por solicitud.

Es menos útil para cargas de trabajo en las que el prompt es único cada vez o donde el prefijo almacenable en caché cambia con frecuencia. Las cachés también expiran tras un periodo de inactividad (los TTL exactos varían según el proveedor), por lo que las solicitudes muy poco frecuentes podrían no beneficiarse.

Una API de lote es un modo de procesamiento asíncrono en el que envías muchas solicitudes a la vez (normalmente como un archivo JSONL) y recibes los resultados más tarde, dentro de una ventana de tiempo prometida que suele llegar hasta 24 horas. Como el proveedor puede programar tus solicitudes durante capacidad de horas valle, ofrece un descuento sustancial, a menudo de alrededor del 50 % en comparación con la API síncrona en tiempo real.

El procesamiento por lotes encaja bien con cargas de trabajo que no necesitan una respuesta instantánea: evaluar un conjunto de datos grande, generar descripciones para un catálogo de productos, clasificar miles de tickets de soporte, ejecutar una suite de pruebas de regresión frente a un modelo nuevo o procesar grandes volúmenes de documentos durante la noche.

Encaja mal con cualquier cosa orientada al usuario que necesite una respuesta en tiempo real, o con flujos en los que cada paso depende de la salida del anterior (ya que podrías tener que esperar muchas horas entre pasos).

Al presupuestar cargas de trabajo por lotes, reducir a la mitad el precio por token puede marcar una diferencia significativa a gran escala. Si procesas millones de tokens al día en tareas no urgentes, dirigirlas a través de la API de lote en lugar del endpoint síncrono es una de las formas más simples de reducir los costos de infraestructura.

Un presupuesto de tokens es un tope planificado sobre cuántos tokens puede usar una tarea, solicitud o aplicación determinada. Establecer un presupuesto cumple dos propósitos: mantiene los costos predecibles y evita que las solicitudes superen inadvertidamente la ventana de contexto del modelo.

Un presupuesto de tokens práctico suele cubrir tres áreas: el mensaje de sistema y el contexto estático (fijo por despliegue), el contexto dinámico añadido por solicitud (documentos recuperados, historial de conversación, entrada del usuario) y la longitud máxima de salida (controlada mediante el parámetro max_tokens). Sumar las tres y comprobarlas frente al límite de contexto del modelo te indica si tu diseño encajará.

Las técnicas habituales para mantenerse dentro de un presupuesto incluyen acortar los mensajes de sistema, limitar el número de fragmentos recuperados en las canalizaciones RAG, truncar o resumir turnos de conversación antiguos y limitar el parámetro max_tokens para evitar salidas descontroladas.

Estimar tu presupuesto antes de construir es mucho más fácil que depurar un exceso en producción. Usa la calculadora de tokens para medir tus prompts y ver exactamente en qué punto se encuentra tu conteo de tokens antes de comprometerte con un modelo o un nivel de precios.