올라마 vs LM 스튜디오 vs llama.cpp vs vLLM vs Jan: 2026 최신 로컬 LLM 실행 도구 비교 완전 가이드

2026년 8월 현재, 내 노트북과 내 서버에서 직접 대형 언어 모델을 돌리는 일은 더 이상 취미 개발자의 실험이 아닙니다. 사내 문서를 외부 API에 올릴 수 없는 기업, 월 수십만 원의 API 요금을 줄이려는 1인 개발자, 비행기 안에서도 코딩 어시스턴트를 쓰고 싶은 엔지니어 모두가 같은 질문 앞에 서 있습니다. “그래서 뭘로 돌려야 하죠?” 이 글은 그 질문에 답하기 위한 로컬 LLM 실행 도구 비교 가이드입니다. 2026년 8월 2일 기준 각 프로젝트의 공식 릴리스 페이지와 가격 페이지를 직접 확인한 데이터만으로 작성했습니다.

이 카테고리에서 실질적으로 선택지에 오르는 도구는 다섯 개입니다. 올라마(Ollama), LM 스튜디오(LM Studio), llama.cpp, vLLM, 그리고 Jan. GitHub 스타 수만 봐도 이 다섯이 시장을 나눠 갖고 있다는 게 드러납니다. 2026년 8월 2일 GitHub API로 직접 조회한 결과 올라마 177,543개, llama.cpp 122,385개, vLLM 87,913개, Jan 43,808개입니다. (LM 스튜디오는 앱 본체가 클로즈드 소스라 스타 수로 비교하면 안 됩니다. 공개된 것은 lms CLI와 SDK뿐이며 5,138개입니다.)

2026년 상반기에 이 시장에서 벌어진 가장 큰 변화는 세 가지입니다. 첫째, “로컬 전용 = 완전 무료”라는 공식이 깨졌습니다. 올라마는 Pro/Max/Team 유료 구독을, LM 스튜디오는 토큰 종량제 클라우드 크레딧을 각각 운영합니다. 둘째, 애플 실리콘에서 MLX 백엔드가 사실상 표준이 되었습니다. 올라마(0.19~), LM 스튜디오, Jan(0.7.7~)이 모두 채택했습니다. 셋째, 에이전트화입니다. 올라마 0.32.0은 ollama만 입력해도 에이전트가 실행되고, LM 스튜디오는 ‘Bionic’이라는 별도 에이전트 제품을 내놨습니다.

본 가이드에서는 다섯 도구의 최신 버전과 라이선스, 실측 벤치마크, 요금제, 하드웨어별 제약, 그리고 사용자 유형별 최종 추천까지 1만 자 이상의 분량으로 정리합니다. 특히 한국어 블로그 상당수가 아직 틀리게 적고 있는 여섯 가지 사실을 6장에서 바로잡습니다. 결론부터 말하면, 이 선택의 8할은 “혼자 쓰는가, 여러 명이 동시에 붙는가” 하나로 갈립니다.

1. Executive Summary: 2026년 8월 5대 로컬 LLM 도구 한눈에 보기

시간이 없는 분들을 위해 다섯 도구의 핵심 스펙을 한 표로 압축했습니다. 아래 표의 모든 버전·가격·라이선스는 2026년 8월 2일 공식 출처에서 직접 확인한 값입니다.

📊 2026년 8월 최신 5대 로컬 LLM 실행 도구 종합 비교표

이 표에서 가장 먼저 눈에 들어와야 하는 행은 동시 서빙 능력, 애플 실리콘 / MLX, 그리고 지원 모델 포맷 세 줄입니다. 실무에서 도구를 잘못 고르는 사고는 대부분 이 세 줄을 안 보고 시작한 데서 나옵니다. 맥북에서 vLLM을 깔려다 하루를 날리거나, 동시 요청이 수십 개로 늘어난 챗봇을 올라마 기본 설정으로 띄워놓고 왜 이렇게 느리냐고 묻는 경우가 전형적입니다.

특히 지원 모델 포맷 행은 이 카테고리에서 가장 크게 무는 락인 요소인데도 대부분의 비교 글에서 빠져 있습니다. 올라마·LM 스튜디오·llama.cpp·Jan은 모두 GGUF(+MLX) 생태계를 공유하지만, vLLM만 HF safetensors 계열(FP8·AWQ·GPTQ)이 주력이고 GGUF 지원은 본체에서 빠져 아웃오브트리 플러그인 vllm-gguf-plugin으로 이관된 실험 기능입니다. vLLM 공식 문서 문구 그대로 “highly experimental and under-optimized”이며, 토크나이저도 GGUF가 아니라 base model 쪽을 쓰라고 권고합니다. 즉 앞의 네 도구끼리는 모델 파일을 그대로 들고 이사할 수 있지만, vLLM으로 갈 때는 모델 라이브러리를 통째로 다시 조달해야 합니다.

2. 5대 로컬 LLM 실행 도구 비교: 핵심 기능 딥다이브

각 도구가 “무엇을 잘하려고 만들어졌는가”를 이해하면 선택이 훨씬 쉬워집니다. 다섯 도구는 경쟁 관계라기보다 서로 다른 레이어에 서 있습니다. 실제로 LM 스튜디오와 Jan은 내부적으로 llama.cpp를 엔진으로 쓰고, 올라마 역시 llama.cpp 계열 기술 위에서 출발했습니다.

🦙 1) 올라마 (Ollama) - CLI 한 줄로 끝나는 로컬 모델 런처 1위

• 압도적인 배포 편의성: ollama pull과 ollama run 두 명령으로 모델 다운로드부터 대화까지 끝납니다. 자체 모델 레지스트리를 운영해 도커 허브처럼 모델을 이름으로 당겨올 수 있고, GGUF 포맷을 지원합니다. GitHub 스타 177,543개로 5종 중 1위이며, 이 생태계 규모 자체가 올라마의 최대 자산입니다. 웬만한 서드파티 툴은 올라마 연동을 기본으로 지원합니다.
• 대화형 에이전트 도입 (v0.32.0, 2026년 7월 11일): 이제 ollama 명령만 실행하면 채팅·코딩·웹 검색·작업 위임이 가능한 에이전트가 뜹니다. 다만 기본 모델이 glm-5.2:cloud, 즉 클라우드 모델이라는 점은 반드시 알아야 합니다. “로컬 전용 도구”라는 이미지와 실제 기본 동작이 어긋나기 시작한 지점입니다.
• MLX 백엔드로 애플 실리콘 대응 (v0.19, 2026년 3월 30일): 애플 실리콘 성능이 대폭 개선됐습니다. 단, 공식 블로그가 MLX 프리뷰 릴리스의 조건으로 명시한 것이 통합 메모리 32GB 초과(“Please make sure you have a Mac with more than 32GB of unified memory”)입니다. 오해하기 쉬운 지점인데, 8GB·16GB 맥북에서 올라마가 안 도는 게 아니라 MLX 가속만 못 받는 것입니다. 그 이하 맥에서는 기존 Metal(llama.cpp) 경로로 정상 동작합니다. 이 조건을 “올라마는 32GB 이상 맥 전용”으로 옮겨 적는 글은 걸러야 합니다.
• 동시 요청 처리 설정: 공식 FAQ에 따르면 OLLAMA_NUM_PARALLEL이 “각 모델이 동시에 처리할 최대 병렬 요청 수, 기본값 1”이고, OLLAMA_MAX_LOADED_MODELS가 “동시에 로드 가능한 모델 수, 기본값 GPU 수 × 3”입니다. 즉 올라마에도 llama.cpp의 병렬 슬롯 디코딩이 그대로 노출돼 있으며, 기본값이 1이라 아무 설정도 안 하면 요청이 순차 처리된다는 것이 실제 상황입니다. 사내 챗봇이 느리다면 첫 조치는 도구 교체가 아니라 이 환경변수입니다.
• 구형 모델 지원 중단 경고 시작 (2026년 7월 11일): CodeLlama, Qwen2.5 및 Qwen2.5-coder, Llama 3.x, Mistral, StarCoder, DeepSeek-R1 기본 태그를 실행하면 deprecation 경고가 뜹니다. 2024~2025년에 작성된 한국어 튜토리얼을 그대로 따라 하면 경고를 보게 된다는 뜻이라, 지금 시작하는 분은 최신 모델 태그를 직접 확인하시길 권합니다.
• 꾸준한 엔진 개선: 투기적 디코딩(speculative decoding) 드래프트 모델을 지원하고 Qwen3 MoE 디코딩이 최적화됐습니다. 프롬프트 캐싱을 컨텍스트 시프팅과 분리해 응답 일관성 문제도 해결했습니다. v0.32.3에서는 윈도우 ARM64용 CUDA 지원이 추가됐고, v0.32.5에서는 NVFP4 모델(특히 Laguna) 출력 품질을 떨어뜨리던 MLX Metal 버그를 잡았습니다.

💠 2) LM 스튜디오 (LM Studio) - 터미널 없는 GUI 올인원 데스크톱 1위

• 이중 백엔드 내장: llama.cpp와 MLX 두 런타임을 모두 내장하고 있어, 받은 모델 포맷(GGUF / MLX)에 맞는 엔진으로 로드됩니다. 하드웨어를 보고 알아서 갈아타는 구조가 아니라는 점이 중요합니다. 맥이라면 MLX 포맷 모델을 받아야 MLX 엔진을 쓰게 되고, 맥에서 GGUF를 받으면 그대로 llama.cpp 경로로 돕니다. 어느 포맷을 받느냐가 곧 성능 차이로 이어지므로 다운로드 단계에서 한 번은 의식해야 합니다.
• 양자화 레벨 시각 선택: GUI 모델 브라우저에서 Q4_K_M, Q8 같은 양자화 레벨을 눈으로 보고 고를 수 있습니다. 내 램·VRAM에 맞는 버전이 무엇인지 감이 안 오는 초심자에게 이 UI 하나가 결정적입니다. 다른 도구에서는 파일명을 해석해가며 골라야 하는 작업입니다.
• 연속 배칭 기반 병렬 요청 (0.4.0, 2026년 1월 28일): 서버 배포 모드, 병렬 요청 처리, 신규 REST 엔드포인트, UI 개편이 한꺼번에 들어온 메이저 업데이트였습니다. 데스크톱 GUI 도구 중에서는 동시 처리에 가장 앞선 편이라, 소규모 팀 서버로 쓸 여지가 생겼습니다.
• llmster 헤드리스 데몬: GUI 없이 서버로만 돌릴 수 있는 데몬 컴포넌트로, Mac·Linux·Windows 설치 명령을 제공합니다. “GUI로 세팅하고 서버로 배포”라는 흐름이 가능합니다.
• 에이전트 제품 Bionic (2026년 7월 16일 발표): 오픈 모델 전용 AI 에이전트로 macOS·Windows 초기 프리뷰가 공개됐고, 7월 27일에는 Bionic에서 Kimi K3 구동이 지원됐습니다. 다만 Bionic Pass 가격은 공식 페이지가 “coming soon”이라고만 적어둔 미공개 상태입니다.
• 업무용 무료화 (2025년 7월 8일): 그 전에는 회사에서 쓰려면 별도 상업 라이선스를 받아야 했지만, 이제 폼 작성이나 문의 없이 직장에서 무료로 사용할 수 있습니다. 이 사실이 한국어권에 제대로 안 알려져 있습니다.

⚙️ 3) llama.cpp - 모든 것의 기반이 되는 순수 추론 엔진 1위

• GGUF 포맷의 원조: 16비트 가중치를 8·6·5·4·3·2비트로 양자화하는 생태계가 여기서 시작됐습니다. 일부 보고에 따르면 1비트급 양자화까지 등장해 초저사양 기기 대응 폭이 계속 넓어지고 있습니다. LM 스튜디오, Jan, 올라마가 모두 이 계보 위에 서 있습니다.
• 버전 번호가 없는 프로젝트: 시맨틱 버전 대신 빌드 태그(bXXXXX) 방식을 씁니다. 2026년 8월 2일 08:15 UTC 기준 최신 빌드는 b10226이지만, 빌드는 하루에도 여러 번 갱신됩니다(8월 1~2일에만 b10218, b10219, b10221, b10223, b10224가 나왔습니다). “llama.cpp 1.x 버전” 같은 표기는 애초에 존재하지 않습니다.
• llama-server의 기능 밀도: 기본 포트 8080에서 OpenAI 호환 API를 제공하며 /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models 엔드포인트를 지원합니다. base URL만 바꾸면 기존 OpenAI SDK 코드가 그대로 돕니다. 2026년 서버에는 병렬 디코딩(-np), OpenAI + Anthropic 이중 호환 채팅 라우트, 함수 호출, 투기적 디코딩, 실험적 멀티모달 입력, 임베딩·리랭킹 엔드포인트, 다중 모델 LRU 축출을 처리하는 라우터 모드, 웹 UI 내장 MCP 훅까지 들어 있습니다.
• 압도적인 백엔드 폭: CUDA, Metal, Vulkan, ROCm, SYCL, WebGPU를 지원하고 macOS·Linux·Android·Windows에서 모두 돕니다. 다섯 도구 중 하드웨어 커버리지는 llama.cpp가 독보적 1위입니다. 2026년 4월에는 퀄컴 Hexagon NPU 리눅스 지원이 들어가 스냅드래곤 노트북·엣지 기기까지 사정권에 들어왔다는 보고가 있습니다.
• --tools all 플래그: 이 플래그를 켜면 웹 UI에서 LLM이 로컬 파일 시스템에 직접 접근합니다. 강력한 만큼 위험하므로 신뢰할 수 없는 프롬프트를 다루는 환경에서는 절대 켜지 마시길 권합니다.

🚀 4) vLLM - 다중 사용자 프로덕션 서빙 처리량 1위

• PagedAttention: KV 캐시를 연속된 메모리 덩어리가 아니라 운영체제의 페이징처럼 고정 크기 블록으로 온디맨드 할당합니다. 원논문 계열 자료에 따르면 메모리 낭비가 최대 4배 감소하며, 그만큼 훨씬 큰 배치를 GPU에 올릴 수 있습니다. vLLM의 성능이 어디서 나오는지 묻는다면 답은 여기입니다.
• 연속 배칭(continuous batching): 배치 안의 시퀀스 하나가 끝나면 그 자리에 즉시 새 요청을 밀어 넣습니다. 전통적인 정적 배칭이 “가장 긴 요청이 끝날 때까지 GPU가 논다”는 문제를 안고 있던 것과 대조적입니다. 여기에 청크드 프리필(chunked prefill)과 Flash Attention이 결합됩니다.
• 살인적인 릴리스 속도: 2~4주 주기로 릴리스가 나옵니다. 2026년 5월 29일 v0.22.0 이후 6월 5일 0.22.1, 6월 13일 0.23.0, 6월 30일 0.24.0, 7월 11일 0.25.0, 7월 14일 0.25.1, 7월 25일 v0.26.0까지 두 달 남짓에 마이너 릴리스가 다섯 번 넘게 나왔습니다. 주의할 점은 2026년 8월 현재도 여전히 0.x 대라는 사실입니다. “vLLM 1.0”은 아직 존재하지 않습니다.
• 하드웨어 지원의 명확한 경계: GPU는 NVIDIA CUDA, AMD ROCm, Intel XPU를 지원하고 CPU는 x86, ARM AArch64, 애플 실리콘, IBM Z(S390X)까지 커버합니다. 그러나 애플 실리콘 GPU 가속은 vLLM-Metal이라는 별도 프로젝트를 통해서만 가능하며 본체 통합이 아닙니다. 더 중요한 건 윈도우가 공식 지원 목록에 없다는 점입니다. 커뮤니티 포크가 있다는 이야기는 있으나 공식이 아닙니다.
• 엔터프라이즈 채택의 방증: NVIDIA가 자체 최적화한 vLLM 릴리스 노트를 별도로 배포하고 있습니다(RN-11517-001_v26.06, 2026년 7월). 컨테이너 친화적 구조라 쿠버네티스 클러스터 배포에 잘 맞습니다. 이 부분이 궁금하다면 도커 vs 쿠버네티스 vs 포드맨 컨테이너 도구 비교 글을 함께 보시면 배포 그림이 명확해집니다.

🟣 5) Jan - 오픈소스 GUI + MCP 에이전트 1위

• 완전한 오픈소스 데스크톱: Windows·macOS·Linux 앱이며 라이선스는 Apache 2.0입니다. 여러 리뷰 사이트가 Jan을 AGPLv3나 MIT로 잘못 적고 있는데, 리포지토리 README에서 직접 확인한 결과 Apache 2.0이 맞습니다. 개발사는 Menlo Research이고 스타는 43,808개입니다. LM 스튜디오와 가장 큰 차이가 바로 이 지점, 즉 앱 본체가 오픈소스인가입니다.
• 특이한 포트 1337: OpenAI 호환 API를 localhost:1337에 띄웁니다. 올라마 11434, llama.cpp 8080과 헷갈리기 쉬우니 연동 설정할 때 정확히 기억해 두세요.
• MCP(Model Context Protocol) 지원: 인라인 MCP 툴 승인 UI를 제공해 에이전트가 어떤 도구를 언제 쓰는지 사용자가 그때그때 승인할 수 있습니다. 오픈소스 진영에서 에이전트 기능을 GUI로 가장 깔끔하게 붙인 축에 듭니다.
• 6개월간의 빠른 진화: v0.8.0(5월 22일) 다중 토큰 예측(MTP)과 llama.cpp 라우터 프로세스 통합, v0.8.1(5월 29일) Anthropic 호환 커스텀 프로바이더와 OS 네이티브 TLS 신뢰, v0.8.2(6월 1일) AMD ROCm/HIP 리눅스 백엔드와 다운로드 일시정지·재개, v0.8.3(6월 24일) 메시지 버전 분기 탐색과 HTML/SVG 아티팩트 미리보기·비디오 입력, v0.8.4(7월) 네이티브 web_search·web_fetch 툴과 자격증명 백엔드 저장소 이전이 순차적으로 들어왔습니다.
• 모델 조달의 자유: HuggingFace에서 GGUF 모델을 직접 내려받습니다(Llama, Gemma, Qwen, GPT-oss 등). 필요하면 OpenAI·Anthropic·Mistral·Groq·MiniMax 같은 클라우드 API도 연결할 수 있는데, 그 경우 요금은 해당 제공사에 직접 청구되며 Jan이 중간에서 받는 돈은 없습니다.

3. 처리량·지연·애플 실리콘 성능 벤치마크 대결

숫자로 들어가겠습니다. 여기서 중요한 건 “누가 빠른가”가 아니라 “어떤 조건에서 빠른가”입니다. 조건을 빼고 순위를 매기는 순간 그 벤치마크는 거짓말이 됩니다.

그래서 아래 별점표는 측정치가 아닙니다. 각 도구가 어떤 구조를 갖췄는지(PagedAttention·연속 배칭·병렬 슬롯의 유무)를 기준으로 매긴 정성 평가이며, 뒤에 나오는 실측 표와는 성격이 다릅니다. 별 개수를 tok/s 배수로 환산해 읽지 마세요.

[동시 요청이 몰릴 때의 총 처리량(Throughput) — 구조 기반 정성 평가]
vLLM              : ⭐⭐⭐⭐⭐ (PagedAttention + 연속 배칭 모두 보유)
llama.cpp         : ⭐⭐⭐⭐☆ (-np 병렬 슬롯 + 라우터 모드, PagedAttention은 없음)
LM 스튜디오        : ⭐⭐⭐☆☆ (0.4.0부터 연속 배칭, GUI 도구 중 1위)
올라마 (Ollama)    : ⭐⭐⭐☆☆ (OLLAMA_NUM_PARALLEL로 병렬 슬롯 가능, 단 기본값 1)
Jan               : ⭐⭐☆☆☆ (1인 1요청 데스크톱 사용에 최적화)

※ 올라마와 llama.cpp의 별점 차이는 "기능이 있느냐 없느냐"가 아니라
   기본값(올라마 1 슬롯) 및 PagedAttention 유무에서 옵니다. 올라마도
   환경변수 한 줄로 병렬 슬롯을 켤 수 있으나, 페이지드 KV 캐시가 없어
   슬롯을 늘릴수록 캐시 낭비가 커지고 곡선이 비교적 일찍 평탄해집니다.

[혼자 쓸 때(배치 크기 1)의 체감 응답 속도 — 구조 기반 정성 평가]
올라마 (Ollama)    : ⭐⭐⭐⭐⭐ (스케줄러 큐잉 오버헤드가 없어 첫 응답이 빠름)
llama.cpp         : ⭐⭐⭐⭐⭐ (직접 튜닝하면 상한이 가장 높음)
LM 스튜디오        : ⭐⭐⭐⭐☆ (MLX 포맷 모델 사용 시 맥에서 특히 유리)
Jan               : ⭐⭐⭐⭐☆ (네이티브 MLX 지원 이후 격차 축소)
vLLM              : ⭐⭐⭐☆☆ (단일 요청에서는 우위 없음, TTFT는 오히려 불리)

📈 3-1. 애플 실리콘: 올라마 MLX 백엔드 실측 (공식 1차 데이터)

가장 신뢰도가 높은 숫자는 올라마 공식 블로그가 공개한 MLX 벤치마크입니다. Apple M5 계열(M5 / M5 Pro / M5 Max, GPU Neural Accelerators 탑재), Qwen3.5-35B-A3B 모델 조건입니다.

디코드 기준 약 1.9~2.3배 향상입니다. 다만 이 표를 “올라마만 올리면 두 배”로 읽으면 안 됩니다. 열 제목을 다시 보세요. 0.18 열은 Q4_K_M이고 0.19 두 열은 NVFP4와 int4입니다. 즉 이 수치는 버전 업과 함께 NVFP4·int4 양자화 모델로 갈아탔을 때의 결과이며, 기존 Q4_K_M GGUF를 그대로 쓰면서 올라마 버전만 올리면 이만큼은 나오지 않습니다. 공식 블로그도 “Qwen3.5-35B-A3B를 NVFP4로 양자화한 것과, 0.18의 이전 구현에서 Q4_K_M으로 양자화한 것”을 비교했다고 조건을 밝혀두었습니다. 맥에서 이 향상을 실제로 보려면 올라마 업데이트 + 양자화 포맷 교체를 함께 해야 하고, 그 폭은 약 1.9~2.3배 범위로 이해하는 편이 정확합니다. 그리고 이 MLX 경로 자체가 통합 메모리 32GB 초과 맥에서만 열립니다. 16GB 맥북 에어에서는 올라마가 안 도는 게 아니라 기존 Metal 경로로 돌며, 이 표의 향상 폭이 적용되지 않을 뿐입니다.

📈 3-2. vLLM vs 올라마: 동시성이 만드는 격차

여러 벤치마크 자료에 따르면 NVIDIA A100에서 동시 요청 128개를 던졌을 때 vLLM은 약 793 tok/s, 올라마는 약 41 tok/s를 기록했고 P99 지연은 vLLM 80ms 대 올라마 673ms였다고 합니다. 동시 요청 8개에서는 vLLM 187 tok/s 대 올라마 82 tok/s(약 2.3배), 동시 사용자 64명 기준으로는 총 처리량이 약 8~9배 차이 났다고 보고됩니다.

이 숫자들은 앞의 올라마 MLX 표와 같은 급으로 취급하면 안 됩니다. 원 벤치마크 문서를 확인하지 못한 2차 출처인 데다, 모델·양자화·컨텍스트 길이·올라마 쪽 병렬 슬롯(OLLAMA_NUM_PARALLEL) 설정이 하나도 명시돼 있지 않습니다. 이 장의 첫 문장이 “조건을 빼고 순위를 매기면 그 벤치마크는 거짓말이 된다”였으니, 같은 잣대를 이 수치에도 대는 게 맞습니다. 특히 올라마 쪽이 기본값인 1슬롯 상태로 측정됐다면 8~9배 격차의 상당 부분은 구조 차이가 아니라 설정 차이일 수 있습니다. 정확한 배수를 인용하지 마시고, 방향성만 받아들이시길 권합니다. 자기 환경의 실제 숫자가 필요하다면 vllm bench serve와 올라마 쪽 동일 조건 측정을 직접 돌려 비교하는 편이 이 글의 어떤 인용값보다 정확합니다.

방향성 자체는 여러 출처가 일치하고 기술적으로도 타당합니다. 정리하면 세 문장입니다.

1. 배치 크기 1, 즉 혼자 쓸 때는 올라마와 vLLM의 tok/s가 사실상 같습니다. 차이는 한 자릿수에서 20% 수준이고, 오히려 올라마가 스케줄러 큐잉 오버헤드가 없어 첫 응답 지연(TTFT)은 더 빠른 경우가 많습니다.
2. 동시성이 올라가면 vLLM은 처리량이 매끄럽게 우상향하는 반면 올라마는 상대적으로 일찍 평탄해집니다. 다만 “올라마에는 병렬 처리 자체가 없다”는 건 사실이 아닙니다. OLLAMA_NUM_PARALLEL을 올리면 병렬 슬롯이 켜지고, 기본값 1에서 벗어나는 것만으로도 곡선이 상당히 달라집니다. 슬롯을 늘려도 남는 격차는 PagedAttention(페이지드 KV 캐시)과 연속 배칭의 유무에서 오며, 이쪽은 환경변수로 메울 수 없는 구조 차이입니다.
3. 따라서 결론은 **“혼자 쓰면 vLLM을 쓸 이유가 없고, 동시 요청이 수십 개 규모로 올라가면 vLLM 말고 답이 없다”**입니다. 그 사이 구간은 올라마의 병렬 슬롯 조정이나 llama.cpp -np, LM 스튜디오 0.4.0 이상의 연속 배칭으로 충분히 버틸 수 있습니다. 구체적인 기준선은 6장 팁 ⑧에 정리해 두었습니다.

📈 3-3. MLX vs llama.cpp, 그리고 맥 세대별 격차

맥 사용자에게는 백엔드 선택이 곧 성능입니다. 2차 출처 벤치마크에 따르면 MLX가 llama.cpp 대비 20~87% 우위이며, 짧은 컨텍스트 지속 처리량은 MLX 약 230 tok/s 대 llama.cpp 약 150 tok/s로 보고됩니다.

별도로 자주 인용되는 사례가 하나 더 있습니다. Mac mini M4 Pro(64GB)에서 Qwen3-Coder-30B-A3B를 돌렸을 때 MLX 약 130 tok/s 대 올라마(llama.cpp 백엔드) 43 tok/s로 약 3배 차이가 났다는 보고입니다. 이 3배는 위의 20~87% 밴드와 같은 것을 재고 있지 않습니다. 앞의 밴드는 순수 MLX 대 llama.cpp 비교이고, 3배 사례는 MLX 대 “올라마라는 런타임을 거친 llama.cpp”이므로 백엔드 차이 + 올라마 런타임 오버헤드가 합쳐진 단일 사례입니다. 두 숫자를 이어 붙여 “MLX는 3배”라고 일반화하면 과장이 됩니다.

하드웨어 세대 차이도 무시할 수 없습니다. llmcheck.net 집계에 따르면 M5 Max는 M4 Max 대비 약 +28% tok/s를 냅니다. Llama 3 8B Q4에서 M5 Max 82 tok/s 대 M4 Max 64 tok/s, Qwen 3.5 30B-A3B Q4에서 M5 Max 58 tok/s 대 M4 Max 45 tok/s입니다. 중형(1435B) 모델은 M4 Pro 24GB에서 3555 tok/s 수준이고, M5 Max 128GB의 메모리 대역폭은 약 600GB/s입니다. 로컬 LLM에서 성능을 결정하는 것은 GPU 코어 수보다 메모리 대역폭과 용량이라는 사실이 이 숫자들에 그대로 드러납니다.

여기서 실무적으로 도출되는 결론은 이렇습니다. 맥을 쓴다면 MLX를 지원하는 도구(올라마 0.19 이상, LM 스튜디오, Jan 0.7.7 이상)를 고르고 MLX 포맷 모델을 받으세요. 같은 하드웨어에서 백엔드만 바꿔도 **2087%(보고된 사례 대부분은 3050%대)**가 갈립니다. 위의 3배 사례처럼 더 크게 벌어지는 경우도 있지만, 그건 런타임 오버헤드까지 합쳐진 특수 사례이니 기대치는 밴드 쪽에 맞춰 잡는 편이 안전합니다. 반대로 NVIDIA GPU 서버라면 MLX는 무의미하고, 동시성 요구에 따라 올라마와 vLLM 중에서 고르면 됩니다.

4. 요금제 · 가격 완전 비교: 무료의 범위는 어디까지인가

2026년의 이 카테고리에서 가장 오해가 많은 영역입니다. 결론부터 말하면 다섯 도구 모두 로컬 실행 자체는 무료이고, 유료가 붙는 건 어디까지나 클라우드 추론 애드온입니다.

[2026년 8월 로컬 LLM 도구 요금 구조 요약]
- llama.cpp        : $0        (유료 티어·클라우드·구독 일절 없음. 순수 OSS)
- vLLM             : $0        (소프트웨어 무료, 비용은 전적으로 본인 GPU 인프라)
- Jan              : $0        (데스크톱 무료·구독 없음, 외부 API는 해당 제공사 과금)
- LM 스튜디오       : $0        (로컬·업무용 무료 / 클라우드는 토큰 종량제)
- 올라마 (Ollama)   : $0        (로컬 무제한 무료 / 클라우드 Pro 월 $20~)

💰 4-1. 올라마(Ollama) 공식 요금표

Max 플랜이 신규 가입을 막아둔 상태라는 점이 눈에 띕니다. 수요를 감당하지 못하고 있다는 신호로 읽히며, 지금 새로 시작하는 사용자에게 실질적인 선택지는 Free·Pro·Team 셋입니다. 참고로 원화 공식 가격표는 존재하지 않습니다. 국내 블로그에 적힌 “월 2만 원대” 같은 표기는 전부 환산 추정치이니 결제 전 실제 청구액은 카드사 환율로 확인하세요.

💰 4-2. LM 스튜디오(LM Studio) 요금 구조

클라우드 종량제 단가 (100만 토큰당, USD)

캐시 단가가 입력 대비 10분의 1 수준까지 떨어지는 구조라, 같은 시스템 프롬프트를 반복해 쓰는 워크로드라면 실질 비용이 크게 달라집니다. 클라우드 모델 단가 비교가 본격적으로 궁금하시다면 챗GPT vs 클로드 vs 제미나이 vs 딥시크 AI 모델 비교 글에서 프런티어 모델 쪽 가격 구조를 함께 확인하시길 권합니다.

💰 4-3. 진짜 비용은 요금표에 없다

여기가 핵심입니다. 로컬 LLM의 실질 비용은 소프트웨어 값이 아니라 하드웨어와 전기, 그리고 사람의 시간입니다.

첫째, 하드웨어 비용입니다. 여기서 흔히 두 가지를 섞어서 이야기하는데, 분리해야 합니다. 올라마의 MLX 가속을 쓰려면 통합 메모리 32GB 초과가 조건이지만, 그건 어디까지나 올라마 MLX 백엔드의 게이팅 조건일 뿐 30B급 모델의 하드웨어 요구 사양이 아닙니다. 30B급 모델 자체는 M4 Pro 24GB에서도 35~55 tok/s로 돌아갑니다(3-3 참조). 32GB 미만 장비가 이 성능 논의에서 탈락하는 게 아니라, 올라마의 MLX 경로만 못 쓰고 기존 Metal 경로로 돌아간다는 뜻입니다. 그렇더라도 로컬 LLM에서 성능을 결정하는 게 메모리 대역폭과 용량인 이상, 큰 모델을 여유 있게 굴리려면 통합 메모리가 넉넉한 맥이나 VRAM이 충분한 NVIDIA GPU에 돈이 든다는 사실은 그대로입니다. 월 $20짜리 구독을 아끼려고 수백만 원짜리 장비를 사는 것이 합리적인지는 사용 빈도에 달렸습니다.

여기에 잘 안 잡히는 비용이 하나 더 있습니다. 모델 포맷 전환 비용입니다. 올라마·LM 스튜디오·llama.cpp·Jan 사이에서는 GGUF 파일을 그대로 재활용할 수 있지만, vLLM으로 넘어가는 순간 GGUF 라이브러리가 따라오지 않습니다. vLLM의 GGUF 지원은 본체에서 빠져 아웃오브트리 플러그인으로 이관된 실험 기능이라, 실무에서는 HF safetensors(FP8·AWQ·GPTQ) 계열을 다시 받는 게 정석입니다. 모델 하나가 수 GB에서 수십 GB인 만큼 다운로드 시간·저장 공간·검증 시간이 전부 새로 듭니다. 토크나이저도 base model 쪽을 별도로 지정해야 합니다. “요금표에 없는 비용”을 이야기하면서 이 항목을 빠뜨리면 안 됩니다.

둘째, vLLM의 비용 구조는 특히 오해되기 쉽습니다. 소프트웨어는 완전 무료 Apache-2.0이지만, vLLM이 존재 이유를 발휘하려면 데이터센터급 GPU가 전제됩니다. 즉 vLLM의 실제 비용은 GPU 인스턴스 시간당 요금 전액입니다. 반대로 말하면, 그 GPU를 이미 갖고 있고 여러 사용자가 붙는 상황이라면 vLLM은 같은 하드웨어에서 처리량을 몇 배로 끌어올려 GPU 대당 단가를 낮추는 도구가 됩니다.

셋째, 운영 시간 비용입니다. llama.cpp는 소프트웨어 값이 0원이지만 빌드 옵션과 플래그를 직접 다뤄야 하고, 빌드 태그가 하루에도 여러 번 바뀌는 프로젝트라 “어느 빌드에서 잘 돌았는지”를 스스로 관리해야 합니다. 반면 LM 스튜디오는 설치 직후 바로 쓸 수 있습니다. 엔지니어 시급을 계산에 넣으면 무료 도구가 항상 가장 싼 도구는 아닙니다.

5. 사용자 유형별 최종 추천 가이드

지금까지의 로컬 LLM 실행 도구 비교 데이터를 바탕으로, 실제 상황별 최적 선택을 정리합니다. 이 장만 읽어도 결론은 나옵니다.

🎯 1) 로컬 LLM을 처음 써보는 비개발자 · 기획자 · 연구자

• 최적의 선택: LM 스튜디오 (LM Studio)
• 이유: 터미널을 한 번도 열 필요가 없고, GUI 모델 브라우저에서 양자화 레벨을 눈으로 보고 고를 수 있습니다. 무엇보다 2025년 7월 8일부터 업무용도 완전 무료라 회사 노트북에 설치해도 라이선스 문제가 없습니다. llama.cpp와 MLX 런타임을 모두 내장하고 있어 받은 모델 포맷에 맞는 엔진으로 로드되는데, 맥이라면 MLX 포맷 모델을 직접 골라 받아야 MLX 엔진을 쓰게 된다는 점만 기억하세요.

🎯 2) CLI가 편하고 여러 모델을 빠르게 갈아 끼우는 개인 개발자

• 최적의 선택: 올라마 (Ollama)
• 이유: ollama run 한 줄이면 끝이고, GitHub 스타 177,543개가 말해주듯 서드파티 연동 생태계가 압도적입니다. 배치 크기 1 환경에서는 vLLM 대비 처리량이 사실상 같으면서 첫 응답 지연은 오히려 더 빠른 경우가 많습니다. 단, 2024~2025년 튜토리얼의 모델 태그(Llama 3.x, Qwen2.5, Mistral 등)는 deprecation 경고 대상이니 최신 태그를 쓰세요.

🎯 3) 동시 요청이 10개를 넘어서는 사내 챗봇 · RAG API를 운영해야 하는 팀

• 최적의 선택: vLLM
• 이유: 이 구간부터는 대안이 마땅치 않습니다. PagedAttention으로 KV 캐시 낭비를 줄이고 연속 배칭으로 GPU 유휴 시간을 없애는 구조라, 동시 요청이 늘수록 처리량이 우상향합니다. 올라마도 OLLAMA_NUM_PARALLEL로 병렬 슬롯을 켤 수는 있지만 페이지드 KV 캐시가 없어 슬롯을 늘릴수록 캐시 낭비가 커지고 곡선이 먼저 평탄해집니다. 다만 윈도우는 공식 미지원, 애플 실리콘 GPU는 별도 vLLM-Metal 프로젝트 경유라는 제약, 그리고 기존 GGUF 모델 라이브러리를 그대로 못 가져간다는 전환 비용을 반드시 먼저 확인하세요. 사내 인원이 10명이어도 동시에 요청을 던지는 인원은 훨씬 적은 경우가 많으니, 기준은 “등록 사용자 수”가 아니라 피크 시점의 동시 요청 수로 잡아야 합니다.

🎯 4) 저사양 기기 · 엣지 디바이스 · 임베디드에 극한까지 밀어 넣어야 하는 엔지니어

• 최적의 선택: llama.cpp
• 이유: 백엔드 폭이 5종 중 압도적입니다. CUDA·Metal·Vulkan·ROCm·SYCL·WebGPU를 지원하고 macOS·Linux·Android·Windows에서 모두 돕니다. 8/6/5/4/3/2비트 양자화를 자유롭게 고를 수 있고, llama-server의 라우터 모드로 다중 모델을 LRU 축출하며 굴릴 수도 있습니다. 다른 도구가 못 도는 하드웨어에서 도는 유일한 선택지인 경우가 많습니다.

🎯 5) 오픈소스 원칙을 지켜야 하거나 MCP 에이전트를 실험하려는 사용자

• 최적의 선택: Jan
• 이유: 앱 본체가 Apache 2.0 오픈소스인 유일한 GUI 도구입니다. LM 스튜디오는 앱이 클로즈드 소스라 감사(audit)가 필요한 조직에서는 통과가 어렵습니다. Jan은 MCP 인라인 툴 승인 UI를 제공하고 v0.8.4에서 네이티브 web_search·web_fetch 툴까지 붙었습니다. AMD ROCm 리눅스 백엔드(v0.8.2)도 지원합니다.

🎯 6) 오프라인 환경에서 코딩 어시스턴트를 붙이고 싶은 개발자

• 최적의 선택: 올라마 또는 LM 스튜디오
• 이유: 두 도구 모두 외부 코딩 도구와의 연동 경로가 확보돼 있습니다. LM 스튜디오는 2026년 1월 30일부터 모델을 Claude Code에서 쓸 수 있고, 올라마는 v0.32.3에서 Claude Code Channels 연동을 복구했으며 ollama launch chatgpt로 Codex App(명칭 변경 후 ChatGPT) 연동도 제공합니다. 클라우드 기반 코딩 에이전트와의 성능 차이가 궁금하시다면 커서 vs 깃허브 코파일럿 vs 클라인 AI 코딩 에이전트 비교 글을 함께 읽어보시길 권합니다.

🎯 7) 회사 보안 정책상 데이터가 기기 밖으로 나가면 안 되는 경우

• 최적의 선택: llama.cpp 또는 Jan (차선: 올라마 로컬 전용 설정)
• 이유: 다섯 도구 모두 완전 오프라인 동작이 가능하지만, 클라우드 연결 요소가 아예 없는 것은 llama.cpp뿐입니다. Jan도 데스크톱 자체는 구독·과금이 없고 로컬 우선 설계입니다. 올라마를 쓴다면 v0.32.0 에이전트의 기본 모델이 glm-5.2:cloud, 즉 클라우드 모델이라는 점을 반드시 확인하고 로컬 모델을 명시적으로 지정하세요. 팀 단위로 계약한다면 Team 플랜이 제로 데이터 리텐션·무로깅을 명시합니다.

6. 실전 활용 팁 & 흔한 실수 (한국어 블로그가 틀리게 적고 있는 것들)

이 장이 이 글에서 가장 실용적인 부분입니다. 조사 과정에서 확인한, 현재 한국어 자료 상당수가 잘못 적고 있는 사실 여섯 가지와 실전 팁을 정리했습니다.

① “LM 스튜디오는 회사에서 쓰려면 상업 라이선스가 필요하다” → 틀렸습니다. 2025년 7월 8일부로 상업적 사용 라이선스 요구가 폐지됐습니다. 이제 폼 작성이나 별도 문의 없이 직장에서 무료로 사용할 수 있습니다. 그런데 아직도 다수 한국어 블로그가 옛 정책을 그대로 적고 있어, 이것 때문에 LM 스튜디오를 후보에서 뺀 팀이 실제로 있습니다. 사내 도입 검토 중이라면 이 항목부터 정정하세요.

② “Jan은 AGPLv3다” → 틀렸습니다. Apache 2.0입니다. 여러 리뷰 사이트가 AGPLv3 또는 MIT로 적어놨지만, 리포지토리 README에서 직접 확인한 라이선스는 Apache 2.0입니다. AGPL은 네트워크 서비스로 배포할 때 소스 공개 의무가 따라붙어 기업 법무 검토에서 자주 걸리는 라이선스인데, Jan은 여기 해당하지 않습니다. 라이선스 때문에 Jan을 포기했다면 다시 검토해 보실 만합니다.

③ “vLLM 1.0이 나왔다” → 아직 없습니다. 2026년 8월 현재 최신은 v0.26.0이고 여전히 0.x 대입니다. 2~4주 주기로 릴리스가 쏟아지는 프로젝트라 버전 고정(pinning)이 사실상 필수입니다. requirements.txt에 vllm만 적어두면 두 주 뒤 팀원의 환경과 내 환경이 달라집니다. 정확한 버전을 박아두고, 올릴 때는 릴리스 노트를 읽고 올리세요.

④ “올라마는 완전 무료 로컬 전용 도구다” → 2026년에는 절반만 맞습니다. 로컬 실행은 여전히 무제한 무료지만, Pro 월 $20 등 클라우드 구독이 존재하고 **v0.32.0의 기본 에이전트 모델이 클라우드 모델(glm-5.2:cloud)**입니다. 무심코 ollama만 입력하고 사내 데이터를 붙여 넣으면 그 데이터가 외부로 나갈 수 있다는 뜻입니다. 보안이 중요한 환경에서는 첫 세팅 때 로컬 모델을 명시적으로 지정하는 습관을 들이세요.

⑤ “llama.cpp 최신 버전은 1.x다” → 그런 버전 체계 자체가 없습니다. llama.cpp는 시맨틱 버전을 쓰지 않고 **빌드 태그(bXXXXX)**만 씁니다. 2026년 8월 2일 기준 b10226이지만 내일이면 다릅니다. 실무 팁은 **“동작을 확인한 빌드 태그를 기록해 두고 그 태그를 체크아웃해 쓰는 것”**입니다. 매번 master를 당겨 쓰면 어제 되던 플래그가 오늘 안 되는 일이 생깁니다.

⑥ “MLX만 켜면 맥에서 두 배 빨라진다” → 조건이 두 개나 붙습니다. 첫째, 올라마의 MLX 프리뷰 백엔드는 통합 메모리 32GB를 초과하는 맥이 전제입니다. 다만 이걸 “16GB 맥에서는 올라마를 못 쓴다”로 옮겨 적으면 틀립니다. 그 이하 맥에서도 올라마는 기존 Metal(llama.cpp) 경로로 정상 동작하며, MLX 가속만 못 받습니다. 둘째, 공식 블로그의 1.92.3배 수치는 버전 업만의 효과가 아니라 NVFP4·int4 양자화 모델로 갈아탄 결과입니다. Q4_K_M을 그대로 쓰면서 버전만 올리면 그 폭은 나오지 않습니다. 16GB 이하 맥이라면 78B급 소형 모델과 Q4 양자화를 기준으로 계획을 잡되, 도구를 바꾸기보다 모델 크기와 포맷을 먼저 조정하는 게 순서입니다.

⑦ 포트 번호를 외워두면 연동 삽질이 절반으로 줄어듭니다. 올라마 11434, llama.cpp llama-server 8080, Jan 1337입니다. 세 도구 모두 OpenAI 호환 API를 제공하므로, 기존 OpenAI SDK 코드에서 base URL만 바꾸면 그대로 동작합니다. 새 클라이언트를 만들 필요가 없습니다. llama.cpp는 여기에 더해 Anthropic 호환 채팅 라우트까지 제공하므로, Anthropic SDK 기반 코드도 재활용할 수 있습니다.

⑧ “피크 시점의 동시 요청이 몇 개인가”를 먼저 답하고 도구를 고르세요. (이 글의 단일 기준선) 가장 흔한 설계 실수는 순서를 거꾸로 밟는 것입니다. 사내 서비스에 올라마를 띄워놓고 느려지자 GPU를 증설하는 팀을 종종 봅니다. 그런데 첫 조치가 GPU 증설도, vLLM 마이그레이션도 아닙니다. 올라마 공식 FAQ 기준 OLLAMA_NUM_PARALLEL의 기본값은 1입니다(각 모델이 동시에 처리하는 최대 병렬 요청 수). 즉 아무 설정도 안 한 올라마는 요청을 사실상 한 줄로 세워 처리하고 있고, 이 상태의 느림은 하드웨어 문제가 아니라 환경변수 문제입니다. OLLAMA_MAX_LOADED_MODELS도 기본값이 GPU 수 × 3이라 함께 봐 둘 값입니다.

그래서 처방은 2단계입니다. (1) 먼저 OLLAMA_NUM_PARALLEL을 올려 보고, (2) 그래도 곡선이 살아나지 않으면 vLLM으로 갑니다. 순서를 바꾸면 필요 없는 마이그레이션에 모델 재조달 비용까지 얹게 됩니다. 남는 격차는 PagedAttention과 연속 배칭의 부재에서 오는 것이라 슬롯 수로는 못 메웁니다.

이 글은 아래 기준선을 모든 장에서 동일하게 씁니다. 판단 기준은 등록 사용자 수가 아니라 피크 시점의 동시 요청 수입니다.

[동시 요청 수 기준 단일 결정 기준선]
동시 요청 1~4개    → 올라마(NUM_PARALLEL 조정) · LM 스튜디오 · Jan
동시 요청 5~10개   → llama.cpp -np 병렬 디코딩 · LM 스튜디오 0.4.0+ 연속 배칭
동시 요청 10개 초과 → vLLM
또는 SLA가 걸린 서비스

⑨ 모델 태그의 deprecation 경고를 무시하지 마세요. 2026년 7월 11일부터 올라마는 CodeLlama, Qwen2.5·Qwen2.5-coder, Llama 3.x, Mistral, StarCoder, DeepSeek-R1 기본 태그에 지원 중단 경고를 띄웁니다. 튜토리얼을 복붙해서 이 경고를 보고 있다면, 그 튜토리얼 자체가 최소 1년은 지난 자료라는 신호입니다. 다른 내용도 낡았을 가능성이 큽니다.

⑩ --tools all은 신뢰 경계를 무너뜨립니다. llama.cpp의 이 플래그를 켜면 웹 UI에서 LLM이 로컬 파일 시스템에 직접 접근합니다. 개인 실험용으로는 강력하지만, 외부에서 온 문서나 웹 페이지를 모델에 먹이는 파이프라인에서는 프롬프트 인젝션이 곧 파일 접근으로 이어집니다. 외부 입력을 다루는 환경에서는 켜지 마세요.

⑪ vLLM으로 갈아탈 계획이라면 모델 재조달 비용을 미리 계산하세요. “OpenAI 호환 API니까 base URL만 바꾸면 된다”는 말은 클라이언트 코드에만 해당합니다. 모델 자산은 따라오지 않습니다. 올라마·LM 스튜디오·llama.cpp·Jan은 GGUF(+MLX) 생태계를 공유하지만, vLLM은 HF safetensors(FP8·AWQ·GPTQ) 계열이 주력이고 GGUF 지원은 본체에서 빠져 아웃오브트리 플러그인 vllm-gguf-plugin으로 이관된 실험 기능입니다. 공식 문서 표현 그대로 “highly experimental and under-optimized”이며 다른 기능과 충돌할 수 있고, 토크나이저도 GGUF가 아니라 base model 것을 따로 지정하라고 권고합니다. 그러니 마이그레이션 계획서에는 반드시 이 세 줄을 넣으세요. (1) 다시 받아야 할 모델 목록과 총 용량, (2) 다운로드·검증에 드는 시간, (3) 양자화 포맷을 바꾸면서 품질을 다시 확인해야 하는 항목. 실제로 도구 전환에서 가장 크게 무는 비용이 여기입니다.

7. 자주 묻는 질문 (FAQ)

Q. 로컬 LLM 실행 도구 비교에서 결국 1등은 무엇인가요?

절대적 1등은 없고, 조건별 1등만 있습니다. 혼자 쓰는 개발자는 올라마, GUI가 필요하면 LM 스튜디오, 다중 사용자 서빙은 vLLM, 극한 하드웨어 대응은 llama.cpp, 오픈소스 원칙과 MCP 에이전트는 Jan입니다. 굳이 “가장 무난한 하나”를 꼽으라면 생태계 규모(GitHub 스타 177,543개)와 사용 편의를 함께 갖춘 올라마가 첫 선택으로 무난합니다.

Q. 올라마와 vLLM 중에 뭐가 더 빠른가요?

조건에 따라 답이 뒤집힙니다. 혼자 쓰는 배치 크기 1 환경에서는 두 도구의 tok/s가 사실상 같고, 오히려 올라마가 스케줄러 큐잉 오버헤드가 없어 첫 응답이 더 빠른 경우가 많습니다. 반면 동시 요청이 늘어나면 vLLM은 처리량이 계속 올라가는 반면 올라마는 상대적으로 일찍 평탄해집니다. 다만 올라마를 “동시 처리 기능이 없는 도구”로 오해하진 마세요. 공식 FAQ의 OLLAMA_NUM_PARALLEL이 병렬 슬롯 수를 정하며 기본값이 1이라, 느리다고 느끼는 상당수는 이 값을 안 올린 상태입니다. 남는 격차는 PagedAttention과 연속 배칭의 부재에서 옵니다. “빠르다”를 처리량으로 정의하느냐 응답 지연으로 정의하느냐부터 정하고 비교하셔야 합니다.

Q. LM 스튜디오는 회사에서 무료로 써도 되나요?

네, 됩니다. 2025년 7월 8일부로 상업적 사용 라이선스 요구가 폐지되어 별도 폼 작성이나 문의 없이 직장에서 무료로 쓸 수 있습니다. 무료 플랜에서 로컬 LLM 실행, 오프라인 음성 전사, Bionic 에이전트, llama.cpp·MLX 백엔드, LM Link 최대 5대 기기까지 제공됩니다. 아직 “업무용은 별도 라이선스 필요”라고 적힌 글을 보셨다면 그 글이 오래된 것입니다.

Q. 맥북에서 로컬 LLM을 쓰려는데 어떤 도구가 좋나요?

맥이라면 MLX 백엔드를 지원하는 도구가 정답입니다. 올라마(0.19 이상), LM 스튜디오, Jan(0.7.7 이상)이 모두 MLX를 지원합니다. 다만 올라마의 MLX 프리뷰 백엔드는 통합 메모리 32GB 초과가 조건입니다. 여기서 오해가 잦은데, 16GB 맥에서 올라마가 안 되는 게 아니라 MLX 가속만 못 받는 것이고, 기존 Metal(llama.cpp) 경로로는 정상 동작합니다. LM 스튜디오와 Jan은 MLX 사용에 이런 메모리 게이팅 조건을 공식적으로 걸어두지 않았지만, 메모리 한도 자체는 어느 도구를 쓰든 똑같이 적용됩니다. 16GB 맥이라면 도구와 무관하게 7~8B급 Q4 모델이 현실적인 상한이고, 14B 이상은 컨텍스트를 줄여도 빠듯합니다. 즉 16GB 맥의 선택지는 “올라마냐 아니냐”가 아니라 **“어떤 크기·포맷의 모델을 올릴 것이냐”**입니다. vLLM은 맥에 권하지 않습니다 — 애플 실리콘 GPU 지원이 별도 vLLM-Metal 프로젝트를 통해서만 가능하고 본체 통합이 아닙니다.

Q. 윈도우에서 vLLM을 쓸 수 있나요?

공식적으로는 불가능합니다. vLLM 공식 설치 문서의 지원 하드웨어 목록에 윈도우가 없습니다. 커뮤니티 포크가 존재한다는 이야기는 있으나 공식 지원이 아니므로 프로덕션에 쓰기엔 위험합니다. 윈도우에서 다중 사용자 서빙이 필요하다면 6장 팁 ⑧의 기준선을 그대로 적용하세요. 동시 요청 10개 초과 구간이라면 WSL2 또는 리눅스 서버에 vLLM을 올리는 구성이 현실적이고, 5~10개 구간이라면 연속 배칭을 지원하는 LM 스튜디오 0.4.0 이상이나 llama.cpp의 -np 병렬 디코딩으로 윈도우에서도 충분히 감당됩니다. 1~4개 구간이면 올라마의 OLLAMA_NUM_PARALLEL을 올리는 것만으로 해결되는 경우가 많습니다.

Q. 로컬 LLM 도구는 전부 무료인가요? 숨은 비용은 없나요?

로컬 실행 자체는 다섯 도구 모두 무료입니다. llama.cpp, vLLM, Jan은 유료 티어가 아예 없고, 올라마와 LM 스튜디오는 클라우드 추론 애드온에만 과금합니다(올라마 Pro 월 $20, LM 스튜디오 토큰 종량제). 진짜 비용은 하드웨어와 전기, 운영 시간, 그리고 모델 재조달입니다. 여기서 자주 섞이는 게 32GB 이야기인데, 통합 메모리 32GB 초과는 올라마 MLX 백엔드의 조건이지 30B급 모델의 요구 사양이 아닙니다. 30B급 자체는 M4 Pro 24GB에서도 35~55 tok/s로 돌아갑니다. 물론 큰 모델을 여유 있게 굴리려면 메모리 용량과 대역폭에 돈이 들고, vLLM은 사실상 데이터센터 GPU 요금이 전부입니다. 마지막으로 vLLM으로 옮길 때는 GGUF 모델 라이브러리를 그대로 못 가져가므로, 수십 GB를 다시 받는 시간과 저장 공간도 비용에 넣어야 합니다.

Q. LM 스튜디오와 Jan은 뭐가 다른가요?

둘 다 GUI 우선 데스크톱 도구지만 결정적 차이는 오픈소스 여부입니다. LM 스튜디오는 앱 본체가 클로즈드 소스이고 GitHub에 공개된 것은 lms CLI와 SDK뿐입니다. 반면 Jan은 앱 전체가 Apache 2.0입니다. 기능 면에서는 LM 스튜디오가 양자화 시각 선택 UI와 연속 배칭 병렬 요청에서 앞서고, Jan은 MCP 인라인 툴 승인과 네이티브 web_search·web_fetch 툴 등 에이전트 쪽에 강점이 있습니다. 감사가 필요한 조직이면 Jan, 편의성 우선이면 LM 스튜디오입니다.

Q. llama.cpp는 버전을 어떻게 확인하나요?

시맨틱 버전이 없습니다. 대신 bXXXXX 형태의 빌드 태그를 씁니다. 2026년 8월 2일 08:15 UTC 기준 최신 빌드는 b10226이지만, 8월 1~2일에만 b10218·b10219·b10221·b10223·b10224가 연달아 나왔을 만큼 갱신이 잦습니다. 실무에서는 정상 동작을 확인한 빌드 태그를 기록해 두고 그 태그를 고정해 쓰는 것을 권합니다.

Q. 기존 OpenAI API 코드를 로컬 모델로 그대로 옮길 수 있나요?

네, 대부분 가능합니다. 다섯 도구 모두 OpenAI 호환 API를 제공하므로 SDK의 base URL만 로컬 주소로 바꾸면 됩니다. 포트는 올라마 11434, llama.cpp llama-server 8080, Jan 1337이고, LM 스튜디오와 vLLM도 각각 호환 서버를 제공합니다. llama.cpp는 /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models를 지원하며 Anthropic 호환 채팅 라우트까지 갖추고 있어 이식성이 특히 좋습니다.

8. 결론: 2026년 로컬 LLM 실행 도구 비교, 결국 두 가지 질문으로 끝난다

지금까지 다섯 도구를 버전·라이선스·성능·가격·하드웨어 제약까지 훑었지만, 실제 의사결정은 놀랍도록 단순합니다. **첫 번째 질문은 “피크 시점에 동시 요청이 몇 개인가”**입니다. 14개면 올라마(OLLAMA_NUM_PARALLEL 조정)·LM 스튜디오·Jan 중에서 취향껏 고르면 되고, 510개면 llama.cpp -np나 LM 스튜디오의 연속 배칭이 유효 사거리이며, 10개를 넘거나 SLA가 걸린 서비스라면 vLLM입니다. 마지막 구간에서 남는 격차는 환경변수로 좁히기 어렵습니다. PagedAttention과 연속 배칭이라는 구조의 유무에서 오는 차이이기 때문입니다(다만 이 구간 경계는 모델 크기·컨텍스트 길이·SLA에 따라 움직이니, 자기 환경에서 한 번은 측정해 보시길 권합니다). **두 번째 질문은 “터미널을 열 수 있는가”**입니다. 열 수 있으면 올라마와 llama.cpp가 열리고, 못 열거나 열기 싫으면 LM 스튜디오와 Jan이 남습니다.

2026년 상반기를 지나며 이 카테고리가 확실히 성숙했다는 신호도 분명합니다. 애플 실리콘에서는 MLX가 표준으로 자리 잡아 같은 하드웨어에서 디코드 처리량이 크게 올랐고(올라마 공식 벤치마크 기준 0.18의 Q4_K_M 58 tok/s → 0.19의 int4 134 tok/s, 단 버전 업과 양자화 포맷 교체가 함께 이뤄진 결과), 다섯 도구 모두 OpenAI 호환 API를 제공하게 됐습니다. 여기서 딱 한 가지는 정확히 짚고 넘어가야 합니다. API 호출 코드는 base URL 한 줄이면 되지만, 모델 자산은 따라오지 않습니다. 앞의 네 도구끼리는 GGUF 파일을 그대로 들고 이사할 수 있어 전환이 정말 가볍지만, GGUF 라이브러리는 vLLM으로 그대로 넘어가지 않습니다(본체에서 빠져 실험적 아웃오브트리 플러그인으로 이관). vLLM행을 염두에 두고 있다면 모델 재조달 시간과 저장 공간을 처음부터 계획에 넣으세요.

동시에 경계해야 할 흐름도 생겼습니다. “로컬 도구 = 완전 무료 = 데이터가 절대 안 나감”이라는 등식이 더는 자동으로 성립하지 않습니다. 올라마 v0.32.0 에이전트의 기본 모델은 클라우드 모델이고, LM 스튜디오도 클라우드 크레딧을 운영합니다. 프라이버시가 도입 사유였다면 첫 세팅에서 로컬 모델을 명시적으로 지정했는지 반드시 확인하시고, 조직 차원이라면 클라우드 연결 요소가 아예 없는 llama.cpp나 오픈소스 GUI인 Jan을 우선 검토하시길 권합니다.

요약: 내 상황에 맞는 최종 추천

┌─ 피크 시점의 동시 요청이 10개를 넘는가? (또는 SLA가 걸린 서비스인가?)
│   └─ YES → vLLM (v0.26.0)
│            ※ 윈도우 공식 미지원, 맥 GPU는 별도 vLLM-Metal
│            ※ 소프트웨어는 무료, 비용은 GPU 인프라 전액
│            ※ GGUF 라이브러리는 못 가져감 → 모델 재조달 비용 계산 필수
│
├─ 동시 요청 5~10개인가?
│   └─ YES → llama.cpp -np 병렬 디코딩 (b10226, MIT)
│            또는 LM 스튜디오 0.4.0+ 연속 배칭 (0.4.20)
│            ※ 윈도우에서 다중 사용자 서빙이 필요할 때 특히 현실적
│
└─ NO (동시 요청 1~4개 / 사실상 혼자 쓴다)
    │
    ├─ 터미널이 편한가?
    │   ├─ YES ─┬─ 무난한 첫 선택       → 올라마 (v0.32.5, MIT)
    │   │       │                        ※ 느리면 먼저 OLLAMA_NUM_PARALLEL(기본 1)부터
    │   │       │                        ※ 맥 MLX 프리뷰는 통합 메모리 32GB 초과 필요
    │   │       │                          (그 이하는 기존 Metal 경로로 정상 동작)
    │   │       │                        ※ 에이전트 기본 모델이 클라우드임에 주의
    │   │       └─ 하드웨어 극한 튜닝    → llama.cpp (b10226, MIT)
    │   │                                ※ 백엔드 최다, 유료 요소 전무
    │   │
    │   └─ NO ──┬─ 편의성 최우선        → LM 스튜디오 (0.4.20)
    │           │                        ※ 2025-07-08부터 업무용도 무료
    │           │                        ※ 맥이면 MLX 포맷 모델을 직접 골라 받을 것
    │           │                        ※ 단, 앱 본체는 클로즈드 소스
    │           └─ 오픈소스·MCP 필수     → Jan (v0.8.4, Apache 2.0)
    │                                    ※ API 포트 1337, 완전 무료
    │
    └─ 데이터가 절대 밖으로 나가면 안 된다면
        → llama.cpp (클라우드 요소 전무) 또는 Jan
        → 올라마/LM 스튜디오 사용 시 로컬 모델 명시 지정 필수

[포트 치트시트] 올라마 11434 · llama.cpp 8080 · Jan 1337
[가격 치트시트] 로컬은 전부 $0 / 올라마 Pro $20·Team $25(시트)
                LM 스튜디오 클라우드는 토큰 종량제
[포맷 치트시트] 올라마·LM 스튜디오·llama.cpp·Jan = GGUF(+MLX) 공유
                vLLM = HF safetensors·FP8·AWQ·GPTQ (GGUF는 실험적 플러그인)

로컬 LLM은 이제 “되는가”의 문제가 아니라 “무엇으로, 어떤 조건에서 돌릴 것인가”의 문제가 됐습니다. 위 치트시트를 기준으로 오늘 바로 하나를 골라 설치해 보세요. GGUF 생태계 안(올라마·LM 스튜디오·llama.cpp·Jan)에서라면 base URL 한 줄로 언제든 갈아탈 수 있고, vLLM으로 넘어갈 때만 모델을 새로 조달하면 됩니다. 🚀