새로운 모델들을 시도해보고 싶어서 저 자신을 위해 빠르게 가이드를 만들었는데, 여러분과 공유하고자 합니다. 꽤 기초적인 내용이지만, 이곳의 초보자분들에게 유용할 수 있습니다.

또한 오픈 코드 설정(config)과 명령어가 포함된 저장소(repo)를 공개했습니다:
https://github.com/facuHannoch/AI_Workflows-Ornith-1.0

가이드
Ornith 1.0을 실행하기 전에 실제로 무엇을 다운로드하고 실행하는지 알 수 있도록 돕는 빠른 가이드입니다.
이 문서는 명칭과 기초 용어를 설명합니다. Ornith-1.0을 실행 예시로 사용하겠지만, 이는 거의 모든 오픈 모델 출시(release)에 적용됩니다.

Dense vs MoE
Ornith는 네 가지 파라미터(parameter) 크기로 제공됩니다: 9B Dense, 31B Dense, 35B MoE, 그리고 397B MoE.

Dense는 모든 토큰(token)마다 모든 파라미터가 활성화됨을 의미합니다. 9B Dense 모델은 매 단계마다 90억 개의 모든 파라미터를 사용합니다.

MoE (Mixture of Experts, 전문가 혼합)는 모델이 많은 "전문가(experts)"를 가지고 있지만, 각 토큰을 오직 몇 개의 전문가를 통해서만 라우팅(routing)함을 의미합니다. 35B MoE는 총 35B의 파라미터를 가지고 있지만, 토큰당 약 3B만을 활성화합니다.

MoE는 RAM이 아니라 연산 속도(compute speed)에 영향을 미친다는 점에 유의하세요. 토큰당 약 3B만 사용되더라도, 여전히 35B의 모든 파라미터를 메모리에 로드해야 합니다. 따라서 35B MoE는 9B Dense 모델보다 RAM이 적게 드는 것이 아니라 더 많이 필요합니다. 토큰당 속도는 더 빠르지만, 용량은 더 무겁습니다.

저장소(repo)마다 달라지는 두 가지 요소

1. 포맷 (파일이 패키징되는 방식): safetensors 또는 GGUF
2. 정밀도 (가중치당 비트 수): BF16, FP8, 또는 GGUF 양자화(quantization) 중 하나

이것들은 서로 다른 축입니다. 하나의 저장소는 전체 정밀도의 safetensors일 수도 있고, FP8의 safetensors일 수도 있으며, 다양한 양자화가 적용된 GGUF일 수도 있습니다. "포맷"과 "양자화"를 혼동하지 마세요. 이 둘은 서로 다른 질문에 답하기 때문입니다.

포맷: safetensors vs GGUF
safetensors는 표준 PyTorch/HuggingFace 컨테이너입니다. 이것이 "원시(raw)" 모델입니다. vLLM이나 transformers와 같은 도구들이 소비하는 방식이며, 미세 조정(fine-tuning)을 수행하는 대상입니다. 접미사가 없는 저장소(9B, 35B, 397B)는 전체 정밀도의 safetensors입니다.
GGUF는 llama.cpp(따라서 Ollama 및 LM Studio)를 위해 구축된 다른 컨테이너입니다.

단일 GGUF 리포지토리(repo)는 보통 내부에 여러 양자화(Quantization) 레벨을 포함하고 있습니다. 이는 노트북에서 로컬로 실행하고자 할 때 필요한 방식입니다. 접미사가 없는 리포지토리는 소스 코드와 같고, GGUF는 사용자의 기기에 맞춰 빌드된 컴파일된 압축 바이너리(Binary)라고 생각하면 됩니다. llama.cpp, ollama 등을 사용하여 실행하려면 이 바이너리가 필요합니다.

정밀도(Precision): BF16, FP8, 그리고 GGUF 양자화 모델(Quants)
원본 가중치(Weights)는 BF16(숫자당 16비트) 상태입니다. 양자화(Quantization)란 해당 정밀도를 낮추어 모델이 차지하는 메모리를 줄이는 것을 의미합니다.

FP8은 8비트 부동 소수점(Floating point)입니다. 품질의 대부분을 유지하면서 크기를 대략 절반으로 줄여줍니다. 이는 데이터센터 GPU(H100 등과 같이 FP8을 네이티브로 지원하는 모델)에서 사용됩니다. FP8은 여전히 safetensors 형식이지만 정밀도가 더 낮을 뿐이므로, 노트북이 아닌 vLLM과 함께 사용됩니다.

GGUF 양자화 모델(Quants)은 더 공격적이며 정수 기반(Integer-based)으로, CPU / Mac / 소비자용 GPU를 위해 설계되었습니다. 이들은 Q<bits>_<variant>라는 명명 패턴을 따릅니다:

[IMG:1]

• 숫자는 가중치당 비트(Bits per weight)를 의미합니다. 비트가 많을수록 품질이 높아지지만 크기도 커집니다.
• K는

참고로 이는 항상 동일한 모델이며, 단지 서로 다른 하드웨어와 서로 다른 작업에 맞춰 패키징되었을 뿐입니다.

놓치기 쉬운 한 가지: 모델의 출처
이는 주로 opencode 내에서 사용하거나, 도구(tools), 채팅 파서(chat parsers) 등을 사용할 때 관련이 있습니다.
Ornith GGUF 메타데이터는 아키텍처를 qwen35로 나열합니다. 이는 이 모델이 처음부터 학습된 모델이 아니라, Qwen 3.5를 기반으로 사후 학습(post-trained)되었기 때문입니다 (더 큰 제품군에서는 Gemma 4도 사용합니다). 파운데이션 모델(foundation model)을 처음부터 학습시키는 데는 수백만 달러가 듭니다. 연구소들은 보통 다음과 같이 합니다: 기존의 베이스(base)를 가져와서 이를 전문화(specialize)합니다.

이는 모델이 Qwen의 토크나이저(tokenizer)와 광범위하게는 그 채팅 템플릿(chat template)을 상속받음을 의미합니다. 따라서 Qwen 기반의 채팅 설정은 호환성이 높은 시작점이 됩니다.

하지만 완전히 동일하다고 가정해서는 안 됩니다. 이것은 추론 모델(reasoning model, <think>...</think> 블록으로 시작함)이자 에이전트형 코딩 모델(agentic coding model, <tool_call> 블록을 생성함)입니다. 이들은 각각 추론 파서(reasoning parser)와 도구 호출 파서(tool-call parser)가 필요하며, 서빙 레시피(serving recipes)가 이를 명시적으로 활성화합니다. 만약 이것을 에이전트형 도구에 연결했는데, 실제로 도구를 호출하지 않고 도구 사용에 대해 "말만" 한다면, 도구 호출 파싱(tool-call parsing)을 가장 먼저 확인해야 합니다. GGUF에 내장된 채팅 템플릿이 진실의 근원(source of truth)이며, 정확히 Qwen과 같을 것이라는 가정은 틀릴 수 있습니다.

선택을 위한 핵심 요약

노트북에서 로컬로 실행 → -GGUF 리포지토리, 시작은 Q4_K_M 권장.
데이터센터 GPU에서 서빙 → vLLM과 함께 -FP8 (또는 raw) safetensors 사용.
파인튜닝 (Fine-tuning) → 접미사가 없는(no-suffix) safetensors 사용.

그 외의 모든 것은 여러분이 실제로 보유한 환경에 맞춰 변형(variant)을 맞추는 과정입니다.
submitted by /u/facu_75
[link] [comments]