Cuando tu motor de localización traduce texto, una parte del prompt que envía al LLM es idéntica en cada solicitud, y otra cambia de una solicitud a la siguiente. El caché de prompts permite que el motor reutilice la parte estable, en lugar de volver a pagar por procesarla cada 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 arma un prompt de traducción#
Cada solicitud que el motor envía a un modelo se compone de varias capas. Algunas se mantienen estables en todas las solicitudes para el 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 específica | Dinámica: varía según la solicitud | No |
| El texto 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 quiebre de caché: todo lo anterior puede guardarse en caché y reutilizarse, y todo lo posterior —el glosario de cada solicitud, los ejemplos y tu texto de entrada— se envía nuevo en cada solicitud.
Por qué el glosario no se guarda en caché
El glosario se recupera en cada solicitud según el texto exacto que estás traduciendo, así que cambia de una solicitud a otra. Mantenerlo después del punto de quiebre de caché permite que el resto del prompt siga siendo reutilizable, sin importar qué términos del glosario incorpore una solicitud determinada.
Por qué la entrada en caché cuesta menos#
La primera solicitud para un motor e idioma determinados 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 cobran esas lecturas de caché a una fracción de la tarifa normal de tokens de entrada, así que la mayor parte de tu prompt —la que nunca cambia— deja de cobrarse a precio completo en cada solicitud.
La caché dura poco tiempo y la administra el proveedor del modelo, no tu motor. Eso significa que el beneficio es mayor cuando traduces mucho con el mismo motor e idioma en una ventana corta: las solicitudes llegan mientras el prefijo sigue activo y se leen directo desde la caché.
El caché es automático
No tienes que configurar nada. Que una solicitud use caché depende del modelo que la atiende: los modelos de Anthropic y Google usan puntos de quiebre de caché explícitos, los modelos de OpenAI almacenan en caché prefijos largos por su cuenta y algunos proveedores no usan caché en absoluto. El motor aplica el comportamiento correcto según el modelo.
El resultado#
- Menor costo: 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 necesitan reprocesarse, así que las solicitudes con caché activa vuelven más rápido.
- Sin configuración: el caché viene activado por defecto; no hay nada que habilitar en la configuración de tu motor.
Las ganancias se acumulan con tráfico constante sobre el mismo motor e idioma: justo la forma en que funciona un pipeline de localización en producción, donde la misma configuración atiende solicitud tras solicitud.
Cómo leer los tokens de caché en tu uso#
Cada respuesta de traducción reporta 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 hubo nada guardado en caché. |
cacheWriteTokens | Tokens del prompt escritos en la caché en esta solicitud: un fallo de caché o primera llamada. |
La primera solicitud para un motor e idioma normalmente muestra un cacheWriteTokens positivo (el prefijo se está escribiendo) y un cacheReadTokens de 0. Las solicitudes siguientes, mientras la caché sigue activa, invierten eso: cacheReadTokens sube y cacheWriteTokens baja a 0. Haz seguimiento del uso total de tokens en todos tus motores en Reports.
