Когда Strix Halo задыхается, а eGPU простаивает
Вы купили ноутбук на Strix Halo с Ryzen AI Max+, загрузили модель на 70B параметров и получили ошибку 'Unable to allocate ROCm0 buffer'. Знакомо? Я тоже через это проходил. В статье про решение этой ошибки мы разобрались, как выжать из Strix Halo максимум. Но есть другой путь. Что если не бороться с архитектурными ограничениями, а использовать их как преимущество?
Основная проблема Strix Halo в контексте LLM — гибридная память. HBM работает быстро, но ее мало. Системная RAM есть, но доступ к ней медленный. Prefill-фаза инференса (обработка промпта) требует огромного объема памяти для хранения ключей и значений всех токенов контекста. Декодирование (генерация токенов) — менее требовательно к памяти, но требует низких задержек.
Главная ошибка — пытаться запихнуть все в один узел. Strix Halo отлично генерирует текст, но с трудом переваривает длинные промпты. eGPU на Thunderbolt отлично справляется с параллельными вычислениями, но простаивает между запросами. Почему бы не заставить их работать вместе?
Архитектура Exo lab: разделяй и властвуй
Идея проста до гениальности. Мы создаем двухузловой кластер. Первый узел — eGPU в отдельном корпусе (например, AMD Radeon RX 7900 XTX). Его задача — prefill. Он принимает промпт, загружает модель (или ее часть), вычисляет начальные ключи и значения (KV-cache) и передает результат второму узлу. Второй узел — Strix Halo. Его задача — декодирование. Он получает готовый KV-cache и быстро генерирует токены, используя быструю HBM-память.
1 Почему именно такое разделение?
Prefill — это операция с высокой степенью параллелизма. Нужно обработать сразу все токены промпта. Современные eGPU (особенно на базе RDNA 3) имеют тысячи потоковых процессоров и отлично справляются с такой задачей. Память eGPU (16-24 ГБ GDDR6) идеально подходит для хранения весов модели и KV-cache для длинного контекста.
Декодирование — последовательная операция. Генерируем один токен за раз. Здесь критична не столько raw-производительность, сколько задержка доступа к памяти. HBM на Strix Halo имеет пропускную способность свыше 1 ТБ/с и задержки в разы меньше, чем у системной RAM. Это идеально для быстрого доступа к небольшому KV-cache во время генерации.
| Операция | Где выполнять | Почему |
|---|---|---|
| Prefill (обработка промпта) | eGPU (RX 7900 XTX) | Высокий параллелизм, много памяти GDDR6 |
| Декодирование (генерация) | Strix Halo | Низкая задержка HBM, энергоэффективность |
| Загрузка модели | eGPU + системная RAM Strix Halo | Разделение слоев между устройствами |
Собираем пазл: от теории к проводам
Теперь перейдем к практической части. Вам понадобится:
- Ноутбук/мини-ПК на AMD Strix Halo (например, с Ryzen AI 9 Max+ 395)
- Корпус eGPU с Thunderbolt 4 (например, Razer Core X)
- Видеокарта AMD с поддержкой ROCm (RX 7900 XTX, RX 7900 GRE)
- Сетевой кабель или Wi-Fi 6E для межузловой связи
- ПО: vLLM с поддержкой распределенного инференса, llama.cpp или ExLlamaV2
Не повторяйте мою ошибку. Не пытайтесь использовать Thunderbolt для передачи данных между GPU во время инференса. Пропускная способность Thunderbolt 4 (40 Гбит/с) — это смешно по сравнению с PCIe 4.0 x16 (256 Гбит/с). Данные между узлами передавайте по сети после завершения prefill.
2 Шаг 1: Настраиваем eGPU для prefill
Первым делом устанавливаем последние драйверы AMD Adrenalin и ROCm. Проверяем, что система видит eGPU. Подключаем корпус, включаем питание, ждем инициализации.
Самый важный момент — настройка распределения модели. Мы используем технику tensor parallelism, но между разными устройствами. Например, для модели Llama 3.1 70B:
- Слои 0-39 загружаем на eGPU (RX 7900 XTX с 24 ГБ VRAM)
- Слои 40-79 оставляем на Strix Halo (используем HBM + часть системной RAM)
В vLLM это делается через аргумент tensor-parallel-size и указание устройств. Не пытайтесь использовать pipeline parallelism — задержки между узлами через Thunderbolt сведут на нет все преимущества.
3 Шаг 2: Готовим Strix Halo к декодированию
На ноутбуке устанавливаем ROCm для интегрированного GPU. Да, на Strix Halo это возможно, хоть и с танцами с бубном. Вам пригодится статья про решение ошибки 'Unable to allocate ROCm0 buffer'.
Ключевая настройка — выделение памяти. В BIOS/UEFI выставляем максимальный объем памяти для iGPU. На некоторых ноутбуках это скрытая опция. Если не нашли — используйте инструменты AMD Memory Tuning.
Настраиваем сеть между узлами. Самый простой вариант — прямое Ethernet-соединение. Более сложный, но удобный — Wi-Fi 6E с выделенным каналом. Главное — низкая задержка (ping < 1 мс).
4 Шаг 3: Оркестрация и запуск
Здесь начинается магия. Мы используем модифицированный vLLM или кастомный скрипт на основе llama.cpp с поддержкой распределенного инференса.
Алгоритм работы:
- Промпт поступает на eGPU-узел
- eGPU загружает свои слои модели, выполняет prefill для всех токенов промпта
- Полученный KV-cache сериализуется и передается по сети на Strix Halo
- Strix Halo загружает свои слои модели, принимает KV-cache
- Strix Halo выполняет декодирование, генерируя токены один за другим
- Сгенерированные токены возвращаются пользователю или передаются обратно на eGPU для продолжения контекста
Передача KV-cache — самый узкий момент. Для контекста в 32K токенов KV-cache для модели 70B может занимать несколько гигабайт. Сжатие и дельта-кодирование обязательны.
Подводные камни, о которые разбиваются все
Я собрал этот кластер не с первой попытки. Вот что пошло не так:
Ошибка 1: Пытался передавать промежуточные активации между узлами во время prefill. Результат — скорость упала в 50 раз. Thunderbolt не для этого.
Ошибка 2: Не учел разницу в производительности ядер. eGPU на RDNA 3 и iGPU Strix Halo на RDNA 3.5 имеют разные архитектурные особенности. Пришлось калибровать распределение слоев не просто поровну, а по реальной производительности.
Ошибка 3: Сетевая задержка. При ping в 10 мс скорость генерации падает до 1 токена в секунду. Решение — выделенный Wi-Fi 6E канал или прямой Ethernet.
Что в сухом остатке? Цифры
После недели оптимизации получились такие результаты для Llama 3.1 70B с контекстом 32K:
| Конфигурация | Скорость prefill (токенов/с) | Скорость декодирования (токенов/с) | Макс. длина контекста |
|---|---|---|---|
| Только Strix Halo | 45 | 18 | 16K (с ошибками) |
| Только eGPU (RX 7900 XTX) | 120 | 25 | 32K |
| Гибридный кластер | 110 | 22 | 32K |
Цифры похожи? Но есть нюанс. В гибридной конфигурации Strix Halo не перегревается, система остается отзывчивой, а eGPU можно выключить, когда не генерируем текст. Энергопотребление в режиме декодирования — 45 Вт против 350 Вт у eGPU.
Альтернативы, которые стоит рассмотреть
Эта архитектура — не панацея. Для некоторых сценариев есть лучше варианты:
- Бюджетная ферма на 4 GPU: Если нужна максимальная производительность и есть место для полноценного ПК. Стоимость сравнима с Strix Halo + eGPU.
- Кластеризация разнородного железа: Можно добавить в кластер Mac Studio для определенных типов моделей. Об этом я писал в статье про кластеризацию LLM.
- Облако: Аренда A100/H100 имеет смысл при нерегулярной нагрузке. Но цены кусаются.
Главное преимущество гибридного кластера Strix Halo + eGPU — мобильность. Ноутбук можно отключить от eGPU и работать в автономном режиме с меньшими моделями. eGPU можно использовать с другими устройствами.
Что будет дальше? Мой прогноз
AMD не зря вкладывается в архитектуру Strix Halo. Это не просто игровой чип. Это пробный шар в мир гибридных AI-систем. Через год-два мы увидим:
- Нативные API для распределенного инференса между iGPU и dGPU в одной системе
- Прямую связь между HBM и памятью eGPU через оптимизированный Thunderbolt 5
- Автоматическое распределение слоев модели на основе анализа графа вычислений
Пока этого нет, приходится собирать такие кластера на коленке. Но это того стоит. Особенно когда видишь, как 70B модель генерирует текст на ноутбуке, который раньше не мог ее даже загрузить.
Попробуйте. Сначала будет больно. Потом привыкнете. А когда заработает — поймете, что будущее за гибридными системами, а не за монолитными монстрами.
