2026-05-01

DGX Spark에서 vLLM vs llama.cpp vs Ollama — 어떤 추론 스택을 써야 하나

GB10 추론 스택 결정 가이드: MoE+고동시성은 vLLM, MXFP4 프롬프트·단일 사용자는 llama.cpp, 제로 설정 개발은 Ollama. NVFP4 tok/s 비교 포함.

DGX Spark 배포를 지배하는 세 가지 추론 스택: vLLM, llama.cpp, Ollama. GB10의 SM121 아키텍처에서 각각 명확히 다른 트레이드오프가 있습니다.

한눈에 보기

	vLLM	llama.cpp	Ollama
NVFP4 지원	✅(cu130-nightly)	✅(PR #22196)	⚠️ llama.cpp 백엔드 경유
MoE 모델	✅ 최고	✅ 양호	✅ 양호
멀티 사용자 동시성	✅ 우수	⚠️ 제한적	⚠️ 제한적
MTP 투기적 디코딩	✅	❌	❌
설정 복잡도	높음	중간	낮음
OpenAI 호환 API	✅	✅(llama-server)	✅

단일 사용자 처리량: Qwen3.6-35B-A3B

스택	양자화	단일 사용자 tok/s
vLLM(FP8, MTP 없음)	FP8	28–33
vLLM(NVFP4, MTP 없음)	NVFP4	~42
vLLM(NVFP4 + MTP-1)	NVFP4	55.9
llama.cpp(NVFP4)	NVFP4	~38
llama.cpp(MXFP4)	MXFP4	~43
Ollama(기본 Q4)	Q4_K_M	~24

동시성: vLLM의 절대적 우위

c=32 동시 사용자에서 vLLM의 연속 배치 처리와 페이지드 KV-cache가 차이를 만듭니다:

스택	c=32 총 tok/s
vLLM(NVFP4 + MTP)	433
llama.cpp(llama-server, NVFP4)	~95
Ollama	~60

언제 어떤 스택을 쓰나

vLLM을 선택하는 경우:

MoE 모델(Qwen3, Mixtral) 운용 — flashinfer_cutlass로 TRITON 대비 +30%
동시 사용자 4명 초과 서빙
투기적 디코딩(MTP)으로 레이턴시 감소
Prometheus 메트릭과 OpenAI 호환 API 필요

llama.cpp를 선택하는 경우:

MXFP4 정밀도(최고 프롬프트 처리량, vLLM 미지원)
Docker 없는 로컬 개발 환경
NVFP4 업로드가 없는 모델 사용(로컬 양자화)
최소 의존성 — Python 없이 단일 바이너리

Ollama를 선택하는 경우:

프로토타이핑이나 개발자 전용 워크로드
GUI 프론트엔드(Open WebUI, Continue.dev) 연동
14B 이하 소형 모델로 오버헤드가 문제 되지 않는 경우

TRITON-only 함정