동일한 GGUF를 사용한 Ollama 대 llama.cpp 비교: 15% 속도 차이는 엔진이 아닌 기본 설정 때문이었다

Surface Laptop Ultra(Windows on Arm, RTX Spark)에서 측정했을 때: 초안 및 샘플링 설정을 맞추자 대부분의 격차는 사라졌다.

이 글은 제가 원래 Zenn에 일본어로 게시했던 기사를 영어로 각색한 것입니다: Ollama と Llama-Windows を同じ GGUF で比べたら、差はエンジンではなく既定の設定だった. 측정 결과와 결론은 제가 내린 것이며, 텍스트 번역 및 재구성을 위해 AI 도구를 사용했고 수치는 원본과 대조했습니다.

로컬 LLM을 벤치마크할 때, 이 글은 제가 비교를 두 번이나 잘못 이해했던 기록입니다. 해결책은 더 빠른 엔진이 아니었습니다. 양쪽 모두 동일한 설정을 사용하도록 맞추는 것이었습니다.

요약 (TL;DR)

• 동일 GGUF(Qwen3.6-35B-A3B, Q4_K_M), 동일 노트북. 기본 설정에서는 Llama-Windows가 Ollama 속도의 약 85%(대략 15% 느림)로 작동했다.
• Ollama 역시 내부적으로 llama.cpp를 실행하고 있습니다. 번들된 빌드는 Llama-Windows에 있는 버전보다 단 32 커밋만 더 최신이었습니다.
• 두 가지 기본 설정이 달랐습니다: Ollama는 기본적으로 MTP speculative decoding(초안 토큰 2개)을 사용하며, 샘플링 기본 설정이 다릅니다.
• 둘 다 설정을 맞추자 속도는 거의 동일했습니다. 남아있는 유일한 차이는 presence_penalty를 1.5로 설정했을 때, llama.cpp 측만 약 7% 느려진 것입니다. 그 이유에 대해서는 조사하지 않았습니다.
• 초안 토큰 2개면 충분했습니다. 3개는 결코 더 빠르지 않았습니다.

이름부터 알아보기

이 글에는 비슷하게 생긴 네 가지 이름이 있습니다. 이들은 서로 다른 것입니다:

아래 첫 번째 비교는 “Ollama 앱 대 Llama-Windows 앱, 기본 설정 기준”입니다. 그 이후의 모든 내용은 제가 설정을 제어할 수 있도록 수동으로 시작한 llama.exe와 Ollama를 비교한 것입니다.

비교가 바뀐 과정

이 글을 작성하면서 결론을 두 번 수정했습니다:

1. 기본 설정 상태(Defaults as shipped): Llama-Windows는 Ollama보다 약 15% 느리다.
2. Draft(추측 디코딩, speculative decoding) 정렬 시: 이제 llama.exe가 Ollama보다 7~8% 더 빠워 보였다. 이것 역시 너무 이른 비교였다.
3. Draft와 샘플링을 모두 정렬했을 때: 속도가 거의 비슷했다.

나머지 기사 내용은 각 단계에서 제가 정렬하는 것을 잊었던 부분이다.

테스트 설정 (Test setup)

단계 1: 기본 설정을 사용했을 때, Llama-Windows는 약 15% 느렸다

동일한 파일을 사용했음에도 불구하고, Llama-Windows는 Ollama 속도의 약 85% 수준으로 작동했다. 게다가 GPU 활용률은 더 높았다. 즉, 더 바쁘지만(활용도가 높지만), 느렸다.

Ollama 역시 내부적으로 llama.cpp를 사용한다

어느 엔진의 잘못이라고 비난하기 전에, 저는 Ollama가 실제로 무엇을 실행하고 있는지 확인했다. Ollama 0.40.7은 CUDA 환경에서 내장된 llama.cpp의 llama-server를 실행한다:

• 로그에는 'using llama-server for model'이라고 표시되어 있으며, ollama ps의 RUNNER 열에는 'llamacpp'라고 되어 있다.
• GPU 라이브러리는 cuda_v13의 ggml-cuda.dll이다. Vulkan 빌드는 포함되어 있지 않다.
• 내장된 llama-server 커밋은 Llama-Windows의 llama.exe (b11706)보다 단 32개 커밋만 더 최신이었다. 저는 GitHub의 비교 보기(compare view)를 사용하여 --version으로 출력되는 커밋들을 비교했다.

따라서 이것은 llama.cpp 대 llama.cpp에 가까웠다. 만약 15%의 격차가 있다면, 엔진이 아니라 설정(settings)이 첫 번째 용의자이다.

차이점 1: Ollama는 기본적으로 Draft를 미리 수행한다 (MTP)

Qwen3.6은 모델에 다중 토큰 예측(multi-token prediction, MTP) 레이어를 내장하고 있다. 이는 런타임이 별도의 Draft 모델 없이도 곧 나올 토큰을 추측하여 한 번에 검증할 수 있게 해준다: 즉, 추측 디코딩(speculative decoding)이다.

• Ollama는 이것을 기본으로 사용합니다. ollama show는 파라미터(Parameters) 아래에 draft_num_predict 2를 나열하며, 이는 2개의 토큰을 미리 초안 작성(drafts)한다는 의미입니다. API의 options에서 draft_num_predict를 0으로 설정하면 이를 끌 수 있습니다.
• Llama-Windows 앱은 기본적으로 초안 작성을 하지 않습니다. 만약 사용자가 직접 llama.exe를 시작한다면, --spec-type draft-mtp --spec-draft-n-max 2가 2토큰 초안 작성을 제공합니다.

초안 작성(Drafting)은 약 1.5~2GB의 추가 GPU 메모리를 소모하며 GPU 활용률을 낮춥니다. 이것이 단계 1에서 나타난 "더 바쁘지만 느린(busier but slower)" 패턴을 설명합니다. Llama-Windows는 단순히 초안 작성을 하지 않았기 때문입니다.

제가 오직 초안 작성만 맞추었을 때, llama.exe가 Ollama보다 7~8% 더 빠게 나왔습니다. 그것은 저의 두 번째 결론이었으며, 이 역시 성급한 것이었습니다.

차이점 2: 샘플링 기본값이 달랐다

샘플링(sampling) 기본값도 일치하지 않았습니다:

• S1: 모델이 권장하는 값으로, 이는 Ollama의 기본값과 동일합니다: temperature 1.0, top_k 20, top_p 0.95, min_p 0, presence_penalty 1.5, repeat_penalty 1.0.
• S2: 그리디 디코딩(greedy decoding) (temperature 0)으로, 항상 가장 가능성이 높은 토큰을 선택합니다.

기타 조건:

• 양쪽 모두 시드(Seed)를 42로 고정했습니다.
• 요청마다 값을 전달했습니다. 저는 앱이나 Ollama의 설정 파일을 변경하지 않았습니다.
• 생성은 1024 토큰으로 제한했습니다 (Ollama의 경우 num_predict, llama.exe의 경우 max_tokens).
• 각 조합에 대해, 워밍업 실행(warm-up run) 1회는 폐기하고 5회의 측정 실행을 진행했습니다. 측정하지 않는 엔진은 중지되었습니다.

결과 (토큰/초, 5회 평균; 표준 편차 0.38–1.90):

• 드래프팅(drafting)과 샘플링(sampling)을 모두 맞추었을 때, 두 엔진은 속도가 비슷했습니다 (드래프팅 없음, 그리디 디코딩: 81.69 vs. 80.44).
• 나머지 차이는 presence_penalty 때문이었습니다. 1.5에서, llama.exe만 약 7% 느려졌습니다 (80.44 → 74.75). Ollama는 거의 변하지 않았습니다 (presence_penalty 0일 때 81.69 → 1.5일 때 81.45).
• 2 토큰 드래프팅은 두 엔진 모두를 약 2040% 빠르게 했습니다 (Ollama 2227%, llama.exe 30~38%). 권장 설정에서는, llama.exe가 드래프팅을 통해 presence_penalty로 인한 속도 저하분을 만회하여 Ollama와 거의 비슷한 수준이 되었습니다.
• 그리디 디코딩과 2 토큰 드래프팅을 사용했을 때, llama.exe가 앞섰습니다 (110.85 vs. 104.04). 하지만 출력 텍스트와 드래프트 수용률(draft acceptance rate)이 달랐기 때문에 (0.835 vs. 0.819), 저는 이것을 엔진 차이라고 부를 수 없습니다.

드래프트 토큰 2개가 충분했습니다

드래프트 토큰을 2개에서 3개로 늘려도 네 가지 조합 중 어느 것도 더 빠르지 않았습니다 (같거나 느림). 드래프트 수용률은 2 토큰일 때 0.710.84였고, 3 토큰일 때는 0.650.71이었습니다. 세 번째 추측을 맞히기가 더 어려워 전체 수용률을 떨어뜨립니다.

시드(seed)를 고정하기 전에는, 각 실행마다 다른 텍스트가 생성되었기 때문에 3 토큰 드래프팅은 초당 103~113 토큰 사이에서 변동했습니다. 시드를 고정한 후에는, 5개 모든 실행이 동일한 수의 토큰을 생성했고 편차가 사라졌습니다.

Llama-Windows 설치 시 확인한 사항들

Llama-Windows는 추론 엔진(inference engine)을 앱 자체와 분리하여 가져옵니다 (MSIX 패키지). 이 앱은 install.ps1을 다운로드하고 메모리에서 실행한 다음, Hugging Face로부터 사용자의 GPU에 맞는(llama.exe 빌드, 여기서는 CUDA aarch64 빌드)를 설치합니다.

• MSIX는 서명되어 있었고, 해시(hash) 값은 릴리스에 명시된 것과 일치했습니다.
• 다운로드한 llama.exe는 서명되어 있지 않았고 해시 검사도 없었습니다. 단순히 HTTPS를 통해 가져올 뿐이었습니다.
• 그래서 저는 설치하기 전에 install.ps1을 읽고, 그 후에 llama.exe의 해시 값을 기록했습니다.
• 기본적으로 서버는 127.0.0.1에서만 수신 대기(listened)했습니다.

측정하지 않은 것들

• 하나의 프롬프트, 하나의 PC. 긴 컨텍스트나 다른 모델을 사용할 경우, 격차의 방향과 크기는 달라질 수 있습니다.
• 시드(seed)가 고정되었기 때문에, 5회 실행은 반복되는 동일한 텍스트입니다. 다른 출력에서 오는 변동성은 포함되지 않습니다.
• 그리디 디코딩(greedy decoding)을 사용했음에도 불구하고, 두 엔진의 출력은 일치하지 않았습니다. 생각하는 과정은 동일하게 시작했지만, 답변은 중간에 달라졌고, 생성된 토큰 수는 739개에서 1024개까지 다양했습니다. 심지어 같은 엔진이라도 드래프팅(drafting) 유무에 따라 다른 텍스트를 생성했습니다.
• 왜 presence_penalty가 llama.exe만 느리게 만드는지는 조사하지 않았습니다. Ollama의 번들 빌드는 32 커밋(commits)이 더 최신 버전이므로, 그 사이에 변경 사항이 있었거나 엔진 호출 방식에 차이가 있을 수 있습니다. 이것들은 가설일 뿐, 발견된 사실은 아닙니다.
• 답변의 품질은 비교하지 않았습니다.

핵심 요약 (Takeaways)

1. Ollama는 llama.cpp도 실행합니다. 동일한 GGUF를 사용했을 때, 속도 차이는 엔진이 아닌 기본 설정(default settings)에서 비롯되었습니다.
2. 두 가지 기본 설정이 달랐습니다: Ollama는 MTP를 사용하여 2개의 토큰을 미리 드래프팅하며, 샘플링 값(sampling values) (예: presence_penalty 1.5 등)도 다릅니다.
3. 정렬(aligned)했을 때 속도는 거의 비슷했으며, presence_penalty만이 llama.cpp 측에서 약 7%의 격차를 만들었습니다. 드래프트 토큰 2개만으로 충분했습니다.
4. 속도를 비교할 때는 드래프팅(drafting), 샘플링(sampling), 시드(seed), 그리고 생성 길이(generation length)를 정렬하여 비교해야 합니다. 이 중 어느 하나라도 빠뜨리면 10%의 격차를 얻기 쉬우며, 때로는 잘못된 방향을 가리킬 수 있습니다.

위에 언급된 모든 기본 설정은 측정 당시의 버전 (Ollama 0.40.7, Llama-Windows 0.13.0 with llama.cpp b11706) 기준입니다. 최신 버전에서는 변경되었을 수 있습니다.
업데이트 참고 사항 (2026년 11월): 이 장치에 설치된 Ollama는 이후 0.40.7에서 0.40.10으로 자동 업데이트되었습니다. 위에 언급된 모든 측정값은 0.40.7 기준이며, 0.40.10에서 기본 설정이 변경되었는지 재확인하지 않았습니다. Llama-Windows는 여전히 0.13.0입니다.

Llama-Windows와 llama.cpp는 MIT 라이선스를 따릅니다 (ggml-org/Llama-Windows).

본 시리즈 소개 (About this series)

• 초기 설정: Arm Windows에서 각 도구가 설치 전에 GPU를 사용할 수 있는지 확인하기
• ComfyUI를 Intel Arc에서 Arm의 WSL2로 옮기기: 동일한 요구 사항, 다른 패키지 버전