# Grouped-query attention en geheugengebruik

 Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

 
 Bij het schalen van grote taalmodellen lopen ontwikkelaars en infrastructuurarchitecten steeds vaker tegen fysieke limieten van hardware aan. Hoewel de rekenkracht van moderne grafische processoren blijft toenemen, vormt de bandbreedte naar het geheugen en de fysieke capaciteit van dat geheugen een harde bottleneck. Binnen de architectuur van moderne transformermodellen is het attention-mechanisme de drijvende kracht achter het vermogen om context te begrijpen, maar het is tegelijkertijd de grootste verbruiker van runtimegeheugen.

 
 Om deze uitdaging aan te pakken, zijn er verschillende varianten van het attention-mechanisme ontwikkeld. Een van de belangrijkste standaarden die in moderne modellen wordt toegepast, is Grouped-Query Attention (GQA). In dit artikel analyseren we hoe deze techniek werkt, waarom het een noodzakelijke tussenstap is tussen eerdere benaderingen, en hoe het direct invloed heeft op de schaalbaarheid en snelheid van systemen die met grote taalmodellen werken.

 

 
 
## Een korte opfrissing: queries, keys en values

 Om te begrijpen waarom attention-mechanismen zoveel geheugen vereisen, moeten we terug naar de basis van de transformerarchitectuur. In een standaard attention-laag wordt de invoer geprojecteerd naar drie verschillende vectoren per token: queries (Q), keys (K) en values (V). Zie voor een breder perspectief ook het artikel over [wat een transformer is](https://leren.llmnet.nl/wat-is-een-transformer).

 
 De werking van deze drie vectoren kan als volgt worden samengevat:

 
 
- Query: De zoekopdracht van het huidige token. Dit token 'vraagt' aan de rest van de context welke informatie relevant is voor zijn eigen betekenis.
 
- Key: Het label of de index van elk token in de context. De query van het huidige token wordt vergeleken met de keys van alle voorgaande tokens om de relevantie te bepalen.
 
- Value: De daadwerkelijke inhoudelijke informatie die elk token met zich meedraagt. Zodra de relevantie (de attention-score) tussen een query en een key is berekend, wordt deze score gebruikt om de bijbehorende values te wegen en te combineren.
 

 Tijdens het autoregressieve generatieproces (waarbij het model token voor token genereert) is er een belangrijk verschil in levensduur tussen deze vectoren. De query is alleen nodig voor het token dat op dat specifieke moment wordt verwerkt. Zodra de attention-berekening voor het huidige token is voltooid en het volgende token wordt gegenereerd, hebben we die specifieke query niet meer nodig. De keys en values van alle verwerkte tokens moeten echter wel bewaard blijven. Bij elk nieuw te genereren token moet het model namelijk opnieuw de relatie leggen met alle voorgaande tokens. Het opnieuw berekenen van deze keys en values voor elk nieuw token zou leiden tot een onacceptabele hoeveelheid dubbel rekenwerk.

 
 De oplossing hiervoor is het opslaan van deze vectoren in het geheugen, een techniek die bekendstaat als KV-caching. Voor een diepgaande blik op deze structuur kun je het artikel over de [opbouw van KV-caching](https://leren.llmnet.nl/kv-caching-opbouw) raadplegen. Dit cachen voorkomt dat we bij stap 100 de keys en values van stap 1 tot en met 99 opnieuw moeten berekenen. Het lost een rekenprobleem op, maar introduceert direct een omvangrijk geheugenprobleem.

 

 
 
## De geheugenkosten van de KV-cache bij lange contexten

 De opgeslagen keys en values vormen de primaire oorzaak van de hoge geheugeneisen tijdens de generatiefase van een model. Waar de modelparameters (de gewichten) statisch in het geheugen geladen blijven en ongewijzigd blijven ongeacht de lengte van het gesprek, groeit de KV-cache dynamisch bij elke stap in de interactie. Deze groei is direct gekoppeld aan de lengte van de context.

 
 Schaalformule in woorden: De omvang van de KV-cache per actieve gebruikerssessie groeit lineair met het aantal tokens in de context, het aantal lagen in het model, de verborgen dimensie (hidden dimension) van het netwerk, en de precisie waarmee de getallen worden opgeslagen (zoals 16-bits floating-point formaten).

 

 Als een model bijvoorbeeld tientallen lagen heeft, en elke laag heeft tientallen attention-koppen met elk hun eigen dimensie, dan leidt dit bij lange documenten of uitgebreide chatsessies tot een gigantische hoeveelheid data. Bij een traditionele opzet met Multi-Head Attention (MHA) heeft elke individuele attention-kop zijn eigen set keys en values. Dit betekent dat bij een model met 32 koppen, er voor elk verwerkt token 32 key-vectoren en 32 value-vectoren in het geheugen moeten worden opgeslagen, voor elke laag van het model opnieuw.

 Wanneer de contextlengte toeneemt tot tienduizenden tokens, kan de KV-cache van een enkele actieve gebruiker groter worden dan de modelparameters zelf. Dit beperkt niet alleen de maximale context die een model kan verwerken, maar vermindert ook drastisch het aantal gebruikers dat gelijktijdig op dezelfde hardware kan worden bediend. Voor een uitgebreide analyse van de uitdagingen rondom contextlimieten, zie het artikel over de [uitleg van het context window](https://hub.llmnet.nl/context-window-uitleg).

 

 
 
## De evolutie: van Multi-Head naar Multi-Query Attention

 Om te begrijpen hoe Grouped-Query Attention dit probleem oplost, moeten we kijken naar de twee uitersten die eraan voorafgingen: Multi-Head Attention (MHA) en Multi-Query Attention (MQA).

 
### Multi-Head Attention (MHA)

 In de traditionele transformerarchitectuur, zoals geïntroduceerd in de originele documentatie over attention, maakt men gebruik van Multi-Head Attention. Hierbij heeft elke query-kop een bijbehorende, unieke key-kop en value-kop. Als het model 32 query-koppen heeft, heeft het ook 32 key-koppen en 32 value-koppen. Dit stelt elke kop in staat om zich op compleet verschillende aspecten van de invoer te richten. De ene kop leert bijvoorbeeld syntactische relaties (zoals het koppelen van een werkwoord aan een onderwerp), terwijl een andere kop zich richt op semantische verbanden over langere afstand. Hoewel dit zorgt voor een hoge expressiviteit en nauwkeurigheid, resulteert dit in de maximale belasting van de KV-cache.

 
### Multi-Query Attention (MQA)

 Als reactie op de geheugenproblemen van MHA werd Multi-Query Attention (MQA) voorgesteld. MQA kiest voor het andere uiterste om geheugen te besparen. In deze opzet behoudt het model nog steeds meerdere query-koppen (bijvoorbeeld 32), maar delen al deze query-koppen één enkele key-kop en één enkele value-kop per laag. Dit betekent dat er ongeacht het aantal query-koppen slechts één key- en value-vector per token in het geheugen hoeft te worden opgeslagen.

 De besparing is enorm: de omvang van de KV-cache wordt gereduceerd met een factor die gelijk is aan het aantal koppen. Bij een model met 32 koppen krimpt de KV-cache met 96,875%. Dit maakt het mogelijk om met zeer grote batches te werken en de contextlengte aanzienlijk op te rekken. De keerzijde is echter kwaliteitsverlies. Omdat alle query-koppen gedwongen worden om informatie te zoeken in exact dezelfde gecomprimeerde key- en value-ruimte, verliest het model een deel van zijn vermogen om complexe relaties te leggen. Dit uit zich vaak in verminderde prestaties bij taken die diepe logica, codegeneratie of nauwkeurige tekstextractie vereisen.

 

 
 
## Grouped-Query Attention (GQA) als de optimale tussenvorm

 Grouped-Query Attention (GQA) is ontworpen om de voordelen van beide uitersten te combineren. Het dient als een instelbare tussenvorm. In plaats van elke query-kop een eigen key/value-kop te geven (MHA), of alle query-koppen één enkele key/value-kop te laten delen (MQA), verdeelt GQA de query-koppen in groepen.

 Binnen elke groep delen de query-koppen een gezamenlijke key-kop en value-kop. De verhouding tussen het aantal query-koppen en het aantal key-value-koppen bepaalt de mate van compressie en kan door de architecten van het model nauwkeurig worden afgesteld.

 Stel bijvoorbeeld dat we een model hebben met 32 query-koppen. We kunnen deze opdelen in 8 groepen. Elke groep bevat in dat geval 4 query-koppen. Voor elke groep van 4 query-koppen wordt er één key-kop en één value-kop geprojecteerd en opgeslagen in de KV-cache. In totaal resulteert dit in 8 key-koppen en 8 value-koppen voor de gehele laag, in plaats van de 32 die nodig zouden zijn bij MHA.

 
 
 
 Attention-type | 
 Query-koppen (Q) | 
 Key/Value-koppen (K/V) | 
 Relatieve grootte KV-cache | 
 Kwaliteitsbehoud | 
 

 
 
 
 Multi-Head (MHA) | 
 32 | 
 32 | 
 100% (referentie) | 
 Maximaal | 
 

 
 Grouped-Query (GQA-8) | 
 32 | 
 8 | 
 25% | 
 Zeer hoog | 
 

 
 Grouped-Query (GQA-4) | 
 32 | 
 4 | 
 12,5% | 
 Hoog / Gemiddeld | 
 

 
 Multi-Query (MQA) | 
 32 | 
 1 | 
 3,125% | 
 Verminderd | 
 

 
 

 Door deze groepering toe te passen, blijft een groot deel van de expressieve kracht van het model behouden. Verschillende groepen kunnen zich nog steeds richten op verschillende aspecten van de invoertekst, terwijl de geheugenafdruk van de KV-cache drastisch daalt. De verhouding tussen het aantal query-koppen en key-value-koppen fungeert hierbij als een directe fysieke instelknop.

 

 
 
## De verhouding en rekenkundige besparing

 De besparing die GQA oplevert, is direct te herleiden naar de gekozen verhouding (ratio). Er is geen sprake van abstracte of wisselende prestatiewinst; de reductie in de omvang van de KV-cache is mathematisch exact te bepalen op basis van de modelarchitectuur.

 Als we de verhouding definiëren als:

 Reductiefactor = Aantal Query-koppen / Aantal Key-Value-koppen

 Dan betekent een configuratie met 8 query-koppen per key-value-kop (een verhouding van 8:1) dat de KV-cache exact acht keer zo klein is als bij een traditionele Multi-Head Attention-architectuur met hetzelfde aantal query-koppen. Deze verhouding is consistent over alle lagen van het model en is onafhankelijk van de daadwerkelijke lengte van de context. Of de context nu 1.000 of 100.000 tokens lang is, de benodigde opslagcapaciteit voor de cache bedraagt in dit scenario altijd exact 12,5% (een achtste) van wat MHA nodig zou hebben gehad.

 

 
 
## Geheugenbandbreedte en de generatiefase

 Een belangrijk aspect van GQA is dat de winst zich vooral vertaalt in een hogere doorvoersnelheid tijdens de generatiefase (het genereren van tokens), en minder tijdens de prefill-fase (het verwerken van de initiële prompt). Dit heeft te maken met de manier waarop processors zoals GPU's berekeningen uitvoeren.

 Tijdens de prefill-fase verwerkt het model de volledige invoerprompt in één keer. Dit is een operatie die sterk compute-bound is. De processor voert grote matrixvermenigvuldigingen uit waarbij de rekenkernen (de ALU's) constant aan het werk zijn. De tijd die nodig is om gegevens uit het geheugen te laden valt in het niet bij de tijd die nodig is voor de berekeningen zelf. GQA biedt hier slechts een marginale snelheidsinstroom.

 Tijdens de generatiefase (decoding) verandert de situatie volledig. Het model genereert token voor token. Voor elk nieuw token moet de processor de volledige modelparameters én de gehele KV-cache van alle voorgaande tokens inladen om één enkele berekening uit te voeren. Dit proces is extreem memory-bandwidth-bound. De rekenkernen van de GPU zijn grotendeels aan het wachten tot de benodigde data uit het tragere High Bandwidth Memory (HBM) naar het snelle SRAM-geheugen op de chip is getransporteerd. Door de KV-cache dankzij GQA met een factor 4 of 8 te verkleinen, hoeft er bij elke stap aanzienlijk minder data over de bus te worden verplaatst. Dit ontlast de bandbreedte naar het geheugen direct, waardoor de generatie per token versnelt. Voor meer informatie over het kwantificeren van deze processen en latency, zie het artikel over [snelheid meten](https://benchmark.llmnet.nl/snelheid-meten).

 

 
 
## Praktische voordelen bij deployment

 In de praktijk merken ontwikkelaars en systeembeheerders de voordelen van GQA op verschillende manieren bij het hosten van taalmodellen:

 
 
 
- Hogere batchgrootte (throughput): Omdat de KV-cache per gebruiker veel minder geheugen in beslag neemt, past er meer data op één grafische kaart. Dit betekent dat een server veel meer gelijktijdige conversaties kan verwerken voordat het geheugen volraakt.
 
- Langere contextlengte binnen bereik: Modellen kunnen langere documenten verwerken zonder dat er out-of-memory (OOM) fouten optreden. De fysieke grens van wat er in het VRAM past verschuift aanzienlijk naar boven.
 
- Efficiënter gedrag bij grote schaal: Bij grootschalige systemen vertaalt de reductie in benodigd geheugen zich direct in lagere infrastructuurkosten, omdat er minder fysieke GPU's nodig zijn om hetzelfde aantal verzoeken per seconde te verwerken.
 
 

 
 
## Kwaliteitsafruil en evaluatie

 Hoewel GQA aanzienlijke voordelen biedt op het gebied van efficiëntie, is het belangrijk om kritisch te blijven kijken naar de kwaliteit van de modeluitvoer. Het delen van keys en values tussen verschillende query-koppen betekent onvermijdelijk dat er informatie wordt gecomprimeerd. Het model verliest een klein deel van zijn fijnmazige expressiviteit.

 
 In de praktijk blijkt deze kwaliteitsafruil bij een goed gekozen verhouding (zoals 4:1 of 8:1) echter minimaal te zijn. Wetenschappelijke evaluaties tonen aan dat modellen die gebruikmaken van GQA vaak prestaties leveren die zeer dicht in de buurt liggen van hun MHA-equivalenten, terwijl de operationele winst substantieel is. Toch kan de impact verschillen per taak. Bij complexe redeneertaken, wiskundige berekeningen of zeer specifieke programmeertaken kan het kwaliteitsverlies merkbaarder zijn dan bij creatief schrijven of het samenvatten van teksten. Ontwikkelaars moeten de geschiktheid van een GQA-model daarom altijd evalueren aan de hand van specifieke benchmarks die representatief zijn voor hun uiteindelijke toepassing.

 

 
 
## Samenhang met andere optimalisatietechnieken

 Grouped-Query Attention staat niet op zichzelf, maar maakt deel uit van een breder ecosysteem aan technieken om de efficiëntie van taalmodellen te verbeteren. De winst van GQA kan bijvoorbeeld worden gecumuleerd met andere methoden om de KV-cache te verkleinen.

 
 Een veelgebruikte combinatie is GQA met kwantisatie. Waar GQA het aantal vectoren in de cache vermindert door koppen te groeperen, vermindert kwantisatie de precisie van de resterende vectoren (bijvoorbeeld door ze op te slaan als 8-bits of 4-bits getallen in plaats van 16-bits floating-point getallen). Dit verlaagt de geheugenafdruk per element. Voor een gedetailleerde uitleg over hoe kwantisatietechnieken werken op modelparameters en activaties, verwijzen we naar het artikel over [kwantisatie uitgelegd](https://gids.llmnet.nl/kwantisatie-uitgelegd). Samen met geavanceerde geheugenallocatietechnieken zoals PagedAttention zorgt GQA ervoor dat moderne taalmodellen op relatief toegankelijke hardware kunnen draaien zonder dat dit ten koste gaat van de bruikbaarheid.

 

 
 
## Lees ook

 
 
- [Attention-mechanisme in detail uitgelegd](https://leren.llmnet.nl/attention-uitgelegd)
 
- [De opbouw en werking van KV-caching](https://leren.llmnet.nl/kv-caching-opbouw)
 
- [Wat is een transformer-architectuur?](https://leren.llmnet.nl/wat-is-een-transformer)
 
- [Kwantisatie van LLM's uitgelegd](https://gids.llmnet.nl/kwantisatie-uitgelegd)
 
- [Het context window van taalmodellen begrijpen](https://hub.llmnet.nl/context-window-uitleg)
 
- [Snelheid en latency van LLM's meten](https://benchmark.llmnet.nl/snelheid-meten)
 
 

 llmnet.nl - leren en uitleg over taalmodellen