Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 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 P99 | 99 퍼센타일 응답시간 | 꼬리 지연, 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](https://github.com/vllm-project/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 Decoding | Draft 모델 또는 EAGLE-3로 디코드 2~3배 가속 |

| Chunked Prefill | 긴 프롬프트를 청크로 쪼개 디코드와 인터리브 — P99 안정화 |

| Tensor Parallelism | 한 모델을 여러 GPU에 분할 (NVLink 권장) |

| Pipeline Parallelism | 레이어를 GPU 간에 분할 — 노드 간 가능 |

| LoRA 멀티 어댑터 | 여러 LoRA를 동시에 서빙 |

| Structured Output | xgrammar/outlines 통합 |

| Guided Decoding | JSON 스키마·정규식·문맥자유문법 |

지원 모델: 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](https://github.com/sgl-project/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](https://github.com/NVIDIA/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](https://github.com/huggingface/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](https://github.com/ggml-org/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](https://github.com/ml-explore/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](https://github.com/ml-explore/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](https://github.com/EricLBuehler/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](https://github.com/deepspeedai/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](https://github.com/aphrodite-engine/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](https://github.com/OpenNMT/CTranslate2)) — OpenNMT 팀의 C++ 엔진. NMT(번역)와 Transformer 모델에 특화. CPU에서 매우 빠르고, INT8/INT16 양자화 잘 됨. Whisper.cpp의 빠른 변형 `faster-whisper`가 CTranslate2 위에 만들어져 있다.

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

**OpenVINO** ([openvino](https://github.com/openvinotoolkit/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](https://github.com/triton-inference-server/server)는 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/BF16 | 16 | 모두 | 기준점, 손실 거의 없음 |

| AWQ | 4 | vLLM, TGI, Aphrodite | activation-aware, 정확 |

| EETQ | 4 | TGI | Tensor-Wise INT4 |

| BitNet 1.58 | 1.58 | bitnet.cpp | 삼진법 (-1,0,1) |

| HQQ | 2~8 | Aphrodite, transformers | calibration-free |

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

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

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

**KV 양자화 기법:**

| 기법 | 설명 |

| --- | --- |

| FP8 KV | KV 캐시를 FP8로 저장 — vLLM, TensorRT-LLM 기본 |

| INT8 KV | 더 적극적인 압축, 약간의 손실 |

| KIVI | 2비트 KV (asymmetric) — 학술적 |

| Quantized KV (vLLM) | 사용자 지정 `kv_cache_dtype=fp8_e4m3` |

| Paged KV | PagedAttention으로 단편화 제거 (이전 장) |

| Prefix Cache | 공유 prefix의 KV 재사용 |

| Sliding Window | 윈도우 밖 토큰의 KV 폐기 (Mistral 등) |

| Compressed | H2O, 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-3 | feature-level draft, 더 높은 적중률 | 3~4배 |

| Lookahead | n-gram 기반 self-speculation | 1.5~2배 |

| Prompt Lookup | 입력에서 토큰 복사로 추측 | 코드·요약에서 강함 |

| ReDrafter | NVIDIA의 RNN draft | 2~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](https://github.com/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](https://groq.com)) — Language Processing Unit. SRAM 14MB가 칩 안에 있고, HBM이 없다. 결과: **Llama 3 70B에서 약 500 tok/s 단일 요청 디코드**. NVIDIA의 5~10배. 단점은 컨텍스트 길이 한계와 모델 풀의 좁음.

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

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

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

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

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

| 제공자 | 모델 | 가격대 |

| --- | --- | --- |

| Together.ai | Llama 3.1 70B | 약 0.88/M |

| Fireworks | Llama 3.1 70B | 약 0.90/M |

| DeepInfra | Llama 3.1 70B | 약 0.60/M |

| Replicate | Llama 3.1 70B | 약 2.75/M |

| Anyscale | Llama 3.1 70B | 약 1.00/M |

| Groq | Llama 3 70B | 약 0.79/M (속도 프리미엄) |

| SambaNova | Llama 3.1 405B | 약 5/M |

| AWS Bedrock | Claude 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](https://www.upstage.ai)) — Solar 모델 시리즈, **Predibase** 협업으로 fine-tuning + 서빙, **AWS Foundry** 인증 받은 한국 회사. Document AI 워크플로우 강함.

**Lablup Backend.AI** ([lablup.com](https://www.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](https://sakana.ai)) — 도쿄 기반 AI 스타트업. Evolutionary Model Merging으로 작은 모델 다수 결합. 자체 추론 서비스 제공 중.

**Preferred Networks (PFN)** ([preferred.jp](https://www.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) | SGLang | RadixAttention 트리 캐시 |

| 최저 TTFT (음성·실시간) | TensorRT-LLM 또는 Groq | 컴파일 최적화 |

| Mac에서 개발 | MLX-LM 또는 llama.cpp | Unified Memory |

| 로컬 서버 (RTX 3090×1) | llama.cpp 또는 Aphrodite | 4비트 양자화 |

| 큰 모델 + 적은 GPU | DeepSpeed-MII + ZeRO Inference | NVMe 오프로드 |

| HF 생태계 통합 | TGI | Inference Endpoints 동일 |

| 멀티모델 + A/B 테스트 | Triton + vLLM | 모델 앙상블·버저닝 |

| Apple Silicon (개인) | Ollama (llama.cpp) | 가장 쉬움 |

| 양자화 다양성 | Aphrodite | 모든 포맷 |

| 클라우드 서버리스 | Together.ai / Fireworks | API |

| AWS 환경 | Bedrock 또는 Inferentia | Neuron 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장 · 참고 자료

- vLLM: https://github.com/vllm-project/vllm

- vLLM 논문 (PagedAttention, SOSP 2023): https://arxiv.org/abs/2309.06180

- SGLang: https://github.com/sgl-project/sglang

- SGLang 블로그 (RadixAttention): https://lmsys.org/blog/2024-01-17-sglang/

- TensorRT-LLM: https://github.com/NVIDIA/TensorRT-LLM

- Hugging Face TGI: https://github.com/huggingface/text-generation-inference

- TGI 3.0 long context blog: https://huggingface.co/blog/tgi-v3-overview

- llama.cpp: https://github.com/ggml-org/llama.cpp

- ggml: https://github.com/ggml-org/ggml

- MLX: https://github.com/ml-explore/mlx

- MLX-LM: https://github.com/ml-explore/mlx-lm

- mistral.rs: https://github.com/EricLBuehler/mistral.rs

- DeepSpeed-MII: https://github.com/deepspeedai/DeepSpeed-MII

- Aphrodite Engine: https://github.com/aphrodite-engine/aphrodite-engine

- CTranslate2: https://github.com/OpenNMT/CTranslate2

- ExLlamaV3: https://github.com/turboderp-org/exllamav3

- OpenVINO: https://github.com/openvinotoolkit/openvino

- AWS Neuron SDK: https://github.com/aws-neuron/aws-neuron-sdk

- Triton Inference Server: https://github.com/triton-inference-server/server

- NVIDIA Dynamo: https://github.com/ai-dynamo/dynamo

- Mooncake paper: https://arxiv.org/abs/2407.00079

- Splitwise paper: https://arxiv.org/abs/2311.18677

- EAGLE-3 paper: https://arxiv.org/abs/2503.01840

- BitNet b1.58 paper: https://arxiv.org/abs/2402.17764

- Orca (continuous batching): https://www.usenix.org/conference/osdi22/presentation/yu

- Ollama: https://github.com/ollama/ollama

- LM Studio: https://lmstudio.ai

- Jan: https://github.com/janhq/jan

- Groq: https://groq.com

- Cerebras: https://cerebras.ai

- SambaNova: https://sambanova.ai

- Sakana AI: https://sakana.ai

- Preferred Networks: https://www.preferred.jp

- Upstage: https://www.upstage.ai

- Lablup Backend.AI: https://www.lablup.com