AI 뉴스

GGUF에는 가중치 외에 무엇이 들어 있고, 아직 무엇이 빠져 있나?

노동1호 2026. 5. 17. 19:07

GGUF에는 가중치 외에 무엇이 들어 있고, 아직 무엇이 빠져 있나?

GGUF는 로컬에서 대규모 언어 모델을 돌리는 사람이라면 누구든 한번은 만나게 되는 파일 형식이다. llama.cpp가 채택한 이 포맷은 단순히 가중치를 담는 그릇이 아니라, 모델을 올바르게 실행하는 데 필요한 메타데이터까지 한 파일에 밀어 넣는다. Hugging Face의 safetensors처럼 별도의 JSON이 여기저기 흩어진 형태와 비교하면 관리 포인트가 하나 줄어드는 이점이 있다.

그렇다면 GGUF에는 정확히 어떤 정보가 들어 있고, 현재로서 무엇이 부족해 추론 엔진 개발자가 고생하고 있을까? 긱뉴스에서 논의된 내용을 중심으로 정리했다.

GGUF가 담는 것들

채팅 템플릿: 대화 형식의 핵심

대화형 언어 모델은 입력 프롬프트를 특정 형식의 토큰 시퀀스로 구성해야 올바르게 동작한다. <|turn|>user 안녕하세요 같은 마크업이 이에 해당한다. 실제 모델의 채팅 템플릿은 훨씬 복잡해서, Gemma 4 기준으로 약 250줄짜리 Jinja2 스크립트가 포함되기도 한다.

<|turn|>user Hi there!<|turn|>model Hi there, how can I help you today?

GGUF의 메타데이터에서는 이 템플릿이 tokenizer.chat_template 키 아래 저장된다. 모델 하나가 도구 호출용과 비도구 호출용으로 별개의 템플릿을 가진 경우도 있다.

Jinja2 구현체는 엔진마다 다른데, Hugging Face의 transformers는 Python의 jinja2 라이브러리를 쓰고, llama.cpp 기반의 llama-server와 llama-cli는 C++로서카레타 자체 구현체를 쓴다. 속도 차이는 있지만, 채팅 템플릿 처리가 실제 병목이 되는 경우는 드물다.

특수 토큰: 생성을 멈추는 힘

언어 모델은 토큰 시퀀스를 입력받아 다음 토큰을 무한히 출력할 수 있다. 이 무한 루프에서 벗어나려면 종료 토큰이 필수다. GGUF는 이런 특수 토큰의 목록과 권장 샘플러 설정을 함께 담을 수 있다.

Gemma 4의 특수 토큰 예시를 보면 (종료), (시퀀스 시작), <|tool_call|>(도구 호출 시작), <|turn|>(대화 턴 경계) 등 모델마다 수십 개의 토큰이 정의되어 있다.

샘플러 체인: 순서가 결과를 바꾼다

모델이 출력한 확률 분포에서 최종 토큰을 선택하는 과정을 샘플링이라고 한다. 단순히 확률이 가장 높은 토큰을 고르는 것도 방법이지만, 온도(temperature) 조절, 반복 페널티, 최상위 p 필터링 등 여러 변환을 거치면 훨씬 품질 높은 결과를 얻을 수 있다.

연구소에서 권장 샘플러 설정을 별도로 제공하는 경우가 많은데, 과거에는 사용자가 직접 값을 복사해 붙여넣어야 했다. GGUF의 최근 업데이트로 general.sampling.sequence 필드에 샘플러 체인의 순서를 모델 파일 안에 직접 명시할 수 있게 되었다. 덕분에 별도의 설정 파일 없이도 모델이 의도한 샘플링 파이프라인을 그대로재현할 수 있다.

아직 빠져 있는 것들

도구 호출 형식: 엔진별 하드코딩의 원인

도구 호출은 로컬 LLM 애플리케이션에서 가장 복잡한 부분 중 하나다. 문제는 모델마다 도구 호출 형식이 완전히 다르다는 데 있다.

Qwen3는 이런 형식을 사용한다.

{"name": "get_weather", "arguments": {"location": "Copenhagen"}}

같은 Qwen3.5는 전혀 다른 형식을 쓴다.

 Copenhagen

Gemma 4는 또 다르다.

<|tool_call>call:get_weather{city:<|"|>Copenhagen<|"|>}

새 모델이 나올 때마다 각 추론 엔진(Qwen.cpp, llama.cpp, ollama 등)가각자 파서를 구현해야 하는 상황이다. GGUF 표준에 문법(grammar)을 포함해서 파서를 도출할 수 있다면 큰 진전이지만, 현재로서는 임시방편이 계속되고 있다.

think_token: 생각 구간 분리의 필요

최근 모델 중 일부는 출력의 "사고" 구간을 같은 태그로 감싸는 경우가 있다. 사용자에게 보여줄 때는 이 구간을 제거하거나 다르게 렌더링해야 한다. 문제는 Hugging Face 저장소에는 think_token 필드가 포함되어 시작했지만, GGUF 변환 파이프라인에서는 이 필드가 누락되는 경우가 많다는 점이다.

결과적으로 GGUF 기반 추론 엔진은 모델 계열별 별도 코드 경로 없이는 생각 스트림을 깔끔하게 분리하지 못한다.

프로젝션 모델 번들링: 단일 파일 철학의 균열

멀티모달 LLM에서 이미지나 오디오를 텍스트가 아닌 형태로 처리하려면 추가 모델이 필요하다. 이를 프로젝션 모델이라고 한다. 현재 관례는 주 언어 모델용 GGUF와 별개로 프로젝션 모델용 GGUF 파일을 전달하는 방식이다.

이는 GGUF의 단일 파일 편의성을 깨뜨린다. 프로젝션 모델의 크기가 대략 1GB에 달하는 것을 고려하면, 사용하지 않을 때 이 오버헤드를 피하고 싶은적수구도 현실적이다. GGUF 안에 프로젝션 가중치를 포함하는 variant를 제공할지 아니면 계속 분리할지의 결정이 남아 있다.

지원 기능 목록: 모델의 진짜 능력을 알 수 없다

GGUF 파일만 보고 모델이 진짜 어떤 기능을 지원하는지 알기가 어렵다. 이미지를 지원하는지, 네이티브 도구 호출이 가능한지, 생각 블록을 출력하는지 — 이런 정보를 GGUF 메타데이터에서 직접 확인할 방법이 없다.

현재 우회 방법은 프로젝션 모델 존재 여부로 이미지 지원 유무를 추측하거나, 채팅 템플릿에서 특정 문자열 패턴을 찾는 것이다. 기능 플래그가 GGUF 표준에 추가되면, 추론 엔진이 모델 비의존 방식으로 적절한 오류 메시지와 경고를 제공할 수 있을 것이다.

마무리

GGUF는 단순한 가중치 컨테이너를 넘어 모델 실행에 필요한 부가 정보를 한 파일에 모아 추론 엔진의 모델별 코드 경로를 줄이는 데 기여하고 있다. 개방적이고 확장 가능한 형식이라는 점에서 커뮤니티의 지지를 받고 있으며, 도구 호출 문법, think_token, 프로젝션 모델 번들링, 기능 플래그 등의 개선이 진행 중이다.

로컬에서 LLM을 운용하는 생태계가 성숙할수록 GGUF의 역할은 더 중요해질 것이다. 단일 파일이라는 철학이 지켜지는 가운데, 커뮤니티가 부족한 부분을 채워나가는 과정이치득관주이다.