추론 엔진 아키텍처 전쟁, vLLM·SGLang·TensorRT-LLM과 커스텀 실리콘의 실제 차이
2026년 5월 같은 주에 Cerebras IPO $26.6B, Sierra $950M Series E, RadixArk Seed $100M, Gimlet Labs $80M이 동시에 터졌다. 이 자본들이 공통으로 베팅하는 질문은 하나다: “이미 학습된 모델을 어떻게 더 싸게, 더 빠르게 서빙하는가.”
이 질문에 두 갈래의 답이 경쟁하고 있다. 소프트웨어 추론 엔진(vLLM, SGLang, TensorRT-LLM)과 커스텀 실리콘(Cerebras, Groq, Etched). 하지만 이 둘은 경쟁 관계가 아니다, 각각 다른 병목을 겨냥한다. 어떤 병목을, 어떻게 풀었는지를 아는 것이 실무 선택의 기준이 된다.
목차
- KV 캐시 전략이 처리량을 결정한다
- vLLM, PagedAttention: 운영체제에서 배운 방식
- SGLang, RadixAttention: 반복 컨텍스트를 캐싱한다
- TensorRT-LLM, Hopper 전용 컴파일러
- 엔진별 처리량 비교 및 선택 기준
- 커스텀 실리콘: 각각 어떤 병목을 해결하는가
- Gimlet Labs: 이종 칩 통합 레이어
- 의사결정 가이드
KV 캐시 전략이 처리량을 결정한다
Transformer 모델의 추론 비용 중 가장 큰 부분은 KV 캐시(Key-Value Cache) 관리다. 각 토큰을 생성할 때 모든 이전 토큰의 attention key/value를 재계산하지 않고 캐싱하는 것이 핵심인데, 이 캐시를 어떻게 저장하고 관리하는지에 따라 처리량이 크게 달라진다.
GPU VRAM은 모델 파라미터와 KV 캐시를 나눠 써야 한다. Llama 3.1 70B를 bf16로 올리면 이미 140GB가 필요하다, H100 80GB 두 장이 모델만으로 꽉 찬다. 남은 VRAM에서 KV 캐시가 얼마나 많은 요청을 동시에 처리할 수 있는지가 throughput을 결정한다. KV 캐시 단편화가 심하면 VRAM이 있음에도 새 요청을 받지 못한다.
vLLM: PagedAttention: 운영체제에서 배운 방식
vLLM의 핵심 혁신은 Linux 가상 메모리 관리에서 아이디어를 가져온 PagedAttention이다. KV 캐시를 4~16토큰 크기의 고정 블록(page)으로 분할해 관리한다.
전통적 방식의 문제:
요청 A: [토큰 1][토큰 2][토큰 3]...[토큰 512] ← 연속 메모리 예약
요청 B: [토큰 1][토큰 2] ← 연속 메모리 예약
↑ 두 요청 사이 빈 공간 = 내부 단편화PagedAttention의 해결:
물리 블록 풀:
[블록 0][블록 1][블록 2][블록 3][블록 4][블록 5]...
요청 A → 블록 테이블: [블록 0 → 토큰 1-16][블록 3 → 토큰 17-32]...
요청 B → 블록 테이블: [블록 1 → 토큰 1-16][블록 4 → 토큰 17-32]...
→ 블록 단위로 필요할 때마다 할당 = 단편화 없음OS의 페이지 테이블과 동일한 원리다. 결과적으로 KV 캐시 낭비가 줄어 더 많은 배치 처리가 가능하다.
vLLM의 강점: 200+ 모델 지원, 빠른 신모델 채택, continuous batching으로 요청마다 지연 없이 처리. OpenAI-compatible API 내장. 배포가 가장 빠르다.
# vLLM 서빙 시작 (단 2줄)
from vllm import LLM, SamplingParams
llm = LLM(model="meta-llama/Llama-3.1-8B-Instruct", tensor_parallel_size=2)
outputs = llm.generate(["서울의 날씨는"], SamplingParams(temperature=0.8, max_tokens=100))
# OpenAI-compatible 서버로 실행
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.1-8B-Instruct \
--tensor-parallel-size 2 \
--port 8000
SGLang: RadixAttention: 반복 컨텍스트를 캐싱한다
SGLang(RadixArk가 상용화, Seed $100M @ $400M)은 다른 문제를 풀었다. 시스템 프롬프트가 모든 요청에 반복되는 상황, 챗봇, 에이전트, RAG, 에서 같은 prefix의 KV를 매번 재계산하는 낭비를 없앤다.
RadixAttention은 Radix tree(기수 트리)로 KV 캐시를 구조화한다.
공유 시스템 프롬프트:
"당신은 고객 서비스 AI입니다. 친절하고 정확하게 답변하세요..."
(500 토큰)
요청 1: [시스템 프롬프트 500토큰][사용자: "환불 방법이요?"]
요청 2: [시스템 프롬프트 500토큰][사용자: "배송 조회 방법이요?"]
요청 3: [시스템 프롬프트 500토큰][사용자: "결제 오류 해결법이요?"]
전통 방식: 세 요청 모두 시스템 프롬프트 500토큰 KV 재계산
RadixAttention: 시스템 프롬프트 KV는 한 번만 계산, 세 요청이 공유
→ 500토큰 × 2회 KV 계산 절감Radix tree로 prefix를 관리하기 때문에 캐시 히트율이 높고, 다중 턴 대화에서 이전 턴의 KV가 자동으로 재사용된다.
# SGLang 서버 실행
python -m sglang.launch_server \
--model-path meta-llama/Llama-3.1-8B-Instruct \
--port 30000 \
--enable-cache-report # 캐시 히트율 모니터링
# 결과: 공유 prefix가 많은 워크로드에서 캐시 히트율 60~80%
동일 워크로드(Llama 3.1 8B, bf16, 배치 추론)에서 처리량:
- vLLM: ~12,553 tok/s
- SGLang: ~16,215 tok/s (+29%)
+29% 차이는 “SGLang이 vLLM보다 좋다"가 아니다. 시스템 프롬프트가 반복되는 워크로드에서 RadixAttention의 캐시 히트가 재계산을 줄이기 때문이다. 독립적인 단발성 요청이 많으면 이 차이가 줄어든다.
TensorRT-LLM: Hopper 전용 컴파일러
TensorRT-LLM은 NVIDIA의 공식 추론 프레임워크로 Hopper 아키텍처(H100/H200)에 특화돼 있다. 단순히 모델을 로드하는 것이 아니라 그래프를 컴파일해 H100의 Tensor Core와 FP8 연산을 최대로 활용하는 실행 파일을 만든다.
# 모델 컴파일 (28분 소요, 단 한 번만)
trtllm-build \
--checkpoint_dir ./llama-3.1-8b-hf \
--output_dir ./llama-3.1-8b-trt \
--gemm_plugin float16 \
--use_fp8 \ # H100 FP8 Tensor Core 활용
--max_batch_size 64 \
--max_input_len 2048 \
--max_output_len 512
# 이후 실행 시 vLLM 대비 +20~40% 처리량
컴파일 결과물은 특정 모델 + 특정 하드웨어에 최적화된 바이너리다. 다른 모델을 쓰거나 A100으로 바꾸면 재컴파일 필요. 이것이 TensorRT-LLM의 제약이자 강점이다, 단일 모델을 H100에서 안정적으로 운영하는 프로덕션 환경에서는 처리량이 가장 높다.
엔진별 처리량 비교 및 선택 기준
처리량 기준 (Llama 3.1 8B, bf16, 배치 추론)
| 엔진 | Throughput (tok/s) | 상대 성능 | 비고 |
|---|---|---|---|
| vLLM (PagedAttention) | ~12,553 | 기준 | continuous batching |
| SGLang (RadixAttention) | ~16,215 | +29% | 반복 prefix 많은 경우 |
| TensorRT-LLM (FP8) | ~17,500+ | +20~40% | H100 전용, 컴파일 28분 |
| Groq LPU | ~500 tok/s (per request) | 지연 결정론 | 배치 불가, 최저 latency |
수치는 단일 H100 80GB 기준. 워크로드 특성에 따라 변동.
워크로드별 선택 기준
| 워크로드 | 권장 엔진 | 이유 |
|---|---|---|
| 신모델 빠른 채택, 200+ 모델 운영 | vLLM | 가장 넓은 모델 지원, 빠른 릴리스 |
| 챗봇, RAG, 에이전트 (긴 시스템 프롬프트) | SGLang | RadixAttention 캐시 히트율 높음 |
| 단일 모델 H100 프로덕션 (안정 운영) | TensorRT-LLM | 처리량 최고, 단 컴파일 필요 |
| 결정론적 응답 지연이 필수 (통신, 의료) | Groq LPU | 0.8초/100토큰, OS 수준 결정론 |
| 이종 칩 혼합 환경 | Gimlet Labs | 칩 간 워크로드 슬라이싱 |
커스텀 실리콘: 각각 어떤 병목을 해결하는가
소프트웨어 엔진이 GPU VRAM을 얼마나 효율적으로 쓰는지의 문제라면, 커스텀 실리콘은 GPU 자체의 구조적 한계를 하드웨어로 해결하는 접근이다.
메모리 벽 (Memory Wall): Cerebras WSE-3
GPU의 근본 문제: A100/H100의 DRAM 대역폭은 각각 2TB/s, 3.35TB/s다. 컴퓨트 성능은 엄청나게 빠른데, 모델 파라미터를 DRAM에서 읽어오는 속도가 병목이 된다. 70B 모델에서 배치 크기 1로 추론하면 DRAM 대역폭이 처리량을 제한한다, 컴퓨트 활용률이 10~20%에 불과한 이유다.
Cerebras WSE-3는 이 병목을 근본적으로 제거한다.
NVIDIA H100:
DRAM 용량: 80 GB
DRAM 대역폭: 3.35 TB/s
모델 접근: DRAM ↔ HBM ↔ SRAM ↔ Tensor Core
Cerebras WSE-3:
On-chip SRAM: 44 GB (모델 파라미터가 칩 위에)
SRAM 대역폭: 21 PB/s (H100 DRAM의 6,000배)
모델 접근: SRAM → 연산 (DRAM 없음)DRAM 접근이 없으니 메모리 벽이 없다. 단, Llama-70B 한 모델에 wafer 4개, 칩 336개가 필요하다. 비용이 극단적이며, 범용성이 낮다.
지연 결정론 (Latency Determinism): Groq LPU
Groq LPU(Language Processing Unit)는 다른 문제를 푼다. GPU는 운영체제 스케줄러, CUDA 드라이버, 메모리 할당자 등 여러 소프트웨어 레이어를 거쳐 추론이 실행된다. 이 레이어들이 지연을 불확정적으로 만든다. 배포할 때마다 응답 시간이 다를 수 있다.
Groq LPU는 컴파일 시간에 모든 실행 경로가 결정된다. 런타임 스케줄링이 없다. 결과:
- 응답 지연: 0.8초/100토큰 (결정론적)
- 배치 처리: 불가 (단일 요청 최적화)
- 학습: 불가 (추론 전용)
- 용도: 텔레콤 SLA, 자율주행 안전 시스템, 의료 실시간 진단
70B 모델에 576칩이 필요하다는 점에서 역시 범용은 아니다.
트랜스포머 전용 ASIC, Etched Sohu
가장 공격적인 베팅이다. 트랜지스터의 96%를 행렬 연산(matmul)에 할당했다. 다른 연산 기능은 거의 없다. 모든 트랜스포머 연산이 결국 행렬 곱셈으로 분해된다는 전제 하에, 이 연산만 완전히 최적화한다.
주장하는 성능: Llama-70B에서 H100 8칩 대비 ~20배 처리량.
리스크가 명확하다. 아키텍처가 Mamba, RWKV, SSM 같은 선형 시간 복잡도 모델로 이동하면, 행렬 곱에 특화된 ASIC은 즉시 경쟁력을 잃는다. $500M @ $5B 밸류에이션으로 이 베팅을 했다. Etched 입장에서는 “트랜스포머 아키텍처가 향후 10년 이상 dominant하다"는 확신이 있어야 한다.
Gimlet Labs: 이종 칩 통합 레이어
Series A $80M을 받은 Gimlet Labs는 다른 방향을 선택했다. “더 좋은 칩을 만드는 것"이 아니라 “이미 있는 다양한 칩을 동시에 최적으로 활용하는 컴파일러” 를 만든다.
기존 접근:
GPU 클러스터 → 모델 → 단일 칩 아키텍처에 최적화된 실행
Gimlet Labs 접근:
NVIDIA H100 + AMD MI300 + Intel Gaudi + Cerebras + d-Matrix
↓
Gimlet 컴파일러: 모델을 칩별로 슬라이싱 → 각 칩이 잘 하는 것을 처리
↓
추론 3~10배 가속 (칩 갈기 없이, 기존 인프라 활용)기업 입장에서 이미 NVIDIA GPU와 일부 AMD를 가진 곳이 많다. 새 칩으로 전환하지 않아도 현재 이종 환경을 최적화할 수 있다면 채택 장벽이 낮다. 이게 Gimlet의 GTM이다.
의사결정 가이드
세 질문에 답하면 선택이 좁혀진다.
Q1. 모델 다양성이 필요한가?
- YES → vLLM (200+ 모델, 신모델 최속 지원)
- NO → 다음 질문으로
Q2. 시스템 프롬프트나 공유 컨텍스트가 긴가? (RAG, 에이전트, 챗봇)
- YES → SGLang (RadixAttention이 가장 효과적)
- NO → 다음 질문으로
Q3. 단일 모델을 H100에서 장기 안정 운영하는가?
- YES → TensorRT-LLM (컴파일 28분 초기 비용, 이후 최고 처리량)
- 결정론적 지연이 필요 → Groq LPU
- 이종 칩 환경 → Gimlet Labs
실제 운영에서는 레이어를 섞는 경우가 많다. vLLM을 사용하면서 prefix caching을 활성화하거나, SGLang을 쓰면서 TensorRT-LLM 방식의 FP8 양자화를 적용하는 형태다. 엔진 선택보다 워크로드 특성 파악이 먼저다.
소프트웨어 추론 엔진 전쟁의 결론은 아직 나지 않았다. vLLM의 생태계 이점, SGLang의 에이전트 특화, TensorRT-LLM의 하드웨어 최적화는 각각 다른 채택 동기를 가진다. 한국 서비스 환경에서는 KT·네이버·NHN 클라우드의 인프라가 어떤 엔진을 기본 지원하는지가 실질적 선택에 영향을 미친다, 아직 공개된 “권장 엔진” 가이드가 없다는 것이 조사 포인트다.
커스텀 실리콘은 Cerebras IPO가 보여주듯 자본 시장의 베팅을 받고 있지만, 범용 GPU를 대체하기보다 특수 워크로드에서 보완재로 자리잡을 가능성이 더 높다. Etched의 트랜스포머 전용 ASIC 베팅이 10년 뒤에도 유효한지는 아키텍처 진화에 달려 있다.