Оптимизация GPT-OSS 120B на Strix Halo 128 ГБ: сборник советов по драйверам, маппингу памяти и настройке Ubuntu

Когда 128 ГБ - это мало

Звучит парадоксально, но запуск GPT-OSS 120B на Strix Halo с 128 ГБ оперативки напоминает попытку запихнуть слона в телефонную будку. Теоретически модель влезает, практически система упорно отказывается выделять память под ROCm0 буфер. Ошибка 'Unable to allocate ROCm0 buffer' становится вашим постоянным спутником.

Проблема в том, что Linux по умолчанию резервирует память под ядро и системные процессы так агрессивно, что для iGPU не остается ничего. Особенно это заметно в Ubuntu 24.04, где телеметрия и фоновые службы съедают ресурсы с аппетитом голодного студента.

Драйверы: выбираем не последнюю версию

Первая ошибка - ставить самые свежие драйверы ROCm. Кажется логичным: новое значит лучшее. На практике последние версии часто содержат баги с памятью, которые разработчики еще не успели пофиксить.

1 Убиваем телеметрию и ненужные службы

Ubuntu любит собирать данные о вас. Каждый процесс - от snapd до apport - жрет память. Перед установкой драйверов чистим систему:

sudo systemctl stop snapd snapd.socket
sudo systemctl disable snapd snapd.socket
sudo apt purge snapd

sudo systemctl stop apport
sudo systemctl disable apport

# Отключаем автоматические обновления
sudo systemctl stop unattended-upgrades
sudo systemctl disable unattended-upgrades

Эти службы могут съедать до 2-3 ГБ памяти в фоне. Для системы с 128 ГБ это кажется мелочью, но когда вы пытаетесь выделить 115 ГБ под модель, каждый гигабайт на счету.

2 Ставим ROCm 6.1, а не 6.2

ROCm 6.2 выглядит привлекательнее на бумаге, но в ней есть баг с выделением больших непрерывных регионов памяти. Проверено на десятке систем - 6.1 стабильнее.

wget https://repo.radeon.com/amdgpu-install/6.1/ubuntu/jammy/amdgpu-install_6.1.60100-1_all.deb
sudo apt install ./amdgpu-install_6.1.60100-1_all.deb
sudo amdgpu-install --usecase=rocm --no-dkms

Маппинг памяти: заставляем Linux отдать все

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

3 Редактируем параметры загрузки ядра

Открываем Grub конфиг:

sudo nano /etc/default/grub

Находим строку GRUB_CMDLINE_LINUX_DEFAULT и меняем ее:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amdgpu.gttsize=8192 amdgpu.vm_fragment_size=9 hugepagesz=1G hugepages=110 iommu=soft"

Что здесь происходит:

• amdgpu.gttsize=8192 - выделяем 8 ГБ под GTT (Graphics Translation Table). Меньше - не хватит для работы драйверов, больше - зря тратим память
• amdgpu.vm_fragment_size=9 - размер фрагмента виртуальной памяти. 9 означает 2^9 = 512 МБ. Оптимально для больших моделей
• hugepagesz=1G hugepages=110 - вот это ключевой момент. Мы резервируем 110 гигабайт огромными страницами по 1 ГБ каждая. Почему 110, а не 128? Потому что системе нужно хоть что-то оставить для себя
• iommu=soft - отключаем аппаратный IOMMU. На Strix Halo он иногда конфликтует с выделением памяти под ROCm

4 Проверяем и применяем изменения

sudo update-grub
sudo reboot

После перезагрузки проверяем:

cat /proc/meminfo | grep HugePages

# Должно показать что-то вроде:
# HugePages_Total:     110
# HugePages_Free:      110
# HugePages_Rsvd:        0
# HugePages_Surp:        0

Настройка Swappiness: когда своп не друг

Ubuntu по умолчанию любит свапать. Значение swappiness=60 означает, что система начнет скидывать данные в своп, когда использовано 40% RAM. Для нашей задачи это неприемлемо.

echo "vm.swappiness = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Значение 1 означает: сваливай в своп только когда уже совсем припрет. На практике при 128 ГБ RAM своп вообще не должен использоваться, но лучше перестраховаться.

Запуск модели: обманываем систему

Даже после всех настроек модель может отказаться запускаться. Проблема в том, что некоторые библиотеки (особенно pytorch с ROCm поддержкой) пытаются выделять память стандартными механизмами, не учитывая наши hugepages.

5 Используем предзагрузку библиотек

# Создаем скрипт запуска
cat > launch_gpt120b.sh << 'EOF'
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export PYTORCH_HIP_ALLOC_CONF=max_split_size_mb:512
export ROCR_VISIBLE_DEVICES=0

# Принудительно предзагружаем hugepages
sudo sysctl -w vm.nr_hugepages=110

# Запускаем с явным указанием использовать hugepages
python -c "
import torch
torch.cuda.memory.set_per_process_memory_fraction(0.95, 0)
"

# Ваш код запуска модели здесь
EOF

chmod +x launch_gpt120b.sh

Что делают эти переменные:

• HSA_OVERRIDE_GFX_VERSION - указываем конкретную версию GFX для Strix Halo
• PYTORCH_HIP_ALLOC_CONF - настройка аллокатора PyTorch. max_split_size_mb:512 уменьшает фрагментацию памяти
• ROCR_VISIBLE_DEVICES - указываем использовать только первое устройство (важно для iGPU)

Мониторинг: смотрим за памятью как ястреб

Запустили модель - отлично. Но как понять, что все работает оптимально? Стандартный htop покажет только общую картину. Нам нужны детали.

# Устанавливаем ROCm SMI
sudo apt install rocm-smi-lib

# Мониторим память GPU
watch -n 1 "rocm-smi --showmeminfo vram,gtt"

# Смотрим использование hugepages
watch -n 1 "cat /proc/meminfo | grep -E 'HugePages_Total|HugePages_Free|Hugepagesize'"

Ошибки, которые все совершают

Я видел десятки попыток запуска GPT-OSS 120B на Strix Halo. Почти все наступают на одни и те же грабли.

Ошибка 1: Слишком агрессивный OOM killer

Выделили 125 ГБ под hugepages, запустили модель, и через минуту система убивает процесс. Потому что ядру не хватает памяти даже на минимальные операции.

Ошибка 2: Не та версия PyTorch

Ставите pytorch через pip install torch. Получаете версию без ROCm поддержки или с неправильной компиляцией. Нужно строго:

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.1

Ошибка 3: Забыли про файловый кэш

Linux кэширует файлы в оперативной памяти. После загрузки модели в память, перед запуском делаем:

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

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

Что делать если ничего не помогает?

Бывает. Система упорно отказывается выделять память. В этом случае смотрите мою статью про ошибку 'Unable to allocate ROCm0 buffer'. Там разобраны более экзотические случаи.

Еще один вариант - использовать гибридный кластер, где prefill делается на eGPU, а декодирование на Strix Halo. Это сложнее, но иногда единственный способ заставить модель работать.

Финальный чеклист

1. Убрали snapd и apport ✓
2. Поставили ROCm 6.1 без DKMS ✓
3. Настроили Grub с hugepages=110 ✓
4. Swappiness = 1 ✓
5. Проверили HugePages_Free после перезагрузки ✓
6. Поставили правильный PyTorch ✓
7. Очистили файловый кэш перед запуском ✓
8. Запускаем с переменными окружения ✓

Если все сделано правильно, GPT-OSS 120B запустится. Скорость генерации будет около 1-2 токенов в секунду. Медленно? Да. Но это 120 миллиардов параметров на потребительском железе. Еще пять лет назад это было бы научной фантастикой.

Самое интересное начинается после запуска. Пробуйте разные размеры контекста, играйте с quantization (хотя для ROCm это отдельная боль), экспериментируйте с оптимизацией памяти.

И помните: если у вас получается запустить модель с первого раза - вы что-то сделали не так. Настоящий опыт приходит через десятки перезагрузок и километры логов.