2026년 9월 22일, Hugging Face는 공식 블로그를 통해 transformers가 GGUF 양자화 모델을 직접 불러올 수 있게 되었다고 발표했다. from_pretrained에 gguf_file 인자만 넘기면 Hub의 GGUF 체크포인트를 익숙한 transformers API에 올려 로컬 머신에서 실행할 수 있다. ggml의 저수준 커널을 재사용한 덕분에 추론 성능은 llama.cpp에 근접한다고 한다.
인자 하나로 GGUF가 transformers 안에
사용법은 생각보다 간단하다.
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained( "unsloth/Qwen3.5-4B-GGUF", gguf_file="Qwen3.5-4B-Q4_K_M.gguf",
)이후는 표준 transformers 워크플로다. tokenizer, generate, 커스텀 logits 프로세서 모두 그대로 쓸 수 있다. 같은 체크포인트는 transformers serve로 OpenAI 호환 API로 노출할 수 있어 Jan, Pi 같은 클라이언트를 채팅 프론트엔드로 쓸 수 있다.
이번 업데이트에서 가장 설득력 있는 부분은 성능이다. Hugging Face는 MacBook Pro M2 Max(32GB 통합 메모리)에서 세 종류의 체크포인트—소형 dense 모델, 대형 dense 모델, MoE 모델—를 실측했고, transformers의 생성 처리량은 llama.cpp의 llama-bench 점수와 사실상 동등했다. 비결은 ggml Metal 커널의 재사용이다. 양자화 행렬 연산, 융합 정규화, flash attention 등 핵심 연산자가 ggml 구현을 직접 호출하고 Python은 오케스트레이션만 맡는다.
누구를 위한 것인가: 속도 추구자가 아닌 연구자를 위한 것
공식 블로그는 대상 사용자를 분명히 밝힌다. 이 통합이 다루는 것은 주로 네 가지 수요다. Python/PyTorch에서의 GGUF 실험, 기존 평가 워크플로로 양자화 체크포인트 평가, GGUF 변환의 정확성 검증, 그리고 GGUF 역양자화 후 파인튜닝 지속이다. 해결하는 것은 '개발 편의성'이지 '더 빠름'이 아니다. 블로그에는 효율적인 로컬 추론의 권장 엔진은 여전히 llama.cpp라고 명시되어 있다.
경계도 짚어두자. 초기 지원은 Apple Silicon 한정으로 Qwen3.5 아키텍처부터 시작한다. transformers main 브랜치와 kernels 패키지가 필요하며, 호환 양자화 커널이 없으면 역양자화 로딩으로 폴백해 메모리 사용량이 확연히 늘어난다. 본 사이트는 앞서 llama.cpp의 로컬 추론 기반으로서의 위치를 소개한 바 있다(llama.cpp는 누구를 위한 것인가? 로컬 모델의 경량 기반이지 채팅 제품이 아니다 (/zh/article/1856-llama-cpp-shi-he-shui-ben-di-pao-mo-xing-de-qing-liang-di-zuo-bu-shi-liao-tian-c)). 이번 업데이트는 이렇게 읽힌다. 추론은 계속 llama.cpp로, 연구·프로토타이핑에서는 같은 GGUF 파일을 transformers 안에서 직접 다룰 수 있다. 두 툴체인 사이로 가중치를 오가게 할 필요가 없어졌다.
중국 개발자에게도 현실적인 의미가 있다. Qwen3.5 같은 인기 모델의 GGUF 배포판(Unsloth, bartowski 등)은 Hub에서 엄청나게 다운로드된다. PyTorch 생태계에서 쓰려면 그동안 직접 로딩 로직을 짜야 했지만, 이제 공식 경로가 닦였다.
