저희는 8xB200 노드를 보유하고 있으며, 사용자들은 이 노드에서 GLM-5.2를 어떻게 서빙하는지 계속해서 질문하고 있습니다. 저희 엔지니어링 팀은 지금까지 발표된 모든 내용을 검토했으며, 최적의 설정(config)은 뻔한 방식이 아니라는 결론을 내렸습니다. 대부분의 내용이 B200을 대여하거나 랙에 설치하는 모든 곳에 적용될 수 있으므로 분석 내용을 공유합니다.

모델 (The model)
GLM-5.2: 총 파라미터 ~750B / 활성 파라미터(active) ~40B MoE (256명의 전문가, top-8 라우팅, ~5.9% 희소성(sparsity)), DSA + MLA 어텐션(attention), 1M 컨텍스트(context), MIT 라이선스. 가중치(Weights): FP8에서 ~744 GB, NVFP4에서 ~459 GB (KV 캐시(KV cache)는 FP8 유지).

하드웨어 수학 (The hardware math)
8x B200 SXM = 총 1,440 GB HBM3e, GPU당 8 TB/s, NVLink 5 (GPU당 900 GB/s).

직관적이지 않은 부분: 중간 정도의 동시성(concurrency) 스트림에서의 MoE 디코딩(decode)은 ~40B 활성 파라미터 + 매 단계마다 HBM에서 가져오는 KV 캐시를 수반하며, 이는 연산 제한(compute-bound)이 아닌 대역폭 제한(bandwidth-bound) 문제입니다. 이것이 동일한 FP8 정밀도에서 B200이 H200보다 성능 대비 비용($) 측면에서 약 1.2배 정도만 높은 이유입니다 (이는 FLOPs 비율인 2.3배가 아니라 HBM 대역폭 비율을 따릅니다). 실제로 수치를 변화시키는 레버(lever)는 NVFP4입니다. 단계당 읽어야 할 가중치 바이트가 절반으로 줄어들며, Hopper에는 FP4 텐서 코어(tensor cores)가 전혀 없습니다.

발표된 수치들 (InferenceX / SemiAnalysis - SGLang v0.5.12 + EAGLE MTP, ISL 8192 / OSL 1024)
이것들은 동일한 아키텍처 제품군인 GLM-5 실행 결과입니다. Blackwell 기반의 5.2에 대해서는 현재까지 공개된 것이 제공자 수준의 속도뿐이며, 문서화된 8xB200 설정에서 전체 동시성 스윕(concurrency-sweep) 테이블(tok/s/GPU vs conc vs TPOT)은 아직 찾지 못했습니다 - 잘못된 정보라면 알려주시기 바랍니다. 8K 컨텍스트에서 5.2는 GLM-5와 비슷한 수준에 도달할 것으로 예상되는데, 이는 IndexShare 변경 사항이 주로 긴 컨텍스트(long context)에서 이점을 제공하기 때문입니다.

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 37.3
128 4,116 17.6 56.7

출처: https://inferencex.semianalysis.com/blog/b200-glm5-nvfp4-vs-h200-fp8-3-6x-perf-per-dollar

수식에서 도출되는 결과

NVFP4는 4개의 GPU에 적합합니다. 720 GB HBM 중 459 GB의 가중치(weights)를 사용하면 약 230 GB의 KV 캐시(KV cache) 공간이 남습니다. 따라서 하나의 노드는 로드 밸런서(load balancer) 뒤에서 두 개의 독립적인 TP=4 복제본(replicas)을 지원할 수 있습니다: 2 x 4 x 4,116 ≈ 총 33k tok/s, 이는 FP8 TP=8의 약 15.6k tok/s와 비교됩니다. 동일한 부하 조건에서 노드 처리량(throughput)은 약 2배 더 높으며, 사용자당 속도도 더 빠릅니다. 주의사항: 이는 발표된 단일 복제본 데이터를 기반으로 한 산술적 계산입니다. 노드당 2개의 복제본을 사용하는 테스트 결과는 아직 발표되지 않았으며, 스케줄러(scheduler) 또는 NCCL 경합(contention)으로 인한 일부 손실이 발생할 것으로 예상됩니다.

TP=8 NVFP4는 지연 시간(latency)만을 얻을 뿐, 그 외의 이점은 없습니다: 동시 접속(conc) 4에서 사용자당 140 tok/s를 기록하여 TP=4의 121 tok/s보다 높지만, GPU당 처리량은 절반 수준입니다. 이는 엄격한 TPOT SLA(서비스 수준 계약)를 준수해야 하는 경우에만 정당화됩니다.

비용: SemiAnalysis의 B200 TCO(총 소유 비용)인 GPU당 시간당 $1.95를 기준으로 할 때, NVFP4는 처리량 곡선의 끝단에서 토큰 100만 개당 약 $0.13에 도달합니다. 이들의 H200 FP8 기준값은 사용자당 80 tok/s에서 100만 토큰당 $1.06로, 이 모델 제품군에서 성능 대비 비용(perf/$) 격차는 약 3.5배에 달합니다.

이론상으로는 1M 컨텍스트(100만 토큰)가 수용 가능하지만(FP8 KV 기준 1,440 GB), 단일 1M 토큰 프리필(prefill)은 통합된 엔진을 독점하게 됩니다. 만약 긴 컨텍스트(long-context)가 주요 워크로드라면, 첫날부터 분리된 프리필(disaggregated prefill)을 계획하십시오. IndexShare는 1M 컨텍스트에서 FLOP(부동 소수점 연산)이 2.9배 감소한다고 주장하지만, 아직 독립적인 TTFT(첫 토큰 시간) 측정값은 확인되지 않았습니다.

조용히 잘못된 출력을 생성하는 버전 함정: SGLang <=v0.5.9 버전은 이전의 flashmla_kv 경로(#21291)를 통해 B200에서 GLM 정확도 저하(regression)가 발생했습니다. 이는 크래시(crash) 없이 잘못된 생성 결과(bad generations)를 만들어냅니다. sm100에서 FlashInfer TRT-LLM sparse MLA를 기본값으로 사용하는 v0.5.10 이상 버전을 사용하십시오(#21783). MTP는 사용된 벤치마크 플래그를 명시합니다: --speculative-algorithm EAGLE --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4.

참고: v0.5.10+ 버전은 FP8 경로를 지원합니다. NVFP4 5.2 체크포인트(checkpoints)를 사용하려면 SGLang v0.5.13.post1+ (vLLM v0.23.0+)가 필요합니다.

이로 인해 다음과 같은 질문들이 생깁니다:

1. 5.2 버전의 커뮤니티 NVFP4 양자화(quants) 모델의 품질을 FP8과 비교하여 벤치마크(benchmarked)해 본 분이 계신가요?
2. 실제 운영 환경(production)에서 2x TP=4 레이아웃을 실행 중인 분이 계신가요? 실제 스케줄러(scheduler)를 적용했을 때 이론적인 2배 성능 향상 중 어느 정도가 유지되나요?
3. 다양한 워크로드(workloads)에 걸친 5.2 버전의 MTP 수락률(acceptance rates)은 어떠한가요? GLM-5 데이터에 따르면 디코딩(decode) 성능이 약 40-55% 향상되는 것으로 나타나지만, 이는 워크로드에 따라 달라집니다.

저희는 향후 몇 주 동안 자체 8xB200 노드에 GLM-5.2를 구축할 예정이며, FP8 vs NVFP4, TP=8 vs 2x TP=4, 그리고 롱 컨텍스트(long-context) TTFT를 포함한 측정된 수치들을 전체 bench_serving JSON 파일과 함께 후속 게시물로 공유하겠습니다.
제출자: /u/qubridInc
[link] [comments]