GGUF vs safetensors — 런타임이 결정하며, 형식이 아니다

원래 mrsaynothing.dev에 게시됨 · 2026년 10월 14일. 기록된 것은 읽는 것이지, 실행하는 것이 아니다 — 아래의 모든 숫자는 하나의 curl로 확인할 수 있다.

DuckDuckGo는 gguf vs safetensors를 마치 두 파일 확장자 간의 케이지 파이트인 것처럼 자동 완성한다. 이것은 게이트 체크다. GGUF를 선택하면 한 선반의 런타임이 열린다 — llama.cpp, Ollama, LM Studio, Jan. safetensors를 선택하면 다른 선반이 열린다 — transformers, vLLM, ComfyUI. 형식은 열릴 문들의 목록일 뿐이며, 나머지는 모두 그 뒤를 따른다. 이 글이 거부하는 거짓말은, 속도 수치로 싸움이 결정된다는 것인데, 아무도 같은 박스에서 일치시킨 적이 없다.

기록이 무료로 제공하는 것 — 그리고 대부분의 주장이 건너뛰는 것 — 은 각 컨테이너가 무엇을 담고 있는지, 그리고 각각을 어디서 열 수 있는지를 알려준다.

실제로 무엇을 선택하고 있는가?

GGUF는 llama.cpp 개발자들이 만든 단일 파일 컨테이너이며, 양자화(quantization)가 텐서별로 내장되어 있다 — 모두가 논쟁하는 그 양자화 사다리는 오직 이 형식 안에만 존재한다. 하나의 파일이 가중치(weights), 토크나이저(tokenizer), 채팅 템플릿을 담고 있다: 이 파일 자체가 배포판이다. safetensors는 직렬화 컨테이너이며 — JSON 헤더와 원시 텐서 바이트로 구성되어 있다 — 그리고 학습 레포지토리가 보낸 모든 정밀도, 보통 BF16 또는 FP16을 담는다. 이는 양자화하지 않고 저장한다.

safetensors는 그 단 하나의 역할에서 이름을 따왔다: 모델 로드 시 아무도 pickling되는 것을 방지하는 것이다. Python의 pickle은 언패킹(unpack) 시 코드를 실행하지만, safetensors는 아무것도 실행하지 않는다 — 이것이 전체 보안 주장이며, Hugging Face 생태계가 이를 표준화한 이유이다.

같은 모델을 각 컨테이너에 담아보면 그 철학이 바이트 단위로 드러납니다. 2026년 10월 14일, 동일한 Qwen3-0.6B가 다음과 같이 배포되었습니다: Q4_K_M GGUF, 396,705,472 bytes (397 MB) · BF16 GGUF, 1,198,182,848 bytes (1.20 GB) · BF16 safetensors, 1,503,300,328 bytes (1.50 GB). 양자화된 컨테이너가 전체 정밀도(full-precision) 컨테이너의 4분의 1을 차지하는 것은 정밀도가 4분의 1이기 때문입니다. 그리고 이 숫자들 각각은 별도의 벤치마크 장비 없이 여러분의 터미널에서 curl -I 명령 한 번만으로 확인할 수 있습니다. 누락된 정밀도가 품질에 비용을 지불하게 할지는 바이트가 답할 수 없는 충실도(fidelity) 문제입니다.

형식(format)은 선호 사항이 아닙니다. 여러분의 파일을 열어줄 런타임 목록입니다.

바이트들이 말하는 것은 무엇인가?

기록을 읽는 데 있어 정직한 규칙은 오직 기록에 명시된 숫자만을 인용하고, 출처를 밝히며, 벤치마크 같은 허구적 꾸밈을 배제하는 것입니다. 이 표는 하나의 모델, 세 개의 컨테이너, 그리고 실제로 배포된 정확한 바이트 수를 담고 있습니다. 어떤 것도 믿기 전에 직접 확인해 보세요.

curl -sIL https://huggingface.co/unsloth/Qwen3-0.6B-GGUF/resolve/main/Qwen3-0.6B-Q4_K_M.gguf | grep -i content-length

BF16 및 safetensors 파일에 대해서도 동일한 한 줄 명령을 사용하면 됩니다. 바이트 수는 같은 날이든 어느 날이든 같습니다.

표를 정직하게 읽으십시오. 26%는 양자화 계단(quantization ladder)의 전체 약속입니다. 디스크와 RAM에서 16비트였던 곳에 4비트를 사용한 것입니다. 두 전체 정밀도 행 사이의 간격, 즉 1.20 GB 대 1.50 GB는 물리적인 현상이 아니라 패킹 오버헤드(packing overhead)입니다. llama.cpp의 BF16 패킹은 원시 데이터 덤프보다 더 효율적으로 동일한 텐서(tensors)를 저장합니다. 바이트가 말할 수 없는 것은 속도나 품질이며, 일치하는 상자 없이 토큰/초(tokens-per-second) 열을 제시하는 것은 포럼의 잡음일 뿐이며, 이 글은 그런 것을 게재하기를 거부합니다.

세 가지 벽이 명확하게 제시됩니다. 첫째, 품질입니다. Q4와 BF16은 충실도(fidelity)의 트레이드오프이며, 어떤 바이트 카운트가 이를 측정할 수는 없습니다. 둘째, 속도입니다. 로딩 시간과 초당 토큰 수는 특정 장비에서 매칭된 벤치마크에 속하며, 이 글에는 그러한 것이 없으므로 언급하지 않습니다. 셋째, 규모(scale)입니다. 0.6B 모델의 바이트 비율은 70B에서도 형태를 유지하지만, 70B에서 느껴질 절대적인 무게감은 다른 하드웨어에서는 별개의 문제입니다.

각 형식이 실제로 실행되는 곳은 어디인가?

이 부분이 실제 결정을 내립니다. GGUF는 llama.cpp, Ollama, LM Studio, Jan 등 단일 파일 로컬 생태계에서 열립니다. vLLM도 플러그인을 통해 GPU 상에서 GGUF를 읽을 수 있지만 주의할 점이 있습니다. Safetensors는 transformers, vLLM(네이티브), ComfyUI, 그리고 Apple의 MLX 툴링에서 열립니다. 이 경계에서의 중첩은 교훈적입니다. Ollama — GGUF 엔진을 기반으로 구축된 애플리케이션 — 이더라도 Apple Silicon 사용자가 safetensors로 파생된 가중치를 로드할 수 있도록 여전히 MLX 러너를 제공합니다. 심지어 이 애플리케이션조차도 대비책을 마련하고 있습니다.

GGUF는 양자화를 기본값으로 만들고; safetensors는 전체 정밀도(full precision)를 기본값으로 만듭니다. 이 기본값이 가장 큰 결정 요인입니다.

어떤 것을 서빙해야 하는가?

어떤 표를 확인하기 전에 이미 설치된 것을 확인하십시오. 만약 장치가 ollama run에 응답한다면, 당신은 GGUF 국가에 살고 있으니 Q4_K_M 파일을 가져와 포럼 읽는 것을 멈추십시오. 만약 당신의 하루가 Python으로 이루어져 있거나 서빙 계층이 vLLM이라면, safetensors는 애초에 선택지가 아니었습니다. 그것은 생태계의 네이티브 언어입니다. 두 형식 간의 변환은 가능하지만 거의 가치가 없습니다. 모든 변환은 가중치들이 조용히 달라지는 새로운 지점을 만듭니다.

정직한 선언, 저희 스타일입니다: 저는 기록을 읽었지, 직접 실행해보진 않았습니다. 위에 제시된 모든 수치는 이 게시물이 올라온 아침에 가져온 파일에서 나온 것입니다—벤치 리그(bench rig)도 없고, 초당 토큰 개수 코스프레도 없습니다. 이 기록이 확립하는 것은 트레이드(trade)의 형태입니다—양자화된 컨테이너를 위해 4분의 1 바이트가 필요하고, 거의 겹치지 않는 두 개의 런타임이 있으며, 각 측면에서 기본 정밀도가 대부분의 사람들을 조용히 결정합니다.

아무도 속도를 위해 형식을 바꾼 적이 없습니다. 그들은 기능을 위해 런타임을 바꿨고, 그 형식은 티켓처럼 따라왔을 뿐입니다.

이제 여러분 차례입니다

이것은 토론 중심의 글이기 때문에 논쟁은 댓글로 옮겨집니다. 제 입장은 다음과 같습니다: 먼저 런타임을 선택하고, 형식이 뒤따르게 하세요. 제가 반박에 직면할 것이라고 예상하는 부분은—공정한 비교를 위해서는 의견보다 이름 붙여진 상자가 필요하다는 주장과, 대부분의 형식 논쟁이 코스튬을 입은 런타임 논쟁이라는 것입니다.

그래서 논쟁할 만한 두 가지가 있습니다: 실제 사용하시는 장비(daily driver)는 어느 선반에서 꺼내 쓰나요—그리고 여기서 누가 실제 작업에서 Q4 품질 저하를 느껴본 적이 있나요, 아니면 그건 포럼의 속설인가요? 런타임과 모델 이름을 밝혀주세요; 가장 근거가 확실한 답변이 다음 글의 조건을 설정할 것입니다.