Znížte GPU náklady v cloude o 70 % (2026)

GPU v cloude: Prečo sú AI náklady najrýchlejšie rastúcou položkou v rozpočte

GPU workloady pre umelú inteligenciu sú v roku 2026 jednoducho najrýchlejšie rastúca kategória cloudových nákladov. Nie je to žiadna hyperbola — podľa aktuálnych údajov tvoria GPU-intenzívne AI workloady už 18 % celkových cloudových výdavkov v organizáciách, ktoré aktívne nasadzujú AI. To je nárast z iba 4 % v roku 2023. Gartner predpovedá, že do roku 2029 bude 50 % všetkých cloud compute zdrojov vyhradených pre AI workloady.

A tu nastáva ten skutočný problém. Tradičné FinOps postupy, čo fungovali pre bežné EC2 inštancie a kontajnery, jednoducho nestačia na riadenie AI nákladov. GPU zdroje sú rádovo drahšie než štandardný compute, tréningové joby sú burstové a nepredvídateľné, a tímy — veľmi často bez toho, aby si to uvedomovali — duplikujú datasety a vytvárajú paralelné pipeliny bez jasného prehľadu o tom, koľko to vlastne stojí.

V tomto sprievodcovi vám ukážem konkrétne stratégie, ako znížiť náklady na GPU a AI workloady o 40–70 % naprieč AWS, Azure aj GCP. Od výberu správneho typu inštancie, cez spot inštancie a alternatívne čipy, až po frakčné GPU zdieľanie v Kubernetes a optimalizáciu na úrovni modelov. Väčšinu z nich sme v praxi overili na reálnych produkčných workloadoch.

Porovnanie cien GPU inštancií: AWS vs. Azure vs. GCP v roku 2026

Prvý krok k optimalizácii je pochopiť, koľko vlastne platíte — a kde sú najväčšie rozdiely. Znie to banálne, ale bol by som prekvapený, koľko tímov tento krok preskočí. Cenník GPU inštancií sa v rokoch 2025–2026 dramaticky zmenil. AWS v júni 2025 znížil ceny P5 inštancií o až 45 %, P4d o 33 % a Google Cloud znížil ceny H100 z pôvodných ~11 USD na približne 3 USD za GPU/hodinu. Takže ak ste naposledy porovnávali ceny pred rokom, vaše čísla sú zastarané.

H100 GPU — on-demand ceny za GPU/hodinu (marec 2026)

Poskytovateľ	Inštancia	GPU	On-demand za GPU/hod	Spot za GPU/hod
AWS	p5.48xlarge	8× H100	~5,56 USD	~2,50 USD
GCP	a3-megagpu-8g	8× H100	~3,00 USD	~2,38 USD
Azure	ND96isr H100 v5	8× H100	~6,98 USD	~2,27 USD

Pár vecí, čo ma na tejto tabuľke zaujali:

GCP má momentálne najnižšie on-demand ceny za H100 — približne 3 USD za GPU/hodinu oproti takmer 7 USD na Azure. To je obrovský rozdiel
Spot ceny sú prekvapivo vyrovnané naprieč poskytovateľmi — pohybujú sa okolo 2,25–2,50 USD za GPU/hodinu (čo je zaujímavé, pretože on-demand ceny sa líšia dramaticky)
Azure je najdrahší na on-demand, ale jeho spot ceny sú plne konkurencieschopné
Pre inferenčné workloady zvážte lacnejšie G-sériu (G5/G6 s NVIDIA L4 a A10G) — tie stoja zlomok ceny H100 a pre inferenciu sú väčšinou viac než postačujúce

Inferenčné GPU — cenovo efektívne alternatívy

Inštancia	GPU	Použitie	Cena za hod (on-demand)
AWS g6.xlarge	1× NVIDIA L4	Inferencia, fine-tuning malých modelov	~0,80 USD
AWS g5.xlarge	1× NVIDIA A10G	Inferencia, stredné modely	~1,01 USD
GCP G2 (g2-standard-4)	1× NVIDIA L4	Inferencia, FP8 optimalizácia	~0,75 USD
AWS inf2.xlarge	1× Inferentia2	Produkčná inferencia NLP	~0,76 USD

Toto je vec, na ktorú stále narážam pri auditoch: nepoužívajte H100 na inferenciu, ak to nie je skutočne potrebné. Vážne. Pre väčšinu produkčných inferenčných workloadov postačujú NVIDIA L4, A10G alebo AWS Inferentia2 — pri zlomku ceny. Videl som tímy, ktoré behali Llama 8B na plnom H100 klastri, pretože „tak to bolo nastavené od tréningu". Škoda každého dolára.

Stratégia č. 1: Spot inštancie pre GPU — úspory 60–90 %

Spot inštancie sú najúčinnejší spôsob, ako dramaticky znížiť GPU náklady. V praxi prinášajú 60–90 % úspory oproti on-demand cenám. Áno, tá číslica nie je preklep.

Ale — vždy je nejaké ale — spot inštancie môžu byť kedykoľvek prerušené, keď cloud provider potrebuje kapacitu späť. A pri GPU workloadoch to bolí oveľa viac než pri bežnom compute.

Pre AI workloady to v praxi znamená:

Kedy sú spot inštancie ideálne

Tréning s checkpointing — ak váš tréning ukladá checkpointy každých 15–30 minút, prerušenie znamená len stratu posledných minút práce
Hyperparameter tuning — mnohé pokusy bežia súčasne a strata jedného nie je kritická (vlastne je to ideálny use case)
Batch inferencia — spracovanie veľkého datasetu, ktoré možno kedykoľvek reštartovať
Experimentálne workloady — prototypovanie modelov, A/B testovanie architektúr

Kedy sa spot inštanciám vyhnúť

Real-time produkčná inferencia — používatelia nemôžu čakať na rescheduling, to je jasné
Dlhodobý tréning bez checkpointing — strata hodín práce. Toto som zažil osobne a nie je to príjemné
SLA-viazané workloady — kde je garantovaná dostupnosť

Praktická implementácia: Checkpointing pre spot tréning

Tu je príklad implementácie automatického checkpointing v PyTorch, ktorý vám umožní bezpečne bežať tréning na spot inštanciách. Kľúčová je registrácia SIGTERM handlera — AWS vám dá 2-minútové varovanie pred prerušením, čo je dosť času na uloženie stavu:

import torch
import signal
import sys
import os

class SpotCheckpointManager:
    """Manager pre automaticky checkpointing na spot instanciach."""

    def __init__(self, model, optimizer, checkpoint_dir="/tmp/checkpoints"):
        self.model = model
        self.optimizer = optimizer
        self.checkpoint_dir = checkpoint_dir
        os.makedirs(checkpoint_dir, exist_ok=True)

        # Registracia signal handlera pre SIGTERM (spot prerusenie)
        signal.signal(signal.SIGTERM, self._handle_interruption)

    def _handle_interruption(self, signum, frame):
        """Ulozi checkpoint pri prijati SIGTERM signalu."""
        print("Spot prerusenie detekovane! Ukladam checkpoint...")
        self.save_checkpoint(epoch=-1, step=-1, emergency=True)
        sys.exit(0)

    def save_checkpoint(self, epoch, step, loss=None, emergency=False):
        """Ulozi checkpoint modelu a optimizera."""
        checkpoint = {
            "epoch": epoch,
            "step": step,
            "model_state_dict": self.model.state_dict(),
            "optimizer_state_dict": self.optimizer.state_dict(),
            "loss": loss,
        }
        filename = "emergency_checkpoint.pt" if emergency else f"checkpoint_e{epoch}_s{step}.pt"
        path = os.path.join(self.checkpoint_dir, filename)
        torch.save(checkpoint, path)
        print(f"Checkpoint ulozeny: {path}")

    def load_latest_checkpoint(self):
        """Nacita posledny dostupny checkpoint."""
        checkpoints = sorted(
            [f for f in os.listdir(self.checkpoint_dir) if f.endswith(".pt")],
            key=lambda x: os.path.getmtime(
                os.path.join(self.checkpoint_dir, x)
            ),
        )
        if not checkpoints:
            return None

        latest = os.path.join(self.checkpoint_dir, checkpoints[-1])
        checkpoint = torch.load(latest, weights_only=False)
        self.model.load_state_dict(checkpoint["model_state_dict"])
        self.optimizer.load_state_dict(checkpoint["optimizer_state_dict"])
        print(f"Checkpoint nacitany: {latest} (epoch {checkpoint['epoch']})")
        return checkpoint

Stratégia č. 2: Alternatívne AI čipy — Trainium, Inferentia a TPU

NVIDIA nie je jediná možnosť. Viem, pre mnohých to znie takmer hereticky, ale cloudoví poskytovatelia aktívne vyvíjajú vlastné AI akcelerátory, ktoré ponúkajú výrazne nižšie náklady za porovnateľný výkon — ak ste ochotní investovať do adaptácie.

AWS Trainium a Inferentia: až 70 % lacnejšia inferencia

AWS ponúka dva vlastné čipy pre AI workloady:

Trainium2 (trn1 inštancie) — navrhnutý pre tréning veľkých modelov. Cena je približne rovnaká ako p4d.24xlarge (~21,50 USD/hod vs. ~21,96 USD/hod), ale efektivita tréningu je až o 50 % vyššia pre podporované modely (Llama, GPT NeoX). Čiže neplatíte menej za hodinu, ale za ten istý výsledok platíte výrazne menej
Inferentia2 (inf2 inštancie) — navrhnutý pre produkčnú inferenciu. Cena 0,20–0,50 USD za 1 000 inferencií oproti 0,50–1,00 USD na H100. To je až 70 % úspora. AWS navyše uvádza až 12× vyšší priepustnosť pre PyTorch NLP aplikácie oproti NVIDIA T4

Kedy to dáva zmysel: Ak vaše mesačné inferenčné náklady presahujú 10 000 USD a vaše modely sú kompatibilné s Neuron SDK. Pod touto hranicou typicky engineering effort prevýši úspory — investícia do portácie sa vám jednoducho nevráti. Nad 100 000 USD mesačne ale 40–50 % zníženie nákladov prináša desaťtisíce dolárov mesačných úspor. To už stojí za zváženie.

Google TPU v5e: Najnižšia cena za tréning za token

Google TPU v5e ponúka 50–70 % nižšie náklady na miliardu tokenov v porovnaní s NVIDIA H100 klastrami. Pre organizácie, ktoré trénujú veľké jazykové modely a používajú JAX/TensorFlow, sú TPU výrazne ekonomickejšou voľbou. Ak ste ale na PyTorch (a väčšina ľudí je), prechod na TPU vyžaduje netriviálny refactoring.

Budúcnosť: Hybridné nasadenia

Toto ma osobne dosť zaujíma. Najnovší vývoj smeruje k hybridným klastrom, kde Trainium4 (očakávaný v roku 2026–2027) bude podporovať NVIDIA NVLink Fusion — umožní mixovanie Trainium a NVIDIA GPU v jednom klastri. Toto eliminuje nutnosť voliť „buď-alebo" a umožňuje optimalizovať náklady pre každú časť pipeline samostatne. Ak sa to potvrdí, bude to game changer.

Stratégia č. 3: Frakčné GPU v Kubernetes — zdieľanie namiesto plytvania

Tu je šokujúce číslo (a nie je to výnimka): prípadová štúdia z roku 2026 ukázala, že klaster s 20 inferenčnými jobmi na 10 NVIDIA A100 GPU bol v priemere využitý iba na 5 %. Päť percent. To znamená, že 95 % výpočtového výkonu za tisíce dolárov mesačne jednoducho stálo bez úžitku.

Riešením je frakčné GPU zdieľanie — rozdelenie jedného fyzického GPU medzi viacero kontajnerov. V podstate dva hlavné prístupy:

NVIDIA Multi-Instance GPU (MIG)

MIG je hardvérové rozdelenie GPU na izolované inštancie, každá s vlastnými výpočtovými jadrami, pamäťou a cache. Funguje na architektúrach Ampere a novších (A100, L40).

Praktický príklad: Namiesto pridelenia celého A100 (80 GB) každému inferenčnému jobu, ktorý potrebuje iba 4 GB GPU pamäte (a áno, toto vidím bežne), MIG rozdelí jeden A100 na až 7 izolovaných inštancií. Výsledok? Z 10 GPU, ktoré zvládajú len 10 jobov, sa stane 10 GPU zvládajúcich 70 jobov — pri využití blížiacom sa 100 %.

Konfigurácia v Kubernetes:

# MIG konfigurácia pre NVIDIA GPU Operator
apiVersion: v1
kind: ConfigMap
metadata:
  name: mig-parted-config
  namespace: gpu-operator
data:
  config.yaml: |
    version: v1
    mig-configs:
      # 7 rovnakych partícií pre ľahkú inferenčnú záťaž
      all-1g.10gb:
        - device-filter: ["0x233110DE", "0x232210DE"]
          devices: all
          mig-enabled: true
          mig-devices:
            "1g.10gb": 7

      # 3 väčšie partície pre stredné modely
      all-2g.20gb:
        - device-filter: ["0x233110DE"]
          devices: all
          mig-enabled: true
          mig-devices:
            "2g.20gb": 3

GPU Time Slicing — jednoduché zdieľanie bez hardvérovej podpory

Ak vaše GPU nepodporujú MIG (napríklad L4, A10G, T4), môžete použiť time slicing — GPU jednoducho prepína kontext medzi viacerými kontajnermi. Je to softvérové riešenie dostupné cez NVIDIA GPU Operator a nastavenie je pomerne priamočiare.

Benchmark z roku 2026 ukázal 65 % nárast využitia GPU v mixovanom inferenčnom prostredí. V ideálnych podmienkach môže time slicing bežať 10 ľahkých inferenčných jobov na jednom A100 — čo predstavuje až 90 % úspory na GPU infraštruktúre.

# NVIDIA GPU Operator - Time Slicing konfigurácia
apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    sharing:
      timeSlicing:
        renameByDefault: false
        failRequestsGreaterThanOne: false
        resources:
          - name: nvidia.com/gpu
            replicas: 4  # 4 pody zdieľajú 1 GPU

Dôležitý kompromis, na ktorý si dajte pozor: Time slicing neposkytuje pamäťovú izoláciu. Dva workloady zdieľajúce GPU si môžu vzájomne narušiť prístupové vzory k pamäti, čo spôsobuje nepredvídateľnú tail latenciu. Pre latency-kritické produkčné workloady radšej siahnite po MIG. Naučili sme sa to ťažkým spôsobom.

Kedy čo použiť — rozhodovací strom

Stratégia	Najlepšie pre	Úspora	Kompromis
MIG	Multi-tenantná inferencia, latency-citlivé workloady	70–85 %	Len A100/L40, statická konfigurácia
Time Slicing	Ľahké/burstové inferenčné joby	Až 90 %	Žiadna izolácia, nepredvídateľná latencia
MIG + Time Slicing	Mixované workloady	80–95 %	Vysoká komplexita

Stratégia č. 4: Optimalizácia na úrovni modelov — vLLM, kvantizácia a MoE

Nie vždy musíte riešiť infraštruktúru. Niekedy — a vlastne dosť často — najväčšie úspory prinesú zmeny v tom, ako model beží:

vLLM a PagedAttention: Eliminujte plytvanie KV-cache pamäťou

vLLM je momentálne najrozšírenejší open-source engine na servovanie LLM modelov. A zaslúžene. Jeho kľúčová inovácia — PagedAttention — spravuje KV-cache pomocou stránkovacieho systému inšpirovaného virtuálnou pamäťou operačného systému.

Tradičné serving enginy prealokujú súvislé bloky pamäte pre maximálnu dĺžku sekvencie každého requestu. Výsledok? 60–80 % KV-cache pamäte sa plytvá na padding. PagedAttention alokuje pamäť v malých, nesúvislých stránkach a prakticky eliminuje toto plytvanie.

V praxi to znamená, že na tom istom GPU zvládnete obslúžiť 2–4× viac súčasných requestov. Čo priamo znižuje počet potrebných GPU inštancií. Jednoduchá matematika.

# Spustenie vLLM servera s optimálnou konfiguráciou
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --tensor-parallel-size 1 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 4096 \
    --enable-chunked-prefill \
    --max-num-batched-tokens 8192 \
    --quantization awq

Kvantizácia: Menšie modely, rovnaká kvalita

Kvantizácia znižuje presnosť váh modelu z FP16 na INT8 alebo INT4, čím zmenšuje pamäťovú stopu modelu o 50–75 % a zrýchľuje inferenčný výkon. Zásadná vec je, že pre väčšinu produkčných prípadov je strata kvality minimálna — v mnohých benchmarkoch sotva merateľná.

AWQ (Activation-Aware Weight Quantization) — podľa mojich skúseností najlepší pomer kvalita/výkon pre INT4
GPTQ — overená metóda pre offline kvantizáciu, funguje spoľahlivo
FP8 — natívne podporované na NVIDIA L4 (G2 séria na GCP) s minimálnym dopadom na kvalitu

Praktický dopad: Model, ktorý pôvodne vyžadoval 4× A100 (80 GB), po INT4 kvantizácii beží na jednom A100 alebo dokonca na jednom L4. To je úspora ~75 % na GPU infraštruktúre. Stojí za vyskúšanie predtým, než začnete optimalizovať čokoľvek iné.

Mixture-of-Experts (MoE): Menej compute za request

Architektúry ako DeepSeek R1 využívajú sparse aktiváciu — iba zlomok modelu sa aktivuje pre každý request. Výsledkom je dramaticky nižšia spotreba compute na jednu inferenciu pri zachovaní plnej kapacity modelu. Pre organizácie, ktoré trénujú alebo fine-tunujú vlastné modely, je MoE architektúra jedným z najefektívnejších spôsobov, ako stlačiť inferenčné náklady nadol.

Stratégia č. 5: Commitment discounts a autoscaling pre GPU

Aj pre GPU workloady platí základný princíp FinOps: najprv rightsize, potom commit. V tomto poradí. Vždy.

Commitment discounts pre GPU inštancie

Všetci traja veľkí poskytovatelia ponúkajú záväzkové zľavy pre GPU inštancie:

AWS — EC2 Savings Plans a Reserved Instances pre P5, P4d. Trojročný záväzok na P5 môže ušetriť až 56 %. Od júna 2025 sa Savings Plans vzťahujú aj na P6-B200 (Blackwell)
GCP — Committed Use Discounts (CUDs) na 1 alebo 3 roky. GPU sú oprávnené pre resource-based CUDs. Spot VMs však CUDs nezískajú — čo je trochu škoda
Azure — 1–3 ročné rezervácie s úsporami ~30–50 %

Kľúčové pravidlo: Commitujte iba na stabilný baseline — tú minimálnu kapacitu, ktorú bežíte 24/7. Nič viac. Pre burstové workloady (tréning, experimentácia) používajte spot inštancie alebo on-demand. Videl som firmy, čo si kúpili 3-ročnú rezerváciu na základe peak spotreby a potom pol roka hľadali, čo s tým nevyužitým commitmentom robiť.

Kubernetes autoscaling pre GPU nody

Kubernetes 1.36 v roku 2026 priniesol vylepšený Cluster Autoscaler, ktorý lepšie spolupracuje s GPU nodmi. Konečne. Kľúčové stratégie:

Cluster Autoscaler — automaticky pridáva a odoberá GPU nody na základe čakajúcich podov a využitia zdrojov
Horizontal Pod Autoscaler (HPA) — škáluje počet inferenčných replik na základe GPU metrík (využitie, queue depth)
Vertical Pod Autoscaler (VPA) — optimalizuje alokáciu GPU pamäte pre jednotlivé pody
Dynamic Resource Allocation (DRA) — relatívne nová funkcia v Kubernetes 1.34+, ktorá umožňuje frakčné GPU priradenia a topology-aware scheduling

Správne nakonfigurovaný autoscaling zabraňuje dvom najčastejším problémom: over-provisioning (platíte za GPU, ktoré nikto nepoužíva) a under-provisioning (requesty čakajú v rade, pretože nie je dosť GPU). Nájsť ten správny balans vyžaduje čas a iteráciu, ale vyplatí sa.

Stratégia č. 6: Viditeľnosť a governance — tagovanie AI zdrojov

Nemôžete optimalizovať niečo, čo nevidíte. Znie to ako klišé, ale pri AI workloadoch je dôsledné tagovanie ešte dôležitejšie než pre bežné cloudové zdroje. Dôvod je jednoduchý — náklady sú rádovo vyššie a rýchlejšie rastú, takže neoznačený experiment za pár tisíc dolárov mesačne, na ktorý všetci zabudli, je reálny scenár.

Odporúčané tagy pre GPU zdroje (nad rámec štandardných tagov popísaných v našom článku o tagging stratégii):

Tag	Účel	Príklad
`WorkloadType`	Rozlíšenie tréningu vs. inferencie	`training`, `inference`, `fine-tuning`
`ModelName`	Identifikácia modelu	`llama-3.1-70b`, `whisper-large`
`ExperimentId`	Sledovanie experimentov	`exp-2026-03-001`
`ExpirationDate`	Automatické vymazanie dev zdrojov	`2026-04-15`
`GpuType`	Analýza nákladov podľa GPU	`h100`, `l4`, `inferentia2`

Organizácie, ktoré nasadili povinné tagovanie v kombinácii s automatickým vypínaním netagovaných zdrojov, reportujú 35 % zníženie GPU nákladov — a to len vďaka viditeľnosti a eliminácii zabudnutých experimentov. Žiadna mágia, len disciplína.

Stratégia č. 7: Anomálna detekcia a budget alerts pre GPU

Aj s najlepšou governance sa môže stať, že zle nakonfigurovaná tréningová slučka alebo neočakávaný nárast traffic spôsobí explóziu nákladov za hodiny. GPU workloady sú v tomto obzvlášť nebezpečné — keď platíte niekoľko dolárov za GPU za hodinu a máte 8-GPU klaster, deň neefektívneho behu vás vyjde na stovky dolárov.

Praktické kroky:

Nastavte budget alerts na úrovni projektu/tímu s prahovými hodnotami 50 %, 80 % a 100 % mesačného rozpočtu. Trvá to 10 minút a môže vám ušetriť nepríjemné prekvapenia
Monitorujte GPU utilization — GPU bežiace pod 10 % využitím sú červená vlajka. Nástroje ako DCGM Exporter v Kubernetes exportujú GPU metriky do Prometheus/Grafana
Implementujte automatické vypínanie — dev a staging GPU zdroje by sa mali automaticky vypínať mimo pracovný čas. Na 12-hodinovom pracovnom cykle to samo o sebe ušetrí 50 % nákladov na non-production workloady. A pritom je to triviálne nastaviť

# Príklad Cloud Custodian politiky - automatické zastavenie
# neaktívnych GPU inštancií
policies:
  - name: stop-idle-gpu-instances
    resource: aws.ec2
    filters:
      - type: instance-type
        value:
          - p5.48xlarge
          - p4d.24xlarge
          - g6.xlarge
          - g5.xlarge
      - type: metrics
        name: GPUUtilization
        namespace: CWAgent
        statistics: Average
        period: 3600      # posledná hodina
        value: 5          # menej ako 5 % využitie
        op: less-than
      - "tag:Environment": "development"
    actions:
      - type: stop
      - type: notify
        subject: "GPU inštancia zastavená pre nízke využitie"
        to:
          - "resource-owner"
        transport:
          type: sns
          topic: arn:aws:sns:eu-central-1:123456789:gpu-alerts

Akčný plán: 7 krokov k optimalizácii GPU nákladov

Dobre, dosť bolo teórie. Tu je konkrétny postup, ktorým môžete začať ešte dnes:

Audit súčasných nákladov — zistite, koľko platíte za GPU zdroje, rozdelené podľa tréningu, inferencie a experimentov. Bez tohto nemá zmysel robiť čokoľvek ďalšie
Tagging — nasaďte povinné tagy na všetky GPU zdroje (WorkloadType, ModelName, Owner, ExpirationDate)
Right-size GPU typy — presúňte inferenčné workloady z H100 na L4/A10G/Inferentia2, kde je to možné
Spot inštancie pre tréning — implementujte checkpointing a prejdite na spot pre všetky fault-tolerant tréningové joby
Frakčné GPU — nasaďte MIG alebo time slicing pre inferenčné workloady v Kubernetes
Optimalizácia modelov — implementujte vLLM s kvantizáciou (AWQ/GPTQ) pre produkčnú inferenciu
Automatizácia — nastavte automatické vypínanie dev zdrojov a budget alerts

Každý z týchto krokov prinesie merateľné úspory. V kombinácii dokážu znížiť celkové GPU náklady o 40–70 % — bez negatívneho dopadu na výkon alebo dostupnosť AI služieb. Nemusíte robiť všetko naraz — začnite tam, kde je najväčší potenciál (obvykle kroky 1–3), a postupne pridávajte ďalšie.

Často kladené otázky

Aký je rozdiel medzi GPU pre tréning a GPU pre inferenciu?

Tréningové GPU (H100, A100, Trainium) sú optimalizované pre masívne paralelné výpočty a vyžadujú veľkú pamäť a šírku pásma. Inferenčné GPU (L4, A10G, Inferentia2) sú optimalizované pre nižšiu latenciu a vyšší priepustnosť pri nižších nákladoch. Pre väčšinu produkčných inferenčných prípadov nie je ekonomicky opodstatnené používať tréningové GPU — aj keď sa to v praxi deje prekvapivo často.

Sú AWS Trainium a Inferentia vhodné pre každý AI model?

Nie, nie sú. Trainium a Inferentia vyžadujú použitie AWS Neuron SDK, čo znamená, že nie všetky modely a frameworky sú podporované. Najpopulárnejšie architektúry (Transformer, CNN) sú dobre podporované, ale vlastné alebo veľmi nové architektúry môžu vyžadovať dodatočný engineering effort. Odporúčam migráciu seriózne zvážiť, keď mesačné inferenčné náklady presahujú 10 000 USD.

Ako bezpečne využívať spot inštancie pre tréning AI modelov?

Kľúčom je implementácia pravidelného checkpointing — ukladanie stavu modelu každých 15–30 minút. Pri prerušení spot inštancie tréning pokračuje od posledného checkpointu. Použite signal handler pre SIGTERM, ktorý zachytí varovanie pred prerušením (AWS poskytuje 2-minútové varovanie) a automaticky uloží checkpoint. Príklad kódu nájdete vyššie v článku — v praxi je to jednoduchšie, než to znie.

Koľko reálne ušetrím s frakčným GPU zdieľaním v Kubernetes?

Závisí od vašich workloadov, ale čísla sú pekné. MIG na A100 dokáže obsluhovať až 7× viac ľahkých inferenčných jobov na rovnakom hardvéri — úspora 70–85 %. Time slicing umožňuje zdieľanie aj na lacnejších GPU (L4, T4) s úsporami až 90 %, ale bez pamäťovej izolácie. Reálne tímy reportujú 50–70 % zníženie GPU waste po nasadení frakčného zdieľania.

Ako monitorovať skutočné využitie GPU v cloude?

Pre Kubernetes workloady nasaďte NVIDIA DCGM Exporter, ktorý exportuje GPU metriky (utilization, pamäť, teplota) do Prometheus. Pre standalone EC2 inštancie použite CloudWatch agent s NVIDIA GPU metrikami. Kľúčová metrika je GPU utilization — čokoľvek pod 20 % v produkcii naznačuje potenciál na right-sizing alebo konsolidáciu. Začnite tam.