Jak snížit náklady na AI/ML workloady v cloudu: 7 strategií pro úspory GPU v roce 2026

Úvod: AI boom a GPU náklady, které vás můžou překvapit

Umělá inteligence a strojové učení dávno přestaly být doménou výzkumných laboratoří. V roce 2026 AI používá prakticky každá organizace – startupy trénují vlastní jazykové modely, e-commerce firmy ladí doporučovací systémy a finanční instituce provozují modely pro detekci podvodů. Jenže s touhle masivní adopcí přichází i masivní problém: náklady na GPU infrastrukturu rostou závratným tempem a pro spoustu organizací se stávají tou největší položkou na cloudové faktuře.

A čísla mluví jasně.

Trh s AI infrastrukturou dosáhl v roce 2024 hodnoty 50 miliard dolarů a roste tempem 35 % ročně. Podle průzkumu theCUBE Research řadí 74,3 % organizací AI/ML workloady mezi hlavní výdajové priority na příštích 12 měsíců. A State of FinOps 2026 report odhalil, že 98 % respondentů nyní aktivně spravuje AI výdaje – dramatický nárůst z 63 % v roce 2025 a pouhých 31 % v roce 2024.

Pro startupy budující AI aplikace představuje GPU compute typicky 40–60 % celkového technického rozpočtu v prvních dvou letech. Trénování moderních foundation modelů může stát miliony dolarů za jeden běh. A přitom organizace stále plýtvají 30–50 % svých cloudových výdajů na nevyužité nebo předimenzované zdroje. To je hodně peněz, které odtékají zbytečně.

V předchozích článcích jsme se věnovali FinOps praktikám v multi-cloud prostředí a optimalizaci nákladů na Kubernetes. Dnes se zaměříme na oblast, která tyto dvě témata přirozeně doplňuje – optimalizaci nákladů na AI a ML workloady. Ukážeme si konkrétní strategie, nástroje a techniky, díky kterým můžete snížit náklady na GPU compute o 40–70 %, aniž byste obětovali výkon nebo kvalitu modelů. Tak pojďme na to.

Proč jsou AI/ML náklady tak odlišné od tradičních cloudových workloadů

Než se ponoříme do optimalizačních strategií, je potřeba pochopit jednu zásadní věc – správa nákladů na AI/ML workloady je fundamentálně odlišná od tradičních cloudových aplikací. Bez tohoto pochopení budete optimalizovat naslepo.

Specifika AI/ML nákladové struktury

Na rozdíl od tradičních workloadů, kde jsou náklady primárně řízeny CPU a pamětí, u AI/ML nákladů do hry vstupuje celá řada proměnných:

• GPU a akcelerátory: Hlavní nákladový driver – jedna GPU instance H100 stojí na AWS přibližně 3,90 USD/hodinu on-demand, na Azure dokonce 6,98 USD/hodinu
• Masivní datasety: Storage a přenos dat pro trénovací datasety mohou tvořit překvapivě velkou část celkových nákladů
• Trénovací cykly: Jeden trénovací běh může trvat hodiny až týdny a spotřebovat tisíce GPU-hodin
• Inference provoz: Na rozdíl od trénování je inference kontinuální a roste s počtem uživatelů
• Token-based pricing: API služby jako Azure OpenAI nebo Google Vertex AI účtují podle tokenů, což je sakra těžko předvídatelné

Malé změny v konfiguraci modelu, návrhu promptů nebo chování uživatelů mohou vést k nepřiměřeným výkyvům nákladů. Právě tato nepředvídatelnost dělá z AI nákladů tak náročnou výzvu – tradičními FinOps přístupy na to prostě nevystačíte.

Trénování vs. inference: dva zcela odlišné světy

Jednou z nejčastějších chyb (a viděl jsem ji opravdu mnohokrát) je aplikování stejné nákladové strategie na trénování i inference. Přitom jde o fundamentálně odlišné workloady:

• Trénování je typicky batch process – má definovaný začátek a konec, vyžaduje maximální GPU výkon a je tolerantní k latenci. Ideální kandidát na spot instance a off-peak scheduling
• Inference je kontinuální služba – běží 24/7, vyžaduje nízkou latenci a konzistentní propustnost. Potřebuje spolehlivou infrastrukturu, ale často vystačí s méně výkonnými GPU

Podle odhadů bude do roku 2030 inference tvořit 75 % veškerého AI compute. Takže pokud optimalizujete jenom trénování a na inference zapomínáte, řešíte menšinu problému.

Srovnání cen GPU instancí: AWS vs. Azure vs. GCP v roce 2026

Prvním krokem k optimalizaci je pochopení cenové krajiny. A ta se v posledním roce hodně proměnila – zejména díky agresivním cenovým úpravám ze strany AWS.

On-demand ceny H100 GPU (za GPU/hodinu)

Aktuální přehled on-demand cen za jednotlivou H100 GPU u hlavních poskytovatelů:

• Google Cloud (A3-High): přibližně 3,00 USD/GPU-hod – nejlevnější z hyperscalerů
• AWS EC2 (P5 instance): přibližně 3,90 USD/GPU-hod – po 44% snížení ceny v červnu 2025
• Microsoft Azure (NC H100 v5): přibližně 6,98 USD/GPU-hod – výrazně dražší než konkurence

Klíčovým milníkem byl červen 2025, kdy AWS oznámil přibližně 44% snížení cen P5 instancí (H100) napříč regiony. Azure naproti tomu tak výrazné snížení neprovedl, což z něj aktuálně dělá nejdražší volbu pro GPU workloady v on-demand režimu. Ten rozdíl je opravdu markantní.

Spot a preemptible ceny

Spot instance nabízejí dramatické úspory za cenu možného přerušení:

• GCP Spot H100 (A3-High): přibližně 2,25 USD/GPU-hod
• AWS Spot H100: přibližně 2,50 USD/GPU-hod
• Specializovaní poskytovatelé: od 1,49 USD/GPU-hod (např. Hyperbolic pro H100)

Zajímavý detail – AWS Spot ceny H100 klesly mezi lednem 2024 a zářím 2025 o 88 %, což představuje 8,65násobné zlepšení nákladové efektivity. Trh s GPU kapacitou se prostě výrazně nasytil.

Reserved instance a committed use slevy

Pro předvídatelné workloady nabízejí commitment-based modely nejvýraznější úspory:

• AWS Reserved Instances / Savings Plans: až 72 % sleva – efektivní cena H100 může klesnout na 1,90–2,10 USD/GPU-hod
• Azure Reservations / Savings Plans: až 40–50 % sleva v závislosti na regionu
• Google Cloud Committed Use Discounts: až 70 % sleva, plus automatické sustained-use slevy

Google Cloud navíc nabízí granulárnější cenový model – platíte zvlášť za GPU a zvlášť za podkladový virtuální stroj. To umožňuje přesnější optimalizaci konfigurace, což je příjemná flexibilita.

Strategie č. 1: Right-sizing GPU instancí pro různé workloady

Upřímně, tohle je asi nejčastější chyba, na kterou narážím. Organizace nasazují stejný typ GPU instance na úplně všechno. Trénování velkého jazykového modelu ale vyžaduje jiný hardware než servírování inference požadavků nebo experimentování v Jupyter notebooku.

Přiřazení správného GPU k správnému úkolu

Doporučená strategie alokace GPU podle typu workloadu:

• Vývoj a experimentování: NVIDIA T4 nebo A10G – levné GPU dostačující pro prototypování, EDA a testování pipeline
• Fine-tuning menších modelů: NVIDIA A10G nebo L4 – dostatečný výkon pro fine-tuning modelů do 7B parametrů
• Trénování velkých modelů: NVIDIA A100 (40/80 GB) nebo H100 – nutné pro modely nad 13B parametrů a distribuované trénování
• Production inference: NVIDIA T4, L4 nebo A10G – po optimalizaci modelu (kvantizace, distillation) často postačí levnější GPU
• High-throughput inference: NVIDIA A100 nebo H100 – pro velké modely s vysokým počtem souběžných požadavků

Přesunutí inference workloadů z H100 na T4 nebo L4 po provedení kvantizace modelu může snížit náklady o 60–80 % při zachování přijatelné kvality a latence. To není zanedbatelné číslo.

Monitoring GPU utilizace

Základním předpokladem right-sizingu je měření skutečného využití GPU. Bez dat se optimalizovat nedá. Tady jsou klíčové metriky, které byste měli sledovat:

# Základní monitoring GPU utilizace pomocí nvidia-smi
nvidia-smi --query-gpu=utilization.gpu,utilization.memory,memory.used,memory.total,temperature.gpu --format=csv -l 5

# Výstup každých 5 sekund:
# utilization.gpu [%], utilization.memory [%], memory.used [MiB], memory.total [MiB], temperature.gpu
# 45 %, 62 %, 25034 MiB, 40960 MiB, 67
# 43 %, 61 %, 25034 MiB, 40960 MiB, 66

Pro systematický monitoring v Kubernetes prostředí se hodí integrace s Prometheus a Grafana:

# Prometheus query: průměrná GPU utilizace za posledních 24 hodin
avg_over_time(
  DCGM_FI_DEV_GPU_UTIL{
    namespace="ml-training",
    pod=~"training-.*"
  }[24h]
)

# Prometheus query: využití GPU paměti v procentech
DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_FREE * 100

Pokud vaše GPU konzistentně vykazuje utilizaci pod 30 %, jste předimenzovaní – přejděte na menší instanci. Pokud je utilizace trvale nad 85 % s občasnými OOM chybami, potřebujete buď větší GPU, nebo optimalizaci modelu. Žádná věda, ale musíte ta data mít.

Strategie č. 2: Spot instance pro trénovací workloady

Spot instance představují jednoznačně nejefektivnější způsob, jak stáhnout náklady na trénování modelů. Úspora 50–90 % oproti on-demand cenám je reálná. Ale vyžaduje to správnou přípravu.

Checkpointing: Základ práce se spot instancemi

Checkpointing je technika, při které periodicky ukládáte stav trénovacího procesu – váhy modelu, stav optimizéru, learning rate schedule a náhodná semínka. Při přerušení instance pak trénování jednoduše obnovíte z posledního checkpointu místo toho, abyste začínali od nuly. Bez checkpointingu jsou spot instance hazard.

Klíčová pravidla:

• Frekvence: Ukládejte checkpoint každých 10–15 minut do trvalého úložiště (S3, Azure Blob, GCS)
• Kompletní stav: Ukládejte nejen váhy modelu, ale i stav optimizéru, learning rate schedules a random seeds
• Zpracování signálů: Implementujte obsluhu SIGTERM signálu pro graceful shutdown při přerušení
• Automatické obnovení: Pipeline by měl automaticky detekovat existující checkpoint a pokračovat v trénování

Praktická implementace v PyTorch (tahle třída se vám bude hodit):

import torch
import signal
import sys
from pathlib import Path

class SpotCheckpointManager:
    def __init__(self, checkpoint_dir, save_interval_minutes=15):
        self.checkpoint_dir = Path(checkpoint_dir)
        self.checkpoint_dir.mkdir(parents=True, exist_ok=True)
        self.save_interval = save_interval_minutes * 60  # sekundy
        self.last_save_time = 0

        # Zachycení SIGTERM pro graceful shutdown
        signal.signal(signal.SIGTERM, self._handle_termination)

    def _handle_termination(self, signum, frame):
        print("Přijat SIGTERM – ukládám emergency checkpoint...")
        self.save_checkpoint(self.model, self.optimizer,
                           self.epoch, self.step, emergency=True)
        sys.exit(0)

    def save_checkpoint(self, model, optimizer, epoch, step,
                       scheduler=None, emergency=False):
        import time
        current_time = time.time()

        if not emergency and (current_time - self.last_save_time) < self.save_interval:
            return  # Ještě není čas na checkpoint

        checkpoint = {
            'epoch': epoch,
            'step': step,
            'model_state_dict': model.state_dict(),
            'optimizer_state_dict': optimizer.state_dict(),
            'rng_state': torch.random.get_rng_state(),
        }
        if scheduler:
            checkpoint['scheduler_state_dict'] = scheduler.state_dict()
        if torch.cuda.is_available():
            checkpoint['cuda_rng_state'] = torch.cuda.get_rng_state_all()

        path = self.checkpoint_dir / f"checkpoint_epoch{epoch}_step{step}.pt"
        torch.save(checkpoint, path)
        self.last_save_time = current_time
        print(f"Checkpoint uložen: {path}")

    def load_latest_checkpoint(self, model, optimizer, scheduler=None):
        checkpoints = sorted(self.checkpoint_dir.glob("checkpoint_*.pt"))
        if not checkpoints:
            return 0, 0  # Žádný checkpoint – start od začátku

        latest = checkpoints[-1]
        checkpoint = torch.load(latest, weights_only=False)
        model.load_state_dict(checkpoint['model_state_dict'])
        optimizer.load_state_dict(checkpoint['optimizer_state_dict'])
        torch.random.set_rng_state(checkpoint['rng_state'])
        if scheduler and 'scheduler_state_dict' in checkpoint:
            scheduler.load_state_dict(checkpoint['scheduler_state_dict'])
        if torch.cuda.is_available() and 'cuda_rng_state' in checkpoint:
            torch.cuda.set_rng_state_all(checkpoint['cuda_rng_state'])

        print(f"Checkpoint obnoven z: {latest}")
        return checkpoint['epoch'], checkpoint['step']

Diverzifikace instancí pro maximální dostupnost

Nespoléhejte na jeden typ instance v jedné availability zóně. To je recept na problémy. AWS Spot Fleet nebo GCP Managed Instance Groups dokážou automaticky rozložit workloady:

• Konfigurujte 10–15 různých typů instancí pro maximální dostupnost
• Rozložte workloady přes více availability zón a regionů
• Udržujte 20% kapacitní buffer pro hladké přechody při přerušení
• Akceptujte mírně suboptimální instance výměnou za lepší dostupnost

Důležitý detail – AWS poskytuje 2minutové varování před ukončením spot instance, Google Cloud dává jen 30 sekund u preemptible VM. Tato varování musíte využít k uložení stavu, jinak přijdete o progres od posledního checkpointu.

Managed Spot Training služby

Pokud nechcete řešit komplexitu spot instancí sami (a je to legitimní rozhodnutí), managed služby jako Amazon SageMaker Managed Spot Training automaticky zvládnou přerušení, checkpointing i obnovení trénování. Cinnamon AI například díky SageMaker Managed Spot Training dosáhla 70% snížení nákladů na trénování a 40% nárůst počtu denních trénovacích běhů.

Strategie č. 3: Optimalizace modelů pro levnější inference

Inference náklady bývají často podceňovány, přestože tvoří většinu dlouhodobých AI výdajů. Dobrá zpráva je, že existuje celá řada technik, jak dramaticky snížit výpočetní nároky inference bez výrazné ztráty kvality.

Kvantizace: méně bitů, nižší náklady

Kvantizace je v podstatě snížení přesnosti čísel reprezentujících váhy modelu – typicky z FP32 (32 bitů) na INT8 (8 bitů), FP8, INT4 nebo dokonce FP4. Co to přináší v praxi:

• Menší paměťové nároky: Model zabírá 2–8× méně GPU paměti
• Rychlejší inference: Nižší přesnost znamená rychlejší výpočty
• Levnější GPU: Kvantizovaný model může běžet na menší a levnější GPU

V roce 2025 přinesl NVIDIA Model Optimizer (dříve TensorRT Model Optimizer) podporu formátu NVFP4, který dosahuje extrémní komprese při minimální ztrátě přesnosti. Na Hugging Face jsou nyní dostupné kvantizované modely jako DeepSeek-R1-FP4 a Llama-3.3-70B-Instruct-FP4.

Praktický příklad kvantizace s ONNX Runtime:

from onnxruntime.quantization import quantize_dynamic, QuantType
import onnxruntime as ort

# Dynamická kvantizace modelu z FP32 na INT8
quantize_dynamic(
    model_input="model_fp32.onnx",
    model_output="model_int8.onnx",
    weight_type=QuantType.QInt8
)

# Porovnání velikosti a výkonu
import os
original_size = os.path.getsize("model_fp32.onnx") / (1024 * 1024)
quantized_size = os.path.getsize("model_int8.onnx") / (1024 * 1024)
print(f"Původní model: {original_size:.1f} MB")
print(f"Kvantizovaný model: {quantized_size:.1f} MB")
print(f"Komprese: {original_size / quantized_size:.1f}x")

# Inference s kvantizovaným modelem
session = ort.InferenceSession("model_int8.onnx", providers=['CUDAExecutionProvider'])
result = session.run(None, {"input": input_data})

Knowledge distillation: menší model, srovnatelná kvalita

Knowledge distillation komprimuje velký „učitelský" model do menšího „žákovského" modelu. Při správném provedení si žákovský model zachová až 97 % výkonu originálu, přičemž má výrazně méně parametrů a vyžaduje levnější hardware.

Typický scénář vypadá takhle: organizace trénuje velký 70B model jako učitele a poté z něj distiluje 7B model pro production inference. Náklady na inference klesnou řádově, zatímco kvalita zůstane pro daný use case dostatečná. Není to samozřejmě zadarmo – distillation vyžaduje vlastní trénovací cyklus – ale ta investice se většinou rychle vrátí.

ONNX Runtime a TensorRT pro akceleraci

Optimalizační frameworky jako ONNX Runtime a NVIDIA TensorRT dokážou výrazně zrychlit inference existujících modelů:

• ONNX Runtime dosahuje 1,3–2,9násobného zrychlení oproti TensorFlow a 1,1–1,7násobného oproti PyTorch díky grafové fúzi a optimalizaci paměti
• TensorRT nabízí hardwarově specifickou akceleraci na NVIDIA GPU s až 6násobným zrychlením inference
• Adobe dosáhla pomocí kombinace Model Optimizer + TensorRT 60% snížení latence difuzních modelů a 40% snížení celkových nákladů na provoz

Kombinace více technik – třeba kvantizace INT8 + TensorRT optimalizace + batching – přináší kumulativní úspory, které mohou dosáhnout 70–80 % oproti neoptimalizovanému deploymentu. To už stojí za tu námahu.

Strategie č. 4: Google TPU jako alternativa pro inference

Zajímavou (a trochu opomíjenou) alternativou k NVIDIA GPU jsou Google TPU. Podle dostupných dat nabízejí TPU 4násobně lepší poměr výkon/cena pro inference oproti NVIDIA GPU.

Příklad z praxe – Midjourney přesunutím inference na TPU snížilo náklady o 65 %. TPU navíc mají nižší spotřebu energie, což snižuje i náklady na chlazení v datových centrech o 30–40 %.

Migrace na TPU není triviální a vyžaduje úpravu kódu, to je potřeba říct na rovinu. Ale pro organizace s velkými inference workloady může přinést úspory 40–60 % na compute rozpočtu. Framework JAX od Google výrazně zjednodušuje vývoj a optimalizaci pro TPU, takže ten přechod nemusí být tak bolestivý, jak se může zdát.

Strategie č. 5: Automatizace lifecycle managementu GPU zdrojů

Jedním z nejvýznamnějších zdrojů plýtvání u AI/ML workloadů jsou idle GPU instance – prostě GPU, které běží, ale nic nepočítají. Platíte za vzduch. Automatizace lifecycle managementu tento problém řeší.

Automatické vypínání idle GPU instancí

Implementujte automatickou detekci a vypínání neaktivních GPU instancí. Jednoduchý přístup pomocí AWS CloudWatch:

# AWS CLI: Vytvoření CloudWatch alarmu pro nízkou GPU utilizaci
aws cloudwatch put-metric-alarm \
  --alarm-name "idle-gpu-instance-i-0abc123" \
  --metric-name GPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 3600 \
  --threshold 5 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:eu-west-1:123456789:idle-gpu-alerts \
  --dimensions Name=InstanceId,Value=i-0abc123

Scheduling pro vývojová a testovací prostředí

GPU instance pro vývoj a testování by nikdy neměly běžet 24/7. Nikdy. Implementujte scheduling, který instance automaticky vypíná mimo pracovní dobu:

# Terraform konfigurace pro automatické vypínání GPU instancí
# mimo pracovní dobu (Po-Pá 8:00-20:00 CET)

resource "aws_scheduler_schedule" "stop_gpu_dev" {
  name = "stop-gpu-dev-instances"

  schedule_expression = "cron(0 19 ? * MON-FRI *)"  # 19:00 UTC = 20:00 CET
  schedule_expression_timezone = "Europe/Prague"

  target {
    arn      = aws_lambda_function.manage_gpu_instances.arn
    role_arn = aws_iam_role.scheduler_role.arn
    input    = jsonencode({
      action = "stop"
      tag_key = "Environment"
      tag_value = "development"
    })
  }
}

resource "aws_scheduler_schedule" "start_gpu_dev" {
  name = "start-gpu-dev-instances"

  schedule_expression = "cron(0 7 ? * MON-FRI *)"  # 07:00 UTC = 08:00 CET
  schedule_expression_timezone = "Europe/Prague"

  target {
    arn      = aws_lambda_function.manage_gpu_instances.arn
    role_arn = aws_iam_role.scheduler_role.arn
    input    = jsonencode({
      action = "start"
      tag_key = "Environment"
      tag_value = "development"
    })
  }
}

Tato jednoduchá automatizace – vypínání GPU dev instancí mimo pracovní dobu a o víkendech – může ušetřit přibližně 65–72 % nákladů na vývojovou infrastrukturu. Za pár řádků Terraformu to není špatný deal.

Fractional GPU sharing v Kubernetes

V Kubernetes prostředí nemusí každý pod nutně potřebovat celou GPU. Fractional GPU sharing umožňuje sdílení jedné GPU mezi více pody:

# Kubernetes manifest pro fractional GPU s NVIDIA MPS
apiVersion: v1
kind: Pod
metadata:
  name: inference-service-a
spec:
  containers:
  - name: model-server
    image: my-inference:latest
    resources:
      limits:
        nvidia.com/gpu: "1"   # Logická GPU
    env:
    - name: CUDA_MPS_ACTIVE_THREAD_PERCENTAGE
      value: "25"             # Tento kontejner využije max 25 % GPU
---
apiVersion: v1
kind: Pod
metadata:
  name: inference-service-b
spec:
  containers:
  - name: model-server
    image: my-inference-b:latest
    resources:
      limits:
        nvidia.com/gpu: "1"
    env:
    - name: CUDA_MPS_ACTIVE_THREAD_PERCENTAGE
      value: "25"

Díky GPU sharingu můžete na jedné fyzické GPU provozovat 2–4 menší inference služby. Využití GPU dramaticky vzroste a celkové náklady půjdou dolů.

Strategie č. 6: FinOps pro AI – organizační a procesní změny

Technické optimalizace jsou skvělé, ale bez správných organizačních procesů a kultury zůstane jejich efekt omezený. Můžete mít sebelepší nástroje – pokud se nikdo nedívá na čísla, nepomůže to.

Granulární cost attribution

Prvním krokem je pochopení, kam přesně vaše AI peníze směřují. Implementujte důsledné tagování všech GPU zdrojů:

# Příklad tagování GPU instancí pro cost attribution
aws ec2 create-tags \
  --resources i-0abc123def456 \
  --tags \
    Key=Project,Value=recommendation-engine \
    Key=Team,Value=ml-platform \
    Key=Environment,Value=production \
    Key=WorkloadType,Value=inference \
    Key=Model,Value=rec-model-v3 \
    Key=CostCenter,Value=CC-4521

V Kubernetes prostředí využijte labels a nástroje jako Kubecost pro alokaci GPU nákladů na úrovni jednotlivých namespaců, teamů a projektů. Doporučení FinOps Foundation je jednoznačné: přidejte cost-centre labely a Kubecost (nebo ekvivalent) ještě předtím, než se první GPU node připojí k clusteru. Ne potom. Předtím.

Budgety a alerting

Nastavte granulární budgety pro každý AI projekt a tým. GPU workloady mají nepříjemnou tendenci generovat nákladové špičky – a vy je chcete zachytit včas:

• Denní budget alert: Upozornění při překročení 120 % průměrné denní útraty
• Anomaly detection: Automatická detekce neobvyklých vzorců – třeba nečekané spuštění velkého trénovacího clusteru
• Forecast alert: Upozornění, když předpokládané měsíční náklady překročí rozpočet

ML modely dokážou analyzovat vzorce útraty napříč tisíci zdroji současně a detekovat anomálie během minut. Špatně nakonfigurovaný Auto Scaling group spouštějící 500 instancí? Zachyceno dávno předtím, než přijde faktura.

TCO plánování pro AI projekty

Celkové náklady vlastnictví (TCO) AI use casů se dost liší od tradičních softwarových aplikací. Klíčové aspekty, které musíte zahrnout do TCO kalkulace:

• Trénovací náklady: Iniciální trénování + pravidelné přetrénování (retraining je kontinuální náklad, na to se často zapomíná)
• Inference náklady: GPU compute, ale i networking a load balancing
• Storage náklady: Trénovací data, checkpointy, model registry, logy
• Data pipeline náklady: ETL, feature engineering, data labeling
• Kvalitativní dimenze: Trade-off mezi levnějšími menšími modely a dražšími reasoning modely

FinOps Foundation doporučuje vytvořit komplexní strategii zahrnující jak finanční rollup na úrovni celé organizace, tak přizpůsobené metody pro jednotlivé inženýry a workloady.

Strategie č. 7: Multi-cloud a specializovaní poskytovatelé

Podle Flexera přijímá 59 % podniků multi-cloud strategii částečně kvůli optimalizaci nákladů. U GPU workloadů je to obzvlášť relevantní, protože cenové rozdíly mezi poskytovateli jsou opravdu enormní.

Specializovaní GPU cloud poskytovatelé

Vedle tradičních hyperscalerů (AWS, Azure, GCP) existuje rostoucí ekosystém specializovaných GPU cloud poskytovatelů s výrazně nižšími cenami:

• Specializovaní poskytovatelé (např. GMI Cloud, Lambda) nabízejí H100 od 2,10 USD/hod – úspora 40–70 % oproti hyperscalerům
• Decentralizované platformy (např. Vast.ai) jsou typicky o 50–80 % levnější než AWS on-demand
• Hyperbolic nabízí H100 za 1,49 USD/hod a H200 za 2,15 USD/hod

Trade-off je jasný: nižší ceny, ale menší ekosystém služeb a potenciálně nižší spolehlivost. Pro čistě compute-intensive workloady jako trénování modelů to ale může být ideální volba.

Strategická distribuce workloadů

Optimální přístup je rozložit workloady podle jejich charakteristik:

• Trénování: Specializovaní poskytovatelé nebo spot instance na hyperscalerech – cena je priorita
• Production inference: Hyperscaleři s reserved capacity – spolehlivost a SLA jsou priorita
• Experimentování: Decentralizované platformy nebo preemptible VM – minimální náklady, přerušení nevadí
• Batch inference: Spot instance kdekoli – tolerantní k přerušení, optimalizace na cenu

Praktický akční plán: prvních 30 dní

Pokud s optimalizací AI/ML nákladů teprve začínáte, tady je strukturovaný plán na první měsíc. Nic přehnaně ambiciózního – postupné kroky, které přinesou reálné výsledky.

Týden 1: Viditelnost

1. Auditujte všechny běžící GPU instance a jejich skutečnou utilizaci
2. Implementujte důsledné tagování (projekt, tým, prostředí, typ workloadu)
3. Nastavte Kubecost nebo CloudHealth pro GPU cost attribution
4. Identifikujte idle a underutilized GPU instance

Týden 2: Quick wins

1. Vypněte všechny idle GPU instance (a nebojte se – pokud je nikdo nepostrádal, nepotřebujete je)
2. Implementujte scheduling pro dev/test prostředí
3. Přesuňte vhodné trénovací workloady na spot instance
4. Right-sizujte instance, které konzistentně vykazují nízkou utilizaci

Týden 3: Optimalizace modelů

1. Kvantizujte production inference modely (INT8 jako první krok)
2. Implementujte ONNX Runtime nebo TensorRT pro akceleraci inference
3. Vyhodnoťte možnost knowledge distillation pro velké modely
4. Nastavte batching pro inference požadavky

Týden 4: Procesy a governance

1. Nastavte budgety a alerting pro každý AI projekt
2. Vytvořte GPU provisioning policy (kdo může spustit jakou instanci)
3. Implementujte automatické škálování inference služeb
4. Naplánujte pravidelný měsíční cost review

Shrnutí a klíčové závěry

Optimalizace nákladů na AI/ML workloady není jednorázový projekt – je to kontinuální disciplína. Vyžaduje kombinaci technických dovedností, správných nástrojů a organizační kultury. Tady je to nejdůležitější:

• Right-sizing je základ: Nepoužívejte H100 na inference, když po kvantizaci stačí T4. Správné přiřazení GPU ke workloadu může ušetřit 25–60 %
• Spot instance pro trénování: S robustním checkpointingem ušetříte 50–90 % nákladů na trénování. Investice do správné implementace checkpointingu se vrátí mnohonásobně
• Optimalizace modelů: Kvantizace, distillation a inference frameworky (ONNX Runtime, TensorRT) přinášejí kumulativní úspory 60–80 %
• Automatizace lifecycle: Scheduling, auto-scaling a fractional GPU sharing eliminují idle waste
• FinOps kultura: Granulární cost attribution, budgety a pravidelné review zajišťují dlouhodobou udržitelnost
• Multi-cloud strategie: Specializovaní GPU poskytovatelé nabízejí 40–70 % úspory pro compute-intensive workloady

Nejdůležitější je začít. I malé kroky přinášejí významné úspory. Organizace, které budují nákladové povědomí od prvního dne a považují GPU čas za vzácný zdroj, konzistentně překonávají ty, které optimalizují až poté, co překročí rozpočet.

Podle State of FinOps 2026 je správa AI nákladů dovedností číslo jedna, kterou FinOps týmy plánují rozvíjet – a upřímně, není se čemu divit. AI transformuje byznys, ale bez nákladové disciplíny může snadno transformovat i vaši firemní kreditní kartu.