Skip to content
Published on

AI 추론 엔진 2026 완벽 가이드 - vLLM · SGLang · llama.cpp · TGI · TensorRT-LLM · MLX · mistral.rs · DeepSpeed-MII · Aphrodite 심층 분석

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — 2026년, 추론은 모델보다 비싸다

2023년의 LLM 엔지니어링은 "어떤 모델을 쓰는가"였다. 2026년의 LLM 엔지니어링은 **"그 모델을 어떻게 서빙하는가"**다.

이유는 단순하다. 모델은 한 번 학습하지만, 추론은 매 요청마다 발생한다. 같은 Llama 4 405B를 돌려도, 어떤 엔진을 쓰느냐에 따라 토큰당 비용이 5~10배 차이 난다. H100 1대를 잘 쓰는 팀과 못 쓰는 팀의 처리량 차이는 30배가 넘는다.

GPU는 비싸다. 잘못 쓰면 더 비싸다. 추론 엔진은 GPU의 ROI를 결정한다.

이 글은 2026년 5월 기준 추론 엔진 풍경을 해부한다. vLLM, SGLang, TensorRT-LLM, TGI, llama.cpp, MLX, mistral.rs, DeepSpeed-MII, Aphrodite, CTranslate2, ExLlamaV3, OpenVINO, AWS Neuron, Triton — 그리고 그 밑에 깔린 PagedAttention, Continuous Batching, Speculative Decoding, Disaggregated Inference, KV 양자화 같은 기술들. 마지막으로 한국·일본 추론 인프라와 자가 호스팅 ROI까지.

1장 · 왜 추론이 2026년의 전쟁터인가

2024년 OpenAI의 추론 비용은 학습 비용의 약 3배였다고 알려져 있다. 2026년에는 그 격차가 더 벌어졌다. 학습은 한 번이고, 추론은 영원하다.

추론 비용의 4대 결정 요소:

요소의미영향
TTFT (Time To First Token)첫 토큰까지 걸린 시간UX, 대화형 앱 필수
TPS (Tokens Per Second)초당 출력 토큰생성 속도 체감
Throughput동시 처리 가능 토큰/초GPU당 처리량, 단가
Latency P9999 퍼센타일 응답시간꼬리 지연, SLA

엔진 선택은 이 4가지의 타협이다. 처리량을 올리면 P99가 망가지고, TTFT를 줄이면 TPS가 떨어진다. 추론 엔진의 본질은 이 타협을 어떤 워크로드에 최적화했느냐다.

   ┌────────────────────────────────────────────┐
   │  처리량 (Throughput) ────▶ vLLM, SGLang     │
   │  TTFT 최저            ────▶ TensorRT-LLM    │
   │  로컬·CPU             ────▶ llama.cpp       │
   │  Apple Silicon        ────▶ MLX-LM          │
   │  엣지·양자화          ────▶ Aphrodite        │
   │  프로덕션 wrapper      ────▶ Triton, TGI     │
   │  서버리스/API          ────▶ Together, Fireworks │
   └────────────────────────────────────────────┘

2장 · PagedAttention과 Continuous Batching — 모든 것의 시작

vLLM의 2023년 SOSP 논문 (Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention") 이전과 이후로 추론 세계는 갈렸다.

문제: KV cache는 시퀀스마다 가변 길이다. 연속 메모리를 미리 할당하면 30~80%가 낭비된다 (fragmentation). 짧은 요청과 긴 요청이 섞이면 더 심해진다.

해법: OS의 가상 메모리처럼 KV cache를 고정 크기 페이지로 쪼개고, 페이지 테이블로 매핑한다. 메모리 단편화는 거의 0이 된다.

기존 방식:                     PagedAttention:
[KKKK_____] (50% 낭비)         [P1][P2][P3] (페이지 테이블)
[KKK______] (60% 낭비)         [P4][P5]    (필요할 때만 할당)
[KKKKKKKK_] (10% 낭비)

여기에 Continuous Batching (Orca 논문, 2022)이 붙는다. 전통적 정적 배치는 한 배치 안에서 모든 요청이 끝날 때까지 기다린다. Continuous Batching은 토큰 단위로 새 요청을 배치에 끼워 넣는다 — GPU가 한 순간도 놀지 않는다.

이 두 가지가 2026년 모든 진지한 추론 엔진의 기본이다. 둘이 없으면 시작도 못 한다.

3장 · vLLM — 사실상의 표준

vLLM은 2023년 UC Berkeley Sky Computing Lab에서 시작해 2026년에는 사실상 오픈소스 추론의 기본값이 됐다. 2025년에 LF AI & Data 재단으로 거버넌스가 이관됐다.

vLLM V1 엔진 (0.7+): 2025년 출시된 V1은 V0보다 1.5~2배 빠르고, 비동기 스케줄러, 청크드 프리필, 토치 컴파일 통합, 멀티모달 지원이 기본이 됐다.

주요 기능:

기능설명
Prefix Caching공유 프롬프트의 KV를 캐시 — 시스템 프롬프트 재사용 시 TTFT 90%↓
Speculative DecodingDraft 모델 또는 EAGLE-3로 디코드 2~3배 가속
Chunked Prefill긴 프롬프트를 청크로 쪼개 디코드와 인터리브 — P99 안정화
Tensor Parallelism한 모델을 여러 GPU에 분할 (NVLink 권장)
Pipeline Parallelism레이어를 GPU 간에 분할 — 노드 간 가능
LoRA 멀티 어댑터여러 LoRA를 동시에 서빙
Structured Outputxgrammar/outlines 통합
Guided DecodingJSON 스키마·정규식·문맥자유문법

지원 모델: Llama 3.x/4, Qwen 3, Mistral, DeepSeek V3/R1, Gemma 3, Phi-4, Mixtral, Command-R, GPT-OSS, Granite 등 100개 이상.

전형적인 처리량 (H100 80GB, Llama 3.1 8B FP16):

  • vLLM V1: 약 6,000~8,000 tok/s (배치, 짧은 시퀀스)
  • 단일 요청 디코드: 약 130 tok/s

4장 · SGLang — Prefix와 Structured에 강하다

SGLang은 2024년 LMSYS Org이 발표했고, 2026년 0.4 버전에서 V1 vLLM과 정면 경쟁한다.

핵심 기능:

  • RadixAttention — KV 캐시를 트리로 구성해 prefix 공유를 자동화. 시스템 프롬프트와 few-shot이 많은 워크로드에서 vLLM Prefix Caching보다 빠르다.
  • Structured Output — regex, JSON Schema, EBNF, Choice, gen() DSL 같은 1급 객체. xgrammar 통합으로 거의 무비용.
  • OpenAI Compatible Server — /v1/chat/completions 호환 + /generate 확장.
  • DP Attention — 데이터 패럴렐 어텐션, DeepSeek V3 MLA 최적화.
  • Day-0 모델 지원 — Llama 4, DeepSeek R1, Qwen 3 출시 당일 지원이 관례.

SGLang은 특히 에이전트·RAG처럼 prefix가 많이 겹치는 워크로드에서 빛난다. Anthropic의 Claude API도 내부적으로 SGLang 스타일의 트리 캐시를 쓴다고 알려져 있다 (확인된 사실은 아니지만 구조가 매우 흡사하다).

5장 · TensorRT-LLM — Blackwell·H100의 절대 강자

TensorRT-LLM은 NVIDIA가 직접 만든 폐쇄 소스 (라이브러리 자체는 Apache 2.0이지만 NIM/Triton 통합은 NVIDIA 상용) 추론 엔진이다.

왜 빠른가:

  • TensorRT 런타임을 베이스로 모델을 엔진(plan)으로 컴파일.
  • CUDA 커널을 H100/H200/B100에 맞춰 직접 작성.
  • FP8 (Hopper) / FP4 (Blackwell) 네이티브 지원.
  • In-flight batching, paged KV, speculative decoding (Medusa/EAGLE).

처리량 벤치마크 (Llama 3.1 70B, H100×8 FP8):

  • TensorRT-LLM: 약 13,000~15,000 tok/s
  • vLLM: 약 9,000~11,000 tok/s

차이는 워크로드와 모델에 따라 ±30% 변동한다. Blackwell에서는 FP4 덕분에 격차가 더 커진다.

단점: 엔진 빌드가 무겁고 (모델·시퀀스 길이·배치별 재컴파일), 디버깅이 어렵고, 모델 추가가 NVIDIA의 일정에 묶인다. NIM (NVIDIA Inference Microservices) 으로 패키징해서 컨테이너로 배포하는 게 정석.

6장 · Hugging Face TGI 3.x — Rust로 다시 쓰다

Text Generation Inference (TGI)는 HF의 공식 추론 서버다. HF Inference Endpoints의 백엔드.

TGI 3.x (2025~2026) 변경점:

  • 라우터·런처는 Rust, 모델 실행은 PyTorch.
  • vLLM·TensorRT-LLM 백엔드 선택 가능 — 즉 TGI는 점점 "프론트엔드 + 라우팅 + 멀티 백엔드 오케스트레이션"으로 진화.
  • 3.0 단일 GPU long-context: Llama 3 70B에서 32K 컨텍스트 처리량이 vLLM 대비 13배 빠르다고 HF가 주장 (HF 블로그, 2024-12).
  • gRPC + REST + Messages API.
  • Prefix Caching, Flash Attention 2/3, Paged KV 기본.

장점은 HF 생태계 통합 — transformers, datasets, AutoTrain과 매끄럽게 연결된다. 단점은 vLLM/SGLang보다 절대 처리량은 약간 낮은 편.

7장 · llama.cpp — 한 사람이 만든 우주

llama.cpp는 Georgi Gerganov가 2023년 시작한 순수 C/C++ 추론 엔진이다. 의존성이 없고, 어디서나 빌드된다.

왜 압도적으로 인기인가:

  • CPU만으로도 4비트 양자화 모델이 돌아간다. M2/M3/M4 Mac, Raspberry Pi, Android, iOS, 심지어 WASM에서도.
  • GGUF 포맷 — 모델 메타데이터 + 가중치 + 토크나이저 + 채팅 템플릿을 한 파일에 패킹. 2026년 표준이 됐다.
  • 백엔드: CPU (AVX2/AVX-512/NEON), CUDA, Metal (Apple), Vulkan, SYCL (Intel GPU), HIP (AMD), Kompute.
  • 양자화: Q2_K부터 Q8_0, IQ1_S~IQ4_XS의 importance-aware 양자화, K-quants.
  • ggml — 백엔드 텐서 라이브러리, llama.cpp의 심장.

한계: 단일 GPU에서 prefill 처리량은 vLLM보다 느리고, Continuous Batching은 늦게 추가됐다 (-cb). 그러나 로컬 추론 = llama.cpp라는 공식은 흔들리지 않는다.

Ollama, LM Studio, Jan, GPT4All, Kobold.cpp, text-generation-webui 대부분이 내부적으로 llama.cpp를 쓴다.

8장 · MLX와 MLX-LM — Apple Silicon의 답

MLX는 Apple이 직접 만든 PyTorch 대안이다. Unified Memory를 1급 객체로 다룬다 — CPU와 GPU가 같은 메모리를 본다.

MLX의 차별점:

  • Lazy evaluation + 동적 그래프.
  • M 시리즈의 Neural Engine·Metal·CPU를 자동 라우팅.
  • NumPy 호환 API, PyTorch와 유사한 nn.Module.

MLX-LM: mlx-lm은 Hugging Face Transformers 스타일 인터페이스로 LLM을 돌리고 학습/미세조정까지 지원한다.

왜 중요한가: M3 Ultra Mac Studio 512GB로 Llama 3.1 405B를 4비트로 돌릴 수 있다. 1대로. H100 8장이 필요한 모델을 데스크탑 한 대로. 처리량은 H100 대비 1/5~1/10이지만, 로컬 인퍼런스 시장에서 Apple은 NVIDIA의 유일한 경쟁자다.

비교: llama.cpp Metal 백엔드 vs MLX-LM

  • llama.cpp Metal: 안정적, 양자화 다양, GGUF.
  • MLX-LM: 더 빠른 prefill, 학습 가능, MLX 양자화 (4·8비트).

9장 · mistral.rs — Rust로 쓴 다중 모델 엔진

mistral.rs는 Eric Buehler의 1인 프로젝트로 시작해 2026년에는 진지한 옵션이 됐다.

특징:

  • 순수 Rust, candle/burn 기반.
  • 양자화: GGUF, GGML, ISQ (in-situ quantization, 모델 로드 시 양자화).
  • 다중 모델 동시 서빙 (멀티 어댑터).
  • 비전 모델 지원 (LLaVA, Phi Vision, Llama 3.2 Vision, Pixtral, Qwen2-VL).
  • OpenAI API 호환.
  • CUDA, Metal, Accelerate, MKL 백엔드.

왜 Rust인가: 메모리 안전성, GC 없음, 컨테이너 이미지 작음 (수십 MB), 콜드 스타트 빠름. 서버리스 추론에 잘 어울린다.

llama.cpp와 vLLM의 중간 지점 — llama.cpp만큼 가볍지는 않지만 양자화 모델을 GPU에서 효율적으로 돌리고, vLLM처럼 무겁지도 않다.

10장 · DeepSpeed-MII와 DeepSpeed Inference — Microsoft의 답

DeepSpeed-MII는 Microsoft DeepSpeed 팀의 모델 추론 라이브러리다.

주요 기능:

  • Blocked KV Cache (vLLM PagedAttention 유사).
  • Continuous Batching + Dynamic SplitFuse — 긴 프롬프트를 토큰 단위로 디코드와 인터리브.
  • Tensor Parallelism — DeepSpeed Inference의 핵심.
  • ZeRO-Inference — KV·가중치를 CPU/NVMe로 오프로드. 큰 모델을 작은 GPU에 욱여넣는다.

왜 흥미로운가: DeepSpeed는 학습 프레임워크로 시작했지만 MII는 추론에 특화. Microsoft 내부 (Bing, Copilot) 추론 일부가 MII를 쓴다고 알려져 있다.

단점은 vLLM/SGLang에 비해 모델 지원 폭이 좁고, 개발 속도가 느린 편.

11장 · Aphrodite Engine — vLLM의 양자화 친화 포크

Aphrodite Engine은 PygmalionAI가 vLLM을 포크해서 양자화 친화적으로 개조한 엔진이다.

Aphrodite가 vLLM과 다른 점:

  • 모든 양자화 포맷 지원: GPTQ, AWQ, EXL2, GGUF, SqueezeLLM, Marlin, FP8, FP6, FP5, FP4, AQLM, HQQ.
  • 오래된 GPU 지원이 더 좋다 (Turing/Volta까지).
  • LoRA + 양자화 모델 결합 서빙.
  • 일부 디코딩 샘플러 (DRY, Mirostat, XTC, Smoothing 등) 추가 — 캐릭터 챗 워크로드에 특화.

누가 쓰나: 로컬 호스팅 커뮤니티, 캐릭터 AI 사이트, 양자화 모델을 진지하게 서빙하려는 팀. vLLM이 메인스트림이면 Aphrodite는 양자화 전문점.

12장 · CTranslate2, ExLlamaV3, OpenVINO — 특수 목적 엔진들

CTranslate2 (ctranslate2) — OpenNMT 팀의 C++ 엔진. NMT(번역)와 Transformer 모델에 특화. CPU에서 매우 빠르고, INT8/INT16 양자화 잘 됨. Whisper.cpp의 빠른 변형 faster-whisper가 CTranslate2 위에 만들어져 있다.

ExLlamaV3 (exllamav3) — turboderp의 NVIDIA Turing+ 최적화 엔진. EXL3 양자화 포맷이 EXL2를 잇는다. 4비트 모델을 가장 작은 메모리에 욱여넣는 데 강함. text-generation-webui의 기본 백엔드 중 하나.

OpenVINO (openvino) + Intel Neural Compressor — Intel CPU/GPU/NPU 추론. Intel Arc, Core Ultra의 NPU를 활용. ONNX 모델 변환, INT8/INT4 양자화. 데이터센터 Xeon이나 Lunar Lake 노트북에서 LLM 돌릴 때.

AWS Inferentia + Neuron SDK — AWS 인퍼런스 전용 칩 Inf2/Trn2. Neuron SDK로 PyTorch 모델을 컴파일해 Inferentia 위에서 돌린다. Llama 3 405B 같은 큰 모델도 Trn2 UltraServer로 서빙. SageMaker 통합. AWS 환경에서 GPU보다 비용·소비전력 우위.

13장 · Triton Inference Server — 프로덕션 wrapper

Triton는 NVIDIA의 범용 추론 서버다. LLM 전용이 아니라 **모든 모델 (CNN, BERT, XGBoost, TensorRT-LLM, vLLM)**을 한 인터페이스로 서빙한다.

Triton의 역할:

  • 백엔드 추상화 — TensorRT-LLM, vLLM, ONNX, Python, PyTorch를 같은 Triton 서버 안에서.
  • 모델 앙상블 — 토크나이저 → 모델 → 후처리를 파이프라인으로.
  • 동적 배칭 — 모델 단위 배칭 정책.
  • 메트릭 (Prometheus, OpenTelemetry).
  • A/B 테스트, 카나리, 모델 버저닝.

NVIDIA NIM은 사실상 "Triton + TensorRT-LLM + 컨테이너 + Helm chart" 패키지다.

14장 · 양자화 포맷의 동물원

추론 엔진 선택은 양자화 포맷 호환성 문제와 떼어놓을 수 없다.

포맷비트주 엔진특징
FP16/BF1616모두기준점, 손실 거의 없음
FP8 (E4M3/E5M2)8TensorRT-LLM, vLLMH100/H200 네이티브
FP4 (E2M1)4TensorRT-LLM (Blackwell)B100/B200 네이티브
MXFP44TensorRT-LLM마이크로블록 FP4
GGUF2~8llama.cpp, mistral.rs, Aphrodite로컬 표준
GPTQ4vLLM, TGI, Aphroditecalibration-based, 빠름
AWQ4vLLM, TGI, Aphroditeactivation-aware, 정확
EXL2/EXL31.5~8ExLlama가변 비트, NVIDIA 전용
EETQ4TGITensor-Wise INT4
BitNet 1.581.58bitnet.cpp삼진법 (-1,0,1)
HQQ2~8Aphrodite, transformerscalibration-free
AQLM2Aphrodite2비트 극한 압축

규칙: Llama 3 70B를 4비트로 양자화하면 약 40GB → 약 20GB. RTX 3090 (24GB) 한 장에 들어간다. 5비트면 25GB로 안 들어간다. VRAM 한계를 알고 양자화를 선택해야 한다.

15장 · KV Cache 관리 — 두 번째 메모리 전쟁

KV 캐시는 모델 가중치 다음의 메모리 잡아먹는 괴물이다. Llama 3 70B에서 컨텍스트 128K면 KV 캐시만 약 40GB.

KV 양자화 기법:

기법설명
FP8 KVKV 캐시를 FP8로 저장 — vLLM, TensorRT-LLM 기본
INT8 KV더 적극적인 압축, 약간의 손실
KIVI2비트 KV (asymmetric) — 학술적
Quantized KV (vLLM)사용자 지정 kv_cache_dtype=fp8_e4m3
Paged KVPagedAttention으로 단편화 제거 (이전 장)
Prefix Cache공유 prefix의 KV 재사용
Sliding Window윈도우 밖 토큰의 KV 폐기 (Mistral 등)
CompressedH2O, SnapKV 같은 핵심 토큰 선택

2026년에 추론 비용을 정말 줄이려면 FP8 KV + Prefix Cache + Sliding Window가 사실상 필수다.

16장 · Speculative Decoding — 디코드를 2~3배

디코드 단계는 메모리 바운드다 — GPU 연산력이 남는다. Speculative Decoding은 그 잉여를 활용한다.

아이디어: 작은 "draft" 모델이 N토큰을 빠르게 추측 → 큰 "target" 모델이 N토큰을 한 번에 검증 → 일치하는 부분 채택, 불일치는 폐기.

주요 변형:

방법설명가속
Draft+Target별도 작은 모델 사용 (예: Llama 3 8B + Llama 3 70B)2~3배
Medusa모델에 여러 LM head를 추가2배
EAGLE / EAGLE-2 / EAGLE-3feature-level draft, 더 높은 적중률3~4배
Lookaheadn-gram 기반 self-speculation1.5~2배
Prompt Lookup입력에서 토큰 복사로 추측코드·요약에서 강함
ReDrafterNVIDIA의 RNN draft2~3배

vLLM, SGLang, TensorRT-LLM 모두 EAGLE-3를 지원한다 (2025~2026 기준). 적중률이 80% 이상이면 디코드가 3배 가까이 빨라진다.

17장 · Disaggregated Inference — Prefill과 Decode를 분리하라

2024~2026년의 가장 큰 아키텍처 변화다.

문제: Prefill은 compute-bound, Decode는 memory-bound. 같은 GPU에서 섞으면 둘 다 비효율적이다. Continuous Batching이 어느 정도 해결하지만 P99가 흔들린다.

해법: Prefill 클러스터와 Decode 클러스터를 물리적으로 분리. Prefill GPU가 KV를 생성하고, 빠른 네트워크 (RDMA/NVLink/InfiniBand)로 Decode GPU로 전송. Decode GPU는 디코드만 한다.

대표 시스템:

  • Mooncake (Moonshot AI / Kimi) — KV 캐시를 별도 분산 캐시로 분리.
  • Splitwise (Microsoft Research) — Hopper와 Ampere를 역할별로 섞어 쓴다.
  • vLLM Disaggregated Prefill — V1에 실험적 지원.
  • NVIDIA Dynamo (2025) — NVIDIA의 disaggregated 서빙 프레임워크.

왜 가치가 있나: Prefill GPU는 H100, Decode GPU는 더 싼 L40S/A10을 쓸 수 있다. GPU 종류를 워크로드에 맞춰 섞을 수 있다. 큰 규모 운영에서 비용 30~50% 절감 보고가 있다.

18장 · NVIDIA NIM, Triton, Dynamo — 엔터프라이즈 스택

NIM (NVIDIA Inference Microservices): 사실상 "TensorRT-LLM + Triton + 모델 가중치"를 하나의 컨테이너로 패키징한 것. 한 줄 docker run으로 OpenAI API 호환 서버가 뜬다. NVIDIA AI Enterprise 라이선스 필요. Azure, AWS, GCP 마켓플레이스에 등재.

NVIDIA Dynamo (2025): Triton의 차세대. Disaggregated inference, KV 캐시 라우팅, GPU 풀 관리를 1급 객체로. 오픈소스 (Apache 2.0).

왜 중요한가: 엔터프라이즈 고객이 "Llama 4를 H100 클러스터에 깔아 달라"고 하면 답은 보통 NIM이다. 직접 vLLM 운영을 원하지 않는 경우가 많다.

19장 · Ollama, LM Studio, Jan — 데스크탑 추론

Ollama (ollama) — Go로 만든 llama.cpp wrapper. ollama run llama4 한 줄로 모델 다운로드 + 실행. macOS/Linux/Windows 데스크탑에서 가장 인기. 모델 레지스트리는 ollama.com.

LM Studio — Electron GUI, llama.cpp + MLX 백엔드. 일반 사용자 대상, OpenAI API 서버 내장.

Jan — 완전 오픈소스 ChatGPT 대체, llama.cpp/Tabby/원격 API 백엔드. 프라이버시 중심.

GPT4All, Kobold.cpp, text-generation-webui — 각자 카테고리 (개인용/캐릭터/연구).

공통점: 거의 모두 내부적으로 llama.cpp 또는 MLX다. GUI와 모델 관리, 채팅 인터페이스가 차별점.

20장 · 대안 하드웨어 — Groq, Cerebras, SambaNova

NVIDIA 독점을 깨려는 시도들. 2026년에 진짜 의미 있는 처리량을 내는 곳:

Groq LPU (groq.com) — Language Processing Unit. SRAM 14MB가 칩 안에 있고, HBM이 없다. 결과: Llama 3 70B에서 약 500 tok/s 단일 요청 디코드. NVIDIA의 5~10배. 단점은 컨텍스트 길이 한계와 모델 풀의 좁음.

Cerebras CS-3 (cerebras.ai) — 웨이퍼 한 장이 칩 한 개. 850K AI 코어. Llama 3 70B에서 약 450 tok/s. API로만 접근.

SambaNova SN40L (sambanova.ai) — Reconfigurable Dataflow Unit. Llama 3.1 405B를 단일 노드로 서빙 가능. API와 온프렘 어플라이언스.

이들은 속도가 절대 가치인 워크로드(실시간 음성, 코드 자동완성, 다단계 에이전트)에서 NVIDIA를 이긴다. 처리량 단위 비용은 여전히 NVIDIA가 우위.

21장 · 추론 API 가격 — 자가 호스팅 결정선

자가 호스팅 vs API의 갈림길에서 가격이 결정 변수다. 2026년 5월 대략적인 단가 (USD per million tokens, 출력 기준):

제공자모델가격대
Together.aiLlama 3.1 70B약 0.88/M
FireworksLlama 3.1 70B약 0.90/M
DeepInfraLlama 3.1 70B약 0.60/M
ReplicateLlama 3.1 70B약 2.75/M
AnyscaleLlama 3.1 70B약 1.00/M
GroqLlama 3 70B약 0.79/M (속도 프리미엄)
SambaNovaLlama 3.1 405B약 5/M
AWS BedrockClaude 3.5 Sonnet약 15/M (참고)

(가격 표기에서 $ 기호와 숫자 페어 패턴을 피해 약 0.88/M 형식으로 적었다. MDX의 LaTeX 인식과 충돌하지 않게.)

자가 호스팅이 더 싸지는 조건: 일 평균 처리량이 GPU 1대 capacity의 30% 이상 + 24/7 운영. 그 미만이면 API가 거의 항상 싸다.

22장 · 자가 호스팅 ROI — H100 vs H200

대략적 시나리오 (북미 시세, 2026년 5월):

  • H100 80GB 1년 임대: 약 25,000~32,000/년 (대량 할인 전)
  • H200 141GB 1년 임대: 약 35,000~45,000/년
  • B200: 약 60,000~80,000/년 (소량 가용)

Llama 3.1 70B FP8을 H100×4에 vLLM으로 서빙한다고 가정:

  • 처리량: 약 9,000 tok/s 지속.
  • 일일 토큰: 약 7.8억 tok.
  • 월 토큰: 약 230억 tok = 23,000M.
  • 월 비용 (4×H100×730시간×약 3.5/h): 약 10,000.
  • 토큰당 비용: 약 0.43/M.

같은 워크로드를 API로 사면 (Llama 3.1 70B at 약 0.88/M): 23,000M × 약 0.88 = 약 20,000/월. 자가 호스팅이 절반.

단, 이 계산은 GPU가 24/7 풀 사용된다는 가정. 50% 사용률이면 비용 우위가 사라진다.

H200/B200의 효과: HBM이 96GB→141GB→192GB로 커지면서 더 큰 모델을 적은 노드로 서빙. KV 캐시도 더 많이 들어가서 처리량이 1.3~1.8배. 단위 비용은 더 떨어진다.

23장 · 한국 추론 인프라

Naver Cloud HyperCLOVA X Inference — 자체 모델 HyperCLOVA X의 사내·외부 추론. 자체 데이터센터 (춘천, 세종)에서 H100/H200 클러스터 운영. 2025년부터 외부 API 개방 (Naver Cloud Platform).

Kakao i Cloud — Kakao의 LLM 인프라. 한국어 특화 LLM 추론과 멀티모달 (KoCLIP, KaLM).

Upstage (upstage.ai) — Solar 모델 시리즈, Predibase 협업으로 fine-tuning + 서빙, AWS Foundry 인증 받은 한국 회사. Document AI 워크플로우 강함.

Lablup Backend.AI (lablup.com) — GPU 클러스터 관리 + 추론 서빙 플랫폼. vLLM/TGI/Triton을 GUI로 운영. 정부·대기업 온프렘 GPU 클러스터에 다수 도입.

KT Cloud GPU Farm — 5G·AI 통합, NVIDIA H100 클러스터.

SK Telecom AI Pyramid — 자체 LLM 'A.X' 추론, 일본 라쿠텐 등과 협업.

42dot — 현대차 그룹 자율주행 + LLM, 자체 GPU 인프라.

24장 · 일본 추론 인프라

Sakana AI (sakana.ai) — 도쿄 기반 AI 스타트업. Evolutionary Model Merging으로 작은 모델 다수 결합. 자체 추론 서비스 제공 중.

Preferred Networks (PFN) (preferred.jp) — MN-Core 가속기 자체 개발, PLaMo 일본어 LLM 시리즈, 자체 데이터센터 추론.

SoftBank — Stargate Japan 데이터센터에 NVIDIA GPU 다량 투자, Cristal Intelligence (OpenAI 협업) 추론 워크로드.

Rakuten — Rakuten AI 2.0 (Mixtral 기반), Mistral과 협업, AWS Inferentia/Trainium 활용.

LINE Yahoo — 일본 최대 메신저, Yahoo 검색 + AI에 자체 LLM Inference (Llama 기반 + 자체 학습) 운영.

NTT — tsuzumi 모델 (1B~10B, 일본어 효율), 자사 클라우드에서 추론 제공.

25장 · 워크로드별 엔진 선택 가이드

워크로드추천 엔진이유
일반 챗봇 (오픈소스 70B)vLLM표준, 잘 작동
에이전트·RAG (긴 prefix)SGLangRadixAttention 트리 캐시
최저 TTFT (음성·실시간)TensorRT-LLM 또는 Groq컴파일 최적화
Mac에서 개발MLX-LM 또는 llama.cppUnified Memory
로컬 서버 (RTX 3090×1)llama.cpp 또는 Aphrodite4비트 양자화
큰 모델 + 적은 GPUDeepSpeed-MII + ZeRO InferenceNVMe 오프로드
HF 생태계 통합TGIInference Endpoints 동일
멀티모델 + A/B 테스트Triton + vLLM모델 앙상블·버저닝
Apple Silicon (개인)Ollama (llama.cpp)가장 쉬움
양자화 다양성Aphrodite모든 포맷
클라우드 서버리스Together.ai / FireworksAPI
AWS 환경Bedrock 또는 InferentiaNeuron SDK
절대 속도Groq / Cerebras특수 하드웨어
일본어NTT tsuzumi 또는 PLaMo토크나이저
한국어HyperCLOVA X 또는 Solar토크나이저

26장 · 결론 — 엔진은 워크로드에 의해 결정된다

2026년 5월의 결론은 명료하다:

  1. 단일 정답 엔진은 없다. 워크로드가 엔진을 결정한다.
  2. vLLM은 안전한 기본값. 어디서나 작동하고, 가장 큰 커뮤니티. SGLang은 prefix가 많을 때, TensorRT-LLM은 절대 처리량이 필요할 때.
  3. 로컬 = llama.cpp 또는 MLX. 다른 선택은 없다.
  4. 양자화는 필수. FP16으로 70B를 서빙하는 시대는 끝났다.
  5. KV 관리·Speculative Decoding·Disaggregation이 비용을 결정한다. 모델 선택보다 더.
  6. 자가 호스팅 ROI는 활용률이 결정한다. 30% 미만이면 API가 답.
  7. NVIDIA 아닌 대안(Groq, Cerebras, AWS Inferentia, Apple Silicon)이 진짜로 의미 있는 시장 점유를 갖기 시작했다.

다음 단계: 워크로드 측정 → 엔진 후보 3개 벤치마크 → P99·비용 모두 SLA 안 → 운영 시작. 추측 말고 측정.

27장 · 참고 자료

Discuss on Twitter • View on GitHub