Un token es una unidad que un modelo de lenguaje utiliza para procesar una entrada o producir una salida. No coincide necesariamente con una palabra visible. Según el idioma, el modelo y el texto, una palabra puede convertirse en varias piezas, y un signo, un número o un fragmento de código puede ocupar tokens propios.
Esta diferencia importa porque las aplicaciones suelen establecer límites, precios y métricas en tokens. Contar palabras sirve como estimación muy aproximada, pero no permite saber con exactitud cuánto contexto consumirá una petición.
Qué hace la tokenización
La tokenización transforma una cadena de texto en identificadores que el modelo puede procesar. El método depende del tokenizador asociado al modelo. Puede reconocer fragmentos frecuentes y dividir otros menos habituales en varias unidades. Dos modelos distintos pueden producir recuentos diferentes para la misma frase.
La puntuación, los espacios, los emojis, las URLs y los números también afectan al resultado. El código puede fragmentarse de una manera especialmente distinta al lenguaje natural. Por eso no existe una equivalencia fija entre caracteres, palabras y tokens.
Entrada y salida consumen presupuesto
En una petición se cuentan los tokens de las instrucciones, la conversación, los documentos añadidos y la pregunta. La respuesta generada añade tokens de salida. El límite de contexto debe contener ambas partes según las reglas del modelo y de la API utilizada.
Una conversación que parece corta para una persona puede acumular muchos mensajes. Si además se añaden resultados recuperados o instrucciones extensas, la aplicación puede tener que resumir, recortar o rechazar la petición antes de generar.
Por qué una palabra no equivale a un token
Una frase sencilla en español puede dividirse en unidades que no coinciden con sus palabras. Un término raro, una dirección web o un identificador largo puede ocupar varias. Un texto con espacios y signos repetidos también puede consumir más de lo que su longitud visual sugiere.
El idioma influye porque los tokenizadores se comportan de manera diferente con morfología, acentos y frecuencia de palabras. No es correcto multiplicar siempre el número de palabras por una constante y tratar el resultado como una medición exacta.
Tokens y coste de una API
Muchos servicios calculan el coste a partir de tokens de entrada y salida, con precios que pueden ser distintos. El coste real depende del modelo, la cantidad de peticiones, el contexto repetido y la longitud de las respuestas. Reducir instrucciones duplicadas o recuperar solo los fragmentos necesarios puede ser más eficaz que limitar la respuesta a ciegas.
Una aplicación debería registrar recuento, latencia y errores de forma agregada, evitando guardar datos personales completos solo para medir consumo. Los límites de presupuesto deben aplicarse en el backend.
Tokens y calidad de respuesta
Más tokens no implican automáticamente una respuesta mejor. Un contexto largo puede contener información irrelevante o contradictoria. La calidad depende de qué unidades entran, cómo se ordenan, qué instrucciones las acompañan y cómo se evalúa la salida.
Al resumir una conversación para ahorrar tokens, se puede perder una condición importante. La aplicación debe conservar datos críticos de forma estructurada en lugar de confiar en que un resumen textual mantendrá todos los detalles.
Cómo medir en un sistema real
Usa el tokenizador correspondiente al modelo y mide por tipo de petición: preguntas cortas, historiales largos, documentos recuperados y respuestas extensas. Observa percentiles, no solo una media, porque unas pocas consultas grandes pueden dominar coste y latencia.
Si cambias de modelo, repite la medición. El mismo texto puede consumir un número distinto de tokens y el límite de contexto puede cambiar.
Por qué medir tokens importa en una aplicación real
El recuento permite anticipar límites, controlar coste y diseñar la ventana de contexto, pero no sustituye la evaluación de respuestas. Mide con el tokenizador real, define presupuestos y conserva solo la información que la tarea necesita. Una cifra comprensible es útil; una estimación presentada como exacta puede llevar a decisiones equivocadas.
Tokenización en español, código y números
Los acentos y las formas flexionadas no tienen por qué ocupar el mismo número de unidades que sus equivalentes en otro idioma. Una URL, un identificador de pedido o una dirección de correo puede dividirse en piezas poco intuitivas. En código, nombres, operadores y espacios siguen las reglas del tokenizador del modelo, no las de un contador de palabras.
Por eso una aplicación que recibe texto de usuarios debería medir el recuento real antes de enviarlo, especialmente si admite documentos largos o conversaciones acumuladas. Un límite de caracteres puede servir como primera barrera, pero no sustituye el límite de tokens que aplicará el modelo.
Presupuesto de una petición
El presupuesto debe contemplar instrucciones fijas, historial, documentos, salida máxima y posibles reintentos. Una respuesta que alcanza el límite puede quedar incompleta; una entrada que lo supera puede ser recortada o rechazada. La interfaz debería comunicar el problema de manera controlada en lugar de presentar una salida truncada como si fuera definitiva.
También conviene agrupar métricas por endpoint y tipo de tarea. La extracción de campos, un chat con historial y una clasificación corta tienen perfiles diferentes, aunque usen el mismo modelo.
Medir tokens importa en producción
Usa el tokenizador compatible con el servicio, registra percentiles de entrada y salida y define un presupuesto por usuario o proceso cuando el coste lo requiera. Si cambia el modelo, repite las mediciones: el recuento y los límites pueden variar.