Investigadores de ByteDance detectan un punto débil en el ahorro de memoria de DeepSeek

El artículo, publicado a finales de septiembre de 2026, pone en duda uno de los principales pilares de ingeniería de DeepSeek. Lo lideran investigadores de ByteDance y entre los coautores hay científicos de Princeton, Stanford y la Universidad de California en Berkeley. Según SCMP, describen un posible fallo en la tecnología de ahorro de memoria que sustenta los modelos del laboratorio chino. Esa tecnología permitió a DeepSeek reducir su distancia con OpenAI y Anthropic con un gasto notablemente menor. La conclusión de los autores: el ahorro puede pagarse con respuestas menos precisas.

Qué se sabe del trabajo

Por ahora el resumen público es breve, y conviene tenerlo en cuenta. El fragmento disponible de la fuente no menciona el nombre del mecanismo concreto, ni porcentajes de pérdida de calidad, ni una lista de benchmarks. Tampoco indica con qué versiones de los modelos de DeepSeek se hicieron las pruebas. Solo se dice que la investigación detectó una debilidad en el enfoque de ahorro de memoria y que esa debilidad puede reducir la precisión.

La composición del equipo de autores ya dice bastante. ByteDance desarrolla sus propios modelos grandes y paga su propia inferencia, así que sabe lo que cuesta cada gigabyte de caché. Los coautores de tres de las principales universidades estadounidenses aportan peso académico. No es una entrada en el blog de un competidor, sino un preprint con una coalición amplia. Lo más probable es que otros lo analicen e intenten reproducirlo.

Por qué le duele a DeepSeek

Para DeepSeek, el ahorro de memoria no es una optimización puntual, sino la base de su modelo económico. La memoria que el modelo mantiene durante la generación, sobre todo la caché de claves y valores de la atención, determina cuántas solicitudes aguanta un acelerador y qué longitud de contexto puede manejar. Cuanto más compacta es la caché, más barato resulta el token. Para un laboratorio que trabaja con acceso limitado a los chips de gama alta y compite en precio, esto es crítico.

Como contexto: en la publicación de DeepSeek-V2, el laboratorio declaró una reducción del 93,3% de la KV-cache gracias al mecanismo Multi-head Latent Attention. DeepSeek-V3 tiene 671.000 millones de parámetros, de los que 37.000 millones están activos por token, y se entrenó en aproximadamente 2,788 millones de horas de GPU en H800. El texto disponible no confirma que el nuevo artículo se refiera precisamente a este mecanismo: es contexto nuestro, no una cita de la investigación. Pero muestra la magnitud de lo que está en juego. Si la compresión de memoria reduce la precisión de forma sistemática, las cuentas baratas de DeepSeek necesitan una corrección.

Datos clave

• Autores: equipo de ByteDance, con coautores de Princeton, Stanford y UC Berkeley.
• Publicación: finales de septiembre de 2026.
• Objeto de la crítica: la tecnología de ahorro de memoria en los modelos de DeepSeek.
• Riesgo señalado: menor precisión del modelo.
• El fragmento disponible de la fuente no indica las métricas de degradación ni la lista de modelos probados.
• Contexto: V2 declaró una reducción del 93,3% en el tamaño de la KV-cache; V3 tiene 671.000 millones de parámetros, con 37.000 millones activos.

Lo que todavía falta

La pregunta principal es dónde se manifiesta exactamente la degradación. La compresión de memoria suele afectar a las tareas que exigen extraer un detalle preciso de un contexto largo: buscar un dato en un documento grande, trabajar con un repositorio de código o hacer razonamientos de varios pasos que vuelven a tokens tempranos. Los benchmarks promedio pueden no reflejarlo. Si los autores han encontrado justo un escenario así, es más grave que una caída de un par de puntos en un ranking general.

La segunda cuestión es la respuesta de DeepSeek. El laboratorio puede demostrar que el efecto aparece solo en determinadas configuraciones, que se corrige con un ajuste posterior del entrenamiento o que las versiones más recientes ya lo han esquivado. Mientras no haya respuesta, es prematuro evaluar la magnitud del problema.

Cómo actuar

Los equipos que ya usan modelos de DeepSeek en producción no necesitan migrar con urgencia a otro stack. Conviene, eso sí, hacer pruebas con datos propios.

• Ejecute sus escenarios de contexto largo: extracción de datos de documentos grandes, análisis de código, cadenas de razonamiento. Compare con una referencia, por ejemplo otro modelo, y registre las discrepancias.
• Siga el preprint y las réplicas. La confirmación independiente importa más que la primera publicación, sobre todo cuando el autor trabaja en una empresa competidora.
• Calcule el coste ajustado por calidad. Si un token barato exige solicitudes repetidas o revisión manual, la ventaja de precio se diluye.
• Para tareas críticas, mantenga un modelo de reserva y una comparación automática de respuestas.

Para el mercado en general, esta historia deja una lección más amplia. La eficiencia lograda con un truco arquitectónico debe verificarse con el mismo rigor que la lograda a base de escala. La primera auditoría seria del enfoque de DeepSeek ha llegado de colegas del sector y, probablemente, no será la última.