8xB200에서 GLM-5.2 구동하기: 아무도 말해주지 않는 배포 계산 - NVFP4 + 2x TP=4 복제본이 TP=8보다 약 2배 빠름. 전체 설정 가이드 포함.
GLM-5.2 on 8xB200: the deployment math nobody spells out - NVFP4 + 2x TP=4 replicas should beat TP=8 by ~2x. Full config guidance inside.
핵심 요약
8xB200 환경에서 GLM-5.2 모델을 배포할 때 NVFP4와 TP=4 설정을 활용해 효율을 극대화하는 최적의 구성 전략을 분석합니다.
- 최적 배포 구성 — NVFP4와 TP=4를 조합하여 단일 노드에서 2개의 독립적인 복제본을 운영하는 것이 효율적임.
- 대역폭 병목 현상 — B200의 높은 연산 성능보다 HBM 대역폭이 성능을 결정하므로 FP4 가중치 활용이 필수적임.
- 성능 비교 — NVFP4와 TP=4 구성 시 기존 FP8 TP=8 대비 노드 처리량이 약 2배 증가함.
- 주의사항 — SGLang 버전 호환성 및 긴 문맥 처리 시 분산 프리필(disaggregated prefill) 전략이 필요함.
8xB200 노드 굴리는 사람들한테 GLM-5.2 어떻게 돌리냐는 질문을 하도 많이 받아서 정리해 본다. 우리 엔지니어링 팀이 지금까지 나온 자료 다 훑어봤는데, 다들 생각하는 거랑 다르게 최적 설정은 따로 있더라. B200을 어디서 빌려 쓰든, 랙에 박아 쓰든 다 적용되는 내용이니까 공유함.
모델 정보
GLM-5.2: 총 ~750B / 활성 파라미터 ~40B MoE (전문가 256개, top-8 라우팅, 희소성 ~5.9%), DSA + MLA 어텐션, 1M 컨텍스트, MIT 라이선스. 가중치: FP8 기준 ~744 GB, NVFP4 기준 ~459 GB (KV 캐시는 FP8 유지).
하드웨어 계산
8x B200 SXM = 총 HBM3e 1,440 GB, GPU당 8 TB/s, NVLink 5 (GPU당 900 GB/s).
뻔하지 않은 부분: MoE 디코딩은 적당한 동시성에서 매 스텝마다 활성 파라미터 40B랑 KV 캐시를 HBM에서 긁어와야 함. 즉, 연산이 아니라 대역폭이 병목임. 그래서 같은 FP8 정밀도에서 B200이 H200보다 성능/$가 1.2배밖에 안 나오는 거임 (FLOPs 2.3배 차이가 아니라 HBM 대역폭 비율을 따라감). 여기서 판도를 바꾸는 건 NVFP4임. 스텝당 읽어야 할 가중치 바이트가 절반으로 줄어드는데, Hopper는 FP4 텐서 코어가 아예 없거든.
공개된 수치 (InferenceX / SemiAnalysis - SGLang v0.5.12 + EAGLE MTP, ISL 8192 / OSL 1024)
이건 같은 아키텍처 계열인 GLM-5 실행 결과임. Blackwell에서 5.2 돌린 건 아직 공급자 수준의 속도만 나와 있고, 문서화된 8xB200 구성에서 전체 동시성 스윕 테이블(tok/s/GPU vs 동시성 vs TPOT)은 못 찾았음. 혹시 있으면 알려주라. 8K 컨텍스트에서는 5.2가 GLM-5랑 비슷할 걸로 예상함. IndexShare 변경 사항은 주로 긴 컨텍스트에서 효과를 보니까.
FP8, TP=8 (노드 전체, 엔진 하나):
| Conc | tok/s/GPU | tok/s/user | TPOT (ms) |
|---|---|---|---|
| 4 | 417 | 100.9 | 9.9 |
| 16 | 953 | 56.9 | 17.6 |
| 64 | 1,619 | 23.6 | 42.5 |
| 256 | 1,947 | 11.9 | 84.2 |
NVFP4, TP=4 (노드 절반):
| Conc | tok/s/GPU | tok/s/user | TPOT (ms) |
|---|---|---|---|
| 4 | 1,039 | 121.2 | 8.3 |
| 16 | 2,228 | 66.3 | 15.1 |
| 64 | 3,740 | 26.8 |
