GPU voor ML-onderzoek · Crypto-betaling zonder KYC
IteraGPU
Inferentiegeheugen · Context en gelijktijdigheid

Hoeveel geheugen moet ik voor de KV-cache reserveren?

Voor een uniforme dense cache reken je twee tensors, K en V, voor elke laag, KV-head, bewaarde positie en gelijktijdige sequentie. Gebruik het werkelijke cacheformaat, niet dat van de gewichten. Deze berekening geeft het theoretische volume van een geheugenpost; ze voorspelt niet de totale piek van de GPU, noch de latentie, noch de kwaliteit van de antwoorden. Verifieer daarna de allocatiestrategie met je werklast.

01 /

Beschrijven wat in het geheugen blijft

Tijdens een autoregressieve generatie kunnen de sleutels en waarden van reeds verwerkte tokens worden bewaard voor de volgende stappen. Deze cache hoort bij de attentionlagen. Het volume hangt dus af van het model en de bewaarde geschiedenis, niet alleen van het aantal parameters. De context van een gesprek omvat ook de instructies, eerdere berichten en documenten die de applicatie toevoegt.

Je eerste beslissing is operationeel: hoeveel sequenties moeten actief blijven, tot welke lengte? Een wachtrij van twintig aanvragen waarvan er twee gelijktijdig worden uitgevoerd, betekent niet noodzakelijk twintig residente caches. Noteer de werkelijke toelating van de aanvragen en de eventuele extra sequenties die door de generatie worden aangemaakt.

Maak een fiche met de revisie van het model, de attentionlagen, de KV-heads, de dimensie van de sleutels en waarden, hun dtype en de cachestrategie. Tel de tokens na de tokenizer en het gespreksjabloon. Een limiet in tekens beschrijft deze allocatie niet.

Technische bronnen: Hugging Face — werking en vorm van de caches per laag

02 /

De KV-heads gebruiken, met name met GQA

Het aantal query-heads Q en dat van de KV-heads kunnen verschillen. Bij klassieke multi-head attention vallen ze samen. Met MQA wordt één enkele KV-head gedeeld; GQA groepeert meerdere Q-heads rond één KV-head. Lees num_key_value_heads in de configuratie wanneer dat veld bestaat en verifieer de betekenis ervan voor de architectuur.

Bijvoorbeeld: veertig Q-heads en acht KV-heads vormen vijf Q-heads per KV-groep. De formule voor de opgeslagen cache gebruikt acht, niet veertig. Deze verhouding beschrijft niet het volledige geheugen van de attention: bewerkingen of conversies kunnen tijdelijke buffers produceren.

Wijzig dit aantal niet zomaar om de geheugenbehoefte van een al getraind model te verlagen. Het attention-schema maakt deel uit van de architectuur. Twee modellen met verschillende aantallen heads worden niet tot equivalente varianten door een capaciteitsberekening; hun kwaliteit moet afzonderlijk worden beoordeeld.

Technische bronnen: Hugging Face — velden van LlamaConfig en onderscheid tussen MHA, MQA, GQA · PyTorch — dimensies van Q/K/V en beperkingen van GQA-attention

03 /

De formule en zijn eenheden opstellen

In het uniforme geval is L het aantal lagen, Hkv het aantal KV-heads, D hun dimensie, T het aantal posities dat per sequentie wordt bewaard, B het aantal sequenties en q het aantal bytes per waarde. De factor twee telt K en V mee. Deze benadering veronderstelt keys en values met dezelfde dimensie en hetzelfde formaat, zonder compressie of prefix-sharing.

Reken alleen het eindresultaat om: één GiB is 1.073.741.824 bytes; één decimale GB is 1.000.000.000 bytes. Houd de bytes in je notities aan om te voorkomen dat een afronding of een eenheidswijziging een verschil verbergt.

Voor verschillende lengtes zonder padding vervang je B × T door de som van de werkelijk opgeslagen posities. Voor heterogene lagen sommeer je laag per laag. Een dense opslag met padding, een toewijzing per blok of een statische reservering vereist dat je de toegewezen plaatsen meetelt, die meer kunnen zijn dan de nuttige tokens.

Theoretische KV (bytes) = 2 × L × Hkv × D × T × B × q; KV (GiB) = KV (bytes) ÷ 1.073.741.824

Technische bronnen: Hugging Face — dimensies van de cache-tensors · NIST — decimale eenheden en binaire prefixen

04 /

Uitgewerkt voorbeeld: zes sequenties, zonder GPU-meting

Neem een fictieve architectuur van veertig lagen, acht KV-heads en een dimensie van 128. Stel een uniforme cache van twee bytes per waarde. Elke sequentie krijgt maximaal 3.072 invoertokens en een reservering voor 1.024 extra tokens, dus een bovengrens van 4.096 posities. Dit zijn pedagogische aannames, niet de bevestigde configuratie van een model.

De berekende kosten per positie en per sequentie zijn 2 × 40 × 8 × 128 × 2 = 163.840 bytes. Een sequentie van 4.096 posities vertegenwoordigt dan 671.088.640 bytes, ofwel 0,625 GiB. Zes sequenties geven 4.026.531.840 bytes, ofwel 3,75 GiB voor alleen de cache.

De bewaarde lengte verdubbelen verdubbelt deze post in deze formule. Acht KV-heads vervangen door veertig vermenigvuldigt die met vijf, terwijl alle andere aannames gelijk blijven. Deze verhoudingen voorspellen geen versnelling, kwaliteitsverlies of compatibiliteit van een werkelijk model.

Alleen theoretische rekenkunde: L = 40, D = 128, q = 2 bytes; gewichten en tijdelijke buffers uitgesloten.
Sequenties BPosities TKV-headsBerekende bytesGiB
14 0968671 088 6400,625
64 09684 026 531 8403,75
68 19288 053 063 6807,5
64 0964020 132 659 20018,75
05 /

Het budget aanpassen aan de cache-strategie

Een dynamische cache groeit met de bewaarde posities. Een statische cache reserveert een maximale capaciteit: dimensioneeer die reservering, niet alleen de korte query die bij het opstarten wordt waargenomen. Voor sliding-window attention kunnen bepaalde lagen hun geschiedenis aftoppen; lagen met volledige attention vragen een afzonderlijke berekening.

Het quantiseren van de cache en het offloaden ervan naar de CPU zijn andere strategieën, afhankelijk van model en software. Ze veranderen de beperkingen voor opslag, overdracht of berekening. Het quantiseren van de gewichten bewijst niet dat de cache hetzelfde formaat heeft.

Noteer de cache-klasse en zijn expliciete parameters. Controleer ook het vrijgeven van de plaatsen na het beëindigen of annuleren van een verzoek. Voor een werklast met zowel korte als lange sequenties kan een uniforme maximale reservering zwaarder wegen dan alleen de som van de nuttige inhoud.

Technische bronnen: Hugging Face — dynamische, statische, gequantiseerde en offloaded caches

06 /

Een representatieve werklast stap voor stap verifiëren

Stel drie gevallen op: gebruikelijke invoer, verwachte lange invoer en het maximaal toegestane aantal gelijktijdige verzoeken. Leg model, tokenizer, template, generatielimiet en stopregel vast. Varieer één dimensie tegelijk; een ingekort antwoord of een afgekapt document verandert het geleverde werk.

Meet laadtijd, initiële verwerking van de invoer en generatie afzonderlijk. Synchroniseer het device rond de getimede fasen, houd de beginwaarden van het geheugen en de pieken bij. De geheugenmethode verklaart waarom allocated en reserved niet bij elkaar opgeteld worden en waarom het verschil van hun maxima de cache niet isoleert.

Je controle moet uitmonden in een geteste bovengrens en acceptabele uitvoer: IDs van voltooide verzoeken, fouten, geproduceerde lengte en kwaliteitscriterium. Een run die op een korte invoer slaagt, valideert niet de maximale gelijktijdigheid. Een geheugenfout vóór het einde vormt geen meting van de behoefte van een volledige uitvoering.

Technische bronnen: PyTorch — synchronisatie van het werk op het gekozen device · PyTorch — bereik van de geheugentellers

07 /

Sluit fouten uit die de keuze vertekenen

Zet de berekende cache niet om in totale GPU-capaciteit. Voeg een analyse toe van gewichten, tijdelijke activaties, bewaarde uitvoer en software. Deel dit volume ook niet automatisch door het aantal kaarten: de plaatsing van lagen of heads moet daadwerkelijk geconfigureerd en op elk device geverifieerd worden.

De notebook IteraGPU Lab is een instrumentatieoefening op een klein dense netwerk zonder attention. Hij helpt om geheugenfasen te lezen; de parameter context valideert deze KV-berekening niet. Gebruik de belastingsfiche en de map inferentie om de test van je eigen model voor te bereiden.

Vergelijk de capaciteiten van de aanbiedingen pas nadat je het rekenkundige volume, het daadwerkelijk waargenomen maximum en de nog niet geteste gevallen hebt onderscheiden. Het huurforfait organiseert je werkvenster; het garandeert geen enkele contextlengte of generatiesnelheid.

  • Q-heads en KV-heads verwarren: neem de configuratie van de architectuur over.
  • Alleen de prompt budgetteren: generatie en effectieve reservering meenemen.
  • ‘4-bits gewichten’ lezen als ‘4-bits cache’: beide formaten vastleggen.
  • Gelijktijdigheid vergeten: tel de daadwerkelijk aanwezige sequenties.
  • Gedeeld geheugen tussen kaarten beloven: de werkelijke plaatsing verifiëren.

Praktische vragen

Kan ik de KV-cache kennen op basis van alleen het aantal parameters?

Nee. Je hebt ook de architectuur van de attention-lagen nodig, de KV-heads, hun dimensies, het cacheformaat, de bewaarde posities en de aanwezige sequenties. Twee modellen van vergelijkbare grootte kunnen verschillende KV-budgetten vragen.

Verbruikt een statische cache alleen de lengte van mijn verzoek?

Je moet de gereserveerde capaciteit dimensioneren. Een kort verzoek laat niet toe die maximale toewijzing af te leiden. Leg de cacheparameters vast en meet de configuratie die daadwerkelijk is aangemaakt.

Is het resultaat van de formule voldoende om een kaart te kiezen?

Het schat alleen de cache volgens aangekondigde aannames. De keuze moet ook rekening houden met de andere geheugenposten, de softwarecompatibiliteit en een volledige test met representatieve context, gelijktijdigheid en kwaliteit.