GLM5.2 на AMD MI355X

Пост провайдера инференса Wafer от июля 2026 года, продающего мощности на базе AMD. В нём приводятся данные о пропускной способности GLM5.2 на оборудовании AMD MI355X, арендованном у TensorWave. Все цифры опубликованы стороной, коммерчески заинтересованной в выводах, и никем независимо не воспроизводились. Раздел с методикой необычно подробен для вендорского поста, поэтому его и стоит сохранить: инженерный разбор здесь полезнее заголовков.

Что они заявляют

Ценовая предпосылка заключается в том, что MI355X в среднем стоит примерно в 2.75 раза дешевле в пересчёте на GPU по сравнению с B300 при сопоставимых характеристиках кремния, а преимущество NVIDIA сводится к программному обеспечению и поддержке моделей в день релиза (day-0), а не к самому железу.

На нагрузке 20k входных / 1k выходных токенов при 60% попаданий в кэш они заявляют выход на насыщение при 2.4 запросах в секунду с суммарной скоростью 2626 токенов/с на ноду, TTFT p50 0.81 с и p95 2.22 с, 100% успешных запросов при заданном пороге перегиба (knee) по TTFT не хуже 5 с. Они называют это 80% от полученного ими на B200 результата при более чем двукратной разнице в цене. Их эталонный показатель для Blackwell, приведённый далее в том же посте, составляет 3192 токена/с на ноду при 3.0 rps. Обратите внимание на смену объектов сравнения: соотношение цен приводится против B300, а пропускной способности - против B200.

В однопоточном режиме (single stream) по методологии бенчмарков Artificial Analysis при 10k входных / 1.5k выходных токенов они заявляют 213 токенов/с. Они признают, что это не первая строчка в лидерборде AA, и заявляют победу исключительно по соотношению производительности к цене.

Как они этого добились

Сначала квантование. Они перевели веса GLM-5.2 из bf16 в MXFP4 с помощью AMD Quark и называют результат эквивалентным без потерь по сравнению с официальной сборкой FP8 от z-ai (в glm-5-2-step-change-for-open-agents объясняется, почему эту модель вообще имело смысл портировать). Опубликованные ими оценки тестов: GSM8K 0.955 ± 0.014 против 0.965 ± 0.013, GPQA-Diamond 0.9026 ± 0.029 против 0.9217 ± 0.027 и tau2 macro 0.834 против 0.819. Два показателя из трёх снизились и один вырос, все в пределах указанной погрешности, так что под "lossless" они понимают попадание в пределы шума, а не доказанную эквивалентность. MXFP4 - нативный для Blackwell 4-битный формат с плавающей точкой, описанный в llm-quantization; здесь интерес представляет его запуск на AMD.

В качестве фреймворка выбрали sglang. В vLLM не было рабочей кодовой ветки MXFP4 для GlmMoeDsa, поэтому квантованные веса там ничего не давали, а генерация ATOM деградировала на длинном контексте.

Чтобы завести спекулятивное декодирование, потребовалось два небольших исправления, причём ни одно из них не касалось написания ядер. В голове MTP разделяемый эксперт (shared expert) остаётся в bf16, как и во всех остальных слоях, но регистрируется под другим префиксом модуля, нежели указано в списке исключений Quark'а для неквантованных весов: Quark пишет model.layers.78.mlp.shared_experts.*, тогда как реальный префикс слоя MTP - model.decoder.*. Поиск в таблице квантования sglang'а промахивается, собирает этого эксперта как MXFP4, а затем падает при загрузке, пытаясь прочитать полноразмерный тензор bf16 в 4-битный слот. Они исправили это, продублировав записи для 78-го слоя в списке исключений под тем префиксом, который реально использует sglang, что, по их утверждению, дало почти трёхкратный прирост в однопоточном режиме. Второе исправление: объединённое многошаговое ядро метаданных (fused multi-step metadata kernel), необходимое для глубины драфта (draft depth) 4 или выше, включает cuda_runtime.h без защиты под ROCm, поэтому глубокие конфигурации вроде предлагаемой z-ai схемы 5/1/6 были заблокированы, пока они не добавили одну директиву #ifdef USE_ROCM. Вместе с этим, а также с флагами --kv-cache-dtype fp8_e4m3 и --enable-aiter-allreduce-fusion они вышли на показатель в 213 токенов/с. Что такое MTP и почему важна глубина драфта, описано в speculative-decoding.

Для суммарной пропускной способности потребовалась другая работа, так как при 20k входных токенов и 60% попаданий в кэш нагрузка упирается в фазу prefill, а не decode. Конфигурация TP8, настроенная под однопоточный decode, выдала 1461 токен/с на ноду. Переход на TP4xDP2 позволил получить 1944 при 2.0 rps. Оставшийся разрыв возник из-за того, что MoE в fp4 для GLM-5.2 молча выполнялся на медленном эвристическом fallback'е FlyDSL, поскольку в aiter поставлялись оптимизированные конфигурации только для пути a8w8/fp8. Тюнинг выбора ядер MoE под размерности fp4 модели GLM (model_dim 6144, moe_inter 2048, E=256, topk=8) и позволил выйти на вынесенные в заголовок 2626. Архитектура маршрутизации для этих размерностей описана в mixture-of-experts.

Скептический взгляд

Их вывод сводится к тому, что на этот раз им не пришлось писать собственные ядра, в отличие от прежней работы с Qwen3.5 397B, так что передовой уровень на AMD теперь упирается лишь в поддержку, а не в софт, и "ров вокруг CUDA разрушается в реальном времени". Представленные ими доказательства куда скромнее самого заявления: два бага в upstream и один проход по подбору ядер на одной модели, на одной ноде и силами команды, которая профессионально этим занимается.

Моменты, которые признаются в самом посте или остаются открытыми. Тестирование проводилось только на одной ноде, о чём они прямо говорят. Флагманские модели выходят каждые несколько недель, а поддержка на MI355X не появляется в день релиза, так что описанный здесь процесс портирования, по их собственным словам, превращается в бесконечную гонку: к моменту завершения работы уже выходит следующая модель. К тому же итоговая пропускная способность по их же собственным цифрам составляет лишь 80% от показателей Blackwell, поэтому вся аргументация держится на сохранении соотношения цен, что является рыночной конъюнктурой, а не свойством самого оборудования.