LabHub

블로그

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

2026-05-16 · 37 분 읽기 · #llm#model-serving#inference#vllm#llama-cpp#mlx#llamafile#ollama#lm-studio#gpt4all#sglang#tgi#ktransformers#tensorrt-llm#modular-max#quantization#deep-dive

한국어English日本語

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

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 클러스터.

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

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

진영 C · 클라우드 서빙 SaaS

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

각 진영은 다른 가정 아래에서 만들어졌다. 데이터센터는 "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의 현재 모습:

전형적인 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를 내부에서 쓴다.

핵심 결:

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의 강점·약점:

언제 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 사용:

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가 점점 중요한가:

약점: 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이 의미 있나:

약점: 단일 파일 크기 한계(예전엔 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의 현재 모습:

매력 포인트는 단순함이다. "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의 현재:

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

GPT4All

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

2026년 GPT4All의 위치:

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의 강점:

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

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

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

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 모델을 돌리는 것.

핵심 트릭:

# 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가 의미 있나:

약점: 다중 사용자 서빙·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) 같은 신형 칩의 새 명령어를 빠르게 활용하는 게 강점.

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:

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

2026년 Modular의 위치:

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

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

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

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

GGUF (llama.cpp 계열)

AWQ (Activation-aware Weight Quantization)

GPTQ

FP8

NVFP4 / MXFP4

한 줄 추천:

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 모델 추론"의 결로 자리 잡고 있다.

한 줄 비교

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

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

한국

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

일본

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

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

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

개인 / 취미

스타트업 (10~50명)

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

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

하드웨어 lock-in 회피

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

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

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

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

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-llm-serving-local-inference-2026-vllm-llama-cpp-mlx-ollama-lm-studio-sglang-tgi-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다