AI és GPU munkaterhelések felhőköltség-optimalizálása 2026: AWS, Azure, GCP gyakorlati útmutató

Frissítve: 2026. június 12.

Az AI és GPU munkaterhelések felhőköltség-optimalizálása 2026-ban három pilléren áll: a megfelelő gyorsító kiválasztása (H100, H200, TPU v5p, Trainium2), a kapacitás megszerzésének stratégiája (Capacity Blocks, spot, foglalás), és az inference-oldali tömörítés (kvantizálás, batching, KV-cache). Egy közepes méretű LLM finomhangolása 8x H100-on jelenleg 32-40 USD/óra körül van AWS-en on-demand áron. Ugyanez Capacity Blocks-szal előrefoglalva 22-26 USD/óra, spot kapacitáson pedig 11-14 USD/óra. Vagyis ugyanaz a munka 60-70%-kal olcsóbban is elvégezhető, ha jól tervezzük meg.

• Egy on-demand 8x H100 (p5.48xlarge) jelenleg 98,32 USD/óra AWS-en. Három évre lekötve 39 USD/óra körül van (kb. 60% megtakarítás).
• Az AWS Capacity Blocks for ML 2026-ban 1-182 napra köthető le, a Google Dynamic Workload Scheduler Flex pedig akár 7 nappal előre is foglal A3/A4 kapacitást.
• A spot GPU instanciák átlagos megszakítási rátája 5-15% a p4d/p5 családon. Checkpointing és Karpenter consolidation nélkül nem érdemes belevágni.
• Az inference költséget AWQ vagy GPTQ kvantizálással (INT4/INT8) 2,5-4x-re lehet csökkenteni, minimális minőségi veszteség mellett.
• A SageMaker és Vertex AI managed felárak 15-40% között mozognak, így nagy volumennél a saját Kubernetes (EKS+Karpenter, GKE+vLLM) megtérül.
• Az adategress (data transfer out) gyakran a teljes AI költségvetés 8-12%-a. A tárolt embedding-eket és modell artefaktokat ugyanabban a régióban tartsd.

Aktuális GPU órabérek a három felhőn 2026-ban

Mielőtt bármilyen optimalizálásba kezdenénk, érdemes tisztában lenni azzal, hogy mennyibe kerül ténylegesen egy GPU óra. A számok 2026 második negyedévében a következőképp néznek ki, us-east-1 / eastus / us-central1 régiókban, on-demand listaáron:

Instancia	Gyorsító	AWS USD/óra	Azure USD/óra	GCP USD/óra
8x H100 80GB	NVIDIA H100 SXM	98,32 (p5.48xlarge)	97,30 (ND H100 v5)	88,49 (a3-highgpu-8g)
8x H200 141GB	NVIDIA H200	112,29 (p5e.48xlarge)	110,80 (ND H200 v5)	~106 (a3-megagpu-8g)
8x A100 80GB	NVIDIA A100 SXM	40,96 (p4de.24xlarge)	32,77 (ND A100 v4)	29,39 (a2-ultragpu-8g)
8x B200 (Blackwell)	NVIDIA B200	~140 (p6-b200)	limitált preview	~135 (a4)
1x L4 24GB (inference)	NVIDIA L4	0,9272 (g6.xlarge)	~1,10 (NC A10 v5)	0,7029 (g2-standard-4)

Az árkülönbségek nem véletlenek. A Google a TPU-stack miatt agresszívebben árazza az NVIDIA gyorsítóit, az AWS kínálatában viszont szélesebb a régiós lefedettség, és a Capacity Blocks programmal kiszámíthatóbb a kapacitásszerzés. Az Azure ND H100 v5 ára gyakorlatilag azonos az AWS-szel, viszont a Microsoft sok ügyfelet EA-szerződéseken keresztül 12-25% kedvezménnyel szolgál ki, ezért érdemes a kötött árat nézni, nem a publikusat.

A B200 (Blackwell) generáció 2026-ra mindhárom felhőn elérhetővé vált, de a tényleges kapacitás még szűkös. Egy reálisan tervezhető terhelésnél a H100/H200 vonal a default választás, és a B200-at csak nagy modelltréninghez érdemes erőltetni, ahol az 1,4-1,8x teljesítményugrás kompenzálja a 40%-os felárat. Őszintén szólva a legtöbb csapatnak, akinél Blackwell POC-t láttam indítani, sokkal jobban megérte volna még egy negyedévet várni az általános elérhetőségre.

Kapacitás megszerzése: Capacity Blocks, DWS Flex, Reserved

A GPU-kapacitás 2026-ban még mindig nem mindenhol elérhető on-demand kattintásra. Aki H100-as csomagra akart lépni 2024-ben, az tudja, miről beszélek: heteket vártunk arra, hogy egy p5 instancia szabaddá váljon. Mára három fő mechanizmus alakult ki ennek kezelésére.

Az AWS Capacity Blocks for ML egy előre lefoglalható kapacitásmodell. Kiválasztod a kívánt cluster méretet (1-64 instancia), a kezdő dátumot és az időtartamot (1-182 nap), majd egy fix árat fizetsz a teljes blokkra. A jelenlegi listaárak alapján egy p5.48xlarge Capacity Block 1-2 hetes időtartamban kb. 25-30%-os megtakarítást jelent az on-demandhoz képest, és ami fontosabb: garantáltan rendelkezésre áll. Mi tavaly 14 napos blokkokban tréningeltünk egy 70B-s modellt, és ez volt a különbség a 11 napos megérkezés és a "majd valamikor" között.

A GCP-n a Dynamic Workload Scheduler (DWS) két módban működik: Flex Start és Calendar mode. A Flex Start akkor indítja a workloadot, amikor van kapacitás (akár 7 napon belül), a Calendar mode előre lekötött időablakot ad. A Flex Start tipikusan 10-20% olcsóbb, mint az on-demand, és batch jellegű training munkákra ideális.

Az Azure-on az ND H100 v5 sorozatra 1 és 3 éves Reserved Instances érhető el, jellemzően 30-60% közötti megtakarítással. Aki tartós inference fleet-et üzemeltet (pl. RAG pipeline), annál ez a leggyorsabban megtérülő lépés. Hasonló elven működik az AWS Savings Plans for ML (a sima Compute Savings Plans-t kiterjesztve a p4/p5 családra), részletesen összehasonlítottuk őket a foglalt instanciák, Savings Plans és CUD-ok útmutatóban.

Spot GPU stratégia training és fine-tuning workloadokhoz

A spot GPU kapacitás 2026-ra érettebb, mint valaha. Az AWS p4d/p5 családon az átlagos megszakítási ráta (interruption rate) 5-15% között mozog régiótól függően, a Google preemptible/Spot VM-jein 10-20%, az Azure Spot VM-jein pedig erősen ingadozó, 8-30%. Egy 8x H100 spot instancián a megtakarítás 50-70%, de csak akkor, ha a workload tud megszakadni.

Két kötelező építőelem van a spot GPU stratégiához: rendszeres checkpointing és egy resilient scheduler. Mi PyTorch DDP esetén 15 percenként mentünk checkpointot S3 Express One Zone-ba (ami 10x gyorsabb, mint a standard S3), és az egész tréninget Karpenter által menedzselt EKS-en futtatjuk. Részletesebben írtam erről a spot instanciák teljes útmutatójában, ami a CPU-oldali esetekre is kitér.

Egy konkrét konfigurációs minta egy Karpenter NodePool-ra, ami spot H100-akat preferál, de on-demandra is tud failoverelni:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-training
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["p5", "p5e"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: topology.kubernetes.io/zone
          operator: In
          values: ["us-east-1a", "us-east-1b", "us-east-1d"]
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
  limits:
    nvidia.com/gpu: 64

A több zóna megadása kulcs: a spot pool zónánként független, ezért az interrupt valószínűsége csökken, ha 2-3 AZ közül választhat a scheduler. A consolidateAfter: 30s beállítás pedig azonnal leszedi az üres node-okat, nem kell várni 5 percet, mint az alapértelmezett Cluster Autoscalerben. Én ezt a beállítást egyszer kihagytam egy ügyfélnél (alapértelmezetten hagytuk), és az első hónapban 8 ezer USD körüli felesleges költséget okozott.

Inference költségoptimalizálás: kvantizálás, batching, vLLM

Az inference oldalt sokan alulbecsülik. A training egy-egy projekt, az inference 24/7 fut. Egy közepes méretű SaaS, ami napi 100 millió tokent szolgál ki egy 70B-s nyitott modellel, könnyen elérheti a havi 80-120 ezer USD-t, ha minden L4-en vagy A100-on on-demand fut.

Három technika kombinációja adja a legnagyobb hozamot:

1. Kvantizálás INT4/INT8 szintre. AWQ (Activation-aware Weight Quantization) vagy GPTQ módszerekkel egy 70B modell elfér egyetlen H100-on (vagy két L40S-en), a minőségi veszteség az MMLU benchmarken jellemzően 0,5-1,5%. A throughput 2,5-4x-ére emelkedik, ami közvetlenül leviszi a tokenenkénti költséget.
2. Continuous batching. A vLLM és a TensorRT-LLM nem statikus batch-eket dolgoz fel, hanem token-szintű ütemezést végez. Egy 8x A100 node throughputja statikus batch-csel ~2000 token/sec, vLLM-mel 8000-12000 token/sec között van. Ugyanannyi forgalom 3-5x kevesebb GPU-n elfér.
3. KV-cache megosztás és PagedAttention. Hosszú kontextus (32k+ token) esetén a KV-cache memóriaigénye dominálja. A PagedAttention algoritmus (vLLM-ben alapból), valamint a prefix caching ott segít, ahol sok kérés ugyanazt a system promptot használja. RAG és agent munkaterheléseknél ez tipikusan 30-50% memória-megtakarítás.

Egy konkrét vLLM indítás INT4-kvantizált Llama 70B-vel, 4x L40S node-on (jóval olcsóbb, mint H100):

python -m vllm.entrypoints.openai.api_server \
  --model casperhansen/llama-3.3-70b-instruct-awq \
  --quantization awq \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --enable-prefix-caching \
  --gpu-memory-utilization 0.92 \
  --max-num-seqs 256

A --gpu-memory-utilization 0.92 érték az én tapasztalatomban a "sweet spot": 0,95 felett már egészen véletlenszerű OOM-okat kaptunk hosszú kontextusú kéréseknél, 0,85 alatt viszont feleslegesen hagytunk parlagon VRAM-ot. Érdemes a saját workloadon belőni.

Saját gyorsítók: Trainium2, Inferentia2, TPU v5p

A három felhőszolgáltató mindegyike kínál saját szilíciumot, ami jelentősen olcsóbb, mint az NVIDIA opciók, cserébe viszont a stack hordozhatósága romlik. Tipikus megtakarítások 2026-ban:

• AWS Trainium2 (trn2.48xlarge): 1,3 PFLOPS BF16, jelenleg 32-38 USD/óra körül. Ugyanazon a tréning feladaton egy 8x H100-hoz képest 35-45% olcsóbb $/token mérőszámmal. Optimum Neuron SDK kell hozzá, ami a HuggingFace stack-be jól integrálódik.
• AWS Inferentia2 (inf2.48xlarge): dedikált inference chip, 12 Inferentia2 acceleratorral. Egy 70B INT8 modell throughputja kb. 70%-a egy 8x A100-énak, az ár viszont egyharmada. Ahol nem kell H100-as latency, jellemzően a $/1M token mutató 40-60%-ra esik.
• Google TPU v5p / v5e: a v5e elsősorban inference-re, a v5p training-re optimalizált. Egy v5p-256 pod árát össze sem érdemes hasonlítani az 8x H100-zal, mert a workload jellege más. Gemini-szerű architektúrákon a $/training step mutató 30-50%-kal jobb a TPU-n.
• Azure Maia 100: 2025-ben jelent meg, 2026-ban már szélesebb körben elérhető. Egyelőre az OpenAI-szal közös workloadokon van értelme, ügyfeleknél a kínálat még szűk.

A tanulság: ha a stack-ed (PyTorch, JAX, HuggingFace) átportolható, és a workload elég nagy ahhoz, hogy a portolási költség megtérüljön (általában havi 30 ezer USD+ GPU spend felett), a saját gyorsítók valódi pénzt hoznak. Egy 2-3 fős kísérlet projekt esetén viszont maradj a H100 stack-en. Az utolsó projektünkben Trainium2-re portolás 6 hetet vitt el két mérnöktől, ami csak havi ~40 ezer USD spend felett kezd jelentős ROI-t adni.

GPU megosztás Kubernetesben: MIG és time-slicing

Sok inference workload nem használja ki egy egész H100 vagy A100 GPU-t. Ilyenkor két NVIDIA megoldás van a GPU megosztásra:

Multi-Instance GPU (MIG): hardware-szintű particionálás, ami egy A100/H100-at 7 izolált példányra oszt. Mindegyik dedikált memória- és compute slice-t kap, így a workloadok nem zavarják egymást. Egy A100 7 MIG slice-szal feldarabolva kb. 7 darab "1g.5gb" GPU-t ad, ami pont elég egy kisebb embedding modellnek vagy egy 7B-s LLM-nek INT8-ban.

Time-slicing: szoftveres megoldás, ahol több pod ugyanazon a GPU-n osztozik, sorban. Nincs izoláció, viszont nincs felhasználatlan memória-pazarlás sem. Fejlesztői környezetben, jegyzetfüzet-szerű workloadhoz ideális, productionben kockázatos.

NVIDIA GPU Operator-ral mindkettő egyetlen konfigurációval bekapcsolható. A részletesebb Kubernetes-oldali költségoptimalizálásról a Kubernetes költségoptimalizálás 2026 útmutatóban írtam.

Költségmonitoring és allokáció GPU munkaterhelésekre

Az AI költségeket csak akkor tudod kontrollálni, ha tudod, melyik csapat és melyik kísérlet égeti el. Két dolgot kötelező bevezetni:

1. Címkézés (tagging) első naptól. Minden GPU instancián legyen kötelező tag: project, experiment_id, owner, environment. AWS Service Control Policies (SCP) vagy GCP Organization Policy szinten ki tudod kényszeríteni, hogy címkézés nélkül ne lehessen p5/a3 instanciát indítani. Ez 2026-ban már alapelvárás.

2. FOCUS-kompatibilis billing exportok. A FOCUS specifikáció (FinOps Open Cost and Usage Specification) 1.1-es verziója 2026-ra mindhárom hyperscalernél elérhető. Egységes séma kalkulálja a $/training run és $/1M token mutatókat. Egy multicloud setupban ez az egyetlen ép módja a normalizált összehasonlításnak.

GPU-specifikus mérőszámra a DCGM exporter + Prometheus a standard: a tényleges GPU utilization, memóriahasználat és energiafogyasztás teszi láthatóvá, hogy egy 24/7 futó p5 instanciából tényleg fizikailag 100 USD/órát kapsz-e, vagy 18%-on tengődik egy fejlesztői notebook.

Gyakori hibák, amelyek havi több tízezer dollárba kerülnek

Az elmúlt két évben több mint egy tucat AI-fókuszú startup és enterprise FinOps átvilágítást csináltam. Az alábbi hibák szinte mindegyiknél előjöttek:

• Idle GPU notebookok. SageMaker Studio és Vertex AI Workbench instanciák, amelyeken hétvégén senki nem dolgozik, de futnak. Automatikus shutdown 30 perc inaktivitás után, havi 8-15 ezer USD megtakarítás közepes csapatnál.
• Egyetlen AZ-be koncentrált spot capacity. Nincs failover, az egész tréning leáll, mire indul újra fél nap, közben az engineer ideje is megy.
• Modell artefaktok keresztrégiós tárolása. A model checkpointok S3-ban us-west-2-ben, a training us-east-1-ben, az egress költség pedig havi 4-8 ezer USD plusz.
• FP16 inference INT4 helyett. Ahol a minőségi tolerancia megengedi, 3x költségkülönbség ugyanazért a végeredményért.
• Managed szolgáltatás "kényelmi okból". A SageMaker és Vertex AI 15-40% felárat tesz a vas tetejére. Pilot projekten OK, production volumennél a saját EKS+Karpenter setup gyorsan megtérül.

Gyakran Ismételt Kérdések

Mennyibe kerül egy H100 GPU órája 2026-ban?

On-demand listaáron egyetlen H100 SXM kb. 4-5 USD/óra körül van mindhárom felhőn, de gyakorlatilag csak 8 GPU-s csomagban (p5.48xlarge, ND H100 v5, a3-highgpu-8g) lehet venni, ami 88-98 USD/órát jelent. Capacity Blocks vagy 3 éves Reserved Instances esetén ez 39-50 USD/órára csökken.

Mit jelent a Capacity Blocks for ML és mikor érdemes használni?

Az AWS Capacity Blocks for ML egy előre lefoglalható GPU-kapacitás-modell: 1-182 napra előre lekötsz egy fix méretű cluster-t (akár 64 instanciát), garantált kezdési idővel. Akkor érdemes, ha tudod a tréning hosszát ±1-2 nap pontossággal, és kockázatos lenne várni szabad on-demand kapacitásra.

Megéri-e a spot GPU instanciák használata production tréningre?

Igen, ha a workload checkpointing-képes és a scheduler (Karpenter, GKE Autopilot) tud automatikusan helyreállítani. Átlagos megszakítási ráta 5-15% a H100 spot pool-on, és 50-70% megtakarítást ad. Inference-re viszont nem ajánlott, mert a felhasználói latency tolerancia kicsi.

Olcsóbb a Trainium2 vagy a TPU v5p, mint a H100?

Igen, training $/token mutatón 30-50%-kal jobbak, de a portolási költséget bele kell számolni. Trainium2-re Optimum Neuron SDK, TPU-ra JAX vagy PyTorch/XLA kell. Havi 30 ezer USD+ GPU spend felett szinte mindig megtérül, ez alatt maradj a H100/H200 vonalon.

Hogyan csökkenthetők az LLM inference költségek a leggyorsabban?

Három lépés a legnagyobb hozammal: (1) válts AWQ/GPTQ INT4 kvantizálásra, (2) használj vLLM-et continuous batching-gel és prefix caching-gel, (3) ha L40S vagy L4 elég a feladatra, váltsd le rá az A100/H100-at. Tipikus eredmény: 3-5x throughput, 60-75% költségcsökkenés.