unsloth - MiniMax-M2.7-GGUF (UD-Q4_K_XL) 모델 깨짐 --> 사용 금지
unsloth - MiniMax-M2.7-GGUF in BROKEN (UD-Q4_K_XL) --> avoid usage
핵심 요약
Unsloth가 검증 없이 성급하게 양자화 모델을 배포하여 오류가 발생한다는 비판이 제기됨.
- 품질 검증 미흡 — PPL 및 KLD 측정 없이 성급하게 모델을 배포하여 치명적인 오류 발생
- 커뮤니티 비판 — 검증된 다른 제작자(bartowski 등)의 모델을 선호하는 분위기 형성
- 개발자 대응 — Unsloth 측에서 문제를 인지하고 조사 중이나, 비판적인 여론이 거셈
- 오픈소스 기여 — 빠른 배포가 llama.cpp 버그 수정에 도움을 준다는 옹호 의견도 존재
난 이미 이런 방식(unsloth나 다른 곳들)에 질렸어. '우리가 제일 먼저 내야지, 왜냐면 새로운 모델에 굶주린 사람들이 있다는 걸 아니까'라는 식인데, 정작 다른 양자화 제작자들처럼 PPL을 체크해서 'NaN' 같은 치명적인 결함을 확인하거나 PPL/KLD 수치를 공개하는 데는 전혀 관심이 없거든.
최근 이런 성급함의 증거가 바로 MiniMax-M2.7-GGUF의 "UD-Q4_K_XL"인데, 간단한 PPL 측정만으로도 모델이 깨졌다는 걸 알 수 있어.
양자화 PPL 측정에서 'NaN'이 뭔지 묻는 사람들을 위해 설명하자면, 이건 보통 백엔드 커널이나 양자화 자체에 수치적인 문제가 있다는 뜻이야. 즉, 제대로 확인도 안 하고 성급하게 양자화했다는 오류지.
다른 HF 제작자들의 비슷한 양자화 모델들을 확인해 봤는데(aessedai/MiniMax-M2.7-Q5_K_M --> 157.226 GiB (5.906 BPW) 그리고 ubergarm/MiniMax-M2.7-IQ5_K --> 157.771 GiB (5.926 BPW)), 그런 오류는 전혀 없었어.
하지만 이건 백엔드 커널 문제도 아니고, unsloth가 그렇게 떠들어대는 "오염된 CUDA 13.2" 문제도 아니야.
양자화를 성급하게 배포하기 전에 확인할 방법들은 얼마든지 있어(예를 들어, 양자화에 "0" 블록이 있는지 확인해 주는 --validate-quants 같은 거).
제발 Unsloth, QA 수준을 맞추고 HF의 "GGUF 양자화 커뮤니티"에서 통용되는 기준을 지켜줘. 최소한 내부적으로라도 위생 관리 차원에서 PPL과 KLD 데이터를 투명하게 공개해. 이런 실패를 피하려면 말이야. 서두르지 마!
~/llms/llama.cpp/build/bin/llama-perplexity -m ~/models/gguf/unsloth/MiniMax-M2.7-UD-Q4_K_XL/MiniMax-M2.7-UD-Q4_K_XL-00001-of-00004.gguf -f ~/models/wikitext-2-raw/wiki.test.raw -fa 1 -ctk f16 -c 512 -ngl 99 -b 512 -ub 512 --seed 1337 --chunks 250
VS
~/llms/llama.cpp/build/bin/llama-perplexity -m ~/workbench/aessedai/MiniMax-M2.7-Q5_K_M/MiniMax-M2.7-Q5_K_M-00001-of-00005.gguf -f ~/models/wikitext-2-raw/wiki.test.raw -fa 1 -ctk f16 -c 512 -ngl 99 -b 512 -ub 512 --seed 1337 --chunks 250
