"re generally tokens that shouldn" 발언은 GGUF(llama.cpp에서 사용하는 모델 파일 포맷) 내의 특수 토큰이 사용자에게 직접 노출되어서는 안 된다는 맥락에서 나왔다. 모델이 생성의 끝을 알리거나 내부적인 의미를 처리하는 특수 토큰의 역할을 정의한 설명이다. 이제 개발자들은 단순히 가중치 덩어리가 아니라, 이 파일 하나에 담긴 메타데이터가 어떻게 추론 성능을 결정짓는지 주목하고 있다.

GGUF의 단일 파일 구조와 메타데이터

이번 주 로컬 LLM 커뮤니티에서는 GGUF 포맷의 효율성에 대한 논의가 다시 뜨겁다. GGUF는 llama.cpp(C++ 기반의 LLM 추론 라이브러리)가 사용하는 파일 형식으로, 가중치와 설정을 파일 하나에 모두 담는다. 이는 여러 개의 JSON 파일이 흩어져 있는 safetensors(텐서 저장 포맷)나 레이어 구조의 JSON과 Go 템플릿이 섞인 ollama(로컬 LLM 실행 도구) 방식과 대조된다.

GGUF 내부에는 jinja2(파이썬 기반 템플릿 언어)로 작성된 채팅 템플릿이 포함된다. Gemma 4 같은 모델은 약 250줄에 달하는 jinja 스크립트를 통해 추론 시 메시지 형식을 결정한다. 이에 따라 Hugging Face transformers(파이썬 기반 모델 라이브러리)는 표준 jinja2를, llama-server는 자체 구현체를, NobodyWho(특정 추론 엔진)는 Rust로 구현된 minijinja(jinja의 Rust 버전)를 사용해 이를 처리한다.

샘플러 체인 통합과 툴 호출의 한계

예전에는 모델의 최적 성능을 내기 위해 마크다운 파일에서 샘플러 설정값을 일일이 복사해 붙여넣어야 했다. 하지만 최근 GGUF 표준에 general.sampling.sequence 필드가 추가되면서 샘플러 체인의 순서를 모델 파일에 직접 명시할 수 있게 되었다. 이는 순서에 따라 결과값이 달라지는 샘플링 과정에서 ollama의 JSON이나 HF의 generation_config.json이 제공하지 못하던 정밀한 제어를 가능하게 한다.

개발자가 체감하는 가장 큰 불편함은 여전히 툴 호출(Tool Call, 모델이 외부 도구를 사용하도록 요청하는 기능) 파싱에 남아 있다. Qwen3, Qwen3.5, Gemma 4 등 모델마다 툴 호출 형식이 제각각이라, 추론 엔진 개발자들은 새 모델이 나올 때마다 파서를 하드코딩해 업데이트해야 한다. GGUF 표준에 모델별 문법(Grammar, 텍스트 생성 규칙을 정의하는 체계)을 포함하는 기능이 추가된다면, 엔진이 이를 통해 자동으로 파서를 유도하는 구조로 바뀔 수 있다.

GGUF는 단순한 저장 포맷을 넘어 로컬 LLM 추론의 표준 운영체제가 되려는 움직임을 보이고 있다.