Зачем строить свой GPU-as-a-Service, когда есть облака?
Потому что аренда H100 на полгода стоит как покупка четырех RTX PRO 6000 Blackwell. Потому что compliance в финтехе и медицине не терпит чужих дата-центров. Потому что когда 20 ML-инженеров одновременно хотят потестить Llama 3.3 405B, бюджет на облачные GPU превращается в черную дыру.
В 2026 году on-prem GPU инфраструктура - это не про экономию. Это про контроль. Контроль над стоимостью, над данными, над производительностью. Cisco UCS C845A с новыми Blackwell GPU и Single Node OpenShift - это рецепт для тех, кому надоело платить за непредсказуемые cloud bills.
Внимание: Эта архитектура не для стартапов из трех человек. Это для компаний, где уже есть команда DevOps и бюджет на железо от 50k$. Если вы только начинаете - посмотрите сначала сравнение аренды и покупки GPU.
Железная правда: что нужно купить
Сначала цифры. Один Cisco UCS C845A стоит около 25-30k$ в базовой конфигурации. Добавляем 4x NVIDIA RTX PRO 6000 Blackwell по 8-10k$ каждая. Плюс 1TB RAM, быстрые NVMe диски, сетевые карты 100GbE. Итог: 70-80k$ за систему, которая заменит вам ежемесячные счета на 10-15k$ от AWS/GCP.
| Компонент | Модель | Зачем нужен |
|---|---|---|
| Сервер | Cisco UCS C845A | 8 GPU слотов, управление через UCS Manager, редиантные вентиляторы |
| GPU | NVIDIA RTX PRO 6000 Blackwell (48GB) | Новая архитектура на 4nm, NVLink 4.0, 192GB/s пропускная |
| Память | 1TB DDR5 5600MHz | Для больших датасетов и кэширования моделей |
| Сеть | Mellanox ConnectX-7 100GbE | RDMA для GPU direct, ускорение распределенного обучения |
Почему именно Blackwell? Потому что в 2026 году Hopper уже устарел для новых моделей. Архитектура Blackwell с чипами на 4nm дает на 30% лучше энергоэффективность при той же производительности. И да, RTX PRO 6000 - это workstation карта, но у нее есть NVLink 4.0 и 48GB памяти. Для inference и fine-tuning средних моделей - идеально.
Почему Single Node OpenShift, а не чистый Kubernetes?
Потому что никто не хочет администрировать etcd, ingress-контроллеры и cert-manager вручную. OpenShift 4.16 (актуальная версия на февраль 2026) дает готовую платформу с:
- Встроенным registry для Docker образов
- Автоматическим TLS через Let's Encrypt
- GUI для не-DevOps пользователей
- Built-in monitoring с Prometheus и Grafana
- OperatorHub с готовыми операторами для всего
Single Node - потому что у нас один физический сервер. Но OpenShift SNO (Single Node OpenShift) поддерживает все фичи полноценного кластера. И да, это бесплатно до 16 ядер в Community Edition.
Шаг за шагом: от железа до работающей платформы
1 Подготовка железа и установка ОС
Сначала нужно вырвать из Cisco UCS всю телеметрию и предустановленный софт. Ставим чистый Ubuntu 24.04 LTS (или Rocky Linux 9.4 если нужен RHEL-совместимый дистрибутив).
# Устанавливаем драйверы NVIDIA для Blackwell
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-drivers-560 cuda-toolkit-12-6
# Проверяем GPU
nvidia-smi
# Должны увидеть 4x RTX PRO 6000 с архитектурой Blackwell
Важно: Не используйте драйверы из репозитория Ubuntu! Берите только с официального сайта NVIDIA. Для Blackwell нужны драйверы версии 560+ и CUDA 12.6+.
2 Установка Single Node OpenShift 4.16
Тут есть хитрость: OpenShift по умолчанию не дружит с NVIDIA GPU. Нужно специальное ISO для SNO с поддержкой GPU.
# Скачиваем инструменты openshift-install
wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable-4.16/openshift-install-linux.tar.gz
tar xvf openshift-install-linux.tar.gz
# Создаем конфиг для SNO
cat > install-config.yaml << EOF
apiVersion: v1
baseDomain: yourdomain.local
compute:
- hyperthreading: Enabled
name: worker
replicas: 0
controlPlane:
hyperthreading: Enabled
name: master
replicas: 1
metadata:
name: gpu-cluster
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
none: {}
pullSecret: '{"auths": ...}' # ваш pull secret с cloud.redhat.com
sshKey: 'ssh-rsa ...' # ваш публичный ключ
EOF
# Генерируем манифесты
./openshift-install create manifests --dir=.
После установки добавляем оператор NVIDIA GPU:
# Создаем Namespace для NVIDIA
oc create namespace nvidia-gpu-operator
# Устанавливаем через OperatorHub
cat > nvidia-subscription.yaml << EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: gpu-operator-certified
namespace: openshift-operators
spec:
channel: "v24.6"
installPlanApproval: Automatic
name: nvidia-gpu-operator-certified
source: certified-operators
sourceNamespace: openshift-marketplace
EOF
oc apply -f nvidia-subscription.yaml
# Ждем 5-10 минут, проверяем
oc get pods -n nvidia-gpu-operator
3 Настройка GPU sharing и квот
Вот где начинается магия. У нас 4 GPU, но пользователей 20. Делим каждую GPU на 4 виртуальных устройства через MIG (Multi-Instance GPU).
# MIG конфигурация для RTX PRO 6000 Blackwell
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
name: gpu-cluster-policy
spec:
migManager:
enabled: true
mig:
strategy: mixed
devicePlugin:
config:
name: "default-config"
default: "mig-1g.12gb" # 12GB на инстанс
gfd:
enabled: true
operator:
defaultRuntime: crio
toolkit:
enabled: true
Теперь у нас 16 виртуальных GPU по 12GB каждая. Идеально для запуска моделей типа Llama 3.1 70B в 4-bit квантовании.
4 Развертывание JupyterHub для self-service
Пользователи не должны знать про kubectl. Даем им веб-интерфейс.
# Устанавливаем JupyterHub через оператор
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: jupyterhub
namespace: openshift-operators
spec:
channel: stable
name: jupyterhub-operator
source: community-operators
sourceNamespace: openshift-marketplace
# Конфиг для JupyterHub
apiVersion: jupyterhub.opendatahub.io/v1
kind: JupyterHub
metadata:
name: ml-platform
namespace: ml-users
spec:
scheduling:
userScheduler:
enabled: true
nodeSelector:
nvidia.com/gpu.present: "true"
hub:
image:
name: quay.io/opendatahub/jupyterhub:v2.0.0
singleuser:
image:
name: quay.io/opendatahub/jupyter-datascience:v2.0.0
storage:
capacity: 20Gi
extraResources:
limits:
nvidia.com/gpu: 1 # 1 виртуальная GPU на пользователя
Теперь пользователи заходят по https://jupyterhub.yourdomain.local, выбирают образ с PyTorch 2.4, TensorFlow 2.16 и получают готовый ноутбук с доступом к GPU.
Архитектура платформы: как все работает вместе
Вот что получается:
| Слой | Технологии | Задача |
|---|---|---|
| Инфраструктура | Cisco UCS C845A, Ubuntu 24.04 | Базовое железо и ОС |
| Оркестрация | OpenShift 4.16 SNO | Контейнеры, сеть, storage |
| GPU Management | NVIDIA GPU Operator, MIG | Делим GPU между пользователями |
| Self-Service | JupyterHub, Kubeflow | Интерфейс для ML-инженеров |
| Model Serving | KServe, vLLM, TGI | Продакшен инференс моделей |
Для продакшен инференса добавляем KServe как в архитектуре Nova AI. Пользователи тренируют модели в Jupyter, затем деплоят через веб-интерфейс KServe.
Типичные ошибки и как их избежать
Ошибка 1: Недостаточное охлаждение. 4x Blackwell GPU выделяют 1200W тепла. UCS C845A справляется, но только в серверной с холодным воздухом на входе. Температура выше 35°C - и GPU начнут троттлить.
Ошибка 2: Плохая сеть. Если планируете distributed training между несколькими серверами, нужна как минимум 100GbE сеть с RDMA. Иначе 80% времени GPU будут ждать данных.
Ошибка 3: Нет мониторинга. GPU могут работать на 100% 24/7 и сломаться через месяц. Ставьте DCGM Exporter и Grafana как в гайде про DGX OS.
Сколько это сэкономит?
Давайте посчитать для команды из 10 ML-инженеров:
- Облако (AWS): 10x g5.12xlarge (4x A10G) = $20/час * 24 * 30 = $14,400/месяц
- On-prem: Сервер $75,000 / 36 месяцев амортизации = $2,083/месяц
- Электричество и охлаждение: 2.5kW * 24 * 30 * $0.15 = $270/месяц
Итого: облако $14,400 vs on-prem $2,353. Разница в 6 раз. Окупаемость - 6-7 месяцев. И это без учета того, что в облаке вы платите даже когда GPU не используются, а on-prem сервер может работать 24/7.
Что делать, когда 4 GPU станет мало?
Добавляйте еще серверов и объединяйте в кластер. OpenShift SNO можно масштабировать до полноценного кластера. Или используйте гибридные связки GPU для особо больших моделей.
Главное - начать. Купите один сервер, разверните OpenShift, дайте доступ первому отделу. Через месяц, когда увидите, что они сделали на этой платформе, вопрос "зачем нам это" отпадет сам собой.
А если не готовы к покупке - есть промежуточный вариант: аренда GPU у specialized providers в 2-3 раза дешевле облаков гигантов.
Но помните: в 2026 году владеть железом - это не анахронизм. Это стратегическое преимущество. Пока ваши конкуренты считают cloud bills, вы уже деплоите третью версию модели.