GPU-затраты в облаке: FinOps-гайд (2026)

Введение: GPU-расходы — новый главный враг облачного бюджета

Если вы уже освоили обязательства (Reserved Instances, Savings Plans, CUD), научились пользоваться спот-инстансами и отладили Kubernetes-кластеры — что ж, поздравляю, базовый уровень облачной оптимизации пройден. Но в 2026 году появился совершенно новый фронт борьбы за бюджет. И имя ему — ИИ-нагрузки.

По данным FinOps Foundation, 98% организаций теперь управляют расходами на ИИ в рамках FinOps-практик. Для сравнения, в 2024 году этот показатель был всего 31%. За каких-то два года ИИ из экспериментального проекта превратился в крупнейшую статью облачных расходов для многих компаний.

Цифры, честно говоря, впечатляют и пугают одновременно. Корпоративные расходы на генеративный ИИ выросли с 11,5 млрд долларов в 2024 году до 37 млрд в 2025-м. 80% компаний превышают свои прогнозы по затратам на ИИ более чем на 25%. Обучение одной крупной языковой модели может стоить до 192 миллионов долларов. А GPU-инстансы обходятся в 5–10 раз дороже обычных вычислительных ресурсов.

Главная проблема — традиционные методы FinOps для ИИ-нагрузок попросту не работают. Спрогнозировать потребление GPU по историческим данным почти невозможно: нагрузки слишком нерегулярны. Обучение моделей — это всплески, инференс — постоянно растущие расходы, а эксперименты дата-сайентистов генерируют хаотичный поток ресурсов, который стандартными инструментами не контролируется.

Давайте разберём практические стратегии оптимизации GPU-расходов в AWS, Azure и GCP. От выбора правильного оборудования до квантования моделей и автоматизации — всё, чтобы ИИ-проекты не сожрали весь бюджет.

Сколько стоят GPU в облаке: ценовая карта 2026 года

Прежде чем оптимизировать, нужно понимать масштаб проблемы. Рынок облачных GPU за последний год серьёзно изменился — цены упали, появились новые чипы, а разброс между провайдерами стал ещё заметнее.

NVIDIA H100: главная рабочая лошадка

H100 (80 ГБ) — самый востребованный GPU для обучения и инференса крупных моделей. Вот актуальные цены на on-demand на начало 2026 года:

AWS (инстансы P5) — примерно $3,90/GPU-час. В июне 2025 года AWS снизил цены на P5 на 44%, что заметно изменило расклад.
GCP (инстансы A3) — примерно $3,00/GPU-час. Самый доступный вариант среди гиперскейлеров.
Azure (NC H100 v5) — около $6,98/GPU-час. Самый дорогой вариант on-demand. Azure до сих пор не объявлял о серьёзных снижениях цен на H100.

Для сравнения: специализированные ML-провайдеры (Lambda Labs, RunPod, Vast.ai) предлагают H100 по $1,49–$2,99/GPU-час — в 2–3 раза дешевле. Но тут есть свои подводные камни: меньше регионов, слабее сеть, минимум управляемых сервисов.

NVIDIA A100: бюджетная альтернатива

A100 по-прежнему отлично справляется с инференсом и обучением моделей среднего размера. На открытом рынке цены упали ниже $1/GPU-час — очень привлекательный вариант для задач, которым мощность H100 попросту не нужна.

Специализированные чипы: T4, L4, Inferentia

Не все ИИ-нагрузки требуют топового GPU. Для инференса зачастую хватает более дешёвого оборудования:

NVIDIA T4 — около $0,50–$1,20/час. Отлично подходит для инференса небольших моделей и обработки изображений.
NVIDIA L4 — примерно $0,79/час на GCP. Пожалуй, лучшее соотношение цены и производительности для инференса прямо сейчас.
AWS Inferentia 2 — специализированный ASIC от Amazon, обеспечивающий до 70% снижения стоимости инференса по сравнению с эквивалентными EC2-инстансами на GPU.

Первый шаг к оптимизации — перестать по умолчанию назначать H100 на все задачи подряд. Для инференса модели с 7 миллиардами параметров T4 или L4 за доллар в час справится ничуть не хуже, чем H100 за семь.

Обучение vs инференс: где утекают деньги

Тут критически важно понимать разницу между двумя типами GPU-нагрузок, потому что стратегии оптимизации для них принципиально разные.

Обучение моделей

Обучение — это интенсивные всплески потребления. Дата-сайентисты запускают эксперименты, которые могут длиться часы или дни, потребляя при этом десятки GPU одновременно. Типичные проблемы:

Повторные эксперименты — одну и ту же модель обучают десятки раз с чуть-чуть разными гиперпараметрами. Без трекинга экспериментов (MLflow, Weights & Biases) это превращается в бесконтрольное сжигание денег.
Неэффективные пайплайны данных — GPU простаивает, пока ждёт загрузки данных. Банальная, но очень частая проблема.
Отсутствие раннего останова — модель продолжает обучаться после того, как метрики перестали расти. Чистый waste.

Инференс (вывод модели)

Инференс — это постоянно работающая инфраструктура для обслуживания запросов к модели. И вот тут-то скрываются основные деньги: 80–90% совокупной стоимости владения ИИ-системой приходится именно на инференс, а не на обучение. Многие об этом забывают.

Типичные проблемы инференса:

Переразмеренные GPU — A100 крутится с загрузкой 10–15%, потому что «так настроили изначально». Утилизация GPU в облаке в среднем составляет жалкие 15–30%.
Статичное масштабирование — эндпоинт работает на пиковую нагрузку 24/7, хотя реальный пик — 4 часа в день.
Отсутствие кэширования — одни и те же запросы обрабатываются снова и снова, каждый раз расходуя GPU.

Стратегия 1: правильный выбор GPU под задачу (right-sizing)

Самый очевидный и, как ни странно, самый недооценённый способ экономии — перестать ставить топовые GPU на все задачи без разбора.

Матрица выбора GPU

Вот практическая матрица для подбора GPU под типичные ИИ-задачи:

Обучение крупных моделей (70B+ параметров) — H100 или H200 (когда станут доступны). Тут альтернатив просто нет — нужна максимальная производительность и объём VRAM.
Обучение средних моделей (7B–30B) — A100 80GB. Мощности хватает, а стоимость в 3–4 раза ниже H100.
Файн-тюнинг с QLoRA — A100 40GB или даже T4/L4. QLoRA позволяет обучать адаптеры на вполне бюджетном оборудовании.
Инференс крупных моделей — A100 или L4 (с квантованием). После квантования в INT4/INT8 многие модели прекрасно работают на L4.
Инференс небольших моделей (до 7B) — T4 или L4. Использовать что-то мощнее — чистая потеря денег.
Пакетная обработка (batch inference) — спот-инстансы с A100 или T4. Если задача допускает прерывания, экономия до 60–90%.

Пример: расчёт экономии при right-sizing инференса

Допустим, вы обслуживаете квантованную модель на 13B параметров. Сравниваем два варианта:

# Вариант A: H100 на AWS (P5)
# Стоимость: $3.90/час × 24 × 30 = $2,808/мес
# Утилизация GPU: ~15%

# Вариант B: L4 на GCP
# Стоимость: $0.79/час × 24 × 30 = $568.80/мес
# Утилизация GPU: ~65%

# Экономия: $2,808 - $568.80 = $2,239.20/мес (80%)
# При 10 эндпоинтах: $22,392/мес = $268,704/год

80% экономии — просто за счёт выбора правильного GPU. Без рефакторинга, без квантования — только правильный подбор оборудования под реальную нагрузку. По моему опыту, именно right-sizing даёт самый быстрый и ощутимый результат.

Стратегия 2: квантование моделей — снижение затрат на инференс в 2–4 раза

Квантование (quantization) — это техника сжатия моделей, при которой вместо 16-битных или 32-битных весов используются 8-битные (INT8) или даже 4-битные (INT4) представления. Результат — драматическое снижение потребления памяти и ускорение вычислений.

Экономия памяти по уровням точности

Каждый параметр модели занимает определённое количество байт в зависимости от точности:

FP16/BF16 (16 бит) — 2 байта на параметр. Базовый уровень, без потери качества.
INT8/FP8 (8 бит) — 1 байт на параметр. Память сокращается на 50%, потеря качества — менее 1%.
INT4/NF4 (4 бита) — 0,5 байта на параметр. Память сокращается на 75%, для большинства задач потеря качества вполне приемлемая.

Что это значит на практике? Модель с 7 миллиардами параметров: FP16 требует ~14 ГБ VRAM, INT8 — ~7 ГБ, а INT4 — всего ~3,5 ГБ. То, что раньше требовало A100, теперь спокойно помещается на T4.

Основные техники квантования

GPTQ — быстрый метод пост-обучающего квантования, заточенный под GPU-инференс. Сжимает модели до 3–4 бит на вес с минимальной потерей качества. Ускорение — до 3–4,5 раза на GPU NVIDIA.

AWQ (Activation-Aware Weight Quantization) — более умный подход, учитывающий важность отдельных весов. AWQ находит ~1% ключевых каналов по статистике активаций и масштабирует их перед квантованием. На практике даёт лучшее качество, чем GPTQ при той же битности.

bitsandbytes (LLM.int8) — самый простой в использовании метод для INT8. Сохраняет выбросы (outlier weights) в полной точности, что обеспечивает надёжный результат практически без настройки. Идеален, если хотите попробовать квантование «с наскока».

Практический пример: квантование для продакшена

# Квантование модели с помощью AWQ (Python)
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "meta-llama/Llama-3-8B"
quant_path = "llama-3-8b-awq-int4"

# Загрузка модели и токенизатора
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)

# Конфигурация квантования
quant_config = {
    "zero_point": True,
    "q_group_size": 128,
    "w_bit": 4,           # INT4 квантование
    "version": "GEMM"     # Оптимизация для GPU
}

# Калибровочные данные (используйте реальные промпты!)
calib_data = [
    "Пример реального запроса к вашей модели...",
    "Ещё один типичный промпт из продакшена...",
    # Минимум 128 примеров для надёжной калибровки
]

# Запуск квантования
model.quantize(tokenizer, quant_config=quant_config, calib_data=calib_data)

# Сохранение квантованной модели
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)

# Результат:
# Размер модели: 16 ГБ -> 4 ГБ (снижение в 4 раза)
# VRAM при инференсе: 18 ГБ -> 6 ГБ
# Скорость: 28 токенов/сек -> 88 токенов/сек (на g5.xlarge)
# Качество: потеря < 1-2% на стандартных бенчмарках

Практическое правило: если INT4 даёт ускорение ≥1,6× при падении качества ≤1–2% на ваших задачах — берите INT4. Иначе — INT8 или FP8.

Стратегия 3: спот-инстансы для обучения

Если вы уже читали нашу статью о спот-инстансах, то знаете, что скидки достигают 90%. Для обучения моделей споты — просто идеальный вариант, потому что обучение можно приостановить и продолжить с того же места.

Чекпоинтинг — ключ к надёжному обучению на спотах

Главное требование — регулярное сохранение контрольных точек. Если инстанс забирают, обучение продолжается с последнего чекпоинта на новом инстансе. Без чекпоинтинга на спотах делать нечего.

# PyTorch: автоматический чекпоинтинг каждые N шагов
import torch
import signal
import sys

class SpotCheckpointer:
    def __init__(self, model, optimizer, save_dir, save_every_n_steps=500):
        self.model = model
        self.optimizer = optimizer
        self.save_dir = save_dir
        self.save_every_n_steps = save_every_n_steps
        self.global_step = 0

        # Обработка сигнала прерывания спот-инстанса
        signal.signal(signal.SIGTERM, self._handle_interruption)

    def _handle_interruption(self, signum, frame):
        print("Получен сигнал прерывания спот-инстанса!")
        self._save_checkpoint(emergency=True)
        sys.exit(0)

    def _save_checkpoint(self, emergency=False):
        prefix = "emergency" if emergency else "step"
        path = f"{self.save_dir}/{prefix}_{self.global_step}.pt"
        torch.save({
            "model_state_dict": self.model.state_dict(),
            "optimizer_state_dict": self.optimizer.state_dict(),
            "global_step": self.global_step,
        }, path)
        print(f"Чекпоинт сохранён: {path}")

    def step(self):
        self.global_step += 1
        if self.global_step % self.save_every_n_steps == 0:
            self._save_checkpoint()

    def resume(self, checkpoint_path):
        checkpoint = torch.load(checkpoint_path)
        self.model.load_state_dict(checkpoint["model_state_dict"])
        self.optimizer.load_state_dict(checkpoint["optimizer_state_dict"])
        self.global_step = checkpoint["global_step"]
        print(f"Возобновление с шага {self.global_step}")

Расчёт экономии

Допустим, обучение модели занимает 100 GPU-часов на H100:

On-demand на AWS: 100 × $3,90 = $390
Спот-инстансы на AWS (скидка ~65%): 100 × $1,37 = $137
Спот на GCP (скидка ~70%): 100 × $0,90 = $90

Да, прерывания спотов могут удлинить обучение на 10–20% (из-за повторения части эпох). Но реальная экономия всё равно составит 55–65%. При регулярном обучении моделей это десятки тысяч долларов в месяц — сумма, которую сложно игнорировать.

Стратегия 4: оптимизация инференса

Раз инференс — это 80–90% затрат на ИИ, именно здесь скрыт наибольший потенциал для экономии. Давайте разберём основные подходы.

Кэширование запросов

Многие ИИ-приложения получают повторяющиеся или очень похожие запросы. Кэширование результатов может срезать GPU-нагрузку на 20–60% — а это, по сути, бесплатная оптимизация.

# Семантическое кэширование с Redis и эмбеддингами
import redis
import numpy as np
import hashlib
from sentence_transformers import SentenceTransformer

class SemanticCache:
    def __init__(self, redis_url, similarity_threshold=0.95):
        self.redis = redis.from_url(redis_url)
        self.encoder = SentenceTransformer("all-MiniLM-L6-v2")
        self.threshold = similarity_threshold

    def _get_embedding(self, text):
        return self.encoder.encode(text)

    def _cosine_similarity(self, a, b):
        return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

    def get(self, query):
        query_emb = self._get_embedding(query)

        # Поиск похожих запросов в кэше
        for key in self.redis.scan_iter("cache:*"):
            cached = self.redis.hgetall(key)
            cached_emb = np.frombuffer(cached[b"embedding"], dtype=np.float32)

            if self._cosine_similarity(query_emb, cached_emb) >= self.threshold:
                return cached[b"response"].decode()

        return None  # Кэш-промах

    def set(self, query, response, ttl=3600):
        query_emb = self._get_embedding(query)
        key = f"cache:{hashlib.md5(query.encode()).hexdigest()}"

        self.redis.hset(key, mapping={
            "embedding": query_emb.tobytes(),
            "response": response,
            "query": query
        })
        self.redis.expire(key, ttl)

Батчинг запросов

GPU наиболее эффективны при обработке батчей. Вместо того чтобы обрабатывать каждый запрос по одному, собирайте их в группы:

# Динамический батчинг с помощью vLLM
from vllm import LLM, SamplingParams

# vLLM автоматически батчит запросы
llm = LLM(
    model="meta-llama/Llama-3-8B-Instruct-AWQ",
    quantization="awq",
    max_model_len=4096,
    gpu_memory_utilization=0.85,  # Используем 85% VRAM
    # continuous batching включён по умолчанию
)

sampling_params = SamplingParams(temperature=0.7, max_tokens=512)

# vLLM автоматически собирает входящие запросы в батчи,
# обеспечивая 2-4x ускорение по сравнению с наивным подходом
outputs = llm.generate(prompts, sampling_params)

Автоскейлинг и scale-to-zero

Если ваш ИИ-сервис не получает запросов ночью — зачем платить за GPU 24/7? Настройте автоскейлинг с возможностью масштабирования до нуля:

# AWS SageMaker: автоскейлинг эндпоинта
# Конфигурация через AWS CLI
aws application-autoscaling register-scalable-target \
  --service-namespace sagemaker \
  --resource-id endpoint/my-llm-endpoint/variant/AllTraffic \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --min-capacity 0 \
  --max-capacity 4

# Политика масштабирования по количеству запросов
aws application-autoscaling put-scaling-policy \
  --service-namespace sagemaker \
  --resource-id endpoint/my-llm-endpoint/variant/AllTraffic \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --policy-name gpu-scaling-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
    },
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

Важный нюанс: Vertex AI на GCP не поддерживает масштабирование до нуля — минимум один инстанс крутится всегда. SageMaker на AWS поддерживает scale-to-zero для асинхронных эндпоинтов. Обязательно учитывайте это при выборе платформы — при малом трафике разница в счёте может быть ощутимой.

Стратегия 5: тегирование и видимость GPU-расходов

Старая истина: вы не можете оптимизировать то, что не видите. Для ИИ-нагрузок нужна особая система тегирования, выходящая за рамки стандартных практик.

Обязательные теги для ИИ-ресурсов

Каждый GPU-ресурс должен иметь как минимум следующие теги:

team — какая команда использует ресурс (ml-platform, nlp, computer-vision)
project — конкретный проект или модель (chatbot-v3, recommendation-engine)
workload-type — training, inference, fine-tuning, experiment
environment — production, staging, development, research
model-name — имя модели (llama-3-8b, custom-bert)
cost-center — бизнес-юнит для чарджбэка
expiration-date — особенно важно для экспериментов, чтобы те не превратились в «зомби-ресурсы», тихо поедающие бюджет

Метрики стоимости для ИИ

Стандартные облачные метрики (стоимость за час, стоимость за инстанс) для ИИ недостаточны. Нужны бизнес-метрики:

Стоимость за токен — сколько обходится генерация 1000 токенов
Стоимость за инференс-запрос — средняя стоимость одного запроса к модели
Стоимость за эпоху обучения — сколько стоит один полный проход по данным
GPU-утилизация — процент реального использования GPU (ниже 50% — значит, вы переплачиваете)
Стоимость за бизнес-метрику — привязка к выручке, конверсии или другому KPI

# Terraform: обязательные теги для GPU-ресурсов
resource "aws_sagemaker_endpoint" "llm_inference" {
  endpoint_name        = "llm-inference-prod"
  endpoint_config_name = aws_sagemaker_endpoint_configuration.llm.name

  tags = {
    Team           = "ml-platform"
    Project        = "chatbot-v3"
    WorkloadType   = "inference"
    Environment    = "production"
    ModelName      = "llama-3-8b-awq"
    CostCenter     = "product-ai"
    ManagedBy      = "terraform"
  }
}

# Политика AWS: запрет создания GPU-инстансов без обязательных тегов
resource "aws_organizations_policy" "require_gpu_tags" {
  name    = "require-gpu-tags"
  content = jsonencode({
    tags = {
      Team = {
        tag_key = {
          "@@assign" = "Team"
        }
        enforced_for = {
          "@@assign" = ["sagemaker:*", "ec2:instance"]
        }
      }
      WorkloadType = {
        tag_key = {
          "@@assign" = "WorkloadType"
        }
        enforced_for = {
          "@@assign" = ["sagemaker:*", "ec2:instance"]
        }
      }
    }
  })
  type = "TAG_POLICY"
}

Стратегия 6: пулинг GPU и совместное использование

Выделять отдельные GPU каждой команде — верный путь к низкой утилизации и раздутым счетам. Гораздо разумнее создать общий пул GPU, который распределяется динамически.

Kubernetes и GPU sharing

В Kubernetes-кластерах можно настроить совместное использование GPU между подами. Выглядит это так:

# NVIDIA GPU Time-Slicing в Kubernetes
apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    sharing:
      timeSlicing:
        resources:
        - name: nvidia.com/gpu
          replicas: 4  # Один физический GPU доступен как 4 виртуальных
---
# Под, использующий часть GPU
apiVersion: v1
kind: Pod
metadata:
  name: inference-server
spec:
  containers:
  - name: model-server
    image: my-inference-server:latest
    resources:
      limits:
        nvidia.com/gpu: 1  # Получает 1/4 физического GPU

Time-slicing позволяет нескольким подам разделять один GPU, что заметно повышает утилизацию. Но имейте в виду: VRAM при этом не изолируется — каждый под потенциально может использовать всю память GPU. Если один из подов «съест» всю видеопамять, остальным не поздоровится.

Приоритизация задач

Не все ИИ-задачи одинаково важны. Настройте приоритеты:

Высокий приоритет — продакшен-инференс (ни в коем случае не прерывается)
Средний приоритет — файн-тюнинг и плановое обучение
Низкий приоритет — эксперименты и исследования (используют только свободные ресурсы)

Стратегия 7: обнаружение аномалий и предотвращение перерасхода

ИИ-нагрузки непредсказуемы по природе. Зацикленный процесс обучения, неожиданный всплеск запросов или ошибка в конфигурации — и расходы мгновенно взлетают. Я лично видел случаи, когда забытый эксперимент за выходные «съедал» пятизначную сумму в долларах.

Настройка алертов

# AWS CloudWatch: алерт на аномальные GPU-расходы
aws cloudwatch put-metric-alarm \
  --alarm-name "gpu-cost-anomaly" \
  --alarm-description "GPU расходы превышают дневной бюджет" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 86400 \
  --threshold 500 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:us-east-1:123456789012:cost-alerts"

# AWS Cost Anomaly Detection (рекомендуемый подход)
aws ce create-anomaly-monitor \
  --anomaly-monitor '{
    "MonitorName": "gpu-workload-monitor",
    "MonitorType": "DIMENSIONAL",
    "MonitorDimension": "SERVICE"
  }'

aws ce create-anomaly-subscription \
  --anomaly-subscription '{
    "SubscriptionName": "gpu-cost-alerts",
    "MonitorArnList": ["arn:aws:ce::123456789012:anomalymonitor/monitor-id"],
    "Subscribers": [
      {
        "Address": "[email protected]",
        "Type": "EMAIL"
      }
    ],
    "Threshold": 100,
    "Frequency": "DAILY"
  }'

Автоматическое отключение забытых ресурсов

Одна из самых частых (и обидных) причин перерасхода — забытые GPU-инстансы после экспериментов. Автоматизируйте их отключение:

# AWS Lambda: автоматическое отключение GPU без нагрузки
import boto3
from datetime import datetime, timedelta

def lambda_handler(event, context):
    ec2 = boto3.client("ec2")
    cloudwatch = boto3.client("cloudwatch")

    # Поиск GPU-инстансов (p5, p4, g5, g4dn)
    gpu_types = ["p5.", "p4d.", "g5.", "g4dn."]

    instances = ec2.describe_instances(
        Filters=[
            {"Name": "instance-state-name", "Values": ["running"]},
            {"Name": "tag:WorkloadType", "Values": ["experiment", "research"]}
        ]
    )

    for reservation in instances["Reservations"]:
        for instance in reservation["Instances"]:
            instance_type = instance["InstanceType"]

            if not any(instance_type.startswith(gt) for gt in gpu_types):
                continue

            # Проверяем GPU-утилизацию за последние 2 часа
            metrics = cloudwatch.get_metric_statistics(
                Namespace="CWAgent",
                MetricName="nvidia_gpu_utilization",
                Dimensions=[
                    {"Name": "InstanceId", "Value": instance["InstanceId"]}
                ],
                StartTime=datetime.utcnow() - timedelta(hours=2),
                EndTime=datetime.utcnow(),
                Period=300,
                Statistics=["Average"]
            )

            avg_util = 0
            if metrics["Datapoints"]:
                avg_util = sum(d["Average"] for d in metrics["Datapoints"]) / len(metrics["Datapoints"])

            # Если утилизация < 5% последние 2 часа — останавливаем
            if avg_util < 5.0:
                instance_id = instance["InstanceId"]
                print(f"Остановка неактивного GPU: {instance_id} "
                      f"(тип: {instance_type}, утилизация: {avg_util:.1f}%)")
                ec2.stop_instances(InstanceIds=[instance_id])

Управляемые ML-платформы: сравнение стоимости

Если вы используете управляемые платформы (SageMaker, Vertex AI, Azure ML), важно понимать их ценовую модель. Она существенно отличается от голых GPU-инстансов, и не всегда в лучшую сторону.

Скрытые наценки

AWS SageMaker — добавляет 10–20% наценку поверх стоимости EC2. Зато предлагает SageMaker Savings Plans со скидкой до 64% и поддерживает Spot-инстансы для обучения (экономия 60–70%).
GCP Vertex AI — наценка на управление сервисом невелика, но Vertex AI не поддерживает масштабирование до нуля. Минимум один инстанс работает всегда, и при малом трафике это ощутимая переплата.
Azure ML — конкурентные цены на средний сегмент (T4 ~ $1,20/час), но H100 стоит непропорционально дорого ($6,98/час). Интересная находка: Azure Container Instances обходятся в 228 раз дешевле SageMaker Serverless для низконагруженного инференса.

Когда управляемая платформа выгоднее

Управляемые платформы оправдывают свою наценку, когда:

Команда небольшая и нет ресурсов на поддержку инфраструктуры
Нужна быстрая итерация с автоматическим масштабированием
Требуется интеграция с экосистемой провайдера (IAM, VPC, мониторинг)
Нагрузка стабильная и предсказуемая (и можно использовать Savings Plans)

А вот для высоконагруженных продакшен-систем с выделенной ML-инженерной командой часто выгоднее разворачивать инференс на голых инстансах — с помощью vLLM, Triton Inference Server или KServe.

Комплексная стратегия оптимизации: пошаговый план

Итак, вот практический план действий, который можно реализовать поэтапно. Не пытайтесь сделать всё сразу — лучше идти последовательно.

Этап 1: Видимость (неделя 1–2)

Внедрите обязательное тегирование всех GPU-ресурсов
Настройте дашборды с метриками GPU-утилизации и стоимости за токен/запрос
Определите базовую линию текущих расходов по командам, проектам и типам нагрузок

Этап 2: Quick wins (неделя 3–4)

Найдите и остановите забытые GPU-инстансы — те самые зомби-ресурсы
Переведите инференс небольших моделей с H100/A100 на T4/L4
Включите автоматическое отключение неактивных GPU для экспериментов
Настройте бюджетные алерты и обнаружение аномалий

Этап 3: Глубокая оптимизация (месяц 2)

Квантуйте продакшен-модели в INT8/INT4 с помощью AWQ или GPTQ
Внедрите семантическое кэширование для часто повторяющихся запросов
Настройте автоскейлинг GPU-эндпоинтов по реальной нагрузке
Переведите обучение на спот-инстансы с чекпоинтингом

Этап 4: Зрелая практика (месяц 3+)

Внедрите GPU пулинг и приоритизацию задач
Настройте автоматический right-sizing по историческим данным утилизации
Создайте систему чарджбэка — пусть каждая команда видит и отвечает за свои GPU-расходы
Интегрируйте стоимостные метрики в CI/CD: каждый деплой модели автоматически оценивается по стоимости инференса

FAQ

Как квантование модели влияет на качество ответов?

При квантовании в INT8 потеря качества обычно составляет менее 1% на стандартных бенчмарках — на практике это почти незаметно. INT4 даёт потерю 1–3%, что вполне приемлемо для большинства продакшен-задач (чат-боты, суммаризация, классификация). Но для задач, требующих высокой точности — математика, генерация кода — обязательно тестируйте на своих данных перед развёртыванием.

Какой облачный провайдер самый дешёвый для GPU-нагрузок в 2026 году?

GCP предлагает самые низкие on-demand цены на H100 (~$3,00/GPU-час) и конкурентоспособные L4 для инференса ($0,79/час). AWS выгоднее при использовании Inferentia 2 и Savings Plans. Azure конкурентен в среднем сегменте (T4), но дорог для H100. Для максимальной экономии стоит присмотреться к специализированным ML-провайдерам (Lambda Labs, RunPod) с ценами от $1,49/GPU-час — если, конечно, вам не критична экосистема гиперскейлера.

Можно ли использовать спот-инстансы для инференса в продакшене?

Напрямую — рискованно. Прерывание спот-инстанса означает недоступность сервиса, а это неприемлемо для продакшена. Но при правильной архитектуре это работает: используйте несколько инстансов за балансировщиком нагрузки, где базовый уровень покрыт on-demand или reserved инстансами, а пиковая нагрузка обрабатывается спотами. Если один спот забирают — трафик автоматически перераспределяется на остальные.

Как рассчитать ROI от внедрения FinOps для ИИ?

Начните с текущих GPU-расходов и средней утилизации. Типичные результаты: right-sizing даёт 30–50% экономии, квантование — 50–75%, спот-инстансы для обучения — 55–65%, кэширование — 20–60%. Консервативная общая оценка — снижение расходов на 40–60%. Для примера: один стартап сократил GPU-расходы с $800K до $380K в месяц (52%) за счёт комбинации спотов для обучения и оптимизации инференса.

С чего начать оптимизацию GPU-расходов, если бюджет уже вышел из-под контроля?

Первый шаг — получить полную видимость: протегируйте все GPU-ресурсы и настройте дашборды утилизации. Второй — найдите зомби-ресурсы (неиспользуемые GPU-инстансы) и немедленно их остановите. Третий — проверьте, можно ли заменить H100/A100 на более дешёвые GPU (T4, L4) для инференса. Эти три шага занимают 1–2 недели и обычно дают 20–30% немедленной экономии. Начните с них — дышать станет заметно легче.