GLM-5.2 - модель размером 436 ГиБ, которая бросает вызов даже современным серверным сборкам. Запустить её на 16 ускорителях AMD MI50 с 32 ГБ памяти каждый - задача на грани возможного. Мы протестировали две конфигурации: распределённый инференс через llama.cpp RPC и бета-сборку vLLM-gfx906 с AWQ INT4. Результат: 12.2 токенов в секунду на декодировании через RPC и 14 токенов в секунду через vLLM. На префилле vLLM вырывается вперёд с 50 токенами в секунду против 30.9 у llama.cpp. Но после 10K токенов контекста обе схемы деградируют. Разбираемся, почему это происходит и где пределы старого железа.
Ключевые цифры: чего удалось достичь на связке MI50 + GLM-5.2
Конфигурация из 16 AMD MI50, собранных в два 8-GPU узла с соединением 10GbE, даёт следующие практические метрики:
- llama.cpp RPC: декодирование - 12.2 tok/s, префилл - 30.9 tok/s. На длинных контекстах (10.7K токенов) скорость падает.
- vLLM-gfx906 (Moby Dick TP=8, PP=2) с AWQ INT4: декодирование - 14 tok/s, префилл - 50 tok/s. После 10K токенов наступает резкая деградация.
Эти цифры - ориентир для инженеров, которые оценивают бюджетные сборки для экспериментов с большими моделями. Производительность не рекордная, но достаточная для офлайн-обработки и исследовательских задач. Для сравнения: на 8× GB10 GLM-5.2 выдаёт 33-54 tok/s на декодировании, но цена такого кластера на порядок выше. Подробный разбор производительности GLM-5.2 на GB10 мы публиковали ранее - там модель показывает 1200 токенов в секунду на префилле и может параллельно запускать Mimo 2.5 для мультимодальных задач.
Тестовый стенд: железо, сеть и софт
Стенд собран из двух серверов, каждый с 8 ускорителями AMD MI50. Суммарно 16 GPU дают 512 ГБ видеопамяти, что покрывает 436 ГиБ модели с запасом под KV-кэш и накладные расходы фреймворков. Межузловое соединение - 10GbE, заведомо узкое место для распределённого инференса. Программный стек: ROCm для gfx906, llama.cpp со встроенным RPC-бэкендом и отдельная бета-сборка vLLM-gfx906 с поддержкой AWQ INT4.
Сборка аналогична той, что мы описывали в материале про запуск Nemotron Ultra 550B на гетерогенном кластере из MI50 и P40. Там 100GbE RPC-соединение позволило достичь приемлемого throughput даже на 126K токенов контекста. Здесь сеть на порядок медленнее, и это сразу отражается на результатах.
Почему именно MI50: память, цена и ограничения
AMD MI50 - ускоритель 2018 года на архитектуре Vega 20 (gfx906). 32 ГБ HBM2 с пропускной способностью 1 ТБ/с, 3840 потоковых процессоров. На вторичном рынке цена карты колеблется в районе $150-250, что делает её привлекательным вариантом для сборки бюджетных кластеров. Главный недостаток - отсутствие официальной поддержки в новых версиях ROCm. Для vLLM и части функций PyTorch приходится использовать форки и патчи сообщества. Квантизация AWQ INT4 критична для MI50: она сжимает модель вдвое, позволяя разместить больше слоёв в ограниченных 32 ГБ на карту.
Альтернативы - NVIDIA P40 с 24 ГБ (дешевле, но меньше памяти) или MI60 с 32 ГБ (чуть быстрее, та же архитектура). Выбор MI50 оправдан соотношением цены к объёму памяти, когда нужно собрать кластер под большие модели.
llama.cpp RPC: распределенный инференс без боли
llama.cpp с RPC-бэкендом - простейший способ распределить модель по узлам. Настройка сводится к запуску сервера на каждом узле и указанию IP-адресов в командной строке. Модель распределяется по слоям: первые N слоёв на первом узле, следующие - на втором. Тензорный параллелизм внутри узла не используется, каждый GPU обрабатывает свой набор слоёв. Это снижает накладные расходы на синхронизацию, но увеличивает задержку при передаче активаций между узлами.
Результат: 12.2 tok/s на декодировании и 30.9 tok/s на префилле. Префилл быстрее, потому что обрабатывает весь промпт параллельно. Декодирование упирается в последовательную природу генерации и пропускную способность 10GbE: каждый токен требует передачи данных между узлами.
Похожий подход мы разбирали в статье про запуск GLM 5.2 на CPU - там на AMD EPYC 9654 с 96 ядрами декодирование давало 5-9 токенов в секунду. RPC на MI50 вдвое быстрее CPU-варианта, но требует аккуратной настройки KV-кэша и NUMA-аффинности.
Поведение на длинных контекстах: 10.7K токенов и падение скорости
При росте контекста до 10.7K токенов производительность llama.cpp RPC падает. Причина - экспоненциальный рост вычислений внимания и увеличение KV-кэша. На MI50 с 32 ГБ памяти KV-кэш начинает конкурировать с весами модели за место в HBM2. Пропускная способность памяти в 1 ТБ/с становится бутылочным горлышком: модель вынуждена чаще обращаться к памяти для операций внимания, что замедляет декодирование. Сеть 10GbE добавляет задержку при обмене промежуточными состояниями между узлами.
Для сравнения: на CPU-инференсе GLM 5.2 с контекстом 131K токенов скорость декодирования падала до 5 токенов в секунду из-за KV-кэша Q8_0. Переключение на Q4_0 и снижение контекста до 32-48K поднимало скорость до 15-25 токенов в секунду. Здесь та же логика: меньше контекст - выше скорость.
Параллельные запросы: как держит нагрузку
При двух одновременных запросах пропускная способность llama.cpp RPC падает нелинейно. Суммарный throughput снижается до 18-20 tok/s на декодировании вместо ожидаемых 24 tok/s. Причина - contention на сетевом соединении и общем KV-кэше. GPU вынуждены переключаться между запросами, что увеличивает latency. Для офлайн-обработки батчами это приемлемо, для интерактивных приложений - нет.
vLLM-gfx906: бета-сборка с AWQ INT4 и ее сюрпризы
vLLM-gfx906 - форк vLLM, адаптированный под архитектуру gfx906. Конфигурация Moby Dick: тензорный параллелизм TP=8 внутри узла и пайплайн-параллелизм PP=2 между узлами. AWQ INT4 сжимает модель до ~220 ГБ, что позволяет разместить её в 512 ГБ суммарной памяти с запасом под KV-кэш. Результат: 14 tok/s на декодировании и 50 tok/s на префилле.
Префилл здесь быстрее, чем у llama.cpp RPC, благодаря оптимизациям vLLM под continuous batching и PagedAttention. Декодирование незначительно быстрее - 14 против 12.2 tok/s. Разница укладывается в погрешность измерений и особенности квантования.
Сравнение бэкендов для инференса - тема, которую мы детально разбирали в материале про vLLM, LMDeploy и Triton с TensorRT-LLM. Там на H100 и B200 разница между бэкендами достигала 2-3 раз. Здесь, на старом железе, софтовые оптимизации упираются в физические ограничения GPU и сети.
Квантизация AWQ INT4: компромисс между скоростью и качеством
AWQ INT4 сокращает размер GLM-5.2 с 436 ГБ до ~220 ГБ. Для MI50 это критично: без квантования модель просто не поместилась бы в 512 ГБ суммарной памяти с учётом накладных расходов. Потери качества при INT4 минимальны на большинстве бенчмарков - разница в perplexity составляет 0.5-1.5 пункта. Для исследовательских задач и прототипирования это приемлемо. Для продакшена с высокими требованиями к точности лучше смотреть в сторону INT8 или FP8 на более новом железе.
Деградация vLLM-gfx906 после 10K токенов связана с управлением памятью в форке. PagedAttention не полностью оптимизирован под gfx906, и при большом KV-кэше начинаются проблемы с фрагментацией памяти. Это известная проблема бета-сборки, которую разработчики пока не исправили.
Сравнение подходов: llama.cpp RPC vs vLLM-gfx906
| Метрика | llama.cpp RPC | vLLM-gfx906 |
|---|---|---|
| Декодирование | 12.2 tok/s | 14 tok/s |
| Префилл | 30.9 tok/s | 50 tok/s |
| Длинный контекст (10K+) | Плавное падение | Резкая деградация |
| Параллельные запросы | Нелинейное падение throughput | Стабильнее, но ограничено памятью |
| Сложность настройки | Низкая: RPC из коробки | Высокая: бета-сборка, патчи ROCm |
| Квантование | GGUF (Q4_K_M и аналоги) | AWQ INT4 |
llama.cpp RPC выигрывает по простоте и предсказуемости. vLLM-gfx906 даёт лучший префилл, но нестабилен на длинных контекстах. Выбор зависит от задачи: для экспериментов с короткими промптами vLLM предпочтительнее, для обработки длинных документов - llama.cpp RPC.
Узкие места: сеть, память и софт - что тормозит больше всего
Главный тормоз системы - 10GbE. При распределённом инференсе каждый токен требует передачи активаций между узлами. Пропускная способность 10GbE (~1.2 ГБ/с) на порядок ниже пропускной способности HBM2 (1 ТБ/с). Переход на 100GbE, как в сборке Nemotron Ultra 550B, мог бы поднять throughput в 2-3 раза. InfiniBand ещё лучше, но цена такого апгрейда превышает стоимость самих MI50.
Память MI50 - 32 ГБ на карту - ограничивает размер квантованной модели и KV-кэша. Для GLM-5.2 в INT4 это пока приемлемо, но более крупные модели потребуют больше GPU или более ёмких ускорителей. Софт для gfx906 остаётся незрелым: форки vLLM отстают от мейнстрима, часть оптимизаций недоступна. Это плата за использование старого железа.
Аналогичные проблемы мы видели при запуске DeepSeek-V4-Flash на одном B300: отказ MoE-ядра без expert parallel и деградация при насыщенном батче. Там бутылочным горлышком оказался софт, а не железо. Здесь та же история: vLLM-gfx906 не вытягивает длинные контексты из-за проблем с управлением памятью.
Практические выводы: стоит ли собирать кластер из MI50 в 2025 году
Сборка из 16 MI50 за $2500-4000 способна запускать GLM-5.2 с приемлемой скоростью для офлайн-обработки и экспериментов. 12-14 tok/s на декодировании - это уровень чтения текста человеком, достаточный для генерации отчётов, суммаризации и batch-обработки. Для интерактивных приложений с требованиями к latency это не подходит.
Сценарии, где такая конфигурация оправдана:
- Исследовательские проекты с ограниченным бюджетом.
- Офлайн-обработка документов и генерация контента.
- Изучение распределённого инференса и квантования.
Сценарии, где MI50 не справляются:
- Продакшен с высокими требованиями к latency.
- Интерактивные чат-боты и голосовые ассистенты.
- Работа с контекстами более 10K токенов.
Альтернативы: кластер из NVIDIA P40 дешевле, но 24 ГБ на карту ограничивают размер модели. Более новые MI60 дают ту же память с чуть лучшей производительностью. Если бюджет позволяет, стоит смотреть в сторону MI100 или MI210 с 32-64 ГБ и официальной поддержкой ROCm. Но цена такого кластера будет в 3-5 раз выше.
Итог: MI50 - рабочий вариант для энтузиастов и исследователей, готовых мириться с ограничениями. Для продакшена лучше выбрать более современное железо с официальной поддержкой фреймворков.