DeepSeek V4.1 Flash: cómo comprobar si su caché comprimida reduce el coste real de un agente

Qué afirma DeepSeek y qué queda por demostrar

La pregunta útil para un equipo que evalúa un agente no es solo cuánta memoria necesita el modelo para conservar su contexto. Es si una tarea concreta, bajo condiciones repetibles, termina con menos coste, en menos tiempo y con una calidad aceptable. DeepSeek presenta V4.1 Flash como un modelo con una arquitectura que reduce la huella de la caché de claves y valores, o caché KV. Su ficha técnica indica que, frente a V4 Flash, la caché KV persistente es aproximadamente una octava parte para una secuencia de igual longitud. También describe ocho mil millones de parámetros activos durante el prellenado del contexto y dieciséis mil millones durante la generación.

Estas cifras son declaraciones del fabricante y describen características técnicas del modelo. No son, por sí mismas, una demostración de que un agente complete una tarea a menor coste o con menor latencia. El gasto final depende, entre otros factores, de cómo se factura la entrada y la salida, de cuánto contexto se reutiliza, de las llamadas a herramientas y de cuántos intentos hacen falta para obtener un resultado válido. El tiempo total incorpora además operaciones que no se reducen necesariamente junto con la caché.

La diferencia es importante para no convertir una ventaja de infraestructura en una conclusión de producto. Una caché menor puede facilitar el manejo de contextos largos o reducir recursos persistentes en una implementación. Para saber si eso beneficia a una aplicación, hay que medir el recorrido completo: desde la solicitud inicial hasta que la tarea supera una validación previamente definida.

Arquitectura asimétrica y caché KV: qué mide cada dato

La caché KV conserva estados calculados a partir de tokens anteriores para que el modelo pueda continuar procesando una secuencia sin reconstruir desde cero todo lo ya leído. En una conversación o un agente con historial extenso, ese estado puede crecer a medida que se añaden instrucciones, resultados de herramientas y documentos. Reducir su huella puede ser relevante para la memoria persistente y para la gestión de secuencias largas. No elimina, sin embargo, los pesos del modelo ni hace desaparecer el procesamiento de las entradas nuevas.

DeepSeek describe una arquitectura asimétrica: el número de parámetros activos por token cambia entre el prellenado de la entrada y la fase de generación. En su material técnico aparecen ocho mil millones de parámetros activos en prefill y dieciséis mil millones en decode. Es una descripción de cómo se distribuye el cómputo en esas fases, no una medida directa de segundos ahorrados ni una tarifa. Para conocer su efecto en una carga propia se necesitan datos de ejecución en esa carga.

El informe también describe SWA Bounded Replay: el sistema reconstruye determinados estados de la caché SWA reproduciendo los tokens más recientes, en vez de conservar todos esos estados de forma persistente en SSD. La decisión incorpora un intercambio entre almacenamiento persistente y trabajo de reconstrucción. Por eso, incluso cuando baja la huella guardada, no basta con contar bytes: conviene observar si la reconstrucción afecta al tiempo, a la memoria durante la ejecución o a la capacidad de atender solicitudes concurrentes. Las fuentes aportadas describen el mecanismo, pero no aportan una garantía de mejora idéntica para cualquier despliegue.

La documentación disponible no permite tratar la reducción de caché como un multiplicador universal del ahorro. La cifra compara la caché persistente con la generación anterior bajo una longitud de secuencia equivalente. No establece qué proporción del coste total representa esa caché en una aplicación concreta, ni aporta una medición de coste por tarea para todas las combinaciones de contexto, herramientas y entrada visual.

La unidad de análisis debe ser la tarea aceptada

Comparar el coste de una llamada aislada puede inducir a error cuando el sistema opera como agente. Una tarea puede requerir varias consultas al modelo, ejecutar herramientas, corregir una respuesta y volver a intentarlo. Si una configuración produce respuestas más rápidas pero necesita más reintentos, la latencia y el gasto por resultado útil pueden empeorar. A la inversa, una llamada individual algo más costosa podría evitar pasos posteriores. El indicador principal debe incluir el conjunto de trabajo necesario para alcanzar un resultado aceptable.

Antes de ejecutar el ensayo, el equipo debe definir qué significa «aceptable» para cada tarea. Puede ser, por ejemplo, que un cambio propuesto pase pruebas, que una extracción incluya los campos obligatorios o que una respuesta cite la evidencia correcta. La validación debe mantenerse igual entre condiciones y, en lo posible, no depender de la impresión subjetiva de quien conoce qué variante se está probando.

El coste debe recogerse con los datos disponibles de uso y con la tarifa aplicable al canal de acceso en el momento del ensayo. La latencia de primer token y el tiempo de tarea requieren marcas de tiempo externas, porque el registro de uso de una respuesta no sustituye necesariamente un cronómetro de extremo a extremo. Hay que incluir también errores, reintentos, respuestas rechazadas por el validador y trabajo adicional de herramientas.

Diseñar las condiciones: contexto, prefijos, herramientas e imágenes

No conviene cambiar todas las variables a la vez. Para estudiar longitud de contexto, se pueden preparar grupos de tareas con historiales cortos, medios y extensos, procurando que las tareas sigan siendo comparables. Si aumenta la longitud, deben registrarse tanto los tokens de entrada como el número de pasos posteriores. Así se distingue el coste inicial de leer contexto del coste acumulado de mantenerlo y reutilizarlo.

La reutilización de prefijos merece una prueba propia. La guía de caché de contexto de DeepSeek describe coincidencias basadas en prefijos y califica la persistencia como best-effort: un prefijo repetido no garantiza un acierto. Para que el resultado sea interpretable, se debe conservar idéntico el tramo que se espera reutilizar y variar de forma controlada el contenido añadido al final. Registrar los tokens de caché acertados y fallidos permite verificar qué ocurrió en cada llamada, en vez de asumir que se reutilizó el contexto.

En agentes con herramientas, hay que fijar el conjunto disponible, las descripciones, los parámetros y las condiciones de ejecución. La API puede informar de llamadas a herramientas en el intercambio y del uso asociado, pero el tiempo de la herramienta y el del agente deben medirse de manera que se puedan separar. Una búsqueda externa o una ejecución de código puede dominar el tiempo total, aunque el modelo reduzca su propia carga de procesamiento.

La entrada visual debe tratarse como una condición distinta, no como un detalle añadido sin control. Si forma parte de la carga prevista, se comparan tareas equivalentes con imágenes representativas y se registra su efecto en coste, tiempo y acierto de la tarea. Las fuentes aportadas no establecen que la reducción de caché produzca una mejora específica en cargas visuales. Esa relación debe medirse y no darse por supuesta.

Qué observar en la API y qué medir fuera de ella

La respuesta de chat de DeepSeek expone campos de uso que incluyen tokens de entrada y salida, así como información sobre tokens de entrada asociados a aciertos y fallos de caché. La especificación también contempla el uso relacionado con llamadas a herramientas. Esos datos permiten describir lo que la API registró en cada solicitud y son una base útil para reconciliar el consumo. No prueban por sí mismos cuánto tardó el agente de principio a fin ni si el resultado cumplió el objetivo.

Para la latencia de primer token, el cronómetro debe empezar en un punto definido, como el envío de la solicitud, y terminar al recibir el primer token de respuesta. Para el tiempo de tarea se necesita un segundo intervalo: desde el inicio del trabajo hasta que el validador declara el resultado aceptable o la ejecución se clasifica como fallida. Si se incluye tiempo de cola, herramientas o validación, hay que indicar cómo se mide. De lo contrario, las cifras de dos ensayos pueden no ser comparables.

El equipo debería informar de las distribuciones y no solo de un promedio: mediana y rangos o percentiles ayudan a mostrar si unas pocas ejecuciones lentas distorsionan la experiencia. También conviene registrar la tasa de éxito y los reintentos. Un resultado de menor coste medio que provenga de más fallos no demuestra eficiencia útil si el objetivo operativo exige completar las tareas.

Si la API no proporciona una medida concreta —por ejemplo, el tiempo desglosado por fase en toda la ejecución— no debe reconstruirse como si fuera un dato observado. Se puede cronometrar externamente, etiquetándolo como medición del equipo. Esta separación entre observaciones del proveedor y mediciones propias hace que los resultados sean auditables y evita atribuir al modelo lo que depende del servicio, la red o las herramientas.

Evitar una línea base falsa con alias y versiones

La comparación histórica requiere comprobar qué modelo atendió realmente cada solicitud. La documentación de DeepSeek señala que `deepseek-flash` es el identificador de acceso actual a V4.1 Flash y que identificadores antiguos de V4 Flash pueden enrutarse al modelo nuevo. Si se ejecuta hoy una prueba con un alias antiguo y se presenta como una medición del modelo anterior, el resultado puede ser engañoso: el nombre enviado no garantiza que la ejecución haya usado una versión histórica.

Antes de iniciar una prueba, hay que consultar el registro de cambios y la documentación de API, anotar el identificador utilizado y guardar la fecha de consulta. Si un alias está redirigido, esa ejecución debe etiquetarse como el modelo de destino documentado, no como una repetición del modelo antiguo. Para una comparación histórica hacen falta datos recogidos cuando la versión anterior estaba disponible o un acceso que identifique inequívocamente ambas versiones.

El estado de los nombres y redirecciones puede cambiar. Por eso, la especificación del ensayo debe tratar el identificador como parte de la configuración experimental, no como un dato accesorio. La incertidumbre sobre alias o cambios del servicio debe constar en el informe si no es posible resolverla.

Cómo leer los resultados sin extrapolar de más

Un ensayo puede respaldar una conclusión acotada: por ejemplo, que con un conjunto de tareas, un patrón de prefijos, una configuración de herramientas y una tarifa determinados, una condición registró cierto coste y tiempo por resultado aceptado. No demuestra que todos los agentes se beneficien de igual forma, que una reducción de caché cause cada diferencia observada ni que el resultado se mantenga en otro canal de acceso.

Para sostener una atribución más fuerte, conviene variar una condición cada vez y repetir la prueba. Si se modifica simultáneamente la longitud del contexto, el prompt y las herramientas, no se puede aislar cuál de esas diferencias explica el cambio. Del mismo modo, una mejora en tokens de caché acertados no demuestra que la calidad haya aumentado: el éxito debe medirse mediante el criterio de tarea establecido.

La documentación disponible es suficiente para formular hipótesis técnicas sobre la arquitectura, los campos de uso y el comportamiento de la caché de contexto. No es suficiente para inferir un ahorro universal por tarea, una latencia garantizada ni una ventaja independiente en todas las cargas. Las fuentes primarias describen las cifras y mecanismos que publica DeepSeek; el equipo debe presentar sus resultados de aplicación como mediciones propias y bajo sus condiciones.

Una conclusión operativa sólida separa cuatro planos: lo que declara el fabricante, lo que expone la API, lo que mide el equipo y lo que todavía no se sabe. La compresión de caché es una propiedad relevante para evaluar infraestructura. La decisión de despliegue debería apoyarse, en cambio, en coste y tiempo por tarea aceptada, junto con calidad, variabilidad, reintentos y límites de observabilidad.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.