DP-LoRA 침묵적 손상 사례

커뮤니티는 장기간의 재현 시도와 공유된 바인딩 테스트 결과를 바탕으로 문제 원인에 대해 실무적 합의를 도출했다. 여러 사용자가 동일 환경에서 재현 결과를 보고하며 호출 순서가 결정적이라는 경험적 증거를 보강했고 프로젝트 레벨의 PR과 문서 변경이 수반되었다. 전반적으로 문제를 단일 라이브러리 버그로 환원하기보다 라이브러리 간 상호작용과 안전 패턴 부족이라는 구조적 문제로 인식하는 분위기가 형성되었다.

• 모델을 특정 디바이스로 이동시키는 model.to(device) 호출을 get_peft_model()보다 먼저 실행하여 accelerate 스타일의 지연된 장치 처리가 Opacus의 per-sample-gradient 훅을 우회하지 않도록 해야 한다.
• 디버깅 시에는 단순한 학습 로그와 privacy accountant 지표만으로는 충분하지 않으므로 가중치 변화 여부를 직접 확인하는 체크를 추가하고 CPU와 서로 다른 GPU 환경에서 재현 테스트를 수행해야 한다.
• 라이브러리 간 통합에서는 훅 연결 시점과 모델 래핑 시점에 대한 명시적 안전 패턴을 적용하고 테스트 케이스로 per-sample 그라디언트 흐름을 검증하는 절차를 포함해야 한다.

LoRA

— LoRA는 전체 모델 가중치를 직접 업데이트하지 않고 저순위(low-rank) 적응 행렬 두 개만 학습해 파라미터 업데이트를 대체하는 파인튜닝 기법이다. 이 방식은 파인튜닝 중 업데이트되는 매개변수 수를 크게 줄여 저장과 전송 비용을 낮추며, 원본 모델 가중치를 그대로 유지하면서 빠른 실험이 가능하게 한다. 본 글 맥락에서는 LoRA의 저수준 가중치가 실제로 업데이트되지 않은 현상이 문제의 핵심으로 작동 원리와 안전 검증이 연관된다.

Opacus

— Opacus는 PyTorch 기반의 differential privacy(차등 프라이버시) 툴킷으로, per-sample gradient를 계산하고 noise를 추가하여 학습 중 프라이버시 보증(ε 계산 등)을 제공한다. 내부적으로 각 샘플에 대한 그라디언트를 훅으로 수집하고 집계하여 privacy accountant로 전달하는 방식으로 동작한다. 본 글에서는 Opacus의 per-sample-gradient 훅이 장치 배치 처리 방식과 충돌해 의도한 대로 작동하지 않은 사례가 핵심이다.

PEFT

— PEFT는 Parameter-Efficient Fine-Tuning을 구현하는 라이브러리 집합으로, LoRA 같은 저파라미터 파인튜닝 전략을 모델에 적용하는 헬퍼 함수를 제공한다. 주로 get_peft_model() 같은 호출을 통해 원본 모델에 적응적 파라미터를 삽입하거나 래핑하여 파인튜닝 가능한 인터페이스를 생성한다. 본 사건에서는 PEFT의 모델 래핑과 장치 이동 시점이 Opacus 훅과 상호작용하며 문제를 야기했다.

Device placement

— Device placement는 모델 파라미터와 텐서를 CPU나 특정 GPU로 옮기는 작업 시점과 순서를 의미하며, model.to(device) 호출로 수행된다. 라이브러리 간에 모델 래핑이나 지연된 장치 이동(lazy device handling)이 섞이면 훅이 연결되기 전후의 장치 상태가 달라져 그라디언트 수집이나 가중치 업데이트가 누락될 수 있다. 본 사례에서는 장치 배치 순서가 LoRA 가중치 업데이트 여부를 결정하는 핵심 요인으로 확인됐다.