NVIDIA가 세계 최고 속도의 거대 언어 모델(LLM) 추론 성능을 달성했습니다. NVIDIA Blackwell GPU 8개를 탑재한 단일 NVIDIA DGX B200 노드는 Llama 4 컬렉션 중 가장 크고 강력한 모델인 4천억 매개변수 규모의 Llama 4 Maverick 모델에서 사용자당 초당 1,000토큰(TPS)을 넘는 성능을 구현할 수 있습니다. 이 속도는 AI 벤치마크 서비스인 Artificial Analysis에 의해 독립적으로 측정되었습니다.
이번 기록으로, NVIDIA Blackwell은 Llama 4를 위한 모든 배포 시나리오에서 최적의 하드웨어로 자리 잡았습니다.
처리량을 극대화하든, 지연 시간을 최소화하든 상관없이 마찬가지입니다. NVIDIA Blackwell은 이 모델에서 사용자당 1,000 TPS를 돌파한 최초의 플랫폼이며, 최대 처리량 설정에서는 서버당 72,000 TPS에 도달합니다.
NVIDIA는 TensorRT-LLM을 활용해 Blackwell GPU의 성능을 극대화하기 위한 소프트웨어 최적화를 대대적으로 진행했으며, EAGLE-3 기법을 사용해 speculative decoding draft 모델을 훈련시켰습니다. 이러한 접근법을 결합해, NVIDIA는 기존 Blackwell 기준 대비 4배 빠른 속도를 달성했습니다. B200 하드웨어에 접근할 수 있다면, 이 배포 가이드를 참고해 직접 Llama 4 Maverick의 가속화된 엔드포인트를 구축할 수 있습니다.
모델 정확도 결과
아래에 설명된 최적화는 응답 정확도를 유지하면서도 성능을 크게 향상시킵니다. 우리는 GEMM, Mixture of Experts(MoE), Attention 연산에 FP8 데이터 타입을 적용해 모델 크기를 줄이고, Blackwell Tensor Core 기술로 가능한 높은 FP8 처리량을 활용했습니다. FP8 데이터 형식을 사용할 경우의 정확도는 여러 지표에서 Artificial Analysis의 BF16 결과와 동등하게 나타났습니다. 해당 내용은 아래 표에 요약되어 있습니다.
LiveCodeBench | AIME 2024 | GPQA Diamond | MATH-500 | |
AA Reference Llama 4 Maverick (BF16) | 0.397 | 0.39 | 0.671 | 0.889 |
Optimized Llama 4 Maverick (FP8) | 0.383 | 0.40 | 0.686 | 0.876 |
왜 지연 시간을 최소화하는 것이 중요할까?
대부분의 생성형 AI 애플리케이션은 처리량과 지연 시간 사이의 균형을 요구합니다. 이는 많은 사용자가 동시에 ‘충분히 좋은’ 경험을 누릴 수 있도록 하기 위함입니다. 하지만, 빠른 판단이 요구되는 중요한 애플리케이션에서는 단일 사용자에 대한 지연 시간을 최소화하는 것이 핵심 과제가 됩니다. TPS/user 기록이 보여주듯, Blackwell 하드웨어는 어떤 작업에도 최적의 선택입니다. 처리량 극대화, 처리량과 지연 시간의 균형, 또는 단일 사용자를 위한 지연 시간 최소화 등 어떤 목적이든 Blackwell이 가장 뛰어난 성능을 발휘합니다. 이번 글에서는 그중에서도 지연 시간 최소화에 초점을 맞춥니다.
지연 시간 최소화를 위한 최적화
아래는 추론 과정에서 NVIDIA가 적용한 커널 최적화 및 커널 결합(빨간 점선 사각형으로 표시됨)에 대한 개요입니다.
NVIDIA는 저지연 GEMM 커널을 여러 개 구현했으며, Blackwell이 지연 시간 최소화 시나리오에서 뛰어난 성능을 낼 수 있도록 다양한 커널 결합을 적용했습니다. 예를 들어 FC13 + SwiGLU, FC_QKV + attn_scaling, AllReduce + RMSnorm 같은 결합이 이에 해당합니다.

CUDA 커널 최적화 및 결합
NVIDIA는 Blackwell GPU에서 최고의 성능을 구현하기 위해 GEMM, MoE, Attention 연산에 사용되는 CUDA 커널을 최적화했습니다.
- NVIDIA는 공간 분할(warp specialization이라고도 함)을 적용하고, GEMM 커널이 메모리에서 데이터를 효율적으로 불러올 수 있도록 설계하여, NVIDIA DGX 시스템이 제공하는 총 64TB/s의 HBM3e 대역폭을 최대한 활용했습니다.
- 또한, Blackwell의 5세대 Tensor Core를 활용한 행렬 곱 연산 이후, Tensor Memory에서 연산 결과를 불러올 때 더 나은 메모리 레이아웃이 되도록 GEMM weight를 swizzled 포맷으로 재배열했습니다.
- Attention 커널의 성능은 K와 V 텐서의 시퀀스 길이 방향으로 연산을 분할함으로써 최적화되었으며, 이를 통해 연산을 여러 CUDA thread block에서 병렬로 실행할 수 있게 했습니다.
- 추가로, NVIDIA는 분산 공유 메모리를 활용해 동일한 thread block cluster 내에서 결과를 효율적으로 집계할 수 있도록 했으며, 이 과정에서 글로벌 메모리에 접근할 필요가 없도록 했습니다.
- 커널 실행 간의 오버헤드와 메모리 입출력 부담을 줄이기 위해 연산 간 결합(fusion)도 적용했습니다. 예를 들어, NVIDIA는 AllReduce 연산을 뒤따르는 RMSNorm 연산과 Quantize 연산을 하나의 CUDA 커널로 통합했으며, 또한 SwiGLU 연산을 앞선 GEMM과 결합했습니다.
Programmatic Dependent Launch (PDL)
Programmatic Dependent Launch(PDL)은 동일한 CUDA 스트림 상에서 연속적으로 실행되는 두 CUDA 커널 사이의 GPU 유휴 시간을 줄이고, 경우에 따라 두 커널의 실행을 겹칠 수 있도록 해주는 CUDA 기능입니다.
기본적으로, 동일한 CUDA 스트림에서 커널이 실행될 경우 두 번째 커널은 첫 번째 커널이 완료될 때까지 실행되지 않습니다. 이로 인해 성능상 두 가지 문제가 발생합니다. 첫째, 아래 그림에서 보이는 것처럼 연속된 커널 실행 사이에 미세한 공백이 생기며, 이때 GPU는 유휴 상태가 됩니다. 둘째, 첫 번째 커널 실행이 거의 끝나갈 때, 남은 CUDA block을 실행하기 위해 일부 Streaming Multiprocessor(SM)는 여전히 사용되지만 나머지 SM은 유휴 상태로 남게 됩니다. 이로 인해 GPU의 연산 자원이 충분히 활용되지 못하는 문제가 생깁니다.

CUDA의 프로그래밍 방식 종속 실행 API를 사용하여 NVIDIA는 기본 커널이 아직 실행 중일 때 보조 커널이 실행을 시작할 수 있도록 합니다. 프리앰블 기간 동안 보조 커널은 기본 커널의 실행에 의존하지 않는 계산을 실행하고 데이터를 로드할 수 있습니다. 이것은 두 연속된 커널 사이의 간격을 제거할 뿐만 아니라 GPU 활용도를 향상시킵니다. 첫 번째 커널이 GPU의 SM 중 일부만 차지하는 동안, 나머지 SM은 두 번째 커널을 실행하기 시작할 수 있습니다.

추측적 디코딩
Speculative decoding은 생성된 텍스트의 품질을 유지하면서 LLM의 추론 속도를 높이기 위해 널리 사용되는 기법입니다. 이 방식은 작고 빠른 ‘draft’ 모델이 예측한 speculative 토큰 시퀀스를, 더 크고 정교한 ‘target’ LLM이 병렬로 검증하는 구조를 통해 속도를 끌어올립니다. 속도 향상은 하나의 target 모델 반복 과정에서 여러 토큰을 한꺼번에 생성함으로써 이루어지며, 그 대가로 draft 모델의 추가 연산 비용이 발생합니다.

이 사이클은 반복되며, accept된 토큰은 그대로 유지되고 reject가 발생한 경우 Target 모델이 올바른 다음 토큰(t4 등)을 생성한 뒤, Draft 모델이 새로운 speculative 시퀀스(d5~d7)를 다시 생성합니다. 이렇게 느린 Target 모델로 토큰을 하나씩 생성하는 대신, Draft 모델의 빠른 예측을 바탕으로 여러 토큰을 병렬로 검증하면 전체 추론 속도를 크게 높일 수 있으며, 특히 Draft 모델의 예측 정확도가 높을수록 그 효과는 더욱 커집니다. Acceptance Length(AL)은 한 번의 검증 단계로 평균 몇 개의 토큰을 생성할 수 있는지를 나타내며, AL이 높을수록 속도 향상 폭도 커집니다.
이 사이클은 반복되며, accept된 토큰은 그대로 유지되고 reject가 발생한 경우 Target 모델이 올바른 다음 토큰(t4 등)을 생성한 뒤, Draft 모델이 새로운 speculative 시퀀스(d5~d7)를 다시 생성합니다. 이렇게 느린 Target 모델로 토큰을 하나씩 생성하는 대신, Draft 모델의 빠른 예측을 바탕으로 여러 토큰을 병렬로 검증하면 전체 추론 속도를 크게 높일 수 있으며, 특히 Draft 모델의 예측 정확도가 높을수록 그 효과는 더욱 커집니다. Acceptance Length(AL)은 한 번의 검증 단계로 평균 몇 개의 토큰을 생성할 수 있는지를 나타내며, AL이 높을수록 속도 향상 폭도 커집니다.
NVIDIA는 speculative decoding을 위해 EAGLE3 기반 아키텍처를 활용하고 있으며, AL을 높이기 위해 speculative layer의 FFN 크기만 조정했습니다. 추론 시에는 Target 모델의 forward pass 과정에서 첫 번째, 중간, 마지막 디코딩 레이어 이후의 hidden state를 각각 기록한 뒤, 이를 토큰 임베딩과 함께 결합하여 speculative layer에 입력으로 전달합니다. Speculative layer는 이를 기반으로 draft 토큰 시퀀스를 autoregressive 방식으로 생성하고, Target 모델이 이를 병렬로 검증합니다.
Speculative layer의 오버헤드는 크지 않지만 완전히 무시할 수는 없기 때문에, draft 길이와 전체 속도 향상 사이의 균형을 잘 맞추는 것이 중요합니다. Draft 길이가 길수록 AL은 높아지지만, Draft 모델을 더 많이 실행해야 하므로 연산 비용도 증가하며, NVIDIA의 실험에 따르면 draft length를 3으로 설정했을 때 가장 큰 속도 향상을 얻을 수 있었습니다.

CUDA 그래프와 오버랩 스케줄러를 통한 호스트 오버헤드 감소
Speculative decoding에서 또 하나의 과제는 Target 모델과 Draft 모델 간 통신 및 동기화 오버헤드를 줄이는 것입니다. 만약 NVIDIA가 샘플링 및 검증 로직을 호스트 측에 두면, 호스트와 디바이스 간에 불필요한 동기화 지점이 생기고 CUDA Graph가 끊어지게 됩니다. 이를 방지하기 위해, 검증 로직은 디바이스 측에 유지하고 Target 모델의 forward pass, 검증 로직, Draft 모델의 forward pass를 하나의 CUDA Graph 내에 통합했습니다. 여기에 더해 NVIDIA는 TensorRT-LLM 오버랩 스케줄러를 활성화해 현재 반복 단계의 모델 추론과 다음 단계의 입력 준비, CUDA Graph 실행을 겹쳐 수행할 수 있도록 했습니다.
torch.compile()을 활용한 Draft 모델 레이어 최적화
검증 로직은 torch native 연산으로 디바이스 측에 구현되어 있어 다수의 작은 torch native 커널이 생성되는데, 이를 수동으로 결합하는 것은 복잡하고 오류 발생 가능성도 큽니다. 이를 해결하기 위해 NVIDIA는 torch.compile()을 사용하여 OpenAI Triton이 자동으로 최적의 커널을 생성하고 결합하도록 했습니다. 이 방식 덕분에 draft length가 3일 때 Draft 모델의 오버헤드는 기존 25%에서 18%로 줄어들었습니다.
요약
NVIDIA는 이번에도 데이터센터 및 AI 인프라 분야에서의 리더십을 입증했습니다. 4천억 개의 파라미터를 가진 Llama 4 Maverick 모델에서 사용자당 초당 1,000개 이상의 토큰을 생성하는 획기적인 성능을 달성한 것입니다. 이 세계 기록 수준의 속도는 강력한 Blackwell 아키텍처, CUDA부터 시작된 깊이 있는 소프트웨어 최적화, 그리고 NVIDIA의 맞춤형 speculative decoding 구현이 가져온 속도 향상 덕분에 가능했습니다. NVIDIA가 보여준 이 기술적 진보는 차세대 AI 상호작용에 필수적인 저지연 처리 요구를 충족시키며, 대규모 모델조차도 실시간 사용자 경험과 복잡한 AI 에이전트 배포 시나리오에서 요구되는 속도와 반응성을 충분히 제공할 수 있음을 보여줍니다.
관련 리소스
- GTC 세션: Meta의 Llama 생태계: 새로운 가능성 열기 (Meta 진행)
- GTC 세션: Apache Spark에서 Blackwell GPU를 활용한 데이터 처리 확장
- GTC 세션: 데이터 및 모델 지적 재산권 보호와 생산성 향상
- NGC 컨테이너: chain-server
- SDK: Llama3 8B Instruct NIM
- SDK: Llama3 70B Instruct NIM