1, 2, 4 или 8 GPU в сервере: как выбрать конфигурацию под LLM, инференс, обучение и рендеринг

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

Количество видеокарт в сервере само по себе не гарантирует производительность. Сервер на 8 GPU может быть медленнее или дороже в пересчёте на полезную работу, чем сервер на 4 GPU, если модель плохо делится между картами, данные идут через узкое место PCIe, часть GPU простаивает или охлаждение не позволяет держать стабильные частоты.

Правильный выбор начинается не с вопроса «сколько GPU можно поставить в корпус», а с других вопросов:

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

Для выбора конкретных карт можно ориентироваться на видеокарты NVIDIA, но количество GPU нужно считать уже после анализа нагрузки, а не до него.

Когда выбирать 1, 2, 4 или 8 GPU

Эта таблица помогает быстро сориентироваться, но не заменяет расчёт. Например, 8 GPU полезны для обучения большой модели, которая разделяется между картами и активно обменивается данными. Но для рендер-фермы, где кадры считаются независимо, несколько серверов по 2–4 GPU могут быть удобнее и устойчивее к отказам.

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

Как принять решение

Модель, сцена или профиль пользователя помещается в память одной GPU?

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

• прототипов LLM;
• внутреннего ассистента с умеренной нагрузкой;
• тестового стенда для дообучения;
• одного 3D-специалиста;
• пилотного VDI-проекта;
• небольшой очереди задач рендеринга.

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

Для больших LLM часто важнее не просто количество карт, а объём и скорость памяти. Например, NVIDIA H200 интересна именно там, где модель и длинный контекст упираются в видеопамять и пропускную способность. В официальном описании NVIDIA H200 указаны 141 ГБ HBM3e и высокая пропускная способность памяти, поэтому такие карты рассматривают для крупных LLM и HPC-задач: NVIDIA H200.

Важнее задержка одного запроса или общий поток задач?

Для LLM-инференса это один из ключевых вопросов.

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

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

Нагрузка независимая или связанная?

Независимые задачи масштабируются проще. К ним относятся:

• рендеринг отдельных кадров;
• несколько независимых моделей;
• отдельные сервисы инференса;
• разные команды разработки;
• VDI-пользователи с разными профилями;
• тестовые и production-нагрузки, которые можно развести по разным GPU.

Для таких сценариев не всегда нужен один большой 8-GPU сервер. Иногда выгоднее взять 2–4 GPU в одном сервере или несколько отдельных узлов с 1 GPU в каждом.

Связанные задачи сложнее. Это обучение одной большой модели, разделение LLM между несколькими GPU или инференс модели, которая не помещается в одну карту. Здесь GPU постоянно обмениваются данными, поэтому важна не только мощность карт, но и то, как они связаны между собой. NVIDIA отдельно описывает роль NVLink и NVSwitch как высокоскоростной связи между GPU для задач, где обмен данными критичен: NVIDIA NVLink.

Один большой сервер или несколько меньших?

Один большой сервер лучше, если:

• модель должна работать как единая задача;
• нужен быстрый обмен между GPU;
• используется 4–8 GPU с NVSwitch;
• задержка между узлами критична;
• команда умеет администрировать плотную GPU-платформу.

Несколько меньших серверов лучше, если:

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

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

Как разные задачи используют несколько GPU

PowerEdge R760xa. Источник изображения: ServerMall

Dell описывает PowerEdge R760xa как air-cooled сервер для AI/ML обучения, вывода результатов, аналитики и VDI.

LLM-инференс

Инференс — это запуск уже обученной модели: ответы чат-бота, анализ документов, генерация кода, классификация, поиск по базе знаний. Для LLM важны не только вычисления, но и память: модель, контекст и промежуточные данные должны где-то размещаться.

На выбор количества GPU влияют:

• размер модели;
• длина контекста;
• число одновременных пользователей;
• требования к задержке ответа;
• объём видеопамяти;
• скорость памяти;
• возможность запускать несколько копий модели;
• поддержка пакетной обработки запросов.

1 GPU подходит, если модель помещается в память карты, пользователей немного, а задержка важнее максимального потока. Это хороший вариант для внутреннего ассистента, пилота или сервиса с нерегулярной нагрузкой.

2 GPU нужны, если модель почти помещается в одну карту, требуется запас по памяти или нужно запустить две независимые копии сервиса. Но здесь важно проверить, поддерживает ли выбранное ПО разделение модели между GPU.

4 GPU обычно удобны для production-инференса, где есть несколько моделей, стабильный поток запросов или разные группы пользователей. Можно выделить одну GPU под одну модель, вторую — под другую, третью — под тесты, четвёртую — под резерв или пиковую нагрузку.

8 GPU оправданы для больших моделей и плотного инференса, где есть постоянная очередь запросов и софт умеет распределять модель между картами. В документации NVIDIA Triton и TensorRT-LLM отдельно рассматривается multi-GPU и multi-node развёртывание больших языковых моделей в Kubernetes.

Обучение и дообучение моделей

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

Есть несколько способов масштабирования.

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

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

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

Для экспериментов и небольшого дообучения часто достаточно 1 GPU. Для первых multi-GPU-тестов и более крупных batch можно использовать 2 GPU. Для команды, которая регулярно дообучает модели, 4 GPU часто становятся рабочим минимумом. 8 GPU нужны там, где есть постоянные тяжёлые эксперименты, большие наборы данных и понятная методика распределения нагрузки.

Карты уровня NVIDIA A100 80GB часто рассматривают как универсальный вариант для инференса, дообучения и задач, где важна HBM-память. Для более тяжёлых сценариев обучения и LLM-инференса стоит смотреть в сторону H100/H200. В официальных характеристиках NVIDIA H100 указаны варианты SXM и PCIe, поддержка MIG и NVLink, поэтому при выборе важно смотреть не только на название GPU, но и на конкретный форм-фактор.

Рендеринг

Рендеринг масштабируется иначе, чем LLM. Если проект можно разделить на независимые кадры или сцены, несколько отдельных GPU или серверов могут быть выгоднее одного плотного 8-GPU узла.

1 GPU подходит для одного специалиста, небольшой студии или сервера, где сцены помещаются в память карты. 2 GPU могут ускорить рендер, если движок умеет эффективно использовать несколько карт. 4 GPU — хороший вариант для небольшой фермы, где можно распределять задания. 8 GPU оправданы при постоянной загрузке, но требуют серьёзного внимания к питанию, охлаждению и лицензиям рендер-движка.

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

Для смешанных задач — рендеринг, визуализация, инференс, графика, инженерные приложения — могут подойти карты вроде NVIDIA L40S 48GB или NVIDIA RTX PRO 6000 Blackwell Server Edition. Такие GPU часто интересны не только для нейросетей, но и для графических рабочих нагрузок.

VDI и многопользовательские нагрузки

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

Для VDI нужно учитывать:

• профили пользователей;
• тип приложений: офисные, CAD, 3D, инженерные, визуализация;
• возможность делить GPU между пользователями;
• поддержку vGPU;
• лицензии;
• совместимость с гипервизором;
• мониторинг загрузки на пользователя.

1 GPU подходит для пилота или небольшой группы. 2 GPU позволяют разделить разные профили пользователей. 4 GPU уже дают более плотный VDI-сервер. 8 GPU имеют смысл для крупной платформы, но только если заранее просчитаны лицензии, профили и реальная загрузка. В документации NVIDIA описаны лицензируемые продукты и настройка лицензирования для vGPU-сценариев.

Что ограничивает multi-GPU сервер

Multi-GPU сервер — это не просто корпус с несколькими видеокартами. Это связанная система, где GPU, CPU, память, диски, сеть, питание, охлаждение и ПО должны соответствовать друг другу. Если один компонент сильно слабее остальных, дорогие GPU будут ждать данные, перегреваться, простаивать или работать ниже ожидаемого уровня.

1 GPU: когда одной видеокарты достаточно

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

1 GPU подходит для:

• прототипирования LLM;
• тестового инференса;
• внутреннего чат-бота;
• дообучения небольших моделей;
• одного 3D-специалиста;
• пилота VDI;
• задач, где важны простота и цена.

Преимущества такой конфигурации:

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

Ограничения тоже понятны:

• одна GPU может быстро упереться в видеопамять;
• один сервис может занять всю карту;
• нет резерва при росте нагрузки;
• сложнее обслуживать несколько команд или проектов.

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

2 GPU: первый шаг к масштабированию

2 GPU — хороший промежуточный вариант между простым сервером и полноценной multi-GPU-системой. Он подходит, когда одной карты уже мало, но переход к 4 или 8 GPU пока не оправдан.

2 GPU полезны, если нужно:

• запустить две независимые модели;
• увеличить число одновременных запросов;
• разделить большую модель между двумя картами;
• ускорить рендеринг;
• протестировать multi-GPU-обучение;
• разделить production и экспериментальную нагрузку.

Перед покупкой нужно проверить:

• одинаковые ли GPU будут использоваться;
• есть ли NVLink для конкретной пары карт;
• хватает ли PCIe-линий;
• не находятся ли GPU за разными CPU без учёта NUMA;
• поддерживает ли софт работу с двумя GPU;
• не выгоднее ли одна карта с большей видеопамятью.

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

4 GPU: сбалансированный вариант для многих задач

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

Такой сервер подходит для:

• пакетного инференса;
• нескольких LLM-сервисов;
• дообучения средних и крупных моделей;
• команды ML-разработчиков;
• небольшой рендер-фермы;
• VDI с несколькими профилями пользователей;
• смешанной нагрузки, где часть GPU занята инференсом, часть — экспериментами.

Плюсы 4 GPU:

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

Минусы:

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

Если у компании есть несколько моделей для инференса, периодическое дообучение и отдельные графические задачи, 4 GPU часто полезнее, чем 8 GPU. Их проще загрузить равномерно, проще обслуживать и проще масштабировать дальше.

8 GPU: когда это действительно оправдано

8 GPU — это не универсальный «лучший вариант», а специализированная конфигурация для задач, которые умеют использовать плотную multi-GPU-систему.

8 GPU нужны, если есть:

• обучение крупных моделей;
• тяжёлое дообучение;
• большие LLM, которые требуют разделения между GPU;
• постоянный поток инференс-запросов;
• HPC-задачи;
• HGX-системы с NVSwitch;
• команда, которая умеет администрировать такие серверы.

Перед выбором 8 GPU нужно проверить:

• форм-фактор карт: PCIe или SXM;
• наличие NVLink или NVSwitch;
• какие GPU связаны напрямую;
• требования к стойке и электропитанию;
• тепловыделение;
• совместимость сервера с конкретными GPU;
• требования к сети, если сервер будет частью кластера;
• лицензии ПО;
• мониторинг температуры, памяти, загрузки и ошибок.

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

Для плотных AI-нагрузок уровня обучения и крупного инференса часто рассматривают NVIDIA H100 80GB, но при выборе важно сравнивать не только GPU, а всю платформу: межсоединение, питание, охлаждение, поддержку драйверов и планируемый режим работы.

Почему 8 GPU не всегда быстрее и выгоднее 4 GPU

Ускорение не растёт линейно

Если GPU стало в два раза больше, задача не обязана выполняться в два раза быстрее. На практике часть времени уходит на:

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

Чем больше GPU участвует в одной задаче, тем важнее становится обмен между ними. Если связь медленная, часть ускорения теряется.

Модель может не использовать все карты

Небольшая модель не станет лучше только потому, что её запустили на 8 GPU. Если она помещается в одну карту и не требует огромного потока запросов, остальные GPU будут простаивать или выполнять слишком маленькие задачи.

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

Видеопамять не складывается автоматически

Нельзя просто умножить 8 GPU по 80 ГБ и считать, что получилась одна видеокарта на 640 ГБ. У каждой GPU своя память. Чтобы использовать несколько карт как единый ресурс, нужны специальные подходы к разделению модели, поддержка со стороны фреймворка и правильная топология.

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

Сервер становится дороже в эксплуатации

У 8-GPU сервера выше не только цена покупки. Растут и постоянные расходы:

• электричество;
• охлаждение;
• требования к стойке;
• стоимость простоя;
• сложность диагностики;
• цена ошибки при настройке;
• требования к квалификации администраторов.

Если одна 8-GPU система простаивает или работает на 30–40% загрузки, экономически она может быть хуже нескольких меньших серверов.

Несколько серверов иногда надёжнее

Для независимых задач несколько серверов по 2–4 GPU могут быть удобнее одного большого узла. Если один сервер выходит из строя, остальные продолжают работать. Можно постепенно докупать оборудование, разделять команды и проще планировать обслуживание.

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

Когда лучше несколько серверов вместо одного большого

Несколько серверов стоит рассмотреть, если:

• задачи независимые;
• есть много небольших inference-сервисов;
• рендеринг делится по кадрам;
• VDI-пользователей можно распределить по пулам;
• нужна отказоустойчивость;
• оборудование закупается постепенно;
• разные команды используют разные GPU-профили.

Один большой сервер лучше, если:

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

Например, для рендер-фермы четыре сервера по 2 GPU могут быть практичнее одного сервера на 8 GPU. Задания независимы, отказ одного узла не останавливает всю ферму, а масштабирование можно делать постепенно. Для обучения одной большой LLM один 8-GPU сервер с правильной топологией может быть лучше, потому что данные постоянно передаются между GPU.

Примеры конфигураций под реальные задачи

Внутренний LLM-ассистент

Для внутреннего ассистента компании обычно не нужно сразу покупать 8 GPU. На старте достаточно понять модель, число пользователей и требования к задержке.

Подход:

• 1 GPU — если модель компактная и пользователей немного;
• 2 GPU — если нужен запас по памяти или параллельным запросам;
• 4 GPU — если есть несколько моделей, стабильная нагрузка и разные ассистенты для разных отделов;
• несколько серверов — если сервисы независимые и нужна отказоустойчивость.

Что проверить:

• длину контекста;
• пиковое число запросов;
• требования к задержке;
• возможность оптимизации модели;
• рост нагрузки на 6–12 месяцев.

Инференс нескольких моделей в продукте

Если продукт использует несколько моделей, одна большая GPU не всегда удобнее. Часто лучше распределить модели по разным картам и управлять очередями.

Подход:

• 2 GPU — для двух независимых моделей или production/test-разделения;
• 4 GPU — как базовый вариант для нескольких сервисов;
• 8 GPU — только при высокой и постоянной загрузке;
• несколько серверов — если модели независимы и нужно горизонтальное масштабирование.

Что проверить:

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

Дообучение LLM

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

Подход:

• 1 GPU — эксперименты и небольшие модели;
• 2 GPU — первые multi-GPU-тесты;
• 4 GPU — рабочая конфигурация для команды;
• 8 GPU — постоянные тяжёлые эксперименты и крупные модели.

Что проверить:

• объём данных;
• размер batch;
• требования к точности вычислений;
• скорость обмена между GPU;
• объём RAM;
• скорость NVMe;
• готовность пайплайна данных.

Рендеринг и 3D-графика

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

Подход:

• 1 GPU — рабочая станция или небольшой сервер;
• 2 GPU — ускорение рендера при поддержке движка;
• 4 GPU — небольшая ферма;
• несколько серверов — если задания независимые;
• 8 GPU — только при постоянной загрузке и подготовленной инфраструктуре.

Что проверить:

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

VDI и виртуальные рабочие станции

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

Подход:

• 1 GPU — пилот;
• 2 GPU — разделение профилей пользователей;
• 4 GPU — рабочий VDI-сервер;
• 8 GPU — крупный пул пользователей с заранее рассчитанными профилями.

Что проверить:

• типы пользователей;
• требования CAD, 3D и инженерных приложений;
• лицензии vGPU;
• совместимость гипервизора;
• мониторинг загрузки на пользователя;
• правила ограничения ресурсов.

Чек-лист перед покупкой GPU-сервера

По задаче

• Какая основная нагрузка: инференс, обучение, рендеринг, VDI или смешанный сценарий?
• Модель или сцена помещается в память одной GPU?
• Важнее задержка или общий поток задач?
• Нагрузка постоянная или нерегулярная?
• Можно ли делить задачу между GPU без большой потери эффективности?
• Нужна ли изоляция команд, клиентов или пользователей?

По серверу

• Сколько PCIe-линий доступно?
• Какая топология GPU?
• Есть ли NVLink или NVSwitch?
• Достаточно ли RAM?
• Хватает ли NVMe и скорости хранения?
• Достаточно ли блоков питания?
• Поддерживает ли корпус нужное охлаждение?
• Есть ли запас по стойке, электропитанию и шуму?

По программному обеспечению

• Поддерживает ли фреймворк multi-GPU?
• Нужны ли vGPU-лицензии?
• Есть ли ограничения у рендер-движка?
• Есть ли планировщик задач?
• Как будет считаться загрузка GPU?
• Как будет рассчитываться стоимость GPU-часа или одного запроса?

По эксплуатации

• Кто и как будет мониторить GPU?
• Как обновлять драйверы?
• Что делать при отказе одной карты?
• Как масштабироваться через год?
• Что дешевле: добавить GPU в один сервер или купить второй узел?
• Есть ли резерв по питанию и охлаждению?

FAQ

Нужно ли брать 8 GPU для LLM?

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

Складывается ли видеопамять нескольких GPU?

Не автоматически. У каждой GPU своя память. Использовать несколько карт как единый ресурс можно только при правильном разделении модели и поддержке со стороны фреймворка.

Что лучше: 4 GPU в одном сервере или 4 сервера по 1 GPU?

Для независимых задач часто удобнее несколько серверов. Для одной большой модели или обучения лучше один сервер с быстрой связью между GPU.

Когда нужен NVLink или NVSwitch?

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

Подходит ли 1 GPU для рендеринга?

Да, если сцены помещаются в память GPU и нет постоянной очереди задач. Для фермы лучше рассмотреть 2–4 GPU или несколько отдельных серверов.

Что важнее для LLM: количество GPU или видеопамять?

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

Можно ли смешивать разные GPU в одном сервере?

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

Как выбрать количество GPU

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

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

4 GPU — самый универсальный вариант для многих компаний. Такая конфигурация подходит для инференса, дообучения, рендеринга, VDI и смешанных задач, если есть планировщик и понятное распределение нагрузки.

8 GPU нужны для задач, которые действительно используют плотную multi-GPU-систему: крупное обучение, большие LLM, постоянный batch-инференс, HGX-платформы с правильной топологией и подготовленной инфраструктурой.

Несколько серверов лучше, если нагрузка независимая, нужна отказоустойчивость и компания хочет масштабироваться постепенно.

Лучший GPU-сервер — не тот, где больше всего видеокарт, а тот, где каждая GPU стабильно занята полезной работой и не упирается в память, сеть, питание, охлаждение или ограничения ПО.