Tokenización y ventana de contexto: qué dispara la latencia y los costes de los agentes

La tokenización divide el texto en tokens, las unidades de procesamiento más pequeñas de un LLM; la ventana de contexto es el número máximo de tokens que un modelo puede procesar conjuntamente en cada petición. En los agentes de IA, ambas determinan directamente los costes y la latencia, porque cada paso del agente vuelve a enviar al modelo todo el contexto acumulado. Quien opera agentes en producción controla con estas dos magnitudes la mayor parte de los costes recurrentes y del tiempo de respuesta.

• Los tokens son la unidad de facturación y de procesamiento. Los costes y la latencia dependen del número de tokens, no del número de caracteres. El texto en alemán tiende a generar más tokens por palabra que el inglés.
• La ventana de contexto es finita. Los agentes de varios pasos la llenan rápido, porque cada paso arrastra el prompt de sistema, todo el historial y todos los resultados de las herramientas. Por eso, la cantidad de tokens facturada por ejecución crece de forma desproporcionada.
• Un contexto lleno no es un contexto mejor. Con entradas muy largas, la calidad baja de forma medible (Lost-in-the-Middle). La gestión del contexto es, por tanto, una palanca de costes y de calidad a la vez.

Qué son los tokens y por qué determinan los costes

Un LLM no procesa texto plano, sino tokens. El tokenizador divide el texto de entrada en unidades que suelen corresponder a un fragmento de palabra, una palabra corta completa o un signo de puntuación. El modelo calcula exclusivamente con estos tokens, y todos los proveedores facturan por token, separando la entrada (lo que entra) y la salida (lo que se genera).

En la práctica, dos propiedades son decisivas. Primero, la densidad de tokens depende del idioma: las palabras compuestas largas, las diéresis y las terminaciones flexivas hacen que el mismo contenido necesite a menudo más tokens en alemán que en inglés. Cuántos más depende del tokenizador del modelo, y este puede cambiar incluso dentro del mismo proveedor: según Anthropic, el tokenizador introducido con Claude Opus 4.7 genera para el mismo texto alrededor de un 30 % más de tokens que su predecesor. Para cargas de trabajo en alemán, esto significa: misma tarea, mayor consumo de tokens, costes más altos y una ventana de contexto que se llena antes.

Segundo, la salida suele ser bastante más cara que la entrada. En los modelos disponibles en el mercado, el precio de salida se sitúa normalmente entre tres y seis veces el precio de entrada. En algunos modelos workhorse baratos el recargo es menor; en los modelos frontier se acerca más bien al extremo superior. Por eso, un agente que produce respuestas largas y detalladas resulta desproporcionadamente caro en relación con la cantidad de tokens de salida.

Cómo funciona la ventana de contexto

La ventana de contexto es el número máximo de tokens que un modelo puede ver conjuntamente en una petición, sumando la entrada y la salida generada. Todo lo que el modelo deba tener en cuenta para una respuesta tiene que caber en esta ventana: instrucción de sistema, historial de la conversación, documentos incorporados, definiciones de herramientas y resultados de herramientas.

El tamaño de las ventanas ha crecido mucho en los últimos años. Los modelos frontier actuales ofrecen contextos muy amplios: Claude Opus 5.5 y Gemini 3.1 Pro trabajan con alrededor de 1 millón de tokens, Mistral Large 3 con 256K. Entre los modelos open-weight, Llama 4 Scout (abril de 2025) alcanza hasta 10 millones de tokens (todos los datos, a octubre de 2026). Una ventana más grande desplaza el límite máximo, pero no hace gratis arrastrar contexto. Quedan dos efectos: los costes y la latencia aumentan con la longitud de la entrada, y la calidad de las respuestas se degrada con entradas muy largas.

Crecimiento del contexto en agentes de varios pasos

Una sola llamada de chat no es crítica en cuanto a costes. El problema surge con el patrón agéntico: un agente no resuelve una tarea en una sola llamada, sino en muchos pasos (planificar, llamar a una herramienta, evaluar el resultado, llamar a la siguiente herramienta, etcétera). En cada uno de estos pasos se vuelve a enviar como entrada todo el historial acumulado, porque el modelo no tiene estado y no recuerda nada.

De ahí se deriva el patrón económico central de los agentes: un consumo de tokens que crece de forma desproporcionada. Si el paso 1 tiene todavía 2.000 tokens de entrada, el paso 2 ya 5.000, el paso 3 luego 9.000 y así sucesivamente, el consumo de tokens facturado a lo largo de la ejecución no se suma de forma lineal, sino muy por encima de lo proporcional, porque cada paso arrastra el contexto acumulado de todos los anteriores. Cada salida adicional de una herramienta (una respuesta de API, un documento consultado, un resultado de búsqueda) amplía el contexto de todos los pasos siguientes. Las salidas largas de herramientas son aquí el factor de coste silencioso más habitual.

La latencia sigue la misma lógica. El tiempo hasta el primer token y el tiempo total de respuesta aumentan con la longitud de la entrada, porque el modelo tiene que leer todo el contexto antes de responder. Un agente que hacia el final de una ejecución larga lleva 80.000 tokens de contexto es notablemente más lento por paso que al principio, y precisamente cuando el usuario ya está esperando.

Degradación: Lost-in-the-Middle con el contexto lleno

Una falacia muy extendida dice: si la ventana es lo bastante grande, se puede meter todo dentro. Técnicamente es cierto, pero no en términos de calidad. Los LLM aprovechan con más fiabilidad la información del principio y del final de una entrada larga que la del medio, un efecto conocido como Lost-in-the-Middle. Cuanto más largo es el contexto, mayor es el riesgo de que la información decisiva reciba menos peso o se pierda.

Para los agentes, esto es doblemente relevante. Primero, un agente suele llenar su contexto con historial irrelevante para el paso actual. Segundo, un contexto saturado puede hacer que el modelo ignore instrucciones antiguas o resultados tempranos de herramientas que quedan en mitad del historial. La calidad de las respuestas baja entonces aunque técnicamente haya espacio suficiente. Más contexto no equivale automáticamente a más rendimiento; a partir de cierto punto, es mejor un contexto más reducido pero bien seleccionado.

Conceptos y su implicación para los agentes

Ejemplo de cálculo: de tokens a costes

Un agente de soporte resuelve una consulta en 6 pasos. En cada paso vuelve a enviar todo el contexto. Supuesto simplificado de la evolución de la entrada: 2.000, 5.000, 9.000, 14.000, 20.000 y 27.000 tokens, en total unos 77.000 tokens de entrada. Además, genera unos 500 tokens de salida por paso, es decir, unos 3.000 tokens de salida en total.

Hagamos el cálculo con tres niveles de precio. Para simplificar, se aplica a los tres modelos el mismo número de tokens; según el tokenizador, la cifra para una misma tarea varía. La tabla usa precios de lista por 1 millón de tokens (entrada/salida, datos de octubre de 2026) según Anthropic, Mistral y DeepSeek:

Una sola ejecución parece barata. Pero con 50.000 ejecuciones de este tipo al mes salen unos 18.400 dólares con el modelo frontier, frente a unos 2.150 dólares con el modelo soberano de la UE y unos 1.300 dólares con el modelo workhorse económico. Para DeepSeek, la tabla recoge la tarifa en horas punta; fuera de ellas se aplica la mitad del precio. Claude Fable 5.1, que Anthropic destina al razonamiento exigente, cuesta 10 $ / 50 $, es decir, 2,5 veces lo que Opus 5.5 (Anthropic). Extrapolado, serían unos 46.000 dólares al mes. El factor entre el nivel frontier y el workhorse se sitúa, según el modelo, entre 8 y 100 (datos de octubre de 2026). Dos lecciones: primero, en los agentes el presupuesto lo domina la entrada que se arrastra de paso en paso, no la salida. Segundo, elegir el modelo para cada subpaso es una palanca de costes enorme.

A esto se suma un recargo por contexto largo. Gemini 3.1 Pro, por ejemplo, se encarece por encima de 200.000 tokens: el precio de entrada se duplica y el de salida también sube de forma notable (4 $ / 18 $ en lugar de 2 $ / 12 $ por 1 millón de tokens, datos de octubre de 2026). Quien deja que el contexto de un agente crezca sin control por encima de este umbral paga por más tokens y, además, una tarifa más alta por token.

Contraestrategias: mantener el contexto pequeño y enfocado

El arte de la ingeniería de agentes consiste en darle al modelo en cada paso solo lo que realmente necesita. Tres estrategias que se pueden combinar:

• Compresión del contexto y resumen. Los pasos antiguos se condensan en un breve resumen en lugar de arrastrar el historial completo. Las salidas largas de herramientas se reducen al resultado. Esto disminuye a la vez los tokens de entrada, la latencia y el riesgo de Lost-in-the-Middle.
• Recuperación en lugar de texto completo (RAG). En vez de cargar bases de conocimiento o documentos enteros en el prompt, se incorporan mediante búsqueda solo los fragmentos relevantes. Así el contexto se mantiene pequeño y mejora la precisión, porque el modelo no se distrae con información irrelevante.
• Enrutamiento de modelos y caché de prompts. Los subpasos sencillos (clasificación, extracción, formateo) se ejecutan en modelos workhorse u open-weight baratos; los costosos modelos frontier se reservan solo para los pasos complejos. La caché de prompts reduce además los costes de las partes del contexto recurrentes y estables, como los prompts de sistema.

Como complemento, conviene limitar la salida de forma deliberada (respuestas breves y estructuradas en lugar de prosa extensa) y recortar los resultados de las herramientas a lo necesario. En conjunto, estas medidas deciden si un agente que luce elegante en la fase piloto también sigue siendo rentable en producción.

Para agencias y decisores B2B

La tokenización y la ventana de contexto son los dos parámetros clave para la rentabilidad de un agente de IA. Quien presupuesta una solución de agentes no debería calcular los costes por petición, sino por ejecución completa de varios pasos y extrapolarlos al volumen mensual previsto, incluido el crecimiento desproporcionado del contexto. Para las agencias, el valor de su asesoría está en ahorrar a sus clientes la desagradable sorpresa de que un agente barato en el piloto se vuelva imprevisiblemente caro o lento bajo carga. Blck Alpaca ayuda a empresas de toda Europa a diseñar arquitecturas de agentes con la gestión del contexto, el enrutamiento de modelos y la recuperación integrados desde el principio. El resultado: costes previsibles, latencia aceptable y una calidad de respuesta estable en producción.