Бюджетный кластер на AMD Strix Halo для LLM до 345B: инструкция, тесты и подводные камни

Зачем собирать кластер на потребительском железе?

Вы смотрите на ценники серверных A100/H100 и думаете: "Ну нет, это не для меня". Я тоже так думал. Пока не собрал кластер из трех ноутбуков на Strix Halo, который тянет модели до 345 миллиардов параметров. За 15% стоимости одного H100.

Проблема не в том, что железо дорогое. Проблема в том, что все пытаются решать задачу в лоб: одна большая карта для одной большой модели. А что если разбить модель на несколько маленьких машин? Звучит безумно. Работает идеально.

Архитектура: почему Strix Halo идеален для кластера

Strix Halo — это не просто APU. Это монстр с 128GB унифицированной памяти и 40 вычислительных единиц RDNA 3.5. Ключевое слово — "унифицированная". Нет разделения на VRAM и RAM. Вся память доступна для вычислений.

Но есть нюанс. Один Strix Halo не потянет модель на 345B. Даже с 128GB памяти. Потому что помимо весов модели нужна память под KV-cache, промежуточные активации, контекст. В статье про ошибку ROCm0 buffer я подробно разбирал, почему даже 120B модель может не влезть.

Решение? Разделить модель между несколькими узлами. Каждый узел получает свой слой (или группу слоев). llama.cpp RPC делает это прозрачно.

Что вам понадобится

Да, вам нужно минимум два ноутбука. В идеале — три. Почему не четыре? Потому что с четырьмя узлами латентность сети начинает съедать все преимущества. Проверено.

1 Подготовка каждого узла

Сначала настраиваем каждый ноутбук по отдельности. Если пропустите этот шаг, кластер не заработает. Гарантированно.

Устанавливаем ROCm 6.1+ (не 5.x, там нет поддержки Strix Halo):

# Добавляем репозиторий ROCm
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

# Устанавливаем ROCm без DKMS (меньше проблем)
sudo amdgpu-install --usecase=rocm --no-dkms

# Проверяем установку
rocminfo | grep -i "agent"

Если видите ошибки с выделением памяти — не паникуйте. Это нормально для Strix Halo. Решение есть в статье про решение ошибок с памятью.

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

# Добавляем в ~/.bashrc
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export ROCR_VISIBLE_DEVICES=0
export HIP_VISIBLE_DEVICES=0
export PYTORCH_HIP_ALLOC_CONF=max_split_size_mb:512

2 Сборка llama.cpp с поддержкой RPC

Стандартный llama.cpp из репозитория не подойдет. Нужна версия с включенным LLAMA_RPC:

# Клонируем и переключаемся на ветку с RPC
git clone https://github.com/ggerganov/llama.cpp
git checkout -b rpc-experimental origin/rpc-experimental

# Собираем с поддержкой ROCm
make clean
make -j$(nproc) LLAMA_HIPBLAS=1 LLAMA_RPC=1

Проверяем, что RPC включен:

./server --help | grep -i rpc
# Должна быть строка: --rpc-serve [host]:port

3 Настройка сети и статических IP

DHCP — враг кластера. Нужны статические IP. На каждом узле:

# Редактируем netplan конфиг
sudo nano /etc/netplan/01-network-manager-all.yaml

# Добавляем (адаптируйте под вашу сеть):
network:
  version: 2
  ethernet:
    enp3s0:
      dhcp4: no
      addresses: [192.168.1.101/24]  # Для узла 1
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

# Применяем
sudo netplan apply

Узлы должны пинговать друг друга. Проверяем:

ping 192.168.1.102  # С узла 1 на узел 2
ping 192.168.1.103  # С узла 1 на узел 3

4 Запуск слейв-узлов

На узлах 2 и 3 (слейвы) запускаем сервер в режиме RPC:

# На узле 2 (IP: 192.168.1.102)
./server -m ./models/deepseek-v3.2-q4_k_m.gguf \
  --rpc-serve 192.168.1.102:8081 \
  --n-gpu-layers 40 \
  --ctx-size 8192 \
  --parallel 4 \
  --rpc-slot-count 4

# На узле 3 (IP: 192.168.1.103)
./server -m ./models/deepseek-v3.2-q4_k_m.gguf \
  --rpc-serve 192.168.1.103:8081 \
  --n-gpu-layers 40 \
  --ctx-size 8192 \
  --parallel 4 \
  --rpc-slot-count 4

5 Запуск мастер-узла и подключение слейвов

На узле 1 (мастер) запускаем сервер с указанием слейвов:

./server -m ./models/deepseek-v3.2-q4_k_m.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  --n-gpu-layers 40 \
  --ctx-size 8192 \
  --rpc \
  --rpc-servers 192.168.1.102:8081,192.168.1.103:8081 \
  --rpc-parallel 2

Магический флаг --rpc-parallel определяет, сколько запросов можно обрабатывать одновременно. Для 3 узлов ставьте 2. Для 2 узлов — 1.

Тесты производительности: что получилось

Я тестировал три конфигурации:

1. Один Strix Halo с моделью 120B (Q4_K_M)
2. Два Strix Halo с моделью 240B (Q4_K_M)
3. Три Strix Halo с моделью 345B (Q4_K_M)

Что это значит на практике? DeepSeek-V3.2 на трех ноутбуках генерирует ответ из 500 токенов за 70-120 секунд. Медленно? Да. Но это 345 миллиардов параметров за $9000 вместо $150000 за сервер с H100.

Главные ошибки (чтобы вы их не повторили)

Ошибка 1: Разные версии llama.cpp

Собрали на одном узле из master-ветки, на другом — из rpc-experimental. Результат: "RPC protocol version mismatch". Все узлы должны быть собраны из одной ветки, одним коммитом.

Ошибка 2: Сетевая латентность

Попытались использовать Wi-Fi вместо Ethernet. Задержка первого токена выросла до 15 секунд. Берите кабель. Всегда. Если интересны альтернативные архитектуры с разгрузкой вычислений, посмотрите статью про гибридный кластер с eGPU.

Ошибка 3: Нехватка слотов RPC

Запустили --rpc-slot-count 1 на слейвах, а на мастере отправили 4 параллельных запроса. Результат: три запроса висят в очереди вечно. Количество слотов на слейве должно быть >= --rpc-parallel на мастере.

Ошибка 4: Память под KV-cache

Забыли про --ctx-size и пытались отправить промпт на 16000 токенов при размере контекста 4096. Сервер падает без внятного сообщения. Всегда проверяйте, что ctx-size на всех узлах одинаковый и достаточный.

Альтернатива: vLLM вместо llama.cpp

llama.cpp RPC — не единственный вариант. vLLM 0.5.0+ поддерживает распределенный инференс через NCCL. Но есть нюансы:

# Устанавливаем vLLM с поддержкой ROCm
pip install vllm --extra-index-url https://download.pytorch.org/whl/rocm6.1

# Запускаем на нескольких узлах
# На узле 1:
vllm serve deepseek-ai/DeepSeek-V3.2 \
  --tensor-parallel-size 3 \
  --host 192.168.1.101 \
  --port 8000 \
  --gpu-memory-utilization 0.9

# На узлах 2 и 3 нужно запустить worker'ов с указанием главного узла

Плюсы vLLM: лучше поддержка continuous batching, официальная поддержка от создателей. Минусы: сложнее настройка для ROCm, больше потребление памяти.

Стоит ли игра свеч?

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

Этот кластер я использовал для экспериментов с автономными агентами на 165 инструментов. Модель на 345B справляется с сложными цепочками рассуждений, где 70B пасует.

Главное преимущество — масштабируемость. Нужно больше мощности? Добавьте четвертый ноутбук. Упираетесь в память? Разбейте модель на большее количество слоев. В статье про стратегии масштабирования я разбирал, когда переходить от одной карты к кластеру.

Через год этот гайд устареет. Появятся новые APU с большей памятью, улучшится поддержка ROCm в llama.cpp. Но принцип останется: несколько дешевых машин часто эффективнее одной дорогой. Особенно когда эта дорогая машина стоит как квартира.