GPU's voor je projecten · crypto-betaling zonder KYC Hoe huren
Nederlands
Console openen
Praktische gids / KERNODECK

Er verschijnt een CUDA-fout: welke bewerking moet je onderzoeken?

Bewaar de eerste fout, identificeer de betrokken batch en reduceer de toepassing tot de bewerking die hem veroorzaakt. Op CUDA kan asynchrone uitvoering de fout later laten opduiken dan zijn oorzaak. Controleer daarna de indices, vormen, typen en apparaten voordat je de omgeving wijzigt. Deze methode betreft een al gestarte toepassing; ze vervangt niet de initiële controle van de beschikbaarheid van de GPU.

7 min leestijd · Gids voor ontwikkelaars

De eerste fout en zijn context bewaren

Deze gids begint na een geslaagde start: PyTorch ziet het apparaat, waarna je toepassing faalt op een batch of een operator. Als geen enkele kleine berekening werkt, begin dan opnieuw bij de initiële diagnose. Zo niet, bewaar de eerste fout, het iteratienummer en de laatste voltooide stap. Een reeks berichten na de eerste fout kan eerder de gevolgen ervan beschrijven dan meerdere onafhankelijke oorzaken.

Noteer de code-revisie, de Python- en PyTorch-versies, de backend, het numerieke type en de vorm van de invoer. Geef voor de data de voorkeur aan een interne identificatie en de dimensies boven een volledige kopie van de inhoud. Zoek wat de foutieve batch onderscheidt: lengte, ontbrekend doel, laatste onvolledige batch, augmentatie of een zelden gebruikte tak. Dit dossier maakt het mogelijk het geval opnieuw te maken zonder een hele campagne opnieuw te starten.

De foutieve start lokaliseren ondanks asynchroon gedrag

Op CUDA worden bewerkingen in de wachtrij geplaatst en kunnen ze voltooien nadat de Python-functie is teruggekeerd. Een fout die tijdens een kopie naar CPU of het lezen van een scalair naar boven komt, kan dus van een eerdere berekening afkomstig zijn. De PyTorch-documentatie legt deze asynchrone uitvoering uit. De regel die de trace aangeeft, is een observatiepunt om te onderzoeken, niet altijd de oorzaak.

Voor een korte reproductie op NVIDIA/CUDA kun je een aparte start met CUDA_LAUNCH_BLOCKING=1 voorstellen. Deze optie maakt de aanroepen synchroon en kan de fout dichter bij de oorsprong brengen. Ze dient voor diagnose, niet voor timing. Je kunt ook tijdelijk synchronisaties tussen grote stappen plaatsen om het verdachte interval te verkleinen. Verwijder deze instrumentatie daarna: ze verandert de gebruikelijke planning.

Het volgende commando is didactisch en is niet uitgevoerd. Het veronderstelt een POSIX-terminal en een bestaand script train.py. De toewijzing geldt alleen voor deze start; pas de syntaxis aan je shell aan. Generaliseer deze NVIDIA-variabele niet naar een ROCm-stack.

Voorgestelde diagnosestart, niet uitgevoerd
CUDA_LAUNCH_BLOCKING=1 python train.py

Een foutenfamilie lezen zonder te snel te concluderen

Het bericht verkleint het zoekveld; het vervangt geen reproduceerbaar geval. Een index buiten het domein, een tensor op het verkeerde apparaat en een onmogelijke toewijzing vragen om verschillende controles. Behoud het onderscheid tussen ongeldige data, operatorcontract en binaire omgeving. Door tegelijk de batch, de precisie en de bibliotheken te wijzigen, verdwijnt dit onderscheid.

Probeer na een assertie die op het apparaat is uitgevoerd niet dezelfde training in hetzelfde proces voort te zetten. NVIDIA geeft aan dat cudaErrorAssert bestaande toewijzingen ongeldig maakt en dat je het proces moet beëindigen en opnieuw starten. In een notebook betekent dit dat je de kernel opnieuw moet starten vóór de gecorrigeerde reproductie. Opnieuw starten verhelpt echter noch een verkeerd doel noch een ongeldige index.

Scroll door de tabel om alle kolommen te lezen.
Diagnosepistes, zonder automatische koppeling tussen bericht en oorzaak
Waargenomen aanwijzingEerste controleConclusie om te vermijden
device-side assertIndices, doelen en voorwaarden van de operatorDe GPU is sowieso defect
Out of memoryVormen, levensduur van tensors, procesgeheugenElke CUDA-fout is een gebrek aan VRAM
Operator of kernel niet beschikbaarVersies, extensie, backend en dtypeAlles willekeurig opnieuw installeren
Verschillende apparatenPlaatsing van het model en elke invoerEen kopie toevoegen zonder de oorsprong te begrijpen

Uitgewerkt voorbeeld: een klasse 4 in een probleem met vier klassen

Neem een didactische classificator waarvan de uitvoer vier kolommen heeft. De klassen zijn geïndexeerd van 0 tot 3. Een annotatiebestand met de waarde 4 kan wijzen op een codering van 1 tot 4 of op een onverwachte vijfde klasse. De uitvoergrootte simpelweg vergroten zou een beperking laten verdwijnen zonder de betekenis van de annotaties op te lossen.

De onderstaande controle wordt toegepast vóór het overbrengen van de CPU-doelen. Ze is niet uitgevoerd. Ze illustreert het CrossEntropyLoss-contract voor klasse-indices van het type long, met ignore_index=-100 expliciet gekozen. Ze dekt geen doelen die uit waarschijnlijkheidsverdelingen bestaan. In dit scenario moet [0, 2, 4] worden geweigerd; dit verwachte resultaat is afgeleid uit de regel, niet gepresenteerd als een meting.

Corrigeer daarna de mapping in de gegevensvoorbereiding en controleer de bijectie met de klassenamen. Trek niet overal 1 af zolang je niet weet of alle bronnen dezelfde conventie gebruiken. Voeg het foutieve geval toe aan een kleine verificatieset die bij het project wordt bewaard.

Didactische CPU-guard voor klasse-indices
import torch

classes = 4
ignore_index = -100
target = torch.tensor([0, 2, 4], dtype=torch.long)
if target.ndim != 1 or target.dtype != torch.long:
    raise ValueError("Cibles : vecteur d’indices attendu")
valid = target[target != ignore_index]
if valid.numel() == 0:
    raise ValueError("Aucune cible exploitable dans ce batch")
if bool(((valid < 0) | (valid >= classes)).any()):
    raise ValueError("Indice de classe hors domaine")

Het programma verkleinen zonder de trigger te wissen

Speel eerst één enkele invoer of één enkele batch opnieuw af met dezelfde transformaties. Verwijder de remote tracking, het wegschrijven van resultaten en de branches die niets met de fout te maken hebben. Behoud de dtype, de vormen en de verdachte operator. Als de fout afhangt van een specifieke lengte of geheugenindeling, kan een willekeurige kleine tensor de fout niet meer reproduceren.

Vergelijk één wijziging tegelijk: optionele extensie uitgeschakeld, referentie-operator, gebruikelijke precisie of zelfs dezelfde bewerking op CPU wanneer die daar bestaat. Een succes op CPU is een aanwijzing, geen CUDA-validatie. Noteer voor een aangepaste functie ook de aannames over strides, contiguïteit en groottes. Zoek een voorbeeld dat vóór de correctie faalt en erna slaagt, met een uitvoercontrole in plaats van alleen het uitblijven van een exception.

De correctie verifiëren op het oorspronkelijke bereik

Een acceptabele correctie moet het minimale geval, de aangrenzende gevallen en een representatief deel van het oorspronkelijke traject doorstaan. Neem met name de laatste batch, een korte invoer, een lange invoer en de grenswaarden van de mapping opnieuw door. Controleer dat de geweigerde elementen identificeerbaar zijn en dat het aantal verwerkte invoeren het verwachte blijft. Exceptions stilzwijgend negeren kan een zichtbare crash omzetten in een onvolledig resultaat.

Schakel de diagnosemodus uit, start opnieuw vanuit een vers proces en bevestig het gedrag met de normale configuratie. Bewaar de oorzaak, de toegepaste wijziging en de non-regressiecontrole. Als je een training had onderbroken, hervat dan vanuit een coherente checkpoint die vóór de fout is gevalideerd; het bestaan van een bestand dat tijdens een crash is geschreven, garandeert de hervatting ervan niet.

Weten wanneer je een gerichtere analyse moet vragen

Als hetzelfde minimale geval met geldige invoeren faalt, stel dan een nauwkeurige aanvraag op: bewerking, vormen, types, backend, versies en het eerste relevante bericht. Verwijder persoonlijke identificatiegegevens en overbodige paden. Een binaire extensie kan een eigen compatibiliteitsmatrix vereisen; de algemene ondersteuning van PyTorch valideert die extensie niet automatisch.

Op ROCm behoudt PyTorch de interface torch.cuda en de apparaatnamen cuda. Controleer torch.version.hip om deze stack te identificeren voordat je een NVIDIA-procedure toepast. Berichten, tools en diagnoseopties kunnen verschillen. Geen enkele controle die hier wordt beschreven bewijst de compatibiliteit van voorbereide omgevingen met een Kernodeck-aanbod; gebruik deze criteria om je behoefte te preciseren voordat je de GPU kiest.

Jouw vragen

Lost CUDA_LAUNCH_BLOCKING=1 een CUDA-fout op?

Nee. Het maakt CUDA-aanroepen synchroon om de foutieve bewerking te helpen lokaliseren. Gebruik het op een korte reproductie, verhelp daarna de oorzaak en verwijder het voordat je de normale prestaties meet.

Kan ik een notebook voortzetten na een device-side assert?

Herstart de kernel voordat je het gecorrigeerde geval opnieuw uitvoert. Een assert aan de kant van het apparaat kan de context onbruikbaar en de toewijzingen ongeldig achterlaten. De herstart herstelt een context, maar corrigeert geen foutieve indices of gegevens.

Als dezelfde berekening op CPU slaagt, is de GPU dan defect?

Nee. Dat resultaat onderscheidt twee uitvoeringspaden. Een dtype, een extensie, een kernel of een gegevensbeperking kan het verschil verklaren. Reproduceer een minimale bewerking op de betreffende GPU-stack voordat je conclusies trekt.

Is de NVIDIA-procedure identiek op ROCm?

Niet volledig. PyTorch voor ROCm gebruikt ook torch.cuda, maar de tools en sommige diagnosevariabelen verschillen. Identificeer HIP met torch.version.hip en raadpleeg de documentatie die overeenkomt met de werkelijke backend.