gemini-3
Gemini 3: cuándo usar la caché de contexto
Gemini3 Team · 14 de octubre de 2026 · 8 min read
Keywords: caché de contexto gemini, optimización api gemini, gestión de tokens gemini
Published: 14 de octubre de 2026 Author: Gemini3 Team
La entrada repetida es la señal para investigar
Supongamos que su equipo hace veinte preguntas diferentes sobre el mismo manual de producto. Enviar el manual completo con cada solicitud puede repetir una gran cantidad de entrada. La caché de contexto vale la pena investigarla cuando el material compartido es sustancial, estable y reutilizado. Es menos convincente cuando cada solicitud usa un documento corto diferente.
Esta guía ofrece un proceso de decisión para usuarios de la API de Gemini, con un escenario original de manual y diagramas editoriales. No informa ahorros medidos, no promete respuestas más rápidas ni describe un interruptor de caché dentro de MidassAI Chat. Un servicio de chat de terceros puede implementar su propio manejo de contexto; verifique su comportamiento documentado por separado.
Primero elija la API que usa realmente. La documentación de caché de Interactions actual de Google describe la caché implícita. Su documentación de caché de generateContent también describe objetos de caché explícitos para los modelos Gemini 3 y 2.5 compatibles. No copie instrucciones de caché explícita en una integración de Interactions.
¿Qué debería permanecer igual entre preguntas?
En la ilustración, el bloque azul es la misma revisión del manual. Los tres bloques más pequeños son preguntas diferentes. Este es el patrón a buscar: material común primero, material específico de la tarea después. El diagrama explica la organización de la solicitud, no una garantía de que una solicitud alcanzará una caché implícita.
Un contexto compartido efectivo es un paquete deliberado: el texto del manual, un identificador de versión y las instrucciones que genuinamente aplican a cada pregunta. Evite colocar una marca de tiempo cambiante, un identificador aleatorio o un saludo no relacionado frente al material estable. Mantenga los identificadores de registro de la aplicación fuera de la entrada del modelo cuando no sirven para ningún propósito de razonamiento.
Antes de optimizar, responda tres preguntas. ¿La fuente cambia durante la sesión? ¿Tiene cada usuario permiso para usar todo el paquete? ¿Puede su aplicación rastrear cada respuesta hasta la revisión de la fuente? Si alguna respuesta no es clara, corrija la selección de la fuente y los controles de acceso antes de intentar reducir los tokens repetidos.
Dos mecanismos, diferentes responsabilidades
| Pregunta | Caché implícita | Caché explícita |
|---|---|---|
| ¿Quién gestiona el objeto de caché? | No hay objeto que crear en su aplicación | Su aplicación crea y referencia una caché |
| ¿Se garantiza la reutilización con un prompt similar? | No; inspeccione el uso real | Verifique la referencia de caché y el uso devuelto |
| ¿Qué ruta de API importa aquí? | Siga la guía de caché de la API actual | Use modelos y métodos de generateContent compatibles |
| ¿Qué debe planificar? | Prefijos compartidos estables y medición | Versiones de fuente, caducidad, limpieza y costo total |
La documentación de Google dice que la caché implícita está habilitada por defecto para los modelos Gemini 2.5 y posteriores, sujeto a umbrales de entrada específicos del modelo. Recomienda colocar el material común al principio y enviar prefijos similares cerca uno del otro. El umbral es un conteo de tokens, no un conteo de palabras o una estimación de tamaño de archivo. Busque el modelo compatible exacto en lugar de asumir que cada variante de Gemini 3 tiene límites idénticos.
La caché explícita agrega trabajo de ciclo de vida. La guía actual de generateContent describe un TTL predeterminado de una hora cuando no se especifica una duración, y distingue la duración de tokens almacenados de la entrada en caché y otros cargos de solicitud. Estos son comportamientos de la API, no una garantía sobre su factura final. Vuelva a verificar la documentación del modelo y la API relevante antes de la implementación.
Una sesión de manual con un final claro
Este es un ejemplo de planificación reproducible, no un experimento de producción grabado. El equipo tiene la revisión 7 del manual, espera una sesión de revisión corta y quiere respuestas a tres preguntas: qué cambió en la incorporación, qué excepciones necesitan aprobación y dónde aparece el procedimiento de escalación.
Para la caché implícita, organice cada solicitud alrededor del mismo prefijo de fuente estable y varíe la pregunta después. Registre el uso devuelto para cada respuesta. La entrada similar es una oportunidad para la reutilización; solo el uso real puede decirle qué sucedió.
Para la caché explícita en una integración de generateContent compatible:
- Prepare una revisión del manual limpia y aprobada y cuente sus tokens con las herramientas apropiadas.
- Verifique el soporte de caché y los límites del modelo antes de crear un recurso.
- Cree una caché con una vida útil elegida deliberadamente y guarde su identificador, modelo y revisión de fuente.
- Referencie esa caché para las preguntas, manteniendo el modelo seleccionado consistente con la caché.
- Registre el uso devuelto y revise las respuestas contra el manual.
- Elimine la caché cuando termine la revisión, o deje que la caducidad elegida maneje la vida útil planificada.
La aplicación debe implementar estos pasos; un prompt de lenguaje natural no puede crear o gestionar una caché por sí solo. Mantenga las credenciales de la API en el servidor y fuera de artículos, código del lado del cliente y registros de análisis.
Los cambios de versión requieren una nueva decisión
La ilustración del ciclo de vida muestra un cambio de revisión como una rama, no como una edición de contenido en el lugar. La guía de generateContent de Google permite actualizar la caducidad o el TTL, pero no el contenido en caché en sí. Si la revisión 8 del manual cambia la respuesta, construya un nuevo contexto aprobado y deje de enrutar nuevas preguntas a la revisión antigua.
Un registro de aplicación útil asocia el identificador de caché con una suma de comprobación de la fuente, modelo exacto, tiempo de creación, caducidad y alcance de acceso. Esta es una recomendación de registro administrativo de la aplicación, no una lista de campos prometidos por la API de Gemini. Nunca asuma que un nombre para mostrar legible por humanos identifica únicamente el documento correcto.
También separe la limpieza de la caché de la retención de documentos. Eliminar una caché no es evidencia de que cada archivo de fuente subido, copia local o registro haya sido eliminado. Aplique sus propias reglas de retención a cada ubicación. La documentación permite recuperar metadatos de caché, no leer el contenido almacenado de vuelta como un archivo de documentos, así que mantenga su fuente autoritativa bajo sus controles existentes.
Compare la carga completa de trabajo, no un número atractivo
Use una pequeña hoja de evaluación antes de decidir si retener una caché explícita. Mantenga la revisión de la fuente, las preguntas y el modelo constantes. Registre la duración de la sesión y el uso real en lugar de inventar un porcentaje de descuento.
| Registro | Por qué importa |
|---|---|
| API, modelo y revisión de fuente exactos | Mantiene comparables dos pruebas |
| Número de preguntas realmente hechas | Mide la reutilización en lugar de la demanda esperada |
| Uso de entrada con caché y sin caché | Muestra dónde ocurrió la reutilización |
| Uso de salida | Capturar la entrada no elimina el trabajo de salida |
| Vida útil de la caché y cargos de almacenamiento | Los períodos de inactividad largos pueden cambiar el resultado |
| Comprobaciones de respuestas y fallos | Un menor costo no es útil si la revisión incorrecta responde |
Calcule el total con los términos de facturación actuales para su cuenta, modelo y API. Incluya cargos de creación de caché o procesamiento de entrada donde corresponda, duración de almacenamiento, tokens de preguntas sin caché y salida generada. Compare ese total contra la misma carga de trabajo sin una caché gestionada explícitamente. La reutilización implícita también puede afectar la línea base, así que no etiquete una línea base como "sin caché" sin inspeccionar su uso real.
Este artículo deliberadamente no proporciona ninguna tabla de precios actual: los precios y la disponibilidad del modelo pueden cambiar independientemente del flujo de trabajo. Use la página de precios oficial para los importes que aplican cuando ejecuta su evaluación.
Reconozca cuándo la caché es el siguiente paso incorrecto
Una pregunta corta única, un paquete de fuente en constante cambio o un proyecto sin un mapa de versión de documento confiable pueden ganar más con una mejor selección de entrada. Elimine páginas irrelevantes, divida tareas independientes y pruebe la calidad de la respuesta primero. No rellene un prompt meramente para cruzar un umbral de caché; eso cambia la carga de trabajo y puede frustrar el propósito de la optimización.
Si una caché caduca a mitad de la sesión, maneje el fallo explícitamente. Recargue la revisión de fuente prevista y vuelva a crear el recurso solo si el trabajo restante lo justifica. No sustituya silenciosamente otro documento o siga reintentando la misma referencia caducada. Preserve la pregunta para que el usuario pueda recuperarse sin adivinar qué se perdió.
Finalmente, la caché reutiliza la entrada; no valida la respuesta ni aumenta la ventana de contexto más allá de los límites del modelo. Para salidas que otro programa debe consumir, empareje el plan de reutilización con un flujo de trabajo de validación de salida estructurada. Una fuente bien organizada y un resultado verificado resuelven diferentes partes del mismo problema de fiabilidad.