Skip to document
pieroot log
Markdown Preview

TGI 서빙 엔진: 대형 언어 모델 배포의 혁신과 핵심 기능 소개

Frontmatter

TGI는 Hugging Face에서 개발한 고성능 LLM 서빙 엔진으로, Rust와 Python을 기반으로 하여 gRPC를 통해 빠른 속도와 대규모 동시 요청 처리를 지원합니다. 주요 기능으로는 Flash Attention, PagedAttention, Tensor Parallelism, 양자화 지원 등이 있으며, SSE 기반의 토큰 스트리밍을 통해 체감 레이턴시를 줄이고, GPU 활용률을 극대화하는 Continuous Batching 기법을 사용합니다. 현재 maintenance mode에 있으며, 후속 엔진인 vLLM과 SGLang의 기반 기술로 자리잡고 있습니다.

TGI 서빙 엔진: 대형 언어 모델 배포의 혁신과 핵심 기능 소개

TGI (Text Generation Inference)


TGI(Text Generation Inference)는 Hugging Face에서 개발한 LLM(대형 언어 모델) 배포 및 서빙을 위한 툴킷입니다.
Llama, Falcon, StarCoder, BLOOM, GPT-NeoX, T5 등 가장 널리 사용되는 오픈소스 LLM에 대한 고성능 텍스트 생성을 지원합니다.
💡
한 줄 요약
Rust로 구축된 고성능 웹 서버에 Python으로 구축된 LLM 모델을 gRPC로 연결하여, 빠른 속도와 대규모 동시 요청을 처리할 수 있는 프로덕션 레벨 LLM 서빙 엔진입니다.
notion image
  • LLM을 효율적이고 빠르게 서빙하기 위한 툴
  • 대규모 배포 및 실시간 애플리케이션에 적합
  • Hugging Face의 Hugging Chat, Inference API, Inference Endpoints에서 프로덕션으로 사용 중

gRPC (1)
📝
참고: TGI는 현재 maintenance mode에 진입했습니다. Hugging Face는 향후 vLLM, SGLang 등의 다운스트림 추론 엔진을 권장하고 있습니다. 다만 TGI가 개척한 최적화 기법들(PagedAttention, Flash Attention, Continuous Batching 등)은 이들 엔진에서도 그대로 활용되고 있기 때문에 개념을 이해하는 것이 중요합니다.

주요 특징

특징
설명
🚀 고성능 추론
Flash Attention, PagedAttention 등 최적화된 모델 추론으로 빠른 텍스트 생성
📈 확장성
Tensor Parallelism을 통한 멀티 GPU 분산 추론, Continuous Batching으로 높은 동시성 제공
🔧 사용 편의성
직관적인 API와 Docker 기반 배포, OpenAI 호환 API 지원
📊 프로덕션 지원
Open Telemetry 기반 분산 트레이싱, Prometheus 메트릭, 구조화된 출력(Guided Decoding) 지원
⚡ 양자화 지원
GPTQ, bitsandbytes(4bit/8bit) 양자화로 제한된 하드웨어에서도 대형 모델 실행 가능

아키텍처 구조


TGI의 아키텍처는 크게 Router와 Model Server 두 부분으로 구성됩니다.
plain text
Client → [Rust Router (HTTP)] → [gRPC] → [Python Model Server (GPU)]
              ↓                              ↓
    - 요청 스케줄링                   - 모델 추론
    - Continuous Batching            - Flash Attention
    - Token Streaming                - PagedAttention
    - 큐 관리                        - Tensor Parallelism
  1. Router (Rust) 🦀: HTTP 요청을 받아 스케줄링하고, Continuous Batching을 관리합니다. Rust로 구현되어 매우 빠른 처리 속도를 제공합니다.
  1. Model Server (Python) 🐍: 실제 GPU에서 모델 추론을 수행합니다. PyTorch 기반으로 Flash Attention, PagedAttention 등의 최적화 기법을 적용합니다.
  1. gRPC 통신: Router와 Model Server 사이를 gRPC로 연결하여 효율적인 직렬화와 낮은 레이턴시를 보장합니다.

주요 구성 요소


Streaming


OpenAI의 ChatGPT와 같이 토큰 스트리밍을 통해 서버가 토큰을 하나씩 반환합니다.
사용자에게 대기시간을 줄여주어 더 나은 사용자 경험을 제공합니다.
LLM의 텍스트 생성은 autoregressive 방식이기 때문에, 전체 응답이 완성될 때까지 기다리면 사용자가 오래 기다려야 합니다. 스트리밍은 생성된 토큰을 즉시 전송하여 체감 레이턴시를 크게 줄여줍니다.
notion image
python
from huggingface_hub import InferenceClient

client = InferenceClient("http://127.0.0.1:8080")
for token in client.text_generation(
	"How do you make cheese?",
	max_new_tokens=12, 
	stream=True):
    print(token)
    
# To
# make
# cheese
#,
# you
# need
# to
# start
# with
# milk
#.
TGI는 Server-Sent Events(SSE) 프로토콜을 사용하여 스트리밍을 구현합니다. HTTP 기반이라 별도의 WebSocket 연결 없이도 실시간 토큰 전달이 가능합니다.

Quantization (양자화)


양자화를 위해 GPTQ, bitsandbytes를 지원합니다.
양자화를 통해 더 가벼운(좋지 않은) 하드웨어에 무거운 모델을 실행할 수 있습니다.
💡
양자화란?
모델의 가중치를 기존 FP32/FP16에서 INT8/INT4 등 더 낮은 정밀도로 변환하는 기법입니다. 메모리 사용량과 연산량을 줄이는 대신 약간의 정확도 손실이 발생할 수 있습니다.
양자화 방식
정밀도
특징
GPTQ
4bit
학습 후 양자화(PTQ), 사전에 양자화된 모델 필요, 높은 압축률
bitsandbytes (8bit)
8bit
런타임 양자화, 별도 사전 처리 불필요, 정확도 손실 최소
bitsandbytes-nf4
4bit
NormalFloat4 양자화, 메모리 절약 극대화, QLoRA에서 사용
shell
# 8bit 양자화
docker run --gpus all --shm-size 1g -p 8080:80 \
  -v $volume:/data ghcr.io/huggingface/text-generation-inference:latest \
  --model-id $model --quantize bitsandbytes

# 4bit 양자화
docker run --gpus all --shm-size 1g -p 8080:80 \
  -v $volume:/data ghcr.io/huggingface/text-generation-inference:latest \
  --model-id $model --quantize bitsandbytes-nf4
📝
실무 팁: GPU 메모리가 부족한 환경(예: 24GB L4에서 70B 모델)에서는 4bit 양자화가 거의 필수입니다. GPTQ는 사전 양자화 모델이 Hub에 올라와 있는 경우가 많으니, TheBloke 같은 유저의 양자화 모델을 활용하면 편리합니다.

Tensor Parallelism


텐서의 병렬화를 통해 여러 개의 GPU를 사용하여 대규모 모델을 분산 실행하는 방법입니다.
notion image
Tensor Parallelism의 핵심 원리는 행렬 연산의 분할 가능성에 있습니다. 하나의 큰 행렬 곱셈을 여러 GPU에 나누어 병렬로 수행한 뒤, 결과를 다시 합쳐도 동일한 결과가 나오는 수학적 성질을 활용합니다.
plain text
[행렬 A] × [행렬 B] = [결과 C]

GPU 0: [A의 절반] × [B의 절반] = [C의 부분 결과 0]
GPU 1: [A의 절반] × [B의 절반] = [C의 부분 결과 1]

AllReduce → [C의 부분 결과 0] + [C의 부분 결과 1] = [결과 C]
shell
# 4개 GPU로 Tensor Parallelism 실행
docker run --gpus all --shm-size 1g -p 8080:80 \
  -v $volume:/data ghcr.io/huggingface/text-generation-inference:latest \
  --model-id $model --num-shard 4
💡
Tensor Parallelism vs Data Parallelism
  • Tensor Parallelism: 하나의 모델을 여러 GPU에 나눠서 실행 (모델이 단일 GPU 메모리에 안 들어갈 때)
  • Data Parallelism: 같은 모델을 여러 GPU에 복제하여 다른 데이터를 처리 (학습 시 주로 사용)
  • TGI에서는 추론 시 모델이 GPU 메모리에 안 들어가는 경우 Tensor Parallelism을 사용합니다

PagedAttention


LLM의 성능은 GPU 메모리 용량에 크게 좌우됩니다.
LLM의 input으로 주어지는 토큰들은 key, value tensor를 생성하고, 다음 토큰을 생성하기 위해 GPU 메모리에 저장됩니다. 이때 이 key-value tensor를 KV Cache라고 부릅니다.
📝
문제점: 기존 시스템에서는 KV Cache를 위해 연속된 메모리 공간을 미리 할당해야 했습니다. 시퀀스마다 최대 길이만큼 메모리를 예약하기 때문에, 실제로 사용되지 않는 메모리가 60~80%까지 낭비될 수 있었습니다.
PagedAttention은 이 문제를 해결하기 위해 운영체제의 가상 메모리 및 페이징 기법을 KV Cache 관리에 응용한 알고리즘입니다.
핵심 아이디어를 정리하면:
  • 블록(Block): KV Cache를 고정 크기 블록으로 분할 (OS의 페이지에 해당)
  • 토큰(Token): 각 블록 안의 개별 단위 (OS의 바이트에 해당)
  • 시퀀스(Sequence): 하나의 요청 처리 과정 (OS의 프로세스에 해당)
  • 블록 테이블(Block Table): 논리적 블록 → 물리적 블록 매핑 (OS의 페이지 테이블에 해당)
notion image
블록은 메모리에서 연속적일 필요가 없기 때문에, OS의 가상 메모리처럼 보다 유연한 방식으로 키와 값을 관리할 수 있습니다. 시퀀스의 연속된 논리 블록은 블록 테이블을 통해 연속되지 않은 물리적 블록에 매핑됩니다.

PagedAttention의 효과

항목
기존 방식
PagedAttention
메모리 할당
연속된 메모리 사전 할당
비연속 블록 단위 동적 할당
메모리 낭비
60~80% (내부/외부 단편화)
~4% 미만 (마지막 블록의 내부 단편화만)
동시 처리량
제한적
2~4배 향상
메모리 공유
불가
Beam Search 등에서 KV Cache 블록 공유 가능

Flash Attention


기존의 Attention 연산은 GPU의 메모리 대역폭 병목으로 인해 비효율적입니다. Flash Attention은 이 문제를 해결하기 위해 IO-aware 접근 방식을 사용합니다.
💡
핵심 문제: GPU의 컴퓨팅 속도는 빠르게 발전했지만, HBM(High Bandwidth Memory)의 읽기/쓰기 속도는 상대적으로 느립니다. 기존 Attention은 중간 결과(S = QK^T, P = softmax(S))를 HBM에 반복적으로 읽고 쓰기 때문에, 메모리 액세스가 병목이 됩니다.
plain text
[기존 Attention]
HBM → Q, K 로드 → S = QK^T 계산 → S를 HBM에 저장
HBM → S 로드 → P = softmax(S) 계산 → P를 HBM에 저장
HBM → P, V 로드 → O = PV 계산 → O를 HBM에 저장
(HBM 읽기/쓰기 6회)

[Flash Attention]
HBM → Q, K, V의 블록(타일) 로드 → SRAM에서 S, P, O 한 번에 계산 → O를 HBM에 저장
(HBM 읽기/쓰기 2회)
Flash Attention의 핵심 전략:
  1. Tiling (타일링): Q, K, V 행렬을 작은 블록(타일)으로 분할하여 GPU의 빠른 SRAM에 로드
  1. 커널 퓨전: Softmax, MatMul 등 여러 연산을 하나의 GPU 커널로 합쳐서 중간 결과의 HBM 왕복을 제거
  1. Online Softmax: 전체 행을 보지 않고도 softmax를 점진적으로 계산하는 알고리즘 사용
notion image
결과적으로 Flash Attention은 메모리 사용량을 O(N²)에서 O(N)으로 줄이고, 실행 속도를 2~4배 향상시킵니다. 특히 긴 시퀀스(4K+ 토큰)에서 효과가 극대화됩니다.

Continuous Batching


LLM 서빙에서 기존의 Static Batching은 배치 내 모든 시퀀스가 완료될 때까지 기다려야 했습니다. 짧은 응답이 먼저 끝나도 가장 긴 응답이 완료될 때까지 GPU가 유휴 상태로 낭비됩니다.
Continuous Batching은 이 문제를 해결합니다.
plain text
[Static Batching]
요청 A (10 토큰) ████████████░░░░░░░░ (끝났지만 대기)
요청 B (20 토큰) ████████████████████ (완료)
요청 C (15 토큰) ███████████████░░░░░ (끝났지만 대기)
                  → B가 끝날 때까지 모두 대기 → 다음 배치 시작

[Continuous Batching]
요청 A (10 토큰) ██████████
요청 D (새 요청)           ████████████████  ← A 완료 즉시 투입
요청 B (20 토큰) ████████████████████
요청 C (15 토큰) ███████████████
요청 E (새 요청)                ██████████  ← C 완료 즉시 투입
                  → 빈 슬롯에 즉시 새 요청 투입
💡
Continuous Batching의 효과
TGI의 Router는 완료된 시퀀스를 즉시 필터링하고, 대기 중인 새로운 요청을 iteration 단위로 배치에 추가합니다. 이를 통해 GPU 활용률을 극대화하고, 처리량(throughput)을 최대 23배까지 향상시킬 수 있습니다.
TGI의 Router는 Prefill(입력 토큰 처리)과 Decode(출력 토큰 생성) 단계를 인터리빙하여 처리합니다. Decode의 토큰 예산이 Prefill보다 크기 때문에, 새로운 요청의 Prefill을 기존 요청의 Decode 사이에 끼워넣어 효율적으로 스케줄링합니다.

TGI 빠르게 시작하기


Docker를 사용하면 간단하게 TGI를 실행할 수 있습니다.
shell
# 기본 실행 (Llama 3.1 8B 예시)
model=meta-llama/Llama-3.1-8B-Instruct
volume=$PWD/data

docker run --gpus all --shm-size 1g -p 8080:80 \
  -v $volume:/data \
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id $model
shell
# API 호출 테스트
curl localhost:8080/generate \
  -X POST \
  -d '{"inputs":"What is Deep Learning?","parameters":{"max_new_tokens":20}}' \
  -H 'Content-Type: application/json'

주요 실행 옵션

옵션
설명
기본값
--model-id
Hugging Face Hub 모델 ID 또는 로컬 경로
필수
--num-shard
Tensor Parallelism에 사용할 GPU 수
1
--quantize
양자화 방식 (bitsandbytes, gptq 등)
없음
--max-input-length
최대 입력 토큰 수
1024
--max-total-tokens
입력 + 출력 최대 토큰 수
2048
--max-batch-prefill-tokens
Prefill 단계 최대 배치 토큰 수
4096

TGI vs vLLM vs SGLang 비교


TGI와 함께 자주 비교되는 LLM 서빙 엔진들을 정리하면:
특성
TGI
vLLM
SGLang
개발
Hugging Face
UC Berkeley
LMSYS
언어
Rust + Python
Python + C++/CUDA
Python + C++/CUDA
PagedAttention
✅
✅ (최초 제안)
✅
Continuous Batching
✅
✅
✅
멀티 백엔드
✅ (TRT-LLM, vLLM)
❌
❌
Guided Decoding
✅
✅
✅ (RadixAttention)
HW 지원
NVIDIA, AMD, Intel Gaudi, AWS Trainium, TPU
NVIDIA, AMD, TPU
NVIDIA, AMD
현재 상태
Maintenance mode
활발한 개발
활발한 개발

정리

TGI는 LLM을 프로덕션 환경에서 효율적으로 서빙하기 위한 핵심 최적화 기법들을 집대성한 툴킷입니다. 현재 maintenance mode에 진입했지만, TGI가 도입하고 발전시킨 기술들은 vLLM, SGLang 등 후속 엔진들의 기반이 되고 있습니다.

핵심 정리

✅ TGI: Rust Router + Python Model Server + gRPC 구조의 고성능 LLM 서빙 엔진
✅ Streaming: SSE 기반 토큰 스트리밍으로 체감 레이턴시 감소
✅ Quantization: GPTQ/bitsandbytes를 통한 모델 경량화로 제한된 GPU에서도 대형 모델 실행
✅ Tensor Parallelism: 행렬 분할을 통해 멀티 GPU에서 대형 모델 분산 추론
✅ PagedAttention: OS 가상 메모리 기법을 KV Cache에 적용하여 메모리 낭비 ~4% 미만으로 감소
✅ Flash Attention: Tiling + 커널 퓨전으로 HBM 접근 최소화, 메모리 O(N) + 속도 2~4배 향상
✅ Continuous Batching: Iteration 단위 동적 배칭으로 GPU 활용률 극대화

참고 링크