Verwachtingen uitleggen voordat je een krachtigere GPU zoekt.

Het probleem beschrijven met een resultaat en een venster

Vervang "de GPU werkt niet" door een verifieerbare observatie: het eerste resultaat komt laat, de stappen vertonen pauzes of het aantal geaccepteerde uitvoeren neemt af. Geef de invoerset, de versie van de toepassing, de instellingen en de waargenomen periode. Een eerste start kan andere fasen bevatten dan een al voorbereide uitvoering; meng ze niet zonder dat te vermelden.

Splits het traject in het openen van bestanden, CPU-voorbereiding, overdracht, GPU-berekening, wegschrijven en validatie. Deze fasen kunnen elkaar overlappen: het beeld is een hypothese die aan de traces moet worden getoetst. Noteer de grenzen met dezelfde tijdzone en voldoende precisie. Een hardwaregrafiek die na de pauze is opgenomen, kan de pauze niet verklaren, zelfs niet als de waarde ongewoon lijkt.

Percentages en geheugen correct lezen

In NVIDIA SMI geeft het GPU-gebruik aan welk deel van het bemonsteringsinterval ten minste één kernel actief was. Het is geen beoordeling van de prestaties van alle componenten. Het geheugengebruik beschrijft de lees- of schrijfactiviteit; het mag niet worden verward met de hoeveelheid bezet geheugen. De documentatie vermeldt ook dat bepaalde velden afhankelijk van de omgeving niet beschikbaar kunnen zijn.

Bewaar dus de exacte naam van de metriek en de bijbehorende eenheid. Een grote hoeveelheid geheugen kan overeenkomen met gegevens die in afwachting worden bewaard; een lage activiteit kan tijdens een normale voorbereidingsfase optreden. Omgekeerd toont een hoge activiteit niet aan dat het programma nuttig werk verricht. Je moet de uitvoer en de voortgang van de toepassing samen met de hardware bekijken.

Een gecorreleerde en voldoende korte meting verzamelen

Kies een representatieve sequentie en beperk de verzameling tot die sequentie. Noteer de tijden, de GPU-identifier, de activiteit, het bezette geheugen en de fasen van de applicatie. Gebruik daarnaast de tools die op je systeem beschikbaar zijn om het CPU-proces te observeren, zijn wachttijden, zijn lees- en schrijfacties. Een gemiddelde over alle cores kan één verzadigde thread verbergen; kijk ook naar de betrokken processen.

Het onderstaande leescommando is bedoeld voor een toegestaan NVIDIA-doel dat al over NVIDIA SMI beschikt. Het is niet uitgevoerd voor deze gids. Het behoudt de eenheden in de CSV en toont één observatie per seconde totdat het wordt onderbroken. Controleer de velden die door jouw versie worden ondersteund en stop de verzameling aan het einde van het scenario. Een N/A-veld blijft onbekend: zet het niet om in nul.

Het minimale logboek verbindt een taakidentifier, een tijd met tijdzone, de huidige fase, een identificeerbare invoer of batch, de voortgang en de eventuele fout. Het mag geen geheimen bevatten of bedrijfsinhoud die niet nuttig is voor de diagnose. Als telemetrie ontbreekt, controleer dan eerst het verzamelinstrument en de voortgang van de applicatie: een lege curve bewijst niet dat een proces is gestopt. Markeer de periode zonder observatie in plaats van die uit het geheugen te reconstrueren.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Het verschil maken tussen een spoor en een conclusie

Als de GPU-activiteit daalt terwijl de applicatie op haar invoer wacht, onderzoek dan het pad van de bestanden. Als ze daalt tijdens een lange CPU-voorbereiding, onderzoek dan die fase en haar werkelijke parallellisme. Als de apparaten wachten op de andere deelnemers van een gedistribueerde taak, controleer dan de belastingbalans en de communicatie. Meerdere symptomen kunnen samen optreden; hun correlatie is nog geen bewijs van causaliteit.

Schrijf een korte hypothese en een wijziging waarmee je die kunt onderscheiden. Zo kan het vergelijken van dezelfde al voorbereide invoer met de gebruikelijke voorbereiding een stap isoleren, op voorwaarde dat de resultaten identiek blijven. Wijzig niet tegelijk de batchgrootte, de precisie, het aantal processen en de locatie van de bestanden: een verbetering zou dan moeilijk toe te schrijven zijn.

Fictief voorbeeld: een lus van honderd seconden analyseren

Het fictieve team "Revue des maquettes" beschrijft een lus zonder overlap: zestig seconden CPU-voorbereiding, twintig GPU-berekening en dan twintig export. Het totaal is 100 seconden en het tijdaandeel dat aan de GPU-berekening wordt toegewezen is 20/100, dus 20%. Deze pedagogische berekening voorspelt niet het percentage van een samplingtool en komt niet overeen met enige meting van een GPU uit de catalogus.

Stel dat de voorbereiding kan worden teruggebracht tot dertig seconden, zonder de berekening of de uitvoer te wijzigen. De lus zou dan 30 + 20 + 20 = 70 seconden duren: dertig seconden minder, met een GPU-aandeel van 20/70, dus ongeveer 28,6%. Omgekeerd zou het hypothetisch halveren van alleen de GPU-berekening 60 + 10 + 20 = 90 seconden opleveren. Het scenario verklaart waarom het aanpakken van de langste wachttijd zwaarder kan wegen dan het wisselen van kaart.

Een fase uitdiepen met een profiler

Als de algemene observatie een trage zone aanwijst zonder die te verklaren, gebruik dan de profiler die bij de toepassing past op een kort venster. PyTorch Profiler kan CPU- en CUDA-events verzamelen en verzamelvensters organiseren. De documentatie meldt een extra belasting wanneer het vastleggen van shapes of stacks is ingeschakeld. Een gedetailleerde trace is dus een diagnostisch instrument; de totale tijd mag niet zonder voorbehoud als de normale programmeertijd worden gepresenteerd.

Houd fasenamen duidelijk genoeg om een technische bewerking aan je werk te koppelen: voorbereiding van een bestandsgroep, overdracht, toepassingsstap of publicatie van uitvoer. Begin met het detailniveau dat nodig is voor de hypothese. Maak na de wijziging een vergelijkbare observatie en daarna een uitvoering zonder zware instrumentatie. Deze tweede controle verifieert dat het voordeel ook onder gebruikelijke omstandigheden bestaat.

Correcties vermijden die het probleem verbergen

Het verhogen van de gelijktijdigheid kan de GPU vullen terwijl de schijf, het hostgeheugen of de uitvoer wordt overbelast. Het vergroten van de batchgrootte kan de latentie en het benodigde geheugen veranderen. Het verlagen van de precisie kan het resultaat wijzigen. Deze beslissingen zijn niet verboden, maar ze moeten op dezelfde bedrijfsdoelstelling worden beoordeeld, met hun neveneffecten, in plaats van te worden gekozen omdat het weergegeven percentage stijgt.

Reset een apparaat niet en wijzig de hardware-instellingen niet om een eenvoudige daling van de activiteit te diagnosticeren. Begin met lezen en laat expliciete fouten door de bevoegde verantwoordelijke onderzoeken. Vermijd ook het publiceren van ruwe traces met privépaden, vertrouwelijke instellingen of invoergegevens. Maak een nuttig fragment voor de diagnose en bewaar het volledige bewijs binnen het toegestane bereik van het team.

De diagnose afsluiten met bewijs dat nuttig is voor de beslissing

Het einddossier moet het symptoom, de gekozen hypothese, de geprobeerde wijziging, de omstandigheden en het waargenomen resultaat vermelden. Bewaar ten minste één voor/na-vergelijking op dezelfde invoerset, dezelfde kwaliteit en dezelfde einddefinitie. Als het resultaat niet overtuigend is, schrijf dan op wat is uitgesloten en welke volgende observatie nodig is. Een gedocumenteerd afgewezen spoor voorkomt dat iemand anders willekeurig opnieuw begint.

Een lage normale activiteit vraagt niet altijd om een correctie. Als de taak binnen haar deadline, kwaliteit en budget blijft, kan het verminderen van complexiteit de voorkeur verdienen boven een fragiele optimalisatie. Als een nieuwe configuratie wordt overwogen, geef de aangetoonde beperkingen door aan het acceptatiedossier. Geen enkele geïsoleerde meting rangschikt de catalogus en geen enkele waarde uit dit voorbeeld vormt een beloofde prestatie.