RTX 3060으로 LLM 가중치 행렬을 약 50분의 1로 압축했을 때, 원래 계산이 재현되는가

서론

중요한 점은 이 글이 LittleBit-2의 최종 성능을 재현하거나 평가하는 것은 아니라는 것입니다. 가정용 GPU에서 실행 가능한 초기 압축 단계만 분리하여, 어떤 과정에서 얼마나 수치 오차가 발생하는지 조사한 기록입니다.

게임 NPC에게 로컬 LLM을 사용해 자연스러운 한국어로 대화하게 만들고 싶습니다. 간단히 말해 자체적으로 RaizaChat과 같은 시스템을 만들어 보고 싶습니다.

다만 사용할 GPU는 RTX 3060 12GB입니다. 게임 본체도 같은 PC에서 구동하기 때문에 VRAM에 여유가 필요합니다. 덧붙이자면 친구에게 로컬 LLM을 만져보게 해주고 싶습니다. 대화하는 것만으로도 충분합니다. 하지만 친구의 GPU는 VRAM 8GB라, 12B 모델을 돌리기는 조금 버거워 보였습니다.

그래서 궁금해진 것이 Samsung Research의 연구인 'LittleBit-2'입니다.

이것은 LLM의 가중치 행렬을 저랭크(low rank) 이진 인수분해(binary factor) 등으로 표현하여, 매우 적은 비트 수로 저장하는 것을 목표로 한 연구이며,

공식 구현을 보고 '이거라면 큰 모델을 작은 GPU에서 구동할 수 있지 않을까?'라고 생각했습니다.

최종적으로는 Gemma 4의 12B급 모델을 압축하여, 공식 경량 모델 E4B와 비슷한 메모리 예산으로 NPC 대화 능력을 비교해 볼 계획이었습니다.

그렇다고 해도 갑자기 12B를 압축하는 것은 쉽지 않습니다.

우선 Qwen2.5-1.5B-Instruct의 가중치 행렬을 단 하나만 꺼내서, 압축 메커니즘과 원래 계산을 얼마나 재현할 수 있는지 확인하기로 했습니다.

결론부터 말하자면, 저장 용량은 약 50분의 1이 되었습니다. 하지만 압축된 행렬 출력에는 약 88~90%의 상대 RMS 오차가 남아 있었습니다.

파일을 작게 만드는 데는 성공했지만, 원래 계산을 유지하는 것은 훨씬 어려웠다는 이야기입니다.

저는 압축 기술 전문가는 아니며, '게임에서 써보고 싶다'고 생각한 입장의 사람입니다. 실험 목적과 범위는 제가 정했고, 구현/측정/진단/기록은 Codex의 Sol 6.1 (이하, Sol)에게 맡겼습니다.

이 글은 그 개인적인 실험 기록입니다.

처음 주의할 점: 이번에 압축한 것은 Qwen2.5-1.5B-Instruct의 행렬 단 하나일 뿐입니다. 모델 전체를 압축하거나, 압축 후 텍스트 생성을 한 것은 아닙니다.

약 50분의 1이라는 수치도 이 행렬의 저장 용량에 대한 결과이며, 모델 전체 용량이나 VRAM이 50분의 1이 된 것은 아닙니다.

1. 실험 환경

LittleBit의 공개 구현을 이용해 Joint-ITQ를 활성화하여 초기 압축을 진행했습니다. 연구용 packed 연산과 진단 코드는 Sol이 구현했습니다.

대략적인 흐름은 다음과 같습니다.

원래 행렬 → 저랭크 분해 → Joint-ITQ → 이진화/스케일 근사 → 잔차를 이용한 보정

저랭크 분해는 큰 행렬을 더 작은 두 행렬의 곱으로 근사하는 방법입니다.

이 작은 행렬을 더욱 이진화함으로써 저장량을 대폭 줄여보려는 생각입니다.

이번에는 압축 후에 모델을 재학습시키는 QAT (양자화를 고려한 학습)나 지식 증류는 진행하지 않았습니다.

즉, 학습으로 능력을 회복시키기 전의 초기 압축만을 조사하고 있습니다.

2. 우선, 압축 자체는 가능했다

처음에 선택한 것은 rank176이었습니다.

주 인자(principal factor)와 잔차 인자(residual factor)에 각각 rank176을 할당하고, Joint-ITQ를 각 50회 실행했습니다.

결과는 다음과 같습니다.

압축된 파일은 555,600byte였습니다. 이진 인수분해만 포함된 것이 아니라, 스케일(scale)이나 저장 형식의 부가 정보까지 포함한 크기입니다.

용량만 보면 상당히 매력적입니다.

더 나아가, 압축된 인자를 사용한 packed 연산과, 같은 인자를 부동소수점으로 계산한 결과를 비교했습니다.

GPU 상에서의 최대 절대 차이는 약 $9.54 imes 10^{-7}$로, 설정한 허용 오차 범위 내였습니다. 저장한 데이터를 다시 읽어와도 인자의 내용은 완벽하게 일치했습니다.

적어도, 작게 저장하고 그 데이터로부터 계산하는 메커니즘은 정상적으로 작동하고 있었습니다.

다만, 이번 packed 연산은 연구용 참조 구현입니다. 계산 시 인자를 작은 단위로 전개했기 때문에, 전용 비트 연산 커널로 고속 추론이 가능하다는 것을 보여준 것은 아닙니다.

자, 여기까지는 순조로웠습니다.

문제는 원래 학습된 행렬과 비교했을 때입니다.

3. 원본 행렬과 비교하니 오차가 컸다

압축할 수 있다 하더라도, 원본 계산 결과와 크게 달라진다면 모델의 능력을 유지할 수 있을지 알 수 없습니다.

그래서 원래 Qwen에서 실제 입력 데이터(activation)를 추출하여, 압축 전후 행렬 출력을 비교했습니다.

사용된 것은 일본어의 간단한 지시나 게임 NPC 대상 질문 등 6개 입력, 총 378행입니다.

입력에는 prefill(처음에 프롬프트를 처리하는 단계)과 decode(다음 토큰을 순차적으로 처리하는 단계)가 모두 포함되어 있습니다.

비교에는 다음 지표를 사용했습니다.

상대 RMS 오차 = RMS（압축 후 출력 − 원본 출력）÷ RMS（원본 출력）

원본 출력으로부터 수치가 얼마나 벗어났는지를 보여주는 것입니다.

rank176, seed42에서의 결과는 이렇습니다.

이는 상당히 큰 차이입니다.

다만, 여기서 오해해서는 안 되는 부분이 있습니다.

'대화 능력이 9할 손실되었다'라는 의미가 아닙니다.

측정한 것은 어디까지나 하나의 행렬 계산 결과일 뿐입니다.

압축된 행렬을 모델 전체에 통합하여 문장을 생성한 것이 아니므로, 실제로 대화 능력이 얼마나 변할지는 아직 알 수 없습니다.

또한, BF16과 FP32의 약 0.53%라는 값은, 압축된 인자들끼리 비교한 또 다른 측정치입니다. 약 88%의 오차에서 단순하게 빼낼 수 있는 숫자가 아닙니다.

그럼에도 불구하고, 원본 계산을 재현한다는 의미에서는 힘든 결과였습니다.

참고로, 다른 난수 seed에서도 비슷한 경향이 확인되고 있습니다.

4. 어디서 오차가 커졌는가

처음에는 이진화(二値化)나 bit packing 과정에서 큰 오차가 발생했을 가능성도 생각했습니다.

그래서 압축 처리를 단계별로 조사했습니다.

여기서 알게 된 것은, 이진화하기 전 저랭크 근사 시점에서 이미 약 87%의 오차가 있었다는 것입니다.

더 나아가, 인자의 크기를 소수점 scale로 근사하면 오차가 증가했고, 잔차를 더함으로써 일부를 되찾았습니다.

즉, 이번에 발생한 큰 오차는 packed 연산의 결함이나 BF16 계산 정밀도만으로는 설명할 수 없습니다.

그렇다면 애초에 rank176에서는 너무 작은 것일까요?

5. rank를 늘리면 개선되는가

다음으로, 같은 행렬에서 rank를 176, 352, 704로 바꿔 비교했습니다.

| rank (주·잔차 각) | 저장 용량 | prefill 오차 | decode 오차 |
|---|---|
| 176 | 0.530MiB | 88.1% | 89.6% |
| ... |
rank176은 선행 측정을 재사용했고, 352와 704는 seed42로 새로 측정했습니다.

결과를 보면, rank를 늘림으로써 확실히 개선되고 있습니다.

다만, rank704에서도 출력 오차는 약 63%였습니다. 저장 파일은 rank176의 약 3.5배로 늘어났습니다.

용기를 크게 하면 원본 계산에 가까워진다. 하지만 여전히 큰 차이가 남는다.

그런 결과입니다.

또 하나, 저랭크 분해의 계산 정밀도 자체도 의심했습니다.

이번에 사용한 randomized SVD는 고속으로 저랭크 근사를 구하는 방법입니다. 일반적인 SVD라면 더 정확하게 근사할 수 있을지도 모릅니다.

그래서 rank176의 연속 저랭크 근사에 대해 비교했습니다.

일반 SVD 값은 FP32로 분해·재구성하고, 오차를 FP64로 집계한 것입니다. 같은 FP32 집계로 비교했을 때는 약 88.33%였습니다.

확실히 조금 개선되었습니다.

하지만, 일반 SVD에서도 큰 오차가 남았습니다.

이 결과로부터, 적어도 이번 행렬과 rank 176에 대해서는 randomized SVD의 계산 정확도뿐만 아니라, 저랭크 표현 자체의 용량 제한이 크다고 생각됩니다.

물론, 원래 가중치를 잘 근사하는 것과 실제 입력에 대해 중요한 계산을 남기는 것은 같지 않습니다.

입력의 특징을 고려하는 다른 압축 방법이라면, 같은 용량이라도 개선할 가능성은 있습니다.

6. 원 논문을 조사하며 알게 된 또 다른 점

여기까지 측정하고 난 후, LittleBit-2의 논문과 실험 조건도 다시 살펴보았습니다.

그 과정에서 중요한 차이점을 발견했습니다.

논문에서 제시된 최종 모델 성능은 초기 압축만으로 얻어진 것이 아닙니다.

LittleBit-2는 저랭크 이진 인자(low-rank binary factor)의 초기 상태를 개선하는 연구입니다. 그 이후, QAT나 지식 증류(knowledge distillation) 등의 학습을 거쳐 최종 성능을 평가하고 있습니다.

LittleBit-2 논문에서 사용된 모델이나 학습 조건은 이번 Qwen 단일 투영 실험과는 다릅니다.

즉, 저희는 학습으로 회복시키기 전의 단계를 살펴보고 있었던 것입니다.

그러므로, 이번 결과만으로 "LittleBit-2는 쓸모없다"라고 말할 수는 없습니다.

반면, 원 논문에 가까운 대규모 QAT나 증류를 가정용 RTX 3060만으로 재현하는 것도 쉽지 않습니다.

작게 저장하는 기술과, 작아도 능력을 유지하는 기술은 별개의 문제였습니다.

이번 실험에서 특히 강하게 느낀 것이 바로 그 점입니다.

7. 여기서 실험을 중단한 이유

이번에 확인된 것은 단일 투영의 초기 압축, packed 연산의 수치 검사, 단계별 오차, rank에 따른 변화, 일반 SVD와의 비교까지입니다.

모든 모델의 압축이나 QAT, 증류, 압축 후의 문장 생성은 진행하지 않았습니다.

또한, 실험 도중에는 계산 자원 모니터링에도 미비점이 발견되었습니다.

Windows 환경에서 부모 프로세스(parent process)만 감시하고 있어, 실제로 계산하는 자식 프로세스(child process)의 RAM 사용량을 정확히 측정할 수 없었던 것입니다.

Sol이 감시 방법을 수정하여 재측정했고, 수정 전 결과나 실패 기록도 남겼습니다.

수치 검사에서도 일반 SVD의 FP32 노름 집계와 고유값 꼬리(eigenvalue tail)의 엄격한 대조, ITQ의 회전 전후 곱의 대조에서 FAIL이 있었습니다.

전자는 FP64 집계로 차이가 크게 줄어드는 것을 확인했지만, 원래 검사를 PASS로 변경한 것은 아닙니다. ITQ의 차이도 큰 압축 오차에 비하면 미미하지만, 엄격한 대조에 실패했다는 사실은 남겨두었습니다.

따라서 추가적인 seed 실험은 진행하지 않고 중단했습니다.

이것들이 실험 결과를 모두 부정하는 것은 아니지만, 확인된 범위와 아직 확인되지 않은 범위를 나누어 두고 싶다고 생각합니다.

무리하게 나아가기보다는, 지금까지의 측정을 기록하고 문헌과 대조하여 다음 방법을 고민하기로 했습니다.

8. NPC를 만드는 것만이라면 다른 길이 있었을지도 모른다

이번 출발점은 압축 연구 그 자체는 아니었습니다.

RTX 3060으로, 자연스럽게 대화하는 게임 NPC를 구동하고 싶었기 때문입니다.

그 목적이라면, 이미 사용 가능한 3~4bit 양자화 모델을 사용하는 방법도 있습니다.

더 나아가, NPC의 설정이나 기억을 모두 LLM에 맡기지 않고, 게임 측에서 관리하는 설계도 고려할 수 있습니다.

예를 들어 여관 NPC라면, 숙박 요금이나 예약 상태는 Godot 측에서 관리하고, LLM에게 그 정보를 사용해 자연스럽게 이야기하도록 하는 것입니다.

그렇게 하면 LLM에게 모든 것을 암기시킬 필요가 없습니다.

실제로 이번에 사용한 원본 Qwen1.5B는 숙박비나 통행 금지 정보에는 올바르게 답하는 경우가 있었지만, 다음과 같은 출력도 있었습니다.

플레이어

옷이 비에 젖었습니다. 어떻게 해야 할까요?

여관 "풍기정" 주인 미나

바로 건조시키세요. 냉장고에 두고, 온기를 제거하세요.

젖은 옷을 냉장고에 넣는, 상당히 참신한 시각의 환영이었습니다.

고열을 내면서 손님의 처리를 하는 것 같은 대응에 나도 모르게 두 번 쳐다보았습니다.

참고로, 이것은 압축 전의 답변입니다.

중요하니 다시 말씀드리자면, 이것은 압축 전의 답변입니다.

모델을 크게 하면 해결되는 문제도 있겠지만, 게임 측에서 보장하는 것이 더 좋은 정보도 있습니다.

압축 방식뿐만 아니라, 애초 NPC 설계 자체를 재검토할 여지가 있어 보입니다.

참고로, 3~4bit 양자화 모델과 Godot을 결합했을 경우의 속도나 대화 품질에 대해서는 아직 실측하지 못했습니다.

요약

이번 실험에서는 RTX 3060으로 학습된 LLM의 가중치 행렬 중 하나를 약 50분의 1로 압축하고 저장할 수 있었습니다.

하지만, 원래 행렬의 출력을 재현한다는 의미에서는 큰 오차가 남았습니다.

원인을 조사해 보니, 저랭크 근사(low-rank approximation) 단계부터 큰 차이가 있었고, 랭크를 늘리면 개선되기는 했지만 아직 충분하지 않았습니다.

한편, 원 논문의 최종 성능은 QAT(양자화 인식 학습)와 증류(distillation)를 거친 결과이므로, 이번 초기 압축만으로 실험한 것과 직접 비교할 수는 없습니다.

이번 결과가 LittleBit-2 전체의 유효성을 부정하는 것은 아니며, QAT로 어디까지 회복할 수 있을지도 알 수 없습니다.

그럼에도 불구하고, 마찬가지로 '큰 LLM을 극단적으로 작게 만들어서 집의 GPU에서 구동하고 싶다'고 생각하는 사람에게는 참고가 될 만한 부분이 있으면 좋겠습니다.

압축률, 계산 재현성, 대화 능력, 학습에 필요한 비용. 이들은 각각 따로 확인해야 합니다.

이것이 이번 가장 큰 배움이었습니다.

그리고 처음에 만들고 싶었던 게임 NPC는 아직 완성되지 않았습니다.

여관 여주인과 평범하게 대화하려고 했는데, 어느새 행렬 분해 실험을 하고 있었습니다.

다음에는 숙소에 묵을 때 냉장고로 옷을 차갑게 해보려는 여주인이 아니라, 서프라이즈도 없는 평범한 여주인에게 체크인하고 싶습니다.

실험 담당 및 검증 범위에 대하여

이번에는 제가 NPC 제작의 목적, 이용 조건, 실험의 지속/중단 여부를 결정했습니다.

ChatGPT에게는 논문 이해 보조, 실험 안 및 검증 관점 제안, 결과 리뷰를 도움 받았습니다.

Codex의 Sol 6.1은 실제 코드 구현, 로컬 GPU에서의 측정, 진단, 기록을 담당했습니다.

저장물의 SHA-256 감사(audit)는 실시했지만, 이는 파일 무결성 확인일 뿐이며 결과의 정확성을 독립적으로 인증하는 것은 아닙니다. 제3자에 의한 완전한 재현도 미실시입니다.

참고 자료

• LittleBit-2 원 논문 (ICML 2026)
• LittleBit-2 논문 본문 (arXiv 버전)
• SamsungLabs / LittleBit 공식 GitHub
• LittleBit 공식 구현의 LICENSE

LittleBit 공식 구현의 라이선스는 CC BY-NC 4.0입니다. 실험 코드나 압축된 모델을 공개할 경우의 라이선스, 파생물, 특허 등의 문제는 별도로 확인이 필요합니다. 현재는 개인 연구 및 시제품으로 진행하고 있습니다.

Discussion