Cost, Billing, and Ops13 октября 2026 г.Flatkey Team

Архитектура GPU-кластера: вычисления, сеть, хранилище и control plane

Практическое руководство по архитектуре GPU-кластера: вычислительные узлы, сетевой fabric, хранилище, control plane Kubernetes или Slurm, наблюдаемость и приемочные тесты.

Архитектура GPU-кластера — это устройство всей системы, а не просто количество GPU. Производственный кластер должен координировать вычислительные узлы, высокоскоростную сеть, хранилище, планировщик, контроль доступа, телеметрию и пути восстановления, прежде чем он сможет превращать дорогие ускорители в полезные обучающие запуски или надежный inference.

Практический вопрос прост: может ли ваша команда достаточно быстро перемещать данные, планировать задачи, восстанавливать сбои и измерять затраты, чтобы GPU были загружены? Если нет, кластер с более мощными картами все равно может дать худшую экономику, чем более небольшой управляемый GPU-сервис или API модели.

Это руководство дает командам AI platform рабочую модель gpu cluster architecture: что входит в вычислительный слой, что должна доказать сеть, как соотносятся хранилище и checkpointing, как Kubernetes или Slurm становится control plane, и что нужно проверить перед арендой или покупкой многонодовой мощности.

Практическое правило Flatkey — начинать с границы workload. Если продукту нужны только результаты модели, сначала сравните путь GPU cloud vs model API. Если вам нужны собственные веса, контроль размещения, длительное обучение или приватная инфраструктура для сервинга, тогда проектируйте GPU-кластер вокруг требований workload к вычислениям, сети, хранилищу и control plane.

Краткий ответ по архитектуре GPU-кластера

Полезный GPU-кластер имеет четыре плоскости:

Плоскость	Что она включает	Типичный сбой при пропуске
Вычисления	GPU-серверы, соотношение CPU/RAM, локальный NVMe, топология GPU, драйверы, CUDA, контейнеры, распределение MIG или выделение полной GPU	Команда покупает правильную модель GPU, но неправильную форму узла, раскладку памяти или стек драйверов.
Сеть	Внутриузловой NVLink/NVSwitch, межузловой InfiniBand, RoCE, EFA, Ethernet, размещение, DNS, ingress, границы service mesh	Многонодовые задачи плохо масштабируются, потому что "быстрая сеть" так и не была проверена на реальном all-reduce или трафике сервинга.
Хранилище	Подготовка наборов данных, веса моделей, запись checkpoint, общий файловый system, object storage, локальный scratch, snapshots, backup, очистка	GPU простаивают, пока загружаются данные, checkpoint блокируют обучение или восстановление после перезапуска занимает слишком много времени.
Control plane	Kubernetes, Slurm, Kueue, Volcano, Ray, доступ пользователей, квоты, observability, теги для биллинга, политика безопасности, реагирование на инциденты	Задачи выполняются, но никто не может объяснить время ожидания в очереди, справедливость распределения, сбои или стоимость за единицу.

multi-node gpu cluster architecture работает успешно, когда эти плоскости проектируются вместе. Вычисления без fabric — это изолированная мощность. Fabric без хранилища лишь переносит bottleneck. Kubernetes без квот, телеметрии и runbook — это только механизм запуска.

Схема архитектуры GPU-кластера

Используйте эту диаграмму как рамку для проверки перед сравнением провайдеров или утверждением проектирования стойки.

                  users / CI / product traffic / API clients
                                  |
                                  v
        +------------------------------------------------------+
        | control plane                                        |
        | Kubernetes or Slurm scheduler, queues, quotas,       |
        | secrets, registry access, policy, telemetry, billing |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | gpu compute node  |   | gpu compute node  |   | gpu compute node  |
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | local NVMe, NICs  |   | local NVMe, NICs  |   | local NVMe, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | high-speed fabric                                   |
        | NVLink/NVSwitch inside node; InfiniBand, RoCE, EFA, |
        | or Ethernet across nodes; placement and routing     |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | storage and data path                               |
        | object store, shared filesystem, local scratch,      |
        | model cache, checkpoints, snapshots, backups        |
        +------------------------------------------------------+

Для kubernetes gpu cluster architecture diagram добавьте вокруг control plane специфичные для Kubernetes объекты:

cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams      -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance        -> labels -> usage export -> cost per job / team / model
security       -> secrets -> image policy -> network policy -> audit logs

Диаграмма намеренно проста. Цель не в том, чтобы изобразить каждый сервис. Цель — выявить недостающие обязанности до того, как кластер станет production-зависимостью.

Начните с рабочей нагрузки, а не со стойки

Прежде чем выбирать Kubernetes, Slurm, cloud reservation или bare-metal vendor, составьте краткое описание workload на одной странице.

Поле	Что нужно определить
Тип рабочей нагрузки	Предобучение, дообучение, пакетный инференс, онлайн-инференс, эмбеддинги, поиск, генерация изображений/видео, симуляция или исследовательские ноутбуки.
Фреймворк	PyTorch, JAX, TensorFlow, vLLM, SGLang, TensorRT-LLM, Ray, Slurm, Kubernetes Jobs или пользовательские сервисы.
Целевая GPU	H100, H200, B200, A100, L40S, RTX PRO, серии AMD MI или допустимый диапазон.
Форма узла	GPU на узел, память GPU, ядра CPU, системная RAM, локальный NVMe, количество NIC и энергетический бюджет.
Форма масштабирования	Один узел, многузловое синхронное обучение, шардинг-инференс, пакетная очередь или смешанная платформа.
Сетевая чувствительность	Требуемая производительность all-reduce, допустимая задержка, требования к placement group, изоляция трафика и путь egress.
Чувствительность к хранилищу	Размер датасета, размер весов модели, частота контрольных точек, целевое время восстановления, требования к файловой системе и регион object store.
Операционная граница	Кто отвечает за драйверы, образы, политику планировщика, телеметрию, поддержку, обновления, доступ пользователей и реагирование на инциденты.
Бизнес-деноминатор	Стоимость за завершённый прогон обучения, стоимость за принятый результат инференса, утилизация GPU-часов или зарезервированный GPU-месяц.

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

Плоскость вычислений: GPU-узлы не взаимозаменяемы

Compute plane определяет, чем реально может пользоваться задача. Полная спецификация compute plane включает больше, чем просто "8x H100" или "B200 cluster".

Запросите:

Модель GPU, объём памяти и, где это важно, PCIe или SXM.
Количество GPU на узел и внутрисерверную топологию.
Модель CPU, количество CPU, системную RAM и NUMA-раскладку.
Объём локального NVMe и ожидаемую пропускную способность.
Количество NIC, скорость NIC и поддержку путей GPU-direct.
Жизненный цикл драйвера, CUDA, runtime контейнеров и образа ОС.
Политику MIG, vGPU, time-slicing или выделения полной GPU.
Гомогенность узлов и политику замены.

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

Документация NVIDIA по Kubernetes GPU Operator полезна здесь, потому что показывает, как драйверы, NVIDIA Container Toolkit, device plugin, телеметрия DCGM и связанные компоненты могут управляться как стек кластера, а не как разовая настройка узла. Документация Kubernetes device plugin объясняет общий extension point, который используется для экспонирования устройств вендора как ресурсов, доступных планировщику.

Сетевая плоскость: проверьте фабрику бенчмарком

Многузловое обучение и высокопроизводительный serving зависят от сети. Спецификация кластера должна указывать fabric и acceptance test, а не только заявленную полосу пропускания.

Запросите:

Детали внутрисерверного NVLink или NVSwitch.
Межузловую архитектуру InfiniBand, RoCE, EFA или Ethernet.
Количество NIC и их скорость на узел.
Гарантию размещения и домен отказа.
Коэффициент oversubscription.
Поддержку GPUDirect RDMA, где это уместно.
Модель сетей контейнеров и хоста.
Наблюдаемость ошибок fabric, retransmit, congestion и отказов узлов.

Используйте acceptance test до начала обязательств:

network acceptance test:
  run NCCL all_reduce across every rented node
  record bandwidth, latency, node IDs, GPU model, driver, CUDA, NCCL version
  repeat after installing the production container image
  save logs and compare them with the provider's quoted topology

NVIDIA NCCL и NCCL tests — стандартные ориентиры для проверки поведения collective communication в распределённых GPU-нагрузках. Суть не в том, чтобы гнаться за одним числом бенчмарка. Суть в том, чтобы обнаружить несоответствующие узлы, плохое размещение, congestion fabric или дрейф драйвера/контейнера до того, как сорвётся полный прогон обучения.

Для инференса сетевой тест должен включать реальный путь трафика: входящий запрос, коммуникацию шардов модели, поведение KV-cache, если это применимо, выборки из хранилища и исходящий трафик. Fabric для обучения, который выглядит сильным в изоляции, всё равно может давать плохую пользовательскую задержку, если serving-стек пересекает слишком много сетевых границ.

Плоскость хранения: уберите данные, веса и контрольные точки из критического пути

Хранилище — это место, где многие планы архитектуры GPU-кластера становятся дорогими. Квота на GPU видна. Путь данных часто скрыт до первого production-прогона.

Проектируйте хранилище вокруг четырёх потоков:

Поток	Архитектурный вопрос
Подготовка датасета	Сколько времени нужно, чтобы переместить датасет из object storage, удалённой файловой системы или хранилища данных на узлы?
Веса модели	Где кэшируются базовые веса, дообученные веса, файлы токенизатора и артефакты engine?
Контрольные точки	Как часто записываются checkpoint'ы, каков их размер и сколько времени занимает восстановление после отказа узла?
Выходные данные и логи	Куда попадают сгенерированные артефакты, метрики, трассировки и audit-логи, и какая политика хранения применяется?

Для обучения пропускная способность checkpoint'ов и время восстановления — это вопросы архитектуры, а не детали резервного копирования. Для инференса время загрузки весов модели, прогрев локального кэша и поведение persistent volume влияют на время развёртывания и время failover.

Документация NVIDIA по GPUDirect Storage — полезный источник, когда архитектура требует прямого пути данных между локальным или удалённым хранилищем и памятью GPU. Не каждому кластеру нужен GPUDirect Storage, но командам, которые перемещают большие наборы данных или checkpoint'ы, следует явно решить, является ли стек хранилища обычным, оптимизированным или же это приемлемое для них узкое место.

Control plane: Kubernetes, Slurm, или оба?

Control plane превращает оборудование в платформу. Он определяет, кто и что может запускать, когда стартуют задачи, как повторяются сбои и как команды понимают использование ресурсов.

Архитектура Kubernetes GPU-кластера

Kubernetes подходит для GPU-платформ, которым нужны развёртывание сервисов, multi-tenant namespaces, контейнерные рабочие процессы, автоматизация через API, политики и интеграция с cloud-native observability. Производственная kubernetes gpu cluster architecture обычно включает:

Образы узлов и автоматизацию bootstrap.
Управление GPU Operator или vendor-specific драйверами/плагинами устройств.
Device plugin или Dynamic Resource Allocation для предоставления GPU.
Namespaces, RBAC, secrets, policy извлечения образов и network policy.
Jobs, Deployments, RayJob, training operators или inference services.
Kueue или другой уровень очередей, когда важна справедливость batch-обработки.
Квоты по команде, проекту, среде или клиенту.
DCGM, Prometheus, логи, трассировки и billing labels.
Admission controls для образов, privileged workloads, host mounts и GPU sharing.

Kubernetes device plugins предоставляют GPU как extended resources. Kubernetes Dynamic Resource Allocation добавляет более богатую модель ресурсов на основе claims для устройств и других специализированных ресурсов. Kueue добавляет концепции очередей заданий, такие как workloads, queues, cohorts и resource flavors, для batch- и AI/ML-планирования. Вместе эти инструменты могут превратить пул GPU в управляемую платформу, а не просто в набор машин с доступом по SSH.

Архитектура Slurm GPU-кластера

Slurm хорошо подходит многим HPC- и research-средам, потому что построен вокруг очередей, partitions, accounting, reservations и batch jobs. Документация Slurm по GRES описывает GPU-ресурсы и то, как задачи запрашивают их.

Slurm часто является сильным выбором, когда:

Пользователи отправляют batch training jobs.
Политика очередей является центральной.
У команд уже есть опыт HPC-эксплуатации.
Нагрузка менее ориентирована на сервисы.
MPI, NCCL-тесты и batch accounting — знакомые операционные примитивы.

Некоторые организации используют оба варианта: Slurm — для исследований и больших очередей обучения, Kubernetes — для inference services и platform APIs. Это может работать, но только если идентификация, доступ к данным, observability и распределение затрат спроектированы для обеих систем.

Наблюдаемость и контроль затрат должны быть в первом проекте

Не добавляйте telemetry после того, как кластер уже запущен. Вопросы, важные для engineering и finance, предсказуемы:

Какие задачи использовали какие GPU?
Какой namespace, команда, клиент, модель или эксперимент вызвал расходы?
Какой была полезная загрузка, а не только выделенное GPU-время?
Сколько времени было потрачено в ожидании в очереди?
Какие сбои «сожгли» больше всего GPU-hours?
Какое узкое место в хранилище или сети привело к простоям GPU?
Какова была стоимость одного завершённого запуска или принятого результата?

Минимальная telemetry должна включать:

Загрузку GPU, использование памяти, энергопотребление, температуру и события ECC.
Время выполнения по задаче, время ожидания в очереди, число повторов, причину завершения и владельца.
Состояние network fabric и историю бенчмарков.
Пропускную способность хранилища, задержку, время checkpoint и время восстановления.
События назначения планировщика и отказ по квотам.
Billing labels или exports использования, привязанные к бизнес-единицам.

Базовая модель/API Flatkey здесь важна. Если управляемый model API выдаёт тот же принятый результат с более понятной стоимостью за единицу и меньшей операционной нагрузкой, кластер должен превзойти этот базовый уровень после учёта простоя, повторов, хранилища и труда.

Безопасность, изоляция и проектирование доступа

GPU-кластеры часто начинаются как инженерные проекты и превращаются в общую инфраструктуру. Рассматривайте проектирование доступа как часть архитектуры.

Определите:

Аутентификацию и источник идентичности.
Изоляцию по namespace, проекту или учётной записи.
Политику SSH, если она вообще есть.
Container image registry, signing и scanning.
Управление secrets.
Network egress policy.
Удаление данных и очистку после завершения задач.
Хранение audit log.
Break-glass access.
Доступ поддержки вендора и workflow удалённого hands.

Для multi-tenant кластеров решите, разрешён ли GPU sharing. Выделение целого GPU проще. MIG, vGPU или time-slicing могут повысить утилизацию, но они также меняют изоляцию, telemetry, планирование и ожидания по производительности.

Размер кластера: переведите архитектуру в числа

Размер должен определяться полезной единицей:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Затем проверьте это на прочность:

Вопрос для расчёта размера	Почему это важно
Какая утилизация действительно полезна, а не просто выделена?	Простаивающие резервы и неудачные запуски не помогают выпуску продукта.
Какое максимальное время ожидания в очереди допустимо?	Дешёвый кластер всё равно может не уложиться в окно запуска или обучения.
Что происходит, если один узел выходит из строя в середине выполнения?	Время перезапуска меняет фактическую пропускную способность.
Можно ли перенести модель на другой класс GPU?	Обязательства по оборудованию могут пережить архитектуру модели.
Каков срок поставки при расширении?	Спрос на GPU может расти быстрее, чем закупки.
Каков путь выхода?	При принятии решения нужно учитывать перепродажу, расторжение контракта, очистку данных и стоимость миграции.

Для модели затрат свяжите эту статью с вашим рабочим листом TCO GPU-кластера:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

Знаменатель должен соответствовать продукту: завершённым обучающим запускам, принятым токенам инференса, сгенерированным медиа-задачам, обновлениям поискового индекса или запросам клиентов.

Контрольный список проверки архитектуры

Используйте этот список перед утверждением схемы архитектуры multi node gpu cluster или предложения провайдера.

Область	Условие прохождения
Краткое описание нагрузки	Команда определила модель, фреймворк, масштаб, путь данных, целевую утилизацию и бизнес-знаменатель.
Вычисления	Конфигурация узла включает топологию GPU, CPU/RAM, локальный NVMe, NIC, жизненный цикл драйвера/CUDA и политику замены.
Сеть	Тип fabric, размещение, oversubscription, домены отказа и бенчмарк NCCL или serving задокументированы.
Хранилище	Проверены staging датасета, кэш весов, запись/восстановление checkpoint, объектное хранилище, snapshots и очистка.
Планировщик	Для Kubernetes, Slurm или смешанной архитектуры чётко определены владельцы очередей, квот, повторов и доступа пользователей.
Наблюдаемость	Задания, GPU, fabric, хранилище и затраты видны по командам и нагрузкам.
Безопасность	Определены идентификация, secrets, image policy, network policy, audit logs и очистка данных.
Приёмочное тестирование	Провайдер или внутренняя команда могут запустить production container, протестировать сеть, записать и восстановить checkpoints и экспортировать логи.
Экономика на единицу	Кластер сравнивается с облачной арендой, colocation, on-premises и базовыми моделями/API с использованием одного и того же знаменателя.

Официальные ссылки, которые стоит держать под рукой

Используйте официальную документацию как источники для проверки во время ревью архитектуры:

Источник	Для чего использовать
Kubernetes device plugins	Как специализированное оборудование, такое как GPU, предоставляется для планирования в Kubernetes.
Kubernetes Dynamic Resource Allocation	Модель выделения на основе заявок для специализированных ресурсов.
NVIDIA GPU Operator	Управление драйвером, контейнерным runtime, device plugin, MIG и телеметрией GPU для Kubernetes.
NVIDIA NCCL documentation и NCCL tests	Распределённая коммуникация и практическая проверка all-reduce.
NVIDIA GPUDirect Storage	Соображения по пути данных от хранилища к GPU для больших данных и потоков checkpoint.
Kueue concepts	Концепции очередей, встроенные в Kubernetes, для batch и AI/ML workloads.
Slurm GRES	GPU-ресурсы, учёт и запросы заданий в Slurm.

Рассматривайте их как архитектурные справочные материалы, а не как замену приёмочному тестированию именно на том кластере, на котором вы будете работать.

Когда GPU-кластер — неверная архитектура

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

Продукту нужны только выходные данные модели.
Состав моделей меняется каждую неделю.
Команда не может эксплуатировать драйверы, планировщики, хранилище, сеть и инциденты.
Нагрузка носит всплесковый характер и имеет низкую утилизацию.
Перемещение данных доминирует над вычислениями.
Закупки хотят трёхлетнее обязательство до появления бенчмарк-данных.
Финансы не могут сопоставить расходы на кластер с принятыми результатами.

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

Итог

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

Для небольших экспериментов начните с аренды или управляемых API. Для серьёзного многоузлового обучения или частного inference используйте диаграмму и чек-лист выше, прежде чем принимать решение о провайдере, стойке или резервировании. Дорогая ошибка — не выбор Kubernetes вместо Slurm или H100 вместо H200. Дорогая ошибка — купить GPU-мощность до того, как архитектура докажет, что способна превращать эту мощность в полезную работу.