Когда нужен сервер с несколькими GPU

MAATRIX

Вопрос «одна карта или несколько» всплывает, как только текущий сервер начинает захлёбываться: модель не влезает в память, обучение тянется сутками, очередь рендер-задач растёт быстрее, чем успевает разгребаться. Соблазн решить проблему простым добавлением второй видеокарты понятен, но работает это не всегда так, как кажется на первый взгляд. Разберём, в каких сценариях многокарточный сервер действительно нужен, а в каких — просто лишние расходы.

Модель не помещается в память одной карты

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

Здесь несколько карт нужны не для скорости, а как единственный способ вообще запустить задачу. Модель делится между GPU одним из способов:

• Model parallelism (тензорный параллелизм) — отдельные слои или части слоёв модели распределяются по разным картам, каждая считает свой кусок.
• Pipeline parallelism — модель режется на последовательные блоки (например, первые 10 слоёв на первой карте, следующие 10 — на второй), и данные проходят по конвейеру.
• Смешанные схемы — крупные фреймворки для обучения комбинируют оба подхода, добавляя ещё и разбиение данных.

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

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

Параллелизм данных: ускорение, а не только объём

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

Это принципиально другая задача по сравнению с делением модели: цель — не «уместить», а «пройти больше данных за единицу времени». Именно так масштабируют обучение на десятки и сотни карт в крупных кластерах: каждая GPU независимо считает свою часть батча, а обмен идёт только градиентами, а не всем состоянием модели.

Для практики на арендованном сервере это означает:

• Если обучение медленное из-за объёма датасета (много эпох, большие батчи), а модель сама по себе некрупная — 2–4 карты с data parallelism дадут прирост, близкий к линейному, при условии, что связь между картами не станет узким местом.
• Прирост от добавления карт в data parallelism предсказуемее, чем в model parallelism — меньше архитектурных нюансов, проще настроить в популярных фреймворках.
• Эффективность всё равно зависит от того, насколько быстро карты обмениваются градиентами между шагами — про это ниже.

Рендеринг и видеообработка с параллельной нагрузкой

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

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

Ключевое отличие от обучения моделей — здесь карты почти не общаются между собой во время расчёта. Это снимает главную головную боль multi-GPU (медленная связь между картами становится узким местом) и делает масштабирование почти линейным: 4 карты рендерят примерно в 4 раза больше кадров в единицу времени, чем одна, если только не упираетесь в другие ресурсы — диск, CPU для препроцессинга, пропускную способность сети при отдаче готовых файлов.

Если тема рендер-ферм актуальна отдельно от машинного обучения, есть смысл заглянуть в статью про то, сколько ресурсов нужно VPS для рендер-фермы — там подробнее про баланс CPU/GPU/диска под конкретно эту нагрузку.

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

Это главное разочарование новичков в multi-GPU: купили или арендовали вторую карту, а прирост скорости — не в 2 раза, а заметно меньше, а иногда обучение вообще падает с ошибкой. Причины почти всегда одни и те же.

Софт должен уметь распределять нагрузку. GPU сами по себе не «складываются» — распределением вычислений между картами занимается фреймворк (PyTorch с DistributedDataParallel или FSDP, DeepSpeed, Megatron-LM и подобные), и он должен быть явно настроен на multi-GPU режим. Скрипт, написанный под одну карту, при простом запуске на сервере с двумя GPU просто продолжит использовать только одну — вторая будет простаивать, а вы будете платить за железо, которое ничего не считает.

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

Разнородные карты — источник проблем. Смешивать в одном сервере карты разных поколений или с разным объёмом памяти технически возможно, но на практике синхронизация между ними усложняется, а слабая карта начинает тормозить более мощные. Для стабильной работы лучше держать однородный набор карт одной модели.

Драйверы и версии CUDA/фреймворков должны совпадать. Multi-GPU конфигурации чувствительнее к рассинхрону версий, чем однокарточные — несовместимость чаще всего всплывает именно на этапе распределённого запуска, а не при работе с одной картой.

Связь между картами: почему она важна

Когда карты обмениваются данными на каждом шаге вычислений (что происходит и в model parallelism, и в data parallelism при усреднении градиентов), скорость этого обмена напрямую влияет на итоговую производительность. Здесь возможны разные варианты связи между GPU внутри одного сервера:

• Обычная шина PCIe — самый распространённый и доступный вариант, есть в подавляющем большинстве конфигураций с несколькими картами. Для рендеринга и многих задач инференса этого достаточно, поскольку интенсивного обмена между картами не требуется.
• Прямые высокоскоростные соединения между GPU (в духе NVLink у NVIDIA) — используются в конфигурациях, заточенных под тяжёлое обучение, где карты постоянно синхронизируют состояние. Такое соединение заметно быстрее обычной шины и снижает потери на обмене данными между картами, но доступно не во всех серверных платформах и обычно означает более высокий класс оборудования и цену.

Не будем приводить точные цифры пропускной способности разных вариантов связи — они зависят от конкретного поколения оборудования и платформы, и лучше сверяться со спецификацией конкретного сервера, который вы рассматриваете, чем ориентироваться на усреднённые цифры из интернета. Общее правило простое: чем плотнее задача требует синхронизации между картами (тяжёлое обучение с частым обменом градиентами или активациями), тем важнее качество связи между GPU. Чем более независимы задачи на картах (рендер отдельных кадров, параллельный инференс разных запросов), тем меньше это имеет значение.

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

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

Одной карты обычно хватает, если:

• Модель для инференса помещается в память карты (в том числе с квантованием) и не идёт речь о параллельном обслуживании десятков запросов одновременно.
• Обучение или дообучение (например, LoRA) идёт на небольшом датасете, и время ожидания в разумных пределах для вашей задачи.
• Рендер-нагрузка не настолько плотная, чтобы очередь задач копилась быстрее, чем одна карта успевает её разгребать.

Несколько карт нужны, если:

• Модель физически не помещается в память одной карты — деления не избежать.
• Датасет и число итераций делают обучение неприемлемо долгим на одной карте, и вы точно знаете, что можете распределить нагрузку через data parallelism.
• Рендер-ферма или продакшн-инференс обслуживают такой поток задач, что несколько независимых карт дают прямой выигрыш по пропускной способности.

Стоит учитывать и цену: сервер с несколькими GPU, особенно с быстрой связью между картами, стоит заметно дороже пропорционального числа отдельных однокарточных серверов. Если задачи между картами не связаны (тот же рендер), иногда практичнее взять несколько независимых серверов с одной картой каждый, чем один многокарточный узел — это может оказаться и дешевле, и гибче в масштабировании. А если задача упирается именно в обучение с плотной синхронизацией — тут уже вопрос не цены, а принципиальной возможности вообще решить задачу без multi-GPU. Про экономику выбора между одной мощной картой и распределённой конфигурацией подробно писали в статье своя видеокарта против аренды GPU: что выгоднее и когда.

Частые вопросы