Ganancias:
- Explicar la lógica de coincidencia de prefijos del almacenamiento en caché de avisos
- Aumenta el acceso al caché al colocar el contexto fijo primero y el contexto variable después
- Puede calcular la economía de escritura/lectura de caché y el punto de equilibrio
Un producto LLM parece barato en prototipo; Cuando te subes a la báscula, la factura sorprende. En la mayoría de las cargas de trabajo, la mayor parte de la factura proviene del mismo contexto fijo que se envía una y otra vez con cada solicitud: un mensaje largo del sistema, un libro de reglas, documentación de referencia. El almacenamiento en caché rápido elimina exactamente este desperdicio. En esta unidad, aprenderá cómo funciona el caché, cómo organizar el mensaje de acierto y cómo calcular el punto de equilibrio de la economía del caché. Cuando se instala correctamente, por sí solo puede reducir su factura a la mitad o incluso menos.
¿Cómo funciona la caché? La única regla inmutable
El almacenamiento en caché rápido es una coincidencia de prefijo. El proveedor almacena temporalmente los tokens que ha procesado desde el comienzo de su solicitud. Si el mensaje comienza con el mismo prefijo en la siguiente solicitud, esta parte común no se vuelve a calcular; Es mucho más económico de leer que el caché.
De esto se sigue una regla inmutable: si un solo byte cambia en cualquier parte del prefijo, todo el caché deja de ser válido a partir de ese punto. Es decir, el contenido fijo debe estar al principio y el contenido variable al final. Si coloca una línea al comienzo del mensaje del sistema que cambia con cada solicitud, como "Fecha de hoy: 18.07.2026", todo lo que está detrás no podrá ingresar al caché.
El orden de procesamiento suele ser: herramientas → aviso del sistema → mensajes. Colocas el punto de caché (punto de interrupción) al final de la sección fija.
Economía de caché
La caché tiene tres niveles de precios:
- Escritura en caché: almacenamiento por primera vez. ~1,25 veces el precio de entrada normal (para almacenamiento de 5 minutos).
- Lectura de caché: lectura de solicitudes posteriores. ~0,1 veces el precio normal de los insumos, es decir, una décima parte.
- Entrada normal: la parte que no ingresa al caché y se procesa al costo total cada vez.
Punto de equilibrio: la primera solicitud paga la prima de suscripción (1,25×). A partir de la segunda solicitud entra en juego la lectura (0,1×). Aproximadamente, estarán codo a codo en dos solicitudes; Después de eso, son ahorros netos. Cuanto mayor sea el contexto fijo y cuantas más solicitudes se reutilicen, mayor será la ganancia.
Guión
¿Funciona el caché?
Aviso de sistema fijo grande, miles de solicitudes
Sí, mayores ganancias
Muchas preguntas sobre los mismos documentos de referencia.
si
Texto breve completamente diferente para cada solicitud.
No, la bonificación por escritura se desperdicia
Solicitud única
No, nada de lectura
Fecha/ID que cambia con cada solicitud en el indicador del sistema
No: el prefijo está roto, el acierto es cero
Paso a paso: ¿Cómo configurar un mensaje de visita?
- Separar constante y variable. ¿Qué contenido nunca cambia (indicador del sistema, libro de reglas, documentación)? ¿Qué cambia con cada solicitud (pregunta de usuario, fecha, ID)?
- Pon la constante al principio. Durante el procesamiento, la pieza que viene primero (herramientas, sistema) debe estar estable.
- Pon la variable al final. Pregunta actual del usuario, última.
- Coloque el letrero al final del borde. Coloque el punto de caché en el último bloque de la parte fija.
- Verificar acierto. Compruebe si cache_read_input_tokens es mayor que cero en el campo de uso de la respuesta. Si es cero, hay un disruptor oculto en el prefijo.
{ "sistema": [ { "tipo": "texto", "texto": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "tipo": "efímero" } } ], "mensajes": [ { "role": "usuario", "contenido": "{{user_current_question}}" } ]}
Consejo: No adivine los aciertos de caché, mídalos. Si use.cache_read_input_tokens sigue siendo cero en solicitudes consecutivas, se está ejecutando un interruptor silencioso (datetime.now() en el indicador del sistema, JSON desordenado, lista de herramientas que cambian con cada solicitud). Compare el mensaje sin formato de las dos solicitudes byte por byte y encuentre la diferencia.
Disruptores silenciosos
Patrones típicos que, sin saberlo, corrompen el caché:
# INTERRUPTOR: incrustar información en el mensaje del sistema que cambia con cada solicitud "Fecha de hoy: {{ahora}}. Eres un asistente..." ← el prefijo cambia con cada solicitud, el resultado es cero# VERDADERO: mueve la variable al sistema de mensajes: "Eres un asistente..." ← la constante ingresa a los mensajes de caché: [{role: usuario, contenido: "Hoy es {{ahora}}. Pregunta: ..."}] ← variable al final
Otros factores decisivos: JSON ordenado de manera diferente en cada solicitud (mantener las claves en un orden fijo), lista de herramientas que varía según el usuario (las herramientas se procesan primero; nada va al caché si cambian), cambio del modelo en mitad de la conversación (los cachés son específicos del modelo).
Aviso débil / Aviso fuerte (estructura compatible con caché)
# Sistema DÉBIL (compilación anti-caché): "Fecha: 18.07.2026 14:32. Usuario: Ahmet (id 8842). Eres un robot de soporte. Reglas: ...(2000 tokens)..."
# Sistema FUERTE (estructura compatible con caché): "Eres un robot de soporte. Reglas: ...(2000 tokens, nunca cambia)..." [signo de caché] mensajes: [ { rol: usuario, contenido: "Fecha: 18.07.2026 14:32. ID de usuario: 8842. Pregunta: ¿cómo inicio mi reembolso?" }]
En la versión débil, el bloque de reglas de 2000 tokens se procesa al costo total en cada solicitud. En la versión segura, el mismo bloque se escribe una vez y se lee en todas las solicitudes posteriores por una décima parte del precio.
Tres mini estuches
Caso 1: Almacenamiento en caché del libro de reglas. Una automatización contable estaba agregando el libro de reglas de 12.000 tokens a cada factura; 5.000 solicitudes por día. La entrada sin caché cuesta ~$180 por día. Mantuvieron el libro de reglas constante y lo almacenaron en caché: las primeras solicitudes pagaron una prima de escritura, las lecturas posteriores 0,1×. El costo de los insumos cayó ~90% a ~$18 por día.
Caso 2: Costo de la línea de fecha oculta. Un equipo creó un caché pero no obtuvo resultados; cache_read_input_tokens siempre fue cero. Motivo: había datetime.now() en la primera línea del mensaje del sistema, el prefijo cambiaba con cada solicitud. Cuando movimos la fecha al mensaje del usuario, la tasa de aciertos aumentó repentinamente del 0% al 94%.
Caso 3: caché extraviado. Una aplicación de búsqueda enviaba consultas breves completamente diferentes con cada solicitud; Agregaron con entusiasmo un letrero de caché. Sin un prefijo común, cada solicitud pagaba solo una prima de escritura, no de lectura, lo que aumentaba el costo. Quitaron el cartel. Lección: el caché solo paga si hay un prefijo grande y constante que se reutiliza.
Errores comunes
- Mezcla de constante y variable: cuando el contenido de la variable está en el prefijo, el resultado se restablece.
- Incrustar fecha/ID en el indicador del sistema: el disruptor silencioso más común.
- No medir el impacto: si no se marca cache_read_input_tokens, no se notará el desperdicio.
- Agregar caché cuando no hay un prefijo público: solo paga la prima de escritura, el costo aumenta.
- Cambio de lista de vehículos o modelo: El prefijo se rompe desde el principio; todo está reescrito.
- Olvidar el tamaño mínimo de caché: los cachés muy cortos (entre 1 y 4 000 tokens, según el modelo) no ingresarán al caché de manera silenciosa.
Más profundo: diseño de caché por tipo de carga de trabajo
El beneficio real del almacenamiento en caché varía según la naturaleza de su carga de trabajo; Así que primero conozca su tráfico. Tres patrones típicos y correcta instalación:
Aviso del sistema común, diferentes preguntas. Patrón empresarial más común: un mensaje de sistema grande (rol, reglas, tal vez documento de referencia) con cientos de preguntas de usuarios diferentes. Aquí la parte fija (sistema) se almacena en caché inicialmente; cada nueva pregunta paga el precio completo sólo por su pequeña porción. La ganancia es muy alta porque la porción grande se recita repetidamente a una décima parte del precio.
Monólogo de varias rondas. A medida que la conversación se prolonga, cada nueva ronda se basa en toda la historia anterior. Si coloca el indicador de caché al final de la última ronda, cada solicitud reutiliza el prefijo de conversación anterior; Las visitas se acumulan a medida que crece la conversación. Esto reduce drásticamente el coste de las largas sesiones de asistente.
El prefijo compartido es el último bit en cambiar. Varias solicitudes comparten un gran conjunto de antecedentes fijos (conjunto de muestra, instrucciones) pero están separadas por una sola pregunta al final. Colocas el puntero de caché al final de la parte compartida; De lo contrario, cada solicitud escribiría su propio caché independiente y no se leería nada.
Una advertencia: el caché depende del modelo y de un tamaño mínimo determinado. Los prefijos muy pequeños (menos de unos pocos miles de tokens, según el modelo) no ingresarán silenciosamente al caché incluso si los marca: cache_creation_input_tokens permanece en cero. Además, cambiar el modelo en mitad de una conversación invalida todo el caché; Si una tarea diferente requiere un modelo económico, mantenga el flujo principal en un modelo y coloque el trabajo secundario en una llamada separada.
En resumen
El almacenamiento en caché rápido es una coincidencia de prefijo: el contenido fijo debe estar al principio, el contenido variable debe estar al final. Para un contexto grande y reutilizado, el costo de lectura es una décima parte del precio total, alcanzando aproximadamente el punto de equilibrio en dos solicitudes. El error más común es corromper el prefijo incrustando datos variables en el indicador del sistema; Verifica el acierto midiéndolo en el campo de uso.
Tarea de aplicación
Elija una carga de trabajo. (1) Divida el contenido en dos columnas: "nunca cambia" y "cambia con cada solicitud". (2) Vuelva a dibujar la estructura del mensaje, colocando la parte constante al principio y la parte variable al final. (3) Calcule el tamaño del token de la parte fija y compare el costo mensual con/sin caché. (4) Tenga en cuenta desde qué campo (cache_read_input_tokens) verificará el resultado.
lista de verificación
- [] Puedo explicar que el caché es la coincidencia de prefijos y la única regla inmutable.
- [] Puedo aumentar la precisión poniendo el contenido fijo al principio y la variable al final.
- [] Sé escribir/leer economía y el punto de equilibrio de dos solicitudes.
- [] Puedo reconocer disruptores silenciosos (fecha, JSON desordenado, cambio de lista de vehículos).
- [] Puedo verificar el resultado con use.cache_read_input_tokens.