Det her lærer du – og hvorfor det betyder noget

Hvis du bygger eller deployer maskinlæring lokalt på en Mac med Apple Silicon, er den klassiske flaskehals sjældent “kan modellen køre?” men snarere “kan den køre hurtigt nok – og på den rigtige hardware?”. Målet her er at få PyTorch-modeller til at udnytte GPU’en på Apple Silicon ved hjælp af ExecuTorch og en MLX Delegate.

Guiden giver dig en praktisk, trinvis tilgang til at komme i gang, hvad du skal holde øje med undervejs, og hvordan du tænker om performance, kompatibilitet og fejlsøgning, uden at gøre det unødigt kompliceret.

Hvad er ExecuTorch MLX Delegate (kort fortalt)

Ud fra kilden handler det om at køre PyTorch-modeller på Apple Silicon-GPU’er via ExecuTorch, hvor MLX Delegate fungerer som broen til GPU-acceleration på Apple-platformen. Det er relevant, fordi det flytter inference tættere på den hardware, du allerede har på skrivebordet – og fordi Apple Silicon typisk har en GPU, der er værd at bruge, når du vil have lavere latenstid og højere throughput lokalt.

Før du går i gang: beslutninger, der sparer tid senere

1) Hvad er dit mål?

Inden du rører ved kode eller build-systemer, så vælg et konkret mål. Det påvirker, om du kan nøjes med en hurtigt proof-of-concept, eller om du skal tænke i stabilitet og reproducerbarhed:

  • Prototype: hurtig validering af om en given PyTorch-model kan køre via ExecuTorch og ramme GPU’en.
  • Produkt/edge: fokus på determinisme, versioner, performance-målinger og robust fallback.

2) Vælg en lille model først

Start med en model, der er let at teste og måle. Små modeller hjælper dig med at skille “setup-problemer” fra “model-grafer der ikke kan oversættes”. Når pipeline virker, kan du skifte til din rigtige model.

Trin-for-trin: sådan kommer du i gang

Da den faktiske “sandhed” i denne sag ligger i kildeartiklen (PyTorch-blogindlægget), er det praktiske workflow her bygget omkring en typisk ExecuTorch-tilgang: du tager en PyTorch-model, eksporterer den til et format ExecuTorch kan arbejde med, og kører den med MLX Delegate, så GPU’en bruges til compute.

Trin 1: Åbn kildelinken og afstem med din platform

Start med at have PyTorch-artiklen åben, da den er den primære opskrift. Notér især:

  • Hvilken modeltype eksemplet bruger (så du kan sammenligne med din egen)
  • Hvordan export/konvertering udføres
  • Hvordan MLX Delegate aktiveres i runtime

Trin 2: Forbered din model til export

Målet er at få din PyTorch-model i en form, der kan køres af ExecuTorch. Det kræver typisk, at modellen er “inference-klar”: fast eval-tilstand, faste input-shapes (hvis dit flow kræver det), og at du undgår dynamiske konstruktioner, der er svære at repræsentere i en optimeret graf.

Praktisk tjekliste:

  • Sæt modellen i eval-mode og frys det, du kan
  • Fastlæg et repræsentativt input til tracing/export
  • Hold øje med special-ops, der kan kræve fallback

Trin 3: Eksportér til ExecuTorch-formatet

Følg eksporttrinnene fra kildeartiklen. Det centrale er, at outputtet skal være noget, ExecuTorch kan indlæse og eksekvere, så du kan vælge en delegate (i dette tilfælde MLX) til at afvikle på Apple Silicon-GPU’en.

Hvis du rammer problemer her, er de typisk af tre typer:

  • Grafen kan ikke eksporteres (modelstruktur/ops)
  • Export lykkes, men runtime fejler (op-implementering, shapes, datatyper)
  • Det kører, men uden acceleration (delegate ikke aktiv, fallback til CPU)

Trin 4: Kør inference med MLX Delegate

Når du har en eksekverbar model, handler næste skridt om at sikre, at du faktisk bruger MLX Delegate – ikke bare “kører noget, der virker”. Delegates kan være lidt som at slå et lys til og fra: output bliver det samme, men du vil kunne se det på hastighed, GPU-aktivitet og ressourceforbrug.

Under eksekvering bør du holde øje med:

  • Latenstid pr. inference (og variation over tid)
  • Warm-up (første kørsel kan være langsommere)
  • GPU-udnyttelse (kørsel vs. idle)

Pro TipMål både første inference og de næste 50–100; på Apple Silicon kan “warm-up”-effekten være markant, så en enkelt timing fortæller ofte mere om cache/opsætning end om reel performance.

Sådan ved du, om du faktisk rammer GPU’en

Det mest almindelige fejlbillede er at tro, man kører accelereret, fordi det “føles hurtigt”. I praksis bør du have et simpelt bevis-batteri:

  • Benchmark A/B: kør samme input med og uden delegate (eller med en CPU-fallback) og sammenlign.
  • Stabilitet: gentag målingerne, så du ikke konkluderer på én heldig kørsel.
  • Ressourcer: tjek systemets GPU-belastning under kørsel.

Typiske problemer – og hvordan du kommer videre

Problem: Export fejler på bestemte lag/ops

Løsning: Skær modellen ned til et mindre delnetværk og eksportér gradvist. På den måde finder du hurtigt den konkrete op, der blokerer dit flow. Overvej om du kan erstatte den med en mere standard operation.

Problem: Runtime kører, men performance er skuffende

Løsning: Tjek om du måler “før” warm-up er færdig. Sørg også for at input-størrelser er realistiske; meget små batches kan gøre overhead mere synligt end compute. Endelig kan en del af grafen stadig køre på CPU via fallback.

Problem: Output afviger fra din PyTorch-reference

Løsning: Valider med et fast seed og samme præprocessering/postprocessering. Sammenlign output på et par kendte cases og mål forskellen numerisk (ikke kun visuelt). Små forskelle kan være acceptable afhængigt af brugsscenarie, men du skal vide, at de er der.

Min vurdering

Det interessante ved kombinationen PyTorch + ExecuTorch + MLX Delegate er ikke bare “GPU er hurtig”. Det er, at det potentielt flytter en stor del af ML-arbejdet ind på en Mac, uden at du skal tænke i eksterne CUDA-maskiner for hver iteration. For udviklere betyder det kortere feedback-loop og lettere lokal test; for produkter betyder det, at Apple Silicon kan bruges mere direkte som inference-platform.

Den praktiske realitet er, at succes ofte afhænger af, hvor “pæn” din modelgraf er: jo mere standardiserede ops og jo mere stabilt input-setup, desto mere gnidningsfrit går eksport og kørsel. Når det spiller, er gevinsten typisk mest tydelig ved gentagne inference-kørsler og workloads, der ellers ville spise CPU’en.

Næste skridt

Når du har din første model kørende med MLX Delegate, så udbyg i denne rækkefølge:

  • Tilføj et reproducerbart benchmark-script
  • Log hvilke dele der kører på delegate vs. fallback
  • Skalér op til din rigtige model og dine rigtige input

For den konkrete opskrift og de præcise kommandoer/eksempler: brug PyTorch-indlægget som facit og lad denne guide være din tjekliste for, hvad du skal sikre undervejs.

Kilde: pytorch.org