🤖 machine learning

Cache-Aware Prompt Compression:A Two-Tier Cost Model for LLM API Caching

Este artículo presenta la Compresión de Prompts Consciente de la Caché (CAPC, por sus siglas en inglés), una estrategia que combina la compresión agnóstica a la consulta con un control de caché explícito y límites de preservación de niveles para superar las limitaciones de los métodos conscientes de la consulta, logrando reducciones de costos significativas (hasta un 90 %) al tiempo que mantiene la calidad en diversas cargas de trabajo de LLM de producción.

Autores originales: Yan Song

Publicado 2026-07-20

📖 3 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Yan Song

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que diriges una biblioteca masiva y superinteligente donde un bibliotecario muy caro (una IA) te ayuda a encontrar respuestas. Para ahorrar dinero, la biblioteca tiene dos trucos especiales. Primero, hay un "Salón VIP" (caché): si le preguntas al bibliotecario sobre el mismo capítulo de un libro una y otra vez, no tiene que volver a leer todo el libro desde los estantes de la biblioteca; simplemente echa un vistazo a sus notas, lo cual es mucho más barato. Segundo, hay un "Resumidor" (compresión): en lugar de entregarle al bibliotecario una novela de 500 páginas, le das un resumen de 50 páginas, lo cual también es más barato de procesar.

Durante mucho tiempo, la gente pensó que estos dos trucos debían usarse por separado. O bien usabas el Salón VIP para libros grandes y aburridos, o usabas el Resumidor para preguntas cortas y complicadas. Pero aquí está el problema: el Resumidor suele cambiar la historia ligeramente cada vez que haces una nueva pregunta para que encaje mejor. El problema es que el Salón VIP es un estricto cumplidor de las reglas. Si la historia cambia aunque sea un poquito, el bibliotecario dice: "Lo siento, ¡ese es un libro nuevo!" y tira sus notas, obligándote a pagar el precio completo para leer todo el libro de nuevo. Este artículo plantea una pregunta sencilla: ¿Podemos usar ambos trucos al mismo tiempo sin romper las reglas?

Los investigadores de PayPal decidieron probar esto en un sistema de IA del mundo real llamado Sonnet 4.6. Descubrieron que el Salón VIP no es tan perfecto como todos pensaban. Tiene una "zona caliente" para notas cortas y una "zona persistente" para las largas, y si te vuelves demasiado astuto con tus resúmenes, accidentalmente expulsas tus notas de la zona caliente y cara. Descubrieron que la forma antigua de hacer las cosas —cambiar el resumen para cada pregunta— en realidad desperdicia dinero porque impide que el bibliotecario use las notas baratas.

Para solucionar esto, inventaron una nueva estrategia llamada CAPC (Compresión de Prompts Consciente de la Caché). Piensa en esto como si, en lugar de reescribir la historia para cada pregunta, crearas un resumen comprimido perfecto de las partes aburridas una sola vez y lo bloquearas en el Salón VIP. Luego, para cada nueva pregunta, simplemente añades la pregunta específica a ese resumen bloqueado sin cambiar el resumen en sí. Es como tener un guion preescrito que nunca cambia, de modo que el bibliotecario puede reutilizar sus notas baratas cada vez.

Los resultados fueron sorprendentes. En pruebas con 16 tipos diferentes de documentos, este nuevo método fue la opción más barata en cada ocasión, ahorrando aproximadamente un 49% comparado con solo usar el Salón VIP y un 64% comparado con el antiguo método de "cambiar el resumen". También lo probaron en trabajos del mundo real, como un robot que usa herramientas para arreglar código de computadora y un sistema que busca a través de enormes grafos de conocimiento. En un caso, ahorraron más del 50% en costos sin perder calidad. En otro, demostraron que el antiguo método de "cambiar el resumen" en realidad costaba un 40% más que no hacer nada en absoluto porque seguía rompiendo la caché. El artículo concluye que, siendo inteligentes sobre cuándo comprimir y qué guardar en caché, podemos hacer que la IA sea mucho más barata de usar sin hacerla más tonta.

Resumen Técnico: Compresión de Prompts Consciente del Caché (CAPC)

Planteamiento del Problema

Los despliegues modernos de Modelos de Lenguaje de Gran Escala (LLM) dependen cada vez más de dos primitivas distintas de reducción de costos: el almacenamiento en caché de prompts (almacenar los estados KV de un prefijo para cobrar tarifas descontadas en lecturas subsecuentes) y la compresión de prompts (reducir el recuento de tokens de la entrada). Históricamente, estas técnicas se han tratado como optimizaciones separadas. Sin embargo, la literatura dominante sobre la compresión de prompts se basa en métodos conscientes de la consulta (query-aware), que generan un prefijo comprimido único para cada consulta específica.

Esta elección de diseño crea un conflicto fundamental con los mecanismos de caché estrictos respecto al prefijo (por ejemplo, cache_control de Anthropic). Debido a que el prefijo comprimido cambia con cada consulta, la clave del caché se invalida en cada llamada. Consecuentemente, el sistema paga la tarifa completa de entrada no descontada por cada solicitud, lo que efectivamente anula los ahorros tanto de la compresión como del caché. Aunque la literatura existente a menudo asume una tasa de acierto de caché ideal ( $\rho = 1.0$ ), esta suposición no tiene en cuenta la realidad económica de las API del mundo real, donde el comportamiento del caché es no trivial y la compresión consciente de la consulta puede resultar en un retorno de inversión (ROI) neto negativo.

Metodología y Caracterización Empírica

Los autores abordan este vacío mediante una combinación de medición empírica, modelado de costos y diseño algorítmico.

1. Caracterización Empírica de Anthropic Sonnet 4.6

El artículo caracteriza primero el comportamiento de caché de la API de Anthropic Sonnet 4.6 a través de experimentos controlados ( $n=3$ ensayos, costo total $1.91). Los hallazgos clave incluyen:

Arquitectura de Dos Niveles: El caché no es uniforme. Exhibe un umbral pronunciado cerca de los 3,500 tokens.
- Nivel Caliente (< 3.5k tokens): La tasa de acierto ( $\rho$ ) se estabiliza en aproximadamente 0.83 (específicamente 0.833 para 2k tokens) incluso después de 30 llamadas. No es 1.0.
- Nivel Persistente (> 3.5k tokens): La tasa de acierto es efectivamente 1.0 a partir de la segunda llamada en adelante.
Invalidación Estricta de Tokens: La invalidación del caché es estricta respecto a la secuencia de tokens. Incluso cambios menores (ej. un cambio de un solo carácter) resultan en un fallo de caché, aunque el espacio en blanco inicial/final es normalizado por el tokenizador.
Estructura de Precios: La API cobra una prima por las escrituras de caché ( $c_w$ ) en comparación con las entradas no almacenadas en caché ( $p_{in}$ ), y un descuento significativo por las lecturas de caché ( $c_r$ ). En Sonnet 4.6, $c_w \approx 1.25 \times p_{in}$ y $c_r \approx 0.10 \times p_{in}$ .

2. Modelado de Costos y Análisis de Crossover

Los autores derivan un modelo de costo por llamada para cuatro estrategias:

A (Vanilla): Sin caché, sin compresión.
B (Solo Caché): Prefijo completo en caché, sin compresión.
C (Compresión Consciente de la Consulta): Comprimido por consulta, sin caché (falla el caché en cada ocasión).
D (CAPC): Compresión agnóstica a la consulta + caché.

El modelo define un umbral de cruce ( $\rho_{cross}$ ) donde el costo de la caché (Estrategia B) es igual al costo de la compresión consciente de la consulta (Estrategia C):
$\rho_{cross}(r) = \frac{c_w - p_{in}/r}{c_w - c_r}$
El análisis revela que para altas tasas de compresión ( $r \ge 6$ ), la tasa de acierto requerida para que el caché supere a la compresión consciente de la consulta sea superior al plateau empírico del nivel caliente de Sonnet 4.6 ( $\rho \approx 0.89$ ). Por lo tanto, bajo condiciones realistas, la compresión consciente de la consulta es a menudo más barata que el almacenamiento en caché ingenuo, contradiciendo la sabiduría convencional.

3. El Algoritmo CAPC

La solución propuesta, Compresión de Prompts Consciente del Caché (CAPC), combina tres componentes:

Compresión Agnóstica a la Consulta: Un documento estático se comprime una sola vez (ej. mediante selección de oraciones) en un prefijo fijo $D'$ , asegurando que la clave de caché permanezca constante entre consultas.
Límite de Ratio Preservador de Niveles: Para evitar que la sobrecompresión empuje el prefijo hacia el "nivel caliente" (donde $\rho < 1$ ), la tasa de compresión $r$ está limitada por $r_{max} = \lfloor |D| / 3500 \rfloor$ . Esto asegura que el prefijo comprimido permanezca en el nivel persistente ( $\rho \approx 1.0$ ).
AdaptiveCacheBoundary: Para documentos en evolución, una subrutina clasifica las posiciones de las oraciones como STATIC (ESTÁTICA), QUASI (CUASI) o DYNAMIC (DINÁMICA) basándose en la tasa de mutación entre versiones, almacenando en caché solo el prefijo estable.

Resultados Clave

1. Benchmarks Sintéticos LongBench-v2

En 16 configuraciones (4 tamaños de documento $\times$ 4 ratios), CAPC fue la estrategia más barata en 16/16 casos.

Ahorros: Ahorro medio del 49% sobre el modelo de solo caché, 64% sobre la compresión consciente de la consulta, y 90% sobre el modelo vanilla.
Calidad: CAPC mantuvo la calidad dentro de 0.05 del baseline sin comprimir en los ratios preservadores de nivel.
Validación de Crossover: En $r=6$ , la compresión consciente de la consulta fue más barata que el solo caché en las 4/4 configuraciones, validando la predicción del modelo de crossover.

2. Validación en Producción: Asistente de Uso de Herramientas Empresarial

Validado en un prefijo estático de 94k tokens (system prompt + 287 definiciones de herramientas MCP).

Reducción de Costos: CAPC con $r=3$ logró una reducción de costos del 51.7% respecto a vanilla.
Calidad: La calidad de selección de herramientas igualó al modelo de solo caché (0.700 vs 0.703).
Perspectiva: La compresión consciente de la consulta con $r=3$ en realidad funcionó peor en la selección de herramientas (0.603) porque descartó definiciones de herramientas relevantes para la consulta. El enfoque agnóstico a la consulta de CAPC preservó el catálogo completo, demostrando ser superior para agentes aumentados con herramientas.
Caché Implícito: El estudio reveló que Anthropic almacena en caché implícitamente los arreglos de tools= grandes incluso sin marcadores explícitos, reduciendo el beneficio marginal del caché explícito pero no negando las ganancias de compresión de CAPC.

3. RAG de Grafo de Conocimiento (Graphify)

Integrado con graphify para el indexado de repositorios de código (FastAPI y httpx).

Arquitectura: La Capa 1 (almacenada en caché, agnóstica a la consulta) contiene metadatos del grafo; la Capa 2 (por consulta) recupera el código fuente.
Desempeño: CAPC entregó una reducción de costos de 9.3x en FastAPI y 2.4x en httpx en comparación con "cache-all" (esqueleto completo del grafo), manteniendo tasas de acierto de caché estables de más del 85%.
Calidad: CAPC superó a las consultas nativas de graphify y a los baselines de RAG de embeddings, particularmente en codebases donde el modelo tenía un conocimiento previo más débil (httpx), entregando un incremento de calidad del 142% sobre vanilla.

4. Benchmark Público: $\tau$ -Bench Retail

Evaluado en 50 tareas deterministas con recompensas de estado de base de datos (sin juez LLM).

Resultado: CAPC fue la estrategia más barata, ahorrando un 7.9% sobre vanilla mientras lograba exactamente la misma tasa de finalización de tareas (36/50) que vanilla ( $z=0.00, p=1.00$ ).
ROI Negativo de la Compresión Consciente de la Consulta: La compresión consciente de la consulta fue un 40.1% más cara que vanilla, proporcionando la primera confirmación en producción de que los métodos conscientes de la consulta pueden tener un ROI negativo en benchmarks públicos.

Significado y Reivindicaciones

El artículo afirma proporcionar la primera caracterización sistemática de la economía del almacenamiento en caché de prompts, yendo más allá de la suposición idealizada de $\rho=1.0$ . Sus principales contribuciones son:

Realidad Empírica: Demostrar que los cachés de los LLM tienen una arquitectura de dos niveles con una tasa de acierto de plateau no trivial por debajo de un umbral de tokens específico.
Inversión Teórica: Probar que, en altas tasas de compresión, la compresión consciente de la consulta es a menudo más barata que el almacenamiento en caché ingenuo, invirtiendo la jerarquía de diseño convencional.
Algoritmo Práctico: Introducir CAPC, que unifica la compresión agnóstica a la consulta con el caché explícito y un límite preservador de niveles.
Validación en Producción: Validar estos hallazgos a través de benchmarks sintéticos, agentes de uso de herramientas empresariales, pipelines de RAG de grafos de conocimiento y benchmarks públicos deterministas.

Los autores enfatizan que CAPC no es un reemplazo para los indexadores (como graphify), sino una capa complementaria de "entrega de última milla" que optimiza el costo económico de entregar el contexto derivado del índice a un LLM. El costo total de todo el trabajo empírico en el artículo fue de $98.96, demostrando que estos hallazgos son reproducibles con recursos modestos.