DeepSeek V4.1 Flash multiplica sus parámetros sin disparar la memoria
El nuevo modelo pasa de 763.000 millones de parámetros y reduce la caché KV a entre el 13% y el 25% de su predecesor, lo que permite servir de cuatro a ocho veces más usuarios con la misma huella.
DeepSeek ha publicado la versión 4.1 de su modelo Flash, la variante optimizada en coste y latencia. Lo que en teoría es un punto de release esconde cambios de arquitectura bastante más gordos de lo habitual: el modelo salta a 763.000 millones de parámetros, más del doble que la versión a la que sustituye y por encima de los V3 y R1 que pusieron a la compañía en el mapa a principios de 2025. Y aun así, sus requisitos de memoria no crecen en la misma proporción.
Menos caché, más usuarios
El primer frente es la caché de clave-valor (KV), ese estado que el modelo arrastra entre sesiones y que en aplicaciones de alto tráfico, como un chatbot, se come la memoria a una velocidad incómoda. Los cambios en los mecanismos de atención y la introducción de un nuevo encoder-decodificador causal dejan el consumo de KV entre el 13% y el 25% del que exigía V4 Flash. Traducido: con la misma huella de caché caben de cuatro a ocho veces más usuarios concurrentes. También mejora el procesamiento de prompts.
El segundo frente, y el más interesante, es el tipo de pesos. De los 763.000 millones de parámetros, 196.000 millones son parámetros n-grama, lo que la compañía llama un módulo de memoria condicional. La idea es desacoplar memoria de cómputo: el modelo gana conocimiento sin que cada token generado obligue a leer todo el modelo activo desde memoria.
Un n-grama es un grupo de tokens. En la práctica funciona como una asociación de palabras o frases, pero la implementación es una tabla de búsqueda enorme. El modelo no guarda ahí respuestas en texto, sino hashes y vectores que se inyectan en el pipeline de inferencia. Para cada token se hacen unas pocas decenas de consultas a esa tabla, y eso la abarata. El enfoque se parece al Per-Layer Embedding que desarrolló el equipo de Gemma en Google para que un LLM corriera en dispositivos con memoria y ancho de banda recortados; DeepSeek cambió los embeddings por n-gramas y lo detalló en un paper en enero.
La consecuencia operativa es directa: esos pesos no tienen que estar en VRAM. Se pueden descargar a RAM del sistema o, potencialmente, a un array de almacenamiento suficientemente rápido. Con pesos en FP8, el modelo pediría unos 763 GB de memoria de GPU; con el offload se queda en unos 567 GB, y eso contando solo los pesos. En producción hay que sumar caché KV, que escala con la longitud de contexto y con los usuarios simultáneos, así que la cifra real será bastante mayor. Hay más detalle en el informe técnico y los pesos están publicados en Hugging Face.
El movimiento encaja en la línea que llevan años explorando los grandes laboratorios: mixture of experts, tipos de dato de baja precisión, tablas de consulta. Todo vale para romper la dependencia entre tamaño del modelo y ancho de banda de memoria, que es el cuello de botella real durante la decodificación. A quien tenga que dimensionar nodos GPU para servir un modelo abierto, la diferencia entre 763 y 567 GB por réplica es la diferencia entre un clúster y otro. Falta ver cifras de latencia y rendimiento medidas en producción, no solo la reducción de caché que anuncia DeepSeek.