• Tech Support ⤴
  • Projects
  • Services
    • AI Development
    • UI/UX Design
    • Web Development
    • Technology Support
    • Mobile App Development
    • Banking ATM Interfaces
    • Process Automation
    • Security Auditing
    • Local AI Servers
  • odoo ERP
get in touchStart with Eva
logo
Tech Support ⤴
Projects
Services
AI DevelopmentUI/UX DesignWeb DevelopmentTechnology SupportMobile App DevelopmentBanking ATM InterfacesProcess AutomationSecurity AuditingLocal AI Servers
odoo ERP
get in touchStart with Eva
Loading…
logo

Transforming businesses through AI-powered digital innovation and creative excellence.

Quick Links

BlogAinexProjectsContact us

Contact Us

pinDubai Digital Park, A5, DTEC - Silicon Oasisemail[email protected]phone+971 55 7538087
© 2026 aratech. All rights reserved.
Privacy PolicyTerms of ServiceCookie Policy
Inicio / Blog / El fin de la KV-Cache: como DeepSeek y Xiaomi hacen los modelos baratos mas listos

El fin de la KV-Cache: como DeepSeek y Xiaomi hacen los modelos baratos mas listos

V4.1-Flash de DeepSeek y HySparse2 de Xiaomi atacan el mismo cuello de botella desde direcciones opuestas: codificar la cache KV una vez y cuantizarla fuerte, o leer solo lo que se va a usar. La atencion dispersa enfocada en agentes se vuelve mainstream y los modelos baratos acaban de volverse competitivos en benchmarks reales de agentes.

- 6 min de lectura

Puntos clave

ExpandCollapse
  • - El ancho de banda de la cache KV, no el computo, es ahora el principal cuello de botella de la inferencia: un contexto de 1M de tokens a precision completa cuesta ~389 GB.
  • - DeepSeek-V4.1-Flash usa codificacion KV incremental y caches FP4 (E2M1) para reducir el tamano de la cache 437x vs V1, llegando a ~890 B por token y un working set de ~0.9 GB para 1M de tokens.
  • - HySparse2 de Xiaomi reduce lo que se lee por token con sparsity elastica por cabeza, recuperacion intercalada top-K + local y KV compartido agrupado: 2.69 GB a 1M de tokens y 5.02x menos computo de prefill vs atencion hibrida de ventana deslizante.
  • - Los modelos baratos optimizados en cache ya rivalizan con los de frontera en benchmarks de agentes: V4.1-Flash (90.6) supera por poco a Claude Opus 5 (89.1) y GPT-5.6 (88.8) en Terminal-Bench 2.1.
  • - Las afirmaciones de recall de un millon de tokens siguen sin verificacion independiente mas alla de ~256K. Trata el recall de 1M como una afirmacion de arquitectura hasta que terceros la repliquen.
Graficos de linea con las huellas de cache KV de los modelos de DeepSeek y Xiaomi y las puntuaciones en benchmarks de agentes

El recurso mas caro en IA hoy no es el computo. Es el ancho de banda de memoria, y casi todo se gasta en mover una sola cosa: la cache KV. Dos lanzamientos de los ultimos meses atacan ese cuello de botella desde direcciones de ingenieria opuestas, V4.1-Flash de DeepSeek y HySparse2 de Xiaomi, y juntos esbozan como se ve la proxima era de la inferencia: agentes de un millon de tokens que caben en gigabytes, no en terabytes.

1. Primero, dimensionemos el problema

En la capa de atencion de un transformer, generar un token requiere leer los vectores clave/valor de cada token anterior. Con atencion completa, 61 capas (DeepSeek-V1), 128 cabezas de atencion y head-dim fino de 128, la cache de un solo token a precision casi sin perdidas cuesta unos 380 KB en todas las capas. Multipliquemos por contexto:

  • 32K tokens: ~12 GB de cache KV
  • 128K tokens: ~49 GB
  • 1M tokens: ~389 GB

Ese ultimo numero es por que "contexto de 1M" fue marketing hasta este ano. No es un problema de capacidad del modelo, es un problema del subsistema de memoria: incluso con 8 TB/s de ancho de banda HBM, transmitir 389 GB por token te limita a unos 20 tokens/segundo, antes de cualquier razonamiento.

2. DeepSeek-V4.1-Flash: codifica la cache una vez, cuantiza fuerte

El linaje de DeepSeek colapsa esa tabla:

ModeloCache por tokenCache KV de 1M tokens
DeepSeek-V1 (MLA, casi sin perdidas)~389 KB~389 GB
DeepSeek-V4-Flash~3.5 KB (437x menor)~3.5 GB
DeepSeek-V4.1-Flash~890 B (437x menor)~0.89 GB

Dos mecanismos hacen el trabajo.

Codificacion KV incremental. Las capas anteriores del stack actuan como una jerarquia de memoria: la codificacion se aplica solo en una pequena ventana final de capas, en lugar de recalcular todo el stack por token. El contexto se construye con un pequeno "diff" por token, con estructuras de metadatos que indexan lo que ya se codifico, de modo que los system prompts repetidos y las salidas de herramientas reutilizadas se codifican una vez, no por turno.

Cache KV FP4 (E2M1) con metadatos FP8. DeepSeek-V4-Flash envio caches KV FP8; V4.1-Flash va mas alla y guarda la mayoria de los vectores cacheados en bloques E2M1 estilo NVFP4, reduciendo a la mitad la huella de V4-Flash otra vez. Los elementos sensibles o de alta frecuencia se mantienen en mayor precision, que es donde se preserva la mayor parte de la calidad del recall.

El resultado compuesto es unas 437x menor que V1 y 4x menor que V4-Flash, que es lo que hace que un contexto de un millon de tokens sea un working set de ~0.9 GB en lugar de un pequeno centro de datos.

El punto de todo esto son los agentes. Los benchmarks auto-declarados donde el contexto del harness (system prompt, skills, definiciones de herramientas, memoria) supera con creces la consulta real del usuario son exactamente la carga que apuntan la codificacion incremental y la eliminacion de redundancia por reutilizacion de cache: una sesion de agente es en su mayoria texto boilerplate reenviado, y V4.1-Flash deja de pagar por el repetidamente.

3. Xiaomi HySparse2: no leas lo que no vas a usar

Por separado, el laboratorio de agentes de Xiaomi publico HySparse2 (arXiv 2609.26368), una arquitectura de atencion dispersa hibrida construida para un modelo de agente MoE de 80B (A3B activos). Donde DeepSeek encoge la cache por token, HySparse2 encoge lo que se lee por token. Mecanicas clave:

  • Sparsity elastica a nivel de cabeza. En lugar de una configuracion de sparsity global, cada cabeza elige su propio equilibrio entre atencion local de ventana deslizante y recuperacion semantica top-K. Las cabezas de retencion pueden mantenerse "calientes" mientras las cabezas sintacticas se vuelven mayormente locales.
  • Multiples profilers. Un pequeño pase de perfilado clasifica los tokens en roles semanticos locales vs globales, y luego divide el flujo KV en carriles paralelos: un carril local-denso de grano fino y un carril global grueso, cada uno con su propia politica.
  • Prefill top-K + local intercalado. Durante el procesamiento del prompt, la atencion alterna entre bloques globales de seleccion top-K y bloques locales de ventana densa, de modo que los hits a nivel de pagina (repos de codigo, documentos largos) no expulsen el contexto local desde donde la generacion realmente continua.
  • Metadatos KV seleccionados. Un indice compacto almacenado por separado sobre la cache cuantizada impulsa la recuperacion. El ablation de Xiaomi muestra que la correctness en su conjunto agente de contexto largo cae de 27.32 a aproximadamente sin vs con esto; el carril de metadatos es lo que evita que el recall disperso se degrade silenciosamente en consultas tipo needle.
  • KV compartido estilo MQA. La cache se organiza como grouped-query (estilo MQA) (KV compartido por capa entre cabezas de consulta), haciendo que la cache del agente sea unas 4-4.5x mas pequena que un layout MLA estandar al mismo ancho.

Con 1M de tokens en el modelo de 80B, con KV FP8: HySparse2 sostiene 2.69 GB vs 6.72 GB de HySparse y 12.09 GB de atencion hibrida de ventana deslizante, mientras hace 5.02x menos computo de prefill y 2.92x menos computo de decode que el SWA hibrido. Segun los evals de recuperacion de Xiaomi (estilo RULER-v2 a 32K): 58.45 para HySparse2 vs 35.74 para HySparse vs 32.61 para ventana deslizante.

Nota importante de honestidad: las afirmaciones de un millon de tokens de Xiaomi son sobre su propio harness de eval contra conjuntos de recuperacion sinteticos como variantes de RedPajama; la verificacion independiente de terceros del recall real de 1M tokens sigue siendo escasa. La arquitectura es creible; los numeros puntuales merecen el escepticismo habitual hasta que equipos independientes los repliquen a profundidades mas alla de 256K.

4. ¿Los avances se ven en benchmarks reales de agentes?

DeepSeek publica cara a cara para V4.1-Flash con esfuerzo de razonamiento completo:

BenchmarkDeepSeek-V4.1-FlashClaude Opus 5GPT-5.6
Terminal-Bench 2.190.689.188.8
DeepSWE v1.174.274.0n/a
CyberGym88.1n/an/a
Terminal-Bench 4.031.251.8n/a

Hay dos historias distintas en esa tabla. En Terminal-Bench 2.1, esencialmente el harness agente de coding/ops estandar actual, V4.1-Flash se mide en 90.6, superando a Claude Opus 5 (89.1) y GPT-5.6 (88.8). En el mas duro Terminal-Bench 4.0, Opus 5 sigue muy por delante (51.8 vs 31.2), asi que no es una afirmacion general de dominancia de frontera. Pero la direccion es inequivoca: un modelo optimizado en cache y fuertemente cuantizado ahora es competitivo en los benchmarks que de verdad importan a quien despliega agentes, no solo en Q&A estatico.

5. Que significa esto si construyes con modelos

  1. La ingenieria de cache KV se esta volviendo la verdadera frontera de la optimizacion de inferencia. El costo de servir a un agente esta dominado por el contexto del harness (el system prompt + definiciones de herramientas MCP + memoria), que en un trace que medi fue 93 tokens de pregunta del usuario vs ~100K tokens de overhead del harness por request. Las arquitecturas que se niegan a pagar eso de nuevo en cada turno cambian la economia unitaria por ordenes de magnitud.
  2. "Modelo barato" ya no implica "modelo tonto". La correlacion entre la franja de precio de un modelo y su posicion en benchmarks agente se esta rompiendo: V4.1-Flash se ubica muy por debajo de Opus 5 en costo pero esta aproximadamente a su nivel en Terminal-Bench 2.1/DeepSWE/CyberGym.
  3. La atencion dispersa paso del paper a produccion. HySparse2 muestra la receta (mix de sparsity por cabeza + seleccion intercalada + cache cuantizada + metadatos de recuperacion) que sera un default en la proxima generacion de modelos agente de pesos abiertos. Observa que laboratorios adoptan variantes primero.
  4. La verificacion de contexto largo todavia hay que ganarla. El recall reclamado de 1M de tokens debe tratarse como una afirmacion de arquitectura, no como un ancla; exige replicaciones independientes en 512K+ antes de construir rutas de producto que dependan de recuperacion tipo needle en un stack de 1M.

Si los ultimos tres anos fueron sobre escalar parametros, los proximos tres parecen ser sobre escalar lo que cabe en memoria por dolar. DeepSeek y Xiaomi acabaron de publicar la evidencia mas fuerte hasta ahora de que esto es un problema de ingenieria solucionable, y de que los equipos que tratan la cache KV como un subsistema de almacenamiento de primera clase, no como un efecto secundario de la atencion, marcaran la curva de precios que todos los demas siguen.

Referencias

  1. Xiaomi AI (2026). "HySparse2: Hybrid Sparse Attention for Million-Token Agents." arXiv:2609.26368. URL: https://arxiv.org/abs/2609.26368
  2. Notas de ingenieria de origen de Xiaomi sobre HySparse2: https://originshq.com/blog/hysparse2-hybrid-sparse-attention-agents/ (analisis secundario de los ablations del paper y las cifras de KV de 1M tokens)
  3. MindStudio (2026). "DeepSeek-V4.1-Flash KV Cache Compression." https://www.mindstudio.ai/blog/deepseek-v4-1-flash-kv-cache-compression
  4. NVIDIA (2024). "NVIDIA Blackwell Architecture Technical Brief: quantizacion NVFP4 (E2M1)." https://resources.nvidia.com/en-us-blackwell-architecture
  5. Video de portada original: "DeepSeek's New Model vs Xiaomi's Sparse Attention" https://youtu.be/85QP5JDZfQM (miniatura usada con credito)

Tabla de contenido

  • ↗1. Primero, dimensionemos el problema
  • ↗2. DeepSeek-V4.1-Flash: codifica la cache una vez, cuantiza fuerte
  • ↗3. Xiaomi HySparse2: no leas lo que no vas a usar
  • ↗4. ¿Los avances se ven en benchmarks reales de agentes?
  • ↗5. Que significa esto si construyes con modelos
  • ↗Referencias

Artículos relacionados

Aparato de puerta de enlace Citrix NetScaler estilizado brillando sobre una rejilla oscura de circuito con un símbolo de shell root expuesto

Citrix NetScaler CVE-2026-88771/88772: explotadas en la naturaleza

Dos RCE críticos de Citrix NetScaler fueron explotados activamente antes del bulletin de Citrix del 27 de septiembre. Esto es lo que realmente hacen CVE-2026-88771 y CVE-2026-88772, las builds corregidas y por qué la forense debe ir antes que el parcheo.

Necolas HamwiNecolas Hamwi
30 de septiembre de 2026 - 9 min de lectura
Arte cyberpunk oscuro de un rack de servidor estilo SharePoint comprometido con luz neón púrpura y cian, que simboliza la vulnerabilidad CVE-2026-65660 explotada activamente

SharePoint CVE-2026-65660: atacantes están comprometiendo activamente servidores sin parchar

Microsoft confirmó que atacantes están explotando activamente CVE-2026-65660, una falla de ejecución remota de código en SharePoint Server que se combina con configuraciones de acceso anónimo para instalar web shells. CISA la agregó a KEV el 25 de septiembre y las agencias federales deben parchear antes del 28. Aquí está el patrón de explotación y una checklist de defensa priorizada.

Necolas HamwiNecolas Hamwi
29 de septiembre de 2026 - 7 min de lectura
Ilustración cyberpunk oscura de una base de datos de webmail bajo inyección SQL, con líneas de circuito en morado neón y cian

El plugin olvidado de Roundcube: una inyección SQL de hace cuatro meses ya se explota en el mundo real

El plugin virtuser_query de Roundcube Webmail contiene CVE-2026-48842, una inyección SQL previa a la autenticación corregida en mayo de 2026. El 24 de septiembre, el Centro Canadiense de Ciberseguridad confirmó su explotación activa, y cualquier servidor de webmail sin parchear es una puerta abierta a la base de datos que tiene detrás.

Necolas HamwiNecolas Hamwi
25 de septiembre de 2026 - 7 min de lectura