Собираем домашний сервер для локальных LLM на доступных GPU (NVIDIA CMP 50HX)

Привет! Меня зовут Александр Щербаков, я DevOps-инженер в X5 Tech. В одной из прошлых статей я рассказывал о домашних серверах на потребительском железе. Сегодня поговорим о том, как моя лаборатория доросла до серверной платформы и двух CMP 50HX с 20 ГБ видеопамяти каждая.

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

Часть 1. С чего всё началось

Итак, что за CMP 50HX? Это майнинговая карта NVIDIA на кристалле TU102 — родственница RTX 2080 Ti, но с своими ограничениями. В штатном варианте у неё 10 ГБ видеопамяти, а у карт, о которых пойдёт речь, исходно был ограничен и интерфейс PCIe. Вот её подробная спецификация.

После спада майнингового бума такие карты стали попадаться на вторичке. Когда я искал варианты для себя, обычную версию на 10 ГБ можно было найти примерно за 5 тысяч рублей. Но однажды на маркетплейсе мне попался мод: недостающие компоненты на линиях PCIe допаяли, и карта получила PCIe 1.1 ×16. Главное же, вместо 10 ГБ на ней было уже 20 ГБ видеопамяти. Цена — 16 тысяч рублей за штуку.

В июне я купил такие в надежде получить суммарные 40 ГБ. Правда, две видеокарты не превращаются автоматически в одну с общей памятью: модель ещё нужно распределить между ними средствами движка.

Примерно через неделю приехала посылка с заветными картами. Продавец не обманул: по 20 ГБ видеопамяти и 16 линий PCIe у каждой.

Но тут я упёрся в новые ограничения со стороны своего железа. У меня был собран сервер на домашней ASRock B460M Pro4. У неё два разъёма формата ×16, но электрически они работают как ×16 и ×4. Первый подключён к процессору, а второй через чипсет. То есть два длинных слота ещё не означают две одинаковые по пропускной способности линии к GPU.

В двухкарточном режиме я столкнулся с заметным падением скорости. Подозревал и топологию платы, и ограничения самих карт, описанные в этих материалах: статья 1 и статья 2. Если кратко, речь шла об ограничениях вычислительной производительности CMP относительно обычных карт на TU102.

В первых запусках модели помещались в память одной карты, но по мере заполнения контекста заметно тормозили. На коротком запросе всё ещё выглядело неплохо, а вот длинного диалога уже приходилось ждать.

Я попробовал распределить модели между двумя GPU и перебрал четырёх-, пяти- и шестибитные кванты, но ожидаемого ускорения не получил. Что именно мешало сильнее — плата, PCIe 1.1 или ограничения CMP, тогда по отдельности не проверял.

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

В итоге собрал следующую конфигурацию:

• Новая материнская плата TYAN S8030GM2NE под процессоры EPYC 2 и 3 поколения

• Сам процессор EPYC 7K62 — 48 физических ядер и 96 потоков с частотами от 2,6 до 3,3 ГГц (б/у)

• Оперативная память DDR4-2133 ECC: восемь модулей по 16 ГБ, суммарно 128 ГБ. На модулях маркировка Huawei, чипы Micron. Взял б/у: хотелось что-то понятное по происхождению и без лишней переплаты.

• Серверный NVMe SSD Samsung формата 22110 на 4 ТБ, тоже б/у. Наработка — около 3000 часов. При покупке такого диска я бы смотрел ещё на SMART, объём записанных данных и ошибки: одних часов мало.

• Модульный блок питания DeepCool на 1200 Вт — его купил новым.

• Процессорный кулер ARCTIC Freezer 4U-M Rev. 2 под сокет SP3 и корпусные вентиляторы ARCTIC: два на 140 мм и один на 120 мм.

• Корпус Jonsbo N5. Всё железо в него поместилось, а заодно появились 12 мест под HDD — лаборатория сама себя не расширит.

Пару слов о материнке. Здесь пять слотов PCIe 4.0 ×16, восемь каналов памяти и BMC с удалённой консолью. По дискам тоже есть куда расти: двенадцать SATA-портов выведены через три Mini-SAS HD, ещё два — отдельными разъёмами. Для моего домашнего сервера это уже совсем другой простор по сравнению с прежней платой.

Комплектные вентиляторы оказались слишком шумными, поэтому заменил их на ARCTIC. У штатных было трёхпиновое подключение, без PWM. Возможность регулировать их напряжением зависит от платы.

Часть 2. Разблокировка карт и первые нормальные результаты

Пока я собирал все комплектующие по онлайн-площадкам и продавал железо, которое у меня было, наступил сентябрь 2026 года. Просматривая интернет, я наткнулся на репозиторий с патчами драйвера NVIDIA для Linux. Проект снимает часть ограничений вычислений и позволяет включить PCIe Gen2 на поддерживаемых CMP 50HX. 

Установил Proxmox, создал виртуальную машину, пробросил обе GPU и применил патчи. Наконец карты заработали так, что захотелось вернуться к черновику статьи.  Отдельный idle-governor управляет P-state в простое. В моей конфигурации потребление снизилось примерно с 65 до 15–20 Вт на карту. Дальше покажу, что получилось в тестах.

Сразу разделю две вещи: 20 ГБ памяти и 16 линий PCIe у моих карт появились после аппаратной переделки. Патч драйвера снимает другие ограничения. Повторять его установку лучше по инструкции проекта, с проверкой своей ревизии карты и версии драйвера.

Сравнение модифицированной CMP 50HX (20 ГБ) с RTX 2080 Ti (22 ГБ)

Для ориентира сравню характеристики с модифицированной RTX 2080 Ti на 22 ГБ. Кристаллы у них одного семейства — Turing TU102, но у CMP меньше вычислительных блоков и уже шина памяти. Саму RTX в этих тестах я не запускал.

Тестовая виртуальная машина

В виртуальную машину поставил Docker и поднял BeeLlama.cpp — форк llama.cpp с доработками для ускорения инференса. В таблице выше указаны текущие 8 vCPU и 16 GiB RAM. В журнале первых замеров ВМ имела 16 vCPU и 32 GiB, поэтому старые результаты и контрольный прогон ниже подписаны отдельно.

Как читать результаты

Чтобы дальше не путаться: prefill — обработка входного текста, decode — генерация новых токенов. В тестах с растущим контекстом часть входа уже лежит в кэше, а grow prefill показывает обработку добавленной части. Поэтому по нему нельзя узнать, сколько займёт загрузка всего документа с нуля.

Размеры контекста пишу в токенах: 32K — это 32768, а 256K — 262144. Точка 260000 до полного окна немного не доходит. Расход видеопамяти беру из nvidia-smi в MiB; 1024 MiB = 1 GiB. Это память, занятая сервером, а не размер файла модели на диске.

Часть 3. Проверяем модели

Настройки, команды запуска и данные для пересчёта результатов собрал в репозитории GitLab. Начать можно с инструкции в current/README.md: там есть Compose и готовые .env для каждой модели. Для своих замеров — benchmarks/README.md, а сводные результаты лежат в BENCHMARKS.md.

Сначала запустил модель без MTP, затем включил Multi-Token Prediction. Смысл простой: небольшой драфт-модуль предлагает продолжение, а основная модель проверяет его. Если предложения часто подходят, за один шаг удаётся продвинуться дальше. Но сама проверка тоже занимает время, поэтому глубину MTP ещё предстояло подобрать.

Qwen3.8-27B IQ4_NL: первые замеры на одной карте

Без MTP

• Контекстное окно сервера: 131208 (128K+)

• KV Cache: q4_0 / q4_0

• Занятая VRAM: 18223 MiB / 20480 MiB (Свободный запас: 2257 MiB)

• Все пять точек прошли без ошибок. Здесь и в следующих лесенках IQ4_NL контекст заполнен повторяющимся токеном. Такой тест показывает, как меняется скорость с заполнением кэша (скорость работы с настоящим документом может отличаться).

С MTP: draft-n-max 1

На 131072 токенах с MTP получилось 20.21 токена/с против 12.14 без него — прирост примерно 66.5%. Для одной карты результат меня уже устраивал.

Qwen3.6-35B-A3B: IQ4_NL на одной и двух картах

Модель: Qwen3.6-35B-A3B-UD-IQ4_NL.gguf 

Это MoE-модель: всего около 35 млрд параметров, но для каждого токена используется лишь часть. В ней 40 основных слоёв, 256 маршрутизируемых экспертов, из которых выбираются восемь, и один общий эксперт. Вот что это даёт по скорости и памяти.

Короткий тест: одна и две GPU, с MTP и без него

Что получилось с IQ4_NL

В коротком тесте на одной карте модель выдала 93.36 токена/с без MTP и 120.32 с ним. Принято 186 из 192 предложенных драфт-токенов — 96.9%. 

С MTP модель заняла 17681 MiB из 20480 MiB, осталось 2799 MiB. То есть для короткого запроса одной карты хватило с запасом.

На двух картах в том же коротком тесте занято 8825 и 9239 MiB. Скорость — 118.01 токена/с, почти как на одной GPU. Дальше покажу, как этот запас памяти помогает при росте контекста.

IQ4_NL: увеличиваем контекст

Две GPU: до 260000 токенов, split-mode layer

В этой серии MTP помогает сильнее по мере заполнения контекста: прирост с 38.7% на 32768 токенах до 86.6% на 260000. В последней строке это 22.32 и 41.64 токена/с.

Одна GPU: до 192000 токенов

Одна карта или две?

На 32768 токенах с MTP получилось 95.84 токена/с на одной карте и 94.60 на двух — практически рядом. Вторая карта даёт прежде всего запас памяти, а не удвоение скорости одного ответа.

На одной карте я дошёл до 192000 токенов: свободно осталось 715 MiB. На двух при 260000 токенов занято 11650 и 12893 MiB — запас заметно больше. Смотреть нужно на обе карты: свободная память одной не спасёт от переполнения другой.

Qwen3.6-35B-A3B: более тяжёлый квант Q6_K

Модель: Qwen3.6-35B-A3B-UD-Q6_K.gguf

Конфигурации:

• 2 GPU: Полный оффлоад в VRAM (-ngl 99, split-mode layer). С MTP занято 14411 и 14595 MiB из 20480 MiB на каждой карте.

• 1 GPU: часть модели на GPU (-ngl 25), остальная — в системной RAM.

Q6_K: полный GPU-оффлоад и гибридный режим

 IQ4_NL и Q6_K: сравнение конфигураций

 Что это означает для моей сборки

На одной карте IQ4_NL поместился без CPU-оффлоада и в коротком тесте с MTP выдал 120.32 токена/с. Гибридная конфигурация Q6_K с -ngl 25 дала 29.03 токена/с без MTP и 42.93 с ним. 

На двух картах Q6_K уже поместился в VRAM целиком. С MTP получил 116.16 токена/с против 118.01 у IQ4_NL — разница около 1.6%. Вот поэтому мне пригодилась вторая карта: можно взять более тяжёлый квант и обойтись без вычислений на CPU.

Qwen3.6-35B-A3B Q6_K_XL: что получилось на длинном входе

Для следующей серии взял UD-Q6_K_XL из репозитория Unsloth и выставил окно 262 144 токена. Суффикс XL (Extra Large) обозначает более объёмный вариант квантования: при базовой 6-битной схеме часть весов сохраняется с повышенной точностью, чтобы уменьшить потери качества. Точное имя файла и SHA256 указаны в MODELS.md.

Распределение VRAM при окне 256K в исходной серии:

• GPU 0: 17945 MiB / 20480 MiB (Свободный запас: 2535 MiB)

• GPU 1: 19487 MiB / 20480 MiB (Свободный запас: 993 MiB)

• Суммарно: 37432 MiB из 40960 MiB. 

Q6_K_XL: исходная лесенка контекста с MTP

Оставил draft-n-max 2, temperature 0.6, top_p 0.95, top_k 20, min_p 0 и включённые рассуждения. На каждой точке — один ответ на 400 токенов, все они ушли в рассуждения. Есть особенность скрипта: названия шагов 4K–250K не совпали с реальной длиной. Поэтому во втором столбце привожу вход по счётчикам сервера. Последний запрос даже короче предыдущего — так сохранилось в исходном результате.

Ornith-1.5-35B-A3B: Q6_K на двух картах

Модель: Ornith-1.5-35B-Q6_K.gguf

По устройству Ornith похожа на предыдущую MoE: около 35 млрд параметров, из них около 3 млрд активны на токен. В GGUF — 40 основных слоёв: 30 DeltaNet и 10 обычного внимания, плюс один MTP-блок. Проверяю её отдельно, со своим файлом весов и настройками.

Контекстное окно сервера: 262144 токена (полные 256K).

Параметры инференса: --split-mode layer --flash-attn on --cache-type-k q4_0 --cache-type-v q4_0 --spec-type draft-mtp --spec-draft-n-max 2

Сколько памяти занял сервер с окном 262144

• GPU 0: 17577 MiB / 20480 MiB (Свободный запас: 2903 MiB / 2.84 GiB)

• GPU 1: 17837 MiB / 20480 MiB (Свободный запас: 2643 MiB / 2.58 GiB)

• Свободно 5546 MiB на двух картах, примерно 5.42 GiB. В этой серии ошибок нехватки памяти не было.

Ornith: заполняем контекст, draft-n-max 2

Что видно по результатам Ornith

Здесь скрипт повторяет один token-id, а затем трижды запускает генерацию 128 токенов на уже заполненном кэше. Знак ± — разброс скорости этих трёх повторов (стандартное отклонение). Последнюю точку в таблицах Ornith обозначаю 256K по размеру окна сервера, но фактически вход в ней — 260000 токенов. Все 84 предложенных драфт-токена были приняты, но такой синтетический вход не проверяет качество кода или ответов модели.

В последней точке получилось 53.42 токена/с. Полный ответ на 128 токенов занял в среднем 3.11 с, когда контекст уже был в кэше. Это не время загрузки всего входа с нуля и не задержка до первого токена.

Ornith: увеличиваем draft-n-max с 2 до 3

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

 На длинном входе глубина 3 оказалась быстрее: 64.46 против 53.42 токена/с на 260000 токенах. Повторная проверка на нынешней ВМ дала близкие числа — 64.32 и 53.38. Но на входе 4096 токенов глубина 3 уже проиграла: 117.54 против 138.27. Так что просто поставить значение побольше и забыть не получится.

Что получилось в итоге

Я давно хотел погрузиться в тему локального инференса и получить побольше видеопамяти за разумные деньги. Брать Tesla V100 не хотелось: для Volta последней поддерживаемой линейкой остаётся CUDA 12.x, а с вариантами SXM2 пришлось бы отдельно решать вопрос переходников и охлаждения. Но повезло найти репозиторий с разблокировкой CMP. Для моей лаборатории доработанные CMP 50HX оказались удачным стартом. Причём начать можно и с одной карты. Qwen3.6-35B-A3B в IQ4_NL у меня целиком поместилась в её видеопамять.

Из практических задач я успел попробовать установку production-like Kubernetes на Proxmox через Terraform. Одинаковое задание дал Ornith и Qwen3.8-27B. В этой задаче Qwen подошёл мне лучше. С ним получилось справиться примерно за 1,5 часа, а с Ornith — за 2,5. 

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

Для подготовки этой статьи были использованы следующие ресурсы:

• Репозиторий от Xrip по разблокировке CMP50/90HX https://github.com/xrip/cmp50hx-unlock

• Статьи с Хабра статья 1 и статья 2

• ChatGPT и Antigravity, которые по итогу помогли с тестами, ресерчем и составлением конфигов для моего личного репозитория к этой статье