GPU FinOps 2026: гайд економії до 80%

Чесно? Витрати на GPU стали найболючішою рядком у хмарних рахунках 2026 року. Один інстанс p5.48xlarge з 8×H100 коштує близько $98/година on-demand у AWS — це понад $70 000 на місяць. Команди, які тренують або обслуговують великі моделі (LLM, дифузійні моделі, мультимодальні системи), легко спалюють шестизначні суми вже у перші тижні.

Гарна новина: при грамотному FinOps-підході реально скоротити ці витрати на 60–80% — і без втрати продуктивності. Я бачив це на власних клієнтах не один раз. Нижче — конкретні стратегії, числа та робочий код для AWS, Azure та GCP станом на травень 2026.

Чому GPU-витрати вибухнули у 2026 році

За даними FinOps Foundation State of FinOps 2026, оптимізація витрат на AI-навантаження вперше посіла перше місце серед пріоритетів FinOps-команд, обігнавши класичний right-sizing. Причини три:

Дефіцит GPU. H100 та H200 досі складно отримати on-demand; B200 (Blackwell) у GA з кінця 2025 — і то в обмежених регіонах. Це піднімає ціну за годину.
Експоненційне зростання інференсу. Один inference-запит до Llama 3.1 405B або GPT-class моделі споживає у 10–100 разів більше FLOPs, ніж класичний ML-інференс 2022 року.
«AI-стартапна психологія». Команди беруть найдорожчі інстанси «про запас», бо «модель не вміщається». У 90% випадків вона вміщається — після квантизації та правильного шардингу.

Базова таксономія GPU-витрат у хмарі

Перш ніж щось оптимізувати, розділіть навантаження на три категорії. У кожної — свої важелі економії:

Тренування (training) — довгі (години-тижні), толерантні до перезапусків, ідеальні для spot.
Файнтюнінг (fine-tuning, LoRA, QLoRA) — короткі (хвилини-години), часто batch-режим.
Інференс (inference) — низька латентність, високий uptime, погано переноситься spot.

Порівняння цін на GPU-інстанси (травень 2026)

Інстанс	GPU	On-demand $/год	Spot $/год	1-y Savings Plan
AWS p5.48xlarge	8×H100 80GB	$98.32	$29–45	$62.50
AWS p5e.48xlarge	8×H200 141GB	$112.00	$38–55	$71.20
Azure ND H100 v5	8×H100 80GB	$98.30	$31–47	$63.10
GCP a3-highgpu-8g	8×H100 80GB	$88.49	$26–40	$58.20
GCP a3-ultragpu-8g	8×H200 141GB	$103.20	$34–50	$66.10

Spot-ціни — діапазон, бо вони динамічні. У моменти дефіциту H100 spot може стрибати на 70–90% від on-demand (так, майже без знижки — і це не баг, а ринок).

Стратегія 1: Spot GPU для тренування — економія 60–75%

Spot-інстанси історично уникали для GPU через ризик переривання. У 2026 цей страх застарілий: всі основні фреймворки (PyTorch Lightning, DeepSpeed, NeMo, Hugging Face Accelerate) підтримують elastic checkpointing з частотою раз на 5–15 хвилин. Втрата прогресу при перериванні — менше 1%.

Робочий приклад: PyTorch на AWS spot з автоматичним checkpoint

import torch
from torch.distributed.checkpoint import save, load
from torch.distributed.checkpoint.state_dict import get_state_dict, set_state_dict
import boto3, os, signal, sys

CHECKPOINT_S3 = "s3://my-training-bucket/runs/llama-ft-2026-05/"
CHECKPOINT_EVERY_STEPS = 200

def save_checkpoint(model, optimizer, step):
    state = {"model": get_state_dict(model)[0], "opt": optimizer.state_dict(), "step": step}
    torch.save(state, f"/tmp/ckpt-{step}.pt")
    boto3.client("s3").upload_file(f"/tmp/ckpt-{step}.pt", "my-training-bucket",
                                   f"runs/llama-ft-2026-05/ckpt-{step}.pt")

def handle_spot_termination(signum, frame):
    # AWS shle SIGTERM ~2 hvylyny do pereryvannia
    save_checkpoint(model, optimizer, current_step)
    sys.exit(0)

signal.signal(signal.SIGTERM, handle_spot_termination)

for step, batch in enumerate(dataloader, start=resume_step):
    loss = model(batch).loss
    loss.backward(); optimizer.step(); optimizer.zero_grad()
    if step % CHECKPOINT_EVERY_STEPS == 0:
        save_checkpoint(model, optimizer, step)

Ключовий нюанс 2026 року: AWS EC2 Capacity Blocks for ML дозволяють зарезервувати кластер з 8–64 H100/H200 на період 1–182 дні. Ціна — приблизно посередині між spot та on-demand, але гарантована доступність. Як на мене, це краще за spot для критичного тренування з дедлайном.

Стратегія 2: Savings Plans та Committed Use Discounts для інференсу

Інференс погано переносить spot, бо latency-чутливий. Тут працюють зобов'язання:

AWS Compute Savings Plans — до 36% знижки за 1-річне зобов'язання, до 53% — за 3-річне. Покривають p5, g6, inf2.
GCP Committed Use Discounts (CUD) 3-year — до 55% знижки на a3/a4 інстанси. У 2026 з'явилася опція Flexible CUD, яка переноситься між регіонами (нарешті).
Azure Reservations + Azure Hybrid Benefit — комбінація дає до 51% на ND H100 v5.

Правило великого пальця: покривайте Savings Plans лише baseline-навантаження — десь 60–70% від мінімального робочого профілю, решту тримайте на on-demand або spot. Зайве зобов'язання гірше за відсутність знижки, перевірено гаманцем.

Стратегія 3: Квантизація моделей — економія 50–75% на одному запиті

Найшвидший спосіб зменшити рахунок — зменшити обчислення на один запит. У 2026 квантизація стала стандартом продакшну, а не «експериментальним хаком»:

Формат	Память	Швидкість	Якість vs FP16
FP16/BF16	100%	1.0×	baseline
FP8 (Hopper, Blackwell)	50%	1.6–1.9×	−0.1 до −0.3% MMLU
INT8	50%	1.5×	−0.3 до −0.8% MMLU
INT4 (AWQ, GPTQ)	25%	2.2–3.0×	−1 до −2% MMLU

Простий приклад: Llama 3.1 70B у FP16 потребує 2×H100 (140 GB), у FP8 — 1×H100, у INT4 — взагалі 1×L40S за $1.80/год замість $24.50/год. Якщо ваш use case толерантний до невеликої деградації якості, INT4-варіант — це 90%+ економії. На чат-ботах різницю помічають тільки ML-інженери.

Приклад: квантизація з vLLM (2026 версія)

# vLLM >=0.7 pidtrymuie FP8 ta INT4 z koroboky
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.3-70B-Instruct",
    quantization="fp8",          # abo "awq" dlia INT4
    kv_cache_dtype="fp8_e5m2",   # ekonomiya KV-cache pamiati
    tensor_parallel_size=1,      # vmistystsia v 1xH100
    gpu_memory_utilization=0.92,
    max_model_len=8192,
)

params = SamplingParams(temperature=0.7, max_tokens=512)
out = llm.generate(["Optimize my AWS bill"], params)

Стратегія 4: Continuous batching та KV-cache reuse

Класичний batching простоює, чекаючи найдовший запит у партії. Continuous batching (PagedAttention, vLLM, TGI) додає нові запити в порожні слоти на льоту. На реальних production-навантаженнях це підвищує throughput у 3–10 разів. Пряма пропорційна економія.

У 2026 додалося Prefix Caching: спільні префікси (системний промпт, інструкції) обчислюються один раз і шеруються між запитами. Для RAG-додатків з 4–8K токенами контексту це економить 40–60% compute. Якщо ви ще не ввімкнули — увімкніть просто зараз, це один параметр.

Стратегія 5: Managed AI vs власні GPU — рахуйте точку беззбитковості

AWS Bedrock, Azure OpenAI, Vertex AI Model Garden — це pay-per-token. Власний GPU — це fixed cost. Точка беззбитковості (приклад для Llama 3.1 70B, травень 2026):

Bedrock: ~$2.65 за 1M output-токенів
Власний 1×H100 (on-demand): $24.50/год; vLLM з FP8 видає ~3500 output-токенів/сек → ~$1.95 за 1M токенів
Точка беззбитковості: ~3M токенів/год сталого навантаження

Висновок: якщо ваш QPS нестабільний або менший за поріг — Bedrock/Vertex дешевше. Якщо у вас 24/7 baseline вище порогу — власний GPU з vLLM на spot дешевший у 3–5 разів за managed API.

Стратегія 6: Distillation та малі моделі для 80% запитів

Найдешевший токен — той, що не пройшов через 70B-модель. Класичний паттерн 2026 року — router + cascade:

Класифікатор (RoBERTa, ~200ms на CPU) визначає складність запиту.
«Легкі» запити (FAQ, форматування, прості summarization) — на Llama 3.2 3B або Mistral Small (працює на L4 за $0.81/год).
«Складні» (reasoning, код, аналіз) — на 70B або Claude/GPT.

На наших клієнтських даних 75–85% запитів закривалися малою моделлю. Економія — у 8–15 разів. Так, серйозно: 8–15х, не друкарська помилка.

Стратегія 7: Heterogeneous fleet та auto-scaling до нуля

GPU-кластери класично тримають «теплі» репліки. У 2026 з'явилися instant-scale рішення, які роблять це непотрібним для багатьох сценаріїв:

AWS SageMaker Serverless Inference for LLMs (GA 2025-Q4) — cold start 8–15 секунд, оплата за фактичні секунди.
Google Cloud Run with GPU (L4, A100) — scale-to-zero, cold start ~30 сек.
RunPod / Modal / Replicate — orchestrator-сервіси з більш агресивним scale-to-zero.

Простий лайфхак: для dev/staging-середовищ scale-to-zero вночі та на вихідні економить 65–70% рахунку без жодних змін у коді. Це буквально cron-таска, яка вимикає кластер о 19:00.

Стратегія 8: Моніторинг GPU-утилізації — приховані 40% economy

За даними OpenCost 2026, медіанна GPU-утилізація у ML-кластерах Kubernetes — 23%. Тобто, ви платите за 4 GPU, а тренуєте на еквіваленті одного. Боляче, правда?

# DCGM exporter + Prometheus + Grafana - minimum stek
helm install dcgm-exporter gpu-helm-charts/dcgm-exporter \
  --set serviceMonitor.enabled=true

# Kliuchovi metryky:
# DCGM_FI_DEV_GPU_UTIL              - % vykorystannia SM
# DCGM_FI_DEV_FB_USED               - vykorystana VRAM
# DCGM_FI_PROF_PIPE_TENSOR_ACTIVE   - aktyvnist Tensor Cores
# Iakshcho tensor_active < 30% - vy spaliuiete groshi na ne tomu mistsi

Якщо DCGM_FI_PROF_PIPE_TENSOR_ACTIVE стабільно нижче 40% — це сигнал тривоги: або дані не встигають дійти до GPU (I/O bottleneck), або модель занадто мала для вибраного GPU. Перейдіть на менший інстанс, або збільшіть batch size — одне з двох.

Чек-лист FinOps для GPU-навантажень (2026)

Розділіть навантаження: training (spot OK), inference (Savings Plans / CUD).
Тренування — на spot з checkpointing кожні 200–500 кроків.
Інференс — vLLM + FP8/INT4 квантизація + continuous batching + prefix cache.
Router + cascade: малі моделі для 75% запитів.
Покривайте Savings Plans лише 60–70% baseline.
Scale-to-zero для всіх non-prod середовищ.
DCGM-моніторинг: тримайте Tensor Core utilization > 50%.
Раз на квартал — A/B-тест managed API (Bedrock/Vertex) vs власний vLLM на актуальних цінах.

FAQ

Скільки коштує тренування LLM 70B з нуля у 2026 році?

Pre-training Llama 3-class моделі (70B параметрів, ~15T токенів) на spot-кластері з 256×H100 займає 21–28 днів і коштує приблизно $1.8–2.5 млн. Fine-tuning тієї ж моделі через QLoRA на 1×H100 — від $50 до $400 залежно від обсягу даних. Різниця, як бачите, на чотири порядки.

Чи безпечно використовувати spot GPU для production-інференсу?

Для критичного latency-чутливого інференсу — ні, не варто. Але для batch-інференсу (нічна генерація embeddings, ETL, scoring) spot дає 60–70% економії і повністю безпечний. Гібридний підхід: on-demand для baseline + spot fallback для пікового навантаження — найкращий компроміс, який я бачив на практиці.

Bedrock чи власний vLLM — що дешевше у 2026?

Залежить від QPS. Поріг беззбитковості для Llama 3.1 70B — приблизно 3 млн output-токенів на годину сталого навантаження. Нижче — Bedrock економніший (немає простоїв). Вище — власний vLLM на spot економить у 3–5 разів. Перерахуйте раз на квартал, бо ціни змінюються.

Як квантизація INT4 впливає на якість моделі?

На бенчмарках MMLU, HumanEval, GSM8K сучасні методи (AWQ, GPTQ, SmoothQuant) дають деградацію 0.5–2% для моделей >7B параметрів. Для більшості бізнес-задач (RAG, чат-боти, класифікація) це непомітно. Для математики та коду тестуйте окремо — там деградація може бути помітнішою.

Який інструмент моніторингу GPU-витрат найкращий?

Для Kubernetes — OpenCost з DCGM-інтеграцією (open-source, безкоштовний). Для multi-cloud — Vantage, CloudZero або CloudHealth з AI-cost модулями. Для початку, чесно, достатньо AWS Cost Explorer + Cost Allocation Tags за моделями та environment.