Фабрика ИИ на Kubernetes: пул GPU, изоляция и учёт затрат¶
7.0/10
Контекст¶
Автор рассматривает «фабрику ИИ» не как модель или кластер, а как общий пул GPU, из которого одновременно берут ресурсы разные команды: дообучение, инференс, оценка. Главная проблема — не обучить модель, а дать каждой команде безопасный изолированный доступ к дорогому оборудованию, не снижая утилизацию.
Суть¶
Узкое место — утилизация, а не скорость инференса. Классическая модель device plugin закрепляет целый GPU даже при десятипроцентном использовании; DRA даёт более богатую модель запроса устройств, но дробление обеспечивают реализации уровня устройств, например HAMi, а MIG изолирует память и сбои в железе, хотя как граница между враждебными арендаторами она спорна. Поэтому автор разделяет выделение целых GPU для изоляции арендаторов и партиционирование для плотности внутри одного домена доверия. Изоляция состоит из двух половин: control plane через tenant-кластеры (vCluster) с собственным API и RBAC, и data plane через сетевую изоляцию, квоты и аппаратные границы (DPU). Поверх этого собираются слои: provisioning (Metal3/Ironic), планировщики (Kueue, Volcano, KAI Scheduler), инференс (vLLM, KServe), Slurm через Slinky, KubeVirt, сеть (Cilium, SR-IOV, RDMA), observability (Prometheus, OpenTelemetry, DCGM), self-service и chargeback (OpenCost, GPU-seconds). Автор подчёркивает выбор «собрать самому или взять интегрированный стек вендора» и что продакшен требует conformance и масштаба на сотни узлов, а также topology-aware планирования.
Вывод¶
Вывод автора: фабрика ИИ — это операционная модель, а не очередная платформа; сложность не в отдельных инструментах, а в том, чтобы плотность, изоляция и chargeback работали вместе, с аппаратными границами там, где требует модель доверия, и без сокрытия GPU-пути за абстракцией.