LLM 서빙 엔진 완벽 가이드 — 18개 도구 심층 분석

최종 업데이트: 2026년 2월
대상 독자: ML 엔지니어, MLOps, 인프라 아키텍트
범위: 프로덕션 LLM 서빙 도구 18종 + 핵심 기술 비교 분석

1. 서론

대규모 언어 모델(LLM)의 실용적 배포에서 가장 핵심적인 병목은 추론 서빙(inference serving)이다. 수십~수백억 개의 파라미터를 가진 모델을 실시간으로 서빙하려면 메모리 관리, 배치 전략, 어텐션 최적화, 양자화 등 다양한 기술적 문제를 해결해야 한다.

2023년 이후 LLM 서빙 도구 생태계는 폭발적으로 성장했다. vLLM의 PagedAttention이 KV 캐시 메모리 관리의 패러다임을 바꾼 이래, SGLang의 RadixAttention, TensorRT-LLM의 FP8 최적화, llama.cpp의 소비자 하드웨어 접근성 확대 등 다양한 접근법이 경쟁하고 있다.

본 글에서는 현재 주요 LLM 서빙/추론 도구 18종을 논문 수준의 깊이로 분석하고, 핵심 기술들을 체계적으로 비교한다.

평가 핵심 지표

2. 핵심 기술 개념 정리

2.1 KV Cache

Transformer 디코딩 시, 이전 토큰들의 Key-Value 텐서를 재사용하여 중복 계산을 피하는 메커니즘. LLM 서빙에서 KV 캐시는 전체 GPU 메모리의 30–60%를 차지하며, 이를 효율적으로 관리하는 것이 서빙 성능의 핵심이다.

2.2 Continuous Batching

정적 배칭(static batching)에서는 배치 내 모든 시퀀스가 완료될 때까지 기다려야 하지만,continuous batching은 각 시퀀스가 완료되는 즉시 새 요청을 삽입한다. 이를 통해 GPU 활용률을 극대화한다. Yu et al. (2022)의 Orca 시스템에서 처음 제안되었다.

2.3 양자화 (Quantization)

FP16/BF16 가중치를 INT4/INT8 등 저비트로 변환하여 메모리를 줄이고 추론 속도를 높이는 기법. 품질 손실과 속도 향상 사이의 트레이드오프가 존재한다.

3. 도구별 심층 분석

3.1 vLLM GitHub: vllm-project/vllm개발: UC Berkeley (Kwon et al.)라이선스: Apache 2.0최신 상태: 활발한 개발 중 (2025년 기준 v0.7.x+, NVIDIA NGC에서도 공식 배포)

핵심 기술: PagedAttention

vLLM의 핵심 혁신은 PagedAttention(Kwon et al., 2023)이다. 운영체제의 가상 메모리 페이징 기법에서 영감을 받아, KV 캐시를 고정 크기 블록으로 분할하고 간접 참조(indirection) 레이어를 통해 관리한다.기존 방식의 문제: 전통적 KV 캐시는 각 시퀀스에 연속적인 메모리 영역을 할당한다. 최대 시퀀스 길이를 미리 예약해야 하므로평균 60–80%의 메모리가 낭비된다 (내부 단편화 + 외부 단편화).PagedAttention의 해결책:

• KV 캐시를 고정 크기 블록(예: 16 토큰)으로 분할
• 각 시퀀스는 블록 테이블(page table)을 통해 비연속적 블록을 참조
• 시퀀스가 성장하면 새 블록을 동적 할당
• Copy-on-Write로 빔 서치 등에서 KV 캐시 공유 가능 결과: 메모리 낭비를5% 미만으로 줄여, 동일 GPU에서 2–4배 더 많은 동시 요청 처리 가능.

아키텍처

Client Request → FastAPI Server → AsyncLLMEngine
    → Scheduler (continuous batching)
    → Model Runner (GPU execution)
    → PagedAttention KV Cache Manager
    → Sampler → Token Output (streaming)

-Scheduler: Continuous batching으로 요청을 iteration 단위로 스케줄링 -Model Runner: CUDA 커널로 모델 실행 (FlashAttention/FlashInfer 백엔드 선택 가능) -KV Cache Manager: 블록 단위 할당/해제, Copy-on-Write 지원

성능 벤치마크

BentoML 벤치마크(2024, A100 80GB, Llama 3 8B):

• TTFT: 모든 동시 사용자 수준에서 최고 수준(best-in-class)
• 토큰 생성률: 100 사용자 기준 약2,300–2,500 tokens/s(LMDeploy의 4,000 tokens/s보다 낮음)
• GPU 활용률이 높은 엔진들(LMDeploy 등)에 비해 decode throughput에서 약간 뒤처짐

지원 모델/양자화

-모델: 30+ 아키텍처 (LLaMA, Mistral, Qwen, Gemma, Phi, Command-R, DeepSeek 등) -양자화: AWQ, GPTQ, FP8, INT8 (W8A8), Marlin kernels -하드웨어: NVIDIA CUDA, AMD ROCm, AWS Neuron, CPU

장단점

적합한 사용 시나리오

• 범용 프로덕션 LLM 서빙 (높은 throughput + 낮은 TTFT)
• 다양한 모델을 단일 인프라에서 서빙
• 멀티 GPU 분산 추론

3.2 SGLang GitHub: sgl-project/sglang개발: LMSYS (UC Berkeley, Zheng et al.)논문: Zheng et al., “SGLang: Efficient Execution of Structured Language Model Programs” (2023, ICLR 2025 게재)최신 상태: 매우 활발한 개발 (2025년 말 기준 Diffusion 모델 지원, EAGLE 3 speculative decoding 등)

핵심 기술: RadixAttention

SGLang의 혁신은 RadixAttention— KV 캐시를라딕스 트리(radix tree) 구조로 관리하여 다수 요청 간 prefix를 자동으로 공유하는 메커니즘이다.PagedAttention과의 차이:

• PagedAttention: 블록 단위 메모리 관리에 초점 (단편화 제거)
• RadixAttention:prefix 재사용에 초점 (동일한 prefix를 공유하는 요청들이 KV 캐시를 중복 계산하지 않음)라딕스 트리 구조:

Root
├── "You are a helpful assistant. " → KV cached
│   ├── "Translate: Hello" → Branch A
│   ├── "Translate: World" → Branch B
│   └── "Summarize: ..." → Branch C

동일한 system prompt나 few-shot 예시를 공유하는 수많은 요청이 KV 캐시를 한 번만 계산하고 재사용. 캐시 히트율:

• Few-shot learning (공유 예시):85–95%(vLLM PagedAttention: 15–25%)
• Multi-turn chat:60–85%(vLLM: 30–50%)
• LMSYS 프로덕션: LLaVA-Next-34B에서52.4%, 일부 모델74.1%캐시 히트율

Frontend DSL

SGLang은 런타임뿐 아니라 프론트엔드 DSL도 제공한다:

python
@sgl.function
def multi_turn_qa(s, question1, question2):
    s += sgl.system("You are a helpful assistant.")
    s += sgl.user(question1)
    s += sgl.assistant(sgl.gen("answer1", max_tokens=256))
    s += sgl.user(question2)
    s += sgl.assistant(sgl.gen("answer2", max_tokens=256))

이 DSL은 자동으로 prefix 공유를 최적화하고, fork/join으로 병렬 생성을 지원한다.

Structured Generation Compressed Finite State Machine기법으로 JSON, regex 등 구조화된 출력을 효율적으로 디코딩. 기존 토큰 단위 마스킹 대비 구간(jump) 단위로 처리하여 오버헤드를 대폭 감소.

성능 벤치마크

LMSYS 벤치마크 (2024년 7월, Llama 3):

• Llama 3 8B (A100): SGLang과 TensorRT-LLM 모두 짧은 입력에서 최대 5,000 tokens/s달성, vLLM은 뒤처짐
• Llama 3 70B: SGLang이 online serving에서vLLM 대비 최대 3x throughput달성
• Structured workload에서 baseline 대비 최대 6.4x throughput, 3.7x 낮은 latencyClarifai 벤치마크 (2025년 8월, GPT-OSS-120B, H100):
• 중간~높은 동시성(50 요청)에서 SGLang이 강한 성능
• TensorRT-LLM이 단일 요청에서 최고 throughput, 극한 동시성에서는 스케일링 부족

장단점

적합한 사용 시나리오

• Agent/Tool-use 워크플로우 (높은 prefix 재사용)
• 구조화된 출력 (JSON) 필요 시
• Multi-turn chat 서빙
• Few-shot 평가 파이프라인

3.3 TensorRT-LLM GitHub: NVIDIA/TensorRT-LLM개발: NVIDIA라이선스: Apache 2.0최신 상태: v0.17+ (2025년 기준), NVIDIA 공식 추론 스택

핵심 기술

TensorRT-LLM은 NVIDIA의 TensorRT컴파일러 위에 구축된 LLM 전용 추론 엔진으로, 모델별로최적화된 CUDA 커널을 컴파일-타임에 생성한다.주요 최적화:

1. In-flight Batching: Continuous batching의 NVIDIA 구현. 개별 요청이 완료되는 즉시 새 요청을 삽입
2. FP8/INT4 양자화: Hopper 아키텍처(H100)의 FP8 Tensor Core를 활용. FP16 대비2x 이상 throughput, 품질 손실2% 미만3.Paged KV Cache: vLLM과 유사한 블록 기반 KV 관리
3. Quantized KV Cache: INT8, FP8로 KV 캐시 자체를 양자화하여 메모리 절약
4. KV Cache Reuse: CPU로 KV 오프로딩 후 재사용. TTFT를최대 14x 감소(H100 기준)
5. Kernel Fusion: MHA, MLP 등을 하나의 커널로 융합

아키텍처

Model Definition (Python) → TensorRT Engine Build (컴파일)
    → Executor API → Triton Inference Server (서빙)
    → In-flight Batching Scheduler
    → Fused CUDA Kernels

중요: TensorRT-LLM은명시적 컴파일 단계가 필요하다. 모델+하드웨어+배치 크기 조합마다 엔진을 빌드해야 하며, 이 과정이 수십 분~수 시간 소요될 수 있다.

성능 벤치마크

• 단일 요청 latency: NVIDIA GPU에서 최저 수준(컴파일된 커널의 강점)
• Llama 3.1 8B FP8 (H100): FP16 대비~2x throughput 향상- LMSYS 벤치마크: 짧은 입력에서 SGLang과 함께5,000 tokens/s달성
• 높은 동시성에서는 공격적 배칭으로 P99 latency 증가 가능

장단점

적합한 사용 시나리오

• NVIDIA 전용 환경에서 최대 성능 필요
• latency-critical 워크로드 (실시간 챗봇)
• 모델이 고정되어 있고 엔진 빌드 투자 가능한 환경

3.4 TGI (Text Generation Inference) GitHub: huggingface/text-generation-inference개발: Hugging Face라이선스: HFOIL (v1까지), Apache 2.0 (v2+)최신 상태:2025년 12월 기준 유지보수 모드(maintenance mode) — 마이너 버그 수정만 수용

핵심 기술

TGI는 Hugging Face 생태계의 공식 추론 서버로, 프로덕션 서빙에 필요한 기능을 올인원으로 제공한다:

1. Rust 기반 HTTP/gRPC 서버: 고성능 웹 서버
2. Flash Attention(Dao et al., 2022): HBM ↔ SRAM 간 IO를 최적화한 어텐션 알고리즘
3. Continuous Batching: 동적 요청 삽입/제거
4. Paged Attention: vLLM 스타일 KV 캐시 관리
5. TGI v3의 Chunked Prefill: 긴 컨텍스트를 청크로 나눠 prefill하여 메모리 피크 감소
6. Prefix KV Caching: 긴 대화 히스토리의 KV를 재사용

성능 벤치마크

• 일반 프롬프트: vLLM과 비슷한 수준, 높은 동시성에서 vLLM이 약간 우세 -TGI v3 + 긴 컨텍스트: vLLM 대비3x 더 많은 토큰 처리, 최대 13x 빠름(긴 히스토리 + prefix caching)
• BentoML 벤치마크 (Llama 3 8B, A100): 2,300–2,500 tokens/s (vLLM과 유사)

지원 양자화

• AWQ, GPTQ, bitsandbytes (INT4, INT8)
• FP8 (실험적)

장단점

적합한 사용 시나리오

• HuggingFace Inference Endpoints 사용자
• 긴 대화 히스토리의 chat 워크로드 (v3의 prefix caching 활용)
• 빠른 프로토타이핑 및 배포

주의: TGI가 유지보수 모드에 진입함에 따라, HuggingFace는 vLLM/SGLang을 대안으로 권장하고 있다.

3.5 llama.cpp GitHub: ggml-org/llama.cpp개발: Georgi Gerganov 및 커뮤니티라이선스: MIT최신 상태: 매일 활발한 개발 (2025년 기준 빌드 번호 4000+)

핵심 기술: GGUF 양자화

llama.cpp는 C/C++로 작성된 순수 추론 엔진으로, Python/PyTorch 의존성 없이 CPU와 GPU 모두에서 LLM을 실행할 수 있다.GGUF(GGML Unified Format): llama.cpp의 모델 파일 형식으로, 다양한 양자화 방식을 지원한다.

양자화 방식 상세

*IQ 양자화는 partial GPU offloading 시 매우 느릴 수 있음. K-Quant 시스템: “K”가 붙은 양자화(Q4_K_M 등) 는super-block구조를 사용한다. 각 super-block(보통 256개 가중치)이 독립적인 스케일 팩터를 가지며, M(medium)과 S(small)는 스케일 팩터의 정밀도 차이.

아키텍처

GGUF Model File → ggml 텐서 라이브러리
    → CPU: AVX2/AVX-512/ARM NEON 벡터 연산
    → GPU: CUDA/Metal/Vulkan/OpenCL 오프로딩
    → 멀티스레드 추론
    → HTTP Server (llama-server) 또는 CLI

-Partial GPU Offloading: 레이어 단위로 GPU/CPU 분할 가능 -Metal 지원: Apple Silicon에서 뛰어난 성능 -Vulkan: 범용 GPU 가속 (AMD, Intel)

성능 벤치마크

llama-bench 결과 (Apple Silicon M-시리즈, Qwen2 1.5B Q4_0):

• Prompt processing (pp512):5,765 tokens/s- Token generation (tg128):198 tokens/sGPU 완전 오프로딩 시 ExLlamaV2 대비:
• 동일 모델에서 llama.cpp는~7,500 tokens/s(prompt) , ExLlamaV2는~14,000 tokens/s(약 2x 차이)

장단점

적합한 사용 시나리오

• 로컬 PC/노트북에서 LLM 실행
• GPU 없는 CPU 서버 배포
• Apple Silicon Mac에서 추론
• 엣지 디바이스 배포

3.6 Ollama GitHub: ollama/ollama개발: Ollama Inc.라이선스: MIT최신 상태: 활발한 개발 (2025년 기준 클라우드 모델 지원까지 확장)

핵심 기술

Ollama는llama.cpp를 래핑한 사용자 친화적 LLM 실행 환경이다. Docker처럼 모델을 pull/run하는 인터페이스를 제공한다.

bash
ollama pull llama3.1
ollama run llama3.1

아키텍처

Ollama CLI/API → Go 서버 (REST API)
    → llama.cpp (추론 백엔드)
    → 모델 레지스트리 (ollama.com)
    → Modelfile (Dockerfile처럼 모델 구성)

주요 기능: -모델 관리: ollama pull, ollama list, ollama rm -Modelfile: 시스템 프롬프트, 온도 등을 선언적으로 설정 -OpenAI 호환 API: /v1/chat/completions 엔드포인트 -멀티모달: 비전 모델 지원 -2025년 업데이트: 클라우드 모델 연동(Turbo), 로컬 전용 모드 설정 추가

성능

Ollama의 성능은 본질적으로llama.cpp와 동일하다. Go 서버 래퍼의 오버헤드는 미미하며, 주요 병목은 llama.cpp 백엔드의 추론 속도이다.

vLLM과의 비교 (동일 모델, 동일 GPU): -단일 요청: 거의 동일한 latency -동시 요청: vLLM이 continuous batching으로2–5x 높은 throughput#### 장단점

적합한 사용 시나리오

• 개발자 로컬 환경 프로토타이핑
• 비개발자의 LLM 접근성 확보
• 소규모 팀의 내부 AI 도구
• CI/CD 파이프라인에서 LLM 테스트

3.7 MLC LLM GitHub: mlc-ai/mlc-llm개발: CMU/OctoAI (TVM 팀, Chen et al.)논문: Apache TVM (Chen et al., 2018)을 기반라이선스: Apache 2.0

핵심 기술: TVM 컴파일러

MLC LLM은 Apache TVM 컴파일러 프레임워크를 사용하여 LLM을 다양한 하드웨어 백엔드에 맞게네이티브 코드로 컴파일한다.컴파일 파이프라인:

HuggingFace 모델 → Relax IR (TVM)
    → 하드웨어별 최적화 (fusion, tiling, vectorization)
    → 백엔드별 코드 생성:
        - CUDA (NVIDIA GPU)
        - Metal (Apple GPU)
        - Vulkan (범용 GPU)
        - OpenCL (모바일 GPU)
        - WebGPU (브라우저)
        - C/LLVM (CPU)

모바일/엣지 배포

MLC LLM의 독보적 강점은 모바일 디바이스에서의 LLM 추론이다: -iOS: Metal 백엔드, Swift 바인딩 -Android: OpenCL/Vulkan 백엔드, Java/Kotlin 바인딩 -WebGPU: 브라우저에서 직접 실행 (web-llm)

모바일 벤치마크 (arxiv:2410.03613, 2024):

• Qualcomm Snapdragon 8 Gen 3에서 7B 4-bit 모델:~10-15 tokens/s- Apple A17 Pro에서 유사 설정:~20+ tokens/s#### BentoML 벤치마크 (Llama 3 8B, A100)

• 10 사용자: LMDeploy와 유사한 decode 성능, 최고 수준 TTFT- 50 사용자: 여전히 좋은 TTFT

• 100 사용자: 높은 부하에서 성능 급격히 저하— decode 속도와 TTFT 모두 LMDeploy에 뒤처짐

장단점

적합한 사용 시나리오

• 모바일 앱에 LLM 내장
• 브라우저 기반 AI (WebGPU)
• 엣지 디바이스 배포 (Jetson, RPi 등)
• 하드웨어 다양성이 큰 환경

3.8 LMDeploy GitHub: InternLM/lmdeploy개발: Shanghai AI Lab (InternLM 팀)라이선스: Apache 2.0

핵심 기술: TurboMind

LMDeploy의 핵심 추론 엔진인 TurboMind는 NVIDIA FasterTransformer의 GPT-NeoX 구현에서 출발하여 대화형 모델 추론에 최적화되었다.핵심 최적화:

1. Persistent Batching: Continuous batching의 변형으로, 배치를 유지하면서 개별 시퀀스를 동적으로 교체
2. Blocked KV Cache: vLLM PagedAttention과 유사한 블록 기반 KV 관리, 단 내부 레이아웃이 다름
3. Dynamic Split & Fuse: 어텐션 블록을 동적으로 분할/융합하여 GPU 활용 최적화
4. KV Quantization: INT8/INT4로 KV 캐시 자체를 양자화
5. Weight Quantization: AWQ 4-bit, INT8 지원

성능 벤치마크 BentoML 벤치마크(Llama 3, A100 80GB):

LMDeploy는 특히 양자화 모델에서 높은 GPU 활용률을 달성하며, GPU utilization이 거의 100%에 근접한다.

장단점

적합한 사용 시나리오

• 최대 throughput이 필요한 NVIDIA GPU 환경
• 양자화 모델 서빙 (AWQ 4-bit)
• InternLM 계열 모델 사용 시
• 대규모 동시 서빙 (높은 동시성에서도 안정)

3.9 Triton Inference Server GitHub: triton-inference-server/server개발: NVIDIA라이선스: BSD 3-Clause

핵심 기술

Triton은 범용 모델 서빙 플랫폼으로, LLM 전용이 아니라 다양한 ML 모델을 서빙한다. LLM 서빙 시에는 주로TensorRT-LLM 백엔드와 함께 사용된다.핵심 기능:

1. Dynamic Batching: 여러 요청을 자동으로 배칭. 대기 시간/배치 크기 제한 설정 가능
2. 모델 앙상블: 전처리 → LLM → 후처리를 파이프라인으로 구성
3. 멀티 백엔드: TensorRT, ONNX Runtime, PyTorch, TensorFlow, vLLM 등
4. 모델 동시 서빙: 하나의 서버에서 여러 모델을 동시에 서빙
5. 모델 버저닝: A/B 테스트를 위한 모델 버전 관리

아키텍처

Client (HTTP/gRPC) → Triton Server
    → Request Scheduler (dynamic batching)
    → Model Repository
        ├── Model A (TensorRT-LLM)
        ├── Model B (ONNX Runtime)
        └── Ensemble Pipeline
    → Response Aggregator

LLM 서빙에서의 역할

Triton 자체는 LLM 추론 최적화(PagedAttention 등)를 수행하지 않는다. 대신: -TensorRT-LLM Backend: tensorrtllm_backend을 통해 TensorRT-LLM 엔진 서빙 -vLLM Backend: vLLM을 Triton 백엔드로 사용 가능

• 실제 추론 최적화는 백엔드 엔진이 담당

장단점

적합한 사용 시나리오

• 멀티모달 AI 파이프라인 (LLM + 이미지 + 음성)
• 대규모 엔터프라이즈 ML 인프라
• A/B 테스트 + 모델 버저닝 필요
• TensorRT-LLM 모델의 프로덕션 서빙 래퍼

3.10 ExLlamaV2 GitHub: turboderp-org/exllamav2개발: turboderp라이선스: MIT

핵심 기술: EXL2 양자화

ExLlamaV2의 핵심 혁신은 EXL2 (ExLlama v2 Quantization)—레이어별, 텐서별로 다른 비트 수를 혼합하는 양자화 방식이다.작동 원리:

1. 각 레이어/텐서의 중요도(sensitivity)를 측정
2. 중요한 레이어는 높은 비트(6-8bit), 덜 중요한 레이어는 낮은 비트(2-3bit)로 양자화
3. 전체 모델의 평균 비트를 목표(예: 4.25 bits per weight)에 맞춤
4. 이를 통해 동일 모델 크기에서 균일 양자화보다 높은 품질달성지원 비트: 2, 3, 4, 5, 6, 8 bit 및 이들의 혼합

성능 벤치마크

Reddit 벤치마크 (2024, RTX 4090):

• Llama 3 8B: ExLlamaV2가 prompt processing에서~14,000 tokens/s(llama.cpp의 ~7,500 대비 약2x)
• 동일 4-bit에서 EXL2가 GPTQ보다 약간 높은 품질, GGUF와 비슷하거나 약간 낮음 -ExLlama를 통한 GPTQ 실행이 가장 빠른 evaluation 속도(oobabooga 벤치마크)

품질 비교 (4-bit, Llama 2 13B, perplexity 기준):

• AWQ: 최고 품질
• GPTQ ≈ EXL2: 유사
• GGUF (Q4_K_M): 약간 뒤처짐

장단점

적합한 사용 시나리오

• 단일 GPU에서 최대 추론 속도 (TabbyAPI 등과 함께)
• 메모리에 맞추기 위한 정밀 양자화 조절
• 로컬 AI 채팅 (oobabooga, SillyTavern)

3.11 Ray Serve + vLLM 프레임워크: Ray Serve + vLLM개발: Anyscale (Ray), UC Berkeley (vLLM)

핵심 기술

Ray Serve는 분산 모델 서빙 프레임워크로, vLLM을 백엔드로 사용하면서오토스케일링, 모니터링, 장애 복구를 추가한다.아키텍처:

Load Balancer → Ray Serve Router
    → Replica 1 (vLLM on GPU 0-1)
    → Replica 2 (vLLM on GPU 2-3)
    → Replica N (autoscaled)
    → Ray Dashboard (모니터링)

핵심 기능:

1. 오토스케일링: 트래픽에 따라 vLLM 인스턴스 자동 증감
2. 멀티모델 서빙: 하나의 클러스터에서 여러 모델 동시 서빙
3. 장애 복구: 레플리카 실패 시 자동 재시작
4. Disaggregated Serving: Prefill과 Decode를 별도 노드에서 실행 (vLLM의 최신 기능)vLLM Large-Scale Serving(2025년 12월):

• DeepSeek 모델에서 H200 당 2,200 tokens/s(Wide Expert Parallelism)
• NIXL/LMCache 커넥터로 효율적 KV 전송
• Ray의 분산 컴퓨팅으로 각 phase(prefill/decode)를 독립적으로 스케일링

장단점

적합한 사용 시나리오

• 대규모 프로덕션 LLM 서비스
• 트래픽 변동이 큰 환경
• 멀티모델 / 멀티테넌트 서빙
• 클라우드 네이티브 AI 인프라

3.12 PowerInfer GitHub: SJTU-IPADS/PowerInfer개발: Shanghai Jiao Tong University논문: Song et al., “PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU” (2023)

핵심 기술: 뉴런 인식 희소 추론

PowerInfer는 LLM의 활성화 희소성(activation sparsity)을 활용한다. FFN 레이어에서 실제로 활성화되는 뉴런은 전체의 일부이며,어떤 뉴런이 자주 활성화되는지(“hot neurons”)는 미리 프로파일링할 수 있다.작동 원리:

1. 오프라인 프로파일링으로 뉴런별 활성화 빈도 분석
2. Hot neurons(자주 활성화): GPU에 상주
3. Cold neurons(드물게 활성화): CPU 메모리에 보관
4. 런타임에 adaptive predictor가 어떤 뉴런이 활성화될지 예측
5. Neuron-aware sparse operator로 활성화된 뉴런만 계산

성능 벤치마크

RTX 4090 단일 GPU:

• OPT-175B 포함 다양한 LLM에서 평균13.20 tokens/s, 최대29.08 tokens/s- A100 서버 대비18%만 낮은 성능— 소비자급 GPU에서!
• llama.cpp 대비 최대11x빠른 추론 (GPU 메모리 제한 모델에서)

장단점

적합한 사용 시나리오

• VRAM이 부족한 소비자 GPU에서 대형 모델 실행
• OPT, Falcon 등 희소 활성화 패턴이 강한 모델
• 연구/실험 목적

3.13 Aphrodite Engine GitHub: aphrodite-engine/aphrodite-engine개발: PygmalionAI라이선스: Apache 2.0GitHub Stars: ~1.6k

핵심 기술

Aphrodite는vLLM의 포크로, RP/스토리텔링 커뮤니티의 니즈에 맞춰 최적화되었다.vLLM 위에 추가된 기능:

• 향상된 샘플링 파라미터 (temperature, repetition penalty 등의 세밀한 제어)
• EXL2, GGUF 양자화 형식 지원 (vLLM은 GPTQ/AWQ 중심)
• 커뮤니티 요구에 빠른 대응
• PagedAttention KV 캐시 관리 (vLLM 기반)
• Continuous batching (async server)

장단점

적합한 사용 시나리오

• RP/스토리텔링 서빙 (SillyTavern 등)
• EXL2/GGUF 모델을 서버에서 서빙하고 싶을 때
• vLLM에 없는 샘플링 기능이 필요할 때

3.14 LocalAI GitHub: mudler/LocalAI개발: mudler 및 커뮤니티라이선스: MIT

핵심 기술

LocalAI는 OpenAI API 완전 호환 로컬 AI 서버로, 다양한 백엔드를 통합한다.멀티백엔드 아키텍처:

OpenAI-compatible API (/v1/chat/completions, /v1/images, /v1/audio, etc.)
    ├── llama.cpp (텍스트 생성)
    ├── whisper.cpp (음성 인식)
    ├── stable-diffusion.cpp (이미지 생성)
    ├── bark (TTS)
    ├── piper (TTS)
    └── 기타 백엔드들

2025년 기능:

• LocalAI Core (텍스트, 이미지, 오디오, 비전 API)
• LocalAGI (자율 에이전트)
• LocalRecall (시맨틱 검색)
• P2P 분산 추론
• Constrained grammars (구조화된 출력)

장단점

적합한 사용 시나리오

• OpenAI API를 사용하는 기존 코드를 로컬로 전환
• 멀티모달 AI (텍스트+이미지+음성)를 하나의 서버에서
• 프라이버시 민감 환경

3.15 DeepSpeed-MII GitHub: deepspeedai/DeepSpeed-MII개발: Microsoft DeepSpeed 팀라이선스: Apache 2.0

핵심 기술

DeepSpeed-MII는 Microsoft의 DeepSpeed라이브러리의 추론 최적화를 활용한 서빙 프레임워크이다.4대 핵심 기술:

1. DeepSpeed-Inference: 커스텀 CUDA 커널로 Transformer 추론 가속
2. ZeRO-Inference: 모델이 단일 GPU에 맞지 않을 때CPU 메모리/NVMe를 활용하여 오프로딩. Bloom-176B 같은 모델을 단일 GPU로 서빙 가능
3. DeepSpeed-FastGen: Continuous batching + Dynamic SplitFuse (prefill과 decode를 동적으로 분할/결합)
4. Tensor Parallelism: 멀티 GPU 병렬 추론Dynamic SplitFuse: 긴 프롬프트의 prefill을 여러 iteration에 걸쳐 분할하고, decode 토큰과 함께 fusion하여 GPU 활용률을 균일하게 유지.

성능

DeepSpeed-FastGen 블로그(2023):

• vLLM 대비 최대 2.3x throughput,최대 2x latency 감소(특정 워크로드)
• 단, 이후 vLLM이 크게 발전하여 최신 비교에서는 격차 축소

장단점

적합한 사용 시나리오

• 단일 GPU로 초대형 모델 서빙 (ZeRO-Inference)
• Azure/Microsoft 생태계
• DeepSpeed 학습 파이프라인과의 통합

3.16 OpenLLM (BentoML) GitHub: bentoml/OpenLLM개발: BentoML라이선스: Apache 2.0

핵심 기술

OpenLLM은 BentoML 프레임워크 위에 구축된 LLM 서빙 도구로, 모델 패키징부터 클라우드 배포까지의 전체 라이프사이클을 관리한다.특징: -Bento 패키징: 모델 + 의존성 + 서빙 코드를 하나의 패키지로 -OpenAI 호환 API-추론 백엔드 교체 가능: vLLM, TensorRT-LLM 등을 백엔드로 사용 -BentoCloud 배포: 원클릭 클라우드 배포 -LangChain 통합#### 장단점

적합한 사용 시나리오

• ML 모델 패키징/배포 파이프라인이 필요한 팀
• BentoCloud 사용자
• LLM + 기타 ML 모델을 함께 서빙

3.17 CTranslate2 GitHub: OpenNMT/CTranslate2개발: OpenNMT (SYSTRAN)라이선스: MIT

핵심 기술

CTranslate2는 Transformer 모델을 최적화된 C++ 포맷으로 변환하여 추론하는 엔진이다. 원래 기계 번역(NMT)을 위해 개발되었으나, LLM으로 확장되었다.최적화 기법:

1. Layer Fusion: 연속된 레이어를 하나의 연산으로 결합
2. Padding Removal: 배치 내 패딩을 제거하여 불필요한 계산 방지
3. Batch Reordering: 배치 내 시퀀스를 길이순으로 정렬하여 효율 향상
4. In-place Operations: 메모리 할당 최소화
5. Caching Mechanism: 반복 연산 결과 캐싱양자화: INT8, INT16, Float16 지원. INT8 모델이 Float32 대비3.53x 빠름(AMD ROCm 벤치마크).주요 사용처:Faster-Whisper(Whisper 음성 인식의 고속 구현)에서 CTranslate2가 핵심 백엔드로 사용됨.

장단점

적합한 사용 시나리오

• 기계 번역 서빙
• Whisper 기반 음성 인식 (Faster-Whisper)
• CPU 전용 환경에서의 Transformer 추론
• 경량 배포

3.18 Candle GitHub: huggingface/candle개발: Hugging Face라이선스: Apache 2.0/MIT

핵심 기술

Candle은 Rust로 작성된 미니멀 ML 프레임워크로, PyTorch와 유사한 API를 Rust의 안전성과 성능으로 제공한다.특징:

• 순수 Rust 구현 (libtorch/Python 의존성 없음)
• CUDA, Metal 백엔드 지원
• HuggingFace Hub 네이티브 통합
• WASM 타겟 (브라우저에서 실행 가능)
• Flash Attention 지원 (CUDA feature flag) 생태계:
• candle-transformers: 주요 모델 구현 (LLaMA, Mistral, Phi 등)
• candle-einops: Rust einops 구현
• atoma-infer: Candle 기반 대규모 추론 라이브러리 (FlashAttention2, PagedAttention)

장단점

적합한 사용 시나리오

• Rust 기반 애플리케이션에 ML 임베딩
• 서버리스/엣지에서 경량 추론
• WASM 기반 브라우저 AI
• HuggingFace 모델을 Rust에서 직접 사용

4. 기술 비교 분석

4.1 KV Cache 관리 방식 비교

4.2 양자화 방식 비교

4.3 Batching 전략 비교

4.4 Attention 최적화 비교

• 공유 prefix가 32,768 토큰이고 배치 크기 256일 때, 기본 PagedAttention 대비 최대 31x 속도 향상- 캐스케이딩 기법으로 공유 prefix 부분의 어텐션을 한 번만 계산FA3 벤치마크: SGLang에서 FA3가 FlashInfer와 Triton 백엔드를 모두 능가하며, 입출력 크기가 클수록 격차 확대.

4.5 Speculative Decoding 지원 현황

Speculative decoding은 작은 “draft 모델”이 여러 토큰을 빠르게 생성하고, 큰 “target 모델”이 이를 한 번에 검증하는 기법이다 (Leviathan et al., 2023; Chen et al., 2023).

4.6 Prefix Caching 비교

4.7 분산 추론 비교

• DeepSeek 모델에서 Wide Expert Parallelism으로 H200 당 2,200 tokens/s- NIXL/LMCache 커넥터로 prefill-decode 분리 시 KV 전송 효율화
• Ray 기반 독립 오토스케일링

5. 종합 비교 테이블

5.1 기능 비교

5.2 하드웨어 지원

5.3 성능 티어 (2025년 기준, 대략적 순위) GPU 서빙 Throughput(높은 동시성, A100/H100):

1. 🥇 LMDeploy (TurboMind) — 특히 양자화 모델
2. 🥇 SGLang — prefix 재사용이 많은 워크로드
3. 🥈 TensorRT-LLM — 엔진 빌드 후 최적 성능
4. 🥈 vLLM — 범용 최강
5. 🥉 TGI — vLLM에 약간 뒤처짐
6. DeepSpeed-MII, MLC LLM 단일 요청 Latency:
7. 🥇 TensorRT-LLM (컴파일된 커널)
8. 🥈 SGLang / vLLM
9. 🥉 LMDeploy 소비자 GPU(단일 사용자):
10. 🥇 ExLlamaV2 — 최고 속도
11. 🥈 llama.cpp (GPU offload)
12. 🥉 Ollama / PowerInfer

6. 사용 시나리오별 추천

시나리오 1: 프로덕션 챗봇 서비스 추천: vLLM 또는 SGLang + Ray Serve

• 높은 동시성, 안정적인 TTFT 필요
• Multi-turn chat이면 SGLang (RadixAttention 이점)
• 오토스케일링 필요 시 Ray Serve 추가

시나리오 2: NVIDIA 전용, 최대 성능 추천: TensorRT-LLM + Triton

• 모델이 고정되어 있고 엔진 빌드 투자 가능
• FP8 (H100)로 최대 throughput
• 엔터프라이즈 수준의 안정성

시나리오 3: 로컬 개발 / 프로토타이핑 추천: Ollama

• 5분 내 설치 + 실행
• 모델 레지스트리로 간편한 모델 관리

시나리오 4: CPU 서버 / GPU 없는 환경 추천: llama.cpp 또는 CTranslate2

• llama.cpp: 범용 LLM, 다양한 양자화
• CTranslate2: 번역/Whisper 등 특화

시나리오 5: 모바일 앱 / 브라우저 추천: MLC LLM (모바일), llama.cpp (모바일), Candle (WASM)

• MLC LLM: 가장 광범위한 모바일 지원
• web-llm: WebGPU 기반 브라우저 실행

시나리오 6: 단일 GPU, 대형 모델 추천: PowerInfer (희소 모델) 또는 DeepSpeed-MII (ZeRO-Inference)

• GPU 메모리 초과 모델을 CPU 오프로딩으로 실행

시나리오 7: Agent / Tool-use / 구조화된 출력 추천: SGLang

• RadixAttention으로 prefix 재사용 극대화
• Compressed FSM으로 JSON 출력 최적화
• DSL로 복잡한 LLM 파이프라인 구성

시나리오 8: OpenAI API 드롭인 대체 추천: LocalAI

• /v1/chat/completions 완전 호환
• 텍스트 + 이미지 + 음성 올인원

7. 결론

2025년 현재 LLM 서빙 생태계는 성숙기에 접어들면서 도구별 차별화가 뚜렷해지고 있다.

핵심 트렌드

1.vLLM과 SGLang의 양강 구도: 범용 서빙에서 vLLM, 구조화된 워크로드에서 SGLang이 각각 강세. TGI가 유지보수 모드에 진입하면서 이 구도가 강화됨.

2. KV 캐시 관리의 혁신: PagedAttention이 표준이 되었고, RadixAttention이 prefix 재사용에서 새로운 가능성을 열었다. KV 양자화(FP8)는 메모리 효율의 다음 프론티어.

3. Speculative Decoding의 보편화: EAGLE 3, Medusa 등으로 2-4x 속도 향상이 일반화되고 있으며, 모든 주요 엔진이 지원 중.

4. Disaggregated Serving: Prefill과 Decode를 분리하여 독립적으로 스케일링하는 아키텍처가 대규모 서빙의 새 표준으로 부상.

5. 소비자 하드웨어 접근성 확대: llama.cpp/Ollama 생태계가 로컬 AI를 대중화했고, PowerInfer가 소비자 GPU의 한계를 확장 중.

선택 가이드 요약

8. 참고문헌

핵심 논문

1. Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., … & Stoica, I.(2023). “Efficient Memory Management for Large Language Model Serving with PagedAttention.” SOSP 2023. [arXiv:2309.06180]

2. Zheng, L., Yin, L., Xie, Z., Huang, J., Sun, C., Yu, C. H., … & Stoica, I.(2023). “SGLang: Efficient Execution of Structured Language Model Programs.” ICLR 2025. [arXiv:2312.07104]

3. Dao, T., Fu, D. Y., Ermon, S., Rudra, A., & Ré, C.(2022). “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness.” NeurIPS 2022. [arXiv:2205.14135]

4. Dao, T.(2023). “FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning.” ICLR 2024. [arXiv:2307.08691]

5. Frantar, E., Ashkboos, S., Hoefler, T., & Alistarh, D.(2023). “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.” ICLR 2023. [arXiv:2210.17323]

6. Lin, J., Tang, J., Tang, H., Yang, S., Dang, X., & Han, S.(2024). “AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration.” MLSys 2024. [arXiv:2306.00978]

7. Leviathan, Y., Kalman, M., & Matias, Y.(2023). “Fast Inference from Transformers via Speculative Decoding.” ICML 2023. [arXiv:2211.17192]

8. Chen, C., Borgeaud, S., Irving, G., Lespiau, J. B., Sifre, L., & Jumper, J.(2023). “Accelerating Large Language Model Decoding with Speculative Sampling.” [arXiv:2302.01318]

9. Yu, G. I., Jeong, J. S., Kim, G. W., Kim, S., & Chun, B. G.(2022). “Orca: A Distributed Serving System for Transformer-Based Generative Models.” OSDI 2022.

10. Song, Y., Mi, Z., Xie, H., & Chen, H.(2023). “PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU.” [arXiv:2312.12456]

11. Chen, T., Moreau, T., Jiang, Z., Zheng, L., Yan, E., Shen, H., … & Krishnamurthy, A.(2018). “TVM: An Automated End-to-End Optimizing Compiler for Deep Learning.” OSDI 2018.

12. Li, Y., Cai, T., Zhang, Y., Chen, D., & Narasimhan, K.(2024). “EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty.” ICML 2024. [arXiv:2401.15077]

벤치마크 출처

• BentoML. (2024). “Benchmarking LLM Inference Backends.” https://www.bentoml.com/blog/benchmarking-llm-inference-backends
• LMSYS. (2024). “Achieving Faster Open-Source Llama3 Serving with SGLang Runtime.” https://lmsys.org/blog/2024-07-25-sglang-llama3/
• LMSYS. (2024). “Fast and Expressive LLM Inference with RadixAttention and SGLang.” https://lmsys.org/blog/2024-01-17-sglang/
• Clarifai. (2025). “Comparing SGLang, vLLM, and TensorRT-LLM with GPT-OSS-120B.” https://www.clarifai.com/blog/comparing-sglang-vllm-and-tensorrt-llm-with-gpt-oss-120b
• MarkTechPost. (2025). “Comparing the Top 6 Inference Runtimes for LLM Serving in 2025.” https://www.marktechpost.com/2025/11/07/comparing-the-top-6-inference-runtimes-for-llm-serving-in-2025/
• FlashInfer. (2024). “Accelerating Self-Attentions for LLM Serving with FlashInfer.” https://flashinfer.ai/2024/02/02/introduce-flashinfer.html
• oobabooga. (2023). “A detailed comparison between GPTQ, AWQ, EXL2, q4_K_M.” https://oobabooga.github.io/blog/posts/gptq-awq-exl2-llamacpp/
• vLLM Blog. (2025). “Large Scale Serving: DeepSeek @ 2.2k tok/s/H200 with Wide-EP.” https://blog.vllm.ai/2025/12/17/large-scale-serving.html

본 글은 2026년 2월 기준 최신 정보를 바탕으로 작성되었습니다. LLM 서빙 생태계는 빠르게 변화하므로, 각 도구의 공식 문서와 최신 릴리스를 확인하시기 바랍니다.