← 스터디

스터디 · 2026-10-12 · 입문

Hugging Face에서 LLM 고르고 읽는 법: 모델 페이지부터 GPU 메모리까지

Hugging Face 허브의 모델 페이지에서 무엇을 보면 되는지 정리한다. 모델 카드·파일·이름 꼬리표·라이선스·벤치마크를 읽는 법을 다루고, 내 GPU 메모리로 돌릴 수 있는지 어림하는 방법과 고를 때 쓰는 점검 목록도 함께 담았다.

목차

• Hugging Face 허브는 무엇이고 왜 알아야 하나
• 모델 페이지는 무엇으로 이뤄지나
• 모델 이름 읽는 법
• 라이선스와 상업 이용 확인
• 벤치마크 표와 인기 지표, 파생 모델 보는 법
• 내 GPU로 돌릴 수 있을까: 메모리 어림하기
• 처음 고를 때 따라 할 순서와 점검 목록
• 흔한 실수와 더 공부하려면

Hugging Face 허브는 무엇이고 왜 알아야 하나

LLM(대규모 언어 모델)을 직접 받아 쓰려는 사람은 대부분 Hugging Face 허브에서 시작한다. Hugging Face 모델 허브 문서글는 이곳을 커뮤니티 구성원이 모델 체크포인트(학습된 가중치를 저장한 파일 묶음)를 올려 보관하고, 찾고, 공유하는 곳이라고 설명한다. 모델은 huggingface_hub 클라이언트 라이브러리나 Transformers로 내려받을 수 있다. 같은 문서에 따르면 허브와 연동된 라이브러리가 15개가 넘고, 실제 서비스에 쓸 때는 Inference Providers나 Inference Endpoints를 이용할 수도 있다.

문제는 모델 수가 너무 많다는 점이다. 이름이 비슷한 모델이 수십 개씩 있고, 같은 모델의 양자화판·파인튜닝판·병합판도 따로 올라온다. 이름과 페이지를 읽을 줄 모르면 회사에서 쓸 수 없는 라이선스의 모델을 고르거나, 내 GPU에 올라가지 않는 모델을 몇 시간씩 내려받는 일이 생긴다.

이 글은 모델 하나를 열었을 때 어디부터 보고, 무엇을 확인해야 '쓸 수 있는 모델'인지 판단하는 순서를 정리한다.

모델 페이지는 무엇으로 이뤄지나

모델 페이지의 첫 화면은 모델 카드다. Hugging Face 모델 카드 문서글에 따르면 모델 카드는 모델 저장소에 있는 README.md 파일이고, 맨 위에 YAML 메타데이터 구역이 붙은 마크다운 문서다. 메타데이터에는 language, license, datasets, base_model 같은 항목이 들어간다. 허브는 이 값으로 모델 목록에서 거르기, 라이선스 표시, 학습에 쓴 데이터셋 연결을 해 준다. 같은 문서는 모델 카드에 모델 설명, 의도한 용도와 한계(편향·윤리적 고려 포함), 학습 파라미터와 실험 정보, 학습 데이터셋, 평가 결과가 들어가야 한다고 안내한다. 이 구성은 모델 카드 논문논문에서 나왔다. 이 논문은 모델마다 의도한 사용 맥락과 평가 절차, 여러 조건별 성능을 밝힌 짧은 문서를 함께 내놓자고 제안했다.

Files 탭에는 실제 파일이 있다. config.json은 모델 구조 설정 파일이다. Transformers 모델은 허브가 이 파일을 보고 작업 종류(pipeline_tag)를 자동으로 추론한다글. 다만 2024년 8월 이후 만든 저장소는 config.json이 있어도 Transformers 모델로 자동 판단하지 않으므로, 카드에 library_name이 적혀 있는지 보는 것이 좋다글. 토크나이저 파일에는 글을 토큰으로 자르는 규칙과 채팅 템플릿이 들어 있다. 가중치 파일은 보통 safetensors나 GGUF 형식이다. Safetensors 문서글는 safetensors가 pickle과 달리 텐서를 안전하게 저장하면서도 복사 없이 빠르게 읽는 형식이라고 설명한다. GGUF 문서글에 따르면 GGUF는 llama.cpp 개발자가 만든 바이너리 형식이고, 텐서만 담는 safetensors와 달리 표준화된 메타데이터도 함께 담는다.

커뮤니티 탭은 사용자 질문과 토론이 모이는 곳이다. 카드에 없는 실행 오류나 템플릿 문제, 라이선스 문의가 여기서 먼저 드러나는 경우가 많으니 한 번 훑어보는 습관을 들이면 좋다.

모델 이름 읽는 법

허브의 모델 ID는 '조직/모델명' 꼴이다. 예를 들어 Hugging Face 채팅 템플릿 문서글에 나오는 mistralai/Mistral-7B-Instruct-v0.1은 mistralai 조직이 올린 모델이다. 모델명은 크기 7B, Instruct 종류, 버전 v0.1로 읽는다. 7B·70B는 파라미터(모델이 학습한 숫자) 수가 70억·700억 개라는 뜻이다. MoE(전문가 혼합) 모델은 이름에 A3B처럼 '활성 파라미터'를 덧붙이기도 한다. 토큰 하나를 처리할 때 실제로 계산에 쓰는 파라미터가 약 30억 개라는 뜻으로 흔히 쓰인다. 계산량은 활성 파라미터를 따르지만, 메모리에는 보통 전체 파라미터를 모두 올려야 한다는 점을 기억해야 한다.

종류 꼬리표는 사용 목적을 가른다. 채팅 템플릿 문서글는 대규모 텍스트로 사전학습해 만든 것이 'Base' 모델이고, 이를 메시지 형식 데이터로 파인튜닝한 것이 채팅 모델이라고 설명한다. Base 모델은 글을 이어 쓰는 데 강하고 지시를 따르게 다듬어지지 않았다. 대화형 업무에는 Instruct·Chat이 붙은 모델을 고르고, 직접 파인튜닝할 출발점이 필요할 때 Base 모델을 고르는 것이 일반적이다.

이름 끝의 변형 꼬리표는 파일 형식이나 양자화(숫자 정밀도를 낮춰 크기를 줄이는 것) 방식을 알려 준다. -GGUF는 llama.cpp 계열 실행기용 GGUF 파일이라는 뜻이다. GGUF 문서글는 TheBloke/Mixtral-8x7B-Instruct-v0.1-GGUF를 예로 든다. -AWQ는 GPTQ·AWQ 같은 가중치 양자화 방식을, -FP8은 8비트 부동소수점 정밀도를 가리키는 꼬리표로 흔히 쓰인다. 이런 꼬리표가 붙은 저장소는 원본을 만든 조직이 아닌 다른 사람이 올린 경우가 많다. 그러니 카드의 base_model로 원본이 무엇인지 확인한다.

라이선스와 상업 이용 확인

가장 먼저 걸러야 할 조건은 라이선스다. Hugging Face 라이선스 문서글는 저장소 카드의 메타데이터에 라이선스를 적게 하고, 남의 코드나 데이터를 쓰려면 그 프로젝트의 라이선스를 찾아 존중하라고 안내한다. 같은 문서의 목록에는 apache-2.0, mit 같은 일반 오픈소스 라이선스가 있다. cc-by-nc-4.0처럼 비상업(Non Commercial) 조건이 붙은 라이선스, llama3.1·gemma처럼 모델 회사가 따로 만든 라이선스, OpenRAIL 계열처럼 사용 제한 조항을 둔 라이선스도 함께 실려 있다.

이름에 'NC'가 들어간 라이선스는 상업 이용이 막혀 있다는 신호다. 회사가 만든 커뮤니티 라이선스는 이름만 보고 판단하지 말고 원문 조항을 읽어야 한다. 모델 카드 문서글에 따르면 목록에 없는 라이선스는 license: other로 표시하고 license_name과 license_link로 원문을 연결하거나 LICENSE 파일을 저장소에 둔다. 이 경우 페이지의 라이선스 배지만으로는 아무것도 알 수 없다.

파생 모델은 한 번 더 확인해야 한다. 파인튜닝판이나 양자화판을 올린 사람이 적은 라이선스와 원본 모델의 라이선스가 다를 수 있다. 실무에서는 base_model을 따라 원본 라이선스까지 확인하고, 판단이 애매하면 법무 검토를 거친다.

벤치마크 표와 인기 지표, 파생 모델 보는 법

모델 카드의 벤치마크 표는 참고 자료이지 내 업무 성능에 대한 보증이 아니다. 모델 카드 논문논문은 평가 결과를 여러 집단과 조건으로 나눠 보고하고, 어떤 지표를 왜 골랐는지와 평가 절차를 함께 밝혀야 한다고 주장했다. 이 기준으로 보면 숫자 하나만 크게 적은 표는 정보가 부족하다. 표를 볼 때는 평가 설정(몇 개의 예시를 줬는지, 어떤 프롬프트를 썼는지)이 비교 대상 모델과 같은지, 다른 모델 점수를 직접 쟀는지 옮겨 적었는지 확인한다. 학습 데이터에 시험 문제가 섞였을 가능성, 즉 데이터 오염도 염두에 둔다. 결국 내 업무에서 뽑은 작은 평가 세트로 직접 확인하는 것이 가장 확실하다.

다운로드 수와 좋아요는 얼마나 많이 쓰이는지 보여 주는 신호다. 그만큼 문제가 알려졌을 가능성도 높다는 뜻이다. 하지만 품질이나 내 업무와의 적합성을 보여 주지는 않는다. 오래된 모델일수록 숫자가 쌓여 있다는 점도 감안한다.

파생 모델은 base_model 메타데이터로 찾는다. 모델 카드 문서글에 따르면 허브는 현재 모델과 기반 모델의 관계를 adapter(LoRA 같은 어댑터), merge(여러 모델 병합), quantized(양자화), finetune(파인튜닝) 가운데 하나로 추론한다. 원본 페이지에서 이 관계별로 파생 모델을 찾아볼 수도 있다. 더 새로운 버전이 있으면 new_version 필드로 최신 모델 링크가 표시된다글. 오래된 버전을 고르지 않도록 이 링크를 확인한다.

내 GPU로 돌릴 수 있을까: 메모리 어림하기

가중치가 차지하는 GPU 메모리(VRAM)는 '파라미터 수 × 파라미터 하나당 바이트'로 어림한다. 정밀도별 바이트는 FP32가 4바이트, BF16·FP16이 2바이트, 8비트 정밀도가 1바이트다. 그러면 7B 모델은 FP32에서 약 28GB, BF16에서 약 14GB, 8비트에서 약 7GB가 된다. 70B 모델을 BF16으로 올리면 약 140GB라서 GPU 한 장으로는 어렵다. GGUF 문서글는 양자화 방식별 '가중치 하나당 비트 수'를 밝힌다. Q4_K는 4.5비트, Q5_K는 5.5비트, Q6_K는 6.5625비트다. 7B 모델을 Q4_K로 받으면 70억 × 4.5비트 ÷ 8로 약 3.9GB가 된다.

여기에 KV 캐시를 더해야 한다. KV 캐시는 모델이 앞서 읽은 토큰의 계산 결과를 저장해 두는 메모리다. 입력이 길수록, 동시에 처리하는 요청이 많을수록 커진다. 짧은 대화 하나라면 가중치 메모리에 약간의 여유만 더하면 되지만, 긴 문서를 넣거나 여러 사용자를 받으면 KV 캐시가 가중치만큼 커질 수도 있다. 실행 프로그램 자체도 메모리를 쓰니 넉넉히 잡는 편이 안전하다.

정확한 정밀도는 Files 탭에서 확인할 수 있다. GGUF 문서글에 따르면 허브의 GGUF 뷰어로 메타데이터와 텐서별 이름·모양·정밀도를 볼 수 있다. GGUF 파일은 llama.cpp, LM Studio, GPT4All, Ollama 같은 도구에서 바로 쓸 수 있다글. MoE 모델은 활성 파라미터가 작아도 전체 파라미터 기준으로 메모리를 계산한다는 점을 잊지 말아야 한다.

7B 모델 가중치 메모리 어림값

FP32

28GB

BF16

14GB

8비트

7GB

GGUF Q4_K

3.9GB

처음 고를 때 따라 할 순서와 점검 목록

첫째, 할 일을 정한다. 대화·요약 같은 업무라면 Instruct 모델을, 직접 파인튜닝할 계획이라면 Base 모델을 후보로 둔다. 둘째, 허브 목록에서 작업 종류와 라이선스로 거른다. 모델 카드 문서글에 따르면 pipeline_tag와 license 메타데이터로 목록을 거를 수 있다. 셋째, 내 GPU 메모리로 가능한 크기와 정밀도를 앞의 어림법으로 정한다. 넷째, 후보 모델 카드에서 용도·한계·학습 데이터·평가 방법을 읽는다. 다섯째, 원하는 형식(safetensors 원본 또는 GGUF 등 양자화판)을 고르고 base_model로 원본을 확인한다. 여섯째, 내 업무에서 뽑은 예시로 직접 돌려 보고 비교한다.

직접 돌려 볼 때는 채팅 템플릿을 꼭 맞춘다. 채팅 템플릿 문서글는 같은 Mistral-7B 기반 모델이라도 Mistral-7B-Instruct는 [INST] 토큰을, Zephyr는 <|user|>·<|assistant|> 토큰을 쓴다고 보여 준다. 그리고 잘못된 제어 토큰을 쓰면 성능이 크게 떨어진다고 경고한다. apply_chat_template로 모델에 딸린 템플릿을 적용하는 것이 안전하다.

점검할 항목은 다음과 같다. 라이선스가 우리 용도(상업 이용 포함)를 허락하는가. 파생 모델이라면 원본 라이선스도 확인했는가. 모델 카드에 용도와 한계, 학습 데이터, 평가 방법이 적혀 있는가. 벤치마크 평가 조건이 비교 대상과 같은가. 가중치와 KV 캐시를 합친 메모리가 GPU에 들어가는가. 가중치 형식이 내 실행 도구와 맞는가. 채팅 템플릿을 모델 것으로 적용했는가. new_version으로 더 새로운 버전이 표시되어 있지 않은가.

모델 고르는 순서

1. 1
   할 일 정하기대화는 Instruct, 학습 출발점은 Base
2. 2
   작업·라이선스로 거르기pipeline_tag·license 필터
3. 3
   크기·정밀도 정하기가중치 + KV 캐시 어림
4. 4
   모델 카드 읽기용도·한계·데이터·평가
5. 5
   형식·원본 확인safetensors·GGUF, base_model
6. 6
   내 예시로 직접 비교채팅 템플릿 맞추기

모델 고르기 점검 목록

권리

• 상업 이용을 허락하는 라이선스인가
• 파생 모델이면 원본 라이선스도 확인했나
• license: other면 원문을 읽었나

문서·성능

• 카드에 용도·한계·데이터·평가가 있나
• 벤치마크 평가 조건이 비교 대상과 같은가
• new_version에 더 새 버전이 있나

실행

• 가중치 + KV 캐시가 GPU에 들어가나
• 파일 형식이 실행 도구와 맞나
• 모델의 채팅 템플릿을 적용했나

흔한 실수와 더 공부하려면

흔한 실수는 네 가지다. 첫째, Base 모델을 채팅용으로 써서 엉뚱한 답을 받는다. 둘째, 템플릿을 적용한 글을 다시 토큰화하면서 특수 토큰을 중복으로 넣는다. 채팅 템플릿 문서글는 tokenize=False로 만든 글을 나중에 토큰화할 때 add_special_tokens=False를 쓰라고 권한다. 셋째, 라이선스 배지만 보고 상업 이용을 판단한다. 넷째, 가중치 크기만 계산하고 KV 캐시를 빼먹어 긴 입력에서 메모리가 부족해진다. 커뮤니티의 양자화판은 원본과 품질이 다를 수 있으니, 원본과 같은 예시로 비교해 보는 것도 좋다.

한계도 있다. 모델 카드는 올린 사람이 직접 쓰기 때문에 내용의 깊이와 정확도가 제각각이다. 모델 카드 논문논문이 제안한 '조건별 평가 결과'를 제대로 갖춘 LLM 카드는 아직 많지 않다. 카드에 빠진 정보는 없는 것으로 보고 직접 확인하는 태도가 필요하다.

더 공부하려면 Hugging Face 모델 카드 문서글부터 읽어 메타데이터 항목을 익히는 것이 좋다. 이어서 채팅 템플릿 문서글로 채팅 모델의 입력 형식을, GGUF 문서글로 양자화 종류를 익힌다. 모델 문서화가 왜 필요한지 배경을 알고 싶다면 모델 카드 논문논문의 서론을 권한다.

관련 용어

Hugging Face 모델 카드 모델 라이선스 Base·Instruct 모델 채팅 템플릿 GGUF safetensors 활성 파라미터

참고 문헌

참고 자료(공식 문서·엔지니어링 글)

• The Model Hub · Hugging Face (huggingface.co)
• Model Cards · Hugging Face (huggingface.co)
• Licenses · Hugging Face (huggingface.co)
• Chat templates · Hugging Face (huggingface.co)
• GGUF · Hugging Face (huggingface.co)
• Safetensors · Hugging Face (huggingface.co)

핵심 논문

• Model Cards for Model Reporting (2018)

AI가 참고 문헌을 바탕으로 작성하고 검수를 거친 해설입니다. 정확한 내용은 원문을 확인해 주세요.