추론 엔진 비교
엔진은 가중치를 토큰으로 바꾸는 프로그램입니다. 파일을 로드하고, transformer 순전파를 돌리고, 대개 그 위에서 HTTP를 말합니다. 좋은 소식은 같은 하드웨어에서 거의 모든 엔진이 같은 모델을 대략 같은 속도로 돌린다는 것입니다 — 엔진 선택은 순수 tok/s가 아니라 워크플로, 포맷 지원, 동시성에 관한 것입니다. 나쁜 소식도 같습니다. 엔진 사이의 벤치마크 쇼핑은 대체로 헛수고입니다.
판도
| 엔진 | 정체 | 포맷 | 하드웨어 도달 | 만들어진 용도 |
|---|---|---|---|---|
| llama.cpp | 내장 서버를 가진 C/C++ 추론 코어 | GGUF | CPU, CUDA, ROCm, Metal, Vulkan — 가장 넓음 | 기반; 거의 모든 곳에서 실행 |
| Ollama | 모델 라이브러리, CLI, REST로 감싼 llama.cpp | GGUF | llama.cpp가 하는 모든 것 | 무마찰 데스크톱 사용 |
| LM Studio | 세련된 GUI + OpenAI 호환 서버 | GGUF (맥에서는 MLX도) | Windows/macOS/Linux GUI | 플래그가 아니라 버튼을 원하는 사람 |
| vLLM | 파이썬 서빙 엔진: 페이징드 어텐션, 연속 배칭 | safetensors | CUDA (일부 ROCm/TPU 지원) | 데이터센터급 동시 서빙 |
| SGLang | RadixAttention 프리픽스 캐싱을 가진 서빙 엔진 | safetensors | CUDA | 빠른 구조화 출력; 프리픽스를 공유하는 에이전트 |
| exllamav2 | 디코드 속도에 튜닝된 GPU 전용 로더 | EXL2, GPTQ | CUDA만 | 소비자 NVIDIA GPU 한 장에서 최대 1인용 tok/s |
| MLX | Apple의 배열 프레임워크; mlx-lm이 그 위에서 모델 실행 |
MLX | Apple silicon | 최근 맥에서 빠른 실용 경로 |
| transformers (HF) | 모든 것이 포팅되는 기준 구현 | safetensors | CPU, CUDA | 정확성 검증, 실험, 학습 배관 |
계보 비고 하나: Ollama와 LM Studio는 둘 다 후드 아래 llama.cpp를 돌립니다. 이들을 llama.cpp와 비교하는 것은 추론이 아니라 포장을 비교하는 것입니다.
덧붙여 알아둘 것: llama.cpp는 서버 이상을 배송합니다 — 양자화·변환 도구, 벤치마크 하니스, 12개 언어의 바인딩.
심층 분석
vLLM은 페이징드 어텐션 통찰에서 태어났습니다(동시성 참고). GPU 메모리를 OS가 RAM을 다루듯 다루면 훨씬 많은 요청이 들어갑니다. "GPU 서버와 실제 트래픽이 있다"는 질문의 기본 답입니다.
SGLang은 요청에 걸쳐 프리픽스를 캐싱합니다(RadixAttention). 40개 에이전트가 같은 두 페이지 시스템 프롬프트를 공유하면 그 프롬프트는 40번이 아니라 한 번 처리됩니다. 빠른 제약 디코딩으로도 유명합니다 — 구조화 출력 참고.
exllamav2는 정확히 하나의 틈새를 위한 예리한 칼날입니다. 소비자 NVIDIA GPU 한 장에서 quant 비트당 최대 tok/s를 원하는 1인 사용자. 서버 스토리와 하드웨어 폭은 얇습니다. 틈새는 실재합니다.
MLX는 통합 메모리를 위해 지어진 Apple의 ML 프레임워크입니다. 집필 시점 기준으로 mlx-lm은 큰 모델에서 llama.cpp의 Metal 경로를 종종 이깁니다 — 맥에서는 둘 다 시도할 가치가 있을 만큼 가깝습니다(Apple Silicon에서 더).
transformers는 느리고 충실한 기준 구현입니다. quant 엔진이 이상한 짓을 하면 같은 모델을 이것으로 돌려 "엔진 탓인가 모델 탓인가"에 답합니다. 파인튜닝 도구의 배관이기도 합니다(파인튜닝 참고).
필요별 선택
| 당신은... | 시작점 |
|---|---|
| 자기 책상에서 챗 | Ollama 또는 LM Studio |
| 셸에서 스크립팅 (파이프, cron, 소형 도구) | Ollama의 REST API, 또는 llama-server |
| 가벼운 트래픽의 앱 백엔드 구축 | llama-server — 프로세스 하나, 운영 제로 |
| 다수의 동시 사용자 서빙 | vLLM 또는 SGLang |
| 긴 시스템 프롬프트를 공유하는 에이전트 함대 | SGLang 또는 vLLM; 에이전트 참고 |
| 올-맥 가족 | 먼저 Ollama/LM Studio; 더 빠르기를 원하면 MLX |
표에 대한 비고 두 개:
- "시작점"은 "만족점"이 아닙니다 — 모든 데스크톱 엔진이 같은 GGUF를 읽으므로 두 번째를 시도하는 비용은 마이그레이션이 아니라 5분입니다.
- 실제로 비교할 때는 모든 것을 고정하세요. 같은 모델, 같은 quant, 같은 프롬프트, 모델은 이미 웜 상태.
포맷 분열은 데스크톱/서버 분열의 거울입니다
GGUF 대 safetensors(모델 포맷 참고)는 컨테이너 취향이 아닙니다 — 엔진을 결정합니다. GGUF는 단일 파일, 사전 양자화, 어디서든 도는 포맷이고 데스크톱 생태계 전체(llama.cpp, Ollama, LM Studio)가 그 위에 지어졌습니다. safetensors는 Hugging Face 생태계의 샤딩된 텐서 포맷입니다. 고처리량 서버 엔진(vLLM, SGLang, transformers)이 그것을 소비하되, 보통 사전 포장이 아니라 즉석 양자화(AWQ/GPTQ 변형)로.
그러니 진짜 결정 트리는 짧습니다. 데스크톱과 1인용 → GGUF 엔진. 서버와 동시성 → safetensors 엔진. 나머지는 디테일입니다.
뭔가 "실행할 수 없다"고 나오면 먼저 포맷을 확인하세요 — "엔진 X가 모델 Y를 못 돌린다"의 절반은 능력 차이가 아니라 GGUF/safetensors 불일치입니다.
오버헤드가 스토리가 아닙니다
같은 하드웨어, 같은 quant에서 엔진들은 단일 스트림 디코드 기준 대략 10–20% 안팎에 모입니다 — 종종 같은 백엔드를 공유하기 때문입니다. 실제로 경험 속도를 몇 배로 움직이는 것은 퍼센트가 아니라:
- 모델이 이미 로드되어 있는가 — 콜드 로드는 수 초에서 1분.
- 매 턴마다 대화 전체가 재전송되는가 — 컨텍스트 비용, 토큰 참고.
- 요청이 서로의 뒤에 줄서는가 — 동시성 참고.
- 레이어가 GPU에 앉아 있는가 — 엔진 노브 참고.
같은 GPU, 같은 8B Q4_K_M, 단일 스트림 (예시이지 스펙 아님):
llama.cpp / Ollama / LM Studio ~130–145 tok/s (밑에서는 같은 엔진)
exllamav2 EXL2 ~4bpw ~160–180 tok/s (디코드에 튜닝된 로더)
같은 GPU, 동시 챗 스트림 8개:
llama-server serial queue 각 스트림이 대기; 총 처리량 제자리
vLLM 모든 스트림이 단일 스트림 속도 근처
워크플로에 맞는 엔진을 고르고, 엔진 벤치마크 대신 에너지를 I/O 패턴에 쓰세요.
파일 하나, 엔진 여럿
Ollama용으로 내려받은 GGUF는 llama.cpp에서도 LM Studio에서도 직접 돌립니다 — 엔진은 변환하거나 재다운로드하지 않습니다. 같은 파일을 가리키면 됩니다(Ollama는 한 줄 Modelfile로 로컬 경로를 가져올 수 있습니다). 서버 쪽에서도 vLLM과 SGLang 사이의 safetensors에 같은 원리가 성립합니다. 실용적 귀결: 파일 수준의 벤더 락인은 없고, 엔진을 잘못 골라도 잃는 것은 몇 분입니다.
이 페이지가 벤치마크보다 워크플로를 계속 밀어붙이는 이유입니다. 필요가 바뀌어도 이미 내려받은 모델은 당신과 함께 이동합니다.
Ollama에서 졸업할 때
Ollama의 기본값은 아닐 때까지 훌륭합니다. 다음에 해당하면 서빙 엔진으로 옮기세요:
- 몇 개 스트림을 넘는 지속 동시성이 필요할 때(동시성 참고).
- 시스템 프롬프트를 공유하는 다수의 에이전트에 걸친 프리픽스 캐싱을 원할 때(SGLang).
- HF 생태계의 AWQ/GPTQ safetensors quant를 직접 서빙해야 할 때.
- 출하 전 제품 기능을 로드 테스트할 때.
- 하나의 큰 모델을 카드에 걸치려면 멀티 GPU 텐서 병렬이 필요할 때.
그중 하나가 참이 될 때까지, 편의가 처리량보다 가치 있습니다.