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

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

Что сравниваем: сервер, аренду или облако

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

VDS — отдельная арендная модель, в которой ресурсы физического сервера распределяются между виртуальными машинами (VM). Отдельно VDS здесь не считаем: для него нужны свои параметры производительности и тарифы.

Как привести разные варианты к одинаковым условиям

Сравнивать нужно один и тот же бизнес-сервис при одинаковых требованиях. Сопоставить «16 vCPU» и «16 физических ядер» недостаточно. Например, n2-standard-16 в Google Cloud содержит 16 vCPU и 64 ГБ памяти, причём один vCPU соответствует одному аппаратному потоку. Физический 16-ядерный процессор может отличаться архитектурой, частотами, кешем, подсистемой памяти и NUMA.

Также vCPU одной виртуальной машины могут выполняться на потоках разных физических процессоров, что приводит к снижению производительности

То же относится к накопителям. Локальный NVMe и облачный диск одинакового объёма могут заметно различаться по задержке, IOPS и пропускной способности. Поэтому сначала определяют профиль реальной нагрузки, а затем подбирают сопоставимые ресурсы.

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

• производительность CPU и GPU в целевой задаче;
• объём RAM и VRAM;
• объём и класс накопителей, IOPS и задержка;
• пропускная способность сети и объём передаваемых данных;
• часы фактической нагрузки;
• лицензии и резервное копирование;
• требования к SLA, RTO и RPO;
• одинаковый уровень резервирования.

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

Что такое TCO и как его считать

TCO — совокупная стоимость владения решением за выбранный период. Для инфраструктуры это все расходы, необходимые для работы сервиса с заданной производительностью и доступностью.

Из чего состоит совокупная стоимость владения: CAPEX и OPEX

CAPEX — капитальные затраты на оборудование и первоначальное развёртывание: серверы, сетевое оборудование, ИБП и блоки распределения питания (PDU), монтаж и часть лицензий.

OPEX — регулярные расходы на эксплуатацию: электричество, площадку, каналы связи, облачные ресурсы, обслуживание, поддержку, резервное копирование и работу инженеров.

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

CAPEX и OPEX нельзя приравнивать к «серверу» и «облаку». Собственная инфраструктура создаёт и капитальные, и операционные расходы. В облаке тоже возможны разовые затраты — например, на миграцию, интеграцию, первоначальную настройку и последующий выход из сервиса.

Базовый и расширенный расчёт TCO

Для собственной инфраструктуры учитывают:

• цену покупки оборудования и внедрения;
• площадку, электричество, охлаждение и сеть;
• администрирование и техподдержку сервера;
• резервное копирование, лицензии и средства безопасности;
• ремонт и модернизацию оборудования;
• простои и потери производительности;
• расходы на вывод из эксплуатации.

Из итоговой суммы вычитают фактическую выручку от продажи оборудования.

Для облачной инфраструктуры учитывают:

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

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

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

Капитальные и операционные расходы: как устроены разные модели

У собственного оборудования основная часть CAPEX возникает при закупке. Затем добавляются OPEX: электричество, площадка, администрирование, обслуживание, ремонт и модернизация. Если сервер позже продают, фактическую выручку можно вычесть из совокупной стоимости владения.

Главный финансовый риск — недозагрузка. Компания заранее покупает определённую мощность, поэтому при снижении нагрузки вернуть часть уже вложенного CAPEX нельзя.

Размещение своего оборудования в ЦОД сохраняет затраты на покупку сервера, но заменяет собственную серверную регулярной оплатой стойки, питания, каналов и услуг площадки.

В облаке и при аренде выделенного сервера капитальные затраты ниже, зато растёт доля OPEX. Облако позволяет быстрее менять объём вычислительных ресурсов, но диски, снимки, IP-адреса и часть сервисов могут продолжать оплачиваться после выключения VM. У выделенного сервера ресурс фиксирован, поэтому масштабирование обычно занимает больше времени.

Точка окупаемости собственного сервера: расчёт на конкретном примере

В поисковых запросах часто используют выражение «точка окупаемости», хотя доход от инвестиции здесь не считается. Точнее говорить о точке равенства накопленных расходов — моменте, когда затраты двух вариантов сравниваются. Это не ROI и не окупаемость инвестиций.

Пример расчёта TCO на 3 года: свой сервер против облака

В учебной модели на 36 месяцев сравниваем собственный сервер в своей серверной и публичное облако. Размещение оборудования в ЦОД и аренду выделенного сервера отдельно не считаем.

Для облака используем Google Cloud us-central1 (Iowa), Linux и 730 часов работы в месяц. Регион выбран для воспроизводимого расчёта по публичным тарифам, а не как рекомендация для российского бизнеса. Локальный сервер задан бюджетом без конкретной модели процессора, поэтому считать его производительным аналогом n2-standard-16 нельзя. Учебный пример показывает механику расчёта расходов, а не преимущество одной архитектуры над другой.

Исходные данные локальной модели:

Электроэнергия уже входит в эксплуатационные расходы 27 000 рублей в месяц, поэтому второй раз её не прибавляем. При ИТ-нагрузке 550 Вт, PUE 1,4, тарифе 8 рублей/кВт·ч и 730 часах работы в месяц питание оборудования и связанной инфраструктуры обходится примерно в 4 500 рублей.

Из стартовых 1,5 млн рублей 1,15 млн приходится на сервер с процессором, ECC-памятью и NVMe корпоративного класса. Ещё 150 тысяч заложены на сеть, стойку и ИБП с блоками распределения питания, 150 тысяч — на внедрение и 50 тысяч — на ЗИП. Это учебная модель, а не готовая конфигурация DigitalRazor или коммерческое предложение.

Исходные данные облачной модели:

Кроме вычислений, в облачном счёте остаются хранилище, снимки и исходящий трафик. В этой модели они добавляют около 250,76 доллара в месяц. Поэтому считать облако только по стоимости виртуальной машины нельзя.

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

Расчёт номинальный: стоимость денег во времени не дисконтируем, а курс и тарифы считаем неизменными все 36 месяцев. В реальной финансовой модели для них лучше построить отдельные сценарии.

Для N2 Google автоматически применяет Sustained Use Discount (SUD) к подходящему потреблению. При полной месячной загрузке максимальный SUD составляет 20%. Committed Use Discounts (CUD) работают иначе: компания принимает обязательство по расходам или ресурсам на определённый срок и получает более низкую ставку. На потребление, уже покрытое CUD, SUD не начисляется.

В расчёте используем ставки n2-standard-16: 0,55939968 доллара/ч для Flexible CUD на год, 0,41954976 доллара/ч — на три года; 0,489456 доллара/ч для Resource CUD на год и 0,349648 доллара/ч — на три года.

В сценарии с однолетним CUD предполагаем, что обязательство продлевается ещё два раза по той же ставке. В реальном проекте условия и цена нового CUD могут измениться.

Результат за 36 месяцев:

Итог заметно зависит от способа оплаты вычислительных ресурсов. При одинаковых расходах на хранилище, трафик и администрирование переход от ставки без скидки к SUD или CUD меняет трёхлетний TCO на сотни тысяч рублей. В этом сценарии трёхлетние CUD делают облако дешевле локальной модели на горизонте 36 месяцев, а ставка без скидки — дороже.

Модельный CAPEX можно заменить реальной ценой оборудования. В каталоге GPU-серверов DigitalRazor представлены системы для ИИ и высокопроизводительных вычислений. Для многих конфигураций стоимость рассчитывается отдельно. Чтобы подставить в TCO реалистичный CAPEX, сначала нужно определить требуемую производительность и получить цену подходящей системы.

Для выбора платформы под ИИ пригодится отдельный материал о сервере для ИИ в 2026 году.

Как определить месяц, когда накопленные расходы сравняются

При постоянных ежемесячных расходах и без промежуточных апгрейдов месяц равенства можно рассчитать так:

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

В учебной модели расходы облака без скидки и локальной инфраструктуры сравниваются примерно на 26-м месяце. С SUD 20% точка равенства сдвигается на 32-й месяц, с Flexible CUD на один год — на 35-й. Для Flexible CUD на три года и обоих вариантов Resource CUD она находится за пределами 36 месяцев.

Что сильнее всего меняет TCO

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

Загрузка оборудования и оплачиваемые часы

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

Но 50% времени работы VM не означает, что весь облачный счёт уменьшится вдвое. Диски, снимки, публичные IP-адреса, некоторые лицензии и инженерные часы могут оплачиваться независимо от работы VM. Для точного расчёта нужен почасовой профиль загрузки CPU/GPU, памяти, операций ввода-вывода и сети хотя бы за 30–90 дней.

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

В учебной модели загрузка заметно меняет точку равенства. Чтобы отделить влияние времени работы VM от остальных факторов, используем ставку N2 без скидки (Default) и без SUD. Расходы на хранилище, снимки, исходящий трафик и администрирование не меняем. Это анализ чувствительности, а не прогноз реального счёта: если выполнены условия SUD, скидка снизит стоимость вычислений.

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

Цена оборудования, стоимость электроэнергии и размещения

На TCO собственной инфраструктуры особенно влияют цена оборудования, стоимость электроэнергии, размещение в ЦОД и срок эксплуатации.

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

Облачные тарифы, скидки и дополнительные услуги

CUD снижают стоимость вычислительных ресурсов, но создают обязательства на определённый срок. В рассматриваемом сценарии Resource CUD для n2-standard-16 даёт более низкую ставку, чем Flexible CUD, но хуже подходит для изменения конфигурации. Поэтому сравнивать нужно не только размер скидки, но и вероятность, что обязательство будет использоваться полностью.

Заметно влияет и сеть. В учебном примере 1 ТиБ исходящего трафика из us-central1 в Северную Америку или Европу стоит около 122,76 доллара в месяц в Premium Tier с учётом первого бесплатного 1 ГиБ. Для того же объёма Standard Tier получится около 70,04 доллара, если бесплатный месячный объём этого тарифа ещё не использован в аккаунте. Premium Tier и Standard Tier различаются маршрутизацией и условиями SLA, поэтому выбирать тариф только по цене трафика нельзя — нужно учитывать требования приложения.

Отказоустойчивость и SLA

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

Например, в SLA Google Compute Engine для Premium Tier доступность обычного одиночного экземпляра в большинстве регионов заявлена на уровне 99,9%, а для экземпляров в нескольких зонах — 99,99%. Это SLA конкретного сервиса, а не гарантия такой же доступности всего приложения.

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

Данные и юридические ограничения

Для российского бизнеса зарубежный тариф нельзя считать готовой закупочной рекомендацией. С 1 июля 2025 года при сборе персональных данных граждан РФ не допускается выполнять запись, систематизацию, накопление, хранение, уточнение и извлечение с использованием баз данных за пределами России, кроме предусмотренных законом исключений. Последующая трансграничная передача регулируется отдельно.

Это требование влияет на архитектуру и TCO. Может понадобиться российская база данных, отдельный контур, дополнительный канал связи или другой облачный провайдер. Юридическую схему нужно проверять для конкретного потока данных.

Письмо Минцифры России от 12 мая 2025 года № П25-44929 разъясняет применение нормы, но само не является нормативным правовым актом.

Когда выгоднее собственное оборудование

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

Постоянная высокая нагрузка: GPU-задачи, рендеринг, машинное обучение и ИИ

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

При расчёте важна не только стоимость видеокарт. На производительность и TCO влияют топология PCIe и прямого обмена между GPU (P2P), сеть между узлами, подсистема хранения и возможные простои оборудования.

DigitalRazor предлагает сервер Scale с поддержкой до восьми GPU и двухпроцессорной платформой на AMD EPYC 9005. Систему можно протестировать перед покупкой и проверить подбор конфигурации на реальной нагрузке. Такой тест не гарантирует меньшие совокупные расходы, но помогает точнее определить необходимое число и тип ускорителей до закупки.

Для локального инференса и других сценариев работы с моделями пригодится отдельное руководство по локальному развёртыванию ИИ на ПК и сервере.

Для персональной нагрузки инженера, 3D-художника или аналитика рабочая станция может быть рациональнее постоянно работающей облачной VM: ресурсы закреплены за сотрудником, а данные остаются локально. Для круглосуточных сервисов и кластерных задач уже нужна серверная инфраструктура.

Долгосрочные проекты с предсказуемой нагрузкой

Покупку оборудования проще обосновать для проекта сроком 3–5 лет, если нагрузка меняется медленно, а платформа допускает плановую модернизацию. Тогда проще оценить жизненный цикл оборудования и будущие OPEX.

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

Когда выгоднее облачная инфраструктура или аренда сервера

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

Сезонные и пиковые нагрузки

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

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

Стартапы, MVP и проекты без крупных вложений

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

Та же логика подходит для CI/CD, тестовых сред и пакетных расчётов: ресурсы создают под конкретную задачу и удаляют после её завершения. Если среда работает постоянно, её уже нужно считать как обычную инфраструктуру, а не как временную.

Когда подходит аренда выделенного сервера

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

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

Гибридный подход: как совместить локальную и облачную инфраструктуру

Если нагрузка состоит из постоянной базы и редких пиков, необязательно выбирать одну модель. Базовые задачи можно оставить на собственном или выделенном сервере, а пиковые нагрузки и временные среды переносить в облако. Резервные копии и среду аварийного восстановления (DR) при этом стоит размещать независимо от основной инфраструктуры, чтобы один отказ не затронул обе системы.

Для GPU-задач работает похожая схема: локальная группа ускорителей обрабатывает постоянную очередь, а облачные GPU подключаются во время пиков. Такой подход позволяет не покупать оборудование под редкую максимальную нагрузку, но усложняет эксплуатацию. В расчёт нужно добавить каналы связи, передачу и синхронизацию данных, управление идентификацией и доступом (IAM), мониторинг и обслуживание двух сред.

Скрытые расходы обеих моделей

Большинство этих затрат уже вошло в формулы TCO выше. Но в реальном расчёте часть статей легко пропустить. Расходы нужно учитывать симметрично: если для собственной инфраструктуры заложены администрирование и резервное копирование, в облачной модели эти статьи тоже не могут быть нулевыми.

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

Если простой можно оценить в деньгах:

Главная сложность — реалистично оценить вероятность и продолжительность отказов, а также их влияние на работу компании.

Скрытые расходы облака

В облачном расчёте чаще пропускают:

• исходящий и межзонный трафик;
• дополнительные IOPS и пропускную способность хранилища;
• публичные IP-адреса, NAT и балансировщики;
• хранение журналов и мониторинг;
• неиспользуемые VM и диски;
• недоиспользованные CUD;
• расходы на выход из облака.

IaaS снимает с компании обслуживание физического оборудования, но не управление гостевой ОС, приложениями, IAM, резервным копированием и конфигурацией. Поэтому обслуживание и поддержка не исчезают — меняется их состав.

Мини-калькулятор TCO

Калькулятор должен принимать реальные исходные данные, а не показывать заранее заданный процент «экономии». Для собственного оборудования нужны цена покупки, внедрение, эксплуатационные расходы, ремонт и предполагаемая выручка от продажи. Для облака — вычисления, хранилище, сеть, поддержка, обязательства и миграция.

На выходе нужны три показателя: совокупная стоимость владения обеих моделей по месяцам, накопленная разница и точка окупаемости — точнее, месяц равенства расходов, если он возникает.

При изменении нагрузки, тарифов или графика модернизации расходы нужно пересчитывать помесячно.

Чек-лист: как выбрать между своим сервером и облаком

Перед решением полезно пройти десять шагов.

1. Опишите сервис. Определите число пользователей или задач, требуемую производительность и расположение данных.
2. Снимите профиль нагрузки. Оцените CPU/GPU, RAM/VRAM, IOPS, задержку, сеть, пиковые часы и рост объёма данных.
3. Задайте требования к доступности. SLA, RTO и RPO определяют, достаточно одного узла или нужны несколько доменов отказа.
4. Постройте сопоставимые архитектуры. Не сравнивайте по цене одиночный физический сервер и облачную систему в нескольких зонах.
5. Посчитайте полную стоимость. Учтите работу сотрудников, резервное копирование, лицензии, сеть, безопасность и дополнительные расходы обеих моделей.
6. Проверьте три сценария. Рассчитайте базовый вариант, рост нагрузки и стрессовый сценарий с изменением курса, трафика или стоимости электроэнергии.
7. Протестируйте реальную нагрузку. Для баз данных, ИИ, рендера и инженерных расчётов одних паспортных характеристик недостаточно.
8. Проверьте условия закупки и юридические ограничения. Провайдер, договор, требования к данным, трансграничная передача, валюта расчётов и поддержка могут изменить и архитектуру, и TCO.
9. Посчитайте стоимость выхода. Для облака это перенос данных и переработка зависимостей, для собственного оборудования — повторное использование или продажа.
10. Сопоставьте экономию с рисками. Если разница в TCO составляет несколько процентов, важнее могут оказаться сроки запуска, контроль инфраструктуры, компетенции команды и доступность нужных ресурсов.

Вопросы и ответы (FAQ)

Коротко о главном

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

При стабильной высокой нагрузке собственная инфраструктура может оказаться выгоднее. Для кратковременных пиков и быстро меняющихся проектов чаще подходит облако. Промежуточные варианты — аренда выделенного сервера и гибридная инфраструктура. Поэтому универсальной точки «окупаемости» нет: результат зависит от профиля нагрузки и всех связанных расходов.

Если расчёт показывает преимущество собственной инфраструктуры, изучите каталог GPU-серверов DigitalRazor. Специалисты помогут подобрать конфигурацию под реальную нагрузку и протестировать её до покупки, чтобы точнее определить необходимую производительность и не переплачивать за лишние ресурсы.

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

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

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

Процессоры

Threadripper PRO

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

RAM до 1024 ГБ DDR5

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

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

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

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

Процессоры

Threadripper PRO

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

RAM до 1024 ГБ DDR5

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

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

Подробнее

Видеокарты

RTX PRO 6000 / RTX 5090

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

Процессоры

AMD Epyc, Intel Xeon

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

RAM до 3072 ГБ DDR5

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

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

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

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

Процессоры

AMD EPYC, Intel Xeon

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

RAM до 1536 ГБ DDR5

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

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

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

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

Процессоры

AMD EPYC, Intel Xeon

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

RAM до 2048 ГБ DDR5

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

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

Подробнее

Видеокарты

NVIDIA H200 SXM

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

Процессоры

AMD EPYC, Intel Xeon

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

RAM до 2048 ГБ DDR5

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