올해 팀에서 B300을 다수 도입할 예정이다. 학습도 하지만 주로 서빙 용도로, vLLM/SGLang/KServe 기반 Kubeflow 파이프라인 위에서 운용하게 된다.

도입 전에 “이 칩이 기존과 뭐가 다른지”를 팀 전체가 이해해야 한다고 생각해서 정리를 시작했다. 스펙시트를 나열하는 것보다 왜(WHY) 이걸 알아야 하는지가 먼저 납득이 되어야 구체적인 내용(WHAT/HOW)도 의미가 생긴다는 생각에, WHY 중심으로 써본다.

이 글은 세 편 중 첫 번째로, Blackwell 아키텍처 자체에 집중한다.

한 줄 요약

B300은 Hopper의 “더 빠른 버전”이 아니라, 설계 철학 자체가 다른 칩이다.
Hopper 감각으로 접근하면 B300 성능의 절반도 못 뽑는다.

1. 듀얼 다이 (Dual Reticle) — 하나인 척하는 두 개의 칩

WHY

B300은 단일 칩(monolithic)이 아니라 두 개의 다이가 하나의 GPU로 동작하는 구조다. 겉으로는 하나의 GPU처럼 보이지만, 내부적으로 두 다이 사이에 데이터가 오가는 cross-die 통신이 존재한다.

이걸 모르면 이런 일이 생긴다:

  • 커널이 두 다이에 걸쳐 실행될 때 예상치 못한 latency가 나타남
  • 프로파일링 결과에서 “왜 bandwidth가 이론치보다 낮지?” 하는 의문이 생김
  • 모델 parallelism 전략 수립 시 intra-GPU 통신 비용을 간과하게 됨

WHAT

  • 2개의 reticle-size 다이, 총 ~208B 트랜지스터
  • 다이 간 연결: NV-HBI (10 TB/s) — 충분히 빠르지만 0은 아니다
  • CUDA 레벨에서는 단일 GPU로 추상화됨
  • 8 GPC, 160 SM (full implementation 기준, SKU에 따라 다를 수 있음)

실무에서는

서빙 워크로드에서는 CUDA 추상화가 대부분 잘 처리해준다. 하지만 커스텀 커널을 작성하거나 Nsight Compute로 프로파일링할 때, 두 다이 간 데이터 이동 패턴을 이해하고 있어야 병목을 정확히 짚을 수 있다.

2. NVFP4 — B300을 사는 진짜 이유

WHY

B300의 존재 이유가 NVFP4라고 해도 과언이 아니다.

Hopper에서는 FP8이 “새로운 정밀도”였고, 대부분의 서빙이 FP16/FP8 기반이었다. B300은 FP4를 네이티브로 지원하면서 inference FLOPS가 ~15 PFLOPS에 도달했다.

핵심은 이것이다:

  • FP8로 돌리면 B300은 그냥 “약간 빠른 B200”일 뿐이다
  • NVFP4를 써야 비로소 B300의 가격 대비 성능이 정당화된다
  • NVFP4 quantization 파이프라인이 없으면 B300을 살 이유가 반감된다

WHAT

  • NVFP4: NVIDIA 독자 4-bit 부동소수점 포맷 (IEEE FP4와 다름)
  • 5세대 Tensor Core + 2세대 Transformer Engine이 자동으로 FP4 ↔ 고정밀도 변환 관리
  • Dense FP4: B300 ~14 PFLOPS vs B200 ~9 PFLOPS (약 55% 향상)
  • FP4 사용 시 메모리 footprint가 FP8 대비 절반 → 같은 GPU 수로 더 큰 모델 서빙 가능

실무에서는

실제 벤치마크를 보면 이 차이가 극명하다. vLLM 블로그에서 공개한 DeepSeek-R1 서빙 데이터를 보면, B300에서 NVFP4를 사용하면 FP8 대비 GPU를 절반만 써도 더 높은 throughput이 나온다. 반대로 말하면, NVFP4를 못 쓰면 GPU를 두 배로 사야 같은 성능이라는 뜻이다.

도입 전에 우리가 서빙하는 모델들의 NVFP4 quantization 지원 여부와 정확도 검증이 최우선 체크 항목이 된다.

3. Attention 가속 2배 — 진짜 병목은 GEMM이 아니었다

WHY

서빙(inference)에서 실제 비용의 대부분은 attention 연산이 지배한다.

매 generation step마다 GEMM도 하지만, long-context/reasoning 모델에서는 attention의 softmax(exponential) 연산이 병목이다. 그런데 역대 GPU 세대에서 Tensor Core의 행렬곱 속도는 세대마다 올라갔지만, exponential/transcendental 연산을 담당하는 SFU(Special Function Unit)는 거의 제자리였다.

GEMM은 빨라졌는데 softmax는 안 빨라진 것이다. 결과적으로 세대가 지날수록 attention이 점점 더 큰 병목이 되어왔다.

B300은 이 문제를 정면으로 해결했다. SFU를 대폭 강화하여 attention 처리량을 2배로 올렸다.

WHAT

  • DGX B300 기준 attention 성능: DGX B200 대비 2배
  • SFU 강화로 exponential, reciprocal 등 transcendental math 가속
  • 이 개선은 GEMM FLOPS 수치에는 안 잡힌다 — 스펙시트만 보면 놓치는 개선점

실무에서는

  • Long-context 서빙 (32K, 128K+): attention 병목이 줄어들어 TTFT(Time To First Token)가 체감 수준으로 단축될 수 있다
  • Reasoning 모델 (DeepSeek-R1 등 CoT 계열): 긴 output 생성 중 attention 비용이 누적되는데, 이 부분이 직접 개선된다
  • 반대로, 짧은 input/output의 단순 서빙에서는 체감이 크지 않을 수 있다

4. TMEM (Tensor Memory) — 또 새로운 메모리 계층

WHY

Hopper에서 TMA(Tensor Memory Accelerator)가 도입되면서 “데이터를 대량으로 한번에 로드”하는 패턴이 성능의 핵심이 되었다. B300은 여기서 한 발 더 나아가 TMEM이라는 완전히 새로운 메모리 공간을 추가했다.

이게 중요한 이유는:

  • TMEM은 레지스터와 유사한 속도이지만, 사용자가 직접 할당/관리해야 한다
  • 프레임워크(vLLM, SGLang)가 이걸 활용하는 커널을 쓰느냐 마느냐에 따라 성능이 갈린다
  • 우리가 직접 TMEM 커널을 짤 일은 거의 없지만, 어떤 커널이 TMEM을 활용하는지 판단하는 눈은 필요하다

WHAT

  • SM당 256KB TMEM — warp-synchronous 중간 결과 저장용
  • 레지스터와 비슷한 위치(속도), 명시적 할당 필요
  • Blackwell 메모리 계층 (빠른 순): TMEM/Register → Shared Memory → L2 Cache → HBM3e
  • 2CTA (CTA Pair): 두 CTA가 서로의 TMEM에 접근하여 행렬 연산 효율 극대화

실무에서는

직접 CUDA 커널을 작성하지 않는 한 TMEM을 직접 만질 일은 없다. 하지만 FlashAttention 4, FlashInfer, ThunderKittens 같은 최적화 커널들이 TMEM 활용 여부에 따라 성능 차이가 크다. 서빙 프레임워크를 고를 때 “Blackwell-optimized kernel을 쓰는가?”를 체크해야 하는 근거가 여기에 있다.

다만 솔직히 말하면, 서빙 엔지니어 관점에서는 TMEM 자체보다 다음 섹션(SM103 호환성)이나 NVFP4가 훨씬 급하다. 여기는 “이런 게 있다” 수준으로 알고 넘어가도 된다.

5. FP64 포기 — NVIDIA가 보내는 신호

WHY

B200의 FP64 성능은 37 TFLOPS였는데, B300은 1.25 TFLOPS로 거의 30배 하락했다.

이건 단순한 스펙 변경이 아니라 NVIDIA가 보내는 명확한 메시지다:

“B300은 HPC/과학계산용이 아니라, AI inference 전용 칩이다.”

이 신호를 읽어야 하는 이유:

  • B300으로 학습 외에 과학계산이나 시뮬레이션도 돌리려는 계획이 있다면 재고 필요
  • NVIDIA 로드맵이 inference 쪽으로 기울고 있으며, 향후 SW 최적화도 이 방향에 집중
  • 우리 팀의 GPU 활용 전략(서빙 위주)이 B300 설계 방향과 맞다는 확신의 근거

6. Compute Capability SM103 — 숫자 하나의 무게

WHY

소프트웨어 호환성의 생사가 이 숫자에 달려있다.

  • H100 = SM90
  • B200 = SM100
  • B300 = SM103

SM100용으로 컴파일된 cubin이 SM103에서 돌아갈 수도 있지만 (같은 major 10.x), SM90(Hopper)용 cubin은 SM103에서 돌아가지 않는다. PTX(중간 표현)가 포함되어 있으면 JIT 컴파일로 돌아가긴 하지만, 성능이 최적이 아니다.

실제로 PyTorch stable 버전(torch 2.9.1+cu130)의 Triton이 SM103용 PTXAS를 지원하지 않아서 문제가 됐던 사례도 있다. nightly 버전에서 먼저 고쳐진 뒤에야 해결되었다.

WHAT

  • CUDA 12.8+에서 SM100 네이티브 cubin 생성 가능
  • CUDA 13.0+에서 SM103 최적 지원, Driver 580+
  • PTX만 포함된 바이너리는 JIT으로 돌아가지만, 네이티브 cubin 대비 성능 저하 가능
  • sm_100a, compute_100a 같은 아키텍처 특화 기능은 forward/backward 호환 안 됨
  • CUDA_FORCE_PTX_JIT=1 환경변수로 기존 바이너리의 Blackwell 호환성 테스트 가능

실무에서는

  • Kubeflow 파이프라인의 모든 컨테이너 이미지를 CUDA 13.0+ 기반으로 재빌드 해야 한다
  • 사내 커스텀 CUDA 커널이 있다면 -gencode 플래그에 SM103 추가 필요
  • PyTorch, Triton 등의 버전을 SM103 지원 버전으로 맞춰야 한다
  • 이 작업을 도입 전에 안 하면, GPU는 있는데 서빙이 안 뜨는 상황이 발생한다

정리: Hopper → Blackwell, 뭐가 달라졌나

영역 Hopper (H100/H200) Blackwell Ultra (B300) 왜 중요한가
다이 구조 단일 다이 듀얼 다이 (10TB/s 연결) 프로파일링 해석이 달라짐
핵심 정밀도 FP8 NVFP4 FP4 안 쓰면 투자 대비 성능 반토막
Attention SFU 병목 존재 SFU 2배 강화 서빙 TTFT 체감 개선
메모리 계층 TMA TMA + TMEM 커널 최적화 수준이 성능 좌우
FP64 37 TFLOPS 1.25 TFLOPS AI inference 전용 칩 선언
Compute Cap SM90 SM103 SW 스택 전체 재빌드 필요

마치며

B300은 Hopper의 업그레이드가 아니라 inference를 위해 새로 설계한 칩이다. NVFP4를 쓰느냐 안 쓰느냐가 투자 대비 성능을 결정하고, SM103이라는 숫자 하나가 소프트웨어 스택 전체의 재빌드를 요구한다.

아키텍처를 모르면 성능을 못 뽑고, 인프라를 안 깔면 GPU를 못 꽂고, 소프트웨어를 안 맞추면 서빙이 안 뜬다. 세 가지 중 하나라도 빠지면 B300은 비싼 고철이다.

다음 편에서는 B300 하드웨어와 인프라(전력, 쿨링, 토폴로지)를 왜 미리 준비해야 하는지 다룬다.

참고 자료:

댓글남기기

참고

Blackwell Serving

1편에서 B300의 아키텍처가 왜 다른지, 2편에서 인프라를 왜 먼저 준비해야 하는지를 다뤘다. 이번 3편에서는 그 위에서 실제로 서빙을 올리기 위한 소프트웨어 스택을 왜 지금부터 맞춰야 하는지를 다룬다.

Blackwell Hardware

1편에서 B300이 Hopper와 설계 철학부터 다른 칩이라는 이야기를 했다. 이번 글에서는 그 칩을 물리적으로 운용하기 위해 왜 미리 준비해야 하는지를 다룬다.