9.2.1 · блок 9
FinOps для GPU
FinOps для GPU
Зачем это нужно
GPU — дорогой и дефицитный ресурс: простаивающая карта стоит денег, а невыданный job тормозит команду. FinOps помогает согласовать скорость экспериментов, надёжность serving и прозрачную стоимость.
Основные идеи
GPU Operator устанавливает и обслуживает драйверы, device plugin и связанные компоненты Kubernetes. Он не решает за команду, кому и на сколько выдать GPU.
MIG делит совместимую NVIDIA GPU на аппаратно изолированные профили; time-slicing даёт нескольким workload доступ к устройству по времени. MIG предсказуемее для совместимых карт, time-slicing не гарантирует такую же изоляцию памяти и производительности.
Spot/preemptible instances дешевле, но могут исчезнуть. Они подходят для checkpointable training и batch, но рискованны для stateful online serving без fallback.
KEDA масштабирует workload от событий, например глубины очереди. Autoscaling не создаёт GPU мгновенно: учитывайте время node provisioning и загрузки модели.
Стоимость считают по GPU-hours, utilisation, очереди, времени до результата и цене на successful training run — не только по счёту облака.
Как это выглядит на практике
Batch-очередь использует spot GPU и checkpoint каждые 15 минут. Инференс держит минимальный on-demand pool; KEDA увеличивает consumers при росте очереди, а лимит на tokens/job защищает бюджет.
Еженедельный отчёт: 40% GPU-hours — idle из-за чрезмерных requests. Команда снижает requests для небольших job и вводит очереди, вместо покупки новых GPU.
Что сделать после занятия
- [ ] Разделите свои workload на serving, batch и interactive notebooks.
- [ ] Для каждого укажите допустимость spot/preemptible GPU.
- [ ] Выберите две метрики стоимости и одну метрику полезной загрузки.