로컬 LLM 실행 환경, 뭘 기준으로 골라야 하나?
결론부터: 같은 모델과 양자화를 쓰면 Ollama·LM Studio·llama.cpp의 출력 품질 차이는 거의 없고, 실제 체감 차이는 실행 편의성·서버 오버헤드·GUI 조작성에서 난다. 2026년 기준 공개 실측에서는 llama.cpp가 동일 조건에서 Ollama보다 약 3~5% 빠른 정도였고, 이 차이는 하드웨어·빌드 옵션에 따라 뒤집힐 수 있다. 도구 선택보다 먼저 검증해야 할 건 "어떤 모델을, 어떤 양자화로, 어떤 작업에" 돌릴지다.
핵심 정리
- Ollama·LM Studio·llama.cpp는 같은 모델·양자화 조건이면 품질 차이가 작고, llama.cpp가 약 3~5% 더 빠르다는 실측이 있다 (dev.to).
- RTX 4090 24GB에서는 Q4_K_M 30B급 코딩 모델이 60~75 tokens/s로 실용적인 속도를 낸다.
- HumanEval 점수(DeepSeek-Coder-V2 83.5%, Qwen2.5-Coder 80.1%)는 Claude 3.5 Sonnet·GPT-4o보다 낮지만, 이 벤치마크는 단순 코드 생성이라 실제 저장소 수정 능력과는 별개로 봐야 한다.
- Mac mini M2 16GB 같은 저사양 환경에서도 Gemma 3 12B Q4_K_M은 초당 11~14 토큰대로 돌아간다.
- 이미지 생성 도구(Flux·Stable Diffusion)는 텍스트 LLM과 별도로 측정해야 하며, 이번 조사에서는 확인된 동일 하드웨어 수치가 부족했다.
이번 실험에서 검증하려던 질문은 단순하다. "로컬에서 LLM을 돌린다"는 말이 실제로 무엇을 의미하는지, 런타임 선택이 속도·메모리·개발 워크플로우에 어떤 차이를 만드는지 수치로 확인하는 것이다. 벤치마크 점수 하나로 도구를 고르는 대신, 런타임·모델·하드웨어·작업 종류를 분리해서 기록했다.
Ollama·LM Studio·llama.cpp, 뭐가 실제로 다른가?
세 가지는 모두 llama.cpp 계열 엔진을 기반으로 하거나 그와 유사한 추론 방식을 쓰지만, 사용자에게 노출되는 레이어가 다르다. Ollama는 모델 다운로드부터 실행까지 단일 CLI 명령으로 처리하고, localhost:11434에서 OpenAI 호환 API를 기본 제공한다. Continue·Cline·Aider 같은 IDE 확장 도구는 API 주소만 바꾸면 바로 연결된다. LM Studio는 기본적으로 localhost:1234에서 같은 방식의 API를 열어 두고, GUI에서 GPU 오프로딩 레이어 수, 양자화 방식, 컨텍스트 길이, 다중 GPU 배분을 직접 조작할 수 있어 하드웨어 비교 리뷰에 적합하다는 평가가 있다. llama.cpp를 직접 빌드해 실행하면 --ctx-size, --threads, --n-gpu-layers, --batch-size 같은 옵션을 세밀하게 조정할 수 있지만, 모델 파일과 프롬프트 템플릿을 직접 관리해야 하는 번거로움이 그대로 남는다. 즉 셋의 차이는 "얼마나 빨리 설치해서 API로 꽂느냐"와 "얼마나 세밀하게 튜닝하느냐" 사이의 트레이드오프에 가깝다 (dev.to).
RTX 4090에서 30B급 코딩 모델은 쓸 만한 속도가 나오나?
24GB VRAM 환경에서는 Q4_K_M 양자화 30B 안팎 모델이 실용 범위에 들어온다는 게 이번 조사의 핵심 수치다.
| 모델 | 생성 속도 | VRAM | HumanEval pass@1 |
|---|---|---|---|
| DeepSeek-Coder-V2 33B Q4_K_M | 68 tokens/s | 21.4GB | 83.5% |
| Qwen2.5-Coder 32B Q4_K_M | 74 tokens/s | 20.8GB | 80.1% |
| CodeLlama 34B Q4_K_M | 62 tokens/s | 22.1GB | - |
같은 조건에서 4,000토큰 프롬프트 처리 시간은 0.35~0.4초 수준이었다. 비교 대상으로 올라온 Claude 3.5 Sonnet(92.0%)과 GPT-4o(90.2%)는 HumanEval 점수에서 앞서지만, 이 벤치마크 자체가 단순 함수 생성 과제라 실제 저장소 수정 작업과는 거리가 있다는 점을 공개 자료도 함께 지적한다. 로컬 모델이 느리거나 부정확하다는 결론이 아니라, "어떤 과제에서" 격차가 나는지를 분리해서 봐야 한다는 뜻이다 (dev.to).
Apple Silicon에서는 같은 모델이 어떻게 돌아가나?
통합 메모리 환경에서도 중형 모델은 돌아가지만, 토큰 처리량은 데스크톱 GPU보다 눈에 띄게 낮다. Mac mini M2 16GB에서 Gemma 3 12B Q4_K_M을 돌린 비교에서는 Ollama가 생성 13.6 tokens/s, 첫 토큰까지 287ms, 최대 RAM 8.2GB를 기록했다. LM Studio는 생성 14.2 tokens/s, 첫 토큰까지 312ms, RAM 8.5GB였고, LocalAI는 생성 11.8 tokens/s, 첫 토큰까지 약 500ms로 셋 중 가장 느렸다. 이 수치는 100토큰 입력에 Python 병합 정렬 구현을 요청하고 콜드 스타트 후 3회 평균을 낸 조건이다. M3 Max 36GB 통합 메모리 환경에서는 더 큰 모델도 돌아가지만, 공개 자료에서 해당 조합의 코딩 모델 수치까지는 충분히 확인되지 않아 이번 글에는 넣지 않았다 (devtoolreviews).
코드 생성 점수만으로 도구를 고를 수 있나?
고를 수 없다는 쪽에 가깝다. HumanEval pass@1은 함수 하나를 맞게 생성하는지를 보는 벤치마크라서, 실제 코딩 도구가 하는 일—기존 저장소를 읽고, 버그를 찾고, 테스트를 통과시키는 일—과는 평가 축이 다르다. 그래서 실사용 평가에는 저장소 역할, 작업 범위, 제약, 절차, 검증까지 포함한 프롬프트가 필요하다. 예를 들어 "이 저장소는 Python 3.12, FastAPI, pytest를 쓴다"는 배경 설명 뒤에 "src/auth.py의 토큰 만료 버그만 수정한다"는 범위를 주고, "공개 API와 기존 테스트 파일은 변경하지 않는다"는 제약을 건 다음, 관련 파일을 먼저 읽고 수정 계획을 3줄로 제시한 뒤 패치하게 하고, 마지막에 테스트를 실행해 실패 원인과 변경 파일을 요약시키는 식이다. 평가 기준도 정답성 하나가 아니라 수정 파일 수, 테스트 통과 여부, 불필요한 변경, 재시도 횟수, 총 소요 시간을 같이 기록해야 비교가 의미 있어진다.
하드웨어 리뷰에서 숫자보다 먼저 기록할 건 뭔가?
모델 크기보다 먼저 적어야 할 조건이 있다. GPU 모델과 VRAM(또는 Apple Silicon 통합 메모리), 운영체제와 드라이버, Ollama·LM Studio·llama.cpp의 버전, 모델 원본과 양자화 형식(Q4_K_M, Q5_K_M, Q8 등), 컨텍스트 길이와 실제 입력 토큰 수, GPU 오프로딩 레이어 수, 프롬프트 처리 속도와 생성 속도의 분리, 첫 토큰 지연시간과 최대 메모리 사용량, 콜드·웜 스타트 여부, 동일 프롬프트 반복 횟수와 샘플링 설정, 그리고 도구 호출·파일 수정·테스트 실행을 포함했는지 여부다. 이 조건들을 빼고 "초당 몇 토큰"만 적으면, 다른 환경에서 재현했을 때 숫자가 맞지 않아도 원인을 추적할 수 없다.
이 실측이 어디까지 적용되고 어디서 막히나?
여기서 소개한 수치는 특정 시점의 런타임·모델·양자화·백엔드 조합에서 얻은 결과다. llama.cpp 기반 엔진이라도 CUDA·Metal·Vulkan 빌드, 드라이버 버전, 컨텍스트 길이, 배치 크기가 바뀌면 속도가 달라질 수 있고, 공개 비교 자료들 자체도 모델과 권장 사양이 빠르게 바뀐다고 밝히고 있다 (mozilla.ai, sitepoint). 또한 이번 조사는 텍스트·코딩 모델에 집중되어 있어, Flux·Stable Diffusion 같은 이미지 생성 도구를 같은 로컬 환경에 얹었을 때의 초당 이미지 수나 VRAM 점유량은 확인된 동일 조건 수치가 부족했다. 이미지 파트까지 비교하려면 텍스트 생성과는 별도로 측정하는 게 안전하다. 또한 LM Studio의 상용 사용 무료 정책이 2025년 7월 변경됐다는 자료가 있어, 실제 배포 전에는 현재 라이선스를 다시 확인해야 한다.
전체 실험을 돌아보면 뭐가 남나?
런타임 세 가지를 같은 모델·양자화로 맞춰 돌려 보면, "어떤 도구가 더 좋은가"보다 "어떤 조건을 고정했는가"가 결과를 더 많이 좌우한다는 걸 다시 확인했다. RTX 4090·24GB급에서는 Q4 양자화 30B 안팎 코딩 모델이 60~75 tokens/s로 실용 범위에 들어오지만, 그 속도가 실제 저장소 수정 작업에서의 성공률을 보장하지는 않는다. 코드 생성 벤치마크 점수만 보고 도구를 고르는 대신, 실제 저장소 수정·도구 호출·테스트 통과·메모리 사용량까지 같은 조건에서 기록해야 다음 실험에서 재현 가능한 비교가 된다는 게 이번 회고의 결론이다 (dev.to).