추론 엔진 아키텍처 전쟁 — 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). 하지만 이 둘은 경쟁 관계가 아니다 — 각각 다른 병목을 겨냥한다. 어떤 병목을, 어떻게 풀었는지를 아는 것이 실무 선택의 기준이 된다.

목차

1. KV 캐시 전략이 처리량을 결정한다
2. vLLM — PagedAttention: 운영체제에서 배운 방식
3. SGLang — RadixAttention: 반복 컨텍스트를 캐싱한다
4. TensorRT-LLM — Hopper 전용 컴파일러
5. 엔진별 처리량 비교 및 선택 기준
6. 커스텀 실리콘: 각각 어떤 병목을 해결하는가
7. Gimlet Labs: 이종 칩 통합 레이어
8. 의사결정 가이드

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, 배치 추론)

수치는 단일 H100 80GB 기준. 워크로드 특성에 따라 변동.

워크로드별 선택 기준

커스텀 실리콘: 각각 어떤 병목을 해결하는가

소프트웨어 엔진이 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년 뒤에도 유효한지는 아키텍처 진화에 달려 있다.

참고

• AI Startup Funding News May 2026
• CNBC: Bret Taylor’s Sierra raises nearly $1B
• vLLM Documentation: PagedAttention
• SGLang: Efficient Execution of Structured Language Model Programs
• NVIDIA TensorRT-LLM Documentation
• Etched: Transformer-Dedicated ASIC
• Groq: Language Processing Unit Architecture