GPU разходи AI/ML: AWS Azure GCP 2026

Актуализирано: 13 юли 2026

GPU оптимизацията на разходи за AI/ML работни натоварвания през 2026 означава комбиниране на три лоста: избор на правилния ускорител (NVIDIA H100/H200/B200, AWS Trainium2 или Google TPU v5p), правилният модел за резервиране (Capacity Blocks за training, on-demand или serverless за inference) и агресивно използване на spot/preemptible капацитет, където workload-ът го позволява. В моята практика като multi-cloud стратег това комбо редовно сваля сметките за GPU с 40-70% без загуба на производителност. Уловката е една: трябва да сравнявате правилните SKU-та във всеки cloud, иначе анализът излиза изцяло крив.

Резервираният капацитет за H100 в AWS Capacity Blocks струва $28-$32/час за p5.48xlarge, докато Azure ND H100 v5 on-demand е около $98/час, което е 3x разлика при equivalent hardware.
Google TPU v5e осигурява 60-70% по-ниска цена за inference на LLM-и до 70B параметра в сравнение с H100 SXM, но изисква JAX/XLA код.
Spot GPU-и в GCP (preemptible A3) и Azure (Low Priority ND) дават 70-80% отстъпка, но с 24-часов hard limit и по-висок процент на прекъсване.
AWS Trainium2 (trn2.48xlarge) е с 40% по-ниска цена от p5.48xlarge за обучение, но поддържа само PyTorch/JAX чрез Neuron SDK.
Fractional GPU чрез MIG на A100/H100 позволява да сервирате 7 модела на един физически GPU и е най-подценяваният лост за inference разходи.
За production inference workloads serverless опции (SageMaker Serverless Inference, Vertex AI Endpoints) са по-евтини от reserved capacity, ако утилизацията е под 40%.

GPU ценова картина на AWS, Azure и GCP през 2026

Пейзажът се промени доста през последните 18 месеца. NVIDIA Blackwell (B100/B200) вече е достъпен в pilot capacity в трите hyperscaler-а, H200 е mainstream, а H100 започна да поевтинява, особено в spot market-а. AWS реорганизира ML ценообразуването около Capacity Blocks (резервации от 1-14 дни) вместо стандартни 1/3-годишни RI, което е много по-подходящо за epizodic training runs. Azure продължава с NC/ND сериите (H100 SXM в ND H100 v5, H200 в ND H200 v5), а Google Cloud пусна A3 Mega и A3 Ultra с NVLink между 8x H100/H200 и своите TPU v5p pods за foundation model training.

Ключовият factor за 2026 е наличността. Дори при on-demand ставки, много региони нямат свободен H100 капацитет седмици наред. Това направи Capacity Blocks и Committed Use Discounts (CUD) не толкова средство за отстъпка, колкото гаранция за достъп. Като страничен ефект, spot pool-ите за GPU-и станаха по-стабилни от преди. Прекъсванията в us-east-1 spot p5 паднаха от 22% на 8% на седмица според моите logs от Q1 2026.

Колко струва H100 на час в трите cloud-а?

Това е първият въпрос, който клиентите ми задават, а правилният отговор изисква да сравнявате equivalent SKU-та. Един самотен H100 не е стандартна SKU в нито един cloud; всички продават 8x H100 в едно физическо шаси с NVLink. Ето сравнителна таблица за equivalent 8x H100 SXM5 конфигурации:

Параметър	AWS p5.48xlarge	Azure ND H100 v5	GCP a3-highgpu-8g
GPU	8x H100 80GB SXM5	8x H100 80GB SXM5	8x H100 80GB SXM5
vCPU / RAM	192 / 2 TB	96 / 1.9 TB	208 / 1.9 TB
NVLink пропускателна способност	900 GB/s	900 GB/s	900 GB/s
Мрежа (за multi-node training)	3200 Gbps EFA	3200 Gbps InfiniBand	3200 Gbps GPUDirect-TCPX
On-demand $/час	$98.32	$98.00	$88.49
1-year reserved / CUD	~$62/час (Capacity Blocks 14 дни)	$54.20/час (RI)	$54.06/час (3-year CUD)
Spot / Preemptible	$29-38/час (променливо)	$32-45/час	$27-33/час (24h max)

Наблюдението, което правя тук е, че on-demand цените са почти изравнени, но GCP печели за committed workloads поради 3-годишните CUD-та с 45% отстъпка. Ако правите training runs от 5-14 дни, AWS Capacity Blocks дават по-добра гъвкавост (купувате точно колкото ви трябва, без да заключвате капацитет за години напред). Azure Reserved Instances за ND H100 v5 остават най-скъпият от трите committed модела, но идват с най-добрата поддръжка за InfiniBand-базирани multi-node training runs на 512+ GPU-и.

Кога spot GPU-и имат смисъл за training и inference

Spot GPU-ите са най-мощният икономически лост, но и най-опасният, ако workload-ът не толерира прекъсвания. Правилото ми: ако checkpoint интервалът е под 20% от expected time-to-preemption, spot е печеливш; ако е над 40%, on-demand или Capacity Blocks са по-евтини заради загубеното преизчисление.

За foundation model training с 100+ H100 GPU-и, spot е рисков дори при добри checkpoint практики. Вероятността поне един node да падне за 48-часова run с 128 spot p5 инстанции е над 99%. Тук работят hybrid стратегии: on-demand parameter servers плюс spot workers, или "elastic training" с frameworks като DeepSpeed и PyTorch Lightning, които могат да продължат обучението с намален брой workers.

За inference workloads spot GPU-и работят отлично при два pattern-а: batch inference (нощни embedding jobs, offline scoring) и redundant serving (deploy на един и същ модел на spot и on-demand капацитет с автоматично failover). За single-endpoint online inference spot почти никога не се изплаща. 30-секундното warmup време на LLM с 70B параметра прави прекъсванията твърде скъпи. Ако още не сте намерили правилния баланс, вижте моето пълно ръководство за spot инстанции в AWS, Azure и GCP, където разглеждам interruption handling patterns в детайли.

AWS Capacity Blocks срещу Reserved Instances за ML

AWS Capacity Blocks for ML (представени в края на 2023 и радикално разширени през 2025-2026) са една от най-подценяваните иновации в GPU pricing. Работят като hotel booking: резервирате N GPU-и за конкретен период (1-14 дни), плащате авансово, получавате гарантиран капацитет. Няма ангажимент отвъд този период.

Икономически, Capacity Block за 8x p5.48xlarge (64 H100) за 7 дни в us-east-1 през юли 2026 струва около $87,000, сравнено с $132,000 за on-demand през същия период (34% отстъпка). Но истинската стойност е достъпът. Когато 512-GPU training run изисква всички node-ове едновременно и в един AZ, Capacity Blocks е практически единственият начин това да се случи без EDP negotiation. Честно казано, точно това ме спаси на един клиент миналата пролет, когато търсехме 384 H100 за spike в pre-training и spot pool-ът беше изсъхнал за седмици.

# Резервация на Capacity Block за 64 H100 за 7 дни
aws ec2 create-capacity-reservation-fleet \
  --instance-type-specifications '[{
    "InstanceType": "p5.48xlarge",
    "InstancePlatform": "Linux/UNIX",
    "AvailabilityZone": "us-east-1a",
    "Weight": 1
  }]' \
  --tenancy default \
  --total-target-capacity 8 \
  --allocation-strategy prioritized \
  --end-date 2026-07-20T00:00:00Z \
  --instance-match-criteria targeted

За сравнение, стандартни Compute Savings Plans не покриват p5, p6 и G-серия инстанции. Ако предимно правите training, Capacity Blocks плюс spot mix почти винаги е по-евтино от 1-year SP на equivalent capacity. За production inference, където утилизацията е стабилна 24/7, EC2 Instance Savings Plans за g6e (L40S) или p5.48xlarge остават валидна опция. Ако не сте сигурни коя опция подхожда на профила ви, разгледайте моята детайлна сравнителна анализа на Savings Plans срещу Reserved Instances.

Google TPU срещу NVIDIA GPU: кой е по-евтин?

TPU v5e и v5p (плюс експерименталният v6e "Trillium") са конкурентното предимство на GCP за LLM training и inference, ако вашият stack може да ги използва. TPU v5e (inference-optimized) в конфигурация 4x chip pod дава производителност еквивалентна на 4x H100 за LLM inference до 70B параметра при 60-70% по-ниска цена. TPU v5p (training-optimized, до 8960-chip pods) конкурира H100 SXM за foundation model pre-training.

Метрика	TPU v5e (4-chip)	TPU v5p (8-chip)	H100 SXM (8x)
BF16 TFLOPs (общо)	788	3,712	7,912
HBM памет	64 GB	760 GB	640 GB
On-demand $/час	$5.34	$32.79	$88.49
3-year CUD $/час	$1.87	$11.48	$54.06
Framework поддръжка	JAX, PyTorch/XLA, TF	JAX, PyTorch/XLA, TF	Всички
Interconnect	ICI 1.6 TB/s	ICI 4.8 TB/s	NVLink 900 GB/s

Има един важен catch: PyTorch/XLA все още има значителни производствени неудобства. Compilation time за първата итерация може да е 15-45 минути на TPU, spectral debugging е ограничено, а много state-of-the-art оптимизации (FlashAttention-3, Blackwell FP4) идват в PyTorch/CUDA първо. За стартиращи ML екипи с уредена PyTorch codebase, преминаването на TPU струва 2-4 седмици инженерно време, което трябва да отчетете в total cost analysis. За JAX-native workloads (Gemini, Anthropic Claude training pipelines) TPU остават unbeatable по $/token.

Виждам най-голям ROI от TPU-та при production inference на open-weight модели като Llama 3.1 70B или Qwen 2.5 72B чрез vLLM с TPU backend. Цената за 1M tokens пада от $4.20 (H100 self-hosted) на около $1.35 на TPU v5e. За справка, официалната Google Cloud TPU v5e документация има detailed benchmarks по модел архитектура.

AWS Trainium и Inferentia: cost profile за 2026

AWS Trainium2 (trn2.48xlarge, наличен от края на 2024) е Amazon отговорът на TPU: custom silicon за foundation model training с $30-33/час on-demand в сравнение с $98/час за p5.48xlarge (67% по-ниско). Наскоро анонсираният Trainium3 обещава още 40% по-добра енергийна ефективност и е в pilot capacity в us-east-1.

Reality check: Trainium като TPU изисква специфичен SDK (Neuron SDK), който поддържа PyTorch и JAX, но не всички operations. Anthropic публично използва Trainium за Claude training runs, което е силен signal, но за middle-tier ML екипи с diverse workloads (fine-tuning, RAG pipelines, computer vision) Trainium все още изисква значителна инженерна инвестиция.

Inferentia2 (inf2.48xlarge) е много по-лесен sell: 12 Neuron chips, $12.98/час on-demand, оптимизиран за high-throughput inference. За Llama 3.1 8B и подобни модели inf2 доставя ~2x по-добро $/token в сравнение с equivalent g6e (L40S) инстанции. За production serving на open-weight модели с висока volume, Inferentia2 често е най-добрият чист-cost избор в AWS. Направете си бенчмарк на реалната latency, защото за real-time interactive workloads (под 100ms TTFT) H100 остава по-бърз. Аз лично поне два пъти съм се опарил, като съм разчитал само на TPS цифрите от datasheet-а, без да меря tail latency.

Как да намалите GPU разходите за inference

Inference обикновено доминира total GPU spend в production ML екипи, типично 70-85% от cost според моите audits на 30+ SaaS компании през 2025-2026. Стратегиите с най-голямо влияние са:

Quantization (INT8/FP8/FP4). Blackwell B200 нативно поддържа FP4, което удвоява throughput за същия модел. За H100/H200 INT8 или FP8 quantization с TensorRT-LLM или vLLM може да намали GPU memory footprint 2-4x, позволявайки да сервирате повече requests на един GPU.
Continuous batching и paged attention. vLLM и SGLang прилагат continuous batching, което подобрява GPU utilization от типичните 20-30% до 60-80% за LLM serving. Резултатът е директно 2-3x повече throughput за същия hardware.
Speculative decoding. Малък "draft" модел (напр. Llama 3.1 8B) генерира кандидати, които големият модел verifies. Реален throughput gain 1.5-2.5x без загуба на quality.
Router-based model selection. Simple queries отиват на по-евтини модели (Llama 3.1 8B на L4), сложни на H100. RouteLLM и подобни framework-и намаляват среден cost per query с 40-60%.
Right-sizing на GPU tier. Много екипи сервират 7-13B параметрови модели на A100/H100, когато L4/L40S са напълно достатъчни при 1/3 от цената. Погледнете детайлното ми ръководство за right-sizing на облачни ресурси за методология.

# Пример: vLLM continuous batching + FP8 quantization на H100
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    quantization="fp8",           # FP8 намалява memory 2x спрямо BF16
    tensor_parallel_size=4,       # 4 H100 вместо 8
    max_num_seqs=256,             # continuous batching capacity
    enable_prefix_caching=True,   # кешира system prompt tokens
    gpu_memory_utilization=0.92,
)

sampling = SamplingParams(temperature=0.7, max_tokens=1024)
# 4x H100 сега сервира 70B модел с throughput еквивалентен на 8x без quantization
outputs = llm.generate(prompts, sampling)

Fractional GPU и MIG: скритият лост за инференс

NVIDIA Multi-Instance GPU (MIG) на A100/H100/H200 позволява да разделите един физически GPU на до 7 изолирани instance-а с dedicated compute и memory. Това е сериозна промяна за multi-tenant inference serving, защото можете да хоствате 7 различни модела на един H100 без interference, всеки със свои SLA гаранции.

Икономически: A100 40GB partitioned в 7x MIG 1g.5gb дава ~$4.30/час за MIG slice, докато dedicated T4 (single GPU eq.) струва $0.53/час. MIG е по-скъп per slice, но осигурява много по-добра latency и достъп до 40GB HBM. Ключът е дали workload-ът ви наистина изисква A100/H100 клас памет, или T4/L4 е достатъчен.

За Kubernetes deployments, NVIDIA GPU Operator плюс NVIDIA Kubernetes Device Plugin exposes MIG slices като schedulable resources. Комбинирано с Karpenter за auto-scaling, това дава изключително ефективна pod-density. Ако вече използвате Kubernetes за ML serving, разгледайте моето ръководство за Kubernetes оптимизация на разходи с Karpenter, KEDA и VPA.

Практически checklist за GPU оптимизация през 2026

Ето workflow-ът, който препоръчвам на всеки нов клиент през първата седмица от engagement:

Инвентаризирайте utilization. AWS CloudWatch (GPUUtilization metric чрез CloudWatch Agent), Azure Monitor (GPU counters) или GCP Cloud Monitoring за 14 дни. Всичко под 40% avg utilization е кандидат за right-sizing или MIG.
Разделете workload-ите по interruption tolerance. Batch inference и dev/test отиват на spot. Multi-node training отива на Capacity Blocks. 24/7 online inference се покрива с RI/SP/CUD.
Bench-маркирайте quantization impact. FP8 или INT8 квантизиран модел на MMLU/HumanEval. Ако quality drop е под 2%, деплойте квантизираната версия.
Проверете TPU/Trainium alternatives. Ако сте на PyTorch, Trainium2 може да даде 40-50% cost cut за training. Ако сте на JAX, TPU v5e е no-brainer за inference.
Настройте anomaly detection. AWS Cost Anomaly Detection, Azure Cost Alerts или GCP Budget Alerts специфично за GPU SKU-та. GPU discovery runs могат да отидат от $2K/ден на $40K/ден за часове без alarms. Аз съм виждал точно такъв overrun у клиент, който забрави инстанция включена през weekend.
Внедрете showback за ML екипи. Тагвайте всеки GPU workload с team, project и environment. Без chargeback culture, cost optimization не се задържа.

Референтна документация, която препоръчвам: AWS P5/P6 instance overview, Azure ND H200 v5 series documentation и Google Cloud GPU platforms overview за официалните SKU-та и региони.

Често задавани въпроси

Кой cloud provider има най-евтини H100 GPU-и през 2026?

За on-demand цени GCP a3-highgpu-8g е най-евтин на $88.49/час срещу $98/час за AWS p5.48xlarge и Azure ND H100 v5. За committed capacity GCP 3-year CUD дава най-добрата ставка ($54/час), но AWS Capacity Blocks предлагат уникална гъвкавост за epizodic training runs от 1-14 дни без дългосрочен ангажимент.

Струва ли си да мигрирам от H100 към TPU v5 за inference?

Ако вашият stack вече използва JAX или можете да инвестирате 2-4 седмици в PyTorch/XLA migration, да, TPU v5e осигурява 60-70% по-ниска цена за LLM inference до 70B параметра. За PyTorch-heavy екипи с diverse workloads (fine-tuning, computer vision, RAG) TPU-тата остават по-трудни за justify заради framework limitations.

Мога ли да използвам spot GPU-и за foundation model training?

Технически да, практически с ограничения. За single-node fine-tuning spot работи добре при чест checkpointing. За multi-node training с 128+ GPU-и вероятността да загубите поне един node за 48-часова run е над 99%, така че използвайте hybrid стратегия: on-demand parameter servers плюс spot workers, или elastic frameworks като DeepSpeed, които продължават с намален брой workers.

Каква е разликата между AWS Capacity Blocks и Reserved Instances за ML?

Capacity Blocks резервират P/G инстанции за конкретен период от 1-14 дни с плащане авансово и без дългосрочен ангажимент, идеални за epizodic training runs. Reserved Instances изискват 1 или 3-годишен commitment, но покриват 24/7 workloads с най-добра ставка. За production inference използвайте RI/SP; за training runs Capacity Blocks почти винаги са по-подходящи.

Как MIG (Multi-Instance GPU) намалява разходите за inference?

MIG разделя един физически A100/H100 GPU на до 7 изолирани instance-а със собствен compute и memory. Това позволява да сервирате няколко различни модела на един физически GPU без взаимна интерференция, увеличавайки utilization от 20-30% до 70-80% и намалявайки cost per model deployment с 3-5x при multi-tenant inference scenarios.