Cuando tu motor de localización traduce texto, una parte del prompt que envía al LLM es idéntica en todas las solicitudes, y otra cambia de una a otra. El almacenamiento en caché de prompts permite que el motor reutilice la parte estable en lugar de pagar por procesarla una y otra vez. Esos tokens reutilizados aparecen en tu uso como tokens de caché y cuestan una fracción de los tokens de entrada normales.
Cómo se construye un prompt de traducción#
Cada solicitud que el motor envía a un modelo se compone de varias capas. Algunas son estables en todas las solicitudes del mismo motor e idioma; una es dinámica y cambia en cada solicitud.
| Capa | Estable o dinámica | En caché |
|---|---|---|
| Prompt del sistema: identidad del motor, reglas de localización, gramática | Estable en todos los motores | Sí |
| Tus instrucciones y voz de marca, por idioma | Estable hasta que edites el motor | Sí |
| Términos del glosario recuperados para esta solicitud concreta | Dinámica: varía según la solicitud | No |
| El texto que se va a traducir | Dinámica | No |
Las capas estables forman un prefijo contiguo al inicio del prompt. El motor marca el final de ese prefijo como un punto de corte de caché: todo lo anterior puede almacenarse en caché y reutilizarse, y todo lo posterior —el glosario de cada solicitud, los ejemplos y tu texto de entrada— se envía como nuevo en cada solicitud.
Por qué el glosario no se almacena en caché
El glosario se recupera en cada solicitud en función del texto exacto que estás traduciendo, por lo que cambia de una solicitud a otra. Mantenerlo después del punto de corte de caché permite que el resto del prompt siga siendo reutilizable, independientemente de los términos del glosario que incorpore una solicitud concreta.
Por qué la entrada en caché es más barata#
La primera solicitud para un motor e idioma concretos escribe el prefijo estable en la caché del proveedor. Cada solicitud posterior que reutiliza ese prefijo lo lee de la caché en lugar de volver a procesarlo desde cero. Los proveedores facturan las lecturas de caché por una fracción de la tarifa normal de los tokens de entrada, así que la mayor parte de tu prompt —la que nunca cambia— deja de cobrarse al precio completo en cada solicitud.
La caché dura poco y la gestiona el proveedor del modelo, no tu motor. Eso significa que el beneficio es mayor cuando traduces mucho con el mismo motor e idioma en un intervalo breve: las solicitudes llegan mientras el prefijo sigue activo y se leen directamente desde la caché.
La caché es automática
No tienes que configurar nada. Que una solicitud use caché depende del modelo que la procese: los modelos de Anthropic y Google usan puntos de corte de caché explícitos, los de OpenAI almacenan en caché por su cuenta los prefijos largos y algunos proveedores no usan caché en absoluto. El motor aplica el comportamiento adecuado en función del modelo.
Qué ganas con ello#
- Menor coste: el prefijo estable se paga una vez al precio completo y, a partir de ahí, a la tarifa reducida de lectura de caché en cada solicitud repetida.
- Menor latencia: los tokens en caché no tienen que volver a procesarse, así que las solicitudes con la caché activa llegan más rápido.
- Sin configuración: la caché está activada por defecto; no hay nada que habilitar en la configuración de tu motor.
Las ventajas se multiplican con un tráfico constante sobre el mismo motor e idioma: justo la forma que tiene un flujo de localización en producción, donde la misma configuración gestiona solicitud tras solicitud.
Cómo interpretar los tokens de caché en tu uso#
Cada respuesta de traducción incluye un desglose de uso que separa los tokens de caché de la entrada nueva:
{
"usage": {
"inputTokens": 1200,
"outputTokens": 800,
"cacheReadTokens": 950,
"cacheWriteTokens": 0
}
}| Campo | Significado |
|---|---|
inputTokens | Tokens del prompt procesados como nuevos en esta solicitud |
outputTokens | Tokens generados por el modelo |
cacheReadTokens | Tokens del prompt servidos desde la caché del proveedor. 0 cuando no había nada almacenado en caché. |
cacheWriteTokens | Tokens del prompt escritos en la caché en esta solicitud: un fallo de caché / primera llamada. |
La primera solicitud de un motor e idioma suele mostrar un valor positivo en cacheWriteTokens (el prefijo se está escribiendo) y cacheReadTokens de 0. Las solicitudes posteriores, mientras la caché siga activa, invierten la situación: cacheReadTokens sube y cacheWriteTokens baja a 0. Haz un seguimiento del uso total de tokens en todos tus motores en Informes.
