ctx::window  /  anatomía de la ventana de contexto
LLM · Ventana de contexto

Un LLM no tiene memoria.
Solo tiene una ventana.

Todo lo que un modelo "sabe" en una respuesta cabe en una única región de tokens acotada que se llena y se reprocesa en cada llamada. Prompt de sistema, historial, skills, memoria, tu mensaje y el espacio para responder comparten el mismo presupuesto. Piénsalo como el límite de memoria de un pod: cuando se llena, algo hay que desalojar.

ceiling · 200K
    01 — Qué vive dentro

    Los inquilinos de la ventana

    No hay carpetas ni disco: todo es texto tokenizado en una misma cola. El orden importa (el sistema va primero) y cada categoría gasta parte del mismo presupuesto. Estos son los colores que verás en todo el documento.

    Regla mental: ventana de contexto = presupuesto compartido. Si algo entra, algo tiene menos sitio. El "output reservado" (el max_tokens que dejas libre para que el modelo responda) también cuenta: por eso el contexto útil siempre es menor que el techo nominal.

    02 — Nivel mensaje

    Cada turno, la conversación entera vuelve a viajar

    El modelo es sin estado: entre llamadas no recuerda nada. La app de chat crea la ilusión de memoria reenviando toda la conversación (sistema + cada turno anterior + tu mensaje nuevo) en cada petición. Avanza turno a turno y míralo crecer.

    Controlar la conversación

    Cada turno añade tu mensaje y la respuesta del modelo al historial.

    Turno 0. Solo está el prompt de sistema. El modelo aún no ha visto nada tuyo.

    El prompt de sistema es un prefijo estable: no cambia entre turnos. Justo por eso es el candidato perfecto para la caché (siguiente sección) — se reenvía siempre igual, así que no hace falta reprocesarlo cada vez.

    ceiling · 200K
    vacío
      03 — Cómo se procesa

      Input y output no cuestan lo mismo

      El input se lee en una sola pasada paralela (prefill): rápido y barato por token. El output se genera de a un token, y cada nuevo token vuelve a mirar todos los anteriores (decode autoregresivo): lento y caro por token. Dale a reproducir.

      Prefill · lectura del inputtoda la ventana, una pasada en paralelo
      en espera
      Decode · generación del outputun token a la vez, autoregresivo
      en espera

      Fíjate: el input entero se ilumina casi de golpe; el output aparece letra a letra. Por eso los tokens de salida se cobran más caros y dominan la latencia percibida.

      Caché: no pagues dos veces por lo que no cambia

      Reprocesar el mismo prefijo largo en cada llamada es tirar cómputo. Hay dos cachés distintas — una interna al modelo, otra que tú controlas.

      Caché de prompt: ON

      Prefijo estable (sistema + herramientas + skills) = 10 300 tokens, idéntico en cada petición.

      Costo del prefijo por llamada
      Latencia hasta el 1.er token (TTFT)

      Caché KV · interna

      Dentro de una misma respuesta

      Al generar, el modelo guarda las claves/valores de atención de cada token ya procesado, para no recalcular la atención sobre toda la secuencia en cada token nuevo. Es lo que hace viable el decode.

      alcance: 1 generación · efímera · automática

      Caché de prompt · API

      Entre llamadas distintas

      Persiste el estado ya "precargado" de un prefijo estable para reutilizarlo en peticiones siguientes. La lectura cuesta una fracción del input normal. Tú marcas dónde cortar y tiene un TTL (p. ej. 5 min).

      alcance: múltiples llamadas · tú la controlas
      04 — Nivel agente

      Un agente es un bucle, y los resultados de herramienta engordan

      Un agente vuelve a llamar al modelo en bucle: el modelo pide una herramienta, el runtime la ejecuta y devuelve el resultado al contexto. Ese resultado (logs, respuestas de API, YAML de un recurso) suele ser grande — y se acumula en cada iteración. Avanza el bucle y observa la presión.

      ↺  el resultado se anexa y el bucle vuelve al modelo

      Ejecutar el agente

      Cada iteración = una llamada a herramienta + su resultado, anexados a la ventana.

      Iteración 0 · el contexto arranca con el prefijo del agente (sistema + herramientas + skills + memoria + objetivo).

      Nota cómo el prefijo de un agente ya es mucho más pesado que el de un chat: las definiciones de herramientas y las skills viven ahí. Y cada resultado de herramienta es un bloque naranja que no se va solo.

      ceiling · 200K
      listo
        05 — En la práctica

        El bucle, aplicado: gate determinista, suggest→approve→execute y proxy

        Así se ve el bucle en un producto real. En KubeBolt, el copilot Kobi no llama al LLM a la primera: una capa de Skills deterministas (L1–L6) decide si hace falta el modelo. Cuando escala, propone un comando, un humano lo aprueba y un proxy agent-outbound lo ejecuta contra el cluster — sin exponer el API server. Todo medido en la misma ventana.

        ↺  si el resultado no resuelve el incidente, el bucle vuelve al modelo
        Gate determinista (Skills L1–L6): ON

        Escenario: alerta CrashLoopBackOff en pago-svc.

        ceiling · 200K
        listo

          Determinismo primero

          Las reglas deciden si corre el LLM

          La capa de Skills L1–L6 se ejecuta antes de cualquier llamada al modelo. Si una regla resuelve el incidente, la ventana ni se toca: cero tokens de LLM, coste ~$0. Es una inversión de control — lo contrario a "todo pasa por el modelo".

          efecto en la ventana: 0 tokens cuando la regla acierta

          Proxy agent-outbound

          Ejecuta sin exponer el cluster

          El agente abre la conexión saliente; el API server nunca queda expuesto. Habilita toda la superficie kubectl con la aprobación humana como gate de control — que cuesta 0 tokens. El resultado que vuelve (logs, describe, YAML) es el bloque naranja que engorda el contexto.

          efecto en la ventana: cada tool_result grande = presión
          06 — Gestión del contexto

          Cómo no reventar la ventana

          El agente de abajo arranca en sobrecarga: un objetivo largo llenó el contexto. Activa cada estrategia y mira cuánto presupuesto recupera. Son exactamente las palancas que expone un Agent SDK.

          ceiling · 200K
          sobrecarga

            Con todo desactivado, el transcript no cabe. Las cuatro estrategias son complementarias: mueven tokens fuera de la ventana o los comprimen, sin perder lo esencial.

            07 — Mapa mental

            Seis ideas para llevarte

            01

            Un presupuesto, no un disco

            Todo — sistema, historial, skills, memoria, input y hueco para el output — comparte una sola cuenta de tokens. Llenar una parte vacía otra.

            02

            El modelo es sin estado

            No recuerda entre llamadas. La "memoria" del chat es la app reenviando la conversación completa cada turno.

            03

            Input barato, output caro

            El prompt se lee en paralelo (prefill); la respuesta se genera token a token (decode). El output domina costo y latencia.

            04

            Cachea lo estable

            La caché KV acelera una respuesta; la caché de prompt reutiliza el prefijo entre llamadas y recorta costo y TTFT.

            05

            En agentes, mandan los tool results

            El bucle acumula resultados de herramienta, no turnos de chat. Ese es el principal motor de consumo de contexto.

            06

            Gestiona o desborda

            Carga progresiva de skills, memoria externa, compactación y subagentes: sacar tokens fuera o comprimirlos es lo que mantiene la ventana viva.

            Este bucle ya corre en producción

            Kobi, el copilot de KubeBolt, aplica todo lo de arriba al diagnóstico de Kubernetes: gate determinista, suggest→approve→execute y la ventana siempre bajo control.

            Conoce KubeBolt →