Caché de prompts, explicado claramente

@akshay_pachaar
INGLÉShace 4 meses · 09 mar 2026
467K
1.1K
159
18
2.0K

TL;DR

Un análisis profundo sobre la mecánica del caché de prompts, explicando cómo el caché KV y la disciplina arquitectónica permiten a Claude alcanzar una tasa de aciertos del 92% y un ahorro masivo de costos.

Un caso de estudio sobre cómo Claude alcanza un 92 % de tasa de acierto de caché

Cada vez que un agente de IA da un paso, paga un peaje.

Vuelve a leer todo desde cero.

Las instrucciones del sistema. Las definiciones de las herramientas. El contexto del proyecto que ya cargó hace tres turnos. Todo. En cada turno.

Ese es el peaje del contexto. Y para flujos de trabajo agentivos de larga duración, suele ser el concepto más caro de toda tu infraestructura de IA.

Aquí están los números: un prompt de sistema de 20 000 tokens que se ejecuta durante 50 turnos significa 1 millón de tokens de cómputo redundante facturados a precio completo, sin generar ningún valor nuevo.

La solución es el almacenamiento en caché de prompts. Pero para usarlo bien, necesitas entender qué está pasando realmente bajo el capó.

Empieza con lo que cambia y lo que no cambia

Antes de optimizar nada, debes pensar con claridad sobre la estructura del prompt (contexto) de un agente.

Cada solicitud que envía tu agente tiene dos partes fundamentalmente diferentes:

El prefijo estático: incluye instrucciones del sistema, definiciones de herramientas, contexto del proyecto, pautas de comportamiento. Este contenido es idéntico en cada turno de una sesión.

La cola dinámica: mensajes del usuario, salidas de herramientas, observaciones del terminal. Esto es único para cada solicitud y crece a medida que avanza la conversación.

Akshay 🚀 - inline image

Esta distinción lo es todo. El prefijo estático es la parte costosa que sigues recalculando sin motivo. La cola dinámica es la única parte que realmente necesita cómputo nuevo.

El almacenamiento en caché de prompts funciona guardando el estado matemático del prefijo estático para que las solicitudes futuras puedan omitir su recálculo por completo. Pagas por procesar ese prefijo una vez. Cada turno posterior lo lee de la memoria.

Por qué funciona esto: lo que realmente hace un Transformer

Para entender realmente por qué el caché es tan efectivo, necesitas entender qué sucede dentro del modelo cuando lee tu prompt.

Cada solicitud de inferencia de un LLM tiene dos fases:

Fase 1: Precarga (Prefill)

Aquí es donde el modelo procesa tu prompt de entrada completo. Está limitado por cómputo, lo que significa que ejecuta multiplicaciones densas de matrices en cada token de tu contexto. El modelo lee todo y construye una representación. Esta es la fase lenta y costosa.

Fase 2: Decodificación

Aquí es donde el modelo genera tokens de salida, uno a la vez. Está limitado por memoria, no por cómputo, porque el modelo pasa la mayor parte del tiempo leyendo el estado previamente calculado en lugar de ejecutar cálculos pesados.

Akshay 🚀 - inline image

Durante la fase de precarga, el transformer construye tres vectores para cada token: una Consulta (Query), una Clave (Key) y un Valor (Value). El mecanismo de atención los usa para determinar cómo se relaciona cada token con todos los demás tokens de la secuencia.

Aquí está la idea clave: los vectores de Clave y Valor dependen solo de los tokens que vinieron antes. Una vez calculados para un prefijo determinado, nunca necesitan cambiar.

La siguiente ilustración explica visualmente lo que acabamos de comentar:

Akshay 🚀 - inline image

Sin almacenamiento en caché, esos tensores de Clave-Valor se descartan en el momento en que se completa una solicitud. La siguiente solicitud comienza desde cero y los recalcula para los 20 000 tokens nuevamente.

El almacenamiento en caché KV soluciona esto guardando esos tensores. La infraestructura los mantiene en los servidores de inferencia, indexados por un hash criptográfico del texto de entrada. Cuando llega una nueva solicitud con el mismo prefijo, el hash coincide, los tensores se recuperan de inmediato y el modelo se salta todo ese cómputo.

Esto reduce la complejidad computacional de O(n²) por token generado a O(n). Para un prefijo de 20 000 tokens repetido a lo largo de 50 turnos, eso es una reducción enorme.

Los aspectos económicos

Entender la estructura de precios es lo que hace que esta decisión arquitectónica sea tan trascendental.

Así es como Anthropic fija los precios del almacenamiento en caché en sus familias de modelos:

Akshay 🚀 - inline image

Tres números para interiorizar:

  • Las lecturas de caché cuestan el 10 % del precio de entrada base, un descuento del 90 % en cada token leído del caché
  • Las escrituras en caché cuestan un 25 % más que el precio de entrada base, una prima pequeña para almacenar los tensores KV
  • El almacenamiento en caché extendido de 1 hora cuesta el doble del precio base

Las matemáticas solo funcionan si tu tasa de acierto de caché se mantiene alta. Lo que nos lleva al mejor ejemplo real de cómo se ve eso en la práctica.

Claude Code: un recorrido por una sesión de 30 minutos

Claude Code está construido enteramente en torno a un objetivo: mantener el caché caliente.

Para entender qué significa eso concretamente, veamos cómo se ve una sesión típica de codificación de 30 minutos y rastreemos exactamente qué se factura y qué no.

Minuto 0: Inicio de sesión

Claude Code carga su prompt de sistema y las definiciones de herramientas. También lee el archivo CLAUDE.md en la raíz de tu proyecto, que describe el código base y las convenciones. Esta carga útil suele superar los 20 000 tokens.

Este es el momento más caro de toda la sesión. Cada token es nuevo. Pero solo pagas este costo una vez.

Minutos 1 a 5: Primeros comandos

Escribes tu primera instrucción, algo como "mira el módulo de autenticación y sugiere mejoras".

Claude Code lanza un Subagente Explorador (Explore Subagent). Navega por el código base, abre archivos, ejecuta comandos grep y construye una imagen del código relevante. Todo esto se añade a la cola dinámica.

¿La base estática de 20 000 tokens? Ya está en caché. Se lee a $0.30/MTok en lugar de $3.00/MTok. Solo pagas por las nuevas salidas de herramientas y tu mensaje.

Minutos 6 a 15: Trabajo profundo

El Subagente Planificador (Plan Subagent) recibe los hallazgos del Subagente Explorador. En lugar de pasar los resultados brutos textualmente (lo que inflaría innecesariamente la cola dinámica), Claude Code pasa un resumen conciso. Esto mantiene el sufijo manejable y el caché eficiente.

El planificador produce un plan de implementación estructurado. Lo revisas, lo apruebas y Claude Code comienza a hacer cambios. Cada turno en este bucle lee el prefijo de 20 000 tokens desde el caché. Cada acierto de caché reinicia el TTL, manteniendo el caché caliente para turnos futuros.

Minutos 16 a 25: Iteración

Pides ajustes. Claude Code revisa su enfoque. Más llamadas a herramientas, más salidas de terminal. La cola dinámica está creciendo, pero representa solo el contenido nuevo y único de esta sesión.

En este punto, la sesión ha procesado cientos de miles de tokens en total. Pero la base de 20 000 tokens se ha leído desde el caché en cada turno.

Minuto 28: Ejecutar /cost

Sin almacenamiento en caché, una sesión como esta supera fácilmente los 2 millones de tokens. A las tarifas de Sonnet 4.5, eso ronda los $6.00.

Con el almacenamiento en caché funcionando con alta eficiencia:

  • La gran mayoría de los tokens se leen desde el caché a $0.30/MTok
  • Solo los tokens nuevos de la cola dinámica se computan desde cero

En la práctica, esperarías una reducción de costos del 80 % o más en una sola tarea. Ahora multiplícalo por cada usuario, cada día.

Para resumir, así es como se ve la disposición del prompt de sistema a medida que continúa la sesión:

Akshay 🚀 - inline image

La regla que lo rompe todo

Esto es lo más contraintuitivo sobre el almacenamiento en caché de prompts.

1 + 2 = 3. Pero 2 + 1 es un fallo de caché.

La infraestructura hashea el prompt. El hash es un identificador para criptografía. El hash cambia si algo en ese orden cambia, incluso si dos elementos están en un orden diferente. El caché está vacío. Todo el prefijo se recalcula a precio completo.

Tres reglas que se derivan de esto:

  1. No añadas ni quites herramientas durante una sesión. El prefijo almacenado en caché incluye las herramientas. Cambiar las herramientas hace que todo lo que viene después sea inútil.
  2. Nunca cambies de modelo a mitad de sesión. Los cachés son específicos del modelo. Cambiar a un modelo más barato a mitad de conversación requiere reconstruir todo el caché.
  3. Nunca cambies el prefijo para cambiar el estado. En su lugar, Claude Code añade una etiqueta al siguiente mensaje del usuario que recuerda al sistema. El prefijo nunca cambia.

Lo que significa para ti

Todo lo anterior explica cómo maneja el caché Claude Code. Las mismas reglas se aplican si estás creando tu propio agente.

Así es como debes estructurar tus prompts:

  • Al principio, las instrucciones del sistema y las reglas. No las cambies a mitad de camino.
  • Carga todas las herramientas que necesitarás por adelantado. No las añadas ni las quites.
  • Después, el contexto y los documentos recuperados. Estáticos durante la duración.
  • Al final, el historial de la conversación y las salidas de las herramientas.

Con el almacenamiento en caché automático activado, el punto de ruptura avanza automáticamente a medida que avanza la conversación.

Claude Code está a cargo de su propio caché. Anthropic acaba de añadir almacenamiento en caché automático a su API, por lo que puedes hacer lo mismo para tu propio agente.

Sin almacenamiento en caché automático, tenías que recordar dónde estaban los límites de los tokens. Un límite incorrecto significaba no llegar al caché.

Akshay 🚀 - inline image

Usa bifurcación segura para caché (cache-safe forking) para compactar el límite de contexto. Usa el mismo prompt de sistema, herramientas y conversación, luego añade la compactación como un nuevo mensaje.

Akshay 🚀 - inline image

La llamada de compactación se ve casi exactamente como la última. El prefijo almacenado en caché se usa de nuevo. Lo único que se factura como nuevo es la instrucción de compactación.

Para ver si una API está funcionando, vigila estos tres campos en cada respuesta:

  • cache_creation_input_tokens: tokens puestos en memoria
  • cache_read_input_tokens: tokens leídos de la memoria
  • input_tokens: tokens procesados como de costumbre

Tu puntuación de eficiencia de caché es el número de tokens leídos en comparación con el número de tokens creados. Vigílalo de la misma manera que vigilas el tiempo de actividad.

Conclusiones clave

El almacenamiento en caché de prompts no es una característica que se activa. Es una disciplina arquitectónica en torno a la cual construyes.

Claude Code es el mejor ejemplo de cómo se ve ese campo cuando se hace a gran escala.

Una tasa de acierto de caché del 92 %. Una reducción de costos del 81 %.

Este es el modelo si estás creando agentes. No puedes ignorar el peaje; existe. Lo único que importa es si lo estás pagando o deshaciéndote de él.

Referencias:

Guardar con un clic

Lee artículos virales en profundidad con IA en YouMind

Guarda la fuente, haz preguntas concretas, resume el argumento y convierte un artículo viral en notas reutilizables en un único espacio de trabajo con IA.

Explora YouMind
Para creadores

Convierte tu Markdown en un artículo de 𝕏 impecable

Cuando publicas tus propios textos largos, dar formato en 𝕏 a imágenes, tablas y bloques de código es un fastidio. YouMind convierte un borrador completo en Markdown en un artículo de 𝕏 impecable y listo para publicar.

Prueba Markdown a 𝕏

Más patrones por descifrar

Artículos virales recientes

Explorar más artículos virales