Частное GPU-облако: архитектура, изоляция и операционная модель

Частное GPU-облако: архитектура, изоляция и операционная модель

Частное GPU-облако — это выделенная AI-инфраструктура с облачным предоставлением ресурсов, управлением и учётом потребления. Оно может работать в регионе провайдера, в размещённом частном кластере, в colocation-кейсе или в вашем собственном дата-центре, но вопрос покупки остаётся тем же: нужна ли вам изолированная GPU-мощность, которую ваша команда эксплуатирует как платформу, или вам нужен только надёжный доступ к моделям с контролем затрат?

Для корпоративных AI-команд ответ не должен начинаться со списка логотипов. Начните с границы нагрузки, границы данных, сетевой границы, границы планировщика и границы затрат. Частное GPU-облако стоит рассматривать, когда общие публичные GPU-пулы, serverless-эндпоинты или управляемые API моделей не могут обеспечить эти границы без неприемлемого риска, задержек, трений по комплаенсу или неопределённости в очередях.

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

Краткий ответ по частному GPU-облаку

Выбирайте частное GPU-облако, когда вам нужны зарезервированная GPU-мощность, предсказуемая топология кластера, частная сеть, строгие границы арендаторов, настраиваемые стеки обслуживания, прямой контроль над планировщиком или подтверждение для проверки безопасности. Не выбирайте частное GPU-облако только потому, что слово «private» звучит безопаснее. Изоляция имеет значение лишь тогда, когда контракт, сеть, хранилище, планировщик, IAM, наблюдаемость и процесс инцидентов все вместе сохраняют эту границу.

Сильное предложение по частному GPU-облаку должно отвечать на такие вопросы:

• Какие GPU, узлы, стойки и фабрики выделены нам?
• Изолируются ли нагрузки по физическому хосту, виртуальной машине, пространству имён Kubernetes, partition Slurm, фрагменту NVIDIA MIG или их комбинации?
• Как образы, веса моделей, промпты, результаты, журналы и метрики удерживаются внутри утверждённой границы?
• Кто отвечает за патчи, обновления драйверов, совместимость CUDA, политику планировщика, соблюдение квот, резервное копирование и реагирование на инциденты?
• Как измеряется стоимость: почасовое выделение GPU, зарезервированная мощность, принятые токены, завершённые задания, хранилище, egress, поддержка или плата за управляемый сервис?

Если поставщик не может показать эти детали, вы оцениваете не частное GPU-облако. Вы оцениваете SKU аренды GPU с корпоративными словами вокруг него.

Что может означать «private»

Фраза частное GPU-облако перегружена смыслами. Команды закупок часто сравнивают несколько разных предложений под одним и тем же ключевым словом.

Для читателей Flatkey важна последняя строка. Flatkey даёт командам один ключ, один баланс, один счёт, управление журналом использования, официальные endpoints моделей и контроль governance для API моделей и инструментов. Это не замена частному GPU-облаку, когда вам нужна изоляция зарезервированного оборудования. Это более простой путь, когда реальное требование — доступ к нескольким моделям, прозрачность затрат, failover и корпоративные средства контроля без эксплуатации GPU-инфраструктуры. Для такого сравнения используйте сопутствующее руководство по GPU cloud vs model API.

Референсная архитектура

Производственное частное GPU-облако имеет больше уровней, чем GPU-узлы. Рассматривайте его как AI-платформу с шестью плоскостями управления.

1. Плоскость ёмкости

Плоскость ёмкости определяет физическую и контрактную границу:

• Поколение и форм-фактор GPU: H100, H200, B200, GB200, L40S, A100 или другие ускорители.
• Форм-фактор узла: одновузловой inference, тренировочные узлы с 8 GPU, многовузловые pod'ы, системы масштаба стойки или формы VM у облачного провайдера.
• Фабрика: NVLink/NVSwitch внутри узлов, InfiniBand, RoCE, EFA, GPUDirect RDMA или специализированная AI-сеть провайдера.
• Модель резервирования: on-demand, committed, reserved, выделенный кластер, block capacity или hosted private cloud.
• Права на замену: что происходит при отказе GPU, NIC, диска, стойки или зоны.

Не нормализуйте предложения private GPU cloud только по почасовой цене GPU. Нормализуйте по используемой топологии. Более дешевый пул, который не может разместить восемь GPU с требуемой сетевой фабрикой, может обойтись дороже на завершенную задачу, чем более дорогой private block. Если обсуждение все еще идет на уровне тарифной сетки, сначала нормализуйте входные данные с помощью таблицы цен на аренду GPU.

2. Сетевая плоскость

Сетевая плоскость определяет, действительно ли кластер доступен и изолирован так, как ожидает ваша команда безопасности.

Минимальные вопросы к проектированию:

• Находится ли кластер в вашем VPC, VPC провайдера, private VLAN, direct-connect сегменте или управляемой учетной записи сервиса?
• Экспонируются ли control API публично, приватно или через bastion/identity proxy?
• Изолирован ли east-west трафик между GPU-узлами от других арендаторов?
• Являются ли endpoints для model-serving по умолчанию приватными?
• Могут ли учебные данные, checkpoints, контейнерные образы, веса модели и логи перемещаться без публичных интернет-путей?
• Есть ли явные egress controls, NAT policies, DNS policies и firewall rules?

Для крупного обучения и высокопроизводительного inference сетевые детали — это не только детали безопасности. Они влияют на пропускную способность, частоту повторов, время checkpoint и поведение при сбоях задач.

3. Плоскость планировщика

Плоскость планировщика определяет, кто и когда может использовать GPU.

Распространенные варианты:

• Kubernetes с device plugins, GPU Operator, node pools, namespaces, quotas, taints, tolerations и admission policies.
• Slurm с partitions, accounts, правилами quality-of-service, fair-share scheduling, preemption и job arrays.
• Управляемая control plane для inference: масштабирование endpoints, очереди, batching, autoscaling и canary deploys.
• Гибридная модель, в которой Slurm управляет обучением, а Kubernetes — обслуживанием.

Private GPU cloud без политик планировщика быстро превращается в общую таблицу. Определите правила квот, классы приоритетов, лимиты очереди, правила preemption, отключение простоя, окна резервирования и аварийный break-glass доступ до того, как мигрирует первая команда.

4. Плоскость runtime

Плоскость runtime — это место, где на практике ломается большинство заявлений о том, что "GPU доступен".

Вам нужна четкая ответственность за:

• Версии NVIDIA driver, CUDA, cuDNN, NCCL и container runtime.
• GPU Operator или аналогичные инструменты жизненного цикла.
• vLLM, SGLang, TensorRT-LLM, Triton, Ray Serve или собственные serving frameworks.
• Доступ к container registry и сканирование образов.
• Распространение весов модели и проверку контрольных сумм.
• Тюнинг ядра, huge pages, NUMA policy, настройки GPUDirect и NCCL topology tests.
• Планы отката для обновлений driver и обновлений serving framework.

Для команд inference полезное private GPU cloud должно предоставлять слой API, совместимый с OpenAI, или внутренний service contract. Иначе каждой product team придется заново разбираться с batching, streaming, совместимостью tool-calling, retry и учетом запросов. Подробности реализации рассмотрены в руководстве по развертыванию vLLM и сравнении vLLM vs SGLang.

5. Плоскость данных

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

• Наборы данных для обучения и feature stores.
• Объектное хранилище, общие файловые системы и локальный NVMe.
• Хранилище checkpoint'ов и retention snapshot'ов.
• Model registry и продвижение артефактов.
• Хранение prompt, output, telemetry и trace.
• Backup, restore и legal hold.
• Репликация между регионами или зонами.

Private GPU не делают данные автоматически приватными. Ваши меры контроля должны охватывать, где записываются входы модели, выходы модели, embeddings, логи, метрики, trace, checkpoint'ы и неудачные запросы.

6. Плоскость управления и FinOps

Private GPU cloud по-прежнему нуждается в облачных механизмах контроля:

• IAM roles и доступ с минимальными привилегиями.
• Квоты и бюджеты по командам.
• Теги или метки для распределения затрат.
• GPU-hours, выделенная память, принятые токены, завершенные задачи, время ожидания в очереди и простаивающие мощности.
• Chargeback или showback.
• Журналы аудита безопасности.
• Правила утверждения для экспонирования публичных endpoints.
• Доказательства SLA, инцидентов и эскалации поддержки.

Если вы не можете отнести затраты на GPU к командам, окружениям, проектам и принятым результатам, private GPU cloud будет выглядеть дешевле в коммерческом предложении и дороже на закрытии квартала.

Модель изоляции: просите доказательства, а не прилагательные

Изоляцию private GPU cloud следует описывать на четырех уровнях.

Физическая изоляция

Физическая изоляция означает, что хосты, стойки, pod'ы или кластеры выделены. Это наиболее надежный вариант для регулируемых рабочих нагрузок и предсказуемой производительности, но это должно быть отражено в контракте и в операционном процессе. Спросите, заменяются ли вышедшие из строя хосты на столь же выделенные хосты, могут ли инженеры поддержки получать доступ к среде и как аудитируются remote hands.

Изоляция виртуализации

Виртуальные машины могут обеспечивать сильные операционные границы, но вам нужно подтвердить размещение на хосте, режим GPU passthrough или vGPU, подключение хранилища, сетевую тенантность и события обслуживания. Для провайдеров, предлагающих резервирование емкости или выделенные хосты, уточните, как ваши GPU сопоставляются с хостами и как это размещение подтверждается во время аудитов.

Изоляция GPU-разделов

NVIDIA Multi-Instance GPU (MIG) может разделять поддерживаемые GPU на отдельные GPU-инстансы. MIG может быть полезен для плотности инференса и контроля тенантности, но это не универсальная замена полному выделению хоста или всего GPU. Уточните, какие модели GPU поддерживают MIG, какие профили разрешены, как назначаются срезы и как мониторинг различает тенанты.

Изоляция оркестрации

Пространства имен Kubernetes, сетевые политики, сервисные аккаунты, admission-контроли и квоты помогают разделять команды. Аккаунты и партиции Slurm помогают разделять batch-пользователей. Это необходимо для работы платформы, но само по себе не гарантирует физическую изоляцию. Архитектура должна точно указывать, где заканчивается изоляция оркестрации и где начинается изоляция на уровне хоста.

Операционная модель: кто что делает?

Частное GPU-облако — это не просто покупка. Это операционная модель. Перед подписанием определите зоны ответственности в таблице RACI.

Если ваша команда не может укомплектовать платформенную инженерию, операции безопасности, FinOps и поддержку приложений, частное GPU-облако может превратиться в неиспользуемый актив. В таком случае сравните его с управляемыми API для моделей, serverless-инференсом и вариантами GPU-облака, прежде чем принимать обязательства. Для многонодовой емкости в частности используйте чек-лист аренды GPU-кластера перед переговорами о частном блоке.

Категории провайдеров для сравнения

Лучшие платформы частного GPU-облака для enterprise AI обычно делятся на пять категорий:

1. GPU-блоки гиперскейлеров: AWS, Google Cloud, Azure и подобные Oracle варианты GPU VM или кластерной емкости с частной сетью, IAM, опциями резервирования емкости и корпоративными закупками.
2. Специализированные GPU-облака: CoreWeave, Lambda, Crusoe, Nebius, Voltage Park и похожие провайдеры, ориентированные на AI-емкость, высокоскоростные fabric-сети и эксплуатацию кластеров.
3. Разработческие GPU-облака и маркетплейсы: RunPod, Vast.ai, TensorDock и похожие варианты для гибкой емкости, прототипов и поиска цены.
4. Хостed private AI stack: HPE Private Cloud AI с NVIDIA и другие appliance-подобные предложения частного облака для предприятий, которым нужны интегрированные оборудование, ПО и поддержка.
5. Слой управления моделями/API: Flatkey и связанные роутеры, когда требуется официальный доступ к моделям, контроль затрат, аудитируемость и отказоустойчивость, а не владение оборудованием.

Если вы сравниваете именно сервисы Vultr private GPU cloud, разделите требование на наличие GPU VM, потребность в bare metal или dedicated-host, VPC/network isolation, committed capacity, условия поддержки и доказательства соответствия. Страница Cloud GPU провайдера может быть хорошей отправной точкой, но окончательный ответ часто находится в коммерческом предложении, архитектурной схеме и контракте поддержки.

Поля TCO, которые пропускают покупатели

Стройте модель TCO для частного GPU-облака вокруг выполненной работы, а не прайс-листа.

Используйте этот рабочий лист:

Затем сравните это с тремя альтернативами:

• Аренда публичного GPU-облака для задач с пиковыми всплесками.
• Serverless или управляемый инференс для неравномерного производственного спроса.
• Маршрутизация моделей/API для команд, которым нужны управление, официальные endpoint-ы, журналы использования и один счет без эксплуатации GPU.

Именно здесь Flatkey полезен в оценке. Если модель TCO показывает, что частное GPU-облако оправдывается главным образом доступом к нескольким моделям, консолидацией счетов, аудируемостью или контролем стоимости токенов, оцените Flatkey, прежде чем брать на себя обязательство по оборудованию. Если модель показывает, что требуется выделенное оборудование, пользовательские ядра, резидентность данных или обучение, зависящее от топологии, сохраните путь частного GPU-облака. Для финансового анализа сочетайте это с моделью TCO GPU-кластера и более широкой рамкой сравнения цен на AI API.

Приемочные тесты перед подписанием

Не принимайте слайд-презентацию за доказательство. Проводите приемочные тесты на точной топологии или на контрактно эквивалентной среде.

Тесты безопасности и изоляции

• Подтвердите доступ через приватный endpoint из вашей сети.
• Проверьте, что не требуется публичный control plane или endpoint обслуживания модели.
• Проверьте разделение IAM между администраторами платформы, командами моделей, читателями безопасности и читателями финансов.
• Подтвердите, что реестр контейнеров, объектное хранилище, хранилище чекпойнтов и журналы остаются в утвержденной границе.
• Проверьте audit events для входа, загрузки образа, отправки задания, развертывания endpoint-а, чтения секрета, исходящего трафика данных и повышения привилегий администратора.

Тесты производительности

• Запустите NCCL all-reduce и тесты топологии для многоузлового обучения.
• Прогоните репрезентативный инференс-трафик через выбранный стек обслуживания.
• Измерьте задержку p50, p95 и p99 при стабильной и всплесковой нагрузке.
• Измерьте число токенов в секунду на GPU, принятые токены на доллар и расход на неудачные запросы.
• Проверьте время загрузки модели, время записи чекпойнта, время отката и поведение при выводе узла из эксплуатации.

Операционные тесты

• Смоделируйте отказ GPU, отказ узла, отказ подключения хранилища, отказ компонента control plane и сбой развертывания сервиса модели.
• Проверьте обновление драйвера и откат в нерабочем пуле узлов.
• Подтвердите, кто реагирует в 3 часа ночи и к какой информации у них есть доступ.
• Проверьте поля экспорта использования для финансов и аудита.
• Подтвердите, что происходит, когда спрос превышает зарезервированную мощность.

Контрактные тесты

• Сопоставьте каждое архитектурное обещание с контрактным условием или документом поддержки.
• Определите даты поставки мощности, SLA на замену, уведомление о техобслуживании, удаление данных, уведомление об инцидентах и сотрудничество при аудите.
• Подтвердите, охватывает ли "private" только вычисления, или также хранилище, журналы, метрики, доступ поддержки и резервные копии.

Паттерн внутренней архитектуры

Практичное частное GPU-облако для enterprise AI часто использует такой паттерн:

1. Приватная сетевая граница с direct connect или VPN.
2. Выделенные пулы GPU-узлов, разделенные по типу нагрузки: обучение, пакетный инференс, онлайн-инференс, оценка и эксперименты.
3. Kubernetes для сервисов и Slurm для крупных пакетных задач/обучения, когда это необходимо.
4. Реестр моделей и путь продвижения артефактов от эксперимента к staging и production.
5. vLLM, SGLang, TensorRT-LLM, Triton или Ray Serve за внутренним gateway.
6. Квоты по командам, политики допуска и метки затрат.
7. Наблюдаемость для загрузки GPU, памяти, ожидания в очереди, задержки, сбойных заданий, принятых результатов и расходов.
8. Fallback к внешней модели/API через управляемый router для избытка нагрузки, неподдерживаемых моделей или сравнения стоимости.

Последний пункт — не обходной путь. Это паттерн устойчивости. Даже команды с частным GPU-облаком часто сохраняют model/API router для избыточной нагрузки, сравнения моделей, fallback к поставщику и сценариев, где покупка GPU нерациональна.

Матрица принятия решения

Чеклист закупки частного GPU-облака

Используйте этот чеклист перед составлением шорт-листа поставщиков:

• Определите нагрузки: обучение, дообучение, пакетный инференс, онлайн-инференс, оценка, эмбеддинги, генерация медиа или ноутбуки.
• Определите изоляцию: физическую, виртуальную, разделение GPU, планировщик, сеть, хранилище и доступ службы поддержки.
• Определите топологию: модель GPU, количество GPU на узел, узлов на кластер, fabric, хранилище и регион.
• Определите среду выполнения: CUDA, драйверы, NCCL, Kubernetes, Slurm, vLLM, SGLang, TensorRT-LLM, Triton, Ray и наблюдаемость.
• Определите контроль данных: веса модели, промпты, выходы, логи, трассировки, чекпойнты, резервные копии, удаление и юридический hold.
• Определите единицу затрат: GPU-час, завершенное задание, принятый результат, принятый токен, час эндпоинта, хранилище, исходящий трафик, поддержка и трудозатраты платформы.
• Определите приемочные тесты: безопасность, сеть, планировщик, производительность, отказоустойчивость, экспорт использования и реагирование на инциденты.
• Определите запасной вариант: перенаправление на публичное GPU-облако, API моделей или маршруты под управлением Flatkey.

Официальные источники для проверки

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

• Руководство NVIDIA MIG User Guide по разделению GPU и поддержке профилей: документация NVIDIA MIG.
• Документация NVIDIA GPU Operator и Kubernetes device plugin по жизненному циклу и планированию GPU в Kubernetes: GPU Operator и NVIDIA k8s-device-plugin.
• Документация Kubernetes device plugin по модели интеграции с планировщиком: Kubernetes device plugins.
• Документация AWS EC2 по GPU-инстансам и емкости: инстансы Amazon EC2 P5 и EC2 Capacity Blocks for ML.
• Документация Google Cloud по VM, оптимизированным для ускорителей, и AI Hypercomputer: машины Google Cloud, оптимизированные для ускорителей и AI Hypercomputer.
• Документация Microsoft Azure по GPU VM серии ND: Azure ND H100 v5-series.
• Страницы провайдеров по специализированным мощностям частного GPU-облака, таким как Lambda Private Cloud, CoreWeave и Vultr Cloud GPU.
• HPE Private Cloud AI для оценки интегрированного стека частного ИИ: HPE Private Cloud AI.
• FOCUS от FinOps Foundation для словаря распределения затрат и структуры отчетности: FOCUS by the FinOps Foundation.
• Страницы продукта Flatkey для альтернативы управлению моделями/API: Flatkey, Flatkey Compute и цены Flatkey.

Часто задаваемые вопросы

Что такое частное GPU-облако?

Частное GPU-облако — это выделенная или сильно изолированная GPU-инфраструктура, предоставляемая с облачной моделью развертывания, сетевой организацией, безопасностью, учетом использования и поддержкой. Оно может быть размещено у провайдера, в колокации или работать on-premises. Важен не сам адрес размещения. Важны изоляция и операционная модель.

То же ли частное cloud GPU, что и аренда GPU на bare metal?

Нет. Аренда GPU на bare metal может быть одним из строительных блоков частного GPU-облака, но частное GPU-облако также должно определять сетевую изоляцию, границы хранилища, политику планировщика, контроль доступа, наблюдаемость, распределение затрат, поддержку и реагирование на инциденты.

Когда частное GPU-облако как услуга лучше, чем API моделей?

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

Как командам enterprise AI сравнивать ведущие платформы частного GPU-облака?

Сравнивайте по соответствию нагрузке, доказательствам изоляции, топологии, владению планировщиком, границе данных, наблюдаемости, модели поддержки, экспорту затрат и результатам приемочных тестов. Не ранжируйте ведущие платформы частного GPU-облака для enterprise AI только по почасовой цене GPU.

Что я должен спросить о сервисах частного GPU-облака Vultr?

Спросите, соответствует ли ваше требование Cloud GPU VMs, bare metal, VPC/частной сети, зарезервированной емкости, времени реакции поддержки, доказательствам соответствия, границе хранения и операциям обслуживания моделей. Также попросите доступ к бенчмаркам, прежде чем считать предложение частным GPU-облаком.

Какую роль играет Flatkey, если у нас уже есть частное GPU-облако?

Flatkey может находиться рядом с частным GPU-облаком как управляемый маршрут к моделям/API для внешних моделей, избыточной нагрузки, резервного варианта, сравнения стоимости и команд, которым не нужен контроль на уровне оборудования. Он дает один ключ, один баланс, один счет и контроль журнала использования для официальных API моделей и инструментов.

Итог

Частное GPU-облако — это обязательство по платформе, а не способ ускорить закупку. Это правильный ответ, когда командам enterprise AI нужны выделенная емкость, контроль топологии, частные пути данных и операционные доказательства. Это неправильный ответ, когда реальная потребность — просто более легкий доступ ко многим моделям, более аккуратный счет и лучшее управление затратами на API.

Сначала используйте чек-лист архитектуры частного GPU-облака. Затем проведите бенчмарк именно той топологии. Затем сравните TCO с арендой GPU, управляемым инференсом и маршрутами к моделям/API под управлением Flatkey. Лучшее решение — то, которое дает вашим AI-командам именно ту границу, которая им действительно нужна, не заставляя их управлять инфраструктурой, которая им не нужна. Если выбор оборудования все еще не определен, начните с best GPU for LLM inference прежде чем запрашивать у поставщиков частное предложение.