양자화 LLM 검증에 빈틈…GGUF 저장소 198곳서 빌드 환경 정보 빠져

대형언어모델(LLM)의 원본 가중치에 전자서명이 있어도 이용자가 내려받아 실행하는 양자화 파일까지 검증되는 것은 아니라는 연구가 나왔다. 10월 14일 아카이브에 공개된 연구자 원문에 따르면 대만 국립양명교통대와 국립대만과학기술대 연구진은 GGUF 모델 배포 과정에서 양자화 도구의 빌드 환경 정보가 빠져 독립적인 검증이 어려워진다고 분석했다.

양자화는 모델 가중치의 숫자 정밀도를 낮춰 메모리 사용량을 줄이는 기술이다. 로컬 AI 환경에서는 원본 모델 대신 GGUF 형식의 양자화 파일을 사용하는 경우가 있다. 원본 파일의 서명은 그 파일의 출처와 무결성을 확인해 주지만, 별도 배포자가 만든 양자화 파일이 원본에서 어떤 조건으로 변환됐는지까지 입증하지는 않는다.

연구진은 2026년 8월 허깅페이스 API의 최근 30일 다운로드 순위에서 GGUF 저장소 상위 200곳을 추렸다. GGUF 가중치 파일이 없는 두 곳을 제외한 198곳을 대상으로 대표 파일과 모델 설명 문서를 조사했다. 그 결과 어느 곳도 컴파일러, 대상 아키텍처, 부동소수점 연산 설정 등 빌드 환경을 기록하지 않았다. 양자화 도구인 llama.cpp의 릴리스 버전을 설명 문서에 적은 곳은 19곳이었다.

연구진이 정의한 독립 검증 가능 비율은 공개된 입력과 환경 기록만으로 같은 파일을 바이트 단위까지 다시 만들 수 있는지를 기준으로 한다. 이 기준을 충족한 저장소는 198곳 중 없었다. 다만 이는 조사 당시 공개 정보가 부족하다는 뜻이다. 해당 모델이 변조됐거나 원천적으로 재현할 수 없다는 결론은 아니다.

실제 재현 실험은 차이를 보여줬다. 연구진은 조사 대상 중 네 저장소의 두 가지 양자화 형식을 시험했다. 설명 문서에 빠진 부동소수점 연산 설정과 텐서별 양자화 방식을 보완하자 x86에서는 8개 파일 중 7개, arm64에서는 8개 중 5개를 비트 단위까지 일치시켰다. 같은 모델과 양자화 형식 이름을 쓰더라도 컴파일 조건과 세부 변환 방식이 달라지면 결과 파일이 달라질 수 있다는 설명이다.

연구진은 배포자가 원본 가중치, 보정용 중요도 행렬, 텐서별 양자화 방식, 도구 버전과 빌드 환경을 함께 기록하고 암호학적 해시로 연결할 것을 제안했다. 서명된 원본과 배포된 양자화 파일 사이의 변환 과정을 제3자가 재현해 확인할 수 있도록 하자는 취지다. 조사 자료와 분석·재실행 도구도 공개 저장소에 올렸다.

이번 결과는 아카이브 사전공개 논문에 제시된 것으로, 동료 심사를 거친 확정적 결론과 구분할 필요가 있다. 재현 실험은 일부 Qwen·Granite 모델과 llama.cpp의 CPU 양자화 과정에 한정돼 GPU 기반 양자화나 모든 모델 배포 방식으로 일반화할 수 없다. 연구진은 변환 단계의 재현에 성공하더라도 입력 원본 자체에 심어진 악성 동작까지 탐지하는 것은 아니라고 선을 그었다.

출처: arXiv, ‘What You Sign Is Not What You Run: The Verifiability Gap in Quantized LLM Supply Chains’
https://arxiv.org/abs/2610.19498
https://arxiv.org/html/2610.19498v1
연구진 공개 자료·재현 도구, gguf-verifiability-artifact
https://github.com/Rlonglong/gguf-verifiability-artifact