Comment BMW a intégré 16 000 tokens de contexte dans un GPU de 16 Go en repensant l'attention

L'ajustement en contexte long a un problème matériel. Les poids du modèle tiennent, les adaptateurs tiennent, mais l'état d'attention dense gonfle à chaque token, et entre 2 000 et 4 000 tokens, le GPU manque de mémoire. Une équipe de BMW Group, un endroit où l'on ne s'attend pas à voir publier de nouveaux mécanismes d'attention, travaille sur ce problème depuis un certain temps.

Leur dernier preprint, publié en juillet 2026, combine trois techniques : l'Attention Globale Hiérarchique (HGA), un article précédent du même groupe ; la rétropropagation par segments (TBPTT) ; et un système de stockage KV à plusieurs niveaux qui pousse les anciennes clés et valeurs dans la RAM ou le NVMe. Le résultat est un pipeline d'entraînement qui atteint 16 384 tokens sur une Quadro RTX 5000 de 16 Go, soit quatre fois plus que ce que l'attention dense peut gérer sur la même carte. Et la qualité, sous lecture dense, est à moins de 0,0022 nats d'un adaptateur entraîné de manière dense.

Ce n'est pas une percée dans le sens d'une nouvelle perte de pointe. C'est une réponse d'ingénierie pratique à une question que beaucoup de gens rencontrent : comment affiner des séquences plus longues que quelques milliers de tokens sans acheter un A100 ?

Ce que HGA fait différemment

L'attention standard traite chaque paire requête-clé. C'est le goulot d'étranglement. HGA est un remplacement direct du module d'attention qui sélectionne uniquement un sous-ensemble de tokens historiques par bloc de requête, en utilisant une hiérarchie de routage à deux niveaux. Le contexte est divisé en morceaux de 64 tokens ; des vecteurs résumés compacts de chaque morceau restent dans la VRAM. La requête évalue ces résumés et sélectionne les k premiers morceaux, puis ouvre ces morceaux au niveau du groupe (groupes de 8 tokens), et enfin charge uniquement les K/V exacts des groupes sélectionnés pour le calcul réel de l'attention.

Le routeur n'utilise pas de poids appris, il évalue des projections de clés existantes, donc les gradients mettent à jour les mêmes projections Q/K/V/O que dans le cas dense. L'idée clé est que les vecteurs résumés n'agissent jamais comme des valeurs d'attention ou des tokens de sortie ; ils dirigent uniquement la sélection. L'attention réelle porte sur les tokens exacts, ce qui maintient l'expressivité de l'attention complète tout en réduisant considérablement l'ensemble de travail.

BMW couple cela avec une rétropropagation par segments : la séquence est divisée en segments de 2 048 tokens, chaque segment effectue une passe avant et arrière indépendamment, et les anciennes KV sont détachées vers la RAM ou le NVMe avant le début du segment suivant. Les gradients ne traversent pas les limites des segments, mais les segments ultérieurs peuvent toujours prêter attention aux tokens exacts antérieurs via le routage HGA.

Comme le résument les auteurs sous forme d'équation : la mémoire GPU devient approximativement la somme du modèle, des adaptateurs et de l'optimiseur, du segment actif et de l'ensemble de travail routé, tous restant bornés. L'enregistrement historique externe croît linéairement avec la longueur totale, mais dans la RAM ou le disque, pas dans la VRAM.

Le croisement d'efficacité a déjà lieu à 2 000 tokens

Les chiffres dans l'article racontent une histoire claire. À 1 024 tokens, HGA est environ 20 % plus lent que l'attention dense (225,54 contre 282,32 tokens/s) car le surcoût de routage n'est pas encore amorti sur une séquence plus longue, la sélection couvre encore la majeure partie de l'historique. Mais à 2 048 tokens, le croisement s'inverse : HGA atteint 217,75 tokens/s contre 207,02 pour l'attention dense. Ce n'est qu'une petite marge, mais la tendance est claire. Comme le travail d'attention de HGA par token reste approximativement constant pour un budget de routage fixe, tandis que le travail dense croît linéairement avec le contexte, l'écart se creuse à mesure que les séquences s'allongent.

L'article ne peut pas mesurer cela directement au-delà de 2 000 tokens, l'entraînement dense manquant de mémoire à 4 000 tokens, mais la logique est solide et les données de balayage la soutiennent.

La qualité de l'adaptateur se maintient

Les chercheurs ont entraîné deux adaptateurs QLoRA sur Qwen3-8B avec quantification 4 bits NF4 et ont utilisé PG19 pendant 100 étapes d'optimisation, en contrôlant la graine et l'ordre des données. La seule variable était le module d'attention lors de l'ajustement. Au contexte d'entraînement partagé de 2 000 tokens, l'adaptateur entraîné avec HGA a obtenu 2,7405 nats sous lecture dense ; l'adaptateur entraîné de manière dense a obtenu 2,7383 nats. Différence : 0,0022 nats. Le modèle de base se situe à 2,9541. L'ajustement lui-même fournit l'effet le plus important, les adaptateurs réduisent tous deux la perte d'environ 0,216 nats, et que vous utilisiez HGA ou dense pendant l'entraînement importe peu pour les poids finaux.

À 4 000 tokens, où seul l'entraînement HGA est possible, l'écart est encore infime : 15,006 PPL pour l'entraîné HGA contre 14,966 pour l'entraîné dense sous lecture dense. Pour des fins pratiques, c'est du bruit.

Récupération : aucune dégradation dans la référence dense

BMW a également effectué des tests de récupération de type RULER (passkey, multikey et multivalue), en utilisant l'attention dense pour la lecture sur les deux adaptateurs. À 4 096 et 8 192 tokens, les deux adaptateurs atteignent un rappel de 100 % sur passkey et multikey. Sur multivalue, chaque adaptateur a manqué exactement une des 96 valeurs plantées, dans des cellules différentes. Ce n'est pas un signal de faiblesse.

L'article est prudent ici : ils utilisent une lecture dense car cela isole si l'ajustement basé sur HGA a modifié le comportement de récupération appris, plutôt que de le mélanger avec le rappel de sélection routée. HGA lui-même peut également effectuer de la récupération et de la génération, mais le moteur de service de qualité production, que l'équipe dit construire, probablement visant une intégration avec vLLM ou SGLang, est encore en développement.

Le seul véritable inconvénient : fuite causale

La limitation à signaler est un canal latéral causal qui apparaît lors d'un entraînement prolongé. Parce que les décisions de routage au sein d'un morceau dépendent des scores de plusieurs positions de requête, un token antérieur peut obtenir des informations indirectes sur les tokens ultérieurs, quels morceaux ont été sélectionnés ou rejetés. Le signal est faible au début, mais après 100 à 200 millions de tokens d'entraînement, le modèle commence à l'exploiter pour la prédiction du prochain token. L'article est clair à ce sujet : la méthode convient pour l'ajustement dans cet horizon, mais vous ne l'utiliseriez pas pour un pré-entraînement à partir de zéro. Les auteurs mentionnent une variante strictement causale en cours de développement.

Ce que cela signifie

Le groupe BMW n'est pas un laboratoire d'IA de haut profil, ce qui explique peut-être pourquoi cet article ressemble plus à un mémo d'ingénierie qu'à une annonce de percée. Ce n'est pas grave. La contribution est pratique : un moyen clair et reproductible de pousser le contexte d'entraînement bien au-delà de la barrière de la VRAM en utilisant une carte de 16 Go de 2018. Pour quiconque effectue un ajustement sur du matériel grand public ou de poste de travail, cela est immédiatement utile.

Le niveau adossé au NVMe est implémenté mais non évalué dans ce preprint. Le dépôt du projet sur GitHub (sous le nom HierarchicalGlobalAttention) contient le code. Si le moteur de service de qualité production se concrétise et que la fuite causale est corrigée, cette approche pourrait être compétitive avec des méthodes comme LongLoRA, avec l'avantage supplémentaire que HGA utilise une attention sur tokens exacts plutôt que des motifs épars décalés.