모델 이름이 중요한 이유
Hugging Face 또는 Ollama의 모델 라이브러리를 둘러볼면Qwen/Qwen3-235B-A22B-Instruct 또는 bartowski/Llama-3.3-70B-Instruct-GGUF와 같은 이름을 볼 수 있습니다. 이는 무작위 문자열이 아닙니다. 각 세그먼트는 다운로드하기 전에 날려야 할 결정을 인코딩합니다.
이름은 다음을 알려줍니다.
- How big the model is — 따라서 필요한 VRAM 또는 시스템 메모리 양.
- What it was trained for — 일반 채팅, 코딩, 사고(reasoning), 비전, 또는 원시 텍스트 완성.
- How it was compressed — 그리고 크기와 교환되는 품질.
- Who made it — 그리고 가중치가 원래 것인지 또는 제삼자의 재포장인지 여부.
모델 이름의 합리학
대부분의 오픈 웨이트 모델 이름은 다음 패턴을 따릅니다.
세그먼트별로 구문 분석된 실제 예시:
Qwen/Qwen3-235B-A22B-Instruct
mistralai/Mistral-7B-Instruct-v0.3
TheBloke/Llama-2-7B-Chat-GGUF — TheBloke (제삼자 양자화 도구), Llama 2, 7B 파라미터, 채팅 튜닝, GGUF 형식.
조직이
TheBloke, bartowski, 또는 unsloth와 같은 제삼자 양자화 도구인 경우, 모델 자체는 다른 사람이 학습했으며 — 리포지토리는 원래 가중치의 재포장 또는 양자화 버전을 포함합니다.크기 라벨 해석
숫자는B 앞에 있으며, 이는 십억 단위의 파라미터 수입니다. 이는 기능과 메모리 요구 사항 모두의 가장 큰 결정 요인입니다.
MoE 모델: 두 개의 숫자
MoE (mixture-of-experts) 모델은 총 파라미터와 활성 파라미터를 모두 나열하며,235B-A22B 또는 30B-A3B로 작성됩니다.
- 첫 번째 숫자는 total 파라미터 수입니다 — 메모리 또는 디스크에 저장해야 하는 양.
- 두 번째 숫자 (
A뒤)는 active 파라미터 수입니다 — 토큰당 실행되는 파라미터 수.
235B-A22B 모델은 235B 파라미터를 보유할 만큼 충분한 메모리가 필요하지만, 한 번에 22B만 계산하므로 dense 235B 모델보다 토큰 생성 속도가 훨씬 빠릅니다. 트레이드오프: MoE 모델은 동일한 활성 크기의 dense 모델보다 디스크와 메모리에서 더 크지만, 추론 시 더 빠릅니다.
예를 들어
235B-A22B MoE 모델은 토큰당 속도 측면에서 dense 22B 모델과 대략적으로 일치하지만, 여전히 모든 235B 파라미터를 저장하기 위해 VRAM 또는 시스템 RAM이 필요합니다. Q4_K_M에서 이는 대략 120 GB로 — dense 22B 모델의 13 GB보다 훨씬 많습니다.파라미터 수가 기능에 매핑되는 방식
파라미터가 많을수록 일반적으로 기능이 더 강력해지지만, 관계는 선형적이지 않습니다. 70B 모델이 10x 더 좋은 것은 아닙니다 — 7B 모델보다 사고(reasoning), 뉘앙스, 복잡한 작업에서 눈에 띄게 더 좋을 뿐입니다. 하지만 잘 튜닝된 7B 모델은 여전히 일상적인 채팅과 간단한 코딩 작업을 잘 처리할 수 있습니다. 올바른 크기는 하드웨어와 작업에 따라 달라지며, 단순히 크기가 클수록 좋다는 규칙에만 의존하지 않습니다.아키텍처 접미사
게시자는 베이스 모델 이상의 아키텍처 변종을 신호하기 위해 접미사를 추가합니다. 이는 모델이 수행할 수 있는 작업과 필요한 하드웨어에 영향을 미칩니다.Dense vs MoE
Dense vs MoE
일반적으로 dense 모델은 모든 토큰에 모든 파라미터를 사용합니다. MoE (mixture-of-experts) 모델은 각 토큰을 “전문가” 서브네트워크의 하위 집합을 통해 라우팅합니다. MoE 모델은 총 파라미터가 더 크지만 활성 파라미터만 계산하므로 토큰당 속도가 더 빠릅니다. 모델 이름에 두 개의 크기 숫자가 포함되면 (예:
235B-A22B), 이는 MoE입니다.VL (vision-language)
VL (vision-language)
이름에
-VL이 붙은 모델은 텍스트 외에도 이미지 또는 비디오를 받습니다. 예시: Qwen3-VL-32B-Instruct, gemma-4-12b-it. VL 모델은 언어 모델 가중치 위에 비전 인코더를 위한 추가 VRAM이 필요합니다.Coder
Coder
이름에
-Coder가 붙은 모델은 주로 코드에 대해 파인튜닝되거나 학습되었습니다. 프로그래밍 작업에서 동일한 크기의 일반 모델보다 일반적으로 더 우수하지만, 개방형 대화에서는 더 약할 수 있습니다. 예시: Qwen3-Coder-480B-A35B-Instruct.Math / reasoning
Math / reasoning
모델들은
-Math 또는 사고(reasoning) 전용 라벨이 있는 경우 수학 문제 해결 및 사고의 사슬(chain-of-thought) 데이터에 대해 학습되었습니다. 동일한 크기의 일반 모델보다 단계별 논리에서 더 강력하지만 범위가 더 좁습니다."next" or preview
"next" or preview
일부 게시자는 실험적 릴리스를
next, preview, 또는 experimental로 태그합니다. 이는 불완전한 학습 또는 테스트되지 않은 채팅 템플릿을 가질 수 있으며 — 평가에는 유용하지만 프로덕션에는 적합하지 않습니다.학습 단계 라벨
학습 단계는 모델이 대화를 나눌 수 있는지 아니면 단순히 텍스트를 완성하는지 알려줍니다. 이는 모델이 상자에서 바로 사용 가능한지 여부를 결정하는 데 가장 중요한 세그먼트입니다.Instruct와 Chat은 대부분의 목적에서 상호 교환 가능합니다 — 둘 다 모델이 사용자 프롬프트에 응답하도록 파인튜닝되었음을 의미합니다. Chat은 더 오래된 라벨입니다 (Llama 2가 사용함); Instruct는 더 새로운 계열에서 더 일반적입니다. Mistral과 같은 일부 게시자는 둘 다 사용하지 않고 대신 베이스 이름과 함께 버전 태그 (v0.3)에 의존합니다.
로컬 사용을 위해서는 거의 항상
Instruct 또는 Chat이 필요합니다. Base 모델은 지시를 따를 수 없습니다 — 텍스트만 완성합니다 — 그리고 채팅봇처럼 프롬프트하면 혼란스러운 출력을 제공합니다.양자화 라벨 (GGUF 세계)
GGUF 양자화 라벨은 llama.cpp quantize README에 문서화된 명명 규칙을 따릅니다.Q 숫자는 가중치당 대략적인 비트 수입니다; 높을수록 파일이 더 크고 품질이 더 높습니다. K-quants는 혼합 정밀도를 추가합니다 — 민감도에 따라 다른 텐서가 다른 비트 폭을 받습니다 — 그리고 접미사 S/M/L은 해당 레벨 내의 소/중/대 변종을 표시합니다.
실용적인 가이드와 함께 만나게 될 전체 범위입니다:
실용적인 스위트 스팟
Q4_K_M— 여기서 시작하세요. 좋은 품질, 소비자 하드웨어에 적합.Q5_K_M— VRAM에 여유가 있을 때 단계적으로 업그레이드. 대부분의 작업에서 거의 손실 없음.Q8_0— 최소한의 손실. 품질이 중요하고 메모리가 있을 때 사용.Q3_K_M—Q4_K_M에서 로드되지 않는 더 큰 모델을 맞추기 위해만 이 수준으로 낮추세요. 품질 저하를 예상하세요.
크기 비교: 각 quant에서의 7B 모델
I-quants (imatrix) vs K-quants
또한IQ로 시작하는 양자화 이름, 즉 IQ4_XS 또는 IQ3_XXS를 볼 수도 있습니다. 이들은 imatrix quants이며, 중요성 행렬을 사용하여 빌드됩니다: 양자화 도구에게 어떤 가중치가 가장 중요한지 알려주는 교정 데이터, 따라서 이를 더 신중하게 보존할 수 있습니다. I-quants는 동일한 비트 폭에서, 특히 매우 낮은 비트 폭에서 K-quants보다 더 나은 품질을 제공할 수 있지만, 양자화 프로세스가 더 느립니다. 리포지토리가 Q4_K_M와 IQ4_M을 모두 제공하는 경우, I-quant가 약간 더 나을 수 있습니다 — 그러나 차이는 일반적으로 작아 둘 다 작동합니다.
양자화가 어떻게 작동하는지와 K-quants가 단순 quants보다 성능이 더 나은 이유에 대한 더 깊은 설명은 Quantization를 참조하세요.
기타 일반적인 접미사
양자화 라벨 외에도, 모델 이름에는 파일을 로드할 수 있는 백엔드를 알려주는 형식 및 정밀도 태그가 포함됩니다.GGUF
GGUF
이 형식은
llama.cpp 기반 백엔드 — Ollama, LM Studio, 및 모든 llama.cpp 서버에서 사용하는 형식. GGUF 파일은 가중치, 토크나이저, 및 채팅 템플릿을 1개의 파일로 번들링합니다. 대부분의 소비자 하드웨어는 GGUF를 실행합니다.GPTQ
GPTQ
GPU 양자화 형식 (일반적으로 4비트 또는 8비트) —
AutoGPTQ 또는 vLLM을 통해 NVIDIA GPU에서 실행됩니다. GPU에서 GGUF보다 빠르지만 NVIDIA 전용이며 llama.cpp 백엔드와 호환되지 않습니다.AWQ
AWQ
활성화 인식 가중치 양자화 — GPTQ와 유사하지만 활성화 통계를 사용하여 교정하는 또 다른 GPU 형식.
vLLM 및 일부 다른 추론 엔진에서 지원됩니다. NVIDIA GPU.EXL2
EXL2
ExLlamaV2 형식 — 다른 레이어가 다른 비트 폭을 사용하는 혼합 비율 양자화를 지원합니다. NVIDIA GPU 및 ExLlamaV2 추론 엔진을 위해 최적화되었습니다.
FP16 / BF16
FP16 / BF16
전체 16비트 정밀도.
FP16 (float16)과 BF16 (bfloat16)은 모두 파라미터당 2바이트입니다. BF16은 더 넓은 지수 범위를 가지고 학습 중에 더 수치적으로 안정적입니다; 추론의 경우, 둘 다 비슷하게 작동합니다. vLLM 또는 유사한 엔진이 필요합니다.FP8
FP8
8비트 부동 소수점 — FP16의 절반 크기이며 최소한의 품질 손실. FP8을 지원하는 GPU (NVIDIA Ada Lovelace 및 이후, AMD MI300)에서
vLLM 및 SGLang과 같은 추론 엔진에 의해 사용됩니다.NVFP4
NVFP4
NVIDIA의 4비트 부동 소수점 형식 — DGX Spark를 포함한 Blackwell GPU에서 사용할 수 있습니다. 하드웨어 네이티브 지원을 갖춘 공격적인 크기 감소를 제공합니다 — DGX Spark model compatibility를 참조하세요.
게시자 vs 제삼자 양자화
여러 당사자가 동일한 모델의 양자화 버전을 자주 게시합니다:- Publisher quants — Qwen, Mistral, Google 및 기타는 점점 더 전체 정밀도 가중치와 함께 자체 GGUF 파일을 배송합니다. 이는 게시자가 원래 가중치와 채팅 템플릿을 제어하기 때문에 일반적으로 가장 안전한 선택입니다.
- Unsloth — 최적화된 채팅 템플릿과 동적 양자화를 갖춘 GGUF quants를 배송합니다. 또한 매우 작은 1.58비트 (
unsloth/...-1.58bit) 변종도 제공합니다. 일반적으로 신뢰할 수 있고 널리 사용됩니다. - TheBloke — GGUF 배포 생태계를 정의하는 데 도움이 된 리포지토리를 가진 다产的 초기 양자화 도구. 잘 조직되어 있지만 최신 모델보다 뒤처지거나 최근 릴리스의 채팅 템플릿 업데이트를 놓칠 수 있습니다.
- bartowski — 일관된 명명과 새로운 릴리스에 대한 좋은 커버리지를 갖춘 활동적인 커뮤니티 양자화 도구. 새로운 모델이 출시될 때 GGUF 변종을 게시하는 데 종종 첫 번째 그룹에 속합니다.
제삼자 quant 검증 방법
- 리포지토리가 원래 모델로 다시 링크하는지 확인하세요.
- 파일 크기를 해당 양자화 레벨에서 예상되는 것과 비교하세요 (위의 표가 참조입니다).
- 채팅 템플릿 메타데이터를 찾으세요 — 누락되거나 잘못된 템플릿은 출력을 조용히 저하시킵니다.
- 양자화에 대한 perplexity 벤치마크가 게시된 경우, 게시자 자신의 숫자와 비교하세요.
빠른 결정 가이드
하드웨어를 모델 크기와 양자화 레벨에 매치하세요:8 GB VRAM
7B Q4_K_M 또는 14B Q3_K_M. 편안한 quant에서 더 작은 모델을 고수하세요 — 7B(Q4_K_M)가 14B(Q2_K)보다 성능이 더 좋습니다.16 GB VRAM
14B Q5_K_M 또는 32B Q4_K_M. 14B(Q5)는 거의 손실 없음; 32B(Q4)는 일부 품질을 희생하여 훨씬 더 많은 기능을 제공합니다.24 GB VRAM
32B Q5_K_M 또는 70B Q4_K_M. 32B(Q5)는 단일 GPU 품질의 스위트 스팟입니다. 70B(Q4)는 기능을 더 높게 밀지만 VRAM의 대부분을 채웁니다.48 GB+
70B Q5_K_M 또는 오프로딩을 갖춘 235B-A22B Q4_K_M과 같은 MoE 모델. 가장 큰 모델의 고품질 quant를 위한 공간이 있습니다.128 GB (DGX Spark)
120B+ MoE 모델을 FP8 또는 NVFP4에서. 프론티어 스케일 모델의 전체 정밀도 또는 거의 전체 정밀도. DGX Spark model compatibility를 참조하세요.CPU only
3B Q4_K_M 또는 7B Q3_K_M. CPU 추론은 느립니다 — 모델을 작게 유지하세요. 초당 1–5 토큰을 예상하세요.이는 시작점입니다. 실제 VRAM 사용량은 컨텍스트 길이 (KV 캐시는 컨텍스트와 함께 성장), 배치 크기, 및 백엔드가 레이어를 시스템 RAM으로 오프로드하는지 여부에 따라 달라집니다. 정확한 크기 측정을 위해 Model fit guide를 사용하세요.
명명 레드 플래그
모든 모델 이름이 관례를 따르는 것은 아니며, 일부 패턴은 주의가 필요합니다:- No size label — 파라미터 수가 없는 모델 이름은 무엇이든 될 수 있습니다. 다운로드하기 전에 모델 카드를 확인하세요.
- “Uncensored” variants — 보통 그냥 안전성 학습이 제거된 것일 뿐, 기능 개선이 아닙니다. 베이스 모델의 품질은 변경되지 않았거나 제거가 정렬을 깨뜨린 경우 더 나쁠 수 있습니다.
- Merged models — 2개 이상의 모델에서 가중치를 결합합니다 (예: 코딩 모델과 채팅 모델 병합). 품질은 크게 다양하며 이름만으로는 예측하기 어렵습니다. 병합 방법 (SLERP, DARE, TIES) 및 평가 결과가 게시되었는지 확인하세요.
- Extremely low quants —
Q2_K는 모델이 로드되는지 테스트하는 것을 제외하고는 거의 항상 너무 손실이 큽니다. 저하된 사고(reasoning), 깨진 포맷팅, 및 환각을 예상하세요. 모델이 Q2 quants만 배송하는 경우, 동일한 파라미터 수의 다른 모델을 찾으세요. - Version numbers without changelogs — 버전 간에 변경된 내용에 대한 명확한 설명 없이
v0.1에서v0.9. 특정 이유가 없는 한 최신 버전을 사용하세요. - “AWSD” or similar hype tags — 일부 리포지토리는 표준 기술과 대응하지 않는 주목을 끄는 접미사를 추가합니다. 용어를 다른 곳에서 찾을 수 없으면 회의적으로 대하세요.
모두 합치기
예시로unsloth/Qwen3-30B-A3B-Instruct-GGUF를 가져옵니다. 왼쪽에서 오른쪽으로 읽기:
unsloth— Unsloth (제삼자 양자화 도구)에 의해 양자화됨.Qwen3— Qwen3 아키텍처, 알리바바의 현재 세대.30B-A3B— MoE 모델: 총 30B 파라미터, 토큰당 3B 활성.Instruct— 지시 튜닝, 채팅 준비 완료.GGUF—llama.cpp형식, Ollama, LM Studio, 또는 모든llama.cpp백엔드에서 실행.
Q4_K_M에서 8 GB VRAM에 맞고, 지시를 따를 수 있습니다. 시도할지 여부를 결정하기 위해 모델 카드를 열 필요가 없습니다.
이제 meta-llama/Llama-3.3-70B-Instruct와 비교하세요. 이는 Meta의 Llama 3.3, 70B dense 파라미터, 지시 튜닝 — GGUF 태그가 없으므로 vLLM 또는 유사한 엔진이 필요한 전체 정밀도 가중치를 보고 있다는 의미입니다. 이름은 이것이 심각한 하드웨어가 필요한 대형 고품질 모델임을 알려줍니다.
다음: 모델 카드 읽기
이제 이름을 해석할 수 있으므로, model card는 이름이 생략한 모든 것을 알려줍니다 — 컨텍스트 길이, 라이선스, 채팅 템플릿, 및 의도된 사용.모델 카드 읽기
다운로드하기 전에 중요한 파라미터, 아키텍처, 컨텍스트 길이, 및 라이선스를 찾으세요.
양자화
양자화가 어떻게 작동하는지와 K-quants가 단순 quants보다 성능이 더 나은 이유.
모델 적합 가이드
모델 및 양자화 조합이 하드웨어에 맞는지 확인하세요.