요약(TL;DR): 레시피의 이미지 빌드 수정 사항은 실제로 공개되어 있지 않습니다. 저는 (Claude를 활용해) 공개된 커널(kernels)로부터 이를 재구성했습니다. 또한, 저자가 지정한 정확한 고정 참조(pinned ref)로 vLLM을 빌드해야 하며, 그렇지 않으면 실제 AWQ 가중치가 로드 시 충돌합니다. 현재 제 개인 4× GB10 환경에서 약 9.4 tok/s로 구동 중입니다.

X에서 CosmicRaisins의 4× GB10용 GLM-5.2 스택에 대한 링크를 보았습니다: vLLM TP=4, MTP speculative decode (추측적 디코딩), 포팅된 sparse-MLA Triton 커널 (Hopper 전용인 _flashmla_C 경로는 sm_121에 존재하지 않음), 그리고 AWQ-INT4 가중치가 들어갈 수 있도록 하는 데이터 프리(data-free) 15% 전문가 프루닝(expert prune)이 적용되어 있습니다. 정말 대단한 작업입니다. 사실 몇 달 전 이 장비들에서 GLM-5.2를 위해 바닐라(vanilla) vLLM을 시도해 보았으나, 512-토큰 컨텍스트 부근에서 무너졌기에 대신 llama.cpp RPC(~5 tok/s)로 서빙해 왔습니다. 작동 가능한 sparse-MLA MTP 경로는 제가 정확히 찾고 있던 것이었습니다. 이를 제 자체 4-노드 Spark 클러스터로 포팅하면서, 공유할 가치가 있는 두 가지 장벽에 부딪혔습니다:

첫째, 이미지는 공개 저장소(repo)로부터 재현할 수 없습니다. README는 spark-vllm-docker 포크에 있는 두 가지 vLLM 수정 사항을 가리키고 있지만, 이들은 실제로 게시되지 않았습니다 (커널만 게시되어 있습니다). 그래서 저는 공개된 커널로부터 이를 재구성했습니다. 커널을 포함하고, deep_gemm.py를 패치하며 (missing() 게이트 이전에 sm_120/121 제품군에서 3개의 DSA 함수를 sm12x* 폴백으로 라우팅), sparse_attn_indexer.py를 패치하고 (sm12x에서 has_deep_gemm 게이트 제거), flashmla→Triton 몽키패치(monkeypatch)를 자동 적용하며, pip install b12x==0.23.0을 수행하는 단일 build-recon-image.sh 스크립트를 만들었습니다. 배선(wiring)은 GPU에서 빠른 임포트(import) 확인을 통해 검증되었습니다.

둘째, 베이스 vLLM 참조(ref)가 정말 중요합니다. 저자가 고정한 커밋보다 더 최신 버전의 vLLM으로 빌드하면, 실제 AWQ 가중치가 process_weights_after_loading 단계에서 충돌합니다 (k_scale.fill → async CUDA error: invalid argument). 더미(Dummy) 가중치는 잘 로드되었으므로, 이는 실제 가중치 처리 과정에 특화된 문제였습니다. 저자의 정확한 참조(ref)로 vLLM을 다시 빌드하자 즉시 해결되었습니다. 만약 이를 포팅한다면, 반드시 참조(ref)를 고정(pin)하십시오.

기타 포팅 참고 사항: 378 GB의 가중치(weight) 다운로드는 건너뛸 수 있습니다. 15% 프루닝(prune)은 해당 리포지토리의 awq_surgery.py를 통해 cyankiwi AWQ 베이스로부터 결정론적(deterministic)으로 수행됩니다 (~20분 소요, 순수 safetensors 수술 작업).

가용 메모리가 적은 노드에서는 gpu-memory-utilization 0.93 설정 시 부트 가드(boot guard)가 작동합니다. 이 경우 0.90으로 낮추고 max-model-len을 줄이십시오. 공유 파일 시스템(shared FS)이 없다면, 헤드 노드에서 가중치를 NFS-export 하십시오. 그리고 사용 중인 패브릭(fabric)에 맞춰 RoCE HCA/GID-index를 설정하십시오.

결과: 정상적으로 서빙되며 일관된 출력을 생성합니다. 단일 RoCE 레일(rail)에서 약 9.4 tok/s의 디코딩 속도를 기록했으며, 이는 교체 전 llama.cpp 폴백(fallback) 대비 약 2배 성능입니다 (MTP 수락률 ~2.8/4). 저자는 듀얼 레일(dual-rail) 사용 시 약 20 tok/s를 얻습니다. 노드 간 올리듀스(allreduce) 대역폭이 디코딩의 병목 지점이므로, 두 번째 레일이 약 2배의 레버리지 역할을 합니다 (본인의 환경에서는 여전히 NCCL 듀얼 레일 GID 해결 문제를 디버깅 중입니다).

전체 노트 + 나의 포크(fork) + 재구성 스크립트: https://github.com/anvarazizov/glm-5.2-gb10

커널/프루닝/MTP 작업을 수행한 CosmicRaisins에게 큰 공로를 돌립니다 — 이것은 단지 이를 이식 가능하게 만드는 통합 접착제(integration glue)일 뿐입니다. 유지 관리자가 빌드 스크립트를 벤더링(vendor)하여 다른 사람들이 역공학(reverse-engineer)을 할 필요가 없게 해주길 바랍니다.

제출자: /u/anvarazizov
[link] [comments]