Загрузка 0
ПОДЕЛИТЬСЯ

Мой блог

Листай вниз

Разблокировка PCIe Gen2 x16 на NVIDIA CMP 90HX: от пайки конденсаторов до хака драйвера с помощью ИИ

Разблокировка PCIe Gen2 x16 на NVIDIA CMP 90HX: от пайки конденсаторов до хака драйвера с помощью ИИ

Перед вами продолжение моих технических экспериментов над майнинговыми видеокартами NVIDIA CMP 90HX. В первой части проекта я собрал домашний вычислительный сервер на базе двух процессоров Intel Xeon и нескольких бывших в употреблении видеокарт. Главная цель заключалась в том, чтобы получить большой объем видеопамяти и внушительную вычислительную мощность за минимальный бюджет, запустив сложные локальные нейросети без арендной платы и сторонних облачных сервисов.

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

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

Реклама
Тестирование пропускной способности шины PCIe в терминале
Результаты тестирования скорости передачи данных через CUDA DMA test.
График зависимости производительности LLM от скорости шины PCIe
Сравнение скорости работы моделей в режимах Layer Split и Tensor Split.
Компоновка корпуса сервера с видеокартами и гофрой кондиционера
Внутренняя компоновка корпуса с установленными видеокартами.
Печатная плата NVIDIA CMP 90HX с крупным планом чипа GA102
Аппаратная платформа CMP 90HX на базе графического процессора GA102.

Экстремальное охлаждение: подключение мобильного кондиционера

После съема вычислительных ограничений видеокарты начали работать в полную силу, что сразу привело к ощутимому выделению тепла. До модернизации системы охлаждения показатели температур выглядели так:

  • В режиме простоя: около 60 °C;
  • Под полной нагрузкой: до 90 °C.

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

Результаты замера температур после модернизации:

Подключение напольного кондиционера к серверной системе
Подвод охлажденного воздуха от кондиционера к корпусу сервера.
  • В режиме простоя: порядка 9 °C;
  • Под предельной нагрузкой: около 60 °C.

Снижение температуры GPU в простое до 9 градусов позволило полностью закрыть вопрос перегрева и подготовить платформу к дальнейшим аппаратным и программным тестам.

Особенности распределения LLM по видеокартам: Layer Split против Tensor Split

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

  • Prefill (обработка входящего контекста): этап, на котором модель прочитывает весь переданный запрос. Когда ИИ-агент получает системный промпт, исходный код драйверов, логи ядра и историю диалога, всю эту информацию необходимо единовременно прокачать через нейросеть. Чем быстрее происходит этот процесс (разница между 250 и 2000 tok/s критична), тем оперативнее агент приступит к ответу.
  • Decode (генерация ответа): непосредственно потоковый вывод токенов. Именно эту скорость (например, 30–70 токенов в секунду) обычно указывают в бенчмарках.

В инструментарии llama.cpp предусмотрены различные методы распределения модели между несколькими GPU. При режиме Layer split слои нейросети последовательно распределяются по видеокартам: первая карта обрабатывает свой блок и передает промежуточный результат следующей. При режиме Tensor split каждая крупная тензорная операция распараллеливается между всеми GPU одновременно. Это дает высокую эффективную мощность, но резко увеличивает объем межкарточного обмена данными.

Реклама

Поскольку у CMP 90HX отсутствует интерфейс NVLink, весь этот интенсивный трафик вынужден проходить исключительно через шину PCIe.

Процесс пайки конденсаторов PCIe на печатной плате CMP 90HX
Процесс восстановления недостающих конденсаторов линии PCIe x16 на видеокарте.

Важное примечание по методике тестирования

Все приведенные ниже эксперименты проводились последовательно в течение длительного времени. В процессе исследований конфигурация тестового окружения и версии нейросетей незначительно менялись (в частности, применялись модели семейства Qwen3.8–27B-Heretic со всеми слоями в VRAM). Разница в отдельных прогонах может составлять доли токенов, однако ключевые изменения показателей на десятки процентов наглядно отражают общую динамику и масштабы прироста производительности.

Первое тестирование Tensor Split: затык в шине PCIe

На момент первичного теста связка состояла из 5 видеокарт CMP 90HX (всего доступно 49 383 MiB VRAM), на которых уже был активирован вычислительный unlock через V67. Четыре карты работали в режиме PCIe x8, а одна — в режиме PCIe x4.

Результаты замеров скорости:

  • Layer split: Prefill — 1992.67 tok/s, Decode — 23.76 tok/s;
  • Tensor split: Prefill — 268.46 tok/s, Decode — 31.93 tok/s.

Режим Tensor split продемонстрировал отличный прирост скорости генерации ответов (Decode вырос на 34.4%), однако обработка входящего контекста (Prefill) просела на 86.5%. Медленная шина PCIe стала бутылочным горлышком, заблокировавшим нормальный обмен данными между ускорителями.

Аппаратная доработка: запаивание недостающих линий PCIe x16

Видеокарта CMP 90HX спроектирована на графическом процессоре GA102. Текстолит платы и сам разъем разведены под полноценные 16 линий PCIe. Однако из экономии или маркетинговых ограничений производитель не распаял разделительные конденсаторы на дополнительных передающих линиях.

Вывод команды dmesg в Linux с подтверждением режима PCIe Gen2 x16
Консоль Linux подтверждает успешное обучение линии PCIe на скорости Gen2 x16.

Взяв в руки паяльник, я допаял отсутствующие SMD-конденсаторы емкостью 220 нФ на оставшиеся линии, физически выведя все карты на полноценный режим PCIe x16. Напомню пропускную способность линий стандартной шины PCIe Gen1 с учетом кодирования 8b/10b (полезная скорость около 250 МБ/с на линию в одну сторону):

  • Gen1 x4 — ~1 ГБ/с;
  • Gen1 x8 — ~2 ГБ/с;
  • Gen1 x16 — ~4 ГБ/с.

Прирост производительности после разблокировки физических 16 линий

Повторное проведение тестов после аппаратного ремонта показало следующие результаты:

Для режима Layer split изменения оказались минимальными (Prefill вырос до 2098.89 tok/s, то есть +5.3%, а Decode — до 23.95 tok/s, +0.8%), так как этот режим слабо зависит от постоянного межпроцессорного обмена.

Реклама

Режим Tensor split показал существенный рывок:

Интерфейс консольной утилиты CMP90HX PWNER
Автоматическая утилита CMP90HX PWNER для патчинга драйверов и разблокировки карт.
  • Prefill: рост с 268.46 до 489.16 tok/s (прирост +82.2%);
  • Decode: рост с 31.93 до 37.34 tok/s (прирост +16.9%).

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

Борьба за Gen2: вывод скорости шины из режима 2.5 GT/s

Несмотря на наличие 16 физических линий, контроллер карты продолжал работать на базовой скорости 2.5 GT/s (PCIe Gen1), выдавая максимум 4 ГБ/с суммарной пропускной способности. Переход на Gen2 (5.0 GT/s) позволил бы удвоить этот показатель до 8 ГБ/с.

Попытки использовать существующие в сообществе скрипты (вроде модификаций rejoin15 и rejoin16) к успеху не привели. В открытых источниках заявлялась работа Gen2 на 4 линиях (x4) с пропускной способностью около 1.7 ГБ/с, но подтвержденного рабочего режима Gen2 x16 для CMP 90HX до сих пор не существовало. Карта упорно возвращалась к стандартам Gen1.

Почему простая запись значений в регистры не работает

PCIe-контроллер внутри чипов NVIDIA защищен несколькими уровнями безопасности. Внутренние регистры XVE, маски привилегий и служебные сопроцессоры блокируют прямое изменение конфигурации из ОС. Для преодоления этого барьера пригодился опыт из предыдущей статьи: использованный ранее механизм V67 открывал доступ к привилегированному контексту GPU через маску FEAT_OVR_PLM.

ИИ-агент на службе инженера: как нейросеть взломала собственный драйвер

Чтобы ускорить процесс поиска нужной комбинации регистров, я применил необычный подход. На четырех картах основного сервера была развернута локальная языковая модель. Отдельно был собран тестовый стенд с пятой картой CMP 90HX, к которому ИИ-агент получил прямой доступ по SSH.

Сложилась уникальная ситуация: четыре графических процессора NVIDIA под управлением локальной нейросети исследовали и модифицировали драйвер пятой карты NVIDIA. Имея неограниченный запас токенов локального сервера, агент анализировал исходный код open-source драйверов, менял регистры, пересобирал модули ядра и перезагружал стенд. Заменяя человеку рутинную работу, автономный ИИ-инженер нашел правильную последовательность инициализации всего за один час.

Технические подробности патча и последовательность инициализации

Исследования проводились на базе модуля NVIDIA Open Kernel Module 610.43.03. Выяснилось, что при прямой загрузке модифицированного драйвера «на холодную» карта вылетала с ошибкой RmInitAdapter. Рабочий алгоритм потребовал поэтапного выполнения:

  1. Штатная инициализация видеокарты стандартным драйвером NVIDIA.
  2. Передача управления пропатченному модулю ядра.
  3. Снятие защитных масок привилегий через V67/fwsec.
  4. Принудительное выполнение FLR (Function Level Reset) для программного сброса устройства.
  5. Повторная инициализация и запуск процедуры обучения линии (PCIe retrain).

Ключевую роль сыграли следующие области регистров GPU:

  • Регистр 0x823800 (FEAT/PLM): снятие ограничений путем записи маски 0xffffffff;
  • Регистр 0x088fe8 (XVE protection): перевод в значение 0xffffffff;
  • Селекторы скоростей: ss0 = 0x88888888, ss1 = 0x00000008.

После выполнения сброса FLR и повторного обучения линии операционная система Linux зафиксировала переключение шины в полноценный режим PCIe Gen2 x16 (5.0 GT/s).

Верификация скорости: результаты теста CUDA DMA

Для подтверждения реальной пропускной способности шины был запущен синтетический тест CUDA DMA bandwidth test с зафиксированными страницами RAM:

  • Передача RAM -> GPU: 6.33 GB/s;
  • Передача GPU -> RAM: 6.40 GB/s.

Физический предел шины PCIe Gen1 x16 составляет около 4 ГБ/с, поэтому получить значения выше 6.3 ГБ/с на старой верстке невозможно. Данный результат гарантирует, что шина действительно работает на скорости Gen2 с учетом накладных расходов протокола DMA.

Итоги проекта и подготовка к оверклокингу

На текущий момент на ускорителях CMP 90HX успешно реализован полный комплекс модификаций: активированы все вычислительные блоки, запаяны 16 физических линий PCIe, включен режим Gen2 и настроена мощная система охлаждения. Под длительной нагрузкой каждая карта потребляет порядка 200 Вт при лимите в 250 Вт, а температуры не превышают 60 °C. Это создает отличные условия для следующего этапа — разгона графического ядра по частоте.

Автоматизация для сообщества: утилита CMP90HX PWNER

Чтобы другим энтузиастам не пришлось проходить весь этот сложный путь с отладкой и сборкой драйверов, я объединил все наработки и код ИИ-агента в единую удобную утилиту — CMP90HX PWNER.

Проект выложен в открытый доступ на GitHub: https://github.com/iatethelogs/cmp90hx_pwner. Утилита в автоматическом режиме выполняет установку модифицированного драйвера, снимает вычислительные блокировки V67, переводит шину в режим Gen2 x16 и проводит финальное тестирование системы.

Источник: habr.com

01.