Ollama·LM Studio·llama.cpp 실행기, 흔한 함정과 해결법

Ollama·LM Studio·llama.cpp로 로컬 LLM을 돌리다 "설정을 분명 바꿨는데 왜 그대로지"에 부딪힌다면, 2026년의 핵심 사실부터 알아야 한다: 세 실행기는 모두 같은 엔진(llama.cpp)을 쓴다. Ollama도 LM Studio도 내부는 llama.cpp다. 그래서 문제는 대개 모델이 아니라 래퍼의 '기본값'과 '버전 지연'에서 나온다. 가장 악명 높은 예: Ollama는 모델이 광고한 128k 문맥을 무시하고 기본 4k만 로드하며, 넘치면 에러 없이 오래된 메시지를 조용히 버린다. 사용자 눈엔 "모델이 갑자기 까먹은" 걸로 보인다. 이 글은 세 실행기의 고유 함정을 증상 → 원인 → 해결 순으로 수치와 함께 정리한다.

쉽게 말하면: 실행기는 같은 엔진을 얹은 세 대의 차다. 엔진(llama.cpp)은 똑같은데 계기판·기본 세팅(래퍼)이 다르다. Ollama는 "간편"을 위해 사이드미러를 접어 출고(문맥 4k)하고, 접힌 줄 모르고 타면 뒤가 안 보인다(문맥 유실). 그리고 셋 다 엔진 펌웨어 업데이트가 늦어(버전 지연) 최신 모델을 제대로 못 다루기도 한다.

Ollama가 왜 대화 내용을 잃어버리나?

문맥 창(num_ctx)이 기본값 그대로여서다 — 광고된 최대치가 아니다. Ollama는 Gemma3가 131,072을 지원해도 기본 2,048~4,096만 로드한다(VRAM에 따라 동적). 위험한 건 조용히 실패한다는 점: 누적 토큰이 num_ctx를 넘으면 에러 대신 앞 메시지를 소리 없이 드롭한다. 해결과 흔한 재실수: (1) 런타임에 ollama run <model> --num-ctx 16384, 영구면 Modelfile에 PARAMETER num_ctx 32768 — 단 Modelfile은 언더스코어(num_ctx), 하이픈(num-ctx)은 조용히 무시된다. (2) 환경변수는 구형 OLLAMA_NUM_CTX가 아니라 OLLAMA_CONTEXT_LENGTH. (3) 우선순위는 API > 환경변수 > Modelfile > 기본값. (4) 실제 로드값은 ollama show(아키텍처 최대)가 아니라 ollama ps로 확인. (5) 태그 주의: yi:6b-200k은 롱컨텍스트지만 베이스 yi:34b은 4k다. 그리고 시스템 프롬프트도 예산을 먹는다 — 2,000토큰 시스템이면 4,096의 절반이 사라진다.

num_gpu와 디스크는 왜 말썽인가?

부분 오프로드가 성능 절벽을 만들고, Ollama는 디스크를 중복으로 먹는다. num_gpu는 GPU에 올릴 레이어 수인데, 일부만 올리면(부분 오프로드) 오히려 급격히 느려진다 — RTX 4060 8GB에서 num_gpu 25는 VRAM을 7.2→4.8GB로 줄이지만 속도가 40.58 → 8.62 tok/s로 4.7배 폭락한다(레이어마다 CPU↔GPU 전송 오버헤드). 그래서 맞으면 num_gpu 99(전부 올리기)가 정석이고, 자동감지는 KV 캐시를 계산에 안 넣어 VRAM이 빠듯할 때 틀린다. 값이 모델 정의에 baked-in돼 바꾸려면 새 모델을 만들어야 하는 것도 불편하다. 디스크: Ollama는 자체 blob 포맷이라 기존 GGUF를 재사용 못 하고 재다운로드·재패키징한다(멀티파일 split GGUF도 미지원). GGUF를 직접 import하면(FROM ./model.gguf + ollama create) 템플릿 자동감지가 실패해 stop token을 무시하는 사례가 흔하니, ollama show --modelfile로 베이스 템플릿을 복사하라.

셋 중 뭐가 빠르고 뭘 골라야 하나?

속도차는 모델이 아니라 '래퍼 오버헤드와 버전 지연'에서 온다 — 셋 다 하드웨어 바운드다. 2026년 7월 단일 GPU 벤치에서 LM Studio는 llama.cpp의 ±2%(사실상 동률), Ollama는 모든 항목에서 8~14% 뒤(≈+10% 세금)였다. 애플에선 더 벌어져, Mac Studio M3 Ultra에서 Gemma 3 1B가 LM Studio 237 t/s vs Ollama 149 t/s였다. 숨은 진짜 원인은 번들된 llama.cpp 빌드의 버전 지연이다 — llama.cpp는 매주(때론 매일) 성능 커밋을 밀지만 Ollama·LM Studio 둘 다 HEAD를 실시간 추적하지 않아, Qwen 3.5 MoE 라우팅 같은 신모델 파라미터를 래퍼가 아직 못 다루기도 한다(직접 llama.cpp 서버는 됨). 선택 기준: ==API·헤드리스=Ollama, GUI·빠른 모델 전환=LM Studio, 최대 제어·앱 임베드=llama.cpp. 단 캐주얼 사용자에게 10% 세금은 결정 요인이 아니다 — 2분 만에 굴리는 편의가 오후 내내 플래그 튜닝보다== 대개 낫다.

그래서 실행기 안전 세팅은?

핵심은 "기본값을 믿지 말고, 실제 로드값을 눈으로 확인"하는 것이다.

• Ollama: 문맥을 명시(OLLAMA_CONTEXT_LENGTH 또는 per-request num_ctx)하고 ollama ps로 실제 로드 확인. Modelfile은 언더스코어, 태그 주의.
• GPU·메모리: 부분 오프로드 금지(맞으면 num_gpu 99), 문맥 올릴 땐 KV 캐시까지 계산 — VRAM 넘기면 20~50배 폭락. 필요하면 KV 양자화(q8_0).
• 실행기 선택: 헤드리스=Ollama, GUI=LM Studio, 제어=llama.cpp. 신모델이 이상하면 번들 버전 지연을 의심하고 최신 llama.cpp 서버로 교차 확인. 모든 세팅은 실제 모델·문맥으로 A/B 후 고정.

함께 읽기: Ollama·LM Studio·llama.cpp 실행기, 2026년에는 무엇을 고를까?, 로컬 코딩 보조 모델 2026: 직접 돌려보고 고른 현황과 추천

함께 읽기: Ollama·LM Studio·llama.cpp 실행기 VRAM·RAM 실측, Ollama·LM Studio·llama.cpp 실행기, 2026 현황과 추천

참고 링크

• llama.cpp(로컬 추론 엔진·서버)
• Ollama(로컬 실행기·Modelfile)
• Ollama 문맥 길이 공식 문서
• LM Studio(GUI·OpenAI 호환 서버)
• Ollama 로컬 GGUF import 요청 이슈

참고: 기본 문맥(2048~4096)·속도세금(+10%·±2%)·부분오프로드(40.58→8.62 tok/s)·M3 Ultra(237 vs 149 t/s)·폭락폭(20~50배) 같은 수치는 2026년 공개·커뮤니티 실측이며 하드웨어·빌드·모델·양자화에 따라 달라진다(영구 수치 아님, 개별 벤치 다수). 포트·플래그·기본값은 실행기 버전마다 바뀌고(예: OLLAMA_NUM_CTX→OLLAMA_CONTEXT_LENGTH), num_gpu 멀티GPU 동작은 버전·구성별로 다르니 자기 환경에서 확인하라. 설정 후 ollama ps·nvidia-smi로 검증하라. 실행기 관행은 빠르게 바뀌니 분기별로 다시 본다.