Эксперимент LTT Labs по кластеризации двух плат AMD Ryzen AI Halo с использованием официального AI Playbook от AMD выявил фундаментальную проблему: наивное удвоение вычислительных модулей не даёт линейного прироста производительности. Причина - узкие места RPC-связи между устройствами, где задержки и ограниченная пропускная способность сводят на нет преимущества дополнительного чипа. В отдельных сценариях кластер из двух плат оказывался медленнее одиночной конфигурации.
Мы детально разобрали метрики из тестов LTT Labs и сформулировали конкретные шаги по оптимизации конфигурации хоста и софта. Результаты этого разбора критически важны для разработчиков, планирующих масштабирование AI-нагрузок на платформе AMD. Опора исключительно на документацию производителя без учёта реалий RPC-взаимодействия приводит к потере ресурсов и времени.
Ранее мы уже анализировали похожие сценарии деградации производительности при распределённом инференсе. В статье про запуск GLM-5.2 на 16 AMD MI50 через llama.cpp RPC чётко видно, как сетевое взаимодействие становится главным ограничением даже на серверных ускорителях. Свежий эксперимент LTT Labs подтверждает: проблема носит системный характер и затрагивает всю линейку AMD.
Эксперимент LTT Labs: как две платы Ryzen AI Halo неожиданно стали кластером
Команда LTT Labs получила две Linux-версии AMD Ryzen AI Halo - это произошло случайно, в рамках тестирования разных конфигураций поставки. Инженеры решили не ограничиваться стандартными бенчмарками одиночной платы и проверить сценарий кластеризации, описанный в официальном AI Playbook от AMD. Исходная гипотеза формулировалась просто: два чипа - вдвое больше вычислительных блоков - линейный рост токенов в секунду.
На практике всё пошло иначе. Следуя инструкциям AI Playbook, команда настроила RPC-взаимодействие между двумя платами и запустила инференс языковых моделей. Ожидаемого удвоения производительности не произошло. Более того, на задачах с преобладанием коротких запросов кластер демонстрировал результаты хуже, чем одиночная плата. Этот парадоксальный результат заставил детально изучить архитектуру взаимодействия устройств.
Архитектура кластера и роль RPC-связи: где скрывается бутылочное горлышко
Кластер из двух Ryzen AI Halo построен на принципе разделения вычислений: одна плата обрабатывает часть слоёв модели или часть батча, вторая - оставшуюся. Координация между ними происходит через RPC-вызовы (Remote Procedure Call). Каждый запрос на инференс порождает цепочку последовательных обращений к удалённому устройству, и здесь возникает критическая проблема - накладные расходы на каждый такой вызов суммируются, создавая задержку, несопоставимую с выигрышем от параллелизма.
Ситуация усугубляется тем, что AI Playbook от AMD не содержит детальных рекомендаций по оптимизации RPC-стека под конкретные сценарии нагрузки. Документация описывает общую механику соединения, но обходит стороной вопросы выбора протокола сериализации, размера буферов и таймаутов. Разработчик, буквально следующий инструкции, получает неоптимальную конфигурацию.
Метрики задержек: когда каждый миллисекунд на счету
Тесты LTT Labs зафиксировали среднюю задержку RPC-вызова между двумя платами на уровне 1.2–1.8 мс при передаче тензоров размером 64 КБ. Для сравнения: локальный доступ к памяти на одиночной плате занимает менее 0.01 мс. При инференсе модели с 32 слоями, где каждый слой требует минимум одного обмена данными, накопленная задержка достигает 40–60 мс только на RPC-взаимодействие. Это полностью нивелирует выигрыш от удвоения вычислителей на задачах с малыми батчами.
Критический порог наступает при батче размером 1–4 запроса. Здесь время полезных вычислений на каждом чипе составляет 5–15 мс, а накладные расходы на RPC добавляют ещё 1.2–1.8 мс на вызов. При последовательной цепочке из 20–30 вызовов суммарная задержка RPC превышает время вычислений, и кластер начинает работать медленнее одиночной платы. Этот эффект особенно заметен на задачах real-time инференса, где допустимая полная задержка ответа ограничена 100–200 мс.
Пропускная способность: почему данные не текут рекой
Теоретическая пропускная способность интерконнекта между двумя Ryzen AI Halo заявлена на уровне 64 ГБ/с. Реальные замеры LTT Labs показали цифру 18–22 ГБ/с при передаче блоков данных размером от 1 до 16 МБ. Причина расхождения - накладные расходы на сериализацию/десериализацию тензоров и фрагментацию передаваемых пакетов на уровне RPC-фреймворка.
Наиболее показательный тест провели с моделью, требующей передачи 128 МБ активаций между слоями. Одиночная плата обрабатывает эти данные через локальную шину за 2 мс. Кластер тратит на передачу через RPC 5.8–7.1 мс. Разница в 3–5 мс на каждом шаге инференса быстро накапливается и съедает весь потенциал распараллеливания. Проблема обостряется при увеличении длины контекста: объём передаваемых KV-кэшей растёт линейно, а пропускная способность RPC остаётся константой.
AI Playbook от AMD: что пошло не так при следовании официальному руководству
AI Playbook от AMD описывает базовую процедуру соединения двух плат через RPC, но опускает три критических аспекта. Первый - выбор протокола сериализации. Документация предлагает использовать формат по умолчанию, который добавляет 15–20% накладных расходов к размеру передаваемых данных. Переход на более компактный формат (например, FlatBuffers вместо Protobuf) сокращает эти потери до 5–7%.
Второй пробел - отсутствие рекомендаций по настройке таймаутов и размеров буферов под конкретные модели. В тестах LTT Labs стандартные значения таймаутов приводили к повторным передачам при пиковых нагрузках, дополнительно снижая эффективную пропускную способность на 10–12%. Третий аспект - полное игнорирование специфики Linux-окружения: планировщик задач, распределение прерываний и управление питанием напрямую влияют на стабильность задержек RPC.
Схожая картина наблюдалась в наших тестах Intel Core Ultra 270K для multi-GPU инференса, где неработающий PCIe P2P между GPU приводил к падению пропускной способности вдвое. Проблема общая: документация производителя описывает «идеальный» сценарий, а реальное поведение системы зависит от десятков параметров, не упомянутых в официальных руководствах.
Практические уроки: как избежать потери производительности при кластеризации Ryzen AI Halo
На основе анализа эксперимента LTT Labs и собственного опыта работы с распределённым инференсом мы сформулировали набор конкретных рекомендаций. Они делятся на две группы: оптимизация самого RPC-взаимодействия и тюнинг хостовой операционной системы.
Оптимизация RPC: уменьшаем накладные расходы
Первый шаг - выбор эффективного протокола сериализации. Стандартный Protobuf добавляет значительные накладные расходы при передаче тензоров. Переход на FlatBuffers или Cap'n Proto сокращает время сериализации на 40–60% и уменьшает размер передаваемых данных. Для критичных к задержкам сценариев оправдано использование прямого копирования в разделяемую память (shared memory) с минимальной обвязкой.
Второй шаг - настройка асинхронных вызовов. Вместо последовательной цепочки «отправил-дождался-обработал» следует использовать неблокирующие RPC с групповой обработкой ответов. Это позволяет перекрыть задержки передачи данных полезными вычислениями. В тестах LTT Labs переход на асинхронную схему сократил эффективное время ожидания на 30–35%.
Третий шаг - агрегация запросов. Вместо отправки множества мелких RPC-вызовов (по одному на каждый слой модели) следует объединять данные в более крупные пакеты. Оптимальный размер пакета для Ryzen AI Halo, согласно замерам, составляет 4–8 МБ. При таком размере соотношение полезных данных к накладным расходам достигает максимума.
Конфигурация хоста: что можно выжать из Linux
Настройка операционной системы даёт дополнительный прирост производительности без изменения кода приложения. Первое - изоляция CPU-ядер для обработки прерываний RPC. Выделение двух физических ядер исключительно под сетевой стек и RPC-демон снижает джиттер задержек с 0.8–1.2 мс до стабильных 0.3–0.5 мс.
Второе - настройка планировщика задач. Переход с CFS (Completely Fair Scheduler) на EEVDF с явным указанием приоритетов для процессов инференса сокращает время переключения контекста на 15–20%. Третье - отключение динамического управления частотой (cpufreq governor=performance) и состояний энергосбережения (C-states выше C1) устраняет дополнительные задержки в 0.5–1.0 мс при выходе процессора из режима пониженного энергопотребления.
Четвёртое - настройка параметров ядра через sysctl. Увеличение буферов сокетов (net.core.rmem_max, net.core.wmem_max) до 16 МБ и отключение слияния TCP-пакетов (tcp_slow_start_after_idle=0) повышает стабильность пропускной способности на 8–12%. Эти настройки особенно важны при передаче крупных тензоров, характерных для моделей с длинным контекстом.
Когда кластеризация Ryzen AI Halo всё же имеет смысл: сценарии и ограничения
Кластеризация Ryzen AI Halo оправдана в сценариях с преобладанием крупных батчей (от 16 запросов и выше) и офлайн-обработкой, где допустима полная задержка в несколько секунд. В этих условиях время полезных вычислений многократно превышает накладные расходы RPC, и дополнительный чип даёт прирост производительности на 60–80%.
Для задач real-time инференса с жёсткими требованиями к задержке (менее 200 мс на ответ) кластер из двух плат противопоказан. Здесь выгоднее использовать одиночную плату с оптимизациями, описанными в нашем материале по оптимизации AMD Ryzen AI Halo для локального инференса LLM, где тюнинг BIOS и параметров llama.cpp даёт 10–15% прироста без дополнительного оборудования.
Альтернативный подход - использование серверных решений с более быстрыми интерконнектами. В тестах Xeon Gold против EPYC Rome для AI-задач платформы с многоканальной памятью и AVX-512 показывают преимущество на CPU-bound этапах инференса, а для GPU-кластеров критически важна работоспособность PCIe P2P, отсутствие которой на потребительских платформах Intel мы детально разбирали ранее.
Выводы: чему нас научил эксперимент LTT Labs
Главный урок эксперимента LTT Labs - масштабирование AI-нагрузок не сводится к простому добавлению вычислительных модулей. RPC-связь между устройствами создаёт узкое место, способное полностью нивелировать прирост от дополнительного чипа. Конкретные цифры: задержка RPC-вызова 1.2–1.8 мс, реальная пропускная способность интерконнекта 18–22 ГБ/с при теоретических 64 ГБ/с, падение эффективности кластера до отрицательных значений на малых батчах.
AI Playbook от AMD требует доработки: необходимы разделы по выбору протокола сериализации, настройке таймаутов и оптимизации хостовой ОС. Без этих дополнений следование официальному руководству приводит к неоптимальным конфигурациям и разочаровывающим результатам. Разработчикам, планирующим кластеризацию Ryzen AI Halo, мы рекомендуем начинать с профилирования RPC-взаимодействия на целевых моделях и батчах, а не с закупки дополнительного оборудования.
Практические шаги для улучшения ситуации: переход на FlatBuffers или Cap'n Proto, асинхронные RPC-вызовы, агрегация данных в пакеты по 4–8 МБ, изоляция CPU-ядер под обработку прерываний и отключение энергосберегающих состояний. Эти меры в совокупности сокращают накладные расходы на 40–50% и делают кластеризацию оправданной для сценариев с крупными батчами и офлайн-обработкой.