올라마(Ollama)·llama.cpp·LM Studio 차이 — 같은 엔진, 다른 기본값

Ollama와 LM Studio는 둘 다 llama.cpp로 GGUF 모델을 돌리므로, 한쪽이 더 느리다면 대개 기본 설정이 달라서입니다. 컨텍스트를 얼마나 잡는지, 동시 요청이 메모리를 어떻게 나눠 쓰는지, GPU 배치를 누가 정하는지가 다릅니다. 예를 들어 24GB 카드에서 Ollama는 Qwen3 32B를 32k로 띄웁니다. CanRun 계산으로는 이때 모델 일부가 시스템 RAM으로 밀려납니다(ollama ps로 확인). llama.cpp 서버는 컨텍스트를 지정하지 않으면 길이를 줄여서 모델을 GPU에 남깁니다. 세 도구를 나란히 잰 속도 데이터는 없어서, 이 글은 어느 쪽이 빠른지가 아니라 설정을 비교합니다.

엔진은 하나, 겉모습은 셋

llama.cpp는 MIT 라이선스로 공개된 오픈소스 엔진입니다. GGUF 파일을 읽어 NVIDIA·AMD·Intel·Apple GPU나 CPU에서 돌립니다. 여러 명령줄 프로그램으로 배포됩니다. llama-server는 브라우저 채팅 화면과 OpenAI 호환 API를 띄웁니다. llama-bench는 속도를 재는 도구입니다. Windows에서는 GitHub 릴리스 페이지에서 미리 빌드된 파일을 받습니다. 그다음 GGUF 파일을 지정하거나, -hf로 Hugging Face에서 바로 받습니다.

Ollama는 백그라운드 서비스, 명령줄 도구, 데스크톱 앱, 자체 모델 라이브러리로 이뤄져 있습니다. 라이선스는 역시 MIT입니다. 0.30부터 Ollama는 GGUF 모델을 llama.cpp의 llama-server로 돌립니다. 설치 폴더에 함께 들어 있는 llama-server를 옵션 몇 개만 붙여 띄우는 방식입니다. 어떤 llama.cpp 빌드를 넣었는지는 소스의 LLAMA_CPP_VERSION 파일에 적혀 있습니다. Apple Silicon에서는 일부 모델에 MLX 엔진도 씁니다. 라이브러리 모델은 태그로 부릅니다. Ollama 태그 목록을 보면 qwen3:14b는 qwen3:14b-q4_K_M과 같은 파일입니다.

LM Studio는 모델 검색, 로컬 서버, 명령줄 도구 lms를 갖춘 데스크톱 앱입니다. LM Studio는 집에서도 회사에서도 무료로 쓸 수 있다고 밝히고 있습니다. GGUF 모델은 자체 llama.cpp 엔진으로 돌리고, CUDA·Vulkan·ROCm·CPU용 빌드가 따로 있습니다. 맥에서는 MLX 엔진도 씁니다. LM Studio는 이 엔진들을 ‘런타임’이라고 부르며, 기본 설정에서는 저절로 업데이트합니다. 런타임 탭이나 lms runtime에서 쓸 런타임을 바꿀 수도 있습니다.

llama.cpp가 바뀐 내용은 Ollama와 LM Studio가 안에 든 llama.cpp 빌드를 새 버전으로 바꿔야 들어옵니다. 세 도구 모두 같은 GGUF 파일을 읽고 OpenAI 호환 API를 제공합니다. 그래서 이 API를 쓰는 채팅 앱이나 코딩 도구는 대개 셋 중 어디에나 붙일 수 있습니다. 컨텍스트 길이와 KV 캐시 종류가 같으면 가중치와 KV 캐시에 드는 메모리도 셋이 같습니다. 연산 버퍼(계산 중에 쓰는 작업 공간)만 배치 설정에 따라 달라지는데, Ollama는 이 값을 다르게 고릅니다(아래 목록 참고). 메모리를 계산하는 법은 ‘로컬 LLM 사양 — VRAM 8~32GB로 돌릴 수 있는 모델 (2026)’ 가이드에 있습니다. CanRun 수치도 llama.cpp로 GGUF 파일을 돌리는 경우를 계산한 값입니다. 맥에서 MLX 엔진으로 돌리는 모델은 llama.cpp를 거치지 않아서 이 글에서 다루지 않습니다.

서로 다른 기본값

같은 카드에 같은 파일을 올려도 세 도구는 출발점이 다릅니다. 메모리나 속도를 바꾸는 기본값은 다음과 같습니다.

• 컨텍스트 길이: Ollama는 감지한 GPU 메모리가 24GiB 미만이면 4k, 24~48GiB면 32k, 48GiB 이상이면 256k 토큰을 기본 컨텍스트 길이로 씁니다 (Ollama 문서, 2026-09-29 확인). 어떤 값을 골랐는지는 서버 로그의 vram-based default context 줄에 남습니다. llama-server는 -c 없이 띄우면 GGUF 파일에 적힌 학습 컨텍스트로 시작합니다. 이 값은 보통 모델의 최대 길이와 같습니다. 모델이 빈 VRAM에 안 들어가면, 기본으로 켜진 fit 기능이 컨텍스트를 줄입니다. 4k까지 줄여도 모자랄 때만 가중치를 GPU 밖으로 옮깁니다. -c 0을 주면 최대 길이를 그대로 쓰고 줄이지 않습니다. LM Studio는 불러오기 설정이나 lms load --context-length의 값을 씁니다. 문서에 기본값이 나와 있지 않으니 불러오기 화면에서 값을 확인합니다.
• 컨텍스트가 가득 찼을 때: Ollama는 오래된 메시지부터 버리고 계속 답합니다. 자세한 동작은 ‘올라마(Ollama)가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값’ 가이드에 있습니다. llama-server는 컨텍스트 시프트가 기본으로 꺼져 있습니다. 그래서 컨텍스트보다 긴 요청에는 오류를 돌려주고, 답을 쓰다 컨텍스트가 차면 멈춥니다. LM Studio에서는 한도에서 멈추기, 대화 가운데 잘라 내기, 최근 대화만 남기기 중에 고를 수 있습니다.
• KV 캐시 종류: 셋 다 f16으로 시작하고, 셋 다 양자화할 수 있습니다. Ollama는 서버를 띄울 때 OLLAMA_KV_CACHE_TYPE(f16·q8_0·q4_0)을 지정하고 플래시 어텐션을 켜야만 KV 캐시를 양자화합니다. 이 설정은 그 서버가 돌리는 모든 모델에 적용됩니다 (Ollama 문서, 2026-09-29 확인). llama-server는 띄울 때 --cache-type-k와 --cache-type-v로 정합니다. LM Studio도 불러오기 설정에서 K 캐시와 V 캐시 종류를 고를 수 있습니다. SDK 문서에 따르면 V 캐시를 양자화하려면 플래시 어텐션이 켜져 있어야 합니다.
• 플래시 어텐션: llama-server의 기본값은 auto입니다. Ollama FAQ에 따르면 Ollama도 백엔드와 장치가 지원하면 자동으로 씁니다. LM Studio에서는 모델별 불러오기 설정에서 켜고 끌 수 있습니다.
• 배치 크기: llama-server는 기본으로 프롬프트를 512토큰씩 묶어 처리합니다(-ub). 최근 Ollama는 num_batch를 따로 정하지 않으면, 컨텍스트가 4k보다 길고 VRAM에 여유가 있을 때 이 값을 1024나 2048로 올립니다. 그만큼 프롬프트 처리가 빨라지고 연산 버퍼도 커집니다.
• 동시 요청: Ollama는 OLLAMA_NUM_PARALLEL을 올리지 않으면 모델마다 요청을 하나씩 처리합니다. llama-server는 KV 캐시 하나를 함께 쓰는 슬롯 네 개를 엽니다. LM Studio도 0.4부터 같은 방식입니다. 메모리가 어떻게 달라지는지는 아래 동시 요청 절에서 봅니다.
• GPU 배치: llama-server는 GPU에 올릴 층 수를 스스로 정합니다(-ngl auto). Ollama는 num_gpu를 정하지 않으면 층 수를 넘기지 않으므로, 이때도 llama.cpp가 정합니다. LM Studio도 GPU 오프로드를 정하지 않으면 자동으로 고릅니다.

시작 컨텍스트와 메모리

KV 캐시는 지금까지의 대화를 담는 메모리라서 컨텍스트가 길수록 커집니다. 그래서 도구 사이의 메모리 차이는 대부분 시작 컨텍스트에서 나옵니다. 아래 표에 여기서 중요한 세 길이의 f16 KV 캐시 크기를 정리했습니다. 4k는 VRAM 24GB 미만에서 Ollama가 쓰는 기본값이고, 32k는 24GB·32GB 카드의 기본값입니다. 128k는 최대 길이가 128k인 Llama 3.1 8B·Gemma 3 12B를 llama-server로 띄울 때 출발하는 길이입니다. Qwen3 두 모델은 최대 길이가 그보다 짧아 128k 칸에 ‘—’가 나옵니다.

가중치와 연산 버퍼까지 더하면 차이가 더 분명해집니다. Llama 3.1 8B Q4_K_M은 4k에서 5.7GB가 필요합니다. 최대 길이인 128k에서는 23.5GB가 필요합니다. 많이 쓰는 카드 두 장에서 도구마다 어디서 시작하는지 보겠습니다.

8GB인 GeForce RTX 4060의 사용 가능 메모리는 7.4GB입니다.

• Ollama는 4k로 시작하고, 모델이 GPU에 전부 올라갑니다.
• **llama-server**는 -c가 없으면 128k에서 출발해 길이를 줄입니다. CanRun 계산으로는 f16 KV 캐시로 8k까지는 GPU에 다 들어갑니다. 16k부터는 가중치 일부가 시스템 RAM으로 갑니다. CanRun 수치로 보면 llama-server는 8k와 16k 사이에서 멈춥니다. 정확한 길이는 llama.cpp가 실제로 확인한 빈 VRAM에 따라 달라집니다. 시작 로그의 llama_context: n_ctx 줄에 그 값이 나옵니다.
• LM Studio는 불러오기 설정의 컨텍스트 길이를 그대로 씁니다.

GeForce RTX 5060 Ti 16GB의 사용 가능 메모리는 15.4GB입니다. 이 카드에서도 Ollama는 4k로 시작합니다. Llama 3.1 8B는 f16 KV 캐시로 64k를 써도 14.3GB라서 GPU에 다 들어갑니다. 128k에서는 f16 KV 캐시만 17.2GB라서 카드의 사용 가능 메모리를 넘습니다. 그래서 CanRun 계산은 이 설정을 CPU 전용으로 봅니다. CanRun 수치로 보면 llama-server는 이 카드에서 길이를 64k와 128k 사이로 잡습니다. 같은 모델에 Ollama가 기본으로 주는 길이의 여러 배입니다.

어느 쪽 기본값도 틀린 것은 아닙니다. 짧은 컨텍스트는 메모리를 적게 쓰지만 긴 대화의 앞부분을 잃습니다. 긴 컨텍스트는 대화를 지키는 대신 메모리를 더 쓰고, 찰수록 생성이 조금씩 느려집니다. 새 토큰을 만들 때마다 KV 캐시 전체를 읽기 때문입니다. 세 도구를 같게 맞추려면 컨텍스트를 직접 지정합니다. Ollama는 OLLAMA_CONTEXT_LENGTH나 num_ctx, 앱 설정의 컨텍스트 길이 슬라이더로, llama-server는 -c로, LM Studio는 컨텍스트 길이 설정이나 --context-length로 정합니다. 다른 모델의 길이별 메모리는 ‘KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까’ 가이드에 있습니다.

24GB 카드에서 Ollama가 더 느릴 수 있는 이유

기본값 차이가 가장 크게 드러나는 곳은 24GB 카드입니다. Ollama는 감지한 GPU 메모리가 24GiB 미만이면 4k, 24~48GiB면 32k, 48GiB 이상이면 256k 토큰을 기본 컨텍스트 길이로 씁니다 (Ollama 문서, 2026-09-29 확인). Ollama 코드는 이 경계를 문서보다 조금 낮게 잡아서, 24GB인 GeForce RTX 4090은 32k를 받습니다. 토큰마다 모든 가중치를 읽는 dense 모델 Qwen3 32B를 Q4_K_M으로 올려 보겠습니다. 8k에서는 22.0GB가 필요해 이 카드의 사용 가능 메모리 23.4GB 안에 들어가고, 쾌적하게 돌아갑니다. f16 KV 캐시로 32k를 쓰면 28.7GB가 필요합니다.

Ollama는 이 32k를 llama-server에 -c 값으로 고정해 넘깁니다. llama.cpp의 fit 기능은 이미 정해서 넘긴 컨텍스트는 건드리지 않고, 대신 층 일부를 시스템 RAM으로 옮깁니다. 그러면 ollama ps의 PROCESSOR 열에 CPU/GPU 비율이 나옵니다. Ollama가 자동 컨텍스트를 줄이는 것은 메모리 부족으로 불러오기가 아예 실패했을 때뿐입니다. 나뉘어서라도 올라간 모델은 32k를 그대로 씁니다. CanRun 표에서도 32k·f16 칸은 부분 오프로드이고, 예상 속도가 8k보다 크게 낮습니다.

llama-server에 모델만 지정해 띄우면 반대로 움직입니다. 모델의 원래 컨텍스트로 시작했다가 안 들어가는 것을 확인하고, 모델 전체가 GPU에 남을 때까지 길이를 줄입니다. 이 카드에서는 f16 KV 캐시로 16k만 써도 CanRun 계산상 넘칩니다. 그래서 CanRun 수치로 보면 8k와 16k 사이에서 멈추고, 풀 GPU 속도를 지킵니다. 엔진도 파일도 같지만 결과는 반대입니다. Ollama는 컨텍스트를 지키고 속도를 잃습니다. llama-server는 속도를 지키고 컨텍스트를 줄입니다.

Ollama에서 Qwen3 32B를 GPU에 다 올리려면 컨텍스트를 줄이거나 KV 캐시를 양자화합니다. 어느 설정이 GPU에 다 들어가는지는 위 표에 있습니다. 두 방법을 Ollama에서 쓰는 법은 ‘올라마(Ollama)가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값’ 가이드에서 자세히 다룹니다. 반대로 llama-server를 Ollama처럼 쓰려면 -c 32768을 직접 넘기면 됩니다. GeForce RTX 3090도 같은 24GB라서 기본값이 같습니다.

동시 요청과 MoE 모델

요청마다 컨텍스트를 따로 잡을까, 캐시 하나를 함께 쓸까

같은 모델에 요청이 동시에 여러 개 들어오면, 세 도구는 메모리를 다르게 나눕니다.

• Ollama는 동시 요청마다 컨텍스트를 하나씩 통째로 잡습니다. llama-server를 띄울 때 컨텍스트 길이에 OLLAMA_NUM_PARALLEL을 곱해 넘깁니다. FAQ도 필요한 메모리가 두 값에 비례해 늘어난다고 설명합니다. 기본값은 요청 하나라서, 기본 설치에서는 컨텍스트도 하나만 잡습니다.
• **llama-server**는 기본으로 슬롯 네 개를 엽니다. 슬롯들은 컨텍스트 크기의 KV 캐시 하나를 함께 씁니다(unified 방식). 요청 하나가 캐시 전체를 쓸 수 있고, 동시에 도는 요청은 캐시를 나눠 씁니다. 그래서 슬롯이 늘어도 KV 캐시는 커지지 않습니다.
• LM Studio도 0.4부터 같은 방식입니다. Max Concurrent Predictions 기본값이 4이고 Unified KV Cache가 켜져 있습니다. LM Studio는 이 기본 설정이 메모리를 더 쓰지 않을 것이라고 설명합니다.

OLLAMA_NUM_PARALLEL을 올리면 이 차이가 드러납니다. Qwen3 14B는 8k에서 KV 캐시가 1.3GB이고, 12GB인 RTX 3060에 모델 전체가 들어갑니다. 다만 남는 메모리는 1GB가 안 됩니다. OLLAMA_NUM_PARALLEL=4로 요청마다 8k를 주면 Ollama는 이 캐시를 네 개 잡습니다. 32k 컨텍스트 하나와 같은 크기(5.4GB)입니다. CanRun 계산으로는 이 카드에 32k가 다 들어가지 않아 가중치 일부가 시스템 RAM으로 갑니다. CanRun 표는 요청을 한 번에 하나만 처리한다고 가정합니다.

MoE 전문가는 누가 배치하나

MoE(mixture-of-experts) 모델은 토큰마다 전문가 몇 개만 읽습니다. 그래서 VRAM에 안 들어가는 전문가는 시스템 RAM에 두고 나머지는 GPU에 둘 수 있습니다. 아래 표는 GeForce RTX 5060 Ti 16GB에서 Qwen3 30B-A3B (2507) 조합으로 CanRun이 계산한 배치를 보여 줍니다. 이 모델은 19.8GB가 필요해 카드의 사용 가능 메모리 15.4GB를 넘습니다. 그래서 일부 층의 전문가가 시스템 RAM으로 갑니다.

CanRun 계산으로는 이 구성에서 원활하게 돌아갑니다. 이 속도는 이론 추정(±30%)입니다. llama.cpp의 fit 기능도 기본으로 이런 식으로 나눕니다. 전문가가 아닌 가중치를 먼저 GPU에 올리고, 꼭 필요한 만큼만 전문가를 시스템 RAM으로 옮깁니다. 다만 함정이 하나 있습니다. 이 모델은 4k로 줄여도 카드에 다 들어가지 않습니다. 그래서 -c 없이 띄운 llama-server는 컨텍스트를 하한인 4k까지 먼저 줄이고, 그다음에 전문가를 옮깁니다. Ollama도 16GB 카드에서는 4k로 시작합니다. -c 8192를 주거나 OLLAMA_CONTEXT_LENGTH를 직접 정하세요. CanRun 계산으로는 32k에서도 원활하게 돌아갑니다. 이 값도 이론 추정입니다. Ollama도 층 수를 llama.cpp에 맡기므로 같은 방식으로 나뉩니다. 다만 Modelfile이나 클라이언트에 num_gpu 값이 남아 있으면 달라집니다. Ollama가 층 수를 고정해 넘기고, llama.cpp는 전문가가 아니라 층 단위로 나눕니다.

LM Studio의 GPU 오프로드 설정은 층 단위로 옮깁니다. MoE 모델에는 ‘Force Model Expert Weights onto CPU’ 설정이 따로 있습니다. 릴리스 노트에 따르면 이 설정은 전문가 가중치를 모두 시스템 RAM으로 옮깁니다. llama.cpp의 --cpu-moe와 같은 방식입니다. 전문가 일부가 들어갈 자리가 있는 카드라면 그만큼 VRAM이 비게 됩니다. CanRun의 속도 범위도 이 설정에는 맞지 않습니다. LM Studio 문서는 자동 오프로드가 fit처럼 전문가를 나누는지 밝히지 않습니다. 큰 MoE 모델에 시스템 RAM이 얼마나 필요한지는 ‘그래픽카드보다 큰 MoE 모델 돌리기 — gpt-oss-120b와 시스템 RAM’ 가이드에 있습니다.

세 도구를 같은 조건으로 맞추기

내 PC에서 직접 비교하려면 기본값부터 걷어 내야 합니다. 같은 GGUF 파일을 쓰고, 컨텍스트와 KV 캐시 종류를 맞춥니다. 요청은 한 번에 하나만 보내고, 모델은 GPU에 전부 올립니다. 아래 명령은 CanRun 조합 페이지가 쓰는 Hugging Face 저장소의 Qwen3 14B Q4_K_M을 8k로 올립니다. 16GB인 RTX 5060 Ti라면 GPU에 다 들어갑니다.

llama.cpp: GitHub 릴리스 페이지에서 빌드를 받습니다. NVIDIA 카드라면 CUDA 빌드와 버전이 맞는 cudart 파일을, AMD·Intel이라면 Vulkan 빌드를 받습니다. 한 폴더에 풀고 그 폴더에서 PowerShell을 열어 아래 명령을 실행합니다. macOS·Linux에서는 .\llama-server.exe 대신 llama-server라고 씁니다. -np 1은 기본 슬롯 네 개를 하나로 줄여 Ollama와 맞춥니다. 시작 로그에 내 GPU 이름이 나오는지 확인하세요. 나오지 않으면 CPU로 돌고 있는 것입니다. 답이 끝날 때마다 콘솔의 eval time 줄에 생성 속도가 찍힙니다.

.\llama-server.exe -hf unsloth/Qwen3-14B-GGUF:Q4_K_M -c 8192 -np 1 -ngl all -fa on

Ollama: 앱 설정의 컨텍스트 길이 슬라이더를 8k로 맞추고 앱을 그대로 둬도 됩니다. 아니면 작업 표시줄에서 Ollama 앱을 종료한 뒤, 원하는 컨텍스트로 서버를 띄웁니다. 그다음 PowerShell 창을 하나 더 열어 모델을 실행합니다.

$env:OLLAMA_CONTEXT_LENGTH="8192"; ollama serve

ollama run hf.co/unsloth/Qwen3-14B-GGUF:Q4_K_M --verbose

--verbose를 붙이면 답이 끝날 때마다 시간 정보가 나옵니다. 그중 ‘eval rate’가 생성 속도입니다. 모델이 올라가 있을 때 ollama ps를 봅니다. CONTEXT 열에는 8192, PROCESSOR 열에는 100% GPU가 나와야 합니다. hf.co/로 시작하는 이름은 llama-server와 같은 파일을 받습니다. qwen3:14b 같은 라이브러리 태그는 Ollama가 따로 만든 파일입니다. 그래서 다른 배포자의 Q4_K_M과 크기나 내용이 다를 수 있습니다. 이 컨텍스트에서는 Ollama가 배치를 더 크게 잡을 수 있습니다. 그러면 프롬프트 처리 속도는 달라지지만 생성 속도는 그대로이니, 생성 속도로 비교합니다.

LM Studio: 오른쪽 위 검색 버튼(또는 Ctrl+Shift+M)으로 모델 검색을 엽니다. unsloth/Qwen3-14B-GGUF를 검색해 Q4_K_M을 받습니다. 불러올 때 컨텍스트 길이는 8192로, GPU 오프로드는 최댓값으로 맞춥니다. -fa on과 맞추도록 플래시 어텐션도 켭니다. 터미널에서는 lms ls에 나오는 모델 이름으로 다음처럼 불러올 수 있습니다.

lms load <model> --context-length 8192 --gpu max

그다음 lms chat <모델> --stats를 쓰면 답마다 속도가 나옵니다. 세 도구에 같은 프롬프트를 보내 생성 속도를 비교합니다. 첫 실행은 준비 과정으로 보고 건너뜁니다. 그래도 숫자가 다르면 두 가지를 더 봅니다.

• llama.cpp 빌드: Ollama는 LLAMA_CPP_VERSION 파일에 적힌 빌드를 넣습니다. LM Studio는 런타임 탭(Ctrl+Shift+R)에서 런타임별 버전을 보여 줍니다. llama.cpp 자체 빌드에는 번호가 붙습니다. 빌드가 바뀌면 모델에 따라 빨라질 수도, 느려질 수도 있습니다.
• 백엔드: 같은 모델이라도 CUDA 빌드와 Vulkan 빌드는 속도가 다를 수 있습니다. Ollama는 서버 로그의 inference compute 줄에 고른 라이브러리를 남깁니다. LM Studio는 런타임 탭에서 어떤 런타임을 골랐는지 보여 줍니다.

도구와 상관없는 숫자가 필요하면 같은 파일로 llama-bench를 돌립니다. 기본으로는 빈 컨텍스트에서 프롬프트 처리(-p 512)와 토큰 생성(-n 128) 속도를 잽니다. -d 8192를 붙이면 컨텍스트에 8k가 이미 찬 상태로 다시 잽니다. 긴 대화에 더 가까운 조건입니다.

쓰는 방식에 맞는 도구 고르기

어떤 도구를 써도 모델의 가중치와 KV 캐시에 드는 메모리는 같습니다. 모델·양자화·컨텍스트는 메모리를 기준으로 먼저 고르고, 도구는 쓰는 방식에 맞춰 고릅니다.

• Ollama: 백그라운드에서 돌며 다른 앱에 모델을 내주는 서비스가 필요할 때 잘 맞습니다. 모델은 짧은 태그로 받습니다. 24GB 미만 카드에서는 컨텍스트를 직접 정하세요. KV 캐시 종류는 서버의 모든 모델에 한꺼번에 적용됩니다.
• llama.cpp: 모든 옵션과 최신 빌드를 쓰고 싶고, 파일과 명령을 직접 다뤄도 괜찮을 때 잘 맞습니다. 기본값이 모델을 GPU에 남기는 쪽으로 움직입니다. 요청이 컨텍스트보다 길면 오류로 알려 줍니다.
• LM Studio: 터미널보다 창이 편할 때 잘 맞습니다. Hugging Face 모델을 검색하고, 불러오기 전에 예상 메모리와 메모리 부족 경고를 볼 수 있습니다. 모델별 설정도 저장해 둘 수 있습니다. 맥에서는 MLX 모델도 돌립니다.

이 숫자는 얼마나 확실한가

메모리 수치는 가중치, KV 캐시, 연산 버퍼를 더한 값입니다. 실제 GGUF 파일의 크기와 헤더, 모델 config로 공식에 따라 계산했습니다. 가중치와 KV 캐시는 어느 도구로 불러와도 같고, 연산 버퍼는 배치 크기에 따라 달라집니다. 속도는 추정치라서 오차 범위와 신뢰 라벨을 함께 붙입니다. 보정된 추정의 오차 범위는 NVIDIA·AMD 카드에서 dense 모델을 GPU에만 올릴 때 ±12%입니다. 부분 오프로드, MoE 모델, 그 밖의 하드웨어에서는 ±20%이고, 이론 추정은 ±30%입니다. 이 글에서는 전문가를 VRAM과 시스템 RAM에 나눠 둔 Qwen3 30B-A3B (2507)의 속도가 이론 추정입니다.

CanRun은 llama.cpp를 기준으로 계산합니다. 보정에 쓰는 공개 벤치마크도 거의 모두 Ollama나 LM Studio가 아니라 llama.cpp로 직접 잰 결과입니다. RTX 5060 Ti 16GB에서 돌린 gpt-oss-20b도 그중 하나입니다. 이 조합은 쾌적하게 돌아가고, 속도는 추정이 아니라 공개 벤치마크 결과입니다. llama.cpp 프로젝트의 gpt-oss 실행 가이드에 실린 결과로, llama-bench로 쟀습니다.

세 도구로 같은 모델을 나란히 잰 데이터는 없어서, CanRun은 도구 순위를 매기지 않습니다. llama.cpp 빌드, 백엔드, 앱마다 속도를 재는 방식에서 오는 차이는 추정에 들어 있지 않습니다. 런타임마다 메모리 여유도 따로 둡니다. 예를 들어 llama.cpp의 fit 기능은 기본으로 장치마다 VRAM을 조금 비워 둡니다. 그래서 CanRun 표에서 아슬아슬하게 들어가는 조합이 내 PC에서는 나뉘어 올라갈 수 있습니다. 이때는 ollama ps와 llama-server 시작 로그가 내 PC에서 실제로 일어난 일을 보여 줍니다. LM Studio에서는 CanRun 수치보다 LM Studio 자체 예상치(lms load --estimate-only)를 참고합니다. 표는 Windows에서 그 카드로 화면을 출력하고, 시스템 RAM은 32GB(DDR5)라고 가정합니다. 모델은 하나만 올리고, 요청은 한 번에 하나만 처리한다고 봅니다.

본문에서 말하는 판정은 따로 밝히지 않으면 8k 컨텍스트, f16 KV 캐시 기준입니다. Qwen3 14B와 Qwen3 32B는 생각 모드가 기본으로 켜져 있고, gpt-oss-20b는 늘 생각합니다. 그래서 생각 모드 모델에는 더 엄격한 속도 기준을 씁니다. 아래 범례에는 나오지 않지만, 기준 속도가 1.5배입니다.

자주 묻는 질문

Ollama가 llama.cpp보다 느린가요?

엔진 때문에 느린 것은 아닙니다. 0.30부터 Ollama는 GGUF 모델을 llama.cpp의 llama-server로 돌립니다. 먼저 ollama -v로 버전을 봅니다. 0.30 전에는 다른 엔진을 썼고, 0.30 릴리스 노트에는 NVIDIA 카드 성능 향상이 적혀 있습니다. 최신 Ollama인데도 같은 파일에서 더 느리다면 기본값을 확인합니다. 24GB 카드의 32k 기본값 때문에 Qwen3 32B 같은 dense 모델 일부가 시스템 RAM으로 갔는지 봅니다. 남아 있는 num_gpu 값과 올려 둔 OLLAMA_NUM_PARALLEL도 봅니다. 함께 들어 있는 llama.cpp 빌드가 오래됐는지도 확인합니다. ollama ps로 컨텍스트와 CPU/GPU 비율을 볼 수 있습니다. CanRun에는 나란히 잰 데이터가 없어서, 어느 도구가 빠른지는 말하지 않습니다.

같은 모델인데 LM Studio와 Ollama의 속도가 다르게 나오는 이유는 무엇인가요?

대개 도구가 아닌 다른 조건이 달라서입니다. 파일이 Ollama 라이브러리 태그인지 Hugging Face GGUF인지 확인합니다. 컨텍스트 길이, KV 캐시 종류, 플래시 어텐션, GPU 오프로드, 런타임(CUDA·Vulkan)도 봅니다. 위 ‘세 도구를 같은 조건으로 맞추기’ 절처럼 같은 파일을 같은 설정으로 올립니다. 그다음 첫 실행을 건너뛰고 생성 속도를 비교합니다.

8GB·12GB 카드에서는 무엇을 써야 하나요?

컨텍스트를 직접 정한다면 어느 것을 써도 됩니다. 모델의 가중치와 KV 캐시에 드는 메모리는 세 도구가 같기 때문입니다. Ollama는 이 카드들에서 4k로 시작합니다. Llama 3.1 8B 같은 모델은 8GB 카드에도 다 올라가지만, 긴 대화는 금방 앞부분을 잊습니다. llama-server는 모델이 들어갈 때까지 시작 컨텍스트를 줄이고, LM Studio는 컨텍스트 길이 설정을 따릅니다. 길이는 조합 페이지의 컨텍스트 표를 보고 고릅니다. 예를 들어 GeForce RTX 3060 12GB에서 Qwen3 14B 조합 페이지에 그 표가 있습니다. 고른 값을 쓰는 도구에 그대로 지정합니다.

세 도구가 모델 파일 하나를 같이 쓸 수 있나요?

쓸 수 있지만 디스크 공간은 따져 봐야 합니다. llama-server는 -m과 경로로 어느 GGUF 파일이든 그 자리에서 엽니다. LM Studio의 lms import는 기본으로 파일을 모델 폴더로 옮깁니다. --hard-link나 --symbolic-link를 붙이면 원본을 그 자리에 둡니다. Ollama는 Modelfile에 FROM과 경로를 적고 ollama create로 모델을 만듭니다. 이때 모델 폴더에 사본을 따로 둡니다. CanRun 조합 페이지는 가정한 파일의 Hugging Face 이름을 보여 줍니다. 그래서 세 도구에서 같은 양자화 파일을 불러올 수 있습니다.

출처

• llama.cpp: 엔진, 라이선스, 지원 하드웨어
• llama.cpp 릴리스: CUDA·Vulkan 등 Windows용 빌드와 CUDA 빌드에 함께 받는 cudart 파일
• llama.cpp 서버 README: -c(0이면 모델 값), --fit(기본으로 켜짐)과 --fit-ctx(fit이 줄일 수 있는 최소 길이, 기본 4k), -ngl auto, -fa auto, -b·-ub(기본 2048·512), --cache-type-k·--cache-type-v, -np(auto), --kv-unified, --context-shift(기본으로 꺼짐), -hf, 웹 UI, OpenAI 호환 API
• llama.cpp 소스: tools/server/server.cpp: 슬롯 수 auto는 unified KV 캐시를 쓰는 슬롯 네 개
• llama.cpp 소스: common/fit.cpp와 fit-params README: 지정하지 않은 컨텍스트는 학습 컨텍스트에서 시작해 층을 옮기기 전에 줄이고, 그래도 안 들어가면 4k 하한까지 줄인 뒤 옮김. 사용자가 정한 컨텍스트는 그대로 둠
• llama.cpp 소스: tools/server/server-context.cpp: 컨텍스트보다 긴 요청의 오류, 컨텍스트 시프트가 꺼져 있을 때 컨텍스트가 차면 멈추는 동작, 답마다 찍는 eval time 줄
• llama.cpp 소스: src/llama-context.cpp: 시작 로그의 n_ctx 줄
• llama-bench README: 기본 프롬프트·생성 길이, 컨텍스트를 채운 상태로 재는 -d
• Ollama v0.30.0 릴리스 노트: llama.cpp로 모델 실행, Apple Silicon의 MLX 엔진, NVIDIA 하드웨어 성능 향상
• Ollama 소스: llm/llama_server.go: Ollama가 llama-server에 넘기는 옵션(컨텍스트 × 동시 요청 수의 -c, -np, num_gpu가 없으면 생략하는 -ngl, --flash-attn auto, --context-shift, KV 캐시 종류, -b·-ub)
• Ollama 소스: server/routes.go와 server/sched.go: 문서보다 조금 낮은 경계를 쓰는 VRAM 구간별 기본값과 로그 줄, 불러오기가 실패했을 때만 자동 컨텍스트를 줄이는 동작, 4k를 넘는 컨텍스트의 큰 배치
• Ollama 소스: LLAMA_CPP_VERSION과 LICENSE: 함께 넣는 llama.cpp 빌드, MIT 라이선스
• Ollama 문서: 컨텍스트 길이: 앱 설정의 컨텍스트 길이 슬라이더
• Ollama 문서: OpenAI 호환과 LM Studio 문서: OpenAI 호환: OpenAI 호환 API
• Ollama FAQ: 플래시 어텐션, OLLAMA_KV_CACHE_TYPE과 정밀도 설명, OLLAMA_NUM_PARALLEL과 메모리, ollama ps
• Ollama 문서: 모델 가져오기: Modelfile의 FROM 줄과 ollama create로 GGUF 파일 가져오기
• Ollama 라이브러리: qwen3 태그: qwen3:14b와 qwen3:14b-q4_K_M이 같은 파일
• Hugging Face: Hub의 GGUF 모델을 Ollama로 쓰기: ollama run hf.co/사용자/저장소:양자화 형식
• LM Studio 0.4.0 릴리스 노트와 블로그 글: 동시 요청, 기본 슬롯 네 개와 Unified KV Cache, llama.cpp 엔진, 새 모델 검색(Ctrl+Shift+M)
• LM Studio 0.3.2 릴리스 노트: KV 캐시 기본값 f16
• LM Studio 0.3.9 릴리스 노트: CPU·CUDA·Vulkan·ROCm·Metal용 llama.cpp 런타임, 런타임 자동 업데이트, 런타임 탭
• LM Studio 0.3.23 릴리스 노트: Force Model Expert Weights onto CPU
• LM Studio 0.3.27 릴리스 노트: 불러오기 전 예상 메모리와 메모리 부족 경고
• LM Studio 문서: lms load, lms chat, lms import, lms runtime: --context-length, --gpu, --estimate-only, --stats, 가져오기 방식, 런타임 관리
• LM Studio 문서: 모델별 기본 설정: 플래시 어텐션을 포함한 불러오기 설정 저장
• LM Studio SDK: 불러오기 설정과 생성 설정: K·V 캐시 양자화 종류, 컨텍스트가 넘칠 때의 선택지
• LM Studio: 업무용 무료: 집과 회사에서 무료로 사용
• llama.cpp 토론 #15396: llama.cpp로 gpt-oss 돌리기: RTX 5060 Ti 16GB의 gpt-oss-20b 벤치마크 결과(llama-bench)