1M 규모 LLM을 1MB로 압축하는 개인 연구 기록

진행하고 있는 것

파라미터(parameter) 크기 1백만 규모의 일본어 언어 모델(LLM)을 노트북 PC 한 대(CPU 전용, GPU 없음)에서 학습시키고, 그 위에 '얼마까지 작게 만들 수 있는지'를 측정하고 있습니다. 학습부터 평가, 압축까지 모두 제 환경에서 진행합니다.

현재 도달한 지점은 fp32로 약 13MB의 모델을 995,341바이트까지 줄였고, 그 과정에서 품질(perplexity) 저하가 측정 시스템의 노이즈 범위 내에 들어오는 것을 확인한 상태입니다. 배율로 따지면 13.1배이지만, 이 '배율'이라는 숫자가 사실 상당히 까다로운 것이라 여러 번 실수했던 이야기도 적을 예정입니다.

여기에 무엇을 쓸 것인가

주로 실패했던 패턴의 기록입니다.

3개월 동안 100개가 넘는 구성을 시도했는데, 그중 명확하게 효과가 있었던 것은 손에 꼽을 정도였습니다. 효과가 없었던 구성이 압도적으로 많았고, 게다가 그 '효과가 없었던 이유'는 사전에 예측하는 것이 거의 불가능했습니다. 그래서,

• 어떤 구성을 시도했고, 어디서 실패했는지
• 측정 시스템의 노이즈가 어느 정도 있어서 몇 % 이하의 차이는 믿어서는 안 되는지
• '개선되었다'고 생각했던 수치가 나중에 조건을 맞추어 보니 사라진 이야기

을 숫자를 포함하여 기록할 것입니다. 재현 가능한 형태로 작성하므로, 같은 것을 하려는 사람이 같은 함정에 빠지는 횟수가 줄어들면 충분하다고 생각합니다.

빈도

월 1회 정도. 측정이 끝난 만큼만 글을 올립니다. 정기적인 업데이트는 약속하지 않습니다(측정하는 데 실시간으로 몇 시간이 걸리기 때문에, 쓸 내용이 없는 달은 쓰지 않을 것입니다).

읽어주시는 분들께

숫자가 잘못되었다고 알게 되면, 수정 기사를 작성할 것입니다. 조용히 내용을 대체하지는 않습니다.

실제로 '어휘를 크게 하면 이득'이라는 하나의 주장을 지금까지 5번이나 정정했습니다. 배율로 보면 +44%, 실바이트(real byte)로 보면 +2~6%가 증가하고, 심지어 파일 크기 영역에 따라 부호 자체가 반전되는 등, 제 결론은 순차적으로 무너져 왔습니다. 최종적으로 알게 된 것은, 제가 1차 때 작성했던 '‘몇 배 압축’을 믿지 말고, 실바이트로 보라'라는 규칙을 저 자신이 어기고 있었다는 사실이었습니다.

그런 무너지는 과정까지 포함하여 쓰기 때문에, '이 숫자는 수상하다'라고 생각하시면 댓글로 지적해 주십시오. 큰 도움이 됩니다.

note와 구분하는 점

note에서는 같은 연구를 배경지식 없이 읽을 수 있는 에세이 형식으로 작성합니다. 여기 Zenn에는 구현(implementation), 설정, 측정 조건, 코드를 올립니다.

Discussion