7 teknikker til sparsitet i transformermodeller

Ustruktureret vægt-pruning handler om at sætte et stort antal enkeltvægt-elementer i Transformer-matricer til 0. Resultatet er “tyndere” matricer, der - i hvert fald teoretisk - reducerer både beregning og hukommelsesforbrug uden at ændre arkitekturen. Nedenfor gennemgår vi de mest udbredte teknikker, hvordan man vælger sparsity-rate, og hvorfor efterfølgende retræning er afgørende for at bevare modellens kvalitet.

1. Hvorfor ustruktureret sparsitet?

• Maksimal fleksibilitet: Man kan fjerne præcis de vægte, der bærer mindst information, uanset deres position.
• Minimal ændring af arkitektur: Matrix-dimensioner og API’er forbliver de samme; kun indholdet bliver tyndt.
• Akademisk velafprøvet: Teknikken har været studeret siden tidlige CNN’er og fungerer også på Transformers.
• Ulempe: Faktisk speed-up opnås kun på hardware og biblioteker, der understøtter ustruktureret sparsitet (f.eks. NVIDIA Ampere’s sparse kernels eller special-acceleratorer som Cerebras/Wave).

2. Klassiske pruning-kriterier

3. Vælg den rigtige sparsity-rate

1. Start konservativt: 30-50 % er som regel “gratis” for store sprogmodeller.
2. Over 80-90 %: Risiko for kraftigt kvalitetstab; kræver ofte kombination med distillation.
3. Layer-wise vs. global: Global threshold dræner typisk embeddings og output-projektion for hårdt; prøv per-layer budgetter.

4. Retræning (prune-finetune-cycle)

Efter hver pruning-runde er en kort finetuning afgørende:

• Learning-rate rewind: Start retræningen fra en tidligere LR-værdi (Lottery Ticket-inspireret) for stabilitet.
• Regularisering: Kombinér med L₁ eller variational dropout for at tilskynde yderligere sparsitet.
• Early stopping: Overtræn ikke - sparsificerede modeller overfitter hurtigere.

5. Hvornår giver ustruktureret sparsitet mening?

• Inference på CPU: Libraries som mkl_sparse_gemm eller ONNX Runtime’s SparseGEMM kan give 2-4× speed-up ved ≥70 % sparsity.
• GPU med Ampere (NVIDIA A100, RTX 30xx): Sparse TensorCores kræver dog 2:4-mønstre (semi-struktureret), ikke helt vilkårlig pruning.
• Forskning og model-zoo’er: Ønsker man blot en mindre checkpoint-fil (storage saving) uden krav om latency-gevinster.
• Edge-FPGA/ASIC: Mange laver on-chip kompression, hvor enhver nul-vægt sparer silikone.

6. Praktiske tips & faldgruber

1. Sæt et random-seed - magnitudebaseret pruning kan blive ikke-deterministisk, hvis to vægte har identisk størrelse.
2. EKS-metadata - gem en mask (0/1-tensor) sammen med vægtene; det gør det let at vende tilbage til tæt form.
3. Benchmark rigtigt: Mål wall-clock-tid, ikke FLOPs; sparse kernel-launch på GPU kan være memory-bound.
4. Check gradient-flow: Høj sparsity kan skabe “dead paths”; overvåg gradientnormer per lag.

Ustruktureret vægt-pruning er stadig en af de enkleste veje til mere kompakte Transformere, men det fulde potentiale udnyttes kun, når både software, hardware og trænings-strategi spiller sammen. Overvej derfor altid, om dine deployment-mål er lagerplads, energiforbrug eller ren latenstid - og tilpas prune-strategien derefter.

Når man arbejder med sparsitet i neurale netværk, er den strukturerede variant særligt interessant for Transformer-arkitekturer, fordi den tilgodeser hardware-reelle matricemultiplikationer. I stedet for at nulstille enkeltværdier tilfældigt (ustruktureret pruning) fjerner man hele underkomponenter, som GPU-kerneler kan springe over i én samlet blok.

Typer af struktureret sparsitet i transformer-lag

1. Head-pruning
   Hvert attentionslag består af h parallelle hoveder. Ved at analysere hovedernes bidrag (f.eks. via entropi, gradientnorm eller lærte skaleringsparametre) kan man:
   • Fjerne hoveder med lav effekt - ofte 20-40 % uden nævneværdigt tab af kvalitet.
   • Batchnormere dimensionaliteten, da d_model = h · d_k. Færre hoveder = færre matrixmultiplikationer.
2. Channel- eller filter-pruning
   De fuldt tilsluttede feed-forward-lag (FFN) i Transformers har typisk 4× udvidelse (d_ff = 4 · d_model). Ved at nulstille hele rækker/kolonner i de to lineære projektioner kan man reducere både vægte og aktiveringer. I praksis:
   1. Udregn L1-norm pr. kanal.
   2. Sortér og fjern de laveste.
   3. Tilpas modstående dimensioner, så matrixstørrelser passer.
3. Blok-pruning
   I stedet for enkelte elementer fjernes blokke på fx 8 × 8 eller 16 × 16 inden for vægtmatricer. Det giver:
   • Mærkbar kompression (op til 10×) med begrænset retrænings-overhead.
   • Ens blokstørrelse, som kernels som CUTLASS, Triton eller OneDNN direkte understøtter.
4. N:M-sparsitet (fx 2:4, 4:8)
   Her kræver man, at præcis N ud af hver M på hinanden følgende weights er non-nul. Eksempel: 2:4 betyder, at 50 % er nul, men i hver 4-gruppe ligger to tal tilbage. Fordele:
   • Garanteret sammenhængende mønster → specialiserede TensorCore-instruktioner kan udnytte det (Ampere, Hopper).
   • Ingen yderligere indlejring af maskinvarelogik; sparsitet håndteres i compiler.
   Ulemper: Fleksibiliteten er lav; man kan ikke frit vælge, hvilke vægte i gruppen der overlever uden at bryde N:M-kravet.

Sammenligning: Struktureret vs. Ustruktureret

Hardware-perspektiv

• NVIDIA GPU: Ampere A100 leverer op til 2× gennemsnitlig speedup ved 2:4 sparsitet gennem SparseTensorCore. Hopper H100 udvider til dynamisk N:M-skemaer.
• AMD ROCm: ROCm 5 har eksperimentel blok-sparse GEMM (MIOpen). N:M ikke officielt supporteret endnu.
• Google TPU v4: Indbygget SparseCore giver acceleration for ustruktureret sparsitet, men fordrer CSR-lagring og 1-step look-ups.
• Specialiserede ASICs (Cerebras, Tenstorrent): Har native blok-sparse datapaths, ofte fleksible på blokstørrelse.

Bedste praksis i udviklings-workflow

1. Start tæt ↠ struktureret: Træn en tæt model fuldt ud; anvend dernæst struktureret pruning for minimalt kvalitetsfald.
2. Iterér og retræn: Fjern 10-20 % af hoveder/kanaler per cyklus, efterfulgt af 1-3 epoch finetuning.
3. Profilér realistisk: Brug nsys/nvprof eller PyTorch Profiler med CUDA Graph Capture slået til, så latencymål er stabile.
4. Gem masken: Læg pruning-masken ind som en del af model-konfigurationen (JSON/YAML) for reproducérbarhed og deployment.
5. Fallback-stier: Design model-koden, så den automatisk kan falde tilbage til tæt udførelse, hvis sparsitet ikke understøttes på mål-GPU’en.

Hvornår giver struktureret sparsitet mest mening?

Korte svar: Når du kører online inferens, hvor latency er vigtigere end maksimal kompressionsratio, og når din infrastruktur kører på hardware, der eksplicit understøtter blok- eller N:M-mønstre. Til ekstremt begrænsede edge-enheder uden special-kerneler kan ustruktureret varianten stadig være nødvendig, men gevinsten i wall-clock tid vil sjældent matche de flotte tal på papiret.

Transformere er notorisk kvadratiske i både tid og hukommelse: et lag med fuld self-attention kræver O(n²) operationer for en sekvenslængde n. Ved lange sekvenser - kode, DNA, log-events eller dokumenter på flere tusinde tokens - bliver denne kompleksitet hurtigt uholdbar. Sparse attention bryder det fulde alle-mod-alle-mønster op og lader kun et delmængde af positioner interagere. Resultatet er ofte O(n·k) eller endda O(n) kompleksitet, hvor k er et lille konstant antal naboer eller blokke.

1. Oversigt over populære sparsity-mønstre

2. Hvornår vælger man hvad?

1. Kontekstens dominans: Har domænet stærk lokal struktur (lyd, kodeblokke)? Vælg lokal eller blok.
2. Behov for global aggregering: Vil vi opsamle et globalt resume (CLS) til klassifikation? Tilføj globale tokens eller zweepattern (BigBird).
3. Repetitivt eller hierarkisk indhold: Dilated/strided mønstre capturerer relationer på flere tids-/positionsskalaer.
4. Semantisk forskellighed: Hvis tokens bør grupperes efter meningsindhold snarere end position → lærte/hashed sparsity.
5. Hardware & batch-størrelse: N/M-blokerede kernels (NVIDIA, TPU) favoriserer blok-baseret sparsity frem for uregelmæssige mønstre.

3. Kvalitetskompromiser

• Context leakage: Lokal sparsity kan give blind spots, især for relationer der krydser window-grænsen.
  Mitigation: overlappende vinduer eller periodisk global attention.
• Gradient flow: Begrænset kontakt i de tidlige lag kan give svag bagudpropagering over lange distancer.
  Mitigation: fuld attention i de sidste lag, eller "Dilated then dense" strategi.
• Parameter-valg ømtåleligt: Window-bredde w, blokstørrelse B og antal globale tokens g skal tunes; for små værdier dropper accuracy, for store mister vi gevinsten.
• Overhead i implementering: Ustrukturerede mønstre kan give kernels med lav udnyttelse - speedup i teori, ikke i praksis.

4. Praktiske implementeringshensyn

1. Effektive kernels: Brug biblioteker som xformers, flash-attn-2, triton eller tfxla, der supporterer blok- og tri-diag masks uden eksplosiv mask-hukommelse.
2. Tids- og hukommelses-profilering: Mål reelle GPU-cycle-time. Sparse attention kan flop-reducere men blive båndbredde-bundet.
3. Mask-generering: Skab masker på GPU for at undgå CPU-overhead, og cache dem ved inference.
4. Mixed patterns: Mange state-of-the-art lange-sekvens-modeller kører:
     • Lag 1-L/2: lokal eller blok
     • Lag L/2-L: global eller fuld
     • Sidste lag: fuld attention for output-følsomhed.
5. Checkpoint-ing & gradient accumulation: Når O(n) hukommelse stadig er stor (fx n=64k), kombiner med activation checkpointing og gradient accumulation for at passe i VRAM.
6. Inferens-mode: Ved autoregressiv generering er kun kvadratiske relationer med tidligere tokens relevante pr. step. Sparse blocks skal derfor håndtere rullende vinduer.

5. Opsummering

Sparse attention er et nøgleværktøj til at bringe transformere fra hundrede til titusinde tokens uden lineær eskalering af compute. Valget af mønster afhænger af datadomæne, kvalitetskrav og hardware. Når det kombineres med trænings-tricks som gradient checkpointing og kernel-optimerede biblioteker, kan man hente reelle 2-10× speedups - ofte med <1% drop i nøjagtighed.

Mixture-of-Experts (MoE) udvider Transformer-arkitekturen med et betinget beregningslag: i stedet for én fælles feed-forward-blok (FFN) findes der m parallelle eksperter, men kun k (typisk 1-2) aktiveres pr. token. Dermed opstår beregnings- og aktiveringssparsitet, som muliggør enorm modelkapacitet uden at gøre FLOP-forbruget per token tilsvarende større.

1. Grundlæggende moe-flow

1. Gatingnetværk (ofte et lille lineært lag) modtager token-repræsentationen ht og producerer scores gt ∈ ℝm.
2. Routing: De k eksperter med højest score vælges (top-k gating). Ved k=1 fås Switch Transformer; k=2 bruges i GShard.
3. Tokenen sendes kun til de valgte eksperter, som beregner deres FFN-output. Resultatet aggregeres (vægtet sum eller simpel summering) og sendes videre til næste lag.

Compute pr. token ≈ k/m af, hvad en tæt model med alle eksperter ville kræve, mens den samlede parametermængde stadig skalerer med m.

2. Routingmekanismer

3. Load balancing

Når få eksperter modtager størstedelen af tokenerne, mister vi både sparsitet og generalisering. Typiske løsninger:

• Auxiliary balancing-loss: f.eks. Lbalance = m·∑e fe·log(fe), hvor fe er andelen af tokens til ekspert e.
• Capacity factor: fast grænse C = ⌈α·T/m⌉ tokens pr. mikro-batch (>1 for headroom). Overflow tokens sendes til en backup-ekspert eller droppes med straight-through-gradients.
• Noisy gating: tilfældig perturbation af scores giver mere jævn fordeling under træning.

4. Stabil træning

1. Gradient-blanding: fordi eksperter trænes på forskellige token-subsets, kan batch-norm og layer-norm drille. Anbefaling: brug RMSNorm eller LayerNorm uden batch-statistik.
2. Expert dropout: slå enkelte eksperter fra under træning for at forhindre co-adaptation.
3. FP16/BF16 + ZeRO-3: kombineres ofte med parameter-sharding for at passe tusindvis af eksperter i GPU-hukommelsen.
4. Kommunikation: tokens til samme ekspert pakkes i contiguous buffers → én all_to_all overgang mellem noder (GSPMD).

5. Kapacitetsfordele vs. Compute

• Parametre: med 256 eksperter à 64M param giver MoE-laget 16,4B param, men kun ca. 64M·k bruges per token.
• Træningstid: wall-clock stiger moderat pga. routing-overhead (<~15 %), men stadig langt under hvad fuld dense model med samme param.mængde ville kræve.
• Inference: gated (deterministisk) routing → forudsigelig latency; memory-bandwidth kan blive flaskhals snarere end FLOPs.

6. Praktiske erfaringer

Hvornår giver MoE mening?

1. Stort datasæt; ellers overfits eksperterne.
2. Høj batch-size; nødvendig for at fylde alle eksperter og få stabile grads.
3. Distributed setup med høj interconnect-båndbredde (NVLink, InfiniBand) - ellers ædes sparsitet af kommunikationslatens.

Fallback-strategier i produktion:

• Freeze gatingnetværket efter træning for deterministisk routing.
• Komprimer hver ekspert med pruning eller kvantisering for at holde modelstørrelsen nede.
• Batch-routing på CPU og beregning på GPU kan reducere spildtid for korte sekvenser.

7. Sammenfatning

Mixture-of-Experts skaber sparsitet langs modeldimensionen. Ved at aktivere et lille udsnit af eksperter pr. token kan man:

• Øge parametermængden (kapacitet) dramatisk.
• Beholde næsten samme regnetid som en tæt model.
• Tilpasse compute-budgettet dynamisk via k og kapacitetsfaktorer.

Udfordringen ligger i routing, load-balancing og kommunikation; håndteres disse korrekt, er MoE en af de mest lovende veje til at skalere transformer-modeller yderligere uden eksploderende beregningsomkostninger.

Transformere er ikke blot tunge på vægte; de mellem-aktiveringer, deropstår i hver fremad- og bagud-passage, fylder også voldsomt i hukommelsen.Ved at gøre disse aktiveringer sparse kan man:

• folde større batch-størrelser ind på samme GPU-hukommelse,
• reducere hukommelses-båndbredde (færre bytes flyttes pr. lag),
• fjerne unødvendig multiply-accumulate-arbejde og sænke energi­forbruget.

Centrale teknikker til aktiveringssparsitet

1. Top-k gating
   Vælg de k største (typisk i absolutværdi) elementer i en vektor og nulstil resten.
   • Typisk anvendt i feed-forward-lag eller efter en ikke-linje (ReLU/GELU).
   • Sparsity rate styres direkte af k eller det relative k/n-forhold.
   • Kan implementeres med torch.topk efterfulgt af scatter/gather for at bevare gradientflow til de valgte elementer.
2. Thresholding
   I stedet for et fast antal beholdes alle elementer over et tærskel-τ.
   • Giver fleksibel sparsitet, men kan svinge kraftigt mellem batch-step, hvilket kan give uforudsigelige latency-kurver.
   • Tærsklen kan være global, pr. kanal eller adaptiv (f.eks. 95-percentil).
3. L1-regularisering
   Tilføj en λ‖h‖1-term på aktivering h i trænings-tabben for at tilskynde sparsitet uden hård nulstilling.
   • Fordelen er glatte gradienter; gradientdescent skubber værdier mod 0.
   • Ulempen er, at aktiveringer sjældent bliver præcis 0, så man skal kombinere den med pruning after training eller soft-threshold i inferens.
4. Variational dropout / Sparse Bayesian layers
   Behandler hver aktivering som en tilfældig variabel med learnable varians.
   • Aktiveringer med høj usikkerhed skaleres ned mod 0 over tid.
   • Fører ofte til mere stabil konvergens end deterministiske masks, men er dyrere i compute under træning.

Trade-offs og praktiske hensyn

Implementationsråd

• Mask caching: Gem den binære maske fra forward og genbrug den i backward for deterministisk gradient.
• Mixed-precision + sparsitet: FP16 aktiveringer + sparsity giver størst hukommelsesbesparelse, men kræver at underliggende bibliotek (cuSPARSELt, Triton eller XLA) understøtter 16-bit i sparse kernels.
• Gradual sparsity-schedule: Start tæt (0 % sparsity) og øg k-reduktionen lineært over de første N trænings-epoker; dette forhindrer katastrofalt tab af signal tidligt.
• Profilér realistiske workloads: GPUs kan ignorere sparsity < 50 %, så bevar færre end halvdelen af elementerne for at se reel speed-up.

Rigtigt kombineret kan aktiveringssparsitet skubbe transformer-både itræning og inferens et betydeligt stykke ned ad hukommelses- og energi-kurven- uden at betale den fulde nøjagtighedspris, så længe man holder styr påmask-stabilitet og hardware-understøttelse.

Dynamiske sparsitetsteknikker sigter efter at tilpasse beregningen til den enkelte input-eksempel snarere end at køre hele modellen uforandret hver gang. Resultatet er lavere latenstid og energiforbrug uden at man nødvendigvis må betale fuld pris i tab af kvalitet.

1. Token-pruning: Slip for de ubetydelige ord

I lange sekvenser er det sjældent, at alle tokens bidrager lige meget til slutresultatet. Token-pruning fjerner de mindst vigtige tokens efter et eller flere lag og fortsætter kun med de mest informative.

1. Beregn et betydningsscore - typisk som:
   • Gennemsnitlig attention-vægt (soft importance)
   • Gradientbaseret saliens
   • Rekonstruktionstab fra et mindre “skygge-netværk”
2. Sorter og behold enten top-k tokens (fixed budget) eller alle over en threshold.
3. Opdater maskering så selv-attention og feed-forward kun ser de resterende tokens.
4. Optionalt kompensation: indsæt et [summary]-token som samler info fra de prunede tokens for at undgå kvalitetsdrop.

Forskningen viser, at man i f.eks. tekstklassifikation ofte kan køre med 30-50 % færre tokens uden nævneværdigt tab i F1-score. Gevinsten bliver endnu større på mobil-GPU’er, hvor hukommelsesbåndbredden er flaskehalsen.

2. Early exiting: Stop, når du er sikker nok

I stedet for at køre alle lag til ende kan man sætte kontrolpunkter (typisk efter hvert 2.-3. lag) med en lille hoved eller softmax-klassefier:

• Under inferens beregnes confidence (f.eks. max probability, entropy eller margin).
• Er confidence > τ, returneres svaret med det samme.
• Ellers fortsættes til næste blok.

Teknikken er særlig effektiv til opgaver med stor varians i sværhedsgrad (fx customer-support chatbots). “Nem” Small-talk kan afsluttes tidligt, mens komplekse spørgsmål får fuld dybde.

For generative modeller (fx GPT-lignende) findes en tilsvarende adaptive computation time (ACT), hvor man efter hver blok måler, om hidden-state ændrer sig under en vis tolerance og stopper, når ændringen flader ud.

3. Adaptiv dybde vha. Routing-netværk

I stedet for faste checkpoints kan et lille policy network (ofte en to-lags MLP over CLS-embeddingen) bestemme:

• Hvilke lag der skal skippes
• Om en given token skal rutes til en lettere gren af modellen

Denne tilgang trænes typisk med Gumbel-Softmax eller REINFORCE-lignende metoder og tillader finere grained kontrol, men kræver mere kompleks træning.

4. Stabilitet og træningsstrategier

• Knowledge-distillation fra en fuld “lærer” sikrer, at de tidlige lag i en exit ikke ser for “nemme” targets.
• Entropy-regularisering gør confidence-scores mere kalibrerede og reducerer hyppige fejleksits.
• Injektér random erasure under træning for at gøre modellen robust mod token-pruning beslutninger.

5. Hvordan måler man gevinsterne?

Det er ikke nok at tælle FLOPs - målet er reel brugeroplevelse og driftsomkostning.

En god tommelfingerregel er at jagte >30 % latenstids-reduktion med højst 1 % absolut tab i kvalitet. Tilpas tærskler og budgetter dataset-specifikt, og hav altid en fallback til fuld model i mission-kritiske systemer.

Samlet set giver token- og lag-dynamik et fleksibelt værktøjssæt til at matche beregning med inputkompleksitet - en nøgle til både bæredygtig og omkostningseffektiv AI-drift.

Det er én ting at opnå sparsitet – en helt anden at gøre det uden at ødelægge modellens præcision eller produktionsklarhed. Nedenfor gennemgår vi de tre vigtigste ”quality-preserving” strategier samt, hvad du konkret bør måle på, og hvor det ofte går galt i drift.

1. Vidensdestillation: Læreren holder eleven skarp

1. Opsætning
   En tæt (dense) lærer genererer bløde mål (soft-targets). Den sparsificerede elev trænes til at efterligne både ground-truth labels og lærerens output.
2. Typer af destillation
   • Logit-matching – klassisk KL-divergens mod teacher logits.
   • Feature-matching – L2-tab på mellemlag for at bevare repræsentationer.
   • Attention-transfer – ekstra tab på attention-værdier gør underværker i Transformers.
3. Praktiske tips
   • Hold lærerens vægte frosset og præ-computér logits i batches for at spare GPU-tid.
   • Brug T ≈ 2-4 (temperatur) for sprogmodeller; højere temperatur fremhæver small-magnitude klasser.
   • Tun balancen: Loss = α·CE_gt + β·KD_loss – start fx med α=0.2, β=0.8.

2. Gradual & iterative prune-retrain-sløjfer

Den mest populære pipeline er inspireret af Lottery Ticket Hypothesis. Proceduren:

1. Træn fuld model til konvergens.
2. Prun fx 20 % af de mindste vægte pr. iteration (magnitudebaseret).
3. Frys masken, retræn til oprindelig tabsfunktion er (næsten) genskabt.
4. Gentag trin 2-3, til ønsket sparsity-rate S er nået.
5. Optionalt “rewind” vægtene til tidligt trænings-checkpoint for hurtigere konvergens.

Hyperparameter-regler:

• Prunings-rate pr. runde: 10-30 % giver stabile resultater.
• Retrænings-epoker: 30-50 % af den oprindelige træningslængde.
• Stop, hvis validerings-tab stiger >2-3 % og ikke kan genvindes efter to runder.

Hvorfor iterativt?

Ét aggressivt cut på fx 90 % sparsitet dræber typisk 5-8  BLEU- eller perplexity-point. Gradual pruning taber <1  point, fordi modellen får chance for at reallokere betydning til de overlevende vægte.

3. Sparsitet plus kvantisering = dobbelt gevinst

Kombinér altid sparsitet med 8-bit ( eller 4-bit ) kvantisering efter retræning:

1. Afslut prune-retrain indtil accuracy ≈ baseline.
2. Kør Post-Training Quantization (PTQ) med calibration-dataset (et par tusind batch).
3. Hvis kvalitetsfald >1-2 %, vælg Quantization-Aware Training (QAT) de sidste 3-5 epoker.
4. Sørg for at vælge en hardware-venlig sparsity-mask (N:M) før kvantiseringen, da bit-packing ellers misaligner.

4. Hvad skal du måle på?

^* Reelle tal afhænger af kernel-support & batch-size.

5. Typiske faldgruber i produktion

• Manglende kernel-support: Ustruktureret masks er ofte kun hurtige i forsknings-frameworks; på mange GPUer falder de tilbage til dense-matematik.
• Fragmenteret hukommelse: Iterativ pruning skaber mask-strukturer der ikke er cache-venlige. Overvej N:M-pruning eller block-sparsity.
• Batch-size afhængighed: Sparsitet giver mest mening ved small/latency-kritiske batches; i throughput-scenarier kan dense-kernel stadig vinde.
• Distribution-skævheder: Destillation kan forstærke lærerens bias – valider på fairness-sæt!
• Dev-Prod mismatch: Sørg for samme ONNX/TensorRT-version og aktiver --sparse-flag i deployment; ellers loader du en tynd model men kører stadig dense compute.

Når du kombinerer disse teknikker metodisk, kan du høste markante gevinster i både latency, strømforbrug og modelstørrelse – uden at gå på kompromis med brugeroplevelsen.