LLM 추론 엔진 비교: vLLM, SGLang, TensorRT-LLM 무엇을 선택해야 할까
“같은 모델과 같은 GPU를 쓰는데도 왜 서비스 처리량은 크게 달라질까요?”
사내 엔지니어링 어시스턴트를 막 배포했다고 가정해 보겠습니다. 좋은 모델을 골랐고 GPU도 충분히 준비했습니다. 그런데 출시 첫날, 엔지니어 50명이 동시에 로그를 요약하고 장애 원인을 묻기 시작하자 처음 10명은 바로 답을 받았지만 나머지는 로딩 화면만 바라봅니다. GPU 대시보드의 사용률은 60%에 머물러 있습니다.
이때 문제는 모델이나 GPU 수량만이 아닐 수 있습니다. 요청을 배치하고 KV 캐시를 관리하며 토큰 생성을 스케줄링하는 추론 엔진(Inference Engine)이 병목일 가능성이 있습니다.
앞선 글에서 Disaggregated Inference를 통해 Prefill과 Decode를 어떻게 서로 다른 GPU에 나눠 배치하는지 살펴봤습니다. 그렇다면 GPU 위에서 실제 요청을 받아 배치하고 토큰을 생성하는 소프트웨어는 무엇일까요?
이번 글에서는 그 실행 계층인 LLM 추론 엔진 — vLLM, SGLang, TensorRT-LLM — 을 비교하고, 어떤 워크로드에 무엇을 선택해야 하는지 정리합니다.
LLM 추론 엔진이란? 역할과 성능 차이
LLM 추론 엔진은 학습이 끝난 모델을 GPU 메모리에 올리고, 사용자의 요청을 배치하며, 입력 토큰을 처리하고 출력 토큰을 생성하는 전 과정을 관리하는 소프트웨어 계층입니다.
같은 모델이라도 이 계층이 요청을 어떻게 묶고, KV 캐시를 어떻게 저장·재사용하고, 다음에 처리할 작업을 어떻게 스케줄링하느냐에 따라 지연 시간과 처리량, 그리고 GPU 1대당 비용이 크게 달라집니다. 모델을 고르는 일만큼이나 이 계층을 고르는 일이 인프라 비용에 직접 영향을 준다는 뜻입니다.
현재 LLM 서빙 환경에서는 vLLM, SGLang, TensorRT-LLM이 대표적인 추론 엔진으로 널리 검토되고 있습니다. 세 프로젝트 모두 오픈소스로 제공되지만, 각각 해결하려는 병목과 적합한 운영 환경이 다릅니다.
LLM 추론 엔진의 핵심: KV 캐시 관리
세 엔진의 차이를 이해하려면 먼저 KV 캐시(Key-Value Cache)를 알아야 합니다.
KV 캐시: 이전에 입력된 토큰을 처리하면서 계산한 Key와 Value 정보를 저장해 두는 메모리입니다. 다음 토큰을 생성할 때 앞선 토큰의 Attention 연산을 처음부터 반복하지 않도록 해 LLM 추론 속도를 높입니다.
LLM은 Decode 단계에서 새로운 토큰을 하나씩 생성합니다. 이때 매번 앞의 모든 토큰을 다시 계산하면 연산량이 지나치게 커집니다. 따라서 이전 토큰에서 계산한 결과를 KV 캐시에 저장하고 다음 토큰 생성 시 재사용합니다.
문제는 요청마다 입력 길이와 출력 길이가 다르고, 생성이 끝나는 시점도 제각각이라는 점입니다. KV 캐시를 비효율적으로 할당하면 GPU 메모리에 사용하지 못하는 빈 공간이 늘어나고, 동시에 처리할 수 있는 요청 수가 줄어듭니다.
vLLM, SGLang, TensorRT-LLM은 이 문제를 서로 다른 방식으로 해결합니다.
vLLM·SGLang·TensorRT-LLM 비교
구분 | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|
핵심 접근 | 블록 기반 KV 캐시 관리(+연속 배칭 대중화) | 프리픽스 기반 KV 캐시 재사용 | NVIDIA GPU 중심의 커널·런타임 최적화 |
대표 기술 | PagedAttention | RadixAttention | 최적화 커널, 양자화, 엔진 빌드 |
강점 | 넓은 생태계와 비교적 빠른 도입 | 반복 프리픽스와 복합 LLM 워크플로 최적화 | 지원 구성이 맞을 때 높은 성능과 세밀한 튜닝 |
하드웨어 | NVIDIA·AMD·Intel·CPU·TPU 등 | NVIDIA·AMD·Intel·TPU·Ascend 등 | NVIDIA GPU |
적합 환경 | 초기 검증부터 범용 프로덕션, 모델 변경이 잦은 환경 | 멀티턴 대화, 에이전트, 반복 시스템 프롬프트 | NVIDIA 기반 대규모 프로덕션과 성능 최적화 환경 |
※ 비교는 공개된 벤치마크와 각 프로젝트의 공식 문서를 기준으로 작성했으며, 실제 성능은 모델 크기, 입출력 토큰 길이, 동시 요청 수에 따라 달라질 수 있습니다.
vLLM: PagedAttention과 범용성
vLLM의 대표 기술은 PagedAttention입니다. PagedAttention은 운영체제가 가상 메모리를 페이지 단위로 관리하는 아이디어를 KV 캐시에 적용합니다. 하나의 요청에 필요한 KV 캐시를 거대한 연속 메모리 공간으로 미리 확보하는 대신, 일정한 크기의 블록으로 나눠 필요한 만큼 할당합니다. 이를 통해 요청마다 생성 길이가 달라도 GPU 메모리를 보다 유연하게 사용할 수 있습니다.
vLLM의 강점은 비교적 넓은 하드웨어 지원과 낮은 도입 장벽입니다. NVIDIA CUDA뿐 아니라 AMD ROCm, Intel XPU, CPU 환경을 지원하며 Google TPU를 위한 별도 지원 경로도 제공합니다. 또한 OpenAI 호환 API 서버를 제공해 기존 애플리케이션과 연동하기 쉽습니다.
다만 설치 방법과 지원 기능은 하드웨어 플랫폼에 따라 달라질 수 있으므로, 실제 도입 전에는 대상 장비와 버전의 호환성을 확인해야 합니다.
SGLang: RadixAttention으로 반복 프리픽스 재사용
SGLang의 RadixAttention은 요청의 토큰 프리픽스를 radix tree 형태로 관리합니다. 여러 요청이 동일한 시작 부분을 공유하면, 해당 프리픽스에서 이미 계산된 KV 캐시를 새로운 요청이 재사용할 수 있습니다.
예를 들어 모든 요청 앞에 다음과 같은 긴 시스템 프롬프트가 반복된다고 가정해 보겠습니다.
“당신은 사내 기술 문서와 장애 대응 지침을 기반으로 답변하는 엔지니어링 어시스턴트입니다.”
일반적인 방식에서는 새로운 요청이 들어올 때마다 이 시스템 프롬프트를 다시 계산해야 합니다. 반면 SGLang은 동일한 프리픽스가 캐시에 남아 있다면 해당 계산 결과를 재사용할 수 있습니다.
다만 요청마다 프롬프트가 완전히 다르고 공통 프리픽스가 거의 없다면 RadixAttention의 캐시 재사용 이점은 줄어듭니다. 따라서 단순히 대화형 서비스라는 이유만으로 SGLang이 항상 유리한 것은 아닙니다. 실제 프롬프트 구조와 캐시 적중률을 함께 확인해야 합니다.
SGLang은 RadixAttention 외에도 Continuous Batching, 구조화된 출력, Speculative Decoding, Prefill–Decode 분리, 텐서·파이프라인·전문가 병렬화 등 다양한 기능을 제공합니다. NVIDIA와 AMD GPU, Intel Xeon CPU, Google TPU, Ascend NPU 등 여러 하드웨어 플랫폼도 지원합니다.
TensorRT-LLM: NVIDIA GPU 중심의 통합 최적화
TensorRT-LLM은 NVIDIA GPU에서 LLM 추론 성능을 극대화하기 위한 오픈소스 라이브러리입니다. vLLM과 SGLang이 KV 캐시 관리와 스케줄링에서 차별화한다면, TensorRT-LLM은 NVIDIA GPU 아키텍처에 맞춘 커널, 양자화, 병렬화, 메모리 관리와 실행 최적화를 통합적으로 제공합니다.
Hopper와 Blackwell을 포함한 여러 NVIDIA GPU 아키텍처를 지원하며, 대상 모델과 GPU에 맞춰 엔진을 빌드하거나 고수준 LLM API를 통해 배포할 수 있습니다. 지원되는 모델과 하드웨어 구성이 잘 맞고 충분한 튜닝이 이뤄진 환경에서는 높은 처리량과 낮은 지연 시간을 기대할 수 있습니다. 반면 새로운 모델이나 양자화 구성을 적용할 때 별도의 엔진 빌드와 검증 과정이 필요할 수 있습니다.
워크로드별 LLM 추론 엔진 선택 기준
세 엔진 중 어느 하나가 절대적으로 우월한 것은 아닙니다. 엔진 선택은 서비스의 트래픽과 프롬프트 구조, 하드웨어 구성, 운영 방식에 따라 달라져야 합니다.
모델을 자주 바꾸는 초기 단계라면 vLLM
아직 어떤 모델을 사용할지 확정되지 않았고 여러 오픈소스 모델을 빠르게 비교해야 한다면 vLLM이 안전한 출발점이 될 수 있습니다. OpenAI 호환 API를 제공하고 다양한 모델과 하드웨어 플랫폼을 지원하기 때문에, 기존 애플리케이션에 연결해 모델별 성능을 검증하기 쉽습니다.
반복되는 프롬프트와 대화 맥락이 많다면 SGLang
사내 챗봇이나 코딩 에이전트처럼 동일한 시스템 프롬프트가 반복되고, 이전 대화나 문서 맥락을 재사용하는 서비스라면 SGLang의 RadixAttention이 효과적일 수 있습니다. 실제 효과는 공통 프리픽스가 얼마나 길고 자주 반복되는지에 따라 달라지기 때문에, 도입 전에는 프롬프트 로그를 분석해 예상 캐시 적중률을 확인하는 것이 좋습니다.
NVIDIA 환경에서 성능을 끝까지 최적화한다면 TensorRT-LLM
트래픽 규모가 크고 지연 시간 SLA가 엄격하며, NVIDIA GPU로 하드웨어가 고정되어 있다면 TensorRT-LLM을 검토할 수 있습니다. 특정 모델을 장기간 안정적으로 운영하고, 엔진 빌드와 성능 검증을 담당할 엔지니어가 있으며, 반복적인 벤치마크와 튜닝을 통해 성능을 높일 수 있는 환경에 적합합니다.
하나의 조직에서 여러 추론 엔진을 사용할 수도 있습니다
실무에서는 반드시 하나의 엔진으로 모든 모델과 서비스를 통일할 필요가 없습니다. 예를 들어 빠르게 모델을 실험하는 개발 환경에는 vLLM을 사용하고, 반복 프롬프트가 많은 사내 Agent에는 SGLang을 적용하며, 트래픽이 큰 핵심 프로덕션 모델에는 TensorRT-LLM을 사용하는 방식으로 서비스 특성에 따라 엔진을 병행할 수 있습니다.
다만 엔진 수가 늘어날수록 다음과 같은 운영 문제도 함께 증가합니다.
엔진별 배포 방식과 설정 차이
모니터링 지표와 로그 형식의 차이
GPU 자원 중복 할당
모델별 용량 계획의 복잡성
엔진 버전과 CUDA 환경 관리
장애 원인과 성능 병목 분석의 어려움
엔진을 고르는 것과 GPU 인프라를 운영하는 것은 다른 문제입니다
앞서 살펴본 것처럼 모델과 서비스가 늘어나고 요청이 여러 GPU와 노드로 분산되기 시작하면, 추론 엔진 자체만으로는 전체 환경을 안정적으로 운영하기 어려워집니다.
여러 추론 워커 중 어떤 워커로 요청을 전달할지, Prefill과 Decode 워커를 각각 얼마나 배치할지, 트래픽 변화에 따라 워커를 어떻게 확장할지 결정해야 하기 때문입니다. 여러 엔진을 병행한다면 배포 방식과 모니터링 지표, 버전과 실행 환경의 차이도 함께 관리해야 합니다.
이러한 문제를 해결하려면 추론 엔진 위에서 요청과 워커를 조정하는 오케스트레이션 계층이 필요합니다.
NVIDIA Dynamo와 같은 분산 추론 프레임워크는 vLLM, SGLang, TensorRT-LLM 등의 추론 백엔드와 연동해 요청을 적절한 워커로 전달하고, Prefill과 Decode 워커를 독립적으로 확장하며, 여러 GPU와 노드에 걸친 추론 서비스를 조정합니다.
하지만 오케스트레이션 계층을 갖췄다고 해서 모든 운영 문제가 해결되는 것은 아닙니다. 오케스트레이션 프레임워크는 요청과 추론 워커의 흐름을 관리하지만, 그 아래의 물리적인 GPU 자원을 조직 전체에서 어떻게 배분하고 활용할 것인지는 별도의 문제입니다.
AIPub으로 GPU 인프라 운영까지 연결하기
여러 팀이 서로 다른 모델과 추론 엔진을 운영하는 환경에서는 요청과 워커의 흐름뿐 아니라, 실제 GPU 자원의 배치와 사용 상태도 함께 확인해야 합니다.
어떤 모델과 워커가 어느 GPU에 배치되어 있는지, 팀과 프로젝트별로 GPU를 얼마나 사용하고 있는지, 유휴 GPU와 과부하 GPU가 동시에 발생하고 있지는 않은지 살펴봐야 합니다. 멀티 GPU 환경에서는 PCIe나 NVLink와 같은 인터커넥트가 성능 병목으로 작용하고 있는지도 확인해야 합니다.
이 지점에서 필요한 것이 GPU 인프라 운영 플랫폼입니다. AIPub과 같은 플랫폼은 사용하는 추론 엔진과 관계없이 GPU 자원을 블록 단위로 분할·배정하고, 팀과 프로젝트별로 자원과 권한을 관리할 수 있도록 지원하는 식으로 이 역할을 합니다. GPU 사용률과 메모리, 인터커넥트 상태 등 인프라 지표를 실시간으로 확인해, 추론 엔진 외부에서 발생하는 자원 병목을 함께 분석할 수 있는 것도 이런 플랫폼이 채우는 역할 중 하나입니다.
추론 엔진과 오케스트레이션 프레임워크가 "요청을 어떻게 서빙할 것인가"를 다룬다면, AIPub과 같은 GPU 인프라 운영 플랫폼은 그 아래에서 "누가 어떤 GPU를 사용하고 있으며, 자원이 실제로 얼마나 효율적으로 활용되고 있는가"를 다룹니다.
결론: 추론 엔진 선택은 끝이 아니라 시작입니다
vLLM, SGLang, TensorRT-LLM은 각각 서로 다른 운영 조건에 강점을 가집니다.
다양한 모델과 하드웨어를 빠르게 검증하고 범용적으로 운영하려면 vLLM, 반복되는 시스템 프롬프트와 대화 맥락을 효과적으로 재사용하려면 SGLang, NVIDIA GPU 환경에서 특정 모델의 성능을 세밀하게 최적화하려면 TensorRT-LLM을 검토할 수 있습니다.
하지만 추론 엔진 하나를 고르는 것으로 운영 설계가 끝나는 것은 아닙니다. 여러 워커와 노드에 요청을 어떻게 분산할 것인지, Prefill과 Decode를 어떻게 확장할 것인지, 엔진 아래의 GPU 자원을 누가 얼마나 사용하고 있는지까지 함께 설계해야 실제 처리량과 비용 효율로 이어집니다.
공개된 엔진 벤치마크보다 중요한 것은 우리 조직의 모델, 프롬프트 길이, 동시 요청 수와 GPU 구성으로 직접 테스트하는 것입니다. 그리고 테스트 결과를 GPU 자원 배치와 모니터링, 비용 관리까지 연결해야 안정적인 LLM 서비스를 운영할 수 있습니다.
여러 엔진을 병행하다 보니 GPU 자원 관리가 점점 복잡해지고 있다면? TEN의 전문가와 함께 확인해 보세요.