GPU-as-a-Service on-prem: Cisco UCS с OpenShift для ML платформы 2026 | AiManual
AiManual Logo Ai / Manual.
21 Фев 2026 Гайд

GPU-as-a-Service на своем железе: строим корпоративную ML-платформу на Cisco UCS и OpenShift

Пошаговый гайд по созданию внутренней GPU-as-a-Service платформы на Cisco UCS C845A, NVIDIA RTX PRO 6000 Blackwell и Single Node OpenShift. Self-service инфраст

Зачем строить свой 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 средних моделей - идеально.

💡
Совет: Не пытайтесь экономить на оперативке. Когда 4 пользователя одновременно запускают Jupyter с загруженными в память моделями по 10-20GB каждая, 256GB RAM закончатся за 5 минут. Берите 1TB минимум.

Почему 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 квантовании.

💡
Производительность: MIG дает изоляцию, но не дает полную производительность физической карты. Для production inference лучше выделять целые GPU. Для разработки и тестирования - MIG идеален.

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.

Бонус: С этой платформой вы можете предложить внутренний GPU-as-a-Service другим отделам. Юридический отдел хочет запускать LLM для анализа контрактов? Дайте им доступ к JupyterHub с квотой 2 GPU. Зарабатывайте внутренние деньги.

Что делать, когда 4 GPU станет мало?

Добавляйте еще серверов и объединяйте в кластер. OpenShift SNO можно масштабировать до полноценного кластера. Или используйте гибридные связки GPU для особо больших моделей.

Главное - начать. Купите один сервер, разверните OpenShift, дайте доступ первому отделу. Через месяц, когда увидите, что они сделали на этой платформе, вопрос "зачем нам это" отпадет сам собой.

А если не готовы к покупке - есть промежуточный вариант: аренда GPU у specialized providers в 2-3 раза дешевле облаков гигантов.

Но помните: в 2026 году владеть железом - это не анахронизм. Это стратегическое преимущество. Пока ваши конкуренты считают cloud bills, вы уже деплоите третью версию модели.