Última verificación documental y prueba práctica: 5 de agosto de 2026. Los importes se expresan en dólares estadounidenses (USD). Esta es una guía independiente y no oficial.
La API de DeepSeek utiliza una caché de contexto en disco para reutilizar partes ya procesadas de una entrada. La función está activada de forma predeterminada, pero repetir texto no garantiza por sí solo un cache hit: el prefijo debe coincidir con una unidad que ya se haya persistido y el sistema funciona según disponibilidad.
Esta página separa dos niveles de evidencia. Primero resume lo que DeepSeek documenta oficialmente sobre Context Caching. Después presenta resultados observados en 18 solicitudes reales realizadas con deepseek-v4-flash y deepseek-v4-pro. El objetivo no es prometer una tasa universal de aciertos o una mejora fija de velocidad, sino mostrar cómo medir el comportamiento y el coste en una integración concreta.
Para una referencia general de autenticación, endpoints y modelos, consulta la guía de DeepSeek API en español. Para presupuestar otras cargas, utiliza la calculadora y tabla de precios de DeepSeek.
Respuesta rápida
- Context Caching se aplica automáticamente; no hay que activar un parámetro específico.
- Los campos que permiten comprobarlo son
prompt_cache_hit_tokensyprompt_cache_miss_tokens. - En dos repeticiones exactas por modelo, los probes registraron 9.216 tokens con acierto de caché y solo 45 o 46 tokens sin acierto, alrededor del 99,5 % del prompt.
- Con las tarifas base verificadas el 5 de agosto de 2026, el coste estimado de una repetición exacta bajó de
$0.00129696a$0.00003252en Flash y de$0.00402940a$0.00005385en Pro. - Un cache hit no garantizó menor tiempo total en todas las solicitudes. Flash mostró un par más rápido y otro más lento; Pro fue más rápido en sus dos pares, pero la muestra es demasiado pequeña para generalizar.
- Al modificar el documento aproximadamente en el 25 % de su longitud, el único probe realizado por modelo registró cero tokens con acierto. Este resultado describe esas dos solicitudes y no define una regla universal.
Qué documenta DeepSeek sobre la caché de contexto
Según la documentación oficial, cada solicitud puede construir unidades de caché. Una solicitud posterior solo obtiene un acierto cuando reutiliza por completo una unidad de prefijo que ya se ha persistido. DeepSeek describe tres mecanismos de persistencia:
- Límites de solicitud: se crean unidades al final de la entrada del usuario y al final de la salida del modelo.
- Detección de un prefijo común: si varias solicitudes comparten el mismo inicio, el sistema puede persistir esa parte común como una unidad independiente.
- Intervalos fijos en textos largos: el sistema puede crear unidades intermedias para evitar que un prefijo extenso quede sin posibilidad de reutilización.
DeepSeek no publica en esa guía el tamaño exacto de los intervalos internos. Por ello, no es correcto deducir un tamaño de bloque a partir de que en esta prueba aparecieran exactamente 9.216 tokens con acierto.
La misma documentación advierte que la caché funciona según disponibilidad y no garantiza una tasa de aciertos del 100 %. Su construcción puede tardar segundos y, cuando deja de utilizarse, suele eliminarse después de unas horas o unos días. También aclara que la caché solo reutiliza el prefijo de entrada: la respuesta se genera de nuevo y puede variar.
Cómo se realizó la prueba
El archivo de resultados saneado contiene 18 respuestas registradas entre las 20:34:21 y las 20:36:32 UTC del 5 de agosto de 2026. No contiene la clave API ni identificadores de respuesta. Los modelos solicitados y devueltos coincidieron en todos los casos.
| Elemento | Configuración observada |
|---|---|
| Modelos | deepseek-v4-flash y deepseek-v4-pro |
| Solicitudes | 9 por modelo; 18 en total |
| Tamaño de entrada | Entre 9.251 y 9.262 tokens por solicitud |
| Salida | Entre 1 y 5 tokens; 34 tokens de salida en todo el lote |
| Escenarios | Repetición exacta, prefijo común con tres preguntas y modificación aproximada al 25 % del prefijo |
| Repeticiones | Dos pares de repetición exacta por modelo; un flujo de tres preguntas y un par con modificación por modelo |
| Tiempo | Tiempo de extremo a extremo medido por la sesión, no tiempo interno exclusivo de inferencia |
| Coste | Estimación calculada con los tokens informados por la API y las tarifas base oficiales vigentes |
El corpus utilizado fue sintético y en español. Las preguntas del escenario de prefijo común devolvieron los valores ficticios HX-7010, 1340 y Puerto Alba. El registro conserva los conteos y salidas, pero no incluye el texto completo del corpus, un hash del prompt, el intervalo de espera como campo independiente, system_fingerprint ni los identificadores de las respuestas. Estas ausencias se consideran límites de reproducibilidad y se indican de nuevo más adelante.
Resultado global del lote
| Modelo | Solicitudes | Tokens de entrada | Cache hit | Cache miss | Tokens de salida | Coste estimado |
|---|---|---|---|---|---|---|
deepseek-v4-flash |
9 | 83.314 | 36.864 | 46.450 | 17 | $0.00661096 |
deepseek-v4-pro |
9 | 83.305 | 36.864 | 46.441 | 17 | $0.02035024 |
| Total | 18 | 166.619 | 73.728 | 92.891 | 34 | $0.02696120 |
Las 18 solicitudes devolvieron HTTP 200, finish_reason=stop y conteos consistentes: en todos los registros, prompt_tokens fue igual a la suma de los tokens con acierto y sin acierto. El porcentaje agregado de hit del lote no debe interpretarse como una tasa del servicio, porque la mezcla incluye deliberadamente solicitudes frías, calientes y modificadas.
Prueba 1: repetición exacta
En este escenario se envió una entrada inicial o seed y después un probe con la misma entrada. Se realizaron dos pares independientes por modelo.
| Modelo | Réplica | Seed: hit / miss | Probe: hit / miss | Hit del probe | Coste seed → probe | Tiempo seed → probe |
|---|---|---|---|---|---|---|
| V4 Flash | 1 | 0 / 9.262 | 9.216 / 46 | 99,503 % | $0.00129696 → $0.00003252 |
917,0 → 1.261,9 ms |
| V4 Flash | 2 | 0 / 9.262 | 9.216 / 46 | 99,503 % | $0.00129696 → $0.00003252 |
1.037,6 → 882,4 ms |
| V4 Pro | 1 | 0 / 9.261 | 9.216 / 45 | 99,514 % | $0.00402940 → $0.00005385 |
1.654,5 → 1.182,8 ms |
| V4 Pro | 2 | 0 / 9.261 | 9.216 / 45 | 99,514 % | $0.00402940 → $0.00005385 |
1.978,6 → 1.065,2 ms |
Con una salida de un token en todas estas solicitudes, la reducción del coste estimado fue del 97,493 % en Flash y del 98,664 % en Pro. Dicho de otra forma, el probe costó aproximadamente 39,88 veces menos que el seed en Flash y 74,83 veces menos en Pro.
El resultado económico fue consistente en los cuatro pares, pero el tiempo no lo fue. El promedio de los dos seeds de Flash fue 977,3 ms y el de los probes 1.072,2 ms: un probe fue más rápido y otro más lento. En Pro, el promedio pasó de 1.816,6 a 1.124,0 ms y ambos probes fueron más rápidos. Con solo dos pares por modelo no se puede atribuir esa diferencia exclusivamente a la caché ni convertirla en una promesa de latencia.
Prueba 2: prefijo común con preguntas diferentes
El segundo escenario conservó un prefijo extenso y formuló tres preguntas distintas. El primer paso fue totalmente miss. En esta ejecución, el segundo y el tercer paso ya reutilizaron 9.216 tokens en ambos modelos.
| Modelo | Paso | Salida | Prompt | Hit | Miss | Porcentaje hit | Tiempo | Coste estimado |
|---|---|---|---|---|---|---|---|---|
| V4 Flash | Pregunta 1 | HX-7010 |
9.253 | 0 | 9.253 | 0 % | 1.172,8 ms | $0.00129682 |
| V4 Flash | Pregunta 2 | 1340 |
9.255 | 9.216 | 39 | 99,579 % | 1.153,5 ms | $0.00003182 |
| V4 Flash | Pregunta 3 | Puerto Alba |
9.252 | 9.216 | 36 | 99,611 % | 2.314,8 ms | $0.00003196 |
| V4 Pro | Pregunta 1 | HX-7010 |
9.252 | 0 | 9.252 | 0 % | 1.917,0 ms | $0.00402897 |
| V4 Pro | Pregunta 2 | 1340 |
9.254 | 9.216 | 38 | 99,589 % | 1.506,5 ms | $0.00005168 |
| V4 Pro | Pregunta 3 | Puerto Alba |
9.251 | 9.216 | 35 | 99,622 % | 1.951,6 ms | $0.00005211 |
La guía oficial incluye un ejemplo pedagógico donde dos preguntas sobre el mismo documento pueden ser miss antes de que una tercera reutilice el prefijo común. En nuestra ejecución, la segunda pregunta ya obtuvo un hit. No es una contradicción demostrada: el comportamiento depende de qué unidades se hayan persistido, de los límites exactos de la solicitud y del tiempo de construcción. El registro saneado no expone la unidad interna que produjo el acierto.
La tercera pregunta de Flash ilustra además por qué no debe confundirse cache hit con velocidad garantizada: reutilizó el 99,611 % del prompt, pero tardó 2.314,8 ms, más que la primera pregunta sin acierto.
Prueba 3: cambio aproximado al 25 % del prefijo
El tercer escenario calentó una entrada y después modificó el texto aproximadamente en el 25 % de su longitud. En el único par realizado por modelo, el probe no registró ningún token con acierto.
| Modelo | Paso | Prompt | Hit | Miss | Tiempo | Coste estimado |
|---|---|---|---|---|---|---|
| V4 Flash | Seed | 9.253 | 0 | 9.253 | 1.342,3 ms | $0.00129570 |
| V4 Flash | Probe modificado | 9.253 | 0 | 9.253 | 4.821,3 ms | $0.00129570 |
| V4 Pro | Seed | 9.252 | 0 | 9.252 | 2.356,4 ms | $0.00402549 |
| V4 Pro | Probe modificado | 9.252 | 0 | 9.252 | 2.717,1 ms | $0.00402549 |
Este resultado no significa que cualquier cambio situado al 25 % invalide siempre toda la caché. Solo se probó una modificación por modelo, el servicio funciona según disponibilidad y no conocemos los límites de las unidades persistidas. Para establecer una relación entre la posición del cambio y los tokens reutilizados harían falta más posiciones, más réplicas y namespaces aislados.
Cómo leer los campos de uso
La referencia de Chat Completions define estas relaciones:
prompt_tokens = prompt_cache_hit_tokens + prompt_cache_miss_tokens
total_tokens = prompt_tokens + completion_tokensLa tasa descriptiva de acierto para una solicitud puede calcularse así:
cache_hit_rate = prompt_cache_hit_tokens / prompt_tokensEs preferible guardar los valores absolutos además del porcentaje. Una tasa alta sobre un prompt pequeño y una tasa alta sobre cientos de miles de tokens tienen consecuencias económicas distintas.
En una aplicación real también conviene registrar el modelo solicitado, el modelo devuelto, la fecha UTC, system_fingerprint, el tiempo total y un hash del prefijo. Nunca se debe guardar la clave API en logs. Si la API devuelve un código distinto de 200, consulta el diagnóstico de errores de DeepSeek API y no cuentes esa solicitud como un hit o miss válido.
Cómo se calculó el coste
La tabla oficial de modelos y precios mostraba estas tarifas base el 5 de agosto de 2026:
| Concepto | V4 Flash | V4 Pro |
|---|---|---|
| Entrada, cache hit | $0.0028 |
$0.003625 |
| Entrada, cache miss | $0.14 |
$0.435 |
| Salida | $0.28 |
$0.87 |
La fórmula empleada fue:
coste =
(hit_tokens / 1.000.000 × precio_hit)
+ (miss_tokens / 1.000.000 × precio_miss)
+ (completion_tokens / 1.000.000 × precio_salida)Los importes de esta página son estimaciones aritméticas basadas en el usage devuelto por la API, no una factura ni una captura del saldo. DeepSeek ha anunciado una política futura de precios 2× durante determinadas horas punta, pero la fecha efectiva seguía pendiente en la documentación consultada. Si esa política entra en vigor, cualquier prueba nueva deberá aplicar la tarifa correspondiente y registrar la zona horaria.
Buenas prácticas para favorecer la reutilización
- Coloca primero las instrucciones, políticas y documentos que se repiten; añade después la pregunta o tarea variable.
- Mantén estable el texto reutilizable. Cambiar espacios, encabezados, orden o contenido puede alterar la tokenización y el prefijo efectivo.
- No insertes timestamps, identificadores aleatorios o metadatos variables antes del documento que quieres reutilizar.
- Comprueba los campos de uso en cada respuesta. No deduzcas un hit solo porque el texto parece idéntico.
- Calcula el presupuesto con una hipótesis conservadora de cache miss; trata el ahorro como un resultado observado, no como una garantía.
- Separa usuarios con
user_idcuando corresponda. DeepSeek documenta que este campo proporciona aislamiento de KVCache y no debe contener información privada. - No confundas Context Caching con memoria conversacional. Chat Completions sigue siendo una API sin estado: la aplicación debe enviar el historial relevante.
La familia y los límites actuales se explican con más detalle en la página de DeepSeek V4 Flash y Pro.
Límites de esta prueba
- La muestra fue pequeña: dos repeticiones exactas, un flujo de prefijo común y una modificación por modelo.
- No se probaron otros tamaños de prompt, cambios en varias posiciones, concurrencia ni carga sostenida.
- No se midió la persistencia después de una hora, un día o varios días.
- No se probó de forma controlada el aislamiento entre valores de
user_id; esa parte se describe únicamente según la documentación oficial. - No se midió streaming ni tiempo hasta el primer token.
end_to_end_msincluye red, programación del servicio y generación. - El archivo saneado no conserva los prompts completos, hashes, request IDs,
system_fingerprintni el intervalo de espera como campo independiente. - Los precios pueden cambiar. Los cálculos utilizan las tarifas base verificadas el 5 de agosto de 2026.
- Un acierto de caché no demuestra que la respuesta sea correcta, estable o apropiada para un caso de uso.
Por estas razones, los resultados deben leerse como observaciones fechadas y reproducibles en parte, no como un SLA, una garantía de ahorro o un benchmark general de velocidad.
Preguntas frecuentes
¿Hay que activar Context Caching en DeepSeek?
No. DeepSeek indica que está habilitado de forma predeterminada para todas las personas usuarias de la API. La aplicación solo necesita enviar solicitudes normalmente y revisar los campos de uso.
¿Cómo sé si una solicitud obtuvo un cache hit?
Consulta prompt_cache_hit_tokens. Los tokens de entrada que no se reutilizaron aparecen en prompt_cache_miss_tokens. La suma de ambos debe coincidir con prompt_tokens.
¿Repetir exactamente el mismo prompt garantiza un hit?
No. En nuestros cuatro probes exactos apareció un hit cercano al 99,5 %, pero DeepSeek describe la función como best effort y no garantiza un 100 %. El resultado debe medirse en cada carga real.
¿Por qué quedaron 45 o 46 tokens como miss en las repeticiones exactas?
El registro confirma esos valores, pero no permite atribuirlos a una causa interna concreta. La documentación no promete que todo el prompt pase a hit. No es correcto inventar una explicación sobre plantillas internas o tamaños de bloque.
¿Un cache hit devuelve la misma respuesta anterior?
No. La caché reutiliza el prefijo de entrada. DeepSeek indica que la salida se vuelve a generar y puede estar influida por parámetros como la temperatura.
¿Un cache hit siempre reduce la latencia?
No se puede garantizar. En esta muestra, los dos probes de Pro fueron más rápidos que sus seeds, mientras que Flash produjo un par más rápido y otro más lento. La cola del servicio, la red y la generación de salida también afectan el tiempo total.
¿Cambiar una palabra invalida toda la caché?
La regla oficial es que una solicitud debe coincidir por completo con una unidad de prefijo ya persistida. En nuestro único cambio aproximado al 25 %, el probe tuvo cero tokens con hit en ambos modelos. Hace falta una matriz más amplia para saber cómo responde otra posición o estructura.
¿Cuánto tiempo conserva DeepSeek una unidad de caché?
La documentación dice que, cuando deja de utilizarse, suele eliminarse después de unas horas o unos días. No publica una duración fija y esta prueba no midió la caducidad.
¿Para qué sirve user_id?
DeepSeek documenta que user_id separa usuarios para gestión de seguridad, aislamiento de KVCache y programación de solicitudes. Debe ser una cadena sin datos personales. Esta función no se verificó experimentalmente en el lote descrito.
¿Context Caching sustituye una política de privacidad o retención?
No. Es una función técnica de procesamiento y facturación. El aislamiento de KVCache no equivale por sí solo a una garantía de retención cero, eliminación inmediata o cumplimiento normativo.
Fuentes oficiales consultadas
- Context Caching: reglas de persistencia, ejemplos, campos de uso, best effort y duración habitual.
- Models & Pricing: tarifas base de cache hit, cache miss y salida.
- Token & Token Usage: los conteos de uso devueltos por el modelo son la referencia efectiva.
- Rate Limit & Isolation: aislamiento de KVCache mediante
user_id. - Create Chat Completion: esquema de respuesta y definición de los campos
usage.
Registro de actualización
| Fecha | Cambio |
|---|---|
| 5 de agosto de 2026 | Primera versión basada en 18 solicitudes reales: repetición exacta, prefijo común y modificación aproximada al 25 % en V4 Flash y V4 Pro. |