Cache de respuestas: no pagues dos veces lo mismo

En una CDN clásica cachear es casi una obviedad: el mismo archivo para todo el mundo, servido desde el borde. Con un modelo de lenguaje la tentación es la misma y las consecuencias son mucho mayores, porque lo que ahorras no es ancho de banda sino inferencia pagada por token y segundos de espera. Pero también es mucho más fácil equivocarse: una respuesta de LLM parece contenido estático y a menudo no lo es. Este capítulo va de las dos caras de esa moneda: cómo se activa la caché y, sobre todo, cómo saber si lo que estás a punto de cachear se puede cachear.

Lo que se ahorra de verdad

Un acierto de caché no es una optimización marginal: es la eliminación completa del trabajo. La petición no llega al proveedor, no se generan tokens y por tanto no se factura nada de inferencia; y como la respuesta sale de la red de Cloudflare, la latencia cae de segundos a decenas de milisegundos. Es el único mecanismo de este nivel que mejora coste y velocidad a la vez, sin compromiso entre ambos.

Hay un tercer beneficio que se nota solo cuando las cosas van mal: una petición que no llega al proveedor tampoco consume su cuota, así que la caché es de paso un amortiguador frente a los límites que él te impone y frente a sus malos momentos. Bajo una avalancha de tráfico repetido, un sistema con caché mantiene la calma mientras el mismo sistema sin ella se estrella contra el techo del proveedor.

La magnitud del ahorro depende por completo de una propiedad de tu tráfico que rara vez se mide: la tasa de repetición de prompts. En un asistente conversacional abierto es baja, porque cada usuario escribe algo distinto. En un bot de soporte con respuestas guiadas, en una clasificación de tickets con etiquetas fijas, en una traducción de cadenas de interfaz o en una demo pública que todo el mundo prueba con el ejemplo sugerido, esa tasa se dispara.

Y hay una asimetría que suele pasar inadvertida: la repetición no se reparte de forma uniforme, se concentra. En casi cualquier producto real un puñado diminuto de peticiones acapara una fracción desproporcionada del volumen —las preguntas frecuentes de verdad, el ejemplo que sale en la documentación, el botón que todo el mundo pulsa al entrar—. Eso significa que no necesitas una tasa de repetición alta en general para que la caché sea rentable: necesitas que la cola corta exista, y casi siempre existe. Conviene además notar que la caché es de red, no por usuario: el primer visitante paga la inferencia y todos los siguientes la aprovechan, así que su valor crece con tu tráfico en lugar de diluirse.

Solo la caché de esta lección tiene la propiedad de ser gratis en ambos ejes. Todo lo demás que veremos en este nivel implica algún compromiso: limitar protege el bolsillo a costa de rechazar peticiones, reintentar mejora la fiabilidad a costa de la latencia, registrar da visibilidad a costa de almacenamiento. Cachear, cuando es correcto hacerlo, no cuesta nada de nada.

Conviene acotar el alcance antes de entusiasmarse: hoy se cachean respuestas de texto e imagen, y solo ante peticiones idénticas. No hay todavía búsqueda semántica, así que dos maneras distintas de formular la misma pregunta son, para la caché, dos preguntas distintas. Eso sitúa el terreno donde brilla —conjuntos de prompts acotados, opciones guiadas, entradas generadas por tu propio código— y donde apenas rasca, que es la conversación libre.

Activar la caché por defecto es una casilla en la configuración del gateway, o el campo cache_ttl si lo creas por API. A partir de ahí toda petición que la admita pasa por ella, y cada respuesta trae la cabecera cf-aig-cache-status con el valor HIT o MISS, que es tu instrumento de medida.

# la respuesta trae cf-aig-cache-status para saber si vino de cache
curl -X POST "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/ai/v1/chat/completions" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "cf-aig-cache-ttl: 3600" \
  --data '{
    "model": "openai/gpt-4.1-mini",
    "messages": [{ "role": "user", "content": "Que es un CDN en dos frases" }]
  }'

La clave de caché: coincidencia exacta

Aquí está el detalle que decide si tu tasa de aciertos será del cuarenta por ciento o del cero. La clave se construye concatenando el proveedor, el endpoint, el modelo, la cabecera de autenticación del proveedor y el cuerpo completo de la petición, y aplicando SHA-256 al resultado. Coincidencia exacta significa exacta: una coma distinta, un valor de temperature diferente, una herramienta más en la lista o una marca de tiempo inyectada en el prompt de sistema producen una clave nueva y, por tanto, un fallo garantizado.

flowchart TB
REQ[Peticion entrante] --> KEY[Clave SHA256 de proveedor endpoint modelo auth y cuerpo]
KEY --> LOOK{Existe en cache}
LOOK -- HIT --> FAST[Respuesta en milisegundos sin coste de tokens]
LOOK -- MISS --> PROV[Se llama al proveedor y se paga la inferencia]
PROV --> STORE[Se guarda segun el TTL]
style FAST fill:#a6e3a1,color:#11111b
style PROV fill:#fab387,color:#11111b

La consecuencia práctica es que cachear bien es sobre todo higiene del cuerpo de la petición. Si tu prompt de sistema incluye la fecha y la hora actuales, acabas de garantizar que ninguna petición se repita jamás. Si envías un identificador de traza dentro del cuerpo, lo mismo. Todo lo que varíe entre peticiones equivalentes debe salir del cuerpo o aceptarás no cachear nunca.

Que la clave incluya la cabecera de autenticación del proveedor tiene además una lectura de seguridad que conviene tener clara: dos claves distintas nunca comparten entradas de caché, así que el aislamiento entre integraciones que usan credenciales separadas es automático. Lo que no aísla es a tus propios usuarios, porque todos ellos comparten la misma clave hacia el proveedor. Esa es exactamente la frontera del riesgo y volveremos a ella al hablar de seguridad.

Otra consecuencia menos evidente es que la caché es del gateway, no de la aplicación. Dos servicios distintos que envíen la misma petición con la misma credencial comparten aciertos sin coordinarse ni saber el uno del otro. Eso multiplica el valor de haber concentrado el tráfico: cuantas más partes de tu producto atraviesen la misma puerta, más se alimentan mutuamente los aciertos.

Cuando esa higiene no es posible, existe la vía de escape: cf-aig-cache-key te deja imponer tu propia clave e ignorar el cuerpo real. Es una herramienta de precisión y de riesgo, porque tú asumes la responsabilidad de que todas las peticiones que compartan clave merezcan de verdad la misma respuesta.

# clave propia: dos peticiones con cuerpos distintos compartiran respuesta
curl -X POST "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/ai/v1/chat/completions" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "cf-aig-cache-key: faq-devoluciones-v3" \
  --header "cf-aig-cache-ttl: 86400" \
  --data '{ "model": "openai/gpt-4.1-mini", "messages": [] }'

El TTL admite desde sesenta segundos hasta un mes, y cf-aig-skip-cache puesto a true fuerza el viaje al proveedor para esa petición concreta, útil cuando el usuario pulsa un botón de regenerar y espera explícitamente una respuesta nueva.

Elegir ese TTL es una decisión más rica de lo que parece, porque en realidad estás fijando cuánta obsolescencia acepta tu producto. Un valor corto captura las ráfagas —el pico de gente que llega a la vez desde el mismo enlace— sin comprometerse a nada a largo plazo, y es casi siempre la elección segura por defecto. Un valor largo solo tiene sentido cuando puedes afirmar que la respuesta correcta no cambia en ese plazo, lo que en la práctica exige que ni el contenido de origen ni el prompt ni el modelo se muevan. Y como el modelo sí se mueve —los proveedores actualizan versiones—, un mes de TTL puede significar servir durante semanas la voz de un modelo que ya jubilaste.

Cuándo es seguro y cuándo no

La pregunta correcta no es si la respuesta cambiará, sino si la respuesta depende de algo que no está en la clave. Si toda la información que determina la salida viaja en el cuerpo, cachear es seguro. Si hay contexto oculto —la identidad del usuario resuelta por una cabecera, unos permisos, la hora, un documento recuperado aparte— entonces dos peticiones con cuerpo idéntico merecen respuestas distintas y la caché te servirá la equivocada.

Ese criterio tiene una virtud: convierte una intuición difusa sobre privacidad en una comprobación mecánica que puedes hacer leyendo el código. Enumera todo lo que la respuesta usa. Táchalo si viaja en el cuerpo. Lo que quede sin tachar es tu lista de razones para no cachear, o tu lista de cosas que tienes que meter en el cuerpo o en la clave antes de hacerlo.

Medir el ahorro en lugar de suponerlo

Una caché activada no es una caché que funcione, y la diferencia entre ambas cosas se mide con un solo número: la proporción de respuestas que llegan con cf-aig-cache-status en HIT. Ese dato aparece en los logs del gateway, se puede filtrar por modelo y por función, y es el primer sitio donde mirar cuando el ahorro prometido no aparece en la factura.

Interpretar ese número exige separar dos magnitudes que se confunden constantemente. El ahorro potencial es qué fracción de tu tráfico son peticiones semánticamente repetidas; depende de tu producto y no lo cambias tocando configuración. El ahorro capturado es qué fracción de esas repeticiones llegan además a compartir clave; depende por completo de la higiene del cuerpo de la petición. Una distancia grande entre ambos no significa que la caché no sirva para tu caso: significa que estás inyectando ruido variable en peticiones que deberían ser idénticas.

// instrumenta el acierto para poder decidir con datos
const respuesta = await fetch(url, opciones);
const estado = respuesta.headers.get("cf-aig-cache-status");

ctx.waitUntil(
  env.METRICAS.writeDataPoint({
    blobs: [funcion, modelo, estado ?? "desconocido"],
    doubles: [Date.now() - inicio],
    indexes: [funcion],
  }),
);

Y hay un tercer número, el más importante de los tres y el que casi nadie calcula: el ahorro en dinero, no en peticiones. Una tasa de aciertos del sesenta por ciento concentrada en tu modelo más barato mueve mucho menos la factura que una del diez por ciento sobre el modelo de razonamiento con contextos enormes. Ordena siempre tus esfuerzos de cacheabilidad por coste evitado y no por volumen evitado; casi nunca coinciden.

Ese orden tiene además una consecuencia agradable sobre la latencia. Los aciertos que más dinero ahorran suelen ser los de las peticiones más pesadas, que son también las más lentas, así que optimizar por coste evitado mejora de paso justo la cola de la distribución que peor experiencia da. Es de las pocas veces en ingeniería en que el criterio económico y el criterio de experiencia apuntan sin esfuerzo al mismo sitio.