Q4_K_M 히든딤 커팅 사냥: 노래방 리모컨 같은 버그를 찾아서

## 3개월 만에 발견된 silent regression

배포 후 3개월. 사용자 불만이 조용히 쌓이고 있었다. "지시를 무시한다"는 피드백이 0.5%에서 3%로 늘더니, 특정 프롬프트 패턴에서 instruction following 정확도가 91%에서 78%로 뚝 떨어졌다. 모델은 llama.cpp 기반 quantized GGUF, Q4_K_M. 처음엔 "오래된 캐시 문제"로 치부했지만, 로그를 까보니 특이한 패턴이 보였다.

히든딤 4096 중 후반부 512차원 (인덱스 3584~4095)의 활성화 값이 거의 0에 수렴하고 있었다. Q4_K_M은 block-wise quantization으로 32개의 히든딤을 한 블록으로 처리하는데, 여기서 특정 블록이 잘려나간 것 같았다. 실제로 해당 블록의 양자화 스케일 팩터가 비정상적으로 작았다 (평균 0.03 vs 정상 블록 0.15~0.20).

## 초보자 vs 숙련자의 선택 기준이 갈리는 지점

초보자들은 보통 "Q4_K_M이면 충분하지?" 라고 생각한다. 벤치마크 점수만 보면 Q8과 차이가 1~2%니. 하지만 숙련자들은 특정 용도(예: instruction following이 중요한 챗봇)에서는 Q5_K_M이나 Q6_K를 고집한다. 왜?

Q4_K_M은 그룹 크기를 32로 하고, 각 그룹 내에서 scale과 min을 따로 저장한다. 문제는 잘 훈련된 모델의 히든딤 분포가 완전 균일하지 않다는 점. 특히 attention head의 출력이나 FFN의 게이트 값들은 특정 차원에 정보가 집중되는 경향이 있다. 이런 차원들이 우연히 같은 그룹에 몰리면, 그룹의 다이내믹 레인지가 커져 양자화 오차가 폭발한다. 그게 extreme case에서는 해당 그룹 전체가 0으로 죽는다.

## field-log: 무엇을 봐야 하는가

### 1. 관찰 시각
배포 전 validation metric으로는 보통 perplexity나 downstream task accuracy만 본다. 하지만 이건 aggregate metric이라 이런 국소적 죽음이 가려진다. 우리 팀은 프롬프트 마지막 토큰의 hidden state를 추출해 차원별 분산을 체크하는