Prompt caching: cómo reducir coste y latencia de LLM sin servir respuestas equivocadas

La keyword principal es prompt caching; la intención es técnica: un equipo que ya paga tokens y espera varios segundos quiere reutilizar instrucciones, schemas de tools o contexto estable sin bajar calidad ni confundirlo con una caché de respuestas.

OpenAI documenta un mínimo de prefijo visible cacheable de 1.024 tokens para GPT-5.6 y posteriores; modelos anteriores pueden exigir 2.048. Anthropic permite puntos de corte explícitos con cache_control. Las cifras son detalles de proveedor: la arquitectura que sobrevive es mantener lo compartido al principio y medir tokens cacheados en cada respuesta.

El orden de tu request decide el ahorro

Ordena por estabilidad, no por conveniencia del código: versión de sistema y política, definiciones de tools, ejemplos compartidos, corpus versionado y solo después identidad, permisos, pregunta, fecha, estado de conversación y resultados de tools. Si interpolas el email o un timestamp en la primera línea, conviertes todo lo que sigue en un prefijo distinto.

Versiona cada bloque estable. Un cambio deliberado en policy:v7 o tools:v12 debe invalidar la caché; un cambio accidental de espacios, orden de JSON o una descripción generada en caliente no. Serializa los schemas de forma canónica y prueba que dos requests que deberían compartir prefijo tienen el mismo hash antes de culpar al proveedor.

No alargues un prompt corto solo para superar un umbral. El coste de una primera escritura puede ser mayor que el input normal. Calcula el punto de equilibrio con tráfico real: longitud del prefijo, precio de write/read, solicitudes que lo reutilizan y caída de latencia. Cachear sin repetición es una optimización que paga el primer usuario y no cobra el segundo.

const stablePrefix = [{ role: "system", content: POLICY_V7 }, { role: "system", content: TOOL_SCHEMAS_V12 }]; const response = await client.responses.create({ model: "gpt-5.6", input: [...stablePrefix, { role: "user", content: "actor=" + actor.id + "; question=" + question }], prompt_cache_key: "support:" + POLICY_VERSION + ":" + TOOLS_VERSION, store: false }); metrics.observe("llm.cached_tokens", response.usage?.input_tokens_details?.cached_tokens ?? 0);

Anthropic: breakpoints y TTL sin suposiciones

Anthropic permite marcar el final de un bloque reutilizable con cache_control. Sus docs ordenan el prefijo como tools, system y messages; cambiar cualquier bloque antes del breakpoint cambia el hash acumulado. Es útil cuando instrucciones y tools cambian a una frecuencia distinta del contexto RAG o del historial.

Caché semántica: otro producto, otra frontera

Una caché semántica embebe una pregunta y devuelve una respuesta anterior si supera un umbral de similitud. Sirve para una FAQ pública y estable donde dos formulaciones tienen la misma respuesta validada. Reduce llamadas completas, pero no reproduce el razonamiento ni las tools del request actual.

No la actives por defecto delante de un agente. LiteLLM advierte que está pensada para single-shot y que tráfico multi-turn o agentic puede reproducir respuestas obsoletas. Una respuesta a un pedido depende de identidad, permisos, hora y datos vivos aunque la frase sea muy similar a otra pregunta.

La clave de seguridad no puede ser solo el embedding. Incluye como mínimo tenant, usuario o grupo autorizado, versión de política, idioma, modelo, versión de base de conocimiento y clase de consulta. Aplica TTL pequeño e invalida al cambiar documentación, precio, permisos o resultado de una tool. Si no puedes explicar el scope de un hit, trátalo como miss.

Ejecuta un experimento por clase de tráfico, no un cambio global. Empieza con una ruta de alto volumen y prefijo largo; compara dos semanas con control. Después revisa una muestra humana de respuestas y casos de seguridad. Ahorrar tokens de una respuesta equivocada es una falsa economía.

Fallos comunes que revisaría en un PR

• Añadir fecha, UUID de request, email o JSON no canónico antes del bloque común y esperar cache hits.
• Contar cualquier descuento de proveedor como caché semántica o cualquier cache hit de prompt como una respuesta reutilizada.
• Cachear outputs de tools, resultados de RAG con ACL o conversaciones enteras solo porque su embedding supera 0,8.
• Compartir una bucket semántica por API key cuando varios usuarios usan esa key; la identidad debe entrar en el scope autenticado.
• No versionar policy, schemas, modelo ni knowledge base; una entrada válida ayer no tiene por qué serlo después de un deploy.
• Medir solo hit rate y no coste del write, P95, precisión, edad, invalidación, fugas y bypasses de cache.