TensorRT-LLM 최적화: NVIDIA 추론 스택 마스터하기
2025년 12월 11일 업데이트
2025년 12월 업데이트: TensorRT-LLM이 H100에서 FP8로 10,000+ 출력 토큰/초, 100ms 미만의 TTFT 달성. 프로덕션 배포에서 네이티브 PyTorch 대비 4배 처리량 보고. 커널 퓨전으로 LayerNorm, 행렬 곱셈, 활성화 함수를 단일 CUDA 커널로 통합. Inflight 배칭으로 GPU 활용률 극대화. Hopper/Blackwell의 FP8 어텐션으로 추가 속도 향상.
NVIDIA의 TensorRT-LLM은 대안들이 따라잡기 어려운 원시 추론 성능을 제공합니다. H100 GPU에서 FP8 정밀도로 최대 처리량 기준 초당 10,000개 이상의 출력 토큰을 달성하며, 첫 번째 토큰까지의 시간(TTFT)은 100밀리초 미만입니다.¹ 프로덕션 배포에서는 네이티브 PyTorch 추론 대비 최대 4배의 처리량 향상이 보고되고 있습니다. 이러한 성능에는 대가가 따릅니다: TensorRT-LLM은 vLLM과 같은 사용자 친화적인 대안보다 더 많은 구성 전문 지식과 더 긴 최적화 주기가 필요합니다.
NVIDIA 하드웨어에 전념하고 최적화에 엔지니어링 시간을 투자할 의향이 있는 조직에게 TensorRT-LLM은 고가의 GPU 인프라에서 최대 성능을 추출합니다. 프레임워크의 아키텍처, 양자화 옵션, 튜닝 매개변수를 이해하면 우수한 토큰 경제성을 통해 프리미엄 하드웨어 투자를 정당화하는 추론 시스템을 구축할 수 있습니다.
아키텍처와 핵심 최적화
TensorRT-LLM은 NVIDIA의 TensorRT 추론 옵티마이저를 기반으로 하며, 컴파일 프레임워크를 트랜스포머 전용 최적화로 확장합니다. 이 라이브러리는 모델 정의를 위한 Python API와 프로덕션 배포를 위한 C++ 런타임 컴포넌트를 제공합니다.
커널 퓨전: TensorRT-LLM은 여러 트랜스포머 연산을 단일 최적화된 CUDA 커널로 결합합니다. LayerNorm, 행렬 곱셈, 바이어스 덧셈, 활성화 함수가 별도의 커널 실행과 메모리 전송 없이 함께 실행됩니다. 퓨전은 커널 실행 오버헤드를 줄이고 중간 텐서 구체화를 제거합니다.²
커스텀 어텐션 커널: 멀티헤드 및 그룹 쿼리 어텐션의 수작업 최적화된 구현은 Tensor Core 명령어를 활용하여 최대 처리량을 달성합니다. Flash Attention 변형은 수치 정밀도를 유지하면서 메모리 대역폭 요구사항을 줄입니다. Hopper와 Blackwell GPU의 FP8 어텐션 커널은 추가적인 속도 향상을 제공합니다.
Inflight 배칭: 전통적인 정적 배칭은 배치 내 모든 요청이 가장 긴 시퀀스가 완료될 때까지 대기하도록 강제합니다. Inflight 배칭은 각 생성 단계에서 실행 중인 배치에 새 요청을 추가하여 컨텍스트와 생성 단계를 함께 처리합니다.³ 이 접근 방식은 개별 요청이 완료되더라도 컴퓨팅 유닛을 바쁘게 유지하여 GPU 활용률을 극대화합니다.
페이지드 KV 캐싱: 운영 체제 가상 메모리에서 영감을 받은 페이지드 어텐션은 연속적인 메모리 영역을 요구하는 대신 비연속적인 블록으로 KV 캐시를 할당합니다.⁴ 블록 수준 할당은 공통 프리픽스를 가진 요청 간에 KV 캐시 공유를 가능하게 하고 내부 단편화로 인한 메모리 낭비를 거의 0에 가깝게 달성합니다.
성능 비교: TensorRT-LLM vs vLLM
두 프레임워크 모두 프로덕션 LLM 추론을 목표로 하지만, 아키텍처 차이로 인해 뚜렷한 성능 프로필이 생깁니다:
| 지표 | TensorRT-LLM | vLLM |
|---|---|---|
| 최대 처리량 (Llama 70B, A100) | ~700 토큰/초 | ~600-650 토큰/초 |
| 첫 번째 토큰까지의 시간 | 35-50ms | 50-80ms |
| 짧은 시퀀스 처리량 우위 | 1.34배 | 기준 |
| 긴 시퀀스 TPOT 우위 | 2.72배 | 기준 |
| 설정 복잡도 | 높음 (수주) | 낮음 (수시간) |
TensorRT-LLM은 기본 구성에서 vLLM을 일관되게 능가하며, 짧은 시퀀스에서 1.34배 높은 처리량과 긴 시퀀스에서 2.72배 더 나은 출력 토큰당 시간을 제공합니다.⁵ B200 GPU에서 TensorRT-LLM의 Blackwell 아키텍처에 대한 더 깊은 최적화는 성능 격차를 더욱 확대합니다.
vLLM은 개발자 경험에서 장점을 제공합니다:⁶ - 드롭인 대체를 위한 OpenAI 호환 API - 컴파일 단계 없이 더 간단한 배포 - 합리적인 기본값으로 자동 모델 최적화 - NVIDIA GPU를 넘어선 더 넓은 하드웨어 지원
권장 사항: 하드웨어 효율성 극대화가 엔지니어링 투자를 정당화할 때 TensorRT-LLM을 배포하세요. 더 빠른 프로덕션 적용이 필요하거나 절대적 성능보다 개발 속도가 더 중요한 소규모 운영에서는 vLLM을 선택하세요.
양자화 전략
TensorRT-LLM은 정밀도와 성능 및 메모리 효율성을 교환하기 위한 광범위한 양자화 옵션을 지원합니다. 올바른 양자화 방법 선택은 배치 크기, 정확도 요구사항, 대상 하드웨어에 따라 달라집니다.
FP8 양자화 (우선 권장)
FP8은 최소한의 정확도 저하로 최상의 성능 향상 균형을 제공합니다:⁷
python quantize.py \
--model_dir $MODEL_PATH \
--qformat fp8 \
--kv_cache_dtype fp8 \
--output_dir $OUTPUT_PATH
FP8 양자화는 적절한 스케일링 팩터를 결정하기 위해 캘리브레이션이 필요합니다. 캘리브레이션 과정은 대표 샘플에서 추론을 실행하여 활성화 범위를 측정합니다:
from tensorrt_llm.quantization import QuantConfig, CalibConfig
quant_config = QuantConfig(
quant_algo="fp8",
kv_cache_quant_algo="fp8"
)
calib_config = CalibConfig(
calib_dataset="cnn_dailymail",
calib_batch_size=8,
calib_num_samples=512
)
FP8은 매우 낮은 정확도 영향으로 중간 수준의 성능 향상을 제공하며 캘리브레이션에 몇 분만 필요합니다. Hopper와 Blackwell GPU는 하드웨어 FP8 지원을 제공합니다; Ada GPU는 효율성이 낮지만 FP8을 지원합니다.
메모리 제약 배포를 위한 INT4 AWQ
메모리가 모델 크기를 제한할 때, INT4 Activation-aware Weight Quantization은 허용 가능한 정확도를 유지하면서 가중치를 4비트로 압축합니다:⁸
python quantize.py \
--model_dir $MODEL_PATH \
--qformat int4_awq \
--awq_block_size 64 \
--tp_size 4 \
--output_dir $OUTPUT_PATH
INT4 AWQ는 추론이 메모리 바운드가 되는 소규모 배치 시나리오(배치 크기 ≤ 4)에서 탁월합니다. 가중치 로딩 시간이 연산을 지배하므로 공격적인 가중치 압축이 상당한 속도 향상을 제공합니다. 대규모 배치에서는 연산 밀도가 증가함에 따라 INT4 AWQ의 성능 우위가 감소합니다.
균형 잡힌 최적화를 위한 INT8 SmoothQuant
SmoothQuant는 양자화의 어려움을 활성화에서 가중치로 이전하여 심각한 정확도 손실 없이 효과적인 INT8 양자화를 가능하게 합니다:
python quantize.py \
--model_dir $MODEL_PATH \
--qformat int8_sq \
--kv_cache_dtype int8 \
--output_dir $OUTPUT_PATH
INT8 SmoothQuant는 중간 수준의 정확도 영향으로 중간 수준의 성능 향상을 제공합니다. 조직은 먼저 FP8을 시도하고, FP8 결과가 요구사항을 충족하지 못하면 INT8 SQ로 대체해야 합니다.
양자화 선택 프레임워크
NVIDIA는 다음 우선순위를 권장합니다:⁹
- FP8 - 최고의 성능/정확도 균형, Hopper/Blackwell 필요
- INT8 SmoothQuant - Ada GPU 또는 FP8 정확도가 부족할 때 좋은 대안
- INT4 AWQ/GPTQ - 메모리 제약 시나리오를 위한 최대 압축
KV 캐시의 경우 특히, 대부분의 경우 정확도 영향이 낮기 때문에 Hopper와 Ada GPU에서는 INT8보다 FP8 양자화가 권장됩니다.
프로덕션 배포 구성
최적의 TensorRT-LLM 배포를 위해서는 워크로드 특성에 따라 여러 매개변수를 튜닝해야 합니다:
엔진 빌드 구성
trtllm-build \
--checkpoint_dir $CHECKPOINT_PATH \
--output_dir $ENGINE_PATH \
--max_batch_size 256 \
--max_num_tokens 8192 \
--max_input_len 4096 \
--max_seq_len 8192 \
--gemm_plugin auto \
--use_paged_context_fmha enable \
--workers 8
max_batch_size: 최신 버전에서 기본값은 256입니다. 최대 처리량을 달성하는 프로덕션 배포에서는 종종 2048로 증가시켜 inflight 배칭 기능을 완전히 활용합니다.¹⁰
max_num_tokens: 배치 반복당 처리되는 총 토큰을 제어합니다. 기본값 8192는 처리량과 메모리 소비의 균형을 맞춥니다. 메모리 제약 배포에서는 줄이고; 모니터링하면서 신중하게 증가시키세요.
use_paged_context_fmha: 효율적인 KV 캐시 관리를 위해 페이지드 어텐션을 활성화합니다. inflight 배칭 사용 시 필수입니다. 구현은 KV 캐시 메모리를 사전 할당하여 모델 가중치 단독보다 약 60% 더 많은 VRAM이 필요합니다.¹¹
Triton Inference Server 통합
프로덕션 배포는 일반적으로 TensorRT-LLM 백엔드와 함께 NVIDIA Triton Inference Server를 사용합니다:
model_repository/
└── llama-70b/
├── 1/
│ └── model.py
├── config.pbtxt
└── tensorrt_llm/
└── 1/
├── config.json
└── engine/
Triton은 다중 모델 오케스트레이션, 요청 큐잉, 메트릭 수집, Kubernetes 네이티브 스케일링을 제공합니다. 사전 빌드된 NGC 컨테이너에는 inflight 배칭과 페이지드 KV 캐시 지원이 활성화된 TensorRT-LLM 백엔드가 포함되어 있습니다.
메모리 계획
배포 전 메모리 요구사항을 추정하세요:
총 VRAM = 모델 가중치 + KV 캐시 + 활성화 메모리 + 런타임 오버헤드
모델 가중치 (FP8): 파라미터 × 1바이트
모델 가중치 (INT4): 파라미터 × 0.5바이트
KV 캐시: batch_size × seq_len × num_layers × 2 × hidden_dim × precision_bytes
FP8의 70B 파라미터 모델은 대략 다음이 필요합니다: - 가중치: 70GB - KV 캐시 (배치 256, 시퀀스 8192): ~120GB - 활성화 + 오버헤드: ~30GB - 총계: ~220GB (H100 80GB 3개 또는 H200 141GB 2개)
성능 튜닝 워크플로우
체계적인 최적화로 TensorRT-LLM 배포에서 최대 성능을 추출합니다:
1단계: 기준선 측정
빠른 성능 평가를 위해 trtllm-bench를 사용하세요:
python -m tensorrt_llm.bench \
--model_dir $ENGINE_PATH \
--input_len 512 \
--output_len 256 \
--batch_size 32 \
--num_requests 1000
벤치마킹 유틸리티는 최적의 엔진 매개변수를 자동으로 설정하여 전체 Triton 배포 복잡성 없이 기준 성능을 제공합니다.¹²
2단계: 양자화 선택
먼저 정확도 요구사항에 대해 FP8을 테스트하세요. 정확도가 허용 가능한 임계값을 넘어 저하되면 INT8 SQ 또는 INT4 AWQ를 평가하세요. 단순 퍼플렉시티 측정이 아닌 대표적인 작업에서 평가 벤치마크를 실행하세요.
3단계: 배치 크기 최적화
1부터 max_batch_size까지 배치 크기에 따른 처리량을 프로파일링하세요. 추가 배칭이 수확 체감을 제공하는 처리량 곡선의 변곡점을 식별하세요. 트래픽 급증을 수용하기 위해 이 지점보다 20-30% 위에 max_batch_size를 설정하세요.
4단계: KV 캐시 튜닝
프로덕션 워크로드 중 KV 캐시 활용률을 모니터링하세요. 활용률이 지속적으로 80%를 초과하면 max_num_tokens를 늘리거나 max_batch_size를 줄이세요. 활용률이 50% 미만으로 유지되면 더 큰 배치를 위한 메모리를 확보하기 위해 할당을 줄이세요.
5단계: 지속적 모니터링
프로덕션에서 주요 메트릭을 추적하세요: - 초당 토큰 (처리량) - 첫 번째 토큰까지의 시간 (지연시간) - 큐 깊이 (용량) - KV 캐시 활용률 (메모리) - GPU 활용률 (효율성)
고급 최적화
추측적 디코딩
TensorRT-LLM은 메인 모델이 검증하는 여러 토큰을 예측하기 위해 더 작은 드래프트 모델을 사용하는 추측적 디코딩을 지원합니다. 이 기술은 호환되는 워크로드에 1.5-2배 속도 향상을 제공합니다:
# 엔진 빌드에서 추측적 디코딩 활성화
trtllm-build \
--speculative_decoding_mode draft_tokens_external \
--max_draft_len 5 \
...
추측적 디코딩은 처리량보다 완료 시간이 더 중요한 지연시간에 민감한 애플리케이션에 유용합니다. 이 최적화는 드래프트와 타겟 모델 모두를 메모리에 유지해야 합니다.
다중 GPU 구성
TensorRT-LLM은 분산 추론을 위한 텐서 병렬화(TP), 파이프라인 병렬화(PP), 전문가 병렬화(EP)를 지원합니다:
# 4-way 텐서 병렬화
trtllm-build \
--tp_size 4 \
--pp_size 1 \
...
TP는 각 레이어를 GPU에 분할하여 각 레이어 경계에서 all-reduce 연산이 필요합니다. PP는 파이프라인 단계에서 레이어를 GPU에 분할합니다. 추론의 경우 TP가 일반적으로 더 나은 지연시간을 제공하는 반면 PP는
[번역을 위해 콘텐츠가 잘림]
