Almacenamiento en caché de prefijos largos

Todo prompt largo paga un coste de prellenado para codificar sus tokens antes de generar la respuesta. Cuando el mismo prefijo largo se repite en muchas llamadas —un prompt del sistema, una especificación de herramientas o un documento de referencia extenso—, la caché de prompts permite al proveedor reutilizar el estado de atención ya calculado en lugar de volver a calcularlo.

• Los aciertos de caché reducen drásticamente la latencia y el coste de entrada.
• El ahorro aumenta con el tamaño del prefijo y la frecuencia de reutilización.

Las cachés se basan en una coincidencia exacta del prefijo de tokens desde el principio del prompt. El tramo almacenado en caché va desde el inicio hasta el primer punto de divergencia. Si cambia cualquier elemento al principio, todo lo que viene después deja de aprovechar la caché.

Implicación: el diseño que maximiza los aciertos coloca primero el contenido más estable y deja para el final el contenido más variable.

Organice el contenido de más estable a menos estable: primero las reglas inmutables del sistema y las definiciones de herramientas, después el material de referencia extenso y estable, luego el contexto estable durante la sesión y, por último, la entrada y la pregunta variables de cada solicitud.

• Estable -> al principio (se puede almacenar en caché).
• Variable -> al final (es la única parte que se vuelve a calcular).

Este único principio de ordenación impulsa la mayoría de las ventajas de la caché.

Algunos proveedores permiten marcar puntos de corte explícitos para la caché. Colóquelos al final de cada segmento estable para que el sistema pueda almacenarlo en caché hasta ese punto. Marque como almacenable en caché el bloque estable más grande, como el corpus de referencia o un prompt del sistema extenso.

Sin marcadores explícitos, organice de todos modos la estructura según la estabilidad para que la coincidencia implícita de prefijos siga siendo útil.

Los cambios sutiles y no intencionados rompen la caché silenciosamente: una marca de tiempo en el prompt del sistema, un id de cada solicitud insertado al principio, definiciones de herramientas reordenadas o un orden no determinista de las claves JSON. Cada uno desplaza el prefijo y obliga a recalcularlo por completo.

Audite el prefijo para detectar cualquier elemento que varíe entre llamadas y muévalo después de la región almacenada en caché.

Las cachés caducan después de un tiempo de vida definido por el proveedor y, a menudo, se actualizan con cada acceso. Los fallos en frío reaparecen si las llamadas son demasiado poco frecuentes. En cargas de trabajo en ráfagas y de alta frecuencia, el almacenamiento en caché resulta rentable; en llamadas poco frecuentes y dispersas, la caché puede caducar entre un uso y el siguiente.

Adapte el patrón de tráfico al TTL y considere enviar pings de keep-alive para los prefijos valiosos.

Normalmente, el almacenamiento en caché aplica un pequeño recargo por escribir una entrada de caché y un descuento considerable por leerla. La economía favorece la reutilización: una escritura amortizada en muchas lecturas supone un gran ahorro neto; un uso único que solo escribe puede costar ligeramente más.

• Alta reutilización -> use la caché de forma agresiva.
• Prefijos de un solo uso -> el almacenamiento en caché puede no resultar rentable.

Haga que el prompt del sistema y las especificaciones de las herramientas sean deterministas y estén fijados a versiones concretas. Ordene las definiciones de las herramientas de forma canónica, evite insertar datos dinámicos y modifíquelas únicamente en lanzamientos deliberados. Un bloque estable del sistema se convierte en una entrada de caché duradera y con una tasa de aciertos alta, compartida por todas las solicitudes.

Trate el prefijo almacenado en caché como un artefacto con una versión, no como una cadena que se modifica de manera improvisada.

En los bucles de agentes, la conversación creciente es una caché natural: cada turno amplía un prefijo que el turno siguiente reutiliza. Añada los turnos nuevos al final y no reescriba nunca los anteriores, para que la caché previa siga siendo válida.

Cuando deba compactar la conversación, hágalo de manera que cree un nuevo prefijo estable para los turnos posteriores, en lugar de modificar repetidamente los antiguos.

Instrumente el sistema. La mayoría de los proveedores informan de los tokens de entrada almacenados en caché y no almacenados en caché de cada llamada. Supervise la tasa de aciertos y, si es baja, inspeccione el prefijo en busca de deriva. Una regresión en la tasa de aciertos suele indicar un valor dinámico introducido recientemente al principio del prompt.

• Registre cached_tokens / total_input_tokens.
• Genere una alerta cuando la tasa de aciertos disminuya después de un despliegue.

Para controlar el coste de los prefijos largos: ordene el contenido según su estabilidad, marque el bloque estable más grande como punto de caché, elimine la deriva oculta, fije y versione los bloques del sistema y de las herramientas, añada contenido únicamente al final en los bucles de agentes y supervise la tasa de aciertos. El objetivo es tener un prefijo grande y reutilizable, junto con una cola pequeña y volátil que se recalcule en cada llamada.

Reutiliza un corpus de referencia de 100k tokens en miles de consultas diarias, pero la tasa de aciertos de la caché es casi nula.

El almacenamiento en caché de prompts reutiliza la fase de prellenado de un prefijo exacto y estable, lo que reduce considerablemente la latencia y el coste de entrada cuando la reutilización es frecuente. Ordene el contenido de mayor a menor estabilidad, marque el bloque estable grande como punto de caché y desplace toda la volatilidad a la cola. Elimine la deriva oculta, fije y versione los bloques del sistema y de las herramientas, añada contenido únicamente al final en los bucles de agentes y supervise la tasa de aciertos para que una regresión indique la introducción de un valor variable al principio del prompt.