GPU-Omkostninger: Spar 90% Guide (2026)

GPU-regningen eksploderer — og det er AI's skyld

Der er sket noget fundamentalt med cloud-budgetterne i 2026. De klassiske besparelsesstrategier — right-sizing af VM'er, slukning af ubrugte ressourcer, spot instances til batch-jobs — virker stadig. Men en helt ny udgiftspost har overtaget førstepladsen: AI og GPU-compute.

Og tallene er ret vilde.

Ifølge FinOps Foundations State of FinOps 2026-rapport administrerer 98% af alle FinOps-teams nu AI-relaterede udgifter — op fra kun 31% to år tidligere. En enkelt NVIDIA H100 GPU koster op til 40.000 dollars i indkøb, og timeprisen i skyen løber fra 3 til næsten 7 dollars per GPU. Det er 10-20 gange dyrere end standard CPU-baseret compute. Bare lige så vi har forventningerne på plads.

Det værste? De fleste teams aner reelt ikke, hvor meget de spilder. Studier viser, at 30-50% af GPU-budgettet typisk går til instanser, der er provisioneret men ikke aktivt træner. Dertil kommer skjulte omkostninger som storage, data-egress og netværk, der ofte udgør 60-80% af den samlede AI-regning. Helt ærligt, det er penge ud af vinduet.

Denne guide giver dig en komplet strategi til at tæmme GPU-omkostningerne på tværs af AWS, Azure og GCP — med aktuelle priser fra 2026, praktiske kodeeksempler og Terraform-konfigurationer, du kan bruge med det samme.

GPU-priser i 2026: AWS vs. Azure vs. GCP

Før du kan optimere noget som helst, skal du forstå prislandskabet. Her er en sammenligning af de mest populære GPU-instanser til AI-workloads i 2026:

Udbyder / Instans	GPU	Antal GPU'er	On-Demand ($/time)	Spot ($/time)	Besparelse (spot)
AWS p5.48xlarge	NVIDIA H100 80GB	8	~$44,50	~$13-18	60-70%
AWS g5.xlarge	NVIDIA A10G 24GB	1	~$1,01	~$0,30-0,50	50-70%
Azure ND96isr H100 v5	NVIDIA H100 80GB	8	~$98,32	~$18-75	24-82%
Azure NC40ads H100 v5	NVIDIA H100 80GB	1	~$6,98/GPU	Varierer	20-60%
GCP a3-highgpu-8g	NVIDIA H100 80GB	8	~$24,00	~$18,00	~25%
GCP g2-standard-4	NVIDIA L4	1	~$0,84	~$0,25	~70%

Et par ting springer i øjnene her. For det første: GCP er generelt billigst per GPU-time for H100, med en on-demand-pris på omkring $3,00 per GPU. AWS tilbyder de mest aggressive spot-rabatter, mens Azure — ja, Azure er den dyreste for on-demand H100-instanser. Sådan er det bare.

For det andet: priserne ændrer sig hele tiden. AWS sænkede P5-priserne med op til 45% i midten af 2025, men hævede dem igen med 15% i starten af 2026. Moralen? Automatisér din prisovervågning frem for at stole på point-in-time sammenligninger.

Strategi 1: Vælg den rigtige GPU til din workload

Den nemmeste besparelse — og den mest oversete — er at matche GPU-typen til den faktiske workload. Alt for mange teams defaulter til den kraftigste GPU de kan finde, selv til opgaver der slet ikke kræver det. Det svarer lidt til at leje en lastbil for at hente en pose mælk.

Her er en praktisk beslutningsguide:

Workload-type	Anbefalet GPU	Pris (on-demand)	Hvorfor
LLM-træning (>70B parametre)	H100 / H200	$3-7/GPU/time	Kræver HBM3-hukommelse og NVLink til multi-GPU
LLM-træning (7-70B parametre)	A100 / H100	$1,50-3/GPU/time	A100 er stadig priseffektiv til mellemstore modeller
Fine-tuning og LoRA	A10G / L4	$0,50-1/GPU/time	Tilstrækkeligt VRAM (24GB) til de fleste fine-tuning-jobs
Inference (<7B parametre)	L4 / T4	$0,25-0,84/GPU/time	Optimeret til inference med lavt strømforbrug
Inference (>13B parametre)	A10G / A100	$1-2/GPU/time	Kræver mere VRAM for store modeller
Udvikling og eksperimenter	T4 / L4	$0,25-0,50/GPU/time	Billigst muligt — brug premium GPU'er til produktion

Tommelfingerreglen: for modeller under 7 milliarder parametre kan en L4 til $0,50-0,70/time ofte overgå en H100 til $3+/time målt på cost-per-token. Samme beregning, bare 5-6 gange billigere. Det er svært at argumentere imod.

Terraform-eksempel: Adskil træning og inference

En af de mest effektive strategier er at bruge forskellige instanstyper til træning og inference. Her er et Terraform-eksempel der opretter separate node pools i GKE:

# gke-gpu-node-pools.tf

# Node pool til AI-træning (H100 GPU'er)
resource "google_container_node_pool" "training_pool" {
  name       = "gpu-training-pool"
  cluster    = google_container_cluster.main.name
  location   = var.region

  autoscaling {
    min_node_count = 0    # Skaler ned til 0 når der ikke trænes
    max_node_count = 4
  }

  node_config {
    machine_type = "a3-highgpu-8g"   # 8x H100
    spot         = true               # Brug spot for træning

    guest_accelerator {
      type  = "nvidia-h100-80gb"
      count = 8
    }

    labels = {
      "workload-type" = "training"
      "gpu-type"      = "h100"
    }

    taint {
      key    = "nvidia.com/gpu"
      value  = "present"
      effect = "NO_SCHEDULE"
    }
  }
}

# Node pool til inference (L4 GPU'er — langt billigere)
resource "google_container_node_pool" "inference_pool" {
  name       = "gpu-inference-pool"
  cluster    = google_container_cluster.main.name
  location   = var.region

  autoscaling {
    min_node_count = 1
    max_node_count = 10
  }

  node_config {
    machine_type = "g2-standard-4"   # 1x L4
    spot         = false              # On-demand for stabil inference

    guest_accelerator {
      type  = "nvidia-l4"
      count = 1
    }

    labels = {
      "workload-type" = "inference"
      "gpu-type"      = "l4"
    }

    taint {
      key    = "nvidia.com/gpu"
      value  = "present"
      effect = "NO_SCHEDULE"
    }
  }
}

Bemærk den afgørende forskel: trænings-poolen bruger spot instances og kan skalere ned til 0 noder, mens inference-poolen kører on-demand for stabil tilgængelighed. Den opdeling alene kan halvere dine GPU-udgifter.

Strategi 2: Spot instances til AI-træning med checkpointing

Spot instances er ganske enkelt den mest effektive enkeltbesparelse for AI-træning. Med rabatter på 50-90% sammenlignet med on-demand kan du træne den samme model til en brøkdel af prisen.

Men — og det er et vigtigt men — du skal arkitektere din træning til at håndtere afbrydelser.

Nøglen er aggressiv checkpointing: gem modellens tilstand regelmæssigt, så du kan genoptage fra det seneste checkpoint efter en spot-afbrydelse. Det lyder måske besværligt, men det er faktisk ret ligetil.

PyTorch-eksempel: Automatisk checkpointing med spot-håndtering

# spot_training.py — PyTorch træning med spot-interruption handling
import torch
import signal
import sys
import os
from pathlib import Path

CHECKPOINT_DIR = "/mnt/shared-storage/checkpoints"
CHECKPOINT_INTERVAL = 500  # Gem hvert 500. step

class SpotAwareTrainer:
    def __init__(self, model, optimizer, checkpoint_dir=CHECKPOINT_DIR):
        self.model = model
        self.optimizer = optimizer
        self.checkpoint_dir = Path(checkpoint_dir)
        self.checkpoint_dir.mkdir(parents=True, exist_ok=True)
        self.global_step = 0
        self.interrupted = False

        # Registrer signal handlers til spot-interruption
        signal.signal(signal.SIGTERM, self._handle_interruption)
        signal.signal(signal.SIGINT, self._handle_interruption)

    def _handle_interruption(self, signum, frame):
        print(f"Spot-interruption modtaget (signal {signum}). Gemmer checkpoint...")
        self.save_checkpoint(emergency=True)
        self.interrupted = True

    def save_checkpoint(self, emergency=False):
        prefix = "emergency" if emergency else "step"
        path = self.checkpoint_dir / f"{prefix}_{self.global_step}.pt"
        torch.save({
            "model_state_dict": self.model.state_dict(),
            "optimizer_state_dict": self.optimizer.state_dict(),
            "global_step": self.global_step,
        }, path)
        print(f"Checkpoint gemt: {path}")

        # Behold kun de 3 nyeste checkpoints (spar storage)
        checkpoints = sorted(self.checkpoint_dir.glob("step_*.pt"))
        for old_ckpt in checkpoints[:-3]:
            old_ckpt.unlink()

    def load_latest_checkpoint(self):
        checkpoints = sorted(
            self.checkpoint_dir.glob("*.pt"),
            key=os.path.getmtime
        )
        if not checkpoints:
            print("Ingen eksisterende checkpoints fundet. Starter fra scratch.")
            return

        latest = checkpoints[-1]
        checkpoint = torch.load(latest, weights_only=True)
        self.model.load_state_dict(checkpoint["model_state_dict"])
        self.optimizer.load_state_dict(checkpoint["optimizer_state_dict"])
        self.global_step = checkpoint["global_step"]
        print(f"Genoptager træning fra step {self.global_step} ({latest})")

    def train(self, dataloader, epochs, loss_fn):
        self.load_latest_checkpoint()

        for epoch in range(epochs):
            for batch in dataloader:
                if self.interrupted:
                    print("Træning stoppet pga. spot-interruption.")
                    sys.exit(0)

                loss = self._train_step(batch, loss_fn)
                self.global_step += 1

                if self.global_step % CHECKPOINT_INTERVAL == 0:
                    self.save_checkpoint()
                    print(f"Step {self.global_step}, Loss: {loss:.4f}")

    def _train_step(self, batch, loss_fn):
        self.optimizer.zero_grad()
        inputs, targets = batch
        outputs = self.model(inputs)
        loss = loss_fn(outputs, targets)
        loss.backward()
        self.optimizer.step()
        return loss.item()

Klassen her fanger SIGTERM-signalet (som cloud-udbyderne sender ved spot-eviction) og gemmer automatisk et emergency checkpoint. Næste gang træningen starter, genoptager den fra det seneste checkpoint. Ingen tabt arbejde. Og det kræver kun et par ekstra linjer kode i din eksisterende træningsløkke.

Strategi 3: GPU-overvågning med DCGM, Prometheus og Grafana

Du kan ikke optimere det, du ikke måler. Og GPU-udnyttelse er — lad os være ærlige — notorisk svær at overvåge uden de rette værktøjer.

Den gode nyhed er, at der i 2026 findes en velafprøvet open source-stack:

NVIDIA DCGM Exporter — eksponerer GPU-metrikker (udnyttelse, hukommelse, temperatur, strøm) som Prometheus endpoints
Prometheus — samler og opbevarer metrikker
Grafana — visualiserer data i dashboards
KEDA / HPA — autoscaler baseret på GPU-metrikker

Lad os se på, hvordan du sætter det op.

Opsætning: DCGM Exporter i Kubernetes

Den hurtigste vej er via Helm:

# Installér DCGM Exporter via Helm
helm repo add gpu-helm-charts \
  https://nvidia.github.io/dcgm-exporter/helm-charts
helm repo update

helm install dcgm-exporter gpu-helm-charts/dcgm-exporter \
  --namespace monitoring \
  --create-namespace \
  --set serviceMonitor.enabled=true \
  --set serviceMonitor.interval=15s

Herefter opretter du en ServiceMonitor, så Prometheus automatisk scraper GPU-metrikkerne:

# gpu-service-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: dcgm-exporter
  namespace: monitoring
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: dcgm-exporter
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

De vigtigste GPU-metrikker at overvåge

Metrik	Beskrivelse	Mål
`DCGM_FI_DEV_GPU_UTIL`	GPU-udnyttelse i procent	>80% under aktiv træning
`DCGM_FI_DEV_FB_USED`	Brugt GPU-hukommelse (bytes)	Bør matche model-størrelsen
`DCGM_FI_DEV_FB_FREE`	Ledig GPU-hukommelse	Undgå massive ubrugte buffere
`DCGM_FI_PROF_SM_OCCUPANCY`	Streaming Multiprocessor-udnyttelse	>60% for effektiv compute
`DCGM_FI_DEV_POWER_USAGE`	Strømforbrug (watt)	Indikerer reel belastning

Tommelfingerregel: Hvis din gennemsnitlige GPU-udnyttelse ligger under 50%, betaler du for mindst det dobbelte af, hvad du har brug for. Teams der implementerer DCGM-overvågning rapporterer typisk en 40% reduktion i GPU-idle-tid og en 30% stigning i job-throughput. Det er ikke småpenge.

Prometheus-alarm for lav GPU-udnyttelse

Opsæt en alarm der advarer, når GPU'er sidder og laver ingenting i mere end 30 minutter:

# gpu-alerts.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: gpu-cost-alerts
  namespace: monitoring
spec:
  groups:
    - name: gpu-waste-detection
      rules:
        - alert: GPUUnderutilized
          expr: |
            avg_over_time(DCGM_FI_DEV_GPU_UTIL[30m]) < 20
            and on(pod) kube_pod_info{namespace=~"ml-.*|ai-.*"}
          for: 30m
          labels:
            severity: warning
            team: finops
          annotations:
            summary: "GPU underudnyttet i {{ $labels.namespace }}/{{ $labels.pod }}"
            description: |
              GPU-udnyttelsen har været under 20% i over 30 minutter.
              Aktuel udnyttelse: {{ $value | printf "%.1f" }}%.
              Overvej at nedskalere GPU-typen eller frigøre ressourcen.
            cost_impact: "Potentiel besparelse: ~$2-7/time per GPU"

        - alert: GPUIdle
          expr: |
            DCGM_FI_DEV_GPU_UTIL == 0
            and on(pod) kube_pod_info{namespace=~"ml-.*|ai-.*"}
          for: 15m
          labels:
            severity: critical
            team: finops
          annotations:
            summary: "GPU helt ubrugt i {{ $labels.namespace }}/{{ $labels.pod }}"
            description: |
              GPU har været 0% udnyttet i 15 minutter.
              Denne ressource bør frigøres øjeblikkeligt.

Strategi 4: Autoscaling af GPU-workloads med KEDA

Statisk allokering af GPU-ressourcer er en af de dyreste fejl teams begår. Jeg har set det utallige gange — et team provisionerer 8 GPU'er til en inference-service, fordi de havde brug for det under et peak-load en enkelt gang. Resten af tiden kører GPU'erne på 15% udnyttelse.

Med KEDA (Kubernetes Event-Driven Autoscaling) kan du skalere GPU-workloads dynamisk baseret på faktisk efterspørgsel:

# keda-gpu-scaler.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: inference-gpu-scaler
  namespace: ml-inference
spec:
  scaleTargetRef:
    name: inference-deployment
  minReplicaCount: 1
  maxReplicaCount: 10
  pollingInterval: 15
  cooldownPeriod: 300     # 5 minutters cooldown før nedskalering

  triggers:
    # Skaler baseret på GPU-udnyttelse
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        metricName: gpu_utilization
        query: |
          avg(DCGM_FI_DEV_GPU_UTIL{namespace="ml-inference"})
        threshold: "75"
        activationThreshold: "50"

    # Skaler også baseret på kø-længde
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        metricName: inference_queue_length
        query: |
          sum(inference_requests_pending{namespace="ml-inference"})
        threshold: "100"

Konfigurationen skalerer inference-pods op, når GPU-udnyttelsen overstiger 75% eller der er mere end 100 ventende requests i køen. Cooldown-perioden på 5 minutter forhindrer unødvendig "flapping" (det konstante hop mellem skalering op og ned, som bare æder ressourcer).

Strategi 5: Commitment-rabatter for forudsigelige GPU-workloads

Hvis du har inference-workloads der kører 24/7, eller planlagte træningsjobs med et nogenlunde forudsigeligt mønster, bør du helt klart udnytte commitment-baserede rabatter:

Udbyder	Commitment-type	Rabat	Bedst til
AWS	EC2 Savings Plans	Op til 72%	GPU-instanser du kører konstant
AWS	Capacity Blocks for ML	Varierer	Planlagte træningsjobs med reserveret kapacitet
Azure	Reserved Instances (1-3 år)	Op til 50%	Stabile inference-workloads
Azure	Savings Plans for Compute	Op til 65%	Varierende GPU-behov på tværs af VM-familier
GCP	Committed Use Discounts	Op til 70%	Langsigtet GPU-forbrug med forudsigeligt mønster
GCP	Sustained Use Discounts	Op til 20%	Automatisk rabat ved vedvarende brug (ingen commitment)

Den anbefalede lagdelte strategi: Dæk 60-70% af dit minimum GPU-forbrug med Savings Plans eller CUD'er. Brug spot instances til burst-træning. Behold 20-30% som on-demand for fleksibilitet. Det giver den bedste balance mellem besparelse og risiko — og det er den tilgang, de fleste modne FinOps-teams ender med at lande på.

Strategi 6: Automatisk shutdown og intelligent scheduling

En overraskende stor del af GPU-spildet stammer fra noget så banalt som ressourcer, der glemmes i kørende tilstand. Jupyter notebooks med GPU-acceleration som ingen har rørt i tre dage. Udviklings-endpoints der kører 24/7 selvom teamet kun arbejder 8 timer om dagen. Færdiggjorte træningsjobs der aldrig bliver lukket ned.

Vi har alle prøvet det. Det gør det ikke billigere.

Kubernetes CronJob til automatisk oprydning

# gpu-cleanup-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: gpu-idle-cleanup
  namespace: ml-platform
spec:
  schedule: "*/30 * * * *"   # Kør hvert 30. minut
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: gpu-cleanup-sa
          containers:
            - name: cleanup
              image: bitnami/kubectl:latest
              command:
                - /bin/bash
                - -c
                - |
                  echo "Scanner for idle GPU-pods..."
                  kubectl get pods -n ml-dev \
                    -l gpu-type \
                    --field-selector=status.phase=Running \
                    -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}' | \
                  while IFS=$'\t' read -r pod start_time; do
                    if [ -n "$pod" ]; then
                      echo "Markerer $pod til review (kørt siden $start_time)"
                      kubectl label pod "$pod" -n ml-dev \
                        finops/idle-review=true --overwrite
                    fi
                  done
                  echo "Oprydning færdig."
          restartPolicy: OnFailure

Denne CronJob scanner hvert 30. minut efter GPU-pods i udviklings-namespacet og markerer dem til review. Du kan udvide logikken til at sende Slack-notifikationer eller automatisk slette pods baseret på GPU-udnyttelsesmetrikker fra Prometheus. Start simpelt og byg videre derfra.

Strategi 7: Mixed-precision training og model-optimering

Ikke al besparelse handler om infrastruktur. Du kan også reducere GPU-forbruget markant ved at optimere selve træningsprocessen. Det her er den del, hvor softwarefolkene virkelig kan skinne:

Mixed-precision training (FP16/BF16): Reducerer hukommelsesforbruget med ~50% og øger training throughput med 30-60% på moderne GPU'er. Alle H100, A100 og L4 GPU'er har hardware-accelereret FP16/BF16-support
Gradient accumulation: Simulér større batch sizes uden at kræve mere GPU-hukommelse — lader dig bruge billigere GPU'er til jobs, der ellers ville kræve premium-hardware
LoRA og QLoRA: Fine-tuning med Low-Rank Adaptation reducerer de trænbare parametre med op til 99%, hvilket drastisk sænker GPU-kravet. Et 70B-parameter model kan fine-tunes på en enkelt A10G i stedet for 4x H100. Det er en ganske markant forskel i pris
Model quantization til inference: Kør inference med INT8 eller INT4 quantization for at halvere (eller kvarte) hukommelsesforbruget — og dermed kunne bruge billigere GPU'er

Eksempel: Mixed-precision training med PyTorch

# mixed_precision_training.py
import torch
from torch.amp import autocast, GradScaler

# Aktivér mixed-precision training med BFloat16
scaler = GradScaler()

for batch in dataloader:
    optimizer.zero_grad()

    # Forward pass i BF16 — halverer hukommelsesforbrug
    with autocast(device_type="cuda", dtype=torch.bfloat16):
        outputs = model(batch["input_ids"])
        loss = loss_fn(outputs, batch["labels"])

    # Backward pass med gradient scaling
    scaler.scale(loss).backward()
    scaler.step(optimizer)
    scaler.update()

De tre linjer kode (autocast, scaler.scale, scaler.step) kan reducere dit GPU-hukommelsesforbrug med op til 50%. Ofte er det nok til at droppe ned til en billigere GPU-type. Få ændringer giver så meget værdi per linje kode.

Opsummering: Den lagdelte GPU-besparelsesstrategi

Så, lad os samle trådene. Her er den samlede strategi, prioriteret efter effekt:

Vælg den rigtige GPU — Match GPU-type til workload. Brug ikke H100 til inference af 7B-modeller (besparelse: 60-80%)
Brug spot instances til træning — Med checkpointing kan du spare 50-90% på trænings-compute
Implementér GPU-overvågning — DCGM + Prometheus afslører skjult spild og muliggør datadrevet optimering (besparelse: 30-40%)
Autoscaler GPU-workloads — KEDA/HPA baseret på faktisk GPU-udnyttelse forhindrer over-provisioning
Commitment-rabatter — Savings Plans/CUD'er for forudsigelige workloads (besparelse: 20-72%)
Automatisk shutdown — Stop med at betale for glemte notebooks og idle dev-miljøer
Model-optimering — Mixed-precision, LoRA og quantization reducerer GPU-kravet fra softwaresiden

Tilsammen kan disse strategier reducere din AI/GPU-regning med 60-90% — uden at gå på kompromis med model-kvaliteten. Start med de øverste punkter, de giver mest bang for the buck.

FAQ: Ofte stillede spørgsmål om GPU-omkostninger i skyen

Hvorfor er GPU-instanser så meget dyrere end CPU-instanser?

GPU'er som NVIDIA H100 koster op til $40.000 per chip, og en fuld server med 8 GPU'er kan koste over $400.000. Dertil kommer, at GPU-servere kræver markant mere strøm og køling end standard compute. Disse hardware- og driftsomkostninger afspejles direkte i timeprisen. Og så er der selvfølgelig den massive efterspørgsel fra AI-boomen, der presser priserne yderligere op.

Kan jeg bruge spot instances til AI-inference i produktion?

Det kan du godt, men det kræver omhyggelig arkitektur. Du skal have multiple replicas bag en load balancer, graceful draining af requests ved spot-interruption, og en fallback til on-demand instanser. For kritisk inference med strenge SLA'er er det typisk bedre at bruge on-demand eller reserved instances som baseline og supplere med spot til burst-kapacitet. Kort sagt: ja, men gør det rigtigt.

Hvilken cloud-udbyder er billigst til GPU-workloads i 2026?

GCP er generelt billigst for H100 on-demand (~$3/GPU/time) og tilbyder automatiske Sustained Use Discounts. AWS har de mest aggressive spot-priser og det bredeste udvalg af GPU-typer. Azure er typisk dyrest on-demand, men tilbyder stærke rabatter via Reserved Instances for langsigtede workloads. Det optimale valg afhænger af din workload-profil — og mange teams benytter faktisk en multi-cloud-strategi for at udnytte de bedste priser hos hver udbyder.

Hvor meget GPU-hukommelse har jeg brug for til mit AI-projekt?

Som tommelfingerregel kræver en model i FP16-format cirka 2 bytes per parameter. Et 7B-parameter model kræver altså ~14 GB VRAM til inference (passer fint i en enkelt L4/A10G med 24 GB). Til træning skal du typisk gange med 4-6x pga. gradienter, optimizer-tilstande og aktiveringsdata. Quantization (INT8/INT4) kan halvere eller kvarte kravet — og det er ofte vejen frem for inference.

Hvordan overvåger jeg GPU-udnyttelsen uden at påvirke ydeevnen?

NVIDIA DCGM Exporter bruger driver-level API'er — ikke polling — til at indsamle metrikker. Benchmarks viser, at overhead er under 0,1% selv under fuld belastning. Med Prometheus-scraping hvert 15. sekund er netværkstraffiken minimal (få KB per scrape). Det er med andre ord nærmest gratis synlighed — der er ingen god grund til ikke at have det kørende.