프롤로그 — "모델을 어디서 돌리느냐"가 다시 중요해졌다

2023년에는 모두가 OpenAI API를 썼다. 2024년에는 Anthropic·Google·Mistral이 들어오고, "어떤 API"를 쓰느냐가 질문이었다. 2025년부터는 다시 **"어디서 돌리느냐"** 가 질문이 됐다. 모델 사이즈가 작아지고(8B·30B·70B), 양자화가 좋아지고(Q4_K_M으로도 쓸 만하다), 노트북에 200GB 메모리가 꽂히고(M4 Max 128GB·M3 Ultra 192GB), 클라우드 토큰 가격이 들쭉날쭉해지면서, 같은 모델을 **API·전용 서빙·로컬** 어디서 굴릴지가 곧 비용·지연·거버넌스를 결정한다.

문제는 **선택지가 너무 많아졌다**는 것이다. vLLM·SGLang·TGI·llama.cpp·MLX·llamafile·Ollama·LM Studio·GPT4All·KTransformers·MLC LLM·Triton·TensorRT-LLM·Modular MAX — 각자 다른 결을 갖고, 다른 워크로드에 맞고, 서로 겹치기도 한다. 게다가 클라우드 쪽에선 Together·Fireworks·Groq·Cerebras·SambaNova·Lepton(NVIDIA가 2025년 인수)이 "API만 부르고 알아서 잘 돌려준다"는 결로 들어왔다.

이 글은 2026년 5월 기준 그 지도를 그린다. 누가 무엇을 잘 하고, 어떤 워크로드에 어떤 진영이 맞는지, 그리고 한국·일본 모델 생태계와 어떻게 만나는지까지.

1장 · 2026년 LLM 서빙 지도 — 3 진영

먼저 큰 그림. 2026년 LLM 서빙·추론 시장은 대략 **3 진영**으로 나뉜다.

진영 A · 데이터센터 / 고처리량 서빙

엔터프라이즈·SaaS·연구실의 production 서빙. 수십~수천 RPS, 다중 사용자, GPU 클러스터.

- **vLLM** — PagedAttention의 사실상 표준

- **SGLang** — 구조적 생성과 RadixAttention

- **TGI(Text Generation Inference)** — Hugging Face의 운영 친화 서버

- **NVIDIA Triton + TensorRT-LLM** — NVIDIA 생태계 풀스택

- **Modular MAX** — Mojo 팀의 새 진영

- **KTransformers** — long-context·MoE 최적

진영 B · 로컬 / 단일 사용자

노트북·워크스테이션·홈서버. 1 RPS 미만, 단일 사용자, 프라이버시.

- **llama.cpp** — C++ 코어, GGUF 포맷, CPU/GPU 양수겸장

- **MLX (Apple)** — Apple Silicon 전용

- **llamafile (Mozilla)** — 단일 실행 바이너리

- **Ollama** — llama.cpp를 감싼 가장 쉬운 로컬 LLM

- **LM Studio** — GUI 우선 로컬

- **GPT4All** — 커뮤니티·desktop chat

- **MLC LLM** — 모바일·웹 GPU·다양한 하드웨어

진영 C · 클라우드 서빙 SaaS

"모델만 골라서 API 부르기" — 자체 GPU 운용 부담 없음.

- **Together AI** — OSS 모델 호스팅의 큰 형

- **Fireworks AI** — 빠른 throughput, 커스텀 fine-tune 지원

- **Groq** — LPU(Language Processing Unit) 자체 칩, 초저지연

- **Cerebras** — Wafer-scale 엔진, 거대 단일 칩

- **SambaNova** — RDU 자체 칩

- **Lepton AI** — 2025년 NVIDIA 인수, NVIDIA 생태계 통합

각 진영은 **다른 가정** 아래에서 만들어졌다. 데이터센터는 "GPU가 비싸니 활용률을 짜내자", 로컬은 "내 노트북에서 돌아가게 하자", 클라우드 SaaS는 "GPU 운영 신경 끄고 토큰 단가만 보자". 그래서 같은 문제처럼 보여도 잘 푸는 사람이 다 다르다.

2장 · vLLM — PagedAttention의 표준

**vLLM**은 UC Berkeley(Sky Computing Lab)에서 2023년 시작한 OSS 추론 서버다. 2024년 vLLM Project로 독립했고, 2025년부터는 Linux Foundation 산하 PyTorch Foundation에 합류하면서 **OSS LLM 서빙의 사실상 기준**이 됐다.

핵심 발명은 **PagedAttention**. KV cache를 OS의 페이지 테이블처럼 블록 단위로 관리해서 메모리 단편화를 없애고, 다수 요청의 KV cache를 같은 GPU에 같이 태울 수 있게 만든 게 출발점이다. 결과적으로 같은 GPU에서 단순 batching 대비 2~4배 throughput이 흔히 나온다.

2026년 vLLM의 현재 모습:

- **continuous batching** — 요청이 다른 토큰 길이에 있어도 같은 batch에 같이 들어간다.

- **prefix caching** — 같은 system prompt·few-shot이 반복되면 KV를 재사용.

- **speculative decoding** — draft model로 미리 토큰을 예측하고 검증.

- **chunked prefill** — 긴 prefill을 잘게 쪼개 decode와 같이 진행.

- **disaggregated serving** — prefill과 decode를 다른 GPU에 분리(P/D split).

- **multi-modal** — vision-language 모델도 1급 시민.

- **tool use·structured output** — 함수 호출과 JSON 스키마 강제.

전형적인 vLLM 서빙:

pip install vllm

vllm serve meta-llama/Llama-3.3-70B-Instruct \

--tensor-parallel-size 4 \

--max-model-len 32768 \

--enable-prefix-caching \

--enable-chunked-prefill

이러면 OpenAI 호환 HTTP 서버가 8000 포트에 뜨고, 클라이언트는 OpenAI SDK 그대로 쓰면 된다.

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

resp = client.chat.completions.create(

model="meta-llama/Llama-3.3-70B-Instruct",

messages=[{"role": "user", "content": "안녕"}],

)

print(resp.choices[0].message.content)

언제 vLLM: 다중 사용자 production 서빙, OSS 모델, NVIDIA(또는 AMD ROCm·Intel Gaudi·TPU) GPU 가용, throughput과 비용 효율이 우선. 단일 사용자 노트북이라면 오버킬.

3장 · llama.cpp — gguf, CPU/GPU 양수겸장

**llama.cpp**는 Georgi Gerganov가 2023년 시작한 C/C++ 추론 엔진이다. "외부 의존 없이 한 바이너리로 LLM을 돌리자"는 야망에서 출발해, 2026년에는 **로컬·임베디드 LLM 추론의 베이스 레이어**가 됐다. Ollama·LM Studio·llamafile·GPT4All 같은 사용자 친화 도구들이 거의 다 llama.cpp를 내부에서 쓴다.

핵심 결:

- **CPU 추론이 진짜로 쓸 만하다** — AVX/AVX2/AVX-512·ARM NEON 최적, M 시리즈에선 Metal·Accelerate까지.

- **GPU 백엔드 풍부** — CUDA·Metal·Vulkan·SYCL·OpenCL·ROCm·Kompute. Vulkan이 들어가면서 사실상 거의 모든 현대 GPU에서 돈다.

- **GGUF 포맷** — `Q4_K_M`·`Q5_K_M`·`Q8_0`·`IQ3_XXS` 등 다양한 양자화 단계, 한 파일에 가중치·메타데이터·tokenizer가 다 들어감.

- **메모리 매핑 로딩** — 모델 파일을 mmap으로 읽어 cold start가 빠르고, 같은 모델을 여러 프로세스가 공유 가능.

`llama-server`로 OpenAI 호환 서버를 띄울 수 있다.

./llama-server \

--model models/Llama-3.3-70B-Q4_K_M.gguf \

--n-gpu-layers 99 \

--ctx-size 8192 \

--host 0.0.0.0 --port 8080

2026년 llama.cpp의 강점·약점:

- 강점: 어디서나 돈다, 양자화의 표준 GGUF가 풍성하다, 의존성이 거의 없다(C++만), 모바일·임베디드에도 들어간다, 커뮤니티가 양자화 포맷·perf 패치를 빠르게 낸다.

- 약점: 다중 사용자 throughput에선 vLLM/SGLang에 밀린다(요청 batching이 후발·단순), MoE·long-context 최적은 KTransformers/vLLM이 더 빠르다.

언제 llama.cpp: 개인·소수 사용자 로컬, 임베디드/엣지, GGUF 양자화 활용, "한 바이너리로 끝내고 싶다"는 결.

4장 · MLX (Apple) — Apple Silicon 추론

**MLX**는 2023년 12월 Apple ML Research가 공개한 OSS 배열·머신러닝 프레임워크다. NumPy + PyTorch와 비슷한 API를 갖고, **Apple Silicon의 unified memory를 1급 시민으로 다룬다**. M1/M2/M3/M4 시리즈에서 CPU와 GPU가 같은 메모리를 보고, MLX는 그 위에서 데이터 복사 없이 연산을 흘려보낸다.

2026년 MLX의 현재 모습:

- **mlx-lm** — Hugging Face Hub의 모델을 한 줄로 받아 추론·fine-tune.

- **MoE·long-context 가속** — Mistral·Qwen·Llama 계열 MoE 모델이 빠르게 돈다.

- **양자화** — 4-bit·8-bit·6-bit·grouped quantization 내장.

- **분산** — 여러 Mac을 묶어 큰 모델을 추론(MLX distributed). M3 Ultra 192GB 두 대로 405B 모델을 돌리는 식.

- **mlx-vlm** — vision-language 모델 지원.

전형적인 MLX 사용:

pip install mlx mlx-lm

mlx_lm.generate \

--model mlx-community/Llama-3.3-70B-Instruct-4bit \

--prompt "Apple Silicon에서 LLM을 돌리는 이유는" \

--max-tokens 200

Python에서 직접:

from mlx_lm import load, generate

model, tokenizer = load("mlx-community/Llama-3.3-70B-Instruct-4bit")

text = generate(model, tokenizer, prompt="안녕", max_tokens=200)

print(text)

왜 MLX가 점점 중요한가:

- **M3 Ultra 192GB·M4 Max 128GB**가 70B~405B 모델을 양자화 후 들어가는 노트북·데스크톱으로 자리잡았다. NVIDIA H100 80GB 한 장으로 안 들어가는 모델도 unified memory가 들어간다.

- **개발자 노트북에서 prototype → 서버로 이주** — MLX로 만들고, 같은 GGUF나 다른 포맷으로 vLLM/llama.cpp 서버에 올리는 워크플로우가 흔해졌다.

- **fine-tune이 가능** — LoRA/QLoRA가 Apple Silicon에서 돈다. CUDA 없이 fine-tune이 진짜 된다.

약점: Apple Silicon 전용. 다중 사용자 서빙은 vLLM만큼 매끈하지 않다.

언제 MLX: Mac에서 로컬 LLM 개발·fine-tune·prototype, M-series 노트북·데스크톱에 묶인 워크로드.

5장 · llamafile (Mozilla) — 단일 바이너리

**llamafile**은 2023년 11월 Mozilla(Mozilla Innovation Group)가 공개한 프로젝트다. 핵심 아이디어: **모델 가중치 + 추론 엔진 + tokenizer를 하나의 실행 파일에 묶어, 어떤 OS·CPU 아키텍처에서도 더블 클릭으로 도는 LLM**을 만든다.

기술적 트릭은 Justine Tunney(같은 사람이 Cosmopolitan libc를 만들었다)가 짠 **Actually Portable Executable(APE)** 포맷이다. 한 파일이 Linux·macOS·Windows·FreeBSD·OpenBSD·NetBSD에서 ELF·Mach-O·PE로 동시에 동작한다. 거기에 llama.cpp 추론 엔진과 GGUF 가중치를 묶었다.

전형적인 사용:

curl -L -o llava-v1.5.llamafile \

https://huggingface.co/Mozilla/llava-v1.5-7B-llamafile/resolve/main/llava-v1.5-7b-q4.llamafile

chmod +x llava-v1.5.llamafile

./llava-v1.5.llamafile

이러면 OpenAI 호환 HTTP 서버가 뜨고, 같은 파일을 Mac/Linux/Windows에 그대로 옮겨도 돈다. 2026년 현재 Mozilla가 LLaMA·Mistral·Phi·Gemma·Qwen 등 주요 OSS 모델의 llamafile 변형을 Hugging Face에 꾸준히 올린다.

왜 llamafile이 의미 있나:

- **배포의 마찰을 거의 0**으로 줄였다 — 비기술자·교실·오프라인 환경·"한 번 받아 두고 인터넷 끊고 쓰자"에 진짜 좋다.

- **archival**의 의미 — 5년 후에도 같은 파일이 돈다는 보장(APE 포맷 + 자체 포함 가중치).

- **CPU 추론 최적**도 같이 — Justine Tunney가 matmul SIMD 커널을 직접 짜서 같은 모델이 일반 llama.cpp보다 CPU에서 빠른 경우가 흔하다.

약점: 단일 파일 크기 한계(예전엔 4GB, 2024년 이후 ZipAlign·외부 가중치 등으로 우회), production 서빙은 결이 아니다.

언제 llamafile: 비기술자에게 LLM을 "주는" 상황, 오프라인 배포, 교실·워크숍, archival.

6장 · Ollama — 가장 쉬운 로컬 LLM

**Ollama**는 2023년 6월 시작된 로컬 LLM 런타임이다. 내부적으로는 llama.cpp를 쓰지만, **Docker처럼 깔끔한 UX**(모델을 `pull`·`run`·`push`, Modelfile로 커스텀)를 얹어서 2026년 현재 **로컬 LLM의 사실상 기본 진입점**이 됐다.

설치 (Mac/Linux/Windows)

curl -fsSL https://ollama.com/install.sh | sh

모델 받고 바로 대화

ollama run llama3.3

백엔드 서버 모드

ollama serve

다른 터미널에서 API 호출

curl http://localhost:11434/api/generate -d '{

"model": "llama3.3",

"prompt": "안녕",

"stream": false

}'

2026년 Ollama의 현재 모습:

- **OpenAI 호환 엔드포인트** — `/v1/chat/completions`도 같이 떠서 기존 코드 그대로 붙는다.

- **Modelfile** — Dockerfile 같은 형식으로 시스템 프롬프트·온도·LoRA를 묶어 "내 모델"로 만들 수 있다.

- **GGUF 직접 import** — Hugging Face의 임의 GGUF를 그대로 가져온다.

- **multi-modal** — LLaVA·MoonDream·Llama 3.2 Vision 같은 vision 모델 지원.

- **자동 GPU 활용** — Metal·CUDA·ROCm을 자동 감지.

- **Ollama Cloud** — 2025년부터 클라우드 호스팅도 시작 — 로컬 시작, 부하 늘면 클라우드.

매력 포인트는 단순함이다. "Mac에 깔고 5분 안에 70B 양자화 모델과 대화" 가 진짜로 된다. 그래서 LangChain·LlamaIndex·n8n·VS Code 확장 등 거의 모든 OSS LLM 도구가 "Ollama 호환"을 기본으로 지원한다.

약점: 다중 사용자 throughput·고급 batching은 vLLM/SGLang에 밀린다. Modelfile DSL이 빈약하다. 모델 라이브러리가 Ollama Hub에 묶이는 경향(GGUF 가져오기는 가능).

언제 Ollama: 개인 노트북·홈 서버·"5분 안에 시작"하고 싶을 때, OSS 도구와 즉시 연결.

7장 · LM Studio / GPT4All — GUI 옵션

CLI보다 GUI가 편한 사용자를 위한 진영.

LM Studio

2023년 시작된 데스크톱 앱(Mac/Windows/Linux). 모델 검색·다운로드·채팅·서버 모드가 하나의 .app 안에 들어 있다. Hugging Face Hub에서 GGUF 모델을 검색·필터·다운로드하고, 채팅 UI에서 바로 쓰거나 OpenAI 호환 로컬 서버를 띄울 수 있다.

2026년 LM Studio의 현재:

- **llama.cpp + MLX 백엔드** — Apple Silicon에선 MLX, 다른 곳은 llama.cpp.

- **모델 호환성 표시** — RAM·VRAM에 들어갈지를 모델 카드에 미리 표시.

- **로컬 서버** — 한 토글로 OpenAI 호환 서버.

- **multi-model loading** — 한 번에 여러 모델 로드.

- **structured output·tool use** — JSON 스키마·function calling.

상업적 사용이 무료(개인·기업 모두, 라이선스 변경 후)라서 사내 데모·POC에 자주 쓰인다.

GPT4All

2023년 초 Nomic AI가 시작한 OSS 프로젝트. 데스크톱 앱 + Python SDK + 모델 라이브러리. "어떤 노트북에서나 도는 LLM"을 모토로, CPU 추론과 작은 모델(3B·7B·13B)에 강하다. 로컬 문서 검색(LocalDocs) 같은 RAG 기능이 데스크톱 앱에 통합돼 있다.

2026년 GPT4All의 위치:

- 데스크톱 chat UX가 깔끔하고, Windows·Mac·Linux에 골고루 다듬어져 있다.

- 기업용 GPT4All Enterprise(유료)로 회사 내 배포 도구를 함께 판다.

- "Nomic Atlas" 임베딩·시각화와 묶인 결.

LM Studio vs GPT4All 한 줄: LM Studio는 "Hugging Face 모델 탐험에 강한 GUI", GPT4All은 "데스크톱 chat + LocalDocs RAG에 강한 GUI".

언제 GUI: 비기술자 사용자, 데모·교육·내부 도구, "마우스로 다 끝내고 싶다".

8장 · SGLang — Structured generation

**SGLang**은 LMSYS·UCB·Stanford 합작으로 2024년 초 공개된 추론 시스템이다. vLLM과 같은 "고처리량 서빙" 진영이지만, **구조적 생성(structured generation)**과 **RadixAttention**이라는 두 카드를 들고 들어왔다.

RadixAttention

PagedAttention이 "메모리 단편화"를 해결했다면, RadixAttention은 **여러 요청 사이의 prefix를 트리(radix tree)로 공유**한다. 같은 system prompt를 쓰는 1000개 요청이 있으면, 그 부분의 KV cache는 한 번만 계산하고 자동으로 공유된다. agentic 워크로드(같은 도구 명세·few-shot이 반복)에서 효과가 크다.

Frontend DSL — 구조적 생성

SGLang은 Python DSL로 LLM 호출을 작성하는데, **분기·반복·병렬·제약**이 1급 시민이다.

@sgl.function

def multi_turn_question(s, question):

s += sgl.system("You are a helpful assistant.")

s += sgl.user(question)

s += sgl.assistant(sgl.gen("answer", max_tokens=256))

s += sgl.user("Was that answer correct?")

s += sgl.assistant(sgl.gen("verification", choices=["yes", "no"]))

state = multi_turn_question.run(question="What is the capital of France?")

print(state["answer"], state["verification"])

`sgl.gen(..., choices=...)`이나 JSON 스키마 제약은 backend에서 constrained decoding으로 강제된다. 즉 모델이 "yes"/"no" 외 다른 토큰을 못 뱉는다.

2026년 SGLang의 강점:

- **agentic·tool-calling 워크로드에서 vLLM 대비 throughput 우위가 자주 보인다** (벤치마크는 워크로드 의존).

- **DeepSeek·Qwen·Llama 등 MoE 모델 최적**이 빠르게 들어온다.

- **OpenAI 호환 서버**도 같이 제공해서 기존 클라이언트 호환.

- **disaggregated serving·speculative decoding**도 최근 들어왔다.

언제 SGLang: structured output·tool use 헤비 워크로드, prefix가 많이 반복되는 agentic 서빙, vLLM과 함께 후보로 두고 본인 워크로드로 벤치.

9장 · TGI (Hugging Face) — 운영 친화

**TGI(Text Generation Inference)**는 Hugging Face가 만든 추론 서버다. 2022년 말 시작, 2026년에는 vLLM·SGLang에 비해 학계 화제성은 덜하지만 **운영 친화 기능**으로 자리 잡았다.

- **Hugging Face Hub와 직결** — `--model-id` 한 줄로 Hub 모델을 받아 띄움.

- **OpenAI 호환 + Messages API** — 표준 인터페이스.

- **continuous batching·flash attention·paged KV** — 핵심 가속은 다 들어왔다.

- **safetensors·BitsAndBytes·AWQ·GPTQ·EETQ·FP8** — 양자화 다수 지원.

- **Hugging Face Inference Endpoints의 백엔드** — 호스티드 서비스를 직접 셀프호스트한다는 결.

- **그라파나 메트릭·OpenTelemetry trace** 내장.

docker run --gpus all -p 8080:80 \

-v $PWD/models:/data \

ghcr.io/huggingface/text-generation-inference:latest \

--model-id meta-llama/Llama-3.3-70B-Instruct \

--quantize bitsandbytes-nf4

라이선스가 한때(2024년) HFOIL로 잠시 제한됐다가 다시 Apache 2.0으로 복귀한 이력이 있다. 2026년 현재는 다시 자유 OSS.

언제 TGI: Hugging Face Hub 의존이 강한 팀, Hugging Face Endpoints와의 모드 통일, "운영 메트릭·표준 도커 컨테이너" 결을 선호.

vLLM·SGLang vs TGI 한 줄: 학계의 가속 혁신은 vLLM·SGLang에서 먼저 나오고, TGI는 "운영 기능 정리"에 강점.

10장 · KTransformers (Tsinghua) — long-context 최적

**KTransformers**는 칭화대(Tsinghua University) MADSys 연구실에서 2024년 공개된 추론 프레임워크다. 초점은 분명하다 — **소비자 GPU 하나로 거대 MoE 모델을 돌리는 것**.

핵심 트릭:

- **expert offloading** — MoE 모델의 expert weights를 CPU RAM에 두고, 활성화될 때만 GPU로 가져온다.

- **CPU SIMD 가속(AMX·AVX-512)** — sparse activation을 CPU에서 효율적으로 돌린다.

- **long-context 최적** — chunked prefill·local-global attention 결합.

- **DeepSeek·Qwen MoE 특화** — 671B DeepSeek-V3·R1 같은 모델을 24GB 소비자 GPU + 큰 RAM(192GB~512GB)으로 돌릴 수 있다는 데모가 화제가 됐다.

DeepSeek-V3를 RTX 4090 + 큰 시스템 RAM에서

git clone https://github.com/kvcache-ai/ktransformers

cd ktransformers

pip install -e .

python -m ktransformers.local_chat \

--model_path /path/to/DeepSeek-V3-GGUF \

--gguf_path /path/to/DeepSeek-V3-GGUF \

--cpu_infer 32

왜 KTransformers가 의미 있나:

- 2025년 DeepSeek-V3·R1, 2026년 Qwen3-MoE 같은 거대 MoE 모델이 OSS로 풀리면서, **이걸 개인이 어떻게 돌리느냐**가 실제 문제가 됐다. KTransformers는 그 답 중 하나.

- **GPU 1장 + 큰 RAM** 조합으로 H100 클러스터 없이도 거대 모델을 돈다.

약점: 다중 사용자 서빙·throughput은 vLLM이 더 잘 한다. 설치·튜닝 학습 곡선이 있다.

언제 KTransformers: 거대 MoE 모델을 단일 사용자로 돌리고 싶은데 GPU 클러스터가 없을 때, long-context 워크로드.

11장 · NVIDIA Triton + TensorRT-LLM — 데이터센터 표준

NVIDIA 진영 풀스택. 둘이 한 쌍처럼 자주 같이 쓰인다.

TensorRT-LLM

NVIDIA의 OSS LLM 추론 라이브러리. PyTorch 모델을 **TensorRT 엔진**(NVIDIA GPU 전용 IR)으로 컴파일해서, FP16·INT8·INT4·FP8·NVFP4 같은 NVIDIA가 미는 정밀도로 가속한다. Hopper(H100/H200)·Blackwell(B100/B200·GB200) 같은 신형 칩의 새 명령어를 빠르게 활용하는 게 강점.

- **in-flight batching·paged KV·speculative decoding·chunked prefill** — vLLM이 가진 가속은 다 있다.

- **FP8/FP4 가속** — Hopper/Blackwell에서 throughput 큰 폭 상승.

- **multi-GPU·multi-node** — Tensor·Pipeline·Expert parallel 풀 지원.

Triton Inference Server

NVIDIA의 일반 추론 서버. LLM뿐 아니라 vision·tabular·custom 모델까지 한 서버에서 multi-framework로 띄운다. TensorRT-LLM 백엔드를 통해 LLM 서빙 모드로 쓸 수도 있고, **TensorRT-LLM의 OpenAI 호환 서버**(`trtllm-serve`)를 직접 띄울 수도 있다.

모델을 TensorRT-LLM 엔진으로 빌드

trtllm-build --checkpoint_dir ./llama3-70b \

--output_dir ./engines/llama3-70b \

--gemm_plugin auto \

--max_batch_size 32

trtllm-serve로 띄우기 (OpenAI 호환)

trtllm-serve ./engines/llama3-70b --port 8000

vLLM vs TensorRT-LLM 한 줄: vLLM은 OSS·다양한 GPU(NVIDIA·AMD·Intel·TPU)·접근 쉬움. TensorRT-LLM은 NVIDIA 전용이지만 NVIDIA GPU의 마지막 한 방울까지 짜낸다(특히 FP8/FP4). production에서 둘을 같이 두고 자기 워크로드로 벤치하는 팀이 많다.

언제 TensorRT-LLM/Triton: NVIDIA Hopper/Blackwell GPU 클러스터, throughput·latency가 절대적인 production, 운영팀이 NVIDIA 생태계에 익숙.

12장 · Modular MAX (Mojo 팀) — 신규 진영

**Modular**는 Chris Lattner(LLVM·Swift·Clang 원작자)가 2022년 창업한 회사다. **Mojo**(Python 호환을 노리는 고성능 시스템 언어)와 **MAX**(Modular Accelerated Xecution, AI 추론 플랫폼)를 만든다. 2024년 MAX의 OSS 전환을 시작했고, 2026년에는 **NVIDIA·AMD·Intel·Apple까지 같은 하나의 그래프 컴파일러로 추론**한다는 결로 자리 잡았다.

핵심 idea:

- **Mojo로 작성된 커널** — Python처럼 짜고 C/CUDA 수준 성능. matmul·attention 같은 핵심 커널을 Mojo로 쓰면 여러 가속기로 컴파일 가능.

- **MAX Engine** — 그래프 컴파일러. PyTorch·ONNX 모델을 받아 NVIDIA/AMD/Apple GPU에 최적화.

- **MAX Serve** — OpenAI 호환 LLM 서버.

- **하드웨어 lock-in 해소** — "CUDA 없이도 NVIDIA GPU에서 빠르게"가 슬로건.

pip install modular

max serve --model-path meta-llama/Llama-3.3-70B-Instruct

2026년 Modular의 위치:

- **NVIDIA·AMD GPU 모두에서 vLLM 경쟁권의 throughput**이 일부 워크로드에서 나오기 시작.

- 일부 클라우드(Lambda·예전 Lepton)에서 backend로 채택.

- 학계·OSS 커뮤니티의 채택은 vLLM·SGLang에 비해선 아직 작지만, **"Mojo + MAX"라는 묶음이 차세대 진영**으로 인정받고 있다.

약점: Mojo의 OSS 전환이 단계적이라 커뮤니티가 아직 작다. 모델 호환성·기능 폭은 vLLM이 더 넓다.

언제 MAX: AMD GPU에서 vLLM의 ROCm 백엔드보다 더 빠른 길을 찾고 싶을 때, Mojo 생태계를 일찍 채택하고 싶을 때, NVIDIA 일변도 lock-in을 피하고 싶을 때.

13장 · 양자화 — GGUF / AWQ / GPTQ / FP8

서빙 프레임워크를 고를 때 떼어놓을 수 없는 한 축이 **양자화 포맷**이다. 2026년 현재 주류 5가지.

GGUF (llama.cpp 계열)

- llama.cpp가 만든 통합 포맷. 가중치 + 메타데이터 + tokenizer 한 파일.

- 양자화 단계가 풍부 — `Q2_K`·`Q3_K_S/M/L`·`Q4_K_S/M`·`Q5_K_S/M`·`Q6_K`·`Q8_0`·`IQ2_XXS`·`IQ3_XXS`·`IQ4_XS`.

- 실무 권장: 7B~70B에서 `Q4_K_M`이 품질·크기의 sweet spot이라는 합의가 흔하다. 더 작게는 `IQ3_XXS`(2~3-bit imatrix), 더 크게는 `Q5_K_M`·`Q6_K`.

- 어디서 잘 도나: llama.cpp·Ollama·LM Studio·llamafile·KTransformers.

AWQ (Activation-aware Weight Quantization)

- 2023년 MIT Han Lab 논문. 활성화 분포를 보고 중요한 weight를 보존하면서 4-bit로 양자화.

- 품질 유지가 좋다는 평이 있고, GPU 추론 최적이다.

- 어디서: vLLM·SGLang·TGI·TensorRT-LLM 모두 AWQ를 1급 지원.

GPTQ

- 2022년 ETH Zürich 논문. layer-wise OBS(Optimal Brain Surgeon)로 4-bit 양자화.

- AWQ보다 먼저 나와 한때 표준이었다. 2026년에는 AWQ에 점유율 일부를 내준 분위기지만 여전히 많이 쓰인다.

- 어디서: vLLM·SGLang·TGI·AutoGPTQ.

FP8

- 8-bit 부동소수점. Hopper(H100)·Ada(L40S)에서 처음 하드웨어로 들어왔고, Blackwell에선 FP4까지.

- "양자화"라고 부르지만 **훈련에 가까운 수치 정확도**를 유지한다는 평. 대형 production에서 throughput 큰 폭 상승.

- 어디서: TensorRT-LLM·vLLM·SGLang의 FP8 경로.

NVFP4 / MXFP4

- 2024~2025년 NVIDIA·OCP(Open Compute)에서 표준화된 4-bit 부동소수점. Blackwell GPU의 새 명령어와 묶임.

- 2026년에는 일부 production 모델이 NVFP4·MXFP4 서빙으로 옮겨오기 시작.

**한 줄 추천**:

- 노트북·로컬 → GGUF `Q4_K_M`

- vLLM/SGLang에 OSS 70B 올릴 때 → AWQ 4-bit (또는 GPTQ)

- H100 production → FP8

- B100/B200 → NVFP4 / FP8 혼합

14장 · 클라우드 서빙 SaaS — Together / Fireworks / Groq / Cerebras / Lepton

자체 GPU 운용이 부담스러운 팀을 위한 진영. **OSS 모델을 API 한 번으로 부르는** 결.

Together AI

OSS 모델 호스팅의 큰 형. Llama·Mistral·Qwen·DeepSeek 등 200+ 모델을 OpenAI 호환 API로. fine-tune·dedicated endpoint·dedicated deployment까지. 학계와의 협업(RedPajama·Stripedhyena 같은 모델 공동 학습)도 강점.

Fireworks AI

빠른 throughput과 함수 호출·structured output 품질로 평가받음. 자체 학습·fine-tune 도구도 강력. Mixture-of-Experts와 long-context에 최적화된 추론 스택을 같이 판다.

Groq

자체 칩 **LPU(Language Processing Unit)**. 대규모 SRAM·결정적(deterministic) 실행으로 같은 모델을 **압도적 저지연**(초당 수백 토큰)으로 서빙. OSS Llama·Mixtral 위주, 모델 폭은 제한적이지만 속도에선 거의 항상 1등 후보.

Cerebras

**Wafer-scale 엔진** — 웨이퍼 하나가 곧 한 칩(WSE-3 기준 ~4조 트랜지스터). 거대 단일 칩이라 H100 클러스터 대비 모델 분할·통신 오버헤드가 적다. inference cloud로 빠른 throughput을 광고하고, 일부 정부·연구실용 거대 학습에도 쓰인다.

SambaNova

자체 칩 **RDU(Reconfigurable Dataflow Unit)**. 데이터플로우 아키텍처로 LLM의 dense·sparse 워크로드에 최적. enterprise·정부 시장 중심.

Lepton AI (NVIDIA 인수, 2025)

Jia Yangqing(Caffe 원작자, Meta·Alibaba) 등이 창업한 클라우드 추론 플랫폼. 2025년 NVIDIA가 인수해서 **NVIDIA 클라우드 생태계의 추론 레이어**로 들어갔다. NVIDIA DGX Cloud·NIM(NVIDIA Inference Microservices)와 통합돼서, "NVIDIA가 직접 운영하는 OSS 모델 추론"의 결로 자리 잡고 있다.

한 줄 비교

- 가장 빠름(저지연) → **Groq**(또는 Cerebras)

- OSS 모델 폭이 가장 넓음 → **Together**

- fine-tune·structured output 품질 → **Fireworks**

- 거대 모델 단일 칩 → **Cerebras**·**SambaNova**(enterprise)

- NVIDIA 생태계 통합 → **Lepton(NVIDIA)** + NIM

15장 · 한국 / 일본 — Upstage Solar / KT Mi:dm / Sakana / NTT Tsuzumi / ELYZA

영어권 모델만 보면 절반을 놓친다. 한국·일본의 OSS·반-OSS 모델 진영도 2026년에 굳어졌다.

한국

- **Upstage Solar** — Upstage가 만든 Solar 시리즈(Solar 10.7B·Pro 모델 등). 작은 사이즈에서 한국어·영어 양쪽 성능이 좋다는 평가, MoE·long-context 변형 활발. Hugging Face와의 협업, AWS Marketplace 진출 등 enterprise 채널을 강하게 잡았다.

- **KT Mi:dm(믿:음)** — KT가 만든 한국어 대형 모델. 2024년부터 공개·확장되어 2026년에는 multi-billion 파라미터의 한국어 특화 라인업으로 자리. 정부·금융·통신 같은 규제 산업에서 on-prem 채택이 늘고 있다.

- **NAVER HyperCLOVA X** — 직접 OSS는 제한적이지만, NAVER Cloud Platform과 묶여 한국 enterprise 시장의 큰 축. multi-modal·HCX-DASH 같은 소형 변형도 활발.

- **LG ExaOne** — LG AI Research의 ExaOne 라인업. 일부 변형이 Hugging Face에 OSS로 공개됨.

이 모델들은 **vLLM·SGLang·llama.cpp**의 fork·branch에서 한국어 토크나이저·specific kernel을 위한 패치가 함께 돌고 있다. OSS 호환성은 모델마다 다르고, 라이선스도(연구용·상업용 한정·완전 OSS) 갈리니 도입 전 라이선스 검토 필수.

일본

- **Sakana AI** — David Ha·Llion Jones(Transformer 공동 저자) 등 창업. "evolutionary model merging"으로 알려진 라인업, 일본어 특화 작은 모델과 vision 모델을 OSS로 풀고 있다. 2025년 NVIDIA·정부 지원과 함께 일본 AI 라인의 상징적 회사.

- **NTT Tsuzumi(つづみ)** — NTT의 일본어 특화 LLM. on-prem·일본 내 데이터 잔존 등 거버넌스 요구가 큰 정부·통신 시장에서 채택.

- **ELYZA** — 도쿄대 발 스타트업. Llama·Qwen 등 OSS 베이스에 일본어 continued pretraining으로 ELYZA-japanese-Llama·ELYZA-shortcut 시리즈를 OSS로 꾸준히 공개. 2024년 KDDI 자회사화 이후에도 OSS 라인 유지.

- **Preferred Networks PLaMo** — PLaMo 100B 같은 일본 발 OSS 베이스 모델 라인.

운영 관점에서 한·일 모델은 대개 **로컬 서빙(llama.cpp·Ollama·vLLM)** + **OSS 호스팅(Together·Fireworks 외 현지 클라우드)** 어느 쪽이든 돌릴 수 있는 GGUF·safetensors 변형을 같이 푸는 게 표준이 됐다. 정부·은행 같은 규제 산업은 **on-prem vLLM/TGI**가 거의 기본 선택.

16장 · 누가 무엇을 골라야 하나

지금까지의 12 진영을 묶어 **상황별 추천**으로 정리한다.

개인 / 취미

- **Mac 노트북** → MLX 또는 LM Studio(MLX 백엔드). 양자화는 `Q4_K_M` 또는 4-bit MLX.

- **Windows/Linux 노트북** → Ollama 또는 LM Studio. 양자화 GGUF.

- **5분 안에 시작** → Ollama 한 줄 설치.

- **GUI 선호** → LM Studio.

- **비기술자에게 주기** → llamafile.

스타트업 (10~50명)

- **API로 시작, 비용 폭발하면 자체 서빙** — 처음엔 Together·Fireworks·OpenAI·Anthropic API. 토큰 비용이 월 5천 달러를 넘어가면 vLLM 셀프호스트 비교.

- **셀프호스트 시작점** → vLLM on AWS/GCP/Azure GPU(H100·L40S). OSS 모델은 AWQ·FP8.

- **agentic·tool use 헤비** → SGLang 후보로.

- **로컬 prototype + 클라우드 production** → Mac에서 MLX/Ollama로 만들고, 같은 모델을 vLLM 서버에 올려 production.

엔터프라이즈 (규제 산업·금융·정부)

- **on-prem 서빙** → vLLM 또는 TGI. NVIDIA Triton + TensorRT-LLM도 NVIDIA 라인이라면.

- **한국어 특화** → Upstage Solar / KT Mi:dm / HyperCLOVA X on vLLM.

- **일본어 특화** → ELYZA / Sakana / Tsuzumi on vLLM 또는 NTT 내부 스택.

- **운영 메트릭·표준화** → TGI 또는 Triton(이미 NVIDIA 생태계).

- **모델 다양성(LLM + vision + tabular)** → Triton(multi-framework).

데이터센터 / 하이퍼스케일

- **NVIDIA H100/B100 풀스택** → TensorRT-LLM + Triton (혹은 trtllm-serve). FP8/NVFP4.

- **OSS 우선·다양한 가속기** → vLLM(NVIDIA·AMD·Intel·TPU 동시 지원).

- **structured / agentic** → SGLang.

- **거대 MoE 단일 사용자** → KTransformers.

하드웨어 lock-in 회피

- **NVIDIA·AMD·Apple까지 같이** → vLLM(폭 넓음) 또는 Modular MAX(컴파일러).

- **Apple만** → MLX.

- **CPU 위주 / 임베디드** → llama.cpp.

에필로그 — 모델은 흔해졌고, 인프라가 차별화다

2023년에는 "어떤 모델을 쓸 것인가"가 질문이었다. 2026년에는 **"어디서, 어떻게 돌릴 것인가"** 가 질문이다. 모델은 흔해졌고(OSS 70B·MoE 거대 모델까지), 가격은 시간 단위로 변하고, 양자화 품질은 1년 전과 다른 수준이며, GPU 한 장이 노트북에 꽂히는 시대가 됐다.

이 글의 결론은 단순하다 — **자기 워크로드에 직접 벤치하라**. throughput·지연·비용·운영 복잡도가 워크로드마다 다르게 나오니, 추천보다 측정이 항상 옳다. 그리고 그 측정을 위한 12 진영이 2026년에 다 OSS로 풀려 있다는 게, 어쩌면 이 글의 진짜 메시지다.

이제 우리가 할 일은 GPU를 더 빠르게 굴리는 게 아니라, **어느 진영이 우리 문제에 맞는지를 일주일 안에 결정하는 것**이다.

참고 / References

- vLLM — [github.com/vllm-project/vllm](https://github.com/vllm-project/vllm) / [docs.vllm.ai](https://docs.vllm.ai/)

- vLLM PagedAttention 논문 — ["Efficient Memory Management for Large Language Model Serving with PagedAttention"](https://arxiv.org/abs/2309.06180)

- llama.cpp — [github.com/ggerganov/llama.cpp](https://github.com/ggerganov/llama.cpp)

- MLX (Apple) — [github.com/ml-explore/mlx](https://github.com/ml-explore/mlx) / [ml-explore.github.io/mlx](https://ml-explore.github.io/mlx/build/html/index.html)

- mlx-lm — [github.com/ml-explore/mlx-lm](https://github.com/ml-explore/mlx-lm)

- llamafile (Mozilla) — [github.com/Mozilla-Ocho/llamafile](https://github.com/Mozilla-Ocho/llamafile)

- Justine Tunney "LLaMA Now Goes Faster on CPUs" — [justine.lol/matmul](https://justine.lol/matmul/)

- Ollama — [ollama.com](https://ollama.com/) / [github.com/ollama/ollama](https://github.com/ollama/ollama)

- LM Studio — [lmstudio.ai](https://lmstudio.ai/)

- GPT4All (Nomic AI) — [gpt4all.io](https://www.nomic.ai/gpt4all) / [github.com/nomic-ai/gpt4all](https://github.com/nomic-ai/gpt4all)

- SGLang — [github.com/sgl-project/sglang](https://github.com/sgl-project/sglang) / [lmsys.org/blog/2024-01-17-sglang](https://lmsys.org/blog/2024-01-17-sglang/)

- TGI (Hugging Face) — [github.com/huggingface/text-generation-inference](https://github.com/huggingface/text-generation-inference)

- KTransformers (Tsinghua) — [github.com/kvcache-ai/ktransformers](https://github.com/kvcache-ai/ktransformers)

- MLC LLM — [github.com/mlc-ai/mlc-llm](https://github.com/mlc-ai/mlc-llm) / [llm.mlc.ai](https://llm.mlc.ai/)

- NVIDIA TensorRT-LLM — [github.com/NVIDIA/TensorRT-LLM](https://github.com/NVIDIA/TensorRT-LLM)

- NVIDIA Triton Inference Server — [github.com/triton-inference-server/server](https://github.com/triton-inference-server/server)

- Modular MAX — [docs.modular.com/max](https://docs.modular.com/max/) / [modular.com](https://www.modular.com/)

- AWQ paper — ["AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration"](https://arxiv.org/abs/2306.00978)

- GPTQ paper — ["GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers"](https://arxiv.org/abs/2210.17323)

- FP8 Formats for Deep Learning — [arxiv.org/abs/2209.05433](https://arxiv.org/abs/2209.05433)

- Together AI — [together.ai](https://www.together.ai/)

- Fireworks AI — [fireworks.ai](https://fireworks.ai/)

- Groq — [groq.com](https://groq.com/)

- Cerebras — [cerebras.ai](https://www.cerebras.ai/)

- SambaNova — [sambanova.ai](https://sambanova.ai/)

- Lepton AI (NVIDIA acquisition, 2025) — [news.crunchbase.com Lepton coverage](https://news.crunchbase.com/ai/nvidia-acquires-lepton-jia/) / [lepton.ai](https://www.lepton.ai/)

- NVIDIA NIM — [nvidia.com/en-us/ai/](https://www.nvidia.com/en-us/ai/)

- Upstage Solar — [upstage.ai](https://www.upstage.ai/) / [huggingface.co/upstage](https://huggingface.co/upstage)

- KT Mi:dm — [kt.com AI](https://www.kt.com/) / [huggingface.co/KT-AI](https://huggingface.co/KT-AI)

- NAVER HyperCLOVA X — [clova.ai](https://clova.ai/) / [ncloud.com HyperCLOVA X](https://www.ncloud.com/product/aiService/clovastudio)

- LG ExaOne — [lgresearch.ai exaone](https://www.lgresearch.ai/exaone) / [huggingface.co/LGAI-EXAONE](https://huggingface.co/LGAI-EXAONE)

- Sakana AI — [sakana.ai](https://sakana.ai/)

- NTT Tsuzumi — [group.ntt tsuzumi](https://group.ntt/en/newsrelease/2023/11/01/231101a.html)

- ELYZA — [elyza.ai](https://elyza.ai/) / [huggingface.co/elyza](https://huggingface.co/elyza)

- Preferred Networks PLaMo — [preferred.jp](https://www.preferred.jp/en/) / [huggingface.co/pfnet](https://huggingface.co/pfnet)