Когда компании пора строить свой LLM/GPU-кластер, а не платить за API

Внешний API удобен, пока LLM остаётся экспериментом: не нужно покупать оборудование, строить серверный контур и заранее угадывать будущую нагрузку. Но после выхода модели в рабочий процесс меняется сама экономика. Появляются постоянный поток запросов, внутренние данные, требования к задержке, контролю доступа и предсказуемой доступности сервиса.

Это ещё не означает, что компании немедленно нужен кластер. Часто разумный путь выглядит так: API или аренда GPU в облаке, затем пилот на локальной станции, один сервер с несколькими ускорителями и только после измерений — несколько узлов. Собственный LLM-кластер имеет смысл там, где один узел уже ограничивает производительность, отказоустойчивость или масштаб распределённого обучения.

В статье разберём признаки такого перехода, методику TCO и состав кластера. Отдельно покажем, когда достаточно одного сервера, как считать сеть и хранилище, чем отличаются Kubernetes, Slurm и Ray и почему новый Rubin не делает Blackwell автоматически устаревшим.

Что происходит, когда LLM выходит за рамки эксперимента

От пилота на внешнем API к операционному процессу

На пилоте главная цель — быстро проверить гипотезу. Команда подключает model API, делает прототип RAG, измеряет качество ответов и выясняет, нужен ли продукт бизнесу. В этот момент оплата за токены обычно удобнее покупки железа: если эксперимент закроют через месяц, сервер останется невостребованным активом.

После запуска в продакшен появляются другие вопросы. Сколько запросов приходит в рабочий час? Как растёт очередь утром? Какая задержка считается приемлемой? Сколько контекста у типового запроса? Есть ли персональные данные или коммерческая тайна? Как быстро восстановить сервис после отказа? Если эти параметры уже можно измерить, инфраструктура для ИИ перестаёт быть абстрактной и её можно проектировать по фактической нагрузке.

Полезно разделить три модели потребления вычислений:

• Model API. Провайдер управляет моделью и железом, а компания платит за токены, запросы или другой измеримый объём использования.
• Аренда GPU в облаке. Компания получает виртуальные машины или выделенные ускорители и сама отвечает за модель, окружение, масштабирование и значительную часть эксплуатации.
• Собственное оборудование. Серверы принадлежат компании и находятся в своём ЦОД, серверной или на площадке colocation.

Три сигнала, что модель «внешний API» начинает мешать

Первый сигнал — нагрузка стала регулярной. Когда сервис круглосуточно обслуживает сотрудников или клиентов, компания уже платит не за удобство короткого пилота, а за постоянный вычислительный поток. Здесь появляется смысл сравнивать стоимость токена или часа с локальным TCO.

Второй — данные и политика доступа становятся сложнее самого API. RAG начинает работать с внутренними договорами, технической документацией, базами клиентов, исходным кодом. Даже если внешний сервис формально допускает такой сценарий, компании приходится отдельно оценивать договор, место обработки данных, сроки хранения и доступ поставщика.

Третий — нужен собственный SLA. Для рабочего ассистента среднее время ответа мало что говорит. Важнее время до первого токена, скорость генерации, число параллельных запросов и p95/p99. Если пики очереди регулярно ухудшают пользовательский опыт, компании нужен управляемый ресурс, а не только высокий лимит запросов в тарифе.

Когда достаточно одного GPU-сервера, а когда уже нужен кластер

Один сервер с четырьмя или восемью GPU — это мощный multi-GPU узел, но сам по себе не кластер. MIG может помочь разделить поддерживаемый ускоритель между изолированными нагрузками, не превращая один сервер в кластер. Если модель помещается в VRAM одной GPU или корректно распределяется между ускорителями внутри одного узла, а нужная параллельность достигается без выхода в межузловую сеть, добавление второго сервера может создать больше инфраструктурной работы, чем пользы.

Кластер начинается там, где несколько узлов решают общую задачу или образуют общий пул. Он нужен, когда модель или обучение выходят за пределы одного сервера, требуется резервирование или сервис должен горизонтально переживать пики.

Мы уже рассказывали, для чего нужен сервер с GPU и какие задачи рационально оставлять на одном узле. Для оценки кластера это полезная отправная точка: сначала нужно доказать, что один сервер действительно стал узким местом.

Для пилота, локального инференса, RAG или дообучения адаптеров полноценный кластер часто избыточен. Начать можно с одной мощной системы, измерить загрузку GPU, расход VRAM и задержки, а затем масштабировать инфраструктуру по фактической нагрузке.

Devbox AI

Для каких задач Универсальная платформа на 4–6 GPU для локального обучения моделей и генеративных задач. Подходит для команд, которым важна надёжность сервера и свобода выбора графики — от RTX 5090 до PRO RTX 6000.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 576 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 6.5U

Scale

Для каких задач Сервер промышленного уровня на 8 GPU с кластерной архитектурой. Предназначен для дата-центров и AI-ферм, где требуется масштабируемость и полная загрузка ресурсов под обучение LLM и R&D.

Подробнее

Видеокарты

RTX PRO 6000 / RTX 5090

Объем видеопамяти до 768 ГБ

Процессоры

AMD Epyc, Intel Xeon

Количество ядер до 320

RAM до 3072 ГБ DDR5

Форм-фактор 6U

HPC 8000

Для каких задач Серия серверов для кластеризации на 8 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 4U

Признаки, что пора переходить от API к своему кластеру

Расходы на токены и запросы — экономический порог

Универсальной цифры вроде «после 500 млн токенов выгодно своё железо» нет. Один и тот же объём токенов в API может стоить по-разному из-за соотношения входных и выходных токенов, кэширования, выбранной модели и тарифа. Для локального запуска на стоимость дополнительно влияют загрузка ускорителей, размер пакета и требования к задержке.

Практический расчёт начинается с текущего профиля за несколько недель. Нужны объёмы входных и выходных токенов, запросы в секунду в среднем и на пике, средняя длина контекста, целевой TTFT и доля времени, когда сервис простаивает. После этого сравнивают фактический счёт API с месячным TCO локальной конфигурации.

Затем TCO делят не на теоретическую производительность GPU, а на реально обработанный полезный объём. Поэтому утилизация GPU критична. Если дорогие ускорители большую часть суток стоят без работы, API или облачная аренда могут сохранять преимущество. При устойчивой очереди и высокой загрузке ситуация меняется.

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

Объём и характер данных — что нельзя выносить наружу

Нет универсального перечня корпоративных данных, которые «запрещено отправлять в любой внешний API». Реальное решение зависит от категории информации, правовых оснований обработки, договора с поставщиком, географии обработки, внутренних политик безопасности и конкретной схемы передачи.

Поводом оценить локально развёрнутую LLM становятся персональные данные, коммерческая тайна, документы под NDA, исходный код и клиентские базы. Локальный контур уменьшает число внешних участников обработки и упрощает контроль доступа, но сам по себе не обеспечивает соответствие закону.

Если данные чувствительные, перед проектированием нужно ответить на четыре вопроса:

1. Какие категории данных реально попадут в промпты, RAG-хранилище, логи и обучающие выборки.
2. Где физически и юридически происходит их хранение и обработка.
3. Кто имеет доступ к исходным данным, эмбеддингам, логам и резервным копиям.
4. Какие требования задают договоры, NDA, отраслевые нормы и внутренняя политика компании.

Требования безопасности и регуляторики (152-ФЗ, 187-ФЗ КИИ, коммерческая тайна)

152-ФЗ требует рассматривать не только сам вызов модели, но и весь поток персональных данных. Для персональных данных граждан РФ важны правила сбора и локализации, а трансграничная передача имеет отдельный порядок. Поэтому архитектуру API оценивают вместе с базами данных, RAG, журналами, резервными копиями и внешними обработчиками.

С 187-ФЗ КИИ другая логика. Требования закона не распространяются автоматически на любую компанию, которая установила LLM. Сначала нужно определить, относится ли организация к субъектам критической информационной инфраструктуры и может ли конкретная система быть объектом КИИ. В 2026 году действуют и типовые отраслевые перечни объектов, поэтому юридическую оценку лучше проводить применительно к конкретной отрасли и системе.

Для защищённого контура с коммерческой тайной и данными под NDA на практике также используют разграничение доступа, журналирование, управление секретами, резервное копирование и защиту администраторских учётных записей. Локальный контур помогает реализовать политику, но не заменяет её.

Латентность и предсказуемость — когда критичен свой SLA

Средняя задержка API может выглядеть хорошо и всё равно не проходить SLA. Чат-ассистенту важен быстрый первый токен, пакетной обработке — общую скорость обработки, а голосовой интерфейс чувствителен к скачкам p99.

Свой сервер для LLM даёт возможность контролировать очередь, версию движка и политику приоритетов. Но локальное размещение не гарантирует меньшую задержку. Если модель едва помещается в память, постоянно выгружает слои на CPU или обслуживает слишком много пользователей, собственная система окажется медленнее облака.

Для SLA стоит измерять:

• Time to first token при обычной и пиковой нагрузке.
• Скорость генерации на одного пользователя и суммарный throughput.
• Одновременное число активных запросов и длину очереди.
• Показатели p50, p95 и p99, а не только среднее время ответа.
• Поведение после отказа узла, обновления модели или заполнения KV-кэша.

Если свой сервер для ИИ стабильно выполняет эти цели с запасом, масштабирование можно отложить. Если очередь растёт даже после оптимизации, появляется техническое основание для второго узла.

Постоянство нагрузки — миф «аренда всегда дешевле»

Аренда выигрывает там, где ресурс нужен на несколько часов или непредсказуемо меняется. Собственное оборудование получает шанс на лучшую экономику при длительной загрузке и понятном горизонте эксплуатации. Но сравнивать нужно одинаковый уровень сервиса: одинаковую модель, доступность, резервирование, объём хранения и сеть.

Проблема часто скрыта в простое. Если восемь арендованных GPU оплачиваются месяц, а работают только ночью, компания всё равно платит за простаивающий ресурс. Если же нагрузка возникает раз в квартал на несколько дней, покупка оборудования обычно проигрывает аренде.

Cloud vs colocation vs собственный GPU-кластер: как считать TCO

Colocation — не противоположность своему кластеру. В этом сценарии серверы принадлежат компании, но находятся в коммерческом ЦОД. Поэтому корректнее сравнивать три модели владения и размещения: API/облако, свои серверы на размещении в коммерческом ЦОД и на собственной площадке.

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

Что почти всегда забывают в расчёте TCO

Самая заметная строка бюджета — ускорители, поэтому вокруг них легко построить неправильный расчёт. Полный TCO длиннее.

В него входят:

• Амортизация серверов, сетевого оборудования и СХД.
• Электроэнергия и отвод тепла, включая жидкостное охлаждение там, где оно требуется платформе.
• Colocation, стойко-места, кроссировки и сетевые подключения, если оборудование стоит во внешнем ЦОД.
• Резервные узлы, запасные компоненты и сервисные контракты.
• Лицензии, мониторинг, резервное копирование и корпоративные платформы.
• Работа инфраструктурных, DevOps и ML-инженеров.
• Потери из-за простоев, неудачных обновлений и недоступности ресурса.

Отдельный фактор — плотность стойки. Восемь мощных ускорителей в одном узле меняют требования к электропитанию и охлаждению. Увеличение числа GPU нельзя рассматривать как линейное добавление плат в существующий ЦОД: в какой-то момент ограничением становится не бюджет на ускорители, а киловатты на стойку и способность отвести тепло.

Гибридный сценарий: база у себя, пики — в облаке

Между «всё у провайдера» и «всё в своей серверной» есть рабочий компромисс. Базовую нагрузку можно держать на собственных серверах, а редкие пики или экспериментальные модели запускать в облаке. Так локальный ресурс загружается регулярно, но компания не покупает оборудование ради нескольких экстремальных дней в году.

Гибрид усложняет эксплуатацию: нужно синхронизировать модели и контейнеры, маршрутизировать запросы и заранее определить, какие данные разрешено передавать наружу. Если нагрузку нельзя вынести в облако, запас мощности приходится строить локально.

Из чего состоит GPU-кластер для LLM

GPU-кластер для ИИ — это не набор серверов, соединённых любым Ethernet. Производительность определяется всей цепочкой: GPU, локальной связью между ускорителями, scale-out сетью, хранилищем, CPU/RAM, программным стеком и планировщиком. Слабое звено может оставить дорогие GPU в ожидании данных.

Логическая диаграмма платформы NVIDIA DGX SuperPOD

GPU для кластеров: H200, RTX PRO 6000 Blackwell, B200/B300 и H100 — что выбрать

Выбор начинается не с поколения, а с нагрузки. Для инференса важны VRAM, пропускная способность памяти, поддерживаемые форматы и требуемая параллельность. Для распределённого обучения сильнее растёт роль межсоединения. Для нескольких независимых сервисов могут быть выгоднее PCIe-карты, которые проще разнести по задачам.

H100 в 2026 году остаётся рабочим вариантом существующей инфраструктуры и HPC-кластеров, но при новой закупке его нужно сравнивать с H200 и Blackwell по TCO задачи. B300 относится к Blackwell Ultra и даёт 288 ГБ HBM3e на GPU, что полезно для задач с длинными цепочками рассуждений и больших KV-кэшей, но не гарантирует лучшую экономику.

RTX PRO 6000 Blackwell интересна другим классом проектов. 96 ГБ GDDR7 ECC на одной PCIe-карте позволяют строить плотные узлы без SXM. В семейство входят Workstation Edition, Max-Q Workstation Edition и Server Edition с разными лимитами мощности и системами охлаждения, поэтому спецификацию нужно фиксировать до закупки.

Мы подробнее разбирали, как выбрать сервер для ИИ в 2026 году и на какие параметры GPU смотреть помимо числа CUDA-ядер. Для кластера к этим критериям добавляются межузловая сеть, масштабирование конкретного фреймворка и стоимость простоя всего пула.

NVLink/NVSwitch и InfiniBand/RoCE — как GPU объединяют в узлы и узлы в кластер

У межсоединений два разных масштаба. NVLink обеспечивает высокоскоростный GPU-to-GPU обмен, а NVSwitch строит коммутируемую NVLink-фабрику в системах, где многим GPU нужен тесный обмен. Это scale-up: расширение вычислительного домена внутри узла или специализированной rack-scale платформы.

Scale-out начинается между отдельными серверами. Здесь применяют InfiniBand или Ethernet с RDMA, в том числе RoCE. Выбор зависит от оборудования, требований к задержке, пропускной способности, RDMA-стека, опыта команды и архитектуры ЦОД. Кластер не обязан использовать InfiniBand только потому, что в нём стоят NVIDIA GPU.

Мы отдельно разбирали NVLink, NVSwitch и их отличие от PCIe. Для LLM ключевой вопрос простой: сколько данных задача гоняет между GPU и остаётся ли этот обмен внутри сервера или выходит в сеть между узлами.

Для независимых inference-реплик сложная NVLink-топология может быть не нужна: балансировщик отправляет запросы на отдельные GPU или узлы. Для tensor parallel и распределённого обучения обмен часто попадает в критический путь, поэтому сеть становится частью вычислительной системы.

Распределённое хранилище и сеть под датасеты и чекпоинты

На пилоте локального NVMe часто достаточно. Модель, векторная база и небольшой датасет помещаются в одном узле, а копирование чекпоинта занимает приемлемое время. Распределённое хранилище становится оправданным, когда несколько серверов должны параллельно читать один датасет, быстро сохранять состояния обучения или обслуживать общий пул моделей.

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

Для проектирования полезно разделить трафик:

1. Compute traffic (вычислительный трафик) между узлами во время распределённого обучения или тензорного параллелизма.
2. Storage traffic (трафик хранилища) к датасетам, весам, чекпоинтам и логам.
3. Management traffic (служебный трафик) для мониторинга, BMC, обновлений и служебных сервисов.
4. Client traffic (клиентский трафик) от приложений, которые вызывают inference API.

Необязательно физически строить четыре независимые сети, но их требования стоит считать отдельно. Иначе резервное копирование может конкурировать с обучением за тот же uplink.

Оркестрация: Kubernetes, Slurm и Ray — кто каким уровнем управляет

Эти инструменты нельзя расположить на одной оси «что лучше». Kubernetes управляет контейнеризированными нагрузками и их жизненным циклом. Slurm распределяет ресурсы Linux-кластера и планирует задания, что удобно для batch, HPC и распределённого обучения. Ray даёт программную модель распределённых задач и акторов и может запускаться поверх Kubernetes или ресурсов, выделенных Slurm.

В одной платформе инструменты могут сочетаться: online-инференс работает в Kubernetes, ночное обучение планирует Slurm, а ML-пайплайн использует Ray. Не нужно заставлять один инструмент решать все уровни задачи.

Как выглядит переход на практике: пошаговый план

Аудит нагрузки и данных

До закупки железа нужно получить факты о работающем сервисе. Если их нет, первый этап — измерения, а не спецификация сервера.

Минимальный аудит включает:

1. Зафиксировать модели, точность весов, квантизацию и максимальный контекст.
2. Измерить входные и выходные токены, RPS, параллельность, TTFT, throughput, p95 и p99.
3. Определить объём VRAM с учётом весов, KV-кэша, размера пакета и служебной памяти движка.
4. Разделить интерактивный инференс, RAG, построение эмбеддингов, LoRA/QLoRA, обучение и пакетные задачи.
5. Классифицировать данные и ограничения по их хранению и передаче.
6. Оценить допустимый простой и требования к восстановлению.

Конфигурацию первого узла лучше определять после замеров на реальной модели: объёма VRAM, загрузки GPU, задержки, параллельности и прироста от нескольких ускорителей.

Для RAG обычно критичны не только GPU. На задержку влияют поиск, reranker, векторная база и сеть между компонентами. Если половина времени ответа уходит на retrieval, удвоение числа ускорителей не даст двукратного эффекта.

Расчёт TCO и выбор конфигурации

После аудита строят несколько вариантов: сохранить API, арендовать GPU, поставить один сервер для ИИ или перейти к нескольким узлам. Для каждого сценария берут одинаковый период расчёта и одинаковые требования по SLA.

Полезно считать не только общую сумму, но и нормализованные показатели: стоимость миллиона полезных токенов, стоимость одного завершённого пакетное задание, стоимость часа доступного GPU-ресурса. Так видно, где дорогое оборудование работает постоянно, а где большую часть времени простаивает.

Если компания рассматривает сервер для LLM под LoRA или QLoRA, не нужно автоматически закладывать кластер. Для многих адаптаций достаточно одного ёмкого multi-GPU узла. Полное распределённое обучение крупной модели, напротив, быстрее упирается в сеть и масштабирование между серверами.

Пилотный узел → масштабирование кластера

Лучший пилот максимально похож на будущую рабочую нагрузку. Синтетический тест полезен для проверки железа, но не отвечает, сколько пользователей выдержит конкретная модель с вашим контекстом и движком.

Переход удобно разбить на этапы:

1. Запустить целевую модель на одной GPU и зафиксировать VRAM, TTFT, throughput и энергопотребление.
2. Добавить вторую или несколько GPU и проверить масштабирование конкретного режима parallelism.
3. Нагрузить один multi-GPU узел до целевой параллельности и посмотреть на очередь, CPU, RAM, PCIe и хранилище.
4. Добавить второй узел только после появления измеримого ограничения первого.
5. Проверить отказ узла, восстановление сервисов и работу планировщика под реальной очередью.
6. Масштабировать сеть и СХД по фактическому профилю трафика, а не по номинальному числу GPU.

На этапе инференса полезно сравнивать несколько движков и режимов batching. Мы уже тестировали TensorRT-LLM на больших языковых моделях, поэтому в пилоте стоит фиксировать не только GPU, но и версию среды выполнения: смена движка иногда даёт больший эффект, чем добавление ещё одной карты.

Готовые конфигурации GPU-серверов для кластера

Выбор оборудования удобно строить от минимального рабочего узла к более сложной инфраструктуре. Scale, HPC и HGX закрывают разные топологии, поэтому сравнивать их только по числу GPU нельзя.

Для пилота не обязательно покупать кластер «на вырост». Рабочая станция AI/HPC позволяет проверить модель и VRAM. Scale подходит как крупный PCIe-узел, HPC — для серверной плотности и кластеризации, HGX — когда одной задаче критичен быстрый обмен между восемью SXM-ускорителями через NVSwitch.

Когда пилот перерастает возможности одной рабочей станции, следующий шаг — выделенный GPU-сервер. Здесь уже можно увеличить число ускорителей, объём системной памяти, производительность хранения и пропускную способность сети.

Такой путь не даёт перепрыгнуть через измерения. Если один локальный узел выполняет SLA и имеет запас по загрузке, второй не нужен только ради слова «кластер». Попытка удержать multi-node обучение в одном большом PCIe-сервере, наоборот, может дорого стоить временем инженеров и низкой эффективностью GPU.

Для нагрузок, которые уже неэффективно помещать в независимые PCIe-ускорители, используют платформы HGX. Здесь восемь SXM-GPU работают внутри заранее спроектированной высокоскоростной топологии, а сам сервер становится узлом более крупной инфраструктуры.

HPC 4000

Для каких задач Серия серверов для кластеризации на 4 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 564 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 128

RAM до 1536 ГБ DDR5

Форм-фактор 2U

HPC 8000

Для каких задач Серия серверов для кластеризации на 8 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 4U

HGX H200

Для каких задач HGX объединяет 8 видеокарт NVIDIA H200, достигая экстремальной плотности производительности. Благодаря внутренней связности NVSwitch мгновенно интегрируется в масштабные вычислительные кластеры.

Подробнее

Видеокарты

NVIDIA H200 SXM

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 5U

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

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

Заключение

Переход от внешнего API к своему железу не должен начинаться с каталога GPU. Сначала нужны метрики: объём запросов, TTFT и p99, VRAM, профиль нагрузки, требования к данным и допустимый простой. Они показывают, нужен ли компании локальный сервер, аренда выделенных GPU или несколько узлов.

Если нагрузка укладывается в один сервер и SLA выполняется с запасом, строить кластер рано. Когда один узел ограничивает распределённое обучение, отказоустойчивость или число одновременных сервисов, LLM-кластер становится инженерно обоснованным следующим шагом. Экономический смысл при этом подтверждает TCO, а не количество токенов само по себе.

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

Свой кластер имеет смысл строить не потому, что API кажется дорогим, а когда измеренная нагрузка, требования к данным и TCO показывают преимущество собственной инфраструктуры. Начинать при этом можно с одного узла и масштабировать систему по мере роста нагрузки.

Rackstation AI

Для каких задач Компактный GPU-сервер до 2 видеокарт для начальных задач в AI и графике. Оптимален для инференса, визуализации, VFX и рендеринга в студиях и лабораториях, где важна гибкость.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 282 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 4.5U

Devbox AI

Для каких задач Универсальная платформа на 4–6 GPU для локального обучения моделей и генеративных задач. Подходит для команд, которым важна надёжность сервера и свобода выбора графики — от RTX 5090 до PRO RTX 6000.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 576 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 6.5U

Scale

Для каких задач Сервер промышленного уровня на 8 GPU с кластерной архитектурой. Предназначен для дата-центров и AI-ферм, где требуется масштабируемость и полная загрузка ресурсов под обучение LLM и R&D.

Подробнее

Видеокарты

RTX PRO 6000 / RTX 5090

Объем видеопамяти до 768 ГБ

Процессоры

AMD Epyc, Intel Xeon

Количество ядер до 320

RAM до 3072 ГБ DDR5

Форм-фактор 6U

HPC 4000

Для каких задач Серия серверов для кластеризации на 4 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 564 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 128

RAM до 1536 ГБ DDR5

Форм-фактор 2U

HPC 8000

Для каких задач Серия серверов для кластеризации на 8 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 4U

HGX H200

Для каких задач HGX объединяет 8 видеокарт NVIDIA H200, достигая экстремальной плотности производительности. Благодаря внутренней связности NVSwitch мгновенно интегрируется в масштабные вычислительные кластеры.

Подробнее

Видеокарты

NVIDIA H200 SXM

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 5U