
Обзор линейки GPU-серверов DigitalRazor
Подберём сервер под задачи
Ответьте на несколько вопросов — подготовим предложение
Линейка GPU-серверов DigitalRazor охватывает путь от первого локального узла для ИИ до системы с восемью картами. В этом материале разберём RackStation AI, Devbox AI и Scale, сравним собственное оборудование с внешней площадкой, подберём GPU по объёму VRAM и обозначим границу, за которой нужен HPC-сервер либо платформа HGX/DGX.
Первый сервер не обязан быть «кластером на вырост». Полезнее запустить рабочую модель, измерить скорость инференса, объём занятой видеопамяти, очередь запросов и прирост от нескольких карт. Эти данные покажут, какой ресурс понадобится ИИ-проекту дальше.
Зачем компании выделенный GPU-ресурс
Графические процессоры используют не только исследовательские группы, которые обучают нейросети с нуля. Выделенный ускоритель нужен внутренним ассистентам и RAG-системам, компьютерному зрению (CV), распознаванию документов, генерации контента, рендерингу и инженерным расчётам. В этих сценариях GPU ускоряет параллельные операции, а объём VRAM ограничивает размер модели, длину контекста и число одновременных запросов.
Локальный вычислитель даёт команде предсказуемый доступ к ИИ-инфраструктуре. Не приходится ждать свободного облачного экземпляра, каждый раз переносить датасет или подстраиваться под чужую версию драйвера. Разработчики могут зафиксировать версии CUDA, PyTorch и движка инференса, сравнить разные конфигурации vLLM или TensorRT-LLM, проверить квантизацию и измерить загрузку GPU в рабочем сервисе.
Но число ядер CUDA не отвечает на все вопросы. Рендеринг способен загрузить GPU почти полностью, а RAG-сервис — упереться в видеобуфер, KV-кэш, CPU, накопитель или подготовку данных. Поэтому первый GPU-сервер служит ещё и измерительным стендом. Базовый разбор сценариев есть в материале «Для чего нужен GPU-сервер».
Нужна помощь с выбором сервера?
Специалисты помогут подобрать оборудование под нагрузку, бюджет и задачи
Когда локальное развёртывание оправдано, а когда — нет
Свой сервер оправдан, если данные и веса модели должны оставаться внутри корпоративного контура, ИИ-нагрузка идёт регулярно, а вычислительный ресурс нужен нескольким сотрудникам без очереди у провайдера. Ещё один довод — крупные локальные датасеты: постоянная передача терабайтов увеличивает время запуска и усложняет контроль копий.
Локальная система удобна и при жёстких требованиях к среде. Команда сама фиксирует ОС, драйвер NVIDIA, CUDA, контейнеры и версии библиотек. Это снижает риск, что обновление образа изменит поведение приложения перед релизом. Собственный контур всё равно требует разграничения доступа, обновлений, резервного копирования и журналирования.
Внешняя площадка разумнее для редкой или всплесковой задачи. Например, отделу нужно раз в квартал провести обучение, проверить новую LLM на H100 или временно увеличить мощность инференса перед запуском продукта. Покупка под такой пик заморозит бюджет, а большую часть года карта будет простаивать.
Купить сервер или арендовать GPU в облаке
У покупки и почасового ресурса разная экономика. Собственный сервер требует капитальных затрат и обслуживания, зато постоянно доступен. Внешняя площадка снижает первоначальные затраты и позволяет менять класс GPU, но итоговая сумма растёт вместе с длительностью работы, объёмом диска, сетевым трафиком, резервированием и уровнем SLA.
| Параметр | Свой сервер | Аренда GPU на внешней площадке |
|---|---|---|
| Расходы | CapEx, затем эксплуатация и амортизация | Почасовая или ежемесячная оплата |
| Данные и среда | Контроль контура, ОС и библиотек | Условия задаёт провайдер; важны локация и договор |
| Доступность | Ресурс закреплён за командой | Быстрый старт, но наличие нужного GPU меняется |
| Когда рациональнее | Регулярная загрузка и стабильный профиль задач | Пилот, редкие расчёты и краткие пики |
На момент написания материала в августе 2026 года, VDSina предлагает тариф на базе NVIDIA L4 с 2 ГБ видеопамяти за 4770 рублей в месяц. IQHost указывает 7680 рублей за RTX 3060, 38 250 рублей за RTX 5090 и 188 500 рублей за H100. Аренда выделенного сервера tenzor.cloud с двумя H100 начинается от 585 000 рублей в месяц при договоре на 12 месяцев. Конфигурации различаются по CPU, RAM, накопителям, сети, резервированию и формату доступа, поэтому эти суммы нельзя сравнивать напрямую.
Точку окупаемости считают по фактическим часам загрузки. В расчёт входят оборудование, электричество, размещение, простой и перенос данных. При непрерывной работе ИИ-сервиса локальный сервер сравнивают с арендой по полной стоимости часа. Для двухнедельного теста проще взять почасовой ресурс.
Как выбрать масштаб ИИ-инфраструктуры
На старте исследований и разработки (R&D) неизвестно, какая LLM останется в продукте, сколько пользователей придёт через полгода и даст ли вторая карта пропорциональный прирост. Пилот должен ответить на конкретные вопросы:
- Сколько VRAM занимают веса, KV-кэш и рабочие буферы;
- Каковы время до первого токена и скорость генерации;
- Какой размер пакета выдерживает ИИ-сервис;
- Хватает ли CPU, системной памяти, NVMe и сети;
- Масштабируются ли инференс и обучение на нескольких GPU;
- Как система ведёт себя под длительной нагрузкой.
Ёмкость нескольких GPU не превращается в единый пул памяти сама по себе. Приложение должно поддерживать тензорный или конвейерный параллелизм либо параллелизм по данным. vLLM умеет распределять модель между несколькими GPU, но скорость зависит от обмена данными; для многоузлового режима особенно важна быстрая сеть. Чем чаще GPU ждут пересылку тензоров, тем меньше польза от дополнительной карты.
R&D-проект не всегда нужно начинать с H200, HGX или DGX. Если модель помещается в 32–96 ГБ, а несколько GPU нужны для независимых ИИ-сервисов, PCIe-система RackStation или Devbox может закрыть задачу без дорогой фабрики межсоединений. Производительность здесь оценивают вместе с объёмом VRAM, пропускной способностью памяти и режимом точности.
Переход к HPC/HGX обоснован, когда ИИ-нагрузке нужны серверные ускорители, HBM или высокая межкарточная полоса для одной большой задачи. H200 оснащён 141 ГБ HBM3e с пропускной способностью 4,8 ТБ/с; H200 NVL поддерживает двух- или четырёхкарточное соединение через NVLink. DGX B200 объединяет восемь GPU B200 через два NVSwitch с совокупной полосой 14,4 ТБ/с. Это другой класс платформы, а не Devbox с большим числом карт.
Подробнее о межсоединениях читайте в статье «NVLink от NVIDIA: что это и как работает», а о прикладном масштабировании — в материале «Multi-GPU в 2026 году».
Линейка RackStation AI, Devbox AI и Scale
Три уровня различаются не только числом GPU. Меняются процессорная платформа, объём ECC-памяти, условия размещения, энергопотребление, охлаждение и роль узла.
| Продукт | GPU и процессорная платформа | Оперативная память | Размещение и сценарий |
|---|---|---|---|
| RackStation AI | 1–2 GPU; AMD Threadripper PRO 7000 | До 1 ТБ DDR5 REG ECC | Офис, лаборатория или стойка; локальная ИИ-разработка, RAG, CV, рендеринг |
| Devbox AI | До 4 RTX 5090/H200 NVL или до 6 RTX PRO; Threadripper PRO 7000 | До 2 ТБ DDR5 ECC | Серверная или ЦОД; общий ресурс, параллельные сервисы, пакетные задачи |
| Scale | До 8 GPU; 2× AMD EPYC или Intel Xeon | До 3072 ГБ DDR5 | Серверная или ЦОД; тяжёлые конвейеры, развитый ввод-вывод, инфраструктурный узел |
RackStation AI: локальный R&D без лишнего масштаба
RackStation AI подходит команде, которой нужна одна или две карты рядом с разработчиками. Система закрывает прототипирование, локальный инференс, RAG, компьютерное зрение и графический рендеринг. Threadripper PRO даёт ресурсы для адаптеров, накопителей и периферии, а объём оперативной памяти достигает 1 ТБ DDR5 REG ECC.
В RackStation можно поставить производительную GeForce или профессиональный ускоритель с большим объёмом VRAM. В первом случае приоритетом обычно становится соотношение цены и скорости. Во втором — ECC, профессиональные драйверы, объём памяти и предсказуемая работа в корпоративной среде.
Devbox AI: общий ресурс для нескольких задач
Devbox AI поддерживает до четырёх RTX 5090 или H200 NVL и до шести профессиональных ускорителей RTX PRO/RTX 6000. Главное здесь — не шестикратное ускорение одной задачи, а одновременная работа нескольких процессов: генерация ответов, подготовка эмбеддингов, создание изображений, обучение адаптеров и пакетный рендеринг.
Здесь критичны топология PCIe, расстояние между слотами, блоки питания и система охлаждения. Шесть ускорителей нельзя выбирать отдельно от корпуса и теплового расчёта: паспортная производительность бесполезна, если карты снижают частоту под длительной нагрузкой.
Scale: до восьми GPU и развитый ввод-вывод
Scale — двухпроцессорная платформа с поддержкой до восьми GPU и до 3072 ГБ DDR5. В текущем каталоге есть конфигурации на AMD EPYC и Intel Xeon. Это инфраструктурный узел для тяжёлых конвейеров, параллельных ИИ-сервисов и высоких требований к накопителям и сети.
Восемь GPU можно направить на независимые процессы или на распределённый расчёт. Во втором случае пилот обязателен: прирост определяют программный стек, топология PCIe и обмен данными, а не количество устройств в спецификации.
HPC 4000 и HPC 8000: плотные узлы для ЦОД
HPC 4000 и HPC 8000 — стоечные системы на четыре и восемь GPU. HPC 4000 занимает 2U, HPC 8000 — 4U. Эта ветка рассчитана на серверные ускорители, высокую плотность размещения, быстрый ввод-вывод и работу в составе кластера. Она не является просто «более крупным Scale».
В каталоге есть HPC 8000 с восемью H200 NVL по 141 ГБ: 8 × 141 = 1128 ГБ. Это суммарный физический объём видеопамяти восьми GPU, а не единый автоматически доступный пул VRAM. Возможности NVLink и схема связи зависят от выбранной конфигурации.
HGX H200: восемь SXM-ускорителей с NVSwitch
HGX H200 объединяет восемь H200 SXM через NVLink и NVSwitch. У каждого ускорителя 141 ГБ HBM3e с пропускной способностью памяти 4,8 ТБ/с. Платформа нужна, когда одна большая задача распределена по всем восьми GPU и её скорость зависит от межкарточного обмена.
DGX — готовая система NVIDIA, а HGX — серверная платформа, на базе которой партнёры строят собственные решения, включая системы DigitalRazor. Поэтому DGX уместен как ориентир для сравнения, но не как модель линейки DigitalRazor.
Как выбрать GPU для сервера
Выбор начинается с объёма VRAM и точного исполнения карты. После этого сравнивают скорость, ECC, профессиональные драйверы, MIG/vGPU, энергопотребление и возможность установить нужное число ускорителей без перегрева.
| GPU | VRAM | Мощность платы | Основные сценарии |
|---|---|---|---|
| GeForce RTX 5090 | 32 ГБ GDDR7; ECC не заявлена | До 575 Вт | R&D, прототипирование, локальный инференс, генерация контента, рендеринг |
| RTX PRO 4500 Blackwell Workstation Edition | 32 ГБ GDDR7 ECC | 200 Вт | Профессиональные приложения и длительная нагрузка при умеренном энергопотреблении |
| RTX PRO 5000 Blackwell Workstation Edition | 48 или 72 ГБ GDDR7 ECC | 300 Вт | Крупные модели, длинный контекст, несколько ИИ-сервисов, инженерные задачи |
| RTX PRO 6000 Blackwell Workstation Edition | 96 ГБ GDDR7 ECC | 600 Вт | Максимальный объём модели и высокая производительность на одном GPU |
| RTX PRO 6000 Blackwell Max-Q Workstation Edition | 96 ГБ GDDR7 ECC | 300 Вт | Плотные Multi-GPU-системы с ограничением по мощности и охлаждению |
| NVIDIA H200 NVL | 141 ГБ HBM3e | До 600 Вт, настраивается | Серверный инференс и HPC; 2- или 4-way NVLink |
Характеристики указаны для конкретных референсных исполнений NVIDIA. У партнёрских GeForce RTX 5090 могут отличаться габариты, охлаждение и лимит мощности. Server Edition нужно указывать отдельной строкой: её параметры нельзя смешивать с Workstation Edition или Max-Q.
Сначала VRAM, затем производительность
VRAM обычно задаёт первую жёсткую границу для производительного запуска модели целиком на GPU. В видеопамяти размещаются веса, KV-кэш, промежуточные данные, буферы CUDA и память фреймворка. CPU-offload и распределение между CPU и GPU позволяют обойти ограничение, но часто заметно снижают скорость.
Проверка «модель запустилась» недостаточна: после увеличения контекста, размера пакета или числа пользователей памяти может не хватить. При обучении VRAM также занимают активации, градиенты и состояния оптимизатора. Реальный расход измеряют на целевой конфигурации.
ECC, MIG и vGPU решают разные задачи
ECC обнаруживает и исправляет ошибки в видеопамяти. MIG делит совместимый GPU на аппаратно изолированные экземпляры. vGPU распределяет ресурсы ускорителя между виртуальными машинами, а passthrough передаёт одной виртуальной машине устройство целиком.
RTX PRO 5000 поддерживает MIG, однако доступные размеры и количество экземпляров зависят от версии карты, выбранного профиля и программного стека. Для 72-ГБ версии NVIDIA также поддерживает MIG-backed vGPU. Совместимость vGPU проверяют по точному исполнению GPU, гипервизору, драйверу и лицензии.
Несколько GPU не образуют общую память автоматически
Две карты по 32 ГБ не превращаются в один GPU с 64 ГБ VRAM. Приложение должно разделять модель или данные между устройствами с помощью тензорного, конвейерного или параллелизма по данным. Эти схемы добавляют обмен, стоимость которого зависит от топологии PCIe, NVLink и поддержки peer-to-peer.
Независимые задачи масштабируются проще: одна карта обслуживает RAG, другая строит эмбеддинги, третья запускает компьютерное зрение, четвёртая генерирует контент. Здесь Devbox или Scale могут эффективно использовать несколько ускорителей без распределения одной модели.
Если ограничением становится межкарточный обмен одной распределённой задачи, нужно отдельно оценить топологию NVLink. Для тесного взаимодействия всех восьми GPU рассматривают HGX с NVSwitch; HPC-сервер решает прежде всего задачи плотности, серверного исполнения и кластеризации.
Подробнее о топологиях читайте в статье «NVLink от NVIDIA: что это и как работает», а о прикладном масштабировании — в материале «Multi-GPU в 2026 году».
Практический порядок выбора GPU
- Определить объём VRAM для модели, контекста, KV-кэша и целевого числа пользователей.
- Проверить инференс или обучение на реальной нагрузке.
- Решить, нужны ли ECC, профессиональные драйверы, MIG или vGPU.
- Рассчитать питание и охлаждение всей конфигурации, а не одной карты.
- Протестировать масштабирование на нескольких GPU.
- Зафиксировать точное исполнение ускорителя в итоговой спецификации.
Такой порядок защищает от двух типичных ошибок: покупки быстрого GPU, которому не хватает VRAM, и сборки дорогой Multi-GPU-системы, где дополнительные ускорители не дают ожидаемого прироста.
Выберите GPU-сервер для нейросетей
Готовые решения для работы с большими массивами данных
От GPU-системы до готовой рабочей среды
GPU-сервер — не просто набор комплектующих в корпусе. Карты, CPU, ECC-память, накопители, сеть и охлаждение должны работать как единая система. DigitalRazor публично предлагает поставку серверов с OneStack — предустановленным и протестированным программным окружением. Точный состав поставки лучше закрепить в техническом задании; таблица ниже показывает возможные уровни работ, а не официальные тарифы.
| Состав проекта | Что стоит закрепить в техническом задании |
|---|---|
| Аппаратная готовность | ОС, драйвер NVIDIA, прошивки, проверка питания, температур и стабильности |
| ИИ-среда | Контейнерная среда, NVIDIA Container Toolkit, PyTorch, vLLM, базовые библиотеки и проверочный запуск |
| Прикладная интеграция | Модель, RAG, подключения к данным, мониторинг и согласованные приёмочные тесты |
NVIDIA Container Toolkit предоставляет контейнерам доступ к GPU после установки драйвера и настройки поддерживаемой среды выполнения — Docker, containerd, CRI-O или Podman. Обновления CUDA, PyTorch и vLLM сначала проверяют на тестовом контуре.
Для общего ресурса заранее выбирают схему доступа. Проброс GPU передаёт виртуальной машине целую карту. vGPU делит поддерживаемое устройство на профили и требует совместимых GPU, гипервизора, драйвера и лицензии. В зависимости от сценария применяются продукты NVIDIA vGPU/RTX vWS либо NVIDIA AI Enterprise.
Как проходит проект
1. Сбор требований
На старте фиксируют ИИ-задачу, модель или приложение, объём данных, число пользователей, желаемое время ответа, требования к SLA и место установки. Для обучения нужны размер датасета, точность и длительность итерации. Для инференса — контекст, размер пакета, параллельность и целевая задержка.
2. Выбор архитектуры
Требования сопоставляют с VRAM, числом GPU, CPU, RAM, накопителями и сетью. На этом этапе определяется класс системы: RackStation AI, Devbox AI, Scale, HPC-сервер или проект HGX. Число ядер CUDA остаётся одним из параметров, но не заменяет расчёт всей платформы.
3. Инженерная проверка
Проверяют габариты карт, линии PCIe, мощность блоков питания, воздушный поток и условия площадки. Для стойки учитывают доступную электрическую мощность, температуру входящего воздуха, шум, глубину корпуса и сетевые подключения.
4. Пилот и тест конфигурации
На пилоте запускают рабочую нейросеть или приложение, а не абстрактный бенчмарк. Измеряют загрузку GPU, потребление VRAM, задержку, пропускную способность сервиса, температуры и масштабирование. Результаты превращают предположения в требования к серийной системе.
5. Поставка, запуск и масштабирование
После приёмочных тестов сервер интегрируют в корпоративную сеть и передают документацию. Масштабирование начинают по фактической нагрузке: добавляют узлы, диспетчер задач, хранилище или более быстрый межсерверный транспорт.
Не знаете точную конфигурацию — это нормально
Для первичной рекомендации не нужен готовый список комплектующих. Достаточно сообщить:
- Какую задачу решает ИИ;
- Название модели или используемого ПО;
- Тип и объём данных;
- Число пользователей или параллельных процессов;
- Желаемое время ответа либо длительность расчёта;
- Место установки и ограничения по шуму и охлаждению.
По этим данным можно выбрать исходный класс системы, провести пилот и не переплачивать за ресурс, который ИИ-проект пока не использует.
FAQ: ответы на частые вопросы
Заключение
RackStation AI подходит для локальной ИИ-разработки, RAG, компьютерного зрения и первого производственного сервиса на одной–двух картах. Devbox AI нужен, когда ресурс использует команда, одновременно работают несколько сервисов или растёт объём пакетных задач. Scale добавляет до восьми GPU, двухпроцессорную платформу, до 3072 ГБ DDR5 и развитый ввод-вывод для инфраструктурной нагрузки.
Дальше начинается другой класс оборудования. HPC-серия нужна, когда обязательны серверные ускорители вроде H200 NVL, более плотное стоечное размещение или кластеризация. HGX рассматривают, когда пилот подтвердил зависимость одной большой задачи от HBM и высокоскоростной межкарточной фабрики.
Сообщите специалистам DigitalRazor название LLM, тип данных, число пользователей, целевую задержку и место установки. Команда предложит исходную систему или пилот, проверит конфигурацию под нагрузкой и подготовит путь масштабирования без покупки лишнего ресурса.






























