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

Если вы технарь и работаете с инфраструктурой, то регулярно слышите слова GPU, HBM, NVLink, Tensor Cores, FP8, PCIe и тому подобное. Термины вроде знакомые, но как показывает практика, далеко не всегда люди понимают, что за ними скрывается и как одно связано с другим.

Привет! Я Евгений Зенухин, руководитель отдела развития и сопровождения физической инфраструктуры в Selectel. С запросами в духе «а можно ли вместо одной H100 использовать 10 штук RTX 1080, ведь суммарно VRAM получается столько же?» я сталкиваюсь чаще, чем хотелось бы. В этой статье я решил ответить на базовые, но очень важные вопросы о GPU, развеять некоторые мифы и показать, на что при выборе графического ускорителя нужно смотреть помимо цифр в его спецификации.

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

Что такое GPU

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

Но по мере развития стало понятно, что архитектура GPU хорошо подходит не только для графики. Она отлично решает задачи, где нужно одновременно выполнять огромное количество однотипных операций над большими массивами данных. Именно поэтому сегодня GPU используют не только в играх, но и в сфере AI для машинного обучения, инференса и дообучения LLM, в области VDI и графической виртуализации, от научных расчетов и инженерного моделирования до 3D-рендеринга и обработки видео.

Следовательно, неверно воспринимать GPU только как «процессор для нейросетей» или «видеокарту для игр», потому что это слишком узко. GPU — это специализированный ускоритель массово-параллельных вычислений. При этом современные GPU тоже бывают разными: одни лучше подходят для инференса, другие — для обучения, третьи — для HPC и FP64-расчетов, четвертые — для графики и VDI. Поэтому GPU — это не один универсальный ответ на все задачи, а целый класс ускорителей. А уж где происходят вычисления, которые надо ускорить — в играх, инференсе или рендеринге — другой вопрос.

Чем GPU отличается от CPU

Если объяснять совсем коротко, то CPU и GPU решают разные классы задач.

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

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

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

Так что если вы решили сэкономить, то задавайте себе правильный вопрос. Не «можно ли обойтись без GPU?» (потому что теоретически почти всегда можно), а «насколько это будет разумно по производительности и цене?».

Серверные и десктопные GPU 

Вокруг деления на серверные и десктопные GPU часто строится чуть ли не полноценная мифология со своеобразным пантеоном процессоров. На практике же все проще.

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

В теории можно придумать экзотический сценарий, где серверный ускоритель оказывается в пользовательском окружении. «Вот бы запустить Cyberpunk на H100» — как раз из этой серии. Но это плохая идея: у серверных GPU другой форм-фактор, другое охлаждение, другой набор драйверных и платформенных ожиданий, а игровые сценарии с DirectX для них не являются целевыми. Поэтому вопрос не в том, «заведется ли оно вообще», а в том, насколько разумно использовать устройство вне своего класса задач. 

В обратную сторону это тоже работает. Так что при появлении идеи установить десктопный ускоритель в сервер ради экономии стоит задать себе вопросы:

• насколько удобно это сделать и подходит ли этот GPU для нагрузки в режиме 24/7?
• есть ли ECC и насколько зрелая поддержка виртуализации?
• как охлаждается и питается GPU?
• что будет с надежностью, плотностью и сопровождением?

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

Для удобства я собрал мини-пример со сравнением десктопной RTX 4090 и серверной H200:

Параметр	RTX 4090	H200 SXM
Класс	десктопный / prosumer	серверный AI/HPC-ускоритель
Память	24 GB GDDR6X	141 GB HBM3e
Пропускная способность	~ 1 TB/s	4.8 TB/s
TDP	450 W	до 700 W
Типичный контекст	локальные AI-задачи, рендеринг, эксперименты, небольшие модели	тяжелый инференс, обучение, HPC, плотные серверные платформы
Важные ограничения	мало VRAM для крупных LLM, нет серверной обвязки уровня HGX/DGX, лицензионные нюансы	высокая цена, требования к платформе, питанию и охлаждению

Просто взглянув на цифры, кто-то может подумать, что серверный GPU — это тот же десктопный ускоритель, просто помощнее и подороже. На деле же различия не сводятся только к цифрам: тут еще другой форм-фактор, возможность использовать NVLink, MIG и серверную обвязку, да и вообще совсем другой эксплуатационный контекст.

Из чего состоит GPU и на что смотреть при выборе

Когда вы открываете спецификацию GPU, на вас вываливается набор параметров: память, тип памяти, шина, пропускная способность, количество ядер, TDP, форматы точности, интерконнект и многое другое. Чтобы не утонуть в этом наборе цифр, полезно понимать, из чего конкретно состоит GPU и что именно описывает каждая метрика.

Вычислительный чип

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

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

CUDA-ядра

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

Тензорные ядра

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

У других производителей похожие по назначению блоки могут называться иначе. Например, у AMD в CDNA-архитектурах используются Matrix Cores/Matrix Core Technologies, а у Intel в GPU — XMX, Xe Matrix Extensions. Поэтому в общем смысле корректнее говорить не только о тензорных ядрах, а о специализированных матричных блоках GPU.

От поколения к поколению меняется не только их производительность, но и то, какие форматы чисел они умеют считать эффективно:

Поколение	Что это дало
Volta / Turing	ранние поколения Tensor Cores, ускорение FP16-матричных операций
Ampere	активное использование TF32, FP16, BF16, INT8; большой скачок для обучения и инференса
Hopper	Transformer Engine и FP8 как важный рабочий формат для современных transformer-моделей
Blackwell/Blackwell Ultra	дальнейшее развитие низкоточных форматов: FP8, FP6, NVFP4; оптимизация под плотный инференс и AI-фабрики

Конкретные TFLOPS лучше смотреть не по «поколению вообще», а по конкретной модели GPU, формату точности и условиям подсчета. В спецификациях NVIDIA часто отдельно указываются значения для FP32, TF32, FP16/BF16, FP8, INT8 и режимов со sparsity, поэтому одна красивая цифра почти никогда не описывает всю картину.

Количество вычислительных блоков

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

Хороший пример — RTX 4090 и H100 PCIe. У RTX 4090 больше CUDA-ядер: 16 384 против 14 592 у H100 PCIe. Если смотреть только на эту цифру, можно решить, что RTX 4090 должна быть быстрее. Но для тяжелых AI-нагрузок это не так просто: у H100 больше памяти, выше пропускная способность, другой класс тензорных ядер, есть поддержка FP8, HBM-память и дата-центровая обвязка.

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

Формат точности: FP16, BF16, FP8, INT8, FP4

Это тоже важнейшая метрика, просто не всегда она указана там, где ее ожидают увидеть новички.

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

Для удобства форматы точности можно разбить на основные группы:

Формат	Где обычно встречается	Что дает	В чем нюанс
FP32	классические вычисления, часть HPC и графики	высокая точность	дорого по памяти и вычислениям
FP16 / BF16	обучение и инференс нейросетей	хороший баланс точности, скорости и памяти	нужна поддержка софта и корректная mixed precision-настройка
TF32	NVIDIA Ampere/Hopper для ускорения FP32-подобных матричных операций	ускоряет обучение без полного перехода на FP16	формат специфичен для NVIDIA Tensor Cores
FP8	Hopper, Ada, Blackwell; современные transformer-сценарии	меньше память, выше пропускная способность и производительность	требует поддержки модели, фреймворка и калибровки/масштабирования
INT8 / INT4	квантованный инференс	сильно снижает потребление памяти	возможна деградация качества, важны квантизация и поддержка kernels
FP4 / NVFP4	Blackwell и новые inference-сценарии	еще более агрессивная оптимизация	подходит не для всего, требует современного стека

Память

Рядом с вычислительным чипом всегда находится память. И именно она во многих современных задачах определяет реальную эффективность ускорителя. Для GPU важны объем, тип и пропускная способность памяти, а также ее надежность, включая ECC в серверном сегменте.

Объем памяти

Данный параметр позволяет понять, сколько данных помещается на ускорителе одновременно. В контексте AI и LLM важно понимать, помещаются ли веса модели, остается ли место под KV-кэш, влезает ли рабочий батч и насколько велик запас под многопользовательскую нагрузку.

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

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

Тип памяти

Если упростить, то в GPU чаще всего встречаются два больших класса памяти:

• GDDR — типичный вариант для десктопных и части профессиональных GPU. Такая память дешевле и проще в массовом производстве, но обычно уступает HBM по пропускной способности и плотности в серверных AI-сценариях. Например, RTX 4090 имеет 24 GB GDDR6X и пропускную способность около 1 ТБ/с.
• HBM — типичный выбор для старших серверных ускорителей. Память размещается очень близко к GPU, использует широкую шину и дает огромную пропускную способность. Например, H200 SXM имеет 141 GB HBM3e и 4.8 ТБ/с.

Поэтому при выборе GPU важно смотреть не только на объем памяти, но и на ее тип и пропускную способность. Для LLM это особенно важно: веса модели и KV-кэш нужно не просто где-то хранить, их нужно постоянно и быстро читать.

Пропускная способность памяти

Вот это один из самых важных параметров для понимания современных LLM-нагрузок. Очень часто узким местом оказывается не абстрактная вычислительная мощность в TFLOPS, а скорость, с которой GPU может читать данные из своей памяти.

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

Подсистема питания

Любой серьезный GPU — это очень требовательное к питанию устройство. Например, DGX B300 с восемью GPU NVIDIA Blackwell Ultra — это система с максимальным энергопотреблением до 15 кВт. На таком уровне питание и охлаждение перестают быть «деталью» и становятся частью архитектуры решения. Поэтому на плате или в модуле присутствуют VRM и силовые элементы, линии питания, коннекторы или специализированные схемы подключения через платформу, механизмы контроля мощности и теплового режима.

TDP и энергопотребление

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

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

Охлаждение

В десктопе карта с собственными вентиляторами может быть нормой. Для серверной среды стандартнее и правильнее будет пассивное охлаждение на самих GPU, системный airflow-шасси, а также правильно рассчитанные вентиляторы и направляющие, для которых необходимо понимание температурного режима стойки и коридора. На высоких плотностях все чаще применяют жидкостное охлаждение.

PCB, интерфейс и физический форм-фактор

Если говорить о карте или модуле как об изделии, то кроме самого кристалла и памяти нас интересует PCB, интерфейс подключения, способ установки в систему, требования к механике и охлаждению. И вот здесь начинаются важные инфраструктурные различия. Для базового понимания разберем два самых часто обсуждаемых формата в NVIDIA-экосистеме: PCIe и SXM.

Важно помнить, что это не единственные варианты на рынке: например, в accelerator-платформах встречается и OAM-подход. Но для первого приближения PCIe и SXM достаточно, потому что именно на их сравнении хорошо видны ключевые инфраструктурные различия: питание, охлаждение, плотность, сервисность и интерконнект.

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

SXM — это уже модуль, который устанавливается на специальную плату-основание внутри серверной платформы. Плюсы формата: лучшее питание и теплопередача, высокая плотность размещения, более сильная и богатая топология интерконнекта между GPU. Минусы: нужны специальные платформы HGX/DGX-класса, сложнее ремонт и замена, выше зависимость от конкретного шасси и экосистемы.

Интерконнект: типы (внутренних) соединений GPU

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

Интерконнект — это общий термин для соединений между компонентами вычислительной системы. В контексте GPU полезно различать несколько уровней: PCIe для связи GPU с сервером, NVLink для быстрой связи GPU с GPU, NVSwitch для объединения нескольких GPU внутри платформы и Ethernet/InfiniBand для связи между разными серверами.

В этой статье мы сосредоточимся в первую очередь на внутренних соединениях GPU внутри одного сервера (NVLink). Именно они чаще всего определяют, насколько хорошо несколько ускорителей смогут работать вместе в тяжелых AI-нагрузках.

NVLink

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

Скорость NVLink сильно зависит от поколения GPU и платформы. Поэтому «есть NVLink» — это еще не панацея: важно понимать, какого он поколения, сколько линий доступно конкретному GPU и используется ли NVSwitch.

Поколение NVLink	Типичные GPU / архитектура	До какой скорости на GPU, двунаправленно	Что важно понимать
NVLink 1	Pascal / P100	до 160 GB/s	первое поколение, большой шаг относительно PCIe своего времени
NVLink 2	Volta / V100	до 300 GB/s	больше линий и выше масштабируемость для multi-GPU-систем
NVLink 3	Ampere / A100	до 600 GB/s	важный скачок для HGX/DGX A100 и плотных AI/HPC-систем
NVLink 4	Hopper / H100, H200	до 900 GB/s	типичная база современных HGX/DGX Hopper-платформ
NVLink 5	Blackwell / B200, B300	до 1.8 TB/s	удвоение относительно Hopper, особенно важно для больших моделей и rack-scale-систем
NVLink 6	Rubin	до 3.6 TB/s	следующее поколение, ориентированное на еще более плотные AI-фабрики

Эти цифры не означают, что любая система с таким GPU автоматически даст указанную скорость между любой парой ускорителей. Реальная картина зависит от форм-фактора, числа NVLink-линий, наличия NVSwitch, топологии сервера и того, как фреймворк распределяет модель между GPU.

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

Топология GPU

У NVIDIA и других вендоров есть много названий для разных уровней платформ: отдельные GPU, NVL-связки, HGX-платы, DGX-системы, NVSwitch-платформы, rack-scale-решения. Для базового выбора важно не заучивать все эти названия, а задавать практические вопросы: сколько GPU в системе, как они связаны между собой, есть ли быстрый GPU-to-GPU-интерконнект, как GPU связаны с CPU и поддерживает ли нужный режим ваш софт.

Формулировка «сервер с 8 GPU» сама по себе мало что говорит. Восемь карт, подключенных через PCIe, и восемь SXM-модулей, связанных через NVSwitch — это разные системы. В первом случае обмен данными между GPU может быстрее упереться в ограничения PCIe и общей топологии сервера, чем в объем памяти ускорителей. Во втором случае платформа изначально рассчитана на плотную совместную работу GPU.

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

Шина и интерфейс

Когда в бытовом контексте говорят про «ширину шины», обычно пытаются косвенно оценить, насколько быстро память обслуживает вычислительные блоки. В профессиональной инфраструктуре лучше сразу уточнять, через какой интерфейс (об этом было выше) при этом GPU подключен к системе и как он связан с соседними GPU.

Важно не путать две вещи: пропускную способность локальной памяти GPU и интерфейс связи GPU с остальной системой.

• Шина HBM/GDDR отвечает за то, как быстро сам GPU читает данные из своей же памяти.
• PCIe, NVLink и NVSwitch отвечают за обмен данными между CPU, GPU и соседними ускорителями.

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

То есть сама по себе «шина 384-bit» или любая другая цифра полезна только как часть картины, а не как универсальный индикатор качества.

Mожно ли заменить H200 десятком десктопных GPU

Это один из самых полезных практических вопросов по данной теме, потому что он очень быстро вскрывает неправильное понимание специфики GPU. Как правило, формулировка звучит примерно в таком формате: «А получу ли я производительность H200, если вместо него собрать 10, 20 или 30 обычных GPU?».

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

Почему так? Во-первых, не все масштабируется линейно. Если задача идеально распараллеливается и почти не требует обмена данными, то рост числа GPU действительно может давать близкий к линейному прирост производительности.

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

Во-вторых, память не всегда суммируется так, как хочется. Очень частая ошибка — думать, что десять карт по 24 ГБ — это «как один GPU на 240 ГБ». Но, к сожалению, нет: память на разных GPU не превращается автоматически в единое общее пространство без штрафов и ограничений. Если задача требует хранить и быстро читать веса модели как единый массив, вам придется распараллеливать модель, и здесь все снова упирается в интерконнект и те самые накладные расходы.

В-третьих, пропускная способность HBM и локальность памяти решают. Например, у RTX 4090 — 24 ГБ GDDR6X и около 1 ТБ/с пропускной способности памяти, а у H200 SXM — 141 ГБ HBM3e и 4.8 ТБ/с. То есть H200 не только «имеет больше памяти», но и быстрее обслуживает эту память внутри одного ускорителя. Если же собрать много отдельных десктопных GPU, их локальная память не превращается в одну большую HBM-подсистему. Данные придется распределять между устройствами, а дальше все снова упрется в топологию, интерконнект и поддержку со стороны фреймворков. Можно собрать много обычных GPU с GDDR, но это не даст магическим образом локальную HBM-подсистему с серверной пропускной способностью на одном устройстве. Именно поэтому «много дешевых карт» и «один жирный ускоритель» очень часто оказываются принципиально разными по поведению системами в реальных LLM-сценариях.

Наконец, усложняется вся инфраструктура вокруг GPU. Даже если допустить, что вычислительно вы теоретически догоняете старший серверный ускоритель, все еще остаются вопросы. Сколько PCIe-линий нужно и какая топология внутри узла? Сколько потребуется CPU и RAM? Как это все питать и охлаждать? Сколько места займет решение? Насколько вырастет вероятность отказов и как вообще этот зоопарк сопровождать?

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

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

GPU выбирают не отдельно, а вместе с платформой

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

CPU нужен не только «чтобы был»: важно смотреть на количество PCIe-линий, NUMA-топологию и то, не станет ли процессор узким местом для препроцессинга, сетевой части или обслуживания пайплайна.

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

Если система выходит за пределы одного узла, важнейшим фактором становится сеть: пропускная способность, задержка, RDMA, InfiniBand/Ethernet и то, насколько часто узлы должны обмениваться данными.

Поэтому корректный выбор GPU — это не выбор одной карточки из прайс-листа. Это выбор всей платформы под конкретную нагрузку.

Что стоит запомнить после этой статьи

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

• Какая у меня задача и нагрузка? Инференс, обучение, VDI, рендеринг, HPC и LLM-сервис с длинным контекстом — все это разные сценарии, требующие разных инструментов.
• Помещается ли задача в память? Нужно учитывать не только веса модели, но и KV-кэш, размер батча, параллельные запросы и запас под эксплуатацию.
• Хватает ли пропускной способности памяти? Для LLM-инференса, особенно на этапе генерации токенов, пропускная способность часто важнее красивых TFLOPS.
• Нужны ли несколько GPU? Если да, нужно смотреть на топологию, NVLink/NVSwitch, PCIe, NUMA и поддержку параллелизма в софте.
• Подходит ли форм-фактор? PCIe, SXM и другие варианты отличаются не только механикой, но и питанием, охлаждением, плотностью и сервисностью.
• Готова ли платформа вокруг GPU? Сервер, CPU, RAM, NVMe, сеть, питание, охлаждение и драйверный стек могут ограничить результат сильнее, чем сам ускоритель.
• Считается ли экономика сервиса, а не только цена железа? Важно понимать стоимость токена, запроса, часа работы или результата, а не только цену одной GPU.

Главная мысль простая: выбор GPU как части IT-инфраструктуры должен быть нормальной инженерной задачей, а не гаданием по цифрам в спецификациях. Объем памяти, TFLOPS, количество ядер, TDP или цена сами по себе ничего не гарантируют. Работает только связка: конкретная задача → подходящая архитектура GPU → правильная серверная платформа → поддерживаемый софт → стоимость результата.