Skip to content
Published on

LLM 서빙 & 로컬 추론 2026 — vLLM / llama.cpp / MLX / Ollama / LM Studio / SGLang / TGI 심층 비교

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

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

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급 시민이다.

import sglang as sgl

@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.
  • 실무 권장: 7B70B에서 Q4_K_M이 품질·크기의 sweet spot이라는 합의가 흔하다. 더 작게는 IQ3_XXS(23-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

Discuss on Twitter • View on GitHub