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

도입 전에 “이 칩이 기존과 뭐가 다른지”, “인프라를 왜 미리 준비해야 하는지”, “서빙 스택을 어떻게 맞춰야 하는지”를 정리했다.

크게 두 파트로 나눴다:

  • Part 1 — 알고만 있어도 되는 것들: 아키텍처, 하드웨어 스펙, SW 개념. 우리가 직접 건드리는 영역은 아니지만, 왜 프로덕션 설정이 그렇게 생겼는지 이해하는 데 필요하다.
  • Part 2 — 직접 해야 하는 것들: DCGM, k8s 설정, vLLM/SGLang 파라미터, NCCL 튜닝, 관측성 스택. GPU 받기 전부터 준비 가능한 것들이다.

한 줄 요약

B300은 Hopper의 “더 빠른 버전”이 아니라 설계 철학 자체가 다른 칩이다.
아키텍처를 모르면 성능을 못 뽑고, 인프라를 안 깔면 GPU를 못 꽂고, 소프트웨어를 안 맞추면 서빙이 안 뜬다.

Part 1 — 알고만 있어도 되는 것들

1. 듀얼 다이 (Dual Reticle) — B300만의 특징이 아니라 Blackwell 세대 전체의 변화

듀얼 다이는 B300만의 특징이 아니다. B100/B200/B300 등 Blackwell 아키텍처 전체가 채택한 구조적 변화다. H100(Hopper)까지는 monolithic single die였고, Blackwell 세대에서 처음으로 dual-die로 전환됐다.

H100은 단일 다이에 80B 트랜지스터를 집적했다. Blackwell은 두 개의 reticle-size 다이를 10 TB/s chip-to-chip 인터커넥트(NV-HBI)로 연결하여 단일 GPU처럼 동작하게 했다. 이 접근의 실질적인 이유는 수율(yield) 최적화다 — 큰 단일 다이보다 두 개의 작은 다이가 불량률이 낮다.

일반적인 서빙 워크로드에서는 CUDA가 cross-die 통신을 완전히 추상화해주기 때문에 성능 영향은 무시할 수 있다. 다만 커스텀 커널을 작성하거나 Nsight Compute로 프로파일링할 때는 두 다이 구조를 알고 있으면 결과 해석에 도움이 된다.

WHAT:

  • H100: 단일 다이, ~80B 트랜지스터, monolithic
  • B200/B300: 2개의 reticle-size 다이, 총 ~208B 트랜지스터, 다이 간 연결 NV-HBI (10 TB/s)
  • CUDA 레벨에서는 단일 GPU로 추상화됨

Blackwell Ultra GPU Dual Die
Blackwell Ultra GPU: 두 개의 reticle-size 다이를 NV-HBI 10 TB/s로 연결 (출처: NVIDIA Developer Blog)

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

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

  • FP8로 돌리면 B300은 그냥 “약간 빠른 B200”일 뿐이다
  • NVFP4를 써야 비로소 B300의 가격 대비 성능이 정당화된다
  • vLLM 블로그의 DeepSeek-R1 서빙 데이터: B300에서 NVFP4를 사용하면 FP8 대비 GPU를 절반만 써도 더 높은 throughput이 나온다. NVFP4를 못 쓰면 GPU를 두 배로 사야 같은 성능이라는 뜻이다.

“FP4면 정확도가 떨어지지 않나?”에 대한 답도 나와 있다. NVIDIA는 MLPerf 훈련/추론 평가에서 모든 LLM 테스트를 NVFP4로 제출했고, 엄격한 벤치마크 정확도 요구사항을 충족했다. 512개 Blackwell Ultra GPU로 Llama 3.1 405B 사전 훈련을 64.6분에 완료(이전 라운드 대비 1.9배)한 결과도 NVFP4 기반이다.

WHAT:

  • NVFP4: NVIDIA 독자 4-bit 부동소수점 포맷 (IEEE FP4와 다름)
  • NVIDIA 공식 블로그 기준 Blackwell Ultra는 “최대 15 PFLOPS의 고밀도 NVFP4 처리량, 동일 GPU에서 FP8 대비 3배”를 제공

Blackwell Ultra NVFP4 Throughput
NVFP4 처리량 비교 (출처: NVIDIA Developer Blog)

  • FP4 사용 시 메모리 footprint가 FP8 대비 절반 → 같은 GPU 수로 더 큰 모델 서빙 가능

FP4/FP8 성능 비교:

  B300 B200
Dense FP4 ~14 PFLOPS ~9 PFLOPS
Dense FP8 ~7 PFLOPS ~4.5 PFLOPS
8-GPU Sparse FP4 144 PFLOPS ~72 PFLOPS

FP8 vs FP4 — 언제 어느 정밀도를 써야 하는가

NVFP4가 만능은 아니다. 정밀도 선택의 가이드라인:

상황 권장 정밀도 이유
Dense LLM 추론 (Llama 3 등) FP4 우선 시도 throughput 2배, 대부분의 dense 모델에서 품질 저하 미미
MoE 모델 (DeepSeek-R1 등) FP4 우선 시도 expert별 양자화로 품질 유지, 메모리 절감 효과 극대화
코드 생성, 수학 추론 FP8 fallback 검토 정밀한 토큰 생성이 필요한 태스크에서 FP4 품질 저하 사례 보고
Fine-tuned 소형 모델 (<7B) FP8 권장 파라미터가 적을수록 양자화 오차에 민감
학습 (training) FP8 (Transformer Engine) FP4 학습은 아직 미지원/불안정

실무 접근법: FP4로 먼저 서빙하고, 오프라인 eval(MMLU, HumanEval 등)에서 품질 저하가 허용 범위를 넘으면 FP8로 fallback한다. 모델별로 FP4/FP8 성능 비교 벤치마크를 도입 초기에 수행하는 것을 권장한다.

flowchart TD
    A["모델 서빙 준비"] --> B{"모델 크기"}
    B -->|"< 7B (fine-tuned)"| C["FP8 권장"]
    B -->|">= 7B"| D{"태스크 유형"}
    D -->|"코드 생성 / 수학 추론"| E["FP8로 시작"]
    D -->|"일반 LLM / MoE 추론"| F["FP4로 시작"]
    F --> G{"오프라인 eval\n품질 OK?"}
    G -->|"Yes"| H["✅ FP4 유지\n(throughput 2x)"]
    G -->|"No"| I["FP8 fallback"]
    E --> J{"성능 부족?"}
    J -->|"Yes"| K["FP4 시도 → eval 재검증"]
    J -->|"No"| L["✅ FP8 유지"]
    style H fill:#198754,color:#fff
    style L fill:#198754,color:#fff
    style C fill:#0d6efd,color:#fff
    style I fill:#0d6efd,color:#fff

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

Long-context/reasoning 모델에서 attention의 softmax(exponential) 연산이 병목이다. 역대 GPU 세대에서 GEMM 속도는 올라갔지만, SFU(Special Function Unit)는 거의 제자리였다.

B300은 이 문제를 정면으로 해결했다. SFU를 대폭 강화하여 attention 처리량을 2배로 올렸다. NVIDIA 아키텍처 페이지에서도 “Blackwell Ultra Tensor 코어는 표준 Blackwell GPU 대비 2배 어텐션 레이어 가속”이라고 명시한다.

Blackwell Ultra Attention Acceleration
Attention 레이어 가속: softmax/SFU 처리량 2배 (출처: NVIDIA Developer Blog)

Long-context 서빙(32K, 128K+)과 reasoning 모델(DeepSeek-R1 등 CoT 계열)에서 TTFT 체감 단축. 반대로 짧은 input/output의 단순 서빙에서는 체감이 크지 않다.

WHAT:

  • DGX B300 기준 attention 성능: DGX B200 대비 2배
  • 이 개선은 GEMM FLOPS 수치에는 안 잡힌다 — 스펙시트만 보면 놓치는 개선점
  • Blackwell Ultra는 표준 Blackwell 대비 1.5배 AI 컴퓨팅 성능 + 2배 어텐션 가속

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

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

WHAT:

  • SM당 256KB TMEM (whitepaper 재확인 필요) — warp-synchronous 중간 결과 저장용
  • 레지스터와 비슷한 속도, 명시적 할당 필요
  • Blackwell 메모리 계층 (빠른 순): TMEM/Register → Shared Memory → L2 Cache → HBM3e

Blackwell Ultra SM Architecture
Blackwell Ultra SM 아키텍처: TMEM 포함 (출처: NVIDIA Developer Blog)

graph TD
    A["TMEM / Register\nSM당 256KB | ~레지스터 속도"] --> B["Shared Memory\nSM당 228KB"]
    B --> C["L2 Cache"]
    C --> D["HBM3e\n288GB | ~8 TB/s"]
    style A fill:#dc3545,color:#fff
    style B fill:#fd7e14,color:#fff
    style C fill:#20c997,color:#fff
    style D fill:#0d6efd,color:#fff

5. FP64 급락 — AI 워크로드 입장에서는 사실상 무의미한 수치

FP64 성능의 세대별 흐름:

GPU FP64 비고
H100 SXM5 ~67 TFLOPS Hopper 세대, Tensor Core FP64
B200 37 TFLOPS Blackwell, CUDA Core FP64 (Tensor Core FP64 제거/극소화)
B300 1.25 TFLOPS Blackwell Ultra, CUDA Core FP64

숫자만 보면 B300이 크게 퇴보한 것처럼 보이지만, 현대 LLM 학습과 추론에서 FP64는 쓰이지 않는다.

실제 LLM 학습의 precision 구성:

Forward/Backward : BF16 (또는 FP16)
Master weight    : FP32  ← optimizer state 보관용
Optimizer state  : FP32 (Adam의 m, v)

이게 Mixed Precision(AMP)이다. FP32는 optimizer state 보관에만 쓰이고, 실제 연산은 BF16이 담당한다. 순수 FP64 연산은 등장하지 않는다. B200도 FP64 수치가 B300보다 높을 뿐, AI 학습/추론 전용 칩이지 과학계산용이 아니다.

FP64가 의미 있는 영역은 유체역학, 분자동역학, 양자화학 같은 HPC/과학계산 도메인이다. 그쪽 워크로드가 있다면 애초에 Blackwell 세대 자체가 맞지 않는다.

오히려 precision 트렌드는 반대 방향이다:

  • 학습: BF16 → FP8 (Transformer Engine)
  • 추론: FP8 → FP4 (NVFP4)

B300의 FP64 급락은 “AI inference 전용으로 설계됐다”는 NVIDIA의 방향성을 확인해주는 숫자다. 우리 팀 워크로드 기준으로는 신경 쓸 필요 없는 지표다.

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

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

  • H100 = SM90
  • B200 = SM100
  • B300 = SM103 (공식 확정 여부 확인 필요)

SM90(Hopper)용 cubin은 SM103에서 돌아가지 않는다. PTX가 포함되어 있으면 JIT 컴파일로 돌아가긴 하지만 성능이 최적이 아니다.

WHAT:

  • CUDA 13.0+ (예정)에서 SM103 최적 지원, Driver 580+ (예정)
  • sm_100a, compute_100a 같은 아키텍처 특화 기능은 forward/backward 호환 안 됨

7. SM103 호환성 — 왜 컨테이너 이미지를 전부 다시 빌드해야 하는가

기존 H100(SM90) 기반으로 빌드한 컨테이너 이미지를 B300에 그대로 올리면:

  • cubin이 SM90 전용이면 커널이 아예 실행되지 않는다
  • PTX가 포함되어 있으면 JIT 컴파일로 돌아가긴 하지만, 첫 기동 시 수 분의 JIT 오버헤드 + 네이티브 대비 성능 저하
  • PyTorch/Triton 자체가 SM103을 인식하지 못하는 버전이면 에러로 즉사

최소 요구 스택

컴포넌트 최소 버전 비고
NVIDIA Driver 580+ (예정) SM103 네이티브 지원
CUDA Toolkit 13.0+ (예정) SM103 cubin 생성 가능
PyTorch nightly 또는 최신 stable torch 2.9.1의 Triton이 SM103 PTXAS 미지원 이슈 있었음
cuDNN 9.x+ Blackwell 최적화 커널 포함

8. 전력 — 왜 GPU 발주보다 먼저 확인해야 하는가

H100은 GPU당 700W, B300은 1,400W다. 정확히 2배.

8-GPU DGX B300 시스템 하나가 피크 기준 약 14kW. 전력 증설은 리드타임이 가장 긴 작업이다. 수전 용량 증설은 몇 달에서 반년 이상 걸릴 수 있다.

항목 H100 B200 B300
GPU당 TDP 700W 1,000W 1,400W
8-GPU 시스템 전체 ~10-11kW ~14kW ~14.5kW

도입 전에 확인: 랙당 전력 예산, PDU 용량, 증설 필요 시 시설 담당 부서와 GPU 발주보다 먼저 협의.

9. 네트워크 — 왜 400Gbps로는 부족한가

B300 세대는 ConnectX-8 SuperNIC (800 Gb/s) 이다. 기존 H100 세대의 ConnectX-7 (400 Gb/s)으로는 B300의 처리량을 소화하지 못한다.

항목 H100 세대 B300 세대
NIC ConnectX-7 ConnectX-8 SuperNIC
속도 400 Gb/s 800 Gb/s
스위치 Quantum-2 Quantum-X800
GPU:NIC 비율 다양 1:1
노드 내 NVLink 900 GB/s/GPU 1.8 TB/s/GPU
NVSwitch 3세대 5세대

노드 내 NVLink 토폴로지에서 NVSwitch 5세대가 GPU 간 all-to-all 통신을 중재한다. NVSwitch 5세대는 NVLink 5.0의 1.8 TB/s/GPU 대역폭을 8-GPU 노드 내에서 full bisection bandwidth로 제공하며, 이전 세대 대비 대역폭이 2배로 증가했다.

graph TB
    subgraph "DGX B300 Node"
        NVS["NVSwitch 5세대"]
        G0["GPU 0"] <-->|"1.8 TB/s"| NVS
        G1["GPU 1"] <-->|"1.8 TB/s"| NVS
        G2["GPU 2"] <-->|"1.8 TB/s"| NVS
        G3["GPU 3"] <-->|"1.8 TB/s"| NVS
        G4["GPU 4"] <-->|"1.8 TB/s"| NVS
        G5["GPU 5"] <-->|"1.8 TB/s"| NVS
        G6["GPU 6"] <-->|"1.8 TB/s"| NVS
        G7["GPU 7"] <-->|"1.8 TB/s"| NVS
    end
    subgraph "Inter-Node Fabric"
        SW["Quantum-X800\nSwitch"]
    end
    G0 ---|"ConnectX-8\n800 Gb/s"| SW
    G7 ---|"ConnectX-8\n800 Gb/s"| SW
    style NVS fill:#7c3aed,color:#fff
    style SW fill:#0d6efd,color:#fff

Grace Blackwell Ultra with ConnectX-8
Grace Blackwell Ultra Superchip + ConnectX-8 SuperNIC (출처: NVIDIA Developer Blog)

기존 400 Gb/s InfiniBand를 그대로 쓸 수는 있지만, B300의 성능을 온전히 활용하려면 800 Gb/s로 업그레이드 필요. 서빙이 단일 노드 내에서 완결된다면(TP2로 대형 모델 서빙 등) 노드 간 네트워크 병목은 상대적으로 덜하다.

10. 토폴로지 재설계 — 288GB가 바꾸는 배치 전략

HBM3e 메모리 대역폭 비교

LLM 추론은 대부분 memory-bandwidth bound다. FLOPS보다 메모리 대역폭이 실질적인 throughput 상한을 결정한다. B200과 B300의 메모리 대역폭은 동일하므로, FP8 추론에서는 토큰 생성 속도(decode) 차이가 크지 않다. NVFP4를 사용해야 weight 크기가 절반으로 줄어 같은 대역폭으로 2배의 weight를 읽을 수 있고, 이것이 B300의 실질적 성능 이점이 된다.

WHAT:

GPU HBM 용량 메모리 대역폭
H100 SXM5 80 GB (HBM3) ~3.35 TB/s
B200 192 GB (HBM3e) ~8 TB/s
B300 288 GB (HBM3e) ~8 TB/s

HBM Capacity Scaling
세대별 HBM 용량 스케일링 (출처: NVIDIA Developer Blog)

288GB HBM3e가 기존의 모델 배치 전략의 전제를 바꾼다.

  • H100 (80GB): 70B 모델 서빙에 TP4~TP8 기본
  • B300 (288GB): DeepSeek-R1 (671B MoE) NVFP4 기준으로 GPU 2장이면 전체 weight 탑재

TP degree가 줄어들면 같은 GPU 수로 더 많은 모델 인스턴스를 띄울 수 있다. 도입 전에 답해야 할 질문:

  • 우리 모델들의 NVFP4 weight size별 최소 TP degree는 얼마인가?
  • GPU가 남는다면 추가 replica로 쓸지, 다른 모델에 할당할지?
  • MoE 모델은 EP가 유리한지 TP가 유리한지?

MoE 모델의 Expert Parallelism(EP) 전략

MoE 모델(DeepSeek-R1 등)에서는 전통적인 Tensor Parallelism(TP)만으로는 최적이 아닐 수 있다. B300의 288GB + NVLink 5.0(1.8 TB/s) 환경에서는 Expert Parallelism(EP)이 특히 유리하다:

  • 288GB면 많은 expert를 단일 GPU에 수용 가능 → EP degree를 낮게 유지
  • NVLink 5.0의 1.8 TB/s 대역폭이 all-to-all 통신 병목을 완화
  • DeepSeek-R1(256 experts) 같은 모델에서 EP8 (노드 내 8-GPU) 구성이 자연스럽게 맞음

NVIDIA의 MoE 추론 최적화 블로그에 따르면, Blackwell에서 SW 최적화만으로 동일 플랫폼에서 3개월간 GPU당 처리량 2.8배 증가를 달성했다. 핵심 최적화는 Programmatic Dependent Launch(커널 실행 간 지연 감소)와 All-to-All 통신 개선(중간 수신 버퍼 제거)이다.

WHAT:

전략 장점 단점 적합한 경우
TP 구현 단순, 모든 프레임워크 지원 all-reduce 통신 오버헤드, GPU당 메모리 비효율 Dense 모델, 소규모 MoE
EP expert별 독립 처리, 메모리 효율적 all-to-all 통신 필요, 라우팅 불균형 시 GPU idle 대규모 MoE (expert 수 > GPU 수)
TP + EP 하이브리드 통신과 메모리의 균형 설정 복잡도 증가 대규모 MoE + 멀티노드

vLLM, SGLang 모두 EP를 지원하며, NVIDIA Dynamo의 KV-aware routing과 결합하면 MoE 라우팅 효율을 더 높일 수 있다.

11. 폼팩터 선택 — DGX vs HGX vs GB300 NVL72

시스템 구성 특징 적합한 경우
DGX B300 8x B300, Intel Xeon NVIDIA 턴키 시스템 빠른 도입, 관리 단순화 우선
HGX B300 8x B300, OEM 선택 CPU/쿨링/섀시 선택 가능 유연한 구성, 기존 인프라 활용
GB300 NVL72 72x B300 + 36 Grace CPU 랙 단위 단일 NVLink 도메인 초대형 모델, 하이퍼스케일

서빙이 주 용도인 경우 DGX B300 또는 HGX B300 (8-GPU 노드)가 현실적인 선택지다. GB300 NVL72는 수랭 전용에 인프라 요구가 훨씬 크다.

12. vLLM vs SGLang — 왜 지금은 둘 다 준비해야 하는가

Hopper 시절에는 vLLM이 사실상 표준이었고, SGLang은 리서치 프로젝트에 가까웠다. B300 시대에는 판이 바뀌고 있다.

  • B300에서 SGLang이 vLLM보다 전 구간에서 더 높은 throughput을 보이는 경우가 늘고 있다
  • vLLM은 생태계(KServe 연동, OpenAI 호환 API)에서 여전히 우위
  • 모델에 따라 어느 쪽이 유리한지가 다를 수 있다

“하나만 쓰면 된다”가 아니라 “둘 다 돌려보고 모델별로 최적을 고르는” 시대가 됐다.

항목 vLLM SGLang TensorRT-LLM
B300 공식 지원 O (GB300/B300 검증 완료) O (GB200/B300 명시) O (NVIDIA 자체 최적화)
NVFP4 FlashInfer FP4 MoE 커널 지원 FlashInfer FP4 커널 지원 최초/최적 NVFP4 지원 — NVIDIA 내부 커널 직접 활용
Attention 커널 FlashAttention 3/4, cutlass_mla FlashInfer, TRT-LLM NSA 커널 FusedAttention, XQA 커널 (Blackwell 네이티브)
Disaggregated serving 지원 (NVIDIA Dynamo 연동) 지원 (자체 PD disaggregation) 지원 (Dynamo 네이티브 통합)
Blackwell 전용 Docker NVIDIA NGC vLLM 이미지 lmsysorg/sglang:*-blackwell NVIDIA NGC TensorRT-LLM 이미지
생태계 KServe 연동, OpenAI API 호환 Anthropic API 호환 추가, 커뮤니티 성장 중 Triton Inference Server 연동, NVIDIA 에코시스템 중심

TensorRT-LLM은 NVIDIA가 직접 개발하는 서빙 엔진으로, NVFP4를 최초로 지원했고 Blackwell 하드웨어에 대한 최적화 수준이 가장 높다. 다만 오픈소스 커뮤니티 생태계는 vLLM/SGLang 대비 제한적이며, 모델 지원 범위가 NVIDIA가 공식 최적화한 모델 위주다. NVFP4 성능을 최대한 끌어내야 하는 경우 TensorRT-LLM을 벤치마크 후보에 반드시 포함해야 한다.

참고: NVIDIA MoE 추론 블로그에 따르면, TensorRT-LLM에서 Multi-Token Prediction(MTP) 적용 시 MoE 모델의 처리량이 크게 향상된다. 소프트웨어 최적화만으로 동일 하드웨어에서 3개월간 GPU당 처리량 2.8배 증가를 달성한 사례가 보고되었다. 프레임워크 벤치마크 시 SW 버전에 따른 성능 차이가 클 수 있으므로, 최신 NGC 이미지 기준으로 비교하는 것이 중요하다.

13. NVIDIA Dynamo — 왜 새로운 레이어가 필요해졌는가

vLLM/SGLang이 “서빙 엔진”이라면, Dynamo는 “클러스터 단위 오케스트레이션 레이어”다.

B300 시대의 서빙이 복잡해진 이유:

  • Disaggregated serving: prefill과 decode를 다른 GPU에서 돌리면 그 사이에 KV cache를 옮겨야 한다
  • Dynamic GPU scheduling: reasoning 모델은 output 길이가 예측 불가능해서 고정 할당이 비효율적이다
  • KV-aware routing: 같은 prefix를 가진 요청을 KV cache가 이미 있는 GPU로 보내면 중복 계산을 피할 수 있다

이런 LLM-specific한 스케줄링은 KServe의 Knative autoscaling으로는 해결이 안 된다.

Dynamo가 지금 당장 필요한가? 단일 노드에서 TP2로 서빙하는 구성이면 당장은 없어도 된다. Disaggregated serving, 대규모 MoE EP, 트래픽 변동이 큰 환경에서 진가가 나온다.

flowchart LR
    Client["Client\nRequest"] --> KServe["KServe\n(Gateway)"]
    KServe --> Dynamo["NVIDIA Dynamo\n(KV-aware Routing)"]
    Dynamo --> P["Prefill GPU\n(vLLM / SGLang)"]
    Dynamo --> D["Decode GPU\n(vLLM / SGLang)"]
    P -->|"KV Cache\nTransfer"| D
    D --> Client
    style Dynamo fill:#7c3aed,color:#fff
    style P fill:#198754,color:#fff
    style D fill:#0d6efd,color:#fff

14. 버전 호환성 매트릭스

B300(SM103)은 아직 소프트웨어 생태계가 안정화되지 않은 하드웨어다.

컴포넌트 권장 주의사항
CUDA 13.0+ (예정) SM103 네이티브 지원
Driver 580+ (예정)  
PyTorch nightly 또는 최신 stable 도입 시점에 SM103 지원 여부 재확인
vLLM 최신 release NVIDIA NGC 컨테이너 권장
SGLang 최신 release sglang:*-blackwell 태그 이미지
FlashInfer Blackwell 지원 버전 FP4 MoE 커널 포함 여부 확인
NCCL 시스템 번들 사용 CUDA 13.0 번들 NCCL 권장

이 표는 오늘 기준이다. 도입 직전에 각 프레임워크의 GitHub release notes와 NVIDIA NGC 카탈로그를 반드시 재확인해야 한다.

Part 2 — 직접 해야 하는 것들

16. DCGM — GPU 헬스 모니터링

프로덕션에서 GPU가 죽으면 제일 먼저 DCGM을 봐야 한다. 설정하지 않으면 장애 원인 파악 자체가 불가능하다.

기본 설치 & 헬스체크

dcgmi discovery -l
dcgmi diag -r 1       # 빠른 헬스체크
dcgmi diag -r 3       # 풀 다이어그노스틱 (GPU 입고 시 반드시 실행)
dcgmi stats --enable  # per-process GPU 메트릭 수집

Prometheus 연동

# dcgm-exporter 배포 (DaemonSet)
helm install dcgm-exporter nvidia/dcgm-exporter \
  --set serviceMonitor.enabled=true

핵심 알람 지표

지표 의미 알람 조건
DCGM_FI_DEV_GPU_TEMP GPU 온도 > 85°C
DCGM_FI_DEV_ECC_SBE_VOL_TOTAL Single-bit ECC 에러 누적 급격히 증가 시
DCGM_FI_DEV_ECC_DBE_VOL_TOTAL Double-bit ECC 에러 > 0 이면 교체 검토
DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL NVLink 대역폭 이론치 80% 이하 시
DCGM_FI_DEV_XID_ERRORS XID 에러 XID 79(GPU fell off bus), XID 48(DBE) 즉시 대응

B300에서 NVLink 5.0 bandwidth 저하가 감지되면 토폴로지 문제일 가능성이 높다.

Blackwell에는 RAS(Reliability, Availability, Serviceability) 엔진이 탑재되어 있다. AI 기반으로 수천 개의 데이터 포인트를 모니터링하여 장애를 사전 예측한다. DCGM과 함께 RAS 엔진의 예측 데이터를 활용하면 GPU 교체를 장애 발생 전에 선제적으로 수행할 수 있다.

17. K8s GPU 레이어 — device plugin부터 topology까지

nvidia-device-plugin 설정에서 자주 놓치는 것

config:
  flags:
    migStrategy: "mixed"
    deviceListStrategy: "envvar"
    nvidiaDriverRoot: "/run/nvidia/driver"
  sharing:
    timeSlicing:
      resources:
      - name: nvidia.com/gpu
        replicas: 1    # B300은 time-slicing 금지 — 서빙 프로덕션에서 의미 없음

Topology Manager — NVLink bandwidth 보장을 위해 필수

# kubelet config
topologyManagerPolicy: single-numa-node
cpuManagerPolicy: static

single-numa-node를 안 쓰면 GPU와 CPU가 다른 NUMA 노드에 할당될 수 있다. NVLink bandwidth를 제대로 쓰려면 GPU-CPU-메모리가 같은 NUMA 노드에 있어야 한다.

체크리스트

  • gpu-feature-discovery DaemonSet 배포 → node label 자동 생성 (nvidia.com/gpu.compute.major=10)
  • GPU 노드에 taint + toleration 설정
  • nvidia-container-toolkit 버전 확인 — CUDA 13.0 지원 여부
  • MIG 비추: 288GB라서 쪼개고 싶은 유혹이 있지만, Tensor Parallelism 충돌 + FlashAttention MIG 미지원 케이스가 아직 있다

18. vLLM/SGLang 프로덕션 파라미터 튜닝

vLLM 런 예시

vllm serve deepseek-r1 \
  --tensor-parallel-size 2 \
  --max-num-seqs 256 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \     # 0.95 이상이면 OOM 리스크
  --enable-chunked-prefill \          # long context에서 prefill latency 분산
  --max-num-batched-tokens 8192 \
  --kv-cache-dtype fp8 \              # NVFP4 안 되는 모델 fallback
  --disable-log-requests              # 프로덕션에서 로그 overhead 제거

자주 실수하는 것들

  • --gpu-memory-utilization 너무 높게 잡으면 KV cache OOM이 워크로드 중간에 터진다
  • --max-num-seqs가 너무 작으면 B300의 throughput을 못 뽑는다 — 배치 사이즈가 핵심이다
  • chunked prefill 비활성 시 long-context 요청 하나가 decode 전체를 블록킹한다

KServe InferenceService에 반영할 것

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llm-serving
spec:
  predictor:
    containers:
    - name: kserve-container
      image: custom-vllm:cuda13.0-sm103       # (1) CUDA 13.0+ 이미지
      env:
      - name: VLLM_USE_FLASHINFER_MOE_FP4     # (2) NVFP4 활성화
        value: "1"
      resources:
        limits:
          nvidia.com/gpu: "2"                 # (3) TP8 → TP2로 변경 (288GB 덕분)
      readinessProbe:
        initialDelaySeconds: 120              # (4) 모델 로딩 시간 조정

19. NCCL 튜닝 — 멀티노드에서 성능이 안 나오면 여기를 봐야 한다

export NCCL_DEBUG=INFO
export NCCL_IB_DISABLE=0                   # InfiniBand 사용 환경
export NCCL_IB_HCA=mlx5_0,mlx5_1
export NCCL_SOCKET_IFNAME=eth0
export NCCL_P2P_DISABLE=0                 # NVLink P2P 반드시 활성화
export NCCL_TOPO_FILE=/path/to/topo.xml

B300 DGX 기준으로 nccl-tests로 AllReduce bandwidth를 먼저 측정하고, 이론치(NVLink 5.0 ~1.8 TB/s bisection) 대비 80% 이상 안 나오면 토폴로지나 드라이버 문제다.

20. OS/Infra 기본 설정

커널 파라미터

# /etc/sysctl.conf
vm.nr_hugepages = 4096
kernel.numa_balancing = 0       # NUMA auto-balancing 끄기
net.core.rmem_max = 134217728

GPU Persistence Mode

nvidia-smi -pm 1   # 안 켜면 첫 요청마다 GPU init overhead 발생
# 부팅 시 자동 적용하려면 systemd service로 등록

21. 관측성 스택 — 없으면 병목 찾기 불가능

┌─────────────────────────────────────┐
│         Grafana Dashboard           │
├────────────┬────────────────────────┤
│ Prometheus │  (scrape targets)      │
├────────────┼────────────────────────┤
│dcgm-exporter│ vLLM /metrics        │
│ (GPU 지표) │ (throughput/latency)  │
└────────────┴────────────────────────┘

vLLM /metrics 엔드포인트에서 핵심 4개:

지표 의미
vllm:num_requests_running 실시간 배치 크기
vllm:gpu_cache_usage_perc KV cache 사용률
vllm:time_to_first_token_seconds TTFT P99
vllm:time_per_output_token_seconds TPOT P99

이 4개 + DCGM GPU util + NVLink bandwidth를 하나의 대시보드에 올려놓는 것이 프로덕션 최소 요건이다.

GTC 2026에서 확인된 것들

GTC 2026 키노트(2026년 3월)에서 B300 관련으로 확인된 주요 내용:

벤치마크 결과:

  • GPT-4급 모델 학습 throughput: B200 대비 35% 향상
  • LLM 서빙 tokens/s: 45-50% 향상
  • GB300 NVL72: GB200 NVL72 대비 1.5배 AI 성능

가격 및 가용성:

  • B300 단가: $40,000-$50,000 (B200 대비 프리미엄)
  • DGX B300 시스템: ~$300,000 (하이퍼스케일러 볼륨 ~$250,000)
  • 2026년 1월 출하 시작, Q1-Q2 클라우드 가용성 확대 중

소프트웨어:

  • NVIDIA Dynamo 오픈소스 추론 프레임워크 공식 발표 — reasoning AI 서비스의 throughput 극대화 + 응답 시간 단축 목적
  • Agentic AI가 B300의 핵심 타깃 워크로드로 명시됨

로드맵:

  • B300은 Blackwell → Rubin 사이의 mid-cycle refresh 포지션
  • Vera Rubin (2027): Rubin GPU + Vera CPU(72 Grace ARM 코어) + NVLink 6
  • Feynman (2028): 차세대 GPU + LPU + Rosa CPU
  • Jensen Huang: “1년 주기 GPU 케이던스” 재확인

우리 팀 입장에서 의미 있는 포인트: Dynamo가 공식 오픈소스가 됐고, 45-50% 서빙 성능 향상이 공식 벤치마크로 확인됐다. Vera Rubin이 2027이므로 B300은 최소 1년간 최신 세대로 운용된다.

도입 로드맵

단계 할 일 GPU 필요 여부 시기
0단계 전력/쿨링/네트워크 인프라 협의, 버전 매트릭스 조사, 이미지 빌드, manifest 수정, DCGM/관측성 스택 구성 불필요 지금 즉시
1단계 클라우드 B300에서 smoke test (vLLM + SGLang 양쪽) 클라우드 GPU 발주 후
2단계 모델별 NVFP4 정확도 검증 & throughput/latency 벤치마크 클라우드 또는 온프레미스 GPU 도착 전후
3단계 KServe 서빙 안정화, 모델별 최적 프레임워크 확정 온프레미스 GPU 도착 후
4단계 Disaggregated serving / Dynamo 평가 (필요 시) 온프레미스 안정화 후

0단계는 GPU 없이도 할 수 있다. 지금 당장 시작할 수 있고, 시작해야 한다.

참고 자료:

댓글남기기

참고

vLLM 스터디 1회차 — 도입부 & Engine 진입

새로운 스터디를 시작했다. Aleksa Gordic의 Inside vLLM: Anatomy of a High-Throughput LLM Inference System을 돌아가면서 발표하는데, 단순 발표가 아니라 현재 vLLM 코드베이스까지 같이 따라가면서 보기로 했다.