Waarom overtreft de geheugenpiek je schatting?

De belasting definiëren voordat je de meter kiest

'Een model van 7B' vermeldt noch de representatie van de gewichten, noch het uit te voeren werk. Noteer de revisie, het framework, de versies van de extensies, het daadwerkelijk geladen formaat en de bewerking: training, fine-tuning of generatie. Noteer voor tekst de lengtes van invoer en uitvoer; voor vision de resolutie en het aantal afbeeldingen. Een multimodaal model vereist dat je beide dimensies aanhoudt.

Bereid een gebruikelijke invoer voor, een lange maar verwachte, en een dicht bij je functionele limiet. Bewaar ze tijdens de vergelijkingen. Controleer de vormen na tokenisatie, padding, groepering of herschaling: de waarde in de configuratie bewijst niet de vorm die daadwerkelijk wordt verwerkt.

Leg ook vast wat gelijktijdig in het geheugen blijft: één sequentie, een microbatch, meerdere verzoeken of een evaluatie die na de training wordt gestart. Je vraag wordt dan verifieerbaar: past deze volledige belasting op elk gebruikt apparaat, ook tijdens de meest veeleisende stap?

• Identiteit van de proef: model of code, revisie, invoerset en seed indien van toepassing.
• Dimensies: batch, context, gegenereerde tokens, resolutie of aantal gelijktijdige verzoeken.
• Omgeving: geselecteerde GPU, driver, Python, PyTorch, CUDA- of HIP/ROCm-backend en allocator-instellingen.
• Scope: laden, berekenen, overdragen, evalueren, exporteren; eerste pass of pass na opwarming.

Gewichten berekenen zonder GB en GiB te verwarren

Een GB komt overeen met 1 000 000 000 bytes; een GiB met 1 073 741 824 bytes. De hier gebruikte PyTorch-tellers geven bytes terug. Bewaar die ruwe waarde in het resultatenbestand en pas daarna één enkele conversie toe om de regels te vergelijken. Het commerciële label van een kaart vervangt niet de capaciteit die het apparaat daadwerkelijk aangeeft.

Voor een dense verzameling van zeven miljard parameters die elk op twee bytes worden opgeslagen, vertegenwoordigen de gewichten 14 000 000 000 bytes: 14 GB, of ongeveer 13,04 GiB. Deze berekening omvat geen activaties, geen gradiënten, geen KV-cache en geen optimizer-states. Een reserve van 4 GiB toevoegen geeft ongeveer 17,04 GiB als voorbereidingshypothese; dat bewijst niet dat een workload binnen dat budget past.

De theoretische deling naar vier bits veronderstelt een uniforme compacte opslag. Een echte gekwantiseerde lading kan scales en andere informatie toevoegen, en sommige modules in een andere precisie bewaren. Het opslagformaat van de gewichten en het rekenformaat moeten dus apart in je fiche staan.

Technische bronnen: NIST — binaire prefixen en vergelijking GB/GiB · Hugging Face — gekwantiseerde formaten en modules met bitsandbytes

Bij training een volledige stap meten

De gewichten bestaan naast andere objecten: gradiënten, optimizer-states, activaties die nodig zijn voor de backward pass en tijdelijke tensors. Hun groottes hangen af van de loop, de precisie en de afmetingen van de workload. Een universele constante in bytes per parameter zou met name het effect van de microbatch en de inputs verbergen.

Instrumenteer de forward pass, de loss-berekening, de backpropagation en de update. Beperk je niet tot het laden van het model als je de states wilt observeren die je optimizer daadwerkelijk aanmaakt. Bewaar ook een meting van de eerste volledige stap: een geslaagde opwarming kan al een initialisatie hebben uitgevoerd die je bij het opstarten in het geheugen moet kunnen financieren.

Voeg de evaluatie en de export toe die je project nodig heeft. Als de fout optreedt tijdens de evaluatie, lost het enkel verkleinen van de trainingsbatch die fase niet op. Een aanpassing die weinig parameters traint, kan nog steeds een basismodel en omvangrijke activaties behouden.

Technische bronnen: Hugging Face — geheugencategorieën tijdens training

Bij inferentie context en gelijktijdigheid volgen

Bij een autoregressieve generatie met attention bewaart de KV-cache states die aan tokens gekoppeld zijn. Voor een uniforme dense cache hangt de grootte af van de lagen, de KV-heads, hun dimensie, de bewaarde tokens en de sequenties die samen aanwezig zijn. Gebruik de KV-heads van het model, niet automatisch zijn query-heads.

Rekenvoorbeeld: 32 lagen, 8 KV-heads, een dimensie van 128, 8 192 tokens, twee bytes per waarde en één sequentie geven 1 073 741 824 bytes, dus 1 GiB voor K en V samen. Vier identieke sequenties geven 4 GiB voor alleen deze post. Deze berekening meet noch de doorvoer, noch de volledige bezetting van de GPU.

Pas de formule aan op de cache die daadwerkelijk wordt gebruikt. Een sliding window bewaart niet noodzakelijk de volledige historiek; een statische cache kan zijn maximale capaciteit vooraf toewijzen. Gekwantiseerde en uitbestede caches veranderen het probleem ook. Meet de initiële verwerking van de input en de generatie afzonderlijk, zonder hun hele verschil automatisch aan de cache toe te schrijven.

Technische bronnen: Hugging Face — cachestrategieën, statische toewijzing en windows

Allocated en reserved: twee waarden die je niet optelt

memory_allocated beschrijft de bytes die door PyTorch gevolgde tensors op het apparaat innemen. memory_reserved beschrijft het geheugen dat zijn allocator met cache beheert, waaronder het geheugen dat al voor die tensors dient. Beide optellen telt een deel van het geheugen dubbel. Bewaar ze in twee afzonderlijke kolommen.

Hun max-varianten registreren elk een piek sinds het begin van de meting of sinds de laatste reset. Het zijn absolute pieken over de periode, die ook de allocaties bevatten die al bij het begin aanwezig waren. Het resultaat vertegenwoordigt dus niet automatisch alleen de objecten die tijdens de fase zijn aangemaakt.

Een systeemmeting kan een breder bereik hebben. Allocaties die rechtstreeks door een CUDA-bibliotheek worden gedaan, bijvoorbeeld bepaalde NCCL-communicatie, zijn niet allemaal zichtbaar in de PyTorch-allocator. Een verschil met een systeemtool bewijst dus op zichzelf geen lek.

Technische bronnen: PyTorch — memory_allocated · PyTorch — memory_reserved · PyTorch — max_memory_allocated · PyTorch — allocaties buiten zijn allocator

Waarom het verschil tussen de twee pieken niet de cache meet

Laten we alleen de twee fictieve momenten uit de tabel bekijken. De allocated-piek is 8 GiB en de reserved-piek 12 GiB. Hun verschil, 4 GiB, is op geen van die twee momenten het waargenomen verschil: dat bedraagt respectievelijk 2 en 6 GiB. Twee maxima beschrijven niet noodzakelijk dezelfde toestand.

Om hun onderlinge afstand op een gegeven moment te onderzoeken, lees je allocated en reserved op hetzelfde controlepunt, na synchronisatie en zonder nieuwe bewuste bewerking tussen de metingen. Je krijgt dan een verschil tussen tellers op dat moment, geen meting van de KV-cache van het model, en ook geen garantie dat dat hele verschil de volgende allocatie kan vervullen.

Neem ook de backend van de allocator op in het rapport. De documentatie van PyTorch 2.14 vermeldt dat max_memory_reserved met cudaMallocAsync de hoogste niveaus van twee pools kan combineren en zo een bovengrens van de gelijktijdige piek kan geven. Dat versterkt de noodzaak om de naam en het bereik van de teller te bewaren.

Technische bronnen: PyTorch — definitie en beperking van max_memory_reserved

Elke fase afbakenen voordat je zijn piek afleest

GPU-bewerkingen kunnen in de wachtrij staan voordat ze klaar zijn. Voor een meting per fase maak je de voorgaande taken af voordat je de pieken op nul zet, en daarna wacht je op het einde van de fase voor de meting. torch.cuda.synchronize wacht op de kernels van alle streams van het geselecteerde apparaat; die keuze vormt een expliciete grens voor dit protocol.

reset_peak_memory_stats herstart het volgen van de pieken vanaf de huidige toestand; het geeft de tensoren van het programma niet vrij. Lees eerst de beginniveaus af. Bewaar aan het einde de twee absolute pieken en de twee huidige niveaus. Presenteer het aftrekken van een beginniveau niet als het exacte volume van alle tijdelijke tensoren: ook eerdere objecten kunnen tijdens de fase zijn vrijgegeven.

Deze instrumentatie kan de gebruikelijke overlap van de fasen veranderen. Gebruik haar om het probleem te lokaliseren en verifieer daarna ook de volledige lus met zijn werkelijke ordening. Herhaal bij meerdere kaarten de metingen voor elk apparaat; een meting op cuda:0 beschrijft de andere GPU's niet.

• 1. Geef de fase een naam en noteer de exacte invoer ervan.
• 2. Synchroniseer het apparaat en lees daarna de beginwaarden van allocated en reserved af.
• 3. Roep reset_peak_memory_stats aan op datzelfde apparaat.
• 4. Voer de gedefinieerde fase uit en bewaar de uitvoer die je daarna nodig hebt.
• 5. Synchroniseer, lees de pieken en de eindniveaus af en noteer succes of fout.
• 6. Bewaar het ruwe resultaat, de dimensies en de configuratie; vul geen ontbrekende meting aan met nul.

Technische bronnen: PyTorch — synchronisatie van een apparaat · PyTorch — reset van de piekstatistieken

Eerste doorgang en doorgangen na opwarmen onderscheiden

De eerste test en een al voorbereide lus beantwoorden niet dezelfde vraag. Bewaar een spoor van het laden en de eerste doorgang, en documenteer daarna het aantal opwarmiteraties vóór de herhalingen. Verwijder een initialisatiefout niet omdat de volgende doorgangen lichter zouden zijn geweest.

Het script van IteraGPU onderscheidt model_load, inputs, cold_forward, warmup en warm_forward. De cold_forward is de eerste doorgang van het kleine model nadat het apparaat is geïnitialiseerd. Hij meet niet de volledige opstart van een server, een driver of een service. De warm_forward-herhalingen blijven in hetzelfde proces en profiteren van de bestaande toestand.

Begin voor je model een nieuwe reeks in een nieuw proces wanneer je een voorwaarde wijzigt die eerdere objecten of reserveringen kan achterlaten. Noteer de volgorde van de tests en het opwarmbeleid. Vijf keer dezelfde lus opnieuw uitvoeren en vijf processen starten vormen niet hetzelfde protocol.

De notebook en het script van IteraGPU Lab v1 gebruiken

Begin met de README en download daarna de zelfstandige notebook of het Python-script. De berekening estimate gebruikt de standaardbibliotheek. De meting vereist een geïnstalleerde PyTorch met een compatibele GPU-backend en een toegankelijk apparaat; ze downloadt geen model of pakket. De notebook vereist een omgeving die ipynb-bestanden kan lezen.

De meetoefening gebruikt een klein, origineel dicht netwerk en synthetische invoer. De opties batch, context en width beschrijven de tensors; context is hier niet de lengte van een echt LLM met KV-cache. Dit hulpmiddel dient om de meetmethode te onderzoeken en één dimensie te variëren. Het toont niet de capaciteit van een kaart voor jouw onderzoeksmodel aan.

Voer de onderstaande opdrachten uit vanuit de map met het script. Bekijk eerst het rapport environment. Als PyTorch of de GPU ontbreekt, moet measure expliciet stoppen met code 2; geen enkel CPU-resultaat mag als GPU-meting worden geïnterpreteerd. De JSON-uitvoer van een geslaagde meting wordt in jouw omgeving geproduceerd. Kies een nieuwe bestandsnaam voor elke reeks: het script weigert een bestaand resultaat te overschrijven.

De eerste opdracht herberekent de gewichten en de hypothetische reserve van 4 GiB. Gebruik voor de volgende opdrachten een apparaat dat je mag belasten en houd de dimensies in het begin bescheiden. Noteer de PyTorch-versie die daadwerkelijk wordt gebruikt: de technische referenties op deze pagina beschrijven onder meer versie 2.14, zonder te eisen dat die bij jou is geïnstalleerd.

De werking van het script is gecontroleerd op een klein geval: een lokale RTX 5070 buiten de catalogus, driver 610.62, Python 3.14.6 en PyTorch 2.11.0+cu128. De test gebruikte batch 1, context 16, width 64, float32, één opwarming en twee herhalingen. Hij valideert dit uitvoeringspad, zonder een LLM, een training of de te huur aangeboden GPU's te kwalificeren. De notebook wordt zonder uitvoer geleverd en de vergelijkingstabel zonder resultaten; de controle op het ontbreken van PyTorch is ook in een aparte omgeving geverifieerd.

python mesure_memoire.py estimate --parameters 7000000000 --bits 16 --reserve-gib 4
python mesure_memoire.py environment --device cuda:0
python mesure_memoire.py measure --device cuda:0 --batch 2 --context 128 --width 1024 --dtype float32 --warmup 3 --repeats 5 --output mesures.json

• Notebook voor berekening en meting ↓

  Zelfstandige notebook om te openen, na te lezen en uit te voeren in jouw omgeving.

• Script mesure_memoire.py ↓

  Berekening zonder externe afhankelijkheid, omgevingscontrole en expliciete GPU-meting.

• Handleiding van de map ↓

  Vereisten, opdrachten, bereik van de fasen en grenzen van de interpretatie.

• Archief IteraGPU Lab v1 ↓

  De gebundelde, geversioneerde bronnen, met hun handleiding en licentie.

• Licentie van de bronnen ↓

  Voorwaarden voor hergebruik van de geleverde bestanden.

Een storing interpreteren voordat je van kaart wisselt

Een onvolledige test blijft een nuttige observatie. Bewaar de fase, de gevraagde dimensies, de foutmelding en de laatst beschikbare waarden. Een gedeeltelijke piek vóór een verzadiging vormt niet het geheugenverbruik van een volledige uitvoering. Verklein één enkele dimensie om een geval te construeren dat slaagt, en zoek dan de grens tussen slagen en falen.

empty_cache geeft ongebruikte blokken uit de cache van de allocator vrij, zonder nog levende tensors vrij te geven. Het is geen universele oplossing voor een te grote belasting. Het aanroepen tussen elke herhaling verandert de omstandigheden: documenteer die keuze in plaats van deze proeven te mengen met proeven die de cache behouden.

Als eenvoudige tellers de situatie niet verklaren, kan een geheugentrace helpen om toewijzingen in de tijd te identificeren. Het bereik blijft beperkt tot de toewijzingen die PyTorch ziet. Een lage allocated-piek sluit dus een externe toewijzing of een andere gebruiker van de kaart niet uit.

Technische bronnen: PyTorch — wat empty_cache vrijgeeft · PyTorch — traces en grenzen van geheugenzichtbaarheid

Een marge opbouwen op basis van vergelijkbare belastingen

Vermijd een margepercentage dat als universeel wordt voorgesteld. De marge moet geïdentificeerde variaties opvangen: langere invoer, toegestane batch, evaluatie, export, bibliotheekversie of ander gebruik van de kaart. Test de verwachte grensgevallen en noteer wat buiten het bereik blijft. Een geslaagde uitvoering op één kleine invoer valideert de maximale belasting niet.

Verander één variabele tegelijk: batch 1 en dan 2 bij constante context, of contexten 2.048 en dan 4.096 bij constante batch. Behoud dezelfde inhoud en dezelfde voorbereidingsregels. Een truncatie die noodzakelijke informatie verwijdert, maakt de taak anders, ook al verlaagt ze de piek.

Als de gewichten domineren, bestudeer dan een ander formaat met controle van de kwaliteit. Als de activaties domineren, kunnen microbatch of activation checkpointing mogelijke pistes zijn. Dat laatste ruilt geheugen voor herberekening: meet ook de duur en controleer de resultaten. Als de KV-cache domineert, onderzoek dan context, gelijktijdigheid en cachestrategie. Het vergelijkingsdossier vult deze aanpak aan met een gemeenschappelijke kwaliteitsregel.

Technische bronnen: PyTorch — activation checkpointing en herberekening

Van de trace naar een configuratiebeslissing

Je verwachte output is een korte fiche: schatting van de gewichten, maximaal geteste belasting, geslaagde of mislukte fasen, vier tellers met eenheden, omgeving en gemaakte keuze. Voeg het ruwe resultaat aan deze fiche toe. Scheid wat je hebt berekend, wat je hebt geobserveerd en wat je nog veronderstelt.

Vergelijk daarna de behoefte met de capaciteit van elke kaart, met behoud van de softwarebeperkingen. Meerdere GPU's vereisen een verdeling van het werk en de gegevens; hun aanwezigheid creëert niet automatisch één enkel geheugenreservoir voor de applicatie. Een fout op de ene kaart kan blijven bestaan ondanks vrije geheugenruimte op een andere.

Het PyTorch-protocol gebruikt de interface torch.cuda; een HIP/ROCm-build van PyTorch hergebruikt die naam. Identificeer de werkelijk geïnstalleerde backend voordat je twee hardwarefamilies vergelijkt. Het gebruik van dezelfde Python-functie bewijst niet dat de kernels, de precisies of de resultaten gelijkwaardig zijn.

Met de dimensioner kun je de oorspronkelijke hypothese hernemen; met de GPU-fiches kun je de capaciteiten vergelijken. Keer daarna terug naar hetzelfde werkgeval om de keuze te controleren. Het kleine netwerk uit de download blijft een instrumentatieoefening: alleen de uitvoering van jouw belasting, in haar gedocumenteerde omgeving, kan jouw eigen marge valideren.

Technische bronnen: NVIDIA — werk verdelen over meerdere GPU's · PyTorch — interface torch.cuda in HIP/ROCm-builds