Când un model AI se oprește cu „CUDA out of memory”, primul impuls este să te uiți la câtă memorie video pare liberă. În PyTorch, însă, mesajul poate fi înșelător dacă îl citești doar ca pe o problemă de capacitate totală. Uneori există VRAM nefolosită, dar allocatorul nu găsește un bloc suficient de potrivit pentru următoarea alocare. Aici intră în scenă memory snapshots: un mod practic de a vedea ce s-a alocat, când, de unde din cod și cum s-a schimbat memoria pe durata rulării.
De ce apare OOM când „mai există” VRAM
PyTorch folosește un CUDA caching allocator. Pe scurt, când memoria este eliberată de tensorii tăi, ea nu este neapărat returnată imediat sistemului, ci poate rămâne rezervată de PyTorch pentru reutilizare. De aceea apar diferențe între memoria alocată efectiv tensorilor și memoria rezervată de allocator.
Fragmentarea apare când memoria disponibilă este împărțită în bucăți care nu se potrivesc bine cu ce urmează să aloci. Poți avea, aparent, suficientă memorie liberă în total, dar nu sub forma unui bloc util pentru o operație mare: un batch mai mare, o matrice de atenție, un buffer temporar sau o activare păstrată prea mult.
Ce sunt memory snapshots în PyTorch
Documentația PyTorch descrie memory snapshots ca fișiere care pot fi salvate și apoi analizate în viewerul vizual de la pytorch.org/memory_viz. Instrumentul arată segmentele de memorie, alocările active, istoricul evenimentelor și stack trace-uri care indică zona de cod responsabilă pentru alocare, dacă istoricul a fost pornit înainte de momentul relevant.
Fluxul de bază este simplu: pornești înregistrarea, rulezi scenariul care produce sau se apropie de OOM, salvezi snapshotul și îl deschizi în viewer. API-urile folosite frecvent în exemple sunt torch.cuda.memory._record_memory_history() și torch.cuda.memory._dump_snapshot(). Pentru că au underscore, trebuie tratate ca instrumente de diagnostic: verifică documentația versiunii PyTorch folosite înainte să le introduci într-un workflow stabil.
Cum le folosești fără să ascunzi problema
Începe cu un script cât mai apropiat de cazul real, dar reproductibil: același model, aceeași dimensiune de batch, aceleași setări de precizie, aceeași ordine a pașilor. Pornește istoricul memoriei cât mai devreme, ideal înainte de încărcarea modelului sau înainte de faza suspectă. Dacă OOM-ul apare după multe iterații, salvează snapshotul periodic sau în blocul de excepție, ca să prinzi starea de dinaintea eșecului.
În viewer, uită-te la două lucruri. Primul este linia temporală: vezi dacă memoria urcă treptat, ceea ce poate indica un leak, obiecte păstrate accidental sau liste care rețin tensori. Al doilea este harta segmentelor: vezi dacă apar multe blocuri mici, spații libere între ele și alocări mari care eșuează după o perioadă de rulare. Stack trace-urile sunt cele care leagă imaginea de cod: stratul, funcția sau pasul de antrenare unde se creează presiunea reală.
Ce remedii merită încercate
Dacă snapshotul arată un vârf clar, soluția poate fi reducerea batch size-ului, gradient accumulation, mixed precision sau checkpointing pentru activări. Dacă vezi creștere continuă, caută tensori păstrați fără detach, liste de logging care țin referințe GPU, callback-uri sau cicluri de referință. Blogurile PyTorch despre GPU memory explică inclusiv cazuri în care reference cycles pot ține tensori în viață mai mult decât te aștepți.
Pentru fragmentare, documentația PyTorch menționează variabila PYTORCH_CUDA_ALLOC_CONF, cu opțiuni precum max_split_size_mb și expandable_segments. Aceste setări pot ajuta în unele scenarii, dar nu sunt rețete universale. Schimbă-le doar după ce ai un snapshot și măsurători, altfel riști să muți problema în altă parte sau să reduci performanța.
Un obicei bun pentru echipele AI
Pentru proiectele care rulează modele mari, memory snapshots ar trebui tratate ca un instrument de depanare, nu ca o ultimă soluție disperată. Salvează configurația experimentului, versiunea PyTorch, GPU-ul, batch size-ul și snapshotul relevant. Când eroarea revine, comparația devine mult mai ușoară.
Mesajul important este acesta: „mai există VRAM” nu înseamnă automat că următoarea alocare poate reuși. Cu memory snapshots, nu mai ghicești. Vezi ce alocări au umplut memoria, de unde vin și dacă problema este un vârf normal, o scurgere de memorie sau fragmentare produsă de patternul de alocare.
Surse
- PyTorch Documentation — Understanding CUDA Memory Usage
- PyTorch Documentation — CUDA semantics / Memory management
- PyTorch Blog — Understanding GPU Memory 1: Visualizing All Allocations over Time
- PyTorch Blog — Understanding GPU Memory 2: Finding and Removing Reference Cycles
- PyTorch memory visualizer
