Пользователь Reddit под ником PraxisOG опубликовал пост о сборке с четырьмя видеокартами AMD Radeon Pro V620 в шасси, которое сгенерировала нейросеть и напечатали на 3D-принтере. В посте есть заголовок и ссылка. Состав платформы, блок питания, пластик, версия софта и результаты замеров не раскрыты.
Ниже разбор идеи, а не отчёт о чужой сборке. Что за карта V620 и почему её рассматривают для инференса, сколько памяти дают четыре GPU, какие узкие места возникают при объединении четырёх ускорителей в одном корпусе и что реально решает корпус, сгенерированный нейросетью. Цифр в токенах в секунду не будет: их не из чего взять, а придумывать нельзя.
Короткий ответ: подход осмысленный, если нужен большой суммарный объём VRAM из карт вторичного рынка и есть опыт сборки серверного железа. Печатное шасси закрывает вопрос компоновки, то есть посадочные места, воздушные каналы и крепления под конкретные платы. Питание, продув и поддержку в ROCm оно не закрывает, и именно на них уходит основное время.
Что известно о проекте PraxisOG, а что нет
Разделяю факты и неизвестное сразу, чтобы дальше не смешивать одно с другим.
- Есть: пост на Reddit от пользователя PraxisOG, четыре Radeon Pro V620, шасси сгенерировано нейросетью и напечатано на 3D-принтере.
- Нет: модель материнской платы и процессора, блок питания, принтер и пластик, версия ROCm и движок инференса, температуры под нагрузкой, потребление из розетки, скорость генерации и prefill, бюджет проекта, факт стабильной работы под длительной нагрузкой.
Из этого следует практическое ограничение для читателя. Любые утверждения вида «сборка выдаёт N токенов в секунду» или «карты держат 70 градусов» проверить нечем, поэтому в статье их нет. Всё про саму карту опирается на официальную спецификацию AMD, а её перед покупкой нужно открыть и сверить руками. Общие соображения про VRAM, питание, PCIe и печать справедливы для любого похожего проекта, и в этом ценность кейса: он показывает набор задач, а не готовый рецепт с числами.
Второй момент: пост без деталей всё равно полезен. Четыре серверные карты в самодельном корпусе встречаются редко, и сама постановка задачи заставляет разобраться, что именно придётся решать. Ниже эти задачи разложены по полкам.
Radeon Pro V620: что это за карта и почему она интересна для LLM
Radeon Pro V620 относится к серверной линейке Radeon Pro на архитектуре RDNA 2 и несёт память GDDR6. Карта проектировалась под облачные рабочие станции и виртуализацию: одна GPU делится между несколькими виртуальными машинами, плата рассчитана на установку в серверное шасси с общим продувом, видеовыходов у неё нет.
Точные цифры я намеренно не подаю как подтверждённые. Объём VRAM на карту, TDP, ширину шины, конфигурацию линий PCIe и требования к продуву нужно смотреть на странице продукта AMD и в release notes ROCm: в исходных материалах этих данных нет, а разница между 24 и 32 ГБ на карту или между 250 и 300 Вт TDP меняет всю смету сборки, включая блок питания и схему охлаждения.
Сильные стороны V620 для локального инференса
- Объём памяти на карту в этом классе измеряется десятками гигабайт. Четыре платы дают запас, который потребительскими картами набирается долго и дорого.
- Серверное происхождение: расчёт на круглосуточную работу, пассивный радиатор без собственных вентиляторов, ресурс под постоянную нагрузку.
- Пассивное охлаждение удобно для плотной компоновки. Воздух гонит один общий поток, а не десяток мелких турбинок, которые мешают друг другу и собирают пыль.
- Форм-фактор под установку в ряд: платы можно ставить близко, если продумать тракт воздуха.
Слабые места и подводные камни
- Пассивный радиатор без серверного продува означает троттлинг, а в плохом случае отказ карты. Двух 120-мм вентиляторов в обычном корпусе для такого потока мало.
- Привязка к специфическим платформам: свои крепления, свои требования к воздуху, иногда нестандартные разъёмы питания.
- Вторичный рынок: гарантии нет, история эксплуатации неизвестна, ремонт дорогой, а запчасти искать долго.
- Программная поддержка: ROCm добавляет устройства в список поддерживаемых с задержкой, и проверять это нужно до покупки, а не после.
- Нет видеовыходов. Отладка только через SSH или IPMI, а значит, нужна платформа с нормальным удалённым управлением.
Сколько VRAM нужно для LLM и что дают четыре GPU
Логика расчёта простая. Вес модели примерно равен числу параметров, умноженному на байты на параметр: FP16 даёт 2 байта, 8-битная квантизация около 1, 4-битная около 0,5-0,6. Сверху добавляется KV-кэш, который растёт линейно с длиной контекста и числом одновременных запросов, плюс буферы, графы и оверхед рантайма.
| Модель | FP16 | 8-bit | 4-bit |
|---|---|---|---|
| 8B | около 16 ГБ | около 8 ГБ | около 5 ГБ |
| 32B | около 64 ГБ | около 32 ГБ | около 18 ГБ |
| 70B | около 140 ГБ | около 70 ГБ | около 40 ГБ |
| MoE на 100B+ параметров | 200 ГБ и выше | около 100-120 ГБ | около 60-70 ГБ |
Цифры в таблице относятся только к весам, без контекста. Контекст на 32 тысячи токенов для модели 70B легко добавляет десятки гигабайт, если KV-кэш не квантован. Отсюда и берётся смысл четырёх карт: суммарный объём около 128 ГБ, если ориентироваться на 32 ГБ на плату (сверяйте по спецификации), позволяет держать 70B в 8-битном виде с приличным контекстом или крупную MoE-модель в 4-битном, тогда как одна карта на 32 ГБ закрывает только 70B в сильной квантизации и короткий контекст.
Почему объём VRAM важнее чистой скорости
Когда модель помещается в память целиком, скорость упирается в пропускную способность VRAM, и здесь даже не самый быстрый чип выдаёт комфортные значения. Когда не помещается, часть слоёв уходит в системную память или на диск, и узким местом становится PCIe. Пользовательский опыт меняется качественно: вместо чтения ответа в реальном времени получаешь абзац за минуту. Поэтому при выборе железа под локальный инференс VRAM служит первичным фильтром, а производительность чипа смотрят уже внутри подходящего класса.
Как считать память под конкретную модель и контекст, включая KV-кэш и выгрузку экспертов, подробно разобрано в материале про 2× Radeon AI PRO R9700 и 64 ГБ DDR5 для Qwen 3.8: там та же арифметика, только на современной архитектуре и с двумя GPU.
Как четыре карты работают вместе
Есть два способа разделить модель. Tensor parallelism режет каждый слой на части между картами: каждая считает свой кусок, но после слоя нужен обмен результатами (all-reduce). Pipeline parallelism раздаёт картам разные слои: обмен идёт только на границах блоков, зато в каждый момент часть карт простаивает, и конвейер нужно заполнять несколькими одновременными запросами.
У AMD в этом сегменте нет аналога NVLink, обмен идёт через PCIe. Поэтому tensor parallel на медленном интерконнекте легко съедает весь выигрыш от распараллеливания: карты проводят время в пересылке, а не в счёте. На практике оба режима пробуют на конкретной модели и смотрят, что получилось, но при x4 на карту ставка на pipeline с батчем запросов обычно выглядит разумнее.
Линейного ускорения от четырёх карт не будет ни в одном режиме. Суммарная пропускная способность памяти растёт, но добавляются синхронизация, простой конвейера и неравномерность загрузки. Четыре GPU берут ради объёма памяти и параллельных запросов, а не ради кратного роста скорости одного потока.
Инженерные сложности сборки на четыре GPU
Собрать такую систему означает спроектировать серверную платформу, а не вставить четыре карты в корпус. Проблемы идут блоками: питание, охлаждение, линии PCIe, физическая компоновка.
Питание четырёх GPU
Считать нужно по формуле: суммарный TDP карт плюс 150-250 Вт на платформу (CPU, память, диски, вентиляторы) плюс запас 20-30% на пики. Пример без привязки к V620: четыре карты по 250 Вт дают 1000 Вт, платформа 200 Вт, итого 1200 Вт номинала, а значит нужен блок на 1500 Вт или два блока с разделением нагрузки.
Дальше начинается скучное, но критичное. Четыре карты с двумя 8-pin каждая требуют восьми разъёмов, и не каждый блок питания столько даёт. Переходники и разветвители на дешёвых проводах плавятся под длительной нагрузкой. Серверные блоки формата CRPS дешевле в пересчёте на ватт и рассчитаны на круглосуточную работу, но требуют своего посадочного места и переходных кабелей. Потребительский блок проще в монтаже, зато хуже переносит постоянную нагрузку на 80-90% мощности.
Охлаждение нескольких видеокарт в корпусе
Пассивная карта живёт за счёт направленного потока. Ей нужен канал с вентиляторами высокого статического давления, разделение зон впуска и выпуска, и зазор между платами, через который воздух реально проходит сквозь рёбра радиатора. Если карты стоят вплотную и дышат горячим воздухом соседа, третья и четвёртая в ряду греются заметно сильнее первой.
Готовое решение такой задачи описано в разборе переезда с Dell R640 на Supermicro X11SPA-T ради четвёртой Tesla T4: там как раз про нехватку слотов PCIe и про то, как организован продув пассивных карт в настольном корпусе. Серверные вентиляторы дают нужный поток, но шумят на 50-60 дБ, и жилая комната с такой сборкой несовместима.
Линии PCIe решают не меньше. Потребительская платформа AM5 отдаёт 24 линии: 16 на видеокарту, 4 на NVMe, 4 на чипсет. Четыре GPU на ней получают максимум x4 каждая через бифуркацию, и поддерживают её не все платы. Серверные и HEDT-платформы дают 128 линий и x16 на каждую карту, но стоят кратно дороже. Компромисс x8/x8 на плате вроде X570 или X870 Taichi разобран в материале про две Radeon 7900 XT/XTX на X570/X870 Taichi, и логика там та же: линии кончаются раньше, чем слоты.
Физическая компоновка добавляет последний слой проблем. Четыре карты длиной под 270-300 мм каждая, каждая с радиатором и весом в килограмм и больше, требуют несущей рамы, а не пластиковых стоек. Питание и PCIe-райзеры должны иметь запас по сечению и длине, а весь поток воздуха нужно направить так, чтобы горячий воздух не возвращался к впуску.
AI-генерация корпуса и 3D-печать: что это даёт на практике
Идея проекта в том, что корпус проектируется под конкретный набор железа: посадочные места под выбранные карты, каналы воздуха под пассивное охлаждение, крепления под конкретную плату. Нейросеть помогает быстро получить и перебрать геометрию, но не заменяет расчёт: нагрузки, температуры, допуски и жёсткость считает инженер, а не генератор.
Где печатное шасси выигрывает у готового
- Точная посадка под нестандартную конфигурацию. Готовое шасси под четыре серверные карты с пассивным охлаждением найти сложно и дорого.
- Воздушный тракт закладывается вместе с корпусом: перегородки, дефлекторы, направляющие под конкретные радиаторы.
- Быстрые итерации. Правка модели и перепечатка отдельной детали занимают вечер, а не неделю ожидания железа.
- Ремонтопригодность узлов: сломанную стойку или кожух печатают заново, не разбирая всю систему.
- Малые партии и редкие форм-факторы, под которые серийных корпусов не существует.
Где подход упирается в ограничения
- Термостойкость. PLA теряет жёсткость уже около 60 °C, PETG держится примерно до 75-80 °C, ABS и ASA до 95-100 °C, поликарбонатные смеси выше. Зона возле радиаторов пассивных карт легко прогревается до этих значений.
- Ползучесть под нагрузкой. Деталь, которая держит несколько килограммов и при этом нагрета, медленно деформируется месяцами.
- Прочность креплений. Стойки и кронштейны под карты с радиаторами нужно усиливать металлическими вставками или делать из металла.
- Точность и усадка. Отверстия под винты и посадочные места приходится подгонять, а разные партии пластика дают разную усадку.
- Размер печатной области. У типичного домашнего принтера это 220×220 мм, а карта длиной 270-300 мм в такую область не влезает: корпус печатают сегментами и склеивают или стягивают винтами.
- Время печати. Крупная деталь корпуса печатается 20-40 часов, и ошибка в модели стоит суток.
Практический вывод по корпусу: печатать несущую конструкцию под четыре карты целиком из пластика рискованно. Разумнее гибрид: рама из алюминиевого профиля держит вес и воспринимает нагрузки, а печатные элементы отвечают за воздушные каналы, кожухи, крепления вентиляторов и облицовку. Какой материал и принтер использовал PraxisOG, неизвестно, поэтому конкретный рецепт печати здесь не даю.
Программная сторона: запуск LLM на AMD GPU
Железо собирается один раз, а софт приходится чинить регулярно. База для AMD это ROCm: набор библиотек и драйверов, без которого не работают ни PyTorch, ни инференс-движки. Ключевая проверка перед покупкой: есть ли ваша карта в списке поддерживаемых устройств ROCm для той версии, которую вы собираетесь ставить. Серверные карты иногда поддерживаются лучше потребительских, иногда хуже, и угадывать здесь нельзя.
Дальше выбор движка. llama.cpp с HIP-бэкендом заводится на широком списке карт и удобен для GGUF-квантований, но на RDNA 2 уступает по скорости сопоставимым решениям на NVIDIA. vLLM поддерживает ROCm, однако набор поддерживаемых архитектур уже, и на старых картах приходится собирать из исходников или мириться с ограничениями. Кастомные форки под конкретную архитектуру существуют, но это отдельный проект с собственной поддержкой.
Форматы квантизации тоже зависят от архитектуры: то, что работает на RDNA 3 и новее, на RDNA 2 может не иметь аппаратной поддержки. Практический порядок действий: собрать стенд с одной картой, зафиксировать версии драйвера, ROCm и движка, прогнать на своей модели с нужной длиной контекста, и только потом докупать остальные три. Драйверы, ROCm и фреймворк лучше фиксировать версиями, иначе после обновления система может перестать запускаться.
Стоит ли повторять: кому подходит такой сервер
Подход имеет смысл, если совпадает несколько условий. Есть доступ к картам этого класса по вменяемой цене. Есть опыт работы с серверным железом: райзеры, бифуркация, продув, удалённое управление. Есть отдельное помещение, где шум вентиляторов никому не мешает. И есть задача, которая упирается именно в объём VRAM: крупная модель с длинным контекстом или несколько параллельных запросов.
Не подходит, если нужен тихий домашний ПК, простая настройка и предсказуемая поддержка софта из коробки. Здесь каждая из трёх составляющих требует ручной работы. Для сравнения: сборки на потребительских картах дают меньше памяти, зато дешевле, тише и лучше поддержаны. Пример такой логики, когда упираются в бюджет и числят каждый гигабайт, разобран в материале про 3× RX 9060 XT против 3× RTX 5060 Ti на 48 ГБ VRAM.
Отдельно стоит посмотреть на путь, где память набирают не четырьмя картами в одном корпусе, а несколькими машинами: в разборе домашнего стенда negus123 на 223 ГБ VRAM из четырёх систем видно, что разнородные GPU дают больший суммарный объём, но добавляют проблемы распределения модели и сетевого обмена.
Чек-лист перед стартом выглядит так:
- Открыть страницу продукта AMD и выписать: объём и тип памяти, TDP, число линий PCIe, требования к продуву.
- Сверить карту со списком поддерживаемых устройств в актуальной версии ROCm и с матрицей совместимости выбранного движка.
- Посчитать суммарное потребление с запасом 20-30% и проверить, сколько 8-pin разъёмов даёт блок питания.
- Спроектировать воздушный тракт под пассивные карты: направление потока, зазоры, статическое давление вентиляторов, зоны впуска и выпуска.
- Проверить платформу по линиям PCIe и поддержке бифуркации, иначе четыре карты получат x4 каждая.
- Решить, что в корпусе несёт нагрузку: металлическая рама или пластик с усилениями. Печать корпуса планировать сегментами, если деталь больше области печати.
- Собрать тестовый стенд на одной карте и только после успешного прогона модели закупать остальное.
Про сам проект PraxisOG остаётся сказать честно: подтверждён только факт публикации и общая идея. Конфигурация, температуры, потребление и скорость работы не раскрыты, поэтому воспринимать пост стоит как повод разобраться в теме, а не как готовую инструкцию к повторению.