허깅페이스와 Ollama의 차이: 모델 저장소와 실행기
로컬 LLM을 처음 돌릴 때는 대개 Ollama부터 깝니다. ollama run llama3.2 한 줄이면 모델이 받아지고, 터미널에서 바로 대화가 됩니다. 그러다 모델 이름을 검색하면 결과 맨 위에 허깅페이스(Hugging Face) 페이지가 뜹니다. 같은 모델인데 파일이 수십 개 있고, 이름 뒤에 GGUF, Q4_K_M, Instruct 같은 꼬리가 붙어 있습니다. 여기서 많은 분이 묻습니다. Ollama를 쓰고 있는데 허깅페이스는 또 뭐고, 둘 중 무엇을 써야 하느냐고요.
둘 중 하나를 고르는 문제라는 오해
질문이 「무엇을 써야 하느냐」로 나오는 것은 둘을 같은 종류의 도구로 보기 때문입니다. 실제로는 서로 다른 층에 있습니다. 허깅페이스는 모델 파일을 올리고 받는 저장소이고, Ollama는 받은 모델을 내 컴퓨터에서 실행하는 프로그램입니다. 개발자에게 익숙한 말로 바꾸면 허깅페이스는 GitHub에, Ollama는 Docker에 가깝습니다. GitHub와 Docker 중 하나를 고르지 않듯이 이 둘도 고르는 관계가 아닙니다.
| 허깅페이스 | Ollama | |
|---|---|---|
| 하는 일 | 모델·데이터셋을 올리고 받고 찾는 곳 | 모델을 내 기계의 GPU·CPU에서 돌리는 프로그램 |
| 비슷한 것 | GitHub | Docker |
| 결과물 | 모델 파일(가중치)과 설명서 | localhost:11434에서 응답하는 API |
| 다루는 모델 | 원본 가중치부터 변환본까지 전부 | 실행하기 좋게 다듬은 판 |
모델이 만들어져 내 터미널에 닿기까지의 순서
Meta, Google, Alibaba 같은 곳이 새 모델을 공개하면 가중치는 보통 허깅페이스에 먼저 올라옵니다. 이때 올라오는 것은 학습에 쓰던 정밀도 그대로의 원본이라 파일이 큽니다. 형식도 대개 허깅페이스가 만든 safetensors입니다.
그다음에 커뮤니티가 이 원본을 줄이고 바꿉니다. 숫자 정밀도를 낮춰 파일 크기와 필요한 메모리를 줄이는 것을 양자화라고 하고, 그 결과를 llama.cpp 프로젝트의 파일 형식인 GGUF로 묶습니다. 이름 뒤의 Q4_K_M 같은 꼬리가 양자화 방식입니다. 이 변환본들도 허깅페이스에 다시 올라옵니다. 같은 모델 이름으로 검색했을 때 저장소가 여러 개 나오는 것은 이 때문입니다.
Ollama의 ollama pull은 Ollama가 따로 운영하는 모델 목록에서 받습니다. 이 목록에 있는 모델도 출발점은 대부분 같은 공개 가중치이고, Ollama 쪽에서 실행하기 좋게 다듬어 이름표(태그)를 붙여 둔 것입니다. 사용자가 양자화 방식을 몰라도 되게 고른 판을 기본값으로 준다는 것이 Ollama가 편한 이유입니다.
목록에 없는 모델을 받는 hf.co 주소
Ollama 목록은 고른 것만 모아 둔 곳이라 허깅페이스보다 훨씬 좁습니다. 한국어에 맞춰 다시 학습한 모델이나 나온 지 며칠 안 된 변환본은 목록에 없는 경우가 많습니다. 그때는 허깅페이스의 GGUF 저장소를 Ollama로 바로 받을 수 있습니다. 허깅페이스 문서에 사용법이 나와 있습니다.
ollama run hf.co/<사용자>/<저장소>
ollama run hf.co/<사용자>/<저장소>:Q4_K_M # 양자화 방식을 골라서저장소에 GGUF 파일이 있어야 이렇게 됩니다. 원본 safetensors만 있는 저장소라면 Ollama의 가져오기 문서대로 직접 변환해야 합니다. 저는 이 경우라면 먼저 같은 모델의 GGUF 변환본이 허깅페이스에 이미 있는지 찾아보는 편이 빠르다고 봅니다. 널리 쓰이는 모델은 대개 누군가 먼저 변환해 둡니다.
저장소만으로 끝나지 않는 허깅페이스
허깅페이스를 저장소라고만 소개하면 절반만 말한 것입니다. Ollama와 겹치지 않는 일이 몇 가지 더 있고, 로컬 LLM을 쓰다 보면 언젠가 여기 닿습니다.
가장 큰 것은 transformers 라이브러리입니다. 파이썬에서 모델을 불러 돌리고, 무엇보다 학습시킬 때 표준으로 씁니다. Ollama는 실행만 하고 학습은 하지 않습니다. 모델을 내 데이터로 더 가르치는 파인튜닝을 하려면 허깅페이스 쪽 도구로 학습하고, 그 결과를 GGUF로 바꿔 Ollama에 올리는 순서가 됩니다.
모델을 고를 때도 허깅페이스를 봅니다. 저장소마다 붙은 모델 카드에 학습 데이터, 지원 언어, 라이선스가 적혀 있습니다. 그 밖에 모델을 허깅페이스 서버에서 돌려 주는 유료 추론 서비스와, 데모 웹앱을 올려 두는 Spaces도 있습니다. 앞의 것은 Groq나 OpenAI API 같은 호스팅 추론과 같은 자리에 있습니다.
라이선스는 받는 곳을 따라오지 않는다는 점
헷갈리기 쉬운 부분이 하나 있습니다. Meta의 Llama처럼 일부 모델은 허깅페이스에서 받으려면 라이선스에 동의하고 승인을 받아야 합니다. 그런데 Ollama에서는 같은 모델이 동의 절차 없이 받아집니다. 이것을 Ollama로 받으면 라이선스가 풀린다고 읽으면 안 됩니다. 라이선스는 모델에 붙어 있고, 어디서 받았는지와 상관없이 똑같이 적용됩니다. 상업적으로 쓸 계획이라면 Ollama로 받은 모델이라도 원본 저장소의 모델 카드에서 라이선스를 직접 확인해야 합니다.
Ollama만으로 충분한 경우
정해진 모델을 받아 대화하거나 API로 붙여 쓰는 것이 전부라면 Ollama만으로 충분합니다. 허깅페이스 계정이 없어도 됩니다. 허깅페이스를 열게 되는 때는 세 경우입니다. Ollama 목록에 없는 모델이 필요할 때, 모델을 직접 학습시킬 때, 모델을 고르기 전에 비교해 보고 싶을 때입니다. 마지막 경우라면 파라미터 수와 양자화가 실제 속도와 품질에 어떻게 이어지는지 잰 로컬 LLM 모델 고르기 글이 이어서 읽을 만합니다.
함께 읽기
- vLLM과 Ollama의 차이: 연속 배칭과 PagedAttentionOllama 공식 FAQ의 동시 요청 항목에는 이런 기본값이 적혀 있습니다. OLLAMANUMPARALLEL, 모델 하나가 동시에 처리하는 요청 수의 최댓값, 기본값 1. 바로 아래 줄에는 필요한 메모리가 OLLAMANUMPARALLEL 곱하기 OLLAMACONTEXTLENGTH만큼 늘어난다고 쓰여 있습니다(Ollama…
- 로컬 LLM으로 업무 자동화를 만들 때, 모델을 몇 개 써야 할까사내에 AI를 도입하려는 회사가 가장 먼저 부딪히는 질문이 있습니다. "모델 하나면 되는 것 아닌가요?"
- 혼자 쓰는 RAG: 인증·권한을 빼고 남은 설계 결정들ChatGPT에 문서를 전부 올리면 끝나는 일 아닌가,라고 한동안 생각했습니다. 그런데 제가 쓰는 데이터를 전부 올리는 건 사정이 달랐습니다. 재고 목록, 영업 리드, 기도 기록, 가계부까지 한 사람의 전 삶이 들어있는 DB였거든요. 그래서 로컬 LLM 기반 RAG를 직접 짰습니다. 이 글은 그 과정에서 내린, 그리고 …
- 로컬 LLM 모델 고르기: 파라미터, 양자화, MoE를 실측으로 비교온프레미스 추론 서버에 모델이 25개, 154GB 쌓여 있었습니다. 저는 필요할 때마다 하나씩 받았고, 어느 시점부터 무엇을 왜 갖고 있는지 설명할 수 없게 됐습니다.
- 사내 지식을 답변으로 바꾸는 RAG 시스템 구축기문서는 많지만 필요한 순간에 찾기 어렵고, 검색 결과를 열어 일일이 내용을 비교해야 한다면 지식은 충분히 활용되지 못합니다. 이번 글에서는 문서와 업무 데이터를 자연어로 검색하고, 근거와 함께 답을 생성하는 RAG 시스템을 작은 범위에서 시작해 운영 가능한 구조로 확장한 과정을 정리합니다.