DGX Spark стоит выбирать для локальной разработки, прототипирования и экспериментов одного специалиста; DGX Station — когда требуется намного больше памяти, тяжёлые модели или общий вычислительный ресурс для небольшой команды; стоечная DGX-система нужна, когда искусственный интеллект превращается в постоянно работающий сервис с параллельными пользователями, требованиями к доступности, отказоустойчивости, мониторингу и масштабированию. Граница между настольным ИИ и дата-центром проходит не по числу параметров модели и не по пиковым петафлопсам, а по ответственности за результат: если отказ одного устройства нарушает работу клиентов или бизнес-процесса, одной рабочей станции уже недостаточно.
В этой статье выражение DGX Server используется как общее обозначение стоечных систем NVIDIA DGX и построенной на них инфраструктуры. Это не название отдельной модели. В качестве актуального примера серверного класса рассматривается DGX B300. Характеристики приведены по состоянию на июль 2026 года.
Серверы NVIDIA DGX
5 лет гарантии
Бесплатная доставкаот 116 666 760 ₽
4 054 170 ₽/мес в лизинг
от 97 222 300 ₽
+ 19 444 460 НДС
5 лет гарантииБесплатная доставкаот 64 235 160 ₽
2 232 172 ₽/мес в лизинг
от 53 529 300 ₽
+ 10 705 860 НДС
5 лет гарантииБесплатная доставкаот 84 645 600 ₽
2 941 435 ₽/мес в лизинг
от 70 538 000 ₽
+ 14 107 600 НДС
5 лет гарантииБесплатная доставкаот 15 897 960 ₽
552 454 ₽/мес в лизинг
от 13 248 300 ₽
+ 2 649 660 НДС
Три класса систем — три способа эксплуатации
DGX Spark обычно принадлежит одному разработчику: на нём проверяют модели, собирают прототипы и оценивают будущую архитектуру. Его отказ останавливает личную работу, но не внешний сервис.
DGX Station можно использовать как мощную персональную машину или общий узел небольшой команды. Серверные функции управления позволяют вынести её в отдельное помещение, однако физически это одна система и одна точка отказа.
Стоечная DGX изначально рассчитана на дата-центр и подключение к общим сетям, хранилищам, мониторингу и планировщикам. Высокий уровень доступности появляется только при наличии нескольких узлов и инфраструктуры вокруг них.
DGX Spark, DGX Station и стоечная DGX: основные различия
| Критерий | DGX Spark | DGX Station | Стоечная DGX |
|---|---|---|---|
| Основная роль | Персональная разработка | Тяжёлая локальная работа и ресурс команды | Промышленная ИИ-платформа |
| Пользователи | Один основной специалист | Один специалист или небольшая команда | Несколько команд и сервисов |
| Типичные задачи | Прототипы, локальный запуск, экономичное дообучение | Крупные модели, длинный контекст, исследования | Инференс под нагрузкой, обучение, общие сервисы |
| Размещение | Рабочее место | Офис, лаборатория, отдельное помещение | Подготовленный дата-центр |
| Управление | Преимущественно локальное | BMC, Redfish, мониторинг GPU | Централизованное управление узлами и кластером |
| Масштабирование | Одна или две системы | До двух связанных станций | Несколько серверов и стоек |
| Отказоустойчивость | Не предусмотрена | Один домен отказа | Проектируется на уровне нескольких узлов |
| Критерий выбора | Скорость личных итераций | Вместимость модели и совместный доступ | SLA, нагрузка и рост |
Пиковую производительность этих систем нельзя напрямую переводить в количество токенов в секунду. Реальная скорость зависит от архитектуры и точности модели, длины контекста, размера пакета запросов, параллелизма и программной среды.
DGX Spark: персональная система, а не миниатюрный дата-центр
Официальный кадр DGX Spark.
Источник изображения: NVIDIA
DGX Spark построен на суперчипе GB10 Grace Blackwell с 20-ядерным процессором Arm. Система получила 128 ГБ согласованной памяти LPDDR5X, накопитель NVMe на 4 ТБ, адаптер ConnectX-7, сеть 10 Гбит/с и блок питания мощностью 240 Вт. NVIDIA заявляет до 1 петафлопса при вычислениях FP4, работу с моделями до 200 млрд параметров и дообучение моделей до 70 млрд параметров. Две системы можно связать для экспериментов с моделями до 405 млрд параметров.
Эти пределы не означают одинаковую скорость для любой модели. Возможность загрузить веса ещё не гарантирует комфортную генерацию при длинном контексте или нескольких пользователях.
Для каких задач подходит Spark
- локальная разработка приложений и ИИ-агентов;
- инференс в рамках персонального использования;
- прототипирование поиска по документам;
- эксперименты с квантованием и LoRA;
- проверка контейнеров и библиотек;
- обработка конфиденциальных данных;
- подготовка проекта к переносу в облако или дата-центр.
Spark ускоряет личные итерации, но его 128 ГБ LPDDR5X нельзя считать эквивалентом серверной HBM. Кроме весов, память расходуют кэш контекста, рабочие буферы, активации и операционная система. Поэтому модель может загрузиться, но отвечать слишком медленно при длинном контексте или нескольких пользователях.
Spark работает на Arm. Инструменты NVIDIA эту архитектуру поддерживают, однако собственные расширения и старые контейнеры могут быть собраны только для x86, что важно учитывать до миграции.
Что даёт объединение двух Spark
Две системы полезны для экспериментов с более крупными моделями и распределённым выполнением. Однако обмен идёт через внешнюю сеть, поэтому возникают задержки, зависимость от схемы параллелизма и более сложная диагностика.
Это всё ещё исследовательская конфигурация, а не прямой аналог многопроцессорного сервера. В стоечной системе ускорители соединены специализированной внутренней фабрикой, тогда как два Spark остаются самостоятельными компьютерами.
DGX Station: рабочая станция и персональное облако
DGX Station на базе GB300 Grace Blackwell Ultra получила 252 ГБ HBM3e со стороны GPU и 496 ГБ LPDDR5X со стороны процессора — всего 748 ГБ согласованной памяти. NVIDIA указывает до 20 петафлопс FP4, поддержку моделей до одного триллиона параметров, адаптер ConnectX-8 до 800 Гбит/с, семь разделов MIG, BMC, Redfish и NVIDIA Data Center GPU Manager. Общая мощность системы достигает 1600 Вт.
Число 748 ГБ тоже требует пояснения. В системе доступно единое согласованное адресное пространство, но 252 ГБ HBM3e и 496 ГБ процессорной памяти различаются по пропускной способности. Это не 748 ГБ одинаково быстрой памяти GPU.
Когда Station заметно лучше Spark
Station нужна, если модель и контекст не помещаются в 128 ГБ, дообучение требует больше рабочей памяти, обрабатываются крупные наборы данных или одной системой пользуется небольшая команда.
До семи экземпляров MIG позволяют разделить ускоритель между задачами: каждому выделяется часть вычислительных ресурсов, кэша и HBM. Например, один специалист может запускать модель, второй — анализировать данные, а третий — проверять обновлённую программную среду.
При этом MIG не объединяет ресурсы в более крупный ускоритель. Технология предназначена для разделения одного физического GPU на изолированные части, а не для ускорения одной задачи за счёт всех независимых экземпляров.
Почему Station называют персональным облаком
Station можно установить в отдельном помещении и использовать как общий серверный узел. BMC, Redfish и DCGM дают удалённое управление и метрики, а команда получает разделение ресурсов, общий набор моделей и очередь задач.
По способу доступа это небольшой внутренний облачный ресурс. Система может работать без подключённого монитора, а пользователи — запускать вычисления удалённо.
Почему это всё ещё не дата-центр
MIG изолирует пользователей внутри одного ускорителя, но все разделы зависят от одного корпуса, системы питания и программного узла. При обновлении или аппаратной ошибке останавливаются все задачи.
Одна Station не обеспечивает автоматически:
- переключение запросов на резервный узел;
- обновление без общего простоя;
- сохранение производительности при пиковом спросе;
- отказоустойчивое общее хранилище;
- независимое масштабирование нескольких сервисов;
- резервирование моделей и состояния приложений.
DGX Station может выполнять роль сервера, но не заменяет кластер и не создаёт высокую доступность сама по себе.
Даже две связанные Station остаются двумя узлами. Чтобы использовать их для постоянно работающего приложения, потребуются внешний балансировщик, общее хранилище, синхронизация конфигурации и программная логика, способная пережить потерю одной системы.
Что меняется при переходе к стоечной DGX
Официальный фронтальный вид NVIDIA DGX B300 с установленной лицевой панелью.
Источник изображения: NVIDIA DOCS
DGX B300 показывает масштаб различия. В корпусе высотой 10U установлены восемь ускорителей Blackwell Ultra SXM с суммарными 2,1 ТБ памяти GPU. Два коммутатора NVLink обеспечивают до 14,4 ТБ/с совокупной пропускной способности между ускорителями. Для внешних соединений предусмотрены ConnectX-8 до 800 Гбит/с и DPU BlueField-3. Расчётное энергопотребление одной системы составляет около 14 кВт.
Это не просто более быстрая Station. Стоечная DGX рассчитана на:
- централизованную работу нескольких команд;
- крупное и распределённое обучение;
- полное или ресурсоёмкое дообучение;
- массовую пакетную обработку;
- обслуживание нескольких моделей;
- промышленный инференс с параллельными запросами;
- круглосуточные агенты и корпоративные ИИ-сервисы;
- подключение к общим сетям хранения и управления.
Внутри DGX B300 ускорители связаны фабрикой NVLink. Для моделей, распределённых по нескольким GPU, это принципиально отличается от обмена между отдельными настольными системами через внешнюю сеть.
Высокоскоростная связь нужна не только для обучения. Крупную модель можно разделить между несколькими ускорителями и при выполнении готовой модели. Если части модели постоянно обмениваются активациями, задержка и пропускная способность соединения напрямую влияют на итоговую скорость.
Серверный класс определяется не только GPU
Стоечная система добавляет аппаратное управление, диагностику, корпоративный мониторинг, планировщики, квоты, централизованные обновления и подключение к отдельным сетям управления, хранения и вычислений.
Однако один DGX B300 всё равно остаётся точкой отказа, если на него направлены все запросы. Восемь GPU внутри одного корпуса повышают производительность, но не защищают приложение от отключения сервера, сбоя операционной системы или простоя при обслуживании.
Один DGX-сервер ещё не является дата-центром
За пределами корпуса серверу нужны питание, охлаждение, сеть, хранилище и система эксплуатации. Именно эта окружающая инфраструктура превращает вычислительный узел в промышленную платформу.
Для DGX B300 NVIDIA описывает стойку с двумя системами, потребляющую около 30 кВт в среднем и до 39,4 кВт на пике. Плотная конфигурация с четырьмя системами требует около 58 кВт в среднем и до 76 кВт на пике. Документация также рассматривает трёхфазное питание, резервирование, нагрузку на пол, сервисные проходы, кабельную инфраструктуру, контроль утечек и охлаждение.
В проект добавляются резервирование питания и охлаждения, управляющая и вычислительная сети, общее хранилище, реестр моделей, планировщик GPU, балансировщики, централизованные метрики и журналы, управление доступом, резервное копирование и автоматизированное развёртывание.
Для альтернативной инфраструктуры необязательно ограничиваться готовой DGX. Компании могут рассматривать универсальные серверы Dell PowerEdge 17-го поколения, где конфигурация ускорителей, процессоров, накопителей и сети подбирается под задачу.
В системах с GPU формата PCIe также востребованы серверы на AMD EPYC благодаря большому числу линий PCIe и серверы на Intel Xeon, если инфраструктура уже стандартизирована на этой платформе.
Готовая DGX упрощает совместимость компонентов и программного стека. OEM-сервер даёт больше свободы при подборе конфигурации. В обоих случаях отказоустойчивость создаётся архитектурой из нескольких узлов, а не маркой оборудования.
Серверы NVIDIA DGX
5 лет гарантииБесплатная доставкаот 116 666 760 ₽
4 054 170 ₽/мес в лизинг
от 97 222 300 ₽
+ 19 444 460 НДС
5 лет гарантииБесплатная доставкаот 64 235 160 ₽
2 232 172 ₽/мес в лизинг
от 53 529 300 ₽
+ 10 705 860 НДС
5 лет гарантииБесплатная доставкаот 84 645 600 ₽
2 941 435 ₽/мес в лизинг
от 70 538 000 ₽
+ 14 107 600 НДС
5 лет гарантииБесплатная доставкаот 15 897 960 ₽
552 454 ₽/мес в лизинг
от 13 248 300 ₽
+ 2 649 660 НДС
DGX System, BasePOD и SuperPOD — не одно и то же
Отдельная DGX System — вычислительный узел. DGX BasePOD — референсная архитектура для объединения нескольких систем с сетью, хранением и управлением.
DGX SuperPOD — масштабируемая платформа дата-центра, в которой вычислительные узлы, InfiniBand и Ethernet, управляющие серверы, программное обеспечение и хранилища проектируются как единое целое. В документации NVIDIA SuperPOD описывается именно как сочетание DGX-систем, сетевых фабрик, управляющих узлов и хранения, а не как набор стоек только с GPU.
После первого сервера объектом проектирования становится уже не отдельная машина. Нужно рассчитывать пути данных, число сетевых портов, пропускную способность хранилища, резервирование управляющих сервисов и поведение приложений при потере узла.
При этом SuperPOD нужен далеко не каждому проекту. Между одной рабочей станцией и крупным комплексом существует множество промежуточных вариантов: несколько GPU-серверов, небольшой кластер, аренда оборудования в дата-центре или сочетание локальных ресурсов с облачными.
Конечно, хочется обойтись минимально-необходимыми вложениями, например Station c BMC по сути является сервером и в ряде случае этого решения достаточно. Но не всегда.
Где Station перестаёт быть достаточной
| Изменение в проекте | Ограничение одной Station | Что добавляет серверная инфраструктура |
|---|---|---|
| Моделью постоянно пользуются клиенты | Простой одного узла останавливает сервис | Несколько экземпляров и балансировка |
| Растёт число параллельных запросов | Увеличиваются очередь и задержка | Горизонтальное масштабирование |
| Работают несколько команд | Пользователи конкурируют за один GPU | Пулы ресурсов, квоты и приоритеты |
| Одновременно нужны разные модели | Память и вычисления фрагментируются | Маршрутизация и независимое масштабирование |
| Обновления нельзя проводить с простоем | Станцию приходится останавливать целиком | Поэтапное обновление узлов |
| Появляются требования SLA | Один корпус остаётся точкой отказа | Резервирование и автоматическое переключение |
| Растёт объём данных и артефактов | Локальных дисков недостаточно | Общее хранилище и реестр моделей |
| Нужна постоянная наблюдаемость | Телеметрия одного узла не видит весь сервис | Единые метрики, журналы и оповещения |
Настольный ИИ заканчивается тогда, когда результат работы модели становится обязательством перед другими людьми или бизнес-системами. Небольшая модель может потребовать серверного кластера, если её круглосуточно вызывают тысячи пользователей. И наоборот, модель на сотни миллиардов параметров может оставаться исследовательской нагрузкой на Station, если с ней работает один специалист и допустим простой.
Переход обычно определяют пять изменений:
- Простой приобретает цену. Остановка системы влияет на продажи, поддержку клиентов, производство или внутренние операции.
- Нагрузка становится непредсказуемой. Один узел справляется со средним потоком, но не выдерживает пики.
- Появляются разные владельцы ресурсов. Командам нужны квоты, приоритеты и изоляция.
- Обновления нельзя проводить одновременно для всех. Трафик приходится переключать между версиями.
- Модель становится частью приложения. Нужно наблюдать весь путь запроса, а не только загрузку GPU.
Какой класс подходит для разных задач
Локальная разработка и RAG
Spark удобен для частых экспериментов с кодом, подсказками, квантованием и ограниченным индексом документов.
Station нужна, если модель, контекст или набор данных не помещаются в 128 ГБ либо ресурсом пользуется целый отдел. Для локального корпоративного поиска она может стать удобной системой промежуточного уровня.
Серверный пул появляется, когда поиск обслуживает много пользователей, учитывает разные права на документы и должен работать без общего окна простоя. В этом случае помимо модели нужно масштабировать базу векторов, получение исходных документов и прикладной интерфейс.
Дообучение
LoRA и другие экономичные методы подходят для Spark или Station при умеренном размере модели. Они изменяют сравнительно небольшую часть параметров и не требуют хранения полного набора обучаемых весов и состояний оптимизатора.
Полное дообучение требует памяти под веса, градиенты, состояния оптимизатора, активации и данные. Рабочий объём может во много раз превышать размер файла готовой модели.
При распределении задачи по нескольким GPU решающими становятся NVLink, внешняя сеть и скорость хранилища. Если ускорители простаивают в ожидании данных или синхронизации, их пиковая производительность не используется.
Инференс и ИИ-агенты
Для одного пользователя важны вместимость модели и время ответа. Промышленный сервис дополнительно требует контролировать параллельные запросы, задержку, очереди, несколько версий модели и восстановление после сбоя.
Личный агент может работать на Spark, агент отдела — на Station. Система из нескольких агентов, связанная с корпоративными приложениями, требует серверной эксплуатации: хранения состояния, разграничения прав, повторов неудачных операций и наблюдения за всем процессом.
При этом размер самой языковой модели может быть умеренным. Инфраструктуру усложняют не только вычисления, но и количество инструментов, длительность задач, сохранение истории и цена ошибочного действия.
Почему объём памяти — лишь часть расчёта
На инференсе память расходуют не только веса, но и кэш контекста, который растёт с числом диалогов и длиной истории. При дообучении добавляются активации, градиенты и состояния оптимизатора. Квантование уменьшает веса, но не устраняет остальные расходы и может влиять на качество и скорость.
Локальный NVMe удобен для активной модели, однако команде нужны общий каталог, версии, права доступа, резервные копии и быстрый перенос данных между узлами. В промышленной среде обычно разделяют рабочее хранилище, объектный архив, реестр моделей и резервные копии.
Сеть тоже состоит из нескольких контуров:
- доступ пользователей к приложению;
- управление оборудованием;
- обмен между вычислительными узлами;
- получение моделей и наборов данных;
- передача метрик и журналов.
При этом наличие ConnectX в корпусе не создаст кластерную фабрику без подходящих коммутаторов, кабелей, топологии и программного обеспечения.
Экономика: считать нужно не только цену системы
Для разработки важны время ожидания ускорителя, скорость экспериментов, хранение данных и стоимость работы специалиста. Для промышленного сервиса — стоимость запроса, загрузка GPU, задержка, резервные мощности, электричество, охлаждение, сеть, поддержка и потери при недоступности.
Spark становится плохой экономией, если несколько специалистов ежедневно ждут освобождения ресурса. Кластер невыгоден при постоянном простое. Station часто оказывается промежуточным уровнем: устраняет дефицит памяти и даёт общий доступ без полноценного проекта дата-центра.
Нужно учитывать и характер нагрузки. Интерактивная разработка обычно создаёт нерегулярные пики: специалист запускает эксперимент, оценивает результат и меняет код. Промышленный инференс может работать непрерывно, но его нагрузка зависит от времени суток и активности пользователей.
Облако удобно для редкого крупного обучения и пиков нагрузки, а постоянные предсказуемые задачи можно закрепить за собственным оборудованием. Для гибридной схемы нужны переносимые контейнеры и независимое хранение данных.
Как проект переходит от Spark к Station и серверной платформе
Персональный прототип
Разработчик проверяет модель и архитектуру приложения. Уже здесь нужны контейнеризация, воспроизводимое окружение и измерения памяти и задержки. Данные и состояние не стоит жёстко привязывать к локальному диску Spark.
Общий ресурс команды
После появления нескольких пользователей нагрузку переносят на Station или другой мощный узел. Добавляются удалённый доступ, очередь заданий, разделение GPU, общий набор моделей и эксплуатационные метрики.
На этом этапе становится понятно, насколько часто пользователи мешают друг другу, достаточна ли изоляция MIG и можно ли останавливать всю систему для обновления.
Промышленный сервис
В дата-центре приложение разворачивают на нескольких узлах, отделяют вычисления от хранения и добавляют балансировку, управление версиями и автоматическое восстановление.
Spark и Station используют процессоры Arm, а DGX B300 — Intel Xeon. Поэтому контейнеры нужно выпускать для нескольких архитектур, а двоичные расширения проверять отдельно. Единый стек NVIDIA облегчает перенос моделей, но не гарантирует совместимость всего пользовательского кода.
Измерять следует полный путь запроса: получение данных, поиск, подготовку контекста, выполнение модели и сохранение результата. Ускорение генерации не поможет, если основная задержка возникает в хранилище.
Распространённые ошибки при сравнении DGX
- Считать, что загруженная модель уже работает приемлемо. Она может помещаться в памяти, но отвечать слишком медленно или не выдерживать параллельные запросы.
- Сравнивать 128, 748 и 2100 ГБ как одинаковую память. У Spark используется LPDDR5X, у Station сочетаются HBM3e и процессорная LPDDR5X, у DGX B300 показатель относится к памяти восьми GPU.
- Приравнивать MIG к отказоустойчивости. MIG изолирует ресурсы пользователей, но все разделы прекращают работу при отказе физического узла.
- Считать две настольные системы прямым аналогом одного многопроцессорного сервера. Распределённая задача зависит от сети и несёт дополнительные задержки.
- Выбирать по пиковым FP4-показателям. Они не показывают скорость конкретной модели при нужной точности, контексте и нагрузке.
- Считать локальное размещение автоматически безопасным. Без обновлений, разграничения доступа, шифрования и журналирования локальная система тоже создаёт риски.
- Покупать сервер без расчёта окружающей инфраструктуры. Для стоечной DGX могут потребоваться модернизация питания, охлаждения, сети и хранения.
Что выбрать
DGX Spark подходит одному специалисту или небольшой исследовательской задаче, когда важны локальная работа, быстрые итерации и возможность запускать крупные модели без постоянного обращения к облаку.
DGX Station нужна, когда модели, контекст или данные уже не помещаются в Spark, а вычислительным ресурсом пользуется один эксперт либо небольшая команда. Она предоставляет серверные средства управления и разделения ресурсов, но остаётся одним узлом.
Стоечная DGX или кластер GPU-серверов становятся необходимы, когда модель превращается в сервис: появляются параллельные пользователи, SLA, несколько команд, независимое масштабирование, централизованное хранение, мониторинг и недопустимость единой точки отказа.
Дата-центр начинается не с восьмого GPU и не с определённого числа параметров. Он начинается там, где вычислительную мощность уже недостаточно просто предоставить — её нужно гарантированно, безопасно и предсказуемо обслуживать.
