Новости

Энтузиаст запустил GLM-5.2 с MTP speculative decode на кластере из 4× DGX Spark (GB10)

Обновлено: 27 июня 2026 г.

Почему это важно

История показывает, что практическая производительность LLM‑стеков может сильно зависеть не только от модели, но и от конкретных сборок инфраструктуры и пропущенных шагов в «публичных рецептах». Это может сигнализировать бизнесу, что запуск и оптимизация моделей вроде GLM-5.2 на специализированных системах DGX Spark требует инженерной доработки и точного воспроизведения окружения. Также укладывается в тренд, где пропускная способность межузловой сети и техники вроде MTP speculative decode становятся ключевыми факторами реальной скорости вывода.

Разработчик под ником /u/anvarazizov сообщил о запуске стека GLM-5.2 с MTP speculative decode на кластере из 4× DGX Spark (GB10). В конфигурации используется vLLM с TP=4, портированные sparse-MLA Triton kernels и data-free 15% expert prune, что позволяет разместить AWQ-INT4 веса. Как сообщает r/LocalLLaMA (Reddit), система выдает около ~9.4 tok/s на одной линии RoCE, показатель MTP acceptance держится на уровне ~2.8/4. Это примерно в два раза быстрее предыдущего варианта: раньше модель обслуживалась через llama.cpp RPC и показывала около ~5 tok/s.

Основой сборки стал стек GLM-5.2 для 4× GB10, который опубликовал разработчик CosmicRaisins. При переносе на собственный 4-узловой кластер выяснилось, что образ нельзя просто воспроизвести из публичного репозитория. В README упомянуты модификации vLLM в форке spark-vllm-docker, однако сами изменения не выложены, доступны только kernels. Поэтому нужные правки пришлось восстановить по публичным kernels. Для этого создан скрипт build-recon-image.sh: он добавляет kernels в образ, патчит deep_gemm.py (перенаправляя 3 DSA функции на sm12x_* fallbacks для sm_120/121 до проверки _missing()), меняет sparse_attn_indexer.py (убирается проверка has_deep_gemm для sm12x), автоматически применяет monkeypatch flashmla→Triton и устанавливает b12x==0.23.0. Корректность сборки проверяется импортом на GPU.

Критичным оказался точный pinned commit vLLM, на который ссылался автор исходной сборки. Попытка собрать систему на более новой версии заканчивалась падением при загрузке реальных AWQ весов в process_weights_after_loading с ошибкой "k_scale.fill → async CUDA error: invalid argument". При этом dummy weights загружались без проблем. После пересборки vLLM на исходном commit ошибка исчезла.

При переносе возникло несколько практических моментов. Например, можно не скачивать 378 GB весов: 15% prune детерминированно воспроизводится из базы cyankiwi AWQ через скрипт awq_surgery.py примерно за ~20 min. На узлах с меньшим объёмом свободной памяти параметр gpu-memory-utilization 0.93 иногда блокирует запуск, поэтому его уменьшают до 0.90 и дополнительно снижают max-model-len. Если нет общей файловой системы, веса предлагают экспортировать через NFS с головного узла и настроить RoCE HCA/GID-index. По словам автора исходного стека, конфигурация с dual-rail достигает около ~20 tok/s, а главным ограничением остаётся пропускная способность inter-node allreduce.

Ключевые факты

GLM-5.2 с MTP speculative decode запущена на кластере 4× DGX Spark (GB10) с vLLM TP=4 и показывает около 9.4 tok/s на одном RoCE‑канале.
Используется data-free pruning экспертов на 15%, чтобы веса AWQ-INT4 помещались в конфигурацию; обрезка детерминированно воспроизводится из базы cyankiwi AWQ через скрипт awq_surgery.py примерно за 20 минут.
Сборка vLLM на более новой версии, чем закреплённый коммит автора, приводила к падению при загрузке реальных AWQ‑весов с ошибкой async CUDA error: invalid argument в process_weights_after_loading.
До внедрения sparse-MLA MTP путь использовался llama.cpp RPC со скоростью около 5 tok/s; новая конфигурация даёт примерно в 2 раза больше, при MTP acceptance около 2.8/4.