자연어 처리에서 창의적인 콘텐츠 생성에 이르기까지, 생성형 AI(GenAI)의 부상은 산업을 변화시켰습니다. 그러나 이러한 강력한 모델을 대규모로 효율적으로 배포하는 것은 여전히 어려운 과제입니다.
추론 엔진은 성능을 최적화하고 지연 시간을 줄이며 리소스 활용도를 극대화하는 데 중요한 역할을 합니다. 이 글에서는 네 가지 주요 솔루션에 대해 자세히 살펴봅니다: TensorRT-LLM, vLLM, Hugging Face TGI, LMDeploy입니다.
NVIDIA의 하드웨어 가속 정밀도, vLLM의 혁신적인 메모리 관리, TGI의 프로덕션 지원 에코시스템, 속도와 단순성에 중점을 둔 LMDeploy 등 각 엔진은 고유한 강점을 가지고 있습니다. 이러한 엔진을 비교하여 귀사의 GenAI 워크로드에 가장 적합한 엔진을 찾아보세요.
대규모 언어 모델을 빠르고 원활하게 실행하기 위한 NVIDIA의 해답은 TensorRT-LLM입니다. TensorRT 프레임워크를 기반으로 구축된 이 솔루션은 NVIDIA GPU에서 모든 성능을 최대한 끌어내도록 설계되었습니다. 레이어 퓨전, 정밀 조정(FP16, INT8, FP8...), 커널 최적화와 같은 트릭을 통해 모델의 정확도를 유지하면서 계산 시간을 단축할 수 있습니다.
속도만이 중요한 것이 아닙니다. TensorRT-LLM은 메모리를 스마트하게 관리하여 대용량 모델을 효율적으로 처리하므로 실행 도중에 충돌이 발생하지 않습니다. 또한 동적 일괄 처리를 지원하므로 메모리 부족 없이 여러 요청을 한 번에 처리할 수 있습니다. 이미 NVIDIA 하드웨어를 사용 중이라면 CUDA 및 cuDNN과 같은 에코시스템과 긴밀하게 연결되어 있으며, NVIDIA의 Triton 추론 서버 및 NVIDIA Dynamo와도 통합되므로 쉽게 사용할 수 있습니다.
하지만 모든 사람에게 완벽한 것은 아닙니다. NVIDIA 툴에 익숙하지 않은 경우 설정이 번거로울 수 있으며, NVIDIA가 아닌 하드웨어를 사용하는 경우 유연성이 떨어집니다. 하지만 NVIDIA GPU의 원시 성능과 최적화에 있어서는 이보다 더 좋은 방법은 없습니다.
vLLM은 대량의 추론 작업을 빠르게 처리하는 데 매우 능숙합니다. 속도 저하 없이 높은 처리량이 필요할 때 빛을 발하는 오픈 소스 프로젝트입니다. 그 비결은 대부분의 경우보다 메모리를 훨씬 더 잘 관리할 수 있는 PagedAttention입니다. 모든 것을 한 번에 로드하여 RAM을 소모하는 대신 키-값 캐시를 청크로 분할하여 필요한 것만 가져옵니다. 낭비는 줄이고 속도는 높입니다.
유연성도 매우 뛰어납니다. LLaMA 또는 Mistral과 같은 인기 모델에서 바로 사용할 수 있으며, NVIDIA 또는 AMD GPU를 비롯한 다양한 하드웨어를 지원합니다. 또한 요청을 효율적으로 그룹화하여 파이프라인을 원활하게 실행할 수 있는 동적 일괄 처리 기능도 제공합니다. Python과 PyTorch에 익숙하다면 설정은 매우 간단합니다.
vLLM의 가장 큰 한계는 시장에서 상대적으로 미성숙하다는 점으로, 이는 아직 기존 솔루션에서 제공하는 포괄적인 기능 세트를 제공하지 못할 수도 있다는 것을 의미합니다. 하지만 고성능 추론을 제공하는 효율적인 솔루션을 찾는 조직이라면 vLLM은 탁월한 선택입니다.
Hugging Face TGI(텍스트 생성 추론)는 골치 아픈 일 없이 모델을 실행하고 싶은 사람들을 위해 만들어졌습니다. Hugging Face 팀이 개발한 도구로, 사전 학습된 방대한 모델 라이브러리(BERT, GPT 등)와 잘 어울립니다. 텍스트 생성이 충돌 없이 빠르게 작동해야 하는 챗봇이나 앱과 같은 실제 사용 환경에 맞게 설계되었습니다.
TGI는 기존 요청이 완료되면 새로운 요청으로 교체하여 시스템을 계속 바쁘게 만드는 연속 배치와 같은 기능으로 과중한 작업을 처리합니다. GPU 가속을 지원하며 하드웨어가 있다면 확장할 수 있습니다. 또한 잘못된 출력을 필터링하는 등 안전 기능이 내장되어 있어 프로덕션에 유용합니다. 몇 단계만 거치면 Docker로 배포할 수 있으므로 비교적 쉽게 설정할 수 있습니다.
문제는? 허깅 페이스의 생태계와 연결되어 있기 때문에 아직 그 세계에 속해 있지 않다면 제한적으로 느껴질 수 있습니다. 하지만 바로 사용할 수 있는 플러그 앤 플레이 옵션을 원한다면 TGI는 훌륭한 선택입니다.
LMDeploy는 대규모 언어 모델을 손쉽게 압축, 배포 및 실행할 수 있도록 제작된 MMRazor 및 MMDeploy 팀의 툴킷입니다. 어떤 점이 눈에 띄나요? A100 GPU에서 vLLM보다 초당 최대 1.8배 더 많은 요청을 처리하는 뛰어난 디코딩 속도를 자랑합니다. 이는 퍼시스턴트 배칭, 차단된 KV 캐싱, GPU를 계속 바쁘게 만드는 매끄러운 CUDA 커널과 같은 트릭 덕분입니다.
두 가지 엔진이 있습니다: 최대 성능을 위한 TurboMind와 손쉬운 조작을 위한 PyTorch 엔진이 있습니다. TurboMind는 FP16보다 2.4배 빠른 4비트 추론을 지원하며, Llama-2 70B와 같은 대형 모델도 쉽게 처리할 수 있습니다. 또한 가중치와 KV 캐시를 정량화하여 정확도를 저하시키지 않고 메모리를 절약할 수 있습니다. 필요한 경우 명령 한 번으로 여러 대의 컴퓨터에 서버를 설정할 수 있어 배포도 간편합니다. 또한 다자간 대화에서 채팅 기록을 기억하므로 이전 작업을 재실행하느라 시간을 낭비하지 않아도 됩니다.
단점은? 터보마인드는 까다롭습니다. 아직 미스트랄과 같은 슬라이딩 창 주의 모델에서는 잘 작동하지 않습니다. 그리고 엔비디아 GPU를 사용하지 않는다면 느린 파이토치 엔진을 사용해야 합니다. 하지만 적절한 하드웨어에서 속도와 단순성을 원한다면 LMDeploy는 훌륭한 선택입니다.
지연 시간(하나의 요청이 얼마나 빨리 완료되는지), 처리량(얼마나 많은 요청을 수집할 수 있는지), 확장성(더 큰 부하나 더 많은 하드웨어를 얼마나 잘 처리하는지)에 대해 이러한 엔진의 성능을 세분화해 보겠습니다.
TensorRT-LLM은 NVIDIA GPU를 사용하는 경우 지연 시간에서 강점을 발휘합니다. NVIDIA 하드웨어에 고도로 최적화되어 있어 단일 요청이 신속하게 완료됩니다(A100의 경우 대부분의 모델에서 50ms 미만). 특히 동적 일괄 처리 시 처리량도 우수합니다. BentoML의 벤치마크에 따르면 이 엔진은 A100 80GB GPU에서 동시 사용자 100명 기준으로 Llama 3 70B Q4의 경우 초당 700 토큰에 도달합니다. TensorRT-LLM은 긴 입력과 높은 요청 속도가 있는 시나리오에서 강력한 성능을 발휘하여 우수한 처리량을 제공합니다. 여러 GPU에 대한 확장성은 뛰어난 성능으로 즉시 지원됩니다.
특히 디코딩이 많은 워크로드에서는 최근 업데이트 후 높은 처리량과 짧은 지연 시간으로 vLLM의 처리량도 우수합니다. BentoML의 벤치마크에 따르면 이 엔진은 A100 80GB GPU에서 100명의 동시 사용자가 있을 때 Llama 3 70B Q4의 경우 초당 600~650개의 토큰을 처리하는 것으로 나타났습니다. 지연 시간은 좋지만 단독 실행 시 약 60-80ms로 TensorRT-LLM만큼 좋지는 않습니다. 여러 GPU에 걸쳐 잘 확장되며, 심지어 여러 브랜드를 혼합하여 사용하더라도 대규모 설정에는 적합하지 않습니다.
허깅 페이스 TGI는 성능과 사용 편의성이 균형 잡힌 vLLM과 비슷한 성능을 제공합니다. 지연 시간은 좋은 GPU에서 50~70밀리초로 괜찮습니다. BentoML의 벤치마크에 따르면 이 엔진은 A100 80GB GPU에서 동시 사용자 100명 기준으로 Llama 3 70B Q4의 경우 초당 600-650 토큰에 도달합니다. 프로덕션에 맞게 확장할 수 있도록 제작되었기 때문에 더 많은 사용자나 머신을 원활하게 처리하며, 특히 Docker를 사용하면 더욱 그렇습니다.
LMDeploy는 디코딩 속도에서 우위를 점합니다. 특히 소규모 모델의 경우 토큰 생성 속도가 뛰어나며, 정량화된 대규모 모델의 경우 첫 토큰 생성 시간(TTFT)이 짧습니다. 지연 시간도 40~60ms로 짧습니다. 처리량도 우수합니다. BentoML의 벤치마크에 따르면 이 엔진은 A100 80GB GPU에서 동시 사용자 100명 기준으로 Llama 3 70B Q4의 경우 초당 700개의 토큰을 처리하는 것으로 나타났습니다. 서버 설정으로 확장은 쉽지만 최상의 결과를 위해 NVIDIA GPU에 크게 의존하며 PyTorch 모드는 뒤쳐집니다.
결론: TensorRT-LLM과 LMDeploy가 원시 속도에서 앞서고 있습니다. 하드웨어와 처리하는 요청 수에 따라 선택이 달라집니다.
정량화는 모델 정밀도를 낮춰 메모리 사용량을 줄이고 추론 속도를 높여주며, 이는 리소스가 제한된 환경에서 중요합니다. 각 엔진의 성능은 다음과 같습니다:
TensorRT-LLM은 FP8, FP4, 활성화 인식 가중치 정량화(AWQ)가 포함된 INT4, SmoothQuant가 포함된 INT8을 지원하여 NVIDIA GPU 성능을 최적화할 수 있는 강력한 옵션을 제공합니다.
vLLM은 다양한 하드웨어 및 정밀도 요구 사항에 맞게 조정할 수 있는 GPTQ, AWQ, INT4, INT8 및 FP8을 통해 유연성을 제공합니다.
허깅 페이스 TGI는 8비트 및 4비트 정량화를 위한 비트샌드바이트와 프로덕션 배포에 적합한 무게 전용 정량화를 위한 GPT-Q를 통합합니다.
LMDeploy는 4비트 AWQ, 8비트 양자화 및 온라인 INT8/INT4 KV 캐시 양자화를 제공하여 제한된 하드웨어에서 대형 모델의 효율성을 향상시킵니다.
하드웨어 지원에 따라 이러한 엔진을 배포할 수 있는 위치가 결정되어 확장성과 성능에 영향을 미칩니다:
TensorRT-LLM은 고성능을 위해 GPU 가속기를 활용하는 NVIDIA CUDA 전용 제품입니다.
vLLM은 NVIDIA CUDA, AMD ROCm, AWS Neuron 및 CPU를 지원하여 다양한 설정에 대한 폭넓은 호환성을 제공합니다.
허깅 페이스 TGI는 엔비디아 CUDA, AMD ROCm, 인텔 가우디, AWS 인페르텐시아 등과 함께 작동하여 다양한 하드웨어 환경에 유연하게 대응할 수 있습니다.
LMDeploy는 NVIDIA CUDA에 최적화되어 있어 NVIDIA GPU에서 최고의 성능을 보장하지만 다른 플랫폼에 대한 지원은 제한적입니다.
설정 및 통합 프로세스는 개발 일정에 영향을 미칠 수 있습니다. 각 엔진의 요금은 다음과 같습니다:
TensorRT-LLM을 사용하려면 체크포인트 변환, TensorRT 엔진 빌드, 파라미터 구성이 필요하므로 엔지니어에게는 어렵고 시간이 많이 소요됩니다.
vLLM은 포괄적인 문서, 간편한 설치, 원활한 Python 라이브러리 통합을 통해 사용자 친화적입니다.
Hugging Face TGI는 사전 구축된 Docker 이미지와 신속한 배포를 위한 철저한 문서를 제공하는 Hugging Face의 에코시스템의 이점을 활용합니다.
LMDeploy는 단일 명령으로 서버를 실행하는 간단한 설정과 사용자 지정을 위한 Python API를 제공하여 편의성과 유연성의 균형을 맞춥니다.
적합한 엔진을 선택하는 것은 사용 사례, 하드웨어 및 기술에 따라 다릅니다.
NVIDIA GPU에서 대규모 모델을 실행하고 모든 속도가 필요한 경우(실시간 챗봇이나 AI 비서처럼 응답을 밀리초 단위로 생성해야 하는 저지연 애플리케이션을 생각해보십시오) TensorRT-LLM을 추론 엔진으로 사용하는 것이 좋습니다. 이미 NVIDIA의 세계를 깊이 이해하고 있는 기업에게는 적합하지만, 단순성을 원하는 기업에게는 과할 수 있습니다.
vLLM은 속도와 단순성 사이의 훌륭한 절충안입니다. 유연하고 빠른 설정이 필요한 스타트업이나 연구자에게 매우 적합합니다.
허깅 페이스 TGI는 속도와 단순성 측면에서 vLLM과 동등합니다. 배포가 쉽고 원활하게 확장되며 Hugging Face의 모델 허브에 연결되므로 간편한 솔루션을 원하는 팀에 이상적입니다.
LMDeploy는 TensorRT-LLM과 같은 성능에서 빛을 발합니다. 간단한 설정과 최고의 성능을 원하는 NVIDIA GPU 사용자에게 적합하지만, 모델이 TurboMind와 잘 맞지 않는 경우 유용성이 떨어집니다.
자체 GenAI 모델을 직접 배포할 수 없거나 배포하고 싶지 않은 경우, NLP Cloud를 사용하여 프로덕션 환경에서 대규모로 빠른 생성 AI 모델을 활용할 수 있습니다. 지금 NLP Cloud에서 빠른 추론을 사용해 보세요!
추론 엔진 전반에 대해 궁금한 점이 있으시면 언제든지 문의해 주세요!
Julien
NLP 클라우드의 CTO