890 bytes/token: matemática de KV-cache para DeepSeek V4.1 Flash de 1M de tokens

Con 890 bytes por token —aproximadamente una cuarta parte de V4-Flash y 437 veces menor que V1—, una sesión de DeepSeek V4.1-Flash de 1.000.000 de tokens almacena 890.000.000 bytes de estado KV antes de los aciertos de prefijo. El compromiso es entre memoria por token y sesiones por GPU: ese número de bytes determina cuánto contexto permanece en HBM, cuánto se desborda a la RAM del host o al SSD, y cuánto cuesta un fallo de caché. Si el pool no puede contener la cola no cacheada, el planificador debe expulsar, descargar o rechazar trabajo, y cada elección modifica la latencia y el coste.

Los bytes por token fijan el tope de HBM

DeepSeek lanzó V4.1-Flash el 10 de septiembre de 2026 como la tercera entrada de la línea V4. El modelo tiene 552B de parámetros totales, 8B activos en prefill y 16B activos en decode. Esos recuentos activos determinan el cómputo, pero el tope de servicio proviene de los bytes KV por token. El presupuesto de memoria es el estado KV. Un modelo eficiente en parámetros puede seguir fallando una prueba de capacidad si la caché por token deja demasiado poco espacio para la residencia.

Los pesos ocupan una porción fija del pool, mientras que el estado KV crece con cada token que se conserva. El diseño causal encoder-decoder divide las 40 capas en 20 capas de encoder y 20 capas de decoder, con el KV del decoder proyectado desde las salidas del encoder. Esa división cambia dónde se almacena el estado, no el número de tokens que hay que presupuestar. El indexador jerárquico disperso CSA2 limita el pool de candidatos a 16.384 posiciones, de modo que los FLOPs por token de decode solo aumentan una cuarta parte cuando el contexto crece de 4K a 1M. El coste de decode permanece acotado, pero la factura de memoria sigue escalando con los tokens que se conservan.

Los aciertos de prefijo convierten bytes en sesiones

El coste de una sesión no cacheada es los bytes KV por token multiplicado por la longitud del contexto. Un acierto de prefijo elimina los bytes del prefijo compartido, de modo que el coste real de la sesión es la cola no cacheada más cualquier estado replayed. Una caché KV más pequeña por token permite que más contexto permanezca cacheado, elevando las tasas de acierto de prefijo, reduciendo el time-to-first-token y aumentando el throughput por GPU. Menos bytes por token aumenta las sesiones por GPU, pero solo si el prefijo realmente se repite. Si la tasa de acierto de prefijo es baja, la cola no cacheada crece y el número de sesiones cae.

Las cargas de trabajo de agentes son intensivas en prefijos. Los prompts de sistema, los esquemas de herramientas, el contexto del repositorio y los turnos anteriores a menudo se repiten entre llamadas. Cuando esos prefijos permanecen cacheados, el planificador omite la atención sobre ellos y sirve el siguiente token más rápido. Cuando no es así, la misma sesión orientada al usuario puede costar más que una más corta que reutiliza un prefijo estable. Para una estimación de tasa de solicitudes, divide el throughput de decode esperado entre los tokens promedio por solicitud y luego acótalo con el número de sesiones que el pool KV puede contener. Ese tope es el número de sesiones por GPU que puedes usar antes de elegir hardware.

El replay y el offload fijan la penalización por fallo

La caché KV principal usa E2M1 con una escala E4M3 por cada 16 canales; los estados de ventana deslizante de 128 tokens residen en la RAM del host con un TTL de nivel de minuto, y un fallo activa SWA Bounded Replay para recalcular los últimos 128 tokens. Un TTL corto puede convertir un prefijo cacheado en una recalculación si el agente se pausa. Presupuesta el replay como trabajo extra de prefill, no como un acierto de caché gratuito.

La RAM del host se sitúa entre HBM y SSD en la jerarquía de servicio habitual. Trátala como la primera capa de recuperación. Un estado de ventana deslizante que permanece en la RAM del host puede recuperarse rápidamente, mientras que un estado que se ha movido a un almacenamiento más lento puede forzar una recalculación mayor. El TTL importa porque las sesiones de agentes se pausan: una llamada a herramienta, una aprobación humana o una tarea en segundo plano pueden dejar el prefijo inactivo el tiempo suficiente para que expire. Si la cola no cacheada más el estado replayed excede la HBM, la ruta de offload cambia la latencia y el coste de la cola, no el número de bytes.

Juzga las sesiones por bytes, no por sensaciones

• Caché de sesión = bytes/token × tokens; introduce los bytes KV del modelo y la longitud del contexto.
• Resta los aciertos de prefijo: elimina los bytes de los tokens ya cacheados y luego suma el estado replayed por cada fallo.
• Compara la residencia en HBM con el offload a RAM del host o SSD; la ruta de offload cambia la latencia, no el número de bytes.
• Calcula las sesiones por GPU dividiendo la memoria KV disponible entre el total de bytes por sesión y luego aplica la penalización de replay.