SevenTnewS

Investigación en IA

Cómo BMW metió 16K de contexto en una GPU de 16 GB rediseñando la atención

Investigadores de BMW demuestran que la Atención Global Jerárquica, combinada con retropropagación truncada y almacenamiento externo de KV, permite que una GPU de 16 GB entrene en 16K tokens, cuatro veces el límite de la atención densa, sin pérdida medible en la calidad del adaptador.

Emmanuel Fabrice Omgbwa Yasse Asistido por IA

2026-07-20 · 6 min de lectura

Cómo BMW metió 16K de contexto en una GPU de 16 GB rediseñando la atención
Fuentes : Long-Context Fi…·HierarchicalGlo…

El ajuste fino de contexto largo tiene un problema de hardware. Los pesos del modelo caben, los adaptadores caben, pero el estado de atención densa se infla con cada token, y entre 2K y 4K la GPU se queda sin memoria. Un equipo de BMW Group, no el lugar donde esperarías nuevas mecánicas de atención, ha estado trabajando en esto durante un tiempo.

Su último preprint, publicado en julio de 2026, combina tres técnicas: Atención Global Jerárquica (HGA, por sus siglas en inglés), un artículo anterior del mismo grupo; retropropagación por segmentos (TBPTT); y un sistema de almacenamiento de KV por niveles que envía claves y valores antiguos a RAM o NVMe. El resultado es un pipeline de entrenamiento que alcanza 16 384 tokens en una Quadro RTX 5000 de 16 GB, cuatro veces más de lo que la atención densa puede manejar en la misma tarjeta. Y la calidad, bajo lectura densa, está dentro de 0.0022 nats de un adaptador entrenado con atención densa.

Esto no es un gran avance en el sentido de una nueva pérdida de última generación. Es una respuesta de ingeniería práctica a una pregunta que mucha gente enfrenta: ¿cómo ajustar finamente secuencias de más de unos pocos miles de tokens sin comprar una A100?

Qué hace HGA de diferente

La atención estándar procesa cada par de consulta y clave. Eso es el cuello de botella. HGA es un reemplazo directo del módulo de atención que selecciona solo un subconjunto de tokens históricos por bloque de consulta, usando una jerarquía de enrutamiento de dos niveles. El contexto se divide en fragmentos de 64 tokens; los vectores resumen compactos de cada fragmento permanecen en la VRAM. La consulta puntúa esos resúmenes y elige los fragmentos top-k, luego abre esos fragmentos a nivel de grupo (grupos de 8 tokens) y finalmente carga solo los KV de tokens exactos de los grupos seleccionados para el cálculo de atención real.

El enrutador no usa pesos aprendidos, puntúa proyecciones de claves existentes, por lo que los gradientes actualizan las mismas proyecciones Q/K/V/O que en el caso denso. La idea clave es que los vectores resumen nunca actúan como valores de atención o tokens de salida; solo dirigen la selección. La atención real se realiza sobre tokens exactos, lo que mantiene la expresividad de la atención completa mientras reduce drásticamente el conjunto de trabajo.

BMW combina esto con retropropagación por segmentos: la secuencia se divide en segmentos de 2048 tokens, cada segmento avanza y retrocede de forma independiente, y los KV más antiguos se envían a RAM o NVMe antes de que comience el siguiente segmento. Los gradientes no cruzan los límites del segmento, pero los segmentos posteriores aún atienden a tokens exactos anteriores mediante el enrutamiento HGA.

Gráfico: Rendimiento (tokens/s) a 1K y 2K: HGA vs Atención Densa
A 1024 tokens, HGA es aproximadamente un 20% más lento que la atención densa (225.54 vs 282.32 tokens/s); a 2048 tokens el cruce se invierte, con HGA alcanzando 217.75 tokens/s frente a los 207.02 de la densa, según el preprint de BMW Group.

Como resumen los autores en forma de ecuación: la memoria de la GPU se convierte aproximadamente en la suma del modelo, los adaptadores y el optimizador, el segmento activo y el conjunto de trabajo enrutado, todo lo cual se mantiene acotado. El registro histórico externo crece linealmente con la longitud total, pero en RAM o disco, no en VRAM.

El cruce de eficiencia ya ocurre a 2K

Los números en el artículo cuentan una historia clara. A 1024 tokens, HGA es aproximadamente un 20% más lento que la atención densa (225.54 vs 282.32 tokens/s) porque la sobrecarga de enrutamiento aún no se amortiza en una secuencia más larga; la selección todavía cubre la mayor parte de la historia. Pero a 2048 tokens, el cruce se invierte: HGA alcanza 217.75 tokens/s frente a los 207.02 de la densa. Eso es solo un margen pequeño, pero la tendencia es clara. Debido a que el trabajo de atención de HGA por token se mantiene aproximadamente constante para un presupuesto de enrutamiento fijo, mientras que el trabajo denso crece linealmente con el contexto, la brecha se amplía a medida que las secuencias se alargan.

El artículo no puede medir eso directamente más allá de 2K; el entrenamiento denso se queda sin memoria a 4K, pero la lógica es sólida y los datos de barrido lo respaldan.

La calidad del adaptador se mantiene

Los investigadores entrenaron dos adaptadores QLoRA en Qwen3-8B con cuantización NF4 de 4 bits y usaron PG19 durante 100 pasos de optimizador, controlando la semilla y el orden de los datos. La única variable fue el módulo de atención durante el ajuste fino. En el contexto de entrenamiento compartido de 2K, el adaptador entrenado con HGA obtuvo 2.7405 nats bajo lectura densa; el adaptador entrenado con atención densa obtuvo 2.7383 nats. Diferencia: 0.0022 nats. El modelo base tiene 2.9541. El ajuste fino en sí mismo proporciona el efecto más grande; ambos adaptadores reducen la pérdida en aproximadamente 0.216 nats, y si se usa HGA o denso durante el entrenamiento apenas importa para los pesos finales.

A 4K, donde solo el entrenamiento con HGA es factible, la brecha sigue siendo mínima: 15.006 PPL para el entrenado con HGA frente a 14.966 para el entrenado con denso bajo lectura densa. Para fines prácticos, es ruido.

Recuperación: sin degradación en la línea base densa

BMW también realizó pruebas de recuperación de estilo RULER con passkey, multikey y multivalue, usando atención densa para la lectura en ambos adaptadores. A 4096 y 8192 tokens, ambos adaptadores alcanzaron un 100% de recuperación en passkey y multikey. En multivalue, cada adaptador falló exactamente uno de los 96 valores plantados, en celdas diferentes. Eso no es una señal de debilidad.

El artículo es cuidadoso aquí: usan lectura densa porque aísla si el ajuste fino basado en HGA cambió el comportamiento de recuperación aprendido, en lugar de mezclarlo con la recuperación de selección enrutada. El propio HGA también puede hacer recuperación y generación, pero el motor de servicio de grado de producción, que el equipo dice que están construyendo, probablemente apuntando a la integración con vLLM o SGLang, todavía está en desarrollo.

La única advertencia real: fuga causal

La limitación que vale la pena señalar es un canal lateral causal que emerge bajo entrenamiento extendido. Debido a que las decisiones de enrutamiento dentro de un fragmento dependen de las puntuaciones de múltiples posiciones de consulta, un token anterior puede obtener información indirecta sobre tokens posteriores, qué fragmentos fueron seleccionados o rechazados. La señal es débil al principio, pero después de 100 a 200 millones de tokens de entrenamiento, el modelo comienza a explotarla para la predicción del siguiente token. El artículo es claro al respecto: el método está bien para ajuste fino dentro de ese horizonte, pero no lo usarías para preentrenamiento desde cero. Los autores mencionan una variante estrictamente causal en desarrollo.

Qué significa

El grupo de BMW no es un laboratorio de IA de alto perfil, lo que podría ser la razón por la que este artículo se lee más como un memo de ingeniería que como un anuncio de gran avance. Está bien. La contribución es práctica: una forma clara y reproducible de empujar el contexto de entrenamiento mucho más allá de la barrera de la VRAM usando una tarjeta de 16 GB de 2018. Para cualquiera que esté ajustando fino en hardware de consumo o estación de trabajo, eso es inmediatamente útil.

El nivel respaldado por NVMe está implementado pero no evaluado en este preprint. El repositorio del proyecto en GitHub (bajo el nombre HierarchicalGlobalAttention) tiene el código. Si el motor de servicio en etapa de producción se materializa y la fuga causal se soluciona, este enfoque podría ser competitivo con métodos como LongLoRA, con la ventaja adicional de que HGA usa atención de tokens exactos en lugar de patrones dispersos desplazados.

Lo esencial de la tecnología en 3 minutos cada mañana

Un correo, cada día laborable, con lo que realmente importa en IA y tecnología.