Si tu aplicación envía instrucciones o documentos repetidos, conviene estudiar la caché de contexto antes de rediseñar todo el flujo. Lo importante es medir qué parte de la entrada se aprovecha realmente y si esa organización conserva la calidad de la tarea.

Qué confirma la documentación actual

DeepSeek indica que la caché de contexto está activada de forma predeterminada. Para obtener un acierto, una petición debe coincidir completamente con una unidad de prefijo ya guardada. Compartir algunas palabras no basta para asegurar que se aproveche ese fragmento.

La construcción funciona con el mejor esfuerzo del sistema, sin garantizar todos los aciertos. La respuesta sigue generándose: la caché de entrada no equivale a recuperar una respuesta final idéntica.

Organiza lo estable antes de lo variable

Organización propuesta

Conserva el prefijo y cambia la pregunta

Dos solicitudes conservan instrucciones y referencia al principio, y cambian la pregunta al final.Ver imagen a tamaño completo ↗
Organización propuesta para evaluar la caché; compartir un prefijo no garantiza un acierto.

Parte estable: las mismas instrucciones y la misma versión del material. Parte variable: la pregunta específica al final.

Comprueba prompt_cache_hit_tokens y prompt_cache_miss_tokens en usage. Aquí no se presenta una medición ni una cifra de ahorro.

Una organización que puedes evaluar consiste en colocar primero las instrucciones estables y el material de referencia; después, la pregunta específica. Evita introducir un identificador cambiante al comienzo si no aporta información necesaria para la tarea.

Por ejemplo, para trabajar con un catálogo ficticio, prepara una versión fija de sus descripciones y cambia únicamente la consulta sobre ese catálogo. Conserva esa versión durante la comparación. Si corriges el documento entre solicitudes, anota el cambio para no atribuir el resultado a otra causa.

Esta propuesta de organización no garantiza un acierto. Su utilidad se comprueba con los datos de consumo, no con la apariencia del texto enviado.

Qué medir

En usage, DeepSeek publica prompt_cache_hit_tokens y prompt_cache_miss_tokens. Registra ambos y compara varias solicitudes del mismo flujo. Para tu análisis, puedes calcular:

proporción de entrada aprovechada =
tokens con hit / (tokens con hit + tokens con miss)

Calcula esa proporción solo cuando el denominador sea mayor que cero. Una petición aislada puede dar una imagen incompleta. Agrupa los resultados por tipo de tarea y versión del material, y conserva también el consumo total de salida.

Diseña una comparación útil

  1. Elige un conjunto pequeño de preguntas reales o ficticias representativas.
  2. Fija el documento, las instrucciones y el criterio de calidad.
  3. Registra el consumo de cada solicitud y el número de correcciones necesarias.
  4. Prueba una organización alternativa manteniendo lo demás constante.
  5. Compara el coste de la tarea completa, además de la proporción de caché.

Este procedimiento es una propuesta de evaluación. No hemos ejecutado esa comparación ni publicado un porcentaje de ahorro.

Aplicaciones con varios usuarios

La documentación de aislamiento contempla user_id para separar la caché entre usuarios de una aplicación. No incluyas información personal en ese identificador. Revisa el diseño del acceso a documentos antes de optimizar la reutilización.

La caché no sustituye tu autorización de acceso ni justifica mezclar material privado entre usuarios. Para calcular importes con el consumo observado, continúa con precios de DeepSeek API; para revisar el formato de la petición, vuelve a la guía de inicio.

Documentación oficial consultada el 12 de septiembre de 2026. DEspañol es una publicación independiente; los ejemplos son educativos y no se han ejecutado contra la API.