“Tokens del prompt” suele significar lo mismo. Sin embargo, el nombre puede inducir a error, porque el prompt puede incluir material añadido por la aplicación o la API.
La solicitud completa, no solo tu mensaje
Imagina que escribes “Resume el informe más reciente” en un cuadro de chat. Esa oración es una parte de la entrada. La aplicación también podría enviar:
- instrucciones que establecen el rol y el comportamiento del asistente;
- mensajes anteriores del usuario y del asistente;
- el informe en sí o fragmentos recuperados de él;
- definiciones de las herramientas que el modelo puede invocar;
- resultados devueltos por una herramienta; y
- marcadores que identifican roles, límites entre mensajes o el punto donde debe comenzar la generación.
Todas esas partes pueden convertirse en tokens de entrada. El conjunto exacto depende de la aplicación, la API, el modelo y las funciones habilitadas.
Esto establece un límite preciso para los tokens de entrada: se definen por su función dentro de una solicitud. El texto que el modelo generó como salida en un turno puede convertirse en entrada en el siguiente cuando la aplicación lo envía de nuevo como historial de la conversación.
Cómo se convierte una solicitud en tokens de entrada
El recorrido desde una interfaz hasta un modelo es el siguiente:
system instructions ─┐
conversation history ├─> request formatting ─> tokenizer ─> input token IDs ─> model
documents and tools ┤
current message ─────┘Primero, la aplicación reúne el contexto de la solicitud. Una llamada básica a una API puede contener solo un prompt. Un asistente en producción puede añadir instrucciones, historial, documentos recuperados, esquemas de herramientas y otro contenido.
A continuación, el servicio da formato a ese material para el modelo seleccionado. Los modelos de chat no reciben una transcripción visual con burbujas de mensajes de colores. Reciben una secuencia creada mediante una plantilla de chat o un formato interno equivalente. La documentación de la API de chat de vLLM hace explícito este paso: los mensajes estructurados se convierten en un prompt de texto con la plantilla de chat del modelo.
Después, un tokenizador convierte la secuencia formateada en identificadores de tokens. Como muestra la referencia del tokenizador de Hugging Face, esto puede implicar normalizar, dividir el texto en fragmentos, asignar identificadores a esos fragmentos y añadir tokens especiales. Como los modelos pueden utilizar tokenizadores y plantillas diferentes, el mismo texto visible no garantiza el mismo recuento de entradas.
Por último, el modelo procesa esa secuencia de tokens y comienza a generar. Los metadatos de uso de la respuesta indican cómo contabilizó el proveedor la solicitud.
Ejemplo práctico
Supón que una aplicación informa del siguiente registro ilustrativo de una solicitud:
- Instrucciones del sistema: 36 tokens
- Definiciones de herramientas: 74 tokens
- Historial de la conversación: 160 tokens
- Mensaje actual del usuario: 12 tokens
- Formato de mensajes y tokens especiales: 15 tokens
La solicitud contiene 297 tokens de entrada, aunque el mensaje actual solo contiene 12.
Ahora supón que la respuesta contiene 60 tokens generados. Esos 60 son tokens de salida para esta solicitud. En el siguiente turno, la aplicación puede incluir esa respuesta en el historial. El mismo texto contribuye entonces al recuento de entrada de la siguiente solicitud.
El almacenamiento en caché cambia el procesamiento y el precio de las entradas repetidas, no su función conceptual. Si 200 de los 297 tokens de entrada provienen de un prefijo reutilizable, un proveedor puede informar de ellos o cobrar por ellos por separado como entrada almacenada en caché. Siguen siendo contexto proporcionado al modelo. Por ejemplo, Anthropic divide las solicitudes almacenadas en caché entre varios campos de uso, mientras que OpenAI muestra la entrada almacenada en caché como una categoría de entrada distinta. Lee siempre las definiciones actuales de los campos en lugar de asumir que un campo llamado input_tokens representa el total completo.
Cómo contar los tokens de entrada
Para un borrador aproximado, un tokenizador adaptado al modelo puede estimar el texto sin formato. No puede reproducir de forma fiable el recuento completo de la API a menos que también aplique la misma plantilla de mensajes, el mismo formato de herramientas, los mismos tokens especiales, la codificación de medios y las adiciones del proveedor.
Para una solicitud completa, utiliza el endpoint del proveedor para contar tokens cuando esté disponible. El endpoint de recuento de tokens de Anthropic acepta mensajes, prompts del sistema, herramientas, imágenes y archivos PDF. La guía de tokens de Google también distingue entre los recuentos de entrada previos a la solicitud y el uso devuelto después de la generación. La guía de OpenAI para contar tokens señala que la estructura de la solicitud y las entradas no textuales pueden afectar al recuento completo.
Considera el recuento previo a la solicitud como una estimación de capacidad y coste. Después de la solicitud, conserva la respuesta de uso del proveedor como registro de cómo se contó y facturó realmente esa llamada.
Por qué importan los tokens de entrada
Coste
Muchas API cobran por separado la entrada, la entrada almacenada en caché y la salida. Un registro de costes útil es:
input cost =
uncached input tokens × uncached input rate
+ cached input tokens × cached input rateLas tarifas y categorías cambian, así que utiliza la página de precios actual del proveedor en lugar de copiar un precio en la lógica de la aplicación. Las instrucciones largas del sistema, las definiciones repetidas de herramientas, los fragmentos recuperados grandes y el historial de chat cada vez más extenso pueden hacer que la entrada sea la parte más costosa de una carga de trabajo.
Contexto disponible
Los tokens de entrada ocupan espacio en el contexto del modelo. Una mayor cantidad de entradas puede dejar menos espacio para la respuesta, según las reglas de límite del modelo y de la API. Por tanto, enviar contexto adicional no equivale a disponer de capacidad gratuita: compite con otras instrucciones, evidencias y turnos de conversación por la atención y el presupuesto de tokens del modelo.
Tiempo de respuesta
El modelo debe procesar la entrada antes de poder producir el primer token de salida. Por lo general, las entradas más grandes requieren más trabajo de procesamiento del prompt. Reutilizar un prefijo almacenado en caché que cumpla los requisitos puede reducir ese trabajo, pero el comportamiento y los beneficios de la caché dependen del proveedor.
Medición
Los recuentos de tokens de entrada ayudan a comparar solicitudes de una forma más útil que los caracteres o las palabras. Pueden revelar un esquema de herramientas demasiado grande, un sistema de recuperación que envía demasiados fragmentos o un historial de conversación que crece en cada turno.
Errores comunes
“Los tokens de entrada son las palabras que escribí”
Tus palabras son solo la parte visible. La solicitud dirigida al modelo también puede contener instrucciones, historial, documentos, herramientas, medios y formato.
“Una palabra equivale a un token de entrada”
Un token puede ser una palabra, parte de una palabra, un signo de puntuación u otra unidad específica del modelo. Los límites de los tokens varían según el tokenizador. ¿Qué es un token en IA? explica esa unidad subyacente.
“Los tokens almacenados en caché ya no son tokens de entrada”
Los tokens almacenados en caché son entradas reutilizadas. El almacenamiento en caché puede cambiar la cantidad de cómputo, el precio y los campos de uso, pero el prefijo almacenado en caché sigue aportando contexto a la solicitud.
“Los mensajes del asistente siempre son tokens de salida”
Son tokens de salida cuando se generan. Si un mensaje del asistente se incluye en el historial de una solicitud posterior, es una entrada para esa solicitud posterior. Entrada y salida describen lados de una solicitud, no tipos permanentes de texto.
“Un tokenizador local proporciona el recuento de facturación”
Puede proporcionar un recuento de texto aproximado. Puede omitir marcadores de la plantilla de chat, esquemas de herramientas, archivos adjuntos y formato aplicado por el proveedor. Utiliza el uso posterior a la solicitud de la API para los registros de facturación.
Cómo encajan los tokens de entrada en el sistema general
Los tokens de entrada son la secuencia inicial del modelo para una solicitud. Los tokens de salida se generan después de esa secuencia, mientras que los tokens de entrada almacenados en caché son una subdivisión de la entrada relacionada con el procesamiento y la facturación. En conjunto, estas categorías explican la mayor parte del registro de tokens que aparece en las respuestas de las API y en las páginas de precios.
El hábito importante es medir la solicitud ensamblada. Cuando un mensaje breve del usuario produce un recuento sorprendentemente grande, inspecciona las instrucciones del sistema, el historial, el material recuperado, las herramientas y el formato antes de culpar al tokenizador.
Qué hacer a continuación
Inspecciona una respuesta real de una API e identifica cada campo de uso que contribuye al total de entrada. Después, ejecuta el contador previo a la solicitud del proveedor con la misma solicitud y compara la estimación con el uso final. Si los límites entre tokens no están claros, empieza por ¿Qué es un token en IA?. Continúa con ¿Qué son los tokens de salida?, y luego utiliza Tokens de entrada frente a tokens de salida y de razonamiento para comparar las tres categorías de contabilización.